|
in reply to Perl in space?
No!
First of all let me clarify I cannot speak for NASA, I've been involved in several European mission and one Indian mission.
You have to draw a line between Ground Segment and Space Segment. This is a strict separation. In the Ground Segment you can basically use anything because it's not critical and processing power or available memory is hardly ever an issue. There is typically software to do operations, science planning, data processing etc. Perl can be used anywhere in the Ground Segment. So to answer your question, yes, but only in the Ground Segment, e.g. in Galileo, Venus Express, Mars Express Smart-1, Rosetta and Chandrayaan-1 missions.
Some examples were I used Perl:
- processing RINEX date from Galileo receivers
- processing telemetry from payloads and satellites, e.g. health check
- preparing datasets for archiving
- integration of SW and scripts (Perl is exceptionally good for glueing things together!)
The Space segment is treated completely different. We use the ECSS standards, onboard SW would typically be "Category A" meaning it could have "catastrophic consequences" like losing the mission. Perl is not used for that. This however is not the major reason for not using Perl. All hardware used in space has to be "space certified", this also implies constraints for the SW. The available memory and processing power is very limited compared to the HW on earth. So most often (if not always) the SW is typically written in C and/or assembler. A minimal footprint, maximum performance and last but not least reuse are the main drivers. So to get back to your post: no, Perl would not be used * in * space.
A sounding rocket doesn't "sound" like a critical mission to me:P How do you define critical? You would have to explain what you mean with synchronizing and controlling major instrument functions. I could see myself preparing a command file with Perl to command a payload onboard a spacecraft (e.g. switch-on, heat-up, calibrate, take image/spectrum, cool-down, switch-off). I would send the file to the Mission Operation Centre and they have the last word. For verifying the file, sending it to the spacecraft and handling it onboard Perl would not be used.
Cheers
Harry |
Re^2: Perl in space?
by jhourcle (Prior) on Aug 26, 2010 at 14:03 UTC
|
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:
- Class A : Human Rated Software Systems
- Class B : Non-Human Space Rated
- Class C : Mission Support Software
- Class D : Analysis and Distribution Software
- Class E : Development Support Software:
- Class F : General Purpose Computing Software (Multi-Center or Multi-Program/Project)
- Class G : General Purpose Computing Software (Single Center or Project)
- Class H : General Purpose Desktop Software
Class D and below are where you get descriptions qualified with : 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.
| [reply] |
|
|
The software was a Class B application.
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.
| [reply] |
|
|
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
---------------------------------------------------------------------
I have written Perl for category D. I'm sure there is Perl category C around as well.
Cheers
Harry
| [reply]
[d/l] |
|
|
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.
| [reply] |
|
|
Re^2: Perl in space?
by Dr. Zowie (Sexton) on Aug 26, 2010 at 15:31 UTC
|
Well, what I meant by "mission critical" is that a bug in the software would result in the loss of primary mission functionality. We used several daemons written in Perl, running onboard the instrument in flight, to control data acquisition and instrument configuration. I'll send more in another reply shortly. | [reply] |
Re^2: Perl in space?
by james2vegas (Chaplain) on Aug 26, 2010 at 15:23 UTC
|
| [reply] |
Re^2: Perl in space?
by LanX (Saint) on Aug 26, 2010 at 14:54 UTC
|
| [reply] |
|
|
| [reply] |
|
|
hmm "efficiency cosniderations" ... 8)
reminds me on the decision taken by EADS to use different CAD systems in France and Germany ... resulting later in huge loses because of the difficulties to assemble the different parts of the Airbus A380... (cables to short...) xD
Update: (Airbus) engineers in Germany and Spain stuck with an earlier version of Paris-based Dassault Systemes' CATIA design software, even though the French and British offices had upgraded to CATIA 5. That meant the German teams couldn't add their design changes for the electrical wiring back into the common three-dimensional digital mockup being produced in Toulouse. ..
| [reply] |
|
|
