**Probability of Potential Collision for Aircraft Encounters in High Density Airspaces**

R. Arnaldo, F.J. Sáez, E. Garcia and Y. Portillo

Additional information is available at the end of the chapter

http://dx.doi.org/10.5772/48685

#### **1. Introduction**

86 Advances in Air Navigation Services

ISSN 0951-8320

September 2009

287, ISSN 1435-5558

*Factors*, Vol.37, No.1, pp. 32-64, ISSN 0018-7208

*Machine Studies*, Vol.39, No.3, pp. 473-493

73738-4, Beijing, China, July 2007

080581874X, Lawrence Erlbaum, Mahwah, NJ

Chang, Y.H.J. & Mosleh, A. (2007). Cognitive modelling and dynamic probabilistic simulation of operating crew response to complex system accidents, Part 1: Overview of the IDAC model, *Reliability Engineering and System Safety*, Vol. 92, No.8, pp. 997-1013,

Endsley, M.R. (1995). Towards Theory of Situation Awareness in Dynamic System, *Human* 

Furuta, K. & Kondo, S. (1993). An approach to assessment of plant man-machine systems by computer simulation of an operator's cognitive behavior, *International Journal of Man-*

Furuta, K.; Soraji, Y.; Kanno, T.; Aoyama, H.; Inoue, S .; Karikawa, D. & Takahashi, M. (2009). Cognitive Model of Team Cooperation in En-Route Air Traffic Control, *Proceedings of ESREL 2009*, pp. 1811-1816, ISBN 13 978-0-415-48513-5, Prague, Czech,

Kanno, T. (2007). The notion of sharedness based on mutual belief, *Proceedings of 12th International Conference on Human-Computer Interaction*, pp 1347-1351, ISBN 978-3-540-

Klein, G. (1997). Recognition-primed decision model: looking back, looking forward, In: *Naturalistic decision making*, C.E. Zsambok & G. Klein, (Eds.), pp. 285-292, ISBN 10

NASA (2011). *MIDAS: Man-Machine Integration Design and Analysis System*, 15.07.2011, Available from: http://humansystems. arc.nasa.gov /groups/ midas/index.html Shu, Y. & Furuta, K. (2005). An inference method of team situation awareness based on mutual awareness, *International Journal of Cognition, Technology, and Work*, Vol.7, pp. 272-

Soraji, Y.; Furuta, K.; Kanno, T.; Aoyama, H.; Inoue, S.; Karikawa, D. & Takahashi, M. (2010). Cognitive model of team cooperation in en-route air traffic control, *International Journal* 

*of Cognition, Technology, and Work*, 07.03.2012, Available from: http://www.springerlink.com/content/g6122786tjq7w81t/fulltext.pdf Collision risk estimation in airspace and mathematical modeling of mid-air collisions have been carried out for over more than 40 years [1]. During this period there has been a development of mathematical models for processes leading to possible collisions of aircraft flying nearby in order to estimate the risk of collision.

B. L. Marks [2] developed the principles in which a collision risk model could be developed in the early 1960s. Marks' work was modified and enhanced by P. Reich [3] and that model, later called the Reich model, has been the basis for many of the important developments in this field.

The Reich model uses information related to the probabilistic distributions of aircraft's lateral and vertical position, traffic flows of the routes, aircraft's relative velocities and aircraft dimensions to generate estimation of collision risk. However, this model does not cover adequately situations where ground controllers monitor the air traffic through radar surveillance and provide tactical instructions to the aircraft crews. Furthermore, the problem of collision risk modeling in the analysis of "high traffic density" ATC scenarios is different to that of "procedural scenarios", which have been developed by Reich [4] and Brooker [5], amongst others. This is mainly due to the active role of Controllers in the first case. In this case positive control is used extensively to modify the planned aircraft route. This requires the inclusion in the model of "human factor response" behavior.

These "collision risk models" were initially applied in the 60s to determine safe separation standards between pairs of aircraft flying at the same altitude on parallel courses over the North Atlantic Ocean [6]. Since then, new models have been developed and continually refined and improved. They have been applied for different geographic regions (USA [7], European airspace [8]), for oceanic or radar [9] environments, and different flight regimes

#### 88 Advances in Air Navigation Services

(for example, high-altitude cruise and landing on close [10,11,12] and ultra close spaced runways [13,14]), for specific flight phases [15] (focused for example on the separation between aircraft on final approach and landing, when flight risks are greater than during any other phase of flight), for different types of separation (vertical, longitudinal and lateral) and also for current and future operational concepts [16], such as free flight [17], airborne self separation [18],….

Probability of Potential Collision for Aircraft Encounters in High Density Airspaces 89

Some authors, like Dr. L. Burt [29], have formulated expressions that attempt to estimate Pa, distinguishing four different aircraft encounters geometries. The mathematical formulas are customized for these geometries so they are only applicable for circumstances that they have been developed for. They barely provide an estimate of the average conditional probability of collision Pa but they do not provide an individual value of Pa for each encounter. Therefore, this approach does not assess the severity of each individual

Other authors, such as Campos [30] have calculated the probability of coincidence for aircraft on arbitrary straight flight paths (either climbing, descending, or in level flight) with constant speed as an upper bound for the probability of collision. Although in this approach the time and distance of closest approach are used to calculate the position for maximum probability of coincidence. In reference [31] same authors illustrate the relationship between the aircraft RMS (Root Mean Square) position error and the minimum separation distance for achieving a certain Target Level of Safety (TLS) for low

Nevertheless, most of the researches on this field have just worked in the estimation of probabilities of conflict (before deliberate actions are taken to solve the conflicts) and how these probabilities depend on aircraft separation standards. Different current and future Air Traffic Management operational concepts have been studied under this perspective in an attempt to reduce aircraft separation standards [32,33] or with the aim of designing proper avoidance maneuvers in order to maintain the prescribed minimum separation standards

The previous considerations give an idea of the complexity of using stored aircraft tracks, within a given scenario and time frame, to infer safety level, collision risk probability and associated system weaknesses. In most high density airspace scenarios recorded tracks can be obtained for all aircraft flying in it, for example, from Radar Data Processing systems (RDP). In fact, this provides us with a robust data source, which could be used for safety analysis. This could include indirect information which is closely related to the "human factor response". Despaite its importance not much effort have been devoted to the development of risk and collision models based upon the analysis of the stored aircraft

Furthermore, it has to be considered that the distribution of aircraft position errors over their intended tracks is one of the most important factors in determining route safety, and consequently it has been broadly studied. Reference [36], for instance, presents a modeling technique to compute the probability density function of position errors as the aircraft proceed along the route taking into account not only the time dependence, but also all the factors influencing an aircraft's position errors, e.g., surveillance and navigation errors,

Following the research line initiated on [31,37,38] by the mentioned previous work, the authors are developing a more detailed mathematical model for both components of

probability of collision in a radar ATC (Air Traffic Control) environment.

surveillance fix rate, and air traffic control procedures.

potential encounter.

probability of collision.

among aircraft [34,35].

tracks.

Most of these models, amongst them the formula proposed by Brooker [19] for mid-air collision risk, involve the aggregation of terms comprising different factors related to: initiating events which produce defective flight paths; the probability of safety defenses correcting these defective flight plans; and traffic and kinematic scalers. But, as he indicates: "it does no more than spell out the mechanisms by which collisions logically have to occur. The hard problem is how to populate the parameters in the formulation with sensible numbers".

Risk models have also been developed for the estimation of conflict probability (understood as the probability that the distance between a pair of aircraft becomes smaller than some specified minimum separation value). Paielli and Erzberger's [20,21] emphasis was on the development of algorithms to numerically evaluate approximations of conflict probabilities. Prandini et al. [22,23] emphasized the analysis of the problem and distinguished three subproblems of evaluating conflict probability.

The main point of conflict probability is its clear relation to a well known safety criterion in civil aviation: the separation minimum, which puts a requirement on the air traffic management system; not to let aircraft come closer to each other than a certain minimum distance. In addition to minimum separation values, ICAO (International Civil Aviation Organization) has also defined limiting criteria for acceptable risk levels of fatal accident, and in particular, for the risk of mid air collision [24 ]. The allowed probability values for such events are of the order of one mid-air collision or physical crossing per 10^9 flight hour.

Furthermore , some effort has been also devoted to the problem of aircraft conflict detection. An excellent survey of the different conflict detection and resolution schemes has been carried out by Kuchar [25,26], where the conflict detection schemes are classified according to the modeling method used for projecting the aircraft position in the future.

According to Brooker [9], mid-air collisions derived from radar inaccuracies are very rare, so to estimate their frequency, it is necessary to model the factors that might lead to such events. But this extremely low value makes it difficult to obtain reliable empirical results from reasonably computational amount of data.

As collisions are very unlikely events most of the previous approaches to estimate collision risk were centered on simulations techniques applicable to rare event estimations such as Montecarlo simulations [27,28]. Nevertheless, simulations are not enough, as the components of the collision models have to be verifiable, i.e. match reality, and cautious. 'Verifiable' in the present context means that the model description can be demonstrated to match what happens in practice, and that most of the parameters in the model can be measured directly by analyzing air traffic patterns.

Some authors, like Dr. L. Burt [29], have formulated expressions that attempt to estimate Pa, distinguishing four different aircraft encounters geometries. The mathematical formulas are customized for these geometries so they are only applicable for circumstances that they have been developed for. They barely provide an estimate of the average conditional probability of collision Pa but they do not provide an individual value of Pa for each encounter. Therefore, this approach does not assess the severity of each individual potential encounter.

88 Advances in Air Navigation Services

self separation [18],….

problems of evaluating conflict probability.

from reasonably computational amount of data.

measured directly by analyzing air traffic patterns.

(for example, high-altitude cruise and landing on close [10,11,12] and ultra close spaced runways [13,14]), for specific flight phases [15] (focused for example on the separation between aircraft on final approach and landing, when flight risks are greater than during any other phase of flight), for different types of separation (vertical, longitudinal and lateral) and also for current and future operational concepts [16], such as free flight [17], airborne

Most of these models, amongst them the formula proposed by Brooker [19] for mid-air collision risk, involve the aggregation of terms comprising different factors related to: initiating events which produce defective flight paths; the probability of safety defenses correcting these defective flight plans; and traffic and kinematic scalers. But, as he indicates: "it does no more than spell out the mechanisms by which collisions logically have to occur. The hard problem is

Risk models have also been developed for the estimation of conflict probability (understood as the probability that the distance between a pair of aircraft becomes smaller than some specified minimum separation value). Paielli and Erzberger's [20,21] emphasis was on the development of algorithms to numerically evaluate approximations of conflict probabilities. Prandini et al. [22,23] emphasized the analysis of the problem and distinguished three sub-

The main point of conflict probability is its clear relation to a well known safety criterion in civil aviation: the separation minimum, which puts a requirement on the air traffic management system; not to let aircraft come closer to each other than a certain minimum distance. In addition to minimum separation values, ICAO (International Civil Aviation Organization) has also defined limiting criteria for acceptable risk levels of fatal accident, and in particular, for the risk of mid air collision [24 ]. The allowed probability values for such events are of the order of one mid-air collision or physical crossing per 10^9 flight hour. Furthermore , some effort has been also devoted to the problem of aircraft conflict detection. An excellent survey of the different conflict detection and resolution schemes has been carried out by Kuchar [25,26], where the conflict detection schemes are classified according

According to Brooker [9], mid-air collisions derived from radar inaccuracies are very rare, so to estimate their frequency, it is necessary to model the factors that might lead to such events. But this extremely low value makes it difficult to obtain reliable empirical results

As collisions are very unlikely events most of the previous approaches to estimate collision risk were centered on simulations techniques applicable to rare event estimations such as Montecarlo simulations [27,28]. Nevertheless, simulations are not enough, as the components of the collision models have to be verifiable, i.e. match reality, and cautious. 'Verifiable' in the present context means that the model description can be demonstrated to match what happens in practice, and that most of the parameters in the model can be

how to populate the parameters in the formulation with sensible numbers".

to the modeling method used for projecting the aircraft position in the future.

Other authors, such as Campos [30] have calculated the probability of coincidence for aircraft on arbitrary straight flight paths (either climbing, descending, or in level flight) with constant speed as an upper bound for the probability of collision. Although in this approach the time and distance of closest approach are used to calculate the position for maximum probability of coincidence. In reference [31] same authors illustrate the relationship between the aircraft RMS (Root Mean Square) position error and the minimum separation distance for achieving a certain Target Level of Safety (TLS) for low probability of collision.

Nevertheless, most of the researches on this field have just worked in the estimation of probabilities of conflict (before deliberate actions are taken to solve the conflicts) and how these probabilities depend on aircraft separation standards. Different current and future Air Traffic Management operational concepts have been studied under this perspective in an attempt to reduce aircraft separation standards [32,33] or with the aim of designing proper avoidance maneuvers in order to maintain the prescribed minimum separation standards among aircraft [34,35].

The previous considerations give an idea of the complexity of using stored aircraft tracks, within a given scenario and time frame, to infer safety level, collision risk probability and associated system weaknesses. In most high density airspace scenarios recorded tracks can be obtained for all aircraft flying in it, for example, from Radar Data Processing systems (RDP). In fact, this provides us with a robust data source, which could be used for safety analysis. This could include indirect information which is closely related to the "human factor response". Despaite its importance not much effort have been devoted to the development of risk and collision models based upon the analysis of the stored aircraft tracks.

Furthermore, it has to be considered that the distribution of aircraft position errors over their intended tracks is one of the most important factors in determining route safety, and consequently it has been broadly studied. Reference [36], for instance, presents a modeling technique to compute the probability density function of position errors as the aircraft proceed along the route taking into account not only the time dependence, but also all the factors influencing an aircraft's position errors, e.g., surveillance and navigation errors, surveillance fix rate, and air traffic control procedures.

Following the research line initiated on [31,37,38] by the mentioned previous work, the authors are developing a more detailed mathematical model for both components of probability of collision in a radar ATC (Air Traffic Control) environment.

#### **2. Fundamentals behind probability of collision estimation**

Jaroslav Krystul [39] defines the risk as the probability of a particular adverse event occurring during a stated period of time. Usually, this is an event occurring when the system reaches a particular critical state. These events with a very small probability of occurrence are called rare events. Applying this definition to an ATC scenario, it is accepted that risk is closely related to those situations in which two aircraft are on conflict course and would not only pass closer than the prescribed horizontal and vertical separation minima but which would, in fact, collide.

The work presented here was originally inspired by the principle stated in [2] by B. L. Marks: "… *the task of relating collision risk to a traffic configuration can be taken in two parts:* 

parts:


According to this idea, the probability of aircraft collision can be expressed as:

$$P(collision) = FeR\*P(pot.coll \{pot.conf \} \* P(coll \{pot.coll \}).\tag{1}$$

Probability of Potential Collision for Aircraft Encounters in High Density Airspaces 91

An initial expectation for probability of potential collision among potential conflicts, **E(Pa)**, could be obtained as the relative frequency that two aircraft, on a conflict course, would not only pass closer than the prescribed horizontal and vertical separation minima, but would in fact collide. This expression provides an expected, or global, value and does not assess the severity of each individual potential encounter itself. This chapter proposes an approach to estimate the severity of the encounter using the conditional probability of a potential collision Pa for each particular aircraft encounter. This proposed approach aims at

 Providing an individual probability of collision for each individual encounter based on the: (1) geometry and kinematics of the encounter, (2) the minimum predicted lateral separation at the CPA, and (3) the minimum predicted vertical separation at

As stated by Ennis [41], a protected zone represents a region around a given aircraft that no

A simplification of the Bellantoni [42] approach for the definition of a collision surface can be made by modelling the aircraft as a cylinder of diameter xy and height <sup>z</sup> as indicated in

Two aircraft are taken as colliding if their cylinders touch. With this bounded and closed airspace region representing the aircraft, a "collision cylinder" can be defined as a larger cylinder of twice the dimensions represented in figure 1, and defined by height 2z and

On the other hand, all high density traffic ATC scenarios have established minimum separation standards defined by two values, the minimum horizontal (R) and vertical (H) separations. When two aircraft are closer than these distances the ATC system is considered to have failed. These values (R, H) allow us to use another cylinder shaped protection model

Taking into consideration the radar data errors and the segmentation errors.

improving the previous works by:

other aircraft should penetrate.

**Figure 1.** Aircraft representation

radius 2xy (see figure 2).

**2.1. Consideration of aircraft protection zones** 

the CPA.

figure 1.

where:


A time horizon is established within which all aircraft positions are projected to explore existence of "potential conflicts". In the following discussion 10 minutes look ahead time has been considered. Accordingly, the relative frequency of potential collisions among potential conflicts F(pot.coll/pot.conf) could be expressed as:

. . ( . / . ) . . . *<sup>a</sup> Num of pot collisions F pot coll pot conf E P Num of pot conflicts* (2)

where Num.pot.collisions is the number of aircraft that are about to collide (and will do if all safety barriers fail).

An initial expectation for probability of potential collision among potential conflicts, **E(Pa)**, could be obtained as the relative frequency that two aircraft, on a conflict course, would not only pass closer than the prescribed horizontal and vertical separation minima, but would in fact collide. This expression provides an expected, or global, value and does not assess the severity of each individual potential encounter itself. This chapter proposes an approach to estimate the severity of the encounter using the conditional probability of a potential collision Pa for each particular aircraft encounter. This proposed approach aims at improving the previous works by:


#### **2.1. Consideration of aircraft protection zones**

As stated by Ennis [41], a protected zone represents a region around a given aircraft that no other aircraft should penetrate.

A simplification of the Bellantoni [42] approach for the definition of a collision surface can be made by modelling the aircraft as a cylinder of diameter xy and height <sup>z</sup> as indicated in figure 1.

**Figure 1.** Aircraft representation

90 Advances in Air Navigation Services

but which would, in fact, collide.

with the traffic density.

the traffic density.

safety barriers fail).

conflicts F(pot.coll/pot.conf) could be expressed as:

together; and

parts:

where:

**2. Fundamentals behind probability of collision estimation** 

2. Determining what chance of collision is inherent in the passing".

According to this idea, the probability of aircraft collision can be expressed as:

Jaroslav Krystul [39] defines the risk as the probability of a particular adverse event occurring during a stated period of time. Usually, this is an event occurring when the system reaches a particular critical state. These events with a very small probability of occurrence are called rare events. Applying this definition to an ATC scenario, it is accepted that risk is closely related to those situations in which two aircraft are on conflict course and would not only pass closer than the prescribed horizontal and vertical separation minima

The work presented here was originally inspired by the principle stated in [2] by B. L. Marks: "… *the task of relating collision risk to a traffic configuration can be taken in two parts:* 

1. Determining the frequency with which aircraft are exposed to risk by passing close

 **FeR**, Frequency of exposition to Risk, here is considered as the relative frequency that an aircraft would potentially violate the separation standards defined for the particular situation, here referred to as potential conflict. It is easily seen that this value increases

 **P(pot.coll/pot.conf)** is the conditional probability of a potential collision (pot.coll) between two aircraft that have previously violated the separation standards (pot. conf). Its value depends on the encounter kinematics and uncertainties associated to predicted positions. It represents the intrinsic severity of the encounter and it is independent of

 **P(coll/pot.coll )** is the conditional probability of collision among potential collisions having failed all the safety barriers (ATC, TCAS) which are in place to mitigate the risk.

A time horizon is established within which all aircraft positions are projected to explore existence of "potential conflicts". In the following discussion 10 minutes look ahead time has been considered. Accordingly, the relative frequency of potential collisions among potential

> . . ( . / . ) . . . *<sup>a</sup> Num of pot collisions F pot coll pot conf E P*

