ARINC 653P0-2013 AVIONICS APPLICATION SOFTWARE STANDARD INTERFACE PART 0 OVERVIEW OF ARINC 653.pdf

1、 AN DOCUMENT Prepared by AEEC Published by AERONAUTICAL RADIO, INC. 2551 RIVA ROAD, ANNAPOLIS, MARYLAND 21401-7435 AVIONICS APPLICATION SOFTWARE STANDARD INTERFACE PART 0 OVERVIEW OF ARINC 653 ARINC SPECIFICATION 653 PUBLISHED: June 10, 2013 This document is published information as defined by 15 CF

2、R Section 734.7 of the Export Administration Regulations (EAR). As publicly available technology under 15 CFR 74.3(b)(3), it is not subject to the EAR and does not have an ECCN. It may be exported without an export license. DISCLAIMER THIS DOCUMENT IS BASED ON MATERIAL SUBMITTED BY VARIOUS PARTICIPA

3、NTS DURING THE DRAFTING PROCESS. NEITHER AEEC, AMC, FSEMC NOR ARINC HAS MADE ANY DETERMINATION WHETHER THESE MATERIALS COULD BE SUBJECT TO VALID CLAIMS OF PATENT, COPYRIGHT OR OTHER PROPRIETARY RIGHTS BY THIRD PARTIES, AND NO REPRESENTATION OR WARRANTY, EXPRESS OR IMPLIED, IS MADE IN THIS REGARD. AR

4、INC INDUSTRY ACTIVITIES USES REASONABLE EFFORTS TO DEVELOP AND MAINTAIN THESE DOCUMENTS. HOWEVER, NO CERTIFICATION OR WARRANTY IS MADE AS TO THE TECHNICAL ACCURACY OR SUFFICIENCY OF THE DOCUMENTS, THE ADEQUACY, MERCHANTABILITY, FITNESS FOR INTENDED PURPOSE OR SAFETY OF ANY PRODUCTS, COMPONENTS, OR S

5、YSTEMS DESIGNED, TESTED, RATED, INSTALLED OR OPERATED IN ACCORDANCE WITH ANY ASPECT OF THIS DOCUMENT OR THE ABSENCE OF RISK OR HAZARD ASSOCIATED WITH SUCH PRODUCTS, COMPONENTS, OR SYSTEMS. THE USER OF THIS DOCUMENT ACKNOWLEDGES THAT IT SHALL BE SOLELY RESPONSIBLE FOR ANY LOSS, CLAIM OR DAMAGE THAT I

6、T MAY INCUR IN CONNECTION WITH ITS USE OF OR RELIANCE ON THIS DOCUMENT, AND SHALL HOLD ARINC, AEEC, AMC, FSEMC 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 ANY TERM, SUCH AS SHALL OR MUST,

7、 IS NOT INTENDED TO AFFECT THE STATUS OF THIS DOCUMENT AS A VOLUNTARY STANDARD OR IN ANY WAY TO MODIFY THE ABOVE DISCLAIMER. NOTHING HEREIN SHALL BE DEEMED TO REQUIRE ANY PROVIDER OF EQUIPMENT TO INCORPORATE ANY ELEMENT OF THIS STANDARD IN ITS PRODUCT. HOWEVER, VENDORS WHICH REPRESENT THAT THEIR PRO

8、DUCTS 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 OF OR RELIANCE ON THIS DOCUMENT SHALL CONSTITUTE AN ACCEPTANCE THEREOF “AS IS” AND BE SUBJECT TO THIS DI

9、SCLAIMER. 2013 BY AERONAUTICAL RADIO, INC. 2551 RIVA ROAD ANNAPOLIS, MARYLAND 21401-7435 USA Prepared by the AEEC Specification 653P0 Adopted by the AEEC Executive Committee April 24, 2013 A description of the changes introduced by each supplement is included at the end of this document. ARINC SPECI

10、FICATION 653 AVIONICS APPLICATION SOFTWARE STANDARD INTERFACE PART 0 OVERVIEW OF ARINC 653 Published: June 10, 2013ii FOREWORD Aeronautical Radio, Inc., the AEEC, and ARINC Standards ARINC organizes aviation industry committees and participates in related industry activities that benefit aviation at

11、 large by providing 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 organiz

12、ations (AEEC, AMC, 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 used in commercial, military, and business

13、aviation. The AEEC, 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 technical and economic benefit to the aviation industry. There are three classes of ARINC Standards: a) ARIN

