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.'
Eigenlijk heeft iedereen gelijk maar tegelijker tijd ook niemand: wanneer de configuratie niet duidelijk is en wat er kan/mag bediend worden in noodsituaties of noodbedrijf en wat hierbij in de besturing of hardware wel/niet vergrendeld is, blijven het speculaties waar een mogelijke oorzaak ligt.
Er wordt op deze manier (imo onnodig) paniek gezaaid, en het meest makkelijke is om daar waar het merendeel van de bevolking (ook technische!) geen kennis van heeft de schuld vraag neer te leggen. De niet gefundeerde uitspraak van de professor helpt hier niet bij.
@ICT-er
Ieder beweegbaar object moet ook voldoen aan de machinerichtlijnen (EN ISO 13849-1, EN1050 en EN ISO 14121-1)
Uit deze normen:
-Als veiligheid afhankelijk is van besturingssystemen, moeten deze ontworpen worden met een voldoende lage kans op functionele fouten.
-Elke fout die opduikt mag niet leiden tot het verlies van de veiligheidsfunctie.
De vergrendeling van de brugbeweging door controle op gesloten slagbomen is een veiligheidsfunctie. Een fout in de software mag dus niet leiden tot het verlies van deze veiligheidsfunctie.
Het is al weer een aantal jaren geleden dat ik een brug in bedrijf heb gesteld, maar ik kan mij niet voorstellen dat er tegenwoordig geen hardwarematige vergrendeling meer wordt toegepast.
Natuurlijk is er hardwarematige vergrendeling. Die kan met het hoofdbedrijf en met het noodbedrijf ontkoppeld worden. Ook kan de hardwarematige vergrendeling via het noodhandbedrijf ontkoppeld worden. Dat is bij een grote brug niet bedoeld om deze te kunnen openen, maar om deze bij een storing te kunnen laten zakken en zekeren.
De brugwachters op deze brug dienen niet vervold te worden, de vaste ploeg was overgeplaatst naar een andere brug, rijkswaterstaat is er verantwoordelijk voor dat er onervaren brugwachters in dienst waren, en een softwarefout is er de oorzaak van dat er een ongeluk gebeurde. Rijkswaterstaat dient eerder vervolgd te worden, zij zijn verantwoordelijk voor de softwarefout.
Zoals het altijd gaat, de man die er alleen voor staat krijgt de schuld. Er staat toch duidelijk dat er een fout in de software zit. De bedienaar mag ervan uit gaan dat de techniek goed werkt. Zeker een bedienaar die niet veel ervaring met deze werkplek heeft.
Wat men niet weet, daar kan men ook niet voor verantwoordelijk worden gehouden.
Een timmerman kan zien of zijn zaag goed is, zo niet dan zal hij een andere zaag nemen. De brugwachter in deze zaak kan niet weten dat de software niet goed werkt. Hij mag er echter wel vanuit gaan dat dat wel het geval is. De software is zijn gereedschap. Als de brugwachter had gezien dat zijn gereedschap niet in orde was had hij waarschijnlijk anders gehandeld.
Bovendien is er sprake van een uitzendkracht. Uit ervaring weet ik dat er dan heel makkelijk naar zo’n werknemer word geschopt. Was het een werknemer van RWS zelf geweest dan had deze veel meer bescherming van zijn werkgever gehad. Een soortgelijke situatie heb ik zelf meegemaakt. De uitzendkracht werd de laan uitgestuurd. Was het een vaste werknemer geweest “zo wist een leidinggevende mij te vertellen” dan was het met een waarschuwing afgedaan.
@ Bram,
Zoals ik al eerder schreef mag een fout in de software nooit leiden tot onveilige situaties. Alle veiligheidsfuncties moeten buiten de software om getroffen zijn.
Een brug is een machine en in Europa moeten alle machines, die vallen onder de machinerichtlijn 2006/42 EC (voor 2009 was dit de 98/37) werknemers, omstanders en materieel etc., voldoen aan de essentiële veiligheids-en gezondheidseisen. Om een “vermoeden van overeenstemming” met de machinerichtlijn te krijgen kun je gebruik maken van normen. Dit zijn ontwerpregels die je helpen bij het ontwerp van de machine. Deze zijn echter niet verplicht. Daarbij helpen “geharmoniseerde normen” (normen die zijn genoemd in het publicatieblad van de Europese unie) alleen voor het verkrijgen van een “vermoeden van overeenstemming”. De RWS normen worden daar niet in genoemd (NBD06000 bijv.) Als een norm geharmoniseerd is dan wil dat zeggen dat ze de “state of the art” ofwel de huidige stand van de techniek voorstellen. Om terug te gaan naar het ontwerp van een machine, deze begint altijd met een risico-analyse. In deze risico-analyse worden alle mogelijke gevaarlijke delen en bedieningsmogelijkheden van de machine beoordeeld. Er is daarbij ook duidelijk een onderscheid tussen bedienend- en onderhoudspersoneel en in welke fase de machine gebruikt wordt (installatie, inbedrijfstellen, gebruik etc.). Uit deze risico-analyse komen restrisico’s die de fabrikant van de machine verplicht is te melden aan de gebruiker van de machine evenals dat in de gebruiksaanwijzing informatie wordt verschaft over de benodigde opleiding van het bedienend personeel. Het is goed voor te stellen dat er een veiligheidsbesturing in de aansturing van de brug is toegepast. Of dit nu hardware- of softwarematig is, maakt niet uit. Zo’n veiligheidsbesturing is een secundaire maatregel op een gevaar (risico) als de primaire bescherming (maatregelen in het ontwerp van de machine) niet afdoende zijn of niet kunnen worden toegepast. (Je kunt bijv. een brug niet helemaal afschermen)Daar is dan weer bijv. de geharmoniseerde norm EN ISO 13849 voor.
Nadat een machine door de fabrikant is geleverd aan de “klant” dan dient deze eerst een RI&E uit te voeren. Dit is ook een analyse vergelijkbaar met een risico-analyse maar is gericht op eventuele noodzakelijke maatregelen die de eigenaar dan moet nemen om de machine veilig door de werknemers te laten gebruiken. Hier kan uitkomen dat de werknemers voldoende opgeleid dienen te worden om de machine veilig te kunnen bedienen. In het verhaal hierboven lees ik dat er uitzendkrachten zijn ingezet voor de bediening van de brug. Ook deze dienen voldoende te worden opgeleid om de brug te bedienen.
Echter, boven alles staat de risico-analyse, als die niet het risico op een verkeerde bediening beoordeeld heeft dan zal niemand daarvan het gevaar zien totdat het inderdaad voorkomt en zo’n bediener is daar dan de dupe van.. Hij moet leven met het feit dat tijdens zijn dienst een ongeluk heeft kunnen gebeuren, ongeacht het een “softwarefout” of bedieningsfout is geweest.