De Onderzoeksraad voor Veiligheid moet meer onderzoek doen naar softwarefouten als mogelijke oorzaak van ongevallen. Dat zegt hoogleraar Jan Friso Groote van de Technische Universiteit van Eindhoven. Hij leidt de faculteit systeemontwerp van de Technische Universiteit van Eindhoven en is gespecialiseerd in de softwareveiligheid van ingebedde systemen.
'De de Onderzoeksraad voor Veiligheid laat zich niet of nauwelijks zien bij ongevallen waaraan software een belangrijke rol heeft gespeeld', aldus Groote. 'Ze lopen er met een grote boog omheen. De Ketelbrug is zo'n geval. Daarvan zou je toch graag helder willen krijgen wat daar exact mis is gegaan. Zo'n brug gaat toch niet zomaar open. Je moet goed onderzoeken wat er exact mis is gegaan en daar lering uit trekken. Alleen zo kun je maatregelen nemen om herhaling te voorkomen. Anders blijven dezelfde problemen keer op keer optreden, ook op andere plekken dan waar de softwarefout voor problemen zorgde.'
Vliegtuigindustrie
De vliegtuigindustrie is voor Groote hét grote voorbeeld van hoe het wél moet. 'Alle vliegtuig-ongelukken worden tot op de bodem uitgezocht, om de oorzaak ervan te achterhalen. Die cultuur zouden we in de software-industrie ook moeten krijgen. Bij elke softwarefout moeten we ons afvragen: hoe hadden we dit kunnen voorkomen? Dat geldt overigens ook voor fouten die geen problemen veroorzaken.'
'Juist in de softwareindustrie is het belangrijk dat we leren van onze fouten', zegt de hoogleraar. Volgens hem toont het ongeval op de Ketelbrug in 2009 aan hoe belangrijk het is om softwarefouten openbaar te maken. 'Alleen zo kun je voorkomen dat dezelfde fout in de toekomst nog eens optreedt.'
Risico-analyses
In de software van de Ketelbrug ontbrak een regel code die voorkomt dat de brug opengaat op het moment dat de slagbomen nog niet gesloten zijn. 'De fout die ten grondslag lag aan het ongeval op de Ketelbrug op 4 oktober 2009 was niet bijzonder complex. Dat weten we nu, dankzij een klokkenluider. Het was eigenlijk een zeer voor de hand liggende fout. Daardoor kan ik nu dit praktijkvoorbeeld aan mijn studenten uiteen zetten en kan het in de handboeken terecht komen.'
Een andere reden om softwarefouten te delen is volgens Groote om een schatting te kunnen maken van de schade door softwarefouten. 'Alleen dan kun je een risico-analyse maken en uitrekenen hoeveel geld je kunt investeren in het zo foutloos mogelijk maken van software.'
Correctie
In april 2011 maakte de Onderzoeksraad voor Veiligheid een rapport openbaar over de Ketelbrug. De eindconclusie uit dit rapport is dat het ongeval op de ketelbrug op 4 oktober 2009 kon gebeuren doordat het besturingsysteem van de Ketelbrug 'intrinsiek risicovol' was.
De raad bleek dit onderzoek te zijn gestart een half jaar nadat het ongeval op de Ketelbrug plaatsvond. Het besluit viel omdat Rijkswaterstaat (RWS) geconcludeerd had geen directe oorzaak voor het ongeval te kunnen achterhalen.
Veiligheid mag NOOIT afhankelijk zijn van software.
De beveiliging moet in de hardware zitten d.m.v. relais en eindschakelaars.
Als dit bij de ketelbrug niet het geval is, dan moet de ontwerper, installateur voor de rechter gedaagd worden maar zeker niet de brugwachter.
“Volgens hem toont het ongeval op de Ketelbrug in 2009 aan hoe belangrijk het is om softwarefouten openbaar te maken.”
Softwarefouten in zulks zullen zelden openbaar worden gemaakt, omdat er zelden sprake is van Open Source. Zo simpel is het eigenlijk.
Er wordt gesproken over softwarefouten.
Ten grondslag aan ontwikkelde software liggen de specificaties. De kracht van juiste specificaties wordt in veel projecten ontkracht.
Tijdgebrek, “politieke” druk, het niet beschikken over de drive of competenties om juist de achterliggende vraag of situatie helder op het netvlies te krijgen, leiden tot situaties die vergelijkbaar zijn met het Ketelbrug incident.
De geschetste situatie had m.i. in specificaties beschreven moeten zijn. Of dat zo is, is de vraag.
Software moet goedkoop zijn.
Inkopen is vaak op de kosten letten.
winnen van opdrachten lukt alleen door scherp te calculeren.
Bezuinigen op testen is de eerste winst voor zowel de koper als de verkoper.
Het niewwe project is succesvol afgesloten en eventuele problemen liggen straks op andermans bordje.
Helaas…