ARINC-653 API

[Cláudio Silva]

Hi again,

On Fri, Aug 3, 2012 at 9:46 PM, Mathew Benson <mathew.benson at gmail.com> wrote:
> First, I don't know what POK is.  Can you post a link to some info?
>

http://pok.safety-critical.net/

Hopefully, soon with RTEMS support on i386. ;)

>
> Second, I thought RTEMS was an RTOS.  In my experience the OS doesn't run "in partitions".  The partition is similar to a heavyweight thread or POSIX process with a two layer scheduler to provide the time partitioning.  The ARINC "process" is similar to a lightweight thread or POSIX thread.  The APEX library provides the ARINC API, but the OS provides the partitioning.

Yes but you can implement an ARINC653 like OS using a two level
architecture. The first level is an hypervisor which creates
"partitions" and ensures that they are isolated in time and in space.
In the second level, in each partition, you have an user mode
virtualized operating system. This increases the flexibility of the
platform because in one partition you might have one operating system
with an ARINC 653 API and in another partition RTEMS (or even user
mode linux).

RTEMS appears as good fit to this scheme because RTEMS is a single
process multi threaded operating system. (i.e RTEMS only as threads
that share the same memory space)

A diagram to help you understand: http://oi45.tinypic.com/2d95qae.jpg

What we are aiming at with this GSOC project is the creation of a
standard virtualization layer between RTEMS and the underlying
hypervisor. This way you can have RTEMS on top of a number of
hypervisors (POK, AIR, etc).
If you then add a A653 api to RTEMS you get an A653 compliant system.

>
> Finally, I have heard there is a Linux implementation of ARINC 653, but I've never seen or used it.  My Linux environment isn't really ARINC 653.  It provides the APEX API so the partition code compiles and executes, but without significant OS changes, it doesn't actually provide space/time partitioning.  ARINC 653 facilitates portability and provides safety.  My Linux environment just allows me to easily port in ARINC code.  It's not suitable for all testing and definitely not suitable for production.
>
> Sorry, our Linux implementation is not open source, but it's fairly simple to write your own APEX API, if you don't need to actually implement partitioning. You just need to use the ARINC 643 header file, and write implementation code for it to map ARINC calls to OS calls.  It's only about 30 or 40 functions.
>
>
>
>
>
> Sent from my iPhone
>
> On Aug 3, 2012, at 3:19 PM, Julien Delange <julien.delange at gmail.com> wrote:
>
>> Hello,
>>
>> I might be of particular interest to have a look at the rtems/arinc653
>> project [1] being actually developed in the Summer Of Code (I put our
>> student Cc: to this mail). Also, I think you might be interested by
>> having a look at POK [2]. Our project is to virtualize RTEMS on top of
>> POK and even if this is not yet ready, you are more than welcome if
>> you want to contribute ! At this time, it focuses more on the
>> interaction between RTEMS being in partitions and POK that isolates
>> RTEMS instances. If you want to write an ARINC653 layer on top of POK,
>> I think it night be a nice contribution to this project.
>>
>> Also, you seem to use ARINC653 functionalities on top of Linux but I
>> am very curious about the ARINC653-compliance of Linux. Did it provide
>> time and space partitioning as regular ARINC-compliant OS do ?
>>
>> Anyway, good to see there is an interest about such a project,
>>
>> Regards,
>>
>> [1] http://www.rtems.org/wiki/index.php/RTEMS_Paravirtualization
>> [2] http://pok.safety-critical.net/
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users