Background: Within the context of EATCHIP (The European ATC Harmonisation and Integration Programme) and the European Air Traffic Management Program (EATMP), a number of automated functions have been defined and are being developed with a view to supporting ATC controllers in their decision-making process.

One of these ATC tools is Medium Term Conflict Detection (MTCD). Definitions, specifications and implementation recommendations are contained in the so-called “green books”, i.e. the Eurocontrol document “Operational Requirements for EATCHIP Phase 3, Volume 5, MTCD”.

Even though MTCD is included in the national EATCHIP Convergence and Implementation Plan (CIP) of many European Civil Aviation Conference (ECAC) countries, only a couple of fully operational and mature applications can be found in Europe. Among them are Area Conflict Detection (ACOD), which is used by ATC Netherlands (LVNL), and the Medium Term Conflict Detection system used by ATC Latvia (LGS) in their ATRACC system.

A conflict is defined as a state in which the closest distance between the (probable) positions of an aircraft and a specific object is less than the minimum required legal separation plus an uncertainty buffer. Such a specific object can be either the probable position of another aircraft, a special-use airspace, or the area below the lowest usable flight level (FL) of an airspace.

A dramatic example of the consequences of missing conflict detection is the aircraft accident inJuly 2002, when a Russian passenger Tu-154 liner of Barhkir Airlines and a Boeing-757 freight aircraft of the DHL international transportation company collided at an altitude of 11,000 metres in the area of Bodensee in Germany.An operationalMTCD might have prevented this catastrophe.

Eurocontrol took great interest in the implementation of MTCD in the ATRACC system and has, therefore, performed an evaluation site visit to the Riga ATCC. Issues under investigation comprised MTCD performance, HMI design, controller acceptance, strategies, workload and situational awareness. The present article is, in part, based on Eurocontrol’s evaluation report and makes use of some of its text and illustrations.

isa Satiksme, LGS – the service provider in Latvia

Having taken the initial steps of technical and technological modernization in 1991, LGS has today developed into one of the most professional air navigation service providers in Europe. Completion of LGS’ modernization programme has made the company fully compatible with the standards of the European organisation for the Safety of Air Navigation, EUROCONTROLLGS has chosen a phased implementation approach when introducing its ATM system.

The first contract for this implementation, signed in January 1996 with the Swedish company Si ATM, contained 4 phases resulting in an ATM product based on high-level requirements, resulting from studies of advanced air traffic control concepts, including multi–radar tracking, advanced flight plan data integration, predicted flight trajectories, OLDI, silent co-ordination and paperless HMI. The system was fully certified for air traffic control by the Latvian Civil Aviation Administration in November 1999.

Since then, the ATRACC system at Riga ATCC has been updated with ATM Added functions according to EUROCONTROL recommendations and has been supplied with a set of ATC tools (accepted in October 2001) comprising:

• Monitoring Aids
• Medium Term Conflict Detection (MTCD)
• Short Term Conflict Alert
• Minimum Safe Altitude Warning
• Area Penetration Warning
• Highly automated support for RVSM and 8,33 KHz frequency spacing

Implementation environment

The ATRACC system comprises an ATM system for tower, approach and area control of the Riga FIR. The RIGA FIR has the following neighbouring FIRs (clockwise from the north):

• Estonia (Tallinn FIR)
• Russia (Velikiye Luki FIR)
• Byelorusssia (Minsk FIR)
• Lithuania (Vilnius FIR)
• Sweden (Malmö and Stockholm FIR)

The Riga airspace consists of three ACC sectors: the east, northwest and southwest sector, where the northwest and southwest sectors are frequently combined into one, the west sector.

Figure 1: Riga FIR and sector definition

The Riga airspace is divided into different airspace classes. FL195 through FL460 is all Class A airspace. Above FL460, the airspace is class C and so is the managed airspace below FL195. Unmanaged airspace is defined as Class G airspace. Figure 2: Riga airspace classes definition

Figure 2: Riga airspace classes definition

The Riga East sector borders on the Russian airspace. This boundary is of particular interest because of differences in altitude indication, RVSM availability and squawk code definition.

Riga airspace	Russian airspace
Altitude in feet	Altitude in meters
RVSM airspace	Non-RVSM airspace
4-digit octal squawk codes	5-digit decimal squawk codes

