Systems Engineering ‘in beweging’

Bij infrastructurele projecten wordt door partijen als Rijkswaterstaat en ProRail meer en meer gebruik gemaakt van Systems Engineering (SE). SE beschrijft de uit te voeren processen door opdrachtgever en opdrachtnemer om een project succesvol uit te voeren. Het gebruik van SE heeft een achtergrond in de Grond-, Weg- en Waterbouw (GWW). Met de opkomst van omvangrijke, integrale projecten die veelal als geheel worden uitbesteed aan marktpartijen, raakt ook de wereld van de installatie- en informatietechniek betrokken bij de SE-aanpak.

Terwijl de GWW-sector begint te wennen aan Systems Engineering, staat de wereld van de dynamische systemen nog aan het begin van de zoektocht naar de praktische toepassing van SE.

Martin van den Beukel, systems consultant bij TriOpSys, heeft de afgelopen jaren bij grote projecten van Rijkswaterstaat de nodige ervaring opgedaan met Systems Engineering. Hieronder schrijft hij over de uitdagingen in het dynamische werkveld, de gevolgde aanpak en de interacties met de andere ‘werelden’.

Uitdagingen

Mijn ontdekkingstocht begon in 2009 toen ik aan de kant van de opdrachtnemer betrokken raakte bij het ontwerp van de Tunnel Technische Installatie (TTI) voor de Leidsche Rijn Tunnel. Met een achtergrond in softwareontwikkeling heb ik samen met anderen geworsteld met de functieboom en de objectenboom volgens Systems Engineering. In de GWW-sector is een objectenboom relatief eenvoudig, want hij beschrijft slechts één soort relatie: ‘x bestaat uit y’. In het dynamisch werkveld bestaat ook een relatie als ‘x bestuurt y’. Maar zit x dan onder of boven y in de boom?

In die tijd was ook de Landelijke Tunnelstandaard (LTS) ‘in aanbouw’. Deze heeft gezorgd voor een gedragen structuur van services en functies, maar dat is geen klassieke functieboom geworden. De LTS beschrijft de TTI en behandelt het dynamische werkveld van een tunnel. In het project A9 Gaasperdammerweg (A9GDW) kreeg ik te maken met de raakvlakken van de TTI met de civiele constructie, het wegontwerp, esthetische aspecten en veiligheidsaspecten. Bij de A9GDW maakte ik deel uit van het projectteam aan de kant van Rijkswaterstaat en was de uitdaging een integraal referentieontwerp te maken.

Aanpak

Eind 2011 begon ik met een plan van aanpak om te komen tot een outputspecificatie voor de TTI. De outputspecificatie TTI maakt deel uit van de outputspecificatie voor het gehele wegtraject, met daarin een tunnel. De basis voor het plan van aanpak was het zogenaamde kookboek in de basisspecificatie TTI van de LTS.

Het principe van de aanpak lag in het maken van een verschilanalyse: wat zijn de kenmerken van de Gaasperdammertunnel en op welke van deze kenmerken is de LTS niet toereikend? Aan de hand van alle raakvlakken van de TTI met zijn omgeving heb ik de kenmerken op een rij gezet. Daarmee zat ik midden in de blauwe S-processen in de ‘Procesbeschrijving systems engineering voor RWS-projecten’, zie ook de figuur hieronder. Het werd al snel duidelijk dat de andere disciplines ook nog bezig waren; het werd een iteratief en interdisciplinair proces!

 

Schematisch weergave in kleur van de procesbeschrijving systems engineering

Figuur 1. Procesbeschrijving Systems Engineering

Dit wordt onderstreept door het Conceptueel Verkeersmanagementplan (CVMP). Om de aantallen en locaties van onder andere afsluitbomen, verkeerslichten en calamiteitendoorsteken te bepalen voor de outputspecificatie (SE-proces S6) was het nodig inzicht te verkrijgen in het wegontwerp (SE-proces S5). Hierbij heb ik gebruik gemaakt van de ‘verkeerskundige richtlijnen autosnelweginstrumentatie’. Deze fungeerde als basisspecificatie in de zin van SE-proces S2. Het wegontwerp bood onvoldoende houvast; het was nodig om te weten te komen hoe de verkeersstromen zouden lopen in de verschillende scenario’s: waar moet bijvoorbeeld het verkeer heen bij een calamiteit in de verkeersbuis voor het doorgaande verkeer in de richting van knooppunt Diemen? In het CVMP heb ik voor alle scenario’s op alle mogelijke locaties de gewenste verkeersstromen in kaart gebracht; SE-processen K1 en K3. Daaruit kon ik de aantallen en locaties van genoemde systemen bepalen en opnemen in eisen in het contract.

