Wat is het probleem met software ?
De rampen met de Boeing 737 MAX laten helaas weer eens zien wat het belang is van goede software in de besturingssystemen van apparaten en transportsystemen in het bijzonder. Bij software voor dit soort belangrijke systemen zijn twee vragen buitengewoon cruciaal:
1/ Is het in alle situaties duidelijk wie de eindregie heeft over de besturing van het systeem ?
2/ Is de eindgebruiker of toezichthouder in voldoende mate betrokken bij het ontwerp van het systeem ?
Wie bestuurt het vliegtuig ?
Wat betreft de eerste vraag: het lijkt er op, voor zoverre nu valt op te maken uit de berichtgeving, dat de piloten, terwijl ze in de gaten hadden dat er iets mis was, geen mogelijkheden hadden om in voldoende mate in te grijpen. Het is natuurlijk de vraag of dat mogelijk zou moeten zijn. Indien de redenering (het ontwerp) is dat in álle gevallen, ook in dit geval, de “automaat” het altijd beter zal doen dan de piloot, dan kan dat bewust ingebouwd zijn in het systeem. Maar het cruciale punt is in ieder geval: het moet de piloot zelf duidelijk zijn OF hij in urgente gevallen de besturing mag of moet overnemen en dan ook de juiste middelen daartoe heeft OF dat voor hem slechts een bijrol is weggelegd en hij het systeem niet wezenlijk kan beïnvloeden. De meeste mensen zullen de laatste situatie een griezelige gedachte vinden, maar feit is natuurlijk dat de meeste vliegtuigen al vrijwel 100% vliegen op de automatische piloot. Maar dat is het punt ook niet. Waar het om gaat is OF de piloot wel of geen mogelijkheid heeft om in te grijpen in het geval van een calamiteit. Dit is zo’n cruciaal punt, dat je je zelfs zou kunnen voorstellen dat vliegtuigmaatschappijen aan passagiers vooraf helder moeten maken of in een specifiek vliegtuig de eindverantwoordelijkheid bij de software of de piloot ligt.
Geen hybride situaties toestaan
Immers: het is een essentieel punt van het vertrouwen in de vlucht of je liever wil dat een piloot van vlees en bloed beslist in geval van een calamiteit, of de software. Zover tot nu toe valt op te maken uit de berichtgeving is het bij de besturing van de Boeing 737 MAX niet helder geweest wie uiteindelijk “aan de knoppen” zat en lijkt er een hybride situatie te hebben bestaan, waarbij de piloot wel een “beetje” kon ingrijpen, maar niet helemaal of voldoende om zelf te vliegen. Zo’n hybride situatie mag zich nooit voordoen. Het moet in alle gevallen duidelijk zijn wie in laatste instantie het vliegtuig bestuurt: de piloot of de software. Daar mag nooit onduidelijkheid over zijn en al zeker niet bij de piloot zelf. Overigens geldt precies hetzelfde voor bestuurbare auto’s, treinen of andere zelfsturende systemen.
Softwarebouw is deels een creatief proces
Wat betreft de tweede vraag: in heel veel IT organisaties nemen de software bouwers zelf de beslissingen over wat het systeem wel of niet doet. Natuurlijk is er veel collegiaal overleg. Natuurlijk wordt veel geleerd van fouten uit het verleden. Maar indien de vraag gesteld wordt waar de ultieme eindverantwoordelijkheid ligt dat het systeem in geval A, X doet en in geval B, Y dan is dat in veel gevallen niet duidelijk. Sterker nog: software bouw is voor een deel een “creatief proces” en er valt niet altijd goed te voorspellen, ondanks uitgebreid testen, wat de software in extreme gevallen doet. Wat betreft verantwoording wordt meestal verwezen naar architectuur groepen die het ontwerp hebben gemaakt e.d. Of naar de ontwerp principes. Dit is echter voor de eindgebruikers geen acceptabele situatie. Er is veel meer transparantie nodig bij softwarebouw over waarom systemen de algoritmes hanteren die ze hanteren. Er is veel meer inbreng nodig wat betreft functionele eisen van de eindgebruikers of toezichthouders. Er moet veel beter gekeken worden of de software wel deskundig is ontwikkeld en of het maximale is gedaan om onverwachte fouten te voorkomen.
Ontwerp principes moeten transparant en openbaar zijn
Ontwerp principes of uitgangspunten, of het nu vliegtuigen, auto’s of kerncentrales zijn, zouden kristal helder moeten zijn bij belangrijke systemen met een maatschappelijk risico. Eindgebruikers of toezichthoudende instanties moeten zeggenschap hebben over cruciale ontwerp uitgangspunten, zodanig dat, zoals bij een vliegtuig, bijvoorbeeld altijd helder is wie in welke gevallen welke verantwoordelijkheid heeft of beslissingen neemt. Maar moeten we de burger, de overheid met al dat soort zaken lastig vallen. Jazeker. We hebben, als goed voorbeeld, in Nederland een Dienst Stoomwezen (inmiddels geprivatiseerd bij Lloyd’s). Die instantie legt eisen vast waaraan een systeem “waar druk op staat” aan moet voldoen. Dit ter bescherming van de maatschappij. De Dienst voert ook onderzoek uit aan bestaande installaties of men zich aan de regels houdt. Dit type eisen aan installaties en bijbehorend toezicht bestaat voor tal van maatschappelijk belangrijke zaken als medische ingrepen, milieu effecten, dijkontwerpen, e.d..
Onafhankelijk toezicht op softwarebouw noodzakelijk.
Maar dit soort controle mechanismes bestaan in het algemeen niet voor software systemen. Er zijn geen formele toezichthoudende instanties die er op toezien dat software doet wat het moet doen, gebouwd is zoals het gebouwd zou moeten worden, noch in de burgerluchtvaart, noch voor auto’s, noch voor kerncentrales, fabrieken, e.d. En dat terwijl inmiddels de hele maatschappij bestuurd wordt door software. Natuurlijk zijn er in alle bedrijven IT audit comités. Maar wie weet hoe weinig impact dit soort IT audit comités in de praktijk hebben, weet dat hier op geen enkele manier serieuze sturing van uit gaat of de software in een organisatie maatschappelijk verantwoord functioneert. Laat staan dat er op de achtergrond, zoals bij de Dienst Stoomwezen, instanties zijn die functionele eisen of normen opstellen.
Eén ding is glashelder: software in vitale systemen als vliegtuigen, auto’s of energie centrales is te belangrijk om louter over te laten aan de, meestal commerciële, bouwers of eigenaren van het systeem. Net zoals er op andere gebieden, denk aan zaken als dijkbewaking, medische richtlijnen, Stoomwezen, Milieu Effect Rapportage, maatschappelijk uitgangspunten, normen, richtlijnen en controles bestaan, zo dienen er op het gebied van software in vitale systemen, ook maatschappelijke richtlijnen, uitgangspunten, controles te worden vastgesteld. Op dit moment is er in veruit de meeste gevallen helemaal niets geregeld. Dat kan onmogelijk zo doorgaan.
Goed discussie punt. Maar vergeet niet dat dank zij het gebruik van computers de veiligheid van moderne vliegtuigen is enorm verbeterd. Maar 100 % “ foolproof “ is te veel gevraagd ! “Pilot error “ komt bijna niet meer voor. Ook de constructie van de vliegtuigen is door computers mogelijk gemaakt. Ik zou geen probleem hebben in een “ Max 8 of 9 te stappen “ , nog steeds veiliger dan op de weg .
Jazeker is de veiligheid enorm verbeterd. Maar dat neemt niet weg dat NOOIT de situatie van twee kapteins op één schip mag voorkomen. Dat lijkt juist bij dit Boeing 737 MAX gebeurt te zijn. De piloot ging corrigeren en de softweare corrigeert weer de andere kant uit. Dat is een kardinale design fout