OT?: AF 447 and avionics software

OT?: AF 447 and avionics software

[Alex R. Mosteo]

I'm sure most of us are following the news on this issue. I just read an 
article where an 'expert' questions "damn computers". Particularly this 
quote:

"In these fly-by-wire systems, one never really knows if one has checked out 
all possible combinations of events to make sure that the computer properly 
reacts,"

http://www.time.com/time/world/article/0,8599,1902421,00.html

Frankly I know nothing about the aviation standards for software/computer 
use, but I suspect it is somewhat more strict than "one never really knows". 
I mean, surely you can't test everything, but I guess one can be reasonably 
confident on the system design!

Now, there's a trend forming pointing to the ADIRU [1] unit, because of 
recent incidents like the Qantas flight mentioned in the article. I'm not 
sure there's really verified reasons to point to it yet but, trying to stay 
on topic:

I think Airbus is mainly Ada, right? Do you know some good place to read 
about its software systems?

What about these ADIRU units, are they delivered to Airbus by some provider 
or are of their own built?

[1] http://en.wikipedia.org/wiki/Air_Data_Inertial_Reference_Unit

Re: OT?: AF 447 and avionics software

[Martin]

On Jun 4, 10:29 am, "Alex R. Mosteo" <alejan...@mosteo.com> wrote:
> I'm sure most of us are following the news on this issue. I just read an
> article where an 'expert' questions "damn computers". Particularly this
> quote:
>
> "In these fly-by-wire systems, one never really knows if one has checked out
> all possible combinations of events to make sure that the computer properly
> reacts,"
>
> http://www.time.com/time/world/article/0,8599,1902421,00.html
>
> Frankly I know nothing about the aviation standards for software/computer
> use, but I suspect it is somewhat more strict than "one never really knows".
> I mean, surely you can't test everything, but I guess one can be reasonably
> confident on the system design!
>
> Now, there's a trend forming pointing to the ADIRU [1] unit, because of
> recent incidents like the Qantas flight mentioned in the article. I'm not
> sure there's really verified reasons to point to it yet but, trying to stay
> on topic:
>
> I think Airbus is mainly Ada, right? Do you know some good place to read
> about its software systems?
>
> What about these ADIRU units, are they delivered to Airbus by some provider
> or are of their own built?
>
> [1]http://en.wikipedia.org/wiki/Air_Data_Inertial_Reference_Unit

They can analysis code to ensure absense of runtime error (e.g. using
SPARK and/or tools like PolySpace) but testing all possible scenarios
is a different kettle of fish all together.

The systems may even do everything that was required of them but how
do you 'test' the requirements are 'sensible'?..

Cheers
-- Martin

Re: OT?: AF 447 and avionics software

[roderick.chapman]

On Jun 4, 12:02 pm, Martin <martin.do...@btopenworld.com> wrote:
> On Jun 4, 10:29 am, "Alex R. Mosteo" <alejan...@mosteo.com> wrote:
>
>
>
> > I'm sure most of us are following the news on this issue. I just read an
> > article where an 'expert' questions "damn computers". Particularly this
> > quote:
>
> > "In these fly-by-wire systems, one never really knows if one has checked out
> > all possible combinations of events to make sure that the computer properly
> > reacts,"
>
> >http://www.time.com/time/world/article/0,8599,1902421,00.html
>
> > Frankly I know nothing about the aviation standards for software/computer
> > use, but I suspect it is somewhat more strict than "one never really knows".
> > I mean, surely you can't test everything, but I guess one can be reasonably
> > confident on the system design!
>
> > Now, there's a trend forming pointing to the ADIRU [1] unit, because of
> > recent incidents like the Qantas flight mentioned in the article. I'm not
> > sure there's really verified reasons to point to it yet but, trying to stay
> > on topic:
>
> > I think Airbus is mainly Ada, right? Do you know some good place to read
> > about its software systems?
>
> > What about these ADIRU units, are they delivered to Airbus by some provider
> > or are of their own built?
>
> > [1]http://en.wikipedia.org/wiki/Air_Data_Inertial_Reference_Unit
>
> They can analysis code to ensure absense of runtime error (e.g. using
> SPARK and/or tools like PolySpace) but testing all possible scenarios
> is a different kettle of fish all together.

This is not entirely true.

There is certainly SPARK code in the Rolls-Royce engines that power
the
A380 and Boeing 787.

There is no SPARK in the other major avionics systems on
the Airbus A320, A330, A340 or A380. (After all, if Airbus
were a SPARK customer I would know for sure!)

