ARINC 657-2009 AIRBORNE RECORDER FILE FORMAT《空运记录文件格式》.pdf

《ARINC 657-2009 AIRBORNE RECORDER FILE FORMAT《空运记录文件格式》.pdf》由会员分享，可在线阅读，更多相关《ARINC 657-2009 AIRBORNE RECORDER FILE FORMAT《空运记录文件格式》.pdf（32页珍藏版）》请在麦多课文档分享上搜索。

1、 AN DOCUMENT Prepared by AEEC Published by AERONAUTICAL RADIO, INC. 2551 RIVA ROAD, ANNAPOLIS, MARYLAND 21401-7435 AIRBORNE RECORDER FILE FORMAT ARINC SPECIFICATION 657 PUBLISHED: February 9, 2009 This document is published information as defined by 15 CFR Section 734.7 of the Export Administration

2、Regulations (EAR). As publicly available technology under 15 CFR 74.3(b)(3), it is not subject to the EAR and does not have an ECCN. It may be exported without an export license. DISCLAIMER THIS DOCUMENT IS BASED ON MATERIAL SUBMITTED BY VARIOUS PARTICIPANTS DURING THE DRAFTING PROCESS. NEITHER AEEC

3、, AMC, FSEMC NOR ARINC HAS MADE ANY DETERMINATION WHETHER THESE MATERIALS COULD BE SUBJECT TO VALID CLAI MS OF P ATENT, COPYRIG HT OR OT HER PRO PRIETARY RIGHTS BY THIRD PARTIES, A ND NO RE PRESENTATION OR WARRANTY, E XPRESS O R IMPLIED, IS MADE IN THIS REGARD. ARINC I NDUSTRY ACT IVITIES US ES RE A

4、SONABLE E FFORTS TO DEVELOP A ND MAINTAIN THESE DOCUMENTS. HOWEVER, NO CERTIFICATION OR WARRANTY IS MADE AS TO THE TECHNICAL ACCURACY OR SUFFICIENCY OF THE DOCUMENTS, THE ADEQ UACY, MERCHANT ABILITY, FITNESS FOR INT ENDED PURPOSE OR SAFETY OF A NY PRODUCTS, COMPONENTS, OR S YSTEMS DESIGNED, TESTED,

5、RATED, INSTALLED OR OPERATED IN ACCORDANCE WITH ANY ASPECT OF THIS DOCUMENT OR T HE ABSENCE OF RI SK OR HAZARD ASSOCIATED WITH SUCH PRODUCTS, COMPO NENTS, OR S YSTEMS. T HE USER OF T HIS DO CUMENT ACKNOWLEDGES THAT IT SHALL BE SOLELY RESPONSIBLE FOR ANY LOSS, CLAIM OR DAMAGE THAT IT MAY INCUR IN CON

6、NECTION WITH ITS USE OF OR RELIANCE ON T HIS DOCUMENT, AND SHALL HOLD ARINC, AEEC, AMC, F SEMC AND ANY PARTY THAT PARTICIPATED IN THE DRAFTING OF THE DOCUMENT HARMLESS AGAINST ANY CLAIM ARISING FROM ITS USE OF THE STANDARD. THE USE IN THIS DOCUMENT OF AN Y TERM, SUCH AS SHALL OR MUST, IS NOT INTENDE

7、D T O AFFECT THE ST ATUS OF T HIS DOCUME NT AS A VOLUNT ARY STANDARD OR IN ANY WAY T O MODI FY T HE ABOVE DIS CLAIMER. NOT HING HEREIN SHA LL BE DE EMED T O REQUIRE A NY P ROVIDER OF EQUIP MENT TO INCORPORATE ANY ELEMENT OF THIS STANDARD IN ITS PRODUCT. HOWEVER, VENDORS WHICH REPRESENT THAT THEIR PR

8、ODUCTS ARE COMPLIANT WITH THIS STANDARD SHALL BE DEEMED ALSO TO HAVE REPRESENTED THAT THEIR PRODUCTS CONTAIN OR CONFORM TO THE FEATURES THAT ARE DESCRIBED AS MUST OR SHALL IN THE STANDARD. ANY USE O F OR RE LIANCE ON T HIS DO CUMENT SHALL CONSTITUTE A N ACCEPTANCE THEREOF “AS IS” AND BE SUBJECT TO T

