offtop: ARINC 653 compatible RTOS and RTEMS

[Joel Sherrill]

On Aug 4, 2017 12:37 PM, "Denis Obrezkov" <denisobrezkov at gmail.com> wrote:

2017-08-03 20:39 GMT+02:00 Joel Sherrill <joel at rtems.org>:

> Crap.. hint send too early.
>
> Deos has a 25 year heritage and came from Honeywell commercial
> avionics. It is Level A flight certified. That is the highest level. We
> have an arrangement to do the FACE Conformance formal validation.
>
> At this point, RTEMS is successfully working in a partition there
> with shared memory across partitions, correct time, and the
> RTEMS tests looking good on x86. PowerPC and ARM will come
> soon. We are working through the network and A653 sampling
> and queuing port integration now.
>
> This should be a flyable, deployable product in an airplane.
> But all of the generic RTEMS infrastructure for paravirtualization
> required is in the main tree.
>
> But I would really love to see a complete open source A653
> solution with RTEMS in a partition. AFAIK Pok is the best path
> to that.
>
> DonnerWorks has a Xen based solution but that is heavier
> than I would like to see and I don't know how much source
> they have released.
>
> --joel
>
> On Thu, Aug 3, 2017 at 1:34 PM, Joel Sherrill <joel at rtems.org> wrote:
>
>> This is an interesting question on multiple fro6nts. :)
>>
>> We have had projects in the past which have worked with RTEMS
>> and the open source ARINC 653 implementation Pok. There was
>> some success on the i386.
>>
>> The first time we tried this was with an "open source" implementation
>> named "AIR". It was a GSoC project and AFAIK they never released
>> any source for AIR. This is a random presentation on that:
>>
>>
>>
>>
>> There are multiple hypervisors/A653 environments in Europe.
>>
>> I am currently working with a Deos developer to have Deos+RTEMS
>> meet the FACE Technical Standard. This TS is a combination of
>> POSIX and ARINC 653. Some partitions can have POSIX with
>> certain A653 services. The native A653 partitions are unmodified.
>> I have been on this standards body for six years representing a
>> customer and currently lead the Operating System Segment group.
>> This was our first paper which highlights the approach and plan.
>>
>> http://face.intrepidinc.com/wp-content/uploads/2016/01/DDC-I
>> -OAR-A-Unique-Approach-to-FACE-Conformance.pdf
>>
>>
>>
>> On Thu, Aug 3, 2017 at 11:20 AM, Denis Obrezkov <denisobrezkov at gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> some time ago I worked in avionics and found out that there is
>>> quite a big trend towards certifiable OSes. But there are quite a few
>>> open-source systems supporting, for example, ARINC 653 interface.
>>> So, I have a question, is it possible to implement ARINC 653 support
>>> in RTEMS and to what extent?
>>> I have seen that ARINC 653 support was one of the possible themes
>>> for a GSoC project.
>>>
>>> --
>>> Regards, Denis Obrezkov
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>>
>>
>>
>
>From ARINC 653, I can see that its API is not very huge. And since I work
with RISC-V
and it is designed with virtualization support in mind, I am also
interested, how hard
will it be to implement a microkernel on top of RTEMS BSP?


It may be possible but I think the core developers and folks looking at
this have tended to land on RTEMS paravirtualizsd on top of a host with VM.

It is likely possible but how intrusive it is to the main RTEMS source is a
question to be answered. This has always concerned us.




Also, since one of our current GSoC projects is about Couverture support,
what do you
think about other related project - Frama-C?


I would be more than happy to see free tools like Frama-C supported in our
host environment. The more bugs found this way the better.

The challenge is ways finding someone to look at the reports. :)



-- 
Regards, Denis Obrezkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170804/e50c938e/attachment-0002.html>