Rijkswaterstaat wil met nieuwe methode tijd besparen bij softwareontwikkeling

Rijkswaterstaat gaat een nieuwe methode gebruiken voor de ontwikkeling van software van beweegbare bruggen en sluizen, die de organisatie veel tijd moet besparen. Het gaat om synthesis-based engineering, of sbe, dat met TNO-ESI en de TU/e is ontwikkeld.

Bruggen en sluizen kennen nogal wat risico's als ze niet goed aangestuurd worden. Een verkeerd aangestuurde brug kan bijvoorbeeld opengaan terwijl er nog auto's overheen rijden. Om dergelijke situaties te voorkomen stelt Rijkswaterstaat, of RWS, besturingseisen op waaraan de besturingssoftware moet voldoen. De software wordt vervolgens ontwikkeld door marktpartijen.

Voortaan gaat de organisatie bij de renovatie van bruggen en sluizen standaard de sbe-methode inzetten, dat een deel van het werk automatiseert. Waar engineers eerder nog meer zelf moesten nadenken hoe een besturingseis kan worden omgezet in logica die de software kan uitvoeren, wordt die logica nu automatisch gegenereerd. "Het synthesealgoritme rekent op een slimme manier alle mogelijke situaties door, soms vele miljarden, en garandeert dat de gegenereerde besturingslogica in al die situaties aan de besturingseisen voldoet", legt Dennis Hendriks, onderzoeker bij TNO-ESI, uit op de website van TNO. "Vervolgens kan door middel van simulatie het systeemgedrag worden gevalideerd en met codegeneratie automatisch de implementatie worden gemaakt.” Op die manier moet het ontwikkelproces sneller en efficiënter verlopen.

Deze methode stelt RWS in staat om in een vroeg stadium alle belanghebbenden mee te nemen in het ontwerp. "We kunnen bijvoorbeeld aan assetmanagers en bedienaars laten zien hoe het object uiteindelijk zal werken, via simulaties en visualisaties. Dat scheelt in latere fasen veel tijd", licht Harry Lammeretz, programmamanager bij RWS, toe. De methode zorgt er verder voor dat er sneller aanpassingen gedaan kunnen worden en er is tijdens de aanbesteding mogelijk minder afstemming met marktpartijen nodig.

RWS werkt al enige jaren met TNO en Technische Universiteit Eindhoven samen aan de methode. Ook zijn er al een aantal pilots geweest, waarbij sbe in de praktijk werd ingezet. Nadat deze succesvol bleken, werd besloten sbe standaard te gaan gebruiken bij de renovatie van bruggen en sluizen om de besturingseisen scherp te krijgen voor aanbestedingsdossiers. De opgestelde modellen worden meegeleverd bij de aanbesteding. In de toekomst wordt sbe mogelijk ook bij andere projecten gebruikt. Ook wordt verdere automatisering verkend, zoals codegeneratie.

De methode is volgens TNO niet alleen voor RWS en andere infrastructuurpartijen interessant, maar ook voor bijvoorbeeld de hightechindustrie. Zo werken halfgeleiderfabrikant ASML en productiebedrijf VDL-ETG binnen een project ook al met sbe. RWS, TNO-ESI, ASML, VDL-ETG en de TU/e werken bovendien samen aan sbe binnen een Nederlands sbe-ecosysteem. Hun resultaten delen ze via een opensourceproject genaamd Eclipse Escet.

Reacties (82)

[Division]

Dit klinkt als een marketingsausje wat ze over TDD + uitbesteding hebben gegoten. Gouden formule voor torenhoge kosten en een ruime kloof tussen de verschillende inzichten en verantwoordelijkheden van de partijen.

Het grootste probleem is dat ze blijkbaar bereid zijn om onverschillig te zijn over de implementatie, over "hoe" de software gebouwd zal worden. Het enige dat immers echt uitmaakt, is dat de test, het "acceptatiealgoritme" groen licht geeft. Vibe coded mess? Groen lampje = go.

Met andere woorden: Wanneer deze test niet 100% compleet is, kan het zomaar zijn dat de achterliggende software niet klopt. En omdat die niet in-house wordt gebouwd, spoor je dat te laat op.

Ik hoor graag of ik er naast zit, want het lijkt me een slecht idee.

En over Test Driven Development gesproken; TDD werkt alleen maar als je de codebase volledig begrijpt, de requirements glashelder hebt en er weinig veranderingen zijn waar je in mee moet. Want je bouwt vanuit de test omhoog. Hoe meer de test moet wijzigen, hoe meer je de fundering breekt. Daar moet je in de code heel erg veel rekening houden, en geloof me - dat is een grote uitdaging.

Geen onpopulaire mening: TDD is eigenlijk alleen nuttig bij simpele projecten.

[Reactie gewijzigd door Division op 27 maart 2025 10:42]

[dhendriks]

Ik begrijp dat er wat onduidelijkheid is. Het nieuwsbericht bevat niet alle details. Ik ben de 'Dennis Hendriks' die wordt gequote in het nieuwsbericht. Ik ben onderzoeker bij TNO-ESI, SBE expert en project lead bij het Eclipse ESCET open source project dat ook in het nieuwsbericht wordt genoemd. Ik geef graag wat meer toelichting.

Traditioneel schrijft Rijkswaterstaat lange requirements documenten. Die worden dan bij een aanbesteding aan een aannemer gegeven, die ze verder uitwerkt en uiteindelijke de besturingssoftware in PLC code implementeert. Alle situaties doorzien is soms lastig, zeker voor de aanbesteding, jaren voordat het object wordt gerealiseerd. Het object en de software zijn er dan nog niet. En zeker voor foutsituaties en combinaties van foutsituaties is het lastig. De documenten zijn dan ook niet altijd eenduidig, consistent, compleet, etc. Er moet dan in latere stadia van de ontwikkeling regelmatig over worden overlegd met de aannemer en onderaannemers, wat veel tijd kost. Dit is overigens niet alleen voor Rijkswaterstaat lastig. Dit is eerder regel dan uitzondering in de praktijk. Niet alleen als er met marktpartijen wordt samengewerkt, maar ook tussen verschillende afdelingen binnen een bedrijf.

Het is onder andere lastig vanwege de grote aantallen toestanden. Er werd in een ander comment al over gesproken. Er zijn typisch honderden sensoren en actuatoren. Als dat digitale sensoren en actuatoren zijn, heb je al snel 2 * 2 * 2 * 2 * ... gecombineerde toestanden. Vandaar de zogenaamde 'state space explosie', het blaast exponentieel op. Uiteraard is niet alles is direct gerelateerd, maar er zijn ook diverse indirecte relaties. Het wordt vooral lastig als je dan ook nog foutsituaties krijgt. Een sensor kan stuk gaan een geeft dan bijvoorbeeld altijd een 'aan' signaal. Of wat als een kabel naar een actuator stuk gaat? De besturingssoftware kan dan wel een actie willen doen, maar dat gaat niet meer. Wat als er meerdere sensoren en actuatoren tegelijk kapot gaan? Hoe moet de besturing dan reageren? Kan een deel van het object nog worden aangestuurd? Wat als je een fout aan het afhandelen bent, en er gaat nog iets stuk? Aan infrastructurele objecten worden door wet- en regelgeving strenge veiligheidseisen gesteld wat betreft faalkansen.

Bij de SBE methode wordt eerst een model van het onbestuurde systeem gemaakt. Je beschrijft wat het systeem kan doen. Er zijn bijvoorbeeld sensoren die aan en uit kunnen gaan, waar je als besturing geen invloed op hebt. En er zijn actuatoren die je aan kunt sturen. Die hebben ook relaties. Als je een motor aanzet om een sluisdeur te openen, gaat de sensor dat de deur open is na verloop van tijd aan (tenzij de motor of sensor kapot is). Je modelleert wat het systeem kan. Daarnaast modelleer je besturingseisen. Je legt vast wat wel en niet mag. RWS heeft de landelijke bruggen standaard en de landelijke sluizen standaard. Die documenten bevatten besturingseisen. Die kun je ook in een formeel (wiskundig) model opschrijven. Een computer kan er dan aan rekenen. Het kan alle scenario's doorrekenen, controleren of er geen tegenstrijdigheden in zitten, of er niet toch nog onveilige situaties mogelijk zijn die over het hoofd zijn gezien, etc.

