The Ariane 5 Programming Failure
In 1996, a European rocket ship called the Ariane 5 was into space from the Guiana Space Centre in
Kourou, Guyane, a small French territory on the northeast coast of South America, only to swerve off course and then explode a mere 40 seconds later. An investigation by independent committee was launched (hehe) approximately one week later, to determine the cause and assess the appropriateness of testing, as well as to make recommendations to fix the problem and improve any potential flaws in the current system. According to the committee's observations and reasoning, the source of the failure was in the software: the explosion and self-destruction was an appropriate response to a severe change in course- an “angle …show more content…
Worst of all, or perhaps a great lesson, the error was the result of an unhandled overflow/carryover during a 64-to-16-bit floating point to signed integer conversion. Even more tragic, perhaps, the module responsible for the exception was redundant at the time of the crash-- its function was related to alignment before lift-off, and it was required to run for some time after lift-off with the previous version, Ariane 4. Due to the differences in actual flight trajectory and speed between the Ariane 5 and its predecessor, the system both misinterpreted the rocket's alignment as problematic, kept redundant components running, and failed to handle one of the most rudimentary exceptions- data overflow. These oversights of very simple detail in a very complex system resulted in a genuine disaster.
The possibility of this Operand Error had been considered; but due to maximum workload constraints, protection was only applied to four of seven variables, despite the fact that analyses showed that this particular conversion could throw an Operand Exception. This is most likely due to the system constraints, in addition to a combination of either a) reasonably high certainty that this error would …show more content…
I agree with Peter B. Ladkin, in his 1998 case study, that this problem potentially spans over all of those domains. Consequently, at the highest level, this is a requirements error. And a tragic lack of humility.
Hindsight: A Test Case for the Ariane 5
One of the most general guidelines of testing is to deliberately “break” the system, to choose inputs that cause overflow, and force results to be too large or too small to handle (Sommerville, 2011). Testing the SRI 1 and SRI 2 modules would have easily revealed this problem. The developers were obviously too confident, however, to seriously consider these results even if they had tested them, because they were most likely aware of this bug. Apparently, these tests are all conducted with simulations of the actual rocket. Simple observation of the program should have led to different, requirement-based testing-- which would have involved new cases, such as the “erroneous” new trajectory data and its effects on the system, which, if done again, and thoroughly, would not have been ignored, now that those numbers are no longer insignificant. And since the developers wanted to reuse the Ariane
In 1996, a European rocket ship called the Ariane 5 was into space from the Guiana Space Centre in
Kourou, Guyane, a small French territory on the northeast coast of South America, only to swerve off course and then explode a mere 40 seconds later. An investigation by independent committee was launched (hehe) approximately one week later, to determine the cause and assess the appropriateness of testing, as well as to make recommendations to fix the problem and improve any potential flaws in the current system. According to the committee's observations and reasoning, the source of the failure was in the software: the explosion and self-destruction was an appropriate response to a severe change in course- an “angle …show more content…
Worst of all, or perhaps a great lesson, the error was the result of an unhandled overflow/carryover during a 64-to-16-bit floating point to signed integer conversion. Even more tragic, perhaps, the module responsible for the exception was redundant at the time of the crash-- its function was related to alignment before lift-off, and it was required to run for some time after lift-off with the previous version, Ariane 4. Due to the differences in actual flight trajectory and speed between the Ariane 5 and its predecessor, the system both misinterpreted the rocket's alignment as problematic, kept redundant components running, and failed to handle one of the most rudimentary exceptions- data overflow. These oversights of very simple detail in a very complex system resulted in a genuine disaster.
The possibility of this Operand Error had been considered; but due to maximum workload constraints, protection was only applied to four of seven variables, despite the fact that analyses showed that this particular conversion could throw an Operand Exception. This is most likely due to the system constraints, in addition to a combination of either a) reasonably high certainty that this error would …show more content…
I agree with Peter B. Ladkin, in his 1998 case study, that this problem potentially spans over all of those domains. Consequently, at the highest level, this is a requirements error. And a tragic lack of humility.
Hindsight: A Test Case for the Ariane 5
One of the most general guidelines of testing is to deliberately “break” the system, to choose inputs that cause overflow, and force results to be too large or too small to handle (Sommerville, 2011). Testing the SRI 1 and SRI 2 modules would have easily revealed this problem. The developers were obviously too confident, however, to seriously consider these results even if they had tested them, because they were most likely aware of this bug. Apparently, these tests are all conducted with simulations of the actual rocket. Simple observation of the program should have led to different, requirement-based testing-- which would have involved new cases, such as the “erroneous” new trajectory data and its effects on the system, which, if done again, and thoroughly, would not have been ignored, now that those numbers are no longer insignificant. And since the developers wanted to reuse the Ariane