The main command and data handling processor runs code written in C, as does the guidance and control computer. However, the G&C algorithms were 'written' in Simulink, and autocoded to C. I believe the instruments also use C, unless they are too resource constrained even for that, in which case, I'd guess Forth.
> Which language is used for programming New Horizon's flight software? How long is code? How do you make sure that it's gonna work?
We don't do the coding for the flight software, that's SciOps.
However here's what I know, each set of spacecraft commands is put up as a "command load", which has a name that's the year plus the day of year. So the 15188 load runs on July 7, and has commands for nine days.
Each load has a multi week coding and vetting process and is simulated on the ground, on a system called "NHOPS", pronounced "nops".
-AZ
I emailed some folk, here's an answer to #3, from Jillian, one of the members of our SciOps team.
3: We have a program called Statesim that checks to make sure constraints are not violated. For instance the Alice aperture door shouldn't be open within 20 degrees of the Sun. We also have something called NHOps which is a software EM of New Horizons and the commands are executed on it and data is downloaded and reviewed by the instruments. We also had a rehearsal in 2013 for the Pluto Closest Approach load.
-AZ
Okay, here's an answer from Helen Hart at Johns Hopkins University Applied Physics Lab (AZ):
We do not program New Horizons flight software. We store commands, packaged into macros, in the portion of C&DH memory designated for command storage, and execute the macros via a Time Tag.
See #1.
How are we sure that it¹s gonna work? That¹s a really, really big question, involving multiple layers, multiple platforms, and a lengthy, intensive Load Build and Review process. For more details on the process, talk to the Science Sequencers.
The command load is simulated in SEQGEN, which is also where it gets built. The Seqgen Modeling File contains hundreds of checks for problems with commands vs. the state of the spacecraft/instrument. The Seqgen modeling file also contains the Mission Operations Playback Data Volume models.
We have a SOFTWARE SIMULATOR called stateSim which models the response of the spacecraft and payload to the command sequence. stateSim generates the file that Mission Operations Command Sequencer turns into the Command Sequence Timeline - the excel spreadsheet that is distributed as part of the load review process.
We have HARDWARE SIMULATORS, called NHOPS-1 and NHOPS-2, which contains HARDWARE modules for the onboard processors, including C&DH-1, C&DH-2, SSR-2, SSR-2, G&C-1, G&C-2, P-Alice, LORRI, PEPSSI, Ralph, REX-1, REX-2, SDC, and SWAP.
The NHOPS and stateSim simulators have different weaknesses; for example: a: NHOPS gets all the details of slews correct; stateSim gets the slew start time and duration correct, but does not track the exact path of the track because that part of the CG&C cannot be modeled in software. b: stateSim correctly predicts C&DH Thermal Control, but NHOPS does not predict this at all c: SSR usage: stateSim does not model SSR usage. NHOPS does, but gets the wrong answer for anything that gets Compressed or Packetized. SEQGEN is tied directly to commanded data downlinks, and cannot be manipulated to produce interim data volumes; it correctly models downlink data volume TO THE ACCURACY OF the Compression Ratios specified by the Science Sequencers (lately, DataTrack).
