Billigaste laddboxen med installation?

[martinot]

Om man inte har koppling till Tesla så hur vet man då statusen?

Enligt Tibber så låter de då Easee-boxen provladda bilen en kort stund, och då får de status och aktuell SoC hos bilen genom Typ2-kontakten (IEC 62196-2) och det protokoll som löper över den (SAE J1772), och som bilen använder när den pratar med laddboxen (Easee i detta fallet).

Detta är nog en liten missuppfattning. Den här informationen finns inte att tillgå via laddkontakten.

Bilen kan kommunicera till laddboxen att laddkontakten sitter i och att bilen vill ha ström, dvs bilen ber laddboxen sluta reläet, eller reläerna, så det kan komma fram ström.

Laddboxen kommunicerar att det är OK för laddboxen att fråga efter att sluta reläerna och även hur mycket ström bilen maximalt får dra.

Inget annat, förutom vissa feltillstånd.

Laddboxen kan alltså inte få reda på tex SoC eller bilens identitet via laddkontakten.

J1772 är egentligen en amerikansk standard. Produktstandarden som täcker in laddboxar heter IEC 61851.

Enligt Tibber så kan de läsa både bilens SoC och status gällande att ta emot laddning på detta sätt.

Har även sätt laddstationer (inte Tesla SuC) med skärmar som visar detta. Senast jag laddade hos Lidel på deras ABB-laddare så visade de vår Tesla M3 SoC exakt.

Ja, men då handlar det väl om DC-laddare?

CCS/Chademo/SuC har alla kommunikation med bilen, men det har inte J1772 som root skriver. J1772 har bara "signalering" som är till för att hantera vilken lastström bilen får dra från nätet.

I CCS, så har du samma signaleringspinnar för både DC och AC. Informationen att Easee kan kommunicera på detta sätt kommer från tekniker på Tibber (som borde ha koll) som jag pratat med.

Skulle misstänka att de kan kommunicera med ett mer intelligent protokoll över dessa kommunikationspinnar för de bilar som stödjer det. Har dock själv varken byggt eller programmerat något kring detta, så skall själv låta både detta (är spekulation från min sida hur det kan förklaras) och detaljerna vara osagt.

Nästa gång jag är på Lidel skall jag testa att ladda AC 11 kW på samma laddare med informationsskärm som jag laddade DC 50 kW på. Kan återkomma i tråden med resultat när jag fått chans att prova detta (kan dock dröja 1-2 veckor).

Då alla ABB-laddare hos Lidel har både CCS DC Typ2, CHAdeMO, och AC Typ2, så är det lätt för vem annan som helst att testa under tiden. Kul att se vad resultatet blir!

[root]

Det jag beskrev var hur en enkel laddbox för hemmabruk fungerar.

Tesla SuC har ett eget protokoll. De kommunicerar med bilen och måste få reda på bilens ID. Det är egentligen det enda de behöver. I övrigt vet jag inte hur Teslas protokoll funkar.

Som flera andra påpekat är det lite annan värld i med CCS, där finns kommunikation på högre nivå, spelar ingen roll om det är AC eller DC. Man brukar inte ha CCS som hemmaladdare..

[martinot]

Det jag beskrev var hur en enkel laddbox för hemmabruk fungerar.

Tesla SuC har ett eget protokoll. De kommunicerar med bilen och måste få reda på bilens ID. Det är egentligen det enda de behöver. I övrigt vet jag inte hur Teslas protokoll funkar.

Som flera andra påpekat är det lite annan värld i med CCS, där finns kommunikation på högre nivå, spelar ingen roll om det är AC eller DC. Man brukar inte ha CCS som hemmaladdare..

Det är inte bara Tesla, utan det finns en ISO-standard kring protokollet som jag inte minns namnet/numret på (såg ett blogginlägg av en norsk utvecklare som jobbade med det). Det är detta ISO-protokoll som Porsche och Ionity använder (och som utvecklaren jobbade med).

I CSS så har du just samma pinnar för datakommunikationen, men olika pinnar för AC- och DC-strömmen. Detta till skillnad från CHAdeMO som är helt separat kontakt, och som kör med CAN-bussen.

[martinot]

Det är inte bara Tesla, utan det finns en ISO-standard kring protokollet som jag inte minns namnet/numret på (såg ett blogginlägg av en norsk utvecklare som jobbade med det). Det är detta ISO-protokoll som Porsche och Ionity använder (och som utvecklaren jobbade med).

