Test af software i selvkørende biler

Jeg har i forbindelse med faget test på pba i softwareudvikling udarbejdet en synopsis om test af software i selvkørende biler.

Indholdsfortegnelse

  • Afgræsning og problemformulering
  • Indledning
  • Test af livskritiske systemer
  • White-box testing
  • Test i Ros(Robot Operating System)
  • Test-driven development i C++
  • Software standarder i bilbranchen
  • Sammenfatning
  • Spørgsmål til drøftelse

Afgræsning og problemformulering

Jeg har i de seneste par år brugt en del tid på at forstå teknologien bag selvkørende biler. Jeg synes det er utrolig sørgeligt, at der stadig er så mange mennesker, som mister livet i trafikken hvert år. Det er næsten hver dag, at vi kan læse i nyhederne at der nu sket et endnu et nyt trafikuheld på de danske veje, hvor flere personer har mistet livet eller er kommet slemt til skade. Hvorfor er det at vi i 2018 stadig overlader fuld kontrol af biler til os mennesker, når vi gang på gang ser at mennesker laver fejl i trafikken, som fører til trafikuheld. Jeg ser et stort behov for videreudvikling af sikre computer systemer til styring af biler i 2018, som kan hjælpe med at få reduceret tabet af menneskeliv i trafikken. Jeg har derfor fundet frem til, at jeg gerne vil forske i følgende problemstilling i faget test:

Hvordan testes software i livskritiske systemer såsom selvkørende biler, hvor systemfejl kan resultere i tab af menneskeliv.

Indledning

Der dør i hele verden over 1.2 millioner mennesker hvert år i trafikuheld, hvor størstedelen af disse trafikuheld skyldes menneskefejl i trafikken. Det kan være en spritbilist, som kører galt i en brandert. Eller en pensionist som glemmer at kigge sig over skulderen, og kører derefter ind i en cyklist. Mange af disse situationer vil kunne forebygges med selvkørende teknologi implementeret i biler og lastbiler, som udgør en stor procentdel af transportmidlerne til transport. Selvkørende teknologi består af en række sensorer, som monteres på køretøjet. Disse sensorer bruger køretøjet til at lokalisere sig selv i forhold til sine omgivelse, og køretøjet kan derefter med avancerede algoritmer planlægge sin egen rute og styre køretøjets retning og hastighed indtil destination uden en menneskelig chauffør hjælper til bag rettet. Alt kørsel bliver kort sagt styret af software algoritmer i det selvkørende køretøjs computer systemer, og det er derfor vigtigt at denne software er meget pålidelig, så køretøjet ikke er til fare for sine passagerer og omgivelser, hvis der sker fejl i softwaren. Pålidelig software er et centralt element i udvikling af selvkørende teknologi. For at kunne bevise af den selvkørende teknologi er sikker nok til kørsel på vejene og rentabel i forretningsammenhænge, er man til at foretage dybdegående test af sin software, og følge udviklingsmetoder som hjælper med at forebygge fejl uden at udviklingsbudgettet overskrides.

Test af livskritiske systemer

Selvkørende teknologi er et livskritisk software system, da en systemfejl kan resultere i tab menneskeliv. For at kunne argumentere for i hvor høj grad livskritiske systemer i form at selvkørende biler bør testes, har jeg tænkt mig først at kigge nærmere på de økonomiske aspekter, der er i forbindelse med udvikling af selvkørende teknologi. Når alt kommer til alt, er det pengene der bestemmer. Der er ingen tvivl om, at der er gode forretningsmuligheder, hvis man formår at bygge sin forretning op omkring selvkørende teknologi.

Et taxafirma bestående udelukkende af selvkørende elektriske biler, ville kunne underbyde samtlige etablerede taxafirmaer, da de ikke har nogle chauffør omkostninger, og ville samtidig kunne køre med en langt mindre flåde af biler, da man ved hjælp af algoritmer, vil kunne regne sig frem til det kommende udbud og efterspørgsel af taxa-kørsel i løbet af dagen, og dermed placere de selvkørende biler på strategiske punkter rundt omkring i byer. Elektriske selvkørende biler består også af langt færre komponenter end almindelige benzin og diesel drevne biler, og det er derfor også bare en spørgsmål om tid, før bilproducenterne får arbejdet elektriske biler og den selvkørende teknologi ned i pris. Der er en god grund til at næsten alle bilproducenter og software/hardware giganter arbejder på teknologien til selvkørende biler, og det er at der er gode forretningsmæssige muligheder ved at have teknologien i sin forretning.

