ARINC-653 API

Fri Mar 16 19:14:09 UTC 2012

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.sherrill at oarcorp.com>:
> 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
>
> On 03/16/2012 11:31 AM, Cláudio Silva wrote:
>> 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.sherrill at oarcorp.com>:
>>> 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.
>>>
>>> At 2012-03-16 06:47:16,"Julien Delange" <julien.delange at gmail.com> wrote:
>>>> On Thu, Mar 15, 2012 at 6:44 PM, WL <jolkaczad at 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
>>>> _______________________________________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.org
>>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>
>>>
>>>
>>>
>>> --
>>> Joel Sherrill, Ph.D.             Director of Research&  Development
>>> joel.sherrill at OARcorp.com        On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>>     Support Available             (256) 722-9985
>>>
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>
>
>
> --
> Joel Sherrill, Ph.D.             Director of Research&  Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985
>
>