sverreb

Denne typen funksjonalitet er temmelig vanlig og har eksistert lenge. Du misforstår imidlertid grundig hvordan man tenker og planlegger for sikkerhet. Dette er en aktiv sikkerhetsmekanisme. Den er avhengig av at funksjonelle komponenter yter som planlagt, også komponmenter som ikke er designet sikre (som billedanalyse) Aktiv og upålitelig sikkerhet er alltid kun et supplement til passiv og pålitelig sikkerhet. Passiv sikkerhet er design som gir sitt sikkerhetsbidrag inherent uten at man er avhengig av at funksjoner gjør inngrep i systemet. Sammenlign f.eks kollisjonssikkerhet. Passiv sikkerhet er kollisjonssoner og sikkerhetsbelter, mens aktiv sikkerhet er nødbremsing fra sensorinput. Du reduserer ikke på kravene til kollisjonsytelse bare fordi du legger til automatiske systemer som har som mål å unngå kollisjonene. At man opererer kjøretøyet med kun bremsepedalen er en form for passiv sikkerhet siden uansett hvordan man opererer bremsepedalen så medfører det ikke at man øker farten mer enn til ca 5km/t. Aktive tiltak som du beskriver ovenfor er inherent mindre pålitelige og man må alltid designe slik at disse kun kommer i tilegg til passiv sikkerhet for at de skal gi en total sikkerhetsgevinst. Dette er samme grunnleggende grunn til at man ikke vil skape inntrykk av at førerautomasjon (SAE 2) er en erstatning for førerens oppmerksomhet og derfor designer de slik at førere ikke begynner å stole på disse systemene og slutter å følge med selv. (selv om kjøringen ikke her er passiv sikkerhet) Så i dette tilfellet: Bare fordi man har systemer som kan stoppe bilen med aktiv inngripen når sensorene detekterer fare for kollisjon, så er det absolutt ingen grunn til å kompromittere på hvordan man designer kontrollinput for maksimal sikkerhet.

Prisen endres naturligvis, men leveringstiden endres i veldig liten grad. Hvis du velger noe som det er leveringsproblemer på komponentene av så kan det nok skje, men i utgangspunktet er jo hver bil lagd på bestilling. De blir ikke produsert før de har en konfigurasjon og da har de en produksjonslinje som klargjør de delene som skal på akurat din bil og har de klar for montering når det som skal bli din bil passerer på samlebåndet. Produsenter som BMW produserer i veldig liten grad for å ha på lager så og si alt lages på bestilling. BMW prosduserer ca 20-40% fler biler i året enn Tesla. Dette handler nok mer om typisk amerikansk vs europeisk bilsalg. I USA er det forventet å kunne gå til en forhandler og kjøre ut med en ny bil. Da blir aksepten for å vente på at en bestilt bil skal gå gjennom produksjon ganske liten. Så lenge man har anledning til å planlegge produksjonen er det ingenting ineffektivt med å kunne tilpasse produksjonen av bilene, men det innebærer naturligvis at det er en lengre ledetid fra kontrakt til levering.

Det er ikke viktig. Slike maskeringer kan man alltid lage (og man kan alltid adressere en gitt maskering i en ny AI, men dette er som å skrelle en løk). Poenget er at med en pluralitet av sensorer synker sannsynligheten dramatisk for at en uventet sensorinput skal gi en feilavlesing som ikke detekteres som feil siden man da må få alle sensorene til å feile samtidig. Det er ikke slik at man må lage systemer som alltid kan forstå omgivelsene, men for at selvkjøring skal fungere må de forstå ommgivelsene tilstrekkelig til at de kan innse når noe feiler og med nok margin til at de kan stoppe. Å ha to forskjellige sensorer gir den redundansen som skal til for å oppnå dette.

Prøvde det en gang. Nogså irriterende å ha på siden man da må trykke på gassen for at bilen skal begynne å bevege seg. Antar noen liker det, men jeg bruker den aldri. Jeg har alltid foten på bremsen når jeg ønsker å stå stille med bilen i gir og har absolutt ingen interesse av at bilen skal gi meg anledning eller incentiver til å ha foten noe annet sted i en slik situasjon.

Ingen av disse knappene er touch knapper. Auto hold knappen er ganske fast og må trykkes nogså bestemt for å aktueres. Den er også nær nok armstøtten til at hånden ikke havner der naturlig slik den gjør på girvelgeren eller hjulet.

Det er naturligvis en forenkling, men var det et poeng du ville frem til?

Den største utfordringen er det som kommer av at man opererer i et ukontrollert miljø. Så lenge man er på en vei som ikke ser så merkelig ut og med biler som ser normale ut kan billedanalysen gi rimelig gode resultater. Det er når det kommer noe uventet at disse algoritmene kan komme til kort og simpelten bli blindet siden billedanalysen ikke forstår at de ser et objekt. Så med litt snodig eller slitt veimerking, uventede veidekorasjoner, eller en lastebil som har mistet en gjenstand som normalt ikke er å finne på en vei o.l. da kan man plutselg få helt feil resultat og uten en faktisk måling av omgivelsene oppdager systemet gjerne ikke at det har tatt feil. Se f.eks hvordan AI lett kan lures til å ignorere et objekt: Nå er ikke slike scenarier så veldig viktige i SAE level 2 systemer, men ved level 3 og opp må man ha en helt annen risikohåndtering, både mot adverserielle input og mer tilfeldige feil.

