Systems, Architecture and Interfaces (SAI) Date February 2, Peter Grau tel /SAI-052 lth.

Transcription

1 To Systems, Architecture and Interfaces (SAI) Date February 2, 2018 From Peter Grau tel Reference /SAI-052 lth Subject Summary Strawman Circulation Strawman for ARINC Project Paper 680: Autonomous Distress Tracking (ADT) This project was initiated in response to APIM The attached document is intended to define the means for global aircraft tracking capability. This will enable tracking of non-communicating aircraft and quick identification of crash sites. The completed document will include: End to end system requirements levied by ICAO and individual Civil Aviation Authorities (CAAs) including certification and operational requirements, and Acceptable Means of Compliance (AMC). Candidate architectures that would meet these system level requirements. Selected architecture(s) with detailed equipment and aircraft installation requirements. Chuck Adler, Boeing, prepared the initial draft based on inputs from the Hamburg, Germany meeting of the GAT Working Group and subsequent teleconferences. This draft includes comments, highlights, and suggestions and will become input for Draft 1 of ARINC Project Paper 680: Autonomous Distress Tracking (ADT). Action Additional comments for this document should be directed to Peter Grau at: peter.grau@sae-itc.org. The GAT Subcommittee will review the Strawman and any comments received at the next face to face meeting, scheduled for February 6-8, Those unable to attend the meeting may comment in writing ( ) to Peter Grau by March 2, This document is published information as defined by 15 CFR Section of the Export Administration Regulations (EAR). As publicly available technology under 15 CFR 74.3(b)(3), it is not subject to the EAR and does not have an ECCN. It may be exported without an export license Melford Blvd., Suite 120, Bowie, Maryland USA

2 Strawman for ARINC Project Paper 680 Autonomous Distress Tracking (ADT)

3 TABLE OF CONTENTS Contents 1.0 INTRODUCTION Purpose of this Document Scope Objectives Related Documents Autonomous Distress Tracking (ADT) Requirements Study Requirements Overview ICAO Requirements ICAO Annex ICAO Annex ICAO GADSS Concept of Operations (ConOps) Regulatory Requirements European Union (EU) Regulation EUROCAE Requirements Key Requirements Terms Discussion and Definitions Key Terms Summary Source documents and associated discussions Autonomous Distress Tracking (ADT) and Autonomous Distress Tracking system Autonomy Distress Nuisance alert Resilience / Robustness to Failure An ADT Architectural Framework Integrated ADT Requirements for Architecture Study Autonomous Distress Tracking (ADT) Architecture Study Architecture Study Overview Space-Based Automatic Dependent Surveillance Broadcast (ADS-B) Architecture Study Description of Architecture Space Based ADS-B Architecture Mapped to the Architecture Frame Work Key Architecture Assumptions and Dependencies... 57

4 TABLE OF CONTENTS Key Airplane Infrastructure Support and Required Changes Key Network Infrastructure Support and Required Changes Key Ground Segment Support and Required Changes Compliance with Requirements Support for Related Services and Capabilities ELT-DT Architecture Study Description of ELT-DT Based Architecture ELT-DT based Architecture Mapped to the Architecture Frame Work Compliance with Requirements Support for Related Services and Capabilities Inmarsat Based SATCOM Architecture Study Description of Architecture Architecture Mapped to the Architecture Frame Work (action CA) Compliance with Requirements ref appendix c (action CA) Support for Related Services and Capabilities ADT with Iridium Transceiver Architecture Study Description of Architecture Architecture Mapped to the Architecture Frame Work Compliance with Requirements Support for Related Services and Capabilities Dissimilar Complementary Architecture Study Description of Architecture (HG/VR) Architecture Mapped to the Architecture Frame Work (BT) Compliance with Requirements (CA) Support for Related Services and Capabilities (VR / MB IOU) Detection/Triggering Architecture Study Description of Architecture Airplane Integration Architecture Requirements & Recommendations ADT system equipment Electrical interfaces and data bus Electrical power Installation aspects: Environmental Qualification

5 TABLE OF CONTENTS Zone installation aspects Maintenance, system health monitoring and fault isolation Particular risk analysis: fire Software considerations Summary and Conclusions Acronyms

6 TABLE OF CONTENTS List of Figures Figure 1 GADSS CONOPS Version 6.0 Concept Scenarios (1 of 2) Figure 2 GADSS CONOPS Version 6.0 Concept Scenarios (2 of 2) Figure 3 ADT Functional Block Definition for Study Architecture Framework Figure 4 Study Architecture Framework Applied to ELT-DT Based System Figure 5 Study Architecture Framework Applied to Space Based ADS-B and SATCOM System Figure 6 Study Architecture Framework Applied to SATCOM Based System Figure 7 SAI GAT Architecture Study Requirements Tables_REV_NEW.xls (embedded file) Figure 8 Space-Based ADS-B Network Figure 9 ADS-B Architecture for Distress Tracking (Example) Figure 10. Emergency State Field of the Emergency/Priority Status Message Figure 11. Examples of potential new Sub type codes to support ADT functionality Figure 12. ADT Functional Block Diagram Figure 13. ADS-B Implementation Architecture Figure 14. ELT(DT) Performance Summary Figure 15. Cospas-Sarsat Rescue System Figure 16. GADSS Conops 6.0 ELT(DT) Swim Lane Figure 17. ELT-DT Mapped to ADT Functional Blocks Figure 18: Overall ADT architecture as published within ICAO Doc Figure 19: Inmarsat GADSS implementation Figure 20: ADT SATCOM Iridium Architecture Option 1 (External Trigger Source) Figure 21: ADT SATCOM Iridium Architecture Option 2 (Internal Trigger Function) Figure 22: ADT SATCOM Iridium Architecture Option 3 (External and Internal Trigger Functions) Figure 23: ADT functional architecture Figure 24: The scope of work of this document: the Distress/Triggering architecture and its interfaces. 99 Figure 25: Further detailing of the Distress/Triggering architecture and its interfaces; and the minimization of nuisance triggers by inhibition of the logic in certain flight phases Figure 26: Distress Event Detection architecture Figure 27: Triggering Criteria Logic architecture Figure 28: ADT system functional architecture Figure 29: Possible ADT system architecture. A new computer unit/computer module is inserted to compute the distress event / triggering criteria logic Figure 30: Possible ADT system architecture. Note that this figure differs from Figure 2, in the aspect that the switch and the display blocks are directly connected to the transmission system Figure 31: Possible ADT system architecture Figure 32: Possible ADT system architecture. In this scheme, the distress event detection / triggering criteria logic computing is performed on the ground Figure 33: Possible ADT system architecture. Note that this figure only differs from Figure 5, in the aspect that both the airborne and ground transmission and reception systems are integrated

7 TABLE OF CONTENTS List of Tables Table 1 Analysis/Discussion of EU 2015/ Table 2 Analysis/Discussion of ED Table 3: Overview of the most common dissimilar complimentary architectures

8 1.0 INTRODUCTION 1.1 Purpose of this Document 1.2 Scope 1.3 Objectives 1.4 Related Documents This document documents the architectural options to support an Autonomous Distress Tracking (ADT) System that are being levied by the International Civil Aviation Organization (ICAO) and individual Civil Aviation Authorities (CAAs) (both at the aircraft-level and on-ground systems). All derived system-level requirements are also documented within this report. In addition, a System Functional Block Diagram, allocating the requirements to each functional block, is also documented. COMMENTARY The difficulty in locating the crash sites of Air France Flight 447 in June 2009 and Egypt Air Flight 804 in May 2016, and the disappearance of Malaysia Airlines Flight 370 in March 2014, has prompted significant international effort to provide means for a global aircraft tracking capability. Since 2015, ICAO has worked to amend ICAO Annex 6 standards to include requirements for tracking commercial planes during all flight phases, including functionality of autonomous identification and reporting of distress situations (Autonomous Distress Tracking). In addition, the European Commission has published Commission Regulation (EU) 2015/2338 with similar, but in some cases differing, requirements. The scope of this document is limited to documenting the system-level requirements for an Autonomous Distress Tracking (ADT) System and a survey of potential architectures to support these requirements. Requirements associated with Normal or Abnormal Tracking, as identified in ICAO or CAA documents, are not part of the ADT requirements. The objective of this ARINC report is to: 1. Capture all documented ICAO and regulatory system-level requirements for an ADT system 2. Integrate these and derive a requirements set to use in evaluating a range of potential ADT architectures. 3. Perform a study of applicable ADT architectures to support the following characteristics development work. These documents provide source requirements for the ADT system. COMMISSION REGULATION (EU) 2015/2338 of 11 December 2015 amending Regulation (EU) No 965/2012 as regards requirements for flight recorders, underwater locating devices and aircraft tracking systems

9 EU No. 965/2012 of 5 October 2012 laying down technical requirements and administrative procedures related to air operations pursuant to Regulation (EC) No. 216/2008 of the European Parliament and of the Council ICAO Annex 6, Operation of Aircraft, Part I, International Commercial Air Transport Aeroplanes ICAO Annex 11, Air Traffic Services ICAO Document, Concept of Operations Global Aeronautical Distress & Safety System (Ver 6.0, 7 June 2017) ICAO Document 10054, Manual on Location of Aircraft in Distress and Flight Recorder Data Recovery (Not yet released)

10 2.0 Autonomous Distress Tracking (ADT) Requirements Study ADT system-level requirements are documented within the following subsections. 2.1 Requirements Overview ICAO Requirements ICAO Annex 6 The ICAO requirements that apply to ADT are contained in different ICAO documents, and are documented within the following sub-sections. The ICAO Annex 6 requirements that apply to ADT are documented in the following table. The section number refers to the section within ICAO Annex 6. Section Requirement LOCATION OF AN AEROPLANE IN DISTRESS All aeroplanes of a maximum certificated take-off mass of over 27,000 kg for which the individual certificate of airworthiness is first issued on or after 1 January 2021, shall autonomously transmit information from which a position can be determined by the operator at least once every minute, when in distress, in accordance with Appendix 9. Recommendation. All aeroplanes of a maximum certificated take-off mass of over 5,700 kg for which the individual certificate of airworthiness is first issued on or after 1 January 2021, should autonomously transmit information from which a position can be determined at least once every minute, when in distress, in accordance with Appendix 9. The operator shall make position information of a flight in distress available to the appropriate organizations, as established by the State of the Operator. Note. Refer to for operator responsibilities when using third parties The operator shall develop policies and procedures for third parties that perform work on its behalf. Appdx 9 Appdx 9 1 LOCATION OF AN AEROPLANE IN DISTRESS (Chapter 6, 6.18, refers) Location of an aeroplane in distress aims at establishing, to a reasonable extent, the location of an accident site within a 6 NM radius.

11 Section Appdx Requirement An aeroplane in distress shall automatically activate the transmission of information from which its position can be determined by the operator and the position information shall contain a time stamp. It shall also be possible for this transmission to be activated manually. The system used for the autonomous transmission of position information shall be capable of transmitting that information in the event of aircraft electrical power loss, at least for the expected duration of the entire flight. Note. Guidance on the location of an aeroplane in distress is provided in Attachment K. Appdx An aircraft is in a distress condition when it is in a state that, if the aircraft behaviour event is left uncorrected, can result in an accident. Autonomous transmission of position information shall be active when an aircraft is in a distress condition. This will provide a high probability of locating an accident site to within a 6 NM radius. The operator shall be alerted when an aircraft is in a distress condition with an acceptable low rate of false alerts. In case of a triggered transmission system, initial transmission of position information shall commence immediately or no later than five seconds after the detection of the activation event. Note 1. Aircraft behaviour events can include, but are not limited to, unusual attitudes, unusual speed conditions, collision with terrain and total loss of thrust/propulsion on all engines and ground proximity warnings. Note 2. A distress alert can be triggered using criteria that may vary as a result of aircraft position and phase of flight. Further guidance regarding in-flight event detection and triggering criteria may be found in the EUROCAE ED-237, Minimum Aviation System Performance Specification (MASPS) for Criteria to Detect In-Flight Aircraft Distress Events to Trigger Transmission of Flight Information. Appdx When an aircraft operator or an air traffic service unit (ATSU) has reason to believe that an aircraft is in distress, coordination shall be established between the ATSU and the aircraft operator.

12 Section Appdx Requirement The State of the Operator shall identify the organizations that will require the position information of an aircraft in an emergency phase. These shall include, as a minimum: a) air traffic service unit(s) (ATSU); and b) SAR rescue coordination centre(s) (RCC) and sub-centres. Note 1. Refer to Annex 11 for emergency phase criteria. Note 2. Refer to Annex 12 for required notifications in the event of an emergency phase. Appdx Appdx Attach K Attach K 1 When autonomous transmission of position information has been activated, it shall only be able to be deactivated using the same mechanism that activated it. The accuracy of position information shall, as a minimum, meet the position accuracy requirements established for ELTs. ATTACHMENT K. LOCATION OF AN AEROPLANE IN DISTRESS (Supplementary to Chapter 6, 6.18) GUIDANCE FOR LOCATION OF AN AEROPLANE IN DISTRESS 1. INTRODUCTION The following material provides guidance on locating an aeroplane in distress. The Triggered Transmission of Flight Data Working Group (TTFDWG) reviewed forty-two accidents to determine an indication of the distance from a last-known aeroplane position to the location of an accident site. The report concluded that in approximately 95 per cent of the cases, when the aircraft position was known one minute prior to the accident, the accident site location was within a 6 NM radius of that position.