where Num.pot.collisions is the number of aircraft that are about to collide (and will do if all

*Num of pot conflicts* (2)

*P collision FeR P pot coll pot conf P coll pot coll* ( ) ( . . ) ( . ). (1)

Two aircraft are taken as colliding if their cylinders touch. With this bounded and closed airspace region representing the aircraft, a "collision cylinder" can be defined as a larger cylinder of twice the dimensions represented in figure 1, and defined by height 2z and radius 2xy (see figure 2).

On the other hand, all high density traffic ATC scenarios have established minimum separation standards defined by two values, the minimum horizontal (R) and vertical (H) separations. When two aircraft are closer than these distances the ATC system is considered to have failed. These values (R, H) allow us to use another cylinder shaped protection model

#### 92 Advances in Air Navigation Services

for all aircraft which should be free of any other aircraft to fulfil this separation minima (see figure 3). This volume will be called the "conflict cylinder" as it is considered that two aircraft potentially violating these separations are exposed to risk.

Probability of Potential Collision for Aircraft Encounters in High Density Airspaces 93

*z*

2 *<sup>z</sup>*

When civil aircraft are climbing or descending, it is considered that pitch angles are small and so, vertical and horizontal dimensions have small changes. Therefore, all the "modelling

As all the cylinders are considered parallel, the longitudes and surfaces ratios among them

Cylinder Diameter Height

Conflict 2R 2H

**~>**

cylinders" will be considered as horizontal, as indicated on figure 4.

will be constant when they are projected onto any plane.

Aircraft representation *xy*

**Table 1.** Modelling cylinders definition.

**Figure 4.** Modelling Cylinders Orientation

impact plane, of the collision cylinder (2 *xy*

**collision (Pa)** 

perpendicular to *ji v*

inside the collision area.

Collision 2 *xy*

**3. Derivation of a general expression for probability of** 

In order to obtain a general expression of Pa an impact plane is defined as a generic projection plane containing the centre of reference aircraft ACi (assumed as static) and

proximity event). Additionally, the collision area is defined as the projection, over the

where its centroid is the one of the cylinder as well, the conflict area could also be defined as the projection of the conflict cylinder (2R, 2H). The CPAP (Closest Point Of Approach Projection) is a point with coordinates y1p and z1p obtained by projecting intruder aircraft. Figure 5 shows that a conflict will occur if ACj encounters the stationary conflict area, that is, if the CPAp coordinates (y1p, z1p) are inside the conflict area. In the same way, a collision will occur if ACj encounters the stationary collision area, that is, if the CPAp coordinates are

 ,2 *<sup>z</sup>* 

(relative velocity vector between the two aircraft i and j involved in the

). If the conflict cylinder is settled in ACi,

**Figure 2.** Collision cylinder definition

During the en route phase of flight, for example, the conflict cylinder would be 5 nm in radius and 2,000 ft in height. However, these current minimum separation standards were determined many years ago and the method by which they were calculated is not well documented. Recently, Reynolds & Hansman [42] identified factors involved in defining the aircraft separation standards and discussed the importance of accurate state information for controllers in maintaining them. Ennis & Zhao [43] examined the physical compositions of the protected zone and presented a formal approach to the analysis of minimum separation standards.

**Figure 3.** Conflict cylinder definition.

A summary of the modelling cylinders defined so far is presented in the following table.

When civil aircraft are climbing or descending, it is considered that pitch angles are small and so, vertical and horizontal dimensions have small changes. Therefore, all the "modelling cylinders" will be considered as horizontal, as indicated on figure 4.

As all the cylinders are considered parallel, the longitudes and surfaces ratios among them will be constant when they are projected onto any plane.


**Table 1.** Modelling cylinders definition.

92 Advances in Air Navigation Services

**Figure 2.** Collision cylinder definition

**Figure 3.** Conflict cylinder definition.

standards.

table.

for all aircraft which should be free of any other aircraft to fulfil this separation minima (see figure 3). This volume will be called the "conflict cylinder" as it is considered that two

During the en route phase of flight, for example, the conflict cylinder would be 5 nm in radius and 2,000 ft in height. However, these current minimum separation standards were determined many years ago and the method by which they were calculated is not well documented. Recently, Reynolds & Hansman [42] identified factors involved in defining the aircraft separation standards and discussed the importance of accurate state information for controllers in maintaining them. Ennis & Zhao [43] examined the physical compositions of the protected zone and presented a formal approach to the analysis of minimum separation

A summary of the modelling cylinders defined so far is presented in the following

aircraft potentially violating these separations are exposed to risk.

**Figure 4.** Modelling Cylinders Orientation

### **3. Derivation of a general expression for probability of collision (Pa)**

In order to obtain a general expression of Pa an impact plane is defined as a generic projection plane containing the centre of reference aircraft ACi (assumed as static) and perpendicular to *ji v* (relative velocity vector between the two aircraft i and j involved in the proximity event). Additionally, the collision area is defined as the projection, over the impact plane, of the collision cylinder (2 *xy* ,2 *<sup>z</sup>* ). If the conflict cylinder is settled in ACi, where its centroid is the one of the cylinder as well, the conflict area could also be defined as the projection of the conflict cylinder (2R, 2H). The CPAP (Closest Point Of Approach Projection) is a point with coordinates y1p and z1p obtained by projecting intruder aircraft. Figure 5 shows that a conflict will occur if ACj encounters the stationary conflict area, that is, if the CPAp coordinates (y1p, z1p) are inside the conflict area. In the same way, a collision will occur if ACj encounters the stationary collision area, that is, if the CPAp coordinates are inside the collision area.

Probability of Potential Collision for Aircraft Encounters in High Density Airspaces 95

This equation provides and individual probability of collision based on:

This takes into consideration the two probability density functions stating segmentation lateral and vertical errors and the projection lateral and vertical errors characterization.

As a result, the bi-dimensional probability density function of the CPAs can be derived

1 1 1 1 1' 1 1 2 1 1 1 1 ( , ) (' ,' ) ( ' ' ) ' '

*f2(y1,z1)* is the probability density function, representing the distribution of y1p and z1p

 *f1(y'1p,z'1p)* is the statistically determined bi-dimensional probability density function (pdf) of the CPA'p coordinates (y'1p,z'1p) for each projected segment associated to an

*f y z f y y z z f y z dy dz* (4)

*app pp p p p p*

 the predicted minimum lateral separation at the CPA (y1p), and the predicted minimum vertical separation at the CPA (z1p).

*PCF*

 fa is the bi-dimensional probability density function of the CPAs, y1p is the minimum predicted lateral separation at the CPA, z1p is the minimum predicted vertical separation at the CPA ,

coordinates errors due to the errors in the segmentation process, and

*S*

**Figure 7.** Changes in the CPA coordinates due to projecting errors..

geometry and kinematics of the encounter (SPCOL),

from previous equation as:

SPCF is the conflict area

individual encounter.

Where:

**Figure 5.** Impact Plane ,Conflict and Collision cylinder.

**Figure 6.** Impact Plane, Collision Area, Conflict Area and Projected CPA definition.

Considering the changes in the CPA coordinates due to radar and radar data segmentation errors, the probability of potential collision for an intruder aircraft that has violated the separation standards and whose projection consequently hits within the conflict area can be calculated as:

$$P\_a(y\_{1p'}z\_{1p}) = \int\_{S\_{\rm PC}} dP\_1 P\_2 \approx S\_{\rm PCOL} \cdot \int\_{S\_{\rm PC}} f\_1(y'\_{1p} - y\_{1p'}, z'\_{1p} - z\_{1p}) \cdot f\_2(-y'\_{1p} - z'\_{1p}) dy'\_1 dz'\_1 \tag{3}$$

This equation provides and individual probability of collision based on:


This takes into consideration the two probability density functions stating segmentation lateral and vertical errors and the projection lateral and vertical errors characterization.

As a result, the bi-dimensional probability density function of the CPAs can be derived from previous equation as:

$$f\_a(y\_{1p'}, z\_{1p}) = \int\_{S\_{\rm PC}} f\_1(y'\_{1p} - y\_{1p'}, z'\_{1p} - z\_{1p}) f\_2(-y'\_{1p} - z'\_{1p}) dy'\_1 dz'\_1 \tag{4}$$

Where:

94 Advances in Air Navigation Services

calculated as:

**Figure 5.** Impact Plane ,Conflict and Collision cylinder.

**Figure 6.** Impact Plane, Collision Area, Conflict Area and Projected CPA definition.

*PCF PCF*

*S S*

Considering the changes in the CPA coordinates due to radar and radar data segmentation errors, the probability of potential collision for an intruder aircraft that has violated the separation standards and whose projection consequently hits within the conflict area can be

1 1 1 2 1 1 1' 1 1 2 1 1 1 1 (,) · ( ' , ' )· ( ' ' ) ' '

*P y z dP P S f y y z z f y z dy dz* (3)

*app PCOL pp p p p p*


**Figure 7.** Changes in the CPA coordinates due to projecting errors..

#### 96 Advances in Air Navigation Services

Both expressions estimate the probability of potential collision, having a potential separation violation (potential conflict), for each aircraft encounter, provided that uncertainties in the projection of segmented trajectories and in the segmentation process have been characterised by associated pdfs, f1 and f2, respectively.

Probability of Potential Collision for Aircraft Encounters in High Density Airspaces 97

**Figure 8.** 2D histogram of projected horizontal and vertical separations at the CPA (31 days of radar

<sup>0</sup> 0.5 <sup>1</sup> 1.5 <sup>2</sup> 2.5 <sup>3</sup> 3.5 <sup>4</sup> 4.5 <sup>5</sup> 5.5 <sup>0</sup>

Projected Horizontal Separation at the CPA (NM)

Once the empirical general or expected value for Pa has been obtained, Pa was estimated for

*v v fy z*

,4 1 \* , <sup>4</sup>

*v v Pyz f yz v v v*

It also takes into consideration the segmentation of lateral and vertical errors (*f2y* and *f2z*).

A result for Pa estimation for leveled flight encounter is shown in the upper part of figure 8. In this case when CPAp coordinates (yp,zp) are very close to the reference aircraft (ACi), Pa estimated value reaches 3\*10-2. This value has a magnitude of two orders higher than the empirical expected result (5.4·10-4), but strongly decreases when predicted CPAp lays apart from ACi, resulting in values much lower than the empirical one. In the lower part of this figure, the graphs show when one or both aircraft are climbing/descending but having vz/vr ratio close to zero, it could be seen that regardeless the decrease of the maximum value of Pa (7\*10-3), It is still greater than the empirical expected result for Pa. Furthermore, the probability of collision for CPAp for which yp coordinates close to zero but zp coordinates

<sup>2</sup> 2 2

 

*xy x z a p p xy z p p z x x z*

 

4

R

(6)

*z x x z*

*v v v*

*xy x z*

 

This equation provides and individual probability of collision based on:

 the predicted minimum lateral separation at the CPA (yp), and the predicted minimum vertical separation at the CPA (zp).

 

*xy y p z z p*

 

22 1

2 2 2 2

**4.2. Pa estimation for each aircraft encounter** 

each particular encounter by the next expression.

kinematics of the encounter (ratio vz,to,vx),

Potential Collisions

Projected Vertical Separation at the CPA (ft)

H

data)

#### **4. Results and discussion**

The previous mathematical formulation is supported by the previously mentioned ad-hoc software, which has been developed by the authors for Eurocontrol in the framework of the 3D-CRM programme. This software is intended to measure the collision risk in high density ATC en route airspace, based on an analysis of the stored aircraft tracks that have flown in it within a given time frame.

With the purpose of evaluating the mathematical expressions to estimate the probability of collisions, the previously mentioned software tool has been applied to a radar data sample from the Maastricht Upper Area Control Centre (MUAC). EUROCONTROL's Maastricht Upper Area Control Centre (MUAC) is a regional air traffic control centre providing seamless air navigation services in the upper airspace (above 24,500ft) for a large (approximately 700,000 square kilometres) multinational airspace in Europe. An advanced and complex ATC automated system named MADAP (Maastricht Automated Data Processing and Display System) is the technical enabler responsible for managing, processing and presenting in real time information relating to the air traffic flows in the whole area. MADAP performs centralized multi-radar tracking using the information provided by a large number of radars and computes a high quality air traffic situation. In MUAC, a unique horizontal separation standard of 5 NM is used throughout the total area of responsibility. The vertical separation minimum of 1000 ft. is used.

#### **4.1. Empirical estimation for Pa**

The general expression of expected Pa is calculated numerically from the relative frequency of potential collisions among all potential conflicts using the following equation:

$$E\left[\text{P(not.coll}/\text{pot.conf}\right)\right] = E\left[P\_a\right] \approx \frac{\text{Num. of } \text{pot.collisions}}{\text{Num. of } \text{pot.conficks}} = \frac{19}{35166} = 5.4 \,\text{"}\,\text{10}^{-4}\tag{5}$$

Figure 8 illustrates the obtained bi-dimensional histogram of the projected horizontal and vertical separations at the CPA for the whole data period analysed. As it is shown, the number of potential conflicts are higher when encounters are between aircraft established at the same flight level (0ft vertical separation) and, as well, between aircraft having 2.5 and 5NM of lateral separation. It could also be noticed that the number of encounters having 1000ft separation is higher than for any other vertical separation except the 0ft. This is easily understood when taking into account that within the en-route airspace most of the time aircraft are in level flight (namaly always 1000ft apart between contiguous flight levels). If safety barriers have not been applied the number of collisions to happen would have been 19. The area used to compute the number of potential collisions is shown circled by a red dotted circle.

**Figure 8.** 2D histogram of projected horizontal and vertical separations at the CPA (31 days of radar data)

#### **4.2. Pa estimation for each aircraft encounter**

96 Advances in Air Navigation Services

**4. Results and discussion** 

flown in it within a given time frame.

**4.1. Empirical estimation for Pa** 

dotted circle.

characterised by associated pdfs, f1 and f2, respectively.

Both expressions estimate the probability of potential collision, having a potential separation violation (potential conflict), for each aircraft encounter, provided that uncertainties in the projection of segmented trajectories and in the segmentation process have been

The previous mathematical formulation is supported by the previously mentioned ad-hoc software, which has been developed by the authors for Eurocontrol in the framework of the 3D-CRM programme. This software is intended to measure the collision risk in high density ATC en route airspace, based on an analysis of the stored aircraft tracks that have

With the purpose of evaluating the mathematical expressions to estimate the probability of collisions, the previously mentioned software tool has been applied to a radar data sample from the Maastricht Upper Area Control Centre (MUAC). EUROCONTROL's Maastricht Upper Area Control Centre (MUAC) is a regional air traffic control centre providing seamless air navigation services in the upper airspace (above 24,500ft) for a large (approximately 700,000 square kilometres) multinational airspace in Europe. An advanced and complex ATC automated system named MADAP (Maastricht Automated Data Processing and Display System) is the technical enabler responsible for managing, processing and presenting in real time information relating to the air traffic flows in the whole area. MADAP performs centralized multi-radar tracking using the information provided by a large number of radars and computes a high quality air traffic situation. In MUAC, a unique horizontal separation standard of 5 NM is used throughout the

The general expression of expected Pa is calculated numerically from the relative frequency

<sup>4</sup> . . <sup>19</sup> P(pot.coll/ . ) 5.4 \* 10 . . 35166 *<sup>a</sup>*

Figure 8 illustrates the obtained bi-dimensional histogram of the projected horizontal and vertical separations at the CPA for the whole data period analysed. As it is shown, the number of potential conflicts are higher when encounters are between aircraft established at the same flight level (0ft vertical separation) and, as well, between aircraft having 2.5 and 5NM of lateral separation. It could also be noticed that the number of encounters having 1000ft separation is higher than for any other vertical separation except the 0ft. This is easily understood when taking into account that within the en-route airspace most of the time aircraft are in level flight (namaly always 1000ft apart between contiguous flight levels). If safety barriers have not been applied the number of collisions to happen would have been 19. The area used to compute the number of potential collisions is shown circled by a red

(5)

total area of responsibility. The vertical separation minimum of 1000 ft. is used.

of potential collisions among all potential conflicts using the following equation:

*Num of pot collisions <sup>E</sup> pot conf E P Num of pot conflicts*

Once the empirical general or expected value for Pa has been obtained, Pa was estimated for each particular encounter by the next expression.

$$\begin{split} P\_a \left( y\_p, z\_p \right) &= 4 \lambda\_{xy} \lambda\_z \cdot \frac{\upsilon\_x}{\sqrt{\upsilon\_x^2 + \upsilon\_z^2}} \left[ 1 + \frac{\pi}{4} \cdot \frac{\lambda\_{xy}}{\lambda\_z} \cdot \frac{\upsilon\_z}{\upsilon\_x} \right] \cdot f\_2 \ast \left( -y\_{p'} - z\_p \right) = \\ &= 2 \lambda\_{xy} \cdot f\_{2y} \left( -y\_p \right) \cdot 2 \lambda\_z \cdot \lambda\_{2z} \left( -z\_p \right) \cdot \frac{\upsilon\_x}{\sqrt{\upsilon\_x^2 + \upsilon\_z^2}} \left[ 1 + \frac{\pi}{4} \cdot \frac{\lambda\_{xy}}{\lambda\_z} \cdot \frac{\upsilon\_z}{\upsilon\_x} \right] \end{split} \tag{6}$$

This equation provides and individual probability of collision based on:


It also takes into consideration the segmentation of lateral and vertical errors (*f2y* and *f2z*).

A result for Pa estimation for leveled flight encounter is shown in the upper part of figure 8. In this case when CPAp coordinates (yp,zp) are very close to the reference aircraft (ACi), Pa estimated value reaches 3\*10-2. This value has a magnitude of two orders higher than the empirical expected result (5.4·10-4), but strongly decreases when predicted CPAp lays apart from ACi, resulting in values much lower than the empirical one. In the lower part of this figure, the graphs show when one or both aircraft are climbing/descending but having vz/vr ratio close to zero, it could be seen that regardeless the decrease of the maximum value of Pa (7\*10-3), It is still greater than the empirical expected result for Pa. Furthermore, the probability of collision for CPAp for which yp coordinates close to zero but zp coordinates separated from the ACi remains significant. Pa estimation for encounters having two different aircraft climbing/descending (vz / vx) ratios is shown in figure 9.

Probability of Potential Collision for Aircraft Encounters in High Density Airspaces 99


Vertical coordinate (z)


Vertical coordinate (z)

**Figure 10.** Pa estimation for different CPAp . Aircraft climbing/descending and different vz / vx ratios.

0 0.005 0.01 0.015 0.02

0 0.005 0.01 0.015 0.02

Pa

5 10 15 x 10-3

Pa

When a collision risk analysis is applied to a representative aircraft population, using segmentation of their stored radar tracks, a 2D histogram of projected horizontal and vertical separations at the CPA can be obtained, as it is shown in figure 8. This histogram provides a first approach for expected Pa using equation (4), which is the way we used to obtain E[Pa]= 5.4\*10-4, (this value can taken as reference value for Pa) . If the histogram exhibits a close to uniform distribution, it can be understood that any "generic" potential conflict would became a potential collision with the same probability. It is also possible to propose a different approach to establish the expected value for Pa in a given scenario

 

*xy z xy a a ji ji ji ji y ji z ji*

2 2

(7)



Lateral coordinate (y)

Lateral coordinate (y)

0

0

5000

5000

2 2

*ji y ji z ji ji*

f2zji the probability density function applied to each aircraft encounter (between each

When this equation is applied to previous MUAC data sample, expected value for Pa results

*EP P y z r rfy f z N N*

<sup>1</sup> ( ) <sup>4</sup>

*rfy f z <sup>N</sup>*

rji=vz/vx the between vertical and horizontal relative speeds,

<sup>1</sup> [] , , <sup>1</sup> ( ) <sup>4</sup>

*ji ji z*

Where Pa(yji,zji,rji) is the individual probability of each potential collision where:

**4.3. Expected Pa estimation for a given scenario and traffic sample** 

and for a given aircraft population, discussed below.

*xy z xy*

pair of aircraft, i and j).

*ji z*

 

8.2\*10-4, which is slightly higher than the empirical results.

 

vz / vx=0.1(upper), vz / vx=20 (lower)


Pa=0.0086

Pa=0.0185

vz/vx=20


vz/vx=0.1



Vertical coordinate (z)

Vertical coordinate (z)

**Figure 9.** Pa estimation for different CPAp . Aircraft established at a defined flight level or vz equals to zero (upper) and aircraft with vz close to zero (lower).

Despite the fact that the shape of both functions for Pa are similar to the one obtained in the lower part of figure 10 (aircraft climbing/descending and vz/vx close to zero), the maximum values for Pa are different in both cases (9\*10-3 for vz/vx=0.1, and 2\*10-2 for vz/vx=20), showing that Pa maximum values for CPAp close to reference aircraft (ACi) has a decreasing trend when vz/vr ratio increases. The following table summarises the results obtained from empirical and estimated Pa for the worst case, that is to say Pa for predicted CPAp=(0,0).

The results clearly shows that it is unrealistic to assign the same probability for potential collisions to all potential conflicts, independently of the predicted coordinates for CPA, no matter how these coordinates have been derived.


**Figure 10.** Pa estimation for different CPAp . Aircraft climbing/descending and different vz / vx ratios. vz / vx=0.1(upper), vz / vx=20 (lower)

#### **4.3. Expected Pa estimation for a given scenario and traffic sample**

98 Advances in Air Navigation Services

Pa=0.028

Pa=0.0069

separated from the ACi remains significant. Pa estimation for encounters having two

0 0.01 0.02 0.03

Pa

Pa


Vertical coordinate (z)


Vertical coordinate (z)

0

0

5000

Lateral coordinate (y)

5000

Lateral coordinate (y)

**Figure 9.** Pa estimation for different CPAp . Aircraft established at a defined flight level or vz equals to

Despite the fact that the shape of both functions for Pa are similar to the one obtained in the lower part of figure 10 (aircraft climbing/descending and vz/vx close to zero), the maximum values for Pa are different in both cases (9\*10-3 for vz/vx=0.1, and 2\*10-2 for vz/vx=20), showing that Pa maximum values for CPAp close to reference aircraft (ACi) has a decreasing trend when vz/vr ratio increases. The following table summarises the results obtained from empirical and estimated Pa for the worst case, that is to say Pa for predicted

The results clearly shows that it is unrealistic to assign the same probability for potential collisions to all potential conflicts, independently of the predicted coordinates for CPA, no

zero (upper) and aircraft with vz close to zero (lower).



matter how these coordinates have been derived.

**Table 2.** Worst case Pa estimation

Empirical result for expected Pa, E[Pa] 5.4·10-4 Estimated Pa for CPAp=(0,0) and level flight 3·10-2 Estimated Pa for CPAp=(0,0) and vz /vx ≈0 7·10-3 Estimated Pa for CPAp=(0,0) and vz /vx =0.1 9·10-3 Estimated Pa for CPAp=(0,0) and vz /vx =20 2·10-2

CPAp=(0,0).



Vertical coordinate (z)

Vertical coordinate (z)

different aircraft climbing/descending (vz / vx) ratios is shown in figure 9.

0 0.005 0.01 0.015 0.02 0.025

> When a collision risk analysis is applied to a representative aircraft population, using segmentation of their stored radar tracks, a 2D histogram of projected horizontal and vertical separations at the CPA can be obtained, as it is shown in figure 8. This histogram provides a first approach for expected Pa using equation (4), which is the way we used to obtain E[Pa]= 5.4\*10-4, (this value can taken as reference value for Pa) . If the histogram exhibits a close to uniform distribution, it can be understood that any "generic" potential conflict would became a potential collision with the same probability. It is also possible to propose a different approach to establish the expected value for Pa in a given scenario and for a given aircraft population, discussed below.

$$\begin{split} E[P\_a] &= \frac{1}{N} \sum\_{ji} P\_a \left( y\_{ji} \cdot z\_{ji} \cdot r\_{ji} \right) = \frac{\lambda\_{xy} \lambda\_z}{N} \sum\_{ji} \left[ 1 + \frac{\pi}{4} \cdot \frac{\lambda\_{xy}}{\lambda\_z} \cdot r\_{ji} \right] f\_{2y}(y\_{ji}) \cdot f\_{2z} \left( z\_{ji} \right) = \\ &= \frac{\lambda\_{xy} \lambda\_z}{N} \sum\_{ji} \left[ 1 + \frac{\pi}{4} \cdot \frac{\lambda\_{xy}}{\lambda\_z} \cdot r\_{ji} \right] f\_{2y}(y\_{ji}) \cdot f\_{2zj} \left( z\_{ji} \right) \end{split} \tag{7}$$

Where Pa(yji,zji,rji) is the individual probability of each potential collision where:


When this equation is applied to previous MUAC data sample, expected value for Pa results 8.2\*10-4, which is slightly higher than the empirical results.

#### **5. Conclusions**

This chapter analyse in detail the inherent collision risk involved for each aircraft proximity event by assessing the conditional probability Pa of a potential collision between aircraft that are exposed to risk, that is to say, they are potentially going to violate the separation standards defined for a specific airspace if no corrective action is taken. The proposed approach allows the determination of the severity of each aircraft encounter as the probability of potential collision for each individual aircraft encounter in high density ATC en route airspace, based on an analysis of the stored aircraft tracks that have flown within a given time frame. The authors propose a mathematical formulation to characterise the severity of each aircraft proximity event using the convolution of the bi-dimensional probability density function of the predicted Closest Point of Approach between the aircraft involved and the distribution of lateral and vertical error in the projected position of the aircraft.The presented work aims to provide an individual probability of collision based on the geometry and kinematics of the encounter and the minimum lateral separation and the minimum vertical separation at the predicted Closest Point of Approach or CPA. The formula takes into consideration uncertainties introduced by the radar data error and the segmentation error. The results of this chapter shows that there is not the same severity for all the proximity events on which aircraft pass closer than the prescribed horizontal and vertical separation minima, and also that the expected severity for given a scenario and traffic sample can also vary depending on the kinematic characteristics of aircraft involved within this scenario. It is also considered that collision risk for high density of air traffic can be analysed from the estimation of three different factors:

Probability of Potential Collision for Aircraft Encounters in High Density Airspaces 101

collision given as accident frequency (per flight) is 5.4\*10-09, specifying that, among them,

[1] Machol, R. E. (1995): "Thirty Years of Modelling Midair Collisions", Interfaces 25: 5

[2] B. L. Marks (1963) Air traffic control separation standards and collision risk. Royal.

[3] Reich, P.G. (1964), A theory of safe separation standards for Air Traffic Control,

[4] Reich, P. G. (1966). Analysis of Long-range Air Traffic Systems: Separation Standards.

[5] Peter Brooker. Longitudinal Collision Risk for ATC Track Systems: A Hazardous Event

[6] ICAO (1988), Review of the General Concept of Separation Panel, 6th meeting, Doc 9536,

[7] H. D. Sherali C. Smith . Dr. A.A. Trani S. Sale.Q. Chuanwen. Analysis of Aircraft Separations and Collision Risk Modeling. NEXTOR - National Center of Excellence for

[8] Burt L , October 2000, 3-D Mathematical Model for ECAC Upper Airspace, Final Report [9] Peter Brooker (Cranfield University).Radar Inaccuracies and Mid-Air Collision Risk: Part

[10] Carpenter, Brenda D., MIT, Cambridge, MA; Kuchar, James K., MIT, Cambridge, MA. Probability-based collision alerting logic for closely-spaced parallel approach. AIAA-1997-222 Aerospace Sciences Meeting and Exhibit, 35th, Reno, NV, Jan. 6-9. 1997. [11] Kuchar, James K., MIT, Cambridge, MA; Winder, Lee F., MIT, Cambridge. Generalized philosophy of alerting with applications to parallel approach collision prevention. MA AIAA-2001-4052 AIAA Guidance, Navigation, and Control Conference and Exhibit,

[12] Lee F. Winder, ; James K. Kuchar. Evaluation of Collision Avoidance Maneuvers for Parallel Approach . Journal of Guidance, Control, and Dynamics 0731-5090 vol.22 no.6

[13] Powell, J. David, Stanford Univ., CA; Houck, Sharon, Stanford Univ., CA Assessment of the possibility of a midair collision during an ultra closely spaced parallel approach. . AIAA-2001-4205 AIAA Guidance, Navigation, and Control Conference and Exhibit,

2 En Route Radar Separation Minima The Journal of Navigation (2004).

Journal of the Institute of Navigation, (19), 88, 169 and 331 (in three parts).

the frequency of fatal accident, directly caused by ATC (per flight), is 3.5\*10-09.

Aircraft Establishment Technical Note No. 91, February, 1963

Model. Journal of Navigation, 2006, Vol. 59 No. 1. pag. 55-70.

Volume 1,ICAO, Montreal, December 1988.

Aviation Operations Research 1998.

Montreal, Canada, Aug. 6-9, 2001.

(801-807)doi: 10.2514/2.4481, 1999

Montreal, Canada, Aug. 6-9, 2001.

Technical Report 64041, Royal Aircraft Establishment, UK

**Author details** 

**6. References** 

R. Arnaldo, F.J. Sáez, E. Garcia and Y. Portillo *Universidad Politecnica de Madrid, Madrid, Spain* 

September -October 1995 (151-172)


As the two first factors can be derived from the stored tracks of the traffic sample, using the software tool developed by the authors [38], further work is now devoted to develop the probability of failure of the ATM safety barriers. Once the probability of failure were stated and validated, it will be possible to estimate the collision risk for individual encounters, scenarios and air traffic samples. Results obtained for MUAC, with data sample used in previous discussion, exhibits a rounded value for frequency of exposition to risk of FeR=0.3. Probability of potential collision among encounters exposed to risk, Pa or its expected value E(Pa) for the same sample, oscillates between 8.2\*10-4(expected) and 2\*10-2(worst case). Previous results demand a probability of "safety barrier failure" lower than 0.4\*10-5 and 1.7\*10-7 respectively, to reach the ATM en route target level of safety of TLS=10-9. This last value is normally the one used as TLS. For instance, in reference (Eurocontrol, 2006) mid-air collision given as accident frequency (per flight) is 5.4\*10-09, specifying that, among them, the frequency of fatal accident, directly caused by ATC (per flight), is 3.5\*10-09.

#### **Author details**

100 Advances in Air Navigation Services

This chapter analyse in detail the inherent collision risk involved for each aircraft proximity event by assessing the conditional probability Pa of a potential collision between aircraft that are exposed to risk, that is to say, they are potentially going to violate the separation standards defined for a specific airspace if no corrective action is taken. The proposed approach allows the determination of the severity of each aircraft encounter as the probability of potential collision for each individual aircraft encounter in high density ATC en route airspace, based on an analysis of the stored aircraft tracks that have flown within a given time frame. The authors propose a mathematical formulation to characterise the severity of each aircraft proximity event using the convolution of the bi-dimensional probability density function of the predicted Closest Point of Approach between the aircraft involved and the distribution of lateral and vertical error in the projected position of the aircraft.The presented work aims to provide an individual probability of collision based on the geometry and kinematics of the encounter and the minimum lateral separation and the minimum vertical separation at the predicted Closest Point of Approach or CPA. The formula takes into consideration uncertainties introduced by the radar data error and the segmentation error. The results of this chapter shows that there is not the same severity for all the proximity events on which aircraft pass closer than the prescribed horizontal and vertical separation minima, and also that the expected severity for given a scenario and traffic sample can also vary depending on the kinematic characteristics of aircraft involved within this scenario. It is also considered that collision risk for high density of air traffic can

 Relative frequency of exposition to risk (FeR). The value of this factor can be easily obtained from any radar data sample and strongly depends on the minimum applied horizontal and vertical separations standard and increases with air traffic density, Expected severity E(Pa). This value can be directly derived from individual probabilities of potential collision (Pa). Furthermore, having individual severities, it

As the two first factors can be derived from the stored tracks of the traffic sample, using the software tool developed by the authors [38], further work is now devoted to develop the probability of failure of the ATM safety barriers. Once the probability of failure were stated and validated, it will be possible to estimate the collision risk for individual encounters, scenarios and air traffic samples. Results obtained for MUAC, with data sample used in previous discussion, exhibits a rounded value for frequency of exposition to risk of FeR=0.3. Probability of potential collision among encounters exposed to risk, Pa or its expected value E(Pa) for the same sample, oscillates between 8.2\*10-4(expected) and 2\*10-2(worst case). Previous results demand a probability of "safety barrier failure" lower than 0.4\*10-5 and 1.7\*10-7 respectively, to reach the ATM en route target level of safety of TLS=10-9. This last value is normally the one used as TLS. For instance, in reference (Eurocontrol, 2006) mid-air

also permits additional assessment on safety (hot spots identification, etc.).

Expected probability of failure of safety barriers (ATC, TCAS, etc.)

be analysed from the estimation of three different factors:

**5. Conclusions** 

R. Arnaldo, F.J. Sáez, E. Garcia and Y. Portillo *Universidad Politecnica de Madrid, Madrid, Spain* 

#### **6. References**


[14] Sharon W. Houck, J. David Powell, Probability of Midair Collision During Ultra Closely Spaced ParallelApproaches. Journal of Guidance, Control, and Dynamics, 0731- 5090 vol.26 no.5 (702-710) do: 10.2514/2.5124. 2003.

Probability of Potential Collision for Aircraft Encounters in High Density Airspaces 103

[28] Lee Yang\*, Ji Hyun Yang†, James Kuchar‡, Eric Feron§ Massachusetts Institute of Technology, Cambridge, MA. A Real-Time Monte Carlo Implementation for Computing Probability of Conflict. AIAA Guidance, Navigation, and Control

[29] Burt L , October 2000, 3-D Mathematical Model for ECAC Upper Airspace, Final Report. [30] Campos L. M. B. C. ; Marques J. M. G. On the probability of collision between climbing and descending aircraft , ; Journal of aircraft ISSN 0021-8669 CODEN JAIRAM / vol.

[31] Campos L. M. B. C.. Probability of collision of aircraft with dissimilar position errors , ; Journal of aircraft ISSN 0021-8669 CODEN JAIRAM , vol. 38, no4, pp. 593-599. 2001. [32] Leonard A. Wojcik The MITRE Corporation, McLean, VA 22102 U.S. Probabilistic Aircraft Conflict Analysis for a Vision of the Future Air Traffic Management System. AIAA 5th Aviation, Technology, Integration, and Operations Conference (ATIO) 26 -

[33] Leonard A.Wojcik∗ The MITRE Corporation, McLean. Probabilistic Aircraft Conflict Analysis for a Future Air Traffic Management System. VA 22102 DOI: 10.2514/1.22850 Journal of Aerospace Computing, Information, and Communication Vol. 6, June 2009 [34] Rachelle L. Ennis1 and Yiyuan J. Zhao2 University of Minnesota, Mpls, MN. Defining Appropriate Inter-Aircraft Separation Requirements. AIAA 4th Aviation Technology, Integration and Operations (ATIO) Forum 20 - 22, Chicago, Illinois. September 2004. [35] Jerry Dingy Claire Tomlinz. A Dynamic Programming Approach for Aircraft Conflict Detection. AIAA Guidance, Navigation, and Control Conference, 10 - 13, Chicago,

[36] D. E. Stepner. Modelling of Aircraft Position Errors with Independent Surveillance.

[27] Eduardo José García González, INECO, Madrid, Spain, Francisco Javier Sáez Nieto, Polytechnic University of Madrid, Madrid, Spain, Maria Isabel Izquierdo, EUROCONTROL, Brussels, Bélgica . Identification and analysis of proximate events in high density en route airspaces Paper N° 63]. 7th USA – EUROPE ATM R&D Seminar

[38] Saez F, Arnaldo R, Garcia E, McAuley G, Izquierdo M. Development of a three dimensional collision risk model tool to asses safety in high density en-route airspaces.

[39] Jaroslav Krystul.Modelling of stochastic hybrid systems with applications to accident

[40] Rachelle L. Ennis† and Yiyuan J. Zhao‡ University of Minnesota, Minneapolis, Minnesota. Characterization of Aircraft Protected Zones. AIAA's 3rd Annual Aviation Technology, Integration, and Operations (ATIO) Tech 17 – 19, Denver, Colorado.

[41] J. F. Bellantoni. The Calculation of Aircraft Collision Probabilities DOT-TSC-FAA-71-27,

[42] Reynolds T.G., Hansman R.J., Analysis of Aircraft Separation Minima Using a

Conference and Exhibit 16 - 19, Providence, Rhode Island. August 2004.

44, no2, pp. 550-557. 2007.

Illinois . August 2009.

July 02-05, Barcelona. 2007

November 2003,

October'1971.

DOI:10.1243/09544100JAERO704

risk assessment. 6 September 2006

Surveillance State Vector Approach, MIT, 2001

28, Arlington, Virginia. September 2005.

VOL. 11, NO. 9, AIAA Journal 1273. September 1973.


[28] Lee Yang\*, Ji Hyun Yang†, James Kuchar‡, Eric Feron§ Massachusetts Institute of Technology, Cambridge, MA. A Real-Time Monte Carlo Implementation for Computing Probability of Conflict. AIAA Guidance, Navigation, and Control Conference and Exhibit 16 - 19, Providence, Rhode Island. August 2004.

102 Advances in Air Navigation Services

2007.

2000.

179–189. December 2000.

New Orleans, LA, August 11-13, 1997.

Ireland AIAA 2007-7729. September 2007.

Pt. 3 (A97-37001 10-63). 1997.

[14] Sharon W. Houck, J. David Powell, Probability of Midair Collision During Ultra Closely Spaced ParallelApproaches. Journal of Guidance, Control, and Dynamics, 0731-

[15] Shepherd, Roger, Rannoch Corp., Alexandria, VA; Cassell, Rick. A reduced aircraft separation risk assessment model, VA AIAA-1997-3735 AIAA Guidance, Navigation, and Control Conference, New Orleans, LA, Aug. 11-13, Collection of Technical Papers.

[16] Blom, H.A.P., Bakker, G.J., Blanker, P.J.G., Daams, J., Everdij, M.H.C., and Klompstra, M.B. ''Accident Risk Assessment for Advanced ATM,'' In: Air Transportation Systems Engineering, G.L. Donohue and A.G. Zellweger (Eds.), AIAA, 2001, pp. 463-480. 2001. [17] H. Blom, GJ Bakker, B. Klein Obbink and MB Klompstra. Free Flight safety risk modeling and simulation. Proceedings of 2nd International Conference on Research in

[18] H. Blom,; B. Klein Obbink, B. Bakker, National Aerospace Laboratory NLR. Safety Risk Simulation of an Airborne Self Separation Concept of Operation. AIAA-2007-7729 7th AIAA ATIO Conf, 2nd CEIAT Int'l Conf on Innov and Integr in Aero Sciences,17th LTA Systems Tech Conf; followed by 2nd TEOS Forum, Belfast, Northern Ireland, Sep. 18-20,

[19] Peter Brooker. Air Traffic Management accident risk. Part 1: The limits of realistic

[20] Paielli, R.A. and H. Erzberger, ''Conflict probability estimation for free flight'', AIAA J.

[21] Paielli, R.A. and H. Erzberger, ''Conflict Probability Estimation Generalised to Non-

[22] Prandini, M., J. Hu, J. Lygeros and S. Sastry, A probabilistic approach to aircraft conflict detection, IEEE Tr. on Intelligent Transportation Systems, Vol. 1, No. 4, pp. 199-220.

[23] M. Prandini, J. Lygeros, A. Nilim, and S. Sastry, "A Probabilistic Framework for Aircraft Conflict Detection", AIAA-99-4144, in Proc. AIAA Guidance, Navigation, and Control

[24] ICAO, Annex 11 – Air Traffic Services, 12th edition, incorporating amendments 1-38,

[25] Kuchar, J. and Yang, L., "A Review of Conflict Detection and Resolution Modelling Methods," IEEE Transactions on Intelligent Transportation Systems, Vol. 1, No. 4, pp.

[26] Kuchar and L. Yang, "Survey of Conflict Detection and Resolution Modelling Methods", AIAA-97-3732, in Proc. AIAA Guidance, Navigation, and Control Conf.,

[27] Henk A.P. Blom , Bart Klein Obbink, G.J. (Bert) Bakker. Safety risk simulation of an airborne self separation concept of operation, 7th AIAA Aviation Technology, Integration and Operations Conference (ATIO)<BR>2nd C 18 - 20, Belfast, Northern

Air Transportation ICRAT 2006, at Beograd, Serbia, June 24-28, 2006.

of Guidance, Control and Dynamics, Vol. 20, pp.588-596. 1997.

Conf., Portland, OR, August 9-11, pp. 1047-1057.1999.

July 1998, Green pages, attachment B, paragraph 3.2.1.

Level Flight'', Air Traffic Control Quarterly, Vol. 7, pp.195-222, 1999.

5090 vol.26 no.5 (702-710) do: 10.2514/2.5124. 2003.

modeling. Safety Science 44, 419–450. 2006.

	- [43] Ennis, R. L.; Zhao,Y.J., Defining Appropriate Inter-Aircraft Separation Requirements, AIAA's 4th Annual Aviation Technology Integrations and Operations (ATIO) Forum # AIAA2004-6203, September 20-22, 2004

**Chapter 7** 

© 2012 Magister and Županič, licensee InTech. This is an open access chapter distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

© 2012 Magister and Županič, licensee InTech. This is a paper distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use,

distribution, and reproduction in any medium, provided the original work is properly cited.

**The Autonomous Flight** 

Tone Magister and Franc Željko Županič

http://dx.doi.org/10.5772/46484

**1. Introduction** 

Additional information is available at the end of the chapter

The Autonomous Flight Airspace (AFA) [9] is the evolutional offspring of the Free Flight Airspace (FFA), and enabler of integrated flight operations of aircraft with autonomous

In the FFA the responsibilities for the airborne spacing and separation assurance are delegated to flight crews on board the aircraft, and the ground–based Air Traffic Management (ATM) is to resume separation authority in emergencies only [2]. Therefore,

Since airborne separation assurance is a fundamental principle of the FFA and the Airborne Separation Assurance System (ASAS) its main enabler, the AFA introduces the autonomous airborne separation assurance with Autonomous–ASAS (AASAS). The AFA is marked by the machine–based decision–making, and the AFA is restricted to the ASAS and AASAS equipped aircraft but both types with autonomous flight capabilities. In the future the only humans–in–the–loop conducting flight operations through AFA are going to be ground– based UAS operators, air traffic flow managers of the next generation ATM, and systems supervisors (*pilots of present–day terminology*) onboard remnant "old–school" manned aircraft. Based on 4D trajectory planning the AASAS concept covers machine–based (a) traffic situational awareness, and (b) airborne spacing and self–separation assurance

The AFA concept is not only important for implementation of non–segregated UAS flight operations [8], but also for the future air transport system responding to the society's emerging needs (which are not limited to enabling permeability of increasing volume of air traffic, but include other issues; i.e., for example airborne security when it is necessary for the pilot to transfer his/her responsibilities to an automatic system due to a hijack situation for flight trajectory protection and safe automatic return to the ground as envisioned in [1]).

flight capabilities (for instance, Unmanned Aircraft Systems (UAS)).

humans are the decision–makers, as well as operatives in the FFA.

through (c) autonomous in–flight conflict detection and resolution.

**Chapter 7** 

### **The Autonomous Flight**

Tone Magister and Franc Željko Županič

Additional information is available at the end of the chapter

http://dx.doi.org/10.5772/46484

#### **1. Introduction**

104 Advances in Air Navigation Services

AIAA2004-6203, September 20-22, 2004

[43] Ennis, R. L.; Zhao,Y.J., Defining Appropriate Inter-Aircraft Separation Requirements, AIAA's 4th Annual Aviation Technology Integrations and Operations (ATIO) Forum #

> The Autonomous Flight Airspace (AFA) [9] is the evolutional offspring of the Free Flight Airspace (FFA), and enabler of integrated flight operations of aircraft with autonomous flight capabilities (for instance, Unmanned Aircraft Systems (UAS)).

> In the FFA the responsibilities for the airborne spacing and separation assurance are delegated to flight crews on board the aircraft, and the ground–based Air Traffic Management (ATM) is to resume separation authority in emergencies only [2]. Therefore, humans are the decision–makers, as well as operatives in the FFA.

> Since airborne separation assurance is a fundamental principle of the FFA and the Airborne Separation Assurance System (ASAS) its main enabler, the AFA introduces the autonomous airborne separation assurance with Autonomous–ASAS (AASAS). The AFA is marked by the machine–based decision–making, and the AFA is restricted to the ASAS and AASAS equipped aircraft but both types with autonomous flight capabilities. In the future the only humans–in–the–loop conducting flight operations through AFA are going to be ground– based UAS operators, air traffic flow managers of the next generation ATM, and systems supervisors (*pilots of present–day terminology*) onboard remnant "old–school" manned aircraft. Based on 4D trajectory planning the AASAS concept covers machine–based (a) traffic situational awareness, and (b) airborne spacing and self–separation assurance through (c) autonomous in–flight conflict detection and resolution.

> The AFA concept is not only important for implementation of non–segregated UAS flight operations [8], but also for the future air transport system responding to the society's emerging needs (which are not limited to enabling permeability of increasing volume of air traffic, but include other issues; i.e., for example airborne security when it is necessary for the pilot to transfer his/her responsibilities to an automatic system due to a hijack situation for flight trajectory protection and safe automatic return to the ground as envisioned in [1]).

© 2012 Magister and Županič, licensee InTech. This is an open access chapter distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. © 2012 Magister and Županič, licensee InTech. This is a paper distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Analogous to the traffic complexity at both highway ends, air traffic is inherently complex especially in both zones adjacent to the boundary between the AFA (or FFA) and non– autonomous (or un–free) flight airspace (non–AFA). The number (quantum) of conflicts between aircraft is proportional to the complexity of the in–flight traffic situation [7]. For AFA implementation (or any airspace organization with changing delegation of responsibilities for the airborne spacing and separation assurance), the transition flights between the AFA and non–AFA therefore represent a critical safety issue.

The Autonomous Flight 107

**Scenario / Degrees of Freedom Fractal Dimension** Airway Network Heading Airspeed Top of Descent

D D D D 1.0 D n/a **F** n/a 2.0 *e* **F** D n/a 2.0 *e* **F** n/a D 2.0 n/a D **F F** 2.1 *e* **F** n/a **F** 2.4 *e* **F F** n/a 2.6

*form 10,000ft to FL410; 120nm box around airport* 1.22 – 1.39

**Table 1.** The fractal dimension of flight is proportional to the freedom of movement (data compiled

encounter for transitioning aircraft at the boundary between the AFA and CA.

The greatest (50%) decrease of fractal dimension of flight and resulting drastic 135% increase of conflict encounters (1) occurs, when an aircraft transits the border between the AFA (or

Since descending and/or climbing aircraft through the sector of level cruising flights markedly increase the air traffic controller's workload [3], and consequently decrease sector throughput, earlier studies such as [2] anticipated mostly level transition flights from the FFA (and applicable to the AFA as well). Level transition flights to and from the AFA (or FFA) require that the AFA (or FFA) and the controlled airspace (CA) are positioned side by side. Such airspace configuration again increases the air traffic controller's workload by introducing the mix of differently equipped aircraft subjected to essentially different procedures, namely the mix of controlled flights and autonomous (or free) flights en–route to or from the AFA (or FFA). However, to simultaneously gain increased airspace capacity and flight economics together with decreased emissions from optimized flights, the AFA (or FFA) should and will extend above CA (Fig. 1). Obviously there is more than one reason to consider transition to and from the AFA (or FFA) while aircraft are climbing or descending. The transition flight from the AFA into the CA results in significantly decreased freedom of flight; aircraft path might be dictated directly by ATM or at least to a certain extent confined by the route network. Due to decrease in freedom of flight the fractal dimension of aircraft path will decrease (Table 1) and consequently the in–flight conflict encounter for transitioning aircraft will inevitability increase (1). The greater the differences between fractal dimensions of flight in the AFA and CA are, the greater is the increase in conflict

*upper airspace above FL240* 1.13 – 1.32

*from 10,000ft to FL240* 1.2

Controlled Airspace / Transition Areas

Upper Control Area

TMA/CTA – Terminal and Control Area

D Determined parameter **F** Free parameter *e* Exclusive parameter n/a Undefined parameter

from [11]).

The prediction accuracy of the future trajectory of each and every aircraft aloft drive the stability of the predicted four-dimensional traffic situation in the airspace confined with a look-ahead time and consequently the ASAS and/or AASAS on-board each aircraft ability to detect every potential conflicton-time and correctly. The statement holds for either freeflight [2], sector-less airspace [4], or automated airspace [5] envisioned to cope with the increasing demand in the crowded skies above.

With the existing technology and methodology the look-ahead time for the construction of accurate future aircraft flight trajectory is reduced to only about 5 to 7 minutes in advance. Prolonged look-ahead timeusing the current airborne separation assurance technology, designed not to include the future intent,results in predicted traffic situation instability [6] and consequently in conflict detection unreliability or even inability.

The study is also focused on the design of an advanced four-dimensionalmodel of aircraft relative flightproviding the capabilities of the AASAS to detect conflicts beyond the borders of the AFA and enabling Autonomous Flight concept implementation.

#### **2. Autonomous flight airspace**

#### **2.1. Problem of transition flight to/from autonomous flight airspace**

The complexity of air traffic and quantum of in–flight conflicts between aircraft in the AFA (or FFA) and its non–AFA neighborhood can be investigated using the theory of airspace fractal dimensions proposed by Mondoloni and Liang in [11]. This theory was introduced as methodology capable of simultaneously distinguishing between complexity of air traffic situation as a consequence of management of air traffic flow, and complexity of an air traffic situation as a consequence of geometry and organization of airspace. Fractal dimension is a number *DD D* { ,1 3} assigned to the particular flight corresponding to freedom of aircraft motion. As shown in Table 1, with increasing freedom of movement the fractal dimension of flight increases, and vice versa.

The frequency of in–flight conflicts decreases exponentially if fractal dimension of aircraft flight increases. Alternatively, the number of in–flight conflict encounters *C* threatening aircraft ( *dC CRdt* ) increases with decreasing freedom of its flight *D*, and their relation can be approximated from data of Table 1 as:

$$
\int \text{CR} \, dt \approx 11.472 - 2.452 \,\text{nD} \tag{1}
$$


D Determined parameter

**F** Free parameter

106 Advances in Air Navigation Services

Analogous to the traffic complexity at both highway ends, air traffic is inherently complex especially in both zones adjacent to the boundary between the AFA (or FFA) and non– autonomous (or un–free) flight airspace (non–AFA). The number (quantum) of conflicts between aircraft is proportional to the complexity of the in–flight traffic situation [7]. For AFA implementation (or any airspace organization with changing delegation of responsibilities for the airborne spacing and separation assurance), the transition flights

The prediction accuracy of the future trajectory of each and every aircraft aloft drive the stability of the predicted four-dimensional traffic situation in the airspace confined with a look-ahead time and consequently the ASAS and/or AASAS on-board each aircraft ability to detect every potential conflicton-time and correctly. The statement holds for either freeflight [2], sector-less airspace [4], or automated airspace [5] envisioned to cope with the

With the existing technology and methodology the look-ahead time for the construction of accurate future aircraft flight trajectory is reduced to only about 5 to 7 minutes in advance. Prolonged look-ahead timeusing the current airborne separation assurance technology, designed not to include the future intent,results in predicted traffic situation instability [6]

The study is also focused on the design of an advanced four-dimensionalmodel of aircraft relative flightproviding the capabilities of the AASAS to detect conflicts beyond the borders

The complexity of air traffic and quantum of in–flight conflicts between aircraft in the AFA (or FFA) and its non–AFA neighborhood can be investigated using the theory of airspace fractal dimensions proposed by Mondoloni and Liang in [11]. This theory was introduced as methodology capable of simultaneously distinguishing between complexity of air traffic situation as a consequence of management of air traffic flow, and complexity of an air traffic situation as a consequence of geometry and organization of airspace. Fractal dimension is a number *DD D* { ,1 3} assigned to the particular flight corresponding to freedom of aircraft motion. As shown in Table 1, with increasing freedom of movement the fractal

The frequency of in–flight conflicts decreases exponentially if fractal dimension of aircraft flight increases. Alternatively, the number of in–flight conflict encounters *C* threatening aircraft ( *dC CRdt* ) increases with decreasing freedom of its flight *D*, and their relation

11.472 2.452 *CRdt D* (1)

between the AFA and non–AFA therefore represent a critical safety issue.

and consequently in conflict detection unreliability or even inability.

of the AFA and enabling Autonomous Flight concept implementation.

**2.1. Problem of transition flight to/from autonomous flight airspace** 

increasing demand in the crowded skies above.

**2. Autonomous flight airspace** 

dimension of flight increases, and vice versa.

can be approximated from data of Table 1 as:

*e* Exclusive parameter

n/a Undefined parameter

**Table 1.** The fractal dimension of flight is proportional to the freedom of movement (data compiled from [11]).

Since descending and/or climbing aircraft through the sector of level cruising flights markedly increase the air traffic controller's workload [3], and consequently decrease sector throughput, earlier studies such as [2] anticipated mostly level transition flights from the FFA (and applicable to the AFA as well). Level transition flights to and from the AFA (or FFA) require that the AFA (or FFA) and the controlled airspace (CA) are positioned side by side. Such airspace configuration again increases the air traffic controller's workload by introducing the mix of differently equipped aircraft subjected to essentially different procedures, namely the mix of controlled flights and autonomous (or free) flights en–route to or from the AFA (or FFA). However, to simultaneously gain increased airspace capacity and flight economics together with decreased emissions from optimized flights, the AFA (or FFA) should and will extend above CA (Fig. 1). Obviously there is more than one reason to consider transition to and from the AFA (or FFA) while aircraft are climbing or descending.

The transition flight from the AFA into the CA results in significantly decreased freedom of flight; aircraft path might be dictated directly by ATM or at least to a certain extent confined by the route network. Due to decrease in freedom of flight the fractal dimension of aircraft path will decrease (Table 1) and consequently the in–flight conflict encounter for transitioning aircraft will inevitability increase (1). The greater the differences between fractal dimensions of flight in the AFA and CA are, the greater is the increase in conflict encounter for transitioning aircraft at the boundary between the AFA and CA.

The greatest (50%) decrease of fractal dimension of flight and resulting drastic 135% increase of conflict encounters (1) occurs, when an aircraft transits the border between the AFA (or FFA) and the CA through the arbitrary place (TC) at level flight and enters directly into the network of airways of CA.

The Autonomous Flight 109

The top of descent (TOD) determination in the AFA has a two–fold impact on the freedom of flight decrease while an aircraft is still flying in the AFA. Determination of the TOD in the AFA itself (Table 1), as the trajectory determination factor, reduces the fractal dimension of flight even before an aircraft reaches the edge of the AFA (Z; Fig. 1). Furthermore the TOD can only be determined by the intersection of an aircraft cruising level and the trajectory of its descent (with a constant rate of descent to the assigned destination) through the rest of the transitioning aircraft free transition corridor (TC; Fig. 1) closest to the optimal route through the border between the AFA and CA. The transition corridor (TC) is a one–way passage in the transition layer through which an aircraft flies from the AFA into the CA (and vice versa); at the same time it is the starting point of a particular airway in the CA. The TC defines the four–dimensional position of an aircraft transitioning from the AFA and direction of flight in the CA adjacent to the transition layer; consequently the TC is the restrictive factor which decreases freedom of aircraft movement and the fractal dimension of its flight (Table 1). Recurrently determined TOD and TC define the route of an aircraft leaving the AFA, and by gradually decreasing its freedom of flight dispersing threatening

Descending from the AFA via the TC an aircraft enters the CA. In the part of the CA that borders upon the AFA it is of a critical importance that the autonomous flights can be safely integrated with the rest of not–autonomous traffic, and that the airspace organization including traffic flow management enables a fractal dimension comparable to the fractal dimension of the AFA. Both major criteria of the CA bordering the AFA are met with the Automated Airspace (AA) type of CA proposed in [4], if a reception zone is introduced into

The AA is based upon the ground–based automation system that provides in–flight separation assurance via data–link communication for properly equipped aircraft. The ground–based automation system issue clearances for aircraft intended trajectories and/or it can up–load safe trajectories directly into the flight management system module of the

The roles of controllers in the AA are strategic control of traffic flow, handling of unusual traffic situations, and monitoring and control of unequipped aircraft [4]. This facilitates the

The reception zone is an integral part of the AA adjacent to the border with the AFA (flying in the opposite direction an aircraft leaves the AA through the dispatch zone). The concourse pattern of airways starting in the AA reception zone with each TC at the border with the AFA is adjusted to match the directions of cardinal routes of the AFA; their geometry and organization serves as a collector of air traffic flows from various TCs onto the main central airways of the AA. The airways structure and management of traffic flow- i.e., the aircraft trajectory control and restrictions--are such that the fractal dimension of the AA reception zone corresponds to the AFA fractal dimension. The fractal dimension of a flight upon crossing the border between the AFA and AA reception zone remains unchanged allowing that in the most critical part of the transition flight in the vicinity of the

AASAS of the autonomous aircraft and ASAS of the non–autonomous aircraft.

conflict encounters with neighboring aircraft along its way.

autonomous and non–autonomous aircraft mix in the AA.

the AA at its border with the AFA.

The solution to the problem of transition flight conflict encounter increase at the border between the AFA (or FFA) and the CA consists of:


The proposed solution to the transitioning flight problem is presented in Fig. 1. Drastic increase in conflict encounter imminent to an aircraft at the AFA border in level transition flight is dispersed. In consequence, severity of conflict encounters along its transitioning trajectory is reduced.

**Figure 1.** Conflict increase dispersion along descending transition from the AFA.

The top of descent (TOD) determination in the AFA has a two–fold impact on the freedom of flight decrease while an aircraft is still flying in the AFA. Determination of the TOD in the AFA itself (Table 1), as the trajectory determination factor, reduces the fractal dimension of flight even before an aircraft reaches the edge of the AFA (Z; Fig. 1). Furthermore the TOD can only be determined by the intersection of an aircraft cruising level and the trajectory of its descent (with a constant rate of descent to the assigned destination) through the rest of the transitioning aircraft free transition corridor (TC; Fig. 1) closest to the optimal route through the border between the AFA and CA. The transition corridor (TC) is a one–way passage in the transition layer through which an aircraft flies from the AFA into the CA (and vice versa); at the same time it is the starting point of a particular airway in the CA. The TC defines the four–dimensional position of an aircraft transitioning from the AFA and direction of flight in the CA adjacent to the transition layer; consequently the TC is the restrictive factor which decreases freedom of aircraft movement and the fractal dimension of its flight (Table 1). Recurrently determined TOD and TC define the route of an aircraft leaving the AFA, and by gradually decreasing its freedom of flight dispersing threatening conflict encounters with neighboring aircraft along its way.

108 Advances in Air Navigation Services

network of airways of CA.

between the AFA (or FFA) and the CA consists of:

transitioning to the AFA (or FFA));

the rest of the traffic.

trajectory is reduced.

introduction of transition in descent and climb;

FFA) and the CA through the arbitrary place (TC) at level flight and enters directly into the

The solution to the problem of transition flight conflict encounter increase at the border

1. the transition to and from the AFA (or FFA) into the CA in non–level flight; i.e.,

2. gradually decreased degree of freedom of flight in the direction from the AFA (or FFA) into the CA; i.e., progressively dictated parameters of flight along the transitioning route before an aircraft leaves the AFA (or FFA), upon leaving the AFA, and afterwards while flying in the CA (and vice versa for the flight in the opposite direction

3. CA organization and air traffic flow regulation adequate to the procedures of autonomously (or free) flying aircraft entering from the AFA (or FFA) and mixing with

The proposed solution to the transitioning flight problem is presented in Fig. 1. Drastic increase in conflict encounter imminent to an aircraft at the AFA border in level transition flight is dispersed. In consequence, severity of conflict encounters along its transitioning

**Figure 1.** Conflict increase dispersion along descending transition from the AFA.

Descending from the AFA via the TC an aircraft enters the CA. In the part of the CA that borders upon the AFA it is of a critical importance that the autonomous flights can be safely integrated with the rest of not–autonomous traffic, and that the airspace organization including traffic flow management enables a fractal dimension comparable to the fractal dimension of the AFA. Both major criteria of the CA bordering the AFA are met with the Automated Airspace (AA) type of CA proposed in [4], if a reception zone is introduced into the AA at its border with the AFA.

The AA is based upon the ground–based automation system that provides in–flight separation assurance via data–link communication for properly equipped aircraft. The ground–based automation system issue clearances for aircraft intended trajectories and/or it can up–load safe trajectories directly into the flight management system module of the AASAS of the autonomous aircraft and ASAS of the non–autonomous aircraft.

The roles of controllers in the AA are strategic control of traffic flow, handling of unusual traffic situations, and monitoring and control of unequipped aircraft [4]. This facilitates the autonomous and non–autonomous aircraft mix in the AA.

The reception zone is an integral part of the AA adjacent to the border with the AFA (flying in the opposite direction an aircraft leaves the AA through the dispatch zone). The concourse pattern of airways starting in the AA reception zone with each TC at the border with the AFA is adjusted to match the directions of cardinal routes of the AFA; their geometry and organization serves as a collector of air traffic flows from various TCs onto the main central airways of the AA. The airways structure and management of traffic flow- i.e., the aircraft trajectory control and restrictions--are such that the fractal dimension of the AA reception zone corresponds to the AFA fractal dimension. The fractal dimension of a flight upon crossing the border between the AFA and AA reception zone remains unchanged allowing that in the most critical part of the transition flight in the vicinity of the TC and in the TC the conflict encounter does not increase for the transitioning aircraft (Fig. 1).

The Autonomous Flight 111

Aircraft flows from either side of the TL converging for transit through the TCs, leading to the traffic dynamic density increase on either side of the TL in its proximity (applying the WJHTC/Titan Systems Metric: the convergence recognition index, separation critically index, and degrees of freedom index will be the most critical [7]). Traditionally the traffic dynamic density is limited by the air traffic controller workload, however even in the AFA or AA the dynamic density will still remain limiting factor due to the limited airborne and ground–based separation assurance system processor capacity as well as limited data–link bandwidth. Dynamic airspace sectorization will ensure that the air traffic dynamic density doesn't reach its limits by the TL shifting. The (pressure) altitude of the TL is proportional to the air traffic dynamic density trend; if it is increasing, for example, the TL will ascend,

resulting in AA vertical expansion simultaneously with the AFA *contraction* (Fig. 2).

coordination of future 4D trajectories of aircraft in the area.

plane of TL.)

In the AFA and AA aircraft, in–flight spacing and separation relies on the machine–based decision–making ASAS; in the AFA the AASAS, responsibility extends to the exit plane of the TL, while in the AA the ground–based automation ASAS responsibilities extend to the entry plane of the TL. Since the exit plane doesn't coincide with the entry plane the airborne spacing and separation of aircraft responsibilities are shared in the TL between the AASAS onboard autonomous aircraft and the ground–based automation ASAS of the AA. Due to shared responsibilities for airborne separation the entrance and exit TCs must be separated; aircraft are flying from the AFA through the exit TC, while they are entering the AFA through the entry TC (Fig. 2). Consequently, and considering again the fact that airborne separation is based upon the machine–based decision–making in the AFA and AA, any conflict avoidance maneuvering can only be coordinated implicitly between the AASAS and/or ASAS onboard aircraft involved in the conflict encounter, including implicit

Since AASAS of autonomously flying aircraft is still responsible for the in–flight spacing and separation when the transitioning aircraft is in the TC at the exit plane of the TL, the AASAS has to be capable of detecting possible conflict situations with aircraft flying in the AA even before the time of transition from the AFA. Actually the rest of the transitioning aircraftfree--and especially conflict-free--exit TC can only be selected (determined) in the process of aircraft descent trajectory from the AFA definition before the TOD is reached, providing that accurate prediction of along the descending route and across the TL airborne traffic situation can be made. The greater look–ahead time for accurate and stable 4D prediction of an airborne traffic situation, demands an accurate model of aircraft future relative positions based on their real future ground speeds, their future intents, as well as on future area weather conditions. (Similar requirements are applicable for the ground–based ASAS of the AA since it is responsible for airborne aircraft spacing and separation in the TC at the entry

Rules–of–the–sky tailored to the AFA flight operations are necessary for competitive rivalry for the best optimal trajectory prevention, and also due to the fact that conflict avoidance maneuvering can only be coordinated implicitly between AASAS and/or ASAS onboard aircraft. For the transition flight to and from the AFA safety, a pair of rules applies. *The priority flight (first) rule*: "An aircraft that flies lower than the other aircraft involved in the

Descending through the CA below the AA the aircraft traverse airspace sectors of different classes with progressively increased restrictions and control (dictation) of its trajectory each time the sector boundary is crossed, leading to non–severe but gradual increase in conflicts in succession of each sector boundary crossing (X,Y; Fig. 1). However the greatest fractal dimension of a non–AA CA is far less than the AA reception zone fractal dimension. Consequently the greatest (30%) change of fractal dimension of a transitioning flight is expected to occur in the AA resulting in an 85% increase in conflict encounter (1) threatening descending aircraft (Fig. 1).

The challenge of the AA organization and traffic flow regulation is to progressively dictate the flight of the transitioning aircraft to secure gradual decrease in AA fractal dimension in the direction away from the transition layer from the value corresponding to the AFA fractal dimension with a value similar to the upper CA fractal dimension. That way the expected increase in conflict is dispersed further along the entire descending trajectory through the AA. The spacing and separation assurance actors in the AA are the AASAS of the autonomous aircraft, the ASAS of a free–flying aircraft, crews of unequipped aircraft, the ground–based separation assurance automation system, and the AA strategic traffic flow controller; but parallel to the human error hazard, a data–link communication failure imposes the greatest risk for flight safety in the AA.

#### **2.2. Autonomous flight airspace design**

For the safety of aircraft flying in the AFA and AA, both are demarcated by the transition layer (TL), defined by the entry and exit plane that are separated at least by the vertical separation minimum. The AFA extends above the entry plane, while the AA is positioned below the exit plane (Fig. 2). Aircraft are transitioning to and from the AFA through the bordered tube–like transition corridor (TC) at the TL.

**Figure 2.** The transition layer between the AFA and the AA.

Aircraft flows from either side of the TL converging for transit through the TCs, leading to the traffic dynamic density increase on either side of the TL in its proximity (applying the WJHTC/Titan Systems Metric: the convergence recognition index, separation critically index, and degrees of freedom index will be the most critical [7]). Traditionally the traffic dynamic density is limited by the air traffic controller workload, however even in the AFA or AA the dynamic density will still remain limiting factor due to the limited airborne and ground–based separation assurance system processor capacity as well as limited data–link bandwidth. Dynamic airspace sectorization will ensure that the air traffic dynamic density doesn't reach its limits by the TL shifting. The (pressure) altitude of the TL is proportional to the air traffic dynamic density trend; if it is increasing, for example, the TL will ascend, resulting in AA vertical expansion simultaneously with the AFA *contraction* (Fig. 2).

110 Advances in Air Navigation Services

threatening descending aircraft (Fig. 1).

imposes the greatest risk for flight safety in the AA.

bordered tube–like transition corridor (TC) at the TL.

**Figure 2.** The transition layer between the AFA and the AA.

**2.2. Autonomous flight airspace design** 

(Fig. 1).

TC and in the TC the conflict encounter does not increase for the transitioning aircraft

Descending through the CA below the AA the aircraft traverse airspace sectors of different classes with progressively increased restrictions and control (dictation) of its trajectory each time the sector boundary is crossed, leading to non–severe but gradual increase in conflicts in succession of each sector boundary crossing (X,Y; Fig. 1). However the greatest fractal dimension of a non–AA CA is far less than the AA reception zone fractal dimension. Consequently the greatest (30%) change of fractal dimension of a transitioning flight is expected to occur in the AA resulting in an 85% increase in conflict encounter (1)

The challenge of the AA organization and traffic flow regulation is to progressively dictate the flight of the transitioning aircraft to secure gradual decrease in AA fractal dimension in the direction away from the transition layer from the value corresponding to the AFA fractal dimension with a value similar to the upper CA fractal dimension. That way the expected increase in conflict is dispersed further along the entire descending trajectory through the AA. The spacing and separation assurance actors in the AA are the AASAS of the autonomous aircraft, the ASAS of a free–flying aircraft, crews of unequipped aircraft, the ground–based separation assurance automation system, and the AA strategic traffic flow controller; but parallel to the human error hazard, a data–link communication failure

For the safety of aircraft flying in the AFA and AA, both are demarcated by the transition layer (TL), defined by the entry and exit plane that are separated at least by the vertical separation minimum. The AFA extends above the entry plane, while the AA is positioned below the exit plane (Fig. 2). Aircraft are transitioning to and from the AFA through the In the AFA and AA aircraft, in–flight spacing and separation relies on the machine–based decision–making ASAS; in the AFA the AASAS, responsibility extends to the exit plane of the TL, while in the AA the ground–based automation ASAS responsibilities extend to the entry plane of the TL. Since the exit plane doesn't coincide with the entry plane the airborne spacing and separation of aircraft responsibilities are shared in the TL between the AASAS onboard autonomous aircraft and the ground–based automation ASAS of the AA. Due to shared responsibilities for airborne separation the entrance and exit TCs must be separated; aircraft are flying from the AFA through the exit TC, while they are entering the AFA through the entry TC (Fig. 2). Consequently, and considering again the fact that airborne separation is based upon the machine–based decision–making in the AFA and AA, any conflict avoidance maneuvering can only be coordinated implicitly between the AASAS and/or ASAS onboard aircraft involved in the conflict encounter, including implicit coordination of future 4D trajectories of aircraft in the area.

Since AASAS of autonomously flying aircraft is still responsible for the in–flight spacing and separation when the transitioning aircraft is in the TC at the exit plane of the TL, the AASAS has to be capable of detecting possible conflict situations with aircraft flying in the AA even before the time of transition from the AFA. Actually the rest of the transitioning aircraftfree--and especially conflict-free--exit TC can only be selected (determined) in the process of aircraft descent trajectory from the AFA definition before the TOD is reached, providing that accurate prediction of along the descending route and across the TL airborne traffic situation can be made. The greater look–ahead time for accurate and stable 4D prediction of an airborne traffic situation, demands an accurate model of aircraft future relative positions based on their real future ground speeds, their future intents, as well as on future area weather conditions. (Similar requirements are applicable for the ground–based ASAS of the AA since it is responsible for airborne aircraft spacing and separation in the TC at the entry plane of TL.)

Rules–of–the–sky tailored to the AFA flight operations are necessary for competitive rivalry for the best optimal trajectory prevention, and also due to the fact that conflict avoidance maneuvering can only be coordinated implicitly between AASAS and/or ASAS onboard aircraft. For the transition flight to and from the AFA safety, a pair of rules applies. *The priority flight (first) rule*: "An aircraft that flies lower than the other aircraft involved in the conflict encounter when conflict is detected, has the right–of–way." The rule therefore implies that only the higher flying aircraft is responsible for resolving the conflict situation. Since the AFA extends above the AA, the autonomous aircraft flying in the AFA are obliged to maneuver for menacing conflict resolution in case they are encountering conflict with an aircraft climbing to enter the AFA from the AA, and in their envisioned descent transition from the AFA. This priority rule also defines minimum separation between the entry and exit plane, as well as minimum separation between the entry and exit TCs at the TL for unnecessary aircraft maneuvering in the AFA prevention. *A maneuver flight (second) rule*: "After a conflict is detected, it is prohibited for the aircraft which has the right–of–way to alter planned trajectory until conflict is resolved." A pair of rules is therefore defined to ensure reliable implicit coordination of conflict avoidance maneuvering and increase conflict resolution predictability.

#### **3. Autonomous airborne separation assurance**

#### **3.1. Aircraft relative flight model**

The primitive flight model predicts each aircraft's future trajectory with extrapolation of its ground speed vector from aircraft's last position, while the aircraft's ground speed vector is derived with interpolation between its last two known positions. The predictions of this model are therefore based upon a set of presumptions of: (a) constant aircraft ground speed and direction, followed by (b) constant wind speed and direction, and (c) constant static state (temperature) of atmosphere as well.

Let's investigate the reliability of conflict detection in the encounter situation between our own aircraft denoted by index 2 in descent and the intruder denoted by index 1 in level flight below. If the time of the present level cruise phase of own flight is denoted as , while *t* denotes the time of own aircraft descent as a subsequent phase of its flight, then the primitive model of relative position between own aircraft and intruder with the top of descent accounted for as a future intent can be written as:

$$\begin{aligned} \dot{x}\_R(\tau, t) &= v\_{2G} \cos \psi\_R - v\_{1G} \\ \dot{y}\_R(\tau, t) &= v\_{2G} \sin \psi\_R \\ \dot{z}\_R(\tau, t) &= -v\_{2G} \tan \theta\_R(\tau, t) \end{aligned} \tag{2}$$

The Autonomous Flight 113

as a function of static state of an

*z Tz* ) variation with aircraft

due to the changing set of speed

 *z wz z* defined with

(3)

(4)

0 ) in the stratosphere:

The improved model of aircraft flight was derived to include not only the aircraft (crew)

Based on the simplification that an angular velocity vector of each aircraft equals to zero, and an assumption that an alteration of each aircraft trajectory is instantaneous (chapter

( ( ( ), ( )), ( ))cos ( ( ))cos

 

 

 

2 2 2

(5)

*z*

2

*S*

*R S DR R S D*

*R S DR R*

andcan be transformed into the time dependant function using the rate of climb (+) or

where the progressive speed *V* of an aircraft follows form the aircraft speed vector triangle:

*w v z zw*

cos( ) ( ( ), ( )) sin ( ) ( ) cos ( ( ))

The solution of the improved kinematical model of aircraft relative flight (3; (4) and (5)) is presented, as improved model of the aircraft relative motion, for the case that aircraft abbreviated as A2 and its flight parameters denoted by index 2, starts its descent at the top of descent (TOD) from a cruise level *zFL2* in stratosphere *FL tp* <sup>2</sup> *z z* (tropopause at *ztp*) at <sup>0</sup> *t t TOD* after conflict is detected at *t0*, while the intruder denoted by index 1 continues its constant Mach number *M* level cruise. The solution of (3) provided is partitioned according to descending aircraft flight phases; note that s, c and t denote trigonometric functions of

 

 

*R*

<sup>2</sup> ( )sin ( ( )) *<sup>R</sup> dz Vz z*

 

( ( ( ), ( )), ( ))sin ( ( ))cos ( ( ( ), ( )), ( ))sin ( ( ))

22 2 2

 

 

> 

> 

*x Vv z z z z*

*y Vv z z z z z Vv z z z z*

( ( ( ), ( )), ( ))

*Vv z z z*

 

 

*dt* 

 

a. <sup>0</sup> *TOD t tt* ( <sup>0</sup>*<sup>t</sup>* <sup>0</sup> ): the A2 is in a *M const* <sup>2</sup> level cruise ( <sup>2</sup>

 

*R S D R*

22 2 2

22 2 2

*<sup>S</sup>*(i.e. static air temperature (SAT)*T*; ( ) { ( )} *<sup>S</sup>*

c. the influence of the dynamic state of an atmosphere ( ) { ( ), ( )} *<sup>D</sup>*

3.2.1), the improved model of aircraft relative motion is defined with:

11 1

*z Mv* of descent and/or climb with constant Mach number *M* and/or

on the progressive speed *V* of an aircraft which can be

 

 

 

future intent but also to consider:

height *z* above reference,

regimes ( ) { , } *<sup>C</sup>* 

atmosphere

descent (–) definition:

sine, cosine and tangent.

a. the aircraft true airspeed *v* variableness ( ( )) *<sup>S</sup> vv z*

b. the aircraft true airspeed variableness *vv z* ( ( ))

with constant calibrated airspeed *vC*,

/

/

 

/

*V z*

*<sup>D</sup>* .

the wind speed *w* and direction

written as ( , ( )) *V Vv z*

where*R* and *<sup>R</sup>* are the relative angles between aircraft trajectories in the horizontal and vertical plane successively, and *vG* is their ground speed.

Closer examination of a primitive model (2) reveals that, if there is no distinction made between the time of own aircraft level flight and the time of its descent then, the primitive model cannot predict when this aircraft will alter its trajectory. Furthermore, following presumptions of the primitive model described above it is obvious that, even if deficiency of this primitive model is corrected with introduction of each aircraft future intent, this primitive model cannot account for the future aircraft trajectory variations due to the true airspeed variableness as a function of a non-zero vertical static temperature gradient in the troposphere.

The improved model of aircraft flight was derived to include not only the aircraft (crew) future intent but also to consider:

112 Advances in Air Navigation Services

resolution predictability.

where*R* and 

**3.1. Aircraft relative flight model** 

state (temperature) of atmosphere as well.

**3. Autonomous airborne separation assurance** 

descent accounted for as a future intent can be written as:

vertical plane successively, and *vG* is their ground speed.

conflict encounter when conflict is detected, has the right–of–way." The rule therefore implies that only the higher flying aircraft is responsible for resolving the conflict situation. Since the AFA extends above the AA, the autonomous aircraft flying in the AFA are obliged to maneuver for menacing conflict resolution in case they are encountering conflict with an aircraft climbing to enter the AFA from the AA, and in their envisioned descent transition from the AFA. This priority rule also defines minimum separation between the entry and exit plane, as well as minimum separation between the entry and exit TCs at the TL for unnecessary aircraft maneuvering in the AFA prevention. *A maneuver flight (second) rule*: "After a conflict is detected, it is prohibited for the aircraft which has the right–of–way to alter planned trajectory until conflict is resolved." A pair of rules is therefore defined to ensure reliable implicit coordination of conflict avoidance maneuvering and increase conflict

The primitive flight model predicts each aircraft's future trajectory with extrapolation of its ground speed vector from aircraft's last position, while the aircraft's ground speed vector is derived with interpolation between its last two known positions. The predictions of this model are therefore based upon a set of presumptions of: (a) constant aircraft ground speed and direction, followed by (b) constant wind speed and direction, and (c) constant static

Let's investigate the reliability of conflict detection in the encounter situation between our own aircraft denoted by index 2 in descent and the intruder denoted by index 1 in level

*t* denotes the time of own aircraft descent as a subsequent phase of its flight, then the primitive model of relative position between own aircraft and intruder with the top of

> 2 2

*zt v t*

*x tv v*

( , ) tan ( , )

Closer examination of a primitive model (2) reveals that, if there is no distinction made between the time of own aircraft level flight and the time of its descent then, the primitive model cannot predict when this aircraft will alter its trajectory. Furthermore, following presumptions of the primitive model described above it is obvious that, even if deficiency of this primitive model is corrected with introduction of each aircraft future intent, this primitive model cannot account for the future aircraft trajectory variations due to the true airspeed variableness as a function of a non-zero vertical static temperature gradient in the troposphere.

*R G RG R GR R GR*

( , ) cos ( , ) sin

 

*y tv*

 

 2 1

 

*<sup>R</sup>* are the relative angles between aircraft trajectories in the horizontal and

 

  , while

(2)

flight below. If the time of the present level cruise phase of own flight is denoted as


Based on the simplification that an angular velocity vector of each aircraft equals to zero, and an assumption that an alteration of each aircraft trajectory is instantaneous (chapter 3.2.1), the improved model of aircraft relative motion is defined with:

$$\begin{aligned} x'\_R &= V\_2(v\_2(\sigma\_2(z), \theta\_\ $(z)), \theta\_\mathcal{D}(z)) \cos \theta\_\mathcal{R}(\sigma\_2(z)) \cos \psi\_R - \\ &- V\_1(v\_1(\sigma\_1(z), \theta\_\$ (z)), \theta\_\mathcal{D}(z)) \\ y'\_R &= V\_2(v\_2(\sigma\_2(z), \theta\_\mathcal{S}(z)), \theta\_\mathcal{D}(z)) \sin \theta\_\mathcal{R}(\sigma\_2(z)) \cos \psi\_R \\ z'\_R &= V\_2(v\_2(\sigma\_2(z), \theta\_\mathcal{S}(z)), \theta\_\mathcal{D}(z)) \sin \theta\_\mathcal{R}(\sigma\_2(z)) \end{aligned} \tag{3}$$

andcan be transformed into the time dependant function using the rate of climb (+) or descent (–) definition:

$$\pm \frac{dz}{dt} = V(z) \sin \theta\_R(\sigma\_2(z)) \tag{4}$$

where the progressive speed *V* of an aircraft follows form the aircraft speed vector triangle:

$$V(z) = \frac{w\cos(\xi - \wp) + \sqrt{v^2(\sigma(z), \theta\_{\mathbb{S}}(z)) - w^2 \sin^2(\xi - \wp)}}{\cos \theta\_{\mathbb{R}}(\sigma\_2(z))}\tag{5}$$

The solution of the improved kinematical model of aircraft relative flight (3; (4) and (5)) is presented, as improved model of the aircraft relative motion, for the case that aircraft abbreviated as A2 and its flight parameters denoted by index 2, starts its descent at the top of descent (TOD) from a cruise level *zFL2* in stratosphere *FL tp* <sup>2</sup> *z z* (tropopause at *ztp*) at <sup>0</sup> *t t TOD* after conflict is detected at *t0*, while the intruder denoted by index 1 continues its constant Mach number *M* level cruise. The solution of (3) provided is partitioned according to descending aircraft flight phases; note that s, c and t denote trigonometric functions of sine, cosine and tangent.

$$\text{a. } \quad t\_0 \le t \le t\_{\text{TOD}} \text{ (}\ t\_0 = 0\text{); the A2 is in a } \, M\_2 = \text{const} \text{ level cruise} \, (\theta\_2 = 0\text{) in the stratosphere:} $$

#### 114 Advances in Air Navigation Services

$$\begin{split} \mathbf{x}\_{R}(t) &= \mathbf{x}\_{R}(t\_{0}) + \left( \mathbf{w} \left( \mathbf{c}\_{\dot{\lambda}\_{2}} \mathbf{c}\_{\nu\_{R}} - \mathbf{c}\_{\dot{\lambda}\_{1}} \right) - \sqrt{M\_{1}^{2} a\_{F\perp1}^{2} - w^{2} \mathbf{s}\_{\dot{\lambda}\_{1}}^{2}} + \mathbf{c}\_{\nu\_{R}} \sqrt{M\_{2}^{2} a\_{\nu}^{2} - w^{2} \mathbf{s}\_{\dot{\lambda}\_{2}}^{2}} \right) t \\ \mathbf{y}\_{R}(t) &= \mathbf{y}\_{R}(t\_{0}) + \mathbf{s}\_{\nu\_{R}} \left( \mathbf{w} \, \mathbf{c}\_{\dot{\lambda}\_{2}} + \sqrt{M\_{2}^{2} a\_{tp}^{2} - w^{2} \mathbf{s}\_{\dot{\lambda}\_{2}}^{2}} \right) t \\ \mathbf{z}\_{R}(t) &= \mathbf{z}\_{R}(t\_{0}) \end{split} \tag{6}$$

The Autonomous Flight 115

(13)

(14)

(15)

2 2

*R R R*

2 2

09 9 2 2

1 1 11

7 11 8

0

*g LR*

9 9 0 10

<sup>2</sup>

2 1

0 2 2

 

 

, while index *R* denotes the relative parameter.

2

0 <sup>1</sup> 1 1

*a*

2

 

0

2 2 <sup>2</sup> 2 2 <sup>1</sup> <sup>2</sup>

00 0 0 1 1 s 21 1 1

The abbreviations not given in the text are: *g0* is acceleration of gravity, *L* is (temperature

of sound at reference level of standard atmosphere and at aircraft flight level (*FL*), *T0* and *T0R* are

*R R*

(16)

1

 

is ratio of specific heats, *a0* and *aFL* are speed

represents the difference between the wind

 

22 22 2 2

1

<sup>1</sup> <sup>1</sup>

<sup>0</sup> <sup>0</sup>

*g g LR LR*

2

(17)

(18)

(19)

() ( ) c c c c s c

 

2 1 1

*xt xt w k Ma w t t k t t*

*R R FL p p*

7 8

7 8

4 0 4 0

*R R RT Lk Lk kk w <sup>s</sup> k T k T*

3 97 4 0 4 0

*k kk k T RL k T*

93 3 4 3 4 4 t *pp p k k k k t z k kz* 

> 2 *Cv <sup>k</sup>*

c s *C R v T kw w T*

4 2 2 *C R <sup>C</sup> <sup>C</sup> <sup>C</sup> k vT v L <sup>v</sup> <sup>v</sup> kwg TT a a*

1 1 11 1

2

*R R*

where ( ) *R p* r *t* is solution of (8) for *<sup>p</sup> t t* , while *k7*, *k8*, *k9*, *k10*, and *k3*, *k4* are:

12 2

8 10 10

10

3

1

3 0 2 2

4 0

atmospheric) lapse rate, *R* is universal gas constant,

reference SATs of standard and real atmosphere,

and aircraft true heading

t 1

2 1 2 2

*RL Lk g k Lk k k <sup>k</sup>*

2

 

2 22

() ( ) t c t ,

*RR p p*

*zt zt tt w k kt t*

7 10

*R*

*RR p p*

*yt yt tt w k kt t*

() ( ) s c s

*p*

*p*

*p*

2

direction

2

 

where 0 000 ( ) ( ( ), ( ), ( )) *R RRR* r *t xt yt zt* is the initial aircraft relative position when conflict is detected at *t*0.

b. *TOD tp t tt* : the A2 descends in constant *M* speed–regime with constant angle of descent *<sup>R</sup>* <sup>2</sup> through the stratosphere:

$$\begin{split} \mathbf{x}\_{R}(t) &= \mathbf{x}\_{R}(t\_{TOD}) + \left( \text{w}\left( \mathbf{c}\_{\dot{\lambda}\_{2}} \mathbf{c}\_{\nu\_{R}} - \mathbf{c}\_{\dot{\lambda}\_{1}} \right) - \sqrt{M\_{1}^{2} a\_{FL1}^{2} - w^{2} \mathbf{s}\_{\dot{\lambda}\_{1}}^{2}} + \mathbf{c}\_{\nu\_{R}} \sqrt{M\_{2}^{2} a\_{tp}^{2} - w^{2} \mathbf{s}\_{\dot{\lambda}\_{2}}^{2}} \right) t \\ \mathbf{y}\_{R}(t) &= \mathbf{y}\_{R}(t\_{TOD}) + \mathbf{s}\_{\psi\_{R}} \left( w \, \mathbf{c}\_{\dot{\lambda}\_{2}} + \sqrt{M\_{2}^{2} a\_{tp}^{2} - w^{2} \mathbf{s}\_{\dot{\lambda}\_{2}}^{2}} \right) t \\ \mathbf{z}\_{R}(t) &= \mathbf{z}\_{R}(t\_{TOD}) - \mathbf{t}\_{\theta\_{2}} \left( w \, \mathbf{c}\_{\dot{\lambda}\_{2}} + \sqrt{M\_{2}^{2} a\_{tp}^{2} - w^{2} \mathbf{s}\_{\dot{\lambda}\_{2}}^{2}} \right) t \end{split} \tag{7}$$

where ( ) *R TOD* r *t* is solution of (6) for *TOD t t* .

c. *tp p t tt* : after passing the tropopause at *ttp* the A2 descends in constant *M* speed– regime through the troposphere:

$$\begin{split} \mathbf{x}\_{R}(t) &= \mathbf{x}\_{R}(t\_{tp}) + \left[ w\left(\mathbf{c}\_{\lambda\_{2}}\mathbf{c}\_{\nu\_{x}} - \mathbf{c}\_{\lambda\_{1}}\right) + \mathbf{c}\_{\nu\_{x}}k\_{3}M\_{2}\sqrt{\mathbf{z}\mathcal{R}} - \sqrt{M\_{1}^{2}}t\_{T11}^{2} - w^{2}\mathbf{s}\_{\lambda\_{1}}^{2} \right] \left( t - t\_{tp} \right) + \mathbf{c}\_{\nu\_{x}}k\_{6}M\_{2}\sqrt{\mathbf{z}\mathcal{R}} \left( t^{2} - t\_{tp}^{2} \right) \\ \mathbf{y}\_{R}(t) &= \mathbf{y}\_{R}(t\_{tp}) + \mathbf{s}\_{\nu\_{x}} \left( t - t\_{tp} \right) \left( w\,\mathbf{c}\_{\lambda\_{2}} + k\_{3}M\_{2}\sqrt{\mathbf{z}\mathcal{R}} \right) + \mathbf{s}\_{\nu\_{x}}k\_{6}M\_{2}\sqrt{\mathbf{z}\mathcal{R}} \left( t^{2} - t\_{tp}^{2} \right) \\ \mathbf{z}\_{R}(t) &= \mathbf{z}\_{R}(t\_{tp}) - \mathbf{t}\_{\theta\_{2}} \left( t - t\_{tp} \right) \left( w\,\mathbf{c}\_{\lambda\_{2}} + k\_{3}M\_{2}\sqrt{\mathbf{z}\mathcal{R}} \right) - \mathbf{t}\_{\theta\_{2}}k\_{6}M\_{2}\sqrt{\mathbf{z}\mathcal{R}} \left( t^{2} - t\_{tp}^{2} \right), \end{split} \tag{8}$$

where ( ) *R tp* r *t* is solution of (7) for *tp t t* , while *k5*, *k6*, and *k1* and *k2* are:

$$k\_5 = \sqrt{T\_{0R} + \frac{L}{2k\_2} \left[k\_1 - \sqrt{k\_1^2 + 4k\_2 \left(t\_{tp}t\_{\theta\_2} + z\_{tp} \left(k\_1 + k\_2 z\_{tp}\right)\right)}\right]} - \frac{w^2 s\_{\lambda\_2}^2}{M\_2^2 \mathcal{Z} \mathcal{R}}\tag{9}$$

$$k\_6 = L \operatorname{t}\_{\theta\_2} \left( 4k\_5 \sqrt{k\_1^2 + 4k\_2 \left( t\_{tp} \mathbf{t}\_{\theta\_2} + z\_{tp} \left( k\_1 + k\_2 z\_{tp} \right) \right)} \right)^{-1} \tag{10}$$

$$k\_1 = \left(w\,\mathrm{c}\_{\lambda} + \sqrt{M^2 \,\mathrm{Z} \,\mathrm{R} T\_{0R} - w^2 \mathrm{s}\_{\lambda}^2} \right)^{-1} \tag{11}$$

$$k\_2 = \frac{k\_1^2 M L \sqrt{\mathcal{Z} \mathcal{R}}}{4} \left( T\_{0R} - \frac{w^2 \mathbf{s}\_{\lambda}^2}{M^2 \mathcal{Z} \mathcal{R}} \right)^{-\frac{1}{2}} \tag{12}$$

d. *<sup>p</sup> t t* : at *tp* the A2 changes its speed–regime and continues its descent through the troposphere with the constant calibrated airspeed ( *<sup>C</sup>*<sup>2</sup> *v const* ):

$$\begin{split} \mathbf{x}\_{R}(t) &= \mathbf{x}\_{R}(t\_{p}) + \left[ w\left( \mathbf{c}\_{\mathcal{L}\_{2}} \mathbf{c}\_{\boldsymbol{\nu}\_{R}} - \mathbf{c}\_{\mathcal{L}\_{1}} \right) + \mathbf{c}\_{\boldsymbol{\nu}\_{R}} k\_{7} - \sqrt{M\_{1}^{2} \mathbf{c}\_{\boldsymbol{\nu}\_{L1}}^{2} - w^{2} \mathbf{s}\_{\mathcal{L}\_{1}}^{2}} \right] \left( t - t\_{p} \right) + \mathbf{c}\_{\boldsymbol{\nu}\_{R}} k\_{8} \left( t^{2} - t\_{p}^{2} \right) \\ \mathbf{y}\_{R}(t) &= \mathbf{y}\_{R}(t\_{p}) + \mathbf{s}\_{\boldsymbol{\nu}\_{R}} \left( t - t\_{p} \right) \left( w\mathbf{c}\_{\mathcal{L}\_{2}} + k\_{7} \right) + \mathbf{s}\_{\boldsymbol{\nu}\_{R}} k\_{8} \left( t^{2} - t\_{p}^{2} \right) \\ \mathbf{z}\_{R}(t) &= \mathbf{z}\_{R}(t\_{p}) - \mathbf{t}\_{\theta\_{2}} \left( t - t\_{p} \right) \left( w\mathbf{c}\_{\mathcal{L}\_{2}} + k\_{7} \right) - \mathbf{t}\_{\theta\_{2}} k\_{8} \left( t^{2} - t\_{p}^{2} \right) . \end{split} \tag{13}$$

where ( ) *R p* r *t* is solution of (8) for *<sup>p</sup> t t* , while *k7*, *k8*, *k9*, *k10*, and *k3*, *k4* are:

114 Advances in Air Navigation Services

2 1 1 2

 

22 22 22 22

22 22 22 22

22 22 2 2

2 2

s

(12)

1

 

(6)

(7)

(8)

(9)

*R R FL tp*

 

0 2

*R*

*R R tp*

() ( ) s c s

*y t y t w Ma w t*

 

through the stratosphere:

 

() ( ) s c s

*y t y t w Ma w t*

() ( ) t c s

*z t z t w Ma w t*

2 22 2

 

() ( ) t c t ,

where ( ) *R tp* r *t* is solution of (7) for *tp t t* , while *k5*, *k6*, and *k1* and *k2* are:

*R R*

*y t y t t t w kM R kM Rt t z t z t t t w kM R kM Rt t*

*R R tp tp R R tp tp*

 

() ( ) s c s

 

*R*

*R R tp*

*R R tp*

0

*TOD*

*TOD*

*TOD*

where ( ) *R TOD* r *t* is solution of (6) for *TOD t t* .

regime through the troposphere:

*tp tp tp*

() ( )

*R R*

detected at *t*0.

b. *TOD tp*

descent *<sup>R</sup>* <sup>2</sup> 

*zt zt*

2 2

*R R FL tp*

 

2

 

5 2 6 2

5 2 6 2

2 1 1

2

2

1

troposphere with the constant calibrated airspeed ( *<sup>C</sup>*<sup>2</sup> *v const* ):

*k T k k k t z k kz*

() ( ) c c c c s c

2 2

22 22

22 22

c. *tp p t tt* : after passing the tropopause at *ttp* the A2 descends in constant *M* speed–

*R R FL tp tp*

 

 

5 0 112 1 2 2

4 t 2 *R tp tp tp*

6 51 2 1 2 t4 4 t *tp tp tp k L k k k t z k kz*

1 0 c s *<sup>R</sup> k w M RT w*

2 0 2

4 *<sup>R</sup> k ML R <sup>w</sup> k T*

*xt xt w kM R Ma w t t kM Rt t*

*R R R*

() ( ) c c c s c s

*xt xt w Ma w Ma w t*

2

2 2 2

0 1 1 2 22 22

*R R*

() ( ) c c c s c s

*xt xt w Ma w Ma w t*

where 0 000 ( ) ( ( ), ( ), ( )) *R RRR* r *t xt yt zt* is the initial aircraft relative position when conflict is

*t tt* : the A2 descends in constant *M* speed–regime with constant angle of

*R R*

 

 

2

2 2

 <sup>1</sup> 2 2 2

2 2 2 2

d. *<sup>p</sup> t t* : at *tp* the A2 changes its speed–regime and continues its descent through the

 

*L w*

2 2

*k M R*

5 2 1 1 6 2

2 2

<sup>2</sup>

(10)

 (11)

1

 

s

*M R* 

2 2

2 1 1 2

1 1 2

 

$$k\_{7} = \sqrt{\frac{2\mathcal{K}RT\_{0R}}{\mathcal{X} - 1} \left(1 + \frac{Lk\_{9}}{2k\_{4}T\_{0R}}\right) \left[ \left(k\_{10} \left(1 + \frac{Lk\_{9}}{2k\_{4}T\_{0R}}\right)^{\frac{\mathcal{S}\_{0}}{LR}} + 1\right)^{\frac{\mathcal{X} - 1}{\mathcal{X}}} - 1\right]} - 1\right] - w^{2}s\_{\lambda\_{2}}^{2} \tag{14}$$

$$k\_{8} = \frac{\mathcal{X}\mathcal{L}\mathbf{t}\_{\theta\_{2}}}{2(\varkappa - 1)(k\_{3} - k\_{9})k\_{7}} \left[ -1 + \left( k\_{10} \left( 1 + \frac{Lk\_{9}}{2k\_{4}T\_{0\mathcal{R}}} \right)^{\frac{\mathcal{G}\_{0}}{\mathcal{L}\mathcal{R}}} + 1 \right)^{\frac{\mathcal{X}}{\mathcal{X}}} \left( 1 - \frac{\left( \varkappa - 1 \right) g\_{0} k\_{10}}{\varkappa \mathcal{R}\mathcal{L}} \left( k\_{10} + \left( 1 + \frac{Lk\_{9}}{2k\_{4}T\_{0\mathcal{R}}} \right)^{\frac{\mathcal{G}\_{0}}{\mathcal{L}\mathcal{R}}} \right)^{-1} \right) \tag{15}$$

$$k\_g = k\_3 - \sqrt{k\_3^2 + 4k\_4 \left(\mathbf{t}\_{\partial\_2} t\_p + z\_p \left(k\_3 + k\_4 z\_p\right)\right)}\tag{16}$$

$$k\_{10} = \left(1 + \frac{\mathcal{X} - 1}{2} \left(\frac{v\_{C2}}{a\_0}\right)^2\right)^{\frac{\mathcal{X}}{\mathcal{X} - 1}} - 1\tag{17}$$

$$k\_3 = \left( w \,\mathrm{c}\_{\lambda} + \sqrt{\frac{v\_{\mathcal{C}}^2 T\_{0R}}{T\_0} - w^2 \,\mathrm{s}\_{\lambda}^2} \right)^{-1} \tag{18}$$

$$k\_{4} = \frac{k\_{3}^{2}}{4} \left(\frac{v\_{\text{C}}^{2}T\_{0R}}{T\_{0}} - w^{2}s\_{\text{A}}^{2}\right)^{-\frac{1}{2}} \left[\frac{v\_{\text{C}}^{2}L}{T\_{0}} - 2g\_{0}\left(1 + \frac{\mathcal{X} - 1}{2}\left(\frac{v\_{\text{C}}}{a\_{0}}\right)^{2}\right)\left[1 - \left(1 + \frac{\mathcal{X} - 1}{2}\left(\frac{v\_{\text{C}}}{a\_{0}}\right)^{2}\right)^{-\frac{\mathcal{X}}{\mathcal{X} - 1}}\right] \right] \tag{19}$$

The abbreviations not given in the text are: *g0* is acceleration of gravity, *L* is (temperature atmospheric) lapse rate, *R* is universal gas constant, is ratio of specific heats, *a0* and *aFL* are speed of sound at reference level of standard atmosphere and at aircraft flight level (*FL*), *T0* and *T0R* are reference SATs of standard and real atmosphere, represents the difference between the wind direction and aircraft true heading , while index *R* denotes the relative parameter.

#### **3.2. Accuracy of modeling**

#### *3.2.1. Simplifications based errors*

At the top of descent (TOD) an aircraft starts its rotation ( ) (0, ,0) *t* (for [0, ]*<sup>t</sup> t t* ) about its lateral axis until the angle of descent is established after transition time *tt* as is shown in Fig. 3.

**Figure 3.** Simplified transition into descent.

For simplicity of an improved model of aircraft relative flight (3) the instantaneous aircraft transition into descent is assumed:

$$\begin{aligned} \lim\_{t\_i \to 0} \frac{V}{\alpha\_\theta} \Big( 1 - \cos \left( \alpha\_\theta \, t\_t \right) \Big) &= 0 \\ \lim\_{t\_i \to 0} \frac{V}{\alpha\_\theta} \sin \left( \alpha\_\theta \, t\_t \right) &= 0 \end{aligned} \tag{20}$$

The Autonomous Flight 117

**Figure 4.** The improved model aircraft position errors in vertical *ez* and horizontal *ex-y* plane after

determinable and with corrections for the *ez*, accurate as well.

to descent with the constant calibrated airspeed (280kt).

*3.2.2 Aircraft trajectory prediction errors* 

While the horizontal plane *ex-y* theoretical position error of improved model (3) is negligible, the vertical plane *ez* position error will be in the worst case almost equal to the reduced vertical separation minimum (RVSM) standard, in high–speed long–duration transition into descent, in tail–wind conditions (Fig. 4). However, as the vertical plane *ez* position error is predictable and constant after transition into descent, the future aircraft descent trajectory is

The descent trajectory prediction error of each model was determined by comparison of future trajectory predicted for the next 900 seconds (15 minutes) using each model (2) and (3) with the actual flight data recorded on commercial flight of Airbus A320 [10]. The ATC imposed break in actual flight which came after the TOD was used to foster trustworthiness of the methodology for the determination of the trajectory prediction error. The results of comparison are presented in Fig. 5, where point A indicates the TOD and B denotes the tropopause (ISA–1,24°C). At C the descent is interrupted, at D resumed, and at point E the descent speed regime has been altered from descent with the constant Mach number (0.78)

The trajectory prediction error of a primitive model of aircraft relative motion (2) clearly increases with the look-ahead time.The reason for such error is in the design of the primitive model of flight being ignorant to the variation of a true airspeed due to the static air temperature gradient in the troposphere. Within next 300 seconds (5 minutes) after the descent is resumed (at E), the trajectory prediction error of the primitive model exceeds 30%

For the entire look-ahead time (15 minutes) of an aircraft future trajectory, predicted with the improved model of flight (3), its trajectory prediction error is stable in oscillations within ±16% of the RVSM standard. Being for the factor of at least 3 more accurate in trajectory prediction as the primitive model, the improved model promises greater reliability of

transition into descent.

of the RVSM standard.

conflict detection.

Due to simplification (20), the aircraft trajectory is not smooth at the TOD, resulting in the horizontal *ex-y* and vertical *ez* plane error of aircraft position prediction in the period of transition time [0, ]*<sup>t</sup> t t* .It can be theoretically estimated from Fig. 1 as:

$$\begin{aligned} e\_{x-y}(t\_t) &= V(t\_t) \left( \cos \theta - \frac{\sin \theta}{\hat{\theta}} \right) t\_t \\ e\_z(t\_t) &= V(t\_t) \left( \sin \theta - \frac{1 - \cos \theta}{\hat{\theta}} \right) t\_t \end{aligned} \tag{21}$$

The position errors *ex-y* and *ez* (21) are proportional to the transition time *tt*, angle of descent , and aircraft progressive speed ( ( ( ), ( )), ) *V fv z z S D* . They reach their maximum after the transition into descent is completed at *tt*; however, after transition time *tt*, the theoretical position errors *ex-y* and *ez* (21) of improved model (3) are constant. The theoretical position errors *ex-y* and *ez* are presented in Fig. 4 for constant Mach number speed regime transition into the descent with standard constant angle of 3 .

**Figure 4.** The improved model aircraft position errors in vertical *ez* and horizontal *ex-y* plane after transition into descent.

While the horizontal plane *ex-y* theoretical position error of improved model (3) is negligible, the vertical plane *ez* position error will be in the worst case almost equal to the reduced vertical separation minimum (RVSM) standard, in high–speed long–duration transition into descent, in tail–wind conditions (Fig. 4). However, as the vertical plane *ez* position error is predictable and constant after transition into descent, the future aircraft descent trajectory is determinable and with corrections for the *ez*, accurate as well.

#### *3.2.2 Aircraft trajectory prediction errors*

116 Advances in Air Navigation Services

shown in Fig. 3.

**3.2. Accuracy of modeling** 

*3.2.1. Simplifications based errors* 

**Figure 3.** Simplified transition into descent.

transition into descent is assumed:

about its lateral axis until the angle of descent

At the top of descent (TOD) an aircraft starts its rotation ( ) (0, ,0) *t*

For simplicity of an improved model of aircraft relative flight (3) the instantaneous aircraft

lim sin 0

*<sup>V</sup> <sup>t</sup>*

lim 1 cos 0

*<sup>V</sup> <sup>t</sup>*

*<sup>t</sup> <sup>t</sup>*

Due to simplification (20), the aircraft trajectory is not smooth at the TOD, resulting in the horizontal *ex-y* and vertical *ez* plane error of aircraft position prediction in the period of

sin ( ) ( ) cos

*e t Vt t*

*xy t t t*

1 cos ( ) ( ) sin

*zt t t*

.

*e t Vt t*

The position errors *ex-y* and *ez* (21) are proportional to the transition time *tt*, angle of descent

the transition into descent is completed at *tt*; however, after transition time *tt*, the theoretical position errors *ex-y* and *ez* (21) of improved model (3) are constant. The theoretical position errors *ex-y* and *ez* are presented in Fig. 4 for constant Mach number speed regime transition

0

transition time [0, ]*<sup>t</sup> t t* .It can be theoretically estimated from Fig. 1 as:

, and aircraft progressive speed ( ( ( ), ( )), ) *V fv z z S D*

into the descent with standard constant angle of 3

*t*

0

*<sup>t</sup> <sup>t</sup>*

*t*

 

is established after transition time *tt* as is

(for [0, ]*<sup>t</sup> t t* )

(20)

(21)

. They reach their maximum after

The descent trajectory prediction error of each model was determined by comparison of future trajectory predicted for the next 900 seconds (15 minutes) using each model (2) and (3) with the actual flight data recorded on commercial flight of Airbus A320 [10]. The ATC imposed break in actual flight which came after the TOD was used to foster trustworthiness of the methodology for the determination of the trajectory prediction error. The results of comparison are presented in Fig. 5, where point A indicates the TOD and B denotes the tropopause (ISA–1,24°C). At C the descent is interrupted, at D resumed, and at point E the descent speed regime has been altered from descent with the constant Mach number (0.78) to descent with the constant calibrated airspeed (280kt).

The trajectory prediction error of a primitive model of aircraft relative motion (2) clearly increases with the look-ahead time.The reason for such error is in the design of the primitive model of flight being ignorant to the variation of a true airspeed due to the static air temperature gradient in the troposphere. Within next 300 seconds (5 minutes) after the descent is resumed (at E), the trajectory prediction error of the primitive model exceeds 30% of the RVSM standard.

For the entire look-ahead time (15 minutes) of an aircraft future trajectory, predicted with the improved model of flight (3), its trajectory prediction error is stable in oscillations within ±16% of the RVSM standard. Being for the factor of at least 3 more accurate in trajectory prediction as the primitive model, the improved model promises greater reliability of conflict detection.

The Autonomous Flight 119

(22)

*T/P*

.

 

 

or advanced model (3-19; ADV) of aircraft relative motion.

*dy* defined (according to (22) and Fig. 6) as:

where *r H*, 0 ).

*dx* and  .

*T/P*

,

*x t RC R*

0

*C*

*t RC R x R*

, ( ) tg ( ( ))

 

 

, ( ) tg ( ( ))

0

*RC R y R*

*y F t dt r H h*

*x F t dt r H h*

*C*

*t*

*R z*

,

*RC R*

*R C*

*z t*

0

*C*

*z F t dt H*

*t*

( )

where *r* is separation minimum in a horizontal plane, *H* is separation minimum in a vertical direction while time functions *Fx(t)*, *Fy(t)*, and *Fz(t)* are defined either by primitive (2; PRIM)

**Figure 6.** Critical initial separation between aircraft (collision in M is presented as special case of (22)

Figure 7 shows typical conflict detection error of the primitive model expressed with the error of relative distance between aircraft in close encounter situation in the horizontal plane

*T/P*

*y t*

**Figure 5.** Trajectory prediction error of the primitive and improved model of flight compared to the flight data of real commercial flight.

#### *3.2.3. Aircraft relative position error analysis*

Initial separation . .. ( , ) ( , ), ( , ), ( ) *RC R RC R RC R R* **r** *xyz T/P T/P T/P T/P* between aircraft A2 and A1 crossing at relative heading *R*, is at the moment*T/P* when A2 plans to initiate its descent at the TOD, critical (as shown in Fig. 6)if separation between them is lost after critical time *tC* while A2 descents:

$$\begin{aligned} \underbrace{\left| \begin{array}{l} \mathbf{x}\_{R,\mathbb{C}} \left( \tau\_{T/P}, \boldsymbol{\nu}\_{R} \right) + \int\_{0}^{t\_{c}} F\_{x}(t)dt \leq \left| r \right| + H \, \operatorname{tg} \theta\_{R}(\sigma(h)) \right. \\\\ \left. \boldsymbol{\nu}\_{R} \left( \boldsymbol{\iota}\_{C}, \boldsymbol{\nu}\_{R} \right) \end{array} \right|}\_{\mathbf{x}\_{R,\mathbb{C}} \left( \boldsymbol{\tau}\_{T/P}, \boldsymbol{\nu}\_{R} \right) + \int\_{0}^{t\_{c}} F\_{y}(t)dt \leq \left| r \right| + H \, \operatorname{tg} \theta\_{R}(\sigma(h)) \\\\ \underbrace{\left| \begin{array}{l} \boldsymbol{\nu}\_{R} \left( \boldsymbol{\tau}\_{T/P} \right) + \int\_{0}^{t\_{c}} F\_{z}(t)dt \leq \left| H \right| \\\\ \boldsymbol{\nu}\_{R} \left( \boldsymbol{\tau}\_{T/P} \right) + \int\_{0}^{t\_{c}} F\_{z}(t)dt \leq \left| H \right| \\\\ \boldsymbol{\nu}\_{R} \left( \boldsymbol{\tau}\_{C} \right) \end{array} \right. \end{aligned} \tag{22}$$

where *r* is separation minimum in a horizontal plane, *H* is separation minimum in a vertical direction while time functions *Fx(t)*, *Fy(t)*, and *Fz(t)* are defined either by primitive (2; PRIM) or advanced model (3-19; ADV) of aircraft relative motion.

118 Advances in Air Navigation Services

flight data of real commercial flight.

and A1 crossing at relative heading

critical time *tC* while A2 descents:

*3.2.3. Aircraft relative position error analysis* 

**Figure 5.** Trajectory prediction error of the primitive and improved model of flight compared to the

 

*R*, is at the moment

descent at the TOD, critical (as shown in Fig. 6)if separation between them is lost after

*xyz T/P T/P T/P T/P* between aircraft A2

 

*T/P* when A2 plans to initiate its

Initial separation . .. ( , ) ( , ), ( , ), ( ) *RC R RC R RC R R* **r**

 

**Figure 6.** Critical initial separation between aircraft (collision in M is presented as special case of (22) where *r H*, 0 ).

Figure 7 shows typical conflict detection error of the primitive model expressed with the error of relative distance between aircraft in close encounter situation in the horizontal plane *dx* and *dy* defined (according to (22) and Fig. 6) as:

#### 120 Advances in Air Navigation Services

$$\begin{split} \left. \mathcal{E}\_{d} \right|\_{\boldsymbol{z}\_{R}(\boldsymbol{\tau}\_{T/P})} &= \left[ \underbrace{\left( \boldsymbol{\chi}\_{\boldsymbol{R},\boldsymbol{M}} \{ \boldsymbol{\tau}\_{T/P}, \boldsymbol{\nu}\_{\boldsymbol{R}} \boldsymbol{\nu}\_{\boldsymbol{R}} \} \big|\_{\boldsymbol{z}\_{R}(\boldsymbol{\tau}\_{T/P}):\text{ADV}} - \boldsymbol{\chi}\_{\boldsymbol{R},\boldsymbol{M}} (\boldsymbol{\tau}\_{T/P}, \boldsymbol{\nu}\_{\boldsymbol{R}} \boldsymbol{\nu}\_{\boldsymbol{R}}) \big|\_{\boldsymbol{z}\_{R}(\boldsymbol{\tau}\_{T/P}):\text{PRIM}} \right)^{2} + \\ & \left. \mathcal{E}\_{d} \mathbf{d} \right|\_{\boldsymbol{z}\_{R}(\boldsymbol{\tau}\_{T/P})} \\ & \left. \right|\_{\boldsymbol{z}\_{R}(\boldsymbol{\tau}\_{T/P})} \big|\_{\boldsymbol{z}\_{R}(\boldsymbol{\tau}\_{T/P}):\text{ADV}} - \boldsymbol{y}\_{R,\boldsymbol{M}} (\boldsymbol{\tau}\_{T/P}, \boldsymbol{\nu}\_{\boldsymbol{R}} \boldsymbol{\nu}\_{\boldsymbol{R}}) \big|\_{\boldsymbol{z}\_{R}(\boldsymbol{\tau}\_{T/P}):\text{PRIM}} \right|^{2} \\ & \left. \tag{23} \right|\_{\boldsymbol{z}\_{R}(\boldsymbol{\tau}\_{T/P})} \end{split} \tag{24}$$

The Autonomous Flight 121

*<sup>d</sup>*(23) sooner at smaller initial relative height between intruder A1

and descending aircraft A2 (10000ft@75kts of wind) in windy atmosphere and when the

**Figure 8.** The relative distance between aircraft error of a primitive model exceeds the horizontal

management of descending aircraft 2 2 22 2 <sup>2</sup> ( ) ( ( ( ), ( )), , ( ( )), ) *S D dz t dt f v z z*

( ) ( ) *R R*

 

*z z*

model increases exponentially and exceeds the vertical separation minimum (Fig. 9).

where the relative position between aircraft in vertical direction

*z*

Based on the critical initial separation between aircraft (22), the error of relative position between

ADV PRIM 2

*<sup>Z</sup>* (24) is shown in Fig. 9. As long as the true airspeed increases (Fig. 6) in constant

() () ( )

 

*z z dz t F t F t dt*

The analysis of the primitive model error of relative position between aircraft in vertical

Mach number descend (6-12), the primitive model (2) is *slow* in defining the future vertical separation between descending aircraft A2 and intruder A1 below. Descending aircraft A2 will actually fly lower than predicted, and the actual vertical separation between aircraft will be smaller than predicted. After the speed regime change, the true airspeed will decrease (Fig. 6) in constant indicated airspeed descent (13-19), consequently the primitive model (2) is *to fast* in defining the future vertical separation between aircraft. Descending aircraft A2 will actually fly higher than predicted, and the actual vertical separation between aircraft will be greater than predicted. It is the constant indicated airspeed descent phase

*<sup>Z</sup>* depends upon the rate of descent and the speed regime change

 

*T/P T/P* (24)

*<sup>Z</sup>* (24) of the primitive

 

*z* (4) and is

horizontal distance error

separation minimum.

defined as:

direction

aircraft in the vertical direction

descending aircraft is faster than intruder.

Imagine an aircraft A2 initiating the descent, then the vertical axis in Fig. 7 represent the relative height between A2 and intruder A1 below at the time of initiation of descent ( ) *R TOD z* . Note how fast the error with which the primitive model predicts future distance between aircraft in encounter incessantly increases after the descending aircraft starts to descent with the constant calibrated speed regime (after wasp-like contraction of a graph on Fig.7).

**Figure 7.** The relative distance between aircraft error of the primitive model of flight.

Investigation of the relative distance between aircraft error of the primitive model shows, as presented in Fig. 8, that the error*<sup>d</sup>* will definitively (in any encounter situation) exceed*r* horizontal separation minimum (in Fig. 8 is represented by a cylinder). The peak values of relative distance between aircraft error*d* are specific for head-on encounters (140°<*<sup>R</sup>*< 220°) and head winds relative to the descending aircraft A2 (90° << 270°; tail wind for the intruder A1). The error of relative distance between aircraft *<sup>d</sup>* increases exponentially with the wind speed *w* (Fig. 8).Horizontal separation minimum *r*will be surpassed by relative horizontal distance error*<sup>d</sup>*(23) sooner at smaller initial relative height between intruder A1 and descending aircraft A2 (10000ft@75kts of wind) in windy atmosphere and when the descending aircraft is faster than intruder.

120 Advances in Air Navigation Services

( ) *R TOD z* 

Fig.7).

*R*

*z*

*dx*

. . ( ) ( ):ADV ( ):PRIM

*T/P T/P*

*T/P T/P T/P*

*RR R*

*d R zz z MR R M R*

*x x*

 

   

 

*y y*

**Figure 7.** The relative distance between aircraft error of the primitive model of flight.

and head winds relative to the descending aircraft A2 (90° <

intruder A1). The error of relative distance between aircraft

presented in Fig. 8, that the error

relative distance between aircraft error

Investigation of the relative distance between aircraft error of the primitive model shows, as

horizontal separation minimum (in Fig. 8 is represented by a cylinder). The peak values of

the wind speed *w* (Fig. 8).Horizontal separation minimum *r*will be surpassed by relative

*<sup>d</sup>* will definitively (in any encounter situation) exceed*r*

< 270°; tail wind for the

*<sup>d</sup>* increases exponentially with

*<sup>R</sup>*< 220°)

*d* are specific for head-on encounters (140°<

( ,) ( ,)

T/P

 

 

*T/P T/P*

( )

2

 

  2

1 2 

(23)

*R*

*z*

*dy*

( ,) ( ,)

*RM R z z RM R*

*T/P T/P*

Imagine an aircraft A2 initiating the descent, then the vertical axis in Fig. 7 represent the relative height between A2 and intruder A1 below at the time of initiation of descent

 . Note how fast the error with which the primitive model predicts future distance between aircraft in encounter incessantly increases after the descending aircraft starts to descent with the constant calibrated speed regime (after wasp-like contraction of a graph on

. . ( ):ADV ( ):PRIM

T/P

*R R*

( )

**Figure 8.** The relative distance between aircraft error of a primitive model exceeds the horizontal separation minimum.

Based on the critical initial separation between aircraft (22), the error of relative position between aircraft in the vertical direction *<sup>Z</sup>* depends upon the rate of descent and the speed regime change management of descending aircraft 2 2 22 2 <sup>2</sup> ( ) ( ( ( ), ( )), , ( ( )), ) *S D dz t dt f v z z z* (4) and is defined as:

$$\varepsilon\_z = \left( \frac{z\_R(\tau\_{T/P})}{F\_z(t)} \Bigg|\_{\text{ADV}} - \frac{z\_R(\tau\_{T/P})}{F\_z(t)} \Bigg|\_{\text{PRIM}} \right) \frac{d\mathbf{z}(t)}{dt} \Bigg|\_2 \tag{24}$$

The analysis of the primitive model error of relative position between aircraft in vertical direction *<sup>Z</sup>* (24) is shown in Fig. 9. As long as the true airspeed increases (Fig. 6) in constant Mach number descend (6-12), the primitive model (2) is *slow* in defining the future vertical separation between descending aircraft A2 and intruder A1 below. Descending aircraft A2 will actually fly lower than predicted, and the actual vertical separation between aircraft will be smaller than predicted. After the speed regime change, the true airspeed will decrease (Fig. 6) in constant indicated airspeed descent (13-19), consequently the primitive model (2) is *to fast* in defining the future vertical separation between aircraft. Descending aircraft A2 will actually fly higher than predicted, and the actual vertical separation between aircraft will be greater than predicted. It is the constant indicated airspeed descent phase where the relative position between aircraft in vertical direction *<sup>Z</sup>* (24) of the primitive model increases exponentially and exceeds the vertical separation minimum (Fig. 9).

The Autonomous Flight 123

**Figure 10.** Inability of conflict detection and/or incorrect conflict detection of the primitive model in

For the AASAS on-board aircraft to be based on the improved model of the aircraft relative motion (3) numerous information ofeach aircraft flight in the conflict detection zone has to be exchanged via Automatic Dependence Surveillance–Broadcast (ADS–B) as shown in Fig

According to the improved model of the aircraft relative motion (3) those information (Fig.

*<sup>I</sup>*: aircraft position, heading, speed regime and rate of

*<sup>P</sup>*: set of each future navigational fix in place and time

*<sup>S</sup>* (static air temperature at the atmospheric reference level) and

with corresponding flight parameter which will be altered at the fix, and

*<sup>D</sup>* state (wind speed and direction) of atmosphere (Fig. 12).

Since the trajectory prediction error pattern of the improved model of aircraft relative motion is non-increasing and stable with the absolute error less than the RVSM standard (Fig. 5), the AASAS on-board each aircraft will be, based on information exchanged, able to predict stable future four-dimensional traffic situation in the conflict detection zone around aircraft. In case of threatening conflict of separation loss the AASAS willaccurately define

**4. The infrastructure of autonomous flight** 

a. instantaneous flight parameters

b. flight plan – i.e. future intent

climb or descent,

c. real time data on static

dynamic

horizontal plane.

11.

11) are:

**Figure 9.** The primitive model error of relative position between aircraft in vertical direction (reduced vertical separation minimum is shown).

#### **3.3. Reliability of conflict detection**

The primitive model error of relative position between aircraft in vertical direction *<sup>Z</sup>* (24) will vary in a range of 10% of the RVSM standard for the conflict encounters up to 2000m (6500ft) below tropopause at moderate wind conditions (*w* = 26m/s (50kt)). However, after 5 minutes of descent and 3600m (12000ft) below tropopause, that is 70 km along the descent trajectory, the error of the primitive model will in vertical direction *<sup>Z</sup>*increase to 170% of the RVSM standard (Fig. 9).

The consequence is that, even before the relative horizontal distance error exceeds the horizontal separation minimum, the primitive model of relative motion becomes blind and unable to detect threatening conflict between aircraft. At the same time conflict alerts of the primitive model will be false resulting in the unnecessary conflict avoidance maneuvering which will actually be unsafe since it can lead into the undetectable conflict with yet another aircraft (domino effect).

The inability to detect loss of separation and erroneous conflict detection of the primitive model of aircraft relative flight (2) is addressed in Fig. 10. From (22) the minimal and maximal initial critical separations that will result in the loss of separation are determined and shown in Fig. 10. Clearly both, the area of undetected conflicts and the area of false conflict detection of the primitive model increase with increasing initial vertical separation between aircraft ( ) *Rz T/P* at the planned initiation of descent. Those areas increase exponentially for head-on encounters in windy conditions and if descending aircraft flies slower than the intruder. In case of moderate wind the sum of the area of false conflict detection and the area of undetected conflicts will increase to approximately 50% of the area of correct conflict detection in head-on encounter at initial vertical separation of 3000m (6500ft) if descending aircraft is 20% slower than intruder.

**Figure 10.** Inability of conflict detection and/or incorrect conflict detection of the primitive model in horizontal plane.

#### **4. The infrastructure of autonomous flight**

122 Advances in Air Navigation Services

vertical separation minimum is shown).

RVSM standard (Fig. 9).

aircraft (domino effect).

between aircraft ( ) *Rz*

(6500ft) if descending aircraft is 20% slower than intruder.

**3.3. Reliability of conflict detection** 

**Figure 9.** The primitive model error of relative position between aircraft in vertical direction (reduced

The primitive model error of relative position between aircraft in vertical direction

trajectory, the error of the primitive model will in vertical direction

will vary in a range of 10% of the RVSM standard for the conflict encounters up to 2000m (6500ft) below tropopause at moderate wind conditions (*w* = 26m/s (50kt)). However, after 5 minutes of descent and 3600m (12000ft) below tropopause, that is 70 km along the descent

The consequence is that, even before the relative horizontal distance error exceeds the horizontal separation minimum, the primitive model of relative motion becomes blind and unable to detect threatening conflict between aircraft. At the same time conflict alerts of the primitive model will be false resulting in the unnecessary conflict avoidance maneuvering which will actually be unsafe since it can lead into the undetectable conflict with yet another

The inability to detect loss of separation and erroneous conflict detection of the primitive model of aircraft relative flight (2) is addressed in Fig. 10. From (22) the minimal and maximal initial critical separations that will result in the loss of separation are determined and shown in Fig. 10. Clearly both, the area of undetected conflicts and the area of false conflict detection of the primitive model increase with increasing initial vertical separation

exponentially for head-on encounters in windy conditions and if descending aircraft flies slower than the intruder. In case of moderate wind the sum of the area of false conflict detection and the area of undetected conflicts will increase to approximately 50% of the area of correct conflict detection in head-on encounter at initial vertical separation of 3000m

*T/P* at the planned initiation of descent. Those areas increase

*<sup>Z</sup>* (24)

*<sup>Z</sup>*increase to 170% of the

For the AASAS on-board aircraft to be based on the improved model of the aircraft relative motion (3) numerous information ofeach aircraft flight in the conflict detection zone has to be exchanged via Automatic Dependence Surveillance–Broadcast (ADS–B) as shown in Fig 11.

According to the improved model of the aircraft relative motion (3) those information (Fig. 11) are:


Since the trajectory prediction error pattern of the improved model of aircraft relative motion is non-increasing and stable with the absolute error less than the RVSM standard (Fig. 5), the AASAS on-board each aircraft will be, based on information exchanged, able to predict stable future four-dimensional traffic situation in the conflict detection zone around aircraft. In case of threatening conflict of separation loss the AASAS willaccurately define

The Autonomous Flight 125

**Figure 12.** Proposed format of atmospheric conditions data available to each airborne aircraft.

**Figure 13.** The feasible radius of conflict detection zone of the improved model of aircraft relative

motion based ASAS.

**Figure 11.** Information exchange requirements of the improved model of flight based Airborne Separation Assurance System.

the safe parameters*I* and *<sup>P</sup>* of conflict avoidance maneuveringfor the execution by the FMS/ autopilot or crew.

Investigation of the relative distance between aircraft error of the improved model as well as its trajectory prediction error revealed (Fig. 5), that the temperature at the atmospheric reference level is the improved model of aircraft relative motion accuracy most critical parameter. The necessary data on atmospheric conditions defined by (3) and their proposed format for up-link to the aircraft are presented in Fig. 12 and obtainable by the Mode-S transponder (for example).

124 Advances in Air Navigation Services

Separation Assurance System.

*I* and 

the safe parameters

FMS/ autopilot or crew.

transponder (for example).

**Figure 11.** Information exchange requirements of the improved model of flight based Airborne

Investigation of the relative distance between aircraft error of the improved model as well as its trajectory prediction error revealed (Fig. 5), that the temperature at the atmospheric reference level is the improved model of aircraft relative motion accuracy most critical parameter. The necessary data on atmospheric conditions defined by (3) and their proposed format for up-link to the aircraft are presented in Fig. 12 and obtainable by the Mode-S

*<sup>P</sup>* of conflict avoidance maneuveringfor the execution by the

**Figure 12.** Proposed format of atmospheric conditions data available to each airborne aircraft.

**Figure 13.** The feasible radius of conflict detection zone of the improved model of aircraft relative motion based ASAS.

The quantum of necessary information which has to be continuously and uninterruptedly exchanged between each aircraft aloft within radius of conflict detection zone of each other and with the ground systems providing them atmospheric conditions data impose concerns about ADS–B ability to exchange all those information. However, based on the assumption that the complete uncompressed data necessary comprise 1150 bits (comparison [6]) of exchanged massage among 30 aircraft per 100×100nautical miles (0.000875 aircraft per square km (Eurocontrol Performance Review Report 1999-2010)) on each of 28 flight levels from FL410 to FL150 (exaggerated aircraft density), and Universal Access Transceiver with the bandwidth of 1Mbit/s [6] is used, then the conflict detection zone with radius of up to 370 km (200 nautical miles) can be realized with the complete information refresh rate of 4 seconds. Relationships described and influence of information refresh rate and the data exchange bandwidth on the feasible radius of conflict detection zone are presented in Fig. 13.

The Autonomous Flight 127

might be less than described in the paper if the real reference atmospheric temperature is

Plain proof is provided that the AFA and autonomous flight operations are feasible and basic–level AFA operational procedures are introduced. Crucial to the AFA introduction feasibility are technologies enabling: (a) sufficient bandwidth for reliable data–link communications, (b) capability to predict accurate and stable future 4D traffic situations with sufficient look–ahead time, (c) multi–factor analyses for real–time determination of safe transitioning trajectory including determination of the TOD, TC, and AA reception/dispatch zone collector airway selection, (d) adaptive airways structuring of AA, and (e) dynamic

*SLOVENIA CONTROL, Slovenian Air Navigation Services, Ltd, Ljubljana, Slovenia* 

The author is sincerely grateful to Cpt. Aleksander Sekirnik of Adria Airways for his

[1] ACARE: "The Challenge of Security", in Strategic Research Agenda 1, Vol. 2, Advisory

[2] Beers, C.,Huisman, H.: "Transitions between free flight and managed airspace", 4th

[3] Bilimoria, K., Lee, H.: "Performance of air Traffic Conflicts for Free and Structured Routing", AIAA Guidance, Navigation, and Control Conference, Paper No. 2001- 4051,

[4] Duong, V., *et al*, "Sector–Less Air Traffic Management," *5th USA/Europe ATM R&D* 

[5] Erzberger, H.: "The Automated Airspace Concept", 4th USA/Europe ATM R&D

[6] Hoekstra, J.M.: Designing for Safety – The Free Flight Air Traffic Management Concept,

[7] Kopardekar, P., Magyarits, S.: "Measurement and Prediction of Dynamic Density", 5th

[8] Magister, T.: "The problem of mini-unmanned aerial vehicle non-segregated flight

[9] Magister, T.: "Transition flight between the autonomous flight airspace and automated

Ph.D. thesis, Technische Universiteit, Delft, The Netherlands, 2001.

USA/Europe ATM R&D Seminar, Budapest, Hungary, 2003.

operations", *Traffic*, 2007, vol. 19, no. 6, pg. 381-386.

airspace", *Traffic*, 2008, vol. 20, no. 4, pg. 215-221.

provided to the AASAS on-board each aircraft.

Tone Magister and Franc Željko Županič

unselfish support, advice and help.

Montréal, Canada, 2001.

*Conf.*, Budapest, Hungary, 2003.

Seminar, Santa Fe, NM, USA, 2001.

Council For Aeronautics Research in Europe, 2002.

USA/Europe ATM R&D Seminar, Santa Fe, NM, USA, 2001.

airspace sectorization.

**Acknowledgement** 

**6. References** 

**Author details** 

#### **5. Conclusion**

Notwithstanding its many–sided complexity, the introduction of the AFA is inevitable, as ideas of unmanned cargo and passenger aircraft are emerging and the first UASs are already inexorably taken to the skies. The AFA technology development is applicable to the coming generation of aircraft and ATM systems with increasing automation anticipated to cope with increasing demand for airspace capacity.

Imminent increase in conflict encounter threatening aircraft transitioning to and from the AFA can be dispersed along the entire trajectory of aircraft with reduced severity of each remaining area of increase in conflicts with the introduction of descending or climbing transitions and AA reception/dispatch zone below the AFA where expected aircraft mix can be handled. The enabling technology is machine–based decision–making airborne AASAS and ground–based automation ASAS communicating by data–link. This AASAS should be capable of accurate conflict detection before descending aircraft exits the AFA or before ascending aircraft enters AFA. Otherwise the conflict encounters (loss of separation between aircraft) imminent in the AA Reception/Dispatch Zone of Fig. 1 are unavoidable.

The investigation of trajectory prediction error of a primitive model of aircraft relative motion clearly indicates the reason for the unstable prediction of future three-dimensional airborne traffic situation with existing (TCAS-like) technology and methodology. Furthermore, the conclusion can be drawn from the study that conflict detection and resolution is not safe and actually impossible for look-ahead time longer than 5 minutes in the airspace where aircraft are flying their trajectories in the vertical plane. Consequently, the primitive model of aircraft relative motion based airborne separation assurance cannot assure promptly and accurate conflict detection and therefore cannotfacilitate the AFA introduction.

The improved model of aircraft relative motion compared to its primitive pendant appears promising particularly because of the stability of its trajectory prediction error. This error might be less than described in the paper if the real reference atmospheric temperature is provided to the AASAS on-board each aircraft.

Plain proof is provided that the AFA and autonomous flight operations are feasible and basic–level AFA operational procedures are introduced. Crucial to the AFA introduction feasibility are technologies enabling: (a) sufficient bandwidth for reliable data–link communications, (b) capability to predict accurate and stable future 4D traffic situations with sufficient look–ahead time, (c) multi–factor analyses for real–time determination of safe transitioning trajectory including determination of the TOD, TC, and AA reception/dispatch zone collector airway selection, (d) adaptive airways structuring of AA, and (e) dynamic airspace sectorization.

#### **Author details**

126 Advances in Air Navigation Services

13.

**5. Conclusion** 

introduction.

with increasing demand for airspace capacity.

The quantum of necessary information which has to be continuously and uninterruptedly exchanged between each aircraft aloft within radius of conflict detection zone of each other and with the ground systems providing them atmospheric conditions data impose concerns about ADS–B ability to exchange all those information. However, based on the assumption that the complete uncompressed data necessary comprise 1150 bits (comparison [6]) of exchanged massage among 30 aircraft per 100×100nautical miles (0.000875 aircraft per square km (Eurocontrol Performance Review Report 1999-2010)) on each of 28 flight levels from FL410 to FL150 (exaggerated aircraft density), and Universal Access Transceiver with the bandwidth of 1Mbit/s [6] is used, then the conflict detection zone with radius of up to 370 km (200 nautical miles) can be realized with the complete information refresh rate of 4 seconds. Relationships described and influence of information refresh rate and the data exchange bandwidth on the feasible radius of conflict detection zone are presented in Fig.

Notwithstanding its many–sided complexity, the introduction of the AFA is inevitable, as ideas of unmanned cargo and passenger aircraft are emerging and the first UASs are already inexorably taken to the skies. The AFA technology development is applicable to the coming generation of aircraft and ATM systems with increasing automation anticipated to cope

Imminent increase in conflict encounter threatening aircraft transitioning to and from the AFA can be dispersed along the entire trajectory of aircraft with reduced severity of each remaining area of increase in conflicts with the introduction of descending or climbing transitions and AA reception/dispatch zone below the AFA where expected aircraft mix can be handled. The enabling technology is machine–based decision–making airborne AASAS and ground–based automation ASAS communicating by data–link. This AASAS should be capable of accurate conflict detection before descending aircraft exits the AFA or before ascending aircraft enters AFA. Otherwise the conflict encounters (loss of separation between

The investigation of trajectory prediction error of a primitive model of aircraft relative motion clearly indicates the reason for the unstable prediction of future three-dimensional airborne traffic situation with existing (TCAS-like) technology and methodology. Furthermore, the conclusion can be drawn from the study that conflict detection and resolution is not safe and actually impossible for look-ahead time longer than 5 minutes in the airspace where aircraft are flying their trajectories in the vertical plane. Consequently, the primitive model of aircraft relative motion based airborne separation assurance cannot assure promptly and accurate conflict detection and therefore cannotfacilitate the AFA

The improved model of aircraft relative motion compared to its primitive pendant appears promising particularly because of the stability of its trajectory prediction error. This error

aircraft) imminent in the AA Reception/Dispatch Zone of Fig. 1 are unavoidable.

Tone Magister and Franc Željko Županič *SLOVENIA CONTROL, Slovenian Air Navigation Services, Ltd, Ljubljana, Slovenia* 

#### **Acknowledgement**

The author is sincerely grateful to Cpt. Aleksander Sekirnik of Adria Airways for his unselfish support, advice and help.

#### **6. References**


#### 128 Advances in Air Navigation Services

[10] Magister, T.: "Long range aircraft trajectory prediction", *Traffic*, 2009, vol. 21, no. 5, pg. 311-318.

**Chapter 0**

**Chapter 8**

**How to Manage Failures in Air**

**Traffic Control Software Systems**

Luca Montanari, Roberto Baldoni, Fabrizio Morciano,

could end up in a failure and overcome such issues when they arise.

in the literature to implement these failure management systems:

Failure Management consists of a set of functions that enable the detection, isolation, and correction of anomalous behavior in a monitored system trying to prevent system failures. An effective failure management should monitor the system looking for errors and faults that

Air Traffic Control (ATC) systems are large and complex systems supervising the aircraft trajectories from departure to destination. Such systems have hard reliability and dependability requirements. Having an effective failure management in such kind of critical systems is a must for safety and security reasons. Two main approaches have been developed

Due to the complexity and the strong requirements, current ATC systems adopt both of them. The Reactive Fault Management is based on the detection paradigm. A reactive fault manager get triggered at the moment in which errors occur and should have the following capability: diagnosis, symptom monitoring, correlation, testing, automated recovery, notification, online system topology update. The Proactive Fault management scheme anticipates the formation of erroneous system states before it actually materializes into a failure. Known techniques in this field are rejuvenation of system components [24], checkpointing [4], prediction mechanisms [21]: to predict a failure occurrence and thus triggering the system state recovery. This chapter focus on failure management in ATC systems pointing out motivations that led engineers to do specific design choices. Two case studies as real implementations of the paradigms are also presented: a reactive approach deployed in a real ATC System and a novel proactive approach that has the distinctive features to be (i) *black-box*: no knowledge of applications' internals and logic of the mission critical distributed system is required (ii)

> ©2012 Baldoni et al., licensee InTech. This is an open access chapter distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly

©2012 Baldoni et al., licensee InTech. This is a paper distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Additional information is available at the end of the chapter

Marco Rizzuto and Francesca Matarese

http://dx.doi.org/10.5772/51119

• Reactive Fault Management; • Proactive Fault Management.

cited.

**1. Introduction**

[11] Mondolini, S., Liang, D.: "Airspace Fractal Dimensions and Applications", 3th USA/Europe ATM R&D Seminar, Napoli, Italy, 2000.

**Chapter 0 Chapter 8**

### **How to Manage Failures in Air Traffic Control Software Systems**

Luca Montanari, Roberto Baldoni, Fabrizio Morciano, Marco Rizzuto and Francesca Matarese

Additional information is available at the end of the chapter

http://dx.doi.org/10.5772/51119

#### **1. Introduction**

128 Advances in Air Navigation Services

311-318.

[10] Magister, T.: "Long range aircraft trajectory prediction", *Traffic*, 2009, vol. 21, no. 5, pg.

[11] Mondolini, S., Liang, D.: "Airspace Fractal Dimensions and Applications", 3th

USA/Europe ATM R&D Seminar, Napoli, Italy, 2000.

Failure Management consists of a set of functions that enable the detection, isolation, and correction of anomalous behavior in a monitored system trying to prevent system failures. An effective failure management should monitor the system looking for errors and faults that could end up in a failure and overcome such issues when they arise.

Air Traffic Control (ATC) systems are large and complex systems supervising the aircraft trajectories from departure to destination. Such systems have hard reliability and dependability requirements. Having an effective failure management in such kind of critical systems is a must for safety and security reasons. Two main approaches have been developed in the literature to implement these failure management systems:


Due to the complexity and the strong requirements, current ATC systems adopt both of them. The Reactive Fault Management is based on the detection paradigm. A reactive fault manager get triggered at the moment in which errors occur and should have the following capability: diagnosis, symptom monitoring, correlation, testing, automated recovery, notification, online system topology update. The Proactive Fault management scheme anticipates the formation of erroneous system states before it actually materializes into a failure. Known techniques in this field are rejuvenation of system components [24], checkpointing [4], prediction mechanisms [21]: to predict a failure occurrence and thus triggering the system state recovery.

This chapter focus on failure management in ATC systems pointing out motivations that led engineers to do specific design choices. Two case studies as real implementations of the paradigms are also presented: a reactive approach deployed in a real ATC System and a novel proactive approach that has the distinctive features to be (i) *black-box*: no knowledge of applications' internals and logic of the mission critical distributed system is required (ii)

*non-intrusive*: no status information of the nodes (e.g., CPU) is used; and (iii) *online*: the analysis is performed during the functioning of the monitored systems.

operational picture of the sky. A controller looks at this picture and, according to the adopted procedures, addresses the aircraft pilot in the safest way ensuring to select the most efficient

How to Manage Failures in Air Traffi c Control Software Systems 131

A very high level architecture of an ATCs is shown in Fig. 1. The Figure highlights the needs for an ATCs in term of hardware, software and human factors. The number of components involved can change depending on the vendor, size of the system and requirements from the customers, still to give a rough idea of the order of magnitude of the size of the system, an

ATCs does not require strict real-time time of responses (the separation criteria can be around seconds) but the availability of the system should be greater than 99,99%. An ATCs

The first class of faults implies failures related to delay in communications (inside and outside the system) and, human factor (wrong order). Faults related to the hardware are minimized by a proper configuration and tuning of the ATC system. In the worst case the entire ATC system can be replaced by a different one using a separate network and possibly employing different hardware and software components to exploit diversity argument (sometimes the

trajectory for reaching the final destination.

**Figure 1.** ATC Very High Level Architecture

ATC system is several million lines of code.

• discovering a fault in a predictable time;

architecture requires at least the following capabilities:

• maintaining the service or restore it in a predictable time.

previous version of the ATC system is used as fallback).

• sharing the same data among all the components forming the system;

According to the previous criteria we can identify some class of faults:

• misalignment in time (not all the system is aware of its processing capacity); • misalignment in data (not all the system shares the same information); • misalignment in functionalities (not all the capabilities are available).

The chapter is organized as follows: section 2 explains the motivations of failure management in ATC. Section 3 shows the role that faults and failures have in ATC systems and the relationship with safety regulation. Section 4 presents the objectives of failure management while section 5 investigates proactive, reactive approaches and we will introduce the online failure prediction technique. The sections 6 and 7 present the two case studies, one using a reactive approach and one that use a proactive approach. Section 8 concludes the chapter.

#### **2. Motivations**

Distributed mission critical systems such ATC, battlefield or naval command and control systems consist of several applications distributed over a number of nodes connected through a LAN or WAN. The applications are constructed out of communicating software components that are deployed on those nodes and may change over time. The dynamic nature of applications is mainly due to (i) adopted policies to cope with software or hardware failures, (ii) load balancing strategies and (iii) the management of new software components joining the system. Additionally such systems have to react to input in a soft real time way, i.e., an output has to be provided after a few seconds from the input the generated it. In such complex real time systems, failures may happen with potentially catastrophic consequences for their entire functioning. The industrial trend is to face failures by using appropriate software engineering techniques at the design phase. However these techniques cannot reduce to zero the probability of failures during the operational phase due to the unpredictability and uncertainty behind a distributed systems [7], thus there is the need of supervising services that are not only capable of detecting a failure, but also predicting and preventing it through an analysis of the overall system behavior.

The literature about failures and fault management embraces several aspects: reactive approaches, proactive approaches, fault detection, failure detection, faults and failure isolation, failure prediction. Before investigating some details of these techniques, it is important to point out some definitions that will be used along this chapter [11]:


A fault is *active* when it produces an error, it is *dormant* otherwise. The next section specializes the faults and failures in the ATC domain.

#### **3. Faults and failures in ATC systems and relationship with safety regulation 482/2008**

An ATC system is a large and complex system with several interrelated functions. It receives inputs from several heterogeneous actors like: messages from external lines (e.g. AFTN), radar information, radio communications with aircraft etc. All these information need to be integrated, processed, correlated and finally presented to an ATC system as a global operational picture of the sky. A controller looks at this picture and, according to the adopted procedures, addresses the aircraft pilot in the safest way ensuring to select the most efficient trajectory for reaching the final destination.

**Figure 1.** ATC Very High Level Architecture

2 Will-be-set-by-IN-TECH

*non-intrusive*: no status information of the nodes (e.g., CPU) is used; and (iii) *online*: the

The chapter is organized as follows: section 2 explains the motivations of failure management in ATC. Section 3 shows the role that faults and failures have in ATC systems and the relationship with safety regulation. Section 4 presents the objectives of failure management while section 5 investigates proactive, reactive approaches and we will introduce the online failure prediction technique. The sections 6 and 7 present the two case studies, one using a reactive approach and one that use a proactive approach. Section 8 concludes the chapter.

Distributed mission critical systems such ATC, battlefield or naval command and control systems consist of several applications distributed over a number of nodes connected through a LAN or WAN. The applications are constructed out of communicating software components that are deployed on those nodes and may change over time. The dynamic nature of applications is mainly due to (i) adopted policies to cope with software or hardware failures, (ii) load balancing strategies and (iii) the management of new software components joining the system. Additionally such systems have to react to input in a soft real time way, i.e., an output has to be provided after a few seconds from the input the generated it. In such complex real time systems, failures may happen with potentially catastrophic consequences for their entire functioning. The industrial trend is to face failures by using appropriate software engineering techniques at the design phase. However these techniques cannot reduce to zero the probability of failures during the operational phase due to the unpredictability and uncertainty behind a distributed systems [7], thus there is the need of supervising services that are not only capable of detecting a failure, but also predicting and preventing it through

The literature about failures and fault management embraces several aspects: reactive approaches, proactive approaches, fault detection, failure detection, faults and failure isolation, failure prediction. Before investigating some details of these techniques, it is

• A *failure* is an event that occurs when the delivered service deviates from correct service;

A fault is *active* when it produces an error, it is *dormant* otherwise. The next section specializes

An ATC system is a large and complex system with several interrelated functions. It receives inputs from several heterogeneous actors like: messages from external lines (e.g. AFTN), radar information, radio communications with aircraft etc. All these information need to be integrated, processed, correlated and finally presented to an ATC system as a global

**3. Faults and failures in ATC systems and relationship with safety**

important to point out some definitions that will be used along this chapter [11]:

• The *system behavior* is what the system does to implement its function;

• An *error* is a deviation in the sequence of the system's states.

analysis is performed during the functioning of the monitored systems.

**2. Motivations**

an analysis of the overall system behavior.

• A *fault* is the cause of an error.

**regulation 482/2008**

the faults and failures in the ATC domain.

A very high level architecture of an ATCs is shown in Fig. 1. The Figure highlights the needs for an ATCs in term of hardware, software and human factors. The number of components involved can change depending on the vendor, size of the system and requirements from the customers, still to give a rough idea of the order of magnitude of the size of the system, an ATC system is several million lines of code.

ATCs does not require strict real-time time of responses (the separation criteria can be around seconds) but the availability of the system should be greater than 99,99%. An ATCs architecture requires at least the following capabilities:


According to the previous criteria we can identify some class of faults:


The first class of faults implies failures related to delay in communications (inside and outside the system) and, human factor (wrong order). Faults related to the hardware are minimized by a proper configuration and tuning of the ATC system. In the worst case the entire ATC system can be replaced by a different one using a separate network and possibly employing different hardware and software components to exploit diversity argument (sometimes the previous version of the ATC system is used as fallback).

#### 4 Will-be-set-by-IN-TECH 132 Advances in Air Navigation Services How to Manage Failures in Air Traffic Control Software Systems <sup>5</sup>

The second class of faults implies failures related to the mismatch between the output of processing server in the system; part of the system could process data no longer relevant with respect to the real status of ATC system. This impacts ATC systems as they cannot rely anymore on the information provided by the system.

2. *Failure Isolation* is the determination of the exact location of a failure. 3. *Failure Identification* is the determination of the size of the failure.

**5. Failure management techniques - reactive and proactive**

to achieve it's main goals, it is necessary to have the following capabilities [10]:

can be an overkill and then sometime it is not implemented.

root causes after the manifestation of symptoms [23].

**5.1. Reactive approach**

tolerance logics (see section 6)

related each other.

cause a proper system failure.

value.

While detection and isolation are a must in any mission critical system, failure identification

How to Manage Failures in Air Traffi c Control Software Systems 133

The reactive approach in fault management is based on the detection paradigm. A reactive fault manager gets triggered at the moment in which errors occurs. More specifically, in order

• *Symptom monitoring*: Symptoms are manifestations of underlying faults and must be monitored to detect the occurrence of problems as soon as they happen. A fault manager quality is its response time to symptoms. The quicker this reaction occurs, the higher the probability to recover the system error is. This in turn raise the probability that the fault will not end up into a failure. In our case study the middleware platform used makes use of FT-CORBA (Fault tolerant CORBA) which rely on the fault detection to implement

• *Diagnosis*: identifies the root causes of "known" symptoms. A fault may originate on one component and then it could manifest on some other component. In large scale systems, there is no one-to-one mapping between faults, errors, failures. Studies on such systems have shown that typically up to 80% of the fault management effort is spent in identifying

• *Correlation*: a correlation capability provides knowledge about root causes of "known" symptoms to the diagnosis modules. Modern systems are often richly instrumented with a large number of sensors that provide large amounts of information in the form of messages and alarms. This flow of information cannot be handled by humans in real-time as a small number of roots causes results in a huge number of messages and alarms. Therefore it is necessary to provide them with concise and aggregate notifications of underlying root causes. Correlation is the process of recognizing and organizing groups of events that are

• *Testing*: in large software systems, it is impractical (and sometime impossible) to monitor every variable. Instead key observable variables are monitored to generate symptom events. Diagnostic inference typically identifies a set of suspected root causes. A test planning facility is needed to select additional variables to be examined to isolate the root causes. The fault management application then needs to request or run these tests, and utilizes their results to complete the diagnosis. A test, as originally defined in [22], can incorporate arbitrarily complex analysis and actions, as long as it returns a true or false

• *Automated recovery*: identifying and automating recovery procedures facilitate rapid response to problems and allow for growth in equipment, processes, and services, without increasing the supervisory burden on system operators. The automation in recovery decreases the response time to an error and thus decreasing the probability that it may

The third class of faults implies failures related to degraded system usability, part of the system cannot be used and its functionality cannot be accessed by ATC systems or software components.

Safety is an essential characteristic of AirTrafficManagement/ATC functional systems. It has a dominant impact upon operational effectiveness. ATM/ATC functional systems in now evolving in a continuously growing integrated environment including automation of operational functions, formerly performed through manual procedures and massive and systematic use of software. All this has a prominent impact for the achievement of safety [5]. Moreover, regulatory compliance has become a legal and necessary extension of business continuity with an increasingly complex set of laws and regulations relating to data integrity and availability. Ensuring the integrity and availability for ATC systems bring bad and good news on regulatory compliance. The bad news is the regulations do not provide a "blueprint" for protection. The good news is high availability and continuous availability protection strategies will help you meet these regulatory requirements, minimizing the risk that under-protected systems will create breaks in the "chain of data". It is important to note that compliance is a moving target; both government and industry leaders will continue to move toward more specific regulations and standards [12]. The issue of regulatory compliance has became more acute on 1st January 2009 when the Regulation (EC) 482/2008 "establishing a software safety assurance system to be implemented by air navigation service providers" went into effect [3]. Still, laws or regulations do not set a specific process or specific requirements for an ATC system, they just describe expected outcomes. The Software Fault Management System supports business continuity and Regulation (EC) 482/2008 compliance, by identifying a set of "risk-mitigation means", defined from the risk-mitigation strategy achieving a particular safety objective. Moreover, it provides:


#### **4. Failure management objectives**

The objective of the failure management can be broadly divided in *Failure Detection*, *Failure Isolation*, *Failure Identification*. Failure detection and isolation has become a critical issue in the operation of high-performance ships, submarines, airplanes, space vehicles, and structures, where safety, mission satisfaction, and significant material value are at stake. [8] presents a survey on the failure detection techniques introducing some basic definition:

1. *Failure Detection* is the task to produce an indication that something is going wrong, i.e. a failure is present in the system.


While detection and isolation are a must in any mission critical system, failure identification can be an overkill and then sometime it is not implemented.

#### **5. Failure management techniques - reactive and proactive**

#### **5.1. Reactive approach**

4 Will-be-set-by-IN-TECH

The second class of faults implies failures related to the mismatch between the output of processing server in the system; part of the system could process data no longer relevant with respect to the real status of ATC system. This impacts ATC systems as they cannot rely

The third class of faults implies failures related to degraded system usability, part of the system cannot be used and its functionality cannot be accessed by ATC systems or software

Safety is an essential characteristic of AirTrafficManagement/ATC functional systems. It has a dominant impact upon operational effectiveness. ATM/ATC functional systems in now evolving in a continuously growing integrated environment including automation of operational functions, formerly performed through manual procedures and massive and systematic use of software. All this has a prominent impact for the achievement of safety [5]. Moreover, regulatory compliance has become a legal and necessary extension of business continuity with an increasingly complex set of laws and regulations relating to data integrity and availability. Ensuring the integrity and availability for ATC systems bring bad and good news on regulatory compliance. The bad news is the regulations do not provide a "blueprint" for protection. The good news is high availability and continuous availability protection strategies will help you meet these regulatory requirements, minimizing the risk that under-protected systems will create breaks in the "chain of data". It is important to note that compliance is a moving target; both government and industry leaders will continue to move toward more specific regulations and standards [12]. The issue of regulatory compliance has became more acute on 1st January 2009 when the Regulation (EC) 482/2008 "establishing a software safety assurance system to be implemented by air navigation service providers" went into effect [3]. Still, laws or regulations do not set a specific process or specific requirements for an ATC system, they just describe expected outcomes. The Software Fault Management System supports business continuity and Regulation (EC) 482/2008 compliance, by identifying a set of "risk-mitigation means", defined from the risk-mitigation strategy

• "cutover or hot swapping", that is the approach of replacing European air traffic management network (EATMN) system components while the system is operational; • "software robustness", that is the robusteness of the software in the event of unexpected inputs, hardware faults and power supply interruptions, either in the computer system

• "overload tolerance", that is the tolerance of the system to, inputs occurring at a greater

The objective of the failure management can be broadly divided in *Failure Detection*, *Failure Isolation*, *Failure Identification*. Failure detection and isolation has become a critical issue in the operation of high-performance ships, submarines, airplanes, space vehicles, and structures, where safety, mission satisfaction, and significant material value are at stake. [8] presents a

1. *Failure Detection* is the task to produce an indication that something is going wrong, i.e. a

anymore on the information provided by the system.

achieving a particular safety objective. Moreover, it provides:

rate than expected during normal operation of the system.

survey on the failure detection techniques introducing some basic definition:

itself or in connected devices; and

**4. Failure management objectives**

failure is present in the system.

components.

The reactive approach in fault management is based on the detection paradigm. A reactive fault manager gets triggered at the moment in which errors occurs. More specifically, in order to achieve it's main goals, it is necessary to have the following capabilities [10]:


• *Notification*: system operators require notifications of all critical fault management activity, especially the identification of root causes, and causal explanations for alarms, tests, and repair actions in a manner that they can follow easily. Sometimes they need to distinguish between what is observed by system sensors versus what is inferred by the underlying fault management application.

of symptoms in ATC or, in general, in mission critical systems is *response-time*. The fault underlying this symptom might be a bad process priority management and consequent starvation of some other processes having lower priority. The key notion of failure prediction based on monitoring data is that faults like starvation in priority management can be detected by their side effects such as high response-time. These side-effects are called symptoms. Later on this chapter (section 7) we will show an architecture for online

How to Manage Failures in Air Traffi c Control Software Systems 135

• Error Detection: Once a fault manifests itself, it becomes an error. Errors and symptoms are different: symptoms are the observation of system state over time; a symptom is a behavior that deviates from the "normal" behavior. While error is something that actually goes wrong. The fault at this stage did not develop in service failure yet but it would possibly do it. What is the probability that this error ends up in a failure? for how long since the first occurrence this probability keeps high? Error detection approaches attempt to answer these questions. The error detection usually employs online failure predictors

"There shall be no single point of failure", this is one of the basic requirements for any ATC system. It drives alone many choices about the design, the used technologies, the verification strategies of a complex distributed system which has to provide a very high service availability : at least 99,99% i.e. downtime of about 5 minutes per month. The complexity of such systems is more and more stored in the software, which is error prone to problems injected at design or coding time as well as to unexpected scenarios due to runtime concurrency and other factors, like for example upgrading activities. Then software fault tolerance stands beside the traditional hardware based solutions and often replaces them, considering also that these systems are maintained and can evolve over a 25 years lifecycle: any chosen solution must support changes. In this context FT CORBA is widely used in ATC, but also in Naval Combat Management and other Command and Control systems. FT CORBA provides both replication and failure transparencies to the application and moreover

The FT CORBA specification defines an architecture and a framework for resilient, highly-available, distributed software systems suitable for a wide range of applications, from business enterprise applications to distributed, embedded, real-time applications. The basic concepts of FT CORBA are entity redundancy, fault detection and fault recovery; replicated entities are several instances of CORBA objects that implement a common interface and thus are referenced by an object group (Interoperable Object Group Reference, IOGR). IOGRs lifecycle and update are totally managed by the FT CORBA infrastructure; client applications are unaware of object replication and changes in the object group due to replica failure are transparent since their request are forwarded to the right replica. The infrastructure (see Fig. 2) provides means to monitor the replicated objects and to communicate the faults, as well as to notify the fault to other interested parties, which could contribute to recover the application. Beyond replication, object groups and complete transparency, FT CORBA relies

based on rules, data-mining approaches, pattern recognition, fault trees etc.

**6. Reactive approach case study: FT CORBA in a real ATC system**

failure prediction in ATC that uses symptoms monitoring.

it is standardized by the Object Management Group [18] [15].

**6.1. Motivation**

**6.2. Principle of FT CORBA**


#### **5.2. Proactive fault management**

Using reactive schemes there are limits to increasing mission critical systems availability. Failure management started looking at proactive approaches to overcome these limitations such as rejuvenation of system components [10]. This scheme anticipates the formation of erroneous system states before it actually materializes into a failure. The listed schemes to increase system availability can be a more effective idea if applied intelligently and preventively. The question remains: when we should apply check-pointing and rejuvenation techniques? To answer this question we need a way to tell if the current state of the system is going to evolve into a failure state. We can extend this concept to include parts or the entire history of the systems state transitions. So to answer the question of the ideal trigger timing for high availability schemes we need to develop a model of the system in question which allows us to derive optimized triggering times. To increase availability of a software system during runtime basically two main concepts are involved: The method to re-initiate the system or a component to a failure free state like rejuvenation and a prediction mechanism to predict a failure occurrence and thus trigger the system state recovery.

#### **5.3. Online failure prediction**

The problem of modeling a system had always the main objective of predicting its behavior. A significant body of work has been published in this area. As far as distributed systems is concerned, a recent work [20] introduces a taxonomy that structures the manifold of approaches. The more relevant approaches for the ATC purpose are the following ones:

• Symptoms Monitoring: Manifestation of faults is not necessary a clear situation rather than a more fuzzy one. It can influence the hosted system gradually in time and space. This type of symptoms is called service degradation. A prominent example for such types of symptoms in ATC or, in general, in mission critical systems is *response-time*. The fault underlying this symptom might be a bad process priority management and consequent starvation of some other processes having lower priority. The key notion of failure prediction based on monitoring data is that faults like starvation in priority management can be detected by their side effects such as high response-time. These side-effects are called symptoms. Later on this chapter (section 7) we will show an architecture for online failure prediction in ATC that uses symptoms monitoring.

• Error Detection: Once a fault manifests itself, it becomes an error. Errors and symptoms are different: symptoms are the observation of system state over time; a symptom is a behavior that deviates from the "normal" behavior. While error is something that actually goes wrong. The fault at this stage did not develop in service failure yet but it would possibly do it. What is the probability that this error ends up in a failure? for how long since the first occurrence this probability keeps high? Error detection approaches attempt to answer these questions. The error detection usually employs online failure predictors based on rules, data-mining approaches, pattern recognition, fault trees etc.

#### **6. Reactive approach case study: FT CORBA in a real ATC system**

#### **6.1. Motivation**

6 Will-be-set-by-IN-TECH

• *Notification*: system operators require notifications of all critical fault management activity, especially the identification of root causes, and causal explanations for alarms, tests, and repair actions in a manner that they can follow easily. Sometimes they need to distinguish between what is observed by system sensors versus what is inferred by the underlying

• *Postmortem*: information from diagnostic problem solving is fed back to the fault management system for historic record keeping in order providing enough data for offline failure analysis to discover some of the mappings between failures and their root cause. It is important to underline that this analysis is different than the offline analysis to discover failure patterns. Failure patterns and relationships between failures and the root cause are orthogonal concepts even if some relationships between failures and faults can form a failure pattern. That's because failures are not caused just by errors or faults but also by

• *Online system topology update*: in an ATC system the reactive fault manager should support expert systems for effective diagnosis of root causes of system errors and that the expert system uses a knowledge base to infer the right diagnosis. The knowledge base as a module can be replaced or connected to another knowledge base. Other components can be completely removed or added. All this dynamic changes need to be done at run-time. It may not be feasible indeed to take the fault management system off-line each time that

Using reactive schemes there are limits to increasing mission critical systems availability. Failure management started looking at proactive approaches to overcome these limitations such as rejuvenation of system components [10]. This scheme anticipates the formation of erroneous system states before it actually materializes into a failure. The listed schemes to increase system availability can be a more effective idea if applied intelligently and preventively. The question remains: when we should apply check-pointing and rejuvenation techniques? To answer this question we need a way to tell if the current state of the system is going to evolve into a failure state. We can extend this concept to include parts or the entire history of the systems state transitions. So to answer the question of the ideal trigger timing for high availability schemes we need to develop a model of the system in question which allows us to derive optimized triggering times. To increase availability of a software system during runtime basically two main concepts are involved: The method to re-initiate the system or a component to a failure free state like rejuvenation and a prediction mechanism to predict a

The problem of modeling a system had always the main objective of predicting its behavior. A significant body of work has been published in this area. As far as distributed systems is concerned, a recent work [20] introduces a taxonomy that structures the manifold of approaches. The more relevant approaches for the ATC purpose are the following ones:

• Symptoms Monitoring: Manifestation of faults is not necessary a clear situation rather than a more fuzzy one. It can influence the hosted system gradually in time and space. This type of symptoms is called service degradation. A prominent example for such types

fault management application.

system configurations and human interaction patterns.

failure occurrence and thus trigger the system state recovery.

there is a change in the system topology.

**5.2. Proactive fault management**

**5.3. Online failure prediction**

"There shall be no single point of failure", this is one of the basic requirements for any ATC system. It drives alone many choices about the design, the used technologies, the verification strategies of a complex distributed system which has to provide a very high service availability : at least 99,99% i.e. downtime of about 5 minutes per month. The complexity of such systems is more and more stored in the software, which is error prone to problems injected at design or coding time as well as to unexpected scenarios due to runtime concurrency and other factors, like for example upgrading activities. Then software fault tolerance stands beside the traditional hardware based solutions and often replaces them, considering also that these systems are maintained and can evolve over a 25 years lifecycle: any chosen solution must support changes. In this context FT CORBA is widely used in ATC, but also in Naval Combat Management and other Command and Control systems. FT CORBA provides both replication and failure transparencies to the application and moreover it is standardized by the Object Management Group [18] [15].

#### **6.2. Principle of FT CORBA**

The FT CORBA specification defines an architecture and a framework for resilient, highly-available, distributed software systems suitable for a wide range of applications, from business enterprise applications to distributed, embedded, real-time applications. The basic concepts of FT CORBA are entity redundancy, fault detection and fault recovery; replicated entities are several instances of CORBA objects that implement a common interface and thus are referenced by an object group (Interoperable Object Group Reference, IOGR). IOGRs lifecycle and update are totally managed by the FT CORBA infrastructure; client applications are unaware of object replication and changes in the object group due to replica failure are transparent since their request are forwarded to the right replica. The infrastructure (see Fig. 2) provides means to monitor the replicated objects and to communicate the faults, as well as to notify the fault to other interested parties, which could contribute to recover the application. Beyond replication, object groups and complete transparency, FT CORBA relies

#### 8 Will-be-set-by-IN-TECH 136 Advances in Air Navigation Services How to Manage Failures in Air Traffic Control Software Systems <sup>9</sup>

well with FT CORBA specification but put in evidence an operative need: in Operating Systems that manage the process as unit of memory space and failure (e.g. POSIX process in Linux/Unix), monitoring and recovery should be done at process level. Then CARDAMOM restricts FT CORBA entity redundancy by enforcing that within the same process all replicated components play the same role, that is all primaries or all backups. This need is also tackled by an extension of FT CORBA specification, the beta OMG specification "Lightweight Fault

A very important aspect of CARDAMOM is the fault detection; since the framework is tuned to react and recover from failures, namely a process crash, mechanisms are put in place to detect malfunctions like for example deadlocks or endless loops which do not lead necessarily to a crash. After the detection, most of the times the safest action to recover normal behavior is to stop or kill the faulty process in order to trigger a switch to a new replica. Normally fault detectors work with several patterns at the same time: they can use a pull model, e.g. "is alive" call, or push model, e.g. by handling OS signals to detect the death of processes or even

FT CORBA with warm-passive replication style fits well the need of statefull servers which must guarantee the processing of sequenced requests. However, an ATC system needs other components to be resilient to failures act as stateless components. Generally speaking, stateless components have to provide their services with high availability but do not need to check for "exactly once" semantics of client requests either to support the state transfer. In this case it is used the Load Balancing framework, specified at OMG by the Lightweight Load Balancing specification [16]. It reuses the object group definition of FT CORBA and allows to transparently redirect the client requests among a pool of server replicas according to predefined or user defined strategies, for example through random or round-robin policies. In this way two conflicting goals are achieved at the same time: distribute the computational

How to Manage Failures in Air Traffi c Control Software Systems 137

**-** 

Tolerance for Distributed RT Systems" [17].

be signaled by the application itself after a fatal error.

**Figure 3.** System decomposition in application, process, component, group and host.

**Figure 2.** FT CORBA framework

also on infrastructure-controlled consistency. Strong replica consistency is enforced in order to guaranty that the sequence of requests invoked on the object group passes unaltered across the fault of one or more replicas.

#### **6.3. Specialization of FT CORBA for safety critical systems: CARDAMOM use case**

In the following we are going to focus on the design choices made for a significant piece of a real ATC system, namely CARDAMOM [2], and that is implemented in a CORBA based middleware.

Among the different replication styles, CARDAMOM adopts the warm passive approach to replicate statefull servers: during normal operation, only one member of the object group, the primary replica, executes the methods invoked on the group. The backup replicas are warm because they receive the status updates at the end of each request from the primary; this way they are always ready to process the next request, in case the primary fails. The FT infrastructure is in charge of detecting such failure and of triggering the switch to a new primary. Transferring to the backup replicas the updated status and the list of processed request ids, it is guaranteed that requests are always served exactly once as long as there are available replicas.

The software architecture is based on CORBA Component Model (see Fig. 3) and then the natural unit of redundancy is a component of the CCM; This Component is a unit of design, development and deployment realized through a collection of CORBA Objects which define attributes and interfaces, called ports [14]. In this context, the exposed ports (facets) of the server components are defined as objects of FT CORBA groups. This approach suits

**Figure 3.** System decomposition in application, process, component, group and host.

8 Will-be-set-by-IN-TECH

)& !'\$

)& !'\$

)& &&!\$

&!\$, &!\$,

also on infrastructure-controlled consistency. Strong replica consistency is enforced in order to guaranty that the sequence of requests invoked on the object group passes unaltered across

**6.3. Specialization of FT CORBA for safety critical systems: CARDAMOM use**

In the following we are going to focus on the design choices made for a significant piece of a real ATC system, namely CARDAMOM [2], and that is implemented in a CORBA based

Among the different replication styles, CARDAMOM adopts the warm passive approach to replicate statefull servers: during normal operation, only one member of the object group, the primary replica, executes the methods invoked on the group. The backup replicas are warm because they receive the status updates at the end of each request from the primary; this way they are always ready to process the next request, in case the primary fails. The FT infrastructure is in charge of detecting such failure and of triggering the switch to a new primary. Transferring to the backup replicas the updated status and the list of processed request ids, it is guaranteed that requests are always served exactly once as long as there

The software architecture is based on CORBA Component Model (see Fig. 3) and then the natural unit of redundancy is a component of the CCM; This Component is a unit of design, development and deployment realized through a collection of CORBA Objects which define attributes and interfaces, called ports [14]. In this context, the exposed ports (facets) of the server components are defined as objects of FT CORBA groups. This approach suits

!%&6

\$\*\$ "

!''! %

""'!

)& &&!\$

)& &&!\$

)&\$"!\$&% %1\*23 %1\*23

!%&7

)& &&!\$

\$\*\$ "

"'!

2&\$!)"

"'!

2&\$!)"

 & -

&

**Figure 2.** FT CORBA framework

the fault of one or more replicas.

**case**

middleware.

are available replicas.

\$#)%&

\$

\$3

\$

\$&1!&23 \*!,-

!%&5

\$&1!&23

\$3

well with FT CORBA specification but put in evidence an operative need: in Operating Systems that manage the process as unit of memory space and failure (e.g. POSIX process in Linux/Unix), monitoring and recovery should be done at process level. Then CARDAMOM restricts FT CORBA entity redundancy by enforcing that within the same process all replicated components play the same role, that is all primaries or all backups. This need is also tackled by an extension of FT CORBA specification, the beta OMG specification "Lightweight Fault Tolerance for Distributed RT Systems" [17].

A very important aspect of CARDAMOM is the fault detection; since the framework is tuned to react and recover from failures, namely a process crash, mechanisms are put in place to detect malfunctions like for example deadlocks or endless loops which do not lead necessarily to a crash. After the detection, most of the times the safest action to recover normal behavior is to stop or kill the faulty process in order to trigger a switch to a new replica. Normally fault detectors work with several patterns at the same time: they can use a pull model, e.g. "is alive" call, or push model, e.g. by handling OS signals to detect the death of processes or even be signaled by the application itself after a fatal error.

FT CORBA with warm-passive replication style fits well the need of statefull servers which must guarantee the processing of sequenced requests. However, an ATC system needs other components to be resilient to failures act as stateless components. Generally speaking, stateless components have to provide their services with high availability but do not need to check for "exactly once" semantics of client requests either to support the state transfer. In this case it is used the Load Balancing framework, specified at OMG by the Lightweight Load Balancing specification [16]. It reuses the object group definition of FT CORBA and allows to transparently redirect the client requests among a pool of server replicas according to predefined or user defined strategies, for example through random or round-robin policies. In this way two conflicting goals are achieved at the same time: distribute the computational

#### 10 Will-be-set-by-IN-TECH 138 Advances in Air Navigation Services How to Manage Failures in Air Traffic Control Software Systems <sup>11</sup>

load among several resources and supporting fault tolerance. because fault detectors are used to update the object group in case of failure and activate recovery mechanism. An additional and important feature is also to prevent that several replicas may crash because of the same implementation: by means of fine request identification, the framework allows to stop those requests that have caused failures, thus avoiding repetitive crashes which would result in a complete system failure.

!%&

 \$ &

**Figure 5.** 3-tier architecture.

be themselves fault tolerant.

stress conditions.

**7.1. Failure and prediction model**

**7. Failure prediction case study: CASPER**

 +\$ )& !\$

\$\$, &&) \$\*\$ "