Het heeft veel raakvlakken met formele verificatie zoals model checking. Het synthese algoritme gaat echter een stapje verder. Bij model checking komt er een antwoord uit dat het model aan de eisen voldoet, of het geeft een tegenvoorbeeld waarbij dat niet zo is. Je moet dan zelf het model aanpassen en door-itereren tot het wel goed is. Met 'supervisory controller synthesis', het algoritme dat bij SBE wordt gebruikt, voegt het algoritme zelf minimale extra beperkingen toe om wel aan de eisen te voldoen. Die kan de engineer dan bekijken, en daarmee de besturingseisen aanscherpen of ontbrekende toevoegen. De uitkomst van synthese voldoet gegarandeerd aan de gestelde eisen. Maar de gestelde eisen kunnen uiteraard verkeerd zijn. Met simulatie kan worden bekeken of het bestuurde systeem op de gewenste manier werkt, en dus of de juiste eisen zijn opgeschreven. Uiteindelijk kan er dan ook de implementatie uit worden gegeneerd, maar de code kan ook nog altijd handmatig worden geschreven.

Rijkswaterstaat heeft SBE nu intern in gebruik genomen. Ze modelleren, synthetiseren en simuleren. Ze kunnen zo snel een requirement wijzigen, opnieuw synthetiseren, en met een simulatie kijken of dat het gewenste resultaat oplevert. Dit kan in een vroeg stadium, als er nog geen hardware en software is, alleen plannen. Ze kunnen dan ook in een vroeg stadium al diverse stakeholders betrekken, zoals asset managers en bedienaars. Via pilots is aangetoond dat het formeel moeten vastleggen wat het gedrag is dat je wenst, tot betere eisen leidt. Op papier kun je alles opschrijven. Met SBE zie je al snel dat het niet klopt. Voor nu gebruikt RWS het dus nog alleen intern. Ze gebruiken het om betere besturingseisen op te stellen. Die gaan dan alsnog in een document naar de aannemer, hoewel ze de modellen nu ook meeleveren.

Er wordt ook gekeken naar toepassing samen met marktpartijen, voor de detailuitwerking van het object na aanbesteding. En ook naar codegeneratie. Maar dat zijn nog pilots om te kijken of het haalbaar en gewenst is om SBE daar ook voor in te zetten. Daarvoor is dus nog niet besloten of dat gaat worden ingezet.

[likewise]

Zeer bedankt voor de uitleg, dit is tenminste een uitleg waar we wat mee kunnen in tegenstelling tot het Tweakers artikel.

Zaken als formele verificatie moet een beetje IT-er hier wel aanspreken.

De state-explosie kan digitaal veel sneller gaan dan 2^N, maar je doelt waarschijnlijk vnl. op binaire sensoren, die bijv. open/dicht als enige twee toestanden kennen?

[dhendriks]

Ja, sorry. Binaire sensoren/actuatoren inderdaad. Als de sensoren meer waardes hebben groeit het aantal toestanden nog sneller.

[Zic]

Wie controleert of datgene wat het systeem in de praktijk kan (of kan overkomen) correct en volledig is gemodelleerd in SBE?
In de praktijk zijn er allerlei onvoorspelbare verborgen actuatoren: bijvoorbeeld een storm waardoor een dragende constructie wordt beschadigd.
Of dat tijdens assemblage of reparatie actuatoren of sensoren worden verwisseld.

[Reactie gewijzigd door Zic op 27 maart 2025 16:18]

[dhendriks]

Organisaties die SBE in gebruik willen nemen denken er uiteraard over na hoe SBE in te passen in hun processen. Zo zullen bijvoorbeeld modellen worden gereviewed, net als dat documenten worden gereviewed, om maar een voorbeeld te noemen. Het is niet zo dat bij ingebruikname van SBE alle bestaande processen overboord gegooid worden of overbodig zijn.

Bestaande analyses als FMEA zullen nog altijd gedaan worden. Dat valt buiten SBE. De conclusies daarvan zijn wel input voor de besturingseisen, en kunnen dus in SBE worden meegenomen. In principe zal men in het ontwerp voor elke sensor en actuator, alle kabels, etc, er vanuit moeten gaan dat ze kapot kunnen gaan. De eerder genoemde analyses moeten ervoor zorgen dat er bijvoorbeeld genoeg sensoren zijn om verschillende beschadigingen te kunnen detecteren, als dat relevant is voor de besturings- en veiligheidseisen. Maar er kan ook met diagnosers gewerkt worden, die bijvoorbeeld detecteren dat na een bepaalde tijd een sensor waarvan verwacht wordt dat deze aan moet gaan, nog niet is aangegaan.

Een verwisselde sensor of actuator zal tijdens een gedegen site acceptance test gevonden worden. Dergelijke testen blijven bestaan bij SBE.

De waarde van SBE is voor bepaalde toepassingen aangetoond met pilots. Maar het is niet de silver-bullet die alles oplost. Het beste is om het in te zetten waar het waarde heeft.

[Reactie gewijzigd door dhendriks op 27 maart 2025 19:51]

[IntrCpT3R]

Dank voor je uitgebreide toelichting, Dennis. Dat geeft veel meer context en diepgang dan het oorspronkelijke artikel — heel waardevol!

Wat ik me op basis van je uitleg nog afvraag:

Je noemt dat het synthese-algoritme zelf extra beperkingen toevoegt om aan de eisen te voldoen. Hoe wordt geborgd dat die automatische toevoegingen niet onbedoeld functionaliteit beperken of tot suboptimale werking leiden?

Hoe worden faalscenario’s en hardwaredefecten (zoals kapotte sensoren of actuatoren) concreet meegenomen in de modellering? Worden die gesimuleerd, of worden er aparte eisen voor opgesteld?

In hoeverre is er al ervaring met het inzetten van SBE ná de aanbesteding, in samenwerking met marktpartijen? En waar liggen dan de grootste knelpunten of aandachtspunten?

Je noemt codegeneratie als vervolgstap: wordt daarbij gewerkt richting specifieke programmeertalen of standaarden zoals Structured Text voor PLC’s?

Tot slot ben ik benieuwd: hoe schaalbaar is de huidige tooling van ESCET in de praktijk? En in hoeverre kan de bredere markt (aannemers, ingenieursbureaus) hier nu al mee aan de slag?

[dhendriks]

Je noemt dat het synthese-algoritme zelf extra beperkingen toevoegt om aan de eisen te voldoen. Hoe wordt geborgd dat die automatische toevoegingen niet onbedoeld functionaliteit beperken of tot suboptimale werking leiden?

Je kunt de extra beperkingen bekijken en reviewen. Je kunt ook simuleren om te kijken of ze het gewenste gedrag opleveren. Vaak duidt het op missende requirements, die je dan vervolgens zelf expliciet kunt maken, zodat synthese uiteindelijk geen extra conditions meer hoeft toe te voegen.

Hoe worden faalscenario’s en hardwaredefecten (zoals kapotte sensoren of actuatoren) concreet meegenomen in de modellering? Worden die gesimuleerd, of worden er aparte eisen voor opgesteld?

Synthese hoeft er niet voor aangepast te worden. Het is puur dat je het in het modelleren meeneemt. Je modelleert wat voor hardware je hebt. Je modelleert je reguliere besturingseisen. Dan kun je synthese doen. Voor fault-tolerant control kun je daarnaast apart specificeren wat er moet gebeuren als hardware fault. Dus inderdaad aparte eisen daarvoor. Je specificeert dat modulair, naast het reguliere gedrag. Er is onderzoek naar gedaan hoe je dat netjes opzet, correct modelleert, etc.

