sverreb

Man kan nok ikke uten videre sammenligne oppgitte forbrukstall nei. Noen oppgir med og andre uten ladetap. (I.e. hvor mye energi gikk ut av batteriet vs, hvor mye du må bruke for å lade batteriet opp igjen.)

Kommer litt an på hva du regner som 'BMS'. BMS er ikke en boks eller en softwaremodul alene. BMS består av * Overvåking og bypasskontrollere. Disse er fysisk koplet til hver enkelt celle, måler individuell cellespenning og kan shunte cellen (strømbegrenset via en resistor) for å balansere cellene. Typiske slike kretser kan overvåke opp til 16 celler, så man har flere av de i en bil. * Datainnsamling: Dette er kontrollsystemet som samler data fra overvåkningskretsene og så kommuniserer videre til styresystemene, denne sitter gjerne også i batteripakken. * Styresystem: Dette er i hovedsak software som instruerer laderegulatorer om ønsket ladespenning, informerer om maksimal belastning, styrer shunting av cellene og som bestemmer når kontaktorer lukkes og åpnes.

BMS arkitekturen er ikke anneledes for LFP vs NMC. Ladekurver og diversse parametre er anneledes, men det er bare en softwareendring unna. Men man kommer ikke til å bytte kjemi i en allerede produsert bil.

Se forøvrig: https://lovdata.no/dokument/SF/forskrift/1999-03-11-302

'Spørsmålene' dine var kun vage uspesifikke klager som koker ned til at du ikke forstod det som ble skrevet og ikke hang med på diskusjonen. Da hjelper det ikke å svare deg på nytt når det bare innebærer å gjenta meg selv. Har du konkrete spørsmål på noen av elementene i det jeg diskuterte så skal jeg forsøke å klargjøre, men disse uspesifikke klagene dine forteller meg ikke hvor du mistet tråden.

Tydelig det, det er derfor jeg ber deg lese på nytt siden forklaringen står der. Du får heller spørre om det er noe konkret som er uklart.

Da har det jo null effekt. Du kan naturligvis velge å la serverens instillinger bli nye standardinstillinger neste gang man starter bilen, men det er knappest fjernstyring av instillinger vi har snakket om, det er fjernstyring av noe som skal skje i bilen som var tema. Bilen aktiverer hovedbatteriet om det er nødvendig. De fleste bilprodusenter vil unngå at dette skal bli nødvendig annet enn når bilen lades eller når den kjøres noe som så setter begrensinger på hva applikasjonen kan tillates å gjøre. Les en gang til du. Som sagt man ønsker å minimere, helst elliminere at batteriets kontaktorer skal lukkes annet enn når det er strengt nødvendig. Dette har jeg nå sagt flere ganger. Dette setter designbegrensinger på hva man kan tillate seg å gjøre f.eks så må man optimere for minimum energibruk når bilen ikke er i bruk noe som tilsier at man må minimere hvor ofte bilen vekkes opp av fjernkontrollkommandoer.

Skal jo sies at man kan sitte i timesvis på i405 eller i75 uten å ha kommet mange kilometrene og uten å ha kommet ut for noe som er utfordrende for en adaptiv CC. Man kjører stort sett minimalt i gatene i amerikanske byer.