&&%% \$\*\$ "

How to Manage Failures in Air Traffi c Control Software Systems 139

&\$&\$ &\$

 +\$ ! 

 +\$ & %&\$)'!

the kind of failure. As final consideration it is very important to underline that the design and implementation of the middleware services that provide this fault tolerant framework have to

In this section we introduce the design, implementation and experimental evaluation of a novel online, non-intrusive and black-box failure prediction architecture we named CASPER that can be used for monitoring mission critical distributed systems. CASPER is (i) *online*, as the failure prediction is carried out during the normal functioning of the monitored system, (ii) *non-intrusive*, as the failure prediction does not use any kind of information on the status of the nodes (e.g., CPU, memory) of the monitored system; only information concerning the network to which the nodes are connected is exploited as well as that regarding the specific network protocol used by the system to exchange information among the nodes (e.g., SOAP, GIOP); and (iii) *black-box*, as no knowledge of the application's internals and of the application logic of the system is analyzed. Specifically, the aim of CASPER is to recognize any deviation from normal behaviors of the monitored system by analyzing symptoms of failures that might occur in the form of anomalous conditions of specific performance metrics. In doing so, CASPER combines in a novel fashion Complex Event Processing (CEP) [13] and Hidden Markov Models (HMM) [19]. The CEP engine computes at run time the performance metrics. These are then passed to the HMM in order to recognize symptoms of an upcoming failure. Finally, the symptoms are evaluated by a failure prediction module that filters out as many false positives as possible and provides at the same time a failure prediction as early as possible. We deployed CASPER for monitoring a real ATC system. Using the network data of such a system in the presence of both steady state performance behaviors and unstable state behaviors, we first trained CASPER in order to stabilize HMM and tune the failure prediction module. Then we conducted an experimental evaluation of CASPER that aimed to show its effectiveness in timely predicting failures in the presence of memory and I/O

