ARINC-653 API

[WL]

I'm looking into the task involving writing an API which will support
the partition-internal services of ARINC-653 as a GSoC project. I went
through some of the reading material linked on the wiki, but still
have a couple questions. First of all I'd like to take a look at the
specification to start reading and prepare a bit, especially since the
AIR report mentioned that some aspects of the API mapping were found
more complex than anticipated. Is there a copy available for RTEMS
developers (I know it costs over $200, but don't know what the license
on it is), or would I have to obtain it myself? Also, is the code
developed by the AIR taskforce as a proof of concept implementation or
at least its documentation publicly available, would be good as a
starting point.

thanks,
W
_______________________________________________
rtems-users mailing list
rtems...@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-users

[Joel Sherrill]

While ARINC 653 support is desirable, it is an extremely large project that is beyond a single student. The (recently removed) ITRON support took a class of approximately 20 students to construct as a semester project. Even it was incomplete.

ARINC 653 requires API support for inside a partition, between partitions, and a partition manager. Pok appears to be the best truly free alternative to build a solution with. If you are interested in ARINC 653, I would recommend looking at Pok which is available today and getting RTEMS BSPs that are able to run as guests in the partitions.

The AIR SPARC BSP developed last year would also be a starting point but we would lile x86 and PowerPC BSPs for Pok as well.

I am cc'ing the author of Pok.
--joel

[WL]

Thanks for the tip. At first glance, Pok looks like the appropriate
solution for the "Partition Management Kernel" which encompasses the
"Partition Scheduler & Dispatcher" and "Inter-Partition Communication"
layers (using AIR terminology). I also like the AADL modelling
language Pok uses to ease and validate system configuration. Getting
instances of RTEMS to run on top of that and implementing the
intra-partition ARINC 653 APEX API look like two distinct tasks, I'd
like to confirm whether one of them would be in the scope of a single
student summer project, maybe someone else has already looked into
that? In the meantime I'll check out the AIR SPARC BSP you mentioned.

Also, why was ITRON support dropped?

[Gedare Bloom]

On Mon, Mar 12, 2012 at 6:27 AM, WL <jolk...@gmail.com> wrote:
> Thanks for the tip. At first glance, Pok looks like the appropriate
> solution for the "Partition Management Kernel" which encompasses the
> "Partition Scheduler & Dispatcher" and "Inter-Partition Communication"
> layers (using AIR terminology). I also like the AADL modelling
> language Pok uses to ease and validate system configuration. Getting
> instances of RTEMS to run on top of that and implementing the
> intra-partition ARINC 653 APEX API look like two distinct tasks, I'd
> like to confirm whether one of them would be in the scope of a single
> student summer project, maybe someone else has already looked into
> that? In the meantime I'll check out the AIR SPARC BSP you mentioned.
>

Yes getting RTEMS to run inside POK and implementing APEX are
distinct. RTEMS-POK integration is a good project. You would have to
dig deeper to see just how much work that would be.

APEX would need to be broken down into a lot of small subtasks that
could each be accomplished. The whole set of tasks is quite large. It
might be possible to define a few of the APEX calls that could be
implemented after RTEMS-POK integration---process management seems
like a good place to start.

> Also, why was ITRON support dropped?
>

bitrot. No one was (apparently) using or maintaining it.

-Gedare

[Julien Delange]

On Sun, Mar 11, 2012 at 2:54 PM, WL <jolk...@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 :-)

[WL]

On Tue, Mar 13, 2012 at 5:52 PM, Julien Delange
<julien....@gmail.com> wrote:
> On Sun, Mar 11, 2012 at 2:54 PM, WL <jolk...@gmail.com> wrote:
>> [snip]

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

This is all valuable stuff, and the topic is getting more interesting
by the minute. I see that this would somewhat pick up where a last
year's GSoC project left off. Is the student still active in the
community? If not ,did he leave his work in a useable state? I'd like
to contact him since there's no need to do the same research again and
come to conclusions which have already been arrived at.

[Gedare Bloom]

On Thu, Mar 15, 2012 at 1:44 PM, WL <jolk...@gmail.com> wrote:
> On Tue, Mar 13, 2012 at 5:52 PM, Julien Delange
> <julien....@gmail.com> wrote:
>> On Sun, Mar 11, 2012 at 2:54 PM, WL <jolk...@gmail.com> wrote:
>>> [snip]
>> Hope that helps, do not hesitate to ask other questions :-)
>
> This is all valuable stuff, and the topic is getting more interesting
> by the minute. I see that this would somewhat pick up where a last
> year's GSoC project left off. Is the student still active in the
> community? If not ,did he leave his work in a useable state? I'd like
> to contact him since there's no need to do the same research again and
> come to conclusions which have already been arrived at.