Det er selvsagt. Bilen og serveren synkroniseres når bilen er aktiv, det er aktiveringen i seg selv som gjerne er energimessig kostbar, ikke datautvekslingen som så skjer. At bil og server er synkron er imidlertid ikke videre relevant for diskusjonen, for interaksjonen som diskuteres er når appen oppdateres, ikke bilen. Denne oppdateringen skal presumptivt reflekteres i bilen så da må man ha en metode for at bilen skal vekkes og oppdateres. Denne metoden initieres av appen/serveren, og da må den ha et kriterie for å gjøre dette. Det kan enten være en eksplisitt bekreftelse fra brukeren, eller så må appen anta på et tidspunkt at brukeren er ferdig med å endre instillinger, noe man må bruke en timeout til og så oppdatere uten bekreftelse. Det er valgene man har. Så kommer realitetene for hvordan man lager biler inn: Man forventes å ha et svært bevisst og konservativt forhold til sikkerhet. Biler er noe av de farligste maskinene vi omgir oss med i forhold til kompetansekravene vi ilegger brukerne. Bilprodusentene gjør derfor en FMEA (Failure Mode and Effect Analysis) på hver minste komponent for å identifisere hva som kan gå galt og hvordan man minimerer risiko og konsekvens, og man har lært at man kan ikke uten videre anta en fornuftig bruker, systemet må altså lages så idiotsikkert som mulig. Derifra får vi et ønske om å minimere hvor mye energi bilen bruker mens den er inaktiv, for bruker man for mye må man gjøre tiltak som f.eks å aktivere bilens hovedbatteri, og det øker risiko. Så driver vi dette kravet over på applikasjonsutviklerne, og da kommer det ut av den prosessen at det å vekke bilen uten tydelig instruks fra brukeren dermed gir et negativt bidrag på sikkerhet p.g.a. unødig bruk av hovedbatteriet eller gir et negativt bidrag på brukeropplevelse ettersom bilen til sist må stenge for fjernkommandoer for å unngå å aktivere bilens hovedbatteri. Så blir spørsmålet hvordan man jobber seg rundt de kravene for å gi en best mulig brukeropplevelse. Man kan velge å ta seg friheter på risikoanalysen, men erfaringer tilsier at det kommer før eller siden og biter bilprodusentene bak. Det er derfor ikke uventet at bilprodusenter som har vært med en stund velger mer konservative løsninger. De som ikke lærer av andres erfaring vil måtte regne med å måtte lære av egen erfaring istedet...

Ingen brukere bryr seg om hva en server vet. Det er effekten i bilen som betyr noe. Jeg ser ikke at du ha kommet med noen forklaringenr som gir noen som helst innsikt som leder meg til andre konklusjoner. Jeg forventer faktisk at du er i stand til å delta i diskusjonen og forklare din posisjon ikke bare be andre om å kaste bort tid. Om du ikke er i stand til å komme med noe bedre enn RTFM, da kommer vi ikke videre.

Det er en overforenkling. I noen kontekster gir det mening at brukeren bekrefter instillinger fremfor at de underliggende systemene bruker bilens resurser på å implementere kommandoer som kanskje brukeren ikke ønsker, i.e. om du skal justere instillinger som kanskje skjer i mange trinn og kan innebære at en bruker endrer mening flere ganger, slik det gjerne er om instillingene har noe mer enn en av på knapp. I andre hvor det er entydig hva som ønskes som f.eks å velge en snapp som betyr start forvarming gir det mening at den sendes med en gang. Om du har et system hvor du gjør instillinger og forventer at de skal ha effekt i bilen uten at du skal bekrefte de kommer du ikke unna at UI må oppdatere bilen innen kort tid uten at den kan vite at instillingene var endelige for at bilen ikke skal oppleves uresponsiv, noe som betyr at mange kommandoer som kanskje aldri var meningen å sende vil ta effekt før de så igjen blir kansellert av brukeren. Som sagt magi finnes ikke, om du ikke ber om en bekreftelse på at et sett instillinger skal ta effekt kan du som applikasjonsutvikler ikke gjøre annet enn å anta at de skal det slik de momentant står. Applikasjonen kan velge å vente på noen sekunders inaktivitet, men neppe særlig mer.

Jeg håper du forstår at 99.9...% av brukerne aldri kommer til å skrive sin egen app, det er i realiteten kun hva den offisielle appen gjør som er relevant for brukerne, uansett hva det underliggende APIet gjør.

Da vil m.a.o. forvarmingen aldri starte. For alle formål vil da appen ikke virke. Det later ikke til å være et praktisk valg. Dette koker uansett ned til at når du har et UI som aldri forventer du skal bekrefte noe så må den oppdatere serveren med hver endring i UI og sende vekkekommandoen etter maksimalt en liten timeout for at bilen ikke skal oppleves som uresponsiv.

At du beskriver det som 'magi' tyder ikke på at du vet hva som foregår. Men hvis du skulle vite noe om hvordan serverne bestemmer når bilen skal oppdateres om det ikke er en timeout så beskriv det gjerne. Du kan godt bruke tekniske termer.

Så det er altså basert på en timeout slik jeg beskrev først, da kan du jo referere til det igjen. Magi finnes som kjent ikke. Du antar vel mye...