13 Section Attach K 1.2 Attach K 2.1 Requirement When an aeroplane has an accident into water and becomes submerged, the location of the accident site within a 6 NM radius on the surface becomes more important. Starting the initial search area beyond a 6 NM radius reduces the amount of time available to search for and locate the aeroplane. At current estimated underwater search capabilities of 100 km2/day, an area with a 6 NM radius could be searched in four days. Allowing for naval assets to reach the search area and conduct the search, it is estimated that an area of km2, equivalent to a radius of 14 NM, will be able to be searched before the ULD battery degrades. Starting at an area of more than 6 NM radius reduces the probability of a successful location during an initial search, whilst extending the location requirement beyond 6 NM radius reduces the time available to search with no appreciable gain in the probability of recovery. 2. CLARIFICATION OF PURPOSE OF EQUIPMENT Information from which a position can be determined: Information from an aircraft system which either is active, or, when automatically or manually activated, can provide position information which includes a time stamp. This is a performance-based requirement which is not system-specific and may also bring operational benefits ICAO Annex 11 The ICAO Annex 11 requirements that apply to ADT are documented in the following table. The section number refers to the section within ICAO Annex 11. Section Requirement ICAO GADSS Concept of Operations (ConOps) The ICAO GADSS ConOps requirements that apply to ADT are documented in the following table. The section number refers to the section within the ICAO GADSS ConOps document.

14 Section Requirement The Autonomous Distress Tracking (ADT) function is used to identify the location of an aircraft in distress with the aim of establishing, to a reasonable extent, the location of an accident site within a 6 NM radius The ADT function uses on board systems to broadcast the 4D position, or distinctive distress signals from which the 4D position can be derived. The position information needs to be transmitted, without the need for flight crew action, at least once every minute when an aircraft is in a distress condition. An aircraft is in a distress condition when it is in a state that, if the aircraft behaviour event is left uncorrected, may result in an accident In terms of the autonomy, the ADT function needs to transmit as long as practically possible during the distress condition. As practically possible refers to a means to achieve resilience to failures of the aircrafts electrical power, navigation and communication systems as well as to human factors and unlawful human intervention or tampering The operator will need to be notified (directly or indirectly) when an aircraft is in a distress condition. The ADT function will need to include the capability to deliver the distress tracking information to SAR To identify a distress condition, the aircraft state will be analysed in realtime by aircraft systems or ground processes and the use of event detection and triggering criteria logic will initiate the notification of the alert to assist locating the aircraft in distress. Distress tracking is a combination of position reporting at intervals of one minute or less with a notification of distress. The event detection and triggering can be used to identify a distress condition (for a system that is already transmitting position information), or to notify a distress condition and also commence transmitting of positon information. Distress tracking manually initiated by the flight crew should also generate a notification The triggering criteria may include analysis of unusual altitudes, unusual speeds, potential collision with terrain, total loss of thrust/propulsion on all engines, Mode A squawk codes, etc. The triggers will be defined making sure that the criteria used maximises the probability of detection of an upcoming catastrophic event and minimises the probability of nuisance events In the case of an on-board triggered transmission system (distinctive distress signal), initial transmission of position information shall commence immediately or no later than five seconds after the detection of the distress condition. Note: The performance specifications for the in-flight event detection and triggering criteria are detailed in EUROCAE ED-237.

15 Section Requirement In case of recovery from the distress condition, distress tracking and any distress signal needs to be de-activated, however, the deactivation can only be done by the activating mechanism Functionality may be included that allows the aircraft operator to activate the ADT function, for example, when there is a (risk of) failure of the aircraft tracking systems or there is uncertainty about the status of the aircraft The ADT function approved by the State of the Operator should consider high-level performance criteria such as: a) Appropriate for the expected duration of flight b) Quality and integrity of data being transmitted c) Robustness of the communication link, including timely receipt of information and recovery after link-loss during unusual attitudes d) Cyber security considerations e) Robustness of the system performing the transmission f) Global coverage When it is identified that an aircraft is experiencing a distress condition, the effectiveness and efficiency of any subsequent RCC and SAR action will rely on the timely notification and sharing of relevant and consistent information between the actors involved. The source of the data will depend on which GADSS function identified the distress condition, however, in all cases the information to be shared will include: 4D Position information: Last known position Flight Track (past position reports) Planned route as updated by ATC Distress event trigger or type of emergency (why is the aircraft considered to be in distress) Flight Plan information Field 19 Flight/cargo manifest information Dangerous Goods

16 Section Requirement The sharing of distress tracking information requires global coverage and a global system approach. Pending the global coverage of System Wide Information Management (SWIM), this information should be made available through a distress tracking repository service as shown in the figure below: The distress tracking repository service ideally should be provided through a single infrastructure for the alerting and dissemination of distress beacon information. When necessary (in case of a situation which is distress or is judged to evolve towards distress) operators will submit relevant tracking information to the repository service to ensure timely availability to local RCC( s).

17 Section Requirement The point of contact repository service should be provided to assist an operator in contacting an ATSU (and if needed an RCC). The point of contact (PoC) information repository service should allow the position of the aircraft to be correlated to the appropriate ATS units and RCC areas of responsibility. The following minimum information can be returned by submitting a position: The identification and point of contact of the ATS unit and RCC responsible for the area of jurisdiction in which the position fits; In case the position is near to an ATS unit boundary the neighbouring ATS unit Identification and Point of Contact will also be provided; In case the position is near to an RCC boundary the neighbouring RCC Identification and Point of Contact will also be provided The service needs to be available 24/7 and its content is subject to a maintenance process that ensures that the information is accurate and complete to the maximum extent possible and practical. In an Emergency phase, aircraft tracking information needs to be available to all actors. In order to identify the nature of the situation and any corrective measures, communications will be established between the relevant ATS unit(s) and the aircraft operator. This will help eliminate any time lag regarding the establishment of the communications themselves and analysis both by the aircraft operator and the ATS unit of action required. When the ATS unit detects an aircraft in distress it will monitor the situation and communicate, and assist as required. The ATS unit will need to contact the aircraft operator to seek additional information and assist with the emergency phase. When the aircraft operator detects a distress condition it will contact the ATS unit corresponding with the latest known position of the aircraft. The aircraft operator will provide the ATS unit any additional information deemed relevant including the event that initiated the aircraft operator action. At this point, the ATS unit initiates the appropriate emergency phase and should attempt to establish contact with the aircraft. When an RCC detects an aircraft in distress it will contact the ATS unit and the aircraft operator.

18 Section Requirement Emergency phases are used as a standardised method in the ATS/SAR system (ATS units and RCCs) to notify the level of concern for the safety of persons or aircraft which may be in danger. The figure below illustrates the main information links for an emergency requiring the sharing of aircraft tracking information. As a result of on board triggers the ADT can be activated and the information forwarded by the ADT provider to the aircraft operator and RCC. The ATS unit may make use of additional sources of information and share this with the actors. Other ATS units may also receive aircraft tracking information; for example, when there is a probability that the flight will enter their area of jurisdiction Upon initial notification, an event is classified by the notified RCC or ATS unit as being in one of three emergency phases as specified in Annex 11 Chapter 5: Uncertainty (INCERFA), Alert (ALERFA), or Distress (DETRESFA). The emergency phase may be reclassified as the situation develops. The current emergency phase should be used in all communications about the incident as a means of informing all interested parties of the current level of concern for the safety of persons or craft which may be in need of assistance.

19 Section 4.12 Requirement Notification by ATS units to RCCs will contain such of the following information as is available in the order listed: (NOTE the information below is a consolidated list from Annex 11 and the IAMSAR Manual) a) UNCERTAINTY, ALERT or DISTRESS, as appropriate to the phase of the emergency; b) agency and person calling; c) nature of the emergency; d) significant information from the flight plan, including: Aircraft call sign and type; point of departure and departure time; route of flight; destination and estimated time of arrival (ETA); number of persons on board; endurance; colour and distinctive markings; survival equipment carried; dangerous goods carried; telephone number of pilot in command; e) unit which made last contact, time and means used; f) aircraft tracking information including last position report and how determined (course, speed, altitude); i) any action taken by reporting office; j) any direction finder equipment available; and j) other pertinent remarks.

20 Section 4.13 Requirement Information which is not available at the time notification is made to an RCC should be sought by an ATS unit prior to the declaration of a distress phase, if there is reasonable certainty that this phase will eventuate. Further notification to the RCC will, without delay, be furnished by ATS units with: a) any useful additional information, especially on the development of the state of emergency through subsequent phases; or b) information that the emergency situation no longer exists. Note - The cancellation of action initiated by the RCC is the responsibility of that centre ATS units and RCCs will normally interact with aircraft operators when there is a need due to an emergency involving one of their aircraft. ATS units/rccs and aircraft operators may collaborate for emergency planning or exercise purposes. When an area control or a flight information centre decides that an aircraft is in the Uncertainty or the Alert phase, it will, when practicable, advise the operator prior to notifying the RCC. On the other hand, if an aircraft is in the distress phase, the RCC is notified immediately. The operator is then notified when practicable and receives the same information as the RCC. The emergency status is monitored by the ATS unit and the RCC. The emergency phase may be cancelled as a result of determination of a false alarm or disappearance of the cause of the emergency. Confirmation needs to be received from the crew, ATS unit, aircraft operator and RCC as applicable Regulatory Requirements Regulatory requirements that apply to ADT are contained in different regional, national, and Civil Aviation Authority (CAA) documents, and are documented within the following sub-sections European Union (EU) Regulation The EU regulation that mandates ADT is: COMMISSION REGULATION (EU) 2015/2338 of 11 December 2015 amending Regulation (EU) No 965/2012 as regards requirements for flight recorders, underwater locating devices and aircraft tracking systems

21 EU 2015/2338 amends EU No. 965/2012 of 5 October 2012 laying down technical requirements and administrative procedures related to air operations pursuant to Regulation (EC) No. 216/2008 of the European Parliament and of the Council Specifically, EU No. 965/2012,.Annex IV COMMERCIAL AIR TRANSPORT OPERATIONS [PART-CAT] SUBPART A GENERAL REQUIREMENTS is amended by adding the following new requirement: CAT.GEN.MPA.210 Location of an aircraft in distress Aeroplanes The following aeroplanes shall be equipped with robust and automatic means to accurately determine, following an accident where the aeroplane is severely damaged, the location of the point of end of flight: (1) all aeroplanes with an MCTOM of more than kg, with an MOPSC of more than 19 and first issued with an individual CofA on or after 1 January 2021; and (2) all aeroplanes with an MCTOM of more than kg and first issued with an individual CofA on or after 1 January 2021 MCTOM - Maximum Certified Take-Off Mass Table 1 Analysis/Discussion of EU 2015/2338. Section Title Page Requirement(s) Definition of function: (4) It is necessary to take into consideration the disappearance of flight MH370 on 8 March 2014 and the recommendations made by the multidisciplinary meeting of the ICAO on global tracking of 12 and 13 May The position of public transport aircraft should be known at all times, even in a remote location, in order to facilitate the location of the aircraft in case of an abnormal behaviour, an emergency or an accident. Whenever possible, the aircraft tracking means should be robust to loss of normal electrical power on board and should not offer any control to disable it during the flight. Therefore, Regulation (EU) No 965/2012 should be amended in order to include additional requirements related to means to track aircraft on a global basis, including over oceans and remote areas. Key performance requirement: Whenever possible, the aircraft tracking means should be robust to loss of normal electrical power on board and should not offer any control to disable it during the flight. on a global basis, including over oceans and remote areas. Discussion / Issues: 1. This is bullet point (4) on the title page. 2. There are no loss of power or crew control requirements documented in the actual new regulation CAT.GEN.MPA.210 Location of an aircraft in distress Aeroplanes. It may be left to the EASA AMC/GM to address loss of power and crew controls/ability to disable requirements as

22 Section Requirement(s) detailed requirements, but we won t know until EASA releases the AMC/GM for CAT.GEN.MPA There is no explicit definition of what global entails. Inserted: CAT.GEN.MPA.210 Location of an aircraft in distress Aeroplanes Definition of function: The following aeroplanes shall be equipped with robust and automatic means to accurately determine, following an accident where the aeroplane is severely damaged, the location of the point of end of flight: (1) all aeroplanes with an MCTOM of more than kg, with an MOPSC of more than 19 and first issued with an individual CofA on or after 1 January 2021; and (2) all aeroplanes with an MCTOM of more than kg and first issued with an individual CofA on or after 1 January Key performance requirement: The following aeroplanes shall be equipped with robust and automatic means to accurately determine, following an accident where the aeroplane is severely damaged, the location of the point of end of flight Discussion / Issues: 1. robust isn t defined 2. automatic is not defined, but automatic could be interpreted to mean that there is no manual action (by the pilot, airline ground operations, or air traffic controller) required in order to determine the location of the point end of the flight. 3. accurately determine the location of the point of end of flight - There are no quantifiable accuracy requirements stated.

23 Section Requirement(s) (h) CAT.IDE.A.280 is amended as follows: Definition of function: EU No. 965/2012 currently states: CAT.IDE.A.280 Emergency locator transmitter (ELT) (a) Aeroplanes with an MOPSC of more than 19 shall be equipped with at least: (1) two ELTs, one of which shall be automatic, in the case of aeroplanes first issued with an individual CofA after 1 July 2008; or (2) one automatic ELT or two ELTs of any type, in the case of aeroplanes first issued with an individual CofA on or before 1 July (b) Aeroplanes with an MOPSC of 19 or less shall be equipped with at least: (1) one automatic ELT, in the case of aeroplanes first issued with an individual CofA after 1 July 2008; or (2) one ELT of any type, in the case of aeroplanes first issued with an individual CofA on or before 1 July (c) An ELT of any type shall be capable of transmitting simultaneously on 121,5 MHz and 406 MHz. CAT.IDE.A.280 is modified by EU 2015/2338 as follows: (i) point (a) is replaced by the following: (a) with an MOPSC of more than 19 shall be equipped with at least: (1) two ELTs, one of which shall be automatic, or one ELT and one aircraft localisation means meeting the requirement of CAT.GEN.MPA.210, in the case of aeroplanes first issued with an individual CofA after 1 July 2008; or (2) one automatic ELT or two ELTs of any type or one aircraft localisation means meeting the requirement of CAT.GEN.MPA.210, in the case of aeroplanes first issued with an individual CofA on or before 1 July (ii) point (b) is replaced by the following: (b) Aeroplanes with an MOPSC of 19 or less shall be equipped with at least: (1) one automatic ELT or one aircraft localisation means meeting the requirement of CAT.GEN.MPA.210, in the case of aeroplanes first issued with an individual CofA after 1 July 2008; or (2) one ELT of any type or one aircraft localisation means meeting the requirement of CAT.GEN. MPA.210, in the case of aeroplanes first issued with an individual CofA on or before 1 July Discussion / Issues: For aircraft that meet the distress tracking requirement of CAT.GEN.MPA.210, then an automatic fixed ELT does not need to be installed (or can be removed).

