Verktyget som friade Toyotas programvara
Grammatech lanserar ett verktyg för att certifiera fordonsprogramvara enligt säkerhetsstandarden ISO 26262. Det är en version av företagets klassiska verktyg Codesonar, som nyligen friade programvaran från skulden till de mystiska gaspådrag som plågat Toyota Camry.HITTAR FELET INNAN DET SMÄLLER Statisk kodanalys pekar ut programkod som kan leda till buggar. Om du programmerar har du säkerligen någon gång skrivit data utanför reserverat minne, dividerat med noll eller läst från oinitierat minne. Typiskt får du reda på sådana och liknande fel först när programmet körs, i värsta fall sker det under drift till stora kostnader. Med hjälp av statisk kodanalys kan problemen hittas utan att programmet körs. En total analys av vad som kan ske i ett program – för alla tänkbara indata – är ofta i praktiken omöjlig att genomföra. Statisk kodanalys skapar därför en förenklad modell av programmet och undersöker vad som händer när modellen körs. Exempelvis kan heltal förenklas till "positiv, negativ eller noll". På så vis krymps antalet alternativ som måste utforskas i ett steg från miljarder till tre. Grammatechs verktyg jobbar på servrar som används via webbklienter. Analysen av en halv miljon rader kan ta ett par timmar – fem, tio gånger längre tid än en kompilering skulle ta. Verktyget pekar inte ut en ensam kodrad och säger "detta är fel" utan rapporterar en sekvens instruktioner som leder fram till felet. Grammatech analyserar kod i högnivåspråken C, C++ och Ada. Att analysera maskinspråk skulle vara betydligt svårare, bland annat eftersom den är rensad från mycket information som avslöjar programmerarens intentioner, som exempelvis om data är avsett att representera text eller siffror. |
Nasa beskrober Codesonar som ett verktyg som tar ”längre tid för sin analys än jämförbara verktyg, men kan avslöja mer subtila typer av defekter och tvivelaktig kod”.
Nasa ger därmed Grammatech välkommen draghjälp för lanseringen av Codesonar som verktyg för certifiering enligt fordonssäkerhetsstandarden ISO 26262, en standard som enligt planerna ska klubbas i år.
Toyotas programvara gick alltså fri. Men två olika bilmodeller har nyligen återkallats för programbuggar som stängde av sidokrockskydd respektive motor.
De flesta säkerhetshål beror på buggar, så statisk kodanalys kan användas som en form av säkerhetsrevision, och det är vad den nya versionen av verktyget utgår från.
Verktyget i sig fungerar som det alltid gjort – anmärker på kodsekvenser som kan ge programfel. Nyheten i produkten är dokumentation som hjälper dig koppla samman det med de procedurella krav som ställs i ISO26262.
Grammatech säger sig ha några av de stora biltillverkarna som kunder redan idag.
Elektroniktidningen träffade Grammatech på inbyggnadskonferensen Embedded World i Nürnberg
Företaget är en spinoff från Cornell university, och som de akademiker de är tycks företagets representanter inte ha förstått att deras jobb just nu är att skryta öronen av folk. Istället säger de att skillnaden mellan dem och konkurrenterna inte är dramatisk.
Mark Zarins |
– Ingen av oss kan garantera avsaknaden av buggar.
Konkurrenterna heter Klocwork och Coverity. Trots att de tre i grunden använder samma metod, är överlappningen mellan de anmärkningar som deras respektive verktyg spottar ur sig mycket liten.
I en studie som körde alla verktyg på samma kod, så var det nästan inga defekter alls som rapporterades av alla tre. 14,5 procent av anmärkningarna rapporterades av två av verktygen och resterande – 85 procent – av endast ett verktyg.
Det låter som om det skulle kunna vara en god ide att skaffa alla tre, för att vara på den säkra sidan.
Paul Anderson |
Trots att verktygen ger olika anmärkningar på koden, handlar det i grunden ofta om samma fel. När du byter analysverktyg ”försvinner” dina gamla buggar, och ersätts av en ny uppsättning buggar. Dessutom tvingas du jobba i parallella verktyg med olika ansatser till hur kodanmärkningarna redovisas.
Endast projekt med riktigt stora budgetar är beredda att betala kostnaden för två eller tre verktyg för att kunna täcka in ett fåtal fler buggar.
Det kan låta orimligt, men i praktiken accepteras ofta en viss nivå av orättade buggar i programvara. Paul Anderson har just hållit en föreläsning på Embedded World om goda skäl till att behålla buggar.
Ett problem är att om du petar i ett program – rättar en bugg – så får det konsekvenser för hela programmet – allting måste testas om, och du kan i värsta fall introducera nya buggar. Därför kan man i stället för att ändra i koden välja att skriva runt den – att se till att buggen inte uppträder – eller att acceptera buggen men se till att den inte gör skada.
Ibland är det tvärtom. Kodanalysverktygen oroar sig ofta i onödan och ger falsklarm för i sig korrekta kodavsnitt. Men det kan finnas skäl att ändra också sådan kod, trots att man egentligen vet att den är korrekt. Falsklarmet betyder att analysatorn är konfunderad – om man skingrar dimman genom att koda bort anmärkningen så kanske analysatorn upptäcker ett annat – verkligt – problem någon annanstans.
Det finns ingen enhetlig linje bland experterna huruvida det är bäst att sikta på noll anmärkningar eller inte.
– Jag använder inte det kriteriet på vår egen programkod, exempelvis, säger Paul Anderson.
– Det beror på vad din kod gör. Om det handlar om en mp3-spelare där en bugg inte är en katastrof blir kostnaderna för att rensa bort alla anmärkningar orimliga.
I jämförelse med Klocwork och Coverity är Codesonar, enligt Grammatech, det verktyg som ger flest varningar. Men det betyder att även falsklarmen är fler, erkänner Grammatech. Priset du betalar för att hitta lite fler fel är tid du offrar på att utreda falsklarmen.
– Om man vill ha bort fler buggar så måste man också acceptera fler falsklarm. Konkurrenten Coverity ger färre falsklarm, men det är till priset av att de missar äkta buggar, hävdar Paul Anderson.