9、HIS DISCLAIMER. 2009 BY AERONAUTICAL RADIO, INC. 2551 RIVA ROAD ANNAPOLIS, MARYLAND 21401-7435 USA Prepared by the AEEC Specification 657 Adopted by the AEEC Executive Committee October 21, 2008 A description of the changes introduced by each supplement is included on Goldenrod paper at the end of t

10、his document. ARINC SPECIFICATION 657 AIRBORNE RECEORDER FILE FORMAT Published: February 9, 2009ii FOREWORD Aeronautical Radio, Inc., the AEEC, and ARINC Standards ARINC organizes aviation industry committees and participates in related industry activities that benefit aviation at large by providing

11、 technical leadership and guidance. These activities directly support aviation industry goals: promote safety, efficiency, regularity, and cost-effectiveness in aircraft operations. ARINC Industry Activities organizes and provides the secretariat for international aviation organizations (AEEC, AMC,

12、FSEMC) which coordinate the work of aviation industry technical professionals and lead the development of technical standards for airborne electronic equipment, aircraft maintenance equipment and practices and flight simulator equipment and used in commercial, military, and business aviation. The AE

13、EC, AMC, and FSEMC develop consensus-based, voluntary standards that are published by ARINC and are known as ARINC Standards. The use of ARINC Standards results in substantial benefits to the aviation industry by allowing avionics interchangeability and commonality and reducing avionics cost by prom

14、oting competition. There are three classes of ARINC Standards: a) ARINC Characteristics Define the form, fit, function, and interfaces of avionics and other airline electronic equipment. ARINC Characteristics indicate to prospective manufacturers of airline electronic equipment the considered and co

15、ordinated opinion of the airline technical community concerning the requisites of new equipment including standardized physical and electrical characteristics to foster interchangeability and competition. b) ARINC Specifications Are principally used to define either the physical packaging or mountin

16、g of avionics equipment, data communication standards, or a high-level computer language. c) ARINC Reports Provide guidelines or general information found by the airlines to be good practices, often related to avionics maintenance and support. The release of an ARINC Standard does not obligate any o

17、rganization or ARINC to purchase equipment so described, nor does it establish or indicate recognition or the existence of an operational requirement for such equipment, nor does it constitute endorsement of any manufacturers product designed or built to meet the ARINC Standard. In order to facilita

18、te the continuous product improvement of this ARINC Standard, two items are included in the back of this volume: An Errata Report solicits any corrections to the text or diagrams in this ARINC Standard. An ARINC IA Project Initiation/Modification (APIM) form solicits any recommendations for addition

19、 of substantive material to this volume which would be the subject of a new Supplement. ARINC SPECIFICATION 657 TABLE OF CONTENTS 1.0 . 1 INTRODUCTION1.1 1 Purpose/Scope1.2 . 2 Background1.3 2 Overview1.4 . 2 Related Documents1.4.1 2 ARINC Characteristics 573, 717, 747, 757, and 7671.4.2 2 ARINC Spe

20、cification 647A2.0 3 FILE FORMAT CHARACTERISTICS2.1 . 3 Architecture2.1.1 3 Block Diagram2.1.2 3 Characteristics2.2 . 4 Tagged Object2.2.1 . 5 Compound Objects2.2.2 . 5 Header Objects2.2.2.1 5 Labeled Fields2.2.2.1.1 . 5 Universal Labeled Fields2.2.3 . 6 Data Objects2.2.4 . 6 Filler Object3.0 . 7 SP

21、ECIFICATIONS3.1 . 7 Object Types3.2 . 7 Object3.2.1 . 7 Object3.2.1.1 7 RSO Header Labeled Fields3.2.1.2 9 Content3.2.2 10 Generic Object3.2.2.1 . 10 Generic Object3.2.2.1.1 . 10 File Header Labeled Fields3.2.2.1.2 11 Content3.2.2.2 12 Generic Object3.2.2.2.1 12 Generic Object3.2.2.2.1.1 12 Session

