4 ms·

To the shock and horror of many programming-inclined people, it turns out that having "arbitrary memory read/write" commands on a remote computer that must ke

To the shock and horror of many programming-inclined people, it turns out that having "arbitrary memory read/write" commands on a remote computer that *must* keep the mission going is quite useful. I can tell you a little first-hand account of where this helped a satellite formation flight mission I worked on. The communication system was working fine in terms of signal strength, but many command packets were ignored (no response). We were able to figure out that a message queue in the processing pipeline was considered full, by strategically reading certain memory locations. We then sent a memory patch to the satellite to skip some of the processing steps and this improved the communication system dramatically. We also brought back to life the first CubeSat launched by my university, BEESAT-1, by using arbitrary memory write to patch some telemetry collection software to avoid a damaged section of the onboard flash. Pretty cool story actually.

0xDEAFBEAD 2y ago
It occurs to me that writing software for spacecraft could demand an entirely different paradigm than writing software for traditional applications. For example, you could use an OS that is deterministic down to the last detail, and have a "digital twin" / virtual machine of the spacecraft computer here on Earth, kept in sync with all sensor and actuator activity out in space. Before issuing any command to the spacecraft, you branch the digital twin, issue the command on the branch, and make sure everything looks good. With this method, you wouldn't even need to read memory locations on the spacecraft, you could just read them on the digital twin. Then test the memory patch on the digital twin and make very sure that it won't brick your spacecraft before you transmit it.
- jdiez17 2y ago
  Interesting idea. If you had control over the whole software stack down to the hardware, you could organize it in such a way that all meaningful mutable state is kept in a contiguous region of memory - and then you could just download or sync that. I can imagine that these "state dumps" would be quite big though. And there is definitely some hidden state in the hardware blocks themselves (SPI, I2C, whatever...).
LorenPechtel 2y ago
Sounds like a very, very useful capability to put in for diagnostic capability, but it's not exactly what I would like for routine operations. Things happen, and the electronics has to take radiation hits. I'd make the software as defensive as feasible so failures have less potential to cascade.

To the shock and horror of many programming-inclined people, it turns out that having "arbitrary memory read/write" commands on a remote computer that *must* ke

0xDEAFBEAD 2y ago

It occurs to me that writing software for spacecraft could demand an entirely different paradigm than writing software for traditional applications. For example, you could use an OS that is deterministic down to the last detail, and have a "digital twin" / virtual machine of the spacecraft computer here on Earth, kept in sync with all sensor and actuator activity out in space. Before issuing any command to the spacecraft, you branch the digital twin, issue the command on the branch, and make sure everything looks good. With this method, you wouldn't even need to read memory locations on the spacecraft, you could just read them on the digital twin. Then test the memory patch on the digital twin and make very sure that it won't brick your spacecraft before you transmit it.

jdiez17 2y ago
Interesting idea. If you had control over the whole software stack down to the hardware, you could organize it in such a way that all meaningful mutable state is kept in a contiguous region of memory - and then you could just download or sync that. I can imagine that these "state dumps" would be quite big though. And there is definitely some hidden state in the hardware blocks themselves (SPI, I2C, whatever...).

LorenPechtel 2y ago

Sounds like a very, very useful capability to put in for diagnostic capability, but it's not exactly what I would like for routine operations. Things happen, and the electronics has to take radiation hits. I'd make the software as defensive as feasible so failures have less potential to cascade.