We model the distributed system to be monitored as a set of nodes that run one or more services. Nodes exchange messages over a communication network. Nodes or services can be

Middleware CARDAMOM provides all the previously mentioned services (see Fig. 4): in fact it has been chosen as the foundation for a safety critical subsystem, the core part of a next generation ATC system.

#### **Figure 4.** CCM and CORBA based middleware services.

In order to separate duties and define a clearly decoupled architecture that could support extensibility and maintainability, a three tier model has been put in place for the building blocks of the ATC system using CARDAMOM services. The first tier provides the interface to the external clients and guaranties the ordered processing of requests; it is realized by statefull components replicated with FT CORBA and warm passive replication style. The second tier executes the business logic; it is realized by stateless components replicated with LwLB supporting fault containment for killer requests; the third tier tackles the data management and persistency.

This architecture (see Fig. 5) is proven to be, at the same time, resilient to failures and highly scalable in terms of computational power, thus responding to the opposite requirements coming from availability, safety and performances. The use of FT and LB CORBA services is strongly interrelated also with System Management services, that are informed of replica crashes by the Fault Notifier. Automatic actions are put in place in order to stop or restart the replicas and contribute to the overall system availability; actions like restart and stop can be defined with different level of granularity, that is for process, application or host according to

**Figure 5.** 3-tier architecture.

