Aviation Week & Space Technology
June 12, 1995, pp. 114-116
"Ariane 5 Tests Peak as First Flight Nears"
Craig Covault/Paris

Europe's Ariane 5 heavy booster program is beginning its final series of critical propulsion and software tests to clear the 2.5-million-lb.-thrust vehicle for its first mission. The flight is scheduled to lift off from French Guiana late this year.

There are major software and system test differences between Ariane 5 and the previous Ariane 4 development. Ariane 5 has for more system redundancy than Ariane 4. This requires the new vehicle and its software to undergo much more prelaunch computer simulation to ensure the vehicle can shift to backup systems, especially at critical moments such as solid rocket booster separation.

Ariane 4 systems were, of course, tested thoroughly. But with the added Ariane 5 redundancy, its test team must verify that the software and subsystems can function in failure scenarios that would cause a mission failure with the older Ariane 4.

A key difference that inherently affects testing is that the Ariane 5 flight control and electrical systems are fully integrated and redundant. These two systems are totally separate in Ariane 4, however.

From an avionics, electrical and propulsion system integration perspective, the Ariane 5 design is more like that of the space shuttle than existing expendable boosters. And like the space shuttle program, the Ariane 5 effort uses a software development and validation process similar to that at the Shuttle Avionics Integration Laboratory (SAIL) at the Johnson Space Center, Houston.

Ariane 5, just like the shuttle, also operates using a U.S. Mil-Std 1553B type bus configuration.

Launch of the first European Space Agency Ariane 5 vehicle is scheduled for Nov. 29 carrying the four ESA/Dornier Cluster magnetospheric science spacecraft. But the actual launch date will depend upon the success and pace of final tests now underway at Kourou and industrial facilities across Europe.

Top managers will hold the Nov. 29 target to maintain workforce momentum, but a delay into early 1996 is possible. Such a slip would not damage the overall program, however - as long as it ends in a mission success.

The $6.37-billion project is managed by the French space agency CNES with Aerospatiale the chief industrial architect for the future commercial Arianespace vehicle.

Key tests toward first launch are:

Final development and testing of the flight software for first flight is an ongoing critical test issue, according to Serge Petit, Aerospatiale Ariane 5 program manager at Les Mureaux, west of Paris.

"I can say it is a difficult challenge, but we expect to deliver the on-board software on time," according to Gerard Auvray, who heads Ariane 5 flight control qualification.

The qualification testing is being done at Aerospatiale's Functional Simulation Facility at Les Mureaux. "For the final qualification of Ariane 5 flight software, we plan to perform about 300 runs involving simulated flights or short parts of the simulated flight," he said. About one half of the 300 tests include ignition of the Vulcain engine and powered flight through separation of the solid rocket boosters at about 2 min. 28 sec. The rest of the simulated launches involve various portions of the ascent profile with the vehicle at higher altitudes and lower dynamic pressures. This final major software test series is just now getting underway.

The program has good simulation experience to build upon in the final qualification phase because it already performed similar activity in developing software for previous critical tests, such as the cryogenic battleship stage fired several times at Kourou during 1994, Auvray said.

The development of the simulation software has taken about two years, but it has also been used concurrently for earlier tests such as the battleship propulsion series.

Aerospatiale has overall responsibility for Ariane 5 software development, but a German-based software division of the British company EASAMS Ltd. is the major contractor for on-board software, according to Auvray.

"WE WORK IN AN INTEGRATED manner between Aerospatiale and EASAMS," he said. The British company also is heavily involved in Ariane 4 software.

Ariane 5 has 60 major avionics-related systems and subsystems that are basically divided between 30 primary and 30 backup. Only the telemetry system is not dual redundant.

The Ariane 5 avionics and flight control system is designed to be "fail-operational," meaning a major failure in essentially all avionics and most electrical and hydraulic servos would trigger a shift to a backup.

The avionics have "sensor recovery," meaning that the main algorithms in the software are instantly paired with backup data in the event of a primary system malfunction.

If the primary inertial reference unit (IRU) fails or a gyro fails, data from the backup are immediately incorporated in the backup avionics string to maintain flight. Ariane 5's IRU is an improved version of Ariane 4's, and the older Ariane 4 is now also being equipped with the version modernized for Ariane 5.

Two Swedish Saab computers are the heart of the Ariane 5 flight control system. Each computer actually comprises two processors - one loaded with flight algorithms and the other dedicated to managing the information flowing along the primary system. The some process is underway in the offline backup.

All of the real-time system performance data and commands from the computers flow along the bus in cyclic frames. Some of the data are synchronized, while much other data are based on events and vehicle performance.

Each cyclic frame has a 70-millisec. duration and is organized with "empty slots" in which the nonsynchronized data on flight performance are inserted as the vehicle flies.

To simulate this and essentially "flight test" the Ariane 5 before it ever flies, Aerospatiale uses two integrated simulation systems. One is designated the Avionics and Stage Behavior Simulator, which can duplicate two types of information.

First, it can simulate any electrical device in the vehicle by using each component's software model or an actual component. Secondly, it can use this information to simulate the behavior of each Ariane 5 stage. It operates at the full bus level and can simulate and separate out several different component configurations. It is also possible to mix the real equipment and simulated equipment as part of simulations.

"We can use one real channel and one simulated channel, with part of a channel using simulated equipment and part of another channel using real equipment," Auvray said. "All vehicle configurations are available."

The second major element of the system is devoted to flight control. It is able to compute vehicle performance and ever-changing forces, such as dynamic pressure, to generate realistic flight conditions.

The Avionics and Stage Behavior Simulator has about 200,000 lines of computer code. But the computerized scripts prepared to provide realistic simulation of failures have about two or three times more lines of code.

THE SECOND MAJOR Ariane 5 simulation system - the Real-Time Dynamic Behavior Simulator - signals a marked improvement between the Ariane 4 and 5 test programs since many more complex interactions can be tested.

This simulator duplicates real-time dynamic behavior, taking into account all the elements that can affect the vehicle, such as aeroelasticity, propulsion, aerodynamics, propellant sloshing and real-time mass ratios. It too is able to use software models of the hardware, or the actual hardware itself.

The two major simulation systems can be integrated for detailed Ariane 5 mission simulations.

"When we have tools like these, we can do everything. So the challenge to the program is what specifically to simulate - or not to simulate - with the time available before launch," Auvray said.


Aviation Week & Space Technology
July 26, 1996 pp. 33-35
"Board Faults Ariane 5 Software"
Pierre Sparaco/Paris

Fundamental errors in the design and testing of the software for the inertial reference system (IRS) caused the failure of the first Ariane 5, according to the investigation board.

After European contractors and agencies spent a decade and $8 billion on Ariane 5, then boasting it would have 98.5% reliability, a common flaw simultaneously halted both IRSs - a failure caused by a numerical overflow in an unused and unneeded software routine.

THE REPORT, COMPLETED last week, besides determining causes for the June 4 accident, is a strong criticism of the IRS computer software design, test and simulation that preceded the booster's first launch.

Aviation Week & Space Technology reported more than a year ago that software was a concern in the program (AW&ST June 12, 1995, p. 114).

In the wake of the investigation team's findings and recommendations, the booster's second qualification launch has now been tentatively rescheduled for next March-April, about 3-4 months later than initially planned.

The report said Ariane 5's other software may have similar defects. The board expressed serious concern that "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 this view is also accepted in other areas of Ariane 5 software design."

The board also expressed concern over a lack of engineering cooperation and lines of authority in the program. It recommends a revised program organization involving "close engineering cooperation, with clear-cut authority and responsibility that is required to achieve a stronger system coherence," the report said.

"We are all guilty, we have to assume that," European Space Agency Managing Director Jean-Marie Luton said last week, reluctantly citing the names of Ariane 5 contractors. Sextant Avionique developed the IRS, Matra Marconi Space is responsible for the vehicle equipment bay, Aerospatiale Space & Defense Div. is the booster's "industrial architect" and the CNES French space agency has program management responsibility.

About 30 sec. after Ariane 5s liftoff, the backup IRS computer, which was operating on standby for guidance and attitude control, became inoperative. The failure was caused by an overflow error in a software routine for IRS drift alignment on the ground. Though not used, the routine executes for about 40 sec. after liftoff. Flight motion made the routine calculate a large apparent horizontal drift, and it was this number that overflowed. Ariane 5 philosophy is that the overflow error halts the entire IRS processor.