Selvom der er en stor mulig økonomisk gevinst ved at udvikle teknologi til selvkørende biler, er det også vigtigt at tage højde for de risici, der er med at bruge selvkørende biler i forretningssammenhænge. Der er potentielt mange omkostninger, hvis en selvkørende bil kører galt. Der er en risiko for tab af menneskeliv, materielle skader, miljøskader, retsforfølgelse og negative nyheder i medierne som kan skade et etableret brand. For at kunne forebygge alle disse risici, er man nød til at gå meget systematisk og dybdegående til værks i sin udviklingsprocess for at kunne imødekomme de høje software standarder teknologien til selvkørende biler har. I forhold til test ville man skulle teste alle de indre komponenter i selvkørende biler for at kunne sikker på at softwaren virker efter hensigten. Jeg synes det giver god mening at komme ind på emnet white-box testing, da det handler om at teste systemets fysiske struktur. Man er nød til at vide hvad der sker i softwaren i selvkørende biler, så vi kan få forebygget de risici der er ved teknologien. Bruge test til en få høj dækningsgrad i koden, og have klare opdelinger i testaktiviteter.

I forhold til valg af udviklingsmetode til udvikling af livskritiske systemer er der en tendens til at bruges de mere klassiske og veldokumenterede udviklingsmetoder fx vandfaldsmodellen, som er blevet brugt igennem de sidste mange årtier. Her startes der ofte med en dybdegående kravspecifikation og derefter en design fase, så der er helt styr på de kritiske problemstillinger, som der er mange af i livskritiske systemer. Sådan en fremgangs metode kunne passe godt i starten til et projekt, hvor der skal udvikles selvkørende teknologi. Man er nød til at få styr på projektets omfang og hvordan softwaren skal testes, så projekter bliver udviklet i den rigtige retning fra start. Selvkørende biler har dog så høj en kompleksitet, at det ville være svært at få opdækket en fuldt tilrettelagt process, som det kræver i de klassiske udviklingsmetoder. Selvkørende biler har rigtig meget ny teknologi i form at machine learning algoritmer og hardware i form af sensorer og computerchips, som er tilpasses specifikt til selvkørende biler. Der er stadig uklart hvordan alle edge cases i trafikken kan dækkes ind i et software system til selvkørende biler. Jeg vil hellere argumentere mere for agile udviklingsmetoder fx Scrum, hvor der arbejdes iterativt i små ekspert teams bestående af softwareudviklere, hardwareudviklere, testere og projektledere. De selvkørende biler skal ud på vejene og få kørt nogle kilometer i kontrollerede omgivelse. På den måde kan vi gradvist få forbedret og testet teknologien, indtil den er sikker nok til at blive brugt på i trafikken.

Scrum teams der udvikler på selvkørende biler ville have godt at få implementeret en masse automatiske test i et miljø, hvor der er opsat continuous integration og continuous delivery, så der er en hurtig og iterativ udviklingsprocess. For at holde udviklingen mere sikker vil jeg foreslå at man følger en test først fremgangsmetode. Her udvikles der først unit test, som så hjælper med at drive designet, når der skal kodes. Jeg vil senere i rapporten komme ind på test driven development.

Et til flere code reviews ville også være en stor hjælp i udviklingen af livskritiske systemer med en agil fremgangsmetode. Her kan softwareudviklerne med fordel inddrage andre udviklere og testeksperterne for at sikre at koden er sikker inden den testes ude på vejene i de selvkørende biler.

Dertil kunne man overveje mulighederne for at udvikle et simuleringsværktøj til test af selvkørende biler, så der kan testes situationer som selvkørende biler normalt ikke kommer ud for, når der testes på vejene. Hvordan reagere bilen i disse særtilfælde.

White-box testing

White-box testing er en metode til at teste den indre struktur af software applikationer. White-box testing foretages typisk af teknikere, som har en dyb forståelse af software applikationen helt ned til kode niveau. Det er især test i de lave lag, altså unit test og integrations test, som arbejdes med i white-box testing for at få dækket koden ind.