22、Header Labeled Fields3.2.2.2.2 13 Generic Object3.2.3 14 Object3.2.3.1 14 Content3.2.3.2 14 Content3.2.4 . 14 Object3.2.4.1 14 Content3.2.4.2 15 Content3.2.5 . 15 Object3.2.5.1 15 Content3.2.5.2 15 Content3.2.6 . 15 Object3.2.6.1 15 Content3.2.6.2 16 Content3.2.7 17 Object3.2.7.1 17 Content3.2.7.2 1

23、7 Content3.2.8 18 Object3.2.8.1 18 Content3.2.8.2 18 ContentARINC SPECIFICATION 657 TABLE OF CONTENTS ATTACHMENTS 1 Hex Code Table. 19 APENDICES A Glossary 20 ARINC SPECIFICATION 657 Page 1 1.0 INTRODUCTION 1.0 INTRODUCTION 1.1 Purpose/Scope This document defines the characteristics necessary to sta

24、ndardize the airborne recorder download file format in order to facilitate data import, transcription, and exchange. A standardized data format will reduce the variety of readout equipment required for airborne recorder data transcription. This document defines the detailed architecture of the Recor

25、der Standard Output (RSO) file. The architecture is a tagged file structure within which many different files and their formats can be supported. The structure is necessary to support newer recording requirements for flight data, data link, audio, and image recording. This structure is intended for

26、use with all civil recorders and should support use with military recorders. The RSO file is typically created by one of several methods: directly within the recorder downloaded raw data converted to an RSO file by a function configured to communicate with the recorder data converted to an RSO by po

27、st-processing software (e.g., a subset of data extracted from a larger file) Internal FRED FileRaw Recorder DataExternalFRED FileRecorderRSOAUDIODLINKIMAGEDATAFREDUSERDownloader FunctionAnalysisSoftwareProcessedDataPost ProcessingThe Figure below shows a conceptual diagram of the file interchange pr

28、ocess. ARINC SPECIFICATION 657 Page 2 1.0 INTRODUCTION 1.2 Background Recorder manufacturer and third-party software packages provide downloaded data in a variety of formats. These formats can include raw unpacked, packed, and compressed and each type can be adapted to include headers or other infor

29、mation creating additional variations. Currently, if a data file is received without any relevant associated information, it is a time consuming process to try and identify the data format and decode the file. Also, several different software packages may be needed to recognize and convert the data

30、into a format an analyst can use when exchanging the data. A standardized data format would allow instant import of the data file, and is consistent with having a standardized documentation file format, as described by ARINC Specification 647A: Flight Recorder Electronic Documentation (FRED). 1.3 Ov

31、erview The RSO is a file format intended for use as an interchange medium for flight recorder products. The file extension .rso shall be used for an RSO file. Files in this format typically contain downloaded data from more than one recorder memory, and may contain data not intended for some target

32、applications. Intended uses include interchange of the following data types: Flight Data FRED Data Link Audio Image User Specified (e.g., Rotor Speed, Universal Time Coordinated (UTC), Fault Logs) Definitions for image, audio, data link, flight data, and FRED have been included or reserved. The arch

33、itecture of the RSO also allows for future growth. By design, the RSO could be expanded to contain any kind of file. 1.4 Related Documents 1.4.1 ARINC Characteristics 573, 717, 747, 757, and 767 ARINC Characteristics 573 and 717 describe equipment and installation standards for a flight data recordi

34、ng system. Both systems use essentially the same Flight Data Recorder (FDR). ARINC Characteristic 747 describes an FDR, which is interchangeable with the FDR described in ARINC Characteristics 573 and 717. ARINC Characteristic 757 describes a Cockpit Voice Recorder (CVR) with provisions for data. AR

35、INC Characteristic 767 describes an Enhanced Airborne Flight Recorder (EAFR). 1.4.2 ARINC Specification 647A ARINC Specification 647A: Flight Recorder Electronic Documentation (FRED) defines the content and format of electronic files which document the information stored in an FDR or an EAFR.ARINC S

