- Timestamp:
-
02/13/12 04:57:30 (12 years ago)
- Author:
-
Gedare
- Comment:
-
Legend:
- Unmodified
- Added
- Removed
- Modified
-
v3
|
v4
|
|
2 | 2 | |
3 | 3 | |
| 4 | |
| 5 | [[TOC(Projects/GSoC/ARINC653API, depth=2)]] |
| 6 | |
| 7 | |
| 8 | '''Mentors:''' |
| 9 | |
| 10 | '''Status:''' |
| 11 | |
| 12 | '''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. |
| 13 | |
| 14 | '''Goal:''' Provide a minimal ARINC-653 layer that supports intra-partition services. |
| 15 | |
| 16 | '''Requirements:''' Low-level programming. Interface design. |
| 17 | |
| 18 | '''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 [wiki:Projects/Paravirtualization RTEMS Paravirtualization]. |
| 19 | |
| 20 | '''Acknowledgements''' |
| 21 | I am VERY fond of the idea of a free hypervisor that provides the real-time features required by ARINC 653. --[wiki:User:JoelSherrill Dr. Joel] 23:18, 25 January 2010 (UTC). |
4 | 22 | = Background = |
5 | 23 | |
6 | | |
7 | | I am VERY fond of the idea of a free hypervisor that provides the real-time features required by ARINC 653. --[wiki:User:JoelSherrill Dr. Joel] 23:18, 25 January 2010 (UTC). |
8 | 24 | = AIR = |
9 | 25 | |
… |
… |
|
11 | 27 | The final report can be found [http://air.di.fc.ul.pt/air/downloads/07-35.pdf 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)." |
12 | 28 | Quoted from http://hdl.handle.net/10455/2982 . -- cdcs |
| 29 | = ARINC=653 Partitions = |
13 | 30 | |
14 | | = ARINC653 API support = |
15 | | |
16 | | |
17 | | The goal is to provide a minimal ARINC653 layer that support only intra-partition services. As inter-partitions would be managed by an underlying hypervisor, they must be integrated as a second step for ARINC653 services integration. The idea here would be to provide an API that support the first part of ARINC653 services so that ARINC653 application can compile with RTEMS and intra-partition services would work. |
18 | | This implies to add a new API support in RTEMS. The project would enable the following services to be interfaces with the regular RTEMS API: tasks, intra-partition (blackboard/event/semaphore/buffer) and time service. 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. |
| 31 | 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. |
| 32 | = References = |