sverreb

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.

Det er ikke gitt. Regenereringen er omtrent en magnitude svakere enn de mekaniske bremsene (typisk 50-200kW mot 0.5-1MW), og siden du ikke kan ha bremseberedskap (I.e. ha foten over bremsen når man er i en tvilsom situasjon) med enpedalkjøring kan det godt ta lengre tid å aktuere bremsepedalen. At man da får litt bruk av regen først har nesten ingenting å si sammenlignet med effekten av de mekaniske bremsene og å få de på tidligere.

Så bilen har altså ikke frunk. Du har m.a.o. ingen garanti for at denne ettermonteringen skaper problemer for antagelsene utviklerne har gjort når de lagde bilen.

Hvordan vet du det? Sikker på at man ikke kunne omdisponert plassen uten frunken? Er vel ingen av oss som vil kunne svare på det, vi trenger noen ingeniører fra VAG til å kunne si dette sikkert en vei eller en annen.

Bare fordi det er tomt betyr ikke det ikke er utnyttet/viktig. Viser til tidligere diskusjon av kollisjonssoner. Du kan ikke uten videre plassere en frunk over alt. At det i ICE variantene er motordeler der endrer ikke på det, de er kjente og kan modelleres inn i kollisjonsytelsen. De monteres slik at de ikke dyttes inn i kabinen eller bidrar til at andre ting dyttes inn i kabinen i en kollisjon. Bilen kunne helt sikkert vært designet anneledes om den ikke også skulle eksistert som ICEv, men som sagt da skulle man ideeelt sett kortet ned fronten, ikke fylle den med bagasjeplass.

Det er ikke ekstra plass, det er en omdisponering av plass fra kabin/bagasjerom til frunk.

Hverken BMW ix eller Mercedes eqs har frunk, ingen av de finnes eller har noen gang vært påtenkt i en ikke BEV versjon. Det er en del fordeler også helt uten tanke for kollisjonssikkerhet: Man trenger ikke designe panseret for å åpnes i det daglige, dermed kan man droppe gassstruts, servoer, plastlinere o.l. Hvorfor de nå velger å inkludere det vet jeg ikke, sannsynligvis for mange kunder som handler bil etter avkryssingsliste. Jeg håper de ikke har kastet bort mye plass på det, og fortrinnsvis er der bare i bakhjulstrekkvariantene. (eller sagt med andre ord: ikke kaster bort plass i de fullt utstyrte variantene)