I believe last year's student worked primarily on the hypervisor guest
aspect---mainly on paravirtualization of RTEMS kernel and a particular
BSP. While this is related to ARINC API, we have identified
paravirtualization of RTEMS as a separate project.

Here is how I see it. We want the ARINC APEX interface so that
applications can be compiled / executed using the standard interface.
Within RTEMS we should implement the intra-partition services, and any
application that uses solely those services should work. Separately we
can tackle the issue of how to get RTEMS to work properly
(paravirtualized) as a guest that is scheduled by a partition OS, like
POK/AIR, that offers the inter-partition services for a
fully-compatible ARINC-653 solution.

-Gedare

[Julien Delange]

On Thu, Mar 15, 2012 at 6:44 PM, WL <jolk...@gmail.com> wrote:
> This is all valuable stuff, and the topic is getting more interesting
> by the minute. I see that this would somewhat pick up where a last
> year's GSoC project left off. Is the student still active in the
> community? If not ,did he leave his work in a useable state? I'd like
> to contact him since there's no need to do the same research again and
> come to conclusions which have already been arrived at.

Hello,

Please have a look the the links below. Also, the whole project has
several goals :
1. Implement ARINC653 services in RTEMS. If you consider RTEMS only,
you can only design intra-partition services (tasks, intra-partition
comm. , etc ...). This is described in [3].
2. Implement a prototype of a hypervisor to execute several RTEMS
instance in different partitions (see proposal [4]). In that case, the
work consists in (1) design a first prototype to execute RTEMS in
several partition and (2) adapt RTEMS to call the hypervisor services
for inter-partitions interactions. Once that is done, we can also
implement ARINC653 inter-partitions services.

So, implementing full ARINC653 compliance for RTEMS would require to
do both tasks. The second project is more difficult but has more
priority since this would be the fundation for building partitions
using RTEMS. In addition, making the partitioned-bsp of RTEMS would be
really tricky because it has to be as much generic as possible to fit
with other separation kernel approaches (as AIR, XtratuM or POK).

As far as I know, the GSOC 2011 project focuses on the second item of
the work. It was based on AIR but unfortunately, it does not seem
available (you can check on http://air.di.fc.ul.pt/). However, the
report of this work is available as gdoc documents, you have to
request access to it, links to ask are located on page [2]. Also, Joel
may have more information about the status of the 2011 GSOC project
related to this topic.

Hope that helps,

[1] http://wiki.rtems.org/wiki/index.php/RTEMSHyperVisor
[2] http://wiki.rtems.org/wiki/index.php/RTEMSSummerOfCode2011
[3] http://wiki.rtems.org/wiki/index.php/ARINC653API
[4] http://wiki.rtems.org/wiki/index.php/RTEMS_Paravirtualization

[张文杰]

Hi, all:
    I am the student who implement the GSOC2011 project hypervisor for RTEMS.
In my original proposal i wanted port the linux to the RTEMS paravirtualization hypervisor
named AIR. But as the progress of project, the plan had changed into adapt the
lastest RTEMS to the AIR hypervisor. So what i did is make the lastest RTEMS run
under AIR successfully which contains a paravirtualization RTEMS kernel named
POK. If you want to know any information please free to contact me

[Joel Sherrill]

On 03/16/2012 09:14 AM, 锟斤拷锟侥斤拷 wrote:

Hi, all:
    I am the student who implement the GSOC2011 project hypervisor for RTEMS.
In my original proposal i wanted port the linux to the RTEMS paravirtualization hypervisor
named AIR. But as the progress of project, the plan had changed into adapt the
lastest RTEMS to the AIR hypervisor. So what i did is make the lastest RTEMS run
under AIR successfully which contains a paravirtualization RTEMS kernel named
POK. If you want to know any information please free to contact me

:) We are very interested. I didn't realize that AIR used Pok. Since I couldn't
get access to AIR, I was refocusing on Pok.  Julien Delange is responsible for
Pok. 

We would like to see RTEMS as a proper client under Pok and eventually
support the ARINC-653 API that way.  So getting your BSP into proper shape
on the RTEMS head and making sure others can run it is a BIG deal.
From there, we can begin to support other architectures supported by Pok
and provide application level ARINC services.

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.s...@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

[张文杰]

Hi Joel, I am very sorry for making you mistake. That AIR use PMK instand of
POK. PMK is hyper visor kernel which response for scheduling. 

在 2012-03-16 23:14:29，"Joel Sherrill" <joel.s...@oarcorp.com> 写道：

[Cláudio Silva]

Hi,

张文杰 mistyped. AIR is based on PMK and not on POK.
If i remember correctly the developed BSP was not included in RTEMS
because it included changes to other "places" than just libbsp.