I CSS så har du just samma pinnar för datakommunikationen, men olika pinnar för AC- och DC-strömmen. Detta till skillnad från CHAdeMO som är helt separat kontakt, och som kör med CAN-bussen.

Googlade lite och det verkar som det protokollet heter ISO 15118-1 (finns en från 2013 som jag tror är den som används i fordon idag, och en ny från 2019).

https://www.sis.se/produkter/fordonstek ... 511812015/

[root]

Det är inte bara Tesla, utan det finns en ISO-standard kring protokollet som jag inte minns namnet/numret på (såg ett blogginlägg av en norsk utvecklare som jobbade med det). Det är detta ISO-protokoll som Porsche och Ionity använder (och som utvecklaren jobbade med).

I CSS så har du just samma pinnar för datakommunikationen, men olika pinnar för AC- och DC-strömmen. Detta till skillnad från CHAdeMO som är helt separat kontakt, och som kör med CAN-bussen.

Googlade lite och det verkar som det protokollet heter ISO 15118-1 (finns en från 2013 som jag tror är den som används i fordon idag, och en ny från 2019).

https://www.sis.se/produkter/fordonstek ... 511812015/

Typ. Men högnivåsignalering, tex 15118, används inte i laddboxar för hemmabruk, i alla fall inte idag. Det kommer helt säkert att ändras i framtiden

Det närmate man skulle kunna komma är tex prylar från nuvve.

Dessutom går det naturligtvis att läsa SoC med hjälp av en app som använder Tesla-api-hacket, https://www.teslaapi.io, men inte med en hemmabox.

[martinot]

Verkar även finnas en tysk standard som konkurrerar med ISO, som heter DIN SPEC 70121, och som baseras på en tidig draft av ISO 15118.

Men den verkar inte stödja krypterad kommunikation (TLS) eller XML-baserade digitala signaturer (vilket bla. Porsche och Ionity använder för deras kommande automatiserade betallösning).

[root]

Verkar även finnas en tysk standard som konkurrerar med ISO, som heter DIN SPEC 70121, och som baseras på en tidig draft av ISO 15118.

Men den verkar inte stödja krypterad kommunikation (TLS) eller XML-baserade digitala signaturer (vilket bla. Porsche och Ionity använder för deras kommande automatiserade betallösning).

Glöm den. Det är 15118 som gäller för framtiden. Det är ett rörligt mål, fortfarande i stark utveckling. I folkmun kallas den "Vehicle to Grid", V2G" eller "Vehicle to Everything", "V2X", vilket anspelar på att man kan mata ström från bilen till elnätet.

15118 stödjer självklart kryptering. En grundtanke är Plug&Charge, dvs det vi gjort med SuC i flera år....

[martinot]

Verkar även finnas en tysk standard som konkurrerar med ISO, som heter DIN SPEC 70121, och som baseras på en tidig draft av ISO 15118.

Men den verkar inte stödja krypterad kommunikation (TLS) eller XML-baserade digitala signaturer (vilket bla. Porsche och Ionity använder för deras kommande automatiserade betallösning).

Glöm den. Det är 15118 som gäller för framtiden. Det är ett rörligt mål, fortfarande i stark utveckling.

Absolut, tyckte bara det var lite kul info! Klassisk DIN vs ISO-krig (där den förstnämnda förlorat).

Jo, det var ju därför jag nämnde och länkade till både nuvarande 2013-versionen, även och den helt nya 2019-versionen.

15118 stödjer självklart kryptering. En grundtanke är Plug&Charge, dvs det vi gjort med SuC i flera år....

Jo, det var ju precis det jag förklarade nyss.

Datan verkar f.ö. skickas genom att pulsbreddsmodulera en högfrekvent signal över CP-pinnen i CCS/Typ2-kontakten.

Jag fann denna info i en PDF från Vector (har själv tidigare jobbat inom fordonsindustrin, och med mjukvara från bla. Vector) som beskriver kommunikationen lite övergripande:

[root]

Bägge två verkar modulera en högfrekvent signal över CP-pinnen i CSS/Typ2-kontakten.

Jag fann denna sliden i en PDF från Vector (har tidigare jobbat inom fordonsindustrin) som beskriver den lite övergripande.

Nu börjar det bli liv i tråden! Kul!