THE ACTIVE IRS, which used identical hardware and software, failed for the same reasons 0.05 sec. later, resulting in the total loss of correct flight guidance information.

"As a result of the double failure, the active IRS only transmitted diagnostic information to the booster's on-board computer, which was interpreted as flight data and used for flight control calculations," Jacques-Louis Lions, chairman of the inquiry board, explained. "The solid boosters' gimbals - and the Vulcain cryogenic engine - were then asked to correct a [flight path] change that was not occurring," he added.

The resulting deflection produced a 20-deg. angle of attack, high aerodynamic loads and the booster's disintegration. Simulation, ground tests and extensive technical reviews "did not include adequate analysis and testing of the IRS or the complete flight control system, which could have detected the potential failure," investigation team members said.

The continuation of the IRS alignment routine into initial flight is a carry-over from Ariane 4, where the scheme makes possible quick IRS recycling for launch holds at liftoff minus 5-9 sec. The feature was used since 1989 but it is not needed at all on Ariane 5. It was "maintained for commonality reasons, presumably based on the view that ... it was not wise to make changes in software that worked well on Ariane 4," the report said.

The Ariane 4 flight trajectory gives an apparent IRS horizontal drift that will not cause an overflow, but Ariane 5 has about five times more horizontal motion during the 40 sec., and this fact was overlooked.

"Ariane 5's [different] horizontal velocity data were not fully analyzed and included in the system," Wolfgang Kubbat acknowledged. He is a member of the nine-member independent investigation team that was formed in June to determine the causes of the failure.

"Extensive reviews and tests during the development program did not include adequate analysis and testing of the IRS or complete flight control system, which would have detected the potential failure," Kubbat said. "This was not analyzed or fully understood," Lions added.

ACCORDING TO MICHEL MUGNIER, head of CNES Launcher Div., "Such failure could have appeared on Ariane 4 if its [initial] flight path had been different. Some [Ariane 5] tests were not made because technicians felt they were not required. Of course, if their cost had been only one franc [a few cents], they would have been done," Mugnier confessed, referring to the tight budget constraints. Sextant's IRS was installed on Ariane 4 for the last 23 launches and proved to be reliable, he added.

According to the investigation board, including "almost" the complete IRS in simulation procedures was feasible. Nevertheless, only simulated IRS output was considered, not the system itself. "Had the [complete] system been included [in the simulation process], the failure could have been detected," the report noted.

To meet a management target that the IRS computer have no more than 80% workload, three variables were left unprotected from overflow in floating point-to-integer conversions. They were assumed to have a large operational margin to overflow, "which in the case of the [horizontal drift] turned out to be faulty," the report said. "It is even more important to note it was jointly agreed [by CNES and its contractors] not to include Ariane 5 trajectory data in the IRS' requirements and specifications," the report emphasized.

THE DECISION TO HAVE an overflow stop the entire IRS processor proved fatal. Restart is not feasible because booster attitude cannot be recalculated after the processor's shutdown. "The reason behind this drastic action lies in the Ariane program's 'culture' of only addressing random hardware failures."

Nevertheless, the IRS computers could have continued to give "best estimates" of the required attitude information, the report added. "There is reason for concern that a software exception should be allowed, or even required, to cause the processor to halt while handling mission-critical equipment. This resulted in the switch-off of two healthy equipment units."

The IRS was developed according to specifications that stipulated the processor was to be stopped by any detected exception. But when such exception developed, it resulted from a design error, not a random failure.

Critical software must now be identified "at a very detailed level" and a "reasonable backup policy" must be implemented. A declaration of limitation for every mission-critical item would have identified noncompliances with Ariane 5s flight path. Limitations in the IRS software were not fully analyzed during reviews, and it was not understood that test coverage was inadequate to expose such limitations, the report added.

Two test launches are still required to qualify Ariane 5. The booster's third launch is now scheduled to "partly" become a qualification flight, Luton said. ESA, CNES and Arianespace officials are expected to jointly decide in September if the third launch will nevertheless inject a commercial payload into orbit.

The cost burden resulting from the program's additional delay has not been exactly determined as yet but is expected to be "only in the order of 2-4% of the $8-billion investment since [Ariane 5] go-ahead," Luton said.