The most important traffic streams in the RIGA FIR are:

• From southwest to northeast (and vice versa) through the northwest part of the west sector; this is mainly traffic between central Europe and the Far East. This traffic enters and leaves the sector almost at the same (cruising) level.
• From the north to the south (and vice versa) through the centre of the FIR;this is mainly traffic between Finland and the eastern part of Europe.
• From the west to the east (and vice versa) through the centre of the FIR; this is mainly traffic between Sweden, Denmark, Latvia and Russia.

Implementation directives

Together with the company Si ATM, LGS successfully used the Eurocontrol requirement documents to implement the MTCD functionality within the ATRACC system. The entire development process is a good example of a stepwise implementation of functionality and of a flexible attitude of the developers as well as the users of the system.

The relevant part of Eurocontrol’s “green books” together with other closely related Eurocontrol operational requirement documents for MONitoring Aids (MONA) and Safety NETs (SNET) were used during the implementation. These documents were even included as part of the contract between LGS and Si ATM. The Trajectory Predictor (TP) previously delivered by Si ATM, already comprised the necessary functionality for the additional requirements generated by MTCD. The functionality of this TP follows the Eurocontrol requirements for a TP to a great extent.

No real problems were encountered during the development and implementation of the ATM Added functions. The Eurocontrol documents were considered very helpful, even if some requirements called for additional specification work.

MTCD – Functionality Overview

Medium Term Conflict Detection, subsequently referred to as MTCD, is a set of functions that assist controllers in their continuous monitoring of the air situation, by detecting potential conflicts and airspace penetrations, based on the predicted flight trajectories, and by providing timely information to enable the affected controllers to assess and, if necessary, resolve the situation by taking deliberate, corrective action. Additionally, MTCD provides a facility for handling tentative flight trajectories, enabling controllers to assess the potential effects of an intended action (a reroute, cleared level change or ordered speed input) leading to a change in the existing trajectory for a flight.

MTCD processing employs the following data:

• Predicted flight trajectory data, determined by trajectory calculation from the requested route, aircraft performance parameter data, and wind and temperature data. During the lifetime of the flight, the predicted flight trajectory is automatically refined by MONA, and updated via given clearances.
• Tentative trajectories, which are based on existing flight trajectories, to which experimental controller modifications have been applied, are also processed by MTCD on an individual basis.
• MTCD parameters defining separation criteria, uncertainties, prediction horizon, calculation frequency and special-use airspace, called MTCD volumes.

MTCD uses the predicted flight trajectory data and related parameters to check for Conflicts and Airspace Penetration. This check is performed on all flights for which the related flight plans are either pre-active or active - the check is made to determine potential conflicts or examine if a particular flight is predicted to enter any defined MTCD volume. On positions is superposed uncertainty in lateral, longitudinal and vertical dimensions forming an uncertainty volume centred on the flights nominal predicted positions.

Detected conflicts are presented in aConflict And Risk Display (CARD).

Below are given some examples of MTCD system parameters. Certain parameters can be defined individually for different parts of the airspace.

Typical parameter values in the en-route airspace are:

• Lateral separation outside RVSM air space5 NM
• Lateral separation within or below RVSM air space 5 NM
• Vertical separation outside RVSM air space 1750 feet
• Vertical separation within or below RVSM air space 750 feet

Typical parameter values in terminal airspace are:

• Longitudinal separation Heavy – Heavy4 NM
• Longitudinal separation Heavy – Light 6 NM
• Longitudinal separation Heavy – Medium 5 NM
• Longitudinal separation Light – Heavy 5 NM
• Etc.

Typical parameter values for uncertainties are:

• Lateral uncertainty 1,5 NM
• Longitudinal uncertainty for flights under MONA monitoring 1 NM
• Uncertainty in ETO FIR boundary60 seconds
• Uncertainty in ATO60 seconds
• Lateral uncertainty in holding8 NM
• Holding leave time uncertainty 60 seconds
• Ground speed uncertainty3%
• Vertical uncertainty in level flight 100 feet
• Vertical uncertainty in climb 200 feet
• Vertical uncertainty in descent200 feet

Some other MTCD parameters are:

Detection horizon 20 minutes

Recalculation cycle 1 minute

(Recalculation is also done at each trajectory update)