In hoeverre is er al ervaring met het inzetten van SBE ná de aanbesteding, in samenwerking met marktpartijen? En waar liggen dan de grootste knelpunten of aandachtspunten?

Aspecten die hierbij naar boven komen zijn onder andere waar de verantwoordelijkheid ligt, hoe je zorgt dat marktpartijen de kennis en kunde rondom SBE hebben, change management, etc.

Je noemt codegeneratie als vervolgstap: wordt daarbij gewerkt richting specifieke programmeertalen of standaarden zoals Structured Text voor PLC’s?

De CIF tooling in de ESCET toolkit bevatten code generatoren, voor general purpose programming languages zoals C en Java, maar ook voor IEC 61131-3 Structured Text voor diverse types PLC's. Het eenvoudig kunnen wisselen van fabrikant wordt als een voordeel gezien. Je genereert gewoon nieuwe code, in plaats van dat je iemand handmatig de code moet laten omzetten.

Tot slot ben ik benieuwd: hoe schaalbaar is de huidige tooling van ESCET in de praktijk? En in hoeverre kan de bredere markt (aannemers, ingenieursbureaus) hier nu al mee aan de slag?

Qua schaalbaarheid van de synthese algoritmes zijn de laatste jaren groten stappen gemaakt. Waar 20 jaar geleden het nog over 100en of 1000en toestanden ging, zijn er nu al systemen met 10^300 toestanden te synthetiseren door slimme symbolische algoritmen te gebruiken. Maar, het hangt af van de complexiteit van het systeem. Een productiesysteem waarbij producten naar alle stations toe kunnen heeft circulaire afhankelijkheden, wat in de fixed-point berekeningen in de algoritmen relatief duurder is. Dat kan meer rekenkracht kosten dan een strict hierarchisch systeem, ook als die laatse veel meer toestanden heeft. In gevallen waar monolitische synthese (waar een enkele supervisor uitkomt) niet schaalt, zijn er ook niet-monolitische synthese algoritmen. Die kunnen supervisors synthetiseren voor deelsystemen. De meerdere supervisors besturen dan samen het systeem. Dit is een onderzoeksgebied op zich.

De ESCET tooling is open-source en kan door iedereen gebruikt worden. Op de website staat ook een online self-studie cursus. Voor een organisatie die het nog nooit heeft toegepast zou ik aanraden contact op te nemen met TNO of een andere partij met kennis van SBE. De kans op succes is groter als je kennis kunt delen en niet voor alles zelf het wiel opnieuw moet uitvinden.

[plukke]

Dank voor je uitgebreide reactie. Ik denk dat dit met name aan de requirements kant bij RWS een hele hoop kan brengen.

Ik heb zelf ook een aantal projecten voor RWS mogen doen. Wat mij voornamelijk opviel is dat RWS het gebrek aan kennis en daadkracht binnen de organisatie lijkt vast te willen leggen in een enorme berg eisen. Combineer dat met een oneindige facinatie voor veiligheid, en what if scenarios en je hebt een brei aan informatie waar je u tegen zegt.

Als ik dat vergelijk met de besturings logica die ik in andere velden tegenkom (b.v offshore productie eilanden van Shell) zie je daar duidelijk dat men veel beter in staat is om tot de kern te komen. Specificaties zijn veel duidelijker uitgewerkt, waardoor de implementatie ook eenvoudiger is. Veiligheden worden daar in een HAZOP geidentificeerd, en zijn uiteindelijk zeer duidelijk afgekaderd en vastgelegd in heldere C&E matrixes. Hierin wordt uiteraard rekening gehouden met falende sensoren en actuatoren, kabelbreuk, etc etc. Er is daarnaast een zeer duidelijke functionele beschrijving, waar tegen je software wordt afgenomen door mensen met kennis van de installatie en het proces.

De reden voor het verschil? Als je het mij vraagt het niveau van kennis van de mensen aan beide kanten, en een aanpak die niet uitgaat van een oneindige berg geld en tijd.

[ajrouvoet]

Ik hoor graag of ik er naast zit, want het lijkt me een slecht idee.

Ik geloof dat je er inderdaad naast zit, al is dat goed te begrijpen met de wat vage presentatie van wat er daadwerkelijk wordt voorgesteld.

Volgens mij is de methode die TNO-ESI met TU/e hier gebruikt de volgende. Ze hebben een (tekstuele dan wel grafische) modelleringstaal om besturingseisen in vast te leggen. Dat model wordt vervolgens op twee manier gebruikt. De eerste manier is om het model te verifieren/valideren voor de gewenste eigenschappen voor besturingseisen. Bijv. een notie van interne consistentie of wellicht iets als deadlock-freedom. De tweede manier is om van een model dat aantoonbaar valide is dan de daadwerkelijk controle-logica te genereren.

In andere woorden: ze gebruiken een modelleringstaal voor control-processes met een simulator (~interpreter) voor testen en een compiler voor operationalisering naar het besturingsplatform.

Deze decompositie is niet nieuw. Als je ooit een parser hebt gegenereerd uit een grammatica dan heb je een soortegelijke methode gebruikt.

De toepassing op een domein waar je hoge kwaliteitseisen hebt brengt natuurlijk nieuwe uitdagingen. Je zult bijvoorbeel zekerheid will hebben over de compiler, zodat er geen logische fouten in kunnen sluipen tijdes model-compilatie. Dit is echter een verbetering dan voor elke implementatie apart die hoge kwaliteitseisen valideren, want je kunt het nu centraal vaststellen. Er bestaan methoden om wiskundig te bewijzen dat zo'n compiler altijd correct functioneert (zie bijv. https://inria.hal.science/hal-01238879/ voor een geverifieerde C compiler).

Waar het artikel wat vaag over is is in hoeverre de gegenereerde control logica daadwerkelijk zal worden gebruikt voor de uiteindelijk besturing. De tekst van het tweakers artikel suggereert dat het mogelijk met de hand zal worden geintergreerd in de besturingssoftware van derden.

Bron: TNO-ESI presenteerde dit project afgelopen jaar op bits-&-chips Eindhoven en publiceerden over deze toepassing. Bijv https://vbn.aau.dk/ws/por...pervisory_Controllers.pdf

[SnobbleCream]

Ik heb binnen de vakgroep op de TU/e gezeten waar dit ontwikkeld werd, en er ook een vak over gehad. Het is wel degelijk iets anders dan TDD, en wat je zegt zit in de richting, maar het gaat verder. (Edit: volgensmij is de reactie aangepast nadat ik dit getypt heb, wat je zegt over het genereren klopt.) Ze gebruiken de requirements om de supervisory controller te genereren, en als (als!!!) het model van het systeem, en het model van je requirements klopt, heb je gegarandeerd een controller die aan je eisen voldoet.

In de basis komt het neer op het modelleren van zowel het gedrag van je systeem, als de requirements die je hebt als state machines. Dit doen ze in een tekstuele programmeertaal.

Bijvoorbeeld, je hebt een brug die open en dicht kan, met slagbomen aan beide einden. Daarop kun je de eis loslaten dat de brug pas open mag, als de slagbomen dicht zijn. Zowel de brug+slagbomen, als die eis die je daar op loslaat, kun je modelleren in die programmeertaal. Vervolgens laat je daar een synthese-algoritme op los die een "supervisory controller" maakt die de brug kan aansturen, maar wel (wiskundig gegarandeerd) voldoet aan de eisen die je hebt.

Deze methode is echt heel gaaf en compleet anders dan wat je normaal binnen software engineering doet. Echter ben je (op dit moment) nog gelimiteerd in de modellen en eisen die je kan uitdrukken in die taal. Toen ik ermee bezig was, waren dingen die met tijd te maken hebben (in veel besturingssystemen wel belangrijk) niet echt lekker uit te drukken, je kon alleen over discrete events praten.

Als je geinteresseerd bent, kan ik je zeker aanraden om naar Eclipse ESCET te kijken. Dit is een open source doorontwikkeling van wat er destijds binnen onze vakgroep werd ontwikkeld, en de documentatie is best toegankelijk (en veel minder kort door de bocht dan wat ik hier beschrijf)