Livskritiske systemer kræver at koden afdækkes af test så meget som muligt, så der ikke sker fejl. Man nød til at kigge efter i sømmene for at finde ud af at der er det rigtige flow af data, og der ikke er sideeffekter i den kode der kører i livskritiske systemer. I selvkørende biler er der en masse flows af sensor data, som bliver brugt til at træffe de rigtige beslutninger i forbindelse med kørsel på vejen. White-box testing kan være en hjælp her for udviklerne til at finde frem til de mest kritiske steder i koden, hvor der virkelig skal afsættes mange ressourcer for at projektet kommer videre.

Jeg vil gerne arbejde noget mere med unit test og integrationstest i ROS – Robot Operating System, som er det robot middleware jeg arbejder med i øjeblikket. Jeg vil teste koden i dybden med unit test, og så vil jeg lave fuld integrationstest med en ROS package rostest, hvor jeg tester flere noder i ros netværket på en gang. Jeg kommer lidt mere ind på hvordan ROS virker i næste afsnit.

Der bliver brugt rigtig mange machine learning algoritmer i selvkørende biler blandt andet til klassificering af objekter bilen møder på sin vej. Der er et black-box problem med machine learning algoritmer, da man kender til input og output, mens man ikke rigtig ved hvordan machine learning algoritmerne fungerer i sit indre. På et eller andet punkt kan man være nød til at allierede sig med matematiske genier og dygtige softwareudvikler, som kan hjælpe til med at få vendt vrangen ud på de her machine learning algoritmer, for at finde ud af hvor høj en dækningsgrad der er i testen af programkode til machine learning algoritmerne, og hvordan machine learning testes generelt. Der bliver i øjeblikket udviklet mange nye tools og frameworks til machine learning, som giver computer støtte i forbindelse med test og udvikling af machine learning. Fx få hjælp til hvor store man bør lave sine neurale netværk, visualisering i form af diagrammer, og hvor store datasæt man bør bruge for at være dækket godt nok ind. Jeg har valgt ikke at gå dybere i test af machine learning delen for at holde på fokus på test af almindelige software applikationer.

Test i Ros(Robot Operating System)

ROS også kaldet Robot Operating System er et af de mest populære robot middleware, som er rigtig godt til at udvikle store robot projekter. ROS er baseret på en graf lignende arkitektur, hvor noder kan kommunikere med i hinanden i et publish og subscribe design mønster. Kode til en kamera sensor ligger fx i sin egen ros package, som kan køres i en node, der publisher data til et topic i ROS netværket. En node med Computer Vision kode til genkendelse af lyskryds kan subscribe til et topic, hvor der bliver published kamera data til. Alle noder er på den måde afkoblet fra hinanden i ROS, og det giver muligheden fra blandt andet at teste de enkelte noder/komponenter i en selvkørende bil.

ROS udvikles primært på en Linux distribution i C++ eller Python. Teknologien i selvkørende biler har rigtig meget C++ kode, da algoritmerne i selvkørende biler skal kunne håndtere store mængder sensor data rigtig hurtigt. Et testmiljø til C++ er ofte det der bliver anvendt til test af softwaren i selvkørende biler. Her er Googletest det primære testing framework til test af C++ kode. Googletest bruger blandt andet xUnit test frameworket, og virker både på Linux, Windows, Mac.

Jeg udvikler i øjeblikket på et Linux Ubuntu operativ system, hvor jeg primært bruger GNU Emacs som text editor, når jeg udvikler python og C++ software. Emacs er en let og kraftfuld text editor, hvor det er muligt at omskrive selve koden i text editoren, så funktionaliteten passer bedst mulig til den måde jeg arbejder mest effektivt på som udvikler. GNU Emacs er bygget op om Emacs Lisp – en dialekt af programmeringssproget lisp. Fortolkeren i Emacs er skrevet i C. GNU Emacs havde sit første initial release i 1985, og bliver stadig videreudviklet her i 2018. Emacs har mange år på bagen, og det gør at der er et stort udvalg af packages, som jeg kan bruge når jeg udvikler. Emacs passer godt til den måde jeg arbejder på i ROS, da jeg ofte arbejder på flere forskellige ROS packages, som jeg kører i docker containers. Emacs minder også meget om den måde man bruger terminalen i linux, så det er alt i alt en godt værktøj til udvikling af software i Linux.

