ARINC-653 API

Julien Delange julien.delange at gmail.com
Tue Mar 13 04:52:21 CDT 2012


On Sun, Mar 11, 2012 at 2:54 PM, WL <jolkaczad at gmail.com> wrote:
> [snip]

Dear all,

Sorry for answering late to this thread.

Gedare and Joel provide a good overview of such a project. You also
have to consider that we have to go step-by-step and really think
about how to implement that. As RTEMS seems to be supported by
different hypervisor/partitionning approaches, it could also be
valuable to take care to be as generic as possible so that RTEMS can
be executed on top of several partitioned kernel (and so, having a
generic adaptation layer to execute RTEMS on top of heterogeneous
partitioned kernel/hypervisor).

However, having an open-source, free and available separation kernel
that could be used as reference would be a really nice thing. And if
it supports the ARINC653 layer, it would be even better !

So, as suggested in the description of the work, the better thing
would probably be to go step by step and instead of implementing
directly in POK, making a first prototype should be fine. Then, we can
go ahead and integrate it with POK.

I would recommend the following checkpoints for the project :
- Implement a first prototype of a small hypervisor to execute basic
RTEMS system (for example, two instances of the ticket examples on
different partitions)
- See how we can implement this separation mechanisms in POK
- Integration within POK
- Investigation about the modification on RTEMS to call POK
specific-functions (such as inter-partitions communications ports).
Make this layer generic so that it can be easily tailored to other
partitioning approaches (AIR, XTratum, etc.)
- Integrate modification on RTEMS to use POK inter-partitions services
and make some examples that use inter-partitions services
- Implementation of ARINC653-layer inside RTEMS. This is mostly
wrappers functions that either call the RTEMS native skin or the POK
inter-partitions services.

But this is the big picture. One student cannot do all the work during
a single GSOC session. So it why somebody that wants to work on this
task should also make his own proposal and explain which part he
intents to do.

Hope that helps, do not hesitate to ask other questions :-)


More information about the rtems-users mailing list