"Het beheersen van de complexiteit van autosoftware wordt een hele opgave als ingenieurs het grote geheel niet zien en, erger nog, geen gezond verstand hebben.
Ik maak me steeds meer zorgen dat de software-engineering in de auto-industrie lijdt aan een ernstige uitbraak van overmoed. Voor het geval je niet bekend bent met het woord "hubris", de definitie is: "[hubris] beschrijft een persoonlijkheidskwaliteit van extreme of overdreven trots of gevaarlijke overmoed". In de Griekse mythologie leidt hubris vaak tot nemesis.
De afgelopen 18 maanden heb ik advies gegeven over het definiëren van software engineeringprocessen in de autowereld. Hoe meer ik me verdiep in de huidige staat van software engineering in deze wereld, hoe bezorgder ik word, vooral als het gaat om overmoed. Het probleem is in wezen dat maar weinig engineers echt de complexiteit begrijpen van de softwaresystemen die ze proberen te realiseren. Erger nog, ze worden gedreven om autonome besturingssystemen op te leveren zonder de bijbehorende complexiteit onder controle te hebben.
Nog verontrustender is het feit dat de software engineers met wie ik te maken heb tot de laatste persoon intelligente, goed opgeleide, gemotiveerde, serieuze mensen zijn die een gedetailleerd begrip hebben van hun specifieke microkosmos van autosoftware. Maar ze lijken twee dingen te missen: inzicht in het "grote geheel" en een zekere mate van puur gezond verstand.
Enige tijd geleden las ik een citaat van een Brainport grootheid, ik ben vergeten wie, die zoiets zei als: "De uitdaging van mechanische/hardware engineering is om de wetten van de natuurkunde te beheersen. Software engineering wordt niet beperkt door natuurkunde. Hier is de uitdaging om complexiteit te beheersen".
Wat we weten over complexiteit in cyberfysische systemen is dat deze toeneemt met toenemende semantische abstractie. Met andere woorden, op het laagste niveau van een systeem zijn er meestal heel veel relatief eenvoudige softwarecomponenten. Maar als we deze eenvoudige componenten gaan combineren om functies op een hoger niveau te creëren, neemt de complexiteit heel snel toe. Hoe hoger we gaan, hoe meer functies op een lager niveau we combineren, hoe meer de complexiteit toeneemt.
Dit "big picture" complexiteitsprincipe wordt slecht begrepen door software-ingenieurs in de auto-industrie, voornamelijk omdat software in het verleden werd behandeld als een ECU-afhankelijk onderdeel van een voertuig. Dit stond, en staat nog steeds, het erkennen van de noodzaak om de software in een voertuig te behandelen als een compleet systeem in plaats van een verzameling van losjes gekoppelde componenten in de weg.
Op mijn gebruikelijke diplomatieke manier daag ik mensen uit de auto-industrie graag uit door ze te vertellen dat een voertuig een onderdeel is van een softwaresysteem en niet andersom. Het oplossen van het "grote plaatje" probleem is moeilijk maar uitvoerbaar, naar mijn mening. Als je eenmaal de voordelen van software als systeem ziet, valt bij veel ingenieurs het kwartje.
Het probleem van gezond verstand is echter moeilijker. Onlangs was ik aanwezig bij een evaluatie van de softwarevereisten voor een bepaalde zeer gedetailleerde voertuigfunctie. Deze functie omvatte het gebruik van 12 identieke temperatuursensoren. Toen ik de requirements met het team doornam, ontdekte ik dat ze 12 sets identieke requirements hadden, één voor elke temperatuursensor. Ik vroeg waarom ze niet één set vereisten hadden geschreven en vervolgens een vereiste hadden toegevoegd waarin stond dat de oorspronkelijke vereisten van toepassing waren op alle 12 sensoren. Ik kreeg een vaag antwoord over de test- en integratiemensen die individuele vereisten nodig hadden voor elke sensor. Toen ik erop wees dat requirements extreem duur zijn, dat elke requirement traceerbaar moet zijn in architectuur, ontwerp, implementatie en test, en dat compliance in elke fase moet worden aangetoond, etc., kreeg ik een paar schaapachtige blikken. Duh.
Software is van nature al ingewikkeld genoeg zonder toevoeging van door mensen veroorzaakte overcomplexiteit. Op de een of andere manier moeten deze software engineers leren hun gezond verstand te gebruiken, eenvoudig te denken en proberen hun softwarecomponenten en -systemen zo eenvoudig mogelijk te maken, maar niet eenvoudiger - om een beroemde quote te lenen. Verminder, beperk, vereenvoudig en weersta alle soorten onnodige complexiteit. Een echt moeilijke uitdaging.
Terugkomend op hubris: hoe kun je vertrouwen hebben in je vermogen om autonoom rijden en aanverwante functies te realiseren als je de uitdagingen van het beheersen van softwarecomplexiteit niet onderkent, laat staan een systematische competentie hebt om deze te beheersen?
Meer lezen
Een uitbraak van overmoed
Software is het medium van de digitalisering. Als je software niet begrijpt, heb je geen hoop om met een fatsoenlijke digitaliseringsstrategie te komen.
Software is geen onderdeel van een voertuig
OEM's in de auto-industrie hebben zich ontwikkeld tot zeer efficiënte organisaties voor uitbesteding en systeemintegratie. Alles wat te maken heeft met een voertuig wordt gezien als een component, inclusief software. Het hele automotive system engineering proces behandelt software als een onderdeel van een voertuig. Hierdoor denken ze niet na over de software als een heel systeem.
Abstractie versus vaagheid in software-engineering
Sommige software engineering teams hebben moeite met het begrijpen van het verschil tussen abstractie en vaagheid. Aangezien het ene essentieel is voor de architectuur en het ontwerp van complexe systemen en het andere leidt tot technische schuld en slechte softwarekwaliteit, moeten softwareteams het verschil begrijpen.