10 Will-be-set-by-IN-TECH

load among several resources and supporting fault tolerance. because fault detectors are used to update the object group in case of failure and activate recovery mechanism. An additional and important feature is also to prevent that several replicas may crash because of the same implementation: by means of fine request identification, the framework allows to stop those requests that have caused failures, thus avoiding repetitive crashes which would result in a

Middleware CARDAMOM provides all the previously mentioned services (see Fig. 4): in fact it has been chosen as the foundation for a safety critical subsystem, the core part of a next

)\$\*%

In order to separate duties and define a clearly decoupled architecture that could support extensibility and maintainability, a three tier model has been put in place for the building blocks of the ATC system using CARDAMOM services. The first tier provides the interface to the external clients and guaranties the ordered processing of requests; it is realized by statefull components replicated with FT CORBA and warm passive replication style. The second tier executes the business logic; it is realized by stateless components replicated with LwLB supporting fault containment for killer requests; the third tier tackles the data management

This architecture (see Fig. 5) is proven to be, at the same time, resilient to failures and highly scalable in terms of computational power, thus responding to the opposite requirements coming from availability, safety and performances. The use of FT and LB CORBA services is strongly interrelated also with System Management services, that are informed of replica crashes by the Fault Notifier. Automatic actions are put in place in order to stop or restart the replicas and contribute to the overall system availability; actions like restart and stop can be defined with different level of granularity, that is for process, application or host according to