I bilden ser man en komplett laddcykel inklusive att laddboxen ändrat duty cycle, dvs informerat boxen om nytt värde på maximal ström.

Se de två första punkterna:

Duty Cycle: Maximum current 0-100% (Det är inte helt korrekt, men vi låter det vara för enkelhets skull) Som exempel betyder 10% duty cycle att bilen får dra högst 6 Ampere. Frekvensen på fyrkantvågen i bilden som boxen startar är 1 KHz.
Voltage: Charging state (-12V to +12V)

Bilden visar precis det jag menade. Duty Cycle sätts av boxen för att informera om hur mycket ström bilen får dra. "Voltage" påverkas av bilen för att informera boxen om att kontakten är i och om bilen vill att boxen skall sluta reläet(erna) Sedan finns det regler för när boxen får starta PWM etc. Men inget om SoC...

Den andra bilden visar en metod att läsa spänningen i "topparna" på fyrkantvågen.

[martinot]

Bägge två verkar modulera en högfrekvent signal över CP-pinnen i CSS/Typ2-kontakten.

Jag fann denna sliden i en PDF från Vector (har tidigare jobbat inom fordonsindustrin) som beskriver den lite övergripande.

Nu börjar det bli liv i tråden! Kul!

Men inget om SoC...

Som jag förstått så är det så är data som SoC och annat troligen något som förs över som digital högnivådata (kallad HLC enligt ISO) pulsbreddsmodulerad med hög frekvens (PLC; se nedan) över CP-pinnen.

ISO 15118-3 addresses how powerline communication (PLC) is used to modulate the digital information specified in ISO 15118-2 onto the Control Pilot (CP) pin inside the charging cable.

https://www.iso.org/obp/ui/fr/#iso:std: ... ed-1:v2:en

Speciellt av intresse är termen HLC som definieras i 3.34:

High Level Communication
HLC
bi-directional digital communication using protocol and messages and physical and data link layers specified in ISO 15118 series
Note 1 to entry: High Level Communication in ISO 15118 is compliant with the term digital communication in SAE J1772/2836/2847/2931.

Nu har jag tyvärr inte längre möjlighet att ladda ner alla ISO-dokument och svenska standardiseringsdokument (vilket jag kunder göra på mitt förra jobb), men fann lite information om det här:

https://www.sis.se/api/document/preview/80001760/

Här är en bild som jag googlade upp som visar hela stacken av information, inklusive digital data ISO 15118-2:

[andersd]

Absolut, tyckte bara det var lite kul info! Klassisk DIN vs ISO-krig (där den förstnämnda förlorat).

Jo, det var ju därför jag nämnde och länkade till både nuvarande 2013-versionen, även och den helt nya 2019-versionen.

Nja, inget direkt krig mellan DIN och ISO här. DIN SPEC 70121 är i princip ett tidigt utkast av ISO15118, tyskarna ville inte vänta med att bygga bilar med DC-laddning tills ISO15118, därför släppte man DIN SPEC 70121.

DIN stödjer mycket riktigt inte kryptering och inte heller AC.

Vidare så finns det än så länge endast en version av ISO15118 ute. -1 finns mycket riktigt i två versioner, men den specificerar bara olika use cases. För den första versionen av ISO15118 specificeras själva protokollet i -2. För den andra versionen (2019) så kommer protokollet att specificeras i -20, som med lite tur kommer ut i en FDIS-version till sensommaren/ hösten.

Kan för övrigt nämnas att det knappt finns någon bil på marknaden som stödjer ISO15118 för AC.

Senast vi kollade, så stödde Tesla endast DIN SPEC 70121 och inte ISO15118 ens för DC. Dock så är det ett tag sedan vi kollade det nu.

[andersd]

Som jag förstått så är det så är data som SoC och annat troligen något som förs över som digital högnivådata (kallad HLC enligt ISO) pulsbreddsmodulerad med hög frekvens (PLC; se nedan) över CP-pinnen.

ISO 15118-3 addresses how powerline communication (PLC) is used to modulate the digital information specified in ISO 15118-2 onto the Control Pilot (CP) pin inside the charging cable.

Ja,som sagt, ISO15118 (och därmed även DIN) är en IP-baserad protkollstack som körs via ett PLC-modem.

Vid DC-laddning så finns SoC med som en parameter, dock är den tyvärr inte med i AC/laddning.

