Open Source Satellite Control

Debra writes "Have you ever wondered how you harness a satellite control system written in three languages, on four development platforms, and deployed to multiple client environments? With open source, naturally. When one wrong move can cost millions, you must rely on teamwork, smart design, and open standards to keep the project -- if not the satellite -- from going down in flames. This article covers software engineering basics, taking advantage of outside solutions, and scripting multi-million-dollar manuvers."

Comments

Reliability?

[delta407]

Open source software is plenty stable -- when it's mature. But, when "one wrong move can cost you millions", can you afford a kernel oops because someone forgot a \n?

See, in this case, the nice part about commercial software is that you have someone to blame, and you at least stand a chance in court (IANAL, but it would be under contract law), so you have an opportunity to recoup your losses. In this case, an "oh yeah, fixed in CVS" isn't good enough.

BSOD=Blazing Satellite Of Death

[Anonymous Coward]

Did I see a Windows screenshot? Fer crissakes, people. If you want a decent satellite ops program, use OASIS. CCSDS compliant, multi-mission, multi-terminal, UN*X-based... None of this Java and Windows namby-pamby ops software. Yeesh.

NASA, Tcl/Tk and Perl

[ghostlibrary]

Actually, NASA satellite ops often uses generalized environments (was it called MOPS?) and mix contractor-produced customerware with in-house software or scripting. Then, use Perl to create stuff after launch that was needed, or to make stuff web-accessible (internal network only, sorry).

Perl and Tcl/Tk are still popular (Tk for GUIs, Tcl or Perl for scripting).

It's not GPLed open source but, within NASA, it is open source.

Many missions are trying to move away from the 'custom designed only-works-for-us' software because it becomes rapidly dated.