Requirements Specification for a Study into IP in the ...
Doc.Ref.
.../FUTURE_COM/FCS_SYSTEM/...../FUTURE_COM/FCS_SYSTEM/.. |
Issue
2.02.0 |
Date
16 Feb 200616 Feb 2006 | |
|Requirements Specification for a Study into IP in the Future Infrastructure for Air-Ground Communication |
|ApplicationsRequirements Specification for a Study into IP in the Future Infrastructure for Air-Ground Communication |
|Applications |
Introduction
1 Objectives
This document specifies the requirements for a Study into the Future Communication Infrastructure (FCI), for the year 2020 and beyond, to support both ATS and AOC data communication applications between aircraft and ground systems.
The aims of the study are to assess the feasibility of using IP to support the next generation of collaborative ATS applications. The criteria for deciding include, but not necessarily be limited to: safety, performance, security, efficiency, coverage, cost and availability of COTS components.
The objective is to obtain an overview of the FCI, including the use of IP to support aeronautical A/G application data interchange.
2 Background
1 Current Mechanisms
The current generation of ATS datalink applications is based on the communication services provided by the Aeronautical Telecommunication Network (ATN), which is a global internet (“network of networks”) specified by the International Civil Aviation Organization (ICAO). European programmes such as LINK 2000+ and CASCADE are based on the ATN. The detailed technical provisions of the ATN are published in an ICAO Manual, Doc 9705 Technical Provisions for the Aeronautical Telecommunication Network.
At the same time, data link services based on the ACARS infrastructure are being used in oceanic and remote airspace regions. Work is being undertaken in Europe and the USA to converge ATN and ACARS based systems to a future unified communications infrastructure.
The ATN Internet is based on the ISO standard connectionless network protocol (CLNP) for universal forwarding of packets through the ATN Internet, and on the ISO standard inter-domain routing protocol (IDRP) for global policy-based routing and aircraft mobility support. The CLNP and IDRP protocols are functionally similar to protocols more widely used on the World Wide Web (informally “The Internet Protocol Suite” or IPS) today. Although functionally similar, there are significant differences between the ATN and Internet protocols, which mean that interoperability between them is not straightforward.
Increasingly, Internet protocols and especially IP are being specified and used for ground-ground aeronautical communications. On board aircraft, data networks supporting TCP/IP protocols both in avionics and in the passenger cabin are becoming widespread. The motivations are mostly economic, based on comparative total cost of ownership of ATN routers compared with commercial off-the-shelf (COTS) IP routers.
IP can already be used as a ground-ground subnetwork of the ATN via the implementation of the IP Subnetwork-Dependent Convergence Function (IP SNDCF), which has recently been standardised by ICAO. In this mode, standard ATN protocols are transparently encapsulated in IP packets.
However, the IP SNDCF is not specified to operate over current air-ground subnetworks, and is not intended as a general-purpose solution for IP Air-Ground Communications. It could be extended, as a short to medium term solution, to allow some IP Air-Ground Networks to be used as part of the ATN, and some organisations may wish to do this.
The question is therefore being asked; "What is preventing the adoption of Internet protocols for all aeronautical communication, including the air-ground segment?" There are some known technical issues with IP that need to be resolved, as they were in the ATN protocols, but the desire is to use IP protocols unmodified in order to take advantage of COTS products.
In ICAO, Working Group N of the Aeronautical Communications Panel (ACP WGN) has developed a report on the potential use of TCP/IP protocols in the provision of aeronautical networking. The report concludes that TCP/IP could be used for ground-ground communications and is appropriate for this purpose. As far as air-ground communication is concerned, several areas including IP mobility and security need further investigation before a conclusion is reached.
In parallel with the ICAO work, a cooperative action between EUROCONTROL and the FAA is being undertaken to define requirements for what is called FCI - The Future Communication Infrastructure. This work is also being performed in the context of the EUROCONTROL / FAA Action Plan 17 framework to develop requirements for the future aeronautical communications system. This is documented in the Communications Operating Concept and Requirements for the Future Radio System (COCR) [5]. The initial datalink services being considered are summarised in Annex C.
There is also the possible establishment of Pan European Network (PEN) for ground-ground applications. There is a need to investigate how future air-ground communication will interwork with this PEN.
2 Future Considerations
[pic]
Step 3 of the ICAO EUR/NAT Data Link Steering Group convergence strategy aims at the development of a future uniform solution that would fully meet all operational requirements for both continental and oceanic airspace. This future data link system might be a derivative of one of the existing ones or a totally new one that supports additional future ATS data link requirements. This area requires ongoing definition work.
Experience has shown that introduction of new CNS technologies into air and ground systems has a very long lifecycle, from initial concept, thorough development and trials, standardization and certification, transition and deployment. For the introduction of new communication systems to address application requirements foreseen in the 2020 time frame, the first steps need to be taken now.
[pic]
The strategic context is illustrated above. Step 4 of the ATM 2000+ Strategy envisages the conceptual changes necessary to implement a more advanced form of ATS enabled by the integrated use of all the data link applications. Additional safety improvements, in particular a new generation of safety nets will supplement the safety effects of the main operational changes.
This step will require enhancements to the CPDLC, AS, GS, D-FIS and ADAP areas developed in previous steps. One of the main enhancements will be the provision of user-preferred 4-D trajectories and the implementation of trajectory based ATM. This enhancement will increase the ATM efficiency by introducing a new type of clearance based on the concept of “trajectory contracts” between controllers and pilots.
Unlike the current generation of data link applications, future applications may be decoupled from the underlying data communications service. Provided that an adequate quality of service is available, applications may be able to negotiate the use of a suitable data link on a “plug and play” basis.
3 Scope
The study will be in the context of the Future Communication Study (FCS), Action Plan 17 of the cooperation agreement between EUROCONTROL and the FAA. It will focus on the data communication part of the system, i.e. voice communication is excluded. While the scope of the FCS is focusing on the data link technology (mainly at layers 1 and 2) for air-ground and air-air communication (see Figure 1), the scope of the present study shall be system-wide and based on an end-to-end approach.
[pic]
Figure 1. Scope of the Future Communication Study
The study Contractor shall examine the possibility of using potential future communications technologies, based on IP, to meet safety and regularity of flight communications requirements, i.e. those supporting Air Traffic Services (ATS) and Aeronautical Operational Control (AOC).
The scope shall include a study of use of the COTS Internet Protocol for air-ground aeronautical data communications. The scope shall include the linkage to a ground IP network, such that mechanisms for the end-to-end transfer of data over IP are defined. In this context, migration steps for the possible transition to a global IP network shall be specified, together with interworking requirements for regions that have yet to adopt the proposed IP-based networking.
The study shall consider the potential constraints that a potential IP network would impose upon the CNS/ATM applications that are the network users.
The scope shall include an investigation of whether broadcast data services (ADS-B, TIS-B), which are currently tightly coupled with subnetwork technologies (e.g. Mode S 1090 Extended Squitter, VDL Mode 4), could benefit from IPS protocols.
4 References
1] ICAO Doc 9705, Technical Provisions for the Aeronautical Telecommunication Network
2] RFC 1771 Border Gateway Protocol Version 4 (BGP4)
3] EUROCAE ED-120 / RTCA DO-290 Safety and Performance Requirements Standard for Initial Air Traffic Data Link Services in Continental Airspace (May 2004)
4] Requirements for "Protected Mode" Controller Pilot Datalink Communication (PM-CPDLC)
5] Communications Operating Concept and Requirements for the Future Radio System (COCR), EUROCONTROL/FAA Future Communications Study (FCS) Operational Concepts and Requirements Team, November 2005[1]
6] EATMP Communications Strategy, EUROCONTROL (25th August 2003), Volume I Management Overview (Edition 4.0) and Volume II Technical Description (Edition 5.0), available from eurocontrol.int/eatm/public/standard_page/library_strategic_doc.html
7] ARINC Specification 664 Aircraft Data Network
8] Migration to IPv6 for ATM Air/Ground data communication, Edition 0.4 (26 January 2006)
9] Proposal for IP Prototype Demonstrator in support of A/G ATC applications, Edition 1.0 (16 February 2006)
5 Abbreviations
|ACARS |Aircraft Communications Addressing and Reporting System |
|ADN |Aircraft Data Network |
|ADS-B |Automatic Dependent Surveillance - Broadcast |
|ADS-C |Automatic Dependent Surveillance - Contract |
|AOA |ACARS over Aviation VHF Link Control |
|AOC |Airline Operational Control |
|ASAS |Airborne Separation Assurance Service |
|ATC |Air Traffic Control |
|ATM |Air Traffic Management |
|ATN |Aeronautical Telecommunication Network |
|ATS |Air Traffic Services |
|ATSU |Air Traffic Services Unit |
|BGP4 |Border Gateway Protocol Version 4 (RFC 1771) |
|CDA |Current Data Authority |
|CDM |Collaborative Decision Making |
|CLNP |Connectionless Network Protocol |
|CNS |Communications, Navigation and Surveillance |
|COCR |Communications Operating Concept and Requirements for the Future Radio System |
|COTS |Commercial Off-The-Shelf |
|CPDLC |Controller Pilot Data Link Communication |
|EEC |EUROCONTROL Experimental Centre |
|EUROCAE |European Organisation for Civil Aviation Equipment |
|FAA |Federal Aviation Administration |
|FCI |Future Communications Infrastructure |
|FCS |Future Communications System for ATS |
|FRS |Future Radio System for ATS |
|ICAO |International Civil Aviation Organisation |
|IDRP |Inter-Domain Routing Protocol |
|IP |Internet Protocol |
|IPS |Internet Protocol Suite |
|IPSec |Internet Protocol Security |
|ISO |International Organisation for Standardisation |
|NDA |Next Data Authority |
|OSI |Open Systems Interconnection |
|PEN |Pan European Network |
|PM-CPDLC |Protected Mode Controller Pilot Data Link Communication |
|SNDCF |Subnetwork Dependent Convergence Function |
|SSL |Secure Sockets Layer |
|TCP |Transmission Control Protocol |
|TIS-B |Traffic Information Service - Broadcast |
|TLS |Transport Layer Security |
|TP4 |OSI Transport Protocol class 4 (ISO/IEC 8073) |
|VDL |Very High Frequency (radio) Data Link |
|VPN |Virtual Private Network |
Requirements
1 General
A thorough investigation shall be performed to identify the most appropriate air-ground communication means to support the next generation of collaborative ATS applications such as COTRAC (see Annex C). The criteria for deciding on the most appropriate technology shall include, but not necessarily be limited to: safety, performance, security, efficiency, coverage, cost and availability of COTS components or technologies.
Recognising the almost universal use of the Internet Protocol (IP), the study shall include a work package to quantify any issues associated with the use of IPv4 and/or IPv6 for end-to-end air-ground communication. The study report shall document the issues and make recommendations for any enabling measures that would be needed. However, the objective is NOT to undertake an "ATN/CLNP vs. TCP/IP" type of analysis, but rather to consider the most appropriate air-ground communication means to support the next generation of collaborative ATS applications.
One lesson learnt from the experience of deploying ATN protocols was that the desire to maximise the use of COTS products and components was not realised. The focus shall be on the potential use of COTS versions of the Internet protocols, i.e. on widely available implementations, without modification or special customisation.
The study shall take into account and build on the current work of ICAO ACP SGN1 and SGN4 on the use of the Internet Protocol Suite (IPS) for Aeronautical Communication.
It shall also reflect the requirements captured in the EUROCONTROL / FAA COCR document [5].
The study shall take due account of a recent EUROCONTROL study into Migration to IPv6 for ATM air-ground data communication [8].
The study shall be based on a total system perspective, considering the impact of the communications infrastructure on the design and specification of air-ground applications.
The scope shall include migration and co-existence with other air-ground communication mechanisms, including ATN Internet (TP4/CLNP) and ACARS/AOA.
The availability of validated products implementing the identified protocol options shall be evaluated.
For guidance, Annex B introduces some of the areas that are required to be addressed by the study.
2 Mobility
The study shall examine possible solutions for handling aircraft efficiently in the IP protocol suite. Aircraft in this context represent highly mobile network nodes, which are distinguished from terrestrial mobile communication users due to their speed, altitude and distance travelled.
In particular, the alternative mobility scenarios outlined in Annex B, section 10.4 shall be evaluated, as well as any alternative solutions.
3 Security
The study shall examine possible solutions for identifying and providing required security services efficiently in the FCI. In particular, the security services to be examined shall include:
1. Peer entity authentication
2. Data integrity assurance
3. Data origin authentication.
The work needs to be driven by strong operational requirements following a risk analysis for the particular communication service.
The suitability of IPS security specifications and products (e.g. IPSec, SSL) for air-ground usage shall be assessed, including an evaluation of message sizes and round trip overheads.
The ATN security specification provides efficient security services for the air-ground as well as the ground-ground environment, but is not yet deployed operationally. The security solution assumes that an initial "security context" will be established by an application such as Context Management, before other applications based for example on CPDLC can make use of the security services. Such assumptions may not be true in the future environment.
The security issues outlined in Annex B, section 10.6 shall be addressed by the study.
4 Portability
The study shall assess the possibility of decoupling CNS/ATM applications from the underlying network provision, such that new applications could be deployed in a “plug and play” fashion. This shall include consideration of the consequences on the definition and monitoring of the quality of service provided to applications.
The contractor shall analyse how the data exchanges of such applications can be specified (e.g. using XML, …).
5 Safety Aspects
Based on the Safety Objectives in ED-120 [3], the study shall consider how safety hazards associated with the end-to-end communications path can be mitigated. The requirements for "Protected Mode" Controller Pilot Datalink Communication (PM-CPDLC) shall serve as a reference. The analysis shall consider hazards directly associated with datalink operation, such as undetected message misdelivery. It shall also consider "indirect" hazards that may arise, for example, from the long dependency chain arising from dynamic information update and subsequent retrieval. As an example of the latter, the PM-CPDLC specification mitigates a hazard that arises from downlinking addressing information using the Context Management application and subsequently requiring the addressing information to be up-to-date and accurate when used operationally by CPDLC.
The safety issues outlined in Annex B, section 10.5 shall be addressed by the study.
The tenderer shall investigate how safety mitigation mechanisms at the application level (e.g. the CPDLC checksum) can result in simplifications of the communications infrastructure.
6 Performance and Reliability Aspects
The study shall consider how the Performance Requirements in ED-120 [3] can be met for the end-to-end communication path. Any problems associated with single point-of-failure scenarios shall be identified, and mitigation means proposed.
The study should consider the impact of bandwidth and latency on the overall communications efficiency. At this stage it is not known where these parameters will finally stabilise for the future communications system, so an indication of how these parameters affect overall performance would be useful.
7 Integration with Ground Networks
The study shall consider the use of the ground IP network. The end-to-end communications path shall be considered, including integration of the air-ground segment with ground-ground IP networks.
It can be assumed that the planned Europe-wide IP network for ground-ground communication will be implemented.
If COTS IP can be used for the air-ground segment, the interface with the ground IP network needs to be considered. The study shall consider how the address space for a possible air-ground IP network would be allocated. (An IPv6 addressing space is allocated by the European responsible authority to EUROCONTROL for ground-ground applications).
8 Integration with Airborne Networks
Integration with airborne IP networks shall be considered, including the Aircraft Data Network (ADN), which is being specified by the AEEC [7].
9 Integration with Airborne and Ground End Systems
The integration of the communication applications in the ground automation (FDP) and the airborne end systems shall be considered, taking into account existing and planned developments.
10 Impacts of Future Radio System Technology
The study shall consider the impacts of different possible future radio system technology types on the protocol stack. There is a widely held view that IP can be the unifying factor over almost any terrestrial network technology (X.25, Frame Relay, Asynchronous Transfer Mode, etc.). The study shall consider whether this is also true for wireless networks. Will IP (v4 or v6) be well supported by a wireless protocol of the (yet to be defined) type envisaged for air-ground data communications? Put another way, if IP were used over the air-ground link, would this allow any simplification in the link protocol?
For the purpose of this study, the future communications systems may be assumed to have any of the following characteristics, and the implications from an IP point of view need to be considered for each type:
• Cellular technologies in another frequency band (e.g. UMTS / CDMA 2000),
• Public Safety and Specialized Mobile Radio (P-25, P-34, TETRA, TETRA2, TETRAPOL, EDACS, iDEN, MESA)
• Satellite technology (with corresponding transmission delays) ( SDLS, Connexion by Boeing, Swift Broadband (Aero B-GAN), Iridium, Globalstar)
In particular the study should consider the impact of "cell sizes" on a wireless data network. (The term "cell" is used in its most general sense, i.e. relating to the volume of space covered by a single transmitter/receiver site pair, and should not be taken to indicate the use of mobile phone cellular technology). Smaller cells (a few tens of miles diameter) would mean frequent cell transitions. Large cells (such as VHF data link coverage) have relatively few cell transitions and an aircraft may be in contact with the same ground station for an extended period. Satellite "cells" may in many cases cover an entire flight.
The study shall also consider possible issues and solutions, associated with the use of IP over radio links.
11 Trials and Validation
The Contractor shall make reasoned proposals for components to be trialled in order to demonstrate and validate the developed end-to-end IP scenarios. Due account should be taken of the results of the iPAX task force for ground-ground IP communication.
The contractor shall develop detailed plans for trial activities, including areas where standard elements could be adopted (e.g.mobile IP routers).
In the short-term, datalink services will initially build upon the LINK 2000+ communications infrastructure, offering a connection-oriented TP4 transport service. Prototyping activities should be foreseen to assess the migration to and coexistence with alternative air-ground infrastructures, including connectionless mode, and IP-based services.
It is anticipated that prototype CNS/ATM datalink applications will subsequently be developed via future Industry contracts. This will partially validate the concepts and specifications and provide a platform for experimentation and optimisation of the datalink environment. Integration of the prototypes with operational air and ground systems will be studied and realistic proof-of-concept demonstrators developed.
Activities and trials shall be specified, to validate the specifications, identify gaps and performance issues, including possible interactions between the various datalink applications. Interoperability testing between independent implementations will ensure the highest level of validation. The results would be fed back into appropriate standards and programme documentation.
Work Breakdown Structure
This section suggests a possible structure for the study in terms of Work Packages (WPs) to be performed by the study contractor. It is not a requirement that this be followed to the letter. Tenderers shall include in their proposal the detailed WBS to be followed.
1 WP1 High Level Overview
This work package will document a "helicopter view" of the future communications infrastructure (FCI). It shall take an end-to-end approach of the communications chain between flight data processing system (including controller HMI as well as automated functions) on the ground and aircraft systems (including flight management automation and cockpit HMIs).
A target architecture for the FCI shall be developed, including components and interfaces such as described in the work packages below.
The components of the architecture shall be identified, including ground end systems (such as communications front-end processor with communication applications), internetwork components, ground communications infrastructure, air-ground subnetworks, airborne end system and supporting layers, etc.
Options for the components shall be discussed where needed.
2 WP2 Use of Internet Protocols
This work package shall consider the use of Internet Protocols in the air-ground environment. It shall include an inventory of candidate RFCs and protocols to support the required degrees of mobility and security, including for each an assessment of the level of maturity and the degree of adoption in COTS products. The results of the study report “Migration to IPv6 for ATM Air/Ground data communication” [8] shall be taken into account.
The suitability of the various protocols and the resulting requirements on application design shall be assessed. The report shall make recommendations on the use of COTS IP for end-to-end aeronautical data communication. Any inhibiting factors and required enabling measures shall be specified.
Due account shall be taken of the use of Internet Protocols in the back cabin for passenger communication services, and the Aircraft Data Network (ADN) specified in AEEC Specification 664.
3 WP3 Use of Ground Infrastructure
This WP shall identify requirements for interfacing to the ground-ground network infrastructure. It may be assumed that a Pan-European Network will be implemented in accordance with the EATM Communications Strategy [6].
Deliverables of the iPAX Task Force (eurocontrol.int/ipax/ipax_documents.html) shall be taken into full account.
4 WP4 Air-Ground Communications Applications
This work package shall consider the impact of the FCI on the design of air-ground communication applications. For example, applications such as Controller-Pilot Datalink Communication (CPDLC) would likely have a different structure if they had been designed to operate over a connectionless IP network. Some of the issues are outlined in Annex B.
AOC applications, operating today over ACARS or AOA, shall also be included in the FCI. The work of the relevant AEEC Working Group shall be taken into account.
5 WP5 Air-Air Communications Applications
This work package shall consider the role of IP in air-to-air multicast communications in the context of the FCI. This shall include the Airborne Separation Assurance Services (ASAS) applications, being developed by the CASCADE programme (eurocontrol.int/Cascade).
The addressed time-frame is starting from 2020 onwards. Therefore different technologies beyond ADS-B Mode-S squitter shall be considered.
Direct addressed communication between aircraft is however out of scope.
6 WP6 Security
This work package shall consider the required level of security to protect the FCI against malicious or accidental attack. It shall then consider any issues associated with providing effective countermeasures against the potential threat scenarios.
7 WP7 Transition Issues
This work package shall consider the issues in migrating from the current and near-future situation to the next generation FCI defined in the "Vision" of WP1.
It shall describe how components of the FCI (VHF data link, satellite solutions, current airborne architecture, ground infrastructure, etc.) will migrate to the envisioned FCI architecture.
It is recognised that a clear migration strategy cannot be formulated until the FCI architecture becomes more concrete. The study shall assume that several links will be available and identify possible migration paths and issues associated with using these means, keeping in mind that not all of them will be mandated.
The WP shall also consider issues with migrating existing datalink applications, both ATN and FANS-1/A, to the FCI.
8 WP8 Trials and Simulations
The Contractor shall make proposals for the development of prototype systems and trials where required to demonstrate the feasibility of the recommendations. Such proposals shall take into account the report “Proposal for IP Prototype Demonstrator in support of A/G ATC applications” [9].
9 WP9 Use Cases
The Contractor shall develop use cases describing the progress of a typical commercial passenger flight from departure gate to arrival gate in terms of the transitions seen at the data communications infrastructure level (i.e. how the proposed mobility solution maintains the required level of communications service, continually satisfying interoperability, safety and performance requirements, through all phases of flight).
Deliverables
The study shall deliver the following:
1. Initial outline study report T0 + 1 month
2. Interim draft study report T0 + 2 months
3. Use cases for gate-to-gate flights T0 + 3 months
4. Final draft study report T0 + 4 months
5. Approved Final Study Report. T0 + 6 months
(T0 = Start of contract)
The study report shall document the identified issues clearly and concisely, and make recommendations for the future air-ground communication system, including a reasoned discussion of the selection criteria adopted.
The study report shall include an Action Plan, including:
• Validation areas
• Outline programme of activities, including plans for trials and prototypes
• Transition aspects
• Elements of business case.
• Further work needed
A draft Project Management Plan shall be delivered before the kick-off meeting and shall be maintained by the Contractor for the lifetime of the contract. Periodic progress reports shall be delivered, specifying the progress made against the activities defined in the PMP.
All deliverables shall be subject to the acceptance of the EUROCONTROL Project Manager (PM), and a review/update process should be foreseen. If the PM is not satisfied with the performance, even after reasonable review and update, he will discuss this with the contracting team. If agreement cannot be reached, EUROCONTROL reserves the right to terminate the contract according to the contractual terms and conditions.
All documents shall be in correct English. Documents shall be delivered in editable MS-Office format. Documents shall be spell-checked before delivery using a UK English spell-checker.
All deliverables shall be scanned for viruses using up-to-date virus detection tools before delivery.
Deliverables shall conform to style and quality guidelines to be provided by the Agency.
Tender Requirements
Tenderers shall provide at least the following:
a) A thorough description of the approach proposed to be adopted, including a Work Breakdown structure, proposal for phasing of the work, estimates of effort and a Gantt chart. This planning information will be used by the EUROCONTROL tender evaluation team to assess whether the Tenderer has fully understood the requirements of this Study.
b) A list of deliverables;
c) Proposed process for ensuring that the deliverables will satisfy the requirements;
Tenderers shall provide initial comments on the concepts outlined in Annex B.
Methodology: The bidder shall include the detailed study methodology as part of their proposed approach, including which Stakeholder (State, ANSP, Industry, Aviation representatives, etc) are proposed to be involved.
Objectives: The study shall address, as a minimum, the objectives described in this specification. The Contractor need not necessarily cover the objectives in the order given and may propose additional or amended objectives.
Bidders shall only be considered if they have provided clear evidence of compliance with all of the mandatory requirements in this specification, including the Annexes.
The Tenderer shall supply the following information:
• The curriculum vitae for the proposed team member(s), including identification of the role of each member within the team;
• The particular experience of the personnel proposed in relation to the requirements;
• A completed “Statement of Expertise” proforma per proposed team member;
• Details of relevant corporate experience and previous involvement in similar projects. Tenderers are also invited to indicate, if appropriate, how their in-house expertise and experience may be used to support staff made available to the Agency;
• Draft quality plan
• Commercial proposal;
The commercial proposal shall be packaged separately from the other documents.
During the evaluation of bids, EUROCONTROL reserves the right to interview, for up to one hour per team member, all members of the team who are proposed for these tasks. All team members shall be made available for interview. These interviews shall be conducted at a location in Europe proposed by the bidder.
1 Required Skills
The requirements for the skills of the proposed personnel are contained in the tables in Annex A of this document.
Tenderers shall complete copies of these tables showing, for each of the listed areas, how well the experience of each of the personnel proposed by the Tenderer matches the skills profile required by the Agency. A separate copy shall be provided for each individual named in the proposal.
Contract Execution
The Contractor shall nominate a single point of contact for day-to-day communication with the Agency.
1 Meetings
Progress meetings shall be held either at EUROCONTROL Headquarters or at the Contractor's premises. The Contractor shall provide agendas and minutes of such meetings.
2 Progress Reports
The Contractor shall provide a progress report 5 working days before each progress meeting.
3 QA Procedures
1 The Quality Plan
Quality Assurance (QA) procedures are to be applied during the contract. In particular, the Tenderer shall describe the quality procedures applicable in a quality plan. The Contractor shall then update and maintain the Quality Plan throughout the lifetime of the project.
2 Quality Control
The Contractor shall institute a programme of internal quality control activities. The Contractor's procedures for these activities shall be described and referenced in the Quality Plan.
3 Configuration Management
The Quality Plan shall detail the approach to be taken to the Configuration Management of deliverables.
• Naming conventions to be employed, both for software code, hardware (whether off-the-shelf or developed for the contract) and documents and drawings
• The methods by which versions of controlled items will be preserved and protected from unauthorised modification
• The methods by which inspection status will be indicated
• The procedures to be used for identifying and segregating non-conforming items
• The provisions to be made for back-up of software and documents developed or procured by the Contractor in support of the project. This should include details of disaster recovery measures adopted by the Contractor
• The use to be made of automated Configuration Management support tools (note that the use of automated support for Configuration Management is strongly recommended by the Agency)
4 Contractor's Internal Quality Assurance
The Contractor shall nominate in writing a single point of contact for Quality Assurance issues. The Contractor shall also define, in writing, the measures to be taken within the Contractor's organisation to ensure that procedures and standards are effective and are correctly implemented. These measures shall include a well-defined internal audit programme. The Contractor shall define the audits to be performed on this project, and shall make the results of these audits available to the Agency's Quality Assurance function. The Agency reserves the right to audit the conduct of the contract at the contractor's premises at any time, against the provisions of the contract and the Quality Plan. The Contractor shall make all necessary provisions for the Agency's rights of access to their premises, and provide reasonable accommodation and assistance during such audits. The conduct of audits, or any other Quality Assurance activity, by the Agency's representatives in no way relieves the Contractor from the responsibility for carrying out its own Quality Assurance activities.
5 Sub-contractor and Vendor Control
The Contractor is responsible for ensuring that all purchased items and services conform to the requirements of the agreed specification. In particular, the Contractor shall not sub-contract any part of this contract without the written consent of the Agency. The Agency reserves the right to inspect the Quality Assurance provisions of any proposed sub-contractor.
The Contractor shall ensure that all applicable requirements of this specification are passed on to any supplier or sub-contractor. This shall as a minimum include the requirements of this section, i.e. to pass on these conditions to any lower level supplier or sub-contractor.
Timescales and Effort
The contract will be restricted by a Limit of Liability (LOL) indicating the total effort that can be spent on this contract. The duration of the contract is estimated to be 6 months. During this period, between 220 – 250 days of man days are estimated to be conducted by a team of people.
Intellectual Property Rights
All Intellectual Property Rights (IPR) in the results of work undertaken by or on behalf of the Contractor(s) for the purposes of the Contract, and any copyright therein shall vest in and be the property of the EUROCONTROL Agency.
Annex A Experience classification
Tenderers shall complete copies of the following tables showing, for each of the listed areas, how well the experience of each of the personnel proposed by the Tenderer matches the skills profile required by the Agency. A separate copy shall be provided for each individual named in the proposal.
The columns of the tables have the following significance:
The “Code” column contains an internal Eurocontrol reference to the particular requirement. The prefix “MRS” indicates a required skill and “DRS” indicates a desirable skill. It is not required that each individual should possess all of the mandatory skills; it is sufficient that the skills profile of the proposed team as a whole shall satisfy each mandatory requirement, at least to the “Basic Understanding” level.
The “Technical Area” column contains a brief description of the area of expertise.
The “Rating” column shall be completed by the Tenderer to show the level of expertise offered by the named individual. The following notation shall be used in the “Rating” column:
Blank No significant knowledge/experience in this area
* Basic understanding
** Moderate experience
*** Thorough understanding, extensive experience.
The “Reference” column shall be completed by the Tenderer to refer to the section in the Tenderer's proposal that best justifies the rating.
Statement of Expertise
Person’s name: ________________________________________________________
Proposed role in the project: ______________________________________________
General Requirements
|Code |Technical Area |Rating |Reference |
|MRS01 |University degree in engineering, science or equivalent | | |
| |professional experience | | |
|MRS02 |Excellent working knowledge of English, written and spoken | | |
|MRS03 |Ability to work well in an international environment both | | |
| |as part of a team and independently | | |
|MRS04 |Ability to work within an ISO 9001 Quality environment | | |
|DRS01 |A working knowledge of French is an advantage | | |
|DRS02 |Availability within the team of a qualified network | | |
| |engineer would be advantageous | | |
Specific Requirements
|Code |Technical area |Rating |Reference |
|MRS05 |Experience of aeronautical data communications | | |
|MRS06 |Experience of mobile data communications in other domains | | |
|MRS07 |Experience with the analysis of operational service | | |
| |descriptions for air/ground data communications | | |
|MRS08 |Experience with IP based solutions and networks | | |
|MRS09 |Experience of Mobile IP | | |
|MRS10 |Experience of IPSec | | |
|MRS11 |Experience of SSL/TLS | | |
|MRS12 |Experience of the ICAO Aeronautical Telecommunication | | |
| |Network | | |
|MRS13 |Experience with the ATN Internet SARPs | | |
|MRS14 |Understanding and Experience of the Operational | | |
| |Requirements defined by the ICAO OPLINK Panel | | |
|MRS15 |Understanding of aeronautical safety and performance | | |
| |requirements | | |
|MRS16 |Knowledge of future datalink applications in the CASCADE | | |
| |programme | | |
|MRS17 |Experience with specifying trials and prototype activities| | |
|MRS18 |Understanding of the main European activities within the | | |
| |data link area | | |
|MRS19 |Understanding of the operational requirements for | | |
| |Air/Ground and Mobile data link services | | |
|DRS03 |Knowledge of IP SNDCF | | |
|DRS04 |Knowledge and understanding of EUROCAE documents ED-110A, | | |
| |ED-120 | | |
|DRS05 |Experience of VDL Mode 2 | | |
|DRS06 |Experience with Systems Management mechanisms | | |
|DRS07 |Experience with interoperability aspects of distributed | | |
| |applications | | |
|DRS08 |Knowledge of the state-of-the-art mobile and fixed | | |
| |subnetwork technologies | | |
|DRS09 |Knowledge of COCR document | | |
|DRS10 |Knowledge of 3-step FANS / ATN convergence strategy | | |
|DRS11 |Knowledge and experience of XML specification | | |
Computer Tools and Environments
|Code |Technical Area |Rating |Reference |
|MRS20 |Microsoft Windows XP (User) | | |
|MRS21 |Microsoft Word 2000 for Windows or higher | | |
|MRS22 |Microsoft Excel 2000 for Windows or higher | | |
|MRS23 |Microsoft PowerPoint 2000 for Windows or higher | | |
|DRS12 |MS Project | | |
|DRS13 |LINUX | | |
ANNEX B Initial Considerations
1 System Requirements
Existing air-ground aeronautical communication mechanisms have been designed from the outset to meet a number of fundamental requirements. These include:
• Support for and segregation of multiple traffic types
• Seamless integration of multiple subnetwork types
• Policy-based routing.
In the general move to commoditised communications based on COTS products, these requirements may require re-examination.
2 CLNP Routing
The ATN, like any internet, is fundamentally concerned with forwarding and routing data packets. CLNP was selected as the forwarding protocol for ATN as a means to satisfy the identified system requirements. On a network-wide basis, CLNP performs packet forwarding hop-by-hop using routing tables. The CLNP function in each router examines the header of a received packet, indexing the routing table to determine the next hop, i.e. the next router, and then forwards the packet to that address. This continues until the last router in the chain is reached and the packet is delivered to the destination end system.
The ATN uses the CLNP Security label in a non-standard way to distinguish different communication types and classes.
The routing tables are populated and dynamically maintained by IDRP, effectively providing mobility support. The distributed adaptive routing protocol is generically characterized as distance vector routing, by which any change in connectivity is propagated or “advertised” to affected routers throughout the network. Routing updates consist of a vector containing a destination address and a distance metric, which is an attribute associated with the path being advertised to a particular destination. In the ATN, the path attribute indicates the type of traffic to be carried over the advertised path as well as the air/ground subnetwork used to reach the advertised address. Thus as an aircraft moves from one air/ground router to another, one or more new path(s) with traffic type and air/ground subnetwork characteristics is (are) advertised through the network and the old route(s) is (are) withdrawn.
This distributed approach to mobility permits rapid convergence of routing tables with each aircraft being treated independently. It inherently provides separate and (in the presence of multiple air/ground subnetworks) redundant paths to an aircraft, each of which has appropriate traffic type and air/ground subnetwork type characteristics. CLNP uses the destination address and the security parameter in the packet header to index the appropriate path when performing hop-by-hop forwarding.
The IDRP approach to mobility, in addition to naturally supporting multiple traffic types over multiple air-ground subnetworks, is efficient from a time and update complexity perspective. Updates propagate outwards from the aircraft through the air/ground router(s) to the rest of the network. Consequently, ground end systems that are geographically close to air/ground routers communicating with a given aircraft have their paths adjusted very quickly. This is generally the situation for ATC communications where a particular ATC centre communicates with aircraft in its geographic airspace.
3 TCP/IP Routing
The CLNP and IDRP protocols are functionally similar to protocols used on the World Wide Web (informally “The Internet”) today. CLNP is similar to the Internet Protocol Version 4 (IPv4). The routing support of IDRP is similar to the Border Gateway Protocol Version 4 (BGP4). Although functionally similar, there are significant differences between the ATN and Internet protocols.
1 Multiple Subnetworks
IPv4 and BGP4 do not support policy based routing over multiple subnetworks simultaneously.
BGP4 functionality is similar to IDRP. However it requires a supporting transport connection provided by TCP, which is not available with current VHF air-ground subnetworks. Dynamic routing is a consequence of connection-mode transport, which is not a "given" for future applications, unlike current air-ground applications.
2 Traffic Types
ICAO operational panels have established requirements for multiple traffic types and classes to share the air-ground subnetwork(s). In the case of the ATN provisions, the standard CLNP security label is used for ATN-specific purposes to convey non-security information. For ATSC, it is used to select the class of communication. For AOC, subnetwork preferences can be specified.
BGP4 supports a limited set of path attributes when advertising routes. Specifically it does not have the equivalent of the IDRP security attribute, which is used in ATN to differentiate between traffic types (different ATS categories, AOC, APC, etc).
IPv4 is also limited in that it does not have a parameter to signal traffic types. IPv6 has an extensible header that could be used to define parameters to signal different traffic types and subnetwork types as is signalled by the security label in CLNP.
3 Addressing
The limited address space of IPv4 would not support the requirements for a global hierarchical address structure. This may not be an issue if the scope of the addressing is limited to local domains in the future. The extended address space of IPv6 would facilitate mapping or otherwise adapting a global address hierarchy.
4 Mobility
While IPv6 has the potential for use as a forwarding protocol in the aeronautical environment, a solution for aircraft mobility is also required. Mobile IP is one candidate solution. However, Mobile IP in its current form is inefficient and would not operate across simultaneous multiple subnetworks in support of multiple traffic types.
In principle it would be possible to extend BGP to support additional routing attributes and to have its own built-in transport so as not to be dependent on TCP. BGP has already been extended to advertise IPv6 routes. However, this would require extensive validation and would offset the benefits of COTS products being available. This contrasts with IDRP, which supports multiple protocols by design (but is not available in COTS products).
Under Mobile IP a mobile node has two addresses: a permanent address on its home network and a care-of address on another visited network. In the original (IPv4) version, a mobile node connects to a foreign agent that sends the care-of address back to the home agent with the permanent address. Communication between the mobile node and correspondent node is then tunnelled through the home agent. This method of operation is not efficient since traffic to a mobile node is indirect through the home agent even if the correspondent happens to be in proximity to the foreign agent.
For example, a Qantas aircraft might have a home address in Australia. When flying to the USA, it could have a care-of address in the USA. Communication from a centre in the USA to the aircraft would be addressed to the home address in Australia and then re-routed to the US network before reaching the aircraft.
IPv6 Mobile IP attempts to overcome this by permitting direct communication once a new session is established. However, there are still problems associated with the delay in updating routing information since the “old” router must now forward packets to the “new” router. In general, this further complicates the process and the result is that the correspondent node must now perform a routing function. Of course, any routing protocol has an associated convergence time, and what is important is to relate this to operational requirements.
When compared with the IDRP distributed adaptive routing approach to mobility, Mobile IP may result in longer paths to an aircraft for basic mobility support. Furthermore, no provision is made to concurrently support multiple traffic types over multiple subnetworks in the protocol itself. Thus unless the protocol is modified (which would negate the benefits of COTS product availability), multiple home and foreign agents (or at least different permanent and care-of addresses) may be required, for example, one for each traffic type, resulting in increased complexity.
At best Mobile IP might be used on a single subnetwork basis without being able to distinguish traffic types. However even this limited use is subject to the problems outlined above.
5 Other Considerations
Certification and software assurance would be a major consideration. It is unlikely that COTS software could be used in safety-critical aircraft communications systems without extensive (and expensive) design assurance processes, although certification "credit" can be derived if a COTS product is widely deployed and supported.
4 Alternative Mobility Scenarios
1 Basic Networking Scenarios
The following general approaches to the network support of highly mobile applications can be envisaged:
• Dynamic Address Assignment
In this scenario, an aircraft uses a single service provider (e.g. the SITA data link service) over a single type of data link. The aircraft could be dynamically assigned a single Network Address that it uses whilst it is logged into that network. After the aircraft logs off the network, the Address can, after a suitable quarantine period, be re-assigned to another aircraft. In this scenario, a mobile user connects to a network, performs the required application transactions, and then logs off ("break before make"). Each session is completely independent of any other. User authentication cannot be dependent on a user’s IP Address as this will usually be different for each session. Ground-initiated communication is not possible, unless supported by a dynamic mechanism to inform ground applications of an aircraft's connectivity.
• Serial use of Different Networks
In this scenario, an aircraft may move between different Air-Ground Networks (e.g. when moving from Oceanic to Continental Airspace) but will still need to maintain communications with (e.g.) its Current Data Authority. Transition between the datalinks should be seamless and must not interrupt ATC communications. However, if network Addresses were dynamically assigned by each such network (as above), then a discontinuity in communications would occur as the end-to-end connections would have to be terminated and then reconnected using the new Network Address.
This scenario therefore requires that a Network Address is statically assigned to each aircraft and stays with the aircraft as it moves between different networks. This is an altogether more complex scenario.
The basic TCP/IP Internet cannot support this scenario because of the requirement that the same IP Address is used regardless of how the host computer connects to mobile networks. Mobile IP could in principle support scenarios such as this. However, Mobile IP has drawbacks as discussed above in terms of single point of failure and security issues.
• Concurrent use of Different Networks
In this scenario, an aircraft is able to make concurrent use of multiple Air-Ground networks, routing packets dependent upon the quality of service or cost of the service. Again a static network address is required but additionally, the routing algorithms must include additional rules to select between alternative air-ground datalinks if this scenario is to be useful.
The basic TCP/IP Internet cannot support this scenario because of the requirement that the same IP Address is used regardless of how the host computer connects to mobile networks. Even with Mobile IP, a TCP/IP Internet cannot, today, support this mobility scenario.
Unless the fundamental requirements underlying the ICAO CNS/ATM concept are changed, then the second or third mobility scenarios would be required. High Availability and Security will also continue to be issues. The latter two scenarios provide increasing levels of protection to threats against network availability both due to system failures and Denial of Service attacks.
The following subsections build on these basic network scenarios to consider the resulting requirements on air-ground ATS applications
2 Air-Ground ATN over TCP/IP
This scenario represents a minimal change to the current ATN application architecture. It envisages TCP/IP replacing TP4/CLNP. An application level integrity check mechanism (such as PM-CPDLC) would avoid any need to improve the TCP checksum.
However, when considering mobility:
• The first mobility scenario (break before make) could be readily supported provided some mechanism is added to the ICAO air-ground datalinks to support dynamic IP Address assignment to airborne systems.
• Mobile IP could support the second mobility scenario (make before break). However, the single point of failure and security concerns may not make this viable.
• There is no mechanism in TCP/IP, outside of the research lab, to support the third mobility scenario (multiple concurrent air/ground datalinks).
The approach currently used in the ATN Internet to support the third mobility scenario could be redeployed for a TCP/IP ATN Internet:
a) The Inter Domain Routing Protocol (IDRP) also applies to IP routing and could be used in a TCP/IP ATN with only limited change to the current specification.
b) IPv6 would be required as the IPv4 address space is too small to support each aircraft configured as a separate Routing Domain.
c) An IPv6 Extension Routing Header would have to be defined to convey the application’s ATSC Class Requirement; Air-Ground and Ground-Ground ATN Routers would be required to make policy based routing decisions based on the information contained in this Routing Header and using routing information distributed by IDRP. (A similar extension header was defined for CLNP, using the security parameter). But this would not be COTS.
There is a significant amount of work required to implement the above. There is also a consequential impact on implementations as both IDRP and support of the IPv6 Extension Routing Header is required in critical components such as Airborne, Air-Ground and Ground-Ground Routers. This requires the development of new software and validation.
Where Safety Considerations apply, in areas such as avionics, there is a further issue to consider. Software partitioning may be a viable implementation option. However, TCP/IP is typically part of the OS kernel and any change, such as support for an Extension Routing Header, potentially invalidates a Safety Case based on widespread use of the software. Any change from standard TCP/IP is thus highly undesirable and a major disadvantage of this approach.
Any such undesirability is in addition to the extra costs imposed by any move from COTS TCP/IP.
3 "Transient Connection" Approach
This scenario considers the possible consequences of using TCP/IP for air-ground datalink based on dynamic address assignment. Specifically:
1. An aircraft is given a new dynamic IP Address every time it makes contact with a mobile network.
2. An aircraft has a separate and unrelated IP Address for every mobile network that it is currently in contact with.
3. The aircraft IP Address used (as the source for downlink messages and the destination of uplink messages) determines which mobile network is used for a given application’s datalink communications.
4. A TCP connection is therefore tied to a given mobile network and is lost when connectivity is lost to that mobile network, even if the aircraft still has datalink service available via a different mobile network.
Any change in mobile network connectivity is directly visible to the application, which has to take explicit action on such a change. Furthermore, the application also has to be aware of which mobile network(s) an aircraft is currently attached to, and the IP Address assigned to the aircraft for each such network. This is because when the air or ground End System initiates a TCP connection it must choose the appropriate IP Address for, respectively, the source or destination of the connection, so that the air-ground data link that provides the most appropriate ATSC Class for the application is used.
There is no dependency on IPv6 with this scenario, as there are no address size issues. Indeed, the use of IPv4 could be more efficient, as the smaller IPv4 headers are more suited to air-ground operations. Industry standard compression may also be used.
• Reporting Changes in Connectivity
A mechanism is needed to communicate an aircraft’s current connectivity to ground systems. This is because in, for example, CPDLC, the ground system that initiates a connection with the aircraft needs to know the IP Address assigned to the aircraft that is associated with the mobile network providing the most appropriate ATSC Class for the application.
Context Management is currently used by an aircraft to communicate the transport address (or in TCP/IP terms the IP Address plus port number) for each supported application. It would be a relatively simple extension for CM to report, in this scenario, each IP Address currently associated with the aircraft, the type of mobile network and the ATSC Class that should be associated with each IP Address.
A further extension to CM would be required to accommodate changes in mobile connectivity. The CM Logon information would have to be updated every time such a change occurs, thus keeping the ground system up-to-date.
• Impact on Applications
There would be an impact on connection-oriented applications such as CPDLC, ADS-C and D-FIS in this scenario, since changes in network connectivity are now visible to these applications.
The impact on ADS-C is relatively minor. The ground system is in control and when connectivity changes are reported by CM, it could terminate one set of ADS contracts (via a given mobile network) and establish a new set of contracts via a different mobile network. Such a change could be policy driven. For example, when an aircraft that has been given an Oceanic Clearance reaches a certain waypoint, ADS-C communications may be automatically switched to AMSS if connectivity is available.
The CPDLC SARPs permit the Current Data Authority (CDA) to replace an existing CPDLC connection with a new one. Any open transactions are lost when this occurs. It is possible for the ground system to change the mobile network used by CPDLC by establishing a new connection, and to do this without an operational impact, provided that it ensures that there are no open transactions when this is performed. No matter what the ground system does, there is a risk that a CPDLC request may be downlinked during the switchover and this would be lost.
On the other hand, a CPDLC connection is always changed when there is a change from one CDA to another. A CDA operates in a well-defined airspace and should have coverage over the whole airspace, preferably by single air-ground mobile network. In a well-planned CPDLC deployment, it is therefore unlikely that there will be a need to change the mobile network used, in normal operation.
• Handling Unexpected Changes in Mobile Connectivity
The ideal scenario for changes in mobile connectivity is “make before break”. That is an aircraft comes into contact with a new mobile network, reports this to the ground using CM and the ground system changes application connections before the aircraft goes out of range of the previous mobile network. There will be inevitably situations in which this ideal scenario does not happen.
Mobile network connectivity may be lost before the ground system has the chance to change the communications path and there may be a temporary loss of communications as a result.
With applications such as ADS-C, this should not be a major problem as the ground system can re-establish the contracts using any available mobile network should the ADS connection be unexpectedly terminated. It would be aware of available mobile networks as the aircraft will have reported them via CM. On recovery of an ADS connection, a Demand Contract could be used to ensure that up-to-date information about the aircraft and its intent is available.
For CPDLC, the CDA could re-establish a connection should a CPDLC connection be unexpectedly lost, though any open transactions will be lost. Under current operational procedures the aircraft would revert to voice-based ATC for the remainder of its time under the control of the ATSU, which may not be acceptable in a heavily loaded sector.
4 "Connectionless" Approach
For future ATS applications, the viability of using a completely connectionless communication environment based on COTS IP should be investigated, as this would appear to minimise the impact of changes in mobile connectivity and to bring some potential benefits.
Applications such as CPDLC are concerned with:
• The initial establishment of communications with a current data authority (CDA)
• The exchange of messages in well defined transactions
• Transfer of communications from the CDA to the next data authority (NDA).
There is generally a well-defined context (e.g. the relationship between the aircraft and the CDA) under which communication takes place. In the connection-oriented paradigm, this context is represented by the transport connection used to exchange messages. At a more detailed level, there is the transaction context; each transaction has an explicit ending (when a closure response is exchanged). A transaction is linked to the "outer" context provided by the transport connection, and the transaction is lost if the connection is lost.
The transport connection provides a convenient representation for the overall context. It also provides a service that should rapidly detect and report loss of communications and recover from errors. In practice, in order to detect loss of communications, the transport protocol has to periodically exchange packets known as “inactivity AKs” and it is the non-receipt of these packets (or reception of disconnects from underlying service) that results in connection loss being reported. The operational usefulness of this may be questioned, as the "heartbeat" period is typically set to a high value in order to keep the overhead to a minimum.
A connectionless mode of operation would require an alternative way of detecting loss of communications. This could be by exchanging “null” application messages, but this is no better or worse than transport inactivity heartbeat messages. Alternatively, the aircraft is aware of its current mobile connectivity so could quickly recognise when it is an actual NOCOMM state.
If another Mobile Network is available at the time the Mobile Network used for an application ceases to be available, the aircraft could quickly change to using the available alternative Mobile Network without any need to establish a new context. This is because in a connectionless environment the context is between the aircraft and the ground and independent of the means of communications. At the same time, the aircraft could use a service such as CM to report the loss of the Mobile Network and the ground user could switch to the alternative Mobile Network as well.
With connectionless communications, there is the additional risk that packets can be lost or duplicated. Duplicate packets can be detected and discarded by means of an unambiguous message identifier. Message loss is more of an issue. This could be handled by means of a Logical Acknowledgement (LACK), which would be returned automatically upon message receipt. Non-receipt of an expected LACK is used on the current connection-oriented CPDLC as an indication of a probable communications problem. In a connectionless environment, message retransmissions could be attempted and a communication loss reported only after a series of failed attempts. In practice, this depends on what is an acceptable value for a retransmission timer compared with the operational need for loss of communications to be detected quickly.
A Connection Mode Transport Protocol ensures that the transmission order of application messages is preserved on reception, but this property is lost in the connectionless case. The lack of guaranteed in-sequence delivery can be mitigated by careful application/procedure design. Alternatively, application-level message re-ordering based on sequence numbers could be specified.
One benefit of connectionless applications could be improved responsiveness to loss of communications and straightforward recovery by use of an alternative communications path.
Another potential benefit would be more efficient usage of the data link. For example, a CM Logon currently requires the exchange of two relatively small application level messages. With current air-ground subnetworks, many lower level protocol messages are exchanged, including transport connection and termination messages and subnetwork control frames. If the CM Logon messages were exchanged using a connectionless communications service, then typically only two messages would be exchanged; the Logon Request and the Logon Response. In exceptional cases, when either message was lost, the exchange would have to be repeated.
5 Safety Considerations
EUROCAE ED-120 / RTCA DO-290 identifies the hazards applicable to systems implementing the ATC Services described in EUROCAE ED-110A. It then derives the Safety Objectives for such systems and the Safety Requirements with which they must comply. (Both ED-120 and ED-110A are baseline documents for the EUROCONTROL LINK 2000+ Programme).
Implementers of ground and airborne systems must comply with the ED-120 Safety Requirements if their products are to be approved and/or certified for operational use.
The key Safety Objectives for air-ground datalink are:
a) The likelihood of undetected early delivery of a message used for separation (of aircraft from each other) shall be no greater than Remote.
b) The likelihood of an undetected late or expired message used for separation shall be no greater than Remote.
c) The likelihood of undetected misdirection of a message used for separation shall be no greater than Remote.
d) The likelihood of undetected corruption of a message used for separation shall be no greater than Remote.
e) The likelihood of undetected out of sequence messages used for separation shall be no greater than Remote
Objectives a) and b) are concerned with timing – a message must be neither too early nor too late. Un-intended early release of a clearance can result in a hazard, as can a clearance that was delayed and then delivered, only to be executed after it was intended. Both imply use of synchronised clocks (the degree of synchronisation is a another question).
Objectives c) and d) are concerned with avoidance of corruption and mis-delivery. Mis-delivery itself can result from routing errors or corruption of addressing information. They imply the need for a suitable integrity assurance mechanism.
Objective e) is concerned with message sequencing and, specifically, dependent clearances. There has been considerable debate over whether this implies that the communications services must preserve message sequencing. EUROCONTROL studies concluded that when dependent clearances are issued, the safety requirement is that the controller’s intent is preserved as to the order of execution of the clearances. The technical solution to this is that dependent clearances must be concatenated into the same message and a further related clearance cannot be issued until the closure response has been received. The conclusion is then that the safety requirement is on the user of the communications service and not on the communications service itself.
The analysis showed that there is no other workable solution given the current structure of the ICAO CPDLC implementation.
Future applications and operating concepts, including other CPDLC services, might require a sequence assurance service.
• Integrity and Mis-delivery Prevention
From the Safety point of view, a known weakness of TCP is that it only provides a simple 16-bit data integrity check that can detect no more than 1 in 65,535 errors and cannot detect byte swap errors.
The ATN Internet specification originally incorporated the standard 16-bit Fletcher checksum algorithm, specified in the TP4 protocol standard. In order to address early concerns over possible undetected mis-delivery and to achieve a higher degree of integrity assurance, an ATN-specific 32-bit integrity check was added as an extension to the TP4 protocol, using standard extensibility support procedures.
However, in the context of the LINK 2000+ Programme, a system wide analysis of the mis-delivery hazard identified shortcomings in the approach. This led to the development of Protected Mode CPDLC (PM-CPDLC), which includes a with every message a 32-bit integrity check field, whose value is computed from the message content, the Flight ID (callsign), the 24-bit ICAO Aircraft Address and the Ground Facility Designation of the ATSU. This provides a strong check on both message integrity and detection of mis-delivery. In addition to hazards that result from mis-operation of the communications services, it also detects errors in the operation of CM and ground distribution of CM related information.
PM-CPDLC is intended to be the basis of all future CPDLC deployments. PM-CPDLC removes from the ATN Internet the only LINK 2000+ Safety Requirement that applied to the Internet.
COTS TCP alone is not suitable for meeting the data integrity requirement; use of PM-CPDLC is an essential dependency for any consideration of TCP/IP.
• Availability
A general loss of CPDLC within an ATC Sector could lead to a sudden increase in controller workload, as there may be several CPDLC transactions in progress and each of them now has to be concluded by voice procedures. The hazard level associated with loss of datalink communications has an impact on all components of the communication system.
At present, CPDLC loses all context information when the CPDLC connection is lost; the only option is voice recovery for any open transactions. CPDLC is vulnerable to even short term loss of service. Recovery at the application user level following a short-term loss of connection is therefore required. The alternative would be to force unrealistic availability targets on to the communication infrastructure.
The conclusion is that an application level integrity validation mechanism such as that used by PM-CPDLC is a key enabler for the use of TCP/IP for connection-mode datalink services such as CPDLC, because it removes the need to modify TCP/IP in order to meet the Safety Requirements for data integrity and prevention of mis-delivery.
6 Information Security Considerations
An early analysis by EUROCONTROL identified the following threats and vulnerabilities for air-ground datalink applications:
a) Masquerade of a Controller, potentially leading to loss of separation due to execution of an invalid clearance.
b) Masquerade of a Pilot, leading to confusion (e.g. issuing of a clearance ahead of time).
c) Modification of uplink messages, leading to loss of separation due to execution of an invalid clearance.
d) Modification of downlink messages, leading to confusion (e.g. issuing of a clearance ahead of time).
e) Denial of Service by jamming, or modification or masquerade of routing information.
No threats due to loss of confidentially were identified. In voice-based ATC, no attempt is made to keep ATC communications confidential and neither is there any current intent to make datalink ATC confidential. However, as ATN supports other classes of communication including AOC, it may be required to support confidentiality in some circumstances.
Edition 3 of ICAO Doc 9705 defines provisions for security. With IDRP security an airborne router (thus an aircraft) is authenticated to an air/ground router so that route updates are protected from masquerade, modification, and replay attacks. Doc 9705 also allows for an air/ground router to be authenticated to an airborne router.
The ATN security solution has been optimised for use over air-ground subnetworks. A hybrid approach is specified, in which symmetric session keys are used to produce a cryptographically strong 16-bit Message Authentication Check (MAC) on application messages.
An IP-based security solution would have to provide similar efficiency and strength.
There are well-known security issues with Mobile IP. The Mobile IP approach to security has been to use an Authentication Server. The server approach naturally introduces delays. In addition, both the Authentication Server and the Home Agent represent single points of failure.
Also, because the mobile node sends packets with its home network as the source address while inside a foreign network, routers in the foreign network using ingress filtering access control lists will drop the packets rather then forward them. One solution to this problem is reverse tunnelling, with the foreign agent sending packets back to the home agent. However, this solution results in essentially the original IPv4 version with attendant longer paths and thus delays.
The possibility of integrating the ATN Security Extensions into PM-CPDLC exists and could provide a highly efficient mechanism for authentication of the sender, protecting integrity and protecting against mis-delivery.
Denial of Service attacks based on jamming have to be counted by means to detect the transmitter and physical security. Mitigation of Denial of Service by providing alternative routes via other air/ground technologies is a feature of the ATN Internet.
A move to TCP/IP datalink would increase the need for effective security due to the very openness of TCP/IP. There is a certain amount of protection ("security by obscurity") due to the ICAO ATN using communications protocols that are not COTS and hence which are not widely available. Attacks on TCP/IP networks are well publicised, and a great deal of effort continually goes into devising new forms of attack. Any cheap computer supports TCP/IP, and datalink systems based on TCP/IP without effective security mechanisms would be vulnerable to attack from any such system.
Thus the vulnerability analysis would need to be updated before any use of TCP/IP datalink is contemplated.
There would be an increased need to protect the integrity of application messages. This could be achieved using the existing ATN solution, SSL/TLS, or IPSec. There are various trade-offs between these options. The use of IPSec (the industry standard IP Security Framework) would need to be considered. The advantages of IPSec (e.g. available freeware implementations) would need to be weighed against the advantages of the ATN application level solution (e.g. better bandwidth utilisation). SSL/TLS (TCP/IP transport layer security) should also be considered, since this is in many ways a more natural fit than IPSec (TCP/IP network layer security).
As noted above, there are no known current requirements to make datalink ATC confidential (e.g. by encryption of the messages). On the other hand, if there were a requirement for confidentiality of ATN communication then IPSec would be a candidate for this. The ATN application solution can also be easily updated to add confidentiality.
If confidentiality were justified for datalink communications, then it is probably also justifiable for voice-based ATC; a requirement for confidentiality would have a much bigger impact than just on datalink. Link layer encryption in the future communication system may thus be a more natural solution since it would protect both voice and data.
Routing security needs (such as protection of IDRP packets) will depend upon the network architecture. Any move to use TCP/IP for air-ground datalink would impact the vulnerability analysis if this resulted in a change to the mobile routing strategy. The actual impact of the change would depend on what the change was. Further investigation would be required in this area.
7 Software Assurance Considerations
EUROCAE ED-109 / RTCA DO-278 “Guidelines for Communication, Navigation, Surveillance, and Air Traffic Management (CNS/ATM) Systems Software Integrity Assurance” provides a way of classifying levels of confidence in the correct operation of a software function and how to go about assuring that the required level of confidence is achieved.
Assurance Level 6 (AL6) applies for software of uncertain origin for which a high level of confidence is not essential.
Assurance Level 5 (AL5) can be gained when confidence in the operation of a piece of software is gained through widespread use over an extended period. Due to the length of time over which error-free operation has to be demonstrated, it is difficult to gain more confidence than the probability of failure being no worse than 1 in 103 to 104 operations.
Greater confidence in a system’s correct operation can be gained by introducing a well-defined Software Development Lifecycle based on recognised standards, and the Quality Assurance procedures that ensure that the lifecycle is adhered to. This reduces the probability of defects remaining in the final version of the software. Together with a well-defined software architecture and verifiable requirements, this constitutes the requirements for Assurance Level 4 (AL4).
Higher Assurance Levels add further orders of magnitude improvement to the level of confidence. AL3 requires traceability to low-level requirements at the software module level, and the testing of those low level requirements. AL2 and AL1 impose further degrees of requirements and source code verification, often requiring some form of independent verification mechanism.
ED-109 is a relatively new standard and is being applied to ground systems. An existing standard DO-178B/ED-12B is used as the software development requirements for avionics.
The software assurance level to which a given system must be built depends on the Airspace in which it will be used and the Safety and Performance Requirements. For example, in the European Airspace covered by LINK 2000+, the Safety Authority has ruled that in order to exchange profile-changing CPDLC messages, ground systems on which a safety requirement has been placed must be compliant with ED-109 AL4, while avionics must be compliant with DO-178B Level C (ED-109 AL3).
The development of PM-CPDLC has implied that ATN Internet functions do not have to comply with any Safety Requirements in the current version of ED-120. In practice, ATN Internet functions are implemented in the same physical systems as CPDLC and may still have a negative effect on the CPDLC implementation unless strong separation between the functions can be demonstrated i.e. there needs to be software partitioning that permits functions with different Assurance Levels to execute on the same processing environment.
Open Source Software (i.e. Linux) gives a number of advantages for Safety Related Systems, including making it easier to ensure continued support over the extended in-service lifetime of such systems, and that configuration control is under the control of the user rather than the vendor. The widespread use of Linux also enables in-service experience to be cited in terms of evidence that the system is reliable and there is confidence in a low level of defects even though AL4 principles may not have been applied during its development.
The software itself can be partitioned so that AL4 functions are in separate processes to those that do not have to be AL4. In practice, the AL4 requirement is largely placed on software that manipulates the information interchanged between and within systems, rather than on the data transport mechanism.
TCP/IP functionality is integrated into the OS kernel. However, any modification to the TCP/IP function would invalidate not only the “in service experience” case for using the TCP/IP function but also for the whole OS kernel, because it is an integral part of the kernel.
Any argument as to the suitability (or otherwise) of IPv4 for air-ground datalink can be extended to an OS kernel with embedded TCP/IP support.
ANNEX C DATALINK SERVICES TO BE SUPPORTED
The following datalink services are assumed in the COCR, and are required to be supported by the air-ground communications. Conversely, the impact of the communications technology on the design of the applications needs to be considered. For example, if the communications mechanism does not guarantee an acceptable level of data integrity then appropriate means must be incorporated into the application (cf. the impact of the safety analysis on CPDLC, resulting in the development of Protected-Mode CPDLC). A connectionless communications service will require appropriate state and contextual information to be retained by the communicating end systems.
AIR TRAFFIC SERVICES (ATS) APPLICATIONS
ATC Clearance Service (ACL)
An aircraft under the control of an ATSU transmits reports, makes requests and receives clearances, instructions and notifications through ACL. The ACL service specifies the aircraft - Controlling Air Traffic Services Unit (C-ATSU) dialogue exchanges via air/ground communications. This service is the basic building block for trajectory conformance management.
Automatic Controller-flight crew Data Link Communications (Auto-CPDLC)
Auto-CPDLC is automatic preparation and sending of messages to a single or multiple aircraft (multicast). Other non-tactical messages (e.g., squawk changes) can also be delivered in this way.
ATC Microphone Check (AMC)
When the voice channel is blocked, such as when an aircraft has a stuck microphone, the AMC Service provides an alternative to voice communication for contacting other aircraft, as well as the one with the stuck microphone, via data link. This allows a message to be dispatched to some or all aircraft being controlled by that sector/position. The AMC Service is a one-way uplink and requires no response.
Data Link Taxi Clearance Delivery (D-TAXI)
A flight due to depart from an airport, or an aircraft that has just landed, must obtain a series of clearances from the Controlling Air Traffic Service Unit in order to proceed from/to its stand to/from the runway. This is a specific use of ACL on the ground. The objective of the D-TAXI Service is to provide automated assistance to Controllers and flight crews to perform these communication exchanges during ground movement operations.
Data Link Surface Information and Guidance (D-SIG)
The D-SIG Service provides automated assistance to flight crews by delivering a current, static graphical airport map. D-SIG presents an updated (e.g., taxiway closures, runway re-surfacing) and integrated representation of all the airport elements necessary for ground movements to the flight crew. Adding the visual representation of taxi routes provided by D-TAXI to the D-SIG Service complements this goal.
Departure Clearance Service (DCL)
A flight due to depart from an airfield must first obtain departure information and clearance from the C-ATSU. The DCL Service provides automated assistance for requesting and delivering departure clearance and related route of flight information.
Down Stream Clearance (DSC)
In specific instances, flight crews need to obtain clearances or information from ATSUs that may be responsible for control of the aircraft in the future, but are not yet in control of it. The DSC Service provides assistance for requesting and obtaining Downstream ATSU (D-ATSU) clearances or information using air/ground data link. The DSC Service is a specific instance of ACL with a D-ATSU that can only be initiated by the Aircrew. For example, this service could be used in the absence of ground/ground coordination capability.
Pilot Preferences Downlink (PPD)
Aircrews have preferences on the way the flight is to be conducted for various operational reasons. In order to execute pertinent control strategies, controllers need to be aware of these preferences. The PPD Service allows the aircrew, in all phases of a flight, to provide the Controller with a set of preferences not available in the filed flight plan (e.g., maximum flight level) as well as requests for modification of some flight plan elements (e.g., requested flight level). It automates the provision to Controllers of selected Aircrew preferences even before the aircraft reaches their sector.
Dynamic Route Availability (DYNAV)
The objective of the DYNAV Service is to automate the provision of route changes when alternative routings can be offered by the ATSU, even before the flight is under their control. For example, aircrews can be offered routes that have become available due to lifting of military Special Use Airspace reservations, dissipation of weather or other operational restrictions.
Arrival Manager (AMAN) Information Delivery Service (ARMAND)
ARMAND automatically transmits relevant arrival manager advisories directly to flight crews that are within the optimum horizon of the AMAN, but may be beyond the limits of the ATSU that contains the flight’s destination airport. The ARMAND service transmits target, expected or revised approach time advisories relevant to the destination airport. This exchange may subsequently be followed by an ACL transaction. When COTRAC becomes available, ARMAND will be superseded for those equipped.
Graphical Enabler for Graphical Co-ordination (GRECO)
The purpose of GRECO is to establish revised route contracts between flight crew and Controllers during the flight using graphical interfaces and automation systems, in particular the FMS. GRECO gives flight crews the freedom to choose how they meet ATC constraints by creating one new constraint – eventually returning to the planned route. The flight crew or controller could initiate the coordination via a 4D downlink request. When COTRAC becomes available, it will allow changes to multiple constraints and thereby obviate the need for GRECO.
Common Trajectory Co-ordination (COTRAC)
The purpose of COTRAC is to establish and agree on 4D trajectory contracts in real time using graphical interfaces and automation systems, in particular the FMS. COTRAC differs from and may replace GRECO in that it will allow new trajectory contracts involving multiple constraints (latitude/longitude, altitude, airspeed, etc.).
Flight Plan Consistency (FLIPCY)
The FLIPCY Service provides information to detect inconsistencies between the ATC used flight plan and the one activated in the aircraft’s Flight Management System (FMS). This information may generate an uplink ACL message to resolve the inconsistency.
Flight Path Intent (FLIPINT)
The FLIPINT Service consists of the downlinking of the trajectory predicted by the FMS (ADS [Contract]) together with some additional information in order to support the Flight Data Processing System trajectory prediction. FLIPINT includes a FLIPCY data function plus FMS ETA, velocity prediction, airborne winds, etc.
System Access Parameters (SAP)
The scope of the SAP Service is to make specific, tactical flight information (instantaneous indicated heading, air speed, vertical rate, and wind vector) available to the Controller or ground automation by extracting the relevant data from the airborne system. The use of the SAP parameters by the ground system should be considered as a means to provide enhancements to the existing ATC surveillance functions. The SAP Service can be periodic or event driven and is available in all phases of flight.
Data Link Operational Terminal Information Service (D-OTIS)
The D-OTIS service provides flight crews with compiled meteorological and operational flight information derived from ATIS, METARs, NOTAMs, and PIREPs specifically relevant to the departure, approach and landing phases of flight. Delivery can be implemented through local broadcast, addressable point-to-point ground/air communications or both.
Data Link Runway Visual Range (D-RVR)
The D-RVR Service provides flight crews with up-to-date RVR information related to an airport’s runway(s). At any time of their choosing, the flight crews can request RVR information related to any airport’s runway(s). Delivery can be implemented through local broadcast, addressable point-to-point ground/air communications or both.
Data Link Operational En Route Information Service (D-ORIS)
The D-ORIS Service provides flight crews with compiled meteorological and operational flight information, derived from “En Route” weather information, from NOTAMs, as well as from other sources, specifically relevant to an area to be over-flown by the aircraft or any area of interest in the en route domain. Delivery can be implemented through local broadcast, addressable point-to-point ground/air communications or both.
Data Link Significant Meteorological Information (D-SIGMET)
The purpose of D-SIGMET information is to advise flight crews of the occurrence or expected occurrence of weather phenomena that may affect the safety of aircraft operations. The preparation and issue of SIGMET reports is the prime responsibility of meteorological watch offices (MWO). SIGMET information messages are distributed on ground initiative to aircraft in flight through associated ATS units. Delivery can be implemented through local broadcast, addressable point-to-point ground/air communications or both.
Data Link Automatic Terminal Information Service (D-ATIS)
D-ATIS provides terminal information relevant to a specified airport(s) in any phase of flight. Weather, active runway(s), approach information, NOTAM information is provided by data link rather than by voice. Delivery can be implemented through local broadcast, addressable point-to-point ground/air communications or both.
Data Link Flight Updates Service (D-FLUP)
The D-FLUP Service provides all the ATM-related operational data and information aimed at the optimisation of the flight preparation supporting punctual departure. Examples of this data include information related to the departure sequence, CDM agreements, slot time allocations, as well as to airborne target approach times. Special operations such as de-icing will be included in this service. Delivery can be implemented through local broadcast, addressable point-to-point ground/air communications or both.
Automatic Dependent Surveillance – Broadcast (ADS-B)
ADS-B is a function on an aircraft or a surface vehicle operating within the surface movement area that periodically broadcasts (reports) its state vector (horizontal and vertical position, horizontal and vertical velocity) and other information. ADS has been traditionally used in non-radar airspace to supplement command and control functions of ATS. Unlike ADS-B, ADS (Contract) downlinks addressed position reports to ATSUs on a contract basis. These reports have been credited with bringing order and separation confidence in the airspace where implemented.
The ADS-B system transmits and receives messages to support air-to-air and air-to-ground surveillance reports. The Minimum Aviation System Performance Standards for ADS-B provide guidance regarding performance standards. ADS-B services currently require once/second broadcasts for use with/without other supporting systems and services, e.g., CDTI, ACL, and radar. ADS-B is used to provide the information in various environments to support different services. These include but are not limited to:
• ATC surveillance in all domains; with or without primary or secondary radar support
• Airborne surveillance for situational awareness
• Enhanced visual acquisition
• In Trail Procedures (ITP)
• Crossing and Passing operations (C&P)
• Sequencing and Merging (S&M) operations
The ITP, C&P, and S&M services are supported by both broadcast and transactional communication. Broadcast communication is used for position information. Transactional related communication (ACL) provides the controller/flight crew instructions (e.g., merge behind target aircraft).
Traffic Information Service – Broadcast (TIS-B)
In some airspace, and for some classes of users, a ground–to-air TIS-B will be implemented. TIS-B allows the broadcast of sensor-based traffic information and/or rebroadcast of ADS-B information. Traffic information is displayed on associated aircraft avionics. TIS-B update rates may be less frequent than ADS-B update rates. Some services, such as ATC Surveillance and Airborne Surveillance for Situational Awareness, which do not rely on high update/transmission rates could be implemented through TIS-B. TIS-B is likely to be available through 2030 in some areas and for some users (such as GA), resulting in a mixed equipage environment.
Urgent Contact Service (URCO)
The Urgent Contact (URCO) Service is to provide assistance for establishing urgent contact (via voice or data link) with Aircrews that may or may not be under the initiating ATSU’s control at the time.
Data Link Alert (D-ALERT)
The objective of the D-ALERT Service is to enable Aircrews to notify, by data link, designated stakeholders when the aircraft is in a state of emergency or abnormal situation (with or without declaring emergency).
Data Link Logon (DLL)
The aircrew activates the data link system and DLL takes place automatically without flight crew involvement. Logon and contact with the system is performed by the DLL Service, which encompasses all data link exchanges required to enable the other data link services.
ATC Communication Management (ACM)
When a flight is about to be transferred from one sector/ATSU to another, the Aircrew is instructed to change to the voice channel of the next sector/ATSU. The ACM Service provides the air/ground exchanges between an Aircraft and its transferring ATSU (T-ATSU) as well as with its receiving ATSU (R-ATSU) to establish communications control of the flight. In addition, when data link communications are involved, the ACM service manages the data link connection transfer.
AERONAUTICAL OPERATIONAL CONTROL (AOC) SERVICES
AOC is an important element of ATM and is needed for continued efficient operation of airspace users. AOC services are concerned with the safety and regularity of flight and as such are defined in Annex 6 of the ICAO Convention. AOC applications involve voice and data transfer between the aircraft and the Aeronautical Operations Control centre, company or operational staff at an airport.
Out Off On In (OOOI)
Movement Service messages including; Out, Off, On, In, report data that is automatically routed to the AOC Movement Control System. This service is a one way downlink from the aircraft to AOC to report significant points in the flight’s progress.
NOTAM Request/NOTAMs
NOTAM service delivers Automatic Terminal Information Service (ATIS) that includes any immediate NOTAMs available. This service is activated manually by the flight crew from a menu list displayed on the cockpit Control and Display Unit.
Free Text
Free Text Service includes miscellaneous uplinks and downlinks via textual messages between the cockpit and AOC/other ground based units. This does not include cockpit-to-cockpit exchanges. Free text can also be used to append standard pre-formatted downlink response messages such as in Oceanic Clearances.
Weather Request/Weather Report
Weather Request Service includes flight crew requests for airport weather. Weather reports include Meteorological Aerodrome Reports (METARs) and Terminal Area Forecasts (TAFs), which are provided via downlink messages. The AOC Flight Planning System replies by delivering the requested weather information to the cockpit.
Position Report
Position Report Service includes automatic downlink of position during the climb, cruise and descent portions of the flight. The primary purpose is delivery of position reports at required waypoints for use in AOC tracking systems. During all phases of flight, but principally en route, the aircrew can also manually initiate the Position Report Service.
Flight Status
The Flight Status Service includes, for example, malfunction reports to maintenance including fault reporting codes that allows maintenance and spares to be pre-positioned at plane side after landing. Fault reporting can be done manually, or automatically sent when triggered by an event.
Fuel Status
Fuel Status Service downlinks fuel state en route and prior to landing. This service allows ground services to dispatch refueling capability promptly after landing. The aircrew also reports the fuel status upon specific AOC request.
Gate and Connecting Flight Status
This service includes manual and automatic uplink of connecting flights, ETD, and gate before landing. Information about rebooking may also be included in case of late arrival or cancelled flights.
Engine Performance Reports
Aircraft Condition Monitoring System (engine and systems) reports are down linked automatically and on request. This is usually done in the en route phase.
Maintenance Troubleshooting
Through this service, maintenance is able to discuss and correct technical problems while the aircraft is still airborne. Although voice is customarily used for the discussion, this service may be used to provide the instructions for problem resolution in a textual format.
Flight Plan Request/Flight Plan Data
This service provides the operators with the ability to request and receive the AOC-developed flight plan for comparison to that assigned by ATC and for loading into avionics. AOC flight plans have more information that flight plans filed with ATS.
Load Sheet Request/Load Sheet Transfer
Upon downlink request, the Load Sheet Control System uplinks planned load sheet and cargo documentation. Prior to departure, the final load sheet, including actual weight and balance data is automatically uplinked to the cockpit while the aircraft is at the gate or while waiting for takeoff. The minimum equipment list (MEL) can also be confirmed at this time.
Flight Log Transfer
This service delivers next flight assignment, estimated time of departure, and gate information. Flight log information may be manually requested by the flight crew or automatically uplinked.
Real Time Maintenance Information
This service allows aircraft parameters to be sent to the airline maintenance base in real-time to monitor the operational status of the aircraft. Information could include engine data, airframe systems, etc. This service allows information to be obtained more quickly than the normal maintenance data acquisition via on-board recorders. It is typically event driven, triggering a flow of information until resolution is achieved.
Graphical Weather Information
Weather information is sent to the aircraft in a form that is suitable for displaying graphically on displays in the cockpit, e.g., vector graphics. This service supplements or replaces the text weather information available in current AOC services. Graphical weather information is expected to be more strategic in nature, and will supplement on-board tactical weather radar, which has inherent range and display limitations.
Online Technical Trouble Shooting
This service allows airline ground maintenance staff to request information from on-board systems so that a diagnosis of problems can be undertaken at locations away from the aircraft’s base.
Real-Time Weather Reports for Met Office
Information derived by the aircraft on the environment in which it is flying (e.g., wind speed and direction, temperature) can be sent automatically in real-time to weather forecasting agencies to help improve predictions.
Technical Log Book Update
This service allows the flight crew to complete the aircraft’s technical log electronically and send the updated log to the maintenance base. Information regarding the technical status of the aircraft can therefore be obtained much more quickly so that any remedial action can be taken at an early stage.
Cabin Log Book Transfer
This service allows the cabin crew to complete the aircraft’s cabin equipment log electronically and send the updated log to the AOC. Information regarding the status of the cabin equipment can therefore be obtained much more quickly so that any remedial action can be taken at an early stage.
Update Electronic Library
The Electronic Library will replace many of the paper documents currently required to be carried in the cockpit (e.g., Aircraft Manual and AICs). This service enables that electronic information to be updated automatically. The transmitted information will be used to update various avionic systems, e.g., an Electronic Flight Bag (EFB) device.
Software Loading
This service allows new versions of software to be uploaded to the aircraft systems.
-----------------------
[1] The Contractor shall take into account any COCR updates from the drafting group producing the COCR, at least up to the contract start date.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- circuit to convert tumbler switch to momentary switch action
- n506rv van s aircraft rv builder forums and news
- the selection engine
- introduction steward observatory
- aim the aim of the project is to develop rfid based book
- western carolina university western carolina university
- deltasim studio
- requirements specification for a study into ip in the
Related searches
- requirements for a business loan
- requirements to be a teacher in florida
- education requirements for a lawyer
- system requirements specification example
- software requirements specification template free
- a study of the gospels
- requirements specification document example
- requirements specification sample
- a the abundance of a ground beetle species in a meadow b the zonation of seaweed
- dung beetles feed on the faeces of larger animals a study recorded numbers of
- product requirements specification sample
- convert a number into binary in python