NASA Draws On Open Source For Shuttle Bug-Tracking

thefickler writes "NASA has built a new software package to track problems with the Space Shuttle using open source tools from Mozilla. '[Alonso Vera, the lead of the Ames Human-Computer Interaction Group] wouldn't say exactly how much the new systems cost to build, but he said they were an order of magnitude cheaper than what was being used before, closer to $100,000 than the $1 million it would have cost in the past.' The Space Shuttle Endeavor launched successfully on Friday, so the new system is being used to track any problems which may crop up in the current mission. As one commentator pointed out, 'A system like this could save more than money; it could save lives.'"

Comments

PHLEGM already taken...

[mach1980]

The name of the system sure sounds as from a dilbert strip: "Problem Reporting Analysis and Corrective Action (PRACA)"

Re:Good Company

[invisiblerhino]

A lot of science uses open source tools anyway, so this is only news in that it'll draw the public's attention to it. At CERN, the data analysis package (ATHENA) I worked on had a Python front end, used gnu tools (gcc, gdb), expressly encouraged physicists to use valgrind etc. I've forgotten how bug tracking worked, but I'm pretty sure it was something like Bugzilla. I'm not sure about the status (open source or not) of the full analysis package, but other stuff to come out of CERN (CERNLIB, Geant3) has been. It's all good.

Re:Hopefully this is only the beginning.

[pnewhook]

RTA - it was to replace a large number of proprietary databases spread across numerous subcontractors with a single common solution hosted locally at NASA. It saves costs and time, but not lives.

Re:Hopefully this is only the beginning.

[cyclone96]

I understand your point, however this particular software is basically a system for tracking vehicle "funnies" on the ground, it's not something that is in the loop of the vehicle flight software or something used to make critical decisions. The old system is pretty dated and unwieldy to use (I've used it, I work for NASA). We're obligated to try out cheaper alternatives to custom code to see if it works for us without compromising what we are trying to do.

Sometimes it does work for us - the Mission Control Center workstations and the onboard command and control laptops on the Space Station were all recently converted to Red Hat. It is in many ways better than the old proprietary unix solutions because with the source it's easy to do our own mods to the software. We still test the daylights out of it since that is critical software, but it's a lot easier to support since we have the source code and can do our own bug in-house bug investigations, patch it, or rip out things we don't want/need.

Re:Why not publish the source online?

[JetScootr]

Perhaps I was a bit snarky there...sorry.
I work in the astronaut training facility, on simulation software. Loosely, I'd categorize the code like this:

• simulation 'infrastructure' or 'framework' (ie,realtime game engine,graphics,network/shared memory protocols,etc) .. (Requires knowledge specific to computational hardware, i/o devices, etc of the simulator itself)
• Model software, such as payload X or onboard system Y
  (Requires specific aerospace tech knowledge)
• Math, like equations of motion, mass properties, ephemeris, etc. (Requires rocket scientist)
• Non-simulation support software, such as S/W CM, bug tracking, distribution software, process mgt s/w, etc .. (Requires paperwork-procedure-specific knowledge)
• Maybe miscelleanous, but none comes to mind right now.

Bringing a good programmer up to speed on all this stuff takes several months. The math is the only part I'd think a good coder could analyze witout domain-specific knowledge. That was written,vetted and frozen decades ago (except ephemiris, Fischer stuff *should* get updated infrequently).