Spaghetti-codes, waarom de kwaliteit van software in auto’s zo slecht is

Wat een schrijver lijden kan…

Het was de bedoeling om het artikel ‘Waarschijnlijk zit uw auto vol gevaarlijke software’ in twee delen te hakken. Ik had deel 2 tegelijk met deel 1 af toen er allemaal dingen gebeurden die ik nooit had kunnen voorzien. Plots kwam na een tip van Yoav Hollander de ISO 26262 om de hoek kijken. Dan had ik een gesprek met een software-ingenieur die anoniem wenst te blijven. Daarna volgde nog een gesprek met een expert op het gebied van auto-elektronica — die ook anoniem wil blijven. Tenslotte vond ik nog een website van een Duitse jurist die veel bleek te weten van ‘automotive software’, maar die gooide de ‘deur’ resoluut dicht na een mailtje van mij. Ik leverde hem waarschijnlijk geen geld op, tja….

Even dacht ik dat mijn brein net zulke spaghetti was geworden als die brakke ‘automotive software’ die ze ook wel gekscherend spaghetti-code noemen. Alles waarvan ik dacht dat ik het net begon te begrijpen, leek me weer volledig door de vingers te glippen. Ik had echter totaal geen zin om mijn verhaal helemaal vanaf een blank tekstdocument opnieuw te beginnen. Ik besloot daarom een nieuw begin te schrijven. Ik zou dan wel zien wanneer het verhaal af zou zijn en mijn goedkeuring weg kon dragen.

Elektronica voor dummies? Gewoon afzetten die handel

Mamma mia, wat was het leven vroeger simpel: auto’s zonder stuurbekrachtiging, met een motorblok met contactpuntjes en een carburateur erop onder de motorkap. Ik vraag me dan ook af of de autofabrikanten niet verschrikkelijk doorgeschoten zijn met al die elektronica in de auto. Het gros van de automobilisten begrijpt geen moer van de elektronica in zijn auto, laat staan dat ze het gebruiken. Of dat ze überhaupt weten hoe ze het moeten gebruiken.

Ik ken automobilisten die bang zijn om zoiets simpels als een cruise control (vroeger mechanisch, nu op software gebaseerd) in hun auto te gebruiken. Ze doen het dan ook nooit. Ze weten meer van hun smartphone dan van hun auto. Die smartphone is dan weer zo verschrikkelijk verslavend dat er daardoor weer veel meer ongelukken gebeuren dan ooit tevoren. Je zou toch juist verwachten dat al die geniale veiligheidssystemen in hun auto die ongelukken zouden moeten kunnen voorkomen?

Waar zijn we in hemelsnaam mee bezig? Voor wie test ik eigenlijk auto’s als het gros van de automobilisten toch geen moer van al die elektronica begrijpt? Als ze die elektronica liever gewoon uitzetten? Of als die  gewoon helemaal niet werkt zoals tijdens die Volvo-demonstratie voor de voltallige wereldpers. Begrijpen jullie mijn radeloosheid nu een klein beetje?

Veiligheidsstandaarden: richtlijnen, geen regels!

Ik ga het eerst maar eens over de ISO 26262 Road Vehicles Functional Safety hebben. Die werd al in 2011 ingevoerd als afgeleide van IEC 61508. Dat is de overkoepelende functionele veiligheidsstandaard voor elektrische en elektronische systemen. Het grote probleem, vind ik, is dat het een richtlijn is, géén verplichting! Natuurlijk zal iedere autofabrikant — naar ik mag aannemen — alleen elektronische componenten afnemen van een ISO 26262-erkende toeleverancier. Maar wat zegt dat? Die toeleverancier heeft zijn elektronische componenten onder laboratoriumomstandigheden getest. In een moderne auto zitten veel verschillende elektronische componenten die allemaal met elkaar verbonden zijn. Het cruciale punt is dat al die componenten met elkaar moeten communiceren, wat gebeurt via een zogenaamde CAN Bus.