ALTHOUGH MINIMAL, the additional spending will require the unanimous agreement of ESA's 14 member states. Before the failure, the program was nearly 20% over budget. With funding extremely tight, the additional costs resulting from the new delay and modifications and tests are expected to further complicate ESA's cost-cutting effort and could seriously affect the agency's science programs.

ESA members should not increase their investment in Ariane 5, and the agency must absorb the extra expenditure and remain within the limits of approved budgets, Juergen Ruttgers, Germany's research and technology minister, said.

In the wake of the board's recommendations,. ESA, CNES and their contractors plan to establish additional test facilities that will use "as much real equipment as feasible, inject realistic input data and perform complete closed-loop system testing. " To increase vigilance, the board recommended that outside experts participate in program reviews.


Aviation Week & Space Technology
August 5, 1996 pg. 74
EDITORIAL: "Ariane 5 'culture' must change"

No one should doubt the European Ariane 5 engineering team's ability to recover from the program's disastrous first launch failure on June 4. The Ariane technical team has demonstrated its ability to recover effectively after the handful of other accidents over the course of the 20-year program.

Strong thanks are due the accident investigation board headed by Jacques-Louis Lions of the French Academie des Sciences. The board conducted a timely and open investigation that will serve as a roadmap to get the program back on track. In summary, the board found a lack of management oversight, a lack of adequate testing and a poor software/avionics design (AW&ST July 29, p. 33).

But there is more than that. The board's recommendations indicate a peculiar climate in the program. The project seemed distracted from harsh engineering and flight test realities and must now change its "management culture" to recover.

Prior to the accident, the Ariane 5 culture was dominated by marketing hype and contractors more interested in projecting their own "global leadership" and European identity than establishment of a homogeneous team. The daily goal was to be "politically correct" and "commercially discrete" with no one on the team asking penetrating questions.

This attitude was carried to ridiculous extreme the day of the accident when the European Space Agency's written statement on the failure avoided saying there even WAS a failure. "The first Ariane 5 flight did not result in validation of Europe's new launcher" was as close as ESA's statement got to saying there was indeed a big problem.

The lack of candor spoke volumes for the culture inherent in the program. The accident took place on the world stage. But the European statement treated the loss of the first Ariane 5 as if all the flaming debris would go unnoticed.

When marketing fervor, contractor self-promotion and political caution in the extreme begin to dominate the management of any program, the falling debris is predictable. This misplaced emphasis and lack of reality was becoming apparent before the accident.

It doesn't take a rocket scientist to figure out that you cannot reliably claim a 98.5% success rate for a complex new launch vehicle before it ever leaves the ground. Yet that is exactly what the Ariane 5 program was doing years before first launch. Program managers "assumed" it would be so, just as the failure board criticized the "assumptions" made in designing the faulty flight software.

 "We are all guilty," ESA Managing Director Jean-Marie Luton said. He was again being politically correct and commercially discrete in trying to softly spread the blame. But what he was actually saying is that the ESA/CNES/contractor management system did not work. And some elements of it are more guilty than others.

ESA and CNES certainly must shoulder blame, but in Europe (more so than in the U.S.), the contractors rather than the space agencies rule the roost. Aerospatiale as "industrial architect" and Matra Marconi Space and Sextant Avionique as key contractors for software and avionics bear more responsibility for the accident.

The very term "industrial architect" clouds the lines of authority. Aerospatiale had overall responsibility for management of the software, as the company's own written documentation shows. And Aerospatiale was seriously distracted from its goal of ensuring a good, redundant design and test program with key participation by the other contractors.

Ariane 5 management has been promising potential customers a more reliable, redundant launch vehicle. Yet the Ariane 5 avionics and software design was seriously flawed, the test program philosophy and facilities were inadequate, and the redundancy was not there to protect against the malfunctions. Finally, the management structure was inadequate to catch the faults at any level. An $8-billion vehicle that was being heavily marketed as having 98.5% reliability in fact contained a 100% unreliable system.

What the engineers need now is the time to solve these problems without schedule pressure. If Ariane 5 management sets the specific goal of having the booster fly again, "in time for the 1997 Paris Air Show" next June, that should raise concern as a "marketing-based schedule" set by the old culture - rather than a recovery schedule dictated by the challenges of fixing a flawed program.