<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi all,<br>
<br>
We are currently developing a mass memory (PDHU) for the GAIA and
Earthcare satellites. Both of them use RTEMS.<br>
<br>
While reading the other answer in this chain I wondered something;
On the GAIA satellite I think we used the 4.6 version (devlopement
started a while ago) but Earthcare is a newish project on which we
are going to use the validated RTEMS 4.8 the original poster is
talking about. I totaly agree with Thomas Doerfler that using a 4.8
version when the current is 4.10 is not optimal but we were strongly
advised by ESA to use the Edisoft RTEMS validation suite. I'm
wondering what was the arguments and approach of the two previous
persons who are working with a 4.10 version? Did you have to
validate RTEMS yourself or was the ESA okay for you to use it as is?
I'm really curious about this. ;)<br>
<br>
Léonard<br>
<br>
On 25.01.2012 10:51, Matthews, Lee wrote:
<blockquote
cite="mid:92DD1990DC437C4B969E5AADA8ED8DF608CD02@icexch-m3.ic.ac.uk"
type="cite">
<pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:rtems-users-bounces@rtems.org">rtems-users-bounces@rtems.org</a> [<a class="moz-txt-link-freetext" href="mailto:rtems-users-bounces@rtems.org">mailto:rtems-users-bounces@rtems.org</a>] On Behalf Of Thomas Doerfler
Sent: 24 January 2012 17:13
To: <a class="moz-txt-link-abbreviated" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a>
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:
</pre>
<blockquote type="cite">
<pre wrap="">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 (<a class="moz-txt-link-freetext" href="http://rtemscentre.edisoft.pt">http://rtemscentre.edisoft.pt</a>).**
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
<a class="moz-txt-link-abbreviated" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a>
<a class="moz-txt-link-freetext" href="http://www.rtems.org/mailman/listinfo/rtems-users">http://www.rtems.org/mailman/listinfo/rtems-users</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
Léonard Bise<br>
Software Engineer<br>
Phone: +41 (0)32 338 9902<br>
E-mail: <a href="mailto:leonard.bise@syderal.ch">leonard.bise@syderal.ch</a><br>
<br>
SYDERAL SA<br>
Neuenburgstrasse 7<br>
CH-3238 Gals (Switzerland)<br>
<br>
Desk: +41 (0)32 338 9800<br>
Fax: +41 (0)32 338 9934<br>
Web site: <a href="http://www.syderal.ch">http://www.syderal.ch</a><br>
</div>
</body>
</html>