ARINC 653

The ARINC 653 standard specifies an operational environment for application software used in Integrated Modular Avionics (IMA) modules. It allows the execution of programs with mixed degree of criticality on the same computer platform at the same time.

The underlying operating system typically makes use of virtualization techniques but must be capable to full-fill real-time requirements. The parts 1-5 of the standard specify the required services for an ARINC 653 compliant operating system. These refer to the virtualization techniques as well as to the provided API which is named APEX.

The PikeOS APEX guest operating system is a complete and fully compliant implementation of the ARINC 653 P1-5 specification and parts of the ARINC 653 P2-4 specification based on the general purpose product PikeOS. It provides

  • robust partitioning with respect to processing time and platform resources,
  • partition management,
  • health monitoring,
  • inter-partition communication based on sampling and queuing ports
  • an ARINC 653 compliant application runtime environment including process management and intra-partition communication and synchronization.
  • logbook services as defined in ARINC 653 P2-4.
  • file system services as defined in ARINC 653 P2-4.
  • memory block services as defined in ARINC 653 P2-4.
  • service access point port services as defined in ARINC 653 P2-4.

Developing with the APEX API

The APEX application runtime environment is shipped as a library, a set of header files, a linker script, and the APEX OS binary. The APEX OS binary is a fully linked ELF file that contains the APEX service code as well as the initialization code that is executed before the MAIN process is invoked. The APEX services are entered via an API table that is linked to a fixed address. During the development process, the APEX user application is linked against the library and the API service table addresses provided by the linker script.

The entry point of the executive is part of the APEX library. After being initialized, the APEX kernel passes control to the MAIN() function, which must be provided by the user code. At this time the preemption is locked and the partition mode is COLD_START. The prototype of the main function is given as

void MAIN(void);

This is where the user application starts. During the partition mode COLD_START, the user code is expected to create all static user resources, e.g. processes and their priorities as well as communication endpoints. Afterwards, the partition mode moves on to the state NORMAL. In this mode, the process scheduler is active and the system is in an operational mode. The full APEX API is now available, offering all OS services such as time management, inter-partition communication, intra-partition communication and error handling.

The entire development process is supported by the CODEO IDE. The rather technical and repetitive steps, such as linking the user code against the OS binary are automated and running in the background. Needless to say, remote debugging within the IDE is supported and the C Development Tooling (CDT) debug views are available. In addition to that, the ARINC 653 integration comes with a static monitor and a dynamic trace tool kit which are OS aware allowing you to inspect the APEX objects.

Learn more about CODEO

Benefits

Development for Integrated Modular Avionics (IMA) by means of the ARINC 653 API

Configuration is fully compliant to ARINC 653

PikeOS philosophy allows to access ARINC 653 technology from other partition types as well. Even a Linux application might access communication ports

Extended time-partition mechanisms allow to build more flexible systems

Certifiable according to DO-178C DAL A

Need more Information?

Tell us about your project and your needs.
 

Contact us