SubscribeProject presentation ATRACC (Air Traffic Riga Area Control Centre) is an ATM system for area, approach and tower Control of the Riga FIR. The system has been designed, produced and implemented by the Swedish company Systemintegrering AB for and together with Latvijas Gaisa Satiksme, the Latvian authority responsible for air navigation services in the Latvian airspace.
Summary of features
ATRACC features some truly pioneering ingredients. The project is 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 (On-Line Data Interchange), silent co-ordination and paperless HMI. Especially as regards the latter, i.e. silent co-ordination and paperless HMI, ATRACC is one of the very first projects to have ever implemented these functions in full for area, approach and tower control.
From a functional point of view, the system consists of two main components: a Primary System, providing the full functionality described above, and a Radar Bypass System for use if the primary system should fail.
Controllers are given the following main support:
- Access to the current traffic situation
- Provided by flight symbols in radar window
- Radar By-pass System
- Access to future (medium term) traffic situation for planning
- Provided by different kind of lists in particular; point, entry, departure and arrival lists
- Support for silent coordination’s
- Between control sectors. (Coordinated level and pointer symbol transfer)
- With adjacent FIRs via OLDI, (ABI, PAC and ACT)
- Support for given clearances
- For clearances during the departure and arrival phases using lists
- For level, speed and heading clearances using the label or lists
- Jurisdiction handling
- User Authorisation
- Airspace jurisdiction
- Flight jurisdiction
- Special functionality
ATRACC emerges from a rudimentary radar presentation unit, developed earlier by Systemintegrering for the Swedish CAA. Thus a substantial development effort has been required.
The ATRACC contract was signed in January 1996 and the major part of the system was in operational use as early as December 1998. This successful outcome has been largely due to the two main characteristics of the project model: phased implementation in well-defined steps and strong customer involvement throughout the project.
Functional blocks
Four main functional blocks are defined:
- The Flight Plan Data Management block
- The ATC Functions
- The Support Functional block and
- The ATC-Simulator.
The distinct border between the Flight Plan Data Management block and the ATC Functional block should be noted. This means that a Flight Data Assistant, (FDA) is working with Repetitive Flight Plans, (RPLs) and passive Flight Plans, (FPLs) in the Flight Plan Data Management block while the ATC controller is working with active FPLs in the ATC Functional block.
Flight plan data management is available at flight data assistant working positions. The Flight Data Assistant HMI has efficient support for editing, browsing, queue handling and specification of complex search criteria.
RPLs can be searched, created, modified and deleted manually, but also automatically based on airline time schedules on data media.
FPLs are normally created automatically from RPLs or received from AFTN. They can also be searched, created, modified and deleted manually.
Received AFTN and OLDI messages are processed and checked automatically and produce updates of concerned FPLs.
Billing data is automatically submitted to external systems at FPL termination.
For RPLs and FPLs both, route analysis is done and route details are examined against the local airspace structure for compliance with ICAO rules.
The airspace structure is defined by means of system parameters.
ATC functions are available at controller working positions. Controller interaction with flights is performed through extensive use of lists and flight symbols.
A trajectory describing the flight path in airspace is calculated with consideration to aircraft performance characteristics and current weather data.
The trajectory’s coverage of ATC sectors determines the distribution of flight data to working positions
Data from PSR and SSR radar stations is processed by means of an advanced centralised true multi-radar tracker. The resulting system tracks are associated with FPLs.
Flight symbols comprising surveillance and flight plan information are presented to controllers.
AIS data is received, processed, stored and presented to controllers.
The Support functional block contains a parameter system making the system easily adaptable to any operational environment by means of extensive use of system parameters.
In the Recording and Playback data is continuously recorded and at playback, operational scenarios are recreated at a controller work position.
System Monitoring and Control is performed by means of graphical presentation and tools for diagnostics and configuration control.
Event Analysis provides tools for technical analysis, traffic analysis, statistics and prognosis.
The Simulator is a so-called high fidelity simulator, which means that the trainee functionality is an exact simulation of the operational system’s ATC functions.
Efficient tools are available for the definition of airspace structure and the preparation and execution of exercises.
Pilots navigate aircraft according to voice instructions received from the trainees.
Controlling Functions
The Human Machine Interface of controlling functions is window driven and suitable for a two-screen configuration. It adapts to the latest recommendations of Eurocontrol concerning stripless HMI with extensive use of label and list interaction.
The functionality supports ACC, TMC and TWR operations. Main operational features:
- Flight data are presented, and operator interaction is performed, in labels and lists.
- The basic idea of the design of these HMI objects is to present only the required data. Additional data are easy to retrieve.
- The labels and lists are specially designed to support control of the air traffic in a stripless environment.
- Each flight is dynamically updated based on controller input of clearances/instructions. Input facilities are available in any of a flight’s HMI objects.
- Functions for silent co-ordination exist. This also applies for co-ordinations between controllers in TWR and TMC.
- Co-ordination with adjacent centres is performed by means of OLDI wherever such connections are available.
- The dynamic handling of the operational configuration is flexible.
- The transfer of sector jurisdiction is handled in a decentralised manner.
Configuration
The system builds on standard commercial off-the-shelf (COTS) products, has an open architecture and can easily be expanded. ATRACC has a distributed architecture with 18 computer nodes that communicate on a duplicated local area network using the standard protocol TCP/IP. It comprises 3 servers and 15 working positions intended for operators with different operational roles, specifically TWR (Tower), ACC (Area Control), APP (Approach Control), ARCC (air rescue communication), FDA (Flight Data Assistant), HIST (History, Recording and Playback), OSUP (Operational Supervisor) and TSUP (Technical Supervisor). The servers (RDP server / FDP server / HIST server) are equipped with fault-tolerant computers. To increase the redundancy even further the radar bypass system is implemented with an own LAN.
Traditional implementation
Recent history concerning the implementation of ATM systems is a sad story of delays, increased costs, inability to reach initial objectives and even total project collapses. There are many explanations to this negative record, and explanations differ from one programme to another. Some common weaknesses that impair traditional implementation may, however, be identified. Detailed system functionality is negotiated and decided on at a very early stage, in connection with the contract negotiations. The specification thus created will then remain unchanged clear up to the testing phase and, in many projects, the customer will have no real control over or influence on the ongoing work. The risk is obvious that he will receive a product that does not correspond to his needs and expectations. Maybe the customer and the supplier did not manage to be sufficiently clear and detailed in their specification work. Or maybe they simply had no possibility to foresee the changes that are likely to develop during a lengthy implementation period. And in the end, nobody is happy. The customer asks for more functionality and the supplier for more money. New negotiations cause agitation and interfere with the work already in progress. The delay is already a fact. The collapse is eminent.
Phased implementation
In the ATRACC project, the supplier and the customer wisely agreed to apply phased implementation. Four phases were defined, and the functionality of each phase was specified very carefully in order to avoid temporary solutions and dead ends. Each new phase in the project was specified only when the work with the preceding phase was drawing to an end, and each new phase could, consequently, profit by increased system know-how from the preceding phases. As a result, specifications become constantly clearer, the system itself constantly better, project fulfilment and customer satisfaction constantly higher and - last but far from least - the mutual understanding and confidence between buyer and seller constantly greater. Each phase in the ATRACC implementation has constituted a clearly defined, completed milestone, put into operational use and thereby possible to build on in the next phase.
The following four phases were defined:
- Phase 1 implemented simple radar data presentation for TWR, TMA and ACC control. With this, the customer could make use of radar data from their new radar stations.
- Phase 2 upgraded to multi radar tracking and added low-level flight data
processing. - Phase 3 upgraded to high-level flight data processing with paperless procedures
and silent co-ordination. - Phase 4 completed with additional functionality for OLDI, System monitoring and control, Recording and Playback.
The delivery of these four project phases was accomplished within a total time frame of 3 years and 8 months as illustrated in the figure below.
Project time schedule
Customer involvement
An important asset to the ATRACC project has been the exceptionally active and professional customer involvement. In normal projects, the customer involvement is usually limited to the following tasks:
- Requirement specification preparation
- FAT and SAT
- Operational evaluation
- Certification
In addition to these classical items, the ATRACC model has benefited from customer involvement in the following activities:
- Product specification preparation
- Requirements analysis
- Test specifications preparation
- Preparation of operational handbooks and installation manuals
- Internal testing at factory and on site
- Site installation of hardware and software
- Training
- Development of the HMI
Advantages of the ATRACC model
Some of the most important advantages with the ATRACC implementation model are:
- It is easier to control and follow up on a project divided into a number of well-defined phases. Buyer and user get tangible, usually high-priority, results early in the project.
- It is easier to get controller acceptance.
- Acceptance testing becomes less dramatic for both parties.
- The transition to the new system is easier to perform.
- There are a number of clearly defined milestones to which payment schedules and other contractual issues can be connected.
- The project risk decreases.
- The customer gets in-depth knowledge of the system hardware, software and functionality.
- The product usability increases.
- The calendar time for operational evaluation can be limited.
Conclusion
ATRACC is an excellent example of the apparent advantages of the applied model. As early as 6 months after the contract signing, the project had produced a system that could already be used operationally and then be stepwise upgraded by means of very smooth transition steps. A vital prerequisite for the successful application of this model – stepwise implementation in small steps with constant decision-making – was the fact that both project partners are small, alert and flexible organisations. Today the customer has got the system he wanted and expected. And the supplier has a product in the very frontline as regards functionality and technical solutions.