ARINC 653

ARINC 653 (Avionics Application Standard Software Interface) is a software specification for space and time partitioning in Safety-critical avionics Real-time operating systems. It allows to host multiple applications of different software levels on the same hardware in the context of an Integrated Modular Avionics architecture.[1]

It is part of ARINC 600-Series Standards for Digital Aircraft & Flight Simulators.

Overview

In order to decouple the RTOS platform from the application software, ARINC 653 defines an API called APplication EXecutive (APEX).

Each application software is called a partition and has its own memory space. It also has a dedicated time slot allocated by the APEX API. Within each Partition, multitasking is allowed. The APEX API provides services to manage partitions, processes and timing, as well as partition/process communication and error handling.

VisualSim[2] ARINC 653 is a system simulation library that contains the model of the real-time operating system (RTOS), components to emulate the software tasks, hardware components and analysis tools. The models can be used for timing analysis, power consumption and functional correctness.

The current work of the AEEC APEX Subcommittee includes the enhancement of ARINC 653 for multicore processor architectures.[3]

History

Initial version

The initial version of ARINC 653 was published on October 10, 1996.

ARINC 653-1

Supplement 1 was published on January 1997 and introduced the concepts of APEX and Time and Space partitioning.

ARINC 653-2

Supplement 2 was published in 3 parts between March 2006 and January 2007:[4]

Current Organization of Standard

Basic Principles of Partitioning

ARINC 653 Platform

An ARINC 653 platform contains:

Initialization

Initialization of an ARINC 653 partition creates resources used by the partition. Resources creation (PROCESS, EVENT, SEMAPHORE...) is performed by calling API services named CREATE_xxxx.

Error Handler

The partition Error Handler is a preemptive process of the highest priority dedicated to handle partition exceptions. It is created by the service CREATE_ERROR_HANDLER during partition initialization.

The API allows the Error Handler to stop a faulty process (STOP_SELF). In that case, the RTOS scheduler will elicit the next process with the highest priority.

ARINC 653 does not specify how the scheduler should behave if the Error Handler does not stop a faulty process. In some (theoretical) cases, this could lead to an infinite loop between the faulty process and the Error Handler.

The Error Handler can obtain information about the source and the context of the exception.

Mode management

Each Partition can be in several activation modes:

The SET_PARTITION_MODE service allows to manage these states. It can be called by any process in the partition. Entering the IDLE state is irreversible for the partition. Only an external event (such as a platform restart) can change the state to another mode when the partition is in this state.

The processes of a partition

Each partition has at least one process.

Process scheduling is preemptive. The scheduler is called either by a timer or by API services.

API Services

The ARINC 653 APEX services are API calls belonging in six categories:

No ARINC 653 services are provided for the memory management of partitions. Each partition has to handle its own memory (still under the constraints of memory partitioning enforced by ARINC 653).

Each service returns a RETURN_CODE value which indicates if the call has been successful:

Links to POSIX and ASAAC

The field covered by ARINC 653 is similar to ASAAC Def Stan 00-74. However, there are differences between the two standards.[11]

Some ARINC 653 (APEX) calls have a POSIX equivalent, but are different from how they are defined in POSIX.[11]

For example, the following call defined in ASAAC:

 receiveBuffer

would be translated in ARINC 653 by:

 RECEIVE_BUFFER()

and also in POSIX by:

 recv()

References

See also