Hacker News new | past | comments | ask | show | jobs | submit login

> The Flight Data Subsystem was an innovation in computing when it was developed five decades ago. It was the first computer on a spacecraft to use volatile memory. Most of NASA's missions operate with redundancy, so each Voyager spacecraft launched with two FDS computers. But the backup FDS on Voyager 1 failed in 1982.

I wonder why they chose volatile memory: Were there performance demands that required it? How much did non-volatile memory cost back then?




The voyager program was on a somewhat tight budget so I would imagine that had an impact. Having volatile memory is arguably a really good thing since it’s allowed them to patch the FSW on the vehicle in space a bunch of times, which a pretty common thing for spacecraft nowadays but would have been unheard of when it launched.


I'm not sure that's a capability specific to volatile memory, merely R/W memory. R/W memory already existed on prior NASA computers in the form of magnetic core RAM (as opposed to magnetic rope memory which served as ROM).


I'm understanding 'volatile memory' to mean memory that needs power for data integrity - if you lose power, memory is wiped like the memory in most desktops/laptops.


This is just speculation but, a shift in software engineering philosophy. The software of early probes was viewed, as a fixed part of the flight avionics and command sequencer. It was programmed well in advance to allow physical manufacture of the ROMs, tested as a whole unit, and the software became fixed quite early on in the project. Like a simple microcontroller, basically.

By the late 70s the modern understanding of software development was taking hold. They wanted to be able to download arbitrary programs, as needed, in flight. And so instead of having it mostly in ROM, the Voyager computers are like any other general purpose computer and all their main memory is RAM.

Updating a live system in RAM isn't as risky as it might sound when you consider there are three different computers on board, each dually redundant, serving a supervisor role for the other two.


It doesn't need to be volatile (require power for data integrity) to be read/write. See the other subthread ...


Until the spares fail, in which case it gets fun. This is the case where the spare failed already.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: