Softwarefouten maken bediening sluizen Afsluitdijk onbetrouwbaar

Door een groot aantal fouten in de software voor de bediening van de bruggen en sluizen bij de Afsluitdijk kunnen brug- en sluiswachters er niet op vertrouwen dat hun opdrachten voor de besturing correct uitgevoerd worden.

Omrop Fryslân geeft als voorbeeld dat de systemen aangeven dat een brug nog open staat, terwijl op de camera's te zien is dat deze in werkelijkheid gesloten is. In het voorjaar worden de belangrijkste beveiligingsfuncties van de software gerepareerd, wat naar verwachting vijf tot zeven nachten van stremming oplevert.

De problemen dateren al van 2016, toen de software vervangen werd. Dat leidde er vorig jaar toe dat Rijkswaterstaat onderzoek liet uitvoeren. Daarbij kwam een groot aantal gebreken met de software en techniek aan het licht. Rijkswaterstaat heeft daarna meer camera's geplaatst en brugwachters ingezet om de situatie in goede banen te leiden.

Een nieuw onderzoek moet uitwijzen hoe het in 2016 met de oplevering fout kon gaan en wie er verantwoordelijk is. Volgens minister van Infrastructuur en Waterstaat Van Nieuwenhuizen - Wijbenga gaat het nog anderhalf tot twee jaar duren voor alles weer aan de eisen voldoet.

Ook in Noord-Holland ging het mis met software voor bruggen. De software voor de Prinses Amaliabrug bij Westknollendam moet aangepast worden waardoor deze twintig weken later klaar is dan gepland. De software is noodzakelijk om de brug aan te sluiten op de bedieningscentrale in Heerhugowaard. De Prinses Amaliabrug moet eind augustus 2019 gereed zijn. Niet bekend is wat het probleem met de software is.

Reacties (176)

[marcelvdk]

Besturing op laagste niveau vindt plaats mbv PLC's. De besturingen moeten vaak fail-safe worden uitgevoerd. Daar komt erg veel bij kijken, meer dan de meeste mensen zich kunnen bedenken. Het is erg vervelend dat als een stuk kantoorsoftware niet werkt, maar bij machines praten we soms ook over mensenlevens. Bij machinebesturingen is het wel wat anders.
Een paar jaar geleden moest ik de voor een brug de bestaande Siemens S5 software (STL) "ontrafelen", want de overheid was wat documentatie kwijt geraakt. Ben er een aantal weken mee zoet geweest om functioneel te omschrijven wat er allemaal in de code gebeurd. M.a.w. er zit veel meer in dan wat je in de eerste instantie zou verwachten.
Daarboven zit een laag die aangeeft wat er moet gebeuren. En dus rijst de vraag, zit het al fout in de PLC laag, of daarboven? En hoe zijn de afname testen gedaan?

Aanvullend: uit dit artikel http://m.binnenlandsbestu...gingsupdates.205563.lynkx)
[quote] In 2010 werd een kerncentrale in Iran gehackt, waarvoor Siemens de plc’s leverde. Djohan van Revnext: ‘Het was mogelijk om de turbines van de centrale op afstand te bedienen. Deze werden door hackers 5 procent hoger afgesteld waardoor ze harder gingen draaien en oververhit raakten.
[quote]
Is wel wat te kort door de bocht dat het gewone hackers zouden zijn. Het gaat over stuxnet hier. Daarvan wordt door de experts toch echt wel van gedacht dat de VS/Israel hierachter zouden zitten. Mogelijk heeft Siemens er ook aan meegewerkt. Daar is een documentaire over gemaakt. Is een aanrader.(fff googlen)

[Reactie gewijzigd door marcelvdk op 23 juli 2024 00:03]

[cagXZ]

Een paar jaar geleden moest ik de voor een brug de bestaande Siemens S5 software (STL) "ontrafelen", want de overheid was wat documentatie kwijt geraakt. Ben er een aantal weken mee zoet geweest om functioneel te omschrijven wat er allemaal in de code gebeurd. M.a.w. er zit veel meer in dan wat je in de eerste instantie zou verwachten.

Zou je wat meer kunnen vertellen over wat je precies ontrafeld heb?
Ik vraag mij bijvoorbeeld af in wat voor taal dat allemaal geschreven is!

[marcelvdk]

Het brug project was in Siemens S5 = STL taal. Oud maar behoorlijk krachtig. Lastig te lezen/begrijpen. Daarbij zijn ladder en FBD kinderspel. Het moderne SCL is voor de nieuwe generatie nog beter te behappen. Al hebben servicemonteurs daar vaak weer meer moeite mee. Een ladderdiagram leest nou eenmaal makkelijk weg.
voorbeeld:
-------------------------------------
O Automode
O Handmode
AN Restart
(
A SequenceActive
A ModuleActive
O
AN SequenceActive
AN ModuleActiv
)
A WithinRange
L 5000
T MW500
L 2000
T MW504

(A= And, O=Or, AN=And Not L= Load, T=Transfer)
-------------------------------
Kun je ook in ladderdiagram doen, Dan zie je veel sneller wat er gebeurd. Je moet alleen veel meer ladders maken.
Maar ik kom dit voor mijn werk vooral bij bestaande installaties tegen. Bij de nieuwe projecten gaan we nu ook over op TIA waarbij ook een totaal nieuwe opzet is gemaakt, en STL eigenlijk niet meer voor komt. Nu komt er dus veel meer SCL voor in de plaats.

NB: het brugproject ging van Siemens S5 naar Rockwell PLC's. Ik heb alleen dus alle functies ontrafeld en functioneel beschreven wat er gebeurde. 6-8 weken mee bezig geweest. Ik denk tegen de 300 pagina's aan. Was ik zo goed als klaar, kwam het originele(vermiste) document weer boven water. 1 Voordeel, we konden controleren of wat ik had uitgevogeld, overeen kwam met originele document. bleek nog verrassend te kloppen.

[JorisNoordweg]

Onzin code. Load and transfer acties worden niet conditioneel uitgevoerd. Je zult dus een jump instructie moeten toevoegen om over je load/transfer te springen.
Zo zie je maar hoe snel je een denkfout maakt in STL. In FBD was dat niet gebeurd.

Het vervelendste met deze fout is nog wel dat je het RLO en FS bit van je statusregister hebt gemanipuleerd zonder deze terug te zetten. Volgende logische operatoren (in een volgend netwerk) zullen dus onbedoeld beïnvloed worden door het resultaat van jouw netwerk).

Nasty bug om te vinden.

[Reactie gewijzigd door JorisNoordweg op 23 juli 2024 00:03]

[marcelvdk]

klopt, was ook een stukje zo uit mijn hoofd, en aangezien ik geen STL programmeur ben... Maar ik kom er wel veel mee in aanraking. En dan is het een pain in the ass om uit te vogelen wat er daar gebeurd.

[dbeusink]

Zoals JorisNoordweg al aangeeft is dit kleine stukje code al niet bepaald fraai, je krijgt eerder zoiets:

O Automode
O Handmode
AN Restart
A(
A SequenceActive
A ModuleActive
O
AN SequenceActive
AN ModuleActiv
)
A WithinRange
JCN NOTR

L 5000
T MW500
L 2000
T MW504

NOTR: NOP 0

Zo zie je maar dat deze taal vaak fouten oplevert en lastig te lezen is door onervaren STL programmeurs / service medewerkers.

[Justberry]

Als PLC programmeur kan ik me soms heel erg verbazen over wat er gemaakt is. Stap 1 voor mij is altijd bij wat voor error dan ook moet het systeem in veilige modus gaan. (hier is dat dicht gezien dat het ons moet beschermen)
Stap 2 is de meest basale functie moeten simpel en perfect werken. Dus nooit mag zoals hier een systeem melden dat iets anders is dan in realiteit, dit slaat ook op de veiligheid. Als iemand ooit vertrouwt op je systeem mag dit nooit fout gaan.

Ooit ook een oude programma mogen ontcijferen, als reactie gegeven waarom dit ooit goed gekeurd was. ik kon als gebruiker het systeem kapot maken met 1 handeling..

Dan vind ik hier ook dat 1,5/2 jaar om software fouten op te lossen wel heel erg overdreven tenzij de hele ground works verpest is en opnieuw gemaakt moet worden.
Meeste systemen die ik heb gemaakt zijn max een half jaar programmeren en dan een maand testen/debuggen.

[burne]

Dan vind ik hier ook dat 1,5/2 jaar om software fouten op te lossen wel heel erg overdreven tenzij de hele ground works verpest is en opnieuw gemaakt moet worden.

Je kunt niet live testen, want de brug draait productie. Je zult moeten beginnen met een simulator te maken, minimaal één van ieder component. (Je hebt duplicatie in de vorm van verkeerlichten en slagbomen die je niet allemaal apart hoeft te testen.) Dat kost je gauw een half jaar.

Zodra je software hebt zul je een test moeten plannen. Die moet je maanden van tevoren aankondigen want je sluit de afsluitdijk een nacht lang af. Al het vrachtverkeer moet omrijden en je moet ook even nakijken of de A7 niet dezelfde nacht ook wat heeft. Als je drie keer wilt testen is de vertraging alleen daarvan al meer dan een half jaar.

Dan moet er niet veel mis gaan om 1.5 jaar te halen.

[burne]

Het is een brug, zo enorm complex is dat niet.

