Leven hardware en software nog langs elkaar heen of heeft software zich al een volwaardige plek verworven in mechatronica, de combinatie van mechanica, elektronica, regeltechniek en software? Link Magazine sprak met een wetenschapper over hardware en software als elkaar aanvullende rechterhanden en met hightech bedrijven over taakverdeling en samenwerking tussen de disciplines. Komt er een overkoepelende way of working en kan de digital twin een brug slaan?
Michiel Tempelaar
– ‘Het heeft te maken met de bestendigheid van een bedrijf, dat bijvoorbeeld in de huidige context succesvol is en tegelijk ook toekomstbestendig’
– ‘Je laat tegengestelde krachten samenwerken en de medewerkers maken telkens weer de afweging of er een exploitatieve of een exploratieve focus is gewenst’
– ‘Goed definiëren waar de knip ligt, is stap één. Vervolgens, stap twee, moet je heel goed synchroniseren.’
– ‘Bij grotere projecten zetten we vaak een systeemarchitect in, die over de disciplines heen kan kijken.’
– ‘We zitten nu op een kantelpunt waar agile/scrum bij ons een formele status krijgt.’
Tegenpolen of twee rechterhanden?
Michiel Tempelaar, universitair hoofddocent aan de Universiteit van Amsterdam, doet binnen Amsterdam Business School onderzoek naar strategie. Hij richt zich op ‘ambidexteriteit’, letterlijk het hebben van twee rechterhanden. ‘Het geeft aan dat iets of iemand in twee dingen even goed is. Denk aan een voetballer die ‘tweebenig’ is en daar baat bij heeft voor zijn handelingssnelheid. Het is een belangrijk concept en roept bij mensen uit de praktijk altijd herkenning op. Het heeft te maken met de bestendigheid, de levenskracht, van een bedrijf, dat bijvoorbeeld in de huidige context succesvol is en tegelijk ook toekomstbestendig. Of niet alleen in zijn oorspronkelijke markt succesvol is, maar ook in een markt die wat meer van de kern af ligt. Of neem het leren van nieuwe technologieën, dat impact kan hebben op het bestaande technologiedomein, bijvoorbeeld door de lifecycle ervan te verlengen. Uit onderzoek komt namelijk overtuigend bewijs dat organisaties die de twee componenten niet alleen naast elkaar laten staan maar ook met elkaar verbinden, een langer leven is beschoren en dat ze een hogere en consistentere performance vertonen.’ Dat lijkt strijdig met de trend van specialisatie en uitbesteden van non-core activiteiten, maar wat Tempelaar betreft blijft er ook dan ruimte voor de dynamiek van sterktes die elkaar ontmoeten en versterken – binnen zo’n specialisme van een bedrijf of in een innovatie-ecosysteem tussen bedrijven.
Stug en flexibel
Tempelaar hanteert ambidexteriteit als een containerbegrip en past het ook toe op de situatie waarin twee uiteenlopende disciplines, zoals hardware en software, binnen één organisatie samenleven. ‘Er zit natuurlijk een verschil in focus. Hardware heeft bijvoorbeeld een langere investeringshorizon, terwijl je bij software je doelen tussentijds makkelijker kunt bijstellen. Hardware is dan het ‘stuggere’ onderdeel van de organisatie, software het flexibelere. Wil je over die disciplines heen innoveren, dan zul je het stugge deel moeten samenbrengen met het flexibele. Dat vergt een soort metaorganisatie, bijvoorbeeld met crossfunctionele teams en medewerkers die circuleren tussen verschillende afdelingen of specifiek een verbindende functie hebben.’
Tegengestelde krachten
Belangrijk in Tempelaars analyse is ook het begrippenpaar exploitatie-exploratie, gekoppeld aan de korte versus de lange termijn. Exploitatie is nodig om nu resultaat te behalen, financieel en/of maatschappelijk, maar ook om middelen vrij te maken voor exploratie, of innovatie, om in de toekomst succesvol te blijven. Ze hebben elkaar dus nodig – ambidexteriteit is gevraagd – maar kunnen elkaar ook in de weg zitten: de hectiek en de efficiency-mindset die bij exploitatie komen kijken versus de vrijheid en creativiteit die exploratie vereist. Om hier kruisbesmetting te voorkomen, worden de twee – traditioneel – in verschillende organisatieonderdelen ondergebracht. ‘We spreken dan van structurele ambidexteriteit. Een postmodern concept is contextuele ambidexteriteit; je laat tegengestelde krachten binnen één afdeling samenwerken en de medewerkers maken telkens weer de afweging of er een exploitatieve of een exploratieve focus is gewenst. De rol van het management is hier belangrijk, voor het creëren van een context waarin tegengestelde krachten samenkomen: de eigen discipline, ondersteuning, vertrouwen en stretch. Stretch wil zeggen dat er ruimte is om op zoek te gaan naar nieuwe kennis en om zaken buiten de gebaande paden te verkennen. Als er vertrouwen is, kunnen hardware- en software-engineers samenkomen en preconcepties over elkaar aan de kant schuiven om de zaak van een andere kant te bekijken. Zeker voor een kleine organisatie kan dit interessant zijn, want het maakt snel schakelen mogelijk.’
De fysieke radar, de hardware, is zeker geen commodity, benadrukt Gerben Pakkert van Robin Radar Systems, maar software is wel in de lead voor innovatie.
‘Kleine’ radar, ‘schoon’ signaal
Robin Radar Systems in Den Haag, in 2010 uit TNO voortgekomen, ontwikkelt radaroplossingen voor het detecteren van kleine objecten, zoals vogels en drones. Het technologiebedrijf bedient drie internationale markten: windenergie, luchtvaart en defence & security. In de eerste twee groeit Robin inmiddels uit tot system integrator, maar de focus blijft liggen op technologieleiderschap. Grote technologische uitdaging is het voorkomen van ruis in de radarbeelden, vertelt r&d-directeur Gerben Pakkert. ‘Met onze radar kijken we naar heel kleine dingen die normaliter in de ruis van de radar wegvallen. De kleinste verstoringen, zoals regen, bewegende boomblaadjes of stoorsignalen in de radarcomponenten, kunnen er dan al voor zorgen dat je de propellers van een drone of een kleine vogel niet meer ziet. We moeten dus zorgen voor een ‘schoon’ signaal, met een hoge signaal-ruisverhouding. Daarbij gaat het er niet zozeer om hoever we kunnen kijken, als wel hoe goed de dekking is. Een sterke radar kan nog steeds niet achter een gebouw kijken. Wij werken daarom meer in een genetwerkte set-up en met mobiele, human portable systemen, om met meerdere radars een gebied goed af te dekken.’
Hardware mag nieuwe software eisen
De fysieke radar, de hardware, is zeker geen commodity, benadrukt Pakkert, maar software is wel in de lead voor innovatie. Want Robin onderscheidt zich met de software voor beeldbewerking en -classificatie voor het herkennen van vogels en drones. Overigens rekent hij – grenzen vervagen – de embedded software voor de besturing juist tot de hardware. ‘Wij leggen de knip bij het ruwe beeld dat uit de radar komt. Die doet al wat preprocessing en daarna gaat het beeld naar software voor de echte beeldbewerking.’ Dat vergt in ontwikkeling natuurlijk de nodige afstemming. Pakkert: ‘Goed definiëren waar de knip ligt, is stap één. Vervolgens, stap twee, moet je heel goed synchroniseren: bij een nieuwe ontwikkeling steeds kijken of die backward compatible is met welke versie van de hardware en van de software. Het managen van versies is extreem belangrijk. Hardware beweegt het langzaamst (qua nieuwe versies, red.), dus die moet future proof zijn. Nieuwe software moet altijd kunnen draaien op bestaande hardware, terwijl nieuwe hardware wel een nieuwe softwareversie mag vereisen. Dit bepaalt ons testbeleid; we moeten oude versies van de hardware beschikbaar houden om daarop nieuwe softwareversies te kunnen testen.’
Software wilde sneller
Als technologiebedrijf heeft Robin een relatief grote r&d-organisatie: van de 75 medewerkers zitten er ruim twintig in r&d, 50/50 verdeeld over een software- en een hardwareteam. Beide disciplines volgen in ontwikkeling hun eigen, bekende methodiek: voor hardware stage-gate en voor software agile/scrum. Bij stage-gate verloopt de ontwikkeling in goed gedefinieerde fases (stages) met telkens een beslispunt aan het eind (gate). Bij agile/scrum werken multidisciplinaire teams in korte sprints aan een ontwikkeling, om daarna te evalueren, bij te sturen en de volgende sprint aan te gaan. De indeling in een software- en een hardwareteam dateert van de reorganisatie die Pakkert eind vorig jaar doorvoerde. ‘Ik had een indeling naar conceptuele ontwikkeling, hardware en software door elkaar heen, tegenover meer detailgerichte engineering. Aanleiding voor de aanpassing was het ritme in ontwikkeling. Onze softwaremensen hadden behoefte aan versnelling, om te kunnen werken in een ritme van sprints van drie weken. Terwijl het radarteam maximaal één of twee releases per jaar heeft van een nieuw productontwerp. Die behoefte lag zover uit elkaar dat het lastig te managen was, met ontwikkelmijlpalen die volledig los van elkaar stonden. Ook de cultuur verschilde: softwareontwikkelaars zijn van karakter anders dan radarmensen. Wel heb ik de r&d-mensen op kantoor bewust op dezelfde plek als voorheen laten zitten, door elkaar heen. Dit om de integratie te bevorderen en muurvorming tegen te gaan.’
Kruisbestuiving bevorderen
Er is veel te zeggen voor zo’n scheiding, reageert onderzoeker Tempelaar. ‘Want je kunt mensen gerichter aansturen als je gespecialiseerde afdelingen hebt. Het gaat wel ten koste van de overkoepelende wendbaarheid en het aanpassingsvermogen, en je loopt het risico dat je subculturen creëert en barrières opwerpt tussen afdelingen.’ Mensen door elkaar heen laten zitten, kan dan inderdaad een goed idee zijn, vindt hij. ‘De informele contacten tussen medewerkers zijn minstens zo belangrijk als, zo niet belangrijker dan, de formele hiërarchie en functie-indeling. In een projectgeoriënteerde organisatie bijvoorbeeld heb je formeel tijdelijke samenwerkingsverbanden, maar informeel blijven relaties bestaan. Als de hardware- en software-afdeling in dezelfde ruimte werken, blijven de informele contacten bestaan. Die kunnen zorgen voor kruisbestuiving (zoals afstemming en uitwisseling van ontwerpideeën, red.), terwijl er tussen de formeel verschillende afdelingen geen kruisbesmetting (wrijving vanwege de verschillen in ontwikkeltempo, red.) meer is.’
Tot nu toe is Pakkert enthousiast over de nieuwe structuur van de r&d-organisatie. ‘Het regelen van versie-afstemming en het bepalen van de grens tussen de twee teams blijft uitdagend. Maar ik zie wel dat, zeker in het softwareteam, de capaciteitsplanning en voorspelbaarheid van wat we de komende periode gaan doen, zijn verbeterd. Er is ook meer focus op wat moet worden opgeleverd, de klantbehoefte dus. In het radarteam zie ik wat meer fundamentele verbetering in de aanpak van r&d. Parallel hieraan moeten we het productmanagement en product ownership nog versterken, voor die betere klantfocus, zeker in het softwareteam, terwijl we bij de radarontwikkeling toch meer technology push zien.’ Over ambidexteriteit gesproken. ‘De klant vraagt niet om radar maar om informatie. De productmanager moet zorgen voor technology pull bij de klant, maar die weet niet wat hij over vijf jaar wil. Daarom zullen de langetermijnontwikkelingen in de hardware technology push blijven. Die balans is best spannend: er komen veel vragen uit de markt, maar we moeten ook ons technologieleiderschap behouden en daarvoor ook werken aan de fundamentelere ontwikkelingen die over vijf jaar een game changer zijn.’
Over de disciplines heen kijken
Interactie, formeel en informeel, tussen de disciplines – van elektronica-hardware tot embedded software – is ook cruciaal voor de ontwikkeling van complexe regelsystemen bij 3T. Aldus technology manager Bert van den Berg, verantwoordelijk voor nieuwe technologieën, roadmapping en interne kennisspreiding. 3T ontwikkelt en produceert klantspecifieke elektronica en embedded systemen voor markten als hightech machinebouw, medische technologie en defence & security. Het bedrijf (100 medewerkers) heeft vestigingen in Enschede en Eindhoven, en is sinds vorig najaar onderdeel van Kendrion.
In complexe regelsystemen zijn de oplossingen voor actuatoraansturing en data-acquisitie vaak kritisch in hun timing van acties, verklaart Van den Berg. ‘Het design van de elektronica en embedded software is dan altijd een optimum tussen kosten, stroomverbruik (efficiëntie) en functioneel gedrag. Voor optimalisatie, inclusief de keuze van elektronicacomponenten, is interactie tussen de disciplines echt nodig, om te zorgen dat wel het gewenste timinggedrag wordt behaald. Naast hard- en software werken we ook met fpga-technologie (high-performance programmeerbare logica, red.) en LabVIEW (grafische programmeeromgeving voor meet- en regeltechniek, red.). En bij klanten hebben we vaak ook met mechanica te maken.’ Reden waarom 3T interactie tussen de disciplines actief bevordert. ‘Wij vinden het belangrijk dat onze mensen over de grenzen heen kunnen kijken. Onze hardware-engineers hebben recent nog deelgenomen aan een programmeertraining, terwijl nagenoeg alle software-engineers bij 3T een elektrotechniekachtergrond hebben. Voor interne kennisspreiding werken wij met competence officers die regelmatig overleg hebben en 3T-brede presentaties geven. Bij grotere projecten zetten we vaak een systeemarchitect in, die goed over de disciplines heen kan kijken en over en weer kan communiceren. Die architect komt meestal uit de hardwarediscipline (elektronica), die vaak de basis van ons systeem vormt van waaruit de link met enerzijds de mechanica en anderzijds de software het makkelijkst is te leggen.’
Interfacing en integratie
Succes begint bij een goede voorbereiding en dus wordt bij 3T het vastleggen van afspraken tussen de disciplines steeds belangrijker. ‘Al bij de projectstart bespreken we samen de requirements en maken een verdeling over de disciplines: waar kunnen we welke requirement het beste oplossen, in hardware, software of in een fpga die als programmeerbare hardware wordt gezien? Dat is naast een functionele ook een kosten-batenafweging, voor de hardwarecomponenten en de benodigde ontwikkelinspanningen.’ Uiteraard komt daarbij de interfacing aan de orde, tussen de disciplines en tussen de embedded software die 3T ontwikkelt en de applicatiesoftware die de klant meestal voor z’n rekening neemt. Overigens is er op hardwaregebied wel steeds meer integratie van technieken. Zo kan in een system-on-chip-oplossing een fpga worden geïntegreerd, die zelf weer meerdere processorblokken kan bevatten die afzonderlijk worden geprogrammeerd. ‘Nieuwe geïntegreerde oplossingen bieden meer mogelijkheden om timingproblemen op te lossen. Dat er steeds meer wordt geïntegreerd, betekent niet dat we minder disciplines nodig hebben. De elektronica wordt steeds kleiner en compacter, maar er zit voor alle disciplines nog heel veel werk in. De hoeveelheid werk per vierkante centimeter neemt alleen maar toe.’
Model-driven design
Een belangrijke impuls voor de samenwerking tussen disciplines komt van model-driven design, signaleert Van den Berg. ‘Een software-engineer, elektronicus of mechanicus kan een model van het te ontwerpen (deel)systeem maken om het gedrag ervan te simuleren en code voor de besturing te genereren. Een stap verder is een systeemmodel waarin verschillende disciplines samenkomen. De submodellen kunnen worden gemaakt door experts in de betreffende disciplines en – omdat iedereen dezelfde ‘taal’ spreekt – eenvoudig worden samengevoegd tot een systeemmodel. Zo kunnen engineers uit de verschillende takken van sport, aan de hand van dit model, makkelijker met elkaar overleggen en de uitkomst daarvan vertalen naar hun eigen discipline. Deze experts kunnen onze eigen engineers zijn, maar soms ook een (kennis)toeleverancier of de eindklant. Op deze manier kunnen we het gat tussen bijvoorbeeld software en de mechanische discipline, die we zelf niet in huis hebben, behoorlijk dichten. Omgekeerd maakt het gebruik van standaardhardware, zoals de ‘ingrediënten’ die we bij 3T hebben ontwikkeld, het makkelijker om de brug naar software te slaan. De software-engineer hoeft dan niet meer alles van de hardware te weten, maar kan die wel functioneel bij zijn ontwerp van de software betrekken; zo kan hij veel meer als architect optreden. Het model kan ook worden gebruikt voor de interfacing tussen disciplines.’
Time-boxed
Bij Demcon speelt de hardware-softwarediscussie vooral binnen Demcon advanced mechatronics. Met ruim 500 medewerkers en locaties in Best, Delft, Enschede en Maastricht is dat verreweg het grootste bedrijf binnen de Demcon group (1.000 medewerkers). Het legt zich toe op mechatronica, de combinatie van mechanica, elektronica, regeltechniek en software. Van oudsher was de positie van software wat ondergeschoven, ook bij Demcon, zegt Sjaak Maalman, teamleider software in Best. ‘Het wordt beter, maar we zijn vooral dienstig aan de mechatronica. We hebben ook software-only projecten, maar de grote projecten zijn toch wel mechatronica. Vroeger werd software er meestal te laat bijgetrokken. Nu gebeurt dat wel eerder en dat is goed, want veel dingen kunnen wij oplossen in software.’
‘Nieuwe geïntegreerde oplossingen bieden meer mogelijkheden om timingproblemen op te lossen’
‘Er moet wel telkens een eindpunt zijn gedefinieerd in termen van mijlpalen. Ik weet dat dit vloeken is voor agile/scrum-puristen, maar qua risicobeheersing en testen is dat nodig’, aldus David Rijlaarsdam van Demcon. Foto: Demcon
In Link Magazine sprak David Rijlaarsdam, businessunitmanager artificial intelligence bij Demcon, al eerder over de uitdaging om agile softwareontwikkeling in te passen in het klassieke stage-gate ontwikkeltraject van mechatronische projecten. Een aantal grote software/AI-gedreven projecten is al helemaal agile/scrum uitgevoerd, vertelt hij nu. ‘We zijn zelfs echt time-boxed gaan werken, waarbij we met de klant hadden afgesproken dat we elke week iets zouden opleveren, maar niet wat precies. Iedere week opnieuw besloten we wat dat iets was en dat ging heel goed. Andere projecten hebben we deels op basis van agile/scrum uitgevoerd, vooral omdat de requirements vooraf nog niet goed bekend waren. We zitten nu op een kantelpunt waar agile/scrum bij ons een formele status krijgt en we met coaches en een competentiegroep voor deze methodiek gaan werken. Bij projecten die software- of AI-gedreven zijn, is het logisch om hiervoor te kiezen.’
Rollen en bruggen
Voor de grote mechatronicaprojecten, waarin ook hardware een belangrijke rol speelt, onderzoekt Demcon een mix van stage-gate en agile/scrum in de ontwikkelmethodiek. ‘Daarbij moet wel telkens een eindpunt zijn gedefinieerd in termen van mijlpalen. Ik weet dat dit vloeken is voor agile/scrum-puristen, maar qua risicobeheersing en testen is dat nodig. We zijn hierin nog lerend’, benadrukt Rijlaarsdam. ‘We voeren nu de discussie hoe we onze traditionele way of working, waarin we het bekende V-model (van concept en specificatie via ontwerp en realisatie tot validatie, red.) volgen, kunnen combineren met de agile werkwijze. Liefst leggen we aan het begin van elk project vast welke werkwijze er het beste bij past. Hoe verhouden de agile/scrum-rollen – van de scrum master die het ontwikkelproces bewaakt en de product owner – zich tot de rollen die we al kennen, zoals die van de mechatronic system engineer, of systeemarchitect?’ Kan die system engineer ook de rol van product owner pakken, vraagt Rijlaarsdam zich af, daarmee de figuur aanwijzend die – samen met de projectmanager – de brug tussen hardware en software zou kunnen slaan. ‘Daar ligt bij ons de zwaarste discussie.’
Digital twin nog niet volwassen
En het denken gaat alweer verder. Maalman: ‘We zoeken naar manieren om ook hardwareontwikkeling scrumachtig aan te pakken.’ Want kan het klassieke beeld van trage hardware- en snelle softwareontwikkeling niet kantelen omdat hardware steeds meer virtueel wordt ontwikkeld en getest? Dat zou immers veel sneller kunnen werken dan fysieke prototyping. De digital twin komt dan voorzichtig in beeld. ‘Daar werken we nog niet veel mee. Natuurlijk maken we in Matlab/Simulink (data analytics en model-based design, red.) een model van ons ontwerp om er een regeling voor te ontwerpen en software op te testen. Maar van een echte digital twin is pas sprake als je het gehele systeem virtueel beschikbaar hebt en alles van een complexe machine goed kunt modelleren. Dat lukt al wel voor de regelaar maar nog niet voor het complete fysische gedrag.’ Een deel daarvan zit natuurlijk al wel in die regelaar verwerkt, merkt Rijlaarsdam op, en expliciete modellering van de fysica gaat soms ook al best ver. ‘Zoals bij onze beademingssystemen, waar de fysica van slangen en luchtstromingen letterlijk in de digital twin zit. Wat ik bij ons juist nog niet vaak zie, is dat we een digital twin maken om de software snel en efficiënt vroeg in het ontwikkeltraject te kunnen testen. Misschien zou dat wel gebeuren als we alle tijd en geld van de wereld hadden (om zo’n digital twin te bouwen, red.).’ Grote oem’ers vragen ook nog niet om een complete digital twin. Voor hun complexe machines is de inspanning nog te groot, verklaart Maalman. ‘Wel moeten we nu soms achteraf een digital twin bouwen, voor het onderhoud. Dat is om te zorgen dat machines geen stilstand hebben als je software-updates uitvoert, doordat je de nieuwe software eerst op de digital twin test. Dit staat nog wel in de kinderschoenen.’
Link magazine editie juni 2022 | jaargang 24 thema: Hoe slaan we de brug tussen de software- en de hardware-engineers? Lees Link digitaal of vraag een exemplaar op: mireille.vanginkel@linkmagazine.nl’
Synthetische data
De meeste business hier haalt Demcon nu uit een speciale vorm van digital twinning die het als losse service aanbiedt. Het betreft het genereren van synthetische data van sensorsystemen, bijvoorbeeld camerabeelden, voor het trainen van AI-algoritmes. Dat slaat niet zozeer een brug tussen hard- en software, maar verschuift veel meer de balans van hard- naar software, door de opkomst van AI. Mede daarom zit binnen Demcon de grootste groei in software-engineering, zo smokkelt Rijlaarsdam nog even de grote arbeidsmarktuitdaging het interview binnen. ‘We zoeken heel veel software-engineers.’
Hoe slaan we de brug tussen de software- en de hardware-engineers?
Software heeft in de machine- en apparatenbouw enorm aan belang toegenomen. Niets werkt meer zonder. Nu valt software gemakkelijk aan te passen en is dat bij hardware een stuk lastiger. Maar betekent dat automatisch dat de software-engineers zich moeten conformeren aan het werk van hun hardwarecollega’s? Hoe zorg je dat ze elkaar versterken? Hoe voorkom je dat mechanici of elektronica-engineers iets bedenken wat softwarematig niet te besturen valt? Of dat die robotarm ineens niet meer kan doen wat nodig is omdat er – zonder terugkoppeling – nog éven aan de software gesleuteld is? Hoe zorgt een bedrijf dat het werkelijk ‘tweehandig’ wordt? Zijn daar (software-)tools voor? En, geldt dat spanningsveld alleen tussen hard- en software, of zijn er veel meer interdisciplinaire bruggen te slaan?
