Efficiënt werken met een gestandaardiseerde taal

Bij nieuwe ontwikkelingen passen engineers vaak beproefde ontwerpen toe, al dan niet met kleine aanpassingen. Waarom lukt het dan toch niet om oplossingen te leveren waar klanten om vragen? Niet zelden is communicatie het grote struikelblok. Eric Burgers legt uit hoe SysML helpt om ontwerpideeën voor complexe systemen succesvol over te brengen.

Eric Burgers

In een ideale situatie begint een project met perfecte eisen: ondubbelzinnig, specifiek en nauwkeurig, en precies genoeg om het op te lossen probleem te beschrijven, met voldoende vrijheid voor creativiteit en innovatie. De ontwerpen die hieraan voldoen, zijn compleet, specificeren de ontbinding, het gedrag en de samenwerking volledig, zijn 100 procent consistent en in alle opzichten toetsbaar. Uiteindelijk wordt een systeem opgeleverd dat voldoet aan de eisen en het beoogde gebruik kan vervullen.

In een nachtmerrieversie vertrekt een project van inconsistente of tegenstrijdige eisen, met uitdrukkingen als ‘het systeem zal een … faciliteren’ of ‘bijdragen aan …’ De systeemgrens is moeilijk vast te stellen. Het geheel is ontleed in vage onderdelen, zoals (categorieën van) apparaten of zelfs willekeurige groepen van ‘dingen’. Gewenst gedrag lijkt, indien gespecificeerd, los te staan van het ontwerp of is feitelijk onvolledig, waardoor er veel ruimte is voor interpretatie. In de ultieme nachtmerrieversie van een project wordt een systeem gebouwd dat niet gebaseerd is op het eigenlijke ontwerp. Herstel van defecten gebeurt door notitie op notitie te stapelen, waardoor het ontwerpdossier een absolute puinhoop wordt. Alleen wanneer alles wordt gelezen in de juiste volgorde, kan het daadwerkelijk gemaakte ontwerp worden afgeleid.

De meeste projecten zijn geen complete nachtmerries, maar ook niet ideaal. Gemaakte ontwerpen voldoen niet altijd aan alle eisen en kunnen inconsistenties, omissies of andere defecten bevatten. Deze gebreken zijn een potentiële bron van faalkosten: defecten geïntroduceerd tijdens de eisenanalyse of het ontwerp worden duurder om te repareren naarmate ze later worden opgelost. En dat terwijl ze voorkomen hadden kunnen worden.

Een ontwerp is juist bedoeld om het risico op het bouwen van verkeerde of gebrekkige systemen te verkleinen. Toch creëren projecten heel vaak ontwerpen die niet voldoen aan de eigenlijke eisen. Hoe komt dat en wat is eraan te doen?

Bottom-upbenadering

Projecten zijn er in alle soorten en maten en lossen eenvoudige tot uitdagende problemen op. Relatief simpele, kleine projecten zijn niet al te moeilijk tot een goed einde te brengen. Het risico op mislukking neemt toe naarmate een project ingewikkelder wordt. De complexiteit van een project hangt samen met de complexiteit van het product dat wordt gemaakt (in omvang of moeilijkheidsgraad) en de grootte van de organisatie die het product maakt.

Grote(re) projecten zijn vaak georganiseerd in disciplinespecifieke ontwikkelgroepen. Deze groepen bespreken hun onderlinge interfaces wel met elkaar, maar er is meestal geen overkoepelende benadering om te beschrijven hoe alle onderdelen moeten worden geïntegreerd tot één werkend geheel. Soms lijkt het er zelfs op dat interfaces ad hoc tot stand komen.