24 2.1.3 EUROCAE Requirements Table 2 Analysis/Discussion of ED-237. Section Purpose and Scope General Requirements Requirement(s) Definition of function: This section provides a general description of the need for this system, justification for Autonomous Distress tracking, general discussion about triggering, background history, and general high level description of ICAO GADSS activates. This document defines the minimum specification to be met for criteria which can be used to detect an in-flight aircraft distress event and to trigger the transmission of sufficient information for the purpose of locating an accident site. It only specifies characteristics that are relevant to the logic used for event detection and trigger activation/cancellation Discussion / Issues: Need to make clear that this document does not endorse a specific methodology, just the triggering logic of an airborne system only. There is concern that this document has some statements that seem to imply the architecture even though there are other caveats stating the opposite. It is geared toward airborne ADT and does not really address the ground segment of the system Need harmonization with GADDS CONOPS This document defines triggering of an airborne system without any context of the greater system including the ground. There are requirements of on or off distress conditions with 10^-5 restriction of false positives. (Ref.: 3.2.4) There is some concern that manufacturers may create software that may not transmit some data that could have been useful to the ground operation s analysis of a pre-distress condition. Definition of function: The overall objective of this specification is to make sure that the criteria used to trigger in-flight transmission maximizes the probability of in-flight detection of an upcoming catastrophic event and minimizes the probability of nuisance activation. This MASPS is intended to define in-flight aircraft distress event detection and triggering criteria that can be used to activate the transmission of information used to locate an aircraft that is experiencing an event that, if left uncorrected, would likely result in an accident. Similar logic also applies to the detection of the return to normal This MASPS focuses on transport category aeroplanes above 27,000 kg. Therefore, using this MASPS for aircraft in other categories will require evaluation of the applicability of the specifications in this document. Discussion / Issues: Does not align with GADSS CONOPS does not discuss ground triggering and cancellation. Need to harmonize with compliance of all requirements.

25 Section Requirement(s) Background ICAO Activities COSPAS SARSAT Activities Definition of function: Provides a general description of the ICAO GADSS Concept of Operations (ConOps) Discussion / Issues: None Definition of function: General description of COSPAS-SARSAT activities. Discussion about second generation of the MEOSAR system and transponders using GPS/GLONASS and GALILEO satellites. Key performance requirement: A number of recommendations resulted from the studies conducted by accident investigation bodies. In particular, it was recommended that EASA and ICAO define the regulatory requirements for a new generation of ELTs that can be triggered in-flight. In parallel to the development of this document, the ED-62A Minimum Operational Performance Specifications have been improved to detail the specifications for second generation ELTs. Discussion / Issues: This section lacks an awareness of alternate Satcom means of transmissions such as Inmarsat and Iridium. It is focused on ELT s and second generation of MEOSAR related satellites and communication systems Description of Content Definition of function: Brief description of the 4 chapters, intent of system and benefit for airlines. Discussion / Issues: Chapters 1.3 s description of section Chapter 1 implies that there is a triggering system description where Chapter 1.1 does not imply that Operational Applications Triggering System Definition of function: General description that the event detection and triggering criteria logic supports SARS and benefits Airlines by providing almost immediate distress condition and location Discussion / Issues: None Definition of function: This is an overview of the triggering requirements. Section 3 The triggering system may consist of one or more physical devices. At least one of these devices must host the in-flight aircraft distress event detection and triggering criteria logic described within this MASPS. The triggering system should make the result of the triggering logic available to systems that would transmit information to be used to locate an aircraft that has experienced an accident.

26 Section Verification Procedures Requirement(s) Systems that can potentially transmit flight information include but are not limited to second-generation ELT or other systems (e.g. ACARS, ADS-B ). The system used to transmit the flight information while an aircraft is in a distress condition may have to comply with requirements defined in regulatory documents such as ICAO Annex 6 Discussion / Issues: Implies that the triggering system may be a separate system from delivery system(s). Need some discussion about the ADT system being able to attempt to communicate via various means available to it on the aircraft and implications for return cancellation of messages should the triggering logic be supplied from the ground (not covered in this document). Definition of function: The verification procedures specified in this document are intended to be used as guidance for demonstrating that the in-flight aircraft distress event detection and triggering logic meets the performance requirements. Although specific test procedures are cited, it is recognized that other methods may be used. Alternate procedures may be used if it can be demonstrated that they provide at least equivalent performance. Discussion / Issues: Discussed more fully in section Mandating and Recommendation Phrases Definition of function: Defining SHALL and SHOULD committee Discussion / Issues: None Common Definitions and Abbreviations Definition of Terms Definition of function: General description of terms used, no comment needed for most. Discussion / Issues: We noted two below that might lead to discussion Nuisance Trigger - Any trigger that is erroneously generated by the on-board triggering system when there is no potential for an accident. Simulation - The use of a laboratory-installed system of avionic components ( test bench ) representative of the aircraft in which the recording system is to be certified. The test bench may be controlled by a computer-based system including analogue and discrete inputs, to create specific operating conditions, such as 90 pitch up, or other conditions that cannot be tested in flight or are difficult to test on the aircraft. The test bench should be configured such that the computer or analogue inputs to the system drive the instruments and displays in a way representative of the aircraft. All avionic components installed in the test bench should be either of production standard or representative of the final production configuration. Note: there was other discussion about software simulation and the criteria needed to validate trigger logic, discussed in more detail in section 4.

27 Section Requirement(s) Abbreviations List of Reference Documents Definition of function: Abbreviations, reference and related docs. Discussion / Issues: None Related Documents 2.1 Overall System Introduction Definition of function: This chapter identifies general specifications and design considerations for the inflight aircraft distress event detection and triggering criteria logic. The model description below does not imply any particular system architecture employed on board the aircraft or ground-based. Discussion / Issues: None Model Description Definition of function: The components of an in-flight aircraft distress event detection and triggering criteria system can be broken down into individual functional blocks that have unique inputs and outputs. Each functional block is depicted in FIGURE 2-1 and is defined in paragraph This MASPS deals primarily with the In-flight distress event detection and triggering criteria functional block. Quantification of requirement: The functional blocks in Fig 2-1 are located on the aircraft. Discussion / Issues: In-flight distress event detection and triggering criteria depends on aircraft data only. While ConOps does not imply system architecture, FIGURE 2-1 does imply an aircraft based architecture. This section appears to provide a functional block diagram, not necessarily a specific architecture. Incompatibility/difference airborne function in ED-237 and ConOps in regards to the detection and notification of a distress state. Proposal: Architecture Component: Distress event detection and triggering logic Phase of Flight: All

28 Section Requirement(s) Introduction Definition of function: The purpose of this section is to define the minimum performance of the in-flight aircraft distress event detection and triggering criteria logic. Compliance with this specification is recommended as one means of assuring the logic will perform its intended function satisfactorily under normal operating conditions. The in-flight aircraft distress event detection and triggering criteria logic shall be designed to process data pertaining to aircraft status and provide output(s) to the transmission system(s) to trigger and/or cancel the transmission of flight information. This specification provides a minimum set of scenarios to be detected by the in-flight event detection and triggering logic. In order to minimize nuisance triggers and optimize triggering logic, the logic may be inhibited or may be limited in its ability to detect distress events during the following flight phases: take-off, initial climb, final approach, landing and goaround. Inhibition of the triggering logic shall not cancel an active trigger. Key performance requirement: Quantification of requirement: The triggering criteria logic may change based on the flight phase. Discussion / Issues: This is a summarized function to process aircraft status and transmit relevant data, an introduction. Again, the triggering logic is based on aircraft status. Proposal: Recommend to allow non aircraft systems to process aircraft data to determine aircraft status Architecture Component: Phase of Flight: All Triggering Criteria Definition of function: The triggering criteria should monitor the aircraft state for the occurrence of pre-defined scenarios. A minimum occurrence duration of a particular condition of a scenario (the persistence time) should also be considered as part of the triggering criteria logic. The triggering criteria should include logic to detect if the aircraft returns to normal flight to allow automatic cancellation. The set of triggering criteria should maximize the detection of scenarios, while limiting nuisance triggering. Excessive nuisance triggers have the potential to reduce confidence in the system as well as saturate SAR resources. Key performance requirement: Quantification of requirement:

29 Section Requirement(s) Discussion / Issues: The logic should address the temporary scenarios, including persistence time criteria, and cancellation. Proposal: Architecture Component: Phase of Flight: All Scenarios Definition of function: The scenarios listed below were developed based on analyses which included reviews of previous events and represent the minimum set which should be detected by the logic. They are identified by conditions which, if left uncorrected, are likely to result in an accident. Manufacturers may include additional scenarios or combine scenarios, provided that they do not impair the overall efficiency and/or reliability of the triggering logic. Each condition is defined by parametric data thresholds which may differ depending on the type of aircraft and its mission (as for example military training phase, aerial work, Search And Rescue civil, passenger transport). Scenario 1: Unusual attitude. The conditions may include, but are not limited to, excessive values of roll, pitch and yaw and their corresponding rates of change Scenario 2: Unusual speed. The conditions may include, but are not limited to, excessive vertical speed, stall condition, low airspeed, over speed or other speed conditions. Scenario 3: Collision with terrain. The conditions may include, but are not limited to, high rate of closure to terrain or inappropriate altitude for the current position. Scenario 4: Total loss of thrust/propulsion on all engines. The parametric data used to define this condition may be engine performance parameters or other parameters that result from loss of thrust. Key performance requirement: Quantification of requirement: Discussion / Issues: Provides examples of scenarios the logic should detect based on previous accidents Need more details about nuisance triggers? Should we assume nuisance trigger automatically ceases when condition ends? Suggests analysis should be conducted for specific aircraft types and conditions that evolve over time. Should address scenario 3: collision with terrain. Relatively easy to locate aircraft that collides with terrain (versus water/ocean). Compatible with GADS functionality? Proposal: Consider other situations for Scenario 3.

30 Section Requirement(s) Architecture Component: Phase of Flight: All Persistence Time Definition of function: The persistence time is the duration for which the condition(s) is true before a triggering signal is generated. The persistence time for each of the criteria should be balanced to trigger a transmission, as soon as practicable, that captures the greatest number of accidents possible while limiting the number of nuisance triggers. Key performance requirement: Quantification of requirement: Discussion / Issues: There should be a duration for the criteria before transmitting distress alert. Balance the nuisance rate with the valid trigger of a distress state. Proposal: Architecture Component: Phase of Flight: Commented [ACO1]: This really needs Automatic Cancellation Trigger Definition of function: A transmission cancellation notification will be generated when there are no triggering conditions present and the trigger cancellation criteria have been met. The set of trigger cancellation criteria should maximize the probability to detect that the flight crew have regained control of the aircraft and are maintaining a stable flight regime or the aircraft has landed safely. The notification will be generated for a duration sufficient for the transmitter to receive it, after which the triggering logic returns to its normal detection function. Key performance requirement: Quantification of requirement: Discussion / Issues: Adds a triggering cancellation criteria based on flight crew have regained control of the aircraft and are maintaining a stable flight regime. Based on aircraft data (not flight crew). If manually activate distress, then it can be manually cancelled. Implies a persistence time. Note, seems to look at a specific architecture. Can t send cancellation and alert at the same time. Proposal: Triggering and cancellation shall be distinguishable from each other. Aircraft in condition to trigger, once recovered, then cancel. Distinguish active cancellation. Cancellation positively transmitted.[revisit]

31 Section Requirement(s) Architecture Component: Phase of Flight: All Nuisance Trigger Definition of function: To minimize nuisance triggers [for distress condition] Key performance requirement: The triggering logic should implement accurate criteria specific to the target aircraft and be verified for correct operation against a database of exemplar flight data. Quantification of requirement: Nuisance rate objective of no more than 2 nuisance triggers per Flight Hours. The portion of the overall nuisance rate attributable to the triggering logic and causing a false alert to SAR providers, shall be no more than 1 nuisance trigger per Flight Hours. Discussion / Issues: The challenge may be to have a common/recognized a database. Aircraft in distress condition and then transmit, ignores an alert condition. Puts more effort on ground system to process alerts vs. hard distress. Points to inflight detection and transmission. Are all transmissions distress conditions? ELT tracking is distress only. Iridium/Inmarsat based systems are not limited to distress only. Distress indicates imminent danger. ED-237 focuses on specific portion of GATS concept. How to refine the definition of a nuisance trigger? A nuisance trigger does not justify a distress condition. Proposal: Architecture Component: Phase of Flight:

32 Section Information In The Trigger Requirement(s) Definition of function: The trigger sent to the transmission systems should contain sufficient information to determine whether the logic is requesting the start of a triggered transmission or the transmission of a cancellation signal. Key performance requirement: Shall be able to differentiate between the triggering and cancellation. Clarifies the need for an active transmission of a cancellation message Introduction: Performance Requirement Verification Performance Verification of Triggering Criteria Definition of function: Key performance requirement: Quantification of requirement: Discussion / Issues: Introduction to this section. Activation verification based on conditions and trajectories extracted from known accidents, Non-Activation verification based on conditions and trajectories extracted from known flights that did not result in an accident, Automatic cancellation verification, Proposal: Architecture Component: Phase of Flight: Definition of function: Key performance requirement: Verification ensures that all triggering logic and criteria parameters used are adequate, reliable, and robust. The following items shall be considered when evaluating the robustness of the triggering and cancellation logic: Event detection rate Nuisance trigger rate Cancellation cases Erroneous cancellation cases while in distress Quantification of requirement: Discussion / Issues: Erroneous cancellation cases are not defined anywhere else, how much weight do we want to put on them? Are there quantifiable test cases defined anywhere or implicit (1 per 100,000)

