IMPLEMENTATION LEVELS AND SCOPE

An O/S which claims to be compliant to the ARINC 653 specification supports essentially all system services and data structures, including the functional behavior defined by ARINC 653 Part 1. Besides the basic services defined in ARINC 653 Part 1, the standard is extended to include optional services (e.g. file handling, external events, etc.) in ARINC 653 Part 2. The distinction between basic and optional functionality also establishes different levels of compliance (basic level or basic level with one or more extensions).

PURPOSE OF COMPLIANCE DEMONSTRATION

ARINC Specification 653 Part 1 defines the basic set of services that addresses the necessary functionalities for core services, as well as the necessary facilities that have to be provided through the interface (API Application Programming Interface) between the application programs and the O/S. It describes the invocation of those services and the data structures with specified semantics to ensure the accurate binding and running of the applications on the O/S.

These core services are grouped into the following major service categories:

• Partition management, which allows partitions with different criticality levels to execute in the same core module without affecting one another spatially or temporally.

• Process management and control, which includes all the resources necessary to manage the different processes. For example process control and process scheduling, taking into account the specific processes attributes and process state transitions.

• Time management is one of the most critical features to be provided by the O/S within multiple application systems. In accordance to the APEX philosophy time is independent of process or partition execution. All time values are related to the core module time and not relative to the partition or process.

• Inter partition communication mechanisms, which allow the communication of messages between two or more partitions executing either on the same core module or on different core modules. Intra partition communication mechanisms, which allow the communication of messages between processes within the same partition without the overhead of the global message passing processing.

• Health Monitoring functions, which monitor and report platform/ application/ software faults and failures, and help to isolate faults and to prevent failures from propagating.

The goal to take a compliance test process as specified within this ARINC standard for an implemented O/S is to demonstrate and to prove that the interface behavior is in compliance with the ARINC 653 specification. Any application, which will be installed upon this O/S, can rely on this compliance and the portability of applications is more supported. A compliance demonstration finally gives more confidence to both sides, to the O/S providers, as well as to the organization responsible to integrate the applications. A standard specification for compliance test procedures provides a unique test scenario with predetermined conditions for all test candidates, which increases significantly the level of confidence.