sverreb

Jeg kjører jevnlig fra oslo til norvestlandet i en BMW ix. Kjører på acc/styreassist hele veien på alt fra motorvei til smale veier med M skilt. Det hender feil fartsgrense plukkes opp men jeg har ikke opplevd at den har bremset for trafikk urettmessig, men den kan være ganske konservativ når bilen foran skal svinge av veien. (Jeg har imidlertid fått nødbremsen på en gang i et kryss når motgående bil vimset seg over i feil kjørebane)

Kabinradar har ingenting med ADAS systemer å gjøre. Den er der for å detektere om det er mennesker inne i bilen. Dette kommer etter hvert på alle nye biler siden det er i ferd med å bli et regulatorisk krav. Hensikten er å hindre at (i hovedsak) barn gjenglemmes i bilen og skades eller dør av å bli etterlatt i en bil som står i solen.

Den er tatt av markedet. https://support.chamberlaingroup.com/s/article/myQ-Home-Bridge-Frequently-Asked-Questions-Discontinued

Da må garasjeporten ha nettilknytting. Den fjernkontrollen fungerer på en hel masse Chamberlain garasjeportåpnere, og de fleste av de har nok ikke noen annen kommunikasjonsmulighet.

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.

Du vil ikke bruke 'nyeste' av noe slikt som android. Du vil bruke en godt testet versjon. Det å åpne for tredjepartskode betyr at du gir tilgang til noe som har hatt en ukjent QA prosess og potensiellt kan være ondsinnet. Da vil du kjøre dette i en virtualisert prosess eller en isolert maskin, og en av de viktige vurderingene du da gjør er hvilke sikkerhetsmål denne isolasjonen skal oppnå. Ett av de kan f.eks være å hindre at tredjepartsapper kan brukes til ulovlig overvåkning. Mange regioner har strenge grenser på hvordan og når man kan bedrive videovervåkning, og selv om det gjøres av en tredjepartsapp så betyr det ikke at polestar her er uten ansvar.

Jeg antar med 'dashcam apper' så mener du tredjepartsløsninger. Hvorfor er det dumt? Det som er en persons lettvinte løsning er en annens sikkerhetsmareritt. Har du gjort en risikovurdering av sikkerhetsmålene programvaren skal oppfylle? Hvilke biler støtter at tredjepartssoftware har tilgang til kamera og under hvilke forhold?

Disse er oppgitt til 92dB/W/m. M.a.o veldig lettdrevne høyttalere. Bi-amping (som er det du egentlig beskriver) har ganske lite å si. Nesten all energien går i de lave frekvensene så den kanalen som driver mellomtone og diskant ender bare med å se en høyimpedant last på bassen, men vil fortsatt måtte produsere signalet (og det er når signalnivået går i metning man får forvrengning). All den tid man ikke bytter ut eller i det minste supplerer det passive delefilteret med et aktivt før forsterkeren er det fryktelig lite å hente her. 165W er nok til å i teoren produsere 113dBa (1m), som selv når vi antar at du sitter mer enn en meter unna er nok til å gi deg hørselskade etter relativt kort tid. (men man vil naturligvis ha rom for dynamikk i musikken, så dette er også litt flåsete sagt 😉 Du har m.a.o. rikelig effekt til disse. Jeg hadde droppet tanken om å drive de med to kanaler, det er bare en unødig komplikasjon som ikke kommer til å gi noe merkbart resultat.

Det har jeg også. Min erfaring er at å bygge selv oftest er enklere på kort sikt, men så blir det gjerne at alt som ikke er absolutt kjernevirksomhet blir ikke prioritert tilstrekkelig over tid så det som en gang var en banebrytende løsning, blir raskt forbigått av løsninger som bygger på integrasjon av løsninger som hver for seg er levert av utviklere som har akkurat det systemet som sin kjernevirksomhet og dermed vedlikehodler det over tid. Hvor mange her har opplevd å jobbe ett sted som har et eller annet bedriftsinternt skreddersømsystem for en eller annen ikke-kjerneoppgave? Hvor mange har fortsatt gode erfaringer med det etter 10 år? Sagt på en annen måte: Det er mer utfordrende å klare å integrere systemer basert på standarder og rigide spesifikasjoner i starten, men det er langt mer vedlikeholdbart over tid.

Det er som på så mange felt minimal gjenværende verdi i å vedlikeholde en separat spesialsydd software stack. Hardwaren som kjører infotainmentsystemene er blitt mer kapable så man har råd til å akseptere flere lag og abstraksjoner. Samtidig har man dyttet kritiske operasjoner til separate kontrollere eller virtualiserte maskiner på hovedmaskinen, så man kan lette på trygghetskravene. Det er dermed bedre å fokusere softwareressurser på det det som er reellt sett diffrensierende for en bil som er det som går på interaksjonen med det mekaniske og mennesket i en kjøresituasjon samt sensorene som er unike for biler. Så fremfor å finne opp hjulet på nytt gjenbruker man abstraksjoner og kode oprinnelig lagd for PC og mobiltelefoner der det gir mening (I.e. GUI primitiver, task håndtering, sikkerhet og datahåndtering) Så legger man til verdi på ADAS og UI som er spesifikt for bil. Vi så den samme konsolideringen i mobilbransjen for ti år siden og i PC bransjen for 30 år siden. Infotainment er fortsatt en ganske liten del av hva en bil er så til forskjell fra mobil og PC så vil dette ha minimal betydning på konkuransesituasjonen. Dette er bare en av mange ledd av standardisering som sparer innsats. Omtrent som når man valgte å standarddisere på CANbus fremfor at hver produsent skulle lage sin egen kommunikasjonsprotokoll. Legg merke til at å bruke standardiserte undeliggende OS og abstraksjoner er ikke noe nytt. Idrive brukte tidligere QNX, nå linux/android (At man nå kan gjøre dette har en del tekniske grunner ved at man har kunne fjerne krav til hard real-time oppførsel til infotainment systemene)

Praksisen salvesen beskres og som du refererte til med 'på den måten' kalles outsourcing. Mitt poeng er at dette er veldig lite beskrivende for hva som egentlig foregår. Tier 1 leverandørenes utvikling er langt mer integrerte i produktutviklingene hos bilmerkene enn å bare kalle det 'innkjøpt via 3dje part'