The Requirements & Specifications
THE REQUIREMENTS & SPECIFICATIONS
For
Arrival Manager
Validation Project
Identification Number
LGS 2013/106
November, 2013
Prepared by
SJSC ”Latvijas gaisa satiksme”
International Airport ”Riga”,
Riga, LV-1053, Latvia
1.INTRODUCTION
1.1LGS in Brief
1.2LGS ATM System in Brief
1.3LGS ATM System Simulator in Brief
1.4Overview
1.5Organisation of the Document
2.A-MAN MODULE OVERVIEW
2.1AMAN objectives
2.2A-MAN Relation to ATRACC System
2.3A-MAN Basic Controller Concepts
2.4A-MAN basic elements
2.5A-MAN operational context
2.6ATRACC A-MAN Basic HMI Elements
2.7A-MAN Simulator functions
3.REQUIREMENTS
3.1Scope of Work
3.2The Definition of validation strategy
3.3The performance of the Validation
3.4Validation Results
3.5Documentation Delivery
4.TENDER ORGANIZATION
4.1Requirements to the Bidders
4.2Familiarization visit
5.DOCUMENTATION
5.1Introduction
5.2General Requirements
5.3Provision Of Documentation
5.3.1General
5.3.2Validation Strategy Plan (VSP)
5.3.3Validation Experiment Plan (VEP)
5.3.4Validation Report
6.QUALITY ASSURANCE
6.1General Requirements
6.1.1Quality System Requirements
6.1.2Rights Reserved by LGS
7.PROJECT MANAGEMENT
7.1Introduction
7.2Contractor’s representative
7.3Supplier’s Project Organization
7.4Project Management Plans
7.5Progress Meetings
7.6Customer’s Project Organization
1.INTRODUCTION
1.1LGS in Brief
The main goal of the State Joint-Stock Company “Latvijas gaisa satiksme” (LGS) is to provide safe and optimal Air Navigation Services in Latvian airspace, namely Riga Flight Information Region (FIR).
LGS was founded on the October 21, 1991 as an Air Navigation Services Enterprise with 100% state ownership on the basis of the disintegrated “Aeroflot” structure. On June 12, 1997 the enterprise changed its legal status and became a State Joint-Stock Company keeping the same title.
The Air Navigation Services are provided in accordance with ICAO and EUROCONTROL standards and recommended practices. An operational differences are published in Latvian AIP.
As an enterprise operating in the field of civil aviation, LGS is subject to the Ministry of Transport of the Republic of Latvia and is under regulatory supervision of Latvian Civil Aviation Agency.
Operating in the market economy LGS is client-oriented and provides all the users with equal quality services as per international standards.
The main revenue source for LGS is the air navigation charges collected for the service rendered. There is no financing from the State budget. LGS is one of the largest taxpayers in Latvia.
LGS is operating an ATM system called ATRACC. ATRACC supports services in en-route, approach and control zone airspaces including the Towers in Riga, Liepaja and Ventspils.
LGS is using the Test and Development System called TDS. TDS copies and duplicates the ATRACC system environment, is connected to external interfaces (i.e. Radars, AFTN, Met) and allows to test new parameters, configuration and software versions before applying them into real ATRACC system environment.
LGS is using an ATM System simulator called Composite Simulator (CSim). CSim is a high fidelity simulator of the ATRACC system. It provides all facilities necessary for training of controllers in en-route, approach and Tower.
Tower module of CSim is a tool for training of Tower Controllers in real Riga Tower environment including ATRACC system, A-SMGCS, Voice Communication, Weather information etc.
ATRACC, TDS and CSim have been delivered by the Swedish company System Integration Air Traffic Management AB - SiATM.
1.2LGS ATM System in Brief
Operational functions
The main function of the system is processing of radar data and flight plan data and presentation of related information. Radar data is received from MODE-S radar stations and from Wide Area Multilateration System (WAM) and processed by means of a multi sensor tracking function. Flight plan data is received via AFTN, RPLs or is manually entered.
ATM Added Functions provides controllers with efficient automatic tools.
From a functional point of view the system provides the following main functions:
- Radar data processing
- Flight plan data processing including flight data assistant functions
- Route processing
- Airspace management
- Information data processing
- Monitoring aids
- Medium term conflict detection
- Safety nets (incl. STCA, APW, MSAW)
- Airport systems (ATIS, AWOS, AFIPS etc)
- Radar operator functions
- History
- System monitoring and control
- Multi sensor tracking
Simulation functions (see Chapter 1.3)
In addition to the operational functions the following main functions exist for simulation.
- Exercise preparation
- Exercise control
- Navigation functions
- Voice communication
- Weather simulations
- Airport system simulation (airport light system, meteorological systems, ILS etc.)
- Visualization
External systems and Interfaces
The following external systems are distinguished:
- Radar stations provide plot data. This includes also the new Mode-S radars and the multilateration system
- Time system provide universal UTC time.
- A local AFTN switch provides access to the worldwide AFTN network for reception and transmission of AFTN messages.
- 4 ATS units of adjacent FIRs are connected for the exchange of flight plan data by means of OLDI procedures.
- Track data and flight plan data is exchanged with an A-SMGCS system at Riga airport.
- Data about operational and technical events are sent to an Event analysis system for recording and analysis.
- ATIS reports for Riga airport are received from a local ATIS/DCL system. Through the same system is exchanged departure clearance data between tower controllers and pilots.
- Sensor data reports for Riga airport are received from a local AWOS system.
- Data about flight movements is sent to a Billing system.
- Flight data sent to the Airport Flight Information Processing System and stand allocation received from it.
Flight plan data management
Flight Data Assistants have an efficient HMI to support editing, browsing, queue handling with support for complex search criteria.
Handling of RPLs
RPLs can be searched, created, modified and deleted manually, but also automatically based on airline time schedules on data media. Temporary changes and suspensions of flights are supported.
Handling of FPLs
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.
Route analysis
For RPLs and FPLs both, route details are examined against the local airspace structure for compliance with ICAO rules. The airspace structure is defined by means of system parameters.
Data Preparation handling
The system is easily adaptable to any operational environment by means of extensive use of system parameters.
ATC functions
Controller HMI
Controller interaction with flights is performed through extensive use of lists and flight labels.
Trajectory calculation
A trajectory describing the flight’s path in airspace is calculated with consideration to aircraft performance characteristics and current weather data. Wherever applicable, SID or STAR are selected automatically. The trajectory’s coverage of ATC sectors determines the distribution of flight data to working positions.
Surveillance data processing
Target data from PSR and SSR radar stations and Multi-lateration data are processed by means of an advanced centralised true multi-sensor tracker. The resulting system tracks are associated with FPLs. Flight labels comprising surveillance and flight plan information are presented to controllers.
ATC tools
The following ATC tools are available: Monitoring aids, Medium-Term Conflict Detection, Short-Term Conflict Alert, Minimum Safe Altitude Warning and Area Proximity Warning. They have been developed strictly in accordance with Eurocontrol specifications.
PDC
Pre Departure Clearance, PDC is implemented by using a datachannel between the ATC centre and the Aircraft.
Recording and Playback
Data is continuously recorded. At playback, operational scenarios are recreated at a controller work position.
System Monitoring and Control
System Monitoring and Control is performed by means of graphical presentation and tools for diagnostics and configuration control. Parameter changes can be made without interrupting operational use.
Event Analysis
Event analysis provides tools for technical analysis, traffic analysis, statistics and prognosis.
Controlling Functions
The Human Machine Interface of controlling functions is window driven and suitable for one or two monitor configuration. It adapts to the latest recommendations of Eurocontrol concerning stripless HMI with extensive use of label and list interaction. Main operational features:
The functionality supports ACC, APP and TWR operations
Flight data are presented, and operator interaction is performed, in labels and lists. Only the required data is presented. Additional data are easy to retrieve.
The labels and lists are specially designed for 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.
Various functions for silent coordination are available including coordinations between TWR and APP.
Coordination with adjacent centres is performed by means of OLDI.
The handling of the operational configuration is decentralised and flexible. It supports on-line redefinition of sector status.
1.3LGS ATM System Simulator in Brief
CSim features two main segments, the simulator segment, which is the same for all implementations, and the operational segment, which provides the trainee environment as required by individual customers. The concept allows for independent execution of parallel exercises in the same or in different airspaces.
Figure 1. ATM System Simulator Overview
Simulator segment
The simulator segment drives the exercise, generating input to the operational segment and acting as surrounding systems for the output. The main interfaces are:
- Surveillance data in various forms
- Plot and track data in ASTERIX formats as from radar stations
- System tracks as from a multi-radar tracker
- Flight plan data in ICAO FPL or ADEXP format.
- Time is crucial for simulation. The simulator can command start, stop and rewind of exercise time.
- Meteorological systems such as ATIS and different airport sensors can be simulated. Upper winds and temperatures are provided, too.
- Coordination with adjacent FIRs can be performed verbally or with OLDI.
Navigation function
The navigation function generates aircraft movements based on realistic manoeuvring characteristics. It handles a rich set of navigational commands to support procedures as SIDs, STARs, landing, holding and missed approach. Such commands are combined to form intuitive pseudo-pilot manoeuvres or automatic procedures.
Typical manoeuvres are those for immediate action, such as turn to direction or towards point, intercept line, accelerate/decelerate, climb/descend; those for restrictions in speed and level or assignment of runway; and those for monitoring of distance, level, position or time.
Aircraft can either be automatically simulated or navigated by pilot.
Each pilot handles several aircraft and can, for each individual one, control equipment such as the transponder for set code, on/off, SPI or special condition code, and the radio.
He can change the predefined route; re-join the route, request reports on reached level, heading, point, distance, radial or time. He can also reposition a flight and perform take-off and landing.
Exercise preparation
Each exercise is defined by an exercise plan that specifies the flights that shall be included in the exercise, when and how they shall appear, and if they shall be manually or automatically controlled.
Each flight is defined in a simulated flight plan upon which both flight plan and simulated surveillance data are based.
The exercise can be fine-tuned in a special air situation window, where each flight’s timing can be adjusted in order to create the situation required. A quick exercise creation function automatically combines flights as specified by the operator.
Operational segment
Operational segment truly emulates anATM environment. The advanced functionality is inherited from operational system and is well proven.
Integrated voice communication
CSim is equipped with voice communication facilities that automatically adapt to the running exercises. Each trainee and pseudo-pilot has access to radio frequencies and ground-to-ground communication within the exercise.
Recording and playback
For each exercise, the system provides individual data and voice recording, which can be synchronously replayed.
1.4Overview
This document provides operational, functional and other specifications for procurement of Validation of A-MAN Module for LGS ATM System.
It is the intention of the Customer - “Latvijas gaisa satiksme” (LGS) that the Validation procured will provide the maximum benefit/cost ratio with the minimum risk of time-scale overrun. As such, the procured procedure is expected to validate the performance and usability of the A-MAN module to meet the requirements of LGS. The organization and content of this document, and the instructions to Bidders detailed below, are designed to facilitate the evaluation of these factors.
Mandatory capabilities are denoted with the term “shall”; desired capabilities are denoted with the term “should”. Bidders are encouraged to propose validation program in compliance with the requirements provided.
1.5Organisation of the Document
Chapter 1 provides an introduction including information about the document structure and reference documents.
Chapter 2 provides an overview of the A-MAN module.
Chapter 3 describes the Requirements of the Project.
Chapter 4 describes the Requirements to the Tender Organization.
Chapter 5 describes the Documentation.
Chapter 6 describes the Quality Assurance.
Chapter 7 describes the Statement of Compliance.
Chapter 8 describes the Project Management.
2.A-MAN MODULE OVERVIEW
2.1AMAN objectives
The major AMAN objectives are in line with ICAO Global Air Traffic Management Operational Concept (Doc 9854) and are based on metrics defined in ICAO Manual on Global Performance of the Air Navigation System (Doc 9883)
These metrics (KPAs) are:
KPA-02 – Capacity;
KPA-04 – Efficiency;
KPA-05 – Environment;
KPA-10 – Safety.
At least those objectives shall be taken into account:
- Increase runway throughput (KPA-02)
- Minimise delay in high traffic situations (KPA-04)
- Support continuous descent approach (KPA-04)
- Noise reduction (KPA-05)
- User preferred trajectories (idle descent) for reduction of fuel burn and emissions (KPA-05)
- Reduce holding and low-level vectoring (KPA-05)
- Reduce overall controller workload (KPA-10)
- Less numberof multiple trajectory related information committed to controllers’ memory(mind) (KPA-10)
- Recommendation of optimised approach traffic control tactics
LGS is expecting the following benefits after implementation of A-MAN as a part of ATRACC system:
KPA-02: runway throughput should be increased at least by 5%
KPA-04: efficiency during peak hours should be increased at least by 5%
KPA-05: use of holdings and low-level vectoring should be reduced at least by 5%
KPA-10: the controllers’ workload in peak hours should be reduced at least by 5%
2.2A-MAN Relation to ATRACC System
Current ATRACC system contains a set of self-contained functions to support ATC controllers and these reflect a well-functioning operational concept tried and used over a long period of time.
The implementation of A-MAN is in no way remove, change or jeopardize any part this functionality. Nor shall it force controllers to adapt or modify this operational concept. A-MAN is an additional tool or a complement to the current functionality in order to gain the positive effects of the objectives above.
It is however be possible not to install A-MAN, to deactivate it or simply not use it without losing any part of the current system functionality. I.e. the non-AMAN part remains completely functionally independent of the A-MAN.
A-MAN integration with the current system comprises:
- Use of System FPLs
- Use of System Tracks
- Re-use/coexist with current ATRACC HMI
- Re-use a number of ATRACC services and principles such as parameter management, System Monitoring and Control, redundancy principles, recording etc.
- Sharing of computer platforms
- Others
A-MAN does not update any mission critical operational data.
Technical problems or malfunctioning of A-MAN do not be transferred to other parts or components of the ATRACC system.
2.3A-MAN Basic Controller Concepts
The current way of operations with arrivals sequence is based on:
- The functionality in the ATC system called “track miles”, which continuously calculates and shows to Approach controller the distance to Riga airport along the planned route;
- The technical characteristics of the aircrafts;
- Structure of the airspace;
- The Approach controllers’ knowledge of special preferences and abilities of the different aircompanies flying to Riga airport.
In relation to A-MAN two main operator tasks can be distinguished.
Arrival planning
The task is to plan the optimised arrival sequence and monitor its implementation. The main tool is the sequence display. This task is performed by an approach controller. Depending upon the traffic situation and the time of day he is dividing his attention between executive control and arrival planning, or he is performing only arrival planning whilst another controller handles the executive approach control.
Executive air traffic control
This is the traditional ATC task performed with its traditional set of automatic tools, now enhanced with information from A-MAN, mainly advisories, which shall support the implementation of the optimized arrival sequence. This task is performed by controllers of en-route and approach.
2.4A-MAN basic elements
Basic elements of the A-MAN concept are:
- A-MAN receives and processes FPLs with system trajectories for flights to the concerned aerodrome.
- A-MAN receives and processes system tracks from the multi sensor tracker.
- A-MAN uses system trajectories and track data to calculate the flights’ nominal arrival times to build an estimated arrival sequence.
- A-MAN applies various optimisation criteria and maintains the optimised sequence. The optimised sequence contains for each flight a target arrival time and an arrival slot, which constitute the overall arrival strategy.
- For the implementation of the arrival strategy some flights need to lose or to gain time, to be displaced.
- A-MAN applies various tactics to displaced flights to build suitable trajectories, reflecting the determined strategy - these are termed the A-MAN trajectories.
- The A-MAN trajectories may be accepted, or first modified and then accepted, by the planner.
- At acceptance the A-MAN trajectory replaces the system trajectory and it thereby becomes subject to all existing automatic and manual ATC functions.
- For accepted trajectories within the A-MAN advisory horizon A-MAN produces and presents controller(s) with advisories. These are controller clearances or instructions to be executed in sequence, at specific times, while the flight proceeds along the trajectory.
- A-MAN uses track data to monitor the flights' progress along the trajectories in order to correctly time the advisories and to check the flight’s possibility to meet their arrival slots.
2.5A-MAN operational context
The figure below shows A-MAN in its ATM environment. The central A-MAN process receives and processes inputs from various sources and sends arrival planning data to users.