Er vliegt werkelijk van alles over zo’n CAN Bus heen. Je kunt het ding nog het beste vergelijken met de menselijke ruggengraat en het zenuwstelsel: dat communiceert met alle delen van het lichaam. Een autofabrikant moet daarom dan ook alle los geteste elektronische componenten nog eens testen onder laboratoriumomstandigheden, maar dan allemaal met elkaar verbonden via de CAN Bus. Zomaar even één elektronische component vervangen zonder te testen is in theorie dus potentieel gevaarlijk.

Gebrek aan testen: oorzaak bugs

De Duitse jurist Dr. Ekkehard Helmig wierp dan ook terecht de vraag op: ‘Wat moet je doen als in een nieuw model één van de elektronische componenten vervangen wordt door een nieuwer type component?’ In principe zou je dan alle componenten samen opnieuw moeten testen. Volgens Helmig gebeurt dat niet. Dit is naar mijn mening één van de oorzaken van het optreden van software bugs.

Het vervelende is dat een software bug ongrijpbaar is. Een autofabrikant komt er dus vrijwel altijd mee weg. Daarom vroeg ik aan de auto-elektronica expert of hij misschien weet of autofabrikanten een bepaald percentage dodelijke slachtoffers incalculeren bij een nieuw model met nieuwe elektronica en/of software.

In de periode 2009-2012 deed een software bug de ronde in de elektronische demping/stuurbekrachtiging. Aangezien het miljoenen verkochte auto’s betrof, kan het haast niet anders of er zijn dodelijke ongevallen door gebeurd. Maar bewijs dat maar eens. Stel, een auto gaat, zonder dat er remsporen te vinden zijn, rechtdoor de bocht uit en raakt een boom of tegenligger. De oorzaak is dat het stuur geblokkeerd is door een software bug. Maar de meest voor de hand liggende conclusie van de Verkeersongevallen Analyse (=VOA) van de politie zal dan zijn: ‘Bestuurder onwel geworden’ of ‘Bestuurder had een blackout’. Als ervaringsdeskundige zeg ik dan dat het helemaal niet zo hoeft te zijn.

Philip Koopman — Carnegie Mellon University

Toen ik ging zoeken op het internet naar informatie over automotive software bugs, kwam ik uit bij Philip Koopman, een professor aan de Carnegie Mellon University in de USA. Hij is een autoriteit op het gebied van automotive software bugs. Door hem ben ik een stuk wijzer geworden over wat er allemaal speelt op het gebied van automotive software bugs. Verder had hij veel voorbeelden van dergelijke bugs op zijn website staan en ééntje daarvan wil ik noemen: een bug in de Jaguar X-Type die letterlijk levensgevaarlijk was.

De cruise control van deze Jaguar X-Type had de vervelende eigenschap dat-ie zomaar ineens niet meer uitgezet kon worden, vanwege een software bug. De enige manier om dit probleem op te lossen was het contact uitzetten. Maar ja, dan valt ook de elektronische stuurbekrachtiging uit en wat nou als je ook nog eens net 250 km/u op de Duitse Autobahn rijdt?

Ik geef graag nog een kritisch citaat mee uit een interview van Philip Koopman met The Register over zelfrijdende auto’s. De titel van het artikel is Ghost in Musk’s machines: Software bugs’ autonomous joy ride en dateert van 9 oktober 2017.

‘Despite the latest wave of excitement about artificial intelligence, the fear among some of those in the industry is that bugs could prove a serious hurdle to mass adoption – not least because of the weird, unexpected nature of the accidents they can cause. Philip Koopman, an associate professor at Carnegie Mellon University and an expert on autonomous vehicle safety, told The Reg: “I look at the errors, and almost always say: ‘Wow, that should not have happened.’ And the most likely explanation is that they did not follow a safety standard.” The “continuous stream” of defects in the car industry signals “underlying problems: they just don’t want to spend the time and effort to get it right,” he argues. Car manufacturers contacted by The Reg were unwilling to talk. Significantly, many developing Autonomous Vehicles (AV’s) are hiring developers from Silicon Valley whose backgrounds are in general purpose software – software that, of course, crashes with reasonable frequency. People are not hiring from among the ranks of the airline safety industry. “Knowing how to code is not knowing how to be safe,” Koopman says.’