[Reactie gewijzigd door SnobbleCream op 27 maart 2025 13:04]

[rijssel]

Ik zit al wat jaren in de besturing software engineering, ook voor RWS. De eisen zie ik als de spelregels en de lijntjes rond 't voetbalveld, maar hoe het spel tot winst leidt, ligt toch echt bij kennis, ervaring en kunde van de spelers en het team daaromheen (ofwel de uitvoerende partijen).

Tegenwoordig zijn veiligheid systemen veel impactvoller en best complex te begrijpen. Dit hangt af van risico beoordelingen en uitvoering ligt in zowel harware als software. En let op, de veiligheid software staat weer los van de besturing software en de visualisatie en bediening. Veiligheid in de software gaat in geval van RWS (Landelijke Bruggen en sluizen Standaard) over machine veiligheid, functionele veiligheid, water veiligheid, verkeersveiligheid, nautische veiligheid, cyber veiligheid, etc.

Als ik begrijp dat dit SBE zich focust op "Supervisory control" (ofwel SCADA) dan is de besturingslaag nog niet zomaar uitgelopen hiermee.

Toch bere interessant, en ik ga me er zeker in verdiepen. Want, ik ben ook wel van mening dat er tegenwoordig zoveel ontwerp argumenten zijn aan een besturing dat e.e.a. nauwelijks nog te bevatten is voor een engineering team. Alle tools zijn welkom. TDD is naar mijn inziens nooit dekkend vwb alle risico's, maar alleen de bekende risico's.

[SnobbleCream]

Uiteindelijk is het ook niet zo dat het minder werk is, of dat je puur met het toepassen van SBE een toverstokje hebt om alle risico's af te vangen. Je verschuift de complexiteit en de bulk van het werk van het implementeren van software naar het modelleren van je systeem en de requirements. En dat is makkelijker gezegd dan gedaan. Als je een edge case in het gedrag van je systeem vergeet te modelleren, zal je gesynthetiseerde controller daar geen rekening mee houden. De requirements die je ingeeft worden gegarandeerd gehaald, maar dan moeten die requirements er wel zijn, en je moet ze wel goed vertalen naar de tool die gebruikt wordt. Dat is en blijft mensenwerk. Het voordeel zit hem vooral in de garanties die je relatief eenvoudig kan krijgen.

Natuurlijk gelden deze nadelen ook voor TDD; daar kun je ook een edge case vergeten te testen. Er zit wel een fundamenteel voordeel in SBE; Bij reguliere unit/integratietesten is het voor een stuk software van enige omvang praktisch onmogelijk om elk mogelijk pad door de code te raken. SBE doet dit wel, sterker nog, het hele concept achter het algoritme is (heel kort door de bocht) de volledige toestandsruimte van je systeem terug brengen tot een subset die je gewenst acht.

Van wat ik er in mijn studietijd van gezien heb, en de ervaring die ik in de praktijk heb, is het een hele krachtige tool als je systeem zich mooi naar de manier van denken van de tool laat vertalen. Het zit hem inderdaad echt op de supervisory control / SCADA laag. Een PID-regellus kan je er niet in modelleren, en een user interface ook niet. Zoals je zelf al zegt, zie het als een tool in je toolbelt die voor bepaalde problemen écht heel krachtig kan zijn, maar zeker niet de oplossing voor alles.

[boxlessness]

Same shit, new year...
20 jaar geleden had ik bij een grote lithografie machine producent (guess which) een presentatie over model based development... cq, blokjes op een canvas slepen met lijntjes ertussen... het jaar daarna was het code genereren vanuit UML die de architecten maakten, en de codemonkeys hoefden alleen maar wat functies nog in te vullen... toen was het low-code/no-code, en nu vibe-coding met AI.
Tussendoor heb ik ook nog dingen als rule-engines voorbij zien komen.

Deze tools lossen niks op... complexiteit van een applicatie blijft hetzelfde. Code is een expressie van logica, gedrag en structuren, en de talen die we hebben werken daar prima voor. We maken al abstracties om complexiteit achter te verbergen. We gebruiken al libraries zodat we het wiel niet telkens opnieuw uitvinden. We hebben al programmeertalen die delen van de computer weg abstraheren en fouten voorkomen.

Voor een brug of tunnel kan ik me nog voorstellen dat er een gesloten set aan gedrag en fail-states zijn en dat je daar 1 model/ruleset voor kunt maken, maar daaronder zal nog steeds gewone code/software liggen.

[Zic]

Same shit, new year idd.

In de softwareontwikkeling komt er regelmatig een of andere Einstein op het idee om zijn werk zo abstract te maken dat hij in feite een nieuwe compiler aan het maken is voor zijn eigen 'model', wat ook gewoon in bestaande talen uitgedrukt kan worden, en met bestaande tools verwerkt kan worden.

Je kan er geld op inzetten dat die ESCET taal niet eenvoudiger is om in te werken dan een bestaande programmeertaal.

[Reactie gewijzigd door Zic op 27 maart 2025 15:46]

[Oerdond3r]

Ik lees het eerder als: synthesis-based engineering is juist om bij dit soort complexe projecten de requirements glashelder te krijgen. Om alle mogelijke egde-cases al in kaart the hebben voordat er nog maar 1 regel implementatie geschreven is, en de tests die de code moet doorstaan alvast klaar staan.

Dit leest voor mij juist als een manier om de precisie en nauwkeurigheid van TDD naar het complexe te tillen.

Als de implementerende partij vervolgens lui besluit te gaan vibe-coden.. tsja. Je verwacht dat een partij dat professioneel oppakt net als dat ze dat elk project zouden doen. Maar mochten ze slechte code schrijven die resulteert in groene lampjes, maar alsnog niet aan voorwaarden voldoet, dan is dat weer een goede case om de sbe techniek te verbeteren en krijg in feite een soort positieve feedback loop.

Ik trek nu waarschijnlijk teveel conclusies uit dit artikel zonder me erin verdiept hebben, maar ik kan wel mij voorstellen dat zoiets hierachter zit.

[latka]