! )% %% !

%&\$'! ,\$%


)""!\$&&!!% )% %%

complete system failure.

generation ATC system.

and persistency.

\$!4 ! )\$'!

**Figure 4.** CCM and CORBA based middleware services.

the kind of failure. As final consideration it is very important to underline that the design and implementation of the middleware services that provide this fault tolerant framework have to be themselves fault tolerant.

#### **7. Failure prediction case study: CASPER**

In this section we introduce the design, implementation and experimental evaluation of a novel online, non-intrusive and black-box failure prediction architecture we named CASPER that can be used for monitoring mission critical distributed systems. CASPER is (i) *online*, as the failure prediction is carried out during the normal functioning of the monitored system, (ii) *non-intrusive*, as the failure prediction does not use any kind of information on the status of the nodes (e.g., CPU, memory) of the monitored system; only information concerning the network to which the nodes are connected is exploited as well as that regarding the specific network protocol used by the system to exchange information among the nodes (e.g., SOAP, GIOP); and (iii) *black-box*, as no knowledge of the application's internals and of the application logic of the system is analyzed. Specifically, the aim of CASPER is to recognize any deviation from normal behaviors of the monitored system by analyzing symptoms of failures that might occur in the form of anomalous conditions of specific performance metrics. In doing so, CASPER combines in a novel fashion Complex Event Processing (CEP) [13] and Hidden Markov Models (HMM) [19]. The CEP engine computes at run time the performance metrics. These are then passed to the HMM in order to recognize symptoms of an upcoming failure. Finally, the symptoms are evaluated by a failure prediction module that filters out as many false positives as possible and provides at the same time a failure prediction as early as possible. We deployed CASPER for monitoring a real ATC system. Using the network data of such a system in the presence of both steady state performance behaviors and unstable state behaviors, we first trained CASPER in order to stabilize HMM and tune the failure prediction module. Then we conducted an experimental evaluation of CASPER that aimed to show its effectiveness in timely predicting failures in the presence of memory and I/O stress conditions.

#### **7.1. Failure and prediction model**

We model the distributed system to be monitored as a set of nodes that run one or more services. Nodes exchange messages over a communication network. Nodes or services can be

CASPER Symptoms Detection

Performance Metrics Computation

Inference Pre-Processing

Monitored System

**Figure 7.** The modules of the CASPER failure prediction architecture

*computation* component and a *system state inference* component.

Host 3

Network Packets

Host 2

the state of the system during the clock period.

faults, and then symptoms of faults, are present.

Host 1 System State

Knowledge Base

Actions

Prediction

Inferred System State

How to Manage Failures in Air Traffi c Control Software Systems 141

Events Symbols Failure

N Prediction

Host N

state that must be evaluated in order to detect whether it is a safe or unsafe state. To this end, we divided this module into two different components, namely a *performance metrics*

*The performance metrics computation component* uses a CEP engine for correlation and aggregation purposes. It then periodically produces as output a representation of the system behavior in the form of *symbols*. Note that, CASPER requires a *clock mechanism* in order to carry out this activity at each *CASPER clock cycle*. The clock in CASPER allows it to model the system state using a discrete time Markov chain and let the performance metrics computation component coordinate with the system state inference one (see below). The representation of the system behavior at run time is obtained by computing *performance metrics*, i.e., a set of time-changing metrics whose value indicates how the system actually works (an example of network performance metric can be the round trip time). In CASPER we denote symbols as *σ<sup>m</sup>* (see Figure 8), where *m* = 1, . . . , *M*. Each symbol is built by the CEP engine starting from a vector of performance metrics: assuming *P* performance metrics, at the end of the time interval (i.e. the clock period), the CEP engine produces a symbol combining the *P* values. The combination of performance metrics is the result of a discretization and a normalization: each continuous variable is discretized into slots of equal lengths. The produced symbol represents

*The system state inference component* receives a symbol from the previous component at each CASPER clock cycle and recognizes whether it is a correct or an incorrect behavior of the monitored system. To this end, the component uses the Hidden Markov Models' forward probability [19] to compute the probability that the model is in a given state using a sequence of emitted symbols and a knowledge base(see Figure 7). We model the system state to be monitored by means of the *hidden process*. We define the states of the system (see Figure 8) as *Safe*, i.e., the system behavior is correct as no active fault [11] is present; and *Unsafe*, i.e., some

**Failure Prediction module** It is mainly responsible for correlating the information about the state received from the system state inference component of the previous CASPER module. It takes in input the inferred state of the system at each CASPER clock-cycle. The inferred state

Communication Network

**Figure 6.** Fault, Symptoms, Failure and Prediction

subject to failures. A failure is an event for which the service delivered by a system deviates from its specification [11]. A failure is always preceded by a fault (e.g., I/O error, memory misusage); however, the vice versa might not be always true. i.e., a fault inside a system could not always bring to a failure as the system could tolerate, for example by design, such fault.

Faults that lead to failures, independently of the fault's root cause, affect the system in an observable and identifiable way. Thus, faults can generate side-effects in the monitored systems till the failure occurs. Our work is based on the assumptions that a fault generates increasingly unstable performance-related symptoms indicating a possible future presence of a failure, and that the system exhibits a steady-state performance behavior with a few variations when a non-faulty situation is observed [25]. In Figure 6 we define *Time-to-failure* the distance in time between the occurrence of the prediction and the software failure event. The prediction has to be raised before a time *Limit*, beyond which the prediction is not sufficiently in advance to take some effective actions before the failure occurs. We also consider the *time-to-prediction* which represents the distance between the occurrence of the first symptom of the failure and the prediction.

#### **7.2. CASPER architecture**

The architecture designed is named CASPER and is deployed in the same subnetwork as the distributed system to be monitored. Figure 7 shows the principal modules of CASPER that are described in isolation as follows.

**Pre-Processing module.** It is mainly responsible for capturing and decoding network data required to recognize symptoms of failures and for producing streams of events. The network data the Pre-Processing module receives as input are properly manipulated. Data manipulation consists in firstly decoding data included in the headers of network packets. The module manages TCP/UDP headers and the headers of the specific inter-process communication protocol used in the monitored system (e.g., SOAP, GIOP, etc) so as to extract from them only the information that is relevant in the detection of specific symptoms (e,g., the timestamp of a request and reply, destination and source IP addresses of two communicating nodes). Finally, the Pre-Processing module adapts the extracted network information in the form of *events* to produce streams for the use by the second CASPER's module (see below).

**Symptoms detection module.** The streams of events are taken as input by the Symptoms detection module and used to discover specific performance patterns through complex event processing (i.e., event correlations and aggregations). The result of this processing is a system

**Figure 7.** The modules of the CASPER failure prediction architecture

12 Will-be-set-by-IN-TECH

Prediction Limit

subject to failures. A failure is an event for which the service delivered by a system deviates from its specification [11]. A failure is always preceded by a fault (e.g., I/O error, memory misusage); however, the vice versa might not be always true. i.e., a fault inside a system could not always bring to a failure as the system could tolerate, for example by design, such fault. Faults that lead to failures, independently of the fault's root cause, affect the system in an observable and identifiable way. Thus, faults can generate side-effects in the monitored systems till the failure occurs. Our work is based on the assumptions that a fault generates increasingly unstable performance-related symptoms indicating a possible future presence of a failure, and that the system exhibits a steady-state performance behavior with a few variations when a non-faulty situation is observed [25]. In Figure 6 we define *Time-to-failure* the distance in time between the occurrence of the prediction and the software failure event. The prediction has to be raised before a time *Limit*, beyond which the prediction is not sufficiently in advance to take some effective actions before the failure occurs. We also consider the *time-to-prediction* which represents the distance between the occurrence of the

The architecture designed is named CASPER and is deployed in the same subnetwork as the distributed system to be monitored. Figure 7 shows the principal modules of CASPER that

**Pre-Processing module.** It is mainly responsible for capturing and decoding network data required to recognize symptoms of failures and for producing streams of events. The network data the Pre-Processing module receives as input are properly manipulated. Data manipulation consists in firstly decoding data included in the headers of network packets. The module manages TCP/UDP headers and the headers of the specific inter-process communication protocol used in the monitored system (e.g., SOAP, GIOP, etc) so as to extract from them only the information that is relevant in the detection of specific symptoms (e,g., the timestamp of a request and reply, destination and source IP addresses of two communicating nodes). Finally, the Pre-Processing module adapts the extracted network information in the form of *events* to produce streams for the use by the second CASPER's module (see below). **Symptoms detection module.** The streams of events are taken as input by the Symptoms detection module and used to discover specific performance patterns through complex event processing (i.e., event correlations and aggregations). The result of this processing is a system

time-to-prediction time-to-failure

Symptom

Fault

**Figure 6.** Fault, Symptoms, Failure and Prediction

first symptom of the failure and the prediction.

**7.2. CASPER architecture**

are described in isolation as follows.

Time

Failure

state that must be evaluated in order to detect whether it is a safe or unsafe state. To this end, we divided this module into two different components, namely a *performance metrics computation* component and a *system state inference* component.

*The performance metrics computation component* uses a CEP engine for correlation and aggregation purposes. It then periodically produces as output a representation of the system behavior in the form of *symbols*. Note that, CASPER requires a *clock mechanism* in order to carry out this activity at each *CASPER clock cycle*. The clock in CASPER allows it to model the system state using a discrete time Markov chain and let the performance metrics computation component coordinate with the system state inference one (see below). The representation of the system behavior at run time is obtained by computing *performance metrics*, i.e., a set of time-changing metrics whose value indicates how the system actually works (an example of network performance metric can be the round trip time). In CASPER we denote symbols as *σ<sup>m</sup>* (see Figure 8), where *m* = 1, . . . , *M*. Each symbol is built by the CEP engine starting from a vector of performance metrics: assuming *P* performance metrics, at the end of the time interval (i.e. the clock period), the CEP engine produces a symbol combining the *P* values. The combination of performance metrics is the result of a discretization and a normalization: each continuous variable is discretized into slots of equal lengths. The produced symbol represents the state of the system during the clock period.

*The system state inference component* receives a symbol from the previous component at each CASPER clock cycle and recognizes whether it is a correct or an incorrect behavior of the monitored system. To this end, the component uses the Hidden Markov Models' forward probability [19] to compute the probability that the model is in a given state using a sequence of emitted symbols and a knowledge base(see Figure 7). We model the system state to be monitored by means of the *hidden process*. We define the states of the system (see Figure 8) as *Safe*, i.e., the system behavior is correct as no active fault [11] is present; and *Unsafe*, i.e., some faults, and then symptoms of faults, are present.

**Failure Prediction module** It is mainly responsible for correlating the information about the state received from the system state inference component of the previous CASPER module. It takes in input the inferred state of the system at each CASPER clock-cycle. The inferred state

#### 14 Will-be-set-by-IN-TECH 142 Advances in Air Navigation Services How to Manage Failures in Air Traffic Control Software Systems <sup>15</sup>

chooses the best values for both clock period and number of symbols, leaving to the operator the responsibility to select the windows size according to the criticality of the system to be

How to Manage Failures in Air Traffi c Control Software Systems 143

CASPER has been tested on the same real ATC system used in the reactive approach case study (section 6). CASPER intercepts GIOP messages produced by the CORBA middleware and extracts several information from them in order to build the representation of the system at run time. In this section we describe how the events are represented starting from the GIOP messages and how the performance metrics representing the system state are computed.

**Event representation.** Each GIOP message intercepted by CASPER becomes an event feeding the CEP engine of the performance metrics computation component. Each event contains (i)*Request ID*: The identifier of a request-reply interaction between two CORBA entities; (ii)*Message Type*: A field that characterizes the message and that can assume different values (e.g., Request, Reply, Close Connection) and (iii)*Reply Status*: It specifies whether there were exceptions during the request-reply interaction and, if so, the kind of the exception. In addition, we insert into the event further information related to the lower level protocols (TCP/UDP) such as source and destination IP, port, and timestamp. In order not to capture sensitive information of the ATC system (such as flight plans or routes), CASPER ignores the

**Performance metrics.** Events sent to the CEP engine are correlated online so as to produce so-called performance metrics. After long time of observations of several metrics of the ATC CORBA-based system, we identified the following small set of metrics that well characterize the system, showing a steady behavior in case of absence of faults, and an unstable behavior

• *Rate of the messages carrying an exception:* the number of reply messages with exception over

• *Average message size:* the mean of the messages size in a given spatial or temporal window; • *Percentage of Replies:* the number of replies over the number of requests in a given spatial

• *Number of Requests without Reply:* the number of requests expecting a reply that, in a given

• *Messages Rate:* the number of messages exchanged in a given spatial or temporal window.

To compute the performance metrics we correlate the sniffed network data using the CEP engine ESPER [6]. This choice is motivated by its low cost of ownership compared to other

The first part of the evaluation on the field has been to collect a large amount of network traces from the ATC underlying communication network when in operation. These traces represented steady state performance behaviors. Additionally, on the testing environment of

• *Round Trip Time:* elapsed time between a request and the relative reply;

**7.3. Monitoring a real ATC system with CASPER**

monitored.

payload of the messages.

in presence of faults:

the number of caught messages;

temporal window, do not receive the reply;

similar systems (e.g. [9]) and its offered usability.

**7.4. CASPER experimental evaluation**

or temporal window;

**Figure 8.** Hidden Markov Models graph used in the system state inference component

can be a safe state or one of the possible unsafe states. Using the CEP engine, this module counts the number of consecutive *unsafe* states and produces a failure prediction alert when that number reaches a tunable threshold (see below). We call this threshold *window size*, a parameter that is strictly related to the *time-to-prediction* shown in Figure 6.

#### *7.2.1. Training of CASPER*

The knowledge base concerning the possible safe and unsafe system states of the monitored system is composed by the parameters of the HMM. This knowledge is built during an initial training phase. Specifically, the parameters are adjusted by means of a training phase using the max likelihood state estimators of the HMM [19]. During the training, CASPER is fed concurrently by both recorded network traces and a sequence of pairs <system-state,time>. Each pair represents the fact that at time <time> the system state changed in <system-state>1.

#### *7.2.2. Tuning of CASPER parameters*

CASPER architecture has three parameters to be tuned whose values influence the quality of the whole failure prediction mechanism in terms of false positives and time-to-prediction. These values are (i) the length of the CASPER *clock period*; (ii) the *number of symbols* output by the performance metrics computation module; (iii) the length of the failure prediction, i.e., *window size*.

The length of the clock period influences the performance metrics computation and the system state inference: the shorter the clock period is, the higher the frequency of produced symbols is. A longer clock period allows CASPER to minimize the effects of outliers. The number of symbols influences the system state inference: if a high number of symbols is chosen, a higher precision for each performance metrics can be obtained. The failure prediction window size corresponds to the minimum number of CASPER clock cycles required for raising a prediction alert. The greater the window size, the more the accuracy of the prediction, i.e., the probability that the prediction actually is followed by a failure (i.e. a true positive prediction). The tradeoff is that the time-to-prediction increases linearly with the windows size causing shorter time-to-failure (see Figure 6); During the training phase, CASPER automatically

<sup>1</sup> As the training is offline, the sequence of pairs <system-state,time> can be created offline by the operator using network traces and system log files.

chooses the best values for both clock period and number of symbols, leaving to the operator the responsibility to select the windows size according to the criticality of the system to be monitored.

#### **7.3. Monitoring a real ATC system with CASPER**

14 Will-be-set-by-IN-TECH

σ<sup>1</sup> σ<sup>2</sup> σ<sup>3</sup> σ<sup>M</sup>

0.2 0.6 0.4 0.2 0.9 0.2 0.7

can be a safe state or one of the possible unsafe states. Using the CEP engine, this module counts the number of consecutive *unsafe* states and produces a failure prediction alert when that number reaches a tunable threshold (see below). We call this threshold *window size*, a

The knowledge base concerning the possible safe and unsafe system states of the monitored system is composed by the parameters of the HMM. This knowledge is built during an initial training phase. Specifically, the parameters are adjusted by means of a training phase using the max likelihood state estimators of the HMM [19]. During the training, CASPER is fed concurrently by both recorded network traces and a sequence of pairs <system-state,time>. Each pair represents the fact that at time <time> the system state

CASPER architecture has three parameters to be tuned whose values influence the quality of the whole failure prediction mechanism in terms of false positives and time-to-prediction. These values are (i) the length of the CASPER *clock period*; (ii) the *number of symbols* output by the performance metrics computation module; (iii) the length of the failure prediction, i.e.,

The length of the clock period influences the performance metrics computation and the system state inference: the shorter the clock period is, the higher the frequency of produced symbols is. A longer clock period allows CASPER to minimize the effects of outliers. The number of symbols influences the system state inference: if a high number of symbols is chosen, a higher precision for each performance metrics can be obtained. The failure prediction window size corresponds to the minimum number of CASPER clock cycles required for raising a prediction alert. The greater the window size, the more the accuracy of the prediction, i.e., the probability that the prediction actually is followed by a failure (i.e. a true positive prediction). The tradeoff is that the time-to-prediction increases linearly with the windows size causing shorter time-to-failure (see Figure 6); During the training phase, CASPER automatically

<sup>1</sup> As the training is offline, the sequence of pairs <system-state,time> can be created offline by the operator using

Unsafe2 UnsafeK

Hidden Process

Symbols

Safe Unsafe1

**Figure 8.** Hidden Markov Models graph used in the system state inference component

parameter that is strictly related to the *time-to-prediction* shown in Figure 6.

0.3

0.8

*7.2.1. Training of CASPER*

changed in <system-state>1.

*7.2.2. Tuning of CASPER parameters*

network traces and system log files.

*window size*.

CASPER has been tested on the same real ATC system used in the reactive approach case study (section 6). CASPER intercepts GIOP messages produced by the CORBA middleware and extracts several information from them in order to build the representation of the system at run time. In this section we describe how the events are represented starting from the GIOP messages and how the performance metrics representing the system state are computed.

**Event representation.** Each GIOP message intercepted by CASPER becomes an event feeding the CEP engine of the performance metrics computation component. Each event contains (i)*Request ID*: The identifier of a request-reply interaction between two CORBA entities; (ii)*Message Type*: A field that characterizes the message and that can assume different values (e.g., Request, Reply, Close Connection) and (iii)*Reply Status*: It specifies whether there were exceptions during the request-reply interaction and, if so, the kind of the exception. In addition, we insert into the event further information related to the lower level protocols (TCP/UDP) such as source and destination IP, port, and timestamp. In order not to capture sensitive information of the ATC system (such as flight plans or routes), CASPER ignores the payload of the messages.

**Performance metrics.** Events sent to the CEP engine are correlated online so as to produce so-called performance metrics. After long time of observations of several metrics of the ATC CORBA-based system, we identified the following small set of metrics that well characterize the system, showing a steady behavior in case of absence of faults, and an unstable behavior in presence of faults:


To compute the performance metrics we correlate the sniffed network data using the CEP engine ESPER [6]. This choice is motivated by its low cost of ownership compared to other similar systems (e.g. [9]) and its offered usability.

#### **7.4. CASPER experimental evaluation**

The first part of the evaluation on the field has been to collect a large amount of network traces from the ATC underlying communication network when in operation. These traces represented steady state performance behaviors. Additionally, on the testing environment of the ATC system we stressed some of the nodes till achieving software failure conditions, and we collected the relative traces. In our test field, we consider one of the nodes of the ATC system to be affected by either Memory or I/O stress (according to the experience of the ATC designers, these two stress conditions are typical of the observed system). After collecting all these traces, we trained CASPER. At end of the training phase, we deployed CASPER again on the testing environment of the ATC system in order to conduct experiments in operative conditions. Our evaluation assesses the system state inference component accuracy and the failure prediction module accuracy (see Figure 7). In particular, we evaluate the former in terms of *Ntp* (number of true positives) the system state is unsafe and the inferred state is "system unsafe"; *Ntn* (number of true negatives): the system state is safe and the inferred state is "system safe"; *Nf p* (number of false positive): the system state is safe but the inferred state is "system unsafe"; and *Nf n* (number of false negatives): the system state is unsafe but the inferred state is "system safe". Using these parameters, we compute the following metrics that define the accuracy of CASPER:

carried out 10 tests for each type of fault. In general, we obtained that in the 10 tests we carried out, the time-to-failure in case of memory stress varied in the range of [183s, 216s] and the time-to-prediction in the range of [20.8s, 27s]. In case of I/O stress, in the 10 tests, the time-to-failure varied in the rage of [353s, 402s] whereas the time-to-prediction in the range of [19.2s, 24.9s]. The time-to-failure in our evaluation has been long enough in order to trigger proper countermeasures, that can be set before the failure, to either mitigate damages

How to Manage Failures in Air Traffi c Control Software Systems 145

This chapter presented the motivations that led the current literature to develop novel solutions to failure management in ATC systems. We analyzed the failure management objectives, what the faults and failures are and how they can be managed in a real ATC system. Some hint on the failure management reactive and proactive approaches have been described and two case studies have been presented: a reactive approach, that uses FT-CORBA, today in operation and a novel proactive approach that uses a combination of Complex Event Processing and Hidden Markov Models to predict the occurrence of failures in ATC systems.

[1] Baldoni, R., Lodi, G., Montanari, L., Mariotta, G. & Rizzuto, M. [2012]. Online black-box failure prediction for mission critical distributed systems, *to appear in proceedings of*

[2] CARDAMOM [website]. Cardamom middleware website. http://www.cardamom.

[3] EC482 [2008]. Commission regulation (ec) no 482/2008, *Official Journal of the European*

[4] Elnozahy, E. N., Alvisi, L., Wang, Y.-M. & Johnson, D. B. [2002]. A survey of rollback-recovery protocols in message-passing systems, *ACM Comput. Surv.*

[5] ESARR6. [2010]. *ESARR 6. EUROCONTROL Safety Regulatory Requirement. Software in ATM Systems.*, 2.0 edn, European Organisation for the Safety of Air Navigation.

[7] Fischer, M. J., Lynch, N. A. & Paterson, M. [1985]. Impossibility of distributed consensus

[8] Gertler, J. [1988]. Survey of model-based failure detection and isolation in complex

[6] Esper [2012]. Esper project web page. http://esper.codehaus.org/.

or enable recovery actions. Further details can be found in [1].

**8. Conclusion**

**Author details**

Francesca Matarese

**9. References**

eu/.

*Union* pp. 5–9.

34(3): 375–408.

Luca Montanari and Roberto Baldoni *"Sapienza" University of Rome, Italy* Fabrizio Morciano and Marco Rizzuto

*"SESM" a Finmeccanica Company, Italy*

*"Selex Sistemi Integrati" a Finmeccanica Company, Italy*

*SAFECOMP 2012*, Springer Berlin / Heidelberg.

with one faulty process, *J. ACM* 32(2): 374–382.

plants, *Control Systems Magazine, IEEE* 8(6): 3 –11.


We evaluate the latter module in terms of *Nf p* (number of false positive): the module predicts a failure that is not actually coming and *Nf n* (number of false negatives): the module does not predict a failure that is coming. **Testbed.** We deployed CASPER in a dedicated host located in the same LAN as the ATC system to be monitored (see Figure 7). This environment is actually the testing environment of the ATC system where new solutions are tested before getting into the operational ATC system. The testing environment is composed by 8 machines, 16 cores 2.5 GHz CPU, 16 GB of RAM each one. It is important to remark that CASPER does not know the application nor the service logic nor the testbed details.

#### **7.5. Faults and failures**

The ATC testbed includes two critical servers: one of the server is responsible for disk operations (I/O) and another server is the manager of all the services. In order to induce software failures in the ATC system, we apply the following actions in such critical servers: (i)*memory stress*; that is, we start a memory-bound component co-located with the manager of all ATC services, to grab constantly increasing amount of memory resource; (ii)*I/O stress*; that is, we start an I/O-bound component co-located with the server responsible for disk operations, to grab disk resources. In both cases we brought the system to the failure of critical services. During the experiment campaign, we also considered the CPU stress; however, we discovered that due to the high computational power of the ATC nodes, the CPU stress never causes failures.

#### **7.6. Results of CASPER**

We run two types of experiments once CASPER was trained and tuned. In the first type, we injected the faults described in previous section in the ATC testing environment and we carried out 10 tests for each type of fault. In general, we obtained that in the 10 tests we carried out, the time-to-failure in case of memory stress varied in the range of [183s, 216s] and the time-to-prediction in the range of [20.8s, 27s]. In case of I/O stress, in the 10 tests, the time-to-failure varied in the rage of [353s, 402s] whereas the time-to-prediction in the range of [19.2s, 24.9s]. The time-to-failure in our evaluation has been long enough in order to trigger proper countermeasures, that can be set before the failure, to either mitigate damages or enable recovery actions. Further details can be found in [1].

#### **8. Conclusion**

16 Will-be-set-by-IN-TECH

the ATC system we stressed some of the nodes till achieving software failure conditions, and we collected the relative traces. In our test field, we consider one of the nodes of the ATC system to be affected by either Memory or I/O stress (according to the experience of the ATC designers, these two stress conditions are typical of the observed system). After collecting all these traces, we trained CASPER. At end of the training phase, we deployed CASPER again on the testing environment of the ATC system in order to conduct experiments in operative conditions. Our evaluation assesses the system state inference component accuracy and the failure prediction module accuracy (see Figure 7). In particular, we evaluate the former in terms of *Ntp* (number of true positives) the system state is unsafe and the inferred state is "system unsafe"; *Ntn* (number of true negatives): the system state is safe and the inferred state is "system safe"; *Nf p* (number of false positive): the system state is safe but the inferred state is "system unsafe"; and *Nf n* (number of false negatives): the system state is unsafe but the inferred state is "system safe". Using these parameters, we compute the following metrics

*Ntp*+*Nf n*

We evaluate the latter module in terms of *Nf p* (number of false positive): the module predicts a failure that is not actually coming and *Nf n* (number of false negatives): the module does not predict a failure that is coming. **Testbed.** We deployed CASPER in a dedicated host located in the same LAN as the ATC system to be monitored (see Figure 7). This environment is actually the testing environment of the ATC system where new solutions are tested before getting into the operational ATC system. The testing environment is composed by 8 machines, 16 cores 2.5 GHz CPU, 16 GB of RAM each one. It is important to remark that CASPER does not know

The ATC testbed includes two critical servers: one of the server is responsible for disk operations (I/O) and another server is the manager of all the services. In order to induce software failures in the ATC system, we apply the following actions in such critical servers: (i)*memory stress*; that is, we start a memory-bound component co-located with the manager of all ATC services, to grab constantly increasing amount of memory resource; (ii)*I/O stress*; that is, we start an I/O-bound component co-located with the server responsible for disk operations, to grab disk resources. In both cases we brought the system to the failure of critical services. During the experiment campaign, we also considered the CPU stress; however, we discovered that due to the high computational power of the ATC nodes, the CPU stress never

We run two types of experiments once CASPER was trained and tuned. In the first type, we injected the faults described in previous section in the ATC testing environment and we

*Nf p*+*Ntn*

that define the accuracy of CASPER:

• False Positive Rate: *<sup>f</sup>* .*p*.*r*. = *Nf p*

*Ntp*+*Nf p* • Recall (or true positive rate): *<sup>r</sup>* = *Ntp*

*p*+*r*

the application nor the service logic nor the testbed details.

• Precision: *<sup>p</sup>* = *Ntp*

• F-measure: *<sup>F</sup>* <sup>=</sup> <sup>2</sup> <sup>×</sup> *<sup>p</sup>*×*<sup>r</sup>*

**7.5. Faults and failures**

causes failures.

**7.6. Results of CASPER**

This chapter presented the motivations that led the current literature to develop novel solutions to failure management in ATC systems. We analyzed the failure management objectives, what the faults and failures are and how they can be managed in a real ATC system. Some hint on the failure management reactive and proactive approaches have been described and two case studies have been presented: a reactive approach, that uses FT-CORBA, today in operation and a novel proactive approach that uses a combination of Complex Event Processing and Hidden Markov Models to predict the occurrence of failures in ATC systems.

#### **Author details**

Luca Montanari and Roberto Baldoni *"Sapienza" University of Rome, Italy*

Fabrizio Morciano and Marco Rizzuto *"Selex Sistemi Integrati" a Finmeccanica Company, Italy*

Francesca Matarese *"SESM" a Finmeccanica Company, Italy*

#### **9. References**


© 2012 Canino et al., licensee InTech. This is an open access chapter distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

© 2012 Canino et al., licensee InTech. This is a paper distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

**A Multi-Agent Approach for Designing** 

**Next Generation of Air Traffic Systems** 

Additional information is available at the end of the chapter

Traffic Control (ATC) based on 4D trajectories.

http://dx.doi.org/10.5772/50284

**1. Introduction** 

José Miguel Canino, Juan Besada Portas, José Manuel Molina and Jesús García

Current implementation of new technologies for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM systems) along with computational improvements on airborne and ground systems developed in the last two decades, point out the need for more strategic navigation and air-traffic control procedures based on four-dimensional (position plus time) trajectories. Moreover, the CNS/ATM infrastructure will help to achieve more shared real-time information among aircraft, airlines and air-traffic services providers (i.e. Air Traffic Control –ATC- providers, meteorological information providers and air space resources information providers). Then, general requirements for a next-generation of Air Traffic Management (ATM) system is that entities must share real-time information about aircraft state and intentions, air-space state and resources, meteorological conditions and forecast, etc. From this information coordinated and strategic actions should be carried

Several systems have been used on last years to help controllers and pilots to take decisions in a more strategic way. Some examples of these systems are OASIS [1], MAESTRO [2], COMPAS [3], CTAS, [4], etc. In addition, in the PHARE program [5], on-board trajectory predictions were used to inform the air traffic controllers about aircraft intentions. Results of the previous proposal showed potential advantages of a more strategic navigation and Air

However new efforts are still necessary for achieving an ATM system characterized by a greater aircraft autonomy to select an optimal flight path and by a higher automation of airground coordination tasks. Thus, the Free Flight operational concept [6] suggests a future ATM where the aircraft are only restricted by global goals that must ensure safe and efficient air traffic flows. By other hand, the Trajectory Based Operations (TBO) [7] attempts to give more specific to the free flight proposal. In this case TBO concept proposes that

out by them in order to achieve efficient and free of conflict 4D trajectories.

## **A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems**

José Miguel Canino, Juan Besada Portas, José Manuel Molina and Jesús García

Additional information is available at the end of the chapter

http://dx.doi.org/10.5772/50284

#### **1. Introduction**

18 Will-be-set-by-IN-TECH

[9] IBM [2011]. System S Web Site. http://domino.research.ibm.com/comm/

[10] Kapadia, R., Stanley, G. & Walker, M. [2007]. Real world model-based fault management.,

[11] Laprie, J.-C., Avizienis, A., Randell, B. & Landwehr, C. E. [2004]. Basic concepts and taxonomy of dependable and secure computing, *IEEE Trans. Dependable Sec. Comput.*

[12] Liebert [2005]. *Regulatory Compliance and Critical System Protection*, Liebert Corporation. [13] Luckham, D. C. [2001]. *The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems*, Addison-Wesley Longman Publishing Co., Inc., Boston,

[14] OMG [CCM]. Corba component model (ccm), omg specification, formal/2011-11-03, part 3 - components. http://www.omg.org/spec/CORBA/3.2/Components/PDF. [15] OMG [FT-CORBA]. Fault tolerant corba (ft), omg specification, formal/2010-05-07 , v1.0.

[16] OMG [LTLOAD]. Lightweight load balancing service (ltload), omg specification, formal/2010-02-04, v1.0. http://www.omg.org/spec/LtLOAD/1.0/PDF. [17] OMG [LWFT]. Lightweight fault tolerance for distributed rt systems (lwft), ptc/2011-06-05, beta 2. http://www.omg.org/spec/LWFT/1.0/Beta2/PDF. [18] OMG [website]. Object management group webpage. http://www.omg.org/. [19] Rabiner, L. & Juang, B. [1986]. An introduction to hidden markov models, *ASSP*

[20] Salfner, F. [2008]. *Event-based Failure Prediction: An Extended Hidden Markov Model Approach*, PhD thesis, Department of Computer Science, Humboldt-Universität zu Berlin,

[21] Salfner, F., Lenk, M. & Malek, M. [2010]. A survey of online failure prediction methods,

[23] Stanley, G. M. & Vaidhyanathan, R. [1998]. A generic fault propagation modeling approach to on-line diagnosis and event correlation., *3rd IFAC Workshop on On-line Fault*

[24] Trivedi, K. S. & Vaidyanathan, K. [2008]. Software aging and rejuvenation, *Wiley*

[25] Williams, A. W., Pertet, S. M. & Narasimhan, P. [2007]. Tiresias: Black-box failure prediction in distributed systems, *Proc. of IEEE IPDPS 2007*, Los Alamitos, CA, USA.

[22] Simpson, W. & Sheppard, J. [1994]. *System test and diagnosis*, Kluwer Academic.

research\_projects.nsf/pages/esps.index.html.

http://www.omg.org/spec/FT/1.0/PDF.

*ACM Computing Surveys (CSUR)* 42(3): 1–42.

URL: *http://books.google.it/books?id=Pjr93wWJMiQC*

*Encyclopedia of Computer Science and Engineering*.

*Detection and Supervision in the Chemical Process Industries,*.

*Magazine, IEEE* 3(1): 4 – 16.

1(1): 11–33.

MA, USA.

Germany.

*18th International Workshop on the Principles of Diagnosis Nashville TN*.

Current implementation of new technologies for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM systems) along with computational improvements on airborne and ground systems developed in the last two decades, point out the need for more strategic navigation and air-traffic control procedures based on four-dimensional (position plus time) trajectories. Moreover, the CNS/ATM infrastructure will help to achieve more shared real-time information among aircraft, airlines and air-traffic services providers (i.e. Air Traffic Control –ATC- providers, meteorological information providers and air space resources information providers). Then, general requirements for a next-generation of Air Traffic Management (ATM) system is that entities must share real-time information about aircraft state and intentions, air-space state and resources, meteorological conditions and forecast, etc. From this information coordinated and strategic actions should be carried out by them in order to achieve efficient and free of conflict 4D trajectories.

Several systems have been used on last years to help controllers and pilots to take decisions in a more strategic way. Some examples of these systems are OASIS [1], MAESTRO [2], COMPAS [3], CTAS, [4], etc. In addition, in the PHARE program [5], on-board trajectory predictions were used to inform the air traffic controllers about aircraft intentions. Results of the previous proposal showed potential advantages of a more strategic navigation and Air Traffic Control (ATC) based on 4D trajectories.

However new efforts are still necessary for achieving an ATM system characterized by a greater aircraft autonomy to select an optimal flight path and by a higher automation of airground coordination tasks. Thus, the Free Flight operational concept [6] suggests a future ATM where the aircraft are only restricted by global goals that must ensure safe and efficient air traffic flows. By other hand, the Trajectory Based Operations (TBO) [7] attempts to give more specific to the free flight proposal. In this case TBO concept proposes that

© 2012 Canino et al., licensee InTech. This is an open access chapter distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. © 2012 Canino et al., licensee InTech. This is a paper distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

coordination activities between ATM system elements are intended to achieve efficient and free of conflict 4D trajectories. In a hypothetical TBO scenario, aircraft will calculate their User Preference Trajectories (UPTs) taking into account air-space constraints. In addition, an ATC with the role of a central agent should drive air ground negotiation processes in order to provide free of conflict trajectories. Furthermore, under certain circumstances aircraft selfseparation could be possible and air-air negotiation processes could be only supervised by the ATC. After a negotiation is performed the aircraft must fly the negotiated trajectories until a new set of trajectories were negotiated. Meanwhile, if emergence or contingence arises, a new negotiation process could be triggered.

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 149

**Figure 1.** Research and development activities for new operational concepts

models.

Fortunately, current state of the art of Multi-agent technologies provides methodological approaches and tools to develop such models. Then, the main goal of this chapter consists in illustrating how recent proposals in agent-oriented methodologies are a suitable approach for analysing and modelling new air traffic scenarios in order to obtain such conceptual

The chapter begins summarizing main contributions on modelling and simulations of future ATM. This review shows that new simulation platforms should be based on more detailed and structured conceptual models. In additions, it suggests benefices of multi-agent methodologies for approaching this problem. In section 3, multi-agent approaches for modelling several aspects of cited ATM are analysed. After a brief description of particularities of the multi-agent theory, a review of its most recent applications within the air traffic scope is presented. This exploration highlights the need of taking advantage of modern multi-agent technologies for developing robust and modular conceptual models of the new ATM. Section 4 presents the multi-agent methodologies as useful tools for analysing and modelling this ATM in order to facilitate the design and take key decisions for the implementation of new procedures. From them, one of the most recent agent methodologies, named Prometheus, has been selected to integrate the system specifications, inter-agent coordination protocols and agent inner processes as components of an ATM conceptual model, described in section 5. In order to simplify the applicability of the mentioned methodological approach, it has been applied for analysing and modelling a

In summary the new operational concepts propose:


Application of these operational concepts by 2020+ is the key target of current research initiatives such as SESAR (Single European Sky ATM Research) and Next-Gen (Next Generation Air Transportation System) [8-9]. These research programs show that the set of activities aimed to validate procedures and technologies in order to implement the cited paradigm is diverse and extensive. To identify the interdependence of such activities, we propose a framework that classifies them according to a sequential time process (see Fig. 1). The first two groups of activities are referred to the analysis of the potential of CNS/ATM systems and as well as feasible operational concepts: i.e. Free Flight, TBO, etc. Proposals of operational concepts consist of generic specifications that requires of concrete procedures for conducting operations navigation and air-traffic control. Parallel to procedures design, on-board and ground systems and underlying mathematical models have to be also developed. Then, initial design of procedures and their associated systems can be considered as an iterative process that needs to be validated by means of analytical simulation. This process is a key issue as a previous stage to the Human-In-The-Loop (HITL) simulations and flight tests. HITL simulations and flight trials allows defining specific standards (e.g Procedures for Air Navigation Services –PANS- or for Required Performance Navigation –RNP-) for the actual implementation of the operational concept.

