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

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

<LI>The base period of the SRI is 1 millisecond whilst that of the simulation
at the ISF is 6 milliseconds. This adds to the complexity of the interfacing
electronics and may further reduce the precision of the simulation.</LI>
</UL>

<P>The opinion of the Board is that these arguments were technically valid,
but since the purpose of a system simulation test is not only to verify
the interfaces but also to verify the system as a whole for the particular
application, there was a definite risk in assuming that critical equipment
such as the SRI had been validated by qualification on its own, or by previous
use on Ariane 4.</P>

<P>While high accuracy of a simulation is desirable, in the ISF system
tests it is clearly better to compromise on accuracy but achieve all other
objectives, amongst them to prove the proper system integration of equipment
such as the SRI. The precision of the guidance system can be effectively
demonstrated by analysis and computer simulation.</P>

<P>Under this heading it should be noted finally that the overriding means
of preventing failures are the reviews which are an integral part of the
design and qualification process, and which are carried out at all levels
and involve all major partners in the project (as well as external experts).
In a programme of this size, literally thousands of problems and potential
failures are successfully handled in the review process and it is obviously
not easy to detect software design errors of the type which were the primary
technical cause of the 501 failure. Nevertheless, it is evident that the
limitations of the SRI software were not fully analysed in the reviews,
and it was not realised that the test coverage was inadequate to expose
such limitations. Nor were the possible implications of allowing the alignment
software to operate during flight realised. In these respects, the review
process was a contributory factor in the failure.</P>

<H4>2.4 POSSIBLE OTHER WEAKNESSES OF SYSTEMS INVOLVED</H4>

<P>In accordance with its termes of reference, the Board has examined possible
other weaknesses, primarily in the Flight Control System. No weaknesses
were found which were related to the failure, but in spite of the short
time available, the Board has conducted an extensive review of the Flight
Control System based on experience gained during the failure analysis.</P>

<P>The review has covered the following areas :</P>

<UL>
<P>- The design of the electrical system, <BR>
- Embedded on-board software in subsystems other than the Inertial Reference
System, <BR>
- The On-Board Computer and the flight program software.</P>
</UL>

<P>In addition, the Board has made an analysis of methods applied in the
development programme, in particular as regards software development methodology.</P>

<P>The results of these efforts have been documented in the Technical Report
and it is the hope of the Board that they will contribute to further improvement
of the Ariane 5 Flight Control System and its software.</P>

<H3>3. CONCLUSIONS</H3>

<H4>3.1 FINDINGS</H4>

<P>The Board reached the following findings:</P>

<UL>
<P>a) During the launch preparation campaign and the count-down no events
occurred which were related to the failure.</P>

<P>b) The meteorological conditions at the time of the launch were acceptable
and did not play any part in the failure. No other external factors have
been found to be of relevance.</P>

<P>c) Engine ignition and lift-off were essentially nominal and the environmental
effects (noise and vibration) on the launcher and the payload were not
found to be relevant to the failure. Propulsion performance was within
specification.</P>

<P>d) 22 seconds after H0 (command for main cryogenic engine ignition),
variations of 10 Hz frequency started to appear in the hydraulic pressure
of the actuators which control the nozzle of the main engine. This phenomenon
is significant and has not yet been fully explained, but after consideration
it has not been found relevant to the failure.</P>

<P>e) At 36.7 seconds after H0 (approx. 30 seconds after lift-off) the
computer within the back-up inertial reference system, which was working
on stand-by for guidance and attitude control, became inoperative. This
was caused by an internal variable related to the horizontal velocity of
the launcher exceeding a limit which existed in the software of this computer.</P>

<P>f) Approx. 0.05 seconds later the active inertial reference system,
identical to the back-up system in hardware and software, failed for the
same reason. Since the back-up inertial system was already inoperative,
correct guidance and attitude information could no longer be obtained and
loss of the mission was inevitable.</P>

<P>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.</P>

<P>h) On the basis of those calculations the main computer commanded the
booster nozzles, and somewhat later the main engine nozzle also, to make
a large correction for an attitude deviation that had not occurred.</P>

<P>i) A rapid change of attitude occurred which caused the launcher to
disintegrate at 39 seconds after H0 due to aerodynamic forces.</P>

<P>j) Destruction was automatically initiated upon disintegration, as designed,
at an altitude of 4 km and a distance of 1 km from the launch pad.</P>

<P>k) The debris was spread over an area of 5 x 2.5 km2. Amongst the equipment
recovered were the two inertial reference systems. They have been used
for analysis.</P>

<P>l) The post-flight analysis of telemetry data has listed a number of
additional anomalies which are being investigated but are not considered
significant to the failure.</P>

<P>m) The inertial reference system of Ariane 5 is essentially common to
a system which is presently flying on Ariane 4. The part of the software
which caused the interruption in the inertial system computers is used
before launch to align the inertial reference system and, in Ariane 4,
also to enable a rapid realignment of the system in case of a late hold
in the countdown. This realignment function, which does not serve any purpose
on Ariane 5, was nevertheless retained for commonality reasons and allowed,
as in Ariane 4, to operate for approx. 40 seconds after lift-off.</P>