Het zijn vier bruggen, vier sluizen, twintig spuien. Als een brug open is moeten stoplichten, verkeersborden en slagbomen om, en allemaal op de juiste manier in de juiste volgorde, en alles moet bewaakt zijn zodat bij een probleem er alarm geslagen wordt. Zo complex is het wel. En iemand anders heeft het al eens onderschat, anders hadden we deze discussie niet gehad.

[Stemis]

Helemaal mee eens. Het is erg complex om te zorgen dat de veiligheid gewaarborgd blijft zonder dat we de gebruiker(brugbeheer) kunnen vertrouwen. Bij dit soort systemen met veel relaties tussen actoren en sensoren is het ook gebruikelijk om meerdere lagen beveiliging in te bouwen. Zowel soft- als hardwarematig

Mocht er een sensor een verkeerde waarde geven dan kan het hele systeem in de war raken.

Een welbekende casus binnen het software domein waar het in het verleden mis is gegaan met dodelijke gevolgen is de Therac-25. Een medisch stralingsapparaat dat door een fout in de software een enorm hoge straling aan de patiënten gaf.
Er waren niet genoeg beveiligingslagen waardoor een fout in de software fatale gevolgen had.
Zeker het lezen waard: https://en.m.wikipedia.org/wiki/Therac-25

[Reactie gewijzigd door Stemis op 23 juli 2024 00:03]

[Brousant]

[...]

Het zijn vier bruggen, vier sluizen, twintig spuien.

Alle details van het openen en sluiten van 1 van die bruggen hangen toch niet samen met die van de andere? Een softwarelaag die dat alles coördineert hoeft met het meeste daarvan niet te maken te hebben. Als die aantallen het zoveel meer complex maken is het systeem niet goed opgezet.

[HummerHealey]

Een veel gemaakte opmerking over infra land is dat iedereen de helft van de tijd bezig is om te vertellen hoe lastig het allemaal is en de ander helft van de tijd bezig is om het zo moeilijk mogelijk te maken (om de eerste stelling te onderbouwen). In mijn ervaring in de infra (Centrale besturing metro Amsterdam, Stavoren sluizen en de nieuwe Coentunnel) ligt het meer aan de competentie van de mensen, de gigantische overhead aan documentatie, ambtenarij, onzinnige testen (waardoor er voor de nuttige testen minder tijd is). Ik was er klaar mee en ben weer terug bij proces en productie automatisering.

[GeeMoney]

Het is software, dat is natuurlijk gewoon allemaal prima te simuleren lijkt me.
En komt het omdat de bedrijven/overheid het wiel weer opnieuw proberen uit te vinden en/of de goedkoopste inschrijver heeft gegund?
We zijn natuurlijk niet het enigste land ter wereld die bruggen electronisch willen bedienen met of zonder sluizen en slagbomen. Ook neem ik aan dat de sluizen los staan van de bruggen.

[Stemis]

Ik denk dat je de complexiteit zwaar onderschat.

We hebben het hier niet over een simpele brug en deze brug is ook geplaatst op een snelweg waardoor je met ander soort verkeer te maken hebt.

Er komen veel factoren bij kijken die deze situatie uniek maken waardoor je dus niet zomaar een 'standaard' bruggenbediensoftwarepakket kan inzetten.

Daar komt nog bij dat het op afstand bestuurd wordt en de veiligheid met o.a. camera's in beeld gebracht moet worden voordat er alarm geslagen kan worden. Wat het alleen maar belangrijker maakt dat het systeem over de nodige veiligheidsmaatregelen beschikt.

[Reactie gewijzigd door Stemis op 23 juli 2024 00:03]

[GeeMoney]

Dat begrijp ik maar dat is bij 70% van alle bruggen in de grote steden van Nederland het geval. Die worden al jarenlang op afstand bedient, met camera’s bewaakt en slagbomen geactiveerd en verkeer gestopt.
De gedachten en technieken zijn niet nieuw, waarom gaat het dan nog steeds zo gigantisch mis bij dergelijke projecten.

[Stemis]

Ook mij blijft het verbazen dat er zoveel overheidsprojecten mis gaan.

Het blijft speculeren over waarom het hier ook weer mis is gegaan.

Frappant is dat de software al een keer herschreven is en de nieuwe software dus ook niet goed blijkt te zijn.

[psyBSD]

De overheid is de grootste IT organisatie van Nederland met de meeste IT projecten en een full-disclosure policy. (WOB)

Niet zo gek dat alle zaken die misgaan uiteindelijk in de openbaarheid komen.

[Verwijderd]

Stel jij dat er sowieso enorm veel misgaat bij IT, ook in de burgermaatschappij, maar dat het verschil is dat bij de overheid direct zichtbaar wordt doordat er meer openbaarheid is?
Wat ik nu graag wil weten als iemand die wel een klein beetje verstand heeft van hardware en software (zoal programmere met C of Verilog) maar niet in de IT werkt, in welke mate gaat het verkeerd doordat het moeilijk is en in welke mate gaat het verkeerd door bureaucratie (zowel bij de overheid als privaat), slechte planning, gebrekkige communicatie...? Is het meer een technisch probleem of meer een probleem met allerlei soft skills?
Bij gebrek aan een betere omschrijving.

[mg794613]

Mijn persoonlijke ervaring is dat het op alle lagen "designed to fail" is.
D.W.Z. bij aanbesteding of tenders doen partijen de laagste prijs opgeven en de kortste doorlooptijd.
IT bedrijven weten namelijk, dat als de overheid je heeft aangenomen ze het project niet snel stil legt.
Daardoor worden de deadlines (logisch) opgeschoven, budgetten halverwege verdubbelt. En als het dan al "af" komt moet er meestal een derde partij ingehuurd worden omdat "het toch niet af is"

[pcgeek1]

De bruggen worden niet op afstand bediend. Zowel op de sluis als bij de brug zelf zitten 24 uur per dag daadwerkelijk personen (schouwers).

[koploper48]

De bruggen (Kornwerderzand)worden wel op afstand bediend. De brugwachters zitten in het bedieningsgebouw bij de sluizen. De looproute naar ons (Kazematten)museum gaat over de zuidelijke brug. Het gebeurd regelmatig dat bezoekers lopend op de brug door de brugwachter per luidspreker gewaarschuwd worden de brug vrij te maken. Dat ziet hij via op de brug staande cameras. Het bedieningsgebouw bij de bruggen wordt tegenwoordig bevolkt door onderhoudspersoneel en mensen die (in de zomer) de brug moeten nathouden. Ook al zo'n probleem

[pcgeek1]

Bij de bruggen zelf zitten WEL personeel.. en ik snap dat de bruggen vanaf het sluizencomplex worden bediend. Maar op afstand wordt er alleen toezicht gehouden door camera's, wat hier dus niet het geval is. En de brug/sluiswachter hoeven de mensen die de brug oversteken niet te waarschuwen, want je staat vanzelf voor een slagboom. En PS wat betreft dat gelxx over de speakers krijg je zomers ook de kriebels van, nog nooit een sluis meegemaakt waar zo getetterd wordt over de speakers. En waarom moeten ze de brug nat houden? En dan de problemen met de brug doordat deze een x aantal jaar geledenen is vernieuwd en een tig tal tonnen zwaarder was als de oude/originele brug. En dan hebben we het er niet over dat de heleboel al aan het verzakken is.

[Luukje01]

Nee.. Het is hardware die met software wordt aangestuurd. Hardware kan anders reageren dan tijdens het fatten wordt bekeken.

Daarnaast, wie zegt dat er geen profibus storing in zit.. Of dat een encoder net te kritisch is afgesteld.. Machine software is alles behalve dom code kloppen, maar juist bedenken hoe de hardware kan reageren..

[Step5]

Klopt wat je zegt, maar als ik in het gegeven voorbeeld lees dat de brug dicht is maar het bedienpaneel aangeeft van niet...
Als dat niet snel opgelost kan worden is er toch iets grondig mis.

Uiteraard kun je iemand die er geen verstand van heeft alles wijsmaken

[Reactie gewijzigd door Step5 op 23 juli 2024 00:03]

[GeeMoney]

De brug gaat toch niet direct open als een boot in de sluis ligt of wel? Dat zijn dus losse systemen die wel met elkaar te maken hebben maar wel los staan van elkaar.
Ik zeg ook niet dat het in 2 dagen te doen is maar het verbaast me altijd wel dat de kennis nooit van elders opgedaan of gebruikt wordt.
De technieken en situaties zijn helemaal niet nieuw, de werking van die hele dijk is toch al +20jaar zo(vol electronisch) daar is dus behoorlijk wat aan historische gegevens beschikbaar lijkt me.

[Reactie gewijzigd door GeeMoney op 23 juli 2024 00:03]

[burne]

De brug gaat toch niet direct open als een boot in de sluis ligt of wel?

De brug moet open zijn voordat de boot door de sluisdeur kan varen.

Het verbaast me dat je je van zoiets simpels als een sluisdeur met een brugdeel er overheen geen voorstelling kunt maken.

De technieken en situaties zijn helemaal niet nieuw, de werking van die hele dijk is toch al 87 jaar bekend, daar is dus behoorlijk wat aan historische gegevens beschikbaar lijkt me.

(ik plaag je nu, maar ik hoop dat je er iets van leert..)

[GeeMoney]

Een boot vaart een sluis in en wacht dan neem ik aan tot het level bereikt is en de brug open gaat en dan pas doorvaart? Als de brug direct open kan bij het invaren van een sluis dan was de sluis natuurlijk overbodig.
En ik doelde natuurlijk op de electronische werking, exacte jaartal weet ik niet maar dat het 87 jaar geleden niet vol electronisch ging dat weet ik zeker.