Ik las het meer als 'formele verificatie' of 'model checking' wat in hardware land al jaren gemeengoed is. Even de publicaties van de hoofd onderzoeker ernaast gelegd en inderdaad lijkt het een combinatie van model-checking en code-generatie te zijn.
Model checking (kort door de bocht) berekent alle toestanden/inputs die mogelijk zijn van je systeem en bepaald of je in een situatie kunt komen die je niet wilt (simpel: if(timer>60) then brug_open() else bug_dicht(); heeft 2 paden. Doe dit voor if's en loopjes in je systeem en je hebt alle toestanden van je software gezien). Probleem met model-checking zijn vaak de hoeveelheden aan toestanden. Een deel van die toestanden zijn een implementatie detail (if(alloceer_geheugen(1024) then do_iets else error_geen_geheugen();) die je weg kunt halen in je systeem beschrijving. Dan heb je alleen nog een generator nodig die van je systeem beschrijving de nodige implementatie details toevoegd. Die ga je apart op correctheid bewijzen en je hebt een model geverifieerd en een vertaling van model naar echte software gemaakt. Dit lijkt dus niet eens op TDD maar meer op wiskunde.

[Henk Poley]

Als ik zo de namen en universiteiten zie die aan Eclipse ESCET werken, acht ik de kans groot dat het niet gewoon (Java ofzo) software tests schrijven is voordat je echte code schrijft; dus niet de standaard Test Driven Development (TDD). En het heeft weinig met outsourcing te maken.

Het lijkt eerder een formele taal die bewijst dat je alle opties afgedekt hebt. Zo van, de brug kan open en dicht. Er is een vergrendeling die de brug open stand open houdt, en dicht als die dicht is. De vergrendeling wordt op de juiste momenten bedient. Er is een nood systeem dat de brug in eerste versnelling heel langzaam kan sluiten, dat wordt alleen actief als de stroom is uitgevallen, maar de noodstroom ook voldoende stroom levert. Allerlei verkeerslichten voor verkeer op de weg en over het water moet hier correct op reageren. Met het bedieningspaneel moet je alles kunnen besturen.

ESCET bewijst dat wat jij opschrijft logisch in elkaar past, en compileert het naar een programma.

Je schrijft dan meestal de dingen op die waar moeten zijn, kan je dan over bakkeleien of die individueel juist zijn. Gezamenlijk consistent zijn, daar let het systeem op.

[TwiekertBOB]

Hoor graag wat meer inhoudelijk over die methode, want zo zegt het stukje niet veel.

Dan krijg je dit soort overwegingen:
Ik vraag me af of die methode SBE wel beter is dan de KISS methode. Als ik hoor dat er miljarden situaties moeten worden doorgerekend dan gaan bij mij alarmbellen af. Zo ingewikkeld zou het openen of sluiten van een brug of sluis niet moeten zijn, als we sec kijken naar veiligheid.

Als er ook gekeken moet worden naar de meest efficiënte doorstroom voor alle partijen (auto, boot, etc.), dan kan ik me er meer bij voorstellen, maar daar zegt het stukje niets over.

[pegagus]

Die miljarden situties zijn combinaties van storingen die kunnen optreden. Veiligheid is niet enkel een lamp aan en een slagboom naar beneden, maar ook weten dat de lapmp functioneert en de slagboom er niet uitgereden is. De bediening gebeurt tegenwoordig vrijwel geheel op afstand, dus je wil ook weten of je realtime data krijgt en niet de informatie van net iets te lang geleden.

Al die combinaties van falen kun je onmogelijk in de praktijk testen en tegelijkertijd wil je beperkt falen wel toestaan (om te voorkomen dat bij ieder wissewasje nioet bediend kan worden). Dus simuleer je alles in software.

[Mars Warrior]

Miljarden combinaties van storingen op een brug?

Ik kan me daar helemaal niets bij voorstellen eerlijk gezegd. Bij een open/sluit bijv. heb je 3 schakelaars die dubbel zijn uitgevoerd en die bewaakt worden door de besturing. Natuurlijk heb je nog de aandrijving (frequentieregelaars, motoren en remmen/grendels) en de afsluitbomen/lichten, maar om daar miljarden combinaties uit te halen lijkt me een ware kunst.

En ja: met een digital twin kun je wel degelijk falen testen zodat je in de praktijk voorpelbaar gedrag krijgt.

Voor oude bruggen is dit natuurlijjk lastiger, maar die zijn iha ook degelijker gebouwd (overgedimensioneerd) omdat we destijds nog geen computers hadden om alles door te rekenen.

Ik doe data analyses van infra objecten, dus ik weet vanuit de praktijk redelijk hoe dit werkt

[Bart ®]

Ik hoop dan dat je geen data-analyses op bruggen doet, want dan mis je toch wel wat informatie... Je wil niet weten hoeveel systemen er aan een brug gekoppeld zijn, die ook weer allemaal gemonitord worden. Zo heb je filedetectiesystemen (detectielussen in de weg, die weer aangesloten zijn op systemen die die signalen omzetten naar iets wat een PLC kan interpreteren), detectie of de brug wel 100% dicht is, camera's, netwerkapparatuur voor bediening op afstand, PLC's voor de bediening van de brug, scheepvaartseinen, laagspanningsinstallaties, noodstroominstallaties, communicatiesystemen, signaalgevers tbv wegverkeer, voorwaarschuwingsseinen voor het wegverkeer, en ga zo maar door. Elk van die systemen heeft subsystemen, die elk weer meerdere foutmeldingen kunnen genereren. Miljarden verschillende combinaties is dan gewoon een feit. Statistisch onwaarschijnlijk dat ze allemaal voorkomen in de praktijk, dat dan weer wel.

[pegagus]

Doet het wel, doet het niet. Twee mogelijkheden dus. Bij 3 componenten heb je al 8 faalscenario's. Bij 30 componenten overschreidt je 1 miljard mogelijkheden. Uiteraard is het niet zinnig om die allemaal door te rekenen. Maar op deze manier kom je aan een miljard mogelijkheden.

Risicogestuurde projectplanningen worden op een zelfde manier doorgerekend. En dat gaat tegenwoordig razend snel. Als rekentijd geen rol speelt, dan kun je dus net zo goed die miljard combinaties doorrekenen.

[bazs2000]

Analyses gaan al snel over in grote getallen door het aantal mogelijke situaties.

3 schakelaren die elk 3 standen hebben testen of alle mogelijke combinaties werken is nog eenvoudig.

Plaats daarachter verlichting waarvan je per licht niet alleen wilt weten of deze werken maar ook in welke kleurenstand deze staan maakt het alweer wat ingewikkelder.

En dan wil je ook nog eens weten hoeveel tijd er tussen het knipperen van de rode lampen en het dichtgaan van een sluis en de complexiteit neemt alweer wat meer toe.

En nu wil ik ook nog weten in welke stand de sluis staat en het gaat al richting de 10.000 mogelijke combinaties.

Daar draaien wij ons hand niet voor om maar door de ervaring vergeten wij dat wij dagelijks met grote getallen werken.

[haam]

Het gaat volgens mij over heel veel mogelijke paden. Je gaat normaal gesproken geen storingen stapelen

[pegagus]

Normaal gesproken (handmatig) niet. Maar softwarematig is het een tabelletje van componenten die wel of niet aan staan. Het is ook niet perse storingen stapelen, maar het combineren van gebeurtenissen. Bv slagbomen op en brug open. Of lichten uit en slagbomen in beweging. De tijdwinst zit er nu juist in dat je niet situaties handmatig gaat simuleren, maar dat je domweg gestructureerd alle situaties doorrekent en er op een slimme manier de foute combinaties uit weet te halen.

[haam]

Laat ik het anders omschrijven. Zoals @dhendriks het omschrijft, komt het over alsof alle sensoren een relatie met elkaar hebben. Maar dat is alleen het geval als de brug als 1 totale entiteit wordt beschouwd.

In IA wordt alles opgebouwd dmv typicals. Die worden dan weer gecombineerd tot grotere typcials.
Een brug mag pas open als alle slagbomen dicht zijn. Stel er zijn 4 slagbomen, dan is de kortste omschrijving boom1 of boom2 of boom3 of boom4 is niet dicht.

Als je alle mogelijke configuraties gaat benoemen (boom1 en boom2 niet dicht, boom3 en boom4 wel dicht, etc.) dan kom je inderdaad op heel veel mogelijkheden (dus heel veel paden). Maar het resultaat onder de streep is hetzelfde.

[dhendriks]

Er wordt vaak over het aantal toestanden gesproken. Het zijn dan grote getallen die tot de verbeelding spreken. Zo zijn er systemen met iets van 10^300 toestanden waar we synthese voor kunnen doen. Het geeft een bepaalde mate van complexiteit aan. Maar, het is zeker geen heilige metriek. Er zijn systemen die sterk hierarchisch zijn, zoals je beschrijft. Daarbij kun je abstracties gebruiken om niet alle details van lagere niveau's te hoeven meenemen. Echter, er zijn ook systemen waarbij dat lastiger is. Zo zijn er systemen met aanzienlijk minder toestanden die toch complex zijn, omdat zo'n beetje alle delen van het systeem een relatie hebben met andere delen. Denk bijvoorbeeld aan een productiesysteem waar producten rond gaan, met AGV's of met lopende banden. Vaak kan een product van elke positie in het systeem naar elke andere positief. Dan heb je veel meer relaties dan in een strict hierarchisch systeem. Het hangt sterk af van het systeem en het ontwerp.

[haam]

Vaak kan een product van elke positie in het systeem naar elke andere positie

Positie en toestand zijn 2 verschillende dingen. Wat overeenkomt is dat beiden een transitie gebruiken. Na iedere transitie is er een nieuwe positie/toestand.
Een AGV kan niet teleporteren van elke positie naar elke positie. Het komt meer in de buurt van net zo vaak een positie verandering uitvoeren tot je op de gewenste positie staat. Dus het totaal aantal posities kan enorm zijn, het aantal mogelijke 'next step' posities is beperkt.

[Some12]

Ik heb er hier wat over gevonden: https://eclipse.dev/escet/sbe-course/

Wat ik ervan denk te begrijpen (tot nu toe) is als men een controller voor fysieke operaties van een enkel component maakt, er niet rekening gehouden kan worden alle vereisten van een chain van componenten, waarin het geplaatst kan worden.

Wat SBE doet is controller logic genereren die correct is voor het gedrag van een controller voor binnen de hele keten van controllers?

[YungDurum]

Ik ben benieuwd of het gebaseerd is op TLA+, beschrijving lijkt er in ieder geval erg op. Het is een abstracte programmeer taal gebaseerd op wiskunde, waarbij alle mogelijke staten van een systeem worden doorberekend. Op het moment dat een staat wordt bereikt die niet is toegestaan (in dit geval brug open met auto’s), geeft die een error en moet je dus iets veranderen aan de architectuur van je programma. Word onder andere door Google en Amazon gebruikt. Hier een interview met de bedenker https://www.quantamagazin...-need-more-math-20220517/

[Reactie gewijzigd door YungDurum op 27 maart 2025 11:58]

[Sauria]

TLA+ is een model checker, die kan automatisch en volledig controleren of een model van een systeem voldoet aan bepaalde eigenschappen (= requirements, dus wat het moet doen). Je moet dat model en die eigenschappen wel zelf specificeren.
Zo te lezen is het idee bij sbe juist dat je alleen een model van de eigenschappen maakt en er dmv code generatie een implementatie uit genereert die volledig aan de eigenschappen voldoet.

[Nark0tiX]

Klopt en lijkt me ook makkelijk te simuleren en testen.

[HansvDr]

Nu nog wat beheerders die eindelijk eens iets moderns in hun systemen durven op te nemen. Bij de waterschappen meerdere malen meegemaakt. Scada hoeveel het ook kost want dat kennen we.

[jpsch]

Bruggen, sluizen en andere vitale infrastructuur is toch aan internet gehangen? Iets wat 30 jaar geleden als not done werd beschouwd? Volgens mij wordt er ook teveel gemoderniseerd.

[Benadski]

In principe hangt het niet aan internet, maar aan het eigen netwerk. Er zijn soms echter nog wel mogelijkheden om daar in te komen. Bijvoorbeeld door op een locatie fysiek in te breken en vanuit daar te hacken. Meestal krijg je alsnog nergens toegang, soms kun je iets meer als je een MAC adres weet te klonen, maar mijn ervaring is dat (bij het waterschap waar ik voor gewerkt heb iig) er veel getest en beveiligd wordt.

[jpsch]

Schijnbaar niet genoeg bij elk waterschap.

nieuws: Waterschap kan miljoenen aan belastingen niet innen door ict-probleme...

[lenwar]

Er kan altijd is wat mis bij gaan bij een leverancier zoals in je voorbeeld, net zoals dat er altijd iets mis kan gaan bij een systeem van de organisatie zelf.

Belasting tijdelijk niet kunnen innen is onhandig (vroeger of later wordt het sowieso alsnog geïnd), maar is niet gevaarlijk of ontwrichtend. Een brug of sluis die gek doet kan, op z'n best, het verkeer compleet ontregelen, of in het slechtste geval, levens kosten. (geen idee hoe realistisch dit in de praktijk is. In het artikel wordt gesproken over een brug openen terwijl er auto's op rijden. Dit kan, afhankelijk van de brug levensgevaarlijk zijn lijkt mij)

