Niet alleen de software, ook de hardware van de Ketelbrug vertoonde gebreken. Dat blijkt uit uitspraken van één van de getuige-deskundigen tijdens de rechtszitting tegen de brugwachter van de Ketelbrug. Het gaat om een hardware-ingenieur van het ingenieursbureau dat meteen na het ongeval door Rijkswaterstaat werd ingehuurd om de oorzaak van het ongeval te achterhalen.
Tijdens de zitting werden drie getuige-deskundigen gehoord, om te achterhalen of het mogelijk is dat de Ketelbrug open ging, zonder dat de brugwachter daarvoor op een knop had gedrukt.
Dit feitenonderzoek bracht aan het licht dat niet alleen de software van de Ketelbrug rammelde, maar ook de hardware gebreken vertoonde. Dat blijkt uit het relaas van een hardwarespecialist van het ingenieursbureau dat meteen na het ongeval door Rijkswaterstaat werd ingehuurd om de oorzaak van het ongeval te achterhalen.
Lekstroom
Hij verklaarde dat de elektronische aansturing van bepaalde hardwarematige vergrendelingen niet volledig betrouwbaar was gebleken. De betrokken relais zouden, mogelijk door veroudering, 'kleverig' zijn. Daarmee bedoelde hij dat deze relais wanneer de spanning wegviel, niet altijd terugsprongen in de ruststand. Deze situatie zou aanleiding kunnen zijn tot 'onvoorspelbaarheid van het systeem'.
Daarnaast zei deze hardwaredeskundige dat ook een lekstroom, of een beknelde kabel, er voor had kunnen zorgen dat de programmable logic controller (PLC) het signaal ontving om de brug te openen. Een softwaredeskundige van hetzelfde ingenieursbureau verklaarde daarnaast dat wanneer de PLC het signaal 'brug openen'ontvangt, hij niet 'voor 100 procent kon garanderen dat een actie van de brugwachter daarvan de oorzaak was'.
Volgens de logsystemen van de Ketelbrug heeft de programmable logic controller van de brug op 13.58:43 een dubbel signaal ontvangen: 'brug zuidbaan nood openen' en 'noordbaan nood stoppen'.
Ketelbrug
De Ketelbrug werd in 1970 gebouwd. In de periode 2004 – 2005 is de Ketelbrug voorzien van een nieuw brugbesturingssysteem. Het oude besturingssysteem was te zwak om het nieuwe verzwaarde val te bedienen. Het brugbesturingssysteem is een semigeautomatiseerd systeem dat zorgt voor de aansturing van de brug.
Een elektrotechnisch installatiebedrijf was de hoofdaannemer, belast met het ontwerp en de uitvoering van het nieuwe besturingssysteem. Dit brugbesturingssysteem kan op twee manieren bediend worden: via de reguliere bediening en de noodbediening.
Het aantal drukknoppen in de noodbediening is uitgebreider dan in de reguliere bediening, wat het mogelijk maakt iedere stap in het proces apart te bedienen. Het aantal ingebouwde vergrendelingen is minder dan in de reguliere bediening om de beschikbaarheid van de noodbediening te verhogen. Alleen de hardwarematige vergrendelingen zijn meegenomen. Bij noodbediening worden de brugvallen aangestuurd door noodmotoren, die de vallen op lagere snelheid laten bewegen dan dat bij reguliere bediening het geval is. Het openen en sluiten van de brug op noodbediening kost dan ook meer tijd.
Bron : Onbedoeld openen Ketelbrug 4 oktober 2009, rapport van de Onderzoeksraad voor Veiligheid.
De meldingen dat hardware en software niet in orde zijn stapelen zich op.
Waarom wordt het proces tegen de brugwachter dan niet geseponeerd en waarom wordt RWS niet eens aangepakt?
Ik ben reuze benieuwd naar het onderbouwde verweer van RWS. En het is te hopen dat de brugwachter echt geen schuld heeft, hij lijkt steeds meer het slachtoffer van ‘de laagte in rang zijn’ en zo alle bagger over zich heen krijgend.
Helemaal mee eens. Het bekende liedje weer, pak de makkelijkste Kop-van-Jut dan blijven de stroppendassen buiten beeld en die kunnen nog vele jaren door blijven knoeien. Hoeveel geld je er ook tegen aan blijft smijten aan zogenaamde maar altijd publiek betaalde overheidsinstanties.
Hier kunnen ze de (ingehuurde) brugwachter de schuld van geven. Ik ben benieuwd wie ze de schuld kunnen geven voor die zendmast in Hoogersmilde die ingestort is. Het overzicht is toch zoek en het moet zogenaamd goedkoper zijn, met al die uitbestedingen.
Wat ik mis (of waar wellicht nog niet over gecommuniceerd is): is er gekeken naar de design documentatie van destijds, naar de implementatie versus design (is het geïmplementeerd zoals ontworpen) en het testdesign + uitvoering?
Ofwel: is er wel gemaakt wat bedacht is, en is dit ook afdoende afgetest … … of zijn er wellicht onder financiële en of tijdsdruk dingen versimpeld of overgeslagen ?
Zoals dat gaat tegenwoordig, alles wordt uitbesteed aan de goedkoopste. Mogelijk dus een bedrijf dat nog nooit eerder een brug geautomatiseerd heeft en dus het vak, op kosten van de belastingbetaler, opnieuw leert met alle kinderziektes van dien. Om dit te controleren wordt weer andere expertise ingehuurd. Ook de specificaties worden door inhuur gemaakt. Dit alles tegen de laagste tarieven. Advocaten krijgen wel hoge tarieven, engineers niet. Rara dat er dan ongelukken gebeuren.
Een brug die onbedoeld zijn gesloten stand verlaat kan ook worden voorkomen doordat er in de software een extra code (lees: intelligentie)wordt toevoegen met behalve “inschakelstoring” (motor inbedrijf) ook de detectie van “uitschakelstoring” met gevolg door bijv. een noodstop. Met uitschakelstoring wordt bedoeld dat wannneer er geen inschakelcommando is maar door onbekende reden (een kleverig relais contact) een inbedrijf melding er is van de brug motor! Verder is het veld statusmelding “rem gespannen” van de mechanische rem absoluut geen overbodige lux ongeacht de rem fail safe is uitgevoerd, vooral bij de bascule brug die negatief gebalanceerd is. De bedieningsvrijheid in noodbedrijf blijft nog een issue!