Ik maak je eventuele werk of opmerkingen ook niet belachelijk maar we moeten nu niet doen alsof we de eerste raket aan het lanceren zijn naar de maan.

[Reactie gewijzigd door GeeMoney op 23 juli 2024 00:03]

[koploper48]

Tussen de sluizen en de brug zit een paar honderd meter. Als de sluisdeur opengaat is de brug nog niet open. Pas bij het naderen van de brug gaat hij open. Pleziervaart moet vaak nog extra wachten in dat tussengebied. Alleen voor beroepsvaart gaat de brug ri. Waddenzee eerder open om de boot in een keer door te laten varen. De andere kant op ri. IJsselmeer kunnen de schepen eerst de brug door komen dan in het voorhaven gebied en dan pas gaat de sluisdeur open. Schepen liggen daar dan ook vaak een tijdje te wachten.

[pcgeek1]

Waarom moet de brug open zijn? Als ik in de sluis lig en de sluisdeuren gaan open, kan ik toch gewoon uitvaren? Er is gewoon een wacht mogelijkheid tussen sluis en brug, afmeerpalen en anders blijven drijven. En wachten totdat de brug open gaat en verder varen.

Tenzij je vanaf zee komt varen en je niet onder de brug door past, dan moet de brug inderdaad eerst open zijn wil je de sluis in kunnen varen.

[Step5]

Tja en 1 op 1 kopiëren naar een moderner systeem is normaal niet zo moeilijk. Maarja soms moet het "handiger", "slimmer", #industrie 4.0

[jay123]

Typisch een geval van: Niet genoeg kennis van zaken dus "ik weet er alles van!"

Ik kom dit vaak genoeg tegen op de werkplek. Collega's die in mijn vakgebied een beetje kennis hebben, komen vaak met de meest eenvoudige oplossingen; "Maar heb je hier al eens aan gedacht?"; Collega's die daadwerkelijk met de materie bezig zijn, hebben die oplossing al lang van de baan geveegd, aangezien er veel bijkomstige problemen veroorzaakt worden. Problemen waaraan eerder vernoemde collega's zelfs nog niet aan kunnen denken, omdat ze niet genoeg verdiept zijn erin.

Het heeft een naam, maar ik kom er niet op.... niet mijn vakgebied

[burne]

Het Dunning-Krüger-syndroom.

[jay123]

Wow! Bedankt!

[bouwfraude]

Daar heeft het halve management last van.

[wjn]

Soms lijkt het goedkoper en betrouwbaarder om gewoon een brug-/sluiswachter te laten zitten

[burne]

Die moet dan twee bruggen, twee sluizen en tien spuien van 32 kilometer afstand bedienen. En de automatisering waar we het nu over hebben is nodig om dat veilig te kunnen doen. Je zou twee brugwachters neer kunnen zetten (een aan iedere kant) en alle automatisering wegslopen maar dat is onveilig.

[pcgeek1]

Zowel op de sluizen als bij de bruggen zit 24u personeel, NIETS wordt op afstand bediend!

[pcgeek1]

Die zitten er ook... 24u per dag

[Nelis_]

(hier is dat dicht gezien dat het ons moet beschermen)

Als zeiler zie ik dat toch anders Moet er niet aan denken dat de brug ineens dichtgaat...

[Step5]

Of de sluisdeuren ineens dicht (al gaat dat niet zo snel)

[familyman]

Beetje doorvaren, als voor.de brug wachtende automobilist heb ik daar niet zo'n moeite mee. Bedoel maar, voor de een is het bug, voor de andere een feature :-)

[Sando]

Dus nooit mag zoals hier een systeem melden dat iets anders is dan in realiteit

Dit is misschien wat off-topic, maar ik erger me daar vaak aan bij liften. Dat je op de knop drukt en het knop-lampje licht even op, wat aangeeft dat *iets* weet dat er op een knopje wordt gedrukt. Maar het lift-systeem zelf doet niets. Dan druk je een tweede keer, wat harder, licht het lampje weer op, en dit keer hoor je ook dat de lift in beweging komt.

De (onschuldige) fout is hier dat er blijkbaar twee sensoren in de knop zitten waarbij de ontwerpers er van uit zijn gegaan dat ze altijd tegelijk worden geactiveerd. In de praktijk is dat dus niet het geval.

Ik kan me voorstellen dat een dergelijke onjuiste aanname ook bij het ontwerpen van grote machines wordt gedaan, en zal zo'n kleine vergissing voor veel problemen kunnen zorgen.

Misschien wordt bij de sluis na een software-update onder bepaalde omstandigheden een andere subroutine aangesproken waarin de brugstatus wordt afgelezen van een andere sensor die in onbruik is geraakt, waardoor de software niet meer in de status "brug gesloten" terecht komt.

[Tjerk.g.visser]

't Is nog maar twaalf uur later, dan mag ik hier nog wel op reageren

Dat lift-lampje heeft een geïntegreerd lampje, dat licht op door een dubbelcontact in de knop. Daar zit geen logica of aansturing tussen. Dat het soms oplicht en er niets gebeurd kán te maken hebben met de cyclustijd van een PLC (als je precies wilt weten hoe dat werkt dan moet je maar even gaan googlen hoe bijvoorbeeld een Siemens S7-300 werkt).
Een PLC voert cyclisch zijn programma uit en begint vaak met het inlezen van van de ingangen. Die status houd hij dan de hele cyclus vast. Afhankelijk van de grootte van het programma duurt een cyclus 50 tot 500 milliseconden. Als jij het geweldige gevoel voor timing hebt om precies binnen een cyclus de knop in te drukken en los te laten dan 'ziet' de PLC dat niet.
Een beetje PLC-programmeur weet dit en kan dit oplossen door de IO met een snellere cyclus te scannen en vast te zetten tot de volgende programma cylcus.

Toevallig heb ik ooit een spoorbrug mogen programmeren, ook daar werden de PLC's vervangen door nieuwere modellen. Een 'software-update' wordt niet even OTA door gevoerd. Daar wordt goed over nagedacht en dat moet ter plekke uitgevoerd en getest worden. Bij veel (spoor)bruggen zijn de sensoren en aansturing ook SIL2 of 3 uitgevoerd. Dat betekend in geval van sensoren al dat die dubbel zijn én dat beide sensoren binnen een aantal milliseconden van elkaar het zelfde signaal moeten geven. Zo niet , dan gaat de PLC in storing en moet er al een service-engineer bij komen om de brug te resetten. Dat betekend dan vaak al dat er een mechanisch probleem is. De brug sluit bijvoorbeeld te langzaam doordat er te weinig hydraulische druk is.
Als de brug al dicht is en de beide sensoren geven niet meer de zelfde status dan treedt de storing trouwens ook op. Dat is geen PLC-software functie maar dit zit al in de IO-kaart van de PLC.

[familyman]

Ik snap best dat dit complex is. Echter, van dit soort verhalen krijg ik wel het gevoel dat de implementatie waarover we het hebben niet heel robuust in elkaar

Als ik kijk naar goede software architectuur, het superbelangrijk is dat er sterke separation of concerns is en goede test cases zijn.

Bij dit soort systemen gaat dat door naar pic niveau. Dat maakt het inderdaad langduriger en uitgebreider dan veel mensen denken.

Ik kan me voorstellen dat door hoe dit soort projecten wordt aanbesteed, daar vrij weinig ruimte voor is.

Overigens, als we werken met camera's en brugwachters, zie ik alweer meteen een manier voor automatiseren, die een beveiliging oplevert buiten alle aansturingssoftware om...

[NVranya]

(hier is dat dicht gezien dat het ons moet beschermen)

Behalve natuurlijk als je op de boot zit....

[Jessper]

Niet heel relevant voor de discussie, maar mogelijk is dicht gaan niet de beste optie. Over het algemeen is stoppen met bewegen de route om te kiezen. Je kan immers niet weten of er iemand zit op plekken waar de brug beweegt/gaat bewegen. Bij een storing zou ik de burg laten stoppen en afsluiten met slagbomen en alle lichten op rood. Dan mag een monteur komen bepalen hoe het nu verder gaat.

Dat stuk over de Prinses Amaliabrug klinkt eigenlijk als een probleem bij de requirements. Dat iemand gemist heeft dat het nog ergens mee moest communiceren of op een andere manier dan gedacht.

[Reactie gewijzigd door Jessper op 23 juli 2024 00:03]

[Justberry]

Ja klopt zeker dat dicht hier perse niet het beste is, weet niet waarom maar zat met een waterkering in me hoofd ^^
Meestal is er per project ook bekeken wat een veilig modus is in elk geval, daarop moet dan de software gemaakt worden om die modus proberen te bereiken.

