Ariane V update

Ariane V update

[Ken Garlington]

TOUGH BREAK:   Ariane wil delay until at least September its
      second test flight of the new generation Ariane-5 rocket whose
      maiden flight blew up on lift-off last summer.  The flight had
      been scheduled to take place before July.  (Financial Times)

Ariane V update

[Ken Garlington]

Aviation Week and Space Technology has an article on the Ariane V 
failure. It quotes Jean-Michel Desobeau, director of engineering at 
Arianespace as saying:

"The on-board computer received or self-generated bad attitude
information. It thought the vehicle was at the wrong attitude, commanded 
the SRB nozzles to compensate, and they executed it."

Other items:

  o  The flight is called a "qualification" flight, which sounds to me
     like it was part of the test program and not really a "production"
     flight.

  o  Although the telemetry data from the inertial units showed no
     failures, the output path to telemetry from the IMUs is different
     than the one to the on-board computers, so "there is a chance
     the computers were receiving different information than the
     telemetry."

  o  The on-board computers are dual-redundant (which amazed me; I would
     have expected triplex at least). The June 12, 1995 edition of AW&ST
     apparently had an article on some problems encountered with the
     development of the fail-operational [!] fault detection algorithms
     between the two computers, requiring extra manpower to solve.

  o  "The computers are more powerful than the single [non-redundant!]
     one in the Ariane 4, but they use the same general logic."

  o  The on-board computers have a "common sense" algorithms to fault
     isolate between the two inertial units. [In my experience, these
     algorithms are not easy to do right.]

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane V update

[John McCabe]

Ken Garlington <garlingtonke@lmtas.lmco.com> wrote:

<..snip..>

>  o  The flight is called a "qualification" flight, which sounds to me
>     like it was part of the test program and not really a "production"
>     flight.

Weeelll... you could say that. It was basically the first real flight
but the payload (Cluster) was an experimental satellite (4 satellites
actually) funded by the European Space Agency, so it wasn't a
commercial flight.

>  o  The on-board computers are dual-redundant (which amazed me; I would
>     have expected triplex at least).The June 12, 1995 edition of AW&ST
>     apparently had an article on some problems encountered with the
>     development of the fail-operational [!] fault detection algorithms
>     between the two computers, requiring extra manpower to solve.

>  o  "The computers are more powerful than the single [non-redundant!]
>     one in the Ariane 4, but they use the same general logic."

You may be confusing redundancy with something else here. In my
interpretation, Dual-redundant means that each unit is effectively 2
identical units in e.g. 1 box. As far as I understand it, duplex or
triplex is related to having two/three separate units operating in
parallel using a voting system for example to aid fault-tolerance. I'm
not sure if Ariane 5 has this but it would seem reasonable for it to
do so. On the other hand, with Ariane 4, although it has a single
computer, this computer may actually contain 2 redundant halves.

Generally in the equipment we build, dual-redundancy is perfectly
adequate to satisfy most reliability requirements, whereas
triple-redundancy doesn't improve the (calculated) reliability much.
The dual-redundant system I work on at the moment has a calculated
reliability figure of ~0.996, but we had a look at creating a
single-redundant unit with a calculated reliability of ~0.989 or so.
There's always a trade-off though between mass, power and reliability
(and cost of course!).

However, if you can give any more information on the content of the
article you mention, it may prove that I am talking out of my arse :-)

<..snip..>

Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ariane V update

[Ken Garlington]

John McCabe wrote:
> 
> Generally in the equipment we build, dual-redundancy is perfectly
> adequate to satisfy most reliability requirements, whereas
> triple-redundancy doesn't improve the (calculated) reliability much.
> The dual-redundant system I work on at the moment has a calculated
> reliability figure of ~0.996, but we had a look at creating a
> single-redundant unit with a calculated reliability of ~0.989 or so.
> There's always a trade-off though between mass, power and reliability
> (and cost of course!).

Hmmm... for most flight control systems, we usually have to have at least
triplex (or triple-redundant; my experience is to use these terms interchangably), 
since it is practically impossible to guarantee 100% fault isolation (and thus 
100% fail-operate status) when there is a failure between one of two 
dual-redundant units. Usually, you see something like:

single-redundant: first failure ceases operation (obviously).
dual-redundant:   first failure can be isolated in 95+ percent of cases to
                  the failed unit, using techniques like built-in test, etc.
triple-redundant: first failure can be isolated 100% through voting.
                  second failure reduces to dual-redundant case.
quad-redundant:   first failure can be isolated 100% through voting.
                  second failure reduces to triple-redundant case.

(Of course, this assumes no simultaneous failures. You know, like a software
fault in a redundant system with a common mode software error. :)

I would have thought, given the monetary, safety, etc. effects of a flight control 
failure on a missile, that the system would be designed to always handle a first 
failure, which usually implies triplex (triple-redundant) at a minimum.

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane V update

[John McCabe]

Ken Garlington <garlingtonke@lmtas.lmco.com> wrote:

<..snip..>

>Hmmm... for most flight control systems, we usually have to have at least
>triplex (or triple-redundant; my experience is to use these terms interchangably), 

This is basically the only place we differ on this (terminology). I
coonsider there to be two distinct methods of increasing reliability
in this manner:

multiplexing:      e.g. duplex, triplex etc. In this case you have
                   more than one unit operating in parallel on the
                   same data, using e.g. a voting mechanism.
redundancy:        is where each unit is essentially 2 or more units
                   (in one box) only one of which is operational at
                   any one time.

Redundancy can then be split into 2 separate cases:

"cold" redundancy: where only 1 of the "sub-units" is powered at any
                   one time - resulting in complicated switching and
                   commanding mecahnisms which take some time to be
                   performed.
"hot" redundancy:  where all "sub-units" are powered but only 1 is
                   operational.

It is therefore quite feasible (although maybe not particularly
practical or useful) for each unit in a multiplexed system to also
have internal redundancy.

<..snip..>

>(Of course, this assumes no simultaneous failures. You know, like a software
>fault in a redundant system with a common mode software error. :)

>I would have thought, given the monetary, safety, etc. effects of a flight control 
>failure on a missile, that the system would be designed to always handle a first 
>failure, which usually implies triplex (triple-redundant) at a minimum.

I agree entirely with this. A triplex (in my terminology) system would
appear to be best type of implementation for a launch vehicle as it is
continually monitoring itself and can therefore respond immediately to
a first failure.

Redundancy (in my terminology) is better suited to a satellite
(instrument) implementation where a fault is less likely to be
unrecoverable, unlike the Ariane-5 failure.


I'll try to find out more about the actual configuration and let you
know if I find anything of use.


Best Regards
John McCabe <john@assen.demon.co.uk>