Vad styr OCPP mellan laddbox och backend?
OCPP styr kommunikationen mellan laddstation, kallad Charging Station, och backend, kallad Charging Station Management System. Protokollet är öppet och ägs av Open Charge Alliance, med syftet att ge interoperabilitet och göra operatörer mindre beroende av proprietära system enligt OCA:s beskrivning läst den 5 september 2026.
I praktiken styr OCPP dialogen om sessioner, transaktioner, säkerhet och meddelanden mellan box och moln. Samma dialog avgör om en box kan flyttas till en ny operatör utan att byta hårdvara, förutsatt att box och ny backend talar samma OCPP-version. OCPP ersätter inte elanläggningens skydd eller nätbolagets krav, utan reglerar informationsutbytet ovanpå den fysiska installationen.
Vilka OCPP-versioner finns och är de kompatibla?
OCA anger tre levande versioner och att 1.6 och 2.0.1 inte är bakåtkompatibla enligt OCA:s whitepaper från den 1 mars 2023, vilket innebär att box och backend måste matcha version för att fungera tillsammans.
Skillnaderna är variantspecifika och avgör vad en laddbox med stöd för olika OCPP-utgåvor kan rapportera och ta emot från backend:
| Version | Släppt | Transport och huvudfunktion |
|---|---|---|
| OCPP 1.6 | 2015 | SOAP eller JSON över WebSocket, profiler för smart laddning och lokala RFID-listor |
| OCPP 2.0.1 | 2020 | Device model, förbättrade transaktioner, inbyggd säkerhet, utökad smart laddning, native ISO 15118 samt display och meddelanden |
| OCPP 2.1 | 2025 | Bygger på 2.0.1 med bevarad applikationslogik, tillägg för ISO 15118-20 och V2X, DER, lokal kostnadskalkyl, ad hoc-kortterminal, dynamisk QR och prepaid-kort |
Version 1.6 finns i varianter med SOAP eller JSON över WebSocket enligt OCA.
Hur påverkar OCPP inlåsning och operatörsbyte?
OCPP minskar inlåsning när hårdvara som talar samma OCPP-version mot en ny CSMS kan flyttas utan hårdvarubyte. Det är kärnan i OCA:s syfte om mindre beroende av proprietära system. För BRF och företag är det den egenskapen som gör protokollet till en avtalsfråga, inte bara en teknikfråga.
En proprietär molnbaserad box kräver i praktiken byte av box eller upplåsning via firmware för att kunna styras av en annan backend. Upphandlingen bör därför kräva att leverantören uppger exakt OCPP-version, vilka profiler som är aktiverade och hur konfiguration, nycklar och certifikat överlämnas vid byte. För laddning i företag och flerbostadshus med delad backend är det också väsentligt att avtala vem som äger användardata och debiteringshistorik vid ett byte.
Hur specificerar du säkerhet och certifiering vid upphandling?
Säkerhet specificeras per version och profil, inte med ordet OCPP-kompatibel ensamt. OCA tillhandahåller officiella testverktyg, OCTT, för både OCPP 1.6 och OCPP 2.0.1 enligt OCA:s FAQ, och certifiering finns för 1.6 och 2.0.1. Att enbart kräva kompatibilitet utan versionsnummer och profiler för Core, Smart Charging och Security räcker inte som upphandlingskrav.
Skillnaden är att säkerhet i 1.6 bygger på ett Security Whitepaper som tillval, medan 2.0.1 har obligatoriska security profiles enligt OCA:s whitepapers. I en förfrågan för BRF bör kraven därför ange version, exempelvis 2.0.1, samt krav på certifiering, säkerhetsprofil och hantering av certifikat och firmwareuppdateringar. Kopplingen till identifiering med RFID-bricka och lokal lista bör också anges per profil så att behörigheter kan granskas.
Hur kopplas OCPP till Plug and Charge och betalkort?
Plug and Charge har inbyggt ISO 15118-stöd i OCPP 2.0.1 och 2.1. OCPP 1.6 kan implementera Plug and Charge med en DataTransfer-utökning men saknar det inbyggda stödet. För en anläggning som planerar automatisk identifiering via ISO 15118 avgör versionsvalet därför om certifikat och kontraktshantering använder standardiserade meddelanden eller en leverantörsspecifik utökning mot CSMS.
Ad hoc-betalning i stolpen mappas i OCPP 2.1 som inbyggd funktion för kortterminal och QR, enligt OCA:s beskrivning av version 2.1. OCPP 1.6 och 2.0.1 behöver separat terminalintegration för motsvarande betalflöde. Version 2.1 bygger vidare på 2.0.1 och inkluderar enligt OCA stöd för ISO 15118-20 med dubbelriktad effekt, DER och lokal kostnadskalkyl, vilket gör versionsvalet väsentligt när betalterminal och fordonskommunikation ska mötas i samma backend.
