Managed hosting door True

'Extra schil voor Ketelbrug is opmerkelijk'

'Rijkswaterstaat zou meer openheid moeten geven'

 

Professor Jan Friso Groote van de Technische Universiteit van Eindhoven verbaast zich over de extra bedieningsmodule van de Ketelbrug. Deze nieuwe module, die als extra beveiligingsschil om de bestaande heen ligt, moet voorkomen dat de brug opnieuw opengaat zonder dat de slagbomen gesloten zijn. Dat gebeurde wel op 4 oktober 2009. Hierdoor raakten drie inzittenden van een personenauto gewond. De oorzaak van het probleem is nog steeds niet gevonden.

'Het verbaast me dat er geen ingebouwde beveiliging was waardoor de brug alleen open kon bij gesloten slagbomen. Ik zou hebben verwacht dat dat een van de primaire vereisten was bij de bestelling van dit bedieningssysteem', zegt Groote. Hij leidt de faculteit systeemontwerp van de Technische Universiteit van Eindhoven en is gespecialiseerd in de softwareveiligheid van ingebedde systemen.

Ook verbaast het de professor dat een nieuw, extra beveiligingsysteem wordt gebouwd. 'Het zou veel goedkoper zijn om de software van de bestaande bedieningsmodule aan te passen, mits die goed gedocumenteerd en toegankelijk is.'

Gebrek aan openheid

Groote hoopt dat Rijkswaterstaat en de politie van Flevoland volledige openheid geven over het huidige onderzoek naar het falen van de brug. 'Het overduidelijk falen van een systeem is een gouden leermoment. Zoiets mag nooit weer gebeuren. De Ketelbrug hoort thuis in elk college over systeemontwerp. We moeten zelfs kijken of wet- en regelgeving rond dergelijke systemen geen aanpassing behoeft. Als we geen volledige openheid afdwingen, leren we niets en bliijven dergelijke rare ongelukjes optreden'.

Een woordvoerder van Rijkswaterstaat houdt zich op de vlakte. 'De oorzaak van het opengaan van de brug is nog in onderzoek bij de politie. Zolang dit het geval is, kunnen wij niet in meer detail ingaan op de materie. Dat is een gangbare procedure. Bruikbare en betrouwbare informatie die beschikbaar is, verspreiden we door middel van pers- en nieuwsberichten en bieden we aan op de website van Rijkswaterstaat.'

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

?


Lees meer over



Lees ook


 

Reacties

In beide hoedanigheden passeer ik de brug regelmatig en met name in de auto denk ik nu iedere keer aan dit voorval. Ik kan me de reactie van Jan Friso levendig voorstellen. Daarnaast vraag ik me af. Dit is toch waarschijnlijk standaard software?? M.a.w. je gaat toch niet voor iedere brug nieuwe software schrijven?? Dus... ligt het probleem waarschijnlijk veel breder. Zijn er eigenlijk meer voorvallen geweest?

inderdaad raar dat hier geen critical system engineer bij is geweest. Normaal gesproken wordt door dat soort mensen een besturingssysteem ontworpen voor bruggen en sluizen en andere belangrijke systemen. Blijkbaar moest het hier erg goedkoop en heeft er een studentje iets ontworpen met als extra functie open random ....

Dit lijkt me een van de meest eenvoudige programmatjes die er bestaan:
IF (spoorbomen dicht & knop "brug open" ingedrukt)
ga open
ELSE
not!
ENDIF

"mits het systeem goed gedocumenteerd en toegankelijk is", nou, ik moet het eerste goed gedocumenteerde en toegankelijke systeem (buiten Open Source Software) nog tegenkomen na 12 jaar ervaring als software engineer.

Ricardo, onderschat niet hoe complex dergelijke besturingssystemen zijn, dat is echt geen kwestie van een if-then-else statement. Wat jij doet is in feite een 'schil' om de bestaande software heenleggen, maar bij harde wind mag de brug ook niet open. En de lichten moeten op rood staan voordat de slagbomen dicht gaan. En als er een olietanker aankomt zou er een human override knop moeten zijn. enzovoorts enzovoorts, zulke dingen zijn makkelijk te onderschatten !

Mooi dat JFG weer eens aandacht heeft weten te vestigen op het belang van systeemontwerp in het algemeen en het belang van open ('toegankelijke') systemen zeker waar het publieke veiligheid betreft in het bijzonder. There is no security by obscurity !

'De oorzaak van het opengaan van de brug is nog in onderzoek bij de politie'...

Pffff. Hebben die niks beters te doen ?

@john:
Je schrijft: "'De oorzaak van het opengaan van de brug is nog in onderzoek bij de politie'...

Pffff. Hebben die niks beters te doen ? "

