We used about 200-500 lines of not particularly dense Perl (with "use strict" and "use warnings" of course) to handle command inputs (limited to bits set and cleared in a single command word -- this is, after all, a sounding rocket) and change instrument mode. Primary functionality was handled with code written in "C" to acquire data from the onboard cameras, control the mechanisms, and display telemetry over a realtime video feed. Individual functions were accessed from the UNIX command line interface.

RAISE included three separate computers handling different aspects of the flight.

The Perl daemons' role was to control instrument mode and process uplink commands, by monitoring running processes and launching new tasks as necessary. Pretty vanilla IPC and task management stuff, except that it was being used in a mission critical context (admittedly, in a sounding rocket rather than a deep space mission). This is important because it might be seen as advancing Perl to NASA's TRL 8 or 9 for certain applications.

Thanks for your response, very interesting. Let's compare a little bit. (Taken from a PA document, a possible SW criticality categorization is... (our standards can be tailored in most cases).

Category Definition
--------------------------------------------------------------------- 
A        Software that if not executed, or if not correctly executed, 
         or whose anomalous behaviour can cause or contribute to a 
         system failure resulting in:

         -> Catastrophic consequences
--------------------------------------------------------------------- 
B        Software that if not executed, or if not correctly executed, 
         or whose anomalous behaviour can cause or contribute to a 
         system failure resulting in:

         -> Critical consequences
--------------------------------------------------------------------- 
C        Software that if not executed, or if not correctly executed, 
         or whose anomalous behaviour can cause or contribute to a 
         system failure resulting in:

         -> Major consequences
--------------------------------------------------------------------- 
D        Software that if not executed, or if not correctly executed, 
         or whose anomalous behaviour can cause or contribute to a 
         system failure resulting in:

         -> Minor or Negligible consequences
---------------------------------------------------------------------
[download]

I have written Perl for category D. I'm sure there is Perl category C around as well.

Cheers

Harry

I really hate classification systems like that -- who's to decide what's major, minor, critical, etc?

The NASA one's much more clear -- (A) : failure is likely to cause the loss of human life; (B) : failure is likely to cause the loss of a spacecraft or failure of the mission; (C) : failure is likely to cause the loss of a secondary mission objective; ... and everything after that's just an annoyance of some sort.

Years ago, I wrote a trouble ticket system, and we had those sorts of terms, but I qualified then all ... it went from 'cosmetic issue' to 'the building is on fire', with steps in between for 'annoyance', 'can't get work done', 'multiple people can't get work done', 'the boss can't get work done', etc.

I don't like the classification systemas too much myself but they do serve a purpose. E.g. in a selection process to make a decision or to justify an expensive code inspection etc. In defense of it I can say I provided a summary, of course everything is specified in detail;) For example "catastrophic" is described as:

• Loss of life, life‐threatening or permanently disabling injury or occupational illness
• Loss of an interfacing manned flight system
• Severe detrimental environmental effects
• Loss of launch site facilities
• Loss of system
So I think both standards are equally (un)clear;)