SoC kommer även vara helt frivilligt för bilen att skicka i nästa version...

[root]

Som jag förstått så är det så är data som SoC och annat troligen något som förs över som digital högnivådata (kallad HLC enligt ISO) pulsbreddsmodulerad med hög frekvens (PLC; se nedan) över CP-pinnen.

ISO 15118-3 addresses how powerline communication (PLC) is used to modulate the digital information specified in ISO 15118-2 onto the Control Pilot (CP) pin inside the charging cable.

Ja,som sagt, ISO15118 (och därmed även DIN) är en IP-baserad protkollstack som körs via ett PLC-modem.

Vid DC-laddning så finns SoC med som en parameter, dock är den tyvärr inte med i AC/laddning.

SoC kommer även vara helt frivilligt för bilen att skicka i nästa version...

Tack Andersd för förtydligandet om SoC och skillnaden mellan vid DC- och AC-laddning. Jag har själv inte jobbat med 15118 ännu, är fortfarande kvar i 61851-träsket..

[martinot]

Som jag förstått så är det så är data som SoC och annat troligen något som förs över som digital högnivådata (kallad HLC enligt ISO) pulsbreddsmodulerad med hög frekvens (PLC; se nedan) över CP-pinnen.

ISO 15118-3 addresses how powerline communication (PLC) is used to modulate the digital information specified in ISO 15118-2 onto the Control Pilot (CP) pin inside the charging cable.

Ja,som sagt, ISO15118 (och därmed även DIN) är en IP-baserad protkollstack som körs via ett PLC-modem.

Vid DC-laddning så finns SoC med som en parameter, dock är den tyvärr inte med i AC/laddning.

SoC kommer även vara helt frivilligt för bilen att skicka i nästa version...

Tack. Då har vi det klart. Märkligt dock att bilen enligt standarden inte kan skicka SoC bara för att man laddar AC istället för DC?

Det fysiska gränssnittet är ju exakt det samma, och då tycker man att det borde gå att ha samma protokoll och datafunktionalitet (som redan finns på plats i bilen och mjukvarustacken) oavsett DC eller AC?

Men alla standarder är ju inte alltid hel logiska eller helt genomtänkta (i min erfarenhet), så helt förvånad är jag kanske ändå inte, även om det är lite märkligt.

Sedan är jag lite förvånad att man inte valt att använda CAN-bussen, som är vanlig i både bilar och båtar, som hos CHAdeMO?

Har för mig att även den kinesiska standarden även den använder CAN (eller om det var den enklare LIN).

Men det kanske handlar om att man vill minimera antalet fysiska pinnar och kontakter i CCS/Typ2.

Jo, jag har förstått att det är standard IP-paket man kör. Att tunnla vanliga IP-paket är ju smart och vettigt. Då kan man ju återanvända mycket kod från färdiga mjukvarustackar (som man gör med tex. TLC och annat), och även lätt låta bil och annan utrustning enkelt köra samma IP-stack och övrig kod över tex. trådlös WiFi istället.

[root]

Som jag förstått så är det så är data som SoC och annat troligen något som förs över som digital högnivådata (kallad HLC enligt ISO) pulsbreddsmodulerad med hög frekvens (PLC; se nedan) över CP-pinnen.

ISO 15118-3 addresses how powerline communication (PLC) is used to modulate the digital information specified in ISO 15118-2 onto the Control Pilot (CP) pin inside the charging cable.

Ja,som sagt, ISO15118 (och därmed även DIN) är en IP-baserad protkollstack som körs via ett PLC-modem.

Vid DC-laddning så finns SoC med som en parameter, dock är den tyvärr inte med i AC/laddning.

SoC kommer även vara helt frivilligt för bilen att skicka i nästa version...

Tack. Då har vi det klart. Märkligt dock att bilen enligt standarden inte kan skicka SoC bara för att man laddar AC istället för DC?

Det fysiska gränssnittet är ju exakt det samma, och då tycker man att det borde gå att ha samma protokoll och datafunktionalitet (som redan finns på plats i bilen och mjukvarustacken) oavsett DC eller AC?

Men alla standarder är ju inte alltid hel logiska eller helt genomtänkta (i min erfarenhet), så helt förvånad är jag kanske ändå inte, även om det är lite märkligt.

Sedan är jag lite förvånad att man inte valt att använda CAN-bussen, som är vanlig i både bilar och båtar, som hos CHAdeMO?