Airbus have cited the use of Patrick Cousot's ASTREE tool
in the analysis of their flight control codes - this
is published somewhere, so I'm sure a quick google
search will reveal the correct ref.

 - Rod Chapman, SPARK Team

Re: OT?: AF 447 and avionics software

[Martin]

On Jun 4, 7:20 pm, roderick.chap...@googlemail.com wrote:
> On Jun 4, 12:02 pm, Martin <martin.do...@btopenworld.com> wrote:
>
>
>
> > On Jun 4, 10:29 am, "Alex R. Mosteo" <alejan...@mosteo.com> wrote:
>
> > > I'm sure most of us are following the news on this issue. I just read an
> > > article where an 'expert' questions "damn computers". Particularly this
> > > quote:
>
> > > "In these fly-by-wire systems, one never really knows if one has checked out
> > > all possible combinations of events to make sure that the computer properly
> > > reacts,"
>
> > >http://www.time.com/time/world/article/0,8599,1902421,00.html
>
> > > Frankly I know nothing about the aviation standards for software/computer
> > > use, but I suspect it is somewhat more strict than "one never really knows".
> > > I mean, surely you can't test everything, but I guess one can be reasonably
> > > confident on the system design!
>
> > > Now, there's a trend forming pointing to the ADIRU [1] unit, because of
> > > recent incidents like the Qantas flight mentioned in the article. I'm not
> > > sure there's really verified reasons to point to it yet but, trying to stay
> > > on topic:
>
> > > I think Airbus is mainly Ada, right? Do you know some good place to read
> > > about its software systems?
>
> > > What about these ADIRU units, are they delivered to Airbus by some provider
> > > or are of their own built?
>
> > > [1]http://en.wikipedia.org/wiki/Air_Data_Inertial_Reference_Unit
>
> > They can analysis code to ensure absense of runtime error (e.g. using
> > SPARK and/or tools like PolySpace) but testing all possible scenarios
> > is a different kettle of fish all together.
>
> This is not entirely true.
>
> There is certainly SPARK code in the Rolls-Royce engines that power
> the
> A380 and Boeing 787.
>
> There is no SPARK in the other major avionics systems on
> the Airbus A320, A330, A340 or A380. (After all, if Airbus
> were a SPARK customer I would know for sure!)
>
> Airbus have cited the use of Patrick Cousot's ASTREE tool
> in the analysis of their flight control codes - this
> is published somewhere, so I'm sure a quick google
> search will reveal the correct ref.
>
>  - Rod Chapman, SPARK Team

Sorry, I wasn't trying to imply that SPARK was used in this case -
just an example of a tool that is available and could be used in such
systems. I have no idea if PolySpace or a PolySpace-like tool is used
either. I would doubt they only do dynamic testing.

Cheers
-- Martin

Re: OT?: AF 447 and avionics software

[Egil Høvik]

On Jun 4, 11:29 am, "Alex R. Mosteo" <alejan...@mosteo.com> wrote:
> What about these ADIRU units, are they delivered to Airbus by some provider
> or are of their own built?
>


Take a look at this recent press release about the A350 XWB:
http://www.adacore.com/2009/06/01/a350/


--
~egilhh

Re: OT?: AF 447 and avionics software

[Alex R. Mosteo]

Egil Høvik wrote:

> On Jun 4, 11:29 am, "Alex R. Mosteo" <alejan...@mosteo.com> wrote:
>> What about these ADIRU units, are they delivered to Airbus by some
>> provider or are of their own built?
>>
> 
> 
> Take a look at this recent press release about the A350 XWB:
> http://www.adacore.com/2009/06/01/a350/

Very interesting, thanks.

Re: OT?: AF 447 and avionics software

[Olivier Scalbert]

Egil H�vik wrote:
> On Jun 4, 11:29 am, "Alex R. Mosteo" <alejan...@mosteo.com> wrote:
>> What about these ADIRU units, are they delivered to Airbus by some provider
>> or are of their own built?
>>
> 
> 
> Take a look at this recent press release about the A350 XWB:
> http://www.adacore.com/2009/06/01/a350/
> 
> 
> --
> ~egilhh

Thanks, very interesting !
I am quite surprised to read "Agile Programming techniques" in such a 
kind of project.

Olivier

Re: OT?: AF 447 and avionics software

[Matteo Bordin]