<P>n) During design of the software of the inertial reference system used
for Ariane 4 and Ariane 5, a decision was taken that it was not necessary
to protect the inertial system computer from being made inoperative by
an excessive value of the variable related to the horizontal velocity,
a protection which was provided for several other variables of the alignment
software. When taking this design decision, it was not analysed or fully
understood which values this particular variable might assume when the
alignment software was allowed to operate after lift-off.</P>

<P>o) In Ariane 4 flights using the same type of inertial reference system
there has been no such failure because the trajectory during the first
40 seconds of flight is such that the particular variable related to horizontal
velocity cannot reach, with an adequate operational margin, a value beyond
the limit present in the software.</P>

<P>p) Ariane 5 has a high initial acceleration and a trajectory which leads
to a build-up of horizontal velocity which is five times more rapid than
for Ariane 4. The higher horizontal velocity of Ariane 5 generated, within
the 40-second timeframe, the excessive value which caused the inertial
system computers to cease operation.</P>

<P>q) The purpose of the review process, which involves all major partners
in the Ariane 5 programme, is to validate design decisions and to obtain
flight qualification. In this process, the limitations of the alignment
software were not fully analysed and the possible implications of allowing
it to continue to function during flight were not realised.</P>

<P>r) The specification of the inertial reference system and the tests
performed at equipment level did not specifically include the Ariane 5
trajectory data. Consequently the realignment function was not tested under
simulated Ariane 5 flight conditions, and the design error was not discovered.</P>

<P>s) It would have been technically feasible to include almost the entire
inertial reference system in the overall system simulations which were
performed. For a number of reasons it was decided to use the simulated
output of the inertial reference system, not the system itself or its detailed
simulation. Had the system been included, the failure could have been detected.</P>

<P>t) Post-flight simulations have been carried out on a computer with
software of the inertial reference system and with a simulated environment,
including the actual trajectory data from the Ariane 501 flight. These
simulations have faithfully reproduced the chain of events leading to the
failure of the inertial reference systems.</P>
</UL>

<H4>3.2 CAUSE OF THE FAILURE</H4>

<P>The failure of the Ariane 501 was caused by the complete loss of guidance
and attitude information 37 seconds after start of the main engine ignition
sequence (30 seconds after lift- off). This loss of information was due
to specification and design errors in the software of the inertial reference
system.</P>

<P>The extensive reviews and tests carried out during the Ariane 5 Development
Programme did not include adequate analysis and testing of the inertial
reference system or of the complete flight control system, which could
have detected the potential failure.</P>

<H3>4. RECOMMENDATIONS</H3>

<P>On the basis of its analyses and conclusions, the Board makes the following
recommendations.</P>

<P><B>R1 </B>Switch off the alignment function of the inertial reference
system immediately after lift-off. More generally, no software function
should run during flight unless it is needed.</P>

<P><B>R2 </B>Prepare a test facility including as much real equipment as
technically feasible, inject realistic input data, and perform complete,
closed-loop, system testing. Complete simulations must take place before
any mission. A high test coverage has to be obtained.</P>

<P><B>R3 </B>Do not allow any sensor, such as the inertial reference system,
to stop sending best effort data.</P>

<P><B>R4 </B>Organize, for each item of equipment incorporating software,
a specific software qualification review. The Industrial Architect shall
take part in these reviews and report on complete system testing performed
with the equipment. All restrictions on use of the equipment shall be made
explicit for the Review Board. Make all critical software a Configuration
Controlled Item (CCI).</P>

<P><B>R5 </B>Review all flight software (including embedded software),
and in particular :</P>

<UL>
<LI>Identify all implicit assumptions made by the code and its justification
documents on the values of quantities provided by the equipment. Check
these assumptions against the restrictions on use of the equipment.</LI>

<LI>Verify the range of values taken by any internal or communication variables
in the software.</LI>

<LI>Solutions to potential problems in the on-board computer software,
paying particular attention to on-board computer switch over, shall be
proposed by the project team and reviewed by a group of external experts,
who shall report to the on-board computer Qualification Board.</LI>
</UL>

<P><B>R6</B> Wherever technically feasible, consider confining exceptions
to tasks and devise backup capabilities.</P>

<P><B>R7</B> Provide more data to the telemetry upon failure of any component,
so that recovering equipment will be less essential.</P>

<P><B>R8</B> Reconsider the definition of critical components, taking failures
of software origin into account (particularly single point failures).</P>

<P><B>R9</B> Include external (to the project) participants when reviewing
specifications, code and justification documents. Make sure that these
reviews consider the substance of arguments, rather than check that verifications
have been made.</P>

<P><B>R10</B> Include trajectory data in specifications and test requirements.</P>

<P><B>R11</B> Review the test coverage of existing equipment and extend
it where it is deemed necessary.</P>

<P><B>R12</B> Give the justification documents the same attention as code.
Improve the technique for keeping code and its justifications consistent.</P>

<P><B>R13</B> Set up a team that will prepare the procedure for qualifying
software, propose stringent rules for confirming such qualification, and
ascertain that specification, verification and testing of software are
of a consistently high quality in the Ariane 5 programme. Including external
RAMS experts is to be considered.</P>

<P><B>R14</B> A more transparent organisation of the cooperation among
the partners in the Ariane 5 programme must be considered. Close engineering
cooperation, with clear cut authority and responsibility, is needed to
achieve system coherence, with simple and clear interfaces between partners.</P>

<CENTER><P>- END -</P></CENTER>

</BODY>
</HTML>