8 ms·
Called a “poke” by the team, the command is meant to gently prompt the FDS to try different sequences in its software package in case the issue could be resolve
by nullhole 3y ago
Called a “poke” by the team, the command is meant to gently prompt the FDS to try different sequences in its software package in case the issue could be resolved by going around a corrupted section.
The apparent foresight of the original programmers is impressive though maybe not too surprising given the conditions they expected.
I'd be curious to know if anyone has any book recommendations on software design for space missions; I suspect there would be some lessons in there around testing and reliability that could inform more day-to-day stuff.
- isolli 3y agoI can't recommend a book, but I watched this video a while ago, and I found it riveting: "Light Years Ahead | The 1969 Apollo Guidance Computer" [0] > Robert Wills introduces the amazing hardware and software that made up the Apollo Guidance Computer, walks you through the landing procedure step-by-step, and talks about the pioneering design principles that were used to make the landing software robust against any failure. [0] https://www.youtube.com/watch?v=B1J2RMorJXM https://www.youtube.com/watch?v=B1J2RMorJXM
- araker 3y agoThanks for sharing, this is a great talk.
- isolli 3y agoI also read this a while ago [1]: "The Voyager’s computer system was very impressive as well. Knowing the craft would be on its own much of the time, with the lag between command and response from Earth growing longer the farther the craft went into space, engineers developed a self-repairing computer system. The computer has multiple modules that compare the data they receive and the output instructions they decide on. If one module differs from the others, it's assumed to be faulty and is eliminated from the system, replaced by one of the backup modules. It was tested shortly after launch, when a delay in boom deployment was misread as a malfunction. The problem was corrected successfully." [1] https://science.howstuffworks.com/voyager.htm https://science.howstuffworks.com/voyager.htm
- shagie 3y agoSome of the fault protection and failover procedures: https://voyager.gsfc.nasa.gov/Library/DeepCommo_Chapter3--141029.pdf https://voyager.gsfc.nasa.gov/Library/DeepCommo_Chapter3--14... Page 74-75 > 3.7.3 Spacecraft Fault Protection > The CCS has five fault-protection algorithms (FPAs) stored in memory, as summarized in Table 3-9. The two algorithms most directly related to the telecommunications system are named RF Loss and Command Loss [19]. > 3.7.3.1 RF Loss. RF Loss provides a means for the spacecraft to automatically recover from an S- or X-band exciter or power amplifier degradation or failure affecting the unit’s RF output. The CCS monitors the output RF power at four points in the RFS: the S-band exciter and S-band power amplifier and the X- band exciter and X-TWTA. If the output RF power from one or more powered- on units drops below a threshold level, the algorithm will attempt to correct the problem by switching to the redundant unit. > 3.7.3.2 Command Loss. Command Loss provides a means for the spacecraft to automatically respond to an onboard failure resulting in the inability to receive or recognize ground commands. If a period of time set in the flight software goes by without the spacecraft recognizing a valid uplinked command, the Command Loss timer expires. The algorithm responds to the presumed spacecraft failure28 and attempts to correct that failure by systematically switching to redundant hardware elements until a valid command is received. Command Loss will be executed four consecutive times if command reception is not successful. After four unsuccessful executions, the CCS will disable Command Loss and activate a set of sequences of commands named the backup mission load (BML) and described below. > 3.7.3.3 Backup Mission Load. In the event of permanent loss of command reception capability, a BML command sequence stored onboard each spacecraft is programmed to continue controlling the spacecraft and achieving fundamental VIM objectives. The BML will begin execution two weeks after the first execution of Command Loss and continue until the spacecraft stops operating. It will transmit cruise science and engineering telemetry, store science observations on the tape recorder, and downlink playbacks regularly.
- anonymous_user9 3y agoSoftware isn’t the sole focus, but you may enjoy “Computers in Spaceflight: The NASA Experience”, a 406-page history of manned, unmanned, and ground computers from the beginning through the shuttle era. https://ntrs.nasa.gov/citations/19880069935 https://ntrs.nasa.gov/citations/19880069935
- CamperBob2 3y agoIt's not specifically a text on software design, but Sunburst and Luminary by Don Eyles is an enjoyable read ( https://www.amazon.com/Sunburst-Luminary-Apollo-Don-Eyles/dp/0986385905 https://www.amazon.com/Sunburst-Luminary-Apollo-Don-Eyles/dp... ). He manages to capture the Apollo-era zeitgeist in more ways than one. Not just another tale from the trenches.
- maicro 3y agoAlso not a book, but I read this article a couple years ago and it's stuck in the back of my mind since: https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff
- chasd00 3y ago> gently prompt the FDS do you suppose their system prompt ensures it responds more favorably to gentle commands? ;)
- KineticLensman 3y agoSunburst and Luminary by Don Eyles, one of the AGC coders, is an outstanding read. Specific to AGC but indicates some of the challenges
- KineticLensman 3y agoAlso, 'Digital Apollo: Human and Machine in Spaceflight' is a good read. This is more generic, but has good discussions about the role of humans in the system, including whether the crew or the computers control the flight, and who has the best data (crew or mission control) and how these issues evolved during the early space race.