On 4 Giu, 21:02, Olivier Scalbert <olivier.scalb...@algosyn.com>
wrote:
> Egil Høvik wrote:
> > On Jun 4, 11:29 am, "Alex R. Mosteo" <alejan...@mosteo.com> wrote:
> >> What about these ADIRU units, are they delivered to Airbus by some provider
> >> or are of their own built?
>
> > Take a look at this recent press release about the A350 XWB:
> >http://www.adacore.com/2009/06/01/a350/
>
> > --
> > ~egilhh
>
> Thanks, very interesting !
> I am quite surprised to read "Agile Programming techniques" in such a
> kind of project.

Take a look at www.open-do.org !


>
> Olivier

Re: OT?: AF 447 and avionics software

[MRE]

On 4 Jun., 11:29, "Alex R. Mosteo" <alejan...@mosteo.com> wrote:

> I think Airbus is mainly Ada, right? Do you know some good place to read
> about its software systems?
No, not really. In my experience Airbus does not mandate the use of a
programming
language. Thus the language used depends on the supplier. You will
find a lot
of C in the boxes. In a number of critical systems Airbus prefer to
use
SCADE, which can generate C, Ada and afaik SPARK.

> "In these fly-by-wire systems, one never really knows if one has checked out
> all possible combinations of events to make sure that the computer properly
> reacts,"

Sorry in advance for the language: This quotation is pretty fucking
brilliant.
The rocket scientist that came to this brilliant conclusion seems to
be a real
expert in the field of complexity theory.
Thing is: even if you use analog electronics 50's style you can not be
sure
that you have checked all possible combinations of events. So what's
the
proposed conclusion? Let the pilots fly manually? Will those pencil
pilots
in the media ever learn that their "investigative journalism" is just
a form
of stirring bullshit?
Sorry, I'll stop letting off steam right this instant.

>What about these ADIRU units, are they delivered to Airbus by some provider
>or are of their own built?
Most of the systems in a modern passenger aircraft are being built by
companies that specialize in certain fields. Airbus, Boeing,
Embraer,...
just specify what the need and then buy the things and put them
together.

Best regards,

Marc

Re: OT?: AF 447 and avionics software

[sjw]

On Jun 5, 8:22 am, MRE <Marc.Enzm...@web.de> wrote:

> The rocket scientist that came to this brilliant conclusion seems to
> be a real expert in the field of complexity theory.
> Thing is: even if you use analog electronics 50's style you can not be
> sure that you have checked all possible combinations of events.

I think the difference is that analog systems tend to break in much
less complex ways than digital ones. A run-time exception is likely to
result in catastrophic and unpredictable misbehaviours. Who would have
thought that buffer overflows could lead to botnets overloading the
net with spam?

Re: OT?: AF 447 and avionics software

[Dmitry A. Kazakov]

On Sat, 6 Jun 2009 03:38:50 -0700 (PDT), sjw wrote:

> On Jun 5, 8:22�am, MRE <Marc.Enzm...@web.de> wrote:
> 
>> The rocket scientist that came to this brilliant conclusion seems to
>> be a real expert in the field of complexity theory.
>> Thing is: even if you use analog electronics 50's style you can not be
>> sure that you have checked all possible combinations of events.
> 
> I think the difference is that analog systems tend to break in much
> less complex ways than digital ones. A run-time exception is likely to
> result in catastrophic and unpredictable misbehaviours. Who would have
> thought that buffer overflows could lead to botnets overloading the
> net with spam?

Analogue systems are continuous, whatever complexity a continuous system
has it stay to some extent predictable. On the contrary a very simple
discrete system exposes unpredictable behavior upon small changes like a
single toggled bit in a floating-point number representation.

However it is quite possible that very this instability of discrete systems
in the end allows us to solve problems, which we could not using analogue
systems.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: OT?: AF 447 and avionics software

[Florian Weimer]

* Dmitry A. Kazakov:

> Analogue systems are continuous, whatever complexity a continuous
> system has it stay to some extent predictable.

Even if you've got resonance effects?

Re: OT?: AF 447 and avionics software

[Dmitry A. Kazakov]

On Sun, 07 Jun 2009 13:16:14 +0200, Florian Weimer wrote:

> * Dmitry A. Kazakov:
> 
>> Analogue systems are continuous, whatever complexity a continuous
>> system has it stay to some extent predictable.
> 
> Even if you've got resonance effects?

Yes. An oscillation does it with finite mass and energy The acceleration is
limited, which is another way to say that it is continuous.

In a discrete computing system a huge number of states are "equidistant".
You pay the same "price" for incrementing a register by one and for
resetting the CPU. This allows you to make great things - you can "travel"
to anywhere you want in very few steps - but this also makes the trajectory
so unpredictable.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: OT?: AF 447 and avionics software