36、PECIFICATION 657 Page 3 2.0 FILE FORMAT CHARACTERISTICS 2.0 FILE FORMAT CHARACTERISTICS 2.1 Architecture The RSO is a generic tagged file structure that can support different files and their formats. It is similar to, but not exactly like, the Resource Interchange File Format (RIFF) model supported

37、jointly by IBM Corporation and Microsoft Corporation, for use with multimedia data. Like the RIFF model, the RSO uses a tagged file structure. File formats used within the RSO model should be approved by the AEEC Digital Flight Data Recorder (DFDR) Subcommittee in order to become part of the support

38、ed standard. 2.1.1 Block Diagram Figure 2-1 illustrates the hierarchical architecture of an RSO file. This example shows a single object containing two objects. The first of these objects shows a file with two separate sessions that could be for flight data , data link , audio , or image . The secon

39、d shows a file without sessions such as a FRED file. IDSIZEIDSIZEIDSIZEDATAIDSIZEDATAIDSIZEDATAIDSIZEDATAIDSIZEDATAIDSIZEDATAIDSIZEDATAIDSIZEIDSIZEDATAIDSIZEDATAIDSIZEDATAFigure 2-1 Hierarchical Architecture 2.1.2 Characteristics An RSO file is constructed of tagged objects. A tagged object consists

40、 of an identification tag, a size of the payload in bytes, and a payload. Any program reading an RSO file and not understanding an objects tag can skip to the next object on the same level. Thus, if an RSO file included both audio and flight data, an application interested in the audio could ignore

41、the flight data. To make an RSO easier to examine with a hex dump utility, every tagged object in an RSO, except a object, should begin on a 16-byte boundary. This is accomplished by inserting objects after objects that do not end on such a boundary. Size values are stored in little-endian byte orde

42、r format. Identification tags are stored in big-endian byte order format. Endianness of the payloads will be as defined in the governing specification. ARINC SPECIFICATION 657 Page 4 2.0 FILE FORMAT CHARACTERISTICS 2.2 Tagged Object The tagged object is the basic building block of an RSO file. All d

43、ata must be contained in a tagged object. Tagged objects can consist of other tagged objects. Therefore, the entire RSO file can be thought of as a family tree. Tagged objects are organized in a hierarchy as parents, siblings, or children. Tagged objects fall into the following categories: Compound

44、objects, made up of other objects Header objects, used for documentation Data objects, for user data Every tagged object consists of an identification tag, the size of the payload in bytes, and a payload. The basic structure of a tagged object is shown in the following table. Table 2-1 Tagged Object

45、 Bytes Field Description 8 Tag Object identification tag, upper case alphanumeric, left justified, space padded, for example, “ “ 8 Size Size in bytes of payload Variable Payload Data content for this object The Tag field of a tagged object is an ASCII string enclosed in angle brackets, then space p

46、added to a length of eight bytes. The Tag field identifies the type of object. An example of a tagged object ID is “ “. The Size field of a tagged object is an 8-byte unsigned integer indicating the size in bytes of the payload of that object. Immediately after any Size field is read, adding the Siz

47、e to the current file pointer will set the file pointer to the beginning of the Tag field of the next tagged object on the same or a higher level. If there are no more objects on the same or higher level, the file adding the Size to the current file pointer will set the file pointer to the end of fi

48、le. COMMENTARY If the user program adds data to a object, its size field must be updated by the number of bytes added. In addition, the size field of each of its ancestors, all the way to the object, must be updated. The payload of a tagged object will consist of other tagged objects (children), hea

49、der data, or raw recorder or other data, depending on the type of object. ARINC SPECIFICATION 657 Page 5 2.0 FILE FORMAT CHARACTERISTICS 2.2.1 Compound Objects A Compound Object is a tagged object whose payload is made up of other tagged objects. The following list summarizes the tags for all compound objects defined by this specification. Details of these objects are described in Section 3.0. Top-level object representing an entire download Generic object representing various types of file objects that can be found in an RSO file Recording s