[HansvDr]

Niet elke sluis is vitaal. Maar ook die besturing moet en zal Scada zijn. Of ze accepteren geen besturing want geen stroom aansluiting en rijden er af en toe naar toe met 4 man.

Terwijl er besturingen van niet vitale sluizen zijn met zonnestroom, accu's en gprs die vele vele malen goedkoper zijn.

Joh als het ergens een vastgeroeste bende is is het wel bij de waterschappen.

[Reactie gewijzigd door HansvDr op 27 maart 2025 10:05]

[yevgeny]

Dat je met scada voor de levensduur van de brug verzekerd bent van support en reserve onderdelen is niet belangrijk ?

[thomasv]

Natuurlijk wel, maar dat is niet belangrijk als je enkel naar de eerste factuur kijkt toch? Onderhoud en dergelijken zijn allemaal optioneel c.q. zorgen voor later. [/sarcasm]

[Kabouterplop01]

Dat betekent ook dat je niets aanpast tijdens de levensduur van de brug. Wat betekent dat voor de besturing?
En dat geldt voor elk scada systeem op de wereld.

[Reactie gewijzigd door Kabouterplop01 op 27 maart 2025 10:53]

[supersnathan94]

Nee?

Ik weet niet of je wel eens naar "practical engineering" op YT kijkt, maar daar hadden we laatst wat info over zo'n brug met gevaarlijk design, waar er de afgelopen paar jaren er ineens tig van instorten.

Leuk dat support en reserve onderdelen er zijn, maar als inspecties te wensen overlaten en uiteindelijk het design van meet af aan niet goed is, heeft het dan nut? Zeker aangezien al die bruggen in heel veel landen (waaronder Nederland) al vroegtijdig zijn vervangen door nieuwe ontwerpen.

Modernisering in engineering is overigens ook niet verkeerd. Prima om oud en vertrouwd te gaan hoor, maar ook goed om een beetje te moderniseren en weer nieuwe dingen te proberen. Innovatie zorgt ook voor verbeteringen in processen en dus ook veiligheid. Automatisering van zaken hadden ze bijvoorbeeld veel eerder "moeten" doen. Gaat ze echt wel helpen

[lenwar]

Nou word ik niet gehinderd door enige kennis van SCADA, dus aldoende mijn vraag. Is SCADA een bedrijf/merk/consortium? Of is het meer een methode/concept?

Indien het eerste. Een bedrijf kan failliet/stoppen.

Indien het tweede. Hoe wordt dat dan gewaarborgd? Is het een soort 'open/shared source' waardoor de tekeningen en specificaties dusdanig beschreven zijn dat 'iedereen' ze kan maken?

Nogmaals ik ben niet gehinderd door enige kennis hier omheen, dus allicht raakt m'n voorbeeld kant nog wal. Stel dat er een bepaald type tandwiel (of katol/sensor/motor/enz.) nodig is voor die ene type sluis/brug en de bouwer/leverancier van die brug is 15 jaar geleden failliet gegaan, dan kan een willekeurig ander bruggenbouwbedrijf die specificaties opvragen en één op één vervangend tandwiel maken, dat 100% identiek is aan de originele? (of in elk geval voldoet aan de specificaties van de originele)

[haam]

Fyi, scada staat voor supervisory control and data aquisition. Het da deel verzamelt gegevens uit onderliggende besturingscomputers (meestal plc), sc verzorgt bediening (hmi, gui)

[lenwar]

Maar wat 'is' het. Is het een methodiek, of een gepatenteerd mechanisme of een licentie van een organisatie? Als ik naar de betekenis van de afkorting kijk, klinkt het als een redelijk generiek iets, wat iedereen kan gebruiken.

En hoe zorgt dat er dan voor dat je 'verzekerd bent' van ondersteuning en reserveonderdelen gedurende de levensduur van je product (in dit geval een brug/sluis), wat ~yevgeny] aangaf.

[haam]