Several attempts for developing simulation and design analysis tools have been proposed [10-16]. Results of these studies show that it will be necessary more detailed and structured conceptual models to give support to analytical simulation tools to address the paradigm shift in the ATM procedures. Moreover, the close interdependence between coordination procedures, systems to execute them and their underlying mathematical models must be clearly set out in the conceptual model.

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 149

**Figure 1.** Research and development activities for new operational concepts

148 Advances in Air Navigation Services

operations.

clearly set out in the conceptual model.

arises, a new negotiation process could be triggered. In summary the new operational concepts propose:

efficiency and safety of surrounding air traffic flow.

coordination activities between ATM system elements are intended to achieve efficient and free of conflict 4D trajectories. In a hypothetical TBO scenario, aircraft will calculate their User Preference Trajectories (UPTs) taking into account air-space constraints. In addition, an ATC with the role of a central agent should drive air ground negotiation processes in order to provide free of conflict trajectories. Furthermore, under certain circumstances aircraft selfseparation could be possible and air-air negotiation processes could be only supervised by the ATC. After a negotiation is performed the aircraft must fly the negotiated trajectories until a new set of trajectories were negotiated. Meanwhile, if emergence or contingence

 Four dimensional trajectory based operations defined by the aircraft position and time. These trajectories must suit the preferences of the aircraft while preserving the

Accessibility and distribution of updated data among all entities involved in flight

 A more distributed reallocation of the roles of aircraft and services of air traffic control to achieve their respective goals, in contrast with the current scheme of responsibilities characterized by a ground-centralized monitoring and air traffic separation activities. Application of these operational concepts by 2020+ is the key target of current research initiatives such as SESAR (Single European Sky ATM Research) and Next-Gen (Next Generation Air Transportation System) [8-9]. These research programs show that the set of activities aimed to validate procedures and technologies in order to implement the cited paradigm is diverse and extensive. To identify the interdependence of such activities, we propose a framework that classifies them according to a sequential time process (see Fig. 1). The first two groups of activities are referred to the analysis of the potential of CNS/ATM systems and as well as feasible operational concepts: i.e. Free Flight, TBO, etc. Proposals of operational concepts consist of generic specifications that requires of concrete procedures for conducting operations navigation and air-traffic control. Parallel to procedures design, on-board and ground systems and underlying mathematical models have to be also developed. Then, initial design of procedures and their associated systems can be considered as an iterative process that needs to be validated by means of analytical simulation. This process is a key issue as a previous stage to the Human-In-The-Loop (HITL) simulations and flight tests. HITL simulations and flight trials allows defining specific standards (e.g Procedures for Air Navigation Services –PANS- or for Required Performance Navigation –RNP-) for the actual implementation of the operational concept.

Several attempts for developing simulation and design analysis tools have been proposed [10-16]. Results of these studies show that it will be necessary more detailed and structured conceptual models to give support to analytical simulation tools to address the paradigm shift in the ATM procedures. Moreover, the close interdependence between coordination procedures, systems to execute them and their underlying mathematical models must be Fortunately, current state of the art of Multi-agent technologies provides methodological approaches and tools to develop such models. Then, the main goal of this chapter consists in illustrating how recent proposals in agent-oriented methodologies are a suitable approach for analysing and modelling new air traffic scenarios in order to obtain such conceptual models.

The chapter begins summarizing main contributions on modelling and simulations of future ATM. This review shows that new simulation platforms should be based on more detailed and structured conceptual models. In additions, it suggests benefices of multi-agent methodologies for approaching this problem. In section 3, multi-agent approaches for modelling several aspects of cited ATM are analysed. After a brief description of particularities of the multi-agent theory, a review of its most recent applications within the air traffic scope is presented. This exploration highlights the need of taking advantage of modern multi-agent technologies for developing robust and modular conceptual models of the new ATM. Section 4 presents the multi-agent methodologies as useful tools for analysing and modelling this ATM in order to facilitate the design and take key decisions for the implementation of new procedures. From them, one of the most recent agent methodologies, named Prometheus, has been selected to integrate the system specifications, inter-agent coordination protocols and agent inner processes as components of an ATM conceptual model, described in section 5. In order to simplify the applicability of the mentioned methodological approach, it has been applied for analysing and modelling a particular air traffic scenario of arrival air traffic operations. In this case we will consider this particular ATM model as an Air Traffic System (ATS). Moreover the model is focused on the inner architecture of an ATC System. Although these simplifications, the obtained model under this methodological approach can be extended for adding new gate-to-gate air traffic scenarios, coordination procedures as well as improved versions of the technical support to execute mentioned procedures. Section 6 resents guidelines for a software implementation and results of an illustrative example of current implementation state. Finally, conclusions are presented in section 7.

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 151

operations. However, most of agent-based contributions are oriented to developing very

i. Analysis of negotiation patterns between agents in free flight air traffic scenarios. Within this category, Wangerman and Stengel analyse the dynamic behaviour of aircraft in the airspace as an intelligent system (Intelligent Aircraft/ Airspace System or IAAS) [19-21]. This system consists of three types of agents, airlines, aircraft and traffic managers, and the dynamic behaviour of the agents of IAAS is analysed from the perspective of a distributed approach. In this context, the principles of negotiations are a way to implement distributed iterative optimization of IAAS operations. In [22] Harpert et al. propose an agent-oriented model of an ATM in a free flight and a model of distributed decision making for the resolution of conflicts in the ATM. This proposal includes a distributed optimization scheme in which the agents generate and evaluate proposals options that best suit their preferences on a utility function and a multiattribute decision tree scheme. Besides, the declarative capabilities of an intelligent agent can be modelled by expert systems [23-25]. To set the ground rules of the expert system, tasks were classified in [21] into four groups: emergency tasks, tasks of a

ii. Avionics systems for autonomous operations in distributed air traffic management scenarios. Works in this category propose designing avionics systems based on multiagent systems. The proposed developments basically consist of systems for automatic conflict resolution, automatic warnings and recommendations to the crew [26-28]. In [26] authors propose a design of intelligent traffic agent developed to detect and solve conflicts on board in a free flight environment. An extension of previous work presented in [27] proposes a design of an executive agent that resolves conflicts for both the traffic and bad weather areas. In this case an agent's hierarchical architecture is suggested for making decisions based on the information produced by a traffic agent proposed by [26] and a weather agent. Finally, in [29] capabilities required of future flight management systems (FMS) in the cabin were characterized by means of agentoriented analysis of the air navigation and arrival operations into a distributed environment. This analysis was later extended to define capabilities required to carry

basic aspects of the ATS system. The proposals can be classified into three categories:

specific mode of operation, negotiation tasks and routine tasks.

out automated arrivals and departures at uncontrolled airports [30].

implemented as a Java environment SMA is presented.

iii. Simulation systems for the analysis of advanced air traffic concepts. This group includes several simulation platforms used for the design and validation of procedures and systems proposed for next generation of air traffic scenarios. In [15, 17] a multiaircraft control platform is proposed to increase the realism and flexibility of HITL simulations. Functional descriptions of pilot and ATC perspectives within this platform are presented in [15]. In [17] the ATC agent model is analysed in order to identify its roles and responsibilities in future ATM systems. Another development of functional architecture airspace for an Airspace Concept Evaluation System (ACES) is presented in [16]. In a later work an agent-oriented model of the CNS/ATM infrastructure of ACES was proposed in [31]. Finally, in [32] a design of an experimental air traffic simulator

#### **2. Simulation and design analysis tools for new air-traffic concepts**

The simulation of air traffic scenarios with different levels of fidelity is the mainstay of the methodology used widely by the scientific community to develop new operational concepts [8-9]. Real-time simulations are, in general, HITL simulations intended for human factors evaluation while navigation and/or traffic control procedures are performed. Fast-time simulations are centred on the analysis of several issues no specifically focused on human factors: mathematical models, algorithms, negotiation and/or decision-making processes, quality of service measures, etc. Obviously real-time simulation platforms are able to carry out fast-time simulations by including computer models for performing tasks assigned to the human element.

Some of the multi-aircraft simulators currently used for air traffic research purposes are: NLR's Air Traffic Control Research Simulator (NARSIM)) [10], Pseudo Aircraft System (PAS) [11], Target Generation Facility (TGF [12], ATC Interactive for the future of air traffic control[13] and Multi-aircraft Control System (MACS) [14]. Three main consequences can be derived from the analysis of previous works. First, more detailed proposals are necessary for supporting automated air-ground coordination processes. Second, modelling such automatic coordination procedures system requires a parallel specification of their associated systems (i.e. user interfaces, mathematical models and algorithm for making decisions, etc). Third, new conceptual models and simulation frameworks require a high modularity and scalability for making possible the progressive incorporation of new or modified procedures and their associated systems as they are designed or evaluated.

In the context of modelling such complex distributed systems, Multi-Agent Systems (MAS) theory gives natural solutions [17-18]. This theory provides a suitable framework to analyse and model the organization of a set of autonomous ATM entities that coordinate and negotiate their actions in order to achieve their respective goals.

#### **3. Multiagent approaches for future air traffic scenarios**

The dynamic nature of air traffic and its geographical and functional distribution have attracted the attention of agent researchers since the last decade. For example, Optimal Aircraft Sequencing using Intelligent Scheduling (OASIS) [1] is a system used at the airport of Sydney to help air traffic controllers on arrival and approach air traffic sequencing operations. However, most of agent-based contributions are oriented to developing very basic aspects of the ATS system. The proposals can be classified into three categories:

150 Advances in Air Navigation Services

are presented in section 7.

the human element.

particular air traffic scenario of arrival air traffic operations. In this case we will consider this particular ATM model as an Air Traffic System (ATS). Moreover the model is focused on the inner architecture of an ATC System. Although these simplifications, the obtained model under this methodological approach can be extended for adding new gate-to-gate air traffic scenarios, coordination procedures as well as improved versions of the technical support to execute mentioned procedures. Section 6 resents guidelines for a software implementation and results of an illustrative example of current implementation state. Finally, conclusions

**2. Simulation and design analysis tools for new air-traffic concepts** 

The simulation of air traffic scenarios with different levels of fidelity is the mainstay of the methodology used widely by the scientific community to develop new operational concepts [8-9]. Real-time simulations are, in general, HITL simulations intended for human factors evaluation while navigation and/or traffic control procedures are performed. Fast-time simulations are centred on the analysis of several issues no specifically focused on human factors: mathematical models, algorithms, negotiation and/or decision-making processes, quality of service measures, etc. Obviously real-time simulation platforms are able to carry out fast-time simulations by including computer models for performing tasks assigned to

Some of the multi-aircraft simulators currently used for air traffic research purposes are: NLR's Air Traffic Control Research Simulator (NARSIM)) [10], Pseudo Aircraft System (PAS) [11], Target Generation Facility (TGF [12], ATC Interactive for the future of air traffic control[13] and Multi-aircraft Control System (MACS) [14]. Three main consequences can be derived from the analysis of previous works. First, more detailed proposals are necessary for supporting automated air-ground coordination processes. Second, modelling such automatic coordination procedures system requires a parallel specification of their associated systems (i.e. user interfaces, mathematical models and algorithm for making decisions, etc). Third, new conceptual models and simulation frameworks require a high modularity and scalability for making possible the progressive incorporation of new or

modified procedures and their associated systems as they are designed or evaluated.

negotiate their actions in order to achieve their respective goals.

**3. Multiagent approaches for future air traffic scenarios** 

In the context of modelling such complex distributed systems, Multi-Agent Systems (MAS) theory gives natural solutions [17-18]. This theory provides a suitable framework to analyse and model the organization of a set of autonomous ATM entities that coordinate and

The dynamic nature of air traffic and its geographical and functional distribution have attracted the attention of agent researchers since the last decade. For example, Optimal Aircraft Sequencing using Intelligent Scheduling (OASIS) [1] is a system used at the airport of Sydney to help air traffic controllers on arrival and approach air traffic sequencing


#### 152 Advances in Air Navigation Services

The proposals based on multi-agent systems presented above cover a wide spectrum of issues related to air traffic operations in a free flight environment. However it is clear that effective implementation of the new operational concepts involved in the future scenario still requires more structured models that take into account the tight relationship between procedures and systems to support them. In addition, as it was explained before, the model should be scalable enough to allow a progressive integration of the following elements into the model:

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 153

coarse-grained computational systems (agents) and interaction mechanisms for a goal to obtain in the system that maximizes some global quality measure, assuming a certain organizational structure which can be assumed to keep fixed (agents have certain roles and

Some of the main agent-oriented methodologies are MASCommonKADS [33], Tropos [34], Zeus [35], MaSE [36], GAIA [37], INGENIAS [38]. In [30-41] a comparative analysis of the main methodologies is presented. MAS-CommonKADS is a methodology for knowledgebased system that defines different models (agent model, task model, organizational model etc.) in the system life-cycle using oriented-object techniques and protocol engineering techniques. Tropos is a requirement-based methodology; Zeus provides an agent platform which facilitates the rapid development of collaborative agent applications; MaSE is an object-oriented methodology that considers agents as objects with capabilities of coordination and conversation with automatic generation of code and Unified Modelling Language (UML) notation; Gaia is intended to go systematically from a statement of requirements to a design sufficiently detailed for implementation; and INGENIAS proposes a language for multi-agent system specification and its integration in the lifecycle, as well as it provides a collection of tools for modelling, verifying and

A descriptive analysis these methodologies are beyond of these chapter goals. However after a previous study we have selected Prometheus methodology as the most suitable one. Prometheus agent-oriented well-established methodology has been selected to provide guidelines to develop the mentioned multi-agent system [42]. We argue that Prometheus suits well for solving our problem due to: (i) the highly detailed guidelines for defining the initial system specification, (ii) the modularity of the agent's internal architecture around the concept of capability (providing a direct correspondence between capabilities and functionalities of airborne and ground systems), (iii) the easy translation from the conceptual model into an executable model by means of current agent platforms that

Prometheus methodology covers the entire process of design and implementation of intelligent agents. It includes three phases (see Figure 2): system specification, architecture

System Specification stage defines the objectives or goals of the system. Goals help to identify functionality required to achieve them, as well as a description of the interface between the system and its environment in terms of inputs (*Perceptions*) and outputs (*actions*) of the system. The identification and refinement of the objectives are carried out, in an iterative manner, from the definition of different use case scenarios. Scenarios illustrate the operation mode of said system. The concept of scenario (or use case scenario) comes from the object-oriented software methodologies, but with a slightly adapted structure that provides a more integrated than the mere analysis of the isolated

provides software infrastructure as it will be explained later on.

abilities that do not change in time).

generate agents' code.

design and detailed design [42].

system.


Fortunately, methodologies for developing multi-agent systems have reached a noticeable degree of maturity in recent years, becoming an invaluable tool to achieve a comprehensive analysis and modelling of complex scenarios. Thus, the analysis and modeling of interactions in terms of coordination and negotiation strategies between agents provides useful guideline for developing new schemes for developing automated ATC and navigation procedures. In turn, the study of the agents' behaviour and their internal architecture for the mentioned coordination processes provides a more precise identification of the functionalities required by on-board and ground systems to execute mentioned these procedures.

#### **4. Current methodologies and tools for analysing and designing MASs**

Agent methodologies provide with a set of guidelines to facilitate the development of multiagent systems over several stages since the initial draft of idea until the final detailed design. In this way, current multi-agent technology provides practical and formal methodologies to analyse and design, in a structured and consistent manner, the following issues: (i) roles and functionalities of autonomous entities (agents) that take part in an operational scenario, (ii) interactions between agents (or agent protocols) and (iii) inner architecture and dynamic behaviour (processes) of agents. Besides several agent platforms have been proposed as middleware tools for translation the conceptual model into an executable model.

The design of MAS requires not only new models but also the identification of the software abstractions, since this paradigm introduces a higher abstraction level when compared to traditional approaches. They may be used by software developers to more naturally understand, model and develop an important class of complex distributed systems. The key aspects of problems being modelled under a MAS methodology are: establishing a set of coarse-grained computational systems (agents) and interaction mechanisms for a goal to obtain in the system that maximizes some global quality measure, assuming a certain organizational structure which can be assumed to keep fixed (agents have certain roles and abilities that do not change in time).

152 Advances in Air Navigation Services

involved agents

automation levels.

functionalities.

ground systems.

the model:

procedures.

The proposals based on multi-agent systems presented above cover a wide spectrum of issues related to air traffic operations in a free flight environment. However it is clear that effective implementation of the new operational concepts involved in the future scenario still requires more structured models that take into account the tight relationship between procedures and systems to support them. In addition, as it was explained before, the model should be scalable enough to allow a progressive integration of the following elements into

 Operating procedures for ATC and aircraft, specifying: (i) roles and tasks assigned to ATC and flight crew and (ii) coordination rules and negotiation protocols among the

ATC and on-board functionalities to help to execute such procedures at several

Underlying mathematical models and algorithms to give support to previous

High level languages that allow for accurate intercommunication between aircraft and

Fortunately, methodologies for developing multi-agent systems have reached a noticeable degree of maturity in recent years, becoming an invaluable tool to achieve a comprehensive analysis and modelling of complex scenarios. Thus, the analysis and modeling of interactions in terms of coordination and negotiation strategies between agents provides useful guideline for developing new schemes for developing automated ATC and navigation procedures. In turn, the study of the agents' behaviour and their internal architecture for the mentioned coordination processes provides a more precise identification of the functionalities required by on-board and ground systems to execute mentioned these

**4. Current methodologies and tools for analysing and designing MASs** 

middleware tools for translation the conceptual model into an executable model.

Agent methodologies provide with a set of guidelines to facilitate the development of multiagent systems over several stages since the initial draft of idea until the final detailed design. In this way, current multi-agent technology provides practical and formal methodologies to analyse and design, in a structured and consistent manner, the following issues: (i) roles and functionalities of autonomous entities (agents) that take part in an operational scenario, (ii) interactions between agents (or agent protocols) and (iii) inner architecture and dynamic behaviour (processes) of agents. Besides several agent platforms have been proposed as

The design of MAS requires not only new models but also the identification of the software abstractions, since this paradigm introduces a higher abstraction level when compared to traditional approaches. They may be used by software developers to more naturally understand, model and develop an important class of complex distributed systems. The key aspects of problems being modelled under a MAS methodology are: establishing a set of Some of the main agent-oriented methodologies are MASCommonKADS [33], Tropos [34], Zeus [35], MaSE [36], GAIA [37], INGENIAS [38]. In [30-41] a comparative analysis of the main methodologies is presented. MAS-CommonKADS is a methodology for knowledgebased system that defines different models (agent model, task model, organizational model etc.) in the system life-cycle using oriented-object techniques and protocol engineering techniques. Tropos is a requirement-based methodology; Zeus provides an agent platform which facilitates the rapid development of collaborative agent applications; MaSE is an object-oriented methodology that considers agents as objects with capabilities of coordination and conversation with automatic generation of code and Unified Modelling Language (UML) notation; Gaia is intended to go systematically from a statement of requirements to a design sufficiently detailed for implementation; and INGENIAS proposes a language for multi-agent system specification and its integration in the lifecycle, as well as it provides a collection of tools for modelling, verifying and generate agents' code.

A descriptive analysis these methodologies are beyond of these chapter goals. However after a previous study we have selected Prometheus methodology as the most suitable one. Prometheus agent-oriented well-established methodology has been selected to provide guidelines to develop the mentioned multi-agent system [42]. We argue that Prometheus suits well for solving our problem due to: (i) the highly detailed guidelines for defining the initial system specification, (ii) the modularity of the agent's internal architecture around the concept of capability (providing a direct correspondence between capabilities and functionalities of airborne and ground systems), (iii) the easy translation from the conceptual model into an executable model by means of current agent platforms that provides software infrastructure as it will be explained later on.

Prometheus methodology covers the entire process of design and implementation of intelligent agents. It includes three phases (see Figure 2): system specification, architecture design and detailed design [42].

System Specification stage defines the objectives or goals of the system. Goals help to identify functionality required to achieve them, as well as a description of the interface between the system and its environment in terms of inputs (*Perceptions*) and outputs (*actions*) of the system. The identification and refinement of the objectives are carried out, in an iterative manner, from the definition of different use case scenarios. Scenarios illustrate the operation mode of said system. The concept of scenario (or use case scenario) comes from the object-oriented software methodologies, but with a slightly adapted structure that provides a more integrated than the mere analysis of the isolated system.

Later on, in the Architecture Design phase, the description of the system structure is represented by means of diagrams that identify the agents of the systems and their interactions in terms of communication messages and protocols. Protocols represent specific communication schemes. They can be modelled using Agent Unified Modelling Language (AUML) that describes the interactions of agents in different scenarios of use cases.

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 155

Moreover, the tool Prometheus Design Tool (PDT) facilitates the tasks of the developer over the previous stages to provide information about possible inconsistencies in the design [43]. In addition, several software tools have been developed in recent years for software implementation of system multi-agents. One of the most extended is the Java *Agent DEvelopment Framework (JADE)* Platform [44]. JADE simplifies the implementation of multiagent systems through a middleware that provides several resources through a set of library

b. Provide agent intercommunication that complies with the *FIPA (Foundation for* 

c. Supply services for create and manage cycle of live of agents as well are their services

JADE behaviours can be classified onto simple behaviours and composite behaviours. In

a. One-shot behaviour, an atomic task to be carried out once, used here for initialization tasks; b. Cyclic behaviour, which is iterated while exists, such as messages listening and

d. Ticker behaviour or a cyclic behaviour which performs a series of instructions executed keeping a certain fixed time, used in the platform for simulation numeric computation

a. FSMBehaviour that consists of a class that allow defining a Finite State Machine by

c. ParalellBehaviour that executes their sub-behaviours concurrently and ends when a certain condition is satisfied (for one, several or all of them). In this way, agents are able to concurrently to carry out different tasks and to keep simultaneous conversations.

c. Waker behaviour, or a one-shot behaviour invoked after a certain time; and

means sub-behaviours, where each of them represents an machine state b. SequentialBehaviour that executes its sub-behaviours in a sequential way, and

a. Implement agent's tasks into a several JAVA classes named behaviours.

*Intelligent physical Agents)* specifications [45].

into the multi-agent system.

turn, simple behaviours can be classified as:

classes aimed to:

processing;

and graphical output.

Composite behaviours are three:

**Figure 3.** JADE Behaviours

Finally, the Detailed Design phase consists of designing internal processes carried out by each agent and an inner architecture that describes how these processes are organized and implemented. Prometheus proposes implementing agent tasks by means a set of different plans that are triggered when determinate events occurs. Plans are grouped into several groups associated to the execution of specific tasks. A group of plans as well data used or produced by them constitutes an agent capability. Then focus of this stage is to define capabilities, internal events, plans and detailed data structures. In this way capabilities are modules within the agent that use or provide related data types. Capabilities can be nested within other skills so that in the detailed design, the agent will have an arbitrary number of layers in an understandable complexity at each level. Thus, capabilities can be constituted by other sub-capacities or, at lowest level, by plans, events and data. The plans set out the set of tasks performed to achieve a particular purpose. They are also triggered by certain events (internal or external messages, perceptions, etc.). As a result of this stage are general diagrams of each of the agents (which show higher level capabilities of the agent), charts of capabilities, descriptors detailed plans and data descriptors.

**Figure 2.** Prometheus methodology phases [42]

Moreover, the tool Prometheus Design Tool (PDT) facilitates the tasks of the developer over the previous stages to provide information about possible inconsistencies in the design [43]. In addition, several software tools have been developed in recent years for software implementation of system multi-agents. One of the most extended is the Java *Agent DEvelopment Framework (JADE)* Platform [44]. JADE simplifies the implementation of multiagent systems through a middleware that provides several resources through a set of library classes aimed to:


JADE behaviours can be classified onto simple behaviours and composite behaviours. In turn, simple behaviours can be classified as:


Composite behaviours are three:

154 Advances in Air Navigation Services

Later on, in the Architecture Design phase, the description of the system structure is represented by means of diagrams that identify the agents of the systems and their interactions in terms of communication messages and protocols. Protocols represent specific communication schemes. They can be modelled using Agent Unified Modelling Language

Finally, the Detailed Design phase consists of designing internal processes carried out by each agent and an inner architecture that describes how these processes are organized and implemented. Prometheus proposes implementing agent tasks by means a set of different plans that are triggered when determinate events occurs. Plans are grouped into several groups associated to the execution of specific tasks. A group of plans as well data used or produced by them constitutes an agent capability. Then focus of this stage is to define capabilities, internal events, plans and detailed data structures. In this way capabilities are modules within the agent that use or provide related data types. Capabilities can be nested within other skills so that in the detailed design, the agent will have an arbitrary number of layers in an understandable complexity at each level. Thus, capabilities can be constituted by other sub-capacities or, at lowest level, by plans, events and data. The plans set out the set of tasks performed to achieve a particular purpose. They are also triggered by certain events (internal or external messages, perceptions, etc.). As a result of this stage are general diagrams of each of the agents (which show higher level capabilities of the agent), charts of

> Initial Functionality - Capability descriptor

Actions, percepts

Shared data

**Data descriptions**

**Descriptors**

**Key** Final design artifact

Crosscheck Intermediate design tool

Derives

**Capability descriptors**

> **Plan Descriptor**

Coupling Event/Messages

**Event descriptor**

(AUML) that describes the interactions of agents in different scenarios of use cases.

capabilities, descriptors detailed plans and data descriptors.

**System Goals**

**System Overview**

**overview**

**Capability overview**

Data

**Protocols Agent**

Agent acquaintance

**Process Agent** 

**Scenarios**

Interaction diagrams

*System* 

*Architectural design*

*Detailed design* 

*Specification*

**Figure 2.** Prometheus methodology phases [42]


**Figure 3.** JADE Behaviours

### **5. Appling Prometheus methodology for designing an arrival TBO conceptual model**

As explained in the previous section, Prometheus methodology carries out an iterative process on three phases: specification system, architecture design and detailed design. Each of these phases provides guidelines for designing several model components. These components produce a hierarchical structuring mechanism which makes possible a model description at multiple levels of abstraction [19]. In addition, the structured nature of design components facilitates crosschecking for completeness and consistency of the model in each design phase.

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 157

Tasks of each one of above scenarios have been grouped into new sub-scenarios and so on. Figure 4 depicts a list of the most significant sub-scenarios deployed from the previous one. In particular *Manage navigation procedure* scenario and *Manage ATC* scenario are developed until the lowest level. In addition, this scenario architecture shows that air-ground negotiation processes are contained into specific air-ground negotiation scenarios which are

To illustrate how scenarios can be deployed we will focus on the *Manage ATC scenario*. This

 *Update ATC environmental information scenario,* which covers associated processes to collect information about status and intentions of aircraft, airspace resources (including

*Manage ATC procedures scenario*. It includes the processes related to maintaining the

 *Manage on board surveillance scenario*. This scenario contains tasks for monitoring air traffic. These tasks are aimed at identifying aircraft trajectory deviations and potential conflicts with other aircraft or obstacles. It also provides viable solutions for correcting these anomalies and events for triggering specific processes in order to

shared by *Manage Aircraft* and *Manage ATC* scenarios.

restricted flight areas), weather conditions, etc.

implement the solutions mentioned above.

separation of aircraft to achieve an efficient traffic flow.

**Figure 4.** Architecture of the main scenarios for Trajectory Based Operations

scenario contains the following four scenarios:

#### **5.1. System specification**

In this phase, goals of our ATS model are identified. In turns goals are captured from a set of *scenarios* that illustrate essential aspects of the system operation. Scenarios and goals help to recognize initial system functionalities and to examine the system-environment interface in terms of inputs *(Perceptions)* and outputs *(actions) [45].* Thus, scenarios are use cases that contain a sequence of steps each of them relating to a goal, an action, a perception or another scenario.

For outlining the mentioned scenarios, a generic automated air traffic scenario was considered as a distributed process where several autonomous and proactive entities (agents) plan and execute a set of coordinated tasks to provide arrival and approach free of conflict 4D trajectory. This operational scenario is particularly critical in arrival air traffic operations due to the high variability of the speed, heading and altitudes that could affect to the degree of predictability of several converging trajectories. Moreover, guidelines from scenario proposed in DAG-TM (CE-11) project [46] have been taken into account. According to referred guidelines the flight crew: *(i)* could negotiate arrival preferred trajectories with the ATC; *(ii)* is responsible for maintaining longitudinal spacing between consecutive aircraft once a trajectory (o constraints) has been assigned.

In this operational scenario, the following agents have been identified: Aircraft, Air Traffic Control (ATC), Meteorological Service Provider (MPS), Airspace Resources Provider (ASP) and Airline Operational Control (AOC). In addition several ATC agents could be defined in order to coordinate arrival ATC tasks with the ATC en-route or departure ones. MSP, ASP and AOC agents' functionalities have been used to define the information required by the ATC and aircraft agents as well as essential protocols to accomplish this information.

Use case scenarios have been selected and organized taking into account perspective that each agent have about the generic air traffic scenario. Then, five root scenarios have been defined: *(i)* Manage Aircraft, *(ii)* Manage ATC, *(iii)* Manage Airline Operational Control, *(iv)* Provide Airspace Resources *(v)* Provide Weather Information.

Tasks of each one of above scenarios have been grouped into new sub-scenarios and so on. Figure 4 depicts a list of the most significant sub-scenarios deployed from the previous one. In particular *Manage navigation procedure* scenario and *Manage ATC* scenario are developed until the lowest level. In addition, this scenario architecture shows that air-ground negotiation processes are contained into specific air-ground negotiation scenarios which are shared by *Manage Aircraft* and *Manage ATC* scenarios.

156 Advances in Air Navigation Services

**conceptual model** 

design phase.

scenario.

information.

**5.1. System specification** 

**5. Appling Prometheus methodology for designing an arrival TBO** 

As explained in the previous section, Prometheus methodology carries out an iterative process on three phases: specification system, architecture design and detailed design. Each of these phases provides guidelines for designing several model components. These components produce a hierarchical structuring mechanism which makes possible a model description at multiple levels of abstraction [19]. In addition, the structured nature of design components facilitates crosschecking for completeness and consistency of the model in each

In this phase, goals of our ATS model are identified. In turns goals are captured from a set of *scenarios* that illustrate essential aspects of the system operation. Scenarios and goals help to recognize initial system functionalities and to examine the system-environment interface in terms of inputs *(Perceptions)* and outputs *(actions) [45].* Thus, scenarios are use cases that contain a sequence of steps each of them relating to a goal, an action, a perception or another

For outlining the mentioned scenarios, a generic automated air traffic scenario was considered as a distributed process where several autonomous and proactive entities (agents) plan and execute a set of coordinated tasks to provide arrival and approach free of conflict 4D trajectory. This operational scenario is particularly critical in arrival air traffic operations due to the high variability of the speed, heading and altitudes that could affect to the degree of predictability of several converging trajectories. Moreover, guidelines from scenario proposed in DAG-TM (CE-11) project [46] have been taken into account. According to referred guidelines the flight crew: *(i)* could negotiate arrival preferred trajectories with the ATC; *(ii)* is responsible for maintaining longitudinal spacing between consecutive

In this operational scenario, the following agents have been identified: Aircraft, Air Traffic Control (ATC), Meteorological Service Provider (MPS), Airspace Resources Provider (ASP) and Airline Operational Control (AOC). In addition several ATC agents could be defined in order to coordinate arrival ATC tasks with the ATC en-route or departure ones. MSP, ASP and AOC agents' functionalities have been used to define the information required by the ATC and aircraft agents as well as essential protocols to accomplish this

Use case scenarios have been selected and organized taking into account perspective that each agent have about the generic air traffic scenario. Then, five root scenarios have been defined: *(i)* Manage Aircraft, *(ii)* Manage ATC, *(iii)* Manage Airline Operational Control, *(iv)*

aircraft once a trajectory (o constraints) has been assigned.

Provide Airspace Resources *(v)* Provide Weather Information.

To illustrate how scenarios can be deployed we will focus on the *Manage ATC scenario*. This scenario contains the following four scenarios:


**Figure 4.** Architecture of the main scenarios for Trajectory Based Operations

 *Manage contingences scenario* that includes tasks for analysing air traffic contingencies and circumstances in which they occur (e.g. aircraft malfunctions, onboard contingences, etc.). It also includes decision-making processes to determine actions to be carried out regarding the management of traffic control procedures.

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 159

**Figure 5.** ATC agent goals

trajectories that could be in conflicts.

Figure 6 shows a simplified representation of the system overview diagram. The simplification consists on representing only the main actions and perceptions of the ATC and aircraft agents as well as the main communication protocols. In a more complex system

After identifying the interaction protocols in the system overview diagram, protocols are designed. For the ATC and aircraft agents, protocols are aimed to: (i) improve agents' knowledge base about the environment and/or the other agent's intentions, (i) negotiate

overview diagram, all these elements should be signed for all the agents.

Focusing on the *Manage ATC procedures scenario*, the next three scenarios are deployed:


From the above scenario architecture a goals tree can be obtained. Lowest level goals help to identify functionalities and processes that the agent has to carry out to achieve them. For example, Figure 5 shows a particular set or goals that results from the *ATC manage* scenario. On it, the goal *UPT air-ground negotiation* consists of several sub-goals such as generate proposals for aircraft, evaluate proposals from aircraft or establish and an airground communication protocol for negotiate mentioned proposals and counterproposals. In addition, functionalities help to identify actions, perceps and data used or generated by the agents. Then, for the ATC agent the following perceptions can be identified:


#### **5.2. Architecture design and negotiation protocols**

In the architecture design phase the following aspects of the overall system are defined:


**Figure 5.** ATC agent goals

158 Advances in Air Navigation Services

adjacent ATC agents.

delegated on the aircraft.

sub-scenarios.

identified:

 *Manage contingences scenario* that includes tasks for analysing air traffic contingencies and circumstances in which they occur (e.g. aircraft malfunctions, onboard contingences, etc.). It also includes decision-making processes to determine

actions to be carried out regarding the management of traffic control procedures.

*Set ATC traffic* involves actions for *receiving* or transferring air traffic from or to other

 *Set strategic separation*. This scenario contains tasks for planning aircraft trajectories and assigning them by means a negotiation process. *Therefore* it is a key scenario for modelling automated procedures for TBOs and it should contain several negotiations

 *Set tactical separation*. This scenario contains tasks for modifying current flight trajectories when unforeseen contingencies arise. The tasks performed in this scenario are twofold: (i) to provide specific instructions for activating protocols aimed at aircraft separation in extreme situations of short-range conflicts and (ii) to authorize and supervise air-air negotiation for self-separation when separation responsibility has been

From the above scenario architecture a goals tree can be obtained. Lowest level goals help to identify functionalities and processes that the agent has to carry out to achieve them. For example, Figure 5 shows a particular set or goals that results from the *ATC manage* scenario. On it, the goal *UPT air-ground negotiation* consists of several sub-goals such as generate proposals for aircraft, evaluate proposals from aircraft or establish and an airground communication protocol for negotiate mentioned proposals and counterproposals. In addition, functionalities help to identify actions, perceps and data used or generated by the agents. Then, for the ATC agent the following perceptions can be

Perceptions form external sensors: data from radar systems, WAN receivers, etc.

In the architecture design phase the following aspects of the overall system are defined:

Furthermore communication interactions between agents are considered.

behaviour. Then, they have been depicted using an AUML notation [47] .

 The system *overview diagram*. This diagram represents the static structure of the system, tying agents and main data used by them as well as their perceptions and actions.

 The set of *interaction protocols* that capture timing of communication of related messages between agents. These protocols are derived from the scenarios defined in the specification phase protocols and, therefore, they describe the system dynamic

 Perceptions from human-machine interface: menus and inputs options. Actions: display traffic data and ATC procedure state data on screams.

**5.2. Architecture design and negotiation protocols** 

Focusing on the *Manage ATC procedures scenario*, the next three scenarios are deployed:

Figure 6 shows a simplified representation of the system overview diagram. The simplification consists on representing only the main actions and perceptions of the ATC and aircraft agents as well as the main communication protocols. In a more complex system overview diagram, all these elements should be signed for all the agents.

After identifying the interaction protocols in the system overview diagram, protocols are designed. For the ATC and aircraft agents, protocols are aimed to: (i) improve agents' knowledge base about the environment and/or the other agent's intentions, (i) negotiate trajectories that could be in conflicts.

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 161

**Figure 7.** Air-ground Negotiation Protocol

**Figure 6.** Simplified architecture overview

For a better understanding of automated air-ground coordination aspects, we will focus on describing a proposed air-ground negotiation protocol (see Figure 7). This protocol represents the core of the both the ATC strategic planning tasks and the aircraft navigation planning tasks. Although new scheme of negotiation can be defined from this design, all of them will use similar functionalities to evaluate proposals and generate counter-proposals. Therefore, this protocol and its associated functionalities provide guidelines and specification enough for developing new aircraft and ATC coordination procedures.

In Figure 7, the on board computation processes are represented on the left side of the aircraft agent lifeline. On the right side of the ATC agent lifeline we can observe computation performed by ground systems. Moreover, on the right side of this ground computation system, a new lifeline for other aircraft agents is showed.

**Figure 7.** Air-ground Negotiation Protocol

160 Advances in Air Navigation Services

**Figure 6.** Simplified architecture overview

procedures.

For a better understanding of automated air-ground coordination aspects, we will focus on describing a proposed air-ground negotiation protocol (see Figure 7). This protocol represents the core of the both the ATC strategic planning tasks and the aircraft navigation planning tasks. Although new scheme of negotiation can be defined from this design, all of them will use similar functionalities to evaluate proposals and generate counter-proposals. Therefore, this protocol and its associated functionalities provide guidelines and specification enough for developing new aircraft and ATC coordination

In Figure 7, the on board computation processes are represented on the left side of the aircraft agent lifeline. On the right side of the ATC agent lifeline we can observe computation performed by ground systems. Moreover, on the right side of this ground

computation system, a new lifeline for other aircraft agents is showed.

The proposed arrival negotiation protocol can be divided into two phases that are described next:

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 163

Processes are represented by a flow diagram that links protocol messages with internal functionalities that evaluate and generate proposals. Notation used for depicting processes is showed in Figure 8. This notation is slightly different to the UML notation so that, instead of focusing on the activities it is focused on communications. Besides, we extend notation proposed by Prometheus methodology in order to include information about the different states of the air-ground negotiation protocol. These negotiating states are intended to enable automated negotiation processes whose evolution can be understood in supervisory tasks of pilots and controllers. Figure 9 shows the process carried out by the ATC while the air-ground negotiation protocol, previously presented, is

Agent processes like the described above can be implemented by means of plans. Then plans contain a set of instructions in order to: (i) carry out computations, (ii) take decisions (iii) generate or receive messages and new events. Moreover plans are to be triggered by

The agent diagram overview consists of an agent architecture representation that indicates how all these plans are organized. Therefore, it shows interaction between plans, shared data and events. In addition Prometheus methodology proposes to organize plans that share similar functionalities and data into capabilities. Figure 10 represents Prometheus notation for representing elements of the agent overview diagram. Then, Figure 11 represents the ATC agent architecture diagram overview. On it, main capabilities of the ATC agent are depicted together with data used or produced, agent inner events and communication

