ARINC 653
From Wikipedia, the free encyclopedia
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 a Integrated Modular Avionics architecture[1].
It is part of ARINC 600-Series Standards for Digital Aircraft & Flight Simulators.
Contents |
[edit] Overview
In order to decouple the RTOS platform from the application software, ARINC 653 defines an API called APplication EXecutive (APEX) for space and time partitioning.
each application software is called a partition and has its own memory space. It also has a dedicated time slot allocated by the APEX. Within each Partition multitasking is allowed.
[edit] History
[edit] Initial version
The initial version of ARINC 653 was published on October 10, 1996.
[edit] ARINC 653-1
Supplement 1 was published on January 1997 and introduced the concepts of APEX and Time and Space partitioning.
[edit] ARINC 653-2
Supplement 2 was published on 3 parts between March 2006 and January 2007[2]:
- Part 1 (mandatory services): ARINC 653 partition management, Cold start and warm start definition, Application software error handling, ARINC 653 compliance, ADA and C language bindings;
- Part 2 (optional services): File system access, Data logging, Service Access points, ...
- Part 3 (Conformity Test Specification);
[edit] Architecture
ARINC 653 provides the following services through its API:
- Partition Management
- Process Management
- Time Management
- Interpartition Communication
- Intrapartition Communication
- Health Monitoring
[edit] ARINC 653 Platform
ARINC 653 platform contain:
- A hardware allowing Real-time computing deterministic services.
- An abstraction layer managing the timer and space parttioning constraints of the platform (memory, CPU, Input/output).
- An implementation for the ARINC 653 services (the APEX API).
- An interface to be able to configure the platform and its domain of use.
- Various instrumentation tools.
[edit] 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.
[edit] 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 (theoretically) cases, this could lead to an infinite loop between the faulty process and the Error Handler.
The Error Handler can obtain informations about the source and the context of the exception.
[edit] Mode management
Each Partition can be in several activation modes:
- COLD_START and WARM_START: Only the initialization process is executed,
- NORMAL: The initialization process is stopped, and the other partition processed are called by the RTOS scheduler depending on their priority,
- IDLE: No process is executed. However an implementation could still in theory execute a hidden process of the lowest priority, for example to start an infinite loop.
The SET_PARTITION_MODE service allows to manage these states. It can be called by any process in the partition. On 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.
[edit] The partitions processes
Each partition have at least one process.
Processed scheduling is preemptive. The scheduler is called either by a timer or by calling some API services.
[edit] 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[3].
Some ARINC 653 (APEX) calls have a POSIX equivalent, but are different from how they are defined in POSIX[3].
For example, the following call defined in ASAAC:
receiveBuffer
would be translated in ARINC 653 by:
RECEIVE_BUFFER()
and also in POSIX by:
recv()
[edit] References
- ^ "ARINC 653 - An Avionics Standard for Safe, Partitioned Systems". Wind River Systems / IEEE Seminar. August 2008. http://www.computersociety.it/wp-content/uploads/2008/08/ieee-cc-arinc653_final.pdf. Retrieved on 2009-05-30.
- ^ "Product Focus: ARINC 653 and RTOS". aviationtoday.com. 2004-07-01. http://www.aviationtoday.com/av/categories/bga/Product-Focus-ARINC-653-and-RTOS_976.html. Retrieved on 2009-05-30.
- ^ a b "Flexibility and Manageability of IMS Projects". University of York. http://www-users.cs.york.ac.uk/~mark/papers/ISSC2006.pdf. Retrieved on 2008-07-27.
