Changes between Version 3 and Version 4 of Developer/Projects/Open/ARINC653API


Ignore:
Timestamp:
Feb 13, 2012, 4:57:30 AM (8 years ago)
Author:
Gedare
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Developer/Projects/Open/ARINC653API

    v3 v4  
    22
    33
     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'''
     21I 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).
    422=  Background  =
    523
    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).
    824=  AIR  =
    925
     
    1127The 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)."
    1228Quoted from  http://hdl.handle.net/10455/2982 . -- cdcs
     29=  ARINC=653 Partitions  =
    1330
    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.
     31As 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  =