ARINC 653P4-2012 AVIONICS APPLICATION SOFTWARE STANDARD INTERFACE PART 4 - SUBSET SERVICES.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 4 SUBSET SERVICES ARINC SPECIFICATION 653P4 PUBLISHED: June 28, 2012 This document is published information as defined by 15 CFR Se

2、ction 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 PARTICIPANTS

3、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. ARINC

4、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 SYSTE

5、MS 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 IT MA

6、Y 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, IS

7、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 PRODUCT

8、S 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 DISCLA

9、IMER. 2012 BY AERONAUTICAL RADIO, INC. 2551 RIVA ROAD ANNAPOLIS, MARYLAND 21401-7435 USA Prepared by the AEEC Specification 653P4 Adopted by the AEEC Executive Committee May 2, 2012 A description of the changes introduced by each supplement is included at the end of this document. ARINC SPECIFICATIO

10、N 653P4 AVIONICS APPLICATON SOFTWARE STANDARD INTERFACE PART 4 SUBSET SERVICES Published: June 28, 2012ii 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 pr

11、oviding 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

12、, 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 aviation. Th

13、e 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) ARINC Characteri

14、stics 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 requisites of

15、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 computer la

16、nguage. 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 establish or

17、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 items are includ

18、ed 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 to this ARIN

19、C Standard. ARINC SPECIFICATION 653, PART 4 TABLE OF CONTENTS iii 1.0 INTRODUCTION . 1 1.1 Purpose . 1 1.2 Scope . 1 1.3 Document Organization . 2 1.4 ARINC Specification 653 Basic Philosophy . 3 1.5 Implementation Guidelines 3 1.6 Document Overview . 3 1.7 Relationship to Other Standards 3 1.8 Rela

20、ted Documents . 3 2.0 SYSTEM OVERVIEW 4 2.1 System Architecture . 4 2.2 Hardware . 4 2.3 System Functionality 4 2.3.1 Partition Management . 4 2.3.1.1 Partition Attribute Definition 5 2.3.1.2 Partition Control 5 2.3.1.3 Partition Scheduling 5 2.3.1.4 Partition Operating Modes 5 2.3.1.4.1 Partition O

21、perating Modes Description 5 2.3.1.4.1.1 COLD_START and WARM_START Considerations . 5 2.3.1.4.2 Partition Modes and Transitions 5 2.3.1.4.2.1 Initialization Mode Transition . 5 2.3.1.4.2.2 Transition Mode Description 5 2.3.2 Process Management . 5 2.3.2.1 Process Attribute Definition 6 2.3.2.2 Proce

22、ss Control 6 2.3.2.2.1 Process State Transitions 6 2.3.2.2.1.1 Process States . 6 2.3.2.2.1.2 Process State Transitions Versus Partition Mode Transitions . 7 2.3.2.2.1.3 State Transitions 8 2.3.2.3 Process Scheduling 8 2.3.2.4 Process Priority 9 2.3.2.5 Process Waiting Queue 9 2.3.2.6 Process Preemp

23、tion Locking 9 2.3.3 Time Management 9 2.3.4 Memory Management . 9 2.3.5 Interpartition Communication 9 2.3.5.1 Communication Principles 9 2.3.5.2 Message Communication Levels 9 2.3.5.3 Message Types 9 2.3.5.4 Message Type Combinations . 9 2.3.5.5 Channels and Ports 9 2.3.5.6 Modes of Transfer 9 2.3

24、.5.7 Port Attributes . 10 2.3.5.8 Port Control 10 2.3.5.9 Process Queuing Discipline 10 2.3.6 Intrapartition Communication 10 2.4 Health Monitor 10 2.4.1 Error Levels . 11 2.4.1.1 Process Level Errors 11 2.4.1.2 Partition Level Errors 12 ARINC SPECIFICATION 653, PART 4 TABLE OF CONTENTS iv 2.4.1.3 M

25、odule Level Errors . 12 2.4.2 Fault Detection and Response 12 2.4.2.1 Process Level Error Response Mechanisms 12 2.4.2.2 Partition Level Error Response Mechanisms . 12 2.4.2.3 Module Level Error Response Mechanisms . 12 2.4.3 Recovery Actions 12 2.4.3.1 Module Level Error Recovery Actions 12 2.4.3.2