specific events such as arrival messages or events generated by other plans.

in progress.

messages.

**Figure 8.** Notation used wihin agent processes

#### *a. Phase 1: Before reaching Time Limit for Requesting Trajectory (TLRT)*

In this phase aircraft calculates their preferred 4D Trajectory (Traj\_0). To perform this computation, each aircraft agent uses the available information about meteorological conditions and arrival routes. This information is obtained by means of a previous communication procedure (no represented in Fig. 7) with the Meteorological Information Provider agent and the Air-space Resource Provider agent. Once the 4D trajectory is calculated, the aircraft requires clearance to the ATC to execute it. In this case, the TLRT represents a deadline time for requesting mentioned clearance.

 The ATC agent receives *Request messages* from different aircraft that are periodically processed in-batch. After receiving these messages, the ATC evaluate if requested trajectories are free of conflicts. As a result, the ATC could confirm the trajectory initially preferred by the aircraft or it could propose new constrains for a new one *(Traj\_1)*. If the aircraft is agreed with previous information, it sends a corresponding message and the communication process finalizes. But if the aircraft wish to flight an alternative trajectory (i.e. a faster one), the negotiation protocols continues in a second phase.

#### *b. Phase 2: Call For Proposal*

In this phase, the aircraft makes a second counter-proposal in order to improve the previous ATC proposal, arguing reasons for it (for example certain operational contingences). These kinds of proposals *(Traj\_2)* will be evaluated by the ATC. Those one that can be feasible will be accepted. In other case, the ATC will perform a new proposal *(Traj\_3)* that the aircraft in turn can refuse or accept. When an aircraft refuses mentioned ATC proposal, it will have to select one that satisfy previous ATC constrains. But if the aircraft accepts cited ATC proposal, it will have to wait an ATC confirmation message before implement such proposal. This confirmation is necessary due to the ATC has to analyze air traffic state after receiving several aircraft messages accepting or refusing *Traj\_3* proposals. Then the protocol ends with aircraft messages informing about details of the last cleared and accepted trajectory.

Finally note that the software implementation of messages used in this protocol can be performed by a normalized FIPA support [45].

#### **5.3. Detailed design**

Finally, in the detailed design phase, the dynamic behaviour and the internal agent architecture are projected. The dynamic behaviour is described by a set of processes that agents carry out when they interact or make decisions. The internal agent architecture is represent by means an agent overview diagram that shows how these processes are organized.

Processes are represented by a flow diagram that links protocol messages with internal functionalities that evaluate and generate proposals. Notation used for depicting processes is showed in Figure 8. This notation is slightly different to the UML notation so that, instead of focusing on the activities it is focused on communications. Besides, we extend notation proposed by Prometheus methodology in order to include information about the different states of the air-ground negotiation protocol. These negotiating states are intended to enable automated negotiation processes whose evolution can be understood in supervisory tasks of pilots and controllers. Figure 9 shows the process carried out by the ATC while the air-ground negotiation protocol, previously presented, is in progress.

Agent processes like the described above can be implemented by means of plans. Then plans contain a set of instructions in order to: (i) carry out computations, (ii) take decisions (iii) generate or receive messages and new events. Moreover plans are to be triggered by specific events such as arrival messages or events generated by other plans.

The agent diagram overview consists of an agent architecture representation that indicates how all these plans are organized. Therefore, it shows interaction between plans, shared data and events. In addition Prometheus methodology proposes to organize plans that share similar functionalities and data into capabilities. Figure 10 represents Prometheus notation for representing elements of the agent overview diagram. Then, Figure 11 represents the ATC agent architecture diagram overview. On it, main capabilities of the ATC agent are depicted together with data used or produced, agent inner events and communication messages.

**Figure 8.** Notation used wihin agent processes

162 Advances in Air Navigation Services

*b. Phase 2: Call For Proposal* 

performed by a normalized FIPA support [45].

trajectory.

organized.

**5.3. Detailed design** 

next:

The proposed arrival negotiation protocol can be divided into two phases that are described

In this phase aircraft calculates their preferred 4D Trajectory (Traj\_0). To perform this computation, each aircraft agent uses the available information about meteorological conditions and arrival routes. This information is obtained by means of a previous communication procedure (no represented in Fig. 7) with the Meteorological Information Provider agent and the Air-space Resource Provider agent. Once the 4D trajectory is calculated, the aircraft requires clearance to the ATC to execute it. In this case, the TLRT

 The ATC agent receives *Request messages* from different aircraft that are periodically processed in-batch. After receiving these messages, the ATC evaluate if requested trajectories are free of conflicts. As a result, the ATC could confirm the trajectory initially preferred by the aircraft or it could propose new constrains for a new one *(Traj\_1)*. If the aircraft is agreed with previous information, it sends a corresponding message and the communication process finalizes. But if the aircraft wish to flight an alternative trajectory

In this phase, the aircraft makes a second counter-proposal in order to improve the previous ATC proposal, arguing reasons for it (for example certain operational contingences). These kinds of proposals *(Traj\_2)* will be evaluated by the ATC. Those one that can be feasible will be accepted. In other case, the ATC will perform a new proposal *(Traj\_3)* that the aircraft in turn can refuse or accept. When an aircraft refuses mentioned ATC proposal, it will have to select one that satisfy previous ATC constrains. But if the aircraft accepts cited ATC proposal, it will have to wait an ATC confirmation message before implement such proposal. This confirmation is necessary due to the ATC has to analyze air traffic state after receiving several aircraft messages accepting or refusing *Traj\_3* proposals. Then the protocol ends with aircraft messages informing about details of the last cleared and accepted

Finally note that the software implementation of messages used in this protocol can be

Finally, in the detailed design phase, the dynamic behaviour and the internal agent architecture are projected. The dynamic behaviour is described by a set of processes that agents carry out when they interact or make decisions. The internal agent architecture is represent by means an agent overview diagram that shows how these processes are

*a. Phase 1: Before reaching Time Limit for Requesting Trajectory (TLRT)* 

represents a deadline time for requesting mentioned clearance.

(i.e. a faster one), the negotiation protocols continues in a second phase.

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 165

**Figure 10.** Prometheus notatino used in agent and capability overview diagrams

Taking into account scenarios, functionalities, processes, events and data established in

 *Manage ATC Environment Information:* This capability is associated with the goal of maintaining an updated on-board environmental knowledge. Plans for this capability capture information about weather forecast, restricted areas, air space recourses (e.g. available arrival routes and gateways), air space contingency events concerning to

 *Traffic Monitoring:* This capability checks the state and intentions of the aircraft according to air-ground agreements previously negotiated. In case of divergences, an

 *Traffic Conflict Detection-Resolution:* As its name suggests, it is responsible for detecting conflicts with other aircraft or obstacles (terrain, adverse weather areas, etc.). It also provides a set of ranked proposals for conflict resolutions. Furthermore, proposals are negotiated and/or implemented by means of other capabilities. To achieve above goals, plans of this capability are grouped into two sub-capabilities: *(i) Conflict Detection* 

previous phases, plans has been grouped into the following capabilities:

significant environmental changes and aircraft contingence events.

air-traffic contingence event is generated informing about it.

*Capability and (ii) Initial Conflict Solution Capability*.

**Figure 11.** ATC agent architecture

**Figure 9.** ATC Process Diagram for Air-Ground Negotiation Protocols

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 165

**Figure 10.** Prometheus notatino used in agent and capability overview diagrams

**Figure 11.** ATC agent architecture

164 Advances in Air Navigation Services

**Figure 9.** ATC Process Diagram for Air-Ground Negotiation Protocols

Taking into account scenarios, functionalities, processes, events and data established in previous phases, plans has been grouped into the following capabilities:


#### 166 Advances in Air Navigation Services

*Conflict Detection Capability* contains plans to implement algorithms for conflict detection. Therefore, it can be constituted by several plans each of them contains a specific model to detect short, medium and long term conflicts. Plan inputs are data about predicted trajectory, restricted areas, surrounding traffic state and intentions. Plans of this capability are triggered by events generated by plans of other capabilities that perform surveillance tasks as well as testing tasks within the trajectory planning processes. Conflict data calculated by previous plans are used by a specific plan to obtain a detailed conflict description and to generate conflict events.

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 167

Descriptors and diagrams of the components in the described conceptual model contain all the necessary information to carry out implementation. However, not all the components obtained in the three phases of the methodology have to be implemented. The executable model consists of the entities that have been developed in the detailed design phase (i.e.

As it was explained in section 4, Prometheus methodology provides a full life-cycle support tool (PDT tool) to develop multi-agent systems. Current version of PDT provides support for: *(i)* designing most the design artefacts within the Prometheus methodology, *(ii)* cross-checking for consistency and completeness for the conceptual model, *(iii)* automatic generation of skeleton code in JACK agent-oriented programming language

The conceptual model detailed above is currently at implementation phase. Although facilities of automatic code generation of PDT, we have opted for using the JADE Platform [39], cited in section 4, due to: *(i)* it is one of most extended multi-agent platforms and, *(ii)* it provides the FIPA standards [49] infrastructure for inter-agent communications and for managing software agents distributed across multiples hosts. As it was explained, architecture of JADE agent is built upon the behaviour concept rather than a plans-based architecture. Then agent plans can be generally implemented into JADE behaviours in a

On the other hand, continuous simulation requires, in nature, implementing the aircraft dynamic over a continuous-time model. It is essential to carry out real-time and humanin-the-loop simulations in order to analyse in detail and validate the design accordingly to the expected global behaviour. Also it is suitable for fast analytical simulations intended for preliminary designing and evaluation of cockpit systems and underlying mathematical models and algorithms (e.g. for 4D-trajectory guidance, conflicts detection and resolution, etc.). However, while the detailed models are not available, the proposed conceptual model enables discrete event simulation. In this case, events can be generated by random functions implemented within capabilities plans representing underlying models as *black boxes*. In this way, for an initial implementation phase, random functions to generate events are implemented into agent plans. In a later phase, the executable model can be refined when functions are replaced by specific underlying models as they

Figure 12 illustrates an adaptation of the ATC agent capacities-based architecture to a behaviours-based one using JADE behaviours described in section 4. Each one of the agent capabilities has been defined as behaviours that run in a parallel way. Previous behaviours could be progressively broken down into new behaviours, so that, at lower-level,

**6. Implementation** 

quite straightforward way.

are developed.

[48].

agents, capabilities, plans, data, events and messages).

**6.1. ATC model implementation under JADE platform** 

behaviours correspond to plans of the conceptual model.

*Initial Conflict Solution Capability* uses several inner plans to supply solutions according conflict data input. Results of these plans are used by other ones that generate conflict contingence events. Then events also contain associated information about feasible conflict solutions.

	- *Implementation of ATC procedures*. This capability has a first plan that take into account air traffic conditions to generate events that trigger plans for: (i) ATC coordination in order to receipt o transfer air traffic, (ii) planning and assigning trajectories, (iii) establishing point for initiate air-ground negotiations and (iv) assuming or delegating aircraft separation responsibilities.
	- *Strategic Separation*. This capability is modelled through two basic plans. One of them drives processes of trajectories negotiation. The second one manages other supplemental plans that implement re-negotiation processes of trajectories previously assigned to a group of aircraft and pending of execution when a contingency arise.
	- *Tactical Separation*. Plans of this capability manage processes triggered by contingencies that require this type of action (e.g. separation loss contingency when air traffic flows converge). Obviously, in the context of TBO, tactical actions should be reduced to: (i) delegate or regain the separation control role depending as a function of the air traffic state and other contingences and (ii) enable separation control protocols in extreme short-range conflicts.
	- *ATC Coordination.* This capability includes plans to coordinate for air traffic transferring between adjacent ATC units. Events that trigger these plans come from the sub-capacity ATC procedure execution. The detailed design of this capability includes a specific plan to implement ATC coordination protocols with other adjacent units.

#### **6. Implementation**

166 Advances in Air Navigation Services

conflict solutions.

capabilities:

adjacent units.

*Conflict Detection Capability* contains plans to implement algorithms for conflict detection. Therefore, it can be constituted by several plans each of them contains a specific model to detect short, medium and long term conflicts. Plan inputs are data about predicted trajectory, restricted areas, surrounding traffic state and intentions. Plans of this capability are triggered by events generated by plans of other capabilities that perform surveillance tasks as well as testing tasks within the trajectory planning processes. Conflict data calculated by previous plans are used by a specific plan to

*Initial Conflict Solution Capability* uses several inner plans to supply solutions according conflict data input. Results of these plans are used by other ones that generate conflict contingence events. Then events also contain associated information about feasible

 *Manage ATC Contingency.* This capability deal with deciding which kind of ATC procedural tasks are to be carrying out according to the information contained on received contingency events. To make decisions, plans of this capability take also into account current states and intentions of aircraft traffic. Information about the procedural tasks that have to be performed are included into contingency output events that will trigger specific plans to execute such tasks. These plans are grouped into the

 *Manage ATC Procedures*. Plans of this capability carry out strategic and tactical actions aimed to maintain aircraft separation. These plans are grouped into the next for sub-




obtain a detailed conflict description and to generate conflict events.

ATC Procedures Management capability that is described next.

assuming or delegating aircraft separation responsibilities.

control protocols in extreme short-range conflicts.

Descriptors and diagrams of the components in the described conceptual model contain all the necessary information to carry out implementation. However, not all the components obtained in the three phases of the methodology have to be implemented. The executable model consists of the entities that have been developed in the detailed design phase (i.e. agents, capabilities, plans, data, events and messages).

As it was explained in section 4, Prometheus methodology provides a full life-cycle support tool (PDT tool) to develop multi-agent systems. Current version of PDT provides support for: *(i)* designing most the design artefacts within the Prometheus methodology, *(ii)* cross-checking for consistency and completeness for the conceptual model, *(iii)* automatic generation of skeleton code in JACK agent-oriented programming language [48].

The conceptual model detailed above is currently at implementation phase. Although facilities of automatic code generation of PDT, we have opted for using the JADE Platform [39], cited in section 4, due to: *(i)* it is one of most extended multi-agent platforms and, *(ii)* it provides the FIPA standards [49] infrastructure for inter-agent communications and for managing software agents distributed across multiples hosts. As it was explained, architecture of JADE agent is built upon the behaviour concept rather than a plans-based architecture. Then agent plans can be generally implemented into JADE behaviours in a quite straightforward way.

On the other hand, continuous simulation requires, in nature, implementing the aircraft dynamic over a continuous-time model. It is essential to carry out real-time and humanin-the-loop simulations in order to analyse in detail and validate the design accordingly to the expected global behaviour. Also it is suitable for fast analytical simulations intended for preliminary designing and evaluation of cockpit systems and underlying mathematical models and algorithms (e.g. for 4D-trajectory guidance, conflicts detection and resolution, etc.). However, while the detailed models are not available, the proposed conceptual model enables discrete event simulation. In this case, events can be generated by random functions implemented within capabilities plans representing underlying models as *black boxes*. In this way, for an initial implementation phase, random functions to generate events are implemented into agent plans. In a later phase, the executable model can be refined when functions are replaced by specific underlying models as they are developed.

#### **6.1. ATC model implementation under JADE platform**

Figure 12 illustrates an adaptation of the ATC agent capacities-based architecture to a behaviours-based one using JADE behaviours described in section 4. Each one of the agent capabilities has been defined as behaviours that run in a parallel way. Previous behaviours could be progressively broken down into new behaviours, so that, at lower-level, behaviours correspond to plans of the conceptual model.

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 169

**Figure 13.** Application screenshot for the described scenario

air traffic.

the CDTI.

and the ATC agent is carried out with the following messages:

flight plan to initiate a continuous descent approach to the airport.

establishing more complex negotiations between aircraft and ATC.

To carry out communications between agents, a Communication class with specific methods has been designed. In particular, the air-ground communication between the aircraft agents

a. Messages sent by the aircraft to the ATC: message to inform about the state vector and planed route, message to inform about the possible modification of the altitudes of the

b. *Messages received in the aircraft from the ATC*: instruction messages (changing altitude, heading, speed, a flight plan waypoint, etc.) and messages of conflict detection with other aircraft. Starting from this nucleus of air-ground communications, new types of messages can be implemented in future EATS extensions with the purpose of

c. *Messages sent by the aircraft to others aircraft*: message to inform about the state vector. This air-air communication provides information to each aircraft about its surrounding

Besides the previous communications, there are other communications involving the Meteorology Information Provider agent (to obtain atmospheric information) and the Airspace Recourse Provider agent (to request the available routes). Moreover, the communication between the aircraft agent and the pseudo pilot agent represents the communication between a physicals agent (the aircraft) and a man-machine interface like

**Figure 12.** Figure 12. ATC agent architecture based on JADE Behaviours

#### **6.2. Dynamic prototype example: An experimental air traffic simulator**

As example of a JADE implementation we summarize the architecture of an Experimental Air Traffic Simulator (EATS) [32] that we have developed under a JADE support. This simulator includes agents described in the last section as well as other two agents with particular purposes into a simulation environment: the *Configuration Agent* and the *Pseudopilot Agent*.

The *Configuration Agent* is required to define the set of initial simulation parameters (e.g. aircraft type, available routes, etc. The *Pseudopilot* Agent has been designed with a twofold purpose. First, it is a desk control that allows to an unique pilot-user (named pseudopilot) to have control over several aircraft. Second, it represents a graphical display, providing significant information about the state and intentions of surrounding traffic for each selected aircraft. This interface has been implemented as a separated agent (and not like an aircraft agent component), to centralize in a unique interface the access to each aircraft. Besides, it plays an important role (especially in the near future scenarios) to design and evaluate specific on-board man-machine interfaces like the CDTI cockpit display [50]. The CDTI allows seeing the surrounding traffic and, what is more relevant, the intentions of the surrounding aircraft. To access to a particular aircraft, a mouse click over the icon symbol is required. Once the aircraft is selected, it is placed at the central position of the *pseudopilot view window*, and the movement and the position of other aircraft are represented in relation to it. At the same time, the control window of the selected aircraft will be opened.

Then air-traffic controllers and pilots can interact with agents by means of two types of consoles. In one of them an Air Traffic Controller can monitor the positions of different aircraft and send several data instructions to a specific aircraft. In the other one a user pseudopilot that receives orders from the ATC (via voice or via data messages), carries out the necessary actions to fly the aircraft according to these orders. Besides, pseudopilot agent can be configured to automatically execute ATC mentioned data instructions.

Figure 13 shows screenshot of this application. It represents a view of the ATC interface constituted by and screen for displaying the traffic and a window console for interchanging data and instructions with a particular aircraft. Besides, in the same screenshot two aircraft control windows (A320 and Cessna) are deployed.

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 169

**Figure 13.** Application screenshot for the described scenario

168 Advances in Air Navigation Services

**Figure 12.** Figure 12. ATC agent architecture based on JADE Behaviours

**6.2. Dynamic prototype example: An experimental air traffic simulator** 

to it. At the same time, the control window of the selected aircraft will be opened.

can be configured to automatically execute ATC mentioned data instructions.

control windows (A320 and Cessna) are deployed.

Then air-traffic controllers and pilots can interact with agents by means of two types of consoles. In one of them an Air Traffic Controller can monitor the positions of different aircraft and send several data instructions to a specific aircraft. In the other one a user pseudopilot that receives orders from the ATC (via voice or via data messages), carries out the necessary actions to fly the aircraft according to these orders. Besides, pseudopilot agent

Figure 13 shows screenshot of this application. It represents a view of the ATC interface constituted by and screen for displaying the traffic and a window console for interchanging data and instructions with a particular aircraft. Besides, in the same screenshot two aircraft

As example of a JADE implementation we summarize the architecture of an Experimental Air Traffic Simulator (EATS) [32] that we have developed under a JADE support. This simulator includes agents described in the last section as well as other two agents with particular purposes into a simulation environment: the *Configuration Agent* and the *Pseudopilot Agent*.

The *Configuration Agent* is required to define the set of initial simulation parameters (e.g. aircraft type, available routes, etc. The *Pseudopilot* Agent has been designed with a twofold purpose. First, it is a desk control that allows to an unique pilot-user (named pseudopilot) to have control over several aircraft. Second, it represents a graphical display, providing significant information about the state and intentions of surrounding traffic for each selected aircraft. This interface has been implemented as a separated agent (and not like an aircraft agent component), to centralize in a unique interface the access to each aircraft. Besides, it plays an important role (especially in the near future scenarios) to design and evaluate specific on-board man-machine interfaces like the CDTI cockpit display [50]. The CDTI allows seeing the surrounding traffic and, what is more relevant, the intentions of the surrounding aircraft. To access to a particular aircraft, a mouse click over the icon symbol is required. Once the aircraft is selected, it is placed at the central position of the *pseudopilot view window*, and the movement and the position of other aircraft are represented in relation

To carry out communications between agents, a Communication class with specific methods has been designed. In particular, the air-ground communication between the aircraft agents and the ATC agent is carried out with the following messages:


Besides the previous communications, there are other communications involving the Meteorology Information Provider agent (to obtain atmospheric information) and the Airspace Recourse Provider agent (to request the available routes). Moreover, the communication between the aircraft agent and the pseudo pilot agent represents the communication between a physicals agent (the aircraft) and a man-machine interface like the CDTI.

Apart from above infrastructure for agent communications, the current prototype version implements the aircraft aerodynamic and simple agent making-decision mechanisms. Thus, aircraft agents are able to fly according a three dimensional flight plans or ATC vector instructions (i.e. heading, altitude and speeds orders). The aircraft aerodynamic model is based on a simplified point mass model that is described in [51]. In addition some navigation coordination tasks have been implemented on it (e.g. modifying arrival flight plan to perform a continuous descent and communicate this modification to the ATC agent via data message). In the same way, the ATC agent can detect missed separation conflict and provide primary conflicts resolution

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 171

 The overall system architecture combines information about roles of the air traffic entities with communication protocols that agents needs in order to improve their knowledge about the environment, agents states and intentions. Protocols are, also, a

key aspect into the agent negotiation processes to achieve their respective goals. It illustrates how agent processes can be implemented by a set of several plans into agent. Plans are organized into several capabilities. Besides, this modular agent architecture based on plans allows a latter inclusion of new plans for implementing new procedures and functionalities. Moreover it is particularly important for obtaining

 Finally, the model connects in a natural way those components that represent the dynamic perspective from those one than give a structural vision of the model. Protocols and processes, that model the dynamic behaviour, represent the core of the procedures. In the other hand capabilities are a high level representation of the systems required by ATC, aircraft and other air traffic entities to execute their task in a

After this first version of a simulation platform has been implemented and validated, new procedures, functionalities and underlying models will be included to be analysed as they are designed and included in the system following the described methodology. Furthermore, directions for future works include the extension of this conceptual model to gate-to-gate operations, as well as obtaining a full executable model for analytical

This work was funded by Spanish Ministry of Economy and Competitiveness under grant TEC2011-28626 C01-C02, and by the Government of Madrid under grant S2009/TIC-1485

[1] Ljungberg M, Lucas A (1992) The OASIS air-traffic management system. Proceedings of the Second Paciffic Rim International Conference on Artificial Intelligence, PRICAI.

robust software models.

procedural manner.

**Author details** 

José Miguel Canino

Juan Besada Portas

**Acknowledgement** 

(CONTEXTS).

**8. References** 

simulation according to the described requirements.

*University of Las Palmas de Gran Canaria, Spain* 

*University Polytechnic of Madrid, Spain*  José Manuel Molina and Jesús García *University of Carlos III of Madrid, Spain* 

Then, this architecture is intended as later extensions in order to add new algorithms (i.e. conflict detection and resolution algorithms, arrival sequence algorithms, etc.), air-air and air-ground negotiations protocols, human-machine interfaces and decision-making support systems, etc.

#### **7. Conclusions**

A summary description of a proposed conceptual model that represents TBO scenarios as a multi-agent system has been presented in this chapter. The aim of this design was to illustrate how current agent-oriented methodologies have been successfully applied to achieve highly structured representations of these scenarios and, therefore, they are a powerful design tool previous to a full implementation of future operational concepts.

A practical and formal methodological approach has been used to analyse and design the mentioned scenarios in a structured and consistent manner. By means of an iterative topdown modelling process the detailed agents architecture were designed based on capabilities, plans, events, and data structures.

The ATC view point was also described in this chapter through its inner architecture design. This architecture is oriented to execute several processes in order to plan, execute or modify trajectories in a coordinated way.

This approach has been based on guidelines provides by the recent Prometheus methodology. It has showed to be a suitable methodology for building models of nextgeneration ATM systems in the light of the following features:


After this first version of a simulation platform has been implemented and validated, new procedures, functionalities and underlying models will be included to be analysed as they are designed and included in the system following the described methodology. Furthermore, directions for future works include the extension of this conceptual model to gate-to-gate operations, as well as obtaining a full executable model for analytical simulation according to the described requirements.

### **Author details**

170 Advances in Air Navigation Services

provide primary conflicts resolution

capabilities, plans, events, and data structures.

architecture design and detailed design.

generation ATM systems in the light of the following features:

system as well as its main data, actions and perceptions.

trajectories in a coordinated way.

systems, etc.

**7. Conclusions** 

Apart from above infrastructure for agent communications, the current prototype version implements the aircraft aerodynamic and simple agent making-decision mechanisms. Thus, aircraft agents are able to fly according a three dimensional flight plans or ATC vector instructions (i.e. heading, altitude and speeds orders). The aircraft aerodynamic model is based on a simplified point mass model that is described in [51]. In addition some navigation coordination tasks have been implemented on it (e.g. modifying arrival flight plan to perform a continuous descent and communicate this modification to the ATC agent via data message). In the same way, the ATC agent can detect missed separation conflict and

Then, this architecture is intended as later extensions in order to add new algorithms (i.e. conflict detection and resolution algorithms, arrival sequence algorithms, etc.), air-air and air-ground negotiations protocols, human-machine interfaces and decision-making support

A summary description of a proposed conceptual model that represents TBO scenarios as a multi-agent system has been presented in this chapter. The aim of this design was to illustrate how current agent-oriented methodologies have been successfully applied to achieve highly structured representations of these scenarios and, therefore, they are a powerful design tool previous to a full implementation of future operational concepts.

A practical and formal methodological approach has been used to analyse and design the mentioned scenarios in a structured and consistent manner. By means of an iterative topdown modelling process the detailed agents architecture were designed based on

The ATC view point was also described in this chapter through its inner architecture design. This architecture is oriented to execute several processes in order to plan, execute or modify

This approach has been based on guidelines provides by the recent Prometheus methodology. It has showed to be a suitable methodology for building models of next-

 This approach achieves the goals of obtaining a highly structured model with several levels of abstractions. This structured nature allows a suitable integrity and consistence verification of the model on each of its three design phases: system specification,

 Also, Prometheus methodology provides proper guidelines for obtaining a system specification based on a goals hierarchical structure. These goals were identified from an organized set of scenarios that illustrate several aspects of the operational behaviour of the system. Goal at lowest level are used for defining required functionalities of the José Miguel Canino *University of Las Palmas de Gran Canaria, Spain* 

Juan Besada Portas *University Polytechnic of Madrid, Spain* 

José Manuel Molina and Jesús García *University of Carlos III of Madrid, Spain* 

### **Acknowledgement**

This work was funded by Spanish Ministry of Economy and Competitiveness under grant TEC2011-28626 C01-C02, and by the Government of Madrid under grant S2009/TIC-1485 (CONTEXTS).

#### **8. References**

[1] Ljungberg M, Lucas A (1992) The OASIS air-traffic management system. Proceedings of the Second Paciffic Rim International Conference on Artificial Intelligence, PRICAI.

	- [2] Garcia, J. L. (1990). MAESTRO-A metering and spacing tool. American Control Conference, 1990 (pp. 502–507).

A Multi-Agent Approach for Designing Next Generation of Air Traffic Systems 173

[18] Callantine TJ, Palmer EA, Homola J, Mercer J Prevot T (2006). Agent-Based Assessment of Trajectory-Oriented Operations with Limited Delegation. 25th Digital Avionics

[19] Wangermann J P, Stengel R F (1998) Principled negotiation between intelligent agents: a model for air traffic management. Artificial Intelligence in Engineering, 12(3), 177-187. [20] Wangermann J P, Stengel R F (1999) Optimization and Coordination of Multiagent Systems Using Principled Negotiation. Journal of Guidance, Control and Dynamics,

[21] Wangermann, J P and Stengel R F (1996) Distributed optimization and principled negotiation for advancedair traffic management. Proceedings of the 1996 IEEE

[22] Harper K A, Mulgund S S, Guarino S L, Mehta A V and Zacharias G L (1999) Air traffic controller agent model for Free Flight. AIAA Guidance, Navigation, and Control

[23] Stengel R F (1993) Toward intelligent flight control. Systems, Man and Cybernetics.

[24] Belkin B L, Stengel, R F (1987) Cooperative rule-based systems for aircraft control. 26th

[25] Stengel R F, Niehaus A (1989). Intelligent guidance for headway and lane control.

[26] Shandy S, Valasek J (2001) Intelligent agent for aircracft collision avoidance. AIAA

[27] Rong J, 2002, Intelligent Executive Guidance Agent For Free Flight. AIAA-2002-15 .

[28] Rong J, Ding Y, Valasek J, Painter J (2003) Intelligent system design with fixed-base simulation validation for general aviation. Proc. IEEE International Symposium on

[29] Painter J H (2002) Cockpit multi-agent for distributed air traffic management. En AIAA

[30] Ding Y, Rong J, Valasek, J (2003) Automation Capabilities Analysis Methodology for Non-Controlled Airports. AIAA Modeling and Simulation Technologies Conference

[31] Satapathy G, Manikonda V (2004). Agent Infrastructures for Modeling and Simulation

[32] Canino J M , García J, Besasa J., Gómez L (2008) EATS: An Agent-Based Air Traffic Simulator. IADIS International Journal of Computer Science and Information Systems,

[33] Iglesias CA, Garijo M ,Gonzalez J C, Velasci J R (1996) A Methodological Proposal for

[34] Giunchiglia F, Mylopoulos J, Perini A(2002) The Tropos Software Development Methodology: Processes, Models and Diagrams. 2002 Autonomous Agents and Multi-

Multiagent Systems Development Extending CommonKADS

Guidance, Navigation, and Control Conference and Exhibit. Monterey, CA.

Systems Conf., Portland, OR.

International Symposium on. pp. 156-161.

IEEE Transactions on, 23(6), 1699-1717.

Intelligent Control, Houston, Texas.

of CNS in the NAS. En Fairfax, VA..

Agent Systems (AAMAS 2002), Bologna, Italy

and Exhibit. Austin, Texas.

http://citeseernj.nec.com/

Vol. 3, Issue 2.

Conference and Exhibit, pp. 288-301, Portland, OR.

IEEE Conference on Decision & Control, Los Angeles, CA

Engineering Applications of Artificial Intelligence, 2(4), 307-314.

Guidance, Navigation, and Control Conference, Montreal, Canada.

22(1), 43-50.

Reno, NV


http://www.aviationsystemsdivision.arc.nasa.gov/research/foundations/pas.shtml


[18] Callantine TJ, Palmer EA, Homola J, Mercer J Prevot T (2006). Agent-Based Assessment of Trajectory-Oriented Operations with Limited Delegation. 25th Digital Avionics Systems Conf., Portland, OR.

172 Advances in Air Navigation Services

html#overview

09pharefinal10.pdf

pdf

Conference, 1990 (pp. 502–507).

[4] NASA (2012), Overview of CTAS.

RTCA, Inc. Washington DC.

http://users.skynet.be/atcsim/

Conference and Exhibit, Reston, VA, USA.

San Diego, USA.

Environment 19 p(SEE N 92-19041 10-04).

Surveillance Conference, 2007. ICNS'07 (pp. 1–10).

http://www.nlr.nl/documents/flyers/f075-07.pdf

Conference, Monterey, CA, 1993, pp. 234–242. Available:

Navigation, vol. 61, no. 2, pp. 195–208

[2] Garcia, J. L. (1990). MAESTRO-A metering and spacing tool. American Control

[3] Schubert, M. (1990). COMPAS system concept. The COMPAS System in the ATC

http://www.aviationsystemsdivision.arc.nasa.gov/research/foundations/sw\_overview.s

[5] van Gool M, Schoröter H (1999). PHARE Final Report, EUROCONTROL, Bruxelles. Availlable: http://www.eurocontrol.int/phare/gallery/content/public/documents/99-70-

[6] RTCA (1995) Report of the RTCA Board of Directors' Select Committee on Free Flight,

[7] Wilson, I. A. . (2007). 4-Dimensional Trajectories and Automation Connotations and Lessons learned from past research. Integrated Communications, Navigation and

[8] Brooker P (2008) SESAR and NextGen: Investing in New Paradigms. Journal of

[9] NASA (2006) Next Generation Air Transportation System (NGATS) Air Traffic

[10] [10] NLR (2002) The NLR Air Traffic Control Research Simulator (NARSIM) Available:

[11] Weske R and Danek G (1993) Pseudo Aircraft Systems- A multi-aircraft simulation system for air traffic control research. AIAA Flight Simulation Technologies

http://www.aviationsystemsdivision.arc.nasa.gov/research/foundations/pas.shtml

[14] Prevot T (2002) Exploring the many perspectives of distributed air traffic management: The Multi Aircraft Control System MACS. Proceedings of the HCI-Aero, 149-154. [15] Clari M, Ruigrok R, Heesbeen B and Groeneweg J (2002) Research Flight Simulation of Future Autonomous Aircraft Operations. Proceedings of Winter Simulation Conference,

[16] Sweet D N, Manikonda V, Aronson, J S, Roth K, Blake, M (2002) Fast-time Simulation System for Analysis of Advanced Air Transportation Concepts· Proceedings of the

[17] Callantine T J, Homola J, Prevot T, Palmer E A (2006) Concept Investigation via Air-Ground Simulation with Embedded Agents. Modeling and Simulation Technologies

AIAA Modeling and Simulation Technologies Conference, Monterey, CA.

[12] FAA (2009) Target Generation Facility. http://hf.tc.faa.gov/capabilities/tgf.htm [13] Vic D (2011) ATC interactive for the future of Air Traffic Control. URL:

http://cafefoundation.org/v2/pdf\_tech/NASA.Aeronautics/PAV.NASA.ARMD.NGATS.

Management (ATM)-Airspace Project. Reference Material. Available:


174 Advances in Air Navigation Services

Seattle, USA, pp. 360-361.

Systems, 3, (3), 285-312

House.

consulted at December 2006.

Lecture notes in computer science, 94-109.

Intelligence (AAAI), Chicago, Illinois, USA.

Computing, 2004, vol. 8, pp. 63–71.

Bordini et al. , pp. 175–193.

Wiley Series in Agent Technology, Hardcover.

http://www.fipa.org/repository/standardspecs.html

Research Center, Moffett Field, CA and Hampton, VA.

Specification, Version J. http://www.24.org/specs/2400037/

USA/Europe Air Traffic Management R&D Seminar. Baltimore, MD.

agents. Lecture Notes in Computer Science, 174-185.

Springer, January 2001, 207-221.

[35] Nwana H S, Ndumu D T, Lee L C, Collis J C (1999) ZEUS: A Toolkit and Approach for Building Distributed Multi-Agent Systems. J. M. Bradshaw, ed., Proceedings of the Third International Conference on Autonomous Agents (Agents '99), ACM Press,

[36] Wood M F, DeLoach S A, (2001) An Overview of the Multiagent Systems Engineering Methodology. Agent-Oriented Software Engineering, Volume 1957 of LNCS, Berlin:

[37] Wooldridge M, Jennings N R, Kinny D (2000) The Gaia Methodology for Agent-Oriented Analysis and Design. Journal of Autonomous Agents and Multi-Agent

[38] Pavón J, Gómez-Sanz J (2006) INGENIAS web site: http:// grasia.fdi.ucm.es/ingenias/,

[39] Cernuzzi L, Rossi G (2002) On the evaluation of agent oriented modeling methods. En

[40] Sturm A, Shehor O (2004) A Framework for Evaluating Agent-Oriented Methodologies.

[41] Luck M M, Ashri R, D'Inverno M (2004) Agent-Based Software Development, Artech

[42] Padgham L Winikoff M (2004) Prometheus: A methodology for developing intelligent

[43] Padgham L, Thangarajah J, Winikoff M (2008) Prometheus Design Tool, (System Demonstration), Proceedings of the Twenty-Third AAAI Conference on Artificial

[44] Luigi F, Caire G, Greenwood D (2007) Developing Multi-Agent Systems with JADE.

[45] Foundation for Intelligent Physical Agents –FIPA- (2007) Standard Status Specifications,

[46] Sorensen, John A, (2000), Detailed Description for CE-11 Terminal Arrival: Self Spacing for Merging and In-trail Separation, NASA Ames Research Center and NASA Langley

[47] Huget M P (2004) Agent uml notation for multiagent system design. IEEE Internet

[48] Winikoff M (2004) JACK TM intelligent agents: An industrial strength platform",

[49] Foundation for Intelligent Physical Agents. 24 Communicative Act Library

[50] Bone RS (2005) Cockpit Display of Traffic Information (CDTI) Assisted Visual Separation (CAVS): Pilot Acceptability of a Spacing Task During a Visual Approach. 6

[51] Glover W., Lygeros J. (2004). A Multi-Aircraft Model for Conflict Detection and Resolution Algorithm Evaluation. Technical Report WP1, Deliverable D1.3. Distributed Control and Stochastic Analysis of Hybrid Systems Supporting Safety Critical Real-

Time Systems Design Project (HYBRIDGE). European Commission, Brussels.

Proceedings of Agent Oriented Methodology Workshop, Seattle, November.

### *Edited by Tone Magister*

Provision of air navigation services entered a new era of performance scheme. The performance scheme provides binding targets on four key performance areas of safety, capacity, environment and cost-efficiency. It is imposed that targets are fully achieved, but it is not prescribed how, this being typical for the performance based and goal oriented regulation. Those key performance areas are interlaced by proportional and inversely proportional interdependencies. Namely, for example and simplified into one sentence; if one aims to increase sector capacity with existing human resources (constant staff costs) and not investing into the technology (constant support cost) to achieve improved cost-efficiency of service provision, the resulting overloaded system might unlock the Pandora box of latent safety issues. Since failure is not an option, we - the general, migrating and traveling public, airspace users, airport operators, air navigation services providers and the economy - will gain attaining the goals of performance scheme in the process. However, un-answered cardinal question is what is the winning strategy? This book provides do-not-forget-peculiarities insight into the elements of new business model of air navigation services provision as evolution of the latter became essential.

Advances in Air Navigation Services

Advances in

Air Navigation Services

*Edited by Tone Magister*

Photo by RomoloTavani / iStock