Har för mig att även den kinesiska standarden även den använder CAN (eller om det var den enklare LIN).

Men det kanske handlar om att man vill minimera antalet fysiska pinnar och kontakter i CCS/Typ2.

Jo, jag har förstått att det är standard IP-paket man kör. Att tunnla vanliga IP-paket är ju smart och vettigt. Då kan man ju återanvända mycket kod från färdiga mjukvarustackar (som man gör med tex. TLC och annat), och även lätt låta bil och annan utrustning enkelt köra samma IP-stack och övrig kod över tex. trådlös WiFi istället.

Detta med SoC över AC eller DC gäller 15118, dvs inget som hemmaladdare kommer i närheten av ännu.

Hemmaladdare kommer inte inte åt SoC från bilen, hur gärna vi än vill.

[martinot]

Som jag förstått så är det så är data som SoC och annat troligen något som förs över som digital högnivådata (kallad HLC enligt ISO) pulsbreddsmodulerad med hög frekvens (PLC; se nedan) över CP-pinnen.

ISO 15118-3 addresses how powerline communication (PLC) is used to modulate the digital information specified in ISO 15118-2 onto the Control Pilot (CP) pin inside the charging cable.

Ja,som sagt, ISO15118 (och därmed även DIN) är en IP-baserad protkollstack som körs via ett PLC-modem.

Vid DC-laddning så finns SoC med som en parameter, dock är den tyvärr inte med i AC/laddning.

SoC kommer även vara helt frivilligt för bilen att skicka i nästa version...

Tack. Då har vi det klart. Märkligt dock att bilen enligt standarden inte kan skicka SoC bara för att man laddar AC istället för DC?

Det fysiska gränssnittet är ju exakt det samma, och då tycker man att det borde gå att ha samma protokoll och datafunktionalitet (som redan finns på plats i bilen och mjukvarustacken) oavsett DC eller AC?

Men alla standarder är ju inte alltid hel logiska eller helt genomtänkta (i min erfarenhet), så helt förvånad är jag kanske ändå inte, även om det är lite märkligt.

Sedan är jag lite förvånad att man inte valt att använda CAN-bussen, som är vanlig i både bilar och båtar, som hos CHAdeMO?

Har för mig att även den kinesiska standarden även den använder CAN (eller om det var den enklare LIN).

Men det kanske handlar om att man vill minimera antalet fysiska pinnar och kontakter i CCS/Typ2.

Jo, jag har förstått att det är standard IP-paket man kör. Att tunnla vanliga IP-paket är ju smart och vettigt. Då kan man ju återanvända mycket kod från färdiga mjukvarustackar (som man gör med tex. TLC och annat), och även lätt låta bil och annan utrustning enkelt köra samma IP-stack och övrig kod över tex. trådlös WiFi istället.

Detta med SoC över AC eller DC gäller 15118, dvs inget som hemmaladdare kommer i närheten av ännu.

Hemmaladdare kommer inte inte åt SoC från bilen, hur gärna vi än vill.

Vad är orsaken?

Låter som en självklart bra och användbar grej att implementera för alla laddboxar.

Skall för övrigt bli intressant nästa gång jag testar ABB-laddaren på Lidel om den ger SoC även på AC-laddning (som inte skall stödjas enligt andra i tråden). Kommer tillbaka om det, om inte någon annan hinner före.

[root]

Det finns en standard, IEC 61851, som laddare och bilar följer. Standarden är nyckeln till att det fungerar så pass bra som det gör mellan olika boxar, laddare och bilar. Om någon tillverkare avviker innebär det naturligtvis att man inte längre är kompatibel med annat än det man just gjort ett hack till. Med kommunikationen som beskrivs i 61851-1 går det inte att få ut SoC, kommandot finns liksom inte. Det finns inga kommandon överhuvudtaget, bara en PWM och spänningsnivåer. Att vissa snabbladdare kan få ut SoC är en annan sak. Man använder inte den tekniken i vanliga hemmaboxar.

Om du trots allt är sugen på en box för hemmabruk som läser SoC kan detta vara ett alternativ: https://www.mobilityhouse.com/int_en/dc ... w-ccs.html

Men det är kanske inte "Billigaste laddboxen med installation?" Men man hade nog fått skattereduktion för grön teknik på den, om den innehåller en MID-mätare vill säga!

[andersd]