Deze laatste zin vat wat mij betreft de kern van mijn betoog perfect samen.

Yoav Hollander

Eigenlijk wilde ik mijn artikel afsluiten met het citaat hierboven. Op het moment dat ik dit verhaal aan het afronden was, kwam ik in een verhaal van professor Koopman de naam Yoav Hollander tegen, oprichter en directeur van Foretellix Ltd. Yoav is de bedenker van de Hardware Verification Language genaamd ‘e’ en houdt zich zijn hele leven al bezig met verificatie van hardware en software.  Tegenwoordig houdt hij zich echter ook bezig met het opsporen van software bugs in de software van AVs (autonomous vehicles), zelfrijdende auto’s dus.

Razend interessant en iemand die helemaal in mijn straatje past. Ik heb dan ook meteen twee reacties op zijn zeer toegankelijke (hij roept op om te reageren) blog achter gelaten. In eerste instantie reageerde hij op zijn blog onder 1 van mijn 2 reacties, maar kort daarna ontving ik een persoonlijk mailtje dat hij graag 1-op-1 contact wilde. Yoav verwees mij in verband met automotive software bugs naar een YouTube-filmpje van professor Phillip Koopman over de onbedoelde acceleratie van Toyota’s (met in ieder geval 89 doden tot gevolg sinds 2002). Na lang en gedegen onderzoek van professor Philip Koopman, andere experts en de NASA kwamen deze tot de conclusie dat het Electronic Throttle Control System de boosdoener moest zijn geweest, maar men heeft helaas geen ‘smoking gun’ (zeg maar dé software bug) kunnen vinden. Feit was echter wel dat professor Philip Koopman en andere experts fouten in de software-architectuur (net als bij die Nederlandse bruggen) en software-defecten hebben gevonden.

De experts spraken over ‘spaghetti code’ en dat is bepaald geen compliment voor de software van Toyota. Op één van de slides in het YouTube-filmpje las ik dat professor Philip Koopman heel veel heeft gezien — ‘a whole lot of stuff’ — maar niet de ‘source code’. Toevallig kwam ik tijdens het schrijven van dit verhaal een link naar een artikel ‘source code’ op tweakers.net tegen met daarin de zin: ‘Europarlementariër Paul Tang van de PvdA wil dat de Europese Commissie autofabrikanten verplicht om de broncode van hun motormanagement-software open te stellen. Op die manier zou manipulatie van de resultaten van stikstoftesten zoals bij Volkswagen tegengegaan kunnen worden.’ Oké, verhoogde uitstoot is een ander onderwerp dan onbedoelde acceleratie en niet levensgevaarlijk (voor gezonde mensen althans), maar ik ben het er wel mee eens dat autofabrikanten hun broncode beschikbaar moeten stellen.

Error handling

Verder las ik op één van de slides van Koopman ook iets over ‘error handling’ (= foutenafhandeling) en certificering van automotive software. Iets waar de webmaster van Autotesten.nl mij ook al opmerkzaam op maakte toen ik dacht dat ik deel 2 al af had.

Error handling is heel simpel gezegd het afhandelen van onvoorziene situaties. Aangezien je nooit alle mogelijke onvoorziene situaties kunt voorzien, is de ‘error handling’ dus nooit compleet. De software is feitelijk constant ‘raadseltjes’ aan het oplossen: de software is in een reeks voorgeprogrammeerde regels aan het toetsen welke handeling uitgevoerd moet worden.

Laten we dat verduidelijken met een voorbeeld. Je hebt een Lego-robot en die wil je door een blauwe deur laten lopen. Stel nu dat de blauwe deur dicht zit, dan luidt de software-opdracht: ga naar de deur rechts van de blauwe deur en ga daar doorheen. Stel dat die deur rechts van de blauwe deur ook dicht is of er geen deur is, dan moet je beide situaties omschrijven in de ‘error handling’. Volgens de reguliere ‘runtime’ software moet de robot door de blauwe deur óf door de deur rechts van de blauwe deur. Maar wat als beide opties niet mogelijk zijn?