Als je bij iedere belangrijke actie van een instantie vraagt of ze niks beters te doen hebben, is dus niets belangrijk. Het lijkt mij dat op het moment dat ze het onderzoeken, dat inderdaad het beste is wat de politie kan doen.
Wat denk je ervan, als bij alles wat jij vanmiddag doet, iemand komt zuchten en vragen of je niks beters te doen hebt. Iemand zou het bijvoorbeeld kunnen vragen bij de twee regels die je hebt gepost. En net als bij de politie zou het antwoord kunnen zijn: "Nee, wij hebben niks beters te doen.". Is het een schande dat je op een bepaald moment heb beste doet wat je op dat moment kunt doen?


Het lijkt mij trouwens beter om de beveiliging via hardware te regelen. Bij verkeerslicht regelsystemen kunnen conflicterende richtingen nooit tegelijkertijd groen licht krijgen omdat het ene groene licht met een relais via een breekcontact van het andere relais (van het conflicterend groen) is geschakeld. Deze relais' worden via software aangestuurd, maar een fout in de software kan er dus nooit toe leiden dat er een aanrijding ontstaat omdat conflicterende richtingen groen licht krijgen. Het lijkt me dat dit principe ook toegepast kan worden voor een brug. Of denk ik nu te simpel?

Nee, jij denkt niet te simpel. Al die anderen denken te moeilijk.
Wat nou software fout? Waarom weer extra software die fouten kan bevatten? Gewoon een doodnormale hardware schakelaar in het circuit zetten. Kost een paar tientjes en klaar is Kees.
Maar als je dit aan de overheid overlaat, kost het waarschijnlijk een paar ton.

@Francine

Acht regels onzin van jouw hand. Jij hebt ook niks beters te doen zeker. En je neemt ook alles nog leterlijk.

Wat ik ermee wil zeggen is dat de politie in deze helemaal niks kan betekenen. Pure tijdverspilling. Een nietszeggend rapportje. Onzinnig volgen van de procedures dat 'de politie het moet onderzoeken'.
Onderzoek van een paar technische mensen zou hier veel meer kunnen betekenen.

Schillen toevoegen over de bestaande puinhoop geeft een extra aantal mogelijkheden waarop het NOG meer fout kan gaan. Niemand heeft nog gehoor van de wet van Murphy bij deze brug-besturings-systeem-integrator.

Dit is een typisch schoolvoorbeeld van verkeerd ontwerp vanaf de tekentafel. Back to the drawingboard

"Een woordvoerder van Rijkswaterstaat houdt zich op de vlakte. 'De oorzaak van het opengaan van de brug is nog in onderzoek bij de politie."
Ze kunnen beter een team van onafhankelijke "forensic it experts" erbij halen, om werkelijk te achterhalen wat er precies mis is.. De ware oorzaak zal wel verdwijnen in doofpot, tussen klant en leverancier of tussen brugdek en wal ;-)

Gezien de ouderdom van de Ketelbrug-installatie zal er wel helemaal geen sprake zijn van enige software. Er is een handmatige bediening van de installatie en schijnbaar zonder enige beveiliging van sleutelmomenten.

De eerste keer doet de brugwachter de bomen in de verkeerde volgorde dicht, er staat dan een auto op de klep en de brugwachter doet gewoon de klep open. De bestuursters gooit de auto in de achteruit en valt over de rand zo'n 30 meter naar beneden. Dood. De brugwachter was met zijn software aan het spelen? Telefoon of andere gadgets worden door allerlei personeel die eigenlijk serieus moeten opletten gewoon tijdens het werk bediend.
Vorig jaar gaat de klep plots open tijdens normaal verkeer. Wellicht iemand een knop ingedrukt terwijl installatie niet op slot stond? Ik neem tenminste aan dat er een sleutel nodig is om de bediening te kunnen toestaan.
Wie denkt dat de slagbomen van de Beneluxtunnel zomaar dichtgingen is goed van vertrouwen. Iemand uit de bediening heeft per ongeluk gewoon de sluiting geactiveerd. Men houdt zich op de vlakte om de collega te dekken en de slechte beveiliging buiten beeld te houden.
Ik heb ook wel eens meegemaakt dat een deurtje van een bedienpaneel van een mainframe-computer open stond (terwijl het dicht hoort te zijn). Een collega met krukken laat een kruk glippen. Deze valt precies tegen de ombeschermde aan/uit schakelaar. Ploep, 1000 man hebben een downtime van meerdere uren te pakken en de salarissen van 50.000 personen moesten maar een dagje later verwerkt worden. Nonchalance en toeval.

Wat een hoop flauwekul,

Dit had met een simpele relais schakeling voorkomen kunnen worden.
Boom dicht > Brug mag open
Brug dicht > Boom mag open
En dan maak het niet uit hoe slim of dom de software die daar achter staat is.

Als dit mijn brug was had ik de leverancier om uitleg gevraagd, voor de rechter.

