Ik ben toevallig net met een verhaal bezig over Automotive software bugs en dat begon met een testauto die onbestuurbaar raakte in 2008. Daarna ben ik er tot op heden mee bezig. Hier twee alinea's uit mijn verhaal.
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 en ik ben door hem een stuk wijzer geworden over wat er allemaal speelt op het gebied van automotive software bugs. Verder had hij veel voorbeelden van automotive software bugs op zijn website staan en eentje daarvan wil ik noemen. Dat ging om een software bug van een 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 zou kunnen 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 wilde graag eindigen met een kritisch citaat uit een interview - doorlink:
https://www.theregister.c...s_in_autonomous_vehicles/ - van Philip Koopman met The Reg (=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.
Citaat: 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 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.
Yoav Hollander
Ik schreef ik wilde graag eindigen maar op het moment dat ik dit verhaal aan het afronden was kwam ik in een verhaal van professor Philip Koopman de naam Yoav Hollander (Oprichter en directeur van Foretellix Ltd) tegen. 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 AV's oftewel Autonomous Vehicles = Zelfrijdende auto's. Razend interessant en dus iemand die helemaal in mijn straatje past en ik heb dan ook meteen twee reacties op zijn 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 wilde mailen. Ik vermoed omdat ik geen computernerd ben maar iemand uit het veld of beter gezegd een ervaringsdeskundige. Yoav verwees mij in verband met Automotive Softwarebugs 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" (=broncode) 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.
Verder las ik op één van de slides ook iets over "error handling" (=fouten afhandeling) en certificering van Automotive Software. Iets waar Mel Jongen (webmaster van Autotesten.nl en ICT-er) mij ook al opmerkzaam op maakte tijdens het schrijven van dit verhaal. Hier ga ik in deel 2 wat ik nog aan het schrijven ben verder op in. De software van auto's is niet gecertificeerd, er bestaat wel zoiets als de MISRA (=Motor Industry Software Reliability Association) maar het probleem van die organisatie is dat er alleen autofabrikanten en onderdelenleveranciers in de stuurgroep zitten. De slager keurt dus zijn eigen vlees dus dan snap je ook dat er van veilige software helemaal niets terecht komt want de kosten van een nieuwe auto moeten zo laag mogelijk blijven. Zoals professor Philip Koopman schrijft in een artikel over Embedded System Software Quality uit 2016: "The fundamental problem: poor software development literacy: 1 Code is not written by "computer" people 2 Managers don't get why software is difficult 3 Low probability failures * large fleet exposure" En wat betreft nummer 1 las ik in hetzelfde artikel over software ontwikkelaars dat 48 procent geen ICT-opleiding heeft dat is bijna de helft en de andere 52 procent zijn al niet veel beter gekwalificeerd. Een autofabrikant hoeft dus niet zijn broncode te overleggen aan een onafhankelijke certificeringscommissie terwijl iemand die een App schrijft en die wil verkopen in de App Store van Apple wel zijn broncode moet overleggen om te kijken of er geen 'rotzooi' in de code staat.
Conclusie uit wetenschappelijk artikel van twee Delftse studenten uit 2008(!!!) over MISRA-C: "7 Conclusions: ........... From the data obtained, we can make the following key observations. First, there are 9 out of 72 rules for which violations were observed that perform significantly better (α = 0.05) than a random predictor at locating fault-related lines. The true positive rates for these rules range from 24-100%. Second, we observed a negative correlation between MISRA rule violations and observed faults. In addition, 29 out of 72 rules had a zero true positive rate. Taken together with Adams’ observation that all modifications have a non-zero probability of introducing a fault [1], this makes it possible that adherence to the MISRA standard as a whole would have made the software less reliable." Link naar artikel:
https://pdfs.semanticscho...a985f549e68e78314e2ba.pdf