Als deze mogelijkheden (variabelen) niet ook geprogrammeerd worden, dan kan de softwareregel dus niet juist worden uitgevoerd. En stel nou dat er 1.000 deuren zijn? Je kunt je wel voorstellen hoeveel regels ‘error handling’ je moet schrijven. En dan ga je er al vanuit dat de software weet hoe een blauwe deur eruit ziet, want ook dat moet je dus omschrijven. En dat geldt dan alleen voor die situatie waarbij de deur een zekere verhouding heeft en in het spectrum (440-490 nm) van de blauwe kleuren valt. Wijzig één ding in die definitie en al je softwareregels zijn niet meer toepasbaar.

Dit is maar een simpel voorbeeld. Vertaal dit maar eens naar bijvoorbeeld Forward Collission System: dat moet weten of het moet ingrijpen of niet. Stel dat het ingrijpt als er een vogel voor je auto vliegt of een kartonnen doos op de weg ligt? Gemiddeld zijn voor één regel goed geschreven software code meerderde regels ‘error handling’ nodig. Dus het aantal regels voor ‘error handling’ kan zeer groot zijn en moet up-to-date zijn in combinatie met de desbetreffende componenten aanwezig in de auto. En dan is het maar de vraag als een component wordt vernieuwd (als bijvoorbeeld in een model een andere component wordt gemonteerd omdat de oorspronkelijke component niet meer leverbaar is) of alle software regels nog steeds van toepassing zijn.

Tijdsdruk

Het hiervoor besproken Forward Collission System bestaat uit verschillende componenten (onder andere: Radar – Camera – Remsysteem – Waarschuwingssysteem – Voertuiginformatie) die moeten samenwerken met elkaar. In ieder geval moeten de losse componenten getest zijn door de toeleverancier en het systeem in zijn geheel door de autofabrikant.

De fabrikant stelt de minimale eis dat de toeleverancier minimaal MISRA-C en/of ISO 26262-gecertificeerde componenten aanlevert voor zowel de hardware als de software. De combinatie van deze componenten wordt in de regel deels theoretisch en praktisch getest door de fabrikant van de auto, terwijl certificering betreffende de veiligheid van de auto als geheel vreemd genoeg niet afgegeven wordt. De praktijktest kan nooit volledig zijn: er zijn te veel mogelijke combinaties. Bovendien is er omwille van marketing- en verkoopdoeleinden tijdsdruk om op de markt te komen met een nieuw model. Dat nieuwe model wordt getest door instanties als de ADAC, TUV, NCAP. Die instanties kunnen niet om 40 auto’s van een nieuw model vragen om te testen. Ze kunnen ook onmogelijk alle praktijksituaties met potentiële dodelijke crashes testen met echte chauffeurs.

En dan moet je dit dus ook nog vastleggen in een log-file en vervolgens de log-files analyseren om tot de conclusie te komen dat er verbeterpunten in de software zijn. Hierna moet de fabrikant deze gecorrigeerde software en/of hardware nog zien te distribueren in het reeds rijdende wagenpark.

Ook hier weer vraag ik mij af of autofabrikanten wel eerlijk en open zijn over software-updates. Stel dat een elektronische component van een bepaald model auto een levensgevaarlijke software bug bevatte en dat die software bug eruit gehaald is. Dan moet deze nieuwe software in alle modellen ge-updatet worden en zou het heel erg netjes zijn als de autofabrikant via een persbericht bekend zou maken dat een elektronische component van een bepaald model een levensgevaarlijke software bug bevatte. Voor een moer die vervangen moet worden, verschijnt er altijd een persbericht. Voor software bugs heb ik nog nooit zo’n bericht gezien.

Op de valreep