I personally agree with Julien, The best project for RTEMS is to
provide a hypervisor-independent paravirtualization layer to which
several hypervisors can attach to. The student shall determinate which
points in RTEMS source need to be virtualized through hypervisor
calls. The best way to achieve this is through porting RTEMS to POK
and by analyzing AIR RTEMS's patch (available in 张文杰 delivery).

Part of the ARINC653 API (processes, time management, buffers,
blackboards, semaphores, events and partially error handling) can be
provided without an underlying Hypervisor. The remaining services
(health monitoring, ports and partition management) can be abstracted
to the services provided by any underlying hypervisor. You can also
include the ports service in standalone mode if you map the ARINC
ports to UDP ports (but then you need to use the ip stack...) [i see a
possible use case of this if someone wants to use pseudopartitions on
a distributed ARINC653 system].
I think this ARINC653 API project is more feasible than the
paravirtualization one and also fits best on a GSOC timeline.

Regards,
Cláudio

2012/3/16 Joel Sherrill <joel.s...@oarcorp.com>:

[Joel Sherrill]

On 03/16/2012 11:22 AM, 锟斤拷锟侥斤拷 wrote:

Hi Joel, I am very sorry for making you mistake. That AIR use PMK instand of
POK. PMK is hyper visor kernel which response for scheduling. 

OK. Doesn't change the basic premise of my response.

+ Your work needs to be in a state to merge.
+ We need to reproduce your testing independently.
+ Paravirtualized BSPs are good things.
+ Pok support is desirable.
+ ARINC-653 support is desirable.
+ Is there a way to have a paravirtualized BSP which
   could run on different hypervisors?

The last point is easy to gloss over but is desirable because
then we would only have one BSP to support long term. Even
if some code differed, structuring the BSP to make this happen
would be of benefit.

--joel

锟斤拷 2012-03-16 23:14:29锟斤拷"Joel Sherrill" <joel.s...@oarcorp.com> 写锟斤拷锟斤拷

[Joel Sherrill]

Well stated Claudio.

I am not sure about the time required for an ARINC-653 API
versus the paravirtualization project though.

To be done correctly, the API task one would need to have
access to the standards, implement the APIs, implement
full coverage tests of those APIs, and write a manual.
The API would need to be implement as a peer with the
Classic and POSIX threading APIs not as a wrapper. That
increases the complexity some. It may involve tinkering
with Score capabilities if they do not map directly into
ARINC 653 services.

All of the above is just to meet the minimum technical goal.
IMO an ARINC-653 API implementation would also need to
address requirements traceability from the standard to
code and tests so we meet the best practices expected by
users in the ARINC 653 community.

In contrast, the paravirtualized BSP could be restricted
to ensuring that the AIR BSP from last year works on both
AIR and Pok using a common BSP. And that the layering
and compartmentalization you describe is proper. There is
some documentation and test required here but not near
as much. And the requirements traceability is not as critical.

--joel

[Cláudio Silva]

In the paravirtualization project you need to account for several
complex things. e.g. memory model of the underlying hypervisor,
removing supervisor mode "things", interrupt virtualization, etc. This
gets even more complex if you want a hypervisor-independent layer/BSP
and different HW architectures.

I feel that the key point for RTEMS in this project is hypervisor
independence. Focusing on only one hypervisor is wrong.
Besides this, I also think that the role of providing these
BSPs/Layers should be from those who develop the hypervisors. They
should contribute the changes they made to RTEMS or at least make them
available even if not "merged" to RTEMS.

Now regarding the ARINC 653 API implementation. Most of the services i
mentioned in my previous email have almost perfect correspondence with
RTEMS or POSIX services already available. Therefore even if you don't
want the ARINC653 API implemented as a wrapper to the classic API,
there would be a lot of code reusable from other APIs.
In a quick overview (i am probably missing somethings) :
- Processes: ARINC processes are priority based. There are periodic
and aperiodic processes. The process period is given when the process
is created and then the process can do such things as
"periodic_wait()" to sleep and only be awaken at next periodic release
point. Although there is no direct match to the classic or posix API,
this implementation shouldn't prove very hard.
- Time Management: Services to obtain monotonic time with nsec
precision (similar to rtems_clock_get_uptime()), to wait for an amount
of time (similar to rtems_task_wake_after()) and related to process
periodicity (periodic_wait and replenish) .
- Buffers: Message queues (FIFO) of a given size. Processes can block
in them and are awaken in priority or FIFO order.
- Blackboards: Single message queue. One writer, several consumers.
Reading processes can block and are all awaken at the same time on
write.
- Semaphores. Counting Semaphore (priority or FIFO). Similar to
rtems_semaphores.
- Events. These are similar to binary conditions. (similar to
pthread_cond / cond_broadcast)
- Error Handling: This would need to be better analyzed.