Slike beregningen betinger at du identifiserer objekter og ikke barre ser pixler. Du er dermed fortsatt prisgitt en stokastisk billedanalyse og gjør fortsatt ikke direkte målinger av omgivelsene. CMOS kamera har naturlig mer sensitivitet i IR enn hva mennesker har. Så lenge man ikke skal bruke kameraene til å vise bilder til mennesker kan man dermed droppe IR filtre og ha mer IR sensitivitet. Det er greit nok, men viktigst er nok å kunne droppe fargefiltre overhode som øker total sensitivitet med 2-4x.

Gjetter avstanden fra normal skulderposisjon til skjerm er større i en BMW hvor man ikke er tenkt å skulle trykke på skjermen normalt.

Mange måter å få ting til å fungere på, i robotmiljøer er normalen at man har langt mer kontroll på omgivelsene enn hva en bil vil ha. Dermed kan man stramme kraftig inn på påkrevd konfidens i den stokastiske analysen og dermed få langt færre feil. Stereokameraer er også en måte å forbedre presisjonen, da kan man forenkle problemet til å kunne identifisere samme objekt i begge synsfelt og så beregne avstand ved å måle vinkel. Så lenge korreleringen av begge bilder går bra vel å merke (som igjen er en stokastisk prosess og ikke en presis måling). For at en bil skal bruke dette må den utstyres med flere kamera enn det som er vanlig, og de må plasseres spredt ut.

Nei, flere datakilder gir deg redundans og mindre feil, ikke mer. Med flere datakilder kan du identifisere og luke ut dårlige datapunkter ved å krysskorrelere og sammenligne konfidens. Har du bare en datakilde oppdager du ikke feilene.

Kameraer ser ikke dybde. Billedanalyse kan forsøke å gjette seg til dybde basert på det de ser, men disse teknikkene er av variabel pålitelighet og variabiliteten er lite kvantiserbar. Det er en vesensforskjell på å måle en avstand direkte, og å prøve å finne det via en eller annen stokastisk metode. Det er omtrent som forskjellen mellom å bruke en lasermålet for å måle hvor stort et rom er mot å ta bilde av rommet og vurdere størrelsen ut i fra hvor store rom som ser lignende ut oftest er.

Jeg har ingen mening om hvordan UI på polestar fremstår. Generellt vil jeg si at jeg har ikke inntrykk av vi nødvendigvis vektlegger de samme aspektene. Telematikkenheten har ikke nødvendigvis noe med UI å gjøre. Og hvordan mobilapplikasjoner opptrer har igjen ikke nødvendigvis noe med UI eller telematikkenheten å gjøre. (Mobilapplikasjoner tenderer å kommunisere med serverinfrastruktur og ikke bilen direkte)

Android er ikke et OS, som du ganske riktig påpeker, men som du ikke later til å ta konsekvensen av Android et run-time miljø som kjører under linux. Det er ikke noe med det som gjør det uegnet til å kjøre et infotainment system. Tvert i mot. Infotainment (Som altså er langt i fra hele bilen) er datapresentasjon og brukergrensesnitt. Fordelen med android er at i det miljøet så finnes det en rikholdig mengde biblioteker og abstraksjoner som lar deg bygge den typen systemer siden det jo er veldig likt det man også gjør på andre UI fokuserte systemer (som mobiltelefoner). Android run-time miljøet har også en robust sikkerhetsmodell som kom ut av også mobiltelefonimarkedet hvor det ble påkrevcd siden brukere ville installere tredjepartsapplikasjoner. Dermed fikk bilprodusentene med et ekstra lag sikkerhet og mulighet til å la brukere kjøre tredjepartapplikasjoner også på bilens systemer. Det er imidlertid ikke slik at alle bilens systemer kjører under android. Det er andre systemer som er enten fysisk adskilte eller som kjører virtualisert som håndterer sikkerhetskritiske systemer. Disse kan kjøre f.eks autosar el. lignende.

Hvorfor i alle dager skal du spesialtilpasse et operativsystem. Hva er det du prøver å oppnå? Burde de som driver med software utvikling også ha et spesialtilpasset operativsystem, de som driver grafisk design. Eget operativsysstem for fiskere osv. Dette er tøv. Operativsystemets jobb er det samme uansett. Det håndterer prosesseparasjon og resursallokering og tilbyr pasale prosesstjenester. Det er null grunn til at man skal ha noe spesialtilpasset for bil i 2025. Det er ferdige gjennomtestede OS på alle nivå fra 64kB MCU systemer opp til multi GB virtualliserte parallelle CPU systemer. Det koster mye mer å prøve å skru sammen et OS fra bunnen av selv. Som du deler med alle andre som bruker OSet, fremfor å ta hele regningen selv. Tro meg, den mest forsølplede rotekoden finner du i lukkede proprietære systemer. Softwareavdelinger med nerder som lager sin egen greie i dag er softwareavdelingen som har hodet under vann og jager etter bugs og sikkerhetshull konstant om ti år når den tekniske gjelden tar de igjen. (IT avdelinger driver ikke med softwareutvikling, de driver med drift). Beste praksis i software er å finne det som virker og kopiere og gjenbruke. Det er stort sett bare yplinger uten erfaring som tror at de er så gudebenådete at alt de de skriver fra bunnen av er bedre enn det som har vært utviklet og gjennomtestet i 40 år. Seriøse utviklere gjenbruker de de kan.