En net toen ik klaar te zijn met dit artikel, gebeurde er nog iets dat mij aan het denken zette. Dinsdag 1 mei vond er een ernstig ongeval met een lesauto plaats op een spoorwegovergang in Bussum. De rijinstructeur die achter het stuur zat kon niet meer wegkomen, maar de leerling naast hem gelukkig wel. Stilvallen precies op een spoorwegovergang en de auto niet meer gestart krijgen: daar moet toch haast wel iets vreemds aan de hand zijn. Vooral omdat dit niet de eerste keer is.

Dinsdagavond 1 mei had ik een afspraak met die auto-elektronica expert. Tijdens ons gesprek begon hij over het ongeluk op de spoorwegovergang in Bussum, precies op het moment dat ik hem daarover een vraag wilde stellen. We hadden beiden het vermoeden dat het een auto met Keyless Entry moet zijn geweest, vanwege de manier waarop dit systeem werkt. Zijn redenering was gebaseerd op een vreemd voorval tijdens een live tv-uitzending van een voetbalwedstrijd van NEC. Hij was naar het stadion geroepen omdat behoorlijk wat auto’s (allemaal met een startknop) niet wilden starten. Hij vermoedt dat dit te maken heeft gehad met de zeer krachtige zendmast die daar stond vanwege de live tv-uitzending. Het kan niet anders dan dat het elektromagnetische veld van het Keyless Entry Systeem binnenin alle auto’s die niet wilde starten verstoord werd door die zeer krachtige zendmast.

Dat elektromagnetische veld in de auto dient ervoor om de contactsleutel van het Keyless Entry Systeem op afstand contact te laten maken met de startknop op het dashboard. Normaal gesproken werkt dat zo dat er in het contact een ontvanger zit die de RFID-chip in de contactsleutel herkent zodra je de contactsleutel in het contact stopt en omdraait. Dat herkennen gebeurt echter op een korte afstand: hooguit een paar centimeter. Een paar dagen na het ongeluk op de spoorwegovergang in Bussum las ik in het Algemeen Dagblad dat de lesauto inderdaad een startknop had en dus een Keyless Entry Systeem, zoals die auto-elektronica expert en ik al dachten.

Op de website van de firma Peutz vond ik een interessant artikel over elektromagnetische interferentie. In het artikel viel het volgende te lezen:

‘Elektro Magnetische Compatibiliteit (EMC) gaat over de wederzijdse beïnvloeding van elektrische en magnetische velden. Om ons heen zijn talloze van deze onzichtbare velden aanwezig. De meest bekende zijn die van radio, telefoon en talloze andere elektrisch gevoede consumenten apparatuur. Over de hoogfrequente EM-velden die daarbij horen is relatief veel bekend. Maar hoe laagfrequente velden elkaar beïnvloeden is veel minder bekend. Praktijkonderzoek kan hier uitkomst bieden. Treinen en trams worden gevoed door gelijkstroom bronnen en creëren dit soort laagfrequente velden. Door de lange bovenleidingen en de hoge stromen in deze bovenleidingen kennen ze bovendien grote verspreidingsgebieden. Deze EM-velden zijn voor de mens tot op zekere hoogte onschuldig, maar elektrische apparatuur kan wel degelijk verstoord worden.’

Ik ben dus zeer benieuwd wat een eventueel onderzoek hiernaar zal opleveren, want blijkbaar heeft nog nooit iemand dit onderzocht. Een zelfmoord op het spoor kost de NS gemiddeld 300.000 euro, een ongeluk met een auto zal vergelijkbaar zijn. Dat is meer dan de moeite waard dus om onderzoek naar te doen.

Nou zou ik natuurlijk met de eerstvolgende testauto met Keyless Entry op een bewaakte spoorwegovergang in ’the middle of nowhere’ stil kunnen gaan staan. Even de motor af laten slaan met de bomen nog open en daarna proberen de auto opnieuw te starten. Ik weet niet hoeveel levens ik nog over heb, dus misschien toch maar niet.