Oops

Festival wrote:From the very first time I read that scene (and you don't even want to know how many times this Shannon fanboi has re-read it...), I thought it looked like she'd caused simultaneous containment bottle failure. The description of the explosions is exactly like the sort RFC employs when describing containment failure in battle.

Yes! She may have also messed with the missiles, but remember, Shannon watched Tepes blow up, and was the only one to stay pinned to her console when it happened, watching the recon drone feed.

Shannon_Foraker wrote:Yes! She may have also messed with the missiles, but remember, Shannon watched Tepes blow up, and was the only one to stay pinned to her console when it happened, watching the recon drone feed.

True, but there was something interesting to see there that no one else had seen: two unpowered reentry trajectories for shuttles.

ThinksMarkedly wrote:

Shannon_Foraker wrote:Yes! She may have also messed with the missiles, but remember, Shannon watched Tepes blow up, and was the only one to stay pinned to her console when it happened, watching the recon drone feed.

True, but there was something interesting to see there that no one else had seen: two unpowered reentry trajectories for shuttles.

Yes, but she also would have likely noticed the fusion bottle failure.

Shannon_Foraker wrote:Yes, but she also would have likely noticed the fusion bottle failure.

Yes, but it's not a very interesting thing to note, when it failed because the rest of the ship was disintegrating around it in the first place. The bottle failed as a consequence of the ship's demise, not as a cause.

tlb wrote:I think people with evil intentions could have managed to trick the sensors, despite failure safeguards. For example replacing the sensor feed with a recording of the main ship's external sensors. The more layers of protection that you add, the greater the probability that a minor problem would keep the pinnace from working when needed. Given the level of maintenance ability in the People's Navy, you have to take a chance at some point.

The thing with simply cutting the feed is that's a possible failure scenario, it doesn't require malice. Systems should fail safe, not fail deadly.

I doubt it would even need something as complex as a recording of the main sensors, there's probably some sort of clear-of-obstacles signal that could be replicated far more easily.

Loren Pechtel wrote:

tlb wrote:I think people with evil intentions could have managed to trick the sensors, despite failure safeguards. For example replacing the sensor feed with a recording of the main ship's external sensors. The more layers of protection that you add, the greater the probability that a minor problem would keep the pinnace from working when needed. Given the level of maintenance ability in the People's Navy, you have to take a chance at some point.

The thing with simply cutting the feed is that's a possible failure scenario, it doesn't require malice. Systems should fail safe, not fail deadly.

I doubt it would even need something as complex as a recording of the main sensors, there's probably some sort of clear-of-obstacles signal that could be replicated far more easily.

Right, modern systems are networked "systems of systems" - where one device does a certain processing and another runs another process, and the second relies on a simplified analysis from the first to do it's work.

A few years back, I saw a system where a processor watching a sensor had an output where it updated a text file located on a file server with a 1 or a 0 (and this was all that was in the file, either a 1 or a 0), signifying that the sensor was in a good or bad state, as defined by the 1st processor's algorithms. A 2nd processor in another box read this file and did it's bit - not caring about the actual reading of the sensor, only whether the output file said it was good or bad.

Usually those inputs are in database files now, with dozens of sensors or processors reporting their settings, but the simple 1 or 0 to determine state is still prevalent.

Loren Pechtel wrote:

tlb wrote:I think people with evil intentions could have managed to trick the sensors, despite failure safeguards. For example replacing the sensor feed with a recording of the main ship's external sensors. The more layers of protection that you add, the greater the probability that a minor problem would keep the pinnace from working when needed. Given the level of maintenance ability in the People's Navy, you have to take a chance at some point.

The thing with simply cutting the feed is that's a possible failure scenario, it doesn't require malice. Systems should fail safe, not fail deadly.

I doubt it would even need something as complex as a recording of the main sensors, there's probably some sort of clear-of-obstacles signal that could be replicated far more easily.

Theemile wrote:Right, modern systems are networked "systems of systems" - where one device does a certain processing and another runs another process, and the second relies on a simplified analysis from the first to do it's work.

A few years back, I saw a system where a processor watching a sensor had an output where it updated a text file located on a file server with a 1 or a 0 (and this was all that was in the file, either a 1 or a 0), signifying that the sensor was in a good or bad state, as defined by the 1st processor's algorithms. A 2nd processor in another box read this file and did it's bit - not caring about the actual reading of the sensor, only whether the output file said it was good or bad.

Usually those inputs are in database files now, with dozens of sensors or processors reporting their settings, but the simple 1 or 0 to determine state is still prevalent.

That certainly happens in a design system, but it is a sloppy and irresponsible design which is built on a single point of failure.

That is what almost brought Boeing to its knees when they merged with McDonald Douglas and created the 737 Max. Boeing had built a history of having the safest planes in the air. When they merged with McDonald Douglas profits became more important than safety, which led to a number of crashes from a very new plane. The 737 Max's recurrent crashes were traced back to a single point of failure. A single sensor located near the nose of the plane.

tlb wrote:I think people with evil intentions could have managed to trick the sensors, despite failure safeguards. For example replacing the sensor feed with a recording of the main ship's external sensors. The more layers of protection that you add, the greater the probability that a minor problem would keep the pinnace from working when needed. Given the level of maintenance ability in the People's Navy, you have to take a chance at some point.

Loren Pechtel wrote:The thing with simply cutting the feed is that's a possible failure scenario, it doesn't require malice. Systems should fail safe, not fail deadly.

I doubt it would even need something as complex as a recording of the main sensors, there's probably some sort of clear-of-obstacles signal that could be replicated far more easily.

Theemile wrote:Right, modern systems are networked "systems of systems" - where one device does a certain processing and another runs another process, and the second relies on a simplified analysis from the first to do it's work.

A few years back, I saw a system where a processor watching a sensor had an output where it updated a text file located on a file server with a 1 or a 0 (and this was all that was in the file, either a 1 or a 0), signifying that the sensor was in a good or bad state, as defined by the 1st processor's algorithms. A 2nd processor in another box read this file and did it's bit - not caring about the actual reading of the sensor, only whether the output file said it was good or bad.

Usually those inputs are in database files now, with dozens of sensors or processors reporting their settings, but the simple 1 or 0 to determine state is still prevalent.

I agree that it should have been more difficult. Perhaps RFC left things out in his description of what was done to bypass security. The thing is that when you pile difficulty upon difficulty; then you introduce an entire new set of failure points, that can make it impossible to use a pinnace that is otherwise serviceable. So designers have to balance maintainability against the possibility of disaster and will count on physical security to guard against malicious intent. But a person with malicious intent and sufficient expertise could find a way around whatever safeguards you introduce.

cthia wrote:That certainly happens in a design system, but it is a sloppy and irresponsible design which is built on a single point of failure.

That is what almost brought Boeing to its knees when they merged with McDonald Douglas and created the 737 Max. Boeing had built a history of having the safest planes in the air. When they merged with McDonald Douglas profits became more important than safety, which led to a number of crashes from a very new plane. The 737 Max's recurrent crashes were traced back to a single point of failure. A single sensor located near the nose of the plane.

I think the 737Max debacle makes my point--sensors can fail. No system should take the absence of a signal as saying there's nothing out there. Some processor is going to distill the results of multiple sensors into an answer that goes into a data bus somewhere. There's no reason for everybody who needs that information to do the analysis or tests for bad sensors and that would actually be a bad design practice because it would make it harder to upgrade the sensor system.

Thus there is some signal from the astrogation sensors to the rest of the world. It's not the 0 or 1 previously mentioned, that's asking for an Ariane V failure mode (Processor crashed on a division overflow, backup processor crashed on the same division overflow, the rocket not only became unguided but the controls got stuck at maximum gimbal.) Rather, the astrogation sensors are sending out "It's all clear at time X", updating X with each tick. The wedge isn't going to come up unless it has a very recent it's-clear signal.

Cutting the wires won't work, but if they can cut them they can insert the signal they want unless it's encrypted.

I don't remember if I posted this link (I thought I did, but didn't see it at a brief check), but click on the posted pictures. They have tons of useful info, and claim to be from Weber himself, about Shannon's little "Oops".

https://m.facebook.com/groups/442313124 ... 544197444/