Ah ok, het is een programma (of set van programma's). Veel PLC fabrikanten hebben hun eigen versie (zo heeft Siemens WinCC en WinCCOA) en er zijn makers van onafhankelijke pakketten (AutomationX).

Heel simplistisch, het zijn de plaatjes waarmee je de automatisering bedient (brug/fabriek/machine/etc.). Je kan op knopjes drukken, waardes uitlezen, alarmen krijgen, etc.

[lenwar]

Oké, het is een soort gestandaardiseerde bedieningsmethode met een compleet modulaire achterkant? (even versimpeld verwoord.)

Dus SCADA garandeert dus helemaal niet dat het gedurende de levensduur van het object wordt ondersteund of vervangbare onderdelen kan bieden zoals @yevgeny aangaf? Daar heeft het dus niets mee te maken. Redelijkerwijs kun je dit soort contracten natuurlijk afsluiten met een Siemens (en al dat soort bedrijven), maar dat staat dus los van SCADA opzich.

[haam]

SCADA draait normaal gesproken op COTS hardware en Windows OS. Dus vervangbare onderdelen komen niet van de SCADA fabrikant, maar van de hardware leverancier (Dell, HP, etc.). De levensduur waar vaak mee gerekend wordt bij IA systemen is ongeveer 15 jaar. Dat geldt vooral voor de besturingscomputers (PLC). Als gebruiker/beheerder wil je dat de bediening een soortgelijke levensduur heeft, ondanks dat er waarschijnlijk veranderingen in windows versies en PC hardware is (die meestal 5 a 6 jaar cyclus hebben).

Waarom je SCADA gebruikt is omdat de fabrikant garandeert dat het backwards compatible blijft. Dus je hoeft niet je SCADA opnieuw te bouwen als er een nieuwe windows versie komt o.i.d. Hooguit een upgrade van de SCADA software, maar alles wat gemaakt is voor de bediening (ook wel configuratie) kan hergebruikt worden op die nieuwe versie.

[lenwar]

En stel dat je fabrikant ermee stopt? Is er dan ook een mechanisme dat een andere fabrikant er mee verder kan?

Dus puur theoretisch. Stel je hebt je spul van HP, en HP gaat stuk. Is er dan een en ander ergens gedeponeerd waardoor een ander ermee op voort kan borduren?

Mijn werkgever vereist dat broncode gedeponwerd is bij een speciale partij, en dat als die partij failliet gaat binnen de duur van de servicecontracten dat die broncode dan beschikbaar komt voor m'n werkgever, zodat we een ander softwarehuis onderhoud kunnen laten plegen.

[haam]

Ah, nu snap ik beter waar je vandaan komt.

Het is sowieso hardware onafhankelijk (want draait op windows). Dus als HP stuk gaat, of het bedrijf HP gaat failliet, dan koop je morgen Dell en gaat vrolijk verder.

Als de leverancier van de SCADA software omvalt, dan blijft de software nog wel een tijdje functioneel. Net als dat je Peugeot het blijft doen, ook al gaat Peugeot als bedrijf failliet.
In de tussentijd kun je op basis van de SCADA software van een andere leverancier de vervanger bouwen. Net zoals je op zoek zou gaan naar een andere auto. Het zijn standaard producten, waarbij je juist probeert de specials/niche uit te sluiten om de uitwisselbaarheid zo groot mogelijk te houden.
Tegenwoordig zijn de meest gebruikte communicatieprotocollen industrie standaard, dus in beginsel is er geen sprake van vendorlocking.

Ter aanvulling, in de industrie is het automatiseringssysteem 2-5% van de aanlegkosten. Er zijn een aantal echt grote jongens (Siemens, ABB, Schneider) en een hele verzameling fabrikanten met een kleinere schaal die al heel lang bestaan. Dus als er 1 omvalt zijn er voldoende alternatieven, waarbij de kosten verhoudingsgewijs te behappen zijn.

[sjaakaq]

Even als simpele ziel: hoe minder er wordt geëxperimenteerd met bruggen, sluizen en andere infrastructuur hoe beter lijkt me.

Snapchat kan experimenteren met nieuwe technieken. Gmail moet even wachten tot die nieuwe technieken al breder in de markt gebruikt worden. Banken kunnen de (inmiddels niet meer zo nieuwe) technieken gebruiken als ze de industriestandaard zijn geworden. En VWS kan er aan beginnen zodra alle grote bugs er zijn uitgehaald, en andere paritjen al aan het kijken zijn naar de opvolger.

[supersnathan94]

Even als simpele ziel: hoe minder er wordt geëxperimenteerd met bruggen, sluizen en andere infrastructuur hoe beter lijkt me.

In een land als Nederland wat voorop loopt in Water management en een gigantische industrie heeft te bedienen ben ik het daar niet mee eens. Innovatie in Water is ons als land eigen. Onze eigen Koning is hier nog mee bezig geweest. Innovatie in deze tak is juist ontzettend belangrijk. Het is niet alleen ons brood wat er vanaf hangt, maar ook ons leven.

Nederland is groot geworden met experimenten op dit vlak. Kijk naar de delta werken. Grootste systeem van water management ter wereld. De afsluitdijk, de Oosterscheldekering, FKN FLEVOLAND. Allemaal producten van innovatie op het gebied van sluizen, bruggen, dijken en watermanagement.

[Mars Warrior]

Hoe bedoel je dit?
Er is niks mis met SCADA icm veiligheids PLC’s van Pilz bijv, waarin dit soort brugprocessen zitten die zwaar zijn getest en in elke situatie een veilige stand kennen.

De standaard componenten van SCADA helpen hier ook enorm in.

[HansvDr]

Er is niks mis met Scada. Maar dat is mijn punt niet. Het zijn 55 plussers die daar een truukje mee kunnen en dat is het al kost het 100000 euro meer.

[thomasv]

Scada is anders wel degelijk en betrouwbaar, als jij dat een truukje wilt noemen prima maar ik betaal liever op voorhand wat "te veel" voor een degelijk scada systeem wat aan een kunstwerk hangt dan dat een brug of sluis te vaak niet functioneert omdat een alternatief component in de besturing vaak in storing gaat.

[Jean luc Picard]

Hoezo, 55 plussers. SCADA. Staat voor Supervisory Control And Data Acquisition is van alle tijden tegenwoordig vaak met een MES laag erboven.

Maar wat zou jij als beheerder "als iets nieuws" willen introduceren?
Ben oprecht benieuwd.

Bij industriële systemen , heb je met
allerlei regelgeving en wetten te maken waaraan je moet voldoen in je totaal ontwerp hardware/software.

Ik moet nog zien of
synthesis-based engineering rekening houdt met de RI&E en noodzakelijke PL's (performance levels) welke nodig zijn voor een Brug. Dit in zowel de hardware als
De programmering.

[inhico]

Rijkswaterstaat is geen waterschap

[Zic]

Het enthousiasme waarmee men beweert dit wel even te kunnen regelen met code generatie/lowcode klinkt mij een beetje naïef in de oren.
In principe heeft een brug 2 eindstanden, open 0% of open 100%. In een theoretisch model is het allemaal heel eenvoudig, dat is de truc niet.
Het gaat erom dat alle onderdelen apart, in alle omstandigheden verifieerbaar veilig en betrouwbaar zijn, en de subonderdelen daarin, en daar weer de subonderdelen etc.

[Reactie gewijzigd door Zic op 27 maart 2025 10:01]

[HollowGamer]

Ik vind het jammer dat je de mensen die op kantoor werken en hier ontzettend veel meetings over hebben, zo wegzet.

Maar ben het met je eens, het voelt iets waar wij Nederlanders goed in zijn. Te veel bestuurders, te weinig (praktijk)ervaring.

[supersnathan94]

In principe heeft een brug 2 eindstanden, open 0% of open 100%.

én 1-99% aan foutstanden

[haam]

De vraag is ook waarom dit op dit platform gepubliceerd wordt. Heb even gezocht op rijkswaterstaat op deze site. 3 hits, waarvan 1 reqruitment spelletje uit 2024 en 2 berichten uit 2019/20.

En het bericht is niet: we hebben de besturing van deze brug volledig gegenereerd

[FrostyPeet]

Hoe vaak ik dit sprookje al hoorde van een "nieuwe methode" voor de "efficiënte" ontwikkeling van software Het is als een waterbed. Je drukt op een plek en ergens anders komt er een bult. De enigen die er wijzer van werden waren de uitbaters van die "nieuwe systemen"

Het eindigt altijd op de installatieplaats zelf, waar de "sh*t" wordt opgelost door de oude rot in het vak. Met ongedocumenteerde "features", niet kloppende tekeningen vol rood-revisies en onwerkbare procedures. Vervolgens juicht het hele bedrijf, alle managers en alle clubjes eromheen hoe goed ze het wel niet deden. Gaat het fout, dan heeft de rot-in-het-vak het gedaan. Als het ding over een half jaar kapot is mag de een of andere uitvoerder de rotzooi zien op te lossen omdat de tekeningen nog steeds niet kloppen.

[lariekoek]

Hoe vaak ik wel niet hoor dat de oude manier, dan dus, sowieso de beste is, is ook een ding natuurlijk.
Volgens mij is het sowieso goed om scherp te blijven maar bovenal ook eerlijk en geen wolfse partijen zichzelf laten verrijken om niets, toch?

[FrostyPeet]

Natuurlijk is het goed om rond te kijken en af en toe alles tegen het licht te houden. Vroeger was niet alles beter.

"Vroeger" was een ploeg mensen verantwoordelijk voor een installatie. Die zorgden er wel voor dat het goed bleef werken want dan was het een rustige baan met voorspelbare taken. Velen werkten er jaren en kenden elke schroef, elke zwakke plek. Gebeurde er iets half/half, dan moesten hun er voor opdraaien want het was "hun" installatie. Werden de luiaards wel aangepakt. Kam er een externe iets doen dan werd dat goed in de gaten gehouden.

Nu moet het efficiënt en goedkoop. Dus uitbesteden naar bedrijf X, die zegt alles te regelen via SLA's. Dan blijkt het net niet uit te kunnen en komen de zzp-ers in beeld. Die problemen worden wel snel "opgelost". Dat relais kan nog wel een jaartje langer mee, De werkbon beland bij de receptie. Die zzp-ers "voelen" niets bij die installatie, het is gewoon een klusje wat zo snel mogelijk moet worden afgewerkt. Na een jaar of twee blijkt alles een grote puinhoop te zijn wat met houtje touwtje draaiend wordt gehouden. De administratie rammelt, iedereen wijs naar elkaar. Dan komen de grote facturen om alles weer "netjes" te maken en de administratie kloppend. De managers die dit alles hebben opgezet zijn allang weg. De nieuwe manager weet niet beter en maakt er wel een project van.

[lariekoek]

Hoe en dat alles rammelt is denk ik iedereen duidelijk inderdaad. Het staat en valt met eerlijkheid. Dat is niet uitsluitend waarheidsgehalte maar eer.
De zaken juist doen, ook als het een externe partij betreft.

Het kortzichtige egoïsme die overal heerst is lelijk.

Meer de tijd nemen om iets juist te doen, in plaats van om een eigenzinnig en snel nut, en dus voor ons als geheel, dat is belangrijk. Eer en geweten dus.
Tijdsdruk als alles tegelijkertijd rammelt doet daar nog verder aan af om snel en kortzichtig, egoïstisch, te handelen.

Het ons, maar ook de tijd voor toewijding, de juiste tijd die nodig is, wordt schaarser in een toenemd conflicterende en van eigenzinnigheden in elkaar rammelende kale kerstboom.

Ik bedoel, we leven letterlijk in een tijd waar kennelijk de koers van natiën casually bepaald wordt op Signal door wat te ventileren met een snelle "agree or not".

[Reactie gewijzigd door lariekoek op 27 maart 2025 13:07]

[Skit3000]

Even over het belang van een standaard voor verkeersregelinstallaties; in Leiden is een kruispunt (bij de Lammebrug) waarachter direct een kruispunt met aan de andere kant wéér een brug ligt. De software voor deze brug is ooit geschreven door een klein team en specifiek voor deze situatie. Na een tijdje wist op één na niemand meer hoe het werkte en die vroeg zo veel geld voor verdere aanpassingen, dat de gemeente Leiden destijds tonnen uit heeft gegeven om de hele regelinstallatie dan maar te laten vervangen.

Ze gaan dit kruispunt nu trouwens aanpakken, waarbij ze twee (!!) tijdelijke bruggen leggen om het verkeer tijdelijk over om te leiden zodat ze de originele bruggen compleet kunnen vervangen.

[supersnathan94]

De software voor deze brug is ooit geschreven door een klein team en specifiek voor deze situatie.

Dus dit hadden we al aan moeten zien komen bij de gunning... is wat mij betreft wel iets anders dan nu werken aan moderne standaarden voor het werk van morgen.

[Skit3000]

De gunning in 1960 zal wel iets anders verlopen zijn dan nu. Of er toen een standaard was weet ik niet, maar ik probeer dus vooral te zeggen dat ik denk dat Rijkswaterstaat hier iets goeds doet (ongeacht of deze nieuwe methode nu wel of geen tijd bespaart).

[rolf-smit]

Is dit een nieuwe methode, of meer een Framework? Het klinkt toch echt meer als het laatste.

[HollowGamer]

Ik gok dat het vooral meer animatie driven is en simulaties die je op een model kunt loslaten.

Maar ik snap verder niet waarom het dan maar weer als richtlijn bij andere bedrijven moet worden gelegd. Het kan dus goed zijn dat een bedrijf uit Spanje, hiervoor software maakt. Ze hebben nooit onze bruggen gezien, maar kennelijk is de methode/insteek dat dit veilig genoeg is.

[bazs2000]

Als het tot een standaard komt en andere bedrijven adopteren het dan komt het ten goede van de kennis. Veel grote systemen zijn zo gestart

[dhendriks]

De 'supervisory controller synthesis' theorie stamt uit de jaren '80. Bij de TU Eindhoven is in 2007 de CIF tooling ontstaan, dat synthese algoritmes implementeert. Sinds 2020 is de CIF tooling ondergebracht in het Eclipse ESCET open source project, bij de Eclipse Foundation, waar nu een grotere community er aan werkt. Je kunt het inderdaad zien als een framework. Het ondersteunt onder andere modelleren, synthetiseren, simulatie, model checking, en code generatie. Zie https://eclipse.dev/escet/cif/.

[Reactie gewijzigd door dhendriks op 27 maart 2025 18:59]

[Rob vd Hoeven]

Vreemd, je zou toch denken dat het aansturen van bruggen en sluizen niet zo moeilijk is. Een brug/sluiswachter hoeft geen hogere opleiding te hebben toch? Als de besturing nu al zo moeilijk is dat mensen het niet meer kunnen volgen dan wordt het met een black box methode niet beter. Integendeel.

[P_Tingen]

Het gaat juist om infrastructuur waar niemand een oogje in het zeil houdt. Dat spul moet een betrouwbaarheid hebben van 99 + heel veel negens achter de komma %. Om te weten hoe moeilijk het is om een menselijk brein na te doen - want we willen de brugwachter automatiseren - hoef je alleen maar te kijken naar hoe "makkelijk" het ontwikkelen van een zelfrijdende auto is. Ja, de eerste stap is zo gedaan, maar zorgen dat echt goed werkt is verhipte lastig

[HollowGamer]

> De software wordt vervolgens ontwikkeld door marktpartijen

Dit werkt gewoon niet, ga je echt al die 50 partijen hun source controleren? Leuk deze methode, maar het voelt toch een beetje alsof je zegt dat een auto ook goede remmen moet hebben en gordels.

[pegagus]

De marktpartij moet de machinevieligheid garanderen. Om die reden moet de marktpartij de software van de brug of sluis of tunnel schrijven.

[bzuidgeest]

Het nieuwe methode sprookje... Leuk in de manager vergadering, maar stelt (in mijn ervaring) meestal niet veel meer voor. Laten we hopen dat voor dit soort belangrijke dingen het meer voorstelt, maar ik hem mijn twijfels. Mensen zijn mensen... en de enige die er wat aan verdient is de methode-maker.