33 Section Verification of Event Detection Rate Requirement(s) How can we prove this, are there test databases? This is the negative false report versus false positive. Very rare event with a 10^-5 is a very high standard. It was noted by OEMs that auto-pilot software ex.: CAT3 auto-land, and end of runway detection etc. has the same strict requirements. Alternate views expressed were - those are very predictable set of circumstances, and this distress detection trigger logic requires detection of rare and non-normal conditions. Proposal: Architecture Component: Phase of Flight: Definition of function: Key performance requirement: Identifies an accident database is provided (in appendix 1), which is a minimum set for testing. All test scenarios may not be complete for validation. See below Quantification of requirement: Specifies that must have 100% compliance when testing against this database except when justified. Note: Event detection rate verification using only the datasets provided by the investigation agencies is incomplete. If those are the only accident datasets used, additional analytical verification is required to ensure that all scenarios defined in Chapter 3 are captured. Discussion / Issues: 100% compliance against testing using the known database, this is a very broad statement. Not all parameters for testing may not be available within the provided databases. This cannot be the only means of verification. We are missing definition of the criteria for justification of not meeting the 100% testing requirement. Proposal: If this database is admittedly insufficient then we recommend that the committee identify additional databases or methodologies to be able to test against all the possible scenarios in chapter 3. Architecture Component: Phase of Flight: All phases however chapter 3.1 gives a bit of leeway for some phases flight, i.e. takeoff and approaches

34 Section Requirement(s) Verification of Nuisance Trigger Rate Definition of function: One means to verify the nuisance trigger rate (see Nuisance Trigger) of the logic is to run the logic on a database of operationally representative flight data and to evaluate the resulting nuisance rate. The database should contain a sufficient number of flights to adequately assess the resulting nuisance rate against the objective. When building the database, it is recommended to use flights from similar aircraft types. It is recognized that operational data may not be available, and other aircraft types may be used if justified. The applicant, in coordination with the regulatory authorities, may determine that testing the complete set of triggers against such a database is impractical. In these cases, the regulatory authorities may accept an analytical approach to verifying the nuisance trigger rate, based on simulated data or combining the results of testing subsets of the logic. Key performance requirement: The database has to be valid for the aircraft type being certified. Since getting enough data about an aircraft may be difficult, then other aircraft type databases types may be used if justified. Quantification of requirement: Discussion / Issues: The specification applies to all aircraft types. Need large datasets for all aircraft types. Trigger rates on the order of 1/100K - probably need a couple million hours of data to have confidence that we can meet 1 in 100lk (10^-5) Might be beyond the capabilities and maturity of the industry to be able to provide complete datasets for testing This is the inverse of How do we justify similar aircraft type s datasets for a target aircraft type being certified? Need definition of justification. Higher propensity of nuisance alerts in some phases. Identify window of allowable events ex: Takeoff and Landings - transiting between these phases

35 Section Requirement(s) higher likelihood of false positives. Look at those areas more closely during testing The definition varies with aircraft type and mission type (and approach and performance specs.) Section 3 does call out different mission type we can think of examples of firefighting aircraft swooping and dropping extinguisher payloads, versus normal civilian transport How do we define and produce a common analytical approach or other means of testing that we can all use to validate the system performance, in addition to the given limited test databases? Reference Section definition of terms SIMULATION. Need a common criteria for simulations example: trigger input criteria. We feel that the nuisance trigger definition is inadequate. Proposal: Architecture Component: Phase of Flight: Verification of Cancellation Cases and Erroneous Cancellations Definition of function: The verification of the cancellation logic should be performed by analysis to demonstrate that it sufficiently detects the return to normal flight following an event and does not erroneously cancel any trigger before a stable flight regime is maintained. Appendix 1 incidents and accidents database may be used to support the analysis. Key performance requirement: Quantification of requirement: Discussion / Issues: Triggers are extremely rare events if aircraft autonomous system stop sending signal, even if A/C returns to normal flight, the ground and non-autonomous components of the system will probably be contacting the aircraft / verifying the situation so trying to test that we don t have false cancellations is very, very rare. So rare almost not applicable? Proposal: Architecture Component: Phase of Flight:

36 Section Appendix 1 - Database Info List of accidents and incidents table and List of Database Parameters table Requirement(s) Key performance requirement: None INFO only Defines a list anonymized flights within aircraft accidents / incidents database with flight phase and a description of the key scenario. There are 46 Accidents and 24 Incident reported flights. Appendix 2 - BAE commitment letter Key performance requirement: None info only BAE commitment letter to provide accident/incident database. 2.2 Key Requirements Terms Discussion and Definitions ADT system-level requirements are documented within the following sub-sections Key Terms Summary Autonomous Distress Tracking (ADT) - is the capability that enables the aeronautical safety system to identify and track an aircraft in distress. Note: this capability is described under Location of an Aeroplane in Distress in ICAO Annex 6 Part 1; and in EU 2015/2338 amending EU 965/2012, CAT.GEN.MPA.210. Autonomous Distress Tracking system - identifies the aircraft's distress condition and autonomously transmits information from which the aircraft position can be determined at least once every minute. ADT system shall be resilient to failures of the aircraft s electrical power, navigation, communication systems, as well as to human-machine interface errors. Autonomy - is the ADT system s ability to perform its function independently, as long as practical, during the distress condition. Distress - is a condition in which the aircraft behavior, if left uncorrected, is likely to result in an accident. Notes:

37 - This condition is determined by the ADT system with airborne system real-time analysis and / or ground processes. - ADT distress notification may be used to determine the start of the Distress Phase (a.k.a. DETRESFA), as defined in ICAO Annexes 11 and 12. Nuisance alert - an alert generated by a system that is functioning as designed but which is inappropriate or unnecessary for the particular condition. Resilience / robustness to failure - it is a measure of the sensitivity to failures, malfunctions, human errors and violations. The more resilient the system is, the less susceptible it is to failures. Note: ADT system should be resilient to failures Source documents and associated discussions Autonomous Distress Tracking (ADT) and Autonomous Distress Tracking system Sources: - ICAO GADSS CONOPS v. 6.0 (section 1.2 definitions) "The capability using transmission of information from which a position of an aircraft in distress can be determined at least once every minute and which is resilient to failures of the aircraft s electrical power, navigation and communication systems. Note: this capability is described under Location of an Aeroplane in Distress in ICAO Annex 6 Part 1" - ICAO Annex 6 (section Location of an Aeroplane in Distress) "All aeroplanes of a maximum certificated take-off mass of over kg for which the individual certificate of airworthiness is first issued on or after 1 January 2021, shall autonomously transmit information from which a position can be determined by the operator at least once every minute, when in distress, in accordance with Appendix 9." - EUROCAE ED-237 (section background) "The intent of this ADT System is to use on-board systems that can detect an emergency situation and broadcast position, or distinctive distress signals from which the position can be

38 derived, on protected frequencies and, depending on its application on each aircraft, to be automatically activated or manually activated at any time." - EU 2015/2338 amending EU 965/2012 (CAT.GEN.MPA.210 Location of an aircraft in distress Aeroplanes) "The following aeroplanes shall be equipped with robust and automatic means to accurately determine, following an accident where the aeroplane is severely damaged, the location of the point of end of flight: (1) all aeroplanes with an MCTOM of more than kg, with an MOPSC of more than 19 and first issued with an individual CofA on or after 1 January 2021; and (2) all aeroplanes with an MCTOM of more than kg and first issued with an individual CofA on or after 1 January 2021." Discussions: - Only ICAO CONOPS document provides a concise definition for ADT. - ICAO Annex 6 and EU 2015/2338 does not explicitly address ADT, but "location of an aircraft in distress". These documents that use the "location of an aircraft in distress" expression emphasize that the aircraft is to be found within 6 NM. - Both ICAO documents and ED-237 mention transmission of information from which a position of an aircraft can be determined. EU regulation does not explicitly mention ti. However, it is implied on the concept, otherwise, how could the aircraft be found if nothing is transmitted? - Both ICAO documents state that position of the aircraft can be determined at least once a minute. ED-237 and EU regulation do not mention the rate in which the position of the aircraft can be determined. However EU regulation mentions the 6 NM concept, which Attachment K of ICAO Annex 6 explains that it is associated with the aircraft position that is known one minute prior to the accident. Therefore, implicitly, the EU regulation also addresses the 1 minute rate. - ICAO documents imply that it is not necessary to transmit the aircraft position, but a signal from which aircraft position can be derived. - How much resilient/robust (resilience is mentioned in ICAO CONOPS and robustness in EU regulation) to failures this capabality should be? ICAO GADSS, v. 6.0, adds some clarification by indicating that the necessary resilience is as "practically possible" to failures of the aircrafts

39 electrical power, navigation and communication systems as well as to human factors. (Refer to the correspondent term in this glossary) - Autonomous transmission (all sources). Autonomous detection and triggering, as well? What is autonomy? (Refer to the correspondent term in this glossary) - Aircraft in distress (all sources, explicitly or implicitly).what is distress? (Refer to the correspondent term in this glossary) - On the 08/08 meeting, it was determined that it is better to have two separate definitions: ADT and ADT system. ADT explains the associated capability, while ADT system describes the corresponding system Autonomy Sources: - ICAO GADSS CONOPS v. 6.0 (section autonomous distress tracking function) --- "The ADT function uses on board systems to broadcast aircraft position (latitude and longitude), or distinctive distress signals from which the aircraft position and time can be derived. The aircraft position information will be transmitted, without the need for flight crew action, at least once every minute, when an aircraft is in a distress condition. An aircraft is in a distress condition when it is in a state that, if the aircraft behaviour event is left uncorrected, may result in an accident." (section autonomous distress tracking function) "In terms of the autonomy, the ADT function will transmit as long as practically possible during the distress condition. As practically possible refers to a means to achieve resilience to failures of the aircrafts electrical power, navigation and communication systems as well as to human factors. The onboard component of the ADT function will be designed such that, in the event of aircraft electrical power loss, it will continue transmitting for the expected duration of the remaining flight." - EUROCAE ED-237 (section background) "The intent of this ADT System is to use on-board systems that can detect an emergency situation and broadcast position, or distinctive distress signals from which the position can be derived, on protected frequencies and, depending on its application on each aircraft, to be automatically activated or manually activated at any time."

40 - EU 2015/2338 amending EU 965/2012(CAT.GEN.MPA.210 location of an aircraft in distress - aeroplanes) "The following aeroplanes shall be equipped with robust and automatic means to accurately determine, following an accident where the aeroplane is severely damaged, the location of the point of end of flight: (1) all aeroplanes with an MCTOM of more than kg, with an MOPSC of more than 19 and first issued with an individual CofA on or after 1 January 2021; and (2) all aeroplanes with an MCTOM of more than kg and first issued with an individual CofA on or after 1 January 2021." - FAA AC (section 5.6 system behavior) "(...) (S)ystems designed to operate autonomously, in the sense that they require very limited or no human interaction, are referred to as automatic systems. Such systems are switched on or off or run automatically, and are not covered by (c). Examples include Full Authority Digital Engine Controls (FADEC) and yaw dampers. Specific detailed guidance for automatic systems can be found in relevant paragraphs of part 25." Discussions: - There are two meanings to the term "autonomy". In the first meaning, autonomy refers to the amount of time a certain equipment is expected to function. In this meaning, autonomy is closely related to the term "resilience/robustness to failure". - In the second meaning, autonomy refers to independence, system self-control, system design that requires limited or no human interaction. - Both meanings permeate the ADT functionality. - On the 08/08 meeting, it was introduced a definition that would emphasize the independence aspect, as well as the resilience aspect Distress Sources: - ICAO GADSS CONOPS v. 6.0 (section 1.2 definitions) - ICAO Annex 11 (chapter 1 definitions)

41 - ICAO Annex 12 (chapter 1 definitions) "Distress phase: A situation wherein there is reasonable certainty that an aircraft and its occupants are threatened by grave and imminent danger or require immediate assistance." - ICAO GADSS CONOPS v. 6.0 (section high level objectives of the GADSS) "The GADSS is designed to address three specific issues; a) the late notification of SAR services when aircraft are in distress (as defined in ICAO Annex 11), b) missing or inaccurate end of flight aircraft position information i.e. the location of wreckage and --- c) lengthy and costly retrieval of flight data for accident investigation." (section autonomous distress tracking function) --- "To identify a distress condition, the aircraft state will be analysed in real-time by aircraft systems or ground processes and the use of event detection and triggering criteria logic will initiate the notification of the alert to assist locating the aircraft in distress." (section autonomous distress tracking function) --- "The triggering criteria may include analysis of unusual attitudes, unusual altitudes, unusual speeds, potential collision with terrain, total loss of thrust/propulsion on all engines, Mode A squawk codes, etc. The triggers will be defined making sure that the criteria used maximises the probability of detection of an upcoming catastrophic event." (section autonomous distress tracking function) "Note: Further guidance regarding in flight event detection and triggering criteria may be found in the EUROCAE ED 237 Minimum Aviation Performance Specification (MASPS) for Criteria to Detect In Flight Aircraft Distress Events to Trigger Transmission of Flight Information." - ICAO Annex 11 (section 5.2 notification of rescue coordination centres) "5.2.1 Without prejudice to any other circumstances that may render such notification advisable, air traffic services units shall, except as prescribed in 5.5.1, notify rescue coordination centres immediately an aircraft is considered to be in a state of emergency in accordance with the following:

42 (...) c) Distress phase when: 1) following the alert phase, further unsuccessful attempts to establish communication with the aircraft and more widespread unsuccessful inquiries point to the probability that the aircraft is in distress, or when 2) the fuel on board is considered to be exhausted, or to be insufficient to enable the aircraft to reach safety, or when 3) information is received which indicates that the operating efficiency of the aircraft has been impaired to the extent that a forced landing is likely, or when 4) information is received or it is reasonably certain that the aircraft is about to make or has made a forced landing, except when there is reasonable certainty that the aircraft and its occupants are not threatened by grave and imminent danger and do not require immediate assistance." - ICAO Annex 6, (Appendix 9, item 2.2: operation) "An aircraft is in a distress condition when it is in a state that, if the aircraft behaviour event is left uncorrected, can result in an accident." - EUROCAE ED-237 (section definition of terms) --- "In-flight distress event: A situation which, if left uncorrected, is likely to result in an accident." (section scenarios) "The scenarios listed below were developed based on analyses which included reviews of previous events and represent the minimum set which should be detected by the logic. They are identified by conditions which, if left uncorrected, are likely to result in an accident. Manufacturers may include additional scenarios or combine scenarios, provided that they do not impair the overall efficiency and/or reliability of the triggering logic. Each condition is defined by parametric data thresholds which may differ depending on the type of aircraft and its mission (as for example military training phase, aerial work, Search And Rescue civil, passenger transport). Scenario 1: Unusual attitude. The conditions may include, but are not limited to, excessive values of roll, pitch and yaw and their corresponding rates of change

