|
|
|
|
|
by akira2501
633 days ago
|
|
You characterize every single piece of equipment on platform so you can do somewhat accurate simulations. The shuttle flew most of the critical phases of their missions on the ground before ever uploading the code into an actual shuttle computer. The simulation system was continuously updated with real world performance information so it's accuracy continually improves. You also have a command processor on the spacecraft side. It will have some of these characterizations present as limits on command authority. Commands sent without override that exceed these limits will be ignored, possibly cancelling the entire sequence of dependent commands. You can demand that these limits be ignored but this obviously requires you to specify it redundantly in the message set. Should anything happen your flight software is generally going to go into a recovery mode. Voyager will try this 4 times after a period of no commands triggers a watchdog. This will switch on different radios while keeping them oriented towards the Earth in a constant effort to reacquire the command signals. Should this process fail a backup flight software mode will then activate which performs basic mission functions on a continuous loop so whatever continues to operate on the spacecraft will transmit it's data automatically back to the Earth at it's highest power setting. Voyager was a continuation of some of the Viking hardware and flight systems. |
|
This is not true of the Voyager probes:
> Newer NASA missions have hardware and software simulators on the ground, where engineers can test new procedures to make sure they do no harm when they uplink commands to the real spacecraft. Due to its age, Voyager doesn't have any ground simulators, and much of the mission's original design documentation remains in paper form and hasn't been digitized.
https://www.wired.com/story/nasa-repair-voyager-1-spacecraft...