Managed hosting door True

'Brugwachter moet fout kunnen maken'

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

'Rijkswaterstaat laat steken vallen bij Ketelbrug'

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

De heer Groote heeft gelijk.Een bediening voor de brugwachter hoort "hufterproof" te zijn. Dat betekent dat ten alle tijden, ook in een tijdelijke bediening of in een noodprotocol de afsluitbomen eerst gesloten moeten zijn voor een brugwachter de brug kan openen.
Als er in de software vergeten is een vinkje aan te geven, mag deze fout niet in de schoenen van een bedienaar worden geschoven want dan komt de fout terecht bij de eigenaar, in dit geval RWS. Beter nog dan software is dat bij gesloten afsluitbomen er een mechanische handeltje overgaat dat een signaal veilig geeft tot openen. Dit na jaren ervaring met Amsterdamse bruggen als technisch adviseur

Ik ben het niet met de heer Groote eens. En wel om de volgende reden. De noodbediening is een noodbediening, bedoelt om bij exceptionele omstandigheden in staat te zijn bepaalde onderdelen van een brug aan te kunnen sturen. In nood ligt de verantwoordelijkheid voor de juiste stappen volledig bij de bediener en moet het ook mogelijk zijn de brug te openen zonder dat de slagbomen gesloten zijn.

Wanneer de sensor voor het detecteren dat de slagbomen gesloten zijn defect zou zijn zou het anders onmogelijk zijn om de brug nog te openenen omdat ook in noodmodus het passeren van allerlei veiligheidsmaatregelen onmogelijk is.

Mijn mening is dat deze hele situatie gecreeerd is door de eigenaar van de brug die het probleem, waardoor om de brug permanent middels noodbediening bedient moest worden, had moeten verhelpen.

@Daniel

Maar... het mag niet zo zijn dat, zoals in dit geval, een noodingreep tot gevaarlijke situaties kan leiden.

Ik ben het met Daniel eens. Alle software bevat fouten. Als het om veiligheid gaat moet de eindverantwoordelijkheid dan ook altijd liggen bij een persoon, niet bij een computersysteem.

Om een extreem voorbeeld te noemen. Als een vliegtuig neerstort dan hoor ik liever dat dat kwam omdat er een piloot iets verkeerd deed dan dat een computersysteem faalde. In het eerste geval kan je het als een enkel incident beschouwen. In het tweede geval zijn alle vliegtuigen onbetrouwbaar.

@PaVaKe

Een noodingreep mag niet tot gevaarlijke situaties leiden, maar dat is de verantwoordelijkheid van de brugwachter.

De software mag (in noodbediening!) best gevaarlijke situaties toestaan, een brugwachter mag dat niet.

De brugwachter in kwestie was een uitzendkracht die er nog maar net aan het werk was en geeneens de nukken van het systeem kende. Iets wat de oorspronkelijke brugwachters wel wisten maar die werkten ondertussen al ergens anders.
En als de persoon in kwestie opdracht van zijn baas krijgt om de noodbediening te gebruiken wordt de schuld in zijn schoenen geschoven omdat hij beter zou moeten weten?
Sterker nog: controle van alle andere bruggen is afgeblazen dus het kan goed zijn dat er nog meer ondeugdelijke bruggen in Nederland zijn.

@Daniel: "De noodbediening is een noodbediening, bedoelt om bij exceptionele omstandigheden in staat te zijn bepaalde onderdelen van een brug aan te kunnen sturen."

Helemaal mee eens. EN!!! Noodbediening is NOODBEDIENING! Het onder normale bedrijfsomstandigheden gebruiken van noodbediening is uit den boze en dient, als onderdeel van de bediening van de noodbediening, fysiek/mechanisch beschermt te zijn tegen 'per ongeluk' gebruik. Noodbediening die deze eis negeert bij ontwerp en implementatie is gevaarlijk. De verantwoordelijke daarvoor is degene die opdracht heeft gegeven tot het implementeren en operationeel maken van een dergelijke bediening. Noodbediening gebruiken als omzeilen van een organisatorisch probleem bij de normale bedrijfsomstandigheden is even eens uit den boze. Moorddadig in dit specifieke geval. Als al iemand vervolgd dient te worden voor dood door schuld of hoe het ook mag heten is het om te beginnen de minister en van daar af naar beneden. Die brugwachter, al of geen uitzendkracht, komt de eerste 25 lagen van de organisatie nergens voor.