43 Scenario 2: Unusual speed. The conditions may include, but are not limited to, excessive vertical speed, stall condition, low airspeed, overspeed or other speed conditions. Scenario 3: Collision with terrain. The conditions may include, but are not limited to, high rate of closure to terrain or inappropriate altitude for the current position. Scenario 4: Total loss of thrust/propulsion on all engines. The parametric data used to define this condition may be engine performance parameters or other parameters that result from loss of thrust." Discussions: - There is a "distress phase", which is referenced in ICAO Annex 11 and 12, plus the GADSS CONOPS. This is one of the three emergency phases (uncertainty, alert and distress) defined in the Search and Rescue operating procedures. - The distress phase is a period of time, in which the Rescue Coordination Centre (RCC) and Air Traffic Control (ATC) have to follow a number of procedures (ICAO Annex 11 and 12). - Criteria are provided in item of ICAO Annex 11 for the RCC and the ATC to determine the start of the distress phase. This initial time is mainly defined from the point of view of the RCC and the ATC. - On the other hand, the ICAO GADSS CONOPS, the Annex 6 and EUROCAE ED-237 mention a distress condition, which roughly corresponds to the initial time of the distress phase. However, this distress condition is defined mainly from the point of view of the Aircraft Distress Tracking functionality, which includes both airborne system and ground processes. - Therefore, although all these documents refer to term "distress", the tools that are used to determine the distress condition are different. Real-time analysis of the aircraft state may be implemented by an airborne system, while the RCC may use the lapse of time in which there is no communication with the aircraft to determine the distress condition. - For the work that is being performed in this committee, in which the focus is in the Autonomous Distress Tracking functionality, the term "distress" should be defined from this capability point of view and not the RCC's and ATC's perspective only.

44 - Distress logic and triggering criteria are not part of the Distress condition definition. They are functional requirements to accomplish the ADT functionality Nuisance alert Sources: - ICAO GADSS CONOPS v. 6.0 (section 1.2 definitions) --- "False alert. An alert received from any source, including communications equipment intended for alerting, when no distress situation actually exists, and a notification of the alert should not have resulted." (section autonomous distress tracking function) "The ADT function will be approved by the State of the Operator, considering high level performance criteria such as: (...) g) Minimisation of False Alerts." - ICAO Appendix 6 (appendix 9, section operation) "An aircraft is in a distress condition when it is in a state that, if the aircraft behaviour event is left uncorrected, can result in an accident. Autonomous transmission of position information shall be active when an aircraft is in a distress condition. This will provide a high probability of locating an accident site to within a 6 NM radius. The operator shall be alerted when an aircraft is in a distress condition with an acceptable low rate of false alerts. In case of a triggered transmission system, initial transmission of position information shall commence immediately or no later than five seconds after the detection of the activation event." - EUROCAE ED-237 (section definition of terms) --- "Nuisance trigger: any trigger that is erroneously generated by the on-board triggering system when there is no potential for an accident." (section introduction)

45 "In order to minimize nuisance triggers and optimize triggering logic, the logic may be inhibited or may be limited in its ability to detect distress events during the following flight phases: take-off, initial climb, final approach, landing and go-around." --- (section triggering criteria) --- "The set of triggering criteria should maximize the detection of scenarios, while limiting nuisance triggering. Excessive nuisance triggers have the potential to reduce confidence in the system as well as saturate SAR resources." (section persistence time) --- "The persistence time is the duration for which the condition(s) is true before a triggering signal is generated. The persistence time for each of the criteria should be balanced to trigger a transmission, as soon as practicable, that captures the greatest number of accidents possible while limiting the number of nuisance triggers." (section nuisance trigger) As defined above, a nuisance trigger is any trigger that is erroneously generated by the triggering logic when there is no potential for an accident. Keeping the rate of nuisance trigger activations low is paramount to maintaining user confidence in the overall system and to avoid saturating SAR resources. Based on input from SAR service providers regarding additional nuisance alerts due to the introduction of the in-flight activation logic, the overall in-flight event detection and triggering system should meet a nuisance rate objective of no more than 2 nuisance triggers per Flight Hours. Many factors could lead to a nuisance trigger activation, such as, but not limited to: - Triggering logic, - Erroneous input (e.g. hardware failure, corrupt data), - Development errors or triggering system hardware failure, - Maintenance action, - Ground and/or flight test. Addressing the reliability of hardware and the design implementation are beyond the scope of this document. The portion of the overall nuisance rate attributable to the triggering logic and causing a false alert to SAR providers, shall be no more than 1 nuisance trigger per Flight Hours. To meet this objective, the triggering logic should implement accurate criteria specific to the target aircraft and be verified for correct operation against a database of exemplar flight data (see Chapter 4) to reduce the nuisance trigger rate. The rate may be reduced further if the triggering logic takes into account: - The use of appropriate limit values and/or persistence times for each of the criteria to ensure the non-transient nature of an event (see 3.2.2), - The effect of sensor failures on the triggering logic,

46 - The effects of maintenance or functional check flight activities on the triggering logic." - FAA AC (appendix 5 definitions) "Nuisance alert - an alert generated by a system that is functioning as designed but which is inappropriate or unnecessary for the particular condition." Discussions: - There is a concern about nuisance triggers and a possible high rate of false alerts. - ED-237, particularly, lay out objectives to be met and suggest design techniques to ensure appropriate compliance with the objectives. - ED-237 defines nuisance trigger emphasizing that the nuisance is erroneously generated. This may create some confusion. As AC points out, the nuisance is generated because the system is functioning as designed (maybe the design needs to be reviewed, but this is another matter) and not because there is an error in it (suppose that a false alert is generated by the failure of an electronic component this cannot be interpreted as a nuisance failure). The AC definition seems to be more accurate than ED-237's. Besides, this definition should be independent from the ADT concept Resilience / Robustness to Failure Sources: - ICAO GADSS CONOPS v. 6.0 (section 1.2 definitions) --- "Autonomous Distress Tracking (ADT). The capability using transmission of information from which a position of an aircraft in distress can be determined at least once every minute and which is resilient to failures of the aircraft s electrical power, navigation and communication systems. Note: this capability is described under Location of an Aeroplane in Distress in ICAO Annex 6 Part 1." (section autonomous distress tracking function) --- "In terms of the autonomy, the ADT function will transmit as long as practically possible during the distress condition. As practically possible refers to a means to achieve resilience to failures of the aircrafts electrical power, navigation and communication systems as well as to human factors. The onboard component of the ADT function will be designed such that, in the event of aircraft electrical power loss, it will continue transmitting for the expected duration of the remaining flight." (appendix C concept scenario)

47 Figure 1 GADSS CONOPS Version 6.0 Concept Scenarios (1 of 2)

48 Figure 2 GADSS CONOPS Version 6.0 Concept Scenarios (2 of 2) - ICAO Appendix 6 (appendix 9, section 2 operation) "The system used for the autonomous transmission of position information shall be capable of transmitting that information in the event of aircraft electrical power loss, at least for the expected duration of the entire flight." - EU 2015/2338 (CAT.GEN.MPA.210 location of an aircraft in distress - aeroplanes) "The following aeroplanes shall be equipped with robust and automatic means to accurately determine, following an accident where the aeroplane is severely damaged, the location of the point of end of flight: (1) all aeroplanes with an MCTOM of more than kg, with an MOPSC of more than 19 and first issued with an individual CofA on or after 1 January 2021; and (2) all aeroplanes with an MCTOM of more than kg and first issued with an individual CofA on or after 1 January 2021."

49 Discussions: - The ICAO GADSS CONOPS indicates that the ADT functionality is to be resilient to failures of the aircraft's electrical power, navigation, communication systems and human factors errors, as well. - However, there is no definition for resilience / robustness to failure in the GADSS family documents. Therefore, a new definition should be crafted. - Resilience is characteristic that assures a certain intended performance, despite system's failures, faults and malfunctions, and user's errors and violations. It is a measure of the system's susceptibility to failure (update from the 08/08 meeting). - This characteristic may be achieved through certain mechanisms (e.g.: operational procedure) or techniques (e.g.: system design). - This resilience is referred as being "as practical as possible". This idea is further expanded in the Appendix C table of the ICAO GADSS CONOPS document, where the level of resilience for certain scenarios is presented. As it can be observed, resilience is translated into system independence (which is a system design technique) to ensure that the location of the end of flight is always known. 2.3 An ADT Architectural Framework Figure 3 ADT Functional Block Definition for Study Architecture Framework

50 Figure 4 Study Architecture Framework Applied to ELT-DT Based System Figure 5 Study Architecture Framework Applied to Space Based ADS-B and SATCOM System

51 Figure 6 Study Architecture Framework Applied to SATCOM Based System 2.4 Integrated ADT Requirements for Architecture Study Microsoft Excel Worksheet Figure 7 SAI GAT Architecture Study Requirements Tables_REV_NEW.xls (embedded file)

52 3.0 Autonomous Distress Tracking (ADT) Architecture Study 3.1 Architecture Study Overview 3.2 Space-Based Automatic Dependent Surveillance Broadcast (ADS-B) Architecture Study Description of Architecture Automatic Dependent Surveillance Broadcast (ADS-B) Out (aka Extended Squitter) is a surveillance function which has been installed on all commercial air transport airplanes since the 2004 timeframe. ADS-B transmits aircraft data, including aircraft identification, horizontal position, altitude, velocity, and other parameters. Since the release of the RTCA DO-260 ADS-B Minimum Operational Performance Standards (MOPS) in 2000, there have been two revisions to the MOPS: DO-260A (in 2003) and DO-260B (in 2009). Some Air Navigation Service Providers (ANSPs) (e.g. NavCanada, AirServices Australia and certain ANSPs in Southeast Asia) have implemented ground ATC systems to track aircraft that meet any version of DO-260. The U.S. Federal Aviation Administration (FAA) has mandated that all aircraft (forward-fit and retrofit) be equipped with DO-260B complaint ADS-B Out functionality by Jan. 1, The European Union has mandated that air transport aircraft (forward-fit and retrofit) be equipped with DO-260B complaint ADS-B Out functionality by June 7, Other regions of the world have already mandated, or are in the process of mandating, ADS-B Out. Therefore, it is expected that nearly all air transport aircraft worldwide will have ADS-B Out functionality installed by From an air transport aircraft installation perspective, the ADS-B Out function resides in the same Line Replaceable Unit (LRU) (e.g. a standalone Air Traffic Control (ATC) transponder, an Integrated Surveillance System Processor Unit (ISSPU), a T2CAS unit, or a T3CAS unit), that contains the ATC transponder function. Each airplane has (2) ADS-B Out systems installed with one system being selected and active at any given time while the other ADS-B Out system is in standby mode (aka hot-spare). Each ADS-B Out system receives specific aircraft data parameters from other aircraft systems and alternately transmits the data in ADS-B Out registers in 1090 MHz Extended Squitter (ES) messages via the top and bottom ATC antennas (i.e. the ADS-B messages are transmitted out the top antenna, and then the bottom antenna). Air Traffic Services (aka Air Navigation Service Providers (ANSPs)) which have ground-based ADS-B receiving stations (e.g. the FAA s network of ADS-B stations) receive the transmitted ADS-B data and provide the data to ATS automation for use in aircraft separation services. In addition, Aireon has developed a Space-Based ADS-B receive capability which will provide worldwide ADS-B aircraft tracking services that can be interfaced to any Service Provider (e.g. ANSP/ATS Unit, FlightAware, or SITAinair). Figure 8 provides a general overview of Aireon s Space-Based ADS- B Network, which serves as a reference architecture for any given Space-Based ADS-B Network.

53 Figure 8 Space-Based ADS-B Network Figure 9 provides an end-to-end architecture overview of the Space-Based ADS-B Architecture for Distress Tracking. Figure 9 ADS-B Architecture for Distress Tracking (Example)

54 In this architecture, the ATC Transponder (shown as ADS-B OUT XMTR (XPDR) in Figure 9) is the Distress Tracking transmitter. The XPDR receives position data from an onboard position source(s). The position source will most likely be the Global Navigation Satellite System (GNSS) receiver (which is typically housed within a Multi-Mode Receiver (MMR) on many air transport aircraft). The GNSS provides worldwide, high accuracy, and high integrity horizontal position (latitude and longitude) data which is already provided to the XPDR to support the ADS-B Out function. The position data is transmitted in an ADS-B message (Airborne Position BDS register 05H) every 500 msec, alternating transmissions between the top ATC antenna and the bottom ATC antenna. Therefore, the ADS- B position data is transmitted from the top antenna once per second. In addition, the XPDR receives uncorrected barometric altitude data from an onboard air data source(s). The altitude data is transmitted in the same Airborne Position message (BDS register 05H) as the position data, and therefore, the altitude data is also transmitted from the top antenna once per second. In the example architecture shown in Figure 9, the ADT Computer function contains the Distress Detection Logic and the Triggering Criteria Logic for determining whether an onboard distress event is occurring and whether a distress event has been cancelled. Alternatively, the ADT Computer function could be incorporated into the XPDR, but this is left to the implementer to decide whether this is feasible. For the purposes of this architecture study, the ADT Computer will be shown as a separate LRU. When a distress event is active, a signal is sent to the XPDR to indicate that a distress event is currently active. The XPDR would register the distress event by encoding a General Emergency in the Emergency State field in the existing ADS-B Emergency/Priority Status message (BDS register 61H Subtype 1). This message is transmitted every 800 msec, alternating between the top ATC antenna and the bottom ATC antenna. Therefore, the distress event in the Emergency State field is transmitted from the top antenna every 1.6 seconds. Figure 10 shows the Emergency State field coding (bits 11-9) within the Emergency/Priority Status message (BDS register 61H Subtype 1). Coding (Bits 11-9) Meaning (Binary) (Decimal) No Emergency General Emergency Lifeguard/Medical Emergency Minimum Fuel No Communications Unlawful Interference

