ARINC 653 on PikeOS

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.

Read the Blog Article

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

Connect System Composer™ and Simulink® with PikeOS ARINC 653

With this tutorial we demonstrate the workflow for integrating the ARINC 653 blockset from MathWorks into PikeOS. It covers generating CODEO binaries from a Simulink model, configuring the project in  our CODEO integrated development environment, and building a PikeOS image. 

The process includes creating Simulink models from an XML definition, configuring the PikeOS toolchain, generating APEX binaries, and setting up the integration project in CODEO. 

Finally, the video walks through importing ARINC 653 configurations and building the final PikeOS image for deployment.

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 pre-emption 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.