Så du må sende en våkne kommando for at endringene faktisk skal ta effekt? Hvordan er i så fall det forskjellig fra å trykke send?

Det er ikke egentlig ønskelig å lukke kontaktorene når bilen ikke lades eller er i bruk. Ikke at det er noen stor risiko, men det er alltid en noe høyere risiko for at feil skal få store konsekvenser når kontaktorene er lukket siden du da har høy spenning på langt flere punkter i bilen. Derfor vil man gjerne minimere tiden de er lukket og begrense det til når det er absolutt nødvendig som når bilen lader eller den kjøres. (Det er tross alt grunnen til at kontaktorene er der i første omgang) Derfor er det et rimelig kompromiss å heller være aggressiv på å spare energi når bilen ellers er passiv, selv om det medfører en og annen brukerbekreftelse, enn å la 12v batteriet tappes unødig.

Serveren må synkronisere status mot bilen. Man kan vente litt for å samle opp endringer, men siden brukeren ikke forventes å bekrefte med en 'send' kommando kan ikke serveren vente særlig lenge, maks noen sekunder, om det ikke skal gi en dårlig brukeropplevelse. I mellomtiden kan brukeren sitte og fikle i appen uten egentlig noen intensjon om å egentlig gjøre noe og holde bilen våken uforvarende. som enten resulterer i at 12v batteriet tappes ned unødig eller at hovedkontaktorene må lukkes uten at bilen lades eller at noen er til stede (som ikke er ønskelig)

Handler nok vel så mye om å ikke vekke opp bilen i tide og utide.

Du trenger jo ikke det bare for å forvarme. Det er bare i menyer man skal stille inn diverse ting du har den send til bilen knappen. For å forvarme trykker du bare på vifteikonet i appen eller widgeten:

Nå var jo hele historien at han fikset det med en skotørker. For å fikse forsseglinger og legge på ny coating, om det er problemet, må man demontere og inspisere hele batteriet, da tror jeg ikke det er beskrivende å si man bare kan fikse med en skotørker.

Utover advarselen i artikkelen*, ville jeg også vært bekymret for om man ikke her bare maskerer problemet fremfor å utbedre noe. Presumptivt får man feilmeldingen etter at systemet måler jordfeil/krypstrømmer p.g.a. fukt i systemet. Om man tørker det opp forsvinner naturlig nok krypstrømmene, men man har ikke fjernet grunnen til at fukten var der i utgangspunktet. Og mens det har vært fuktig har det gjerne blitt en del korrosjon slik at problemet kan bli verre neste gang det kommer til fukt. Det er naturligvis fint å kunne forlenge levetiden selv om det bare er midlertidig, den faktiske bekymringen er om feilen også kan lede til en katastrofal feil, i.e. kortsluttet batteri med påfølgende brann som kan medføre både mennesklige og matrielle skader. For at man skal kunne føle seg trygg på en slik operasjon må man på et vis kunne forsikre seg om at man ikke sitter på en potensiell katastrofal ulykke. *) Et EV batteri er noe man skal ha stor respekt for, dette er langt farligere enn elanlegget i huset. Spenningen er høyere og det finnes nesten ubegrenset strømkapasitet

Hvis vi antar 2l vann totalt (vann i potetene teller med) og en starttemperatur på 10C så kreves det 0.21kWh å varme opp dette til kokepunktet. Så vil du i praksis bruke en god del mer siden du lekker varme og damp til rommet. For hver kg vann som fordamper forsvinner det 0.6kWh opp i avtrekket. Vanns varmekapasitet: 4.21J/gK, vanns fordampingsvarme er 40.6kJ/mol (1 mol vann er 18 g)

Nå er ikke antallet brukere nødvendigvis så høyt. Det er ikke ett nett og en trafo fordelt på hele landet, nettet består av mange komponenter hvor mange bare forskyner noen relativt få (titalls til hundretalls) brukere. Den statistisk variasjonen blir da merkbar og det er en vesentlig praktisk forskjell om brukere tenderer til å bruke 2kW i 10 minutter eller 1kW i 20

Jeg kan ikke merke når de mekaniske bremsene tar over i min ix. Den eneste måten å se det er å kikke i displayet som viser regenereringseffekten og se at den er makset. De føles forutsigbare og proporsjonale med hvor mye pedalinput man gir.