Neerstortende software

Onlangs zag ik een herhaling van het foutste
TV programma ter wereld: top gear.  Een van
de presentatoren legde omstandig uit dat de
software in zijn nieuwe auto niet deed wat
het zou moeten doen.  Onderweg naar de
studio had hij vijf SMSjes gehad dat zijn
auto gestolen was.  Dit werd op
onnavolgbaar hilarische wijze gebracht.

Da's allemaal leuk en aardig maar stel je
eens voor dat dat soort software niet in een
auto zit maar in een vliegtuig.  Lachen we
er dan ook nog om?  Erger: storten we dan
niet gewoon neer?  Er zijn recent een paar
vliegtuigen iets te hard naar beneden
gekomen en uit de schaarse aanwijzingen voor
oorzaken kan ik in ieder geval software als
(mede)oorzaak niet uitsluiten.

Ik spijker uw kennis hierover eerst even
bij.  Jovial, wel eens van gehoord?  Dat is
en militaire standaard onder andere voor het
programmeren van straalmotoren.  Zeg maar de
Cobol van de vliegtuig industrie.  Leuk om
te weten is dat dit staat voor Jules' Own
Version of the International Algebraic
Language.  Met andere woorden een heuse
Algol compiler!

Dat klinkt overjarig belegen, en dat is het
ook.  Net als Cobol wordt Jovial
nog volop gebruikt.  Denk aan de B52
bommenwerper, het F16 gevechtsvliegtuig, de
Black Hawk helicopter, etc.  Onlangs kreeg
ik nog prangende vragen van een franse
student die bij Thales afstudeerde waarvoor
hij een tool bouwde om de software in AWACS
vliegtuigen te kunnen analyseren.
Bottleneck was hier naast Fortran ook
Jovial.

Het zijn ook geen kinderachtige
programma's.  Zo is het AOCP (Airborne
Operational Computer Program) een belangrijk
stuk software waar ook de AWACS
functionaliteit in verwerkt wordt.  U bent
inmiddels opgestegen, maar geen nood, het
gaat in deze Boeing om een AOCP dat versie
na versie groeit van 600000 regels code naar
800000 regels.  En daaarvoor zijn dus
speciale tools nodig zodat bij onderhoud en
beheer de zaak weer begrepen wordt.
We hebben dus te maken met veelal oude
software in exotische programmeertalen die
niemand meer begrijpt en daar vliegen we
in.  De mise en sc`ene is geschetst.

De crash bij Schiphol werd waarschijnlijk
veroorzaakt door een kapotte hoogtemeter.
We citeren uit het rapport:  ``Het
autothrottle system wordt voor de hoogte
tijdens de nadering en landing gevoed door
de linker radiohoogtemeter.  [..] Deze
waarde wordt niet weergegeven in de
cockpit.  [..] De waarden van de rechter
radiohoogtemeter en de drukhoogtemeter zijn
gedurende de nadering correct geweest.''

Hier zit mijns insziens een zware
ontwerpfout.  Onderdelen gaan stuk, dus ook
een hoogtemeter.  En als je er meer dan een
aan boord hebt, dan MOET je al die meters
gebruiken om met meerdeheid van stemmen vast
te stellen hoe hoog je vliegt.  Maar nee, we
nemen de linker.  Hierdoor mis je een kans
om je systeem fault-tolerant te maken en
daar laat je de autopilot op blindvliegen.
Zit u nog lekker?

Nee dan moderne vliegtuigen, zoals de Airbus
A330 die onlangs in de Oceaan neerstortte.
Speculaties hoef ik niet zelf te verzinnen.
In de Wall Street Journal las ik
recentelijk: ``An international team of
experts is building a scenario in which it
believes a cascade of system failures,
seemingly beginning with malfunctioning
airspeed sensors, rapidly progressed to what
appeared to be sweeping computer outages,
according to people familiar with the
probe.''

Ik kijk daar niet gek van op.  Stel de
linker hoogtemeter geeft veel te lage
waardes door---waar kennen we dat van?  Dan
gaat de autopilot langzamer vliegen en
verliest zijn draagvermogen en tuimelt naar
beneden.  Nog een WSJ-citaat van een bijna
ongeval met hetzelfde type vliegtuig: ``The
Northwest crew reported entering a storm in
daylight and running into turbulence; in
less than a minute their primary and standby
airspeed indicators showed the plane had
slowed dramatically.  Other systems that
automatically maintain speed and altitude
also disengaged.''

Het zal een combinatie van oorzaken zijn,
maar ik kan me niet aan de indruk onttrekken
dat softwareontwerp daarin een belangrijke
rol speelt, zowel het technisch ontwerp als
de OCD (Operational Concept Description).
Ik ben niet overtuigd van de fout tolerantie
van de gekozen ontwerpen gegeven het
onderzoek van Pieter van Vollenhoven.  Ik
hoorde van een viertal hoogtemeters.  Dat is
fout.  Je hebt een oneven aantal nodig om
met meerderheid te kunnen besluiten.  En ik
snap niet hoe je ertoe komt om de linker te
nemen.  Dat is onbestaanbaar.

Een OCD beschrijft het gehele systeem vanuit
de mens.  Een voorbeeld: wie belt de
politie als er ergens een auto alarm
afgaat?  Niemand, juist.  Dus dit is een
fout ontwerp, net als de reeks SMSjes die je
krijgt dat je auto gestolen is terwijl je
erin zit.  En maar hopen dat de fabrikant de
auto niet remote stilzet.

Als in een cockpit overal lichtjes knipperen
en metertjes piepen kan ik me zo voorstellen
dat ook niemand gealarmeerd wordt als door
die ruis heen een hoogtemeter het werkelijk
niet doet.  Echter hier zet de fabrikant via
de autopilot het toestel wel remote stil.
Dat gaat zo smooth dat ook dat niemand
merkt.  Tot het te laat is en dan is er geen
vluchtstrook.  

X

Meer weten over de wondere wereld van ICT
in Jip en Janneke taal? Ga dan naar de
knipselkrant van Chris Verhoef

Prof. dr Chris Verhoef is hoogleraar informatica
aan de Vrije Universiteit in Amsterdam en
wetenschappelijk adviseur voor overheid en
bedrijfsleven.  Hij schrijft regelmatig een
column in AG II.  Hij is te bereiken via email:
x@cs.vu.nl.  Deze tekst is copyright SDU.  Niets
van deze uitgave mag zonder schriftelijke
toestemming van de uitgever worden overgenomen of
worden gepubliceerd.