[svlug] open source avionics in Ares I

Edward Cherlin echerlin at gmail.com
Tue Jan 22 12:36:44 PST 2008


On Jan 5, 2008 5:36 PM, Rick Kwan <kwanrj03 at comcast.net> wrote:
> Hi all,
>
> Following a tip to the article cited below, I managed to engage a
> few aerospace computing professionals across the country on what this
> may mean.
>
> Title:  NASA Will Tinker With Open-Source Rocket for Return to Moon
> Author:  Alex Hutchinson
> Date:  Dec. 12, 2007
> URL:  http://www.popularmechanics.com/science/air_space/4236758.html
>
> When I asked about it, we were told the rationale is that NASA's
> Constellation is a roughly a 30 year program.  Ares I is a launch
> vehicle which would put humans into orbit.  The Ares I team wants to
> ensure that the avionics code is maintainable even if a particular
> vendor goes out of business.  (This decision only applies to Ares I,
> not Constellation in general.)

Before we get to the development stage, we have to ask whether there
is a fully Free certified avionics-grade Linux. I tend to doubt it. I
worked at LynuxWorks some years ago on their DO-178B-certified
software documentation. This page gives a useful introduction to the
issues.

http://www.lynuxworks.com/solutions/milaero/do-178b.php3

Here is the LynxOS-178 product page. http://www.lynuxworks.com/rtos/rtos-178.php

If NASA would be willing to fund development and certification of a
Free avionics-grade Linux, go for it! The question then is how to get
changes certified in a reasonable and timely manner.

The Feds are making some progress on this issue:
http://www.electronicsweekly.com/Articles/2006/04/12/38189/linux-makes-reusable-software-in-avionics.htm

The recent Federal Aviation Administration (FAA) reusable software
component (RSC) software acceptance procedures provide the approach
and documentation necessary for systematic reuse of software
components that meet RTCA/DO-178B...

To meet DO-178B, it is estimated that for every line of code there
will be 5 - 10 lines of tests, and for every two lines of code there
will be one signature on some review form. In addition, there is
normally one requirement for every 5-10 lines of code. In an extreme
example, in the 1980s a one-line change to the OFP on the Space
Shuttle cost nearly $1m.

Using the RSC process, standalone software components can be accepted
by the FAA as meeting DO-178B objectives across hardware platforms,
allowing for "portable" certification.

> Reactions of my colleagues have ranged from curiosity and skepticism
> to "government use rights" do pretty much the same thing.

>From a very narrow perspective, some of the same things, but in the
broader sense, LOL.

> Frankly, we
> still don't have all the specifics; we expect that one of the folks has
> access and will straighten us out.  I've been pondering OSS avionics
> with human life at stake in my own free time for a couple of years.

"When reporters asked Shepard what he thought about as he sat atop the
Redstone rocket, waiting for liftoff, he had replied, 'The fact that
every part of this ship was built by the low bidder.'"

"I felt about as good as anybody would, sitting in a capsule on top of
a rocket that were both built by the lowest bidder." (Senator John
Glenn, Colonel USMC, Retired)

"It's a very sobering feeling to be up in space and realize that one's
safety factor was determined by the lowest bidder on a government
contract." -- Alan Shepard.

> I sent the following two points to my friends today.
>
> --------
> 1. The OSS community likes to say "given enough eyeballs, all
> problems are shallow" or something to that effect.  This is how
> projects like Linux, Apache, and other keep the quality up.  It also
> assumes that the eyeballs understand the problem space.  It seems to
> me, the narrower the problem space, the harder it is to find qualified
> eyeballs.  Part of why device drivers are so hard is because device
> behavior is often not well understood.  (Conversely, the OSS community
> loves manufacturers that open their hardware interface specs.  A
> similar thing would have to happen for OSS avionics.)

NASA's biggest bugs are in management. Would opening up development
create a wider community of people who actually knew what the safety
factors were for a given launch?

> 2.  Sweat equity.  In the strictest sense, OSS source code only needs
> to be delivered to the software's users.  However, it does provide a
> context and good starting point for the uninitiated.  Individual
> developers will often develop their expertise in an area by studying
> someone else's source code.  (Of course, this comes as no surprise,
> since that's how software maintenance works.)  Lots of OSS projects
> have readers that the project originators are completely unaware of.
> But it certainly works a lot better when there are forums, FAQs, etc.

This would have immense benefits for private spaceflight.

> --------
> Before I get into the next round of discussion, I'd like to give people
> here a chance to shoot me down, or elaborate further.
>
> Last year, the group published a set of guidelines for the use of
> commercial off-the-shelf software in mission critical systems (specifically
> in aerospace).

Link? I get over 100,000 hits for  nasa cots guidelines .

This article discusses some of the problems in the context of using
Linux for scientific missions.
http://www.linuxdevices.com/news/NS5714800202.html

> Naturally, I asked how OSS fit in the picture.  We didn't
> answer that in the current edition. But there is a very strong likelihood
> that we'll do it this time.
>
> --Rick Kwan

-- 
Edward Cherlin
End Poverty at a Profit by teaching children business
http://www.EarthTreasury.org/
"The best way to predict the future is to invent it."--Alan Kay




More information about the svlug mailing list