offtop: ARINC 653 compatible RTOS and RTEMS

[Denis Obrezkov]

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

>
>
> 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.
>
Oh, I don't propose to do change the mainline kernel - RTEMS has its own
ideology and goals. I as any embedded developer
want to implement some tiny hobby OS. But I am too lazy to rewrite a BSP
layer.

>
>
>
>
> 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 problem with this question as I can see it is that some very small
subset of the kernel should be defined, analyzed and constrained with
specifications.
That's why I am especially interested in small microkernels - I think they
are a bit easier to verify.



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