5 ms·

> The software was actually developed correctly Not quite. If you read the details about the case you can find that it didn't have the handler for the overflow

by acqq 10y ago

> The software was actually developed correctly Not quite. If you read the details about the case you can find that it didn't have the handler for the overflow in the calculations(!) It's similar to this case now that both were developed with under the assumptions "can't happen," in the sense, developed to be too brittle, for the inputs that were certainly possible to happen as soon as the trajectory (in the case of Ariane 5) or the duration of the spinning movement (this case now) doesn't match their initial test cases. Still, the development, especially in this kind of projects, is always a balancing act to organize covering most of the cases that can go wrong. Murphy's law works against the whole organization. Given the amount of real problems, I'm still amazed that the Apollo 11 succeeded. Or even that there weren't any really destructive "accidents" involving rockets with the nuclear warheads. Think about it, these are prone to the same problems any other computer-related projects are: the amount of the damage is effectively infinitely larger than the effort needed to start it. https://www.theguardian.com/world/2016/jan/07/nuclear-weapons-risk-greater-than-in-cold-war-says-ex-pentagon-chief https://www.theguardian.com/world/2016/jan/07/nuclear-weapon... “These weapons are literally waiting for a short stream of computer signals to fire. They don’t care where these signals come from.” “Their rocket engines are going ignite and their silo lids are going to blow off and they are going to lift off as soon as they have the equivalent of you or I putting in a couple of numbers and hitting enter three times.” http://thebulletin.org/ http://thebulletin.org/ "It is 3 minutes to midnight" Also: "How Risky is Nuclear Optimism?" http://www-ee.stanford.edu/%7Ehellman/publications/75.pdf http://www-ee.stanford.edu/%7Ehellman/publications/75.pdf And if you still think "but it works, the proof is that it hasn't exploded up to now", just consider this graph from Nassim Taleb: http://static3.businessinsider.com/image/5655f69c8430765e008b57c8-1200-900/taleb-turkey.png http://static3.businessinsider.com/image/5655f69c8430765e008...

andai 10y ago
What do we do about this?
- acqq 10y ago
  Act! Share the info, raise the awareness. It seems non-technical people can't imagine how easy the computers and the technology can be catastrophically wrong. The accident will hapen and we must rationally minimize the impacts: http://nuclearrisk.org http://nuclearrisk.org The political action is essential.
fghgfdfg 10y ago
> Not quite. If you read the details about the case you can find that it didn't have the handler for the overflow in the calculations(!) It's similar to this case now that both were developed with under the assumptions "can't happen," in the sense, developed to be too brittle, for the inputs that were certainly possible to happen as soon as the trajectory (in the case of Ariane 5) I'm not sure that's entirely fair. The software was intended for the Ariane 4 which wasn't intended to have as much horizontal acceleration as the 5. If the 4 had experienced such an acceleration it wasn't intended to be capable of recovering from it. That area of the code also explicitly had some protections provided by the language removed for the sake of efficiency. So it wasn't a total oversight that just happened to work out - there was a decision made based on the fact the rocket had already irrecoverably failed if the situation ever occurred. While I agree it's somewhat distasteful not to cover all the bases in the most technically correct way all the time, I'm not sure how important it is to have an overflow handler fire in the inertial reference system just as the rocket self-destructs.
- acqq 10y ago
  > That area of the code also explicitly had some protections provided by the language removed for the sake of efficiency As far as I know the efficiency wasn't the issue, just that the "model" was, as I've said, brittle. The overflow was to be handled with what we'd today call "an exception handler" and the selected solution was, instead of (reasonably) writing "keep the maximum value as the result" handler, to leave the processor effectively executing random code in the case the overflow occurs. And the "exception" occured. It's not that the overflow detection was turned off to save the cycles, or that some default handling was provided. It was that it was handled with "whatever" (execute random instructions)! by intentionally omitting the handlers.
  - acqq 10y ago
    I've checked the report: the exception resulted in the transmission of effectively random data to the main computer: http://www.math.umn.edu/~arnold/disasters/ariane5rep.html http://www.math.umn.edu/~arnold/disasters/ariane5rep.html "g) As a result of its failure, the active inertial reference system transmitted essentially diagnostic information to the launcher's main computer, where it was interpreted as flight data and used for flight control calculations." So the handler in the processes existed but it effectively confused the main computer. The units shut off but before that sent "the diagnostic." For which there was no handler at all in the main computer. And even more interesting, these processes weren't even needed for the flight. The main computer were able to just ignore such input and the flight would have continued (R1). Brittle.

by acqq 10y ago

andai 10y ago

What do we do about this?

acqq 10y ago
Act! Share the info, raise the awareness. It seems non-technical people can't imagine how easy the computers and the technology can be catastrophically wrong. The accident will hapen and we must rationally minimize the impacts: http://nuclearrisk.org http://nuclearrisk.org The political action is essential.

fghgfdfg 10y ago

> Not quite. If you read the details about the case you can find that it didn't have the handler for the overflow in the calculations(!) It's similar to this case now that both were developed with under the assumptions "can't happen," in the sense, developed to be too brittle, for the inputs that were certainly possible to happen as soon as the trajectory (in the case of Ariane 5) I'm not sure that's entirely fair. The software was intended for the Ariane 4 which wasn't intended to have as much horizontal acceleration as the 5. If the 4 had experienced such an acceleration it wasn't intended to be capable of recovering from it. That area of the code also explicitly had some protections provided by the language removed for the sake of efficiency. So it wasn't a total oversight that just happened to work out - there was a decision made based on the fact the rocket had already irrecoverably failed if the situation ever occurred. While I agree it's somewhat distasteful not to cover all the bases in the most technically correct way all the time, I'm not sure how important it is to have an overflow handler fire in the inertial reference system just as the rocket self-destructs.

acqq 10y ago
> That area of the code also explicitly had some protections provided by the language removed for the sake of efficiency As far as I know the efficiency wasn't the issue, just that the "model" was, as I've said, brittle. The overflow was to be handled with what we'd today call "an exception handler" and the selected solution was, instead of (reasonably) writing "keep the maximum value as the result" handler, to leave the processor effectively executing random code in the case the overflow occurs. And the "exception" occured. It's not that the overflow detection was turned off to save the cycles, or that some default handling was provided. It was that it was handled with "whatever" (execute random instructions)! by intentionally omitting the handlers.
- acqq 10y ago
  I've checked the report: the exception resulted in the transmission of effectively random data to the main computer: http://www.math.umn.edu/~arnold/disasters/ariane5rep.html http://www.math.umn.edu/~arnold/disasters/ariane5rep.html "g) As a result of its failure, the active inertial reference system transmitted essentially diagnostic information to the launcher's main computer, where it was interpreted as flight data and used for flight control calculations." So the handler in the processes existed but it effectively confused the main computer. The units shut off but before that sent "the diagnostic." For which there was no handler at all in the main computer. And even more interesting, these processes weren't even needed for the flight. The main computer were able to just ignore such input and the flight would have continued (R1). Brittle.