Het ongeval op de Ketelbrug op 4 oktober 2009 is veroorzaakt door een softwarefout in de noodbediening. Verkeerde instructies aan een onervaren brugwachter leidde tot het ongeval waarbij een personenauto met vier inzittenden tegen de gedeeltelijk geopende brug botste. Dezelfde softwarefout komt in minstens één andere Nederlandse brug voor. Dit meldt een betrokkene aan ict-vaktitel Computable.
Volgens de betrokkene ontbrak in de software van de Ketelbrug een regel code die voorkomt dat de brug opengaat op het moment dat de slagbomen nog niet gesloten zijn. De betrokkene, die anoniem wil blijven, stelt dat Rijkswaterstaat een advies om ook andere bruggen te controleren in een la heeft laten verdwijnen.
Bij het ongeval op 4 oktober 2009 raakten drie inzittenden van een personenauto gewond doordat de brug omhoog kwam en de auto tegen de betonnen rand botste. Het ongeluk kon gebeuren door een aaneenschakeling van menselijke fouten, maar het incident had voorkomen kunnen worden door de software. De Ketelbrug ligt in de snelweg A6 tussen Lelystad en Emmeloord.
Uitzendkrachten
De betrokkene vertelt dat enige maanden voorafgaand aan het ongeluk de vaste ploeg brugwachters is overgeplaatst naar een andere locatie. Sindsdien was de bediening van de brug in handen van uitzendkrachten. Deze hadden ondervonden dat het openen van de brug op de normale wijze, met de knoppen openen en sluiten, niet altijd werkte. Wanneer er bijvoorbeeld wegwerkzaamheden zijn, waardoor er een file op de brug komt te staan, weigert het automatische systeem om de brug te openen.
De leiding van de Ketelbrug hoorde van de storingen en gaf aan dat de brug gewoon geopend diende te worden, desnoods door gebruik van de noodbediening. Hierdoor werd het gebruikelijk om de brug te openen met de noodbediening. Dat dit niet de bedoeling is, blijkt uit het feit dat de noodbediening zich onder een glasplaat bevond. Bij de onbedoelde opening was er ook sprake van het gebruik van de noodbediening.
Softwarefout
Op het moment van het ongeluk werd de brug geopend en gesloten via de noodbediening. Nadat de brug gesloten was, opende de invalbrugwachter de bomen. Daarna drukte hij per ongeluk op de knop om de brug weer te openen. De software had dit moeten verbieden, omdat de bomen niet gesloten waren, maar controleerde alleen of de bomen niet in de bovenste stand stonden. Omdat de bomen aan het openen waren, concludeerde de software dat ze gesloten waren, en stond het toe dat de brug geopend werd.
De brugwachter realiseerde zich vrij snel dat hij een fout had gemaakt, en maakte meteen een volgende fout door op de knop `stop brug' te drukken. De brug kwam daardoor langzaam tot stilstand waardoor deze ongeveer anderhalve meter uit het wegdek kon oprijzen. Het verkeer dat voor de brug stond te wachten, was inmiddels op gang gekomen en enkele voertuigen reden tegen het brugdek op. De brugwachter had de knop `noodstop brug' in moeten drukken, waardoor de brug sneller tot stilstand was gekomen en ongelukken mogelijkerwijs vermeden hadden kunnen worden.
Ook andere bruggen
De foutieve software van de Ketelbrug is volgens de betrokkene ook bij minstens één andere Nederlandse brug in gebruik. Rijkswaterstaat had oorspronkelijk het plan om alle bruggen in Nederland op systematische wijze te controleren op het voorkomen van dezelfde fout als bij de Ketelbrug. De betrokkene stelt echter dat dit plan inmiddels in een la is verdwenen. Het is daardoor zeker denkbaar dat deze fout in andere bruggen nog aanwezig is.
Jan Friso Groote
Hoogleraar Jan Friso Groote van de Technische Universiteit Eindhoven verwijt Rijkswaterstaat een gebrek aan openheid: '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.'
Groote leidt de faculteit systeemontwerp van de Technische Universiteit van Eindhoven en is gespecialiseerd in de softwareveiligheid van ingebedde systemen.
Reactie Rijkswaterstaat
Rijkswaterstaat zegt 'in beginsel niet te reageren op anonieme beweringen', maar 'wel te hechten aan het geven van betrouwbare en bruikbare informatie.' In een persbericht meldde de organisatie begin 2010 dat de oorzaak van de fout nooit is gevonden: 'Het technische onderzoek heeft niet aangetoond wat de oorzaak is van het plotseling omhoog gaan van de brug, maar heeft wel aangetoond dat het systeem het niet heeft verhinderd, terwijl het dat wel had moeten doen.'
Daarnaast zegt Rijkswaterstaat nu dat 'de menselijk organisatorische kant van het ongeval dat in 2009 heeft plaatsgevonden nog steeds in onderzoek is bij het openbaar ministerie. Dat wil zeggen dat wij hier geen mededelingen over doen. Veiligheid heeft voor Rijkswaterstaat de hoogste prioriteit. Elk ongeval is aanleiding voor Rijkswaterstaat om te kijken of de veiligheid verder kan worden verbeterd, ook het ongeval van oktober 2009 op de Ketelbrug.'
Bij een brug hebben alle grote beweegbare delen twee eindstanden die door drukschakelaars, benaderingsschakelaars, e.d. afgetast moeten worden. Die schakelaars moeten op hun beurt door de software gecontroleerd worden. Dat is hier dus niet het geval geweest.
Misschien is de software verkeerd ontworpen (door iemand die te weinig van bruggen af weet), maar de software is in ieder geval slecht getest.
Het spreekt voor zich dat alle vergelijkbare bruggen op dit mogelijke euvel gecontroleerd worden.
Noodbediening komt op mij over als…noodbediening. En dan wil je misschien niet dat je tegen gehouden wordt door software.
Of het een software fout is is daarom alleen te beoordelen door te kijken naar het ontwerp. Ik (als software ontwikkelaar) geloof namelijk niet (direct) dat het een fout in de software is.
(of moet ik waarde hechten aan de reactie van Rijkswaterstaat: ‘Het technische onderzoek heeft niet aangetoond wat de oorzaak is van het plotseling omhoog gaan van de brug, maar heeft wel aangetoond dat het systeem het niet heeft verhinderd, terwijl het dat wel had moeten doen.’)
@ ICT-er
Betreft: “de software is in ieder geval slecht getest.”
Dit is een makkelijke, maar (vaak) onterechte opmerking/conclusie.
Slecht testen is als het wel getest had moeten worden en dus als er een opdracht is afgegeven om het scenario af te dekken. En er is niet getest (bijvoorbeeld vergeten). Testen blijft een activiteit die betaald moet worden, net als ontwikkelen of ontwerpen. Alles testen is vrijwel onmogelijk en kost zoveel dat de kosten van het product zeer(!) prijzig kunnen uitvallen.
Mogelijk bedoelde je “slecht testen” anders. Over de reden waarom het scenario niet is getest (of wel) is afhankelijk of er opdracht voor is gegeven. Misschien hebben ze wel een risico analyse gemaakt, misschien niet. Er zijn zoveel afhankelijkheden voordat er bepaalt kan worden of er “slecht getest” is, maar als er een bug zichzelf openbaart (want hij zit er al) is het altijd onterecht om te zeggen dat er slecht is getest.
Wij “Testers” zullen ook nooit garanderen dat software foutloos is, want dat kunnen we niet bewijzen.
Wie weet is de software wel goed geschreven en goed getest, maar was het onderliggende design of de onderliggende specs fout.
Ofwel: het is wel heel makkelijk wijzen naar testers of de ontwikkelaars, maar er zit nog een heel stuk voor waar de fout ook opgetreden kan zijn.
Aanvulling op PaVaKe:
En er zit een heel stuk achter. Wie weet is de software wel goed geschreven en goed getest en was het onderliggende design of de onderliggende specs goed.
Bij implementatie kan ook een hoop fout gaan, wat niet wil zeggen dat de software “fout” is.
Dit heeft weinig tot niets met al dan niet foute software te maken. Als je van je baas de brug moet openen via de noodbediening (terwijl je er nog maar net werkt) dan weet je niet beter.
@Tester (alias in DIT artikel), ik vind je reactie nogal vreemd. De specs of een ontwerp blind overnemen is niet erg professioneel (al komt het veel voor vanwege commerciële druk).
In een goed team wordt met elkaar meegedacht. In elke fase kunnen fouten gemaakt worden. Testers maken de testscenario’s. Testers kunnen daarbij ook fouten in het ontwerp en de specs ontdekken en niet alleen in het programmeerwerk.
@Emiel, ook bij de noodbediening van zo’n grote brug zijn er heel veel checks nodig, dus worden er elektronische circuits en/of software gebruikt om fouten te voorkomen. Je moet heel erg oppassen met het kunnen overrulen van vaste veiligheidsmaatregelen, zeker als je niet alleen met vast personeel werkt zoals hier het geval was.
De betrokken brugwachter wordt overigens vervolgd wegens het toebrengen van zwaar lichamelijk letsel.
@ ICT-er
Vreemd? Kan.. Ik struikel puur over je (in mijn ogen) te snel getrokken conclusies. Maarja.. Er staat ook “Misschien” in het begin van je zin.
Maar met je aanvulling ben ik het zeker wel eens. Je zegt het zelf al: “In een goed team wordt met elkaar meegedacht.” Maar helaas is er niet altijd een (goed) team. Ik denk dat menig Tester meer wil testen dan wordt toegelaten ( bv. door te weinig tijd en/of geld). En ik ben ook zeker voor testen tijdens alle fases. Hopelijk wordt dat ooit de “standaard”.
@Peter
Software heeft er duidelijk WEL wat mee te maken omdat “De software had dit moeten verbieden”. “Dit” verwijst naar de handmatige actie van de betrokken brugwachter.
Ik heb heel wat bruggen in bedrijf gesteld.
Normaal is de brugbeweging elektrisch vergrendeld met eindschakelaars die in de slagbomen zitten.
Alle bomen moeten omlaag zijn om de brug te kunnen openen.
Dit heeft NIETS met de software te maken, maar is volledige relaistechniek. De software is de bovenliggende laag. De vergrendelingen zitten altijd in de hardware.
Op elke brug zit op het bedieningspaneel een door een sleutel bediende schakelaar. Hiermee is het mogelijk om de vergrendeling ‘alle bomen dicht’ te overbruggen.
Hiermee is een brugbeweging mogelijk zonder dat de bomen gesloten zijn bijvoorbeeld bij een storing in 1 van de slagbomen.
Deze sleutel is als het goed is alleen beschikbaar voor de technische dienst en niet voor de brugwachter.
De reactie van Jan is nog de meest zinvolle.
Voor een brugbediening zijn er een 3-tal mogelijkheden:
Normale bediening
Hand bediening
Nood bediening
Bij de normale- en handbediening zijn de beveiligingen tevens onder gebracht in de PLC. Hier zou dus nog sprake kunnen zijn van een softwarefout.
Bij noodbediening gaat de volledige bediening buiten de PLC om en KAN er domweg geen sprake zijn van een softwarefout. Alle beveiligingen behoren op dat moment hardwarematig aanwezig te zijn. Overigens zijn deze hardwarematige beveiligingen ook werkzaam tijdens normale- en handbedieningen, bij bediening via de PLC zou er dus sprake moeten zijn van een dubbele beveiliging.
Wat het eerder genoemde testen betreft, Rijkswaterstaat kennende nemen zij zeker geen software af waarvan de goede werking van de software niet is bewezen bij een fabrieks test én bij een test on site waarbij zeker de (verplichte) vergrendelingen getest worden. (er zitten er meer op een brugbesturing)