Space Qualified RTEMS
Joel Sherrill
joel.sherrill at OARcorp.com
Wed Jan 25 17:26:23 UTC 2012
On 01/25/2012 11:15 AM, Thomas Doerfler wrote:
> Johan,
>
> thank you for your interesting post.
>
> Am 25.01.2012 16:38, schrieb Zandin Johan RUAG N:
>> Thomas: Very good points! I think they should be discussed with ESA and with both
>> minor an major RTEMS users in the European space industry.
> Up to now our problem is, that we couldn't get in touch with anyone
> responsible for the missions OS inside the ESA or in the inner circle of
> the european space industry. So any hints/recommendations/activities
> changing this situation are heartily welcome ;-)
>
Agreed 100%!!!
RTEMS requirements are user driven
>> In the numerous RTEMS projects I have worked, our intention has definitely been to
>> report all detected problems upstream and some of the differences between the
>> "space qualified" versions and the RTEMS main branch can probably be solved by
>> properly committing patches upstream.
>>
>> But other ones would probably have a larger impact on the RTEMS main branch if
>> they should be integrated there, e.g. adding configuration options to strip away
>> unused code (to save memory space, to avoid accidental execution and to minimize
>> the amount of code to qualify). That of course has to be discussed in the RTEMS
>> community too.
> It really depends on the type of midification needed. When a severe
> change to the RTEMS core is required, the community might find different
> solutions, so a sort of a discussion process will take place, but my
> experience is that if one user/application has urgent needs to modify
> the RTEMS sources, many others may appreciate this modification
> (allthough this might not have been such a heavy problem for them..).
>
Agreed.
Sometimes we also may see a way to solve the problem that
provides more payoff. Or reduces the maintenance burden.
For example, we could have found a way to hack in a single
SMP-aware thread scheduling algorithm. But I insisted on a
pluggable scheduler interface. Now we have four single core
scheduling algorithms to choose from including the traditional
deterministic priority one, Earliest Deadline First and Constant
Bandwidth Server. Plus since they are pluggable, the user can
write a new algorithm. This will be important as we learn more
about embedding SMP cores.
> Saftey-critical of "too expansive to fail" applications are getting more
> and more common, so it is not only the space applications which require
> a lean, qualified system. So the ESA requirements will not be SO exotic
> that upstream RTEMS would simply reject all changes in that direction.
>
It is actually quite scary how many embedded systems you
encounter during a day and how many of them could fail
in a way that could result in harm. Even a street crossing
signal which is out of sync with the traffic signals is potentially
deadly. <shudder>
And Thomas warned me years ago about being careful
not to step in front of a tram line in Munich without looking. :)
> wkr,
>
> Thomas.
>
>>
>>
>> Best regards
>> Johan Zandin
>>
>> -----------------------------------------------------------
>> Johan Zandin Software Engineer
>> RUAG Space AB Phone: +46-31-735 41 47
>> SE-405 15 Gothenburg, Sweden Fax: +46-31-735 40 00
>> -----------------------------------------------------------
>>
>>
>>> -----Original Message-----
>>> From: rtems-users-bounces at rtems.org
>>> [mailto:rtems-users-bounces at rtems.org] On Behalf Of Matthews, Lee
>>> Sent: den 25 januari 2012 10:52
>>> To: 'Thomas Doerfler'; rtems-users at rtems.org
>>> Subject: RE: Space Qualified RTEMS
>>>
>>> Thomas, Cláudio,
>>>
>>> Thank you for your feedback. Thomas you note that the RTEMS
>>> community has contributed to many space missions. Could you
>>> please give me some examples of any previous (or upcoming)
>>> missions that use RTEMS, particularly version 4.10. This will
>>> give me an idea of heritage and provide me with some leverage
>>> if ever ESA decides to try and force version 4.8 upon us.
>>>
>>> Thanks again.
>>>
>>> Best wishes,
>>> Lee
>>>
>>> -----Original Message-----
>>> From: rtems-users-bounces at rtems.org
>>> [mailto:rtems-users-bounces at rtems.org] On Behalf Of Thomas Doerfler
>>> Sent: 24 January 2012 17:13
>>> To: rtems-users at rtems.org
>>> Subject: Re: Space Qualified RTEMS
>>>
>>> Hi Lee, hi all,
>>>
>>> First of all: the RTEMS commmunity is proud to have contributed to so
>>> many space missions. AFAIK at least the NASA projects had
>>> returned their
>>> share of code improvement to RTEMS, which is a benefit to all future
>>> users (including future NASA missions).
>>>
>>> Your set of questions significantly emphasises the problem with those
>>> "pull everything, commit nothing" projects like the ESA "space
>>> qualified" RTEMS kernel.
>>>
>>> It is nice and vital for the ESA space community to have a qualified
>>> RTOS, which also supports the space specific platforms like ERC32/LEON.
>>> But those "read-only" activities are all prone to severe bit rot.
>>>
>>> Since RTEMS 4.8, there were severe improvements to the system:
>>> - many bugs were identified and eliminated
>>> - new features were added
>>> - support for up-to-date hardware was added (and this is what you ask
>>> for in your mail)
>>> - siginificant activities were launched to improve code quality, like
>>> extensions to the test sets, automated code coverage analysis
>>> and others.
>>>
>>> You will not have access to these improvements, because the "space
>>> qualified" RTEMS has not been merged back into the main RTEMS
>>> repository.
>>>
>>> -------------------------
>>>
>>> I have a scenario in mind:
>>>
>>> - Let's say that during a certain test configuration late in the
>>> development cycle, my system will fail
>>>
>>> - the reason for the failure can be tracked down to an OS bug (which is
>>> unlikely, but may happen in every piece of software)
>>>
>>> - I or my colleagues will find out that the bug has long been
>>> identified
>>> and fixed in RTEMS
>>>
>>> - but I am using a "space qualified" version of RTEMS, which
>>> has the bug
>>> still in it...
>>>
>>> ... this would really bother me. Almost every software has minor bugs.
>>> But using an old release of a software, which, due to the develpoment
>>> model selected, does not care about improvements and fixes in the main
>>> source tree may be regarded rather careless...
>>> -------------------------
>>>
>>> What I really long to see is to have these space qualification related
>>> modifications to RTEMS be integrated back into the main RTEMS
>>> repository, because that's how Open Source software works:
>>>
>>> If all users share their OS software knowledge, every user can partake
>>> in the whole collected knowledge.
>>>
>>> Just my two cents,
>>>
>>> Thomas.
>>>
>>>
>>> Am 24.01.2012 16:41, schrieb Matthews, Lee:
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I'm developing software that uses RTEMS on an Aeroflex
>>> Gaisler LEON3FT
>>>> processor that is running on a Pender GR-CPCI-AX2000
>>> development board.
>>>> I am using version 4.10 of RTEMS and RCC 1.1.99.19.
>>>>
>>>>
>>>>
>>>> We are working on producing a Magnetometer instrument that will be
>>>> integrated into ESA's upcoming Solar Orbiter mission to the Sun. We
>>>> shall be using RTEMS on our Leon3FT CPU. Having just gone
>>> through ESA's
>>>> Preliminary Design Review process, it has been highlighted
>>> by ESA that
>>>> there is a space qualified version of RTEMS available, though this is
>>>> currently based on version 4.8 of the kernel. I believe this is being
>>>> developed by the company Edisoft (http://rtemscentre.edisoft.pt).**
>>>>
>>>>
>>>>
>>>> I have a few questions about this :
>>>>
>>>>
>>>>
>>>> 1) Does anyone know what the difference is exactly between
>>> a "standard"
>>>> and a "space qualified" version of RTEMS ?
>>>>
>>>> 2) Assuming that we were to use the space qualified RTEMS
>>> 4.8 kernel,
>>>> would we still be able to use Aeroflex Gaisler's BSP (RCC
>>> 1.1.99.19) ?
>>>> 3) Would Aeroflex Gaisler's BSP also need to be space qualified ?
>>>>
>>>>
>>>>
>>>> Thanks in advance.
>>>>
>>>>
>>>>
>>>> Best wishes,
>>>>
>>>> Lee Matthews
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.org
>>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>
>>> --
>>> --------------------------------------------
>>> Embedded Brains GmbH
>>> Thomas Doerfler Obere Lagerstr. 30
>>> D-82178 Puchheim Germany
>>> email: Thomas.Doerfler at embedded-brains.de
>>> Phone: +49-89-18908079-2
>>> Fax: +49-89-18908079-9
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>
>> _______________________________________________
>> 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
More information about the users
mailing list