Korta utvecklingstiden med mjukvarutestning i simulerad miljö

Vill du kunna testa mjukvaran innan hårdvaran är färdig? Vill du ha obegränsat med testriggar? Vill du kunna ’debugga’ med enkla standardverktyg? Vill du kunna skeppa en testrigg till Kina (LCC) på en sekund? Då är en simulerad testmiljö det du behöver!

Vad är då en simulerad testmiljö?
Det är en miljö där din eller dina mjukvaror kan exekvera och debuggas tillsammans med testmotorer, omvärldssimulator, bussimuleringar etc.

Hur lyckas man med sin testmiljö?
För att ha de bästa förutsättningarna för att lyckas med en enkel implementering av simuleringsmiljö så skall man ha en bra mjukvaruarkitektur med väldefinerade drivar-lager. I drivar-lagret är det oftast bäst att koppla bort hårdvaruberoende och styra över till en simulerad miljö. I den simulerade miljön bygger man upp simulerade drivrutiner med samma interface mot applikationen som då enkelt kan integreras. Skillnaden med dessa är att de inte kopplar till någon riktigt hårdvara utan till simuleringar av databussar, minnen, IO etc. Detta koncept funkar både för enklare IO kort som för mer komplexa hårdvaror som även använder OS.

Nu börjar det roliga. Mjukvaran är nu anpassad så den inte längre är kopplad mot riktigt hårdvara utan istället styr simulerade interface. Därför går det nu att koppla dessa till andra simulerade mjukvaror för test av distribuerade system eller till omvärdssimuleringar. Simuleringarna kan utvecklas i verktyg som t.ex. LabView och Matlab/Simuling. Man kan även koppla direkt till någon test exekverare.

Men är det inte omöjligt att testa ett realtidssystem på en vanligt PC?
Jo det kan vara mycket svårt om man förväntar sig realtidsprestanda, men det kanske inte är nödvändigt. Så länge mjukvaran under test, testscript och omvärdssimulator har samma uppfattning om tid, så går det bra. Men denna tid behöver inte överensstämma med verkligt tid, så man kopplar bort alla beroenden till verklig tid och kopplar mot en simulerad klocka istället. Detta kan man dra fördel av åt båda håll, har man en PC som inte har tillräcklig prestanda så kan man köra simuleringen långsammare än realtid men ändå få ett korrekt beteende. Skulle man å andra sidan ha ett minde krävande system att testa, så har man möjligheten att skruva på klockan åt andra hållet och exekvera testsekvenser på kortare tid.

Som man ser av en sådan här lösning så testar man ju inte hela systemet. Man testar inte drivrutiner och man hittar inte timing och prestandaproblem. ”But face it” hur mycket timingfel brukar det vara? 10/90? Förmodligen mindre. Vad gäller drivrutiner är det vanligt att man antingen återanvänder eller köper ett färdigt Borad Support Package som då förhoppningsvis är testat och klart. Faktum kvarstår dock, har man en simulerad testmiljö så utesluter det inte att man också måste göra tester på riktigt hårdvara.

Hur kan det bli en stor vinst om man ändå måste testa på riktigt hårdvara?
Om mjukvaran först testas i simulerad miljö kan den stora andelen logiska fel avhjälpas. Den mjukvara som sen kommer för test i den trånga sektorn, hårdvarulabbet, har en mycket högre kvalitet. Sedan är det också så att det finns ett antal test som inte lämpar sig att börja med i en riktig miljö. Det kan röra sig om styrning av maskiner, som kan vara farliga och kanske kräver regulatorer för att hålla sig stabila. Att sätta en brytpunkt i ett styrsystem för ett flygplan när man testar det på riktigt är inte lämpligt.

Vill man sedan ta steget längre och börja med icke funktionell testning som tex felinjicering, så lämpar det sig alldeles utmärkt att göra i den simulerade miljön. Här har man full kontroll över tiden och varje bit som skickar på en buss, så att t.ex. korrumpera endast en bit i ett IP telegram på ett repeterbart sätt är en enkel match.

Av: Anders Öberg

Läs om hur Bombardier framgångsrikt arbetat med en simulerad testmiljö