Toyota har numera bekräftat att problemen med hybridbilen Prius av årsmodell 2010 orsakades av felaktig programvara i bilens styrsystem. Gaspedalsfiaskot blev katastrofalt — det orsakade 52 dödsfall under en tioårsperiod.

Det har skrivits en hel del om Toyotas återkallande och programvarans roll i bilar. Vad som dock inte klargjorts hur komplex den programkod som används är, och de utmaningar som finns när det gäller att hitta fel.

Programvaran i dagens bilar är inte ett avskilt system. Det är lätt att få illusionen att det är förarens vridning på ratten och tryck på bromspedalen som fysiskt får bilen att bromsa och svänga. I själva verket är detta bara styrkommandon.

Om detta var mer allmänt känt skulle det kanske påverka hur förare reagerar när problem uppstår: om gaspedalen "fastnar" är rätt åtgärd att frikoppla — det hjälper inte att börja rycka i gaspedalen.

Faktum är att programvaran i moderna bilar består av uppemot 100 miljoner rader kod, det är mer än hos en F-35 eller Dreamliner 737 jumbojet. Programvaran påverkar olika delar av bilen, från anslutnings- och styrteknik och ABS-bromsar till traditionell elektronik som navigering, ljud, värme och A/C. Moderna bilar har brake-by-wire-teknik, adaptiv farthållare, aktiv styrning, däcksensorer och många andra delar som styrs av olika system och program.

För att ytterligare komplicera saker och ting kommer den största delen av programkoden från flera olika leverantörer. I Toyotas fall har man inte bekräftat om de felaktiga bromsarna i Prius-modellen kodades av Toyotas egna tekniker eller av en leverantör längre ned i kedjan. Även om varje enskild kodbas var helt felfri är det ändå ingen garanti för att de inte ska krångla när de olika delarna sätts ihop till en bil. Till detta kommer de allt kortare ledtiderna och stressen att lägga till allt fler elektroniska funktioner i moderna bilar, vilket i sin tur ökar risken för en sämre programvara.

Men frågan är om man idag är mer mån om att finslipa bilens utseende till perfektion, än om att finslipa programvaran till felfrihet?

Bristen på programvarutestning är troligen den verkliga utmaningen för biltillverkare som Toyota. Men hur blev det så? Biltillverkning började en gång i tiden som en löpande band-process där ett stort antal bilar kunde byggas på ett förutsägbart sätt. I nästa steg utvecklades Demings kvalitetsstyrningsprocess och gjorde biltillverkning förutsägbar, upprepningsbar och skalbar.

Edward Deming var en affärsguru som höjde medvetenheten om kvalitet inom den krossade japanska industrin efter andra världskriget. Deming menade att hemligheten bakom kvalitetsförbättringar var att uppmuntra arbetare att göra saker ordentligt från början och ge dem rätt verktyg, inte att använda sig av kontrollanter.

Tyvärr har biltillverkningen idag nått en punkt där noggrant byggda bilar kan bli fatala misslyckanden eftersom en kvalitetskontroll motsvarande Deming saknas för programvaran. Bilar i alla hastigheter — precis som datorsystem i hög bredbandshastighet — är osäkra system om de drivs av en motor utan hög integritet.

Därför ska självklart varje modern programvaruindustri ha en ODI-avdelning (Office of Defect Investigation, en amerikansk myndighet som utreder trafiksäkerhetsproblem). Men den ska finnas med på ett tidigt stadium i tillverkningen och inte efter det att produkterna har lanserats på marknaden; då är det ju redan för sent och resultatet kan vara katastrofalt (som Toyota nu alltför väl känner till).

Avdelningen bör särskilt fokusera på:

•     Arkitekturanalys under utvecklingen av programvaran.
•     Statisk analys när koden skrivs.
•     Dynamisk analys då funktionsproblem upptäcks och rättas till.

För ett tag sedan cirkulerade ett påstått citat i media. I den vanligaste versionen lär Bill Gates ha sagt: "Om GM hade hängt med i svängarna på samma sätt som datorbranschen skulle alla kört omkring i bilar som kostade 25 dollar och nästan inte drog någon bensin alls.” På detta svarade GM i ett smart pressmeddelande att om de skulle utveckla produkter på samma sätt som Microsoft skulle bilar drabbas av samma problem som finns i Microsofts mjukvara. Det hela har visat sig vara en vandringshistoria, men i Toyotas fall är debatten inte avslutad.

Det får inte bli så att programvaruingenjörer hamnar i en position där de bara får ta emot stryk i den här typen av debatter.

Men för att de ska kunna säkerställa kvalitet för all programvara som de levererar till industrin så måste de utrustas med sina egna ODI-avdelningar och felrapporteringssystem, och det måste läggas en stor betoning på kvalitet tidigt och ofta i produktionen.