Een ander ding wat mij als ICT-er aan het hart gaat, is het volgende. Automatisering is het door mechanische functionaliteit uitvoeren van andere mechanische functionaliteit op basis van ingebakken (menselijke) beslissingen. De software die de drijfwerken aansturen om de klep van de brug te bewegen, dient onderdeel van een geheel te zijn dat gericht is op het veilig gebruiken van de brug. Veilig gebruiken van de brug betekent dus dat zich geen (dodelijke) ongelukken kunnen voordoen bij verantwoord gebruik. Software die geen aansluiting heeft met een dergelijk geheel en een systeem dat toestaat dat de veiligheid in het geding te laten zijn is sociaal en maatschappelijk onverantwoord. Wij, als (mensen in de) gemeenschap hebben de verantwoordelijkheid voor het veilig gebruiken van onze weg- en waterwerken neergelegd bij de mensen binnen het ministerie, beginnend bij de minister.

Fouten in software zijn ontstaan door mensen en kunnen alleen gecorrigeerd worden door mensen. Alle betrokken mensen hebben verantwoordelijkheid voor het gebruik, implementatie, bouw, testen en operationeel maken. Het grote voordeel van een computer is: hij kan helemaal niks! Alles wat een computer doet is aan het apparaat opgedragen door een mens. Het allergrootste deel van de keren is dat gebeurd door een programmeur. Als gebruiker van de software heb dus de verantwoordelijkheid om te controleren en beslissen of de programmeur verantwoord bezig is geweest.

Bij deze mijn eigen deel van mijn verantwoordelijkheid: "Beste brugwachter, sorry dat mensen jou als 'schuldige' aanwijzen. De groep is groter dan jij alleen."

Allen,

als de discussie gaat over "mag software fouten bevatten", dan moeten we niet de fout maken om bedrijfsapplicaties te vergelijken met systemen die aan veiligheidseisen moeten voldoen (safety integrity). Als er mensenlevens in het geding kunnen zijn, dan moet een systeem in elke situatie, dus ook bij software fouten, zichzelf in een veilige toestand plaatsen. Neem bijvoorbeeld de overwegbomen bij een spoorwegovergang, die sluiten automatisch als de stroom uitvalt.

Wordt er dus gekozen om een (mechanische)installatie software matig aan te sturen, dan gelden er zeer strenge eisen die aan de software gesteld worden. Evenzo voor het testproces. Daarom is de stelling dat een dergelijk systeem "hufterproof" moet zijn volledig terecht en correct. Om te stellen dat systemen fouten kunnen bevatten en dat je dan als gebruiker moet controleren of de programmeur zijn werk goed gedaan heeft is volslagen onzin en bovendien onmogelijk. Als je dit zegt begrijp je er niks van (sorry G.J. van der Wolf, maar het is niet anders).

De verantwoordelijke voor het systeem is daarmee eerder verantwoordelijk dan de bediener. Dat geldt ook voor degene die de bediener heeft ingewerkt en mogelijk heeft nagelaten te wijzen op ondeugdelijk gebruik van noodvoorzieningen en de risico's die daaraan kleven.

Je zult maar de betreffende brugwachter zijn die er net zit, slecht ingewerkt is (neem ik aan) en met een systeem moet werken wat fouten bevat en dan ook nog publiekelijk verantwoordelijk ervoor wordt gehouden door mensen die de details niet kennen maar wel een oordeel hebben.

Wat mij betreft gaat alle steun primair naar de slachtoffers en secundair naar de betreffende brugwachter.

Ben slechts een domme huisarts (met veel belangstelling voor IT, anders zou ik Computable niet lezen).
Zo heel complex kan de besturing van een brug in mijn ogen toch niet zijn. Het gaat volgens mij om slechts enkele regels en de oen die die regels niet goed heeft ingevuld treft blaam. En nog meer de superieuren die dat goed hebben gekeurd. Ideale oplossing van dit probleem is: blame another one: dus de bediener (die ingehuurd is en niet voldoende onderlegd).
driewerf schande!


Addendum: hoe high-tech is het bedienen van een brug tegenwoordig?? In mijn opinie is het gewoon dom werk, wat je met domme programmeerregels zou moeten kunnen ondervangen. In de medische wereld zijn we wel anders gewend.
Wordt tijd dat techneuten eens naar de echte wereld kijken.

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

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.