Ooit een luchtbehandeling systeem geprogrammeerd (gebruiker wou het in siemens PLC's dus dan doe ik dat maar )
Daar was een leuke tegenstrijdigheid dat bij brand de lucht toevoer naar maximaal moest, maar dit wakkert het vuur natuurlijk aan. Het werd belangrijker geacht de rook weg te blazen voor het personeel dan het gebouw te redden/meer tijd te geven.

[Reactie gewijzigd door Justberry op 23 juli 2024 00:03]

[Justberry]

Tuurlijk vooral niet doen
Maar een groot aantal gebreken in een live systeem hoop ik nooit op te leveren.
Dat in speciale gevallen op een regen achtige dag met volle maan niets gebeurt kan niemand beloven

[Sando]

Het gaat over stuxnet hier. Daar is een documentaire over gemaakt. Is een aanrader.(fff googlen)

Zero Days

[marcelvdk]

Tja Siemens................ De oude S7 gaat wel. De nieuwe TIA portal omgeving...........Ik heb nog geen PLC programmeur ontmoet die daar vrolijk van wordt. Wat een traag pakket zeg. Hopelijk als er i10 processors komen dat het dan een beetje soepel draait. En de updates..........Gelijk een paar GB alsof het niks is. Layout is inconsistent. De ene keer staat button F daar, bij een ander window weer op een andere plek.

Maar ja, Siemens wordt nu eenmaal veel gebruikt. Je ontkomt er niet aan.

[hood]

Ik ben best tevreden met TIA V15. Het is niet zo snel als Simatic maar de structuur in TIA vind ik wel een stuk prettiger.

[marcelvdk]

TIA, soms bij de kleinste aanpassing moet de PLC al in stop. En dat zijn dan aanpassingen die we in de oude S7 omgeving gewoon "on the fly" konden uitvoeren..........

[Justberry]

Ben zelf blij met tia fijne omgeving, kan niet meer terug.
Maar zoals je zegt hebben ze functies verwijderd/veranderd die zeer handig waren.
Multiuser om maar niet over te spreken, eerst weg halen en daarna terug verkopen voor een godsvermogen.

[Step5]

Dan gebruik je 1200s? De 300 en de 1500 hebben daar geen last van, op hoge uitzondering na.

[marcelvdk]

Toch wel hoor. model 1515.

[Step5]

Dan ben ik toch benieuwd welke aanpassingen dat zijn die een stop veroorzaken

[Justberry]

Heb zelf vooral last van de database herinitialisatie. 1 bit aanpassen en alles word gereset, timers enz...
Dit terwijl de het systeem draait kan soms wel rare acties veroorzaken

[Step5]

Dat is wel een dingetje die je niet altijd live kunt doen. In principe is dat bij S7 ook al zo maar wordt dat niet geforceerd wat soms handig is maar ook tegen je kan werken

[bouwfraude]

De Step 7 software is wat onoverzichtelijk. De sourcecode is niet in plaintext. Siemens heeft een conversieprogramma van Step 7 naar de TIA portal maar als je dat geïnstalleerd hebt moet je ook Step 7 nog installeren wat weer om licenties gaat zeuren.
S5 PLC's staan op het punt van overlijden of zijn al dood.
Een S7 heeft erg weinig geheugen en is traag. Een ESP8266 van $4 is vlotter en arduino.cc een stuk beter te doen dan de jaren 60 technieken die Siemens gebruikt.
De TIA portal is traag ook op een i7 en de gebruikers interface schaalt niet mee.
Ik heb wel netjes opgebouwde programma's gezien in de TIA portal maar het niveau wisselt.
Software van WAGO en B&R ziet er wat beter uit.

[Step5]

Your mileage may vary. Aanzienlijk gedeelte van onze machines draait nog S5. Simpele reden: gaat weinig van dood. Dus vanuit management geen reden voor budget om te upgraden.
En Arduino etc. Vergelijken met hardware wat decennia 24/7 betrouwbaar blijft draaien?

Als zo'n type als jij de besturing van de Afsluitdijk gemaakt heeft snap ik het probleem wel ..

[schaduwridder]

De software van Wago is CODESYS 2.3 Of 3. CODESYS 3 is echt een mooie omgeving waarin je nette software kunt schrijven. Ik werk nu 17 jaar in de industriële automatisering en ondersteun daarbij klanten / "programmeurs" en ik kan je wel vertellen dat het echt meestal aan de programmeur ligt als er iets fout gaat. Er zijn er zo veel die het niet goed beheersen. Probleem is ook dat er veel te weinig van zijn.

[marcelvdk]

En toch zijn de S7 PLC's enorm stabiel.... laat ik de MeC serie (Embedded Windows) even buiten beschouwing. Een ESP8266 en Arduino inzetten in een industriele omgeving, dat zie ik niet zo zitten.

Kom veel 400 serie PLC's tegen. Daarvan beginnen nu vooral de voedingen problemen te vertonen. (Tijdje geleden nog, ook nog backup batterij niet vervangen...... poefff weg programma. En aangezien het niet in de buurt was heeft het mij aardig wat inspanning gekost om het op afstand te fixen.)

[bouwfraude]

Het is meer dat een ESP8266 beter te programmeren is en de hardware al een stukje moderner.
Die PLC's doen wat ze moeten doen, alleen de Siemens tools maken het zo moeizaam. We hebben er een paar waarvan je het programma kan bekijken maar daar zit weer een iets groter display bij van Siemens en daar is weer een andere licentie voor nodig. En de siemens displays zijn echt uit het jaar kruik, waardeloos touchscreen, superslecht afleesbaar TF paneel.

[bussie66]

Hebben ze daar wel eens van FAT / GAT / PVT enz gehoord?

Wat een gepruts en wij maar weer betalen....

[TheekAzzaBreek]

Hebben ze daar wel eens van FAT / GAT / PVT enz gehoord?

Wat een gepruts en wij maar weer betalen....

Vast wel, maar dit is procesengineering/instrumentatie. Daar doen ze in principe in validatie, en dat is andere koek dan huis, tuin en keuken ICT'ers (zoals ik) gewend zijn. Bij regulier testen probeer je aan te tonen dat er geen (belangrijke) fouten in zitten. Bij validatie bewijs je dat het systeem precies doet wat het moet doen.

Bovendien: je legt er niet effe een afsluitdijkje naast, om alles eens grondig te testen en misschien een poosje schaduw te draaien. De echte Afsluitdijk platleggen voor testen kan ook maar heel beperkt. Schaduw draaien kan maar een beetje, je kan sensoren en logica testen, maar niet de actuatoren.

Het is geen simpel probleem, zo'n systeem testen.

[Olaf van der Spek]

maar niet de actuatoren.

Schaalmodellen?
Lego?

[Corrit]

Als je daar een waarheidsgetrouwe simulatie mee kunt doen zou dat een prima oplossing zijn lijkt me. Je zou het ook softwarematig kunnen doen natuurlijk, maar lego is wel leuker.

[DJMaze]

Dat is in elke vorm van IT het geval.
Met name omdat veel bedrijven hun ontwikkelaars met 3 jaar ervaring als "seniors" bombardeerd

[Scriptkid]

Een groter problem is dat de project manager en owner vaak niet de juiste requirements opleveren en aan de programeurs kant veel programmeurs er niet goed naar vragen.

Er is een disconnect ontstaan. Als je in mijn klas hebt gezeten de laatste maanden weet je precies waar ik het over heb. Bijna geen van de participanten vraagt zelfs Nadat je net het hele verhaal over requirements hebt gedaan en ze een opdracht moeten doen die aan alle kanten haperd naar de requirements.


Iedereen geeft dan ook meestal al aan dat dat een goede les was.

[Frij5fd]

Ik zag de afgelopen jaren als stakeholder bij een groot RWS project hoe RWS het Bahama model toepaste bij een DBFM-contract. Waarde meer dan een miljard euro, maar amper techneuten die toezicht hielden, omdat de contractenboys in Utrecht bedacht hadden dat het toch allemaal "risico aannemer" zou zijn. Uiteindelijk blijkt het voor het bouwconsortium te complex te zijn en maken ze een astronomisch verlies. En de omgeving heeft het nakijken omdat er regelmatig storingen zijn en delen van de beloofde functionaliteit nog steeds niet gerealiseerd zijn. Nu weer betrokken bij enkele nieuwe projecten; nu zit RWS er wat dichter op. Ze gaan nu een standaard brug besturingssysteem toepassen (als eerste bij de Wantijbrug bij Dordrecht), ik hoop dat ze daar serieus mee meekijken. NB: in de jaren '90 moest 10 jaar na openstelling de klep van de tweede Van Brienenoordbrug al weer vervangen worden; ook weer zo'n voorbeeld van slechte kwaliteit bij een rijksobject

[Reactie gewijzigd door Frij5fd op 23 juli 2024 00:03]

[latka]

En dat hangt dan ook vaak samen met persoonlijkheden: de meeste programmeurs zijn niet van de vragende soort op dit niveau (wel op het niveau van inspringen en welk framework-du-jour je moet gebruiken).

[FreezeXJ]

Er zijn dan ook geen eisen aan 'senior', of 'architect' of uberhaupt 'software ontwikkelaar'. En aangezien detacheerders euros vragen voor het labeltje, promoveren ze mensen al heel snel tot wat het meeste oplevert, en nog net verdedigbaar lijkt.

Controle op kwaliteit is lastig, en met zeemeeuw-management(veel geschreeuw, en als ze opvliegen ligt er alleen nog sh*t) al helemaal onmogelijk. Welkom in de moderne realiteit, die in theorie goed werkt, en in praktijk niet. De regering leeft in theorie, want de praktijk hebben ze geen zicht meer op.

[tonkie_67]

3 jaar? Was ooit senior bij LogicaCMG na 3 weken in dienst, waarvan mn 1e 2 weken cursus was in het software pakket (framework waarmee je netwerk inventarisatie en capaciteit in kaart bracht) waarvoor ik vervolgens implementatie specialist was. Terwijl ik toch echt meer netwerk ontwerper was; geen software developer en zeker niet voor dit systeem. Maar vervolgens wel verantwoordelijk voor ontwikkeling van nieuwe module bij een grote telco...

[demonic]

En deze opmerking toont aan dat je geen flauw idee hebt waar je het over hebt.

Er is zoveel wetgeving waar alles aan moet voldoen. mbt. safety en dergelijke.
Je kan gewoon niet de knop inhouden en dat de brug draait. Daar zijn allemaal procedures voor.

Mensen onderschatten vaak wat er bij dit soort zaken allemaal komt kijken. Er is vaak onbegrip voor, en dat is begrijpelijk. Maar denk er is een beetje logisch over na.


^ Dit sluit overigens niet uit dat dit niet had moeten gebeuren, bij de afname had men gewoon geen goedkeuring moeten geven voor het geleverde product.

[multikoe]

Mensen onderschatten vaak wat er bij dit soort zaken allemaal komt kijken. Er is vaak onbegrip voor, en dat is begrijpelijk. Maar denk er is een beetje logisch over na.

Het zou interessant zijn om eens te zien waar dan precies overal rekening mee gehouden moet worden. In de basis zou het een heel simpel systeem kunnen zijn: die brug moet open kunnen en weer dicht. De brug mag alleen open als de slagbomen naar beneden zijn. De slagbomen mogen alleen open als de brug dicht is. Sensoren koppelen de stand van de brug en de slagbomen terug.

Dan nog wat trammelant-registratie, zoals een detectie of er een auto op de brug staat, of er iemand onder de slagbomen staat, of de motoren wel stroom hebben.

Wat zie ik over het hoofd?

[Theo]

Wat zie je over het hoofd?

Veiligheidshardware om te controleren of de reguliere detectiehardware werkt; en hardware om de veiligheidshardware te monitoren. Qua safety moet hardware de software kunnen overrulen.

Je hebt niet een sensor om te kijken of er iemand onder de slagboom is met een motortje die de slagboom dicht doet. Je hebt een vracht aan sensoren die op meerdere manieren nagaan of de slagboom dicht gaat, dicht is en dicht mag. Die sensoren worden met elkaar vergeleken en daaruit komt of de slagboom dicht is of niet. Maar als één van de tien sensoren een afwijkende waarde geeft; hoe ga je hier dan mee om? (bijv het stroomverbruik van de electromotor ten tijde van het dichtgaan van de slagboom die buiten een bepaalde range valt) Gaat het systeem dan in een error modus totdat het gereset wordt door een monteur? En hoe gaat het in error modus? blijft de slagboom dan half dicht/open; of gaat het naar een van te voren gedefinieerde errorpositie? En hoe kan deze dan bediend worden terwijl niet alle sensoren betrouwbaar zijn? Wat voor signaal wordt er naar de operator gestuurd over de slagboompositie?

En dit is enkel nog maar één slagboom..

[MSalters]

Veiligheidshardware om te controleren of de reguliere detectiehardware werkt; en hardware om de veiligheidshardware te monitoren.

Tja, dat is vragen om problemen.

Ikzelf heb recent gewerkt aan medische systemen, en daar zijn de eisen zo mogelijk nog hoger. Onze recentste ontwikkeling daar was een twee-laags systeem. De controle-laag was opzettelijk simpel, en kon mede daardoor zichzelf controleren.

Complexiteit is namelijk het grootste risico. Hoe complexer het systeem, hoe groter het aantal mogelijk storingen, en hoe moelijker het is om de exacte storing vast te stellen. Ons controle-systeem wist daarom maar weinig af van het gecontroleerde systeem. De controle was of het bewaakte systeem werkte; diagnoses stellen was mensenwerk. Het enige wat er bij een storing automatisch gebeurt is de switch naar een fail-safe backup modus.

[Tjerk.g.visser]

En toch is dat wel wat er op PLC gebied gebeurd. Een Safety PLC heeft hardware die zelf kan monitoren of bijvoorbeeld twee aangesloten sensoren binnen een vastgestelde tijd het zelfde signaal geven en dat blijven doen. Zo niet dan treedt er een hardwarefout op in de PLC en zal het programma stoppen.
Aan de hand van de elektrische installatie kan dan een veilige situatie gekozen worden. Welke actuatoren sluit je normally open of normally closed aan? Moet een motor bekrachtigd worden gestopt of mag deze uitlopen?

In het geval van een hefbrug wordt zelfs de kracht die nodig is om het brugdek te heffen in de gaten gehouden. Als het koppel op de motor te hoog wordt dan zal de beweging stoppen en moet er inderdaad een monteur komen om het systeem in rust te brengen (lees met de hand het brugdek laten zakken met een zwengel) en de besturing te resetten.

[multikoe]

Ik had duidelijk niet lang genoeg nagedacht.

[P_Tingen]

Wat zie ik over het hoofd?

Ik mocht ooit in een fabriek een programma maken om kisten te wegen die via een lopende band over een weegschaal schuiven en niet stilstaan. Hoe moeilijk kan het zijn?

De theorie: gewicht wat de schaal doorgeeft neemt toe naarmate de kist verder op de weegschaal schuift. Als de kist er helemaal op staat is het gewicht stabiel. Als het afneemt, weet je dat de kist eraf schuift en heb je het gewicht van de kist.

De praktijk: Kist schuift erop, weegschaal zegt achtereenvolgens: 100gr, 200gr, 180gr, 290gr, 285gr, 330gr, 340gr, 370gr, 300gr, 310gr, 220gr, 100gr, 110gr, 10gr.

Het resultaat:Ik heb met eigen ogen 1 kist over de weegschaal zien gaan. Mijn software zegt echter dat het 5 kisten heeft gezien van achtereenvolgens 200gr, 290gr, 370gr, 220gr en 110gr

En dit is nog maar een simpele weegschaal

[Basjuh84]

Ik werk zelf ook in een fabriek, en dit is wat mij betreft dan ook typisch een probleem waarvan de IT oplossing (exact zoals hier beschreven) in de ‘echte’ wereld dus nooit werkt. Ik maak dit zo vaak mee (en vrijwel altijd pas te zien in de testfase). Het is een bijzonder complex (maar ook leuk) proces om vanuit een Engineerings-rol te praten met IT / automatiserings collega’s. En wij als engineers hebben er dan vaak een handje van om de technische zaken / hardware erg complex te maken, omdat de ‘software’ het wel oplost. Ik vermoed dat dat bij een brug net zo gaat (maar dan zitten de verschillende afdelingen vast niet onder één dak).

[bouwfraude]

Een oogje (sensor) toevoegen op de band om te kijken of er wat staat?

[P_Tingen]

Nee, het probleem was dat een band niet 100% stabiel is, waardoor de kist dus een beetje 'stuitert'. De oplossing was werken met drempelwaardes; steeds de hoogste waarde onthouden en pas als de waarde ónder een bepaalde drempel komt aannemen dat de kist voorbij is. De drempel stel je dan in op bv de helft van het te verwachten gewicht.

[FreezeXJ]

Stap 1: definities. Wat is "open", wanneer is dat het geval, en waar zit de grens tussen open en dicht?
Stap 2: trammelant: ja je kunt detecteren of er een auto op de brug staat, maar wat doe je dan als er een eend staat? Of een voetganger? Of een vuile sensor? Of... Voila.
Stap 3: testen. Slagbomen mogen alleen open als de brug dicht is. Mooi. Testbaar. Maarrr... is de brug dicht als de sensor dat zegt? Is ie dan wel echt dicht? Weet je het zeker? OK. Toch fout, de sensor loog. En de backup is uitgevallen, dus nu is de brug stuk. Sorry!

[Grrrrrene]

Stap 1: definities. Wat is "open", wanneer is dat het geval, en waar zit de grens tussen open en dicht?

Open is als de brug niet rust op de fundatie aan de niet-scharnierende kant (in het geval van een ophaalbrug).

Stap 2: trammelant: ja je kunt detecteren of er een auto op de brug staat, maar wat doe je dan als er een eend staat? Of een voetganger? Of een vuile sensor? Of... Voila.

Een eend is niet boeiend, een mens wordt gezien op de beveiligingscamera's die er volgens mij gewoon al hangen en een vuile sensor moet je voorkomen door de sensor te beschermen, bijvoorbeeld door hem op het bewegende deel te monteren, zodat er geen sneeuw, ijs, regen, troep van auto's, etc op kan vallen. Dat soort kritieke dingen voer je wellicht ook dubbel of driedubbel uit. Het is geen rocket science Dit soort dingen vang je af door in je ontwerpfase een FMEA te doen waarbij je alles wat redelijkerwijs fout kan gaan in kaart brengt en maatregelen neemt om de gevolgen te beperken tot een acceptabel niveau.

Stap 3: testen. Slagbomen mogen alleen open als de brug dicht is. Mooi. Testbaar. Maarrr... is de brug dicht als de sensor dat zegt? Is ie dan wel echt dicht? Weet je het zeker? OK. Toch fout, de sensor loog. En de backup is uitgevallen, dus nu is de brug stuk. Sorry!

Wat is de kans dat beide sensoren op exact hetzelfde moment kapot gaan? Ik denk verwaarloosbaar klein. Hier is heel wat anders aan de hand. En ja, met goede sensoren en backups weet je zeker dat hij dicht is of in ieder geval weet je op enig moment dat de sensoren het niet met elkaar eens zijn. Dan stuur je daar een mannetje naar toe om de defecte sensor te vervangen en laat je zo'n situatie niet sinds 2016 aanmodderen

[FreezeXJ]

Maar als ie 'open' staat kan ie ook 'net open' zijn, waardoor er nog geen boot doorkan. Die hanteren dus een andere definitie van 'open', namelijk dat het brugdek verticaal staat...

Overigens is het prima te doen om nu te bedenken wat er allemaal nodig is, maar dan alsnog... krijg je dit...

[To_Tall]

correctie "schip"

Er speelt veel meer dan alleen een brug. het is een sluis, met brug deel.
Een brug kan nooit geopend worden, als de slagbomen niet een signaal terug geven dat ze omlaag staan. de definitie van open is dat alle veiligheid onderdelen. verkeerslichten, slagbomen, enz op safe staan. == brugdeel gesloten en vrij gegeven.

Volgende stap is dat de bedienaar visueel moet controleren of het brug deel vrij staat. Niet dat er een auto met pech op het brugdeel staat of nog fietsers onder de slagboom doorlopen.

Pas dan en alleen dan, mag de brug geopend worden. Schip kan binnen varen.

Echter we hebben nog een facet.. het is een sluis. ook hier zijn tientallen PLC's die verschillende onderdelen controleren en terug melden aan de bedienaar. water druk, water hoogte, schutlijn, verlichting enz enz..

Alles moet perfect werken.

Probleem is alleen. bedienaar is nu fysiek op de sluis aanwezig. Die moet daar weg, naar een centraal punt verhuizen. als systemen niet altijd de goede waarden doorgeven. Dan mag de brug/sluis niet op afstand bediend worden. dan moeten er toch echt fysiek op de sluis aanwezig zijn voor visuele checks.

Is de bediening van het object veilig? Ja is het veilig genoeg om op afstand te bedienen nee.

[Grrrrrene]

Maar als ie 'open' staat kan ie ook 'net open' zijn, waardoor er nog geen boot doorkan. Die hanteren dus een andere definitie van 'open', namelijk dat het brugdek verticaal staat...

@Theo had het erover dat de slagbomen dicht moeten voor de brug open mag. Daarop reageer jij "wat is open". Ik leg daarom uit wat "open" is in relatie tot de slagbomen. Voor het verkeerslicht (?) dat er voor schepen is aangebracht aan de zijkant van de brug heb je inderdaad een andere definitie van open. Ik zie niet helemaal waarom dat een probleem zou zijn. Echt complex is dit niet.

Overigens is het prima te doen om nu te bedenken wat er allemaal nodig is, maar dan alsnog... krijg je dit...

Ik snap wat je wil zeggen, maar de fouten die hierboven genoemd zijn vallen wat mij betreft niet in de categorie "we hebben over het hoofd gezien wat de gebruiker allemaal fout kan doen". Het systeem is ook niet zo complex als sommigen willen doen geloven. Maar dat is mijn punt nog niet zozeer: ik snap werkelijk niet waarom er zo lang voor nodig is voor er iets aan gebeurt. De problemen zijn zo te lezen al jaren bekend. Dat klinkt meer als een gevalletje: niemand wil zijn/haar verantwoordelijkheid nemen.

[Reactie gewijzigd door Grrrrrene op 23 juli 2024 00:03]

[latka]

"Open is als de brug niet rust op de fundatie aan de niet-scharnierende kant (in het geval van een ophaalbrug)." is wel wat smal: de boot moet er ook nog onderdoor passen, dus op welke openstand gooi je het groene licht voor de scheepvaart aan?

[supersnathan94]

Daarom heb je in dit soort scenarios altijd semantische context die beschrijft wat de definitie is.
Voor het verkeer op de brug is de brug afgesloten/niet toegankelijk als het niet scharnierende punt geen contact heeft met de basis.
Voor het verkeer onder de brug is de brug afgesloten/niet toegankelijk als het niet scharnierende punt geen contact heeft met een sensor die ergens op een paal in de lucht hangt.

[To_Tall]

schip krijgt alleen groen licht, als het brugdeel vergrendeld open staat.
Bij brugdeel gesloten is alleen als de brug vergrendeld staat en de slagbomen opgehaald zijn.

in alle andere tussen standen. staat het licht voor de weg gebruiker en het schip altijd op rood.

[Rolfie]

at is de kans dat beide sensoren op exact hetzelfde moment kapot gaan? Ik denk verwaarloosbaar klein.

Maar dat kan een mega schadepost opleveren of misschien zelfs een dode. En wie is er dan aansprakelijk?
Wat als door bijvoorbeeld inductie velden de sensor niet altijd goed werkt?=> Storing. Brug moet gerest worden. Maar de status van diverse onderdelen kan onbekend zijn. De uitzonderingen maakt het altijd zo complex.

Werkelijkheid is altijd een stuk complexer als je er verstand van hebt.

[Tjerk.g.visser]

[...]
Maar dat kan een mega schadepost opleveren of misschien zelfs een dode. En wie is er dan aansprakelijk?
Wat als door bijvoorbeeld inductie velden de sensor niet altijd goed werkt?=> Storing.

En precies die afweging is in het ontwerp van de machine (in dit geval een brug) opgenomen. Dat noemen we hier SIL en is beschreven in de IEC 61508. Afhankelijk van een aantal aannames en berekeningen, bijvoorbeeld de kans dat iemand komt te overlijden door onjuist functioneren van de machine, wordt een veiligheidsniveau geselecteerd. Vervolgens moeten alle sensoren en andere hardware aan dat niveau voldoen. Let op, dat ieder afzonderlijk onderdeel SIL2 is wil niet zeggen dat alles bij elkaar dat ook is. Daar zitten allemaal berekeningen aan vast.
Bij een spoorbrug waarbij de kans op zwaar lichamelijk letsel, dan wel overlijden, van meerdere personen een reëel gevaar is bij een storing moet de volledige besturing SIL3 zijn uitgevoerd.
Er zitten dan al twee sensoren op het brugdek die beide gelijktijdig de zelfde status moeten geven (en dat zal een 'waar' signaal zijn in rust) om de brug als dicht aan te merken.

Bij de bruggen in de afsluitdijk zit het probleem denk ik niet in de daadwerkelijke besturing van de brug maar in de bediening op afstand. Het scherm dat de brugwachter ziet laat een andere status zien dan waar de besturing zich in bevind.

[multikoe]

Werkelijkheid is altijd een stuk complexer als je er verstand van hebt

Dat is waar, maar het zijn vaak de mensen die er geen verstand van hebben die de werkelijkheid complexer maken

Ik postte in mijn naïviteit een vraag waarom een in de basis zo'n simpel systeem als een brug zulke complexe software aansturing nodig heeft. De antwoorden zijn allemaal waar maar de conclusie is dan dus dat een in wezen simpele mechanische constructie door externe eisen onvermijdelijk een "systeem" wordt met ironisch genoeg alle risico's die daaraan verbonden zijn.

[WillySis]

Je hebt het hier niet over een brug, maar een over een complex met bruggen, sluizen en spuien met een waterkerende functie.
Alles is zwaarder uitgevoerd dan normaal en de combinatie maakt het niet gemakkelijk. De brug is pas echt dicht als deze geborgd is. In dit geval vermoedelijk niet alleen aan de vrije kant, maar ook aan de scharnier kant. De borging mag pas uit als het wegdek is gesloten. Mogelijk zit er ook nog een koppeling met de sluis dat deze allemaal aan minimaal één kant gesloten zijn. Omdat het waterpijl variabel is heb je het ook over 3 of 4 paar deuren per sluis. Kortom je hebt al snel met een hele massa sensoren te maken die in een omgeving moeten werken die niet echt vriendelijk is. De kans dat een sensor kapot gaat of door water en vuil een foutieve waarde doorgeeft is heel reëel. Dat kan meerdere malen per jaar gebeuren. Als het door externe factoren wordt veroorzaakt is de kans dat ook de backup sensor storing geeft niet te verwaarlozen.

De bruggen krijgen het ook best zwaar te verduren. Bruggen zien er niet zo ingewikkeld uit, maar zeker zo'n complex als in de Afsluitdijk is een behoorlijk stuk ingewikkelde techniek op een techniek onvriendelijke plek. Dat wordt door de meeste mensen behoorlijk onderschat.

[zaphod_b]

Ik heb nu een paar reacties gelezen en ik word nu al moe van de betweterige toon van een stel PLC-programmeurs hier. Sorry hoor, ik snap dat jullie trots op je werk zijn en dat mag ook, maar laten we hier niet gaan doen alsof jullie met rocket-science bezig zijn. Je kunt hier hele interessante semantische discussies voeren, ik begrijp dat "open" afhangt van je definitie enzo, maar laten we wel realistisch blijven. PLC's zijn er al decennia en ik vind het niet gek dat mensen raar opkijken als dat verdorie nog steeds niet werkt...

Natuurlijk is dit soort software wat anders dan een Windows-applicatie maar dit soort toepassingen zijn echt niet de enige waarbij fouten niet getolereerd worden. Wel eens van banken gehoord? Dat zijn minstens zo complexe applicaties en ik durf wel te wedden een stuk complexer en ook zeer kritisch. Wellicht niet *direct* levensbedreigend... maar probeer je eens in te denken wat er gebeurt in een grote stad als Amsterdam als je 3 dagen niet kunt pinnen.. Juist ja: rellen en voedselplunderingen.

Kortom: prima dat je vertelt dat het ff wat lastiger is dan domotica thuis of een windows-app, maar even wat minder interessant doenerij mag ook wel hoor.

En dan over die bruggen: sorry maar ik vind het anno 2019 ronduit bezopen dat dit nog zo moeilijk moet zijn. En als ik dan lees dat Siemens kennelijk krakkemikkige rommel verkoopt maar ja het wordt zoveel gebruikt (klinkt alsof de managers op de golfbaan weer eens een mooie "deal" hebben gesloten met de grote jongens...)...

Je zou toch mogen verwachten dat op een gegeven moment dit soort systemen wel uitgedokterd zijn. Maar sja, dat is kapitalisme: dan kan de fabrikant niks meer verkopen dus moet er "vernieuwd" worden en krijg je telkens weer nieuwere en "betere" systemen..

Wellicht ben ik wat negatief, maar ik kijk er met verbazing naar.

[tonkie_67]

Dat verhaal van de banken klopt wel, maar daarom draaien daar regelmatig applicaties die soms al decennia in gebruik (& doorontwikkeling) zijn. Nog maar paar jaar terug gigantische problemen toen RBS de boel moderniseerde en alle opgekochte dochterbanken "om" moesten op dit super en door en door geteste nieuwe systeem. Resultaat: duizenden mensen dagenlang zonder geld, incassos en periodieke betalingen niet gedaan (met als verder gevolg de bank klanten in problemen). Wees blij dat de particuliere tak van abn*amro niet door hen werd overgenomen in2k7..
Idd niet alleen plc systemen zijn lastig, maar ook in puur softwarematige systemen gaat het vaak genoeg mis.
En de vele mislukkingen in "puur software" zijn er legio, maar dan flikkert er geen brug omlaag of loopt t ijsselmeer niet leeg.

[zaphod_b]

Oh er worden overal fouten gemaakt. En ik was een tijdje betrokken toevallig bij die splitsing en ik kan je vertellen dat het een idioot complexe operatie is geweest. Ga maar eens uitzoeken wat van welke systemen precies van ABN AMRO is en welk deel van RBS als het tot voor kort 1 bank was... Niet te doen. Natuurlijk is het vet beroerd dat er dingen mis zijn gegaan maar gezien de enorme opgave vind ik eigenlijk dat het mee is gevallen .

En wat je zegt over applicaties die al decennia werken, dat is helemaal waar. En dat zouden we dus met kritische infrastructuur ook moeten doen, zoals bruggen en sluizen. Maar sja, de overheid moet tegenwoordig Europees aanbesteden. Dat is op zich prima, maar er wordt bij veel overheden veel te licht over gedacht en dus koopt men verkeerd in. Dan zit je dus voor een duppie op de eerste rang en krijg je dus allerlei shit. Een voorbeeld: de kustwacht (marine) had nieuwe heli's nodig voor SAR (Search and Rescue) omdat de oude Seakings echt veel te oud werden. Er is aanbesteedt en een Italiaans bedrijf had gewonnen. Die gingen dan een heli leveren die totaal niet geschikt is voor SAR en die zouden ze dan effe ombouwen zodat 'ie wel geschikt zou zijn... En uiteraard goedkoop en sja volgens de aanbesteding voldeden ze aan de eisen... In de realiteit was het kreng niet geschikt, was er voor miljoenen meerwerk nodig en noemden ze dat ding bij de Kustwacht "de vliegende Fyra"... Need I say more .

[MWDKing]

De problemen die hier optreden zijn zeker niet te wijten aan de standaard hardware producten van het besturingssysteem (bijv. Siemens). De gebreken zullen zitten in o.a. de software die de programmeurs op het platform laden, de toegepaste sensoren en de strenge faaldefinities voor de veiligheid (een veilig brug of sluis is een dichte sluis). Je kan ook moeilijk Microsoft Word de schuld geven als je een slechte brief typt....
Overigens maakt Siemens zelf ook software voor dergelijke infrastructuur, maar in dit geval is dat niet zo.

[Patriot]

Stap 3: testen. Slagbomen mogen alleen open als de brug dicht is. Mooi. Testbaar. Maarrr... is de brug dicht als de sensor dat zegt? Is ie dan wel echt dicht? Weet je het zeker? OK. Toch fout, de sensor loog. En de backup is uitgevallen, dus nu is de brug stuk. Sorry!

Even uit interesse: Wat doe je daar dan tegen? Uiteindelijk komt het toch neer op meerdere sensoren, als ze overeenkomen is het goed en anders "storing" (met een eventuele tolerantie)?

[MSalters]

Het is een opzettelijk zwart scenario; een uitgevallen sensor en de backup die daardoor een Single Point of Failure is geworden. De normale procedure is dat je de defecte sensor vervangt. Als dan toch de backup sensor faalt, dan kun je als verantwoordelijk wegbeheerder in elk geval melden dat de monteur al onderweg was voordat de storing zichtbaar werd. Nog steeds vervelend, maar niet meer dan dat.

[APClll]

Wat zie ik over het hoofd?

Ik vermoed dat 't probleem niet in de bediening op zich zit, maar in de "afstandsbediening" dus dat op afstand de status 100% betrouwbaar moet zijn. Brugwachters die zelf uit het raam kijken worden steeds zeldzamer, alles moet dus via sensoren en camera's.

Als ik het bericht goed lees, is er geen garantie dat een brug die bijna dicht lijkt, maar nog niet vlak/veilig is, al dan niet onterecht toch als veilig wordt gesignaleerd. En op een camera is die laatste paar cm niet te zien, je zult "blind" op de sensoren moeten vertrouwen. Of op de sensor die de sensor controleert. Maar ook of een motor werkelijk draait, gestopt is, etc.

[Reactie gewijzigd door APClll op 23 juli 2024 00:03]

[supersnathan94]

Op een camera is die laatste paar CM prima te zien afhankelijk van waar je de camera plaatst. Daarom heb je er vaak ook meer dan 1.

1 om te kunnen zien of er niemand overheen loopt en of het ding helemaal open staat of niet. En
1 om te kunnen zien of die laatste 2 CM ook netjes is gegaan.

[Olaf van der Spek]

Wat zie ik over het hoofd?

Alle mechanica?
Integratie daarvan met de besturing?
Wat doe je als een slagboom niet helemaal dicht gaat? Niet helemaal open?
Met zo'n woonplaats had ik toch wel iets meer verstand van de materie verwacht.
Ik heb er overigens ook geen verstand van maar kan best begrijpen dat zoiets enorm complex is.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 00:03]

