ariane 5 launcher failure

Post on 11-Nov-2014

668 Views

Category:

Technology

6 Downloads

Preview:

Click to see full reader

DESCRIPTION

Explains the causes of the Ariane 5 launcher failure in 1996. Due to a failure in the software controlling the inertial navigation system Video: http://www.youtube.com/watch?v=W3YJeoYgozw

TRANSCRIPT

Ariane launcher failure, Case study, 2013 Slide 1

The Ariane 5 Launcher Failure

Ian Sommerville

Ariane launcher failure, Case study, 2013 Slide 2

June 4th 1996Total failure of the Ariane 5 launcher on its maiden flight

Ariane launcher failure, Case study, 2013 Slide 3

Ariane 5

• A European rocket designed to launch commercial payloads (e.g.communications satellites, etc.) into Earth orbit

• Successor to the successful Ariane 4 launchers

Ariane launcher failure, Case study, 2013 Slide 4

Ariane launcher failure, Case study, 2013 Slide 5

• Ariane 5 can carry a heavier payload than Ariane 4

• Now the standard launch vehicle for the European Space Agency

Ariane launcher failure, Case study, 2013 Slide 6

Ariane launcher failure, Case study, 2013 Slide 7

Launcher failure

• First test launch of Ariane 5 in June 1996

• Appoximately 37 seconds after a successful lift-off, the Ariane 5 launcher lost control

Ariane launcher failure, Case study, 2013 Slide 8

Ariane launcher failure, Case study, 2013 Slide 9

• Incorrect control signals were sent to the engines and these swivelled so that unsustainable stresses were imposed on the rocket

• The vehicle started to break up because of the stresses imposed and self-destructed

Ariane launcher failure, Case study, 2013 Slide 10

The problem

• The attitude and trajectory of the rocket are measured by a computer-based inertial reference system.

• The IRS transmits commands to the engines to maintain attitude (the angle to the vertical) and direction

Ariane launcher failure, Case study, 2013 Slide 11

• The system failure was a direct result of a software failure.

• However, it was symptomatic of a more general systems validation failure

Ariane launcher failure, Case study, 2013 Slide 12

IRS 1 IRS 2

Sensors

Instructions to engine control system

Ariane launcher failure, Case study, 2013 Slide 13

• The IRS had both a primary and a backup computer

• The backup computer was included to cope with hardware failure but both the primary and the backup system ran the same software.

Ariane launcher failure, Case study, 2013 Slide 14

• The IRS software in both the primary and the backup computer shut itself down 37 seconds after take-off

• Diagnostic data about the shutdown was sent to the engine control system

• This system did not expect such data and interpreted these as real data

• The values were such that the system swivelled the rocket engines to an extreme position

Ariane launcher failure, Case study, 2013 Slide 15

Software failure

• Software failure occurred when an attempt to convert a 64-bit floating point number representing the horizontal velocity to a signed 16-bit integer caused the number to overflow (become too big).

Ariane launcher failure, Case study, 2013 Slide 16

0 111111111111111

Sign

16-bit integer

Max value (32768)

Ariane launcher failure, Case study, 2013 Slide 17

• There was no exception handler associated with the conversion so the system exception management facilities were invoked. These shut down the software controlling the IRS.

• Redundant but not diverse software

• The backup software was a copy and behaved in exactly the same way i.e. the number overflowed and the system was shut down

Ariane launcher failure, Case study, 2013 Slide 18

Avoidable failure?

• The software that failed was reused from the Ariane 4 launch vehicle. The computation that resulted in overflow was not used by Ariane 5.

• The calculations had been transferred to a ground-based system in Ariane 5

Ariane launcher failure, Case study, 2013 Slide 19

Implementation decisions

• Decisions were made– Not to remove the facility as this could

introduce new faults

– Not to test for overflow exceptions because the processor was heavily loaded.

– For dependability reasons, it was thought desirable to have some spare processor capacity

Ariane launcher failure, Case study, 2013 Slide 20

Why not Ariane 4?

• The physical characteristics of Ariane 4 (A smaller vehicle) are such that it has a lower initial acceleration and build up of horizontal velocity than Ariane 5

• The value of the variable on Ariane 4 could never reach a level that caused overflow during the launch period.

• This calculation had been carried out during the development of Ariane 4 and it was therefore decided that no overflow check was required

Ariane launcher failure, Case study, 2013 Slide 21

Validation failure

• As the facility that failed was not required for Ariane 5, there was no requirement associated with it.

• As there was no associated requirement, there were no tests of that part of the software and hence no possibility of discovering the problem.

Ariane launcher failure, Case study, 2013 Slide 22

Simulator-based testing

• During system testing, simulators of the inertial reference system computers were used.

• These did not generate the error as there was no requirement for the unused code to be included in the simulator

Ariane launcher failure, Case study, 2013 Slide 23

Review failure

• Review failures?

• The inertial reference system software was not reviewed because it had been used in a previous version

• The review failed to expose the problem or that the test coverage would not reveal the problem

• The review failed to appreciate the consequences of system shutdown during a launch

Ariane launcher failure, Case study, 2013 Slide 24

Ariane launcher failure, Case study, 2013 Slide 25

Lessons learned

• Don’t run software in critical systems unless it is actually needed

• As well as testing for what the system should do, you may also have to test for what the system should not do

• Do not have a default exception handling response which is system shut-down in systems that have no fail-safe state

Ariane launcher failure, Case study, 2013 Slide 26

Lessons learned

• In critical computations, always return best effort values even if the absolutely correct values cannot be computed

• Wherever possible, use real equipment and not simulations

• Improve the review process to include external participants and review all assumptions made in the code

top related