Contenu connexe


Enhanced Flight Operations Data Exchange using ATA Spec 2300

  1. ATA e-Business Forum Bill Cunningham Boeing Flight Operations Digital Data Lead Bruno Chatel Chadocs Consultant
  2.  Each OEM delivers Flight Operations data using proprietary formats ◦ May differ from one airplane program to another program for an OEM ◦ Mix of structured and unstructured formats  XML, SGML  Published data (e.g. PDF) ◦ Proprietary data models…  …and tools ◦ No shared basic concepts
  3.  Need specific/separate systems to manage Flight Operations data for each OEM/program  OEM manuals ◦ Airlines often need to customized OEM manuals ◦ Airline also publish in-house manuals (SOPs) that often cross or combine fleets from multiple OEMs  Airline manuals may require specific airline proprietary formats/tools  Configuration management and other transversal requirements : no opportunity to use same level or technology  Industry publishing solutions providers can convert multiple OEM FO data into a single structure, but this is costly and often involves compromise  Mixed fleet  High cost
  4.  Receive data from OEM ◦ Fleet manual  Calculation of revision impacts  Add Airline customized data  Publication ◦ Fleet manual ◦ A/C manual (single-tail)  Deliver to crews ◦ Onboard : EFB, Paper ◦ On-Ground: Paper, Computers, Tablets, Intranet  Training  A standard exchange model for Flight Operations data will allow airlines complete all these tasks with a single system.
  5.  What is it ? ◦ Common vocabulary ◦ Common data model ◦ Common data types and data organization framework ◦ Common exchange package technology (based on XML) ◦ Each data provider uses the same language to deliver FO data  What it is not ! ◦ No standardized manual organization ◦ No standardized authoring philosophy, constraints ◦ No standardized content ! ◦ No standardized publication process ◦ No standardized style sheets
  6.  What do we deliver: Flight Operations data types, manuals ◦ Data-centric approach  Data modules are marked-up based on the content, not the organization of the manual ◦ Additional data definitions are provided to organize and publish DM into logic documents
  7.  Flight Operations data will be delivered as a set of XML files ◦ Data Modules  Technical content  DM Status ◦ Publication Modules  Organization for Publication  PM Status ◦ Data management XML documents  External objects, such as graphics and multimedia are delivered as separate files and referenced in the technical content DMs
  8.  Separate XML fragments  Status => metadata related to content ◦ Applicability ◦ Revision data ◦ Metadata (approval/subset info, tdm, qualifications, policy references, data owner…)  Different lifecycles  Opportunity to exchange only status or content separately (incremental delivery)
  9.  Provisions for complete or incremental exchange  Revision data ◦ Status Information  New, Changed, Applicability change, Unchanged ◦ Reason for update  Technical or Editorial  Deleted, Moved, Textual content ◦ Revision marks  Add, Modify, Move, Move and Modify  Revision data is delivered in the DM Status XML Fragment
  10.  ACT, PCT, CCT : cross reference tables ◦ Based on S1000D ◦ Defines the products (aircraft table) and the conditions (list of Airplane Modifications/Service Bulletins)  Applicability statements ◦ Statement that gives the applicability for 1 DM or a specific element  Which products (aircraft), with conditions or not ?  If needed, associated with a formula of technical criteria ◦ In the DM status  Can define inline applicability (using XPATH to address the element in content)  Container/alternates ◦ Different DMs of the same subject for different configurations (applicability) are called alternates ◦ Alternates are grouped in “interface” DM called container.
  11.  General purpose ◦ Repositories allowing data factorization, provided as data modules  Repository types ◦ Glossary  Set of definitions for abbreviations referenced in content ◦ Qualifier (dispatch, avionic contexts)  Business qualification of content such as  Impacts on performance of a dispatch condition  Limitations on landing capabilities due to a dispatch condition  Code of data received from avionics systems allowing to index an alert for a procedure ◦ Link target summary  Set of resolved links targets information  Allows resolution of links to data outside of an exchange package
  12.  Are found in the spec : ◦ Information Layers  Three layers are available – Need to Know, Nice to Know, Expert Knowledge ◦ TDM  Temporary data module ◦ Major event  High priority for a set of data ◦ External applications  Opportunity to reference external applications (such as Performance applications) from the content ◦ Subset  Identification of a set of data modules, part of a bulletin (OEB, OMB) ◦ Metadata related to a DM  Phase of flight, crew qualification, policy references, data owner
  13.  An exchange package is composed of a set of objects ◦ DM (content and status), PM (content and status), External objects (graphics & multimedia)  The Exchange Package Status List provides ◦ the package content, with related status ◦ the list of deleted resources  Delivery can be Complete or incremental ◦ Only changed resources are delivered
  14. Common Exchange Interface ATA 2300 OEM A Exchange Pack A/C Program X Exchange Pack A/C Program Y OEM B Exchange Pack A/C Program Z Airline Revision impacts Customization environment Data model Configuration management Publication tools Mixed fleet but… + Single data format + Single environment On ground Consultation tool EFB EFB EFB
  15.  Version 2011.2  Spec + XML Schemas  All business requirements for FCOM, MMEL, DDG, AFM, QRH  Developed by FOIG ◦ OEM participants ◦ ATA e-Business Program ◦ Airline participants ◦ XML publishing industry vendor participants and consultants
  16.  The group holds quarterly face-to-face meetings  Web and phone conferences are held regularly to monitor and progress the work between face-to-face meetings  Members are assigned action items to work between meetings  New participants are needed and always welcome!
  17.  2012/2013 : consolidation, proof of concepts ◦ General analysis of all data types ◦ New requirements ◦ Schema Simplification and Consolidation ◦ Spec rewriting/reorganization ◦ Planning for the Future
  18. Questions? Thank you for attending our session!