[multikoe]

Met zo'n woonplaats had ik toch wel iets meer verstand van de materie verwacht.

Wij hebben een ondertussen beruchte pontonbrug in de buurt die er de afgelopen jaren meerdere keren heeft uitgelegen. Oorzaak: hardware

[multikoe]

Met zo'n woonplaats

Oeps

[TheekAzzaBreek]

[...]
Wat zie ik over het hoofd?

Het verkeer over water.
Minimale en maximale openingsduur van de brug.
Maximale windsterkte waarbij de brug open mag.
Het netwerk dat 100% up moet zijn.
Dat alles meervoudig moet zijn uitgevoerd, en je iets moet kunnen besluiten als je tegenstrijdige signalen krijgt.
Dat het praktisch onmogelijk moet zijn de boel te hacken.
Dat je moet kunnen signaleren dat allerlei verschillende soorten componenten dringend onderhoud nodig hebben.

Daar heb ik niet lang over hoeven denken, en ik ben een volslagen leek. De lijst met eisen voor zo'n systeem is ongetwijfeld lang.

[TheVivaldi]

Kunnen ze niet beter terug naar de ouderwetse methode, namelijk met de hand open en dicht? Ik weet dat dat nu wat lastig is, maar bij de volgende grootschalige werkzaamheden zouden ze de sluizen zo kunnen bouwen dat met de hand bedienen mogelijk is, net als vroeger. Hetzij altijd met de hand, hetzij als alternatief voor als de software hapert.

