Python and spacecraft onboard or ground control scripting

Peter Hansen peter at engcorp.com
Wed Apr 10 21:01:55 EDT 2002


Don Garrett wrote:
> 
> "M. J. Mix" wrote:
> >
> > Is anyone using Python as a spacecraft ground system scripting
> > language, or onboard (embedded) language?
> >
> > Pros and cons when compared with TCL or JAVAScript.  Just
> > some real life, honest opinions.
> 
>   I'm not aware of ANY scripting languages that have been developed in a manor
> suitable for life critical fail-safe situations. I like Python a lot, and find
> it very reliable for day to day stuff, but I'd hate to have it embedded in my
> pace maker. 

Agree.  Unsuitable for pacemakers, or any other life-critical
application, at this time.  Not inherently unsuitable mind you.

> I also don't think it's suitable for serious real-time processing.

Don't agree at all.  Python is completely suited for real-time processing
if you can handle two constraints: it is not as fast as some other 
languages, so you have to accept latency on the order of milliseconds to
seconds as opposed to microseconds, and no one (to my knowledge) has
done a thorough analysis of the performance characteristics of the
interpreter so you have no guarantees unless you do that yourself.
(Translation of that last: can't be used for truly "hard" realtime
applications of any time scale without someone doing the proofs.)

>   Fail-safe and Real-time processing are both rather specialized and arcane
> arts.  

I tend to think of them as more hard-core engineering than art, but
maybe that's a matter of opinion.  Or background?

> Embedded systems in spacecraft often fall into these categories
> (just like pacemakers). Standard Python is just not suitable for these tasks,
> though specialized versions could be developed (given the types of
> cost/expense usually associated with such systems).

Pacemakers no, embedded systems even such as in spacecraft, why not?
Other than the need to do a more thorough risk analysis because of 
the incredibly high cost of spacecraft failure, what would need to
change in Python for it to be suitable?

(The reason I say all this is that I'm using Python for what
are considered embedded, mission critical applications with some 
near-hard realtime response requirements on the order of seconds 
and I don't agree with the "just not suitable" claim at all.  
It depends entirely on the degree of risk deemed acceptable.
Because of the expected lower defect rate, higher productivity,
and lower cost of maintenance of Python code we feel its use is 
not only acceptable, but almost mandated.)

-Peter



More information about the Python-list mailing list