Systems Engineering (SE) draait in de kern om het omgaan met risico’s bij de complexiteit wanneer wij als mens ergens op ingrijpen: werkend vanuit de klantvraag, met integraliteit, de levenscyclus in ogenschouw, slim documenteren van de opgedane kennis en informatie.
Kijkend naar deze kernbegrippen blijf ik me vaak verwonderen bij toepassing van SE in de NLse infrastructuur. SE lijkt (te) vaak gericht op:
- eisen beheer enkel voor contracteren
- vastlegging ten behoeve van het knippen van verantwoordelijkheden
- een specialistische taak zonder relatie naar doelstelling of functie
Als sterk visueel en informatie gedreven BIM enthousiasteling ben ik bij het onderwerp Systems Engineering het meest geïnteresseerd in architectuur en modellering. Dat spreekt mij altijd meer aan dan tekstuele eisen analyse of interpretatie. Ik houdt me graag bezig met de samenhang, het houden van gezamenlijke grip op complexiteit, en het duiden van de behoefte van betrokkenen. Vanuit mijn praktijkervaring als analist in software ontwikkel trajecten maakte ik dan ook meer praktische meters met de UML toolkit en werd ik door de collega’s “de plaatjes man” genoemd.
Ik kijk, opgevoed als “virtual design & construct” BIMmer van nature naar het modelleren van de beheersbare zaken in het realisatieproces, het te ontwikkelen stuk infrastructuur, en de informatiebehoeften van de verschillende betrokkenen. Ja daar zit een bias naar het 3D geometrische model en ook het realisatieproces. Zeker ook nuttig. Echter niet alles wat langs komt over de levenscyclus van een complex stuk infrastructuur. Uiteindelijk draait het om de blik van domeinexperts, beheerders, en belanghebbenden uit de omgeving. Die hebben allen echt een andere blik op het onderwerp. Elkaar begrijpen kan vlotter en eenvoudiger met het juiste plaatje.
Het doen van SE is belangrijk om over de gehele levenscyclus en vanuit diverse perspectieven het overzicht te behouden en complexiteit te beheersen. Maar hoe voorkom je nu al die lappen tekst op het project en ga je ook om met nieuwe werkwijzen en mogelijkheden om die heel hard vaart maken en meer (niet-textuele) data gedreven zijn zoals parametrisch ontwerp en de toename van software om vanuit sensordata om keuzen te ondersteunen?
Model-based systems engineering (MBSE) biedt al jaren een toolkit daar waar technische hardware en software in een consumentenproduct wordt gestopt. Ook in de Nederlandse infrastructuur is het niet compleet nieuw. Zeven jaar geleden kwam ik er mee in aanraking in het Rijkswaterstaat Wegtunnel domein rond de tunnelstandaard. Hoewel op kleine schaal en in een omgeving met koploper(s) met een achtergrond uit andere industrieën. Ik heb van de methoden en technieken altijd wat van meegenomen en mijn eigen toepassing.
MBSE is de geformaliseerde toepassing van modellering om systeem eisen, ontwerp, analyse, verificatie en validatie activiteiten te onderneunen van conceptueel ontwerp tot en met alle andere fasen van de levenscyclus van het systeem.
INCOSE
Wanneer toegepast op de juiste wijze, helpen de methoden en technieken van MBSE omgaan met grotere maten van complexiteit zoals het dynamische gedrag ook de inpassing van nieuwe werkwijzen en technieken. Ook helpt het risico’s bekend bij technologie verminderen, omdat de werking meer duidelijk kan worden beschreven en gecommuniceerd dan met enkel natuurlijke taal. Volgorderlijkheid van functies, raakvlakken, etc. krijg je letterlijk in beeld wanneer relevant.
De definitie is vrij breed. En als je niet op past noemt iedereen zich een “model based” Systems Engineer, echter moet er wel een goede basis architectuur en toolkit beschikbaar zijn voor het managen van meer formele beschrijvingen van het systeem. Vaak is een goede impact te halen met het uitwerken van delen in stapjes over diverse losse opdracht(jes) heen met plaatjes, ofwel: “minder formele modellen”. De kunst is het juiste moment te zien te vinden. Stapsgewijs wordt dan duidelijk voor het bedrijf of de afdeling welke informatie in het model op te nemen, hoe en waartoe.