14、C 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 coordinated opinion of the airline technical community concerning the re

15、quisites 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 mounting of avionics equipment, data communication standards, or a high-level

16、 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 organization or ARINC to purchase equipment so described, nor does it e

17、stablish 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 facilitate the continuous product improvement of this ARINC Standard, two item

18、s are included in the back of this volume: An Errata Report solicits any corrections to existing text or diagrams that may be included in a future Supplement to this ARINC Standard. An ARINC IA Project Initiation/Modification (APIM) form solicits any proposals for the addition of technical material

19、to this ARINC Standard. ARINC SPECIFICATION 653 PART 0 TABLE OF CONTENTS iii 1.0 INTRODUCTION . 1 1.1 Purpose 1 1.2 Scope . 2 1.3 ARINC Specification 653 Basic Philosophy . 2 1.3.1 IMA Partitioning . 2 1.3.2 Software Decomposition . 2 1.3.3 Goals . 4 1.3.4 Expected Benefits . 5 1.4 ARINC Specificati

20、on 653 Overview . 5 1.5 Implementation Guidelines 7 1.5.1 Portability . 8 1.5.2 Language Considerations . 8 1.6 Relationship to Other Standards 8 1.6.1 POSIX . 9 1.6.2 Extensible Markup Language (XML) . 9 1.6.3 ARINC Report 651 9 1.6.4 ARINC Report 652 9 1.6.5 ARINC Report 613 9 1.6.6 RTCA DO 178/EU

21、ROCAE ED-12 . 9 1.6.7 RTCA DO-255/EUROCAE ED-96 . 9 1.6.8 RTCA DO-297/EUROCAE ED-124 . 10 1.6.9 RTCA DO-326/EUROCAE ED-202 . 10 1.7 Security Considerations . 10 APPENDICES APPENDIX A GLOSSARY 11 APPENDIX B ACRONYMS . 22 ARINC SPECIFICATION 653 PART 0 PAGE 1 1.0 INTRODUCTION 1.0 INTRODUCTION 1.1 Purp

22、ose This document provides an overview of the entire set of documents collectively referred to as ARINC 653. As this set of documents evolves, Supplements to Parts 1 through 5 will be made more consistent with Part 0 in conjunction with the technical changes expected to be made in the evolution of A

23、RINC 653. A summary of the ARINC 653 documents follows: Part 0 Overview of ARINC 653 Part 1 Required Services Part 2 Extended Services Part 3 Conformity Test Specification Part 4 Subset Services Part 5 Core Software Required Capabilities The term “this document” refers to Part 0 only, while the term

24、 “ARINC 653” or “the Specification” refers to the whole set of ARINC 653 documents, currently Parts 0 to 5. The primary objective of ARINC 653 is to define a general purpose APEX (APplication/EXecutive) interface (API = Application Program Interface) between the Core Software (CSW) of an avionics co

25、mputer resource and the application software. Included within ARINC 653 are the interface requirements between the application software and the CSW and the list of services which allow the application software to control the scheduling, communication, and status information of its internal processin

26、g elements. ARINC 653 defines the data exchanged statically (via configuration) or dynamically (via services) as well as the behavior of services provided by the CSW and used by the application. It is not the intent of the Specification to dictate implementation requirements on either the hardware o

27、r software of the system, nor is it intended to drive certain system level requirements within the system which follows this standard. ARINC 653 Parts 1, 2, and 4 describe the runtime environment for embedded avionics software. This list of services identifies the minimum functionality provided to t

28、he application software and is, therefore, the industry standard interface. It is intended for this interface to be as generic as possible, since an interface with too much complexity or too many system specific features is normally not accepted over a variety of systems. The software specifications

29、 of this API are High Order Language (HOL) independent, allowing systems using different compilers and languages to follow this interface. ARINC 653 is intended to complement ARINC Report 651: Design Guidance for Integrated Modular Avionics. It is expected that individual parts of ARINC 653 will evo

30、lve to contain additional functionality and capability. Supplements to ARINC Specification 653 Parts 0 to 5 will be prepared and published independently as needed by the industry. In each case, the evolution of one part must consider the potential impact on the other ARINC 653 parts. ARINC SPECIFICA

31、TION 653 PART 0 Page 2 1.0 INTRODUCTION 1.2 Scope This document introduces the concepts and principles specified within ARINC 653 to support the API, including vocabulary and definitions, and system architecture. Both the interface and the behavior of the API services are specified in ARINC 653. Beh

32、avior is specified to the extent needed to describe functionality relevant to calling applications. Where necessary, assumptions are made as to the support or behavior provided by the CSW and hardware. This document should not be construed as a specification for the CSW or hardware. However, where t

33、he CSW or hardware does not coincide with the stated assumptions, the API behaviors specified in ARINC 653 may not match the actual behavior. ARINC 653 is intended for use in a partitioned software environment. In order to assure a high degree of portability, aspects of the partitioned environment a

34、re discussed and assumed. However, ARINC 653 does not define the complete system, hardware, and software requirements for partitioning nor does it provide guidance on proper implementation of partitioning, and in particular, robust partitioning. It must not be construed that compliance to ARINC 653

35、assures robust partitioning. 1.3 ARINC Specification 653 Basic Philosophy 1.3.1 IMA Partitioning One purpose of a core module in an IMA system is to support one or more avionics applications and allow independent execution of those applications. This can be correctly achieved if the system provides

36、partitioning, i.e., a functional separation of the avionics applications, usually for fault containment (to prevent any partitioned function from causing a failure in another partitioned function) and ease of verification, validation, and certification. The unit of partitioning is called a partition

37、. A partition is basically the same as a program in a single application environment: it comprises data, its own context, configuration attributes, etc. For large applications, the concept of multiple partitions relating to a single application is recognized. 1.3.2 Software Decomposition The softwar

38、e that resides on the hardware platform may consist of: Application Partitions: They are the portions of software specific to avionics applications supported by the core module. This software is specified, developed, and verified to the level of criticality appropriate to the avionics application. A

39、RINC 653 application partitions are subject to robust space and time partitioning and are restricted to using only ARINC 653 calls to interface to the system. OS Kernel: This provides the API and behaviors defined within this Specification and supports a standard and common environment in which appl

40、ication software executes. This may include hardware interfaces such as device drivers and built-in-test functions. System Partitions: They are partitions that require interfaces outside the scope of APEX services, yet constrained by robust spatial and temporal partitioning. These partitions may per

41、form functions such as managing ARINC SPECIFICATION 653 PART 0 PAGE 3 1.0 INTRODUCTION communication from hardware devices or fault management schemes. System partitions are optional and are specific to the core module implementation. System Specific Functions: These may include hardware interfaces,

42、 such as device drivers, down loading, debug, and built-in-test functions. Figure 1 Example Module Architecture Each core module can contain one or more individual processors. The core module architecture has influence on the CSW implementation, but not on the APEX interface used by the application

43、software of each partition. Application software should be portable between core modules and between individual processors of a core module without modifying its interface with the CSW. COMMENTARY When there are multiple processors on a common hardware element, each processor or a set of processors

44、that hosts a single ARINC 653 API execution context (i.e., execute a single partition schedule at any given time) is considered to constitute a separate core module. The APEX interface, between the application software and the CSW, defines a set of facilities which the system will provide for applic

45、ation software to control the scheduling, communication, and status information of its internal processing ARINC SPECIFICATION 653 PART 0 Page 4 1.0 INTRODUCTION elements. The APEX interface can be seen from the viewpoint of the application software as a High-Order Language (HOL) specification and f

46、rom the CSW viewpoint as a definition of parameters and entry mechanisms (e.g., trap calls). APEX may include a layer that translates from the HOL specification into the appropriate entry mechanism. This translation is directly dependent on the CSW implementation, hardware platform, and also on the

47、compiler used for application software. If library routines are used, they may need to be included within the application code to preserve robust partitioning. ARINC 653 provides the definition of APEX interface services. The additional interface available to system partitions is not detailed here.

48、There are two reasons for not including the System Partition interface: a. This Specification covers avionics applications to platform interfaces only. Therefore, the definition of the System Partition interface is out of scope. b. The System Partition interface is likely to be specific to the CSW o

49、r platform hardware (for example, device drivers) and, therefore, cannot be generically defined by this Specification. 1.3.3 Goals The APEX interface provides a common logical environment for the application software. This environment enables independently produced applications to execute together on the same hardware. The principal goal of the APEX interface is to provide a general purpose interface between the application software and the CSW within IMA. The concept of CSW that is common to different hardware implementations is not new.