http:^^www.cs.utexas.edu^users^kornerup^ariane5rep.html

来自「This data set contains WWW-pages collect」· HTML 代码 · 共 786 行 · 第 1/3 页

alignment function result called BH, Horizontal Bias, related to the horizontal
velocity sensed by the platform. This value is calculated as an indicator
for alignment precision over time.</LI>

<LI>The value of BH was much higher than expected because the early part
of the trajectory of Ariane 5 differs from that of Ariane 4 and results
in considerably higher horizontal velocity values.</LI>
</UL>

<P>The SRI internal events that led to the failure have been reproduced
by simulation calculations. Furthermore, both SRIs were recovered during
the Board's investigation and the failure context was precisely determined
from memory readouts. In addition, the Board has examined the software
code which was shown to be consistent with the failure scenario. The results
of these examinations are documented in the Technical Report.</P>

<P>Therefore, it is established beyond reasonable doubt that the chain
of events set out above reflects the technical causes of the failure of
Ariane 501.</P>

<H4>2.2 COMMENTS ON THE FAILURE SCENARIO</H4>

<P>In the failure scenario, the primary technical causes are the Operand
Error when converting the horizontal bias variable BH, and the lack of
protection of this conversion which caused the SRI computer to stop.</P>

<P>It has been stated to the Board that not all the conversions were protected
because a maximum workload target of 80% had been set for the SRI computer.
To determine the vulnerability of unprotected code, an analysis was performed
on every operation which could give rise to an exception, including an
Operand Error. In particular, the conversion of floating point values to
integers was analysed and operations involving seven variables were at
risk of leading to an Operand Error. This led to protection being added
to four of the variables, evidence of which appears in the Ada code. However,
three of the variables were left unprotected. No reference to justification
of this decision was found directly in the source code. Given the large
amount of documentation associated with any industrial application, the
assumption, although agreed, was essentially obscured, though not deliberately,
from any external review.</P>

<P>The reason for the three remaining variables, including the one denoting
horizontal bias, being unprotected was that further reasoning indicated
that they were either physically limited or that there was a large margin
of safety, a reasoning which in the case of the variable BH turned out
to be faulty. It is important to note that the decision to protect certain
variables but not others was taken jointly by project partners at several
contractual levels.</P>

<P>There is no evidence that any trajectory data were used to analyse the
behaviour of the unprotected variables, and it is even more important to
note that it was jointly agreed not to include the Ariane 5 trajectory
data in the SRI requirements and specification.</P>

<P>Although the source of the Operand Error has been identified, this in
itself did not cause the mission to fail. The specification of the exception-handling
mechanism also contributed to the failure. In the event of any kind of
exception, the system specification stated that: the failure should be
indicated on the databus, the failure context should be stored in an EEPROM
memory (which was recovered and read out for Ariane 501), and finally,
the SRI processor should be shut down.</P>

<P>It was the decision to cease the processor operation which finally proved
fatal. Restart is not feasible since attitude is too difficult to re-calculate
after a processor shutdown; therefore the Inertial Reference System becomes
useless. The reason behind this drastic action lies in the culture within
the Ariane programme of only addressing random hardware failures. From
this point of view exception - or error - handling mechanisms are designed
for a random hardware failure which can quite rationally be handled by
a backup system.</P>

<P>Although the failure was due to a systematic software design error,
mechanisms can be introduced to mitigate this type of problem. For example
the computers within the SRIs could have continued to provide their best
estimates of the required attitude information. There is reason for concern
that a software exception should be allowed, or even required, to cause
a processor to halt while handling mission-critical equipment. Indeed,
the loss of a proper software function is hazardous because the same software
runs in both SRI units. In the case of Ariane 501, this resulted in the
switch-off of two still healthy critical units of equipment.</P>

