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.'
Van Ikke en Jan komen erg in de buurt maar is niet noodzakelijk waar. De huidige generatie PLC’s voldoen met een software-besturing aan de vereiste veiligheidscategorie (te vinden in de norm voor beweegbare bruggen) waardoor het mogelijk is de noodbediening en de beveiligingen software-matig uit te voeren.
@ Fcoev,
Het kan best dat de huidige PLC’s aan de vereiste veiligheidscategorie voldoen. Naar mijn mening mag je nooit volledig vertrouwen op beveiliging via software. Een fout in de software mag niet het gevolg hebben dat een brug via een verkeerde druk op een knop in beweging komt.
Daarom moeten volgens mij essentiële vergrendelingen altijd hardwarematig worden uitgevoerd. Maar ik hoor wel vaker dat ik niet zo ouderwets moet denken.
@Ikke, wat bedoel je met Nood bediening?
Normale bediening en nood(bedrijf)bediening werken bij dit soort bruggen d.m.v. hoofdbedrijf- resp. noodbedrijf software en eveneens separate hardware zoals PLC’s en motoren.
Handbediening mag alleen toegepast worden na speciale toestemming en deze opschaling gaat gepaard met veel mankracht waaronder monteurs en mensen die de boel afzetten en in de gaten houden. Dat laatste lijkt me niet het geval te zijn geweest, ook al spreekt men in de pers van handbediening.
@ICT’er
Bij de meeste bruggen zijn er drie bedieningsmogelijkheden
1- Automatisch bedrijf.
De brugwachter, lokaal of op afstand drukt op de knop ‘brug openen’.
Alles gaat automatisch. Er is allen een ingreep met de noodstop mogelijk.
2- Handbediening. De brugwachter doet alle bedieningshandelingen apart.
3 -Noodbedrijf. Alle handelingen gaan buiten de software om. Vaak zit er een noodmotor gemonteerd om toch de brug te bewegen.
In alle drie de gevallen moet het voor de brugwachter niet mogelijk zijn om in de verkeerde volgorde te bedienen.
Allen een storingsmonteur heeft de mogelijkheid bepaalde vergrendelingen te overbruggen.
En dan is er nog mogelijkheid nummer 4. En dat is met de slinger de brug of slagbomen open of dicht te draaien.
Feit is dat de brug bediend werd door een relatief onervaren kracht. Dit ook nog zonder toezicht van meer ervaren personeel (die waren overgeplaatst. Totdat we er het fijne van weten blijft het gissen waar de exacte oorzaak ligt. Een duidelijkere procedure en een goede gedegen opleiding kan dit soort zaken zeker helpen voorkomen. Helaas is het zoals zo vaak dat er eerst een kalf verdronken moet zijn voor de put gedempt wordt, in dit geval wordt de “put” aangeklaagd omdat hij met het bevatten van water mogelijk maakt dat het kalf verdrinkt. Niemand heeft het er echter over wie het water in de put heeft gegooid.
Naar mijn bescheiden mening is hier dan ook een organisatorisch falen te bespeuren en dient rijkswaterstaat hier duidelijke conclusies uit te trekken.
Deze alinea geeft aan waar de fout zit :
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.
De fout zit dan toch echt bij de leiding/verantwoordelijke. De rest zijn alleen maar gevolgen van de eerste fout en zijn ondergeschikt aan de eerste fout:
Noodbediening als gewoonte en dit delegeren aan uitzendkrachten.
Hier is geen excuus voor als dit waar blijkt te zijn. Rijkswaterstaat zou dit onderzoek ook niet zelf uit mogen voeren ivm belangenverstrengeling.
Het is de verantwoordelijkheid van de opdrachtgever om de brug goed te testen of laten testen. Als het in het artikel gesuggereerde scenario nooit is getest, dan is dat had Rijkswaterstaat de oplevering niet mogen accepteren.
Tragisch voor alle betrokkenen.
Noot: Testen is slechts een onderdeel van maatregelen die ervoor dienen te zorgen dat een ‘goed’ systeem in gebruik genomen wordt (systeem als informatiesysteem _en_ procedurele maatregelen samen). Immers preventief, detectief en correctief dien je maatregelen inregelen in het voortbrengingsproces om tot de goede kwaliteit te komen. Deze maatregelen horen elkaar aan te vullen.
Knullig ontwerp? of mis ik iets?
@Jan de Vries, ik ben een andere indeling tegengekomen in mijn VWS-tijd. Er is onderscheid te maken tussen de bediening, de aansturing en de mechanische uitvoering.
Noodbediening en noodbedrijf zijn twee verschillende zaken, maar wel gelinked. Tegenwoordig heb je bij grote bruggen een noodbedrijf met eigen software / PLC’s (en aparte motoren zoals je schrijft).
Zie de NBD 06000 en RVW 205 richtlijnen en NEN 6702, NEN 6786 en NEN 6787 normen.