26、 Partition Level Error Recovery Actions . 12 2.4.3.3 Process Level Error Recovery Actions . 12 2.5 Configuration Considerations . 12 2.5.1 Configuration Information Required by the Integrator . 12 2.5.2 Configuration Tables . 12 2.5.2.1 Configuration Tables for System Initialization 13 2.5.2.2 Confi

27、guration Tables for Inter-Partition Communication . 13 2.5.2.3 Configuration Tables for Health Monitor . 13 2.6 Verification . 13 3.0 SERVICE REQUIREMENTS . 14 3.1 Service Request Categories 14 3.1.1 Return Code Data Type 14 3.1.2 OUT Parameters Values . 14 3.2 Partition Management 14 3.2.1 Partitio

28、n Management Types 14 3.2.2 Partition Management Services 14 3.2.2.1 GET_PARTITION_STATUS . 14 3.2.2.2 SET_PARTITION_MODE . 15 3.3 Process Management 16 3.3.1 Process Management Types . 16 3.3.2 Process Management Services . 16 3.3.2.1 GET_PROCESS_ID . 16 3.3.2.2 GET_PROCESS_STATUS 16 3.3.2.3 CREATE

29、_PROCESS . 16 3.3.2.4 SET_PRIORITY 18 3.3.2.5 SUSPEND_SELF . 18 3.3.2.6 SUSPEND 18 3.3.2.7 RESUME 18 3.3.2.8 STOP_SELF . 18 3.3.2.9 STOP 18 3.3.2.10 START 18 3.3.2.11 DELAYED_START . 19 3.3.2.12 LOCK_ PREEMPTION . 20 3.3.2.13 UNLOCK_PREEMPTION . 20 3.3.2.14 GET_MY_ID . 20 3.4 Time Management . 20 3.

30、4.1 Time Management Types 20 3.4.2 Time Management Services 20 3.4.2.1 TIMED_WAIT . 20 3.4.2.2 PERIODIC_WAIT . 20 3.4.2.3 GET_TIME 21 3.4.2.4 REPLENISH . 21 3.5 Memory Management 21 3.6 Interpartition Communication . 21 ARINC SPECIFICATION 653, PART 4 TABLE OF CONTENTS v 3.6.1 Interpartition Communi

31、cation Types 21 3.6.2 Interpartition Communication Services 21 3.6.2.1 Sampling Port Services 22 3.6.2.1.1 CREATE_SAMPLING_PORT 22 3.6.2.1.2 WRITE_SAMPLING_MESSAGE . 22 3.6.2.1.3 READ_SAMPLING_MESSAGE . 22 3.6.2.1.4 GET_SAMPLING_PORT_ID . 22 3.6.2.1.5 GET_SAMPLING_PORT_STATUS . 22 3.6.2.2 Queuing Po

32、rt Services 22 3.6.2.2.1 CREATE_QUEUING_PORT 22 3.6.2.2.2 SEND_QUEUING_MESSAGE 23 3.6.2.2.3 RECEIVE_QUEUING_MESSAGE . 25 3.6.2.2.4 GET_QUEUING_PORT_ID . 27 3.6.2.2.5 GET_QUEUING_PORT_STATUS . 27 3.6.2.2.6 CLEAR_QUEUING_PORT 27 3.7 Intrapartition Communication . 27 3.8 Health Monitoring . 27 3.8.1 He

33、alth Monitoring Types . 28 3.8.2 Health Monitoring Services . 28 3.8.2.1 REPORT_APPLICATION_MESSAGE . 28 3.8.2.2 CREATE_ERROR_HANDLER . 28 3.8.2.3 GET_ERROR_STATUS . 28 3.8.2.4 RAISE_APPLICATION_ERROR 28 4.0 COMPLIANCE TO APEX INTERFACE . 30 4.1 O/S Implementation Compliance . 30 4.2 Application Com