55 Coding (Bits 11-9) Meaning (Binary) (Decimal) Downed Aircraft Reserved Figure 10. Emergency State Field of the Emergency/Priority Status Message (BDS 61H Subtype 1) Discussion item: The Figure 10 Emergency/Priority Status table is limited by the use of Subtype code 1. Per DO-260B, there are 5 unassigned Subtypes available (3-7). Would it be desirable to utilize a new Subtype code to identify the transmission to be of ADT origin? If so, one (or more) new message matrices could be defined to precisely identify the reason for the transmission. Coding (Bits 11-9) Meaning (Binary) (Decimal) No ADT Activation Automatic ADT Activation Manual ADT Activation See below* See below* See below* ADT Condition Cancelled/Cleared Reserved Figure 11. Examples of potential new Sub type codes to support ADT functionality *Messages such as Unusual Attitude, Unusual Altitude, Unusual Airspeed, Impact Imminent, Loss of Primary Electrical Power, EGPWC Warning, etc could be used here. The possibilities are limited by the functionality of the ADT LRU (however that may be employed). If there are multiple causes for the activation, the ADT LRU could cycle the coding bits from, for instance Automatic ADT Activation / Unusual Attitude / Automatic ADT Activation / Unusual Attitude and so on. When the condition is corrected, bits 110 ADT

56 Condition Cancelled/Cleared is transmitted. Note also that the Surveillance Status bit in Register 5 must change to terminate the emergency state in Register 61. Defining the transmission to be of ADT origin and providing the actuation type and cause could provide investigators with immediate knowledge for the reason the aircraft emergency. Could this type of information be useful to the AOC, RCC, or SAR? This would also be beneficial in the event the FDR data could not be recovered. This code is received by all ADS-B receivers within range (from terrestrial and Space-Based systems) and can signify a distress condition to ATS, AOCs, and RCCs that are subscribed to the ADS-B data from these systems. In fact, the FAA s ATC automation systems already process the data within the Emergency State field (bits 9 through 11) in Emergency/Priority Status messages and will provide an ATC emergency alert if the field is set to 1 (001). In addition, the Downed Aircraft code could also be set for certain distress conditions. Several companies such as FlightAware and SITAonair will be connected to ADS-B sensor networks of their own, as well as to Space-Based ADS-B, and distribute the data with applications that are configurable to alert AOCs and/or RCCs to several common distress conditions (e.g. emergency Mode 3/A codes, sudden changes in altitude or speed, etc.). Additionally, Aireon will provide a service called Aircraft Locating and Emergency Response Tracking (ALERT) for contingency conditions, however this service by itself is not designed to support ADT. A Manual Distress Trigger capability in the flight deck could also allow the flight crew to manually activate a distress event. The XPDR is already connected to a flight deck control head (e.g. an ATC/TCAS control panel or similar LRU) where the Mode 3/A code (aka squawk code ) is selected by the flight crew. When the Mode 3/A code is set to the General Emergency code (7700), then the XPDR transmits the Emergency State field in the Emergency/Priority Status message (BDS register 61H, subtype 1) with an encoding of 1 (001) which represents a General Emergency. In addition, the XPDR could also provide an input to an optional Flight Deck DISTRESS indicator (e.g. annunciator light or crew alerting message) to alert the flight crew when a distress signal (Emergency State Field = 1 (001)) is being transmitted by the XPDR. However, this type of indication is dependent upon the aircraft implementation and should take into account human factors considerations and the overall flight deck philosophy for that aircraft platform. Note that with the ADS-B architecture, there is no uplink function that would enable the ground to initiate an airborne distress signal.

57 3.2.2 Space Based ADS-B Architecture Mapped to the Architecture Frame Work Figure 12 is the ADT Functional Block Diagram. It explains each of the ADT system s functions and their interconnections. Functional Block 1 Aircraft State To capture from Aircraft Systems the parameters (e.g. position, systems status) that define the aircraft condition (in distress or not) and the position/altitude of the aircraft. State Parameters Functional Block 2 Distress Detection Logic To identify the Distress Event condition using the state parameters Distress Event Notification Functional Block 3 Triggering Criteria Logic To generate the triggering command (notification of distress (ON/OFF). Triggering Command Functional Block 4 Distress Tracking Transmission To transmit the distress tracking signal (distress notification, aircraft identification, and aircraft position). Aircraft Position Distress Tracking Signal Functional Block 5 Distress Report To provide reports to ground stakeholders (AOC, ATS, RCC) Distress Reports Functional Block 6 Flight Crew Feedback (Optional) To provide information to the flight crew AOC ATS RCC Figure 12. ADT Functional Block Diagram

58 Figure 13 is the ADS-B Implementation Architecture that maps to each of the ADT system functional blocks (Functional Blocks 1 through 6) of the ADT Functional Block Diagram (Figure 12). AIRCRAFT Triggering Logic (3) ADT Computer ADS-B Transmitter (ATC Transponder) Antennas SAT Detection Logic (2) (4) Parameters Aircraft Systems GNSS (1) Air Data Position Altitude Control Panel (3) Emerg Code 7700 Distress Signal (ON/OFF) Crew Alerting (6) ATS AOC RCC Distress Reports Service Delivery Point [e.g. ANSP Delivery Point, FlightAware, SITAinair] ADS-B Data ADS-B Data Terrestrial ADS-B Receivers 1090 MHz Ground Segment including Processing & Distribution [e.g. Aireon] Space-Based ADS-B Data ADT Functional Block Allocations (1) Aircraft State Function (2) Distress Detection Logic (3) Triggering Criteria Logic (4) Distress Triggering Transmission (5) Distress Reports (6) Flight Crew Feedback (Optional) Figure 13. ADS-B Implementation Architecture The ADT Triggering Logic (3) will generate a trigger event based on either: An automatic trigger based on the Detection Logic (2) being satisfied, or A manual trigger as set by the flight crew setting a XPDR Mode A code of 7700

59 The ATC Transponder will transit a distress signal via both top and bottom ATC antennas, along with the aircraft s identification, horizontal position, and altitude. This data, which is contained within ADS-B Out messages, can be received any ADS-B receiver (including terrestrial ADS-B receivers as well as Space-Based ADS-B Receivers) Key Architecture Assumptions and Dependencies The ADS-B architecture has the following specific dependencies: 1. The aircraft ATC Transponders must be capable of transmitting ADS-B messages that meet the minimum operational performance standards (MOPS) of RTCA DO-260, DO-260A, or DO-260B. 2. In order to provide full-time, global ADS-B coverage, the Iridium Next satellites that carry the Aireon Hosted Payload and Main Mission L-Band antenna must be deployed. The current schedule for completing deployment of these satellites is July The Aireon Ground-Based Network must be completed to the extent that high-integrity ADS-B data can be distributed to users of the data (e.g. FlightAware). The current schedule for completing the Aireon network that supports this level of functionality is July FlightAware must be able to consume the Aireon ADS-B data and make it available to users of the data. FlightAware is currently receiving Aireon ADS-B data and performing beta testing. FlightAware is scheduled to provide Normal Tracking services by July 2018 and will provide ADT services by December SITAinair currently provides Normal tracking using SATCOM and ACARS position reports. SITAinair plans on receiving Space-Based ADS-B data from FlightAware for use in Normal tracking services by July 2018 and for ADT services by December Key Airplane Infrastructure Support and Required Changes Key Airplane Infrastructure Support The aircraft must be capable of transmitting ADS-B messages that meet the requirements of RTCA DO-260, DO-260A, or DO-260B MOPS. In addition, the ATC transponder must have the ability to receive specific data parameters from qualified systems. Horizontal position (latitude and longitude), along with position accuracy and integrity parameters, must be supplied by a qualified position source (e.g. GNSS). In addition, data containing aircraft identification (Flight ID) and altitude data (uncorrected barometric altitude) must be received and transmitted by the ATC transponder. All air transport aircraft delivered after approximately 2004 meet the above requirements. Required Changes The aircraft must be updated as follows:

60 Add an ADT Computer that provides the Detection and Triggering logic as outlined in Figures 4 and 5. Note: Alternatively, the Detection and Triggering logic could be added to the ATC Transponder LRU. Add wiring to connect the ADT Computer to the required aircraft systems to receive necessary data parameters Add wiring to connect the ADT Computer to the ATC Transponder so that a Trigger ON/OFF can be sent from the ADT Computer to the ATC Transponder Key Network Infrastructure Support and Required Changes Discussion of key network support and changes required to support architecture. Aireon Network - Mike FlightAware - Mark SITAinair - Paul Key Ground Segment Support and Required Changes Discussion of key ground segment support and changes required to support architecture. Aireon Network - Mike FlightAware - Mark SITAinair - Paul Compliance with Requirements Evaluate the architectures support for the minimum and optional requirements described in Appendix B (minimum requirement set spreadsheet) and for the GADSS CONOPS (Ver 6.0) State of the Operator Approval Criteria Recommendations (section ) using the matrices in Appendix C. Identify and provide textual/graphic descriptions and discussions of any major shortcomings and if and how they are expected to be addressed. Provide textual/graphic descriptions and discussions of any additional capabilities or opportunities for improved distress capabilities and services not addressed in the requirements. Identify and discuss requirements that potentially impose a significant cost or impact for the architecture and discuss where changes in requirements or alternative could potentially provide similar capabilities at a significantly reduced cost or impact.

61 Identify and discuss requirements where there is potential opportunity for the architecture to significantly exceed or improve on the required levels with minor impact and cost Support for Related Services and Capabilities Provide textual/graphic descriptions and discussions of any additional capabilities or opportunities for improved distress capabilities and services not addressed in the requirements. In particular address support for 1. Normal tracking 2. Abnormal and potential distress tracking 3. Implications for timely recovery of flight data 4. Post Flight Localization and Recovery 3.3 ELT-DT Architecture Study Description of ELT-DT Based Architecture Introduction to Emergency Locator Transmitters An Emergency Locator Transmitter (ELT) is defined as transmitter equipment which broadcasts distinctive signals on designated frequencies which are used to locate an aircraft and survivors after a crash. An ELT may take any of the following forms: Automatic Fixed (ELT (AF)) - This type of ELT is intended to be permanently attached to the aircraft before and after a crash, to automatically activate upon a crash, and is designed to aid SAR teams in locating a crash site. Automatic Portable (ELT (AP)) - This type of ELT is intended to be rigidly attached to the aircraft before a crash, automatically activates upon a crash, but is readily removable from the aircraft after a crash. If the ELT does not employ an integral antenna, the aircraft-mounted (external) antenna may be disconnected and an auxiliary antenna (stored on the ELT case) connected in its place. The ELT can be tethered to a survivor or a life raft. This type of ELT is intended to aid SAR teams in locating the crash site and/or survivor(s). Automatic Deployable (ELT (AD)) - This type of ELT is intended to be rigidly attached to the aircraft before a crash and automatically deploy when a crash occurs. This type of ELT also operates while floating in water and is intended to aid SAR teams in locating the crash site. The ELT(AD) may be either a stand-alone beacon or may be a part of an Automatic Deployable Flight Recorder. Survival (ELT (S)) - This type of ELT is intended to be removed from the aircraft after a crash and activated by survivors or automatically with the deployment of other survival equipment. There are two categories of

62 ELT(S) Category A which is buoyant and designed to operate when floating in water and Category B which is not designed to operate when floating in water. This type of ELT is intended to aid SAR teams in locating survivor(s). Distress Tracking (ELT (DT)) - This type of ELT is designed to be activated prior to a crash upon detection of a distress condition by logic such as that defined by EUROCAE MASPS ED-237. This type of ELT is intended to provide information prior to the crash to aid in locating the crash site and may not be required to survive the impact. The usage of ELTs are outlined in the ICAO Standard and Practices: In ICAO Annex 6, Part IIA, a Recommendation is made that all airplanes operated on extended flights over water and when operated on flights over designated land areas shall be equipped with an automatic ELT. There is an identical Recommendation in respect of certain Classes of helicopter when conducting overwater operations. ICAO Annex 10, Volume V requires that ELTs carried in compliance with the Standards of Annex 6, Parts I, II and III shall operate on both 406 MHz and MHz. Although the SAR satellite systems are no longer able to use MHz signals, this frequency is considered necessary to allow homing. All ELTs capable of transmitting on 406 MHz must be coded in accordance with ICAO Annex 10 and registered with the national agency responsible for initiating Search and Rescue or another nominated agency. National regulations incorporate the certification of ELT s through the Technical Standard Order (TSO) process. TSO-c126b and ETSO-c126b define the requirements of ELTs for both USA and EU certifications respectively. The TSO and ETSO reference the standards RTCA DO-204a and EUROCAE ED-62a respectively; MINIMUM OPERATIONAL PERFORMANCE SPECIFICATION FOR AIRCRAFT EMERGENCY LOCATOR TRANSMITTERS 406 MHz AND MHz (OPTIONAL 243 MHz). These MOPS are current being revised and updated by RTCA SC-229 and EUROCAE WG-98 with expected publication by mid-year All ELTs operate on the International Cospas-Sarsat System which is described in the next section. An ELT must be independently certified and approved for use on the Cospas-Sarsat system. This Type Certification requires testing at an approved test lab and then a subsequent review conducted by the technical officers of the Cospas-Sarsat organization. The Type Approval is required by the TSO and ETSO. The applicable standards are published by Cospas Sarsat and are updated annually:

63 C/S T SPECIFICATION FOR COSPAS-SARSAT 406 MHz DISTRESS BEACONS C/S T COSPAS-SARSAT406 MHz DISTRESS BEACONS TYPE APPROVAL STANDARD C/S T SPECIFICATION FOR SECOND-GENERATION COSPAS- SARSAT406-MHz DISTRESS BEACONS C/S T COSPAS-SARSAT SECOND GENERATION 406-MHz DISTRESS BEACON TYPE APPROVAL STANDARD COSPAS-SARSAT SYSTEM OVERVIEW The International Cospas-Sarsat Program is a treaty-based, nonprofit, intergovernmental humanitarian cooperative of more than 40 nations and agencies dedicated to detecting and locating 406 MHz radio beacons activated from aircraft, vessels and by persons (e.g., hikers, skiers, remote workers) in distress, and forwarding this alert information to search-and-rescue (SAR) authorities that can take action for rescues. The system utilizes a network of satellites that provide coverage anywhere on Earth. Distress alerts are detected, located and forwarded to over 200 countries and territories at no cost to the receiving government agencies. Cospas-Sarsat was conceived and initiated by the founding Party States of Canada, France, the United States, and the former Soviet Union in MHz Distress Beacons: The family of 406 MHz Distress Beacons capable of being detected by the Cospas-Sarsat System include: Emergency Locator Transmitters (ELTs) for aviation use, Emergency Position Indicating Radio Beacons (EPIRBs) for maritime use Personal Locator Beacons (PLBs). Some beacon models also can receive return link messages sent to them over the navigation channels of the Galileo satellite system. The first generation of beacons (FGB) currently in use are detected through the Doppler shift of the narrowband beacon frequency (406MHz) by the orbiting satellites. The second generation of beacons (SGB) being developed will be detected by the time delay of arrival of signals from a number of satellites and will use spread spectrum modulation. Space Segment: The Cospas-Sarsat system Space Segment consists of : The distress-alert instruments are attached as secondary payloads to satellites that are being launched primarily for meteorological or navigation purposes. SAR signal repeaters (SARR) and SAR signal processors (SARP) aboard satellites;

64 Satellites in polar low-altitude Earth orbit called LEOSARs; Satellites in geostationary Earth orbit called GEOSARs; and Satellites in medium-altitude Earth orbit called MEOSARs. Ground Segment : The system consists of a Ground Segment that includes: Distress radio-beacons to be activated in a life-threatening emergency; Several satellite downlink receiving and signal processing ground stations called LUTs (local user terminals); The independent calculation of the location is made from measurements of the Doppler-effect-induced frequency differences and/or distance-dependent time-of-arrival seen in the distress signal at the LUT receiver. In addition, the inclusion of GNSS or Navigation Interface position data in the beacon message can be used to directly locate the distress signal. Mission control centers (MCC) that exchange, route and distribute the distress alert data (particularly beacon location data) provided by the LUTs. Rescue Coordination Centers (RCC) which receive the alert data and prosecute the rescue. Data Distribution System: Cospas-Sarsat provides a robust Data Distribution System for distress alerts and consists of: A network of more than 30 mission control centres, operated by governments, and distributed world-wide; Built in redundancy of data distribution regions to collect, store, sort data. Communication links to global SAR authorities, which are tested on a monthly basis. Further information on Cospas-Sarsat, the system and beacons can be found at The ELT in Autonomous Distress Tracking Emergency beacons, and in particular ELTs, are specified and developed to operate when stationary or moving very slowly (walking, drifting). The use of an ELT operation in flight requires careful consideration of the transmission and message characteristics necessary to track an aircraft in flight. The Distress Tracking ELT, ELT(DT), is a specific type of ELT designed to be activated prior to a crash and to function in compliance with the ICAO GADSS requirements for the Location of an aircraft in distress, aimed at establishing, to a reasonable extent, the location of an accident site within a 6 NM radius. The ELT (DT) shall be armed/disarmed upon reception of the corresponding signal from the automatic triggering system. Once armed, it shall have the means to automatically activate the transmitter upon command from the automatic triggering system and radiate a signal through an antenna. ELT(DT) shall stop transmitting an alert signal and shall start transmit a cancellation signal only when the cancellation command is originating from the same mechanism that activated it

65 The key characteristics of the ELT(DT) are shown in Figure 14 and are centered around faster transmissions, GNSS position in the message, and crash survivability. The ELT(DT) may be activated automatically upon detection of a distress condition while in flight, activated manually, or activated from the ground (for example via the Galileo Return Link Service. The first transmission occurs within the first 5 seconds after activation. Subsequent transmissions occur every 5 seconds for the first 30 seconds of operation and then every 30 seconds thereafter. The ELT(DT) must operate at least 20 hours at the minimum specified operating temperature. The ELT (DT) requires the inclusion of a GNSS capability. The ELT(DT) is not required to have a homing signal (121.5 MHz ) for onsite crash location. A regular ELT(DT) not expected to survive a crash, however,.. For an ELT(DT) specifically designed to survive a crash o o o o The Beacon Hex ID is always that of an ELT(DT), that is it doesn t change after a crash The device needs some sort of crash sensor as it is meant to change the Triggering Event Bits in the Rotating Field to indicate G-switch activation The device is required to restart the transmission sequence after a crash (i.e. repeat the 6 bursts in the first 30 seconds) The total required minimum duration of 406 MHz continuous operation is 24 hours (that is pre-crash added to post crash, so if the ELT(DT) was on for 5 hours before the crash it only has to do 19 hours post-crash) A combined ELT(DT) and ELT(AF) will meet the requirements of both devices independently.

66 Figure 14. ELT(DT) Performance Summary ELT(DT) End to End Architecture Anatomy of a Rescue The structure of the Cospas-Sarsat System have been presented and the unique performance characteristics of an ELT(DT) have been outlined. The same C/S Space Segment, Ground Segment, and SAR Routing are utilized with an ELT(DT) as with any other type of beacon. The inclusion of the GADSS Conops 6.0 Swim Lane for an ELT(DT) completes the scenario with data management, agency alerting, and coordination of the rescue. For illustration, Figure 15 shows a pictorial of a rescue based on the MEOSAR satellite and ground segment. Figure 16 shows the Swim Lane for an ELT(DT). An Alert is triggered and the ELT(DT) transmits the emergency message to the satellites on 406MHz. The message is then downlinked via an L-band transmission to the local user terminals, or in this case the MEOLUT. The ELT(DT) message is demodulated and decoded and then forwarded automatically to the appropriate MCC. The MCC routes the alert to the ATSU. The MCC then routes the alert to the RCC. The RCC validates the alert and prepares to deploy assets. The flow of the swim lane shows the subsequent flow of communication and actions between the RCC, the ATSU, and the Airline Operator. The process proceeds until the rescue is prosecuted or cancelled.

67 Figure 15. Cospas-Sarsat Rescue System

68 Figure 16. GADSS Conops 6.0 ELT(DT) Swim Lane

69 3.3.2 ELT-DT based Architecture Mapped to the Architecture Frame Work Key components and capabilities of the ELT(DT) architecture are mapped to the architecture framework described in Figure 17). Below is a discussion, in terms of architecture framework components, of the architectures functionality that supports the component. Figure 17. ELT-DT Mapped to ADT Functional Blocks Functional Block 1 Aircraft State : To capture from Aircraft Systems the parameters (e.g. position, systems status) that define the aircraft condition (in distress or not) and the position/altitude of the aircraft. Functional Block 2 Distress Detection Logic : To identify the Distress Event condition using the state parameters. It is currently envisioned that the Distress Detection Logic (DDL) would be functionally separate from the ELT(DT) unit. In this configuration, the DDL would be a common element across all architectures. As part of the Automatic Distress Tracking (ADT) computer, the DDL monitors state parameter input from Function Block 1 and filters the data to assure integrity, observes trends in aircraft state, applies control limits on inputs, applies abnormal/distress algorithms, and identifies the potential for an alert condition. Functional Block 3 Triggering Criteria Logic

70 To generate the triggering command (notification of distress (ON/OFF). The Triggering Criteria Logic takes the summary data and potential alert state from the Distress Detection Logic and applies the final algorithm to determine whether the alert state is an abnormal condition or truly a distress condition. If a distress condition, the TCL initiates the distress trigger to the Distress Tracking Transmission, ie the ELT(DT). Functional Block 4 Distress Tracking Transmission To transmit the distress tracking signal (distress notification, aircraft identification, and aircraft position). This functional block is the ELT(DT) as defined in the ED-62B MOPS and the Cospas Sarat documents. Note the inclusion of the position source (GNSS) directly being a part of the ELT(DT) system. In addition, aircraft state parameters can be interfaced directly to the ELT(DT). An ELT (DT), as per the MOPS, shall incorporate an interface to aircraft systems for the following functions (either as separate electrical discrete or coded on a digital bus). a) Receive a triggering command from the automatic triggering system. b) Provide an indication that an automatic trigger was received. c) Receive a cancellation command from the automatic triggering system. Loss of the automatic triggering command indication shall not be interpreted as a cancellation command. d) Provide an indication that an automatic trigger cancellation command was received. e) Continuously monitor the triggering command communications connection between the automatic triggering system and ELT. If that connection is lost while the ELT is armed the ELT shall be activated. f) Receive arm/disarm commands for the automatic triggering system so that normal post-flight shutdown of the automatic triggering system will not cause the ELT to activate and that pre-flight activation of the ELT cannot occur. g) Remote control and monitoring functions as described in the MOPS. h) Provide an indication that a manually activated trigger was cancelled. In addition to the required functions above, an ELT (DT) may include interfaces for one or more of the following optional functions. a) Receive GNSS information from aircraft systems. b) Receive parametric data from the aircraft. c) Receive information about criteria that triggered automatic activation. d) Indication of availability of and/or connection to external power. e) Communications with aircraft maintenance systems to initiate self-tests and provide results to the cockpit. Functional Block 5 Distress Report To provide reports to ground stakeholders (AOC, ATS, RCC). As previously described, the Cospas-Sarsat Space and Ground segment are in place and working in Search and Rescue operations today. Notification