Vad är orsaken?

Låter som en självklart bra och användbar grej att implementera för alla laddboxar.

Skall för övrigt bli intressant nästa gång jag testar ABB-laddaren på Lidel om den ger SoC även på AC-laddning (som inte skall stödjas enligt andra i tråden). Kommer tillbaka om det, om inte någon annan hinner före.

Tja, orsaken är gissningsvis:

1. Kostnad
2. Kostnad
3. Kostnad

i ungefär den ordningen...

För att vara något mer seriös (delar av slutsatserna är mina privata åsikter):
Alla bilar kan ladda på vanlig, enkel Typ2. Biltillverkarna prioriterar därmed inte att lägga till stöd för mer avancerad kommunikation här, då de själva hittills inte haft någon större vinning med det.
Alla bilar måste implementera DIN SPEC 70121 för att vara säkra att kunna ladda på alla CCS-stationer. Detta gör att alla CCS-stationer måste implementera DIN SPEC 70121 för att veta att alla bilar kan ladda. Biltillverkarna har därmed inte prioriterat att få ut bilar som stödjer ISO15118 på marknaden, då de sett en försumbar nytta...

Om bilarna inte implementerar ISO15118, så kan ingen nyttja detta för AC-laddning. Tillverkarna av AC-laddstationer har då inte haft några större incitament att bygga stationer som stödjer detta, de dels knappt några bilar har stött ISO15118 och bland det fåtal som gjort det, så är det ännu förre som stött det protokollet för AC-laddning. I och med att det knappt finns bilar som stödjer det, så finns det inga (väldigt få) köpare av AC-laddstatationer som är beredda att betala den extra kostnad det innebär att lägga till stöd för ISO15118 (såväl HW, SW som test och certifiering).

[martinot]

Det finns en standard, IEC 61851, som laddare och bilar följer. Standarden är nyckeln till att det fungerar så pass bra som det gör mellan olika boxar, laddare och bilar. Om någon tillverkare avviker innebär det naturligtvis att man inte längre är kompatibel med annat än det man just gjort ett hack till. Med kommunikationen som beskrivs i 61851-1 går det inte att få ut SoC, kommandot finns liksom inte. Det finns inga kommandon överhuvudtaget, bara en PWM och spänningsnivåer. Att vissa snabbladdare kan få ut SoC är en annan sak. Man använder inte den tekniken i vanliga hemmaboxar.

Om du trots allt är sugen på en box för hemmabruk som läser SoC kan detta vara ett alternativ: https://www.mobilityhouse.com/int_en/dc ... w-ccs.html

Men det är kanske inte "Billigaste laddboxen med installation?" Men man hade nog fått skattereduktion för grön teknik på den, om den innehåller en MID-mätare vill säga!

Hade varit coolt med egen DC-laddare hemma, men lite väl dyrt.

Hoppas dock att det kommer ner i pris så småningom. Vill ju skaffa solceller någon gång i framtiden, och gillar tanken att man inte behöver gå med alla effektförluster genom DC->AC->DC, utan kan ladda bilen direkt med en DC-DC-konverter istället (eller en spänningsreglerad DC-lösning).

Men ser inte att det skulle vara något problem (tekniskt talar vi om alltså) att köra 61851-2 med PLC även om man laddar via AC istället för DC. Känns ju fånigt omodernt dumt att de inte löst att man kan ha denna intelligenta och flexibla IP-kommunikation, bara för att man laddar AC istället för DC?

[martinot]

Vad är orsaken?

Låter som en självklart bra och användbar grej att implementera för alla laddboxar.

Skall för övrigt bli intressant nästa gång jag testar ABB-laddaren på Lidel om den ger SoC även på AC-laddning (som inte skall stödjas enligt andra i tråden). Kommer tillbaka om det, om inte någon annan hinner före.

Tja, orsaken är gissningsvis:

1. Kostnad
2. Kostnad
3. Kostnad

i ungefär den ordningen...

Hur dyrt kan ett simpelt chip för PLC-kommunikation vara egentligen?

Chip för LIN är extremt billiga (några få kronor i volym), och CAN-chip kan du hitta för under hundralappen i volym.

Tycker det känns fånigt att man inte har åtminstone "optional" stöd för det i standarden?

