OCPP för laddning av elbussar: Guide till integration och smart laddning

Vad är OCPP vid laddning av elbussar?

Open Charge Point Protocol, eller OCPP, är ett öppet applikationsprotokoll som används för kommunikation mellan laddstationer och centrala laddningshanteringssystem. Det hjälper operatörer att ansluta kompatibla laddare till en backend utan att vara helt beroende av en hårdvarutillverkares egenutvecklade plattform.

Expertanmärkning: Interoperabilitet bör utvärderas på arbetsflödesnivå. Ett projekt behöver inte bara verifiera att ett meddelande stöds, utan också hur laddaren tillämpar gränser, rapporterar tillståndsövergångar, lagrar offline-transaktioner och återställer efter ett nätverks- eller strömavbrott.

Open Charge Alliance beskriver OCPP som ett öppet protokoll som stöder interoperabel och skalbar laddningsinfrastruktur. Granska officiell OCPP-översikt.

I en bussdepå kan OCPP ansluta laddningsinfrastrukturlagret till en laddningssystem för elbussarFordons-SOC, avsändningsscheman och ruttkrav kommer normalt från andra system.

Laddstationens och centralsystemets roller

Laddstation

Laddstationen rapporterar tillgänglighet, kontaktens status, transaktioner, mätarvärden, larm och annan enhetsdata som stöds. Den tar emot stödda kommandon, konfigurationsändringar eller laddningsprofiler från det centrala systemet.

System för hantering av laddstationer

Det centrala systemet autentiserar och övervakar laddstationer, lagrar transaktioner, presenterar status, utfärdar fjärråtgärder och kan beräkna laddningsprofiler. I ett bussprojekt kan det också integreras med dispatch-, telematik-, mätar- och underhållssystem.

Flottoptimeringslager

Detta lager avgör vilken buss som behöver energi, hur brådskande uppgiften är och vilket mål som måste uppnås. OCPP kan bära utvalda laddningsinstruktioner, men det operativa beslutet ligger normalt hos hanteringsprogramvaran.

OCPP 1.6 jämfört med OCPP 2.0.1 jämfört med OCPP 2.1

Protokollvalet bör återspegla laddarnas tillgänglighet, nödvändiga arbetsflöden, cybersäkerhetspolicy och projektlivscykel. Jämförelsen nedan är en upphandlingsorientering och ersätter inte de officiella specifikationerna.

Open Charge Alliance uppger att OCPP 1.6 introducerade smart laddning och fortfarande används i stor utsträckning, medan OCPP 2.0.1 och OCPP 2.1 stöder mer avancerad säker och smart infrastruktur. Se OCA-FAQ och protokollöversikt.

OCPP-användningsfall i en elbussdepå

• Statusövervakning: laddare och kontakttillgänglighet, driftstillstånd och kommunikationsstatus.
• Sessionskontroll: stöd för fjärrstart, stopp, återställning och transaktionshantering.
• Mätarvärden: energi, effekt och andra mätvärden för drift och rapportering.
• Laddningsprofiler: gränser eller scheman som används av arbetsflöden för lasthantering och smart laddning.
• Felanmälan: standardiserad och leverantörsspecifik information för diagnostik.
• Konfiguration och enhetshantering: stödda parameter-, komponent- och firmware-arbetsflöden.
• Tillstånd: inloggningsuppgifter eller centralt hanterad åtkomst där depåns design kräver det.
• Händelse- och säkerhetsrapportering: stödde operativa och säkerhetsmässiga händelser för övervakning.

TrendPowers OCPP 2.0.1 smart laddningsguide förklarar hur backend-systemet kan översätta beslut om strömfördelning till laddarvända profiler.

Vad OCPP inte tillhandahåller i sig självt

OCPP standardiserar kommunikation, men det tillhandahåller inte automatiskt den kompletta driftslogiken för en elbussdepå.

• Den vet inte bussens nästa rutt om inte ett annat system tillhandahåller den informationen.
• Den avgör inte rätt avgångs-SOC.
• Den beräknar inte vilken buss som ska prioriteras.
• Det avgör inte depåns säkra elektriska tak.
• Det garanterar inte att en laddare korrekt implementerar alla nödvändiga funktioner.
• Den ersätter inte integration av fordonsflotta, dispatch, underhåll eller energihantering.

Checklista för interoperabilitetstestning

Ett trovärdigt integrationstest bör använda den avsedda laddarmodellen, firmware, nätverket och det centrala systemet. Testa både lyckad drift och återställning efter fel.

1. Uppstart och registrering: första anslutning, omstart och hämtning av konfiguration.
2. Statusövergångar: tillgängliga, förbereder, laddar, pausade, slutförande, felaktiga och otillgängliga tillstånd i tillämpliga fall.
3. Transaktioner: start, uppdatering, stopp, onormalt stopp och transaktionsåterställning.
4. Mätarvärden: enheter, fasdata, tidsstämplar, intervall och saknade värden.
5. Fjärrstyrning: starta, stoppa, återställa och auktorisera arbetsflöden som krävs av depån.
6. Laddningsprofiler: gränser, scheman, stackbeteende, uppdateringsfrekvens och borttagning av profiler.
7. Offlinebeteende: lokal drift, buffrade meddelanden, återanslutning och transaktionsavstämning.
8. Felhantering: standardfel, leverantörskoder och varningsmappning.
9. Firmware och konfiguration: stödde uppdaterings-, återställnings- och granskningsprocedurer.
10. Tidssynkronisering: tidsstämplar över laddare, mätare, flottsystem och rapporter.