Although the system allows for it, different parameter settings for MTCD for different sectors or types of airspace (ACC and APP) were not made in the ATRACC system from the start. Experience showed, however, that individual parameter settings were required in order to decrease the number of nuisance alerts in the Approach sector.

In accordance with Eurocontrol requirements, a number of flight phases are handled: Departure, Arrival, En-route and Holding phase.

During the implementation and testing, it became clear that the use of pre-active flights induced a lot of undesired alerts because of the large uncertainties relating to such flights. Therefore, different filters were implemented to allow individual selection of the conflicts to be displayed and to reduce the amount of false alerts.

The following filters were introduced:

• Show Arrival Phase Conflicts
• Show Departure Phase Conflicts
• Show En-route Phase Conflicts
• Show Holding Phase Conflicts
• Show Conflicts involving Pre-active Flights (Nominal route)
• Show Conflicts involving Flights which have received Advanced Boundary Information (ABI) / Preliminary Activation message (PAC)

MTCD performance

The MTCD implemented in the ATRACC system is stable and provides the controller with information on possible conflict situations. In case of a potential conflict between two aircraft, the probability is high that this conflict will be timely detected by MTCD and presented accordingly in the CARD window.

The frequent changes in speed and heading in the Approach sector makes the trajectory prediction there unstable. MTCD is therefore somewhat sensitive in the Approach sector, even if a number of alerts often disappear after a short time. Minimizing the number of nuisance alerts requires continuous tuning. Most of the nuisance alerts in the Approach sector have been removed by parameter tuning.

Controller acceptance of MTCD

The air traffic controllers at LGS are very positive to MTCD in en-route control. They appreciate MTCD greatly as a support tool that helps them separate traffic safely. From the controller point of view, the occurrence of nuisance alerts does not compromise the benefits of MTCD. A reason for this is that, given the traffic loads in the Latvian airspace, controllers have enough time to investigate MTCD alerts in detail and to decide whether the situation actually requires action or not. Thus, with Riga traffic levels, filtering of nuisance alerts is not experienced as outweighing the benefits of having an additional safety net.

Working methods and strategies

The air traffic controllers’ positive attitude to MTCD is, at least partially, due to the introduction strategy applied by LGS: The management did not prescribe a certain way of working with MTCD, but left the working method largely up to the controllers. In doing so, LGS managed to avoid problems in the introduction of automated tools, such as fear of de-qualification and loss of control over one’s task. The directive from management was to use MTCD information as a trigger for potential problems, and allow each controller to deal with the situation on the basis of his own experience.

It should be pointed out, though, that the controllers’ strategies are tailored to a situation in which traffic levels are fairly low. With the traffic levels in Riga, controllers have enough time to scan the Radar Display and also check the CARD regularly (which is positioned on a separate screen). Furthermore, they have enough time to investigate all MTCD alerts and decide whether these alerts are relevant or irrelevant for their task. With a higher traffic load, this might not be feasible. A busy traffic situation might not allow the controller to avert his or her gaze from the radar display to the information display in order to monitor MTCD information.

Conclusion

MTCD is a complete set of tools that will assist the ATC controller in detecting, on a planning basis, aircraft conflicts, airspace penetrations and ground proximities. MTCD supports direct routing. It is a flexible tool, based on operational requirements of administrations in different EUROCONTROL states. The experiences from the MTCD implementation in Riga show that, with the proper approach from management and supplier, this important functionality can be implemented with promptness and ease, and be well received by the ATC controllers. Eurocontrol’s evaluation report points out that the successful development process was largely due to the stepwise implementation of functionality and the flexible attitude of both the developers and the system users.

Author Information - Christer Schörling

President & CEO

Christer Schörling is the President & CEO of the Swedish Company Si ATM.
He has dedicated most of his professional life to ATM systems and considerable time outside of Sweden. This fact reflects his personal interest and character. Mr Schörling started his ATM career 1976 participating in the project TERCAS, a Swedish delivery of ATC systems to Moscow, Kiev and MineralnyeVody. He has since then got in contact with most aspects of ATM systems working particularly with operational matters. Mr Schörling has managed a large number of projects to successful endings for example the delivery of the nationwide system to Latvia for the Riga FIR.

Search the site

Search Query

Search Query