Men inte ens det köper jag knappt. Borde nästan vara "mandatory". Varför? Med tanke på att i princip alla moderna bilar ändå kan ladda DC, så finns ju både alla chip och all mjukvara färdigt i alla bilar oavsett. Då blir det ju ingen direkt extra kostnad, eller hur (förutom möjligen en extremt kort och billig validering att det fungerar lika fint att parata IP över CP-pinnen när man laddar såväl AC som DC).

[andersd]

Hur dyrt kan ett simpelt chip för PLC-kommunikation vara egentligen?

Chip för LIN är extremt billiga (några få kronor i volym), och CAN-chip kan du hitta för under hundralappen i volym.

Tycker det känns fånigt att man inte har åtminstone "optional" stöd för det i standarden?

Men inte ens det köper jag knappt. Borde nästan vara "mandatory". Varför? Med tanke på att i princip alla moderna bilar ändå kan ladda DC, så finns ju både alla chip och all mjukvara färdigt i alla bilar oavsett. Då blir det ju ingen direkt extra kostnad, eller hur (förutom möjligen en extremt kort och billig validering att det fungerar lika fint att parata IP över CP-pinnen när man laddar såväl AC som DC).

Tja, ett första problem är som sagt att det endast är ett fåtal bilar som överhuvudtaget pratar ISO15118, vilket gör att OEM:erna har ett hyffsat stort SW och test/certifieringsjobb. (Nu spekulerare jag) om de inte har bedömt att ISO15118 har behövts för DC, så minskar rimligen deras intresse av att implementera detta för AC... Vilket jag inte kan annat än beklaga, då detta skulle möjliggöra att bilen kommunicerar sina laddbehov till en AC-station, vilket skulle underlätta att göra en vettig planering på större site:er (tänk lastbalansering/-hantering).

Tyvärr kan du inte jämföra ett PLC-modem med vare sig LIN- eller CAN-transceivers. Prisbilden är och har framförallt varit betydligt högre, sedan är även SW-stacken betydligt större och mer komplex.
Som sagt, jag skulle väldigt gärna se att alla bilar som stödjer CCS implementerade stöd för ISO15118, både för AC och DC. Då skulle det bli betydligt lättare för tillverkarna av laddstationer att bygga in stöd för detta och få köpare till den funktionen.

Sedan om vi ska hoppa tillbaka till SoC, så var det som sagt på väg helt ur nästa version av ISO15118. OEM:erna såg dels inte nyttan med att låta laddstationen ta del av detta, dels hävdade de integritetsproblem mm. Kompromissen där blev till slut att SoC finns med som en valfri parameter...

[martinot]

Hur dyrt kan ett simpelt chip för PLC-kommunikation vara egentligen?

Chip för LIN är extremt billiga (några få kronor i volym), och CAN-chip kan du hitta för under hundralappen i volym.

Tycker det känns fånigt att man inte har åtminstone "optional" stöd för det i standarden?

Men inte ens det köper jag knappt. Borde nästan vara "mandatory". Varför? Med tanke på att i princip alla moderna bilar ändå kan ladda DC, så finns ju både alla chip och all mjukvara färdigt i alla bilar oavsett. Då blir det ju ingen direkt extra kostnad, eller hur (förutom möjligen en extremt kort och billig validering att det fungerar lika fint att parata IP över CP-pinnen när man laddar såväl AC som DC).

Tja, ett första problem är som sagt att det endast är ett fåtal bilar som överhuvudtaget pratar ISO15118, vilket gör att OEM:erna har ett hyffsat stort SW och test/certifieringsjobb. (Nu spekulerare jag) om de inte har bedömt att ISO15118 har behövts för DC, så minskar rimligen deras intresse av att implementera detta för AC... Vilket jag inte kan annat än beklaga, då detta skulle möjliggöra att bilen kommunicerar sina laddbehov till en AC-station, vilket skulle underlätta att göra en vettig planering på större site:er (tänk lastbalansering/-hantering).

Tyvärr kan du inte jämföra ett PLC-modem med vare sig LIN- eller CAN-transceivers. Prisbilden är och har framförallt varit betydligt högre, sedan är även SW-stacken betydligt större och mer komplex.
Som sagt, jag skulle väldigt gärna se att alla bilar som stödjer CCS implementerade stöd för ISO15118, både för AC och DC. Då skulle det bli betydligt lättare för tillverkarna av laddstationer att bygga in stöd för detta och få köpare till den funktionen.