<P>The original requirement acccounting for the continued operation of
the alignment software after lift-off was brought forward more than 10
years ago for the earlier models of Ariane, in order to cope with the rather
unlikely event of a hold in the count-down e.g. between - 9 seconds, when
flight mode starts in the SRI of Ariane 4, and - 5 seconds when certain
events are initiated in the launcher which take several hours to reset.
The period selected for this continued alignment operation, 50 seconds
after the start of flight mode, was based on the time needed for the ground
equipment to resume full control of the launcher in the event of a hold.</P>

<P>This special feature made it possible with the earlier versions of Ariane,
to restart the count- down without waiting for normal alignment, which
takes 45 minutes or more, so that a short launch window could still be
used. In fact, this feature was used once, in 1989 on Flight 33.</P>

<P>The same requirement does not apply to Ariane 5, which has a different
preparation sequence and it was maintained for commonality reasons, presumably
based on the view that, unless proven necessary, it was not wise to make
changes in software which worked well on Ariane 4.</P>

<P>Even in those cases where the requirement is found to be still valid,
it is questionable for the alignment function to be operating after the
launcher has lifted off. Alignment of mechanical and laser strap-down platforms
involves complex mathematical filter functions to properly align the x-axis
to the gravity axis and to find north direction from Earth rotation sensing.
The assumption of preflight alignment is that the launcher is positioned
at a known and fixed position. Therefore, the alignment function is totally
disrupted when performed during flight, because the measured movements
of the launcher are interpreted as sensor offsets and other coefficients
characterising sensor behaviour.</P>

<P>Returning to the software error, the Board wishes to point out that
software is an expression of a highly detailed design and does not fail
in the same sense as a mechanical system. Furthermore software is flexible
and expressive and thus encourages highly demanding requirements, which
in turn lead to complex implementations which are difficult to assess.</P>

<P>An underlying theme in the development of Ariane 5 is the bias towards
the mitigation of random failure. The supplier of the SRI was only following
the specification given to it, which stipulated that in the event of any
detected exception the processor was to be stopped. The exception which
occurred was not due to random failure but a design error. The exception
was detected, but inappropriately handled because the view had been taken
that software should be considered correct until it is shown to be at fault.
The Board has reason to believe that this view is also accepted in other
areas of Ariane 5 software design. The Board is in favour of the opposite
view, that software should be assumed to be faulty until applying the currently
accepted best practice methods can demonstrate that it is correct.</P>

<P>This means that critical software - in the sense that failure of the
software puts the mission at risk - must be identified at a very detailed
level, that exceptional behaviour must be confined, and that a reasonable
back-up policy must take software failures into account.</P>

<P>2.3 THE TESTING AND QUALIFICATION PROCEDURES</P>

<P>The Flight Control System qualification for Ariane 5 follows a standard
procedure and is performed at the following levels :</P>

<UL>
<P>- Equipment qualification <BR>
- Software qualification (On-Board Computer software) <BR>
- Stage integration <BR>
- System validation tests.</P>
</UL>

<P>The logic applied is to check at each level what could not be achieved
at the previous level, thus eventually providing complete test coverage
of each sub-system and of the integrated system.</P>

<P>Testing at equipment level was in the case of the SRI conducted rigorously
with regard to all environmental factors and in fact beyond what was expected
for Ariane 5. However, no test was performed to verify that the SRI would
behave correctly when being subjected to the count-down and flight time
sequence and the trajectory of Ariane 5.</P>

<P>It should be noted that for reasons of physical law, it is not feasible
to test the SRI as a &quot;black box&quot; in the flight environment, unless
one makes a completely realistic flight test, but it is possible to do
ground testing by injecting simulated accelerometric signals in accordance
with predicted flight parameters, while also using a turntable to simulate
launcher angular movements. Had such a test been performed by the supplier
or as part of the acceptance test, the failure mechanism would have been
exposed.</P>

<P>The main explanation for the absence of this test has already been mentioned
above, i.e. the SRI specification (which is supposed to be a requirements
document for the SRI) does not contain the Ariane 5 trajectory data as
a functional requirement.</P>