Dit heeft alle kenmerken van een bottom-upbenadering, waarbij disciplinespecifieke onderdelen eerst worden ontworpen en geproduceerd en vervolgens worden geassembleerd in de hoop een werkend product te krijgen. Zo’n aanpak werkt misschien voor minder gecompliceerde projecten waar engineers het hele product met al zijn details kunnen begrijpen. Wanneer onderdelen elkaar kunnen beïnvloeden via hun gedrag of eigenschappen, kan het echter moeilijk zijn om te beoordelen hoe het geheel zich zal gedragen, vooral als de bouwstenen afkomstig zijn uit verschillende disciplines.

Tekeningen

Een manier om met grote, complexe projecten om te gaan, is het maken van uitgebreide documentatie om ontwerpideeën te verspreiden onder alle betrokken engineers. In technische domeinen zoals de werktuigbouwkunde, software-engineering, industriële automatisering en civiele techniek zijn daar vaak gestandaardiseerde manieren voor. In de praktijk wordt de documentatie aangevuld met tekeningen gemaakt in populaire tools als Powerpoint of Visio (Windows) of Omnigraffle (Mac OS). Daarnaast wordt Excel ingezet om grote hoeveelheden informatie uit te wisselen.

In multidisciplinaire projecten neemt het gebruik van aanvullende tekeningen en andere projectspecifieke tools toe om de kloof tussen disciplines te overbruggen. Hiermee is in principe niks mis: de overdracht van ontwerpideeën en informatie tussen disciplines is hard nodig. Zonder een dergelijke overbrugging zal een project onherroepelijk op ernstige integratieproblemen stuiten. ‘Projectspecifiek’ betekent echter ook herhaaldelijk het wiel uitvinden, vooral wanneer het werk wordt uitgevoerd door consortia die van project tot project veranderen.

Een ander probleem van deze tekeningen is dat er geen algemene afspraak is over wat ze zouden moeten weergeven. Bovendien is er geen garantie dat ze compleet en consistent zijn. Daardoor is er een reëel risico dat de tekeningen, hoewel duidelijk voor de auteur, door de lezers verkeerd worden geïnterpreteerd, wat dan weer leidt tot defecten in het product die pas in latere stadia van het project worden ontdekt.

Heel vaak worden deze manier van werken en de daarmee gepaard gaande integratieproblemen gewoon geaccepteerd. Wanneer het project de opleverdatum nadert, worden de problemen opgelost door veel herwerk of patches of ze worden simpelweg in het project achtergelaten als ‘toekomstig werk’. Een alternatieve benadering is om de communicatie van ontwerpideeën te standaardiseren per project of zelfs bedrijfsspecifiek. Dit heeft als nadeel dat de conventies ‘lokaal’ zijn voor het project dat wordt uitgevoerd – elke deelnemer zal ze moeten leren.

Verstandiger is het om een industriestandaard aan te nemen, inclusief ondersteunende tools. Dan hoeven de conventies slechts eenmalig te worden geleerd om vervolgens vele malen te kunnen worden toegepast, onafhankelijk van het project of de organisatie. Helemaal mooi is het als de standaard de mogelijkheid biedt om documenten en tekeningen te vervangen door één bron van waarheid die altijd up-to-date is.

Modelleertaal

De complexiteit van projecten, of technologie in het algemeen, neemt alleen maar toe. Denk aan het verschil tussen de eerste telefoons en de smartphones van tegenwoordig. Of aan de eerste auto’s en de voertuigen die vandaag de dag op de weg te zien zijn. Hoewel de hoofdfunctie hetzelfde is gebleven (communiceren, rijden), worden de systemen van nu meer en meer geïntegreerd in een groter geheel om de gebruikers aanvullende diensten te bieden die niet door de systemen zelf kunnen worden geleverd. Deze trend is geïdentificeerd en beschreven in vele bronnen, waaronder de visiedocumenten van Incose – Vision 2025, en meer recent Vision 2035.

Om de toenemende mate van integratie aan te kunnen, bevordert Incose de overgang naar modelgebaseerde systeemengineering (MBSE). Hierbij worden modellen gebruikt om complexe systemen te ontwerpen en te verifiëren. Een van de eerste stappen naar MBSE is de adoptie van een taal die geschikt is om dergelijke modellen te bouwen. SysML is zo’n taal.