34、pliance . 30 5.0 XML CONFIGURATION SPECIFICATION 31 APPENDICES APPENDIX A GLOSSARY . 32 APPENDIX B ACRONYMS 33 APPENDIX C APEX SERVICES SPECIFICATION GRAMMAR 34 APPENDIX D.1 ADA INTERFACE SPECIFICATION 35 APPENDIX D.2 ADA INTERFACE SPECIFICATION 47 APPENDIX E ANSI C INTERFACE SPECIFICATION . 60 APPE

35、NDIX F APEX SERVICE RETURN CODE MATRIX . 69 APPENDIX G GRAPHICAL VIEW OF ARINC 653 XML-SCHEMA TYPES . 70 APPENDIX H ARINC 653 XML-SCHEMA 71 APPENDIX I ARINC 653 XML-SCHEMA TYPE USAGE EXAMPLES . 72 ARINC SPECIFICATION 653, PART 4 Page 1 1.0 INTRODUCTION 1.0 INTRODUCTION 1.1 Purpose This document defi

36、nes a Subset for the Application Programming Interface (API) specified by ARINC Specification 653, Part 1, Required Services. This document is based on Supplement 3 to Part 1. Based on a simpler execution model, with only one or two processes, and a reduced set of services, it defines “restrictions”

37、 to the ARINC 653 Part 1 API. The primary objective of this Specification is to define a restricted interface between the Operating System (O/S) of an avionics computer resource and the application software. Included within this specification are the interface requirements between the application so

38、ftware and the O/S and the list of services which allow the application software to control the scheduling, communication, and status information of its internal processing elements. This Specification defines the data exchanged statically (via configuration) or dynamically (via services) as well as

39、 the behavior of services provided by the O/S and used by the application. It is not the intent of this specification to dictate implementation requirements on either the hardware or software of the system, nor is it intended to drive certain system level requirements within the system which follows

40、 this standard. The majority of this document describes the runtime environment for embedded avionics software. This list of services identifies the minimum functionality provided to the application software and is, therefore, the industry standard interface. It is intended for this interface to be

41、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 of the APEX interface are High Order Language (HOL) independent, allowing systems using different compilers and lan

42、guages to follow this interface. 1.2 Scope This document specifies both the interface and the behavior of the APEX services. Behavior is specified to the extent needed to describe behavior relevant to calling applications. Where necessary, assumptions are made as to the support or behavior provided

43、by the operating system and hardware. This should not be construed as a specification for the O/S or hardware. However, where the O/S or hardware does not coincide with the stated assumptions, the API behaviors specified herein may not match the actual behavior. ARINC 653 is intended for use in a pa

44、rtitioned software environment. In order to assure a high degree of portability, aspects of the partitioned environment are discussed and assumed. However, this specification does not define the complete system, hardware or software requirements for partitioning, nor does it provide guidance on prop

45、er implementation of partitioning and in particular, robust partitioning. It must not be construed that compliance to this standard in any way assures robust partitioning. The main objectives of this Subset are the following: Achieve an execution model and O/S abstractions for a simpler software des

46、ign than with ARINC Specification 653, Part 1. ARINC SPECIFICATION 653, PART 4 Page 2 1.0 INTRODUCTION Simplify dynamic behavior, make it easier to characterize and enable formal methods for Worst Case Execution Time (WCET) analysis. Maintain portability of applications with ARINC Specification 653,

47、 Part 1 (i.e., an application that is compliant to ARINC Specification 653, Part 4 should operate in ARINC Specification 653, Part 1 compliant environment). Downsize O/S code footprint, reduce O/S overhead, improve real-time performance. Scale down O/S complexity to enable formal proof analysis. Reu

48、se configuration tools from ARINC Specification 653, Part 1 compliant environments. Reduce cost of certification. The following table gives for each service category an overview of the main restrictions in this Part 4 versus Part 1. Table 1.1 Overview of Part 4 versus Part 1 restrictions Service Cat

49、egory Restrictions Partition management Partition scheduling is restricted to only one partition time window within the partitions period. This simplifies management of release points and deadline monitoring. Process management Process management is restricted to a dual-process model with at most two processes within a partition (one periodic and/or one aperiodic) - simple but yet more flexible than a single process, i.e., may support a broader range of applications. The periodic process has priority over the aperiodic one, so that scheduling is straightforw