Wim Couwenberg
Embedded systemen bestaan niet meer. Een ’systeem‘ duidt een totaal aan van software- en hardwareonderdelen die samen een product vormen: desktopapplicaties, webservices, databases, lokale bedieningen, niet-realtime software en o ja, ook nog wat embedded software. Dat de embedded-wereld hier duidelijk nog aan moet wennen, blijkt wel uit de onderwerpen die actueel zijn. Die zijn veelal technisch en geven maar weinig blijk van besef van een ruimere systeemopvatting.
Techniek lijkt nog steeds het paradepaardje van embedded software. Natuurlijk vragen sommige onderwerpen speciale aandacht. Het realtime-aspect speelt een grotere rol dan op andere plekken. En een softwarecrash die tot een brandend apparaat leidt, is toch net wat pijnlijker dan een document dat nog niet was bewaard. Daar stel ik tegenover dat ieder gebied zijn eigen lastige problemen kent. Daar heeft embedded software geen monopolie op. Techniek is daarom geen onderscheidende eigenschap van het vak of, zoals soms gedacht, van de ontwikkelaar zelf.
Bovendien vervaagt op het gebied van techniek de grens tussen embedded en niet-embedded software. Embedded software zal meer en meer draaien op standaard besturingssystemen, al was het maar om op licentiekosten te besparen. Omgekeerd zal embedded vaker een processor moeten delen met niet-embedded. Denk bijvoorbeeld aan FPGA‘s met PowerPC-cores aan boord. Een algemene trend is dat embedded processoren steeds verder opschuiven richting een general-purpose architectuur. Als gevolg zullen ook softwareontwikkelmethodieken steeds verder naar elkaar toe schuiven.
In een toekomstvisie van het Amerikaanse ministerie van Defensie las ik hier een diep inzicht over: embedded software zou wel eens voordeel kunnen hebben van objectoriëntatie! Als ontwikkelingen dichter tot elkaar komen, kunnen embedded en niet-embedded profiteren van elkaars oplossingen, bijvoorbeeld op het voor iedereen lastige gebied van concurrency. Dat betekent dat we minder wielen hoeven uit te vinden, soms omdat we deze standaard kunnen inkopen maar nog meer omdat de al aanwezige kennis breder inzetbaar wordt.
Zeker de embedded-softwarearchitect kan het zich niet meer veroorloven om software te verdelen in ’wij‘ en ’zij‘. Een architect kan juist prima het systeemdenken versterken. Een concreet voorbeeld hiervan is modelvorming. Alle delen van een softwaresysteem zijn in enige vorm gebaseerd op een model van de realiteit. Een model is een kapstok om software te structureren en hanteerbaar te maken: het werkterrein van een architect bij uitstek.
Maar is er in de dagelijkse praktijk wel sprake van een systeemmodel of is ieder team een eigen werkelijkheid aan het creëren? In dat geval zijn veelbesproken modelgedreven technieken zoals domeinspecifieke talen en correctheidsbewijzen niks meer dan een dure afleidingsmanoeuvre. Het echte probleem blijkt vervolgens te zijn dat verschillende onderdelen elkaars taal niet spreken.
Een ander voorbeeld is dat wijzigingen aan de embedded component van een systeem steeds gebruikelijker worden. We wisselen immers makkelijker van platform of besturingssysteem en wellicht kunnen we sommige in-huis ontwikkelde componenten inmiddels inkopen. Bovendien bestaan binnen een productlijn vaak meerdere varianten van het embedded deel naast elkaar, bijvoorbeeld een goedkoop instapmodel en een high-end variant. De presentatie naar de klant is over de hele lijn echter zo veel mogelijk gelijk.
Met deze grotere variabiliteit zullen we rekening moeten houden op systeemniveau. Interfaces met een embedded component moeten we bij voorbaat afspreken in een bredere context om te voorkomen dat te specifiek gedrag van een enkele implementatie het systeem in sijpelt. Het voordeel is dat een grotere variatie tot een scherpere en betere architectuur leidt.
In een tijd van polarisatie is het toch een mooie gedachte om als ontwikkelaars en architecten onze labels af te werpen en samen mooie producten neer te zetten. Volgend jaar dus gewoon een conferentie ’Bits&Chips Systemen‘ graag.