Thijs Cobben heeft gelijk. De software voor zo'n systeem is veel complexer dan een aan-uit schakeling en dat geldt ook voor de bekabeling voor de bedieningspanelen, de sensoren en motoren. Dat sommigen dit niet begrijpen doet mij vermoeden dat zij niet geslaagd zijn voor de eerste basismodules van hun ict-studie.

Dat de politie erbij gehaald is, dat is ook niet gek. De politie wordt vaak bij dit soort (bijna) ongelukken ingeschakeld. Zij hebben meer ervaring met waarheidsvinding dan zo maar een ict-er. Rijkswaterstaat moet weten of er een technische fout of een menselijke fout is gemaakt en of daarover wordt verzwegen. Het OM wil dit ook weten.

Jan Friso Groote heeft gelijk als deze stelt dat een module, als extra beveiligingsschil, niet de uiteindelijke oplossing dient te zijn.
Zijn verzoek om openheid steun ik ook. Van het onderzoek kunnen we wellicht leren.

Complex of niet een aantal zaken zijn zo elementair voor de veiligheid dat die dus hardwarematig uitgevoerd moeten zijn.
Zo simpel als een magnetron die niet draait als het deurtje open staat of een slagboom die niet dicht gaat als er een auto onder staat. Dat er ook complexe taken zijn die door software uitgevoerd wordt is logisch maar die software moet en net als een echte brugwachter beschermt worden door een hardwarematige beveiliging.

Professor Jan Friso Groote denkt geloof ik dat er altijd software is geweest. Vroeger toen de brug gebouwd werd waren er helemaal geen regelcomputers voor dit soort situaties en werd alles middels mechanica of middels concrete electrische circuits beveiligd. Er is dus helemaal geen software om te vervangen.
Waarschijnlijk is er nauwlijks beveiliging ingebouwd en functioneerde deze niet omdat deze kapot is of omzeild/genegeerd werd.
Het is een beetje onwaarschijnlijk dat er in nauwelijks 1 jaar tijd twee van dit soort incidenten optreden bij dezelfde installatie. De eerste keer overigens met de dood van een burger tot gevolg. Wat in dit verhaaltje maar even niet opgehaald wordt.

Goh, het lijkt de beurs wel met al dat gespeculeer wat nu de oorzaak is \ hoe het opgelost zou moeten kunnen worden.

Als je de achtergronden en implementatie niet kent, dan heeft het niet veel zin om te oordelen over al dan niet mogelijke oplossingen.

Antje Almere, in 40 jaar is e.e.a. veranderd, ook bij de ketelbrug. Die is 5 jaar geleden door BAM aangepast en heeft daarbij nieuwe PLC-besturing gekregen. De software moet er voor zorgen dat er minder personeel nodig is, maar er toch minder oponthoud is voor het verkeer, er minder mechanische storingen zijn en er minder fouten gemaakt worden die voor onveilige situaties kunnen zorgen.

De operator (brugwachter) van bruggen met veel verkeer wordt door software ondersteund bij het nemen van beslissingen en het uitvoeren van handelingen. Die handelingen worden grotendeels automatisch uitgevoerd, waarbij de operator i.v.m. de machinerichtlijn kan ingrijpen aan de hand van eigen waarnemingen, alarmsignalen en camerabeelden. Naast de manuele noodstop is er ook een noodstop in de software ingebouwd (noodbedrijf ) die bij tal van situaties ingaat.
Zaken zoals het sluiten van de slagbomen, alarmeringen en storingen kunnen tegenwoordig ook bijgehouden worden. Ook zijn koppelingen met verkeersbegeleidingssystemen mogelijk.

Als er zoveel beveiligingen zijn hoe is het dan mogelijk dat de klep open gaat met een auto erop die ingesloten is door de slagbomen? Indien de bomen automatisch gesloten worden had men toch ook wel kunnen bedenken de slagbomen aan de uitrijzijde 5-10 seconde later te sluiten. Dan ontstaat het hele probleem van insluiten niet.

Antje Almere, er zitten vertragingen en checks in om het risico van bijvoorbeeld het insluiten van auto's tegen te gaan. Dat moeten de brugwachters bij kleine bruggen nog steeds zelf doen.
Waarom het mis ging, is ook voor mij een raadsel. Wellicht heeft de noodbedrijf software geen rekening gehouden met een mechanisch mankement dat zelden plaatsvindt. Er zijn nogal wat scenario's waarmee rekening gehouden dient te worden. Denk aan kortsluitingen en haperende sensoren die tegenstrijdige informatie geven.

Als de prof het wil weten mag hij mij een mail sturen, ik kan het hem haarfijn uitleggen met in mijn hand het oude programma en met het aangepaste programma.
Zelfs de achterliggende redenen kan ik hem nog vertellen.

Albert, wellicht kan je een artikel voor ons/Computable schrijven. De noodbediening van de Ketelbrug doet het sinds donderdag niet meer.

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.