Managed hosting door True

Softwarefout veroorzaakte ongeluk Ketelbrug

 

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.'

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/3814774). © Jaarbeurs IT Media.

?


Lees ook


 

Reacties

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)

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.

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.

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.