OCA tillhandahåller verktyg för efterlevnadstestning och certifieringsprogram för protokollversioner och profiler som stöds. Dess uppdaterade OCPP 2.0.1-certifieringsprogram inkluderar centrala laddningsstationsfunktioner och valfria profiler. Se Information om OCPP 2.0.1-certifiering.

Säkerhets- och driftskontroller

Elbussdepåer är operativa teknikmiljöer. Fjärrstyrning bör styras av tydliga roller, revisionsregister och incidentprocedurer.

• Använd krypterad kommunikation mellan laddare och backend där det stöds och krävs.
• Hantera certifikat, inloggningsuppgifter och förnyelseprocedurer.
• Begränsa fjärråtgärder efter roll och webbplats.
• Registrera vem som ändrade gränser, profiler, konfiguration eller tillgänglighet.
• Övervaka upprepade återanslutningar, obehöriga försök och säkerhetshändelser.
• Definiera procedurer för godkännande, testning och återställning av firmware.
• Separera operativt reservbeteende från cybersäkerhetsåtgärder.

För en fokuserad översikt, läs TrendPowers OCPP 2.0.1 säkerhetsguide.

OCPP-upphandlingsfrågor för bussoperatörer

• Vilken OCPP-version och transport stöds av laddaren och CSMS?
• Är implementeringen certifierad, och för vilka profiler?
• Vilka smarta laddningsfunktioner har testats på den här firmware?
• Vad är den minsta stabila laddningseffekten?
• Hur beter sig laddaren när nätverket inte är tillgängligt?
• Hur avstäms buffrade meddelanden och transaktioner?
• Vilka leverantörsspecifika tillägg krävs?
• Hur kartläggs och underhålls felkoder?
• Vem ansvarar för certifikat, firmware och säkerhetsuppdateringar?
• Hur kommer kompatibiliteten att testas på nytt efter uppgraderingar av firmware eller backend?

Rekommenderad integrationsarkitektur

Ett bussladdningsprojekt inkluderar vanligtvis fyra sammankopplade vägar:

• Laddare ↔ CSMS: OCPP för laddarens status, sessioner, kontroll och enhetsfunktioner som stöds.
• Flotta/utskick ↔ laddningsplattform: API:er eller datagränssnitt för arbetsuppgifter och fordonsprioritet.
• Fordons-/telematik ↔ laddningsplattform: SOC, batterigränser, identitet och plats.
• Mätare/energisystem ↔ laddningsplattform: platsefterfrågan, tillgänglig kapacitet, tariffer, solenergi och lagring.

TrendPowers Guide till integration av API för laddning av elbilar täcker de icke-OCPP-gränssnitt som krävs för att ansluta laddning till flottans och företagets arbetsflöden.

Vanliga frågor

Vad gör OCPP i en elbussdepå?

Den ansluter laddare till det centrala hanteringssystemet för status, session, mätning, fjärrstyrning, konfiguration och smart laddningsarbetsflöden.

Bestämmer OCPP vilken buss som ska laddas först?

Nej. Programvaran för flotta- eller laddningshantering beräknar bussprioritet med hjälp av information om avgång, SOC, rutt och plats. OCPP kan bära de resulterande laddningsinstruktionerna.

Är OCPP 1.6 fortfarande användbar för bussladdning?

Ja, den används fortfarande i stor utsträckning. Lämpligheten beror på nödvändiga säkerhets-, enhetshanterings- och smartladdningsarbetsflöden samt på den faktiska implementeringen av laddaren.

Bör ett projekt alltid välja OCPP 2.1?

Inte automatiskt. Ta hänsyn till laddarens tillgänglighet, produktens mognad, certifiering, backend-support, nödvändiga funktioner och livscykel. En testad implementering är mer värdefull än en versionsetikett som inte stöds.

Garanterar OCPP-certifiering projektkompatibilitet?

Certifiering ökar förtroendet för att en implementering följer testade protokollprofiler, men projektet bör fortfarande validera den faktiska laddmodellen, firmware, nätverket och de nödvändiga arbetsflödena.

Kan laddare från flera tillverkare dela en backend?

De kan när deras stödda OCPP-funktioner och projektkrav är kompatibla. Testning med flera leverantörer är nödvändig eftersom implementeringar och felbeteende kan skilja sig åt.

Relaterade TrendPower-guider

• Guide till laddningssystem för elbussar
• OCPP 2.0.1 Smart Laddningsguide
• OCPP 1.6 jämfört med 2.0.1 jämfört med 2.1
• OCPP 2.0.1 Säkerhet Förklarad
• Guide till integration av API för laddning av elbilar