In de lucht- en ruimtevaart zijn echt veilige toepassingen een noodzaak. Ja, zelfs letterlijk van levensbelang.

Informatica in de luchtvaart? Daarbij denk je allicht meteen, als in een reflex, aan de website waar je je goedkoop ticket op de kop hebt getikt. Of aan de systemen die de goede werking van een luchthaven als bedrijf verzekeren. Vermoedelijk sta je er niet bij stil – allicht begrijpelijk – als je uit je auto stapt op de luchthaven, dat je zo meteen het welzijn van je lijf en leden gaat toevertrouwen aan software die zowel op de grond als in de lucht over leven en dood kan beslissen. Wie weet heeft van de perikelen met dagdagelijkse software, zou het al om minder daarbij kil om het hart worden. Toch stap je aan boord van dat vliegtuig, vertrouwend dat de software geen fatale problemen gaat vertonen. Waarom, en kunnen hieruit lessen worden getrokken?

Wettelijk verplicht

Software die letterlijk van levensbelang is, vind je op heel wat plaatsen in de lucht- en ruimtevaart. Aan boord van vliegtuigen worden de stuursystemen en de bijhorende boordinstrumenten volledig software gestuurd, terwijl op de grond radar- en luchtverkeersleidingssystemen evenzeer afhankelijk zijn van veilige soft (evenals ondersteunende systemen zoals positie- en navigatiesystemen).

Een eerste en belangrijk aspect van dergelijke software is dat deze wettelijk verplicht moet worden geoptimaliseerd voor een veilige werking. In Europa bestaat sinds 1963 de organisatie Eurocae (European organisation for civil aviation equipment), die in samenwerking met onder meer de VS (en in het bijzonder de RTCA) documenten publiceert hoe producenten en gebruikers conform de geldende reglementeringen de nodige vitale producten kunnen ontwikkelen en bijwerken. Zo werd begin dit jaar een reeks nieuwe versies van documenten goedgekeurd, waaronder ED-12C (“software considerations in airborne systems and equipment certification”), inclusief aanwijzingen rond model-based ontwikkelen, object-technologieën en formele ontwikkelingsmethoden.

Gedocumenteerd ontwikkelingsproces

Niet alleen zijn de standaarden waaraan software in luchtvaartinstrumenten moeten voldoen duidelijker omschreven, ook het ontwikkelingsproces van die soft wordt veel rigoureuzer uitgevoerd en gedocumenteerd, en dat gedurende de hele levensloop en -duur van het product.

Een cruciaal onderdeel bij de aanvang van de ontwikkeling is de gevarenanalyse (‘hazard analysis’), waarbij van elk onderdeel van een systeem wordt nagegaan wat fout kan gaan, en hoe dat andere onderdelen kan impacteren. Een definitie van ‘hazard’ is dan weer “een toestand, gebeurtenis of omstandigheid die kan leiden of bijdragen tot een niet voorziene of ongewenste gebeurtenis” – een definitie die ook wel in gewone software-omgevingen kan worden gehanteerd. Bij de analyse wordt aandacht besteed aan hoe waarschijnlijk het is dat het gevaar zich voordoet (‘probability’), en hoe ernstig de gevolgen kunnen zijn (‘severity’). Op basis daarvan wordt bepaald hoe kritiek een stuk software wel is, waarna wordt bepaald hoe de gevolgen op te vangen.

Design for safety

Dat gebeurt door een vorm van ‘safety engineering’, waarbij wordt gekeken hoe de problemen te voorkomen, maar ook hoe een eventueel falen op te vangen zodat zich geen catastrofale gevolgen voordoen. Vandaag wordt hierbij steeds meer gemikt op ‘software safety’, ook al omdat het precies de software is die de functionaliteit van instrumenten en systemen aan boord van vliegtuigen en in grondsystemen bepaalt. Die zorg voor safety software zet zich ook door in latere fasen van de levensloop van een product.