<P>The Board has also noted that the systems specification of the SRI does
not indicate operational restrictions that emerge from the chosen implementation.
Such a declaration of limitation, which should be mandatory for every mission-critical
device, would have served to identify any non-compliance with the trajectory
of Ariane 5.</P>

<P>The other principal opportunity to detect the failure mechanism beforehand
was during the numerous tests and simulations carried out at the Functional
Simulation Facility ISF, which is at the site of the Industrial Architect.
The scope of the ISF testing is to qualify :</P>

<UL>
<P>- the guidance, navigation and control performance in the whole flight
envelope, <BR>
- the sensors redundancy operation, - the dedicated functions of the stages,
<BR>
- the flight software (On-Board Computer) compliance with all equipment
of the Flight Control Electrical System.</P>
</UL>

<P>A large number of closed-loop simulations of the complete flight simulating
ground segment operation, telemetry flow and launcher dynamics were run
in order to verify :</P>

<UL>
<P>- the nominal trajectory <BR>
- trajectories degraded with respect to internal launcher parameters<BR>
- trajectories degraded with respect to atmospheric parameters <BR>
- equipment failures and the subsequent failure isolation and recovery</P>
</UL>

<P>In these tests many equipment items were physically present and exercised
but not the two SRIs, which were simulated by specifically developed software
modules. Some open-loop tests, to verify compliance of the On-Board Computer
and the SRI, were performed with the actual SRI. It is understood that
these were just electrical integration tests and &quot;low-level &quot;
(bus communication) compliance tests.</P>

<P>It is not mandatory, even if preferable, that all the parts of the subsystem
are present in all the tests at a given level. Sometimes this is not physically
possible or it is not possible to exercise them completely or in a representative
way. In these cases it is logical to replace them with simulators but only
after a careful check that the previous test levels have covered the scope
completely.</P>

<P>This procedure is especially important for the final system test before
the system is operationally used (the tests performed on the 501 launcher
itself are not addressed here since they are not specific to the Flight
Control Electrical System qualification).</P>

<P>In order to understand the explanations given for the decision not to
have the SRIs in the closed-loop simulation, it is necessary to describe
the test configurations that might have been used.</P>

<P>Because it is not possible to simulate the large linear accelerations
of the launcher in all three axes on a test bench (as discussed above),
there are two ways to put the SRI in the loop:</P>

<UL>
<P>A) &nbsp;&nbsp;&nbsp;To put it on a three-axis dynamic table (to stimulate
the Ring Laser Gyros) and to substitute the analog output of the accelerometers
(which can not be stimulated mechanically) by simulation via a dedicated
test input connector and an electronic board designed for this purpose.
This is similar to the method mentioned in connection with possible testing
at equipment level.</P>

<P>B) &nbsp;&nbsp;&nbsp;To substitute both, the analog output of the accelerometers
and the Ring Laser Gyros via a dedicated test input connector with signals
produced by simulation.</P>
</UL>

<P>The first approach is likely to provide an accurate simulation (within
the limits of the three-axis dynamic table bandwidth) and is quite expensive;
the second is cheaper and its performance depends essentially on the accuracy
of the simulation. In both cases a large part of the electronics and the
complete software are tested in the real operating environment.</P>

<P>When the project test philosophy was defined, the importance of having
the SRIs in the loop was recognized and a decision was taken to select
method B above. At a later stage of the programme (in 1992), this decision
was changed. It was decided not to have the actual SRIs in the loop for
the following reasons :</P>

<UL>
<LI>The SRIs should be considered to be fully qualified at equipment level</LI>

<LI>The precision of the navigation software in the On-Board Computer depends
critically on the precision of the SRI measurements. In the ISF, this precision
could not be achieved by the electronics creating the test signals.</LI>

<LI>The simulation of failure modes is not possible with real equipment,
but only with a model.</LI>