Gedurende het iteratieve proces heb ik in mijn ‘A9GDW TTI Systeemspecificatie’ de projectspecifieke eisen bijgehouden en voorzien van een onderbouwing door te verwijzen naar issues, besluitenmemo’s en natuurlijk het CVMP. De laatste paar versies van deze Systeemspecificatie hielden gelijke tred met de versies A t/m D van het contract. Op deze manier heb ik invulling kunnen geven aan SE-processen S7, S8 en S9.

In beweging

Bij project A9 Badhoevedorp – Holendrecht (A9BaHo) heb ik me bezig mogen houden met de specificaties van onder andere de Schipholbrug. Hier ging Systems Engineering letterlijk over beweging. Ook hier ben ik begonnen met het opstellen van een plan van aanpak. Daarbij heb ik Procesbeschrijving SE gebruikt om de uit te voeren activiteiten te beschrijven.

De producten die Procesbeschrijving SE identificeert, heb ik in het plan van aanpak toegewezen aan een beperkt aantal concrete documenten. Op deze manier verloopt het proces interactief en iteratief, maar worden de resultaten daarvan op een vaste en logische plek vastgelegd. De documentnamen zijn gebaseerd op de topdocumenten van de LTS.

In de Systeemdefinitie wordt de scope afgebakend; over welke onderdelen van het totale A9BaHo project gaat het en wat gaat het project met deze onderdelen doen? In de Systeemspecificatie worden eisen afgeleid voor de Schipholbrug. Dit gebeurt op basis van enerzijds de basisspecificaties, zoals de ‘Basisspecificatie beweegbare brug’ en de ‘Landelijke Brug- en Sluisstandaard’ (LBS) en anderzijds de specifieke kenmerken van de Schipholbrug en zijn omgeving. De specifieke kenmerken zijn verzameld in het Systeemontwerp met verwijzingen naar brondocumenten. In de combinatie van de Systeemspecificatie en het Systeemontwerp is goed het iteratieve proces te herkennen.

Tekening van ontwerp Schipholbrug en omgeving

Figuur 2. Schipholbrug binnen zijn context

Het bleek bijzonder handig werken met de vaste structuur van informatie in een beperkte set van documenten. In de loop van de tijd zijn er gespreksverslagen gemaakt, zijn acties uitgewerkt in memo’s en rapporten opgesteld. In de documenten heb ik hiernaar verwezen en de resultaten en conclusies overgenomen.

Interacties

  • Fasering – Hoe bouw je een nieuwe, grotere brug in plaats van een bestaande brug, terwijl het weg- en vaarwegverkeer door moet gaan?
  • Machineveiligheid – Wat komt er allemaal bij kijken als een brug moet voldoen aan de machinerichtlijn?
  • Prestatie – Hoe goed moet een tunnel of een brug functioneren; hoe leg je dat vast in eisen en hoe meet je dat tijdens het gebruik?

Enkele onderwerpen uit de praktijk die interdisciplinair moeten worden aangepakt met een belangrijke inbreng van en impact op het dynamisch werkveld. Op elk van deze onderwerpen zijn randvoorwaarden van toepassing, zijn uitgangspunten gekozen of opgelegd en zijn keuzes gemaakt. Elke gemaakte keuze beperkt de verdere keuzemogelijkheden en welke keuzemogelijkheden willen we vrijlaten voor de opdrachtnemer? Bij deze en andere onderwerpen heb ik een rol mogen spelen. Bijvoorbeeld door het opstellen van een Machineveiligheidsplan en de analyse van de openingstijden van de huidige Schipholbrug.

Conclusie

Binnen het dynamisch werkveld is Systems Engineering minder ingeburgerd dan in de GWW-sector. Er wordt op diverse projecten ervaring opgedaan. Het verdient aanbeveling een plan op te stellen, waarin de SE-producten worden toegesneden op de wereld van werktuigbouw, installatietechniek en software.

 

 

Share on FacebookTweet about this on TwitterShare on LinkedInEmail this to someonePrint this page