Justitie maakt een inschattingsfout door de schuld voor het ongeval op de Ketelbrug op 4 oktober 2009 af te schuiven op de brugwachter die de brug bediende. Dat zegt hoogleraar Jan Friso Groote van de Technische Universiteit Eindhoven in een interview op Omroep Flevoland. Hij doet zijn uitspraken nadat Justitie anderhalf jaar na het ongeval aankondigde dat de brugwachter vervolgd gaat worden.
Volgens Groote maakt Justitie een inschattingsfout door de schuld voor het ongeval bij de brugwachter te leggen. Die drukte een verkeerde knop in, waardoor de brug open ging terwijl de slagbomen geopend waren. In de software van de Ketelbrug ontbrak tijdens noodbediening een regel code die voorkomt dat de brug opengaat op het moment dat de slagbomen nog niet gesloten zijn.
'Ook al maakt een brugwachter een fout – en we weten dat dat kan gebeuren – dan mag het nooit zo zijn dat daardoor een gevaarlijke situatie ontstaat', zegt Groote. Hij leidt de faculteit systeemontwerp van de Technische Universiteit van Eindhoven en is gespecialiseerd in de softwareveiligheid van ingebedde systemen.
Rijkswaterstaat
Volgens hem probeert Rijkswaterstaat zijn verantwoordelijkheid voor de problemen op de Ketelbrug te ontlopen. 'Het is niet de brugwachter waar je het eerst naar moet kijken. We zouden ook naar de procedures binnen Rijkswaterstaat moeten kijken en naar de werkwijze van de leverancier.'
Groote verwijt Rijkswaterstaat een gebrek aan openheid. 'Ze doen heel geheimzinnig over deze brug. Je kunt met niemand praten, je wordt altijd verwezen naar de persvoorlichters, die niets willen zeggen of niet weten wat er aan de hand is.'
Jos: Het doel van noodbediening is dat de veiligheidscontroles worden overgeslagen. Hierdoor kan een monteur (terwijl de brug is afgesloten door tijdelijke blokkades) of 3 ervaren medewerkers de brug nog tijdelijk bedienen indien er een sensor defect is. Hierbij kunnen er dan 2 medewerkers toezien op de veiligheid aan beide zijden dan de brug terwijl er 1 persoon de brug bedient.
De werkelijke schuldige hier is degene die heeft nagelaten de brug te laten repareren. Iedereen met de nodige ervaring in de ICT had kunnen voorspellen dat er ongelukken gaan gebeuren indien een brug in de noodbediening gebruikt wordt zonder voldoende alternatieve veiligheidsmaatregelen.
@jos boesten, hoezo een paar regels software?
De software van een dergelijke brug moet de brugdelen en slagbomen niet alleen de juiste bewegingen laten maken, met de juiste snelheid en in de juiste volgorde, maar ook met het juiste onderlinge interval en onder de juiste voorwaarden. Denk bij het laatste aan bijvoorbeeld aan het uitvallen van matrixborden of van één van de motoren van de brug. Dan moet het proces veilig afgebroken worden. De software moet daarvoor communiceren met vele tientallen hardware componenten (meetlussen, motoren, hydraulica, schuiven, etc.). Die componenten hebben vaak meerdere sensoren die allerlei statussen kunnen hebben.
Het systeem moet bediend kunnen worden via verschillende panelen op verschillende locaties. Ook moet het systeem diverse soorten feedback geven aan weg- en vaarverkeersdeelnemers en uiteraard aan de bediening zelf. Verder moet het systeem ook de hoofdbewegingen en eventuele bijzonderheden loggen en die bijzonderheden melden aan andere systemen en/of personen. Bij grote bruggen is er naast het hoofdbedrijf een eveneens softwarematige aangestuurd noodbedrijf als fall back. Deze heeft eigen afwijkende software ten opzichte van het hoofdbedrijf. Dit noodbedrijf staat los van de noodhandbediening zonder software.
Als de bediening werkt met een gevisualiseerd (virtueel) beeld, dan wordt de code een stuk omvangrijker. Bij een touchscreen besturing wordt het totaal aan code nogmaals groter. Verder kan er sprake zijn van integratie met andere systemen, zoals een radar- en videobewakingsysteem en dan is er nog meer code nodig.
Jos, denk dus niet dat je klaar bent met een paar regels of zelfs een paar honderd regels software voor de verschillende programma’s (van PLC’s en SCADA). Het gaat niet om een Märklin model spoorbrug.
@gast: Fijn om te merken dat jij, net als ik, van mening bent dat software slechts een onderdeel is van een geheel aan technische maatregelen. Het geheel moet dan gericht zijn op veilig gebruiken. Jij stelt zelfs dat de ’techniek’ zich dan in een veilige toestand moet plaatsen.
Ik vind dat een interessante stelling. Wat een veilige toestand is, is namelijk afhankelijk van je gezichtspunt. Ik ben van een leeftijd dat het ongeluk met twee F16 straaljagers in het Oosten van het land mij bekend is. De F16’s waren aan het gevechtsvliegen (dogfighting). Ze verongelukte waarbij de piloten stierven. Ik haal dit aan omdat dit een interessante illustratie geeft van veiligheid, automatisering en de gevolgen daarvan.
Wat ik van nabij heb vernomen over de oorzaak van dat ongeluk was het volgende. De betreffende versie van de software in de F16, die bij de gratie van een computer moet vliegen, ingesteld stond op het voorkomen van het trekken van meer dan 10G, of zo iets. G-trekken is zo snel bewegen of een bocht maken dat de zwaartekracht zich lijkt te vermeerderen. De grens in de software was getrokken bij wat een gemiddelde, goed getrainde piloot aankan zonder flauw te vallen.
Door een menselijke fout, was de bevinding, waren de piloten bij het manoevreren ’te laag’ uitgekomen. Echter: toen de piloten dat wilde corrigeren kwamen zij boven de gestelde grens uit. De software zette het vliegtuig op een ‘veilige’ koers en de beide vliegtuigen of in elk geval één boordde zich in de grond waar het waarschijnlijk was dat de vlieger het bij meer G mogelijkerwijs gered zou kunnen hebben.
Veel mitsen en maren. Het punt is duidelijk. Mensen, de ontwerpers van het vliegtuig maar ook de opdrachtgever tot het bouwen van dat type vliegtuig, hadden besloten dat het zo moest.
Nu even naar de software en de programmeur. De software was goed. Het werkte naadloos. Het effect was anders dan voorzien. Heel anders. Om die reden mag automatisering nooit zonder menselijke begeleiding of controle worden ingezet. Wat wij mensen kunnen, heeft nog geen enkel geautomatiseerd of gemechaniseerd systeem ons nagedaan. Het is in mijn ogen onverantwoordelijk om automaten ongecontroleerd hun werk te laten doen.
Zoals ICT’er zegt: de programmatuur die bij zo’n brug komt kijken is complex. Zoals jezelf zegt: aan het eind moet het ‘hufterbestendig’ zijn. Testen, testen en nog eens testen, is controleren als gebruiker of de programmeur zijn werk gedaan heeft. Niet door alle regels code te lezen maar door de automaat zijn werk te laten doen in alle mogelijke omstandigheden. En uit ervaring weet ik dat daar geen tijd, geld enzovoort voor is. Getuige de Turkse Boeing, waarin toch een gecertificeerd stuk hard- en software zat wat in heel veel van hetzelfde soort vliegtuigen zit. Ging toch anders dan de bedoeling was. Testen, testen en nog eens testen.
Maar al deze dingen zijn eigenlijk terzijde. Het gaat om één essentieel ding: mensen zijn verantwoordelijk geweest voor het achterwege laten dat het systeem rond de Ketelbrug naar redelijkheid functioneerde. De brugwachter had geen stem in die beslissing(en).