71 occurs automatically from the MCC to the RCC, and subsequently to the ATS. ATS notifies the operator. Functional Block 6 Flight Crew Feedback (Optional) To provide information to the flight crew. The ELT(DT) has a cockpit indicator which is defined in the MOPS ED-62B. A Remote Control and Monitoring System of an Automatic ELT shall have the following functions: MANUAL ON: ELT unit manually activated. ARMED: ELT unit enabled such that activation will occur in response to an activation input (for example, crash sensor, water switch, triggering logic or a remote manual activation) RESET: ELT unit deactivated and return to ARMED. The control must have a provision to prevent inadvertent reset. In the case of ELT(DT), this function shall only reset the manual activations and automatic activations due to the crash sensor, when installed, but not the activations resulting from an automatic distress tracking logic, SELF-TEST: ELT unit Self-Test function provided (refer to 2.8) and optionally including GNSS self-test functionality. CANCELLATION: ELT unit transmits a cancellation sequence and then returns to the ARMED mode. (T.018 ELT(AD), ELT(AP) and ELT(S) ELTs only) (Note that T.001 ELT(DT)s and T.018 ELT(AF)s and ELT(DT)s are not required to have a separate Cancellation Function but are required to transmit a cancellation sequence when RESET) - The control must have a provision to prevent inadvertent cancellation, shall not be combined with the MANUAL ON function and shall require two simple and independent actions to enable it. REMOTE INDICATION and MONITORING - Inform the crew in the cockpit if the ELT is activated - Inform the crew in the cockpit the outcome of a self-test - Inform the crew in the cockpit when the ELT AD is deployed - The monitoring system can be independent of the Remote Control - The indicators and remote control should be continuously powered during aircraft operation. For this purpose, the indicators and remote control may use either a dedicated power source or an alternate power source (e.g., the aircraft power source). Fault Tolerance: No combination of short or open circuits between the remote control, indicators, associated wiring and the airframe shall inhibit the ELT unit from being automatically activated or deactivated once the ELT unit has been activated. Key assumptions and dependencies for the architecture. ELT(DT) Ground Segment processing of new message structure is in place.

72 Key airplane infrastructure support and changes required to support architecture. The ELT(DT) by Cospas-Sarsat specification, must include an independent GNSS position source. Cancellation signal from the cockpit is required, hence cockpit hardware switch or interface to the ICAS is needed. Key network support and changes required to support architecture. Tracking data is being fed directly to the RCC, there is no Data Repository as of yet. Key ground segment support and changes required to support architecture Compliance with Requirements Evaluate the architectures support for the minimum and optional requirements described in Appendix B (minimum requirement set spreadsheet) and for the GADSS CONOPS (Ver 6.0) State of the Operator Approval Criteria Recommendations (section ) using the matrices in Appendix C. Identify and provide textual/graphic descriptions and discussions of any major shortcomings and if and how they are expected to be addressed. Provide textual/graphic descriptions and discussions of any additional capabilities or opportunities for improved distress capabilities and services not addressed in the requirements. Identify and discuss requirements that potentially impose a significant cost or impact for the architecture and discuss where changes in requirements or alternative could potentially provide similar capabilities at a significantly reduced cost or impact. Identify and discuss requirements where there is potential opportunity for the architecture to significantly exceed or improve on the required levels with minor impact and cost. Commented [TP2]: Use EXCEL Compliance matrix. Appendix B, C. Notes in the spreadsheet can end up in this section with descriptions, pictures, examples of industry products. I need requirements V2 Commented [TP3]: Are particular requirements which drive significant cost and impact. Are there alternative requirements which can be refocused to provide similar capabilities. Commented [TP4]: Can there be better requirements which result in better performance and lower cost. A sensitivity assessment of architecture vs cost/performance.

73 The linked image cannot be displayed. The file may have been moved, renamed, or deleted. Verify that the link points to the correct file and location. STRAWMAN FOR ARINC PROJECT PAPER Support for Related Services and Capabilities Provide textual/graphic descriptions and discussions of any additional capabilities or opportunities for improved distress capabilities and services not addressed in the requirements. In particular address support for 5. Normal tracking 6. Abnormal and potential distress tracking 7. Implications for timely recovery of flight data 8. Post Flight Localization and Recovery 3.4 Inmarsat Based SATCOM Architecture Study Description of Architecture Inmarsat s satellite communication network is a proprietary and secure communication facility fit for safety-of-life services. It is the only satellite communication service today which is certified to operate IMO s global maritime distress and safety system (GMDSS). Because GMDSS and GADSS require similar functionality, it is prudent to consider using the same network infrastructure for GADSS. Inmarsat wholly owns and operates the entire system of systems, including all subsystems such as space vehicles, satellite access stations, network nodes and primary and backup space vehicle and network operations centres (SOC and NOC). The network has existing interfaces with rescue coordination centres (RCC) and supports distress alerting, distress communications and priority and pre-emption for safety-of-life communications. To use this infrastructure for GADSS, functionality specific to aviation can be added to the system. Figure 18 shows the overall system architecture and Commented [TP5]: Have Chuck address at Oct 11 th meeting call.

