The Emergency Response System is cold science fiction. It’s not explosions in space. It’s not here to take your time with arbitrary virtue signalling. It’s not here to bend the rules of reality one bit. Nope, the ERS is about technology, problem solving, and I’m sure there’s a “Problem solving is in the eye of the solver” joke in there, somewhere.
This week’s writer is Christopher Allen-Poole, who maintains a site at https://allen-poole.com. (Button at the top-right leads to his regularly updated creative word-smithing.) If you ask me, Chris is one of those compulsive writers with a narrative side that’s sometimes darker, and it comes out in his stories. Considering how he’s one sharp tack, it leads to lots of interesting situations, like this one:
The Emergency Response System
by Christopher Allen-Poole
Awake. It was awake. Something had gone wrong. The ship was in or had been in trouble, and it had awakened it. The Emergency Response System had been activated.
Any time the ERS was activated was a sign that something had gone wrong. It was an independent entity, a small robot within the larger, roboticized machine. It had the ability to assess damage and take action. It could do this without the input of a human, and the long hours that communication would need.
It did not have a sense of fear. The men and women who designed these systems generations ago did not see fit to put a sense of fear into them, but it did have a sense of urgency. It had a sense of the timeliness of problems and their prioritization. It acted according to its best estimate, and that was normally the right one.
Its first task was to reach out into the mind of the freighter and ask for diagnostics. It knew that the ship was dumb, that its computer was well suited to handling navigation and docking, but it had no ability to assess problems. Usually, an ERS activation was caused by something trivial: the last time this ERS was activated after a septic system failure. The ERS noted the leak, and logged it, along with a comment that no personnel were on the craft this far after launch, let alone anyone interested in using a faulty toilet. Not a bad record for a ship that logged well over the ten thousand inter-orbit trips.
In this case, the ship reported an engine misalignment. Typically, that wasn’t something people would care about, and certainly, the ship’s owner wouldn’t care, so long as the cargo arrived at Io on time. The ERS performed the necessary re-alignment and adjusted the flight plan — adding an additional day before deceleration, another two and a half days to the trip overall — but then deactivated. There was nothing important, nothing urgent to report.
It was reactivated a day later. The ship was reporting engine misalignment again. This time it was more severe. The ERS ran the standard diagnosis and could find nothing wrong with the engines. They had just dropped in efficiency. It sent a notification-level signal to its owners and then began a more thorough diagnosis.
It began inside the ship. The software seemed to be behaving correctly. An analysis of the sensor array showed that it was functioning at over 95% efficiency, well within required standards. The components which could be examined electronically all seemed to be functioning well above minimum thresholds. In fact, everything inside the ship was working as expected or better.
It didn’t make sense. Even to a robot, it didn’t make sense. The ship was reporting engine degradation — they were now functioning at less than 40% efficiency — but none of the individual components seemed to have failed. The ERS couldn’t figure out what was going wrong.
It then started what, if it were done by a human, would be considered manual verification. It began by taking the sensor system offline, testing each sensor on its own, verifying that the sensor could function and that it was reporting expected data. It took the engines offline — the ship was already going to be late anyway, so long as it could restore them long enough to decelerate deactivating them would be a way to prevent further damage. It took navigation offline — perhaps the problem was not in the engine itself, but in the way that the ship tracked its speed in the vast interplanetary void — but found no problem there. When none of those worked, it began taking the freighter apart, testing individual parts, trying to find the source of this continued degradation.
The timeline deteriorated, and the ERS got more and more desperate. One would think that a well-adjusted, intelligent machine would be incapable of something so human as “panic,” but there are few words which so succinctly describe the situation. It entered into a spiral of ever-growing diagnostic procedures, making ever broader assumptions about whatever the problem could possibly be.
The ship was found eleven months later. The owner had received notice that the ERS had been activated, but soon after that it had gone completely silent, even its navigation beacon was silenced. When the scavenger team came on board, they found a total wreck. Pieces of machinery in various states of disassembly were floating around, bouncing like billiard balls around the inside of the ship. The computer wouldn’t boot, the engines wouldn’t fire, the radio was utterly destroyed. When they finally found the ERS, it was in the middle of ripping apart the controls for the cargo bay. It didn’t take the salvage crew long to figure out what happened.
A small meteor, about the size of a marble, had struck the craft going just fast enough to rip through the outer hull. Normally, this wouldn’t be important: hull damage on an unmanned freighter was all but irrelevant, normally the ERS would just log it, ignore it, and deactivate. Unfortunately, in its pinging about inside the ship, this marble damaged the ERS and damaged it enough to give it a small case of myopia. The system then proceeded to rip apart the ship’s internals in a vain attempt to fix a problem that wasn’t there.