Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Analysis of-flight-data-streaming-trial-on-the-boeing-2018-eco demonstrator

115 views

Published on

The aviation industry has been looking for a viable and effective solution which would support the emerging standards associated with the Global Aeronautical Distress Safety System (GADSS). These standards are new Standards and Recommended Practices (SARPs) which have been introduced into ICAO Annex 6 Part I regarding Flight Recorder Data Recovery and the Location of an Aircraft in Distress. These new SARPs specify capabilities for operators that begin to take effect as early as 2018. The operational capabilities which are specified in terms of recommended functionality and performance in turn imply a mandate for aircraft equipage. Further information about GADSS and the requirements is available in the GADSS ConOps and the ICAO implementation guidance document “Manual on Location of Aircraft in Distress and Flight Recorder Data Recovery” Doc 10054 (draft). These new SARPs have to some degree already been adopted by many States and incorporated into State’s regulations. Over time it is anticipated that even more States will embrace the GADSS concept and modify their national regulations accordingly.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Analysis of-flight-data-streaming-trial-on-the-boeing-2018-eco demonstrator

  1. 1. Revision NEW Page 1 of 54 Analysis of Flight Data Streaming Trials on the Boeing 2018 EcoDemonstrator RELEASE/REVISION DATE: 15 August 2018 Revision New The Boeing Company FLYHT Aerospace Solutions Inc. Embraer The Boeing Company FLYHT Aerospace Solutions Inc. Embraer S/A Charles Adler Derek Graham Roberto Dias Pereira Greg Moran Luis Henrique Pinto Malizia Alves Janet Booth Kira Hein Approved 15 August 2018 Approved 15 August 2018 Approved 15 August 2018 Abstract This white paper outlines the results and analysis of Flight Data Streaming Trials on the Boeing 2018 EcoDemonstrator program performed in partnership with Boeing, FLYHT and Embraer. ©2018
  2. 2. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 2 of 54 Contents EXECUTIVE SUMMARY ............................................................................................................................ 4 INTRODUCTION....................................................................................................................................... 6 REFERENCE DOCUMENTS .................................................................................................................................6 ACRONYMS AND ABBREVIATIONS.......................................................................................................................6 BACKGROUND......................................................................................................................................... 8 EMERGING STANDARDS FOR FLIGHT DATA RECOVERY.............................................................................................8 Autonomous Distress Tracking (ADT).............................................................................................10 Post Flight Localization and Recovery (PFLR) .................................................................................12 Post flight localization of the aircraft ................................................................................................... 12 Timely recovery of flight recorder data................................................................................................ 12 TRIAL OVERVIEW .................................................................................................................................. 13 TRIAL OBJECTIVES AND SCOPE.........................................................................................................................13 OVERVIEW OF THE BOEING 2018 ECODEMONSTRATOR PROGRAM ........................................................................14 Overview of the FEDEX 777F Test Airplane System ........................................................................14 TEST EQUIPMENT CHARACTERISTICS AND DESCRIPTION........................................................................................15 System Level Description................................................................................................................15 AFIRS228.............................................................................................................................................. 16 Aircraft Configuration Module............................................................................................................. 17 Inmarsat Satellite System...............................................................................................................17 UpTime Cloud servers.....................................................................................................................17 Third party FDM analysis ...............................................................................................................18 Satellite Links..................................................................................................................................20 Inmarsat............................................................................................................................................... 20 Iridium ................................................................................................................................................. 20 FLIGHT TEST SETUP.......................................................................................................................................20 Equipment and Installation............................................................................................................20 AFIRS 228S ........................................................................................................................................... 21 GPS/Iridium Antenna ........................................................................................................................... 21 SDU and SATCOM System .................................................................................................................... 21 Control and Display Unit (CDU)............................................................................................................ 22 Flight Data Recorder ............................................................................................................................ 22 L3 Cockpit Area Microphone................................................................................................................ 23 Flight Test Engineering Interfaces ........................................................................................................ 23 TEST PLAN AND PROCEDURES .........................................................................................................................23 DATA COLLECTION ........................................................................................................................................24 TEST RESULTS ........................................................................................................................................ 25 KEY FINDINGS..............................................................................................................................................26 Test Result Anomalies.....................................................................................................................26 STREAMED FDR DATA INTEGRITY TESTS ............................................................................................................27 Introduction....................................................................................................................................27 Test Process....................................................................................................................................28 Data Verification ............................................................................................................................28 Cost Considerations........................................................................................................................28 Summary of Integrity and Latency Analysis ...................................................................................29 DATA LATENCY TEST RESULTS ..........................................................................................................................30 Introduction....................................................................................................................................30 Data Recovery ................................................................................................................................30 Timestamps....................................................................................................................................30 Calculations and Results ................................................................................................................30
  3. 3. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 3 of 54 IRIDIUM TESTING..........................................................................................................................................31 Introduction....................................................................................................................................31 Test Process....................................................................................................................................31 Iridium Streaming Results ..............................................................................................................31 COCKPIT AREA MICROPHONE TESTING .............................................................................................................32 Introduction....................................................................................................................................32 Test Process....................................................................................................................................32 Cockpit Area Microphone Streaming Results.................................................................................33 FUTURE CONSIDERATIONS, CONCLUSIONS, AND RECOMMENDATIONS ................................................ 33 NETWORK PERFORMANCE AND ROBUSTNESS.....................................................................................................33 CONCLUSIONS AND RECOMMENDATIONS...........................................................................................................33 APPENDIX A ICAO REFERENCES............................................................................................................... 35 APPENDIX B FLIGHT TEST DATA COLLECTION DETAILS ............................................................................. 49 Figures Figure 1: Original Concept of the GADSS................................................................................................ 9 Figure 2: GADSS Current Structure......................................................................................................... 9 Figure 3: GADSS Concept at the Time of the Approval of Amendment 40-A to Annex 6 .................... 11 Figure 4: Boeing 2018 EcoDemonstrator FedEx 777F .......................................................................... 15 Figure 5: AFIRS System Level Diagram.................................................................................................. 16 Figure 6: UpTime Cloud GUI Analysis Plots .......................................................................................... 18 Figure 7: UpTime Cloud GUI Cockpit Display........................................................................................ 19 Figure 8: UpTime Cloud GUI Flight Path Simulation............................................................................. 19 Figure 9: AFIRS Installation and Flow Diagram..................................................................................... 21 Figure 10: SDU and SATCOM System.................................................................................................... 22 Figure 11: AFIRS and UpTime Cloud Data Flow Diagram...................................................................... 27 Tables Table 1: Test Conditions......................................................................................................................... 24 Table 2: Data Summary.......................................................................................................................... 25 Table 3: Key Findings ............................................................................................................................. 26 Table 4: Summary of Data Usage........................................................................................................... 29 Table 5: Summary of Flights with FDR Streamed Content..................................................................... 29 Table 6: Flight Test Data Collection Details............................................................................................ 49
  4. 4. Revision NEW Page 4 of 54 Executive Summary The aviation industry has been looking for a viable and effective solution which would support the emerging standards associated with the Global Aeronautical Distress Safety System (GADSS). These standards are new Standards and Recommended Practices (SARPs) which have been introduced into ICAO Annex 6 Part I regarding Flight Recorder Data Recovery and the Location of an Aircraft in Distress. These new SARPs specify capabilities for operators that begin to take effect as early as 2018. The operational capabilities which are specified in terms of recommended functionality and performance in turn imply a mandate for aircraft equipage. Further information about GADSS and the requirements is available in the GADSS ConOps and the ICAO implementation guidance document “Manual on Location of Aircraft in Distress and Flight Recorder Data Recovery” Doc 10054 (draft). These new SARPs have to some degree already been adopted by many States and incorporated into State’s regulations. Over time it is anticipated that even more States will embrace the GADSS concept and modify their national regulations accordingly. In anticipation of these emerging standards, Boeing, FLYHT, and Embraer (as part of the ecoDemonstrator program) flew a real-time data streaming technology to demonstrate the potential for the technology to support Timely Recovery of Flight Recorder Data outlined in the GADSS ConOps and in Doc10054. The trial activities used FLYHT’s real-time, data streaming solution in concert with two different SATCOM systems: Iridium Short Burst Data Service and Inmarsat SwiftBroadband to evaluate the system’s ability to deliver the functionality required for certain aspects of the ICAO standards. The ecoDemonstrator program utilized FLYHT’s AFIRS 228S to stream in real time all the data normally captured by the flight data recorder and digitized audio from one cockpit area microphone. Data was captured in FLYHT’s UpTime™ Cloud server and recreated in 3D animation allowing operators on the ground to view a Virtual Cockpit Display of the pilots’ Primary Flight Display (PFD), crucial engine gauges, and flight controls in near real time. Test conditions were included that demonstrated full time streaming of data and also data streaming activated by triggering events. Triggers were set up to activate streaming when the airplane experienced excessive bank angle, pitch angle, and vertical speed. These triggers were also used to simulate an Automated Distress Tracking function by initiating a report of aircraft position at a rate higher than once per minute as required by the SARPs. The platform for the 2018 ecoDemonstrator was a FedEx 777F. Boeing, Embraer, and FLYHT collaborated together using this aircraft to test and demonstrate Tracking, Locating, and Data Recovery or TLDR. The testing demonstrated in real flight conditions with COTS equipment the following functionality: • Normal flight tracking • Triggered Flight Data Recorder (FDR) Streaming which would support the near-term ICAO standards and recommendations regarding Autonomous Distress Tracking (ADT) • An FDR and Cockpit Voice (Triggered or Full Time) data steaming solution to meet the future standards and recommendations for Post Flight Localization (aircraft position) and Data Recovery. • Near real time telemetry and display of FDR data on the ground for increase situational awareness during emergency situations The equipment tested during the trial included:
  5. 5. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 5 of 54 • An AFIRS™228, a modified off the shelf based on certified avionics LRU (Line Replaceable Unit), • A permanently mounted ACM (Aircraft Configuration Module), • A Cockpit Area Microphone • An Iridium/GNSS Antenna • An Inmarsat SwiftBroadband System, and • The UpTime Cloud ground server. During the ecoDemonstrator program, four different Inmarsat streaming service classes were experimented with: BACKGROUND, STREAM32K, STREAM128K, and STREAM256K. On the B777 real- time FDR streaming was configured to be initiated by one of two types of triggers: 1. Remotely activated from the ground, through a GUI (Graphical User Interface) on the UpTime Cloud web interface 2. Automatically activated through customized event detection onboard the AFIRS228 unit The AFIRS unit was programmed to transmit real-time streamed FDR data for a minimum of 20 minutes after either of the two triggers. Additionally, and in parallel, 20 minutes of buffered FDR data prior to the event detection was transmitted. The real-time data streaming could be for any length of time and continued until either deactivated remotely from the ground, or until 20 minutes after the automatic trigger conditions ceased and all the buffered data was finished streaming. Note: Because the AFIRS unit acts as a QAR (Quick Access Recorder), the buffered streaming duration can easily be increased as needed. An interface was developed to receive the real-time FDR stream data. After only a few seconds of data, the analysis process began and information was available for users in the UpTime Cloud GUI. Typical latency between any event occurring on the aircraft, and that event being displayed in the UpTime Cloud GUI, i.e., after having been processed through the Flight Data Monitoring (FDM) system, between six and eight seconds. Included in the FDM analysis, and available to users in real- time are: • Complete list of all Engineering Units for all ARINC 717 data • Graphing tools to display any Engineering Unit • Tabular data showing all Engineering Units • Graphical flight deck instrumentation display • Moving map • Aircraft animation • Ability to move forward and backward through a live streaming session The results of these tests showed that the tested proof-of-concept system addresses several key aspects of the guidance material outlined in the ICAO Doc10054. A summary of the tested solution’s conformance to these standards and recommendations is presented in Table 3: Key Findings. Based on the solution’s proof-of-concept testing performed during the ecoDemonstrator trials, a Satcom-based solution combined with real-time, data streaming technology could be leveraged and developed to address the near-term requirements for Aircraft Tracking and Autonomous Distress Tracking and could potentially address future requirements for Post Flight Localization and Data Recovery. Even in incidents where the aircraft data cannot be located, the data streamed off the airplane can provide a head start in accident investigation and perhaps even accident mitigation and recovery.
  6. 6. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 6 of 54 Introduction This white paper presents to the aviation industry a compelling proof-of-concept solution to address the ICAO Standards and Recommendation Practices for Autonomous Distress Tracking and Timely Recovery of Flight Data and which is consistent with the Global Aeronautical Distress Safety System (GADSS) ConOps and the guidance given in ICAO Doc 10054 “Manual on Location of Aircraft in Distress and Flight Recorder Data Recovery”. Doc 10054 supports Standards and Recommended Practices (SARPs) introduced into Annex 6, Part I regarding Flight Recorder Data Recovery and the Location of an Aircraft in Distress. The following sections outline the background issues that triggered the introduction of the new standards and describe the tested system, the test scenarios and activities, and test results from the proof-of-concept demonstration flights. Based on the trial program and results, this paper also provides recommendations on how the aviation industry can best address the new standards and requirements effectively. Reference Documents The following documents are referenced: 1. ICAO International Standards and Recommended Practices (SARPS), Annex 6 to the Convention on International Civil Aviation, Operation of Aircraft, Part I — International Commercial Air Transport — Aeroplanes, Tenth Edition, July 2016 2. ICAO Document 10054, Manual on Location of Aircraft in Distress and Flight Recorder Data Recovery, Final Draft, 3/21/2018 Acronyms and Abbreviations ACM Aircraft Configuration Module ADFR Automatic Deployable Flight Data Recorder ADPCM Adaptive Differential Pulse Code Modulation ADT Autonomous Distress Tracking AFIRS Automated Flight Information Reporting System AIR Aircraft Image Recorder ARINC Aeronautical Radio, Incorporated AT Aircraft Tracking ATS Air Traffic Service ATTF Aircraft Tracking Task Force AWS Amazon Web Services CAM Cockpit Area Microphone CDU Control and Display Unit CF Compact Flash CofA Certificate of Airworthiness ConOps Concept of Operations COTS Commercial-off-the-shelf
  7. 7. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 7 of 54 CRC Cyclical Redundancy Check CVR Cockpit Voice Recorder DFDAF Digital Flight Data Acquisition Function DLNA Diplexer/Low Noise Amplifier DLR Data Link Recorder EFTS Emergency Flight Tracking Service ELT Emergency Locator Transmitter EU European Union EUROCAE European Organization for Civil Aviation Equipment FDM Flight Data Monitoring FDR Flight Data Recorder GADSS Global Aeronautical Distress and Safety System GES Ground Earth Stations GMDSS Global Maritime Distress and Safety System GNSS Global Navigation Satellite System GPS Global Positioning System GUI Graphical User Interface IATA International Air Transport Association ICAO International Civil Aviation Organization ID Identification INU Inertial Navigation Unit LRU Line Replaceable Unit MASPS Minimum Aviation System Performance Specification MCTOM Maximum Certified Take-Off Mass MOPSC Maximum Operational Passenger Seating Configuration NPA Notice of Proposed Amendment OEM Original Equipment Manufacturer ORT Owner Requirements Table PFD Primary Flight Display PFLR Post Flight Localization & Recovery QAR Quick Access Recorder RCC Rescue Coordination Centre RF Radio Frequency RFTS Routine Flight Tracking Service SAR Search and Rescue SARPS Standards and Recommended Practices SBD Short Burst Data SCM SDU Configuration Module SDU Satellite Data Unit
  8. 8. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 8 of 54 SIM Subscriber Identity Module SSR Secondary Surveillance Radar SWIM System Wide Information Management TCP/IP Transmission Control Protocol/Internet Protocol TLDR Tracking, Locating, and Data Recovery TRFD Timely Recovery of Flight Data TTFDWG Triggered Transmission of Flight Data Working Group ULB Underwater Locating Beacon Device ULD Underwater Locating Beacon Device VPN Virtual Private Network XPDR Transponder Background This section provides background on what triggered the development and introduction of new standards in aviation safety, outlines the evolution of those standards and requirements, and briefly explains which requirements are addressed by FLYHT’s proof-of-concept solution. Emerging Standards for Flight Data Recovery Over the past decade, incidents such as the AF447 and MH370 losses have highlighted the need for improved means to accurately locate downed aircraft and to provide more timely means to recover flight data. Mirroring the GMDSS (Global Maritime Distress and Safety System) concept and the definitions of the emergency phases found in Annexes 11 and 12 to the International Convention on Search and Rescue, ICAO (International Civil Aviation Organization) has devised the GADSS (Global Aeronautical Distress and Safety System), which is a system designed to cover a normal (RFTS – routine flight tracking service) and an emergency tracking phase (EFTS – Emergency Flight Tracking Service).
  9. 9. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 9 of 54 Figure 1: Original Concept of the GADSS In 2014, ICAO issued a Concept of Operations (ConOps) document to describe the GADSS, which was meant to provide "(...) performance based standards, (...) independent of any one prescriptive technology." However, this definition did not match, at first, what was described along the document. For instance, in the emergency phase (EFTS), the ConOps required the use of a second generation Emergency Locator Transmitter (ELT) and Automatic Deployable Flight Recorder (ADFR). As the result of such inconsistencies, the GADSS ConOps document has gone through some revisions. The latest one, version 6.0, was issued in June of 2017. Currently, the GADSS is structured as illustrated in Figure 2. Figure 2: GADSS Current Structure
  10. 10. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 10 of 54 Therefore, the current GADSS consists of the following main system components: • Aircraft Tracking (AT) Function; • Autonomous Distress Tracking (ADT) function; • Post Flight Localization and Recovery (PFLR) function, which can be further divided in two sub-functions: o Post Flight Localization of the Aircraft; o Timely Recovery of the Flight Recorders' data; • GADSS Information Management and Procedures. The following sections will discuss Autonomous Distress Tracking used to define Trial triggered events and Timely Recovery of Flight Data which drove the trial flight data streaming approach. Autonomous Distress Tracking (ADT) The Autonomous Distress Tracking (or ADT), which is the capability that enables the aeronautical safety system to identify and track an aircraft in distress, was described, in the ConOps document, as "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". First, it is important to notice that the ICAO definition does not necessarily require the transmission of the 4D position of the aircraft, but instead requires broadcast of a signal from which the operator (or operator’s agent) can determine the position of the aircraft when the aircraft is in distress. Second for the ADT the minimum transmission interval is at least once per minute. The ConOps of the GADSS adopts the definition that "an aircraft is in a distress condition when it is in a state that, if the aircraft behavior is left uncorrected, may result in an accident." This is a somewhat generic definition that can lead to a number of questions (e.g., is fire in the aircraft lavatory a distress condition? Theoretically, if no action is taken to extinguish the fire, the aircraft would eventually crash). In order to address some of these concerns, the GADSS ConOps indicates that guidance concerning when an aircraft is in a distress condition is given in EUROCAE (European Organization for Civil Aviation Equipment) ED-237 (Minimum Aviation System Performance Specification (MASPS) for Criteria to Detect In- Flight Aircraft Distress Events to Trigger Transmission of Flight Information). ED-237 indicates that there are at a minimum four scenarios to be considered when determining if an aircraft is in a distress condition: 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."
  11. 11. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 11 of 54 Theoretically, any aircraft state that would lead to a distress condition, if left uncorrected, would eventually end up in the four scenarios above. For instance, fire in the lavatory would eventually, if left unchecked and uncorrected, lead to an unusual attitude/unusual altitude scenario. However, even ED-237 makes a certain allowance when it states that "manufacturers may include additional scenarios or combine scenarios, provided that they do not impair the overall efficiency and/or reliability of the triggering logic". In the end, the ED-237 scenarios are still somewhat generic and each OEM has to customize for each aircraft type the appropriate distress conditions Note that the ADT functionality standards and recommendations have been adopted by ICAO with the title "Location of an Aeroplane in Distress" and not "Autonomous Distress Tracking". These standards encompass not only the ADT itself, but another GADSS sub-functionality: the post flight localization of an aircraft, which is grouped, according to the ConOps document, with the PFLR functionality. But why is the post flight localization sub-functionality grouped together with the ADT and not with the Timely Recovery of the Flight Recorders' data, as the current GADSS ConOps intended? To answer this question, it is important to note that at the time that ICAO issued amendment 40-A to Annex 6, the composition of the GADSS was somewhat different, as the figure below demonstrates: Figure 3: GADSS Concept at the Time of the Approval of Amendment 40-A to Annex 6 As indicated in Figure 3, there was not the concept of "PFLR" around 2016 and the ADFR was still envisioned as the long term solution for the recovery of the contents of the flight recorders. Also, as Attachment K to ICAO Annex 6 clarifies "(...) 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". Therefore, it is expected to use the ADT system to also perform the function of post flight localization of an aircraft.
  12. 12. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 12 of 54 Post Flight Localization and Recovery (PFLR) Differently from the ADT, the Post Flight Localization and Recovery (PFLR) did not receive a definition in the GADSS ConOps document. Instead, the ICAO document separates the PFLR into two functions: (i) post flight localization of the aircraft; and (ii) timely recovery of flight recorder data. Post flight localization of the aircraft For this sub-functionality, it is required that the ELT (Emergency Locator Transmitter) and the ULD (Underwater Locating Beacon Device) provide information about the position of the aircraft, to aid the Search and Rescue (SAR) services. The GADSS ConOps document references the ELT and ULD standards specified in the Annex 6 provisions. Although this is implicit in the ConOps document, and explicit in the ICAO Annex 6 provisions (Appendix 9 and Attachment K); and draft document 10054 (Manual on Location of Aircraft in Distress and Flight Recorder Data Recovery, sections 3.3.6 and 3.3.7), the ADT function may be used to perform this functionality of aircraft localization. Refer to items 6.18; Appendix 9 and Attachment K to ICAO Annex 6; (refer to item A.1 in Appendix A). It is important to note that there is an incompatibility between ICAO Annex 6, Part I, Appendix 9 and the draft ICAO document 10054. Appendix 9 indicates that the "location of an aeroplane in distress aims at establishing, to a reasonable extent, the location of an accident site within a 6 NM radius." However, draft document 10054 indicates that "the goal of the Post Flight Localization function is to locate an aircraft within 1 NM or better". Last but not least, it is worth noting that ICAO has exempted the use of one ELT if the aircraft is equipped with means to locate an aircraft (refer to item A.2 in Appendix A). Timely recovery of flight recorder data For this other functionality, the GADSS ConOps indicates that the flight recorder's data needs to be recovered in a timely manner. The associated standards and recommendations are detailed in ICAO Annex 6 provisions and ICAO Doc 10054 guidance material (refer to item A.3 in Appendix A). But what is "timely manner"? According to the draft ICAO document 10054, "timely recovery means as soon as possible for a specific situation. It is not possible to define a maximum required duration because the recovery timeframe is a function of the specific situation: the technology used and circumstances of the accident. However the timely recovery of the data should not require more than the search and rescue capabilities and the investigation capabilities recommended by ICAO Annexes and more generally, this should limit the need for authorities to rely on non-conventional and expensive recovery means for getting the data." In other words, albeit "timely manner" is not defined, it is understood that this sub-functionality should avoid situations such as of the AF447 and MH370 long searches. Since ICAO standards are not legally binding (with the exception of flight over international waters), in the end, it will fall to each country certification authority to determine what is the meaning of "timely manner". Another question that must be answered is what data from the recorders should be recovered. According to ICAO draft document 10054, "the objective is to timely recover the complete contents of flight recorder data as defined in Standards of section 6.3 of Annex 6 Part I ‘Flight Recorders’". However, it is also recognized that this objective may not be achievable depending on certain factors. According to document 10054, "the system providing timely recovery of flight recorder data has to provide at a very minimum the data from the time the aeroplane enters the distress conditions to the end of the flight. Also to the extent possible, historical data prior to the time the flight enters the distress conditions should be provided with the most recent data being given the highest priority." In
  13. 13. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 13 of 54 other words: as the very minimum, the timely recovery of flight recorder data system is required to provide data from the time the aircraft enters into the distress state. ICAO is still drafting document 10054, in order to provide a guidance material for the ADT and PFLR functionalities. However, this document has already indicated, at least, two different solutions to comply with the timely recovery of flight recorder data: (i) Satellite Data Streaming (ii) Automatic Deployable Flight Recorder In regards to satellite data streaming, document 10054 still considers two possibilities: A) Continuous transmission of flight recorder data to the ground B) Triggered transmission of flight recorder data to the ground For continuous transmission of flight recorder data to the ground, document 10054 indicates that the system starts transmitting when the aircraft’s fixed recorders start recording; and terminates when the fixed recorders also stop recording. If any connectivity interruption occurs, it is expected to use data buffering to cover the period that the system was not transmitting. For triggered transmission of flight recorder data to the ground, document 10054 indicates that the system starts transmitting when the distress trigger logic is automatically activated. In this case, historical data prior to the distress event is to be also transmitted. Again, if any connectivity interruption occurs, data buffering is expected to be used to cover the period that the system was not transmitting. In both implementations, buffered data transmitted because of a connectivity interruption will have priority over real-time data. Document 10054 also states that since the data that is being transmitted is used for accident investigation, it is also expected that secure means are used for transmitting data from the aeroplane to the server, including data encryption and signing techniques to ensure protection and integrity of the data (except for the data that are already used for surveillance, such as ADS-B or ADS-C). Also, it is worth noting that satellite data streaming presents the advantage to not have the SAR mission searching for the recorders, specifically. As for the ADFR solution, document 10054 indicates that it is to be deployed upon detection of an impact or water immersion. It specifies that the ADFR is to contain an embedded ELT, which is designed to be activated simultaneously with the ADRF deployment. It bears to note that if one adopts the ADFR solution, its use for accident investigation will commence only after it is found by the SAR mission. Trial Overview This section describes the trial details during the ecoDemonstrator program. This includes an overview, trial objectives, the equipment used, the installation design, the data collection and data analysis. Trial Objectives and Scope The objective of the tests performed during this trial was to demonstrate flight data streaming over Satcom to evaluate its potential as a solution to address the emerging standards.
  14. 14. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 14 of 54 The scope of the tests was to: • Stream the entire flight data recorder and cockpit area microphone audio in real-time, • Capture the data in FLYHT’s UpTime™ Cloud server, • Setup streaming triggers to report on excessive bank angle, pitch angle, and vertical speed • Validate the streamed FDR data to the FDR data recorded on the AFIRS CF card; and, • Identify the data latency. Additionally, as an enhancement to TRFD functionality, a re-creation of flight data was generated in 3D animation allowing operators on the ground to view a Virtual Cockpit Display of the pilots’ Primary Flight Display (PFD), crucial engine gauges, and flight controls. Inmarsat SwiftBroadband Satcom was identified to be the primary focus of the activity due to its bandwidth characteristics. Iridium Short Burst Data would be a secondary focus with a subset of tests tailored to its narrow bandwidth. Overview of the Boeing 2018 EcoDemonstrator Program To support the long-term sustainable growth of aviation, Boeing looks for opportunities to improve commercial aviation’s environmental performance throughout an airplane’s lifecycle. The Boeing ecoDemonstrator Program plays a key role in the company’s environmental strategy by using flight testing to accelerate new technologies that can reduce emissions and noise, improve airlines’ gate-to- gate efficiency and help meet other environmental goals. Proven ecoDemonstrator technologies and processes may be incorporated into existing production models, made available for in-service fleets and applied to new airplane development programs. The Boeing ecoDemonstrator Program is focused on accelerating the testing, refinement and completion of new technologies, methods, and materials to improve aviation's environmental performance and sustainability through collaboration and innovation. It is a multi-year program with technologies on several airplanes that serve as flying test beds. To date, the ecoDemonstrator Program has tested more than 55 technologies using four airplanes as flying test beds. More than 15 technologies were tested on an American Airlines 737-800 in 2012. In 2014, more than 25 technologies were tested on the Boeing-owned 787 Dreamliner ZA004. In 2015, the ecoDemonstrator Program tested more than 15 technologies (including Iridium based ADT systems) on a 757 in collaboration with NASA and TUI Group. In 2016, Boeing and Embraer collaborated to test ecoDemonstrator technologies using an Embraer E170 airplane flying the tests in Brazil. In 2018, Boeing and FedEx worked together to test more than 37 technologies aboard a FedEx-owned 777 Freighter. FLYHT and Embraer were two of the many collaborators that contributed to the technologies that were demonstrated on this platform. Overview of the FEDEX 777F Test Airplane System The platform for the 2018 ecoDemonstrator was a FedEx 777F (shown in Figure 4: Boeing 2018 EcoDemonstrator FedEx 777F). It was a flying test bed for over 37 technologies. Boeing, Embraer, and FLYHT collaborated together on one of those technologies, Tracking, Locating, and Data Recovery or TLDR. The purpose of this project was to demonstrate in-flight that existing technology for flight tracking and Flight Data Recorder Streaming may be used to provide functionality consistent with some aspects of ICAO standards regarding ADT, location of an aircraft in distress, and post flight localization. In addition, the results of this test program may be useful to support technical
  15. 15. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 15 of 54 discussions in technology related standardization working groups and Aeronautical Certification Authorities' rulemaking processes. Figure 4: Boeing 2018 EcoDemonstrator FedEx 777F The planning phase of the 2018 ecoDemonstrator began in late 2016. FedEx provided the ecoDemonstrator Program with a 777F airplane. The identified aircraft, WF069, was delivered from the production line to FedEx, used in service for a few months then delivered back to Boeing for use in the program. 37 technologies were installed and tested on the aircraft. With the large number of technologies on this ecoDemonstrator program, the technical integration was quite complicated. The goal was to install the technologies with as small of an impact to the structure and disruption of the systems of the airplane as possible. Boeing installed the test equipment, performed the testing, and then returned the aircraft to the production configuration before returning it to FedEx. Considering this limitation and the integration with all the other technologies, some limitations were imposed on the installation of the TLDR system. The final design is outlined in Section 4.4.1. Even though this was not a standard installation, it was representative of the data inputs and outputs that one would find on a typical 777 STC AFIRS installation. Test Equipment Characteristics and Description The following sections describe the test equipment used during the testing. System Level Description The AFIRS/UpTime Cloud system (illustrated in Figure 5) consists of the following: • An AFIRS™228, a modified off the shelf based on certified avionics LRU (Line Replaceable Unit), • A permanently mounted ACM (Aircraft Configuration Module), • A Cockpit Area Microphone, • An Iridium/GNSS Antenna,
  16. 16. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 16 of 54 • An Inmarsat SwiftBroadband System, and • The UpTime Cloud ground server. Figure 5: AFIRS System Level Diagram AFIRS228 The AFIRS has been installed and operating on different aircraft fleets for over 15 years. The version used on the ecoDemonstrator B777 was the AFIRS228S provisioned to receive ARINC 717 FDR data, ARINC 429, discrete inputs, and GNSS data. The AFIRS unit contains two internal Iridium L-Band Satcom modems for voice and data transmission and is interfaced to a dual-purpose GPS/Iridium Antenna. In addition, AFIRS interfaces to third-party Satcoms and Inflight connectivity systems via Ethernet. An internal INU (Inertial Navigation Unit) was incorporated to demonstrate the ability to detect distress aircraft states autonomously. The Core software on the AFIRS228 allows for customizable data analysis configurations to be developed that will receive, convert, and report on data from these different sources. On the B777 real-time FDR streaming was configured to be initiated by one of two types of trigger: 1. Remotely from the ground, through a GUI (Graphical User Interface) on the UpTime Cloud web interface 2. Automatically through customized event detection onboard the AFIRS228 unit In anticipation of ICAO regulations, the AFIRS unit was programmed to transmit real-time data streaming of FDR data for a minimum of 20 minutes after either of the two types of activation. Additionally, and in parallel, 20 minutes of buffered streaming of FDR data prior to the event detection was transmitted. The real-time streaming could continue for any length of time and was setup to continue until either deactivated remotely from the ground, or for 20 minutes after the
  17. 17. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 17 of 54 automatic trigger conditions ceased. Because the AFIRS unit acts as a QAR (Quick Access Recorder), the buffered streaming duration can easily be increased as needed. Aircraft Configuration Module The aircraft mounted Aircraft Configuration Module (ACM) contains the configuration for the AFIRS 228 unit and contains the SIM card for network access to the Iridium radio function embedded in the AFIRS unit. The ACM is attached to the permanently mounted AFIRS tray. This allows easy replacement of the LRU without changing the configurable components of the AFIRS installation. Inmarsat Satellite System The trial used a Thales TopFlight ARINC 781 Aero-H+ SwiftBroadband, a Satellite Data Unit (SDU) and a Cobham Class 6 Inmarsat high gain antenna. This system provided the primary path for data transmissions for the trial. The choice and configuration of the Thales SDU was determined by the production configuration of the aircraft. SwiftBroadband is an IP-based packet-switched service offering ‘always-on’ data at up to 432kbps per channel. It can also provide IP streaming at various rates. During the ecoDemonstrator program, FLYHT experimented with four different Inmarsat streaming classes: BACKGROUND, STREAM32K, STREAM128K, and STREAM256K. Through the Inmarsat network a VPN (Virtual Private Network) was created using a TCP/IP connection between the AFIRS unit and the UpTime Cloud. UpTime Cloud servers Through the Inmarsat satellite network, FLYHT established a TCP/IP connection between the AFIRS unit on the aircraft and the UpTime Cloud servers on the ground. This connection was maintained from aircraft power-up to shut down regardless of whether FDR data transmissions were taking place. The UpTime cloud servers are maintained on the AWS (Amazon Web Services) network. The UpTime Cloud system provides airlines with an interface to their aircraft and a view into the data that it transmits. Typically an airline would use UpTime to monitor their fleet, communicate with the flight crew, review aircraft exceedances, etc. For the ecoDemonstrator program, the flight data streaming test team was able to activate and deactivate FDR streaming, monitor the ecoDemonstrator aircraft on an ASD (Aircraft Situational Display), view real-time FDM analysis of a flight, and use text messaging between the ground and an onboard iPad. The UpTime Cloud servers also act as the repository for all forwards and backwards streamed FDR data. At any time, during or post flight, Boeing test team had access to download any FDR files that had been streamed off the aircraft. FDR files were made available for download in one of three formats: • .A7 – a binary recording of all ARINC 717 data • .QAR - a binary recording of all ARINC 717, GNSS, and discrete data • .CSV – an export, in Engineering units, of the ARINC 717 and GNSS data The A7 and QAR formats are easily ingested by different FDM (Flight Data Monitoring) programs. They are binary files that contain the exact, bit for bit data that is stored on the aircraft FDR (Flight Data Recorder). UpTime Cloud also forwards the real-time transmitted FDR data to third parties. During the ecoDemonstrator trials, this FDR data was fed to the FDM provider, Flight Data Services, where the data was processed and made available in the UpTime Cloud GUI.
  18. 18. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 18 of 54 Third party FDM analysis UpTime Cloud also forwards the real-time transmitted FDR data to third parties. During the ecoDemonstrator trials, this FDR data was fed to Flight Data Services, a third party analysis provider, where the data was processed and made available in the UpTime Cloud GUI. After only a few seconds, data was received, the analysis process began, and information was available for users in the UpTime Cloud GUI. Figure 6: UpTime Cloud GUI Analysis Plots Typical latency between any event occurring on the aircraft, and that event being displayed in the FDM system, is between six and eight seconds. Included in the FDM analysis, and available to users in real-time are: • List of all Engineering Units from ARINC 717 data • Graphing tools to display Engineering Units • Tabular data showing Engineering Units • Graphical flight deck instrumentation display • Moving map • Aircraft animation • Ability to move forward and backward through a live streaming session
  19. 19. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 19 of 54 Figure 7: UpTime Cloud GUI Cockpit Display Figure 8: UpTime Cloud GUI Flight Path Simulation
  20. 20. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 20 of 54 Satellite Links Inmarsat Inmarsat provides both voice and data services through a series of geostationary satellites that cover the earth less the extreme Polar Regions. This network allows for very high data transmission rates and during the ecoDemonstrator trials rates up to 432 kbps (kilobits per second) were tested. Through Inmarsat the TCP/IP protocol was used to initiate a persistent connection between the AFIRS unit and the UpTime Cloud. Through this connection, a VPN was established, and FDR data was continuously transmitted. Different streaming contexts were evaluated which included dedicated transmission rates of 32, 128, 256 kbps and a Background context, where data transmissions are up to 432kbps on a shared bearer. Iridium The Iridium satellite network consists of 66 low earth orbiting satellites that provide global coverage including complete coverage at both poles. Both voice and data services are provided by the Iridium network. Different data transmission protocols are available when using the Iridium network, and for the ecoDemonstrator trials, SBD (Short Burst Data) was used. SBD allows for payloads up to 1960 bytes to be transmitted from the aircraft to the ground. Each payload is routed between satellites and downlinked to a ground station where it is passed on a public terrestrial network to the UpTime Cloud server. The SBD protocol does not allow for an uninterrupted stream of FDR data to be transmitted from an aircraft to the ground. Instead, for the trial, 30 seconds of FDR data was collected, packed and compressed, before transmission. Flight Test Setup The installation of the AFIRS228 and the communication peripherals that make up the TLDR system are described in this section. Equipment and Installation The connections made for this test are shown below in Figure 9. This diagram shows that AFIRS 228 received airplane data from the Flight Data Recorder (FDR), received GNSS data from the GPS/Iridium antenna, received and sent data through the GPS/Iridium antenna, received and sent c data transfer through the SDU and SATCOM System, received voice data from a cockpit microphone and command and control communication through EFB devices like a telephone, an iPad, and a Laptop.
  21. 21. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 21 of 54 Figure 9: AFIRS Installation and Flow Diagram AFIRS 228S The AFIRS 228 system provided by FLYHT is described in detail in Section 4.3.1.1. The test system was designed to meet the requirements of the inputs and outputs of this equipment with the additional limitations of the airplane configuration. For this reason, some data sources had to be adjusted. For example, airplane data was input directly from the FDR to the AFIRS. As shown in Figure 9, the installation was optimized for Flight Deck access by the addition of a Maintenance Panel. This provided a convenient access for the Flight Test engineer to connect the iPad, telephone, and maintenance laptop during testing. GPS/Iridium Antenna The existing configuration of the FedEx airplane did not allow for a location for an additional Iridium antenna to provide GNSS data to the AFIRS and to provide communication through Iridium network. To mitigate this, an existing GPS antenna was replaced with a GPS/Iridium antenna. Given the additional connector required for this installation, a unique antenna adapter plate was manufactured to prevent any penetration changes on the aircraft. AFIRS utilized the Iridium connection and a GPS system utilized the GPS connector in order to share the antenna location. This setup was tested in the Lab and ground tests proved it to provide sufficient RF transmitted and received signals. SDU and SATCOM System SATCOM uses a satellite network, ground stations, and airplane satellite communication equipment to transmit and receive data and voice messages. The ecoDemonstrator is equipped with the Inmarsat SwiftBroadband Service (Thales TopFlight ARINC 781 Aero-H+ and SBB). It is an IP-based upgrade from Swift64 with up to 432 kbps bandwidth per channel and is hosted on 1-4 satellite
  22. 22. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 22 of 54 constellation. The airplane SATCOM configuration and its connection to the AFIRS 228 are shown in Figure 10. Figure 10: SDU and SATCOM System The SDU Configuration Module (SCM) provides the SDU subscriber information for the SBB network. It also contains the ORT (Owner’s Requirement Table) database. This database allows the SATCOM system to automatically log on to the customer preferred Ground Earth Stations (GES) and allows the airline to have a custom telephone directory accessible via the flight deck Control and Display Unit (CDU). The SDU (Satellite Data Unit) generates the RF signals. It contains a high power amplifier that increases signal strength and offers connections for data/voice services. The DLNA (Diplexer/Low Noise Amplifier) connects transmit signals between the SDU and the antenna. It can filter separate transmit/receive RF signals. Control and Display Unit (CDU) One factor that determined the location of the GPS/Iridium antenna was the requirement to ensure that it was sufficiently separated from the aircraft High Gain SATCOM system to avoid any interference or damage to the AFIRS system. This was further mitigated during flight testing by developing a process to turn off the SATCOM system when the Iridium system was being used. This was done by entering LOGON and LOGOFF commands through the CDU in the Flight Deck. For a real implementation, such link management would be automated. Flight Data Recorder On a typical 777 installation, the Flight Data Recorder outputs data to an onboard network system where it is made available to other systems on the airplane. This particular airplane was not delivered with this network system and due to integration with other technologies on the airplane the AFIRS was connected directly to the ARINC 717 output from the FDR.
  23. 23. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 23 of 54 L3 Cockpit Area Microphone FLYHT Integrated an L3 DM-58 digital cockpit area microphone (CAM) used during these flight tests for recording ambient cockpit audio. It was installed on the overhead panel in the flight deck and connected to the AFIRS228 using ARINC 429 interface. The microphone was controlled through the maintenance interface of the AFIRS unit through the maintenance laptop. Flight Test Engineering Interfaces The FLYHT AFIRS System was setup to allow for several user interfaces for the Flight Test Engineer to use. This included an iPad which was used to send and receive texts with the ground analysts. This was used to show how the addition of texting did not have any effect on the system under test. Additionally, the Flight Test Engineer was able to use a telephone connected to the AFIRS system. This was used to make and received phone calls with the ground analyst. Phone calls were only applicable to test scenarios when the Iridium communication system was under test. For the purposes of providing the Flight Test Engineer with the capability to troubleshoot any issues encountered in flight, a “maintenance” laptop was used to gain access to the maintenance mode of the AFIRS. FLYHT provided the tools loaded on the laptop for this purpose. It is also used to turn the cockpit microphone ON/OFF due to the unique nature of this installation. In this way, the Flight Deck can obtain control of when this feature is available for recording. This was necessary for this test to protect the sensitivity of other ecoDemonstrator projects. Test Plan and Procedures Test conditions (outlined in Table 1) were designed to exercise the requirements for Autonomous Distress Tracking and Timely Recovery of Flight Data. During the planning stage of the program, certain conditions were identified and outlined to be scheduled in during the testing. These conditions included the use of the microphone, calling through the satellite phone, and flight conditions that the pilot would perform. It was also requested that the AFIRS system be allowed to operate as long as there was no interference with planned testing for the day. On those background days, the testing was mostly controlled from the ground side with some interaction from the onboard crew via the AFIRS iPad interface texting feature. To enable the flight crew and test personnel to know precisely when the cockpit area microphone will be on, the CAM was always enabled manually when included in the test condition. The CAM was activated using a four-step process. The Flight Test engineer and the ground personnel would coordinate the start of the audio testing. The Flight Test engineer would use the Maintenance Laptop to enable the system to record the audio input. Once the Flight Test engineer had made the change, the ground team would manually start the audio steam. When streaming is activated from the ground, a text or phone data transfer between the ground and the Flight Deck is required to announce CAM data recording. When a streaming event is detected, the system has 5 seconds to initiate data streaming transmission. Making use of the scenario concepts in paragraph 3.1.1, the test plan conditions in Table 1 were defined using trigger conditions to enable the flight data streaming. For testing with Iridium, the data stream consists of a limited data set chosen to provide critical information to enable the real-time animation.
  24. 24. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 24 of 54 Table 1: Test Conditions Condition ID Streaming Network FDR Streaming Mode CAM Audio Description / Process 100 Inmarsat Continuous Manually Triggered Continuous Transmission: Begin streaming FDR data for over 20 minutes. Since the data is transmitted continuously, there is no need to include 20 minutes of historical data. 200 Inmarsat Manually Triggered Manually Triggered Ground Command with Buffering: Trigger the FDR data stream and/or the CVR Audio manually. Ensure the minimum of 20 minutes of buffered data is included in the data stream. 300 Inmarsat Automatically Triggered Manually Triggered Automatically Triggered by one of the following: • Unusual Attitude / Excessive Bank - Execute a turn with a bank angle greater than 30 degrees and maintain for at least 2 seconds. • Unusual Attitude / Excessive Pitch – Execute a climb or decent at pitch angle greater than 15 degrees and maintain for at least 2 seconds. • Unusual Speed / Excessive Vertical Speed – Execute a climb or decent rate at greater than 4000 fpm and maintain for at least 3 seconds. 400 Iridium Manually Triggered N/A Communicate by phone or text to have the ground initiate a data streaming event. 401 Iridium Automatically Triggered N/A Automatically Triggered by one of the following: • Unusual Attitude / Excessive Bank - Execute a turn with a bank angle greater than 30 degrees and maintain for at least 2 seconds. • Unusual Attitude / Excessive Pitch – Execute a climb or decent at pitch angle greater than 15 degrees and maintain for at least 2 seconds. • Unusual Speed / Excessive Vertical Speed – Execute a climb or decent rate at greater than 4000 fpm and maintain for at least 3 seconds. Data Collection The test program ran from First Flight on March 1, 2018 through Last Flight on May 5, 2018. This project, TLDR, was operated as “Ride-Along”, meaning there were no dedicated flight hours or test conditions assigned to this project. The conditions were performed when the capacity of the flight testing allowed. During each flight day, the ground analysis team would monitor the flight via the UpTime application. Through the application the aircraft and the flight data from the FDR could be watched in real time and messages could be sent to the onboard iPad. During and after the flight, the data collected and
  25. 25. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 25 of 54 transmitted by the box could be seen and downloaded for further access. Periodically during the flight test the SD card on the AFIRS System was swapped and transferred along with the files retrieved from the FDR. The first day of testing, Conditions 200 (Manual FDR Streaming with triggers) and 300 (Automatic FDR Streaming with triggers) were exercised on the first flight and Condition 300 was exercised on the second flight. Details about each flight and the specific test conditions are shown in Appendix B where a table shows the date, condition, streaming metrics, and analyst comments for each test performed. Table 2 summarizes the flight test data collection. Table 2: Data Summary Inmarsat Iridium Total Flights 26 4 291 Flight Hours 63 17 80 Real-Time Streaming Sessions 44 13 57 Buffered Streaming Sessions 44 N/A 44 Hours of Automatically Triggered Streaming 40 7 47 Hours of Manually Triggered Streaming 21 10 31 Hours of Audio Streaming 1.5 N/A 1.5 1 There was a transition flight that started with Inmarsat and switched to Iridium. The conditions for the automatic triggers were set at very conservative values to ensure that they were met without having to request special maneuvers from the pilots. Because of this, there was almost consistently an automatic trigger event during departure. However, the automatic triggers could be silenced as needed for testing. Several test flight opportunities were missed due to either the system not being turned on or due to the system not being able to establish a connection with the INMARSAT system. In the case where the system was on, but could not stream the data out, the data from the flight was recorded the AFIRS228S LRU. In addition, several flights experienced dropouts in the AFIRS system’s connection to the Inmarsat network during flight. Troubleshooting the cause of failed network connection establishment and dropouts during a flight was outside the scope of the trial due to the “Ride-Along” status of the activity. It should be noted that during the drop outs, the AFIRS unit buffered data and continued to transmit when the network connection was re-established. It is expected that further optimization between the AFIRS unit and the Thales SDU interface would result in improvements. Test Results The following section describes the results obtained from the analysis of the five flights chosen for sampling. These flights represented a controlled environment where FLYHT could complete their
  26. 26. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 26 of 54 proof-of-concept measurements and show accordance with the relevant ICAO 10054 document requirements. Key Findings Table 3 presents key findings from the trials. Table 3: Key Findings FLYHT ecoDemonstrator Result ICAO 10054 Reference Successful encryption of all FDR data streamed from aircraft to secure UpTime Cloud server. 3.6.1 Successful transmission of streamed FDR data with average latency less than 5s from receipt of ARINC 717 data on the aircraft to storage in secure UpTime Cloud server. 3.6.3 Confirmation that streamed FDR data archived in UpTime Cloud server is a bit for bit match with the FDR data stored on the AFIRS unit. 3.6.3 and 3.6.4 Confirmation that FDR data compressed before transmission was successfully decompressed with no errors or data loss. 3.6.10 Verification that automated triggers successfully activated and deactivated FDR streaming. 3.6.13 Verification that manual triggers (through the UpTime Cloud GUI) successfully activated and deactivated FDR streaming. 3.6.4 Verification that FDR streaming triggered by an event can only be deactivated by the conclusion of that event. 3.6.5 Verification that after a distress event trigger, a minimum FDR streaming duration of 20 minutes was achieved. 3.6.5 Provided access for validated users to download streamed FDR data. 3.6.3 Successful feed to FDM software for live display of streamed FDR data. 3.6.11.1 Initiation of real-time and historical FDR streaming within 3 seconds of trigger detection. 3.6.13 Test Result Anomalies Several test flight opportunities were missed due to either the system not being turned on or due to the system not being able to establish a connection with the INMARSAT system. In the case where the system was on but it could not stream the data out, the data from the flight was recorded the AFIRS 228S LRU. In the case where it was not turned on, it was determined that this was the cause of miscommunication with the Boeing Test Team and power was not turned on to the equipment. In addition, several flights experienced dropouts in the AFIRS system’s connection to the Inmarsat network during flight. Troubleshooting the cause of failed network connection establishment and dropouts during a flight was limited due the other activities on of the EcoDemonstrator program. Basic troubleshooting indicated that further optimization between the AFIRS unit and the Thales SDU interface would likely result in improvements.
  27. 27. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 27 of 54 During the trial, link loss was experienced due to loss of line of sight to the satellite due to aircraft dynamics. While these losses were expected, in some cases, unusually large times elapsed before the link was recovered. This was unexpected and needs further study. Configuration, optimization, and performance base-lining of the installed Inmarsat System was out of scope for the trial. It should be noted during drop outs the AFIRS unit buffered data and continued to transmit when the network connection was re-established. Streamed FDR Data Integrity Tests Introduction Streamed FDR data is only of value if its integrity is maintained throughout the streaming process. The streamed FDR data must be a bit- for- bit match of the data as recorded on the aircraft Flight Data Recorder (ICAO 10054 calls for an error rate not greater than 1E-5 ). The AFIRS unit records to an internal CF card the ARINC 717, ARINC 429, discrete inputs, GNSS, and INU data during a flight. A subset consisting of all the ARINC 717, GNSS, and INU data was streamed during the ecoDemonstrator test trials. For the purpose of data integrity verification, FLYHT focused on the ARINC 717 data stream. This ARINC 717 data represents the identical information that is recorded to the Flight Data recorder on the aircraft. This is particularly important in consideration of initiatives such as TRFD (Timely Recover of Flight Data). Currently, there is no guarantee of timely flight data recovery. If the integrity of the live - streamed FDR data can be confirmed, there is potential for immediate recovery of data following an incident. On a typical B777 the Digital Flight Data Acquisition Function (DFDAF) provides both the Flight Data Recorder and the AFIRS unit with the identical ARINC 717 data stream. The purpose of our data integrity testing is to confirm that the final streamed FDR files stored in the UpTime Cloud database are a 100% match with the FDR data recorded on the AFIRS CF card,; and therefore, a 100% match with the files stored on the Flight Data Recorder. Figure 11: AFIRS and UpTime Cloud Data Flow Diagram
  28. 28. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 28 of 54 Test Process ARINC 717 data on the ecoDemonstrator is encoded at 1024 words per second (wps), i.e., 1024 * 12 bit words = 1536 bytes per second. It is received by the AFIRS and stored on an internal CF card for retrieval post flight. In parallel, the same data is processed on a second by second basis in preparation to be live streamed off the aircraft to the Inmarsat satellite network. This process involves packing and compressing each second of the ARINC 717 stream in a lossless manner. Before transmission via the Inmarsat network, a CRC (Cyclical Redundancy Check) is calculated against each second of payload. On the B777 the AFIRS is connected to a Thales SATCOM terminal through Ethernet. During the trials the Thales terminal was configured in one of four contexts: SBB: STREAM32K, SBB:STREAM64K, SBB:STREAM256K, or SBB:BACKGROUND when connecting to the Inmarsat satellite network. A VPN (Virtual Private Network) was established between the AFIRS unit and the UpTime Cloud servers through the Inmarsat satellite network to provide data encryption. VPNs use a tunneled connection and encapsulate the data during transmission (i.e., every data packet is placed inside another data packet before it is transmitted). VPNs also use security protocols to encrypt data (e.g. IPSec and OpenVPN). These protocols encrypt each encapsulated data packet’s contents with an encryption key used between the VPN’s server and clients along with a sub-protocol used to hide certain packet information, including the sender’s identity. Each second the ARINC 717 payload was transmitted through a TCP/IP connection to the UpTime cloud servers. At UpTime the streamed data was received, verified, decompressed, and archived. At this point, the CRC is recalculated and compared to the original value. On demand, the archived ARINC 717 data is compiled into a fully formed FDR file for download from the UpTime Cloud servers. These FDR files contain the identical ARINC 717 data that is stored on the AFIRS CF card and on the aircraft Flight Data Recorder. Data Verification As streamed FDR data is only of value if the integrity of the data is maintained, a specific tool was written to compare the streamed FDR data to the FDR data recorded on the AFIRS CF card. Validation was confirmed by identifying the first second of FDR data in a stream and matching it to the appropriate second of data in the corresponding CF recorded FDR file. From this point a bit for bit comparison was made until the end of the streamed data file. The ecoDemonstrator program required that forward and backward streaming from a trigger event be available. This process created two files, one from before and one after the trigger. For each streaming event, both the forward and backward streamed files were verified. The comparisons verified that the integrity of the streamed data was maintained throughout the transmission process from the aircraft to the archived streamed FDR files. Cost Considerations Cost is a critical consideration in any real-life technical implementation. For this capability, the triggered streaming events are expected to be rare events. Per the ED-237 triggering of flight data transmissions requirements, an actual distress triggered event should take place at a rate of less than 2x10^-5 per flight hour. The ability to provide potential distress triggers that are broader (and hence occurring potentially more frequently) than the ED-237 distress triggers is an important capability for taking a conservative approach to ensure that flight data is available when an actual distress event
  29. 29. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 29 of 54 occurs. It is expected that these pre-distress or potential distress triggers will be tailored by the operators to balance acceptable costs, system/network usage, added distress coverage and other considerations. For the capabilities demonstrated in this testing the per-triggered event data costs can be estimated from user’s data costs and the data streaming rate. Data rates during active streaming of ARINC 717 data are shown below in Table 4. Table 4: Summary of Data Usage ARINC 717 words / second bytes / second MB / minute MB / hour Minimum Streaming Context 64 96 0.00576 0.3456 8K 128 192 0.01152 0.6912 8K 256 384 0.02304 1.3824 8K 512 768 0.04608 2.7648 16K 1024 1536 0.09216 5.5296 32K In summary, the service costs for these capabilities are expected to be low because of the rareness of the triggering events and when one does occur the data costs incurred should be comparable to other services available over broadband safety services. In terms of cost/benefit, we expect the benefits of the near-real time availability of this data in a distress condition to far outweigh the potential costs. Summary of Integrity and Latency Analysis During the ecoDemonstrator program, 26 flights were flown, using the Inmarsat network, where one or more FDR streaming trials were conducted. Five flights (as shown in Table 5) were selected where FDR streamed content was analyzed for FLYHT’s proof-of-concept. Table 5: Summary of Flights with FDR Streamed Content The bit-by-bit comparison of these streamed FDR files to the FDR files recorded on the AFIRS unit verified that the integrity of the streamed data was maintained throughout the transmission process from the aircraft to the UpTime Cloud servers. Date and Time of Streaming Session (UTC) Total real-time streaming (s) Total buffered streaming (s) ORIG DEST Average latency for real-time streaming Data Integrity Check 1 5 Mar 2018 19:16:40 1932 1200 BFI BFI 3.065 +- 1s 100% 2 9 Mar 2018 18:02:37 1565 1200 BFI BFI 3.690 +- 1s 100% 3 19 Mar 2018 16:35:21 1430 1200 BFI BFI 3.371 +- 1s 100% 4 28 Mar 2018 21:54:11 1202 1200 BFI BFI 3.869 +- 1s 100% 5 12 Apr 2018 22:05:11 1202 1200 BFI BFI 2.955 +- 1s 100%
  30. 30. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 30 of 54 Data Latency Test Results Introduction In addition to data integrity, achieving reasonable data latency is crucial to real-time data monitoring. Data latency is the time between an event occurring on the aircraft and the time that event is stored securely in the UpTime Cloud database. In the context of the aircraft system, the DFDAF acquires various discrete, analog, and digital parameters from a number of sensors and avionics systems. It then takes the data and routes it to the Flight Data Recorder and in this case, also to the AFIRS unit. The AFIRS unit processes the data using its embedded software, and then sends it over the satellite network to the ground servers. The ground servers then decrypt and store the information in a raw format for airlines and investigators. Data Recovery A frequently asked question is when data can be considered “safe” in the context of TRFD (Timely Recovery of Flight Data). Safety Boards that provide accident investigations are concerned with how quickly (with relation to live events) data can be captured and “safe”. Using satellite transmission, we believe the data can be considered safe as soon as it has been transmitted from the antenna on the aircraft. This means that data is safe within seconds of it being captured, whereas with the current implementation, data recovery is dependent on location and recovery of the Flight Data Recorder. Timestamps Three timestamps of interest were captured during this trial. First, the AFIRS GPS timestamp: this is the timestamp, measured to the nearest second, and recorded when the data is received by the AFIRS unit (and the Flight Data Recorder) from DFDAF. The second timestamp is called Time Received at TCP/IP. This timestamp, measured to the nearest millisecond, is recorded when the data is received on the UpTime Cloud TCP/IP server. The third timestamp is the time the data is persisted. This is when the data has been written to the database and is considered stored and retrievable. This is measured to the nearest millisecond. Calculations and Results In the context of the above timestamps, there are two timeframes of interest. The first is the difference between the AFIRS GPS timestamp and the Time Received at TCP/IP server. This timeframe represents the time it takes the AFIRS unit to process the data, to package the data, and to send the data over the satellite to the ground server. The second time is the difference between the AFIRS GPS timestamp and the Time Persisted. This time represents the time that it took to process the data, to package the data, to send the data over the satellite to the ground server, and to store the data onto the UpTime Cloud server. This timestamp reflects the amount of time it takes for the data to be ready for consumption – i.e., data is ready to be viewed on the webpage and ready for download. Over the course of 50 plus streaming events, including the five streaming events that were used for detailed analysis, the average time between receipt at the UpTime Cloud TCP/IP server and AFIRS GPS time of a recorded event was under 3.5 seconds. The average additional time to store the data and have it ready for download was less than 0.3 seconds. On average, any data that is stored on the FDR is available for consumption on the ground between six to eight seconds.
  31. 31. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 31 of 54 It should be noted that during some of the FDR streaming trials, Cockpit Area Microphone (CAM) streaming was occurring concurrently. The additional payload of the CAM streaming had no impact on the latency of the streamed FDR data. Iridium Testing Introduction In addition to the Inmarsat FDR streaming trials, FLYHT had the opportunity to perform tests of streaming a subset of the ARINC 717 parameters over the Iridium network. Three complete flights were dedicated to the Iridium streaming testing. The test setup involved the proof-of-concept installation used for FDR streaming, but the Inmarsat Thales terminal was disconnected. A single AFIRS configuration change allowed the AFIRS unit to transmit over the Iridium network using the SBD (Short Burst Data) protocol. Due to limited bandwidth of the Iridium network, a subset of the ARINC 717 data, used for supporting dynamic visualization of the aircraft including position, attitude and rate data, was selected for transmission. Test Process The testing for Iridium was the same as previously described for FDR streaming over the Inmarsat network. Throughput of the Iridium SBD protocol is significantly less than that tested on the Inmarsat SBB network. As such, the ARINC 717 payload transmitted over Iridium was reduced. Instead of transmitting all 1024 ARINC 717 words, a subset was selected. Each SBD payload consisted of 30 ARINC 717 words and select GNSS data recorded each second, for 30 seconds. Content of the payload was compressed before transmission as a single SBD packet to the Uptime Cloud. On receipt at UpTime, the payload was decompressed and archived as raw ARINC 717 data. Authorized users were able to download a properly formed FDR file that contained the transmitted ARINC 717 words. These FDR files contained only the subset of ARINC 717 data, but could be used to produce analysis and animations in the same way as a fully populated FDR file. The only difference being that the analysis and animations would be based on a subset of the 1024 ARINC 717 words. Iridium Streaming Results The Iridium FDR streaming results were based on the data collected from three flights. The analysis of the subset of streamed FDR data showed that data integrity was maintained through the compression, transmission, and archiving process. The Iridium streamed FDR file was loaded into the FDM analysis tools on the UpTime Cloud with the difference between the two satellite networks being the Iridium stream only displayed the subset of transmitted FDR data. Iridium SBD payload transmissions of this size typically took 12 to 15 seconds to transmit from the aircraft to the UpTime Cloud. As 30 seconds of FDR data was collected in each payload, a total average latency of approximately 30 seconds was achieved between the ARINC 717 data being recorded on the AFIRS unit and archiving in the UpTime Cloud.
  32. 32. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 32 of 54 Cockpit Area Microphone Testing Introduction A CAM was installed on the flight deck of the ecoDemonstrator to record the ambient audio environment of the cockpit. The CAM recordings were encoded in an ARINC 429 stream and archived on the internal AFIRS CF card. All CAM recordings were buffered on the AFIRS unit in a 20 minute loop that allowed for the buffered audio, along with the real-time audio, to be streamed from the aircraft. Only 20 minutes of buffered audio was kept on the aircraft at any time. The CAM audio was embedded in an ARINC 429 stream using ADPCM (Adaptive Differential Pulse Code Modulation) which allowed for efficient digital encoding of the analog signal. This encoding scheme and the CAM selected for the trials provided an ED-112A complaint environment for the ecoDemonstrator trials. While efficient and lossless, the ADPCM encoding produces a very large payload relative to the ARINC 717 data that is transmitted during the FDR streaming. For security reasons, the CAM was installed on the ecoDemonstrator, but was not configured or powered for most flights. Only when coordinated between the Boeing test team and FLYHT personnel, was the CAM powered, and then configured for testing. This modification to the proof-of- concept installation was to be performed inflight when the all parties agreed that a test could be run. Taking into account the difficult coordination and configuration effort for each CAM streaming test, FLYHT was only able to test this functionality on three flights. Of the three flights, only two tests were initiated where 20 minutes of buffered audio had been recorded in advance of the CAM streaming test. Test Process The CAM audio streaming from the ecoDemonstrator was only configured to be initiated by a ground user. Automated triggers could have been used to initiate the audio streaming, but due to the sensitive nature of the audio streaming it was decided that only through coordination of the airborne Boeing test team and the FLYHT team was streaming to be initiated. One audio streaming session was dedicated to real-time streaming with no buffered audio transmitted. Even considering the efficient encoding of the real-time audio stream, a minimum SBB streaming context of STREAM128K was required. This dedicated 128kbps throughput allowed for the audio to be transmitted in real-time. At the UpTime Cloud server dedicated to testing the audio stream, the ARINC 429 data was received, archived, and formed back to an audio file for near real-time playback. The real-time audio could be accessed by authorized users for playback during the flight. The ARINC 429 data representing the audio was received and archived at the UpTime Cloud servers in a timeframe similar to the streamed FDR data. Reconstruction of the audio data into a file for playback required several seconds of audio data to be available. This resulted in an audio playback latency of some 30 seconds and prevented coordinated playback between the audio and the FDR data as viewed in the analysis and animation tools. A second and third audio streaming test was executed to validate that the buffered audio and real- time audio streaming could be maintained while also maintaining the real-time FDR streaming. This test successfully demonstrated that both buffered and real-time audio streaming did not interfere with the real-time FDR streaming.
  33. 33. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 33 of 54 Cockpit Area Microphone Streaming Results Real-time and buffered CAM audio streaming was a secondary objective on the ecoDemonstrator flights and the required coordination between Boeing Flight Test engineers and FLYHT personnel made the testing difficult. Despite the challenges of initiating these tests the results are very promising. When a sufficiently large dedicated streaming context is used on the Inmarsat network, the ARINC 429 data was successfully transmitted and received at the UpTime Cloud server. The resultant audio files, both buffered and real-time were successfully created and made available for playback. The success of this limited testing is very encouraging for future development of this CAM streaming technology. Future Considerations, Conclusions, and Recommendations As technology continues to improve, data transmission costs continue to decrease. Currently, using the sample SwiftBroadband usage costs, we can show that background mode is a very cost-effective solution for timely recovery of flight data. Even in incidents where the aircraft data can be located, the data streamed off the AFIRS unit can provide a head start in accident investigation or even accident mitigation and recovery. Network Performance and Robustness The trial focused on the application of data acquisition (FDR and Audio) and transmission as a system over Inmarsat and Iridium networks. Anomalies in transport availability during the trial were not root caused. It is hypothesized that further integration between the AFIRS unit and the Thales SDU network interfaces would improve robustness. Future work is needed to characterize the long-term performance and robustness of the satellite network connection in all phases of flight including unusual attitudes. Conclusions and Recommendations The trial has shown that existing, commercially available equipment and network services (FLYHT’s AFIRS paired with an Inmarsat SwiftBroadband system) are suitable for providing distress flight data streaming capabilities that support the ICAO objectives. The trial concludes that Inmarsat SwiftBroadband provided excellent capability for data and voice streaming that supports the ICAO document 10054 recommendations. Additional study and solution hardening are needed to demonstrate robustness in commercial operation; however, it is the recommendation of the trial team that this technology is worthy of further development and trials in a commercial setting. Core findings include: 1. Capability of current equipment (with suitable modifications) to provide distress flight data streaming capabilities that support the ICAO objectives. 2. Excellent capability of broadband safety services to support data and voice streaming that supports the ICAO document 10054 recommendations.
  34. 34. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 34 of 54 3. That even limited bandwidth options such as the Iridium SBD services used in these tests can provide a useful flight data streaming capability. In this case it was to stream sufficient aircraft dynamics parameters to allow near real time display and analysis of the aircraft trajectory and flight dynamics.
  35. 35. Revision NEW Page 35 of 54 Appendix A ICAO References A.1 Amendment 40-A to ICAO Annex 6, Part I, § 6.18; Appendix 9; and Attachment K (referring to Autonomous Distress Tracking and Post Flight Localization of an Aircraft) 6.18 LOCATION OF AN AEROPLANE IN DISTRESS 6.18.1 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. 6.18.2 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. 6.18.3 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 4.2.1.3.1 for operator responsibilities when using third parties. -//- APPENDIX 9. LOCATION OF AN AEROPLANE IN DISTRESS (Chapter 6, 6.18, refers) 1. PURPOSE AND SCOPE Location of an aeroplane in distress aims at establishing, to a reasonable extent, the location of an accident site within a 6 NM radius. 2. OPERATION 2.1 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. 2.2 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.
  36. 36. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 36 of 54 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. 2.3 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. 2.4 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. 2.5 When autonomous transmission of position information has been activated, it shall only be able to be deactivated using the same mechanism that activated it. 2.6 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. (Click here to access the TTFDWG Report under the “publications” tab or go to https://www.bea.aero/en/.) 1.2 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 2 300 km2, equivalent to a radius of 14 NM, will be able to be searched before the ULD battery degrades.
  37. 37. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 37 of 54 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 2.1 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. 2.2 Emergency locator transmitter (ELT): The current generation of ELTs were designed to provide the position of impact for a survivable accident. The next generation of ELTs may have the capability to activate a transmission in flight when any of the conditions detailed in EUROCAE ED-237, Minimum Aviation System Performance Specification (MASPS) for Criteria to Detect In-Flight Aircraft Distress Events to Trigger Transmission of Flight Information are met. When an ELT sinks below the surface of water, its signal is not detectable. 2.3 Automatic deployable flight recorder (ADFR): The purpose of an ADFR is to have flight recorder data available soon after an accident, in particular for accidents over water. The integrated ELT provides for both locating the accident site for accident investigation and search and rescue purposes. Being floatable, it will assist in locating the accident site by providing an ELT signal when the wreckage sinks below the surface of the water. It also ensures redundancy for one ELT. 2.4 Underwater locator device (ULD): A ULD operating at a frequency of 8.8 kHz is attached to the airframe to locate aeroplane wreckage below the surface of water when an ELT signal is not possible to detect. The ULDs operating at 37.5 kHz are attached to the flight recorders and are used for locating the flight recorders under water. 3. EQUIPAGE COMPLIANCE The advancement of technology has made it possible to meet the equipage requirements by different means. Table K-1 below provides examples of compliance. In such potential installations, the cost will be minimized and the effectiveness of the current installation improved. Table K-1. Examples of compliance Current After 1 January 2021 In-service Application for type certification is submitted to a Contracting State Two ELTs Two fixed recorders Example: A system from which a position can be determined; and one ADFR with an integrated ELT; and one combined recorder; Or A system from which a position can be determined and one ELT and two fixed recorders and an additional means to retrieve flight recorder data in a timely manner. Note.― A system from which a position can be determined and used to comply with Chapter 6, 6.18, may replace one of the ELTs required by Chapter 6, 6.17.
  38. 38. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 38 of 54 A.2 Amendment 40-A to ICAO Annex 6, Part I, § 6.18; Appendix 9; and Attachment K (Post Flight Localization of an Aircraft and ELT equipage) 6.17 EMERGENCY LOCATOR TRANSMITTER (ELT) 6.17.1 Recommendation.— All aeroplanes should carry an automatic ELT. 6.17.2 Except as provided for in 6.17.3, all aeroplanes authorized to carry more than 19 passengers shall be equipped with at least one automatic ELT or two ELTs of any type. 6.17.3 All aeroplanes authorized to carry more than 19 passengers for which the individual certificate of airworthiness is first issued after 1 July 2008 shall be equipped with either: a) at least two ELTs, one of which shall be automatic; or b) at least one ELT and a capability that meets the requirements of 6.18. Note.— In the case where the requirements for 6.18 are met by another system no automatic ELT is required. 6.17.4 Except as provided for in 6.17.5, all aeroplanes authorized to carry 19 passengers or less shall be equipped with at least one ELT of any type. 6.17.5 All aeroplanes authorized to carry 19 passengers or less for which the individual certificate of airworthiness is first issued after 1 July 2008 shall be equipped with at least one automatic ELT. A.3 Amendment 40-A to Annex 6 – ICAO – Flight Recorder Data Recovery 6.3.5 Flight Recorder Data Recovery 6.3.5.1 All aeroplanes of a maximum certificated take-off mass of over 27 000 kg and authorized to carry more than nineteen passengers for which the application for type certification is submitted to a Contracting State on or after 1 January 2021, shall be equipped with a means approved by the State of the Operator, to recover flight recorder data and make it available in a timely manner. 6.3.5.2 In approving the means to make flight recorder data available in a timely manner, the State of the Operator shall take into account the following: a) the capabilities of the operator; b) overall capability of the aeroplane and its systems as certified by the State of Design; c) the reliability of the means to recover the appropriate CVR channels and appropriate FDR data; and d) specific mitigation measures. Note.— Guidance on approving the means to make flight recorder data available in a timely manner is contained in the Manual on Location of Aircraft in Distress and Flight Recorder Data Recovery (Doc 10054). A.4 Applicable FDR Standards and recommendations in ICAO Annex 6, Part I, considering Timely Recovery of Flight Data Recorder Chapter 6
  39. 39. Analysis of Flight Data Streaming Trials on the Boeing 2018 ecoDemonstrator Revision NEW Page 39 of 54 6.3.1.2.11 All aeroplanes of a maximum certificated take-off mass of over 5 700 kg for which the individual certificate of airworthiness is first issued after 1 January 2005 shall be equipped with a Type IA FDR. Appendix 8 2.2.1 Flight data recorders shall be classified as Type I, Type IA, Type II and Type IIA depending upon the number of parameters to be recorded and the duration required for retention of the recorded information. 2.2.2 The parameters that satisfy the requirements for FDRs are listed in the paragraphs below. The number of parameters to be recorded shall depend on aeroplane complexity. The parameters without an asterisk (*) are mandatory parameters which shall be recorded regardless of aeroplane complexity. In addition, the parameters designated by an asterisk (*) shall be recorded if an information data source for the parameter is used by aeroplane systems or the flight crew to operate the aeroplane. However, other parameters may be substituted with due regard to the aeroplane type and the characteristics of the recording equipment. 2.2.2.6 Type IA FDR. This FDR shall be capable of recording, as appropriate to the aeroplane, at least the 78 parameters in Table A8-1. Table A8-1. Parameter Guidance for Crash Protected Flight Data Recorders

×