NASA has this concept of "Tech Readiness Level", where you basically have to go through various levels of testing before use in flight. As I understand it, TRL applies to all technology (hardware, software, specific materials, etc.) There's then the "Software Safety Guidebook", which doesn't even mention Perl. (yet, they mention VisualBasic). ... but based on the criteria they use (strongly typed, compiled, etc), Perl is going to be a problem.

There are specific requirements for assessments of systems in the Software Assurance Standard, based on the classification of the systems:

A defect in Class D software may cause rework but has no direct impact on mission
objectives or system safety

I know there's Class D software written in Perl. (I've written some of it.) It's likely that Perl will *never* be in use in Class A or B. I also know of some Class C software out there that's written in Perl (stuff to retrieve and merge various documents for mission planners, and some client/socket software to obtain a secondary science product from ground stations and process them), but I don't know how common it is, as I don't work in mission operations or science operations; I fall under science analysis.

...

Now, this sounding rocket ... I'm guessing it'd be either Class B or C (depending if it was being used for a primary or secondary mission objective), but as it's not a long-lived mission, doesn't need to be a high TRL; this could've just been considered a prototype.

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
---------------------------------------------------------------------

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: