Introduction: The idea here would be to provide an API that supports the first part of ARINC-653 services so that ARINC-653 applications can compile with RTEMS and intra-partition services would work. New API support for the ARINC-653 API (APEX) would need to be designed and implemented in RTEMS. The project would interface the following services with the regular RTEMS API: tasks, intra-partition (blackboard/event/semaphore/buffer) and time service.
Goal: Provide a minimal ARINC-653 layer that supports intra-partition services.
Requirements: Low-level programming. Interface design.
Resources: Consult the posix (and deprecated uitron) layer for an idea of how to design an adaptation layer in RTEMS. This project is related to RTEMS_Paravirtualization.
Acknowledgements I am VERY fond of the idea of a free hypervisor that provides the real-time features required by ARINC 653. --Dr. Joel 23:18, 25 January 2010 (UTC).
The implementation of ARINC 653 interface in RTEMS was studied as part of a ESA project named AIR. This study was developed to "study of how the Real-Time Executive for Multiprocessor Systems (RTEMS) can be adapted to fullfill the requirements defined in the ARINC 653 standard". The project provided a proof of concept of the ARINC 653 implementation. The project page can be found here. The final report can be found here. "This document: (i) describes the main issues regarding the AIR architecture specification; (ii) addresses how space and time partitioning could be provided in an abstract processor infrastructure, as well as those requirements can be mapped into both SPARC ERC32/LEON and Intel IA-32 (80x86) architectures; (iii) describes how to achieve the mapping of the ARINC 653 service interface in RTEMS; (iv) identifies the most relevant module dependencies of RTEMS with regard to AIR implementations;(v) identifies a preliminary set of modifications to be introduced in the RTEMS application production chain for the implementation of AIR-based systems (exemplified through a proof of concept prototype)." Quoted from http://hdl.handle.net/10455/2982 . -- cdcs
As inter-partitions would be managed by an underlying hypervisor, they must be integrated as a second step for ARINC-653 services integration. For inter-partition services (queueing/sampling ports), we expect to provide the definition of the function but leave it blank so that an ARINC653 partition would compile but the behaviour would have to be implemented in the future.