Jeg har så planer om at få indbygget mere test funktionalitet i min Emacs text editor. Lige nu kører jeg alle mine unit test i terminalen, og det kunne jeg godt tænkte mig at få indbygget i Emacs, så jeg får hurtigere feedback, når jeg kører mine unit test igennem. Det er noget jeg tænker at arbejde videre med indtil eksamen.

Test-driven development i C++

Test-driven development er en udviklingsprocess, hvor udvikleren først skriver en test til det funktionalitet der skal udvikles, og derefter koder funktionaliteten testen er baseret på. Når testen skrives først tvinger det udvikleren til at sætte sig ind problemstillinger der skal løses, og de krav der skal overholdes. Testene holdes små og korte, så der hele tiden kun bygges en enkelt ny feature på systemet. Test-driven development hjælper dermed udvikleren med at holde fokus på at udvikle og designe et step ad gangen hurtigt, uden at der bliver introduceret nye bugs til den eksisterende kodebase.

Der skal mange linjer kode til, før man har funktionalitet nok til at en selvkørende bil kan køre af sig selv. Nogle projekter løber op i flere millioner linjer af kode, og spiller helt sikkert sammen med nogle gamle legacy systemer, hvis virksomheder har flere år på bagen. Virksomhederne der udvikler sådanne projekter er nød til at holde nogle software standarder, og her er test-driven development et godt værktøj for udviklerne til at komme sikkert videre et skridt ad gangen i de her komplekse udviklingsopgaver der er med selvkørende biler.

Software standarder i bilbranchen

Livskritiske software systemer skal overholde visse love og regler, før de kan anvendes i praksis. Der er forskellige love og regler i de enkelte brancher og i de lande systemet anvendes i. I bilbranchen er der udviklet en international standard, som hedder ISO 26262. Det er nogle regler omkring funktionssikkerhed i de elektriske systemer, som bliver brugt i biler. ISO 26262 standarden består af 9 forskellige dele og en guide til hvordan man følger standarden. Det er en hel række af lovmæssige krav, som skal overholdes i forbindelse med udvikling af de elektriske komponenter og softwaren dertil. Det er for at forebygge fejl i disse systemer, da der er en høj risiko, hvis der sker fejl når en bil kører på vejen.

For at kunne overholde disse lovmæssige krav, er man nød til at uddanne medarbejdere i reglerne, og der skal derfor afsættes ekstra tid og ressourcer til at få opfyldt de krav. Selvkørende biler skal højst sandsynlig overholde endnu strengere krav, da der ikke er nogen chauffør bag rettet. Man kan med fordel have nogle juridisk kloge medarbejder i sin organisation for at kunne imødekomme de lovmæssige krav.

Sammenfatning

Selvkørende biler udvikles og testes efter strenge lovmæssige standarder, som skal følges for at kunne overholde loven i de lande hvor selvkørende biler kører. Der er stor konkurrence internt blandt de førende virksomheder, som udvikler teknologi til selvkørende biler, da virksomhederne gerne vil først til marked med deres produkter. Mange vælger at udvikle efter agile udviklingsmetoder med en høj grad af automatiske test, og test drevet development for at imødekomme de store teknologiske udfordringer samtidig med at man prøver at undgå systemfejl. White-box testing kan hjælpe med at få testet de indre strukturer i koden, så man har et godt og mere sikkert udgangspunkt at arbejde ud fra. Software til selvkørende kan bygges op omkring ROS – Robot Operating System, hvor der kan laves unit test og integrationstest af ROS softwaren.

Spørgsmål til drøftelse

Hvordan har jeg brugt automatiske test i min continuous integration og continuous delivery pipeline, som jeg har arbejdet på indtil eksamen?

Kunne man argumentere for en grey-box eller black-box testing frem for white-box testing i forhold til udvikling af software til selvkørende biler, som jeg har været inde på i min synopsis?

Hvorfor giver test automation stor værdi til virksomheder i forbindelse med udviklingen af selvkørende biler og udvikling af software til bilbranchen generelt?