Bij het design for safety in de luchtvaartwereld wordt ook een samenwerking tussen verschillende disciplines nagestreefd, ook en niet het minst met experts inzake gedragspatronen van gebruikers, onder meer bij de ontwikkeling van de gebruikerinterfaces en -werkplekken. Gezien de groeiende complexiteit van de softwaresystemen – de oorspronkelijke Airbus vliegtuigen telden enkele duizenden lijnen code, tegens de miljoenen lijnen code in de nieuwste Airbus 380 superjumbo (à rato van ca. 100 euro per lijn gecertifieerde code) – wordt nu ook vaker een beroep gedaan op een model-gesteunde aanpak om tot een veilige softwarewerking te komen. Daarbij kan eventueel worden besloten om systemen of onderdelen ervan te verdubbelen (of zelfs te verviervoudigen plus een alternatief back-up systeem) om een adequaat niveau van veiligheid te bekomen. Ook moet worden gewerkt aan ‘fault isolation boundaries’, waardoor kan worden voorkomen dat problemen zich ongeremd doorheen een heel systeem kunnen voortplanten, maar worden gestopt.

Coderen, checken, testen

Na het opstellen van transparante en duidelijke ‘requirements’, wordt vervolgens gestart met het coderen van de software zelf. Eventuele hulpmiddelen en tools die daarbij worden aangewend, moeten op hun beurt ook betrouwbaar zijn. Zomaar een tooltje plukken uit het internet of mordicus gebruik maken van een lievelingsframework, is er niet bij in de luchtvaartwereld, in schril contrast tot de geplogenheden bij heel wat ontwikkelaars.

De geschreven code moet vervolgens – wettelijk verplicht – door een andere persoon dan de oorspronkelijke auteur worden nagekeken, normalerwijze aan de hand van een lijst van mogelijke problemen. Ook wordt gebruik gemaakt van code-analysetools.

Vervolgens wordt aan unit testing gedaan, waarbij wordt nagegaan of het stuk soft ook echt alles doet wat het moet doen (coverage). En deze testresultaten moeten eveneens wettelijk verplicht worden gedocumenteerd. Het leidt in ieder geval tot een sterke segmentering van de software, waarbij elk deel zo solied mogelijk wordt gebouwd (onder meer met het oog op mogelijk hergebruik).

Transparantie

Veilige soft is mogelijk, althans het creëren van softwaresystemen waarvan het gedrag als veilig en betrouwbaar kan worden verwacht. Uit de aanpak van de lucht- en ruimtevaartwereldwereld blijkt duidelijk dat structuur, transparantie, gevarenanalyse en segmentatie de basis vormen voor succes. Er is geen reden waarom niet dezelfde aanpak voor ‘gewone’ toepassingen kan worden nagestreefd. Het hoeft allicht niet zo ‘gründlich’ en verregaand te zijn als voor systemen die je vliegtuig in de lucht houden, maar toch beter dan de vaak nonchalante aanpak in heel wat projecten. Hoewel in de lucht- en ruimtevaart veel gewicht wordt gehecht aan duidelijke en volledige ‘requirements’, kunnen de lessen van die aanpak ook in werelden met meer ‘agile’ en ‘extreme’ ontwikkelingswerk worden toegepast, zeker wat het segmenteren van software betreft.

Ook blijkt zo’n aanpak niet veel duurder – de eerste reactie tegen zo’n aanpak – te zijn dan ‘gewone’ methoden. Vaak wordt verwezen naar een meerkost in de ordegrootte van 15 procent. Wellicht belangrijker nog is dat zo fouten vroeger in het ontwikkelingsproces worden onderschept, wat later – en duurder – reparatiewerk voorkomt. Of inkomstenverlies wordt vermeden. Of – zo mogelijk nog belangrijker – de klanten het vertrouwen in het bedrijf niet verliezen.

Guy Kindermans