74 GADSS flow diagram as published in ICAO Doc Figure 19 shows the Inmarsat implementation of this architecture. The following elements and functions can be supported by an Inmarsat based solution: - Data SatCom - Voice SatCom - Data rates - Equipage - Tracking capabilities. Global aircraft tracking data can be derived from ADS-C position reports, the location information reporting function integral to the satellite data units (SDU) aboard the aircraft and normally used for network management purposes, and flight recorder data if streamed in real-time. Inmarsat itself does not natively provide distress alert triggering. This is a function of an on-board unit and must therefore be provided by an avionics OEM. We note that Inmarsat does operate the GMDSS system, for which distress alerting and management functions are provided by the Inmarsat maritime terminal. In a similar fashion, GADSS capable terminals / SDU could be provided that implement GADSS compliant and additional distress functions. In addition to this, Inmarsat can implement a distress detection and alert triggering function on the ground by automatically monitoring the aircraft location and available other vehicle telemetry, and trigger a distress alert if a predefined set of parameter values depart from their respective expected envelopes. Further information on triggering can be found in chapter [ADD REF HERE]. Once an alert is received on the ground, whether through GMDSS, GADSS or otherwise, the RCC in charge is notified and communication between SAR and the vehicle in distress is established. In case of an aircraft in distress, the air traffic service unit (ATSU) in charge of the flight can also notified, along with the aircraft s operator. Commented [CP6]: As a minimum requirement ED 237 shall be used to define parameters and associated triggers

75 Figure 18: Overall ADT architecture as published within ICAO Doc (To be harmonized between AEEC and ICAO Doc 10054) Commented [CP7]: Not sure this diagram is in line with ConOps or the White Paper about ADT Data repository. Typically arrows between Operator/ ATSU/RCC/ Repository Figure 19: Inmarsat GADSS implementation

76 Inmarsat already has repositories in place, as soon as the requirements are clear enough to design against, a service can be implemented with relative ease. Figure 2 shows a representative architecture of a possible Inmarsat implementation. Repositories for Maritime ADS-C Paragraph on tracking data volume vs network capacity, network resource allocation Robustness and potential architecture Architecture Mapped to the Architecture Frame Work (action CA) Key components and capabilities mapped to the architecture framework described in Appendix A. Discussion, in terms of architecture framework components, of the architectures functionality that supports the component. Discussion of key assumptions and dependencies for the architecture. Discussion of key airplane infrastructure support and changes required to support architecture. Discussion of key network support and changes required to support architecture. Discussion of key ground segment support and changes required to support architecture Compliance with Requirements ref appendix c (action CA) Evaluate the architectures support for the minimum and optional requirements described in Appendix B (minimum requirement set spreadsheet) and for the GADSS CONOPS (Ver 6.0) State of the Operator Approval Criteria Recommendations (section ) using the matrices in Appendix C. Identify and provide textual/graphic descriptions and discussions of any major shortcomings and if and how they are expected to be addressed. Textual description of future enhancements Provide textual/graphic descriptions and discussions of any additional capabilities or opportunities for improved distress capabilities and services not addressed in the requirements. Identify and discuss requirements that potentially impose a significant cost or impact for the architecture and discuss where changes in requirements or alternative could potentially provide similar capabilities at a significantly reduced cost or impact. Identify and discuss requirements where there is potential opportunity for the architecture to significantly exceed or improve on the required levels with minor impact and cost.

77 3.4.4 Support for Related Services and Capabilities An Inmarsat based ADT system will provide opportunities beyond the anticipated minimum Distress Tracking functions so long as relevant data security requirements are met. The prevalence of installed Inmarsat systems (retrofit market), the significant available bandwidth, and the mature ground network operations allow an Inmarsat based architecture to provide several additional airline AOC/MOC advantages. Encryption and Data Security Functions Normal Tracking By interfacing with various aircraft data buses an Inmarsat based ADT system can be functionally expanded to include rich normal tracking functions. Modifications to normal tacking features can be manually controlled through ground based systems to include reporting of any data available to the airborne ADT system. Airline operations can benefit from ground based GUI systems that allow modifications to reporting intervals, reported parameters, and two-way text communication between ground and aircraft. Additional autonomous tracking modifications, such as interval changes based on various phases of flight can also be incorporated. Commented [CP8]: As discussed, Data Security requirements shall apply The large Inmarsat bandwidth provides opportunities to include significant aircraft state information in the payload of any normal tracking report. Trending and routine diagnostic information can be relayed in real-time with no interference to planned ADT detection and triggering. In the event that any ADT function is needed, normal tracking functions can be suspended. Abnormal and Potential Distress Tracking It is possible that the triggers for ADT tracking will be defined by a small set of conditions. It is also expected that these conditions will be unique to different airframes, types, models, operational modes, etc. By leveraging the onboard logic used for the ADT engine a different, more relaxed set of rules can be used to identify aircraft in an abnormal or potential distressed state. Airline operations will benefit from a real-time understanding of an aircraft state that is not in distress, but that may warrant heightened tracking awareness. Additionally, the Inmarsat payload will allow for streaming of aircraft data, including the entire FDR, from a time before an alerting trigger is identified, to a time when the condition has been resolved. Abnormal or potential distress tracking events can be defined and managed by an airline, independently of the ADT functions. Detection and triggering of

78 abnormal states would remain an airline based responsibility and will not initiate any of the ADT functions. As with normal aircraft tracking, ground based systems can be used to define and manage the triggers for abnormal tracking. DAL considerations need to be addressed to properly manage the expected level D ADT functions from any customer configurable level E functions. REF SYSTEM Commented [CP9]: The DAL, according to the chosen architecture will be Defined/linked to the System Safety Analysis (SSA) Timely Recovery of Flight Data Inmarsat-based ADT functions can provide a significant improvement for timely recovery of flight data and for post flight localization and recovery. Tracking an aircraft at 60 second intervals, or within a 6 NM radius will provide good post flight localization. But the Inmarsat space based network provides an opportunity for further improvement. Latency through the Inmarsat network can effectively be measured in milliseconds. An aircraft that is nearing an end of flight situation can begin a stream of data off the aircraft such that the aircraft 4D position can be known in near real-time. If an antenna lock between aircraft and satellite is maintained during a descent, location of a downed aircraft will be known to a very high degree of accuracy. In extremely unfavourable conditions an aircraft location would still be known within 1 km. [ ] Inmarsat is capable of operating a Black Box in the Cloud service (BBiC), which offers a flight data repository located within its proprietary and secure network. The BBiC may count as a crash-protected memory because it is located away from the aircraft. It is therefore also instantly accessible, with access restricted to accident investigators, rescue coordination centres and related, authorized personnel. In the event of an alert, information pertaining to the flight in distress, especially relevant aircraft telemetry such as location, altitude, altitude change and emergency communication can be forwarded to the ATSU and RCC responsible for the distress flight, and broadcast to maritime vessels near it if the location is over water. Commented [CP10]: Agree, but here we do not address A/C attitude which may impact the link with the satellite. Should this be part of Doc 10054? Commented [CP11]: This is linked to PFLR, not to ADT. I am questioning about its presence in this ADT report? May be put this in Real-time, airborne system diagnostics Using the high throughput capabilities of the Inmarsat network, MOC operations can have real-time access to data from the aircraft. The nature of an ADT system requires that aircraft state is continuously interpreted by monitoring various aircraft data busses. These same busses provide information that can be critical in diagnosing aircraft problems during a flight.

79 The bandwidth provided by Inmarsat makes this real-time diagnosis possible and economical. A system capable of providing the ADT functions can be expanded upon to provide this real-time data as a secondary function. In the event that ADT required functions are needed, any real-time diagnostic functions can be suspended in favour of aircraft distress tracking. Trigger mechanism to complimentary third party system. Some proposed ADT solutions may require an airborne third party system for activation. In a complimentary, dissimilar architecture, an Inmarsat based system as described above, could be used as an input to an ELT-DT or other system. 3.5 ADT with Iridium Transceiver Architecture Study Description of Architecture Autonomous distress tracking functionality is shown for aircraft equipped with Iridium transceiver for both block 1 constellation and high bandwidth Next constellation. As part of the iridium ADT architecture study, these are the options presented and highlighted: Option A - Independent Event & trigger block (ie, ADT) and Iridium transceiver Option B - Integrated Event & trigger block (ADT) and Iridium transceiver and Option C - Separate Event & trigger block (ADT) and Iridium Transceiver with a builtin ADT capability (offering certain level of redundancy for the ADT function).

80 ADT-Satcom Iridium Architecture, Ver 4.0 Option 1 A/C sensor inputs, A/C data (717 etc), A/C power, ADT manual switch Event Detection & Triggering Functional Block Triggering logic Event logic I/O Backup Battery Aircraft Systems Distress Alert (Discrete ) ACK/Crew annunciation Signal (Discrete ) Iridium ADT Functional Block: Aircraft Earth Station (AES) 4 Controller/ Transceiver/Interworking Function RF Block (Filter/Diplexer etc.,). See note on antenna. GNSS Unit Sensors 1 Backup Battery Additional Notes: a. Renamed CMU and/or ADT Router as Controller or Interworking Function. b. Data Bus (one-way) to Iridium ADT enables external GNSS source and additional Abnormal and Flight Data Streaming function c. 2-way coms between AOC and ADT to support ground-based Distress. d. Note 1: LGA/HGA Antenna: (1) With Block 1, LGA. (2) With certus, LGA (RF block builtin to iridium transceiver function) or (3) With Certus, HGA (RF block builtin to antenna) LGA/HGA(see note ) Iridium Satellite Network Ground Earth Station (GES) Note 2: It is recommended the link, A/C systems ADT is unidirectional diode to prevent potential security breach from Ground systems and/or AISD domain. The only exception shown is ADT status going to flight deck (A/C systems domain). This exception will have to be reviewed as a team on how the potential security risk from AISD domain will be addressed. Note 3: Ground based trigger can be used in the case of non-cooperative crew (malicious or incapacitated). Also has cancel trigger ability. Note 4: GNSS unit has its own antenna pole (not shown here) Figure 20: ADT SATCOM Iridium Architecture Option 1 (External Trigger Source)

81 ADT-Satcom Iridium Architecture, Ver 4.0 Option 2 A/C sensor inputs, A/C data (717 etc), A/C power, ADT manual switch Aircraft Systems ACK/Crew annunciation Signal (Discrete ) Iridium ADT Functional Block: Aircraft Earth Station (AES) 4 Event Detection & Triggering Functional Block Controller/ Transceiver/Interworking Function RF Block (Filter/Diplexer etc.,). See note on antenna. GNSS Unit Triggering logic Event logic I/O Backup Battery Distress Alert (Discrete ) LGA/HGA(see note ) Iridium Satellite Network Ground Earth Station (GES) Additional Notes: a. Renamed CMU and/or ADT Router as Controller or Interworking Function. b. Data Bus (one-way) to Iridium ADT enables external GNSS source and additional Abnormal and Flight Data Streaming function c. 2-way coms between AOC and ADT to support ground-based Distress. d. Note 1: LGA/HGA Antenna: (1) With Block 1, LGA. (2) With certus, LGA (RF block builtin to iridium transceiver function) or (3) With Certus, HGA (RF block builtin to antenna) Note 2: It is recommended the link, A/C systems ADT is unidirectional diode to prevent potential security breach from Ground systems and/or AISD domain. The only exception shown is ADT status going to flight deck (A/C systems domain). This exception will have to be reviewed as a team on how the potential security risk from AISD domain will be addressed. Note 3: Ground based trigger can be used in the case of non-cooperative crew (malicious or incapacitated). Also has cancel trigger ability. Note 4: GNSS unit has its own antenna pole (not shown here). Figure 21: ADT SATCOM Iridium Architecture Option 2 (Internal Trigger Function)

82 ADT-Satcom Iridium Architecture, Ver 4.0 Option 3 A/C sensor inputs, A/C data (717 etc), A/C power, ADT manual switch Detection & Triggering Functional Block Triggering logic Event logic I/O Battery backup Aircraft Systems Distress Alert (Discrete ) ACK/Crew annunciation Signal (Discrete ) 4 Additional Notes: a. Solid line boxes denote minimum functional blocks required. Example: Discrete Signal (3) Triggers to Iridium ADT (4) Controller/RF Block/ LGA-antenna transmission to Ground Station, including Flight Crew Feedback (6). b. Renamed CMU and/or ADT Router as Controller or Interworking Function. c. Data Bus (one-way) to Iridium ADT enables external GNSS source and additional Abnormal and Flight Data Streaming function d. 2-way coms between AOC and ADT to support ground-based Distress. e. Note 1: LGA/HGA Antenna: (1) With Block 1, LGA. (2) With certus, LGA (RF block builtin to iridium transceiver function) or (3) With Certus, HGA (RF block builtin to antenna) LGA/HGA(see note ) Iridium Satellite Network Ground Earth Station (GES) Note 2: It is recommended the link, A/C systems ADT is unidirectional diode to prevent potential security breach from Ground systems and/or AISD domain. The only exception shown is ADT status going to flight deck (A/C systems domain). This exception will have to be reviewed as a team on how the potential security risk from AISD domain will be addressed. Note 3: Ground based trigger can be used in the case of non-cooperative crew (malicious or incapacitated). Also has cancel trigger ability. Note 4: GNSS unit has its own antenna pole (not shown here) Figure 22: ADT SATCOM Iridium Architecture Option 3 (External and Internal Trigger Functions)