Sedan om vi ska hoppa tillbaka till SoC, så var det som sagt på väg helt ur nästa version av ISO15118. OEM:erna såg dels inte nyttan med att låta laddstationen ta del av detta, dels hävdade de integritetsproblem mm. Kompromissen där blev till slut att SoC finns med som en valfri parameter...

Är inte riktigt med på hur jag skall tolka marknadsbilden (det tekniska är jag med på); menar du att inte alla elbilar som laddar DC också stödjer IP-kommunikation (över ISO15118)?

Hur mycket kostar ett PLC-chip (ungefär) i någorlunda volymer (säg 100k)?

[andersd]

Är inte riktigt med på hur jag skall tolka marknadsbilden (det tekniska är jag med på); menar du att inte alla elbilar som laddar DC också stödjer IP-kommunikation (över ISO15118)?

Japp.
Tar vi CCS, vilket är vad vi pratar om här, så finns det dels DIN SPEC 70121 (i princip ett tidigt utkast till ISO15118). DIN SPEC 70121 stödjer *alla*, iom att den kom ut först (det var hela syftet).
DIN SPEC 70121 stödjer enbart DC, enbart extern identifiering och körs okrypterat mellan laddstation och bil.
ISO 15118 skriver sedan delvis om delarna ovan, samt lägger till stöd för bl.a. kryptering, AC, Plug'n'Charge.

Idag finns det mindre än en handfull bilar på marknaden som stödjer ISO15118 för DC. Stöd för AC och P'n'C finns inte hos merparten av den lilla mängd bilar som ens stödjer ISO15118 för DC...

Detta är tyvärr den krassa verkligheten och då släpptes ISO15118 under 2013-14. De flesta OEM:er verkar ha resonerat att det räcker att bilarna kan ladda på CCS-stationer, alltså nöjer de sig med DIN SPEC 70121. R&D-avdelningarna har numera som regel iaf stöd för ISO15118 för åtminstone DC, men att sedan få ut detta på marknaden...

[martinot]

Är inte riktigt med på hur jag skall tolka marknadsbilden (det tekniska är jag med på); menar du att inte alla elbilar som laddar DC också stödjer IP-kommunikation (över ISO15118)?

Japp.
Tar vi CCS, vilket är vad vi pratar om här, så finns det dels DIN SPEC 70121 (i princip ett tidigt utkast till ISO15118). DIN SPEC 70121 stödjer *alla*, iom att den kom ut först (det var hela syftet).
DIN SPEC 70121 stödjer enbart DC, enbart extern identifiering och körs okrypterat mellan laddstation och bil.
ISO 15118 skriver sedan delvis om delarna ovan, samt lägger till stöd för bl.a. kryptering, AC, Plug'n'Charge.

Idag finns det mindre än en handfull bilar på marknaden som stödjer ISO15118 för DC. Stöd för AC och P'n'C finns inte hos merparten av den lilla mängd bilar som ens stödjer ISO15118 för DC...

Detta är tyvärr den krassa verkligheten och då släpptes ISO15118 under 2013-14. De flesta OEM:er verkar ha resonerat att det räcker att bilarna kan ladda på CCS-stationer, alltså nöjer de sig med DIN SPEC 70121. R&D-avdelningarna har numera som regel iaf stöd för ISO15118 för åtminstone DC, men att sedan få ut detta på marknaden...

Så man kan säga att alla som laddar på DC klarar minst DIN70121, og nyare bilar även stödjer ISO15118?

Jag antar att både DIN70121 og ISO15118 använder samma PLC-chip och hårdvara i övrigt (som jag förstått det), men skiljer bara i de protokollen som är högre upp i mjukvarustacken?

[andersd]

Så man kan säga att alla som laddar på DC klarar minst DIN70121, og nyare bilar även stödjer ISO15118?

Jag antar att både DIN70121 og ISO15118 använder samma PLC-chip och hårdvara i övrigt (som jag förstått det), men skiljer bara i de protokollen som är högre upp i mjukvarustacken?

Alla bilar som laddar med CCS, stödjer DIN70121, annars skulle de inte kunna ladda på alla CCS-stationer.

Inte alla, men några få ny bilar stödjer även ISO15118, främst för DC.

HW är i princip kompatibel, ja. Det finns smärre skillnader på låg nivå, men det brukar man kunna hantera, även om det innebär att man inte uppfyller något enstaka krav här och där.