In my opinion a good GSOC project would be implementing (and
merging!!) these services and providing documentation . If there is
time remaining one could start to approach coverage.
I think that for the "ARINC 653 community" it only makes sense to
test the full system, and for that you require an underlying
hypervisor. The"ARINC 653 community" generally has the resources to do
their own validation testing.

Regarding the standard availability, maybe the student can obtain it
at his university library..

(sorry for the long text :P)
Cláudio.

2012/3/16 Joel Sherrill <joel.s...@oarcorp.com>:

[Gedare Bloom]

On Fri, Mar 16, 2012 at 3:14 PM, Cláudio Silva <claudio...@gmail.com> wrote:
> In the paravirtualization project you need to account for several
> complex things. e.g. memory model of the underlying hypervisor,
> removing supervisor mode "things", interrupt virtualization, etc. This
> gets even more complex if you want a hypervisor-independent layer/BSP
> and different HW architectures.
>
> I feel that the key point for RTEMS in this project is hypervisor
> independence. Focusing on only one hypervisor is wrong.
> Besides this, I also think that the role of providing these
> BSPs/Layers should be from those who develop the hypervisors. They
> should contribute the changes they made to RTEMS or at least make them
> available even if not "merged" to RTEMS.
>

Agreed. Paravirtualization ought to factor out the
privileged/protected instructions and provide an RTEMS interface that
can wrap hypercalls to whatever VMM will be used. The specifics of the
hypercalls should be pluggable for any particular hypervisor.

This sums up things nicely, although the amount of work might be large
for a gsoc project.

[Jérôme Hugues]

Le 16 mars 2012 à 20:14, Cláudio Silva a écrit :

> Now regarding the ARINC 653 API implementation. Most of the services i
> mentioned in my previous email have almost perfect correspondence with
> RTEMS or POSIX services already available. Therefore even if you don't
> want the ARINC653 API implemented as a wrapper to the classic API,
> there would be a lot of code reusable from other APIs.

Note that ISI@Vanderbilt implemented an emulation library for ARINC on top of POSIX,
see https://wiki.isis.vanderbilt.edu/mbshm/index.php/ACMTOOLSUITE

(You need to be careful about what you build, a part of it drags the whole TAO middleware, be sure to test just the ARINC part)

it can be a first step towards supporting this API in RTEMS

a) first you port it. they support part of the standard. Partitions are mapped to Unix processes, a daemon activate/passivate process to support time isolation. One can certainly emulate similar behavior using a dedicated thread that change task proporties to enable/disable them

b) then the port work may start, following the overview proposed by Cláudio. Starting from this emulation library would help understanding in more depth the amount of work required.

Regards

[WL]

Your last year's project deliverables include obtaining the AIR source
and creating a document describing it's API for the guest system
having in consideration the posibility to map paravirt-ops' functions
to it. Can you forward me both these things? What is the license on
AIR?

If anyone feels that from now on, this conversation should move from
this list to private email exchange, please say so.

On Fri, Mar 16, 2012 at 10:14 PM, 张文杰 <1577...@163.com> wrote:
> Hi, all:
>     I am the student who implement the GSOC2011 project hypervisor for
> RTEMS.
> In my original proposal i wanted port the linux to the RTEMS
> paravirtualization hypervisor
> named AIR. But as the progress of project, the plan had changed into adapt
> the
> lastest RTEMS to the AIR hypervisor. So what i did is make the lastest RTEMS
> run
> under AIR successfully which contains a paravirtualization RTEMS kernel
> named
> POK. If you want to know any information please free to contact me

_______________________________________________

[Gedare Bloom]

On Sat, Mar 17, 2012 at 5:32 AM, Jérôme Hugues <hugues...@gmail.com> wrote:
>
> Le 16 mars 2012 à 20:14, Cláudio Silva a écrit :
>
>> Now regarding the ARINC 653 API implementation. Most of the services i
>> mentioned in my previous email have almost perfect correspondence with
>> RTEMS or POSIX services already available. Therefore even if you don't
>> want the ARINC653 API implemented as a wrapper to the classic API,
>> there would be a lot of code reusable from other APIs.
>
> Note that ISI@Vanderbilt implemented an emulation library for ARINC on top of POSIX,
> see https://wiki.isis.vanderbilt.edu/mbshm/index.php/ACMTOOLSUITE
>

From a technical perspective using this software would depend on how
much of POSIX is required, because RTEMS lacks some certain features
especially those related to processes. More important however is that
the license does not seem to comply with rtems in particular the last
sentence of section 1.3.

-Gedare