Programvarestakken for automatisert kjøring

Programvare for automatisert kjøring gjør usikre sensordata om til fysisk bevegelse ved å anslå posisjon, forstå situasjonen, forutsi utviklingen, velge en lovlig vei og styre kjøretøyet. Den kjente kjeden er persepsjon, lokalisering, prediksjon, planlegging og kontroll; maskinlæring kan slå sammen trinn, men sikkerhetsspørsmålene består.

Persepsjon bygger en verdensmodell

Programvaren oppdager kjørefelt, veikanter, ledig plass, skilt, signaler, kjøretøy, fotgjengere, syklister og andre relevante objekter. Den følger dem over tid og anslår posisjon, hastighet, retning og usikkerhet.

Sensorfusjon kombinerer bilder, radarekkoer, lidar-punktskyer og bevegelsesdata. Det er ingen flertallsavstemning: timing, kalibrering, sensortillit og korrelerte feil må vurderes. Refleksjon, skjuling eller blokkert linse kan gjøre én kilde misvisende.

En nyttig modell viser også det usynlige. Er en fotgjenger delvis skjult bak en varebil, skal usikkerheten følge med i prediksjon og planlegging i stedet for å gjøre området tomt.

Lokalisering anslår posisjon og tillit

Lokalisering kombinerer GNSS, treghetssensorer, hjulbevegelse, kart og observerte veit trekk. Resultatet er en anslått positur—posisjon og retning—med usikkerhet.

Usikkerheten avgjør trygge manøvrer. Et kjøretøy som ikke sikkert kjenner kjørefeltet sitt, bør ikke foreta et tett filskifte bare fordi ruten krever det. I tunneler, bygater eller endrede veier må det stole mindre på én kilde.

Prediksjon viser flere mulige fremtider

Andre trafikanter følger ikke manus. En syklist kan unngå et hull, et barn komme frem fra skjul, og en fører svinge uten signal.

Modeller anslår mulige baner og hensikter, helst med sannsynligheter fremfor én sikker fremtid. Planleggingen må være trygg på tvers av troverdige alternativer, ikke bare gjette den mest sannsynlige handlingen.

Usikkerhet bør endre atferden: lavere fart, større avstand eller utsatt manøver. For stor forsiktighet kan også skape fare ved å blokkere trafikk eller være uforutsigbar; systemet må komme frem uten å late som usikkerheten er borte.

Planlegging velger atferd og bevegelse

Planlegging skjer på flere nivåer:

Ruteplanlegging velger veier og mål.
Atferdsplanlegging velger å følge, vike, flette, skifte fil eller stanse.
Bevegelsesplanlegging skaper en kollisjonsunngående bane med fart og krumning.

Planen må følge regler, fysiske grenser, komfort og forståelig atferd. En matematisk kollisjonsfri bane kan være dårlig hvis den passerer en syklist for nært eller nøler tvetydig i et kryss.

Det trengs også en reservebane. Programvaren må vite hva den kan gjøre ved stengt kjørefelt, svekket sensor eller utilgjengelig mål.

Kontroll gjør banen til bevegelse

Kontrolleren oversetter banen til styring, motormoment og bremsing og tar hensyn til fart, veigrep, stigning, last og aktuatorforsinkelse.

Elbiler har blandet bremsing: regenerering og friksjonsbremser må gi forutsigbar retardasjon når batteri, temperatur og grep endres. Jevnhet er ikke kosmetikk; brå kontroll kan destabilisere passasjerer, redusere grep og gjøre hensikten vanskeligere å lese.

Uavhengig overvåking kan kontrollere forskjellen mellom beordret og faktisk bevegelse, sikkerhetsgrenser og hovedsystemets helse.

Maskinlæring er en komponent, ikke et sikkerhetsargument

Maskinlæring brukes mye til persepsjon, prediksjon og stadig mer planlegging. Noen systemer er modulære; andre kobler sensordata mer direkte til baner gjennom lærte modeller. Virkelige løsninger kan ligge imellom.

Verken «end-to-end-AI» eller en håndbygd kjede beviser kapasitet. Spørsmålene er:

Hvilke data og scenarioer definerer ønsket atferd?
Hvordan finnes sjeldne, skjeve eller feilmerkede tilfeller?
Hvordan representerer systemet usikkerhet?
Hvilke grenser ligger utenfor modellen?
Hvordan testes en endring for regresjon?
Hvilken uavhengig monitor kan begrense utrygge utdata?

ISO/PAS 8800 behandler risiko fra utilstrekkelige AI-utdata, systematiske feil og tilfeldige maskinvarefeil i veikjøretøy. Høy gjennomsnittlig nøyaktighet er ikke et godtagbart sikkerhetsargument.

Trening, testing og validering er ulike oppgaver

Trening forbedrer modellen. Testing leter etter feil. Validering spør om hele systemet passer til det tiltenkte domenet.

Utviklere kombinerer:

avspilling av lagrede data;
software- og hardware-in-the-loop-testing;
simulering med kontrollerte variasjoner;
scenarioer på lukket bane;
overvåket testing på offentlig vei; og
overvåket førerløs drift etter utrulling.

Simulering skaper sjeldne farer uten å utsette publikum, men er bare nyttig dersom modellene representerer virkeligheten. Offentlige kilometer gir driftsbevis, men dokumenterer sjeldne, presise farer ineffektivt. Et troverdig program trenger scenario- og eksponeringsbasert dokumentasjon.

Et fast testsett er ikke nok. Programvare kan overtilpasses målet, og én forbedring kan skape regresjon et annet sted.

Reserveløsning og fjernassistanse

Systemet kontrollerer kontinuerlig driftsdomene, sensorhelse, lokaliseringskvalitet og kjøretøystatus.

På nivå 2 går hele oppgaven ved en grense tilbake til føreren som allerede skal overvåke. På nivå 3 håndterer systemet en forespørsel om inngrep og risikoreduksjon. På nivå 4 må det nå en tilstand med minimal risiko uten fører.

Førerløse flåter kan bruke fjernassistanse for kontekst, for eksempel bekrefte en midlertidig barriere. Det er ikke kontinuerlig fjernkjøring. Kjøretøyet har ansvar for trygg bevegelse med mindre driftsmodellen uttrykkelig bruker en fjernfører.

Oppdateringer endrer et sikkerhetskritisk produkt

Trådløse oppdateringer kan forbedre persepsjon, utvide domenet eller endre atferd, men også skape regresjon. En ny versjon krever sporbarhet, sikkerhet, trinnvis utrulling, overvåking og strategi for tilbakeføring eller begrensning.

En oppdatering endrer ikke SAE-nivå gjennom markedsføring. Hele funksjonen—maskinvare, programvare, domene, reserveløsning, godkjenning og instruksjoner—må støtte den nye rollen.

For kjøpere er grensesnittet ofte mest synlig. Det bør tydelig vise aktiv funksjon, hva den gjør, hva mennesket forventes å gjøre og hvorfor en grense nærmer seg. Modusforvirring er en systemfeil, ikke bare brukerfeil.