De Systems Modeling Language (SysML) is een modelleertaal voor algemeen gebruik die is ontworpen om engineers te helpen bij het ontwikkelen en documenteren van complexe systemen met een groot aantal componenten. De taal wordt veel toegepast in sectoren als de lucht- en ruimtevaart, automotive, infrastructuur en defensie. De geboden grafische notatie maakt de weergave van verschillende soorten systemen en hun gedrag mogelijk, evenals hun interacties met de omgeving. Zo kunnen engineers hun ideeën effectief en efficiënt communiceren en ervoor zorgen dat alle betrokkenen bij het ontwikkelproces hetzelfde begrip hebben van het te bouwen product. Doordat de taal niet disciplinespecifiek is, kunnen systemen op een overkoepelend niveau worden beschreven.

Verhoogde precisie

Bij het gebruik van SysML is het eerste dat opvalt dat de ontwerpen nauwkeuriger zijn en dus extra werk vergen om te voltooien. Die precisie zorgt er echter ook voor dat alle betrokkenen de ontwerpen op dezelfde manier kunnen interpreteren als de auteur en dat defecten en weglatingen veel gemakkelijker zijn te herkennen en te ondervangen. Doordat het bijna onmogelijk is om een inconsistent ontwerp te maken, worden faalkosten voorkomen. Als deze kosten hoger zijn dan de initiële investering, is er een businesscase voor het gebruik van SysML.

De invoering van SysML kan overkomen als een hele klus. Op het eerste gezicht kan het een flinke uitdaging lijken om een compleet complex systeem te gieten in een model dat geschikt is voor analyse en simulatie. In de praktijk is de overgang vaak stapsgewijs en passen organisaties SysML geleidelijk steeds meer toe om ontwerpen te beschrijven. Langzaam maar zeker worden documenten vervangen door modellen en views op modellen, tot er op de hogere niveaus van volwassenheid helemaal geen documenten meer zijn omdat alle informatie is gevat in modellen.

SysML is wel een uitgebreide taal. Daardoor kost het tijd om alle details onder de knie te krijgen. Een goede training zal de adoptie aanzienlijk versnellen. Engineers zullen zeker ook moeten wennen aan de verhoogde precisie waarmee ontwerpen vanaf het begin worden gemaakt. Eenmaal succesvol geadopteerd, zal SysML de communicatie over en de kwaliteit van de ontwerpen verbeteren.

Bij specificaties met veel geometrische informatie, zoals vaak gemaakt in de civiele techniek, is SysML minder effectief. De taal leent zich vooral voor cyber-fysieke, software-intensieve systemen. Een mooi voorbeeld is een infrastructuurproject in Amsterdam-Zuid, waar de ontwerpen zijn gemaakt door de leverancier en beoordeeld door de overnemende partij. Hier heeft het gebruik van SysML gezorgd voor een aanzienlijke toename van de ontwikkelsnelheid, waarbij het aantal gevonden defecten aanzienlijk lager was dan gemiddeld. Ook elders bewijst SysML dat het nachtmerries kan voorkomen en projecten dichter bij de ideale situatie kan brengen.

Eric Burgers is een ervaren technisch manager, systeemengineer en trainer. In de trainingen Introduction to SysML (1 dag) en System modeling with SysML (4 dagen), georganiseerd door High Tech Institute maakt hij deelnemers wegwijs in SysML en de verschillende modelleertechnieken die de taal biedt.

1. Structuur: systemen kunnen worden gedecomponeerd in kleinere onderdelen, die interfaces hebben met elkaar.
2. Gedrag: er kunnen drie soorten gedragingen worden gespecificeerd (flow-, event- en berichtgebaseerd) en aan elkaar gerelateerd.
3. Requirements: systeemeisen en hun tests kunnen worden vastgelegd.
4. Parametrics: eenmaal beschreven, kunnen systemen ook worden gesimuleerd.