[MRE]

On 7 Jun., 15:19, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sun, 07 Jun 2009 13:16:14 +0200, Florian Weimer wrote:
> > * Dmitry A. Kazakov:
>
> >> Analogue systems are continuous, whatever complexity a continuous
> >> system has it stay to some extent predictable.
>
> > Even if you've got resonance effects?
>
> Yes. An oscillation does it with finite mass and energy The acceleration is
> limited, which is another way to say that it is continuous.
>
> In a discrete computing system a huge number of states are "equidistant".
> You pay the same "price" for incrementing a register by one and for
> resetting the CPU. This allows you to make great things - you can "travel"
> to anywhere you want in very few steps - but this also makes the trajectory
> so unpredictable.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

For a single system Dimitry may be right. If however we talk about a
network of
analog systems (which we have in flight controls), the result of a
malfunction
is as unpredictable as for a similar digital system. Thanks to chaos-
theory ;-)

Cheers,

Marc

Re: OT?: AF 447 and avionics software

[Dmitry A. Kazakov]

On Tue, 9 Jun 2009 23:11:22 -0700 (PDT), MRE wrote:

> On 7 Jun., 15:19, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Sun, 07 Jun 2009 13:16:14 +0200, Florian Weimer wrote:
>>> * Dmitry A. Kazakov:
>>
>>>> Analogue systems are continuous, whatever complexity a continuous
>>>> system has it stay to some extent predictable.
>>
>>> Even if you've got resonance effects?
>>
>> Yes. An oscillation does it with finite mass and energy The acceleration is
>> limited, which is another way to say that it is continuous.
>>
>> In a discrete computing system a huge number of states are "equidistant".
>> You pay the same "price" for incrementing a register by one and for
>> resetting the CPU. This allows you to make great things - you can "travel"
>> to anywhere you want in very few steps - but this also makes the trajectory
>> so unpredictable.
>>
> For a single system Dimitry may be right. If however we talk about a
> network of
> analog systems (which we have in flight controls), the result of a
> malfunction
> is as unpredictable as for a similar digital system. Thanks to chaos-
> theory ;-)

Well, no. A chaotic trajectory is still continuous. Chaos theory is not
really as "unpredictable". A case comparable to digital systems would be
systems deploying nanotechnology, they should [mis]behave much alike.

P.S. I don't advocate for analogue systems. Once I saw the square root
module of an analogue computer. It was about 0.5x0.5x0.5 meter size. I
doubt that thing could fly. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: OT?: AF 447 and avionics software

[MRE]

On 6 Jun., 12:38, sjw <simon.j.wri...@mac.com> wrote:
> On Jun 5, 8:22 am, MRE <Marc.Enzm...@web.de> wrote:
>
> > The rocket scientist that came to this brilliant conclusion seems to
> > be a real expert in the field of complexity theory.
> > Thing is: even if you use analog electronics 50's style you can not be
> > sure that you have checked all possible combinations of events.
>
> I think the difference is that analog systems tend to break in much
> less complex ways than digital ones. A run-time exception is likely to
> result in catastrophic and unpredictable misbehaviours. Who would have
> thought that buffer overflows could lead to botnets overloading the
> net with spam?

The issue in flight-systems is: we are using digital systems to
control
analog behaviour. Therefore the level of complexity (is hopefully)
not
determined by the solution but by the problem.

Why would you think that a faulty OpAmp in a complex control circuit
has
less than unpredictable behaviour than a crash in a software system?

The problem is definitely NOT digital flight controls, whatever the
self-proclaimed pundits state. It has been universally acknowledged
wisdom in
the aerospace industry, that accidents / incidents rarely occur due to
one
single failure but due to a combination of problems. If you look at
the
statement quoted here http://www.time.com/time/world/article/0,8599,1902421,00.html
this is however stated to be true only for digital systems. And
that's
rubbish.

Regards,

Marc

Re: OT?: AF 447 and avionics software

[Ludovic Brenta]

On Jun 4, 11:29 am, "Alex R. Mosteo" <alejan...@mosteo.com> wrote:
> Frankly I know nothing about the aviation standards for software/computer
> use, but I suspect it is somewhat more strict than "one never really knows".
> I mean, surely you can't test everything, but I guess one can be reasonably
> confident on the system design!

The most critical subsystems are usually certified to the DO-178B
level A standard; this means that unit tests must cover 100% of the
code and 100% of the decision paths; it's called MC/DC testing
(Modified Condition/Decision Coverage).

In case you didn't know, when working at Barco avionics I published a
set of slides[1] to describe the work involved. Barco only makes
cockpit displays but their internal CPU is now powerful enough to run
the software for other subsystems like autopilot, air data computer,
flight management system, etc. which traditionally used their own
dedicated hardware. Consolidating multiple systems on a single
hardware CPU (aka Integrated Modular Avionics) is the trend nowadays;
it requires partitioning the CPU into multiple virtual machines
running software certified for different criticality levels.

[1] http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/events/07/070612-abga-event.html

--
Ludovic Brenta.

Re: OT?: AF 447 and avionics software

[Tim Rowe]

Ludovic Brenta wrote:
> The most critical subsystems are usually certified to the DO-178B
> level A standard; this means that unit tests must cover 100% of the
> code and 100% of the decision paths; it's called MC/DC testing
> (Modified Condition/Decision Coverage).

I think the problem is confusion between testing the behaviour of the 
/code/ and the behaviour of the /system/. Even if we could achieve 
perfect confidence in the behaviour of the software, in the case of 
fly-by-wire it's still difficult to be sure that it's what you /want/ it 
to do for all situations the aircraft finds itself in. This requirements 
problem is far from unique, of course, but it's important to remember 
that no language and no amount of proof against requirements will help 
if we're unsure of the requirements!

Re: OT?: AF 447 and avionics software

[Olivier Scalbert]

Ludovic Brenta wrote:
> dedicated hardware. Consolidating multiple systems on a single
> hardware CPU (aka Integrated Modular Avionics) is the trend nowadays;
> it requires partitioning the CPU into multiple virtual machines
> running software certified for different criticality levels.
> 
> [1] http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/events/07/070612-abga-event.html
> 
> --
> Ludovic Brenta.

Hi Ludovic,

Consolidating multiple systems on a single CPU, is not it too dangerous 
(single point of failure) ?

Olivier

Re: OT?: AF 447 and avionics software

[Martin]

On Jun 9, 10:06 pm, Olivier Scalbert <olivier.scalb...@algosyn.com>
wrote:
> Ludovic Brenta wrote:
> > dedicated hardware. Consolidating multiple systems on a single
> > hardware CPU (aka Integrated Modular Avionics) is the trend nowadays;
> > it requires partitioning the CPU into multiple virtual machines
> > running software certified for different criticality levels.
>
> > [1]http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/events/07/070612-abga-...
>
> > --
> > Ludovic Brenta.
>
> Hi Ludovic,
>
> Consolidating multiple systems on a single CPU, is not it too dangerous
> (single point of failure) ?
>
> Olivier

From the s/w side, the different systems would be separated into their
own VM, so any one of the s/w apps going down would not affect any
other system. You get this sort of separation in a lot of embedded OS
these days, e.g. Green Hills Integrity.

From the h/w side, the risk of the single CPU going down would have to
be considered and mitigated in the system safety hazard analysis. - it
depends on your risk requirements.

Cheers
-- Martin

Re: OT?: AF 447 and avionics software

[MRE]

On 10 Jun., 00:14, Martin <martin.do...@btopenworld.com> wrote:
> On Jun 9, 10:06 pm, Olivier Scalbert <olivier.scalb...@algosyn.com>
> wrote:
>
>
>
> > Ludovic Brenta wrote:
> > > dedicated hardware. Consolidating multiple systems on a single
> > > hardware CPU (aka Integrated Modular Avionics) is the trend nowadays;
> > > it requires partitioning the CPU into multiple virtual machines
> > > running software certified for different criticality levels.
>
> > > [1]http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/events/07/070612-abga-...
>
> > > --
> > > Ludovic Brenta.
>
> > Hi Ludovic,
>
> > Consolidating multiple systems on a single CPU, is not it too dangerous
> > (single point of failure) ?
>
> > Olivier
>
> From the s/w side, the different systems would be separated into their
> own VM, so any one of the s/w apps going down would not affect any
> other system. You get this sort of separation in a lot of embedded OS
> these days, e.g. Green Hills Integrity.
>
> From the h/w side, the risk of the single CPU going down would have to
> be considered and mitigated in the system safety hazard analysis. - it
> depends on your risk requirements.
>
> Cheers
> -- Martin

It is being considered. The (original) ideal of IMA being that one
faulty
system will be switched off and some other CPU will take the task (the
"M"
in IMA representing "Modular").

Cheers,

Marc