Grotere embedded systemen zijn zeer moeilijk om te maken. Niet alleen omdat de software moeilijk is, maar vaak omdat systemen fysiek ook interacteren met elkaar en de fysieke omgeving. Toch zien we juist dáár vaak een houding van ’dat knopen we wel even aan elkaar‘, zonder dat er vooraf goed wordt nagedacht over de consequenties. In dit artikel laten Sander van den Berg en Jaap van Ekris van DNV zien dat er grenzen zitten aan dit denken, en dat we beter moeten én kunnen.
Embedded software heeft een gigantische ontwikkeling meegemaakt: hadden we vroeger alleen het relais, nu hebben we PLC‘s die vele desktops achter zich laten. Dit opent grote mogelijkheden voor betere systemen en stelt ons zelfs in staat dingen te besturen waar de mens niet meer toe in staat is. Sommige schepen en vliegtuigen zijn bijvoorbeeld niet meer zonder tussenkomst van een computer te besturen omdat de benodigde reactietijd en beslissingscomplexiteit niet meer door mensen geleverd kunnen worden, hoe goed geselecteerd ook.
Wat we ook zien, is dat er een noodzaak ontstaat tot integratie. Vanuit technisch oogpunt is het nodig deelsystemen te integreren om te voorkomen dat deze beslissingen nemen die het hele systeem schaden. Daarnaast is integratie ook wenselijk vanuit de ergonomie: veel gescheiden systemen leiden tot vele (losstaande) interfaces, wat zeer omslachtige besturingen oplevert en een verlammende werking heeft op de besluitvaardigheid bij échte problemen. Een voorbeeld is een Noors passagiersschip dat 28 beeldschermen op zijn redelijk kleine brug had staan voor de primaire besturing. Elk systeem had zijn eigen interface en alarmering. Als er echt wat gebeurt, weet je als bestuurder niet waar je moet kijken en ingrijpen.
Twaalf jaar ploeteren
De huidige techniek staat ons gelukkig toe veel te integreren, zodat we eerder genoemde problemen kunnen vermijden. Integratie is echter niet zonder risico‘s, zeker als de fysieke wereld een rol gaat spelen. Er zijn veel voorbeelden bekend van geïntegreerde systemen waar een kleine fout (bijna) tot catastrofale gevolgen heeft geleid. Zo is er het Virgin Atlantic-vliegtuig dat in 1994 tijdens de landing op Heathrow vrijwel onbestuurbaar werd door een klein probleem in het brandstofmanagementsysteem. Ander voorbeeld is de USS Yorktown, die tijdens een gevechtsoefening volledig stilviel door een database die één verkeerde waarde bevatte. Geïntegreerde systemen beschermen zich nauwelijks tegen verkeerd gedrag van deelsystemen, wat ze erg kwetsbaar maakt.
Het grote risico is echter dat het geheel zo complex en onoverzichtelijk wordt dat we er gewoon niet meer uitkomen. Dat is het punt waarop een verzameling goed gebouwde componenten niet meer automatisch een goed systeem vormt. Dat is ook het punt waarop de bestaande aanpak van ’schouders eronder en veel on-site verbeteringen‘, beter bekend als on-site integration and complete redesign, ophoudt te werken en we eindigen met een geïntegreerde chaos.
Het bekendste voorbeeld van dit werkmodel is de bagageafhandeling van Denver Airport. BAE nam een project aan waar de gebruikelijke aanpak niet meer effectief was. De gevolgen waren desastreus: de oplevering van het vliegveld was een jaar later dan gepland (à 1 miljoen dollar per dag aan gemiste inkomsten) en bij oplevering kon het slechts de helft van de vooraf geplande capaciteit aan. Daarboven werden de koffers simpelweg niet meer afgehandeld. Denk aan de chaotische opstart van Terminal 5 op Heathrow, maar dan als dagelijkse routine gedurende twaalf jaar. Na twaalf jaar ploeteren met een groot aantal experts bleek dat de fysieke installatie softwarematig niet te besturen was en het waarschijnlijk ook nooit zal worden, waarna de volledige installatie is afgeschreven. Naar schatting bedraagt de totale schade anderhalf miljard euro.
Dit lijken excessen, maar als we kijken naar veel embedded-softwareprojecten, dan zien we dat daar dezelfde factoren aanwezig zijn die de hiervoor genoemde problemen veroorzaken. Eén van de belangrijkste is het gebrek aan een goede basisarchitectuur: we beschrijven en valideren niet vooraf hoe het geïntegreerde systeem moet functioneren en wat de exacte rol van de componenten daarin hoort te zijn. De basisgedachte lijkt nog steeds te zijn dat alle problemen zijn op te lossen door veel on-site te debuggen. Het aantal projecten waar toeleveranciers elkaar en hun systemen voor het eerst ontmoeten tijdens de integratie op het uiteindelijke fysieke systeem is eindeloos.
Verschillende invalshoeken
De oplossing is niet gemakkelijk, maar gelukkig bestaan er hulpmiddelen om het integratieprobleem te vereenvoudigen. Een van de belangrijkste is het toepassen van architectuurviews. De logische view beschrijft de functionele systeemonderdelen en de randvoorwaarden voor het goed functioneren hiervan. De ontwikkelview geeft de organisatie van de software tijdens de ontwikkeling in termen van pakketten broncode, gebruikte bibliotheken, compilers, linkers en de onderlinge afhankelijkheden daartussen. De procesview beschrijft alle actieve processen gedurende executie, inclusief alle benodigde communicatie, synchronisatie, redundantie en concurrency-controle. De fysieke view geeft de hardware-infrastructuur (PLC‘s, servers en netwerken) en de allocatie van de runtime onderdelen daarop. De use-caseview met scenario‘s biedt inzicht in de samenhang tussen de verschillende componenten om tot een specifieke beslissing te komen.
Door dergelijke views te introduceren, scheppen we duidelijkheid over welke component waarvoor verantwoordelijk is, welke eisen eraan worden gesteld en hoe interacties verlopen. Hierdoor is het ook mogelijk vooraf het globale gedrag van het complete systeem te simuleren, wat bijvoorbeeld met de huidige generatie van bagageafhandelingssystemen zeer uitgebreid gebeurt. Dit om maar te voorkomen dat er fouten in de totaalarchitectuur zitten die achteraf zeer kostbaar zijn om te herstellen. Bij simulatie kan modelgedreven ontwikkeling een bruikbaar gereedschap zijn.
Het gebruik van views staat ontwerpers en architecten toe om vanuit verschillende perspectieven naar een systeem te kijken. Hierdoor ontstaan vaak nieuwe inzichten in mogelijke probleemgebieden en hotspots in het ontwerp. Een voorbeeld van hotspots zijn kwaliteitseigenschappen. Kijken we vanuit een procesview naar de gemiddelde elektriciteitscentrale, dan zien we dat het Scada-deel is ontworpen om vooral gebruiksvriendelijk te zijn, terwijl de lager gelegen elementen juist zijn ingericht op robuustheid. De autonomie van die elementen laat ze toe door te werken zelfs als het Scada-systeem volledig afwezig is. Door goede views te gebruiken, kunnen we keuzes voor aanpakken duidelijk maken en kunnen we verantwoordelijkheden van (een groep) componenten vastleggen.
Ook voor analyse is het handig om meerdere views te gebruiken dan de zeer beperkte set die vandaag de dag gangbaar is. In de ontwikkelview kan bijvoorbeeld blijken dat er een afhankelijkheid is van meerdere componenten op één bibliotheek. Bij een mogelijke fout in de library kan dezelfde input dan dezelfde fout veroorzaken in beide componenten, wat het fail-overgedrag tenietdoet. Het gebruik van bijvoorbeeld alleen een logische en een ontwikkelview zal dit mogelijke probleem niet aan het licht brengen.
De verschillende views geven invulling aan de wensen van belanghebbenden. Door vanuit verschillende invalshoeken naar een systeem of architectuur te kijken, komen problemen naar boven die vanuit een enkele invalshoek onzichtbaar blijven. Voor performanceanalyses moeten we bijvoorbeeld scenario‘s en netwerkschema‘s combineren om te kunnen voorspellen wat de belasting van de verschillende componenten is. Daarnaast bevordert het gebruik van views de communicatie tussen verschillende ontwerpers.
Blinde vlekken
Een gedegen (in de praktijk bewezen) basisarchitectuur gaat verder dan een enkele installatie: zij is te hergebruiken voor volgende installaties. Hoewel een specifieke installatie altijd haar eigen behoeftes kent, is (een groot deel van) de architectuur vaak herbruikbaar. Sommige partijen gaan zelfs veel verder: zij ontwikkelen een productfamilie. Een dergelijke familie bestaat uit gelijkende versies van dezelfde architectuur, waar de eindklant naar believen onderdelen kan inprikken of uithalen.
Boeing doet dit bijvoorbeeld op grote schaal met zijn vliegtuigen: er zijn zeer veel fysiek verschillende 787-varianten, die in de basis gelijk zijn en allemaal eenzelfde architectuur kennen. Een autofabrikant zoals Mercedes werkt met hetzelfde principe: er is een basisarchitectuur waar hij alle onderdelen van de miljoen productvarianten (schuifdaken, motortype, sperdifferentieel) op kan inprikken. Voordeel is dat de ontwikkelkosten minder zijn en de flexibiliteit en betrouwbaarheid significant toenemen.
Gegeven de huidige uitdagingen in de embedded-softwaremarkt is het noodzakelijk een nieuwe kijk op integrale systeembouw te ontwikkelen. De uitdagingen van steeds grotere en complexere systemen kunnen we alleen aangaan met een gedegen, structurele aanpak. Om het risico van falen te verminderen, is het van belang architectuurdenken door te laten dringen in de embedded-industrie. Voorbeelden uit recente projecten tonen aan hoe belangrijk het denken op systeemniveau is. Architecturele views kunnen een hulpmiddel zijn voor zowel het vinden van blinde vlekken als voor het communiceren van belangen tussen belanghebbenden. Door dit alles vooraf te ontwerpen (hergebruiken), simuleren en analyseren verkleinen we in ieder geval het risico dat we on-site iets onmogelijks aan het bouwen zijn en daar pas achter komen als het fysiek is geïnstalleerd.