[ckr]

Met de hand als met een slinger is erg omslachtig, maar met relatief eenvoudige en super-betrouwbare relaistechniek moet het ook kunnen. Gewoon lampjes die gaan branden op een bord.

Iets ingewikkelder: bovenstaande schakeling omzetten naar PLC. Nog steeds heel betrouwbaar mits je niet van alles gaat toevoegen wat weinig met de basis-functionaliteit te maken heeft. Daar kun je dan je afstandbesturing(-software) op aansluiten, maar dat moet je dus ook heel betrouwbaar maken.

Overigens zijn er volop bedienbare bruggen die wel prima functioneren, dus het kan zeker wel. Mijn vermoeden is dat er is aanbesteed met meer focus op prijs dan op kwaliteit. Dan kun je geluk hebben en een prima product krijgen maar je kunt ook een keer koekenbakkers krijgen die een product maken dat er op het eerste oog wel prima uitziet maar als je echt doorprikt een rommeltje is. Ik spreek uit ervaring.

[TheVivaldi]

Als het omslachtig is met de hand, hoe deed men dat vroeger dan, vóórdat er computers waren? Gingen sluizen toen helemaal niet open of zo?

Maar ben wel met je eens dat relais ook een prima alternatief zou zijn.

[Reactie gewijzigd door TheVivaldi op 23 juli 2024 00:03]

[bouwfraude]

Dat ging met een brug- of een sluiswachter. Daar was het brugwachtershuisje voor.

[TheVivaldi]

Dat kan dan toch gewoon weer opnieuw worden ingevoerd, al was het maar als back-up voor als de software hapert?

[Soldaatje]

Ik moet je de bron schuldig blijven maar ik heb begrepen dat een van de waterkeringen juist automatisch dichtgaat bij hoog water, zodat er niet een nerveuze bediener met zijn huis achter de kering de boel voor de zekerheid maar vast dichtgooit.

[MWDKing]

Zo worden ze ook nog steeds ontworpen: noodbediening met spierkracht moet nog mogelijk zijn volgens de landelijke RWS kaders voor bruggen en sluizen.

[TheVivaldi]

Maar het lijkt erop dat ze daar bij de Afsluitdijk dus geen gebruik van maken, raar dan...

[jochem4207]

Ja bizar en niemand die weet hoe het komt, hardware debuggen kan erg lastig zijn maar moet toch te doen zijn.

[Sharkoon]

Ik mis bij ifttt dat je alleen maar 1 if hebt en verder niks. Als het uitgebreider zou zijn dan kunnen sluizen ermee bedient worden.

[rvt1]

Niet echt omdat het met het internet verbonden zit.

Maar dan nog, wie garandeert ons dat IFTT precies doet wat je verwacht?
Vaak zit je met timing problemen waarmee je te maken hebt en dus ook juist moet oplossen. IFTT is daar totaal niet geschikt voor omdat het geen garantie kan geven van respons, reactie en fail safe situaties.

[Juantinto]

Haha. Heel goed dit. En dan zeker de Philips Hue lampen van de buurman erbij prikken om groen aan te laten gaan als de brug open gaat.

[Tjerk.g.visser]

Zo'n brug programmeren is zo simpel als wat, je moet alleen geen prutsers hebben, en geloof mij, het type programmeur dat dit soort zaken bouwt programmeert in de regel helemaal niet, maar configureert,

Een frequentie omvormer (ooit van gehoord?) kun je configureren. Een PLC die een brug moet besturen, configureer je niet even. Daar gaat eerst een paar maand software ontwerp aan vooraf en het ontwerp moet worden goedgekeurd door een externe partij. Dan mag je gaan programmeren. Jij niet, iemand die er wel verstand van heeft..

in hele rare gare software die niemand begrijpt en wat heel buggy aanvoelt.

Ga er voor het gemak even van uit dat er Siemens PLC's zijn gebruikt, dat is vrij standaard spul, die programmeer je tegenwoordig met TIA Portal. Dat heeft nu en dan z'n nukken, maar "raar, gaar en buggy" zou ik een pakket wat al jaren door Siemens wordt ontwikkeld en in de helft van de wereld wordt toegepast niet willen noemen...

Testen is ook prima te doen zonder echte brug, en ik geloof niet dat je in testen niet alle voorkomende situaties kunt afvangen.

Ja, tuurlijk kan dat. Alleen jammer dat je nooit de exacte eigenschappen van de mechanica kunt simuleren. Eigenschappen die voor iedere brug uniek zijn. Plaatsing van sensoren die je van te voren niet precies weet maar wat wel belangrijk is.
Ideaal ook dat een PLC vaak alleen hardware IO heeft. Die in het geval van een brug failsafe is uitgevoerd.
Met een paar knopjes op een HMI kom je een heel eind, maar als je hier met droge ogen beweert dat jij in C volledig gesimuleerd een brug kunt programmeren heb ik een baan voor je.

[Rolfie]

Gelukkig weten we ook dat jij deze software niet geschreven hebt. Dan had de brug namelijk helemaal niet gewerkt.

Dus nee ik vraag het je niet om in C te schrijven. Ik wil graag namelijk nog veilig over bruggen kunnen rijden. En vraag mij niet waarom, maar ik heb het gevoel dat jij geen enkel idee hebt hoe complex dit soort materie is....

[SPee]

Wie heeft die systemen geleverd?

[biteMark]

Waarschijnlijk Capgemini, die doen bijna alle grote software opdrachten voor de overheid

[MSI2]

Echt een misser dat dit soort bedrijven de opdrachten krijgen. Stevige bureaucratie binnen deze bedrijven waardoor de vrijheid om innovatieve afwijkende oplossingen te bedenken vaak beperkt is. Om nog maar te zwijgen over de tarieven die deze clubs rekenen omdat ook de irrelevante managers dik betaald moeten worden.

Overigens kan het ook dat een partij als CroonWolter&Dros dit hebben gemaakt.

[Reactie gewijzigd door MSI2 op 23 juli 2024 00:03]

[EddoH]

Volgens mij gaan dit soort dingen altijd via een Europese aanbesteding? Wellicht dat Cap ondertussen wel heel goed weet hoe zie die moeten winnen

[bazs2000]

Klopt, dit lijken veel mensen altijd te vergeten. Cap spint er garen bij maar soms zou ik willen dat Cap eens niet een opdracht zou krijgen maar een wat kleinere partij.

Zodra je op het vlak van een Europese aanbesteding komt zijn er meestal niet zoveel spelers die de klus kunnen klaren. Als ik kijk naar mijn huidige werkgever dan zijn er inmiddels al heel wat projecten mislukt omwille van de regels.

In de basis is een Europese aanbesteding prima alleen zijn er situaties waarbij je liever wat 'vrijelijker' kunt kiezen. Overheid en ICT lijkt altijd de combinatie water en vuur maar men moest eens weten wat voor wetten, regels en andere zaken gevolgd moeten worden voordat een project kan worden opgezet. En als er éénmaal een 'winnaar' is dan loopt het vaak stroef omdat de 'winnaar' niet altijd even helder is op het vlak van kosten.

Maar goed, dit was lang geleden al zo, over 10 jaar verwacht ik niet anders en dat is jammer.

[FreezeXJ]

Tja, om mee te doen voor dit soort opdrachten moet je voldoende betaald hebben voor accreditatie, certificatie (50k per certificaatje is niks geks, elk jaar weer, en daarvan moet je er 6 hebben voor je een risicovol product als een brug mag aansturen). Verder moet je de beste ambtenaar al eens bij de golfclub ontmoet hebben zodat hij weet dat je wel echt een mooie deal kunt maken, en moet je ook alle rare randvoorwaarden kennen die opgesteld zijn in het contract, en dat gaat makkelijker als je ook de adviseur kent die de voorwaarden opstelt.
Met al die gekke eisen zijn er maar een paar bedrijven die groot genoeg zijn. En ja, die zijn lomp inefficient, maar dat kan, want ze berekenen allemaal de volle mep voor hun diensten. Goedkopere concurrentie is er niet, want die voldoet niet aan de eisen.

[Bas_f]

Precies dat. En als je al die shit op orde hebt, maar je omzet loopt nog niet in de vele miljoenen, dan kun je het alsnog vergeten. Terwijl juist de kleinere bedrijven deze software uitermate goed kunnen schrijven, omdat ze echt hun best willen doen voor de opdrachtgever. Capgemini zal het geen moer uitmaken dat ene contractje meer of minder.

[MSalters]

Verder moet je de beste ambtenaar al eens bij de golfclub ontmoet hebben zodat hij weet dat je wel echt een mooie deal kunt maken,

Dat is hoe het in het bedrijfsleven werkt. De hele aanbestedingsprocedure van de overheid is nu juist om dit uit te sluiten. En het idee van "gun het ook eens aan een klein bedrijfje"? Vraag het eens aan het Openbaar Ministerie. Daar hebben ze nu een schandaal dat regelmatig projecten onder de aanbestedingsgrens ondehands naar familie-leden geschoven zijn. Ja, die hadden inderdaad een klein bedrijfje. Dat maakt ze niet meer geschikt.

[WimmieV]

Vraag:
"Wie heeft die systemen geleverd?

Antwoord:

Waarschijnlijk Capgemini, die doen bijna alle grote software opdrachten voor de overheid

Ach, doe maar een gok...
En dat is dan ook nog on-topic voor een aantal lezers 🤔

[Falcon]

Dit betreft niet alleen de sluizen van de Afsluitdijk:

http://m.binnenlandsbestu...gingsupdates.205563.lynkx (2017)

Iets meer detailinformatie voor ons.

[Reactie gewijzigd door Falcon op 23 juli 2024 00:03]

[seacat]

De zelfde software ontwikkelaar als bij de Ketelbrug?
https://www.omroepflevoland.nl/dossier/ketelbrug#1

[Reactie gewijzigd door seacat op 23 juli 2024 00:03]

[Geim]

Misschien gewoon weer een brugwachter bij elke brug invoeren?

[bArAbAtsbB]

maar waarom moeten er voor het repareren van de software de sluizen en bruggen gestremd worden? kan men die bugs niet in een testomgeving repareren? wat een faal is dit...welke kneus heeft deze software gemaakt dan? er moet toch een testomgeving zijn om dit soort zaken te testen...hoe heeft men anders deze software kunnen maken? met een natte vinger dus.

[MWDKing]

Dat gebeurt ook zeker in een testomgeving, maar je zal om aan te tonen dat het echt "veilig" is dat ook in het echt moeten doen. Alleen daarna mag volgens de wet de "machine" in gebruik worden genomen.

[Morress]

Er gaat wel meer mis daar.
Brugdekken koelen met zout water (!!!)
Op 1 rit voor beide bruggen stilstaan omdat men draait wanneer men wilt.
Brug draaien voor jan met de korte achternaam.

Kom daar elke werkdag 2x langs, echt feest bij tijden