Protokół OCPP jest dziś domyślnym językiem, którym stacja ładowania pojazdów elektrycznych rozmawia z chmurą. Jeśli projektujesz ładowarkę AC 22 kW albo szybką stację DC 150 kW, prędzej czy później staniesz przed decyzją: OCPP 1.6J czy 2.0.1, jak zapiąć TLS i jak zmieścić stos komunikacyjny w budżecie pamięci kontrolera. Ten artykuł porządkuje te zagadnienia od strony inżynierskiej.
W skrócie: protokół OCPP (Open Charge Point Protocol) to otwarty standard aplikacyjny, opracowany przez Open Charge Alliance, który definiuje komunikaty wymieniane między stacją ładowania EV a systemem zarządzania CSMS — obecnie najczęściej w postaci JSON-RPC przesyłanego trwałym połączeniem WebSocket.
Czym jest protokół OCPP i jaki problem rozwiązuje?
Protokół OCPP to niezależny od producenta standard komunikacji między punktem ładowania a systemem zarządzania (Charging Station Management System, CSMS). Powstał, aby operator sieci nie był na zawsze przywiązany do jednego dostawcy sprzętu.
Open Charge Alliance opublikowała pierwszą wersję w 2010 roku. Kolejne kamienie milowe to OCPP 1.6 (2015), OCPP 2.0.1 (marzec 2020) oraz OCPP 2.1 (2025), która rozszerza standard o ładowanie dwukierunkowe i scenariusze V2X. Dzięki temu jedna ładowarka może w cyklu życia zmienić operatora backendu bez wymiany elektroniki.
Z punktu widzenia architektury to klasyczny przypadek urządzenia brzegowego z trwałą sesją do chmury — podobnie jak w rozwiązaniach opartych o protokół MQTT w systemach IoT, tyle że z twardo zdefiniowanym słownikiem komunikatów zamiast dowolnych tematów.
Jak działa protokół OCPP na poziomie transportu?
OCPP w wariancie JSON działa jako RPC nad WebSocket (RFC 6455). Stacja jest klientem: nawiązuje połączenie do CSMS pod adresem wss://host/ocpp/<identyfikator-stacji> i deklaruje podprotokół ocpp1.6 lub ocpp2.0.1.
Każda wiadomość to tablica JSON z identyfikatorem typu: 2 dla wywołania (CALL), 3 dla odpowiedzi (CALLRESULT) i 4 dla błędu (CALLERROR). Do tego unikalny identyfikator korelacji, nazwa akcji i ładunek. Prostota tego formatu jest zaletą — parser mieści się w kilku kilobajtach kodu.
- BootNotification — stacja zgłasza model, producenta i wersję firmware po starcie; CSMS zwraca interwał heartbeat (typowo 300 s) i status akceptacji.
- Heartbeat — utrzymanie sesji i synchronizacja czasu.
- StatusNotification — zmiana stanu konektora (Available, Occupied, Faulted).
- Authorize — weryfikacja tokenu RFID lub identyfikatora kierowcy.
- TransactionEvent — w 2.0.1 jeden komunikat obsługuje start, aktualizacje i koniec sesji ładowania (w 1.6 były to osobne StartTransaction i StopTransaction).
- MeterValues — odczyty licznika energii, mocy, napięcia i prądu, zwykle co 30–60 s.
- SetChargingProfile — narzucenie limitu mocy lub prądu przez operatora.
OCPP 1.6J czy 2.0.1 — którą wersję wybrać?
OCPP 2.0.1 jest wersją docelową dla nowych projektów, a 1.6J pozostaje bezpiecznym wyborem tam, gdzie liczy się natychmiastowa kompatybilność z istniejącym backendem. Obie wersje są nadal aktywnie wspierane przez rynek.
Kluczowa różnica to model urządzenia. W 1.6J konfiguracja to płaska lista par klucz–wartość obsługiwana przez ChangeConfiguration. W 2.0.1 wprowadzono komponenty i zmienne z SetVariables oraz GetVariables, więc backend może odpytać ładowarkę o jej rzeczywiste możliwości.
Druga różnica to ISO 15118. Wersja 2.0.1 natywnie obsługuje Plug & Charge — kierowca podłącza kabel, a uwierzytelnienie odbywa się certyfikatem zaszytym w pojeździe, bez karty i aplikacji. Zarządzanie tymi certyfikatami odbywa się w ramach protokołu OCPP.
Bezpieczeństwo: profile, TLS i certyfikaty
Stacja ładowania jest urządzeniem publicznie dostępnym, fizycznie niechronionym i podłączonym do systemu rozliczeniowego — czyli celem o wysokiej wartości. Standard definiuje trzy profile bezpieczeństwa, od HTTP Basic bez szyfrowania po wzajemne TLS z certyfikatem klienta.
W praktyce produkcyjnej rekomendujemy wyłącznie profil 3: mutual TLS z kluczem prywatnym przechowywanym w układzie Secure Element, nigdy w zwykłym flashu. Zasady zarządzania tożsamością urządzeń opisaliśmy szerzej przy okazji certyfikatów X.509 we flotach IoT.
Do tego dochodzi zaufany łańcuch rozruchu — bez niego szyfrowany kanał chroni dane w tranzycie, ale nie chroni samego urządzenia. Warto zajrzeć do naszego materiału o bezpiecznym rozruchu (secure boot) w urządzeniach IoT.
Smart charging: jak OCPP steruje mocą?
Smart charging w OCPP to mechanizm ograniczania mocy ładowania przez profile czasowe wysyłane z backendu. Pozwala on utrzymać sumaryczny pobór parkingu poniżej mocy przyłącza, bez rozbudowy infrastruktury elektrycznej.
Profil ładowania zawiera harmonogram okresów, w których obowiązuje limit wyrażony w amperach lub watach. Standard rozróżnia profil całej stacji, profil domyślny transakcji oraz profil konkretnej sesji — priorytety pozwalają nałożyć limit operatorski na indywidualne ustawienia.
Typowy scenariusz: 20 ładowarek AC 22 kW na przyłączu 250 kW. Zamiast blokować stanowiska, CSMS dynamicznie dzieli dostępną moc. Logika decyzyjna działa w chmurze, ale reakcja musi być szybka — dlatego część algorytmów przenosi się bliżej urządzenia, w duchu edge computingu w IoT.
Jak wdrożyć protokół OCPP w firmware ładowarki?
Wdrożenie stosu OCPP to projekt firmware, a nie tylko integracja biblioteki. Realistycznie wymaga kontrolera aplikacyjnego klasy Linux (np. STM32MP1, i.MX 8M) albo mocnego MCU z co najmniej 512 kB RAM, obok osobnego kontrolera odpowiedzialnego za sterowanie sygnałem Control Pilot.
- Rozdziel warstwy: sterowanie mocą i bezpieczeństwo elektryczne muszą działać niezależnie od dostępności łącza.
- Zaimplementuj trwałą kolejkę zdarzeń — sesja ładowania rozliczana jest finansowo, więc żaden
TransactionEventnie może zginąć przy zerwaniu sieci. - Zapewnij aktualizacje zdalne. Standard definiuje komunikaty aktualizacji firmware, ale niezawodność zapewnia dopiero poprawny mechanizm A/B — patrz aktualizacje OTA firmware w skali floty.
- Testuj zgodność przed certyfikacją. Open Charge Alliance udostępnia narzędzie testowe i program certyfikacji zgodności.
- Zaplanuj telemetrię diagnostyczną ponad wymagania standardu — temperatury, jakość zasilania, liczba prób połączenia.
Najczęściej zadawane pytania (FAQ)
Czym różni się OCPP 1.6J od OCPP 2.0.1?
OCPP 1.6J to wersja z 2015 roku oparta na JSON przez WebSocket, z prostym zestawem około 30 komunikatów. OCPP 2.0.1 dodaje ustandaryzowany model urządzenia (komponenty i zmienne), obsługę ISO 15118 i Plug & Charge, wbudowane profile bezpieczeństwa, transakcje jako pojedynczy komunikat TransactionEvent oraz rozbudowaną diagnostykę i zarządzanie firmware.
Czy protokół OCPP jest obowiązkowy w Unii Europejskiej?
Unijne rozporządzenie AFIR (2023/1804) wymaga, aby publicznie dostępne punkty ładowania były cyfrowo połączone i komunikowały się z systemem zarządzania w oparciu o otwarty protokół — w praktyce oznacza to OCPP. Operatorzy przetargów publicznych i sieci roamingowych niemal zawsze wskazują OCPP 1.6J lub 2.0.1 jako wymóg minimalny.
Jak zabezpieczyć połączenie OCPP między ładowarką a chmurą?
Standard definiuje trzy profile bezpieczeństwa: uwierzytelnianie HTTP Basic bez TLS, HTTP Basic z TLS oraz wzajemne TLS z certyfikatem klienta X.509. Produkcyjnie stosuje się profil 3 — klucz prywatny w Secure Element, rotacja certyfikatów przez komunikaty zarządzania certyfikatami i weryfikacja łańcucha zaufania po obu stronach.
Podsumowanie — najważniejsze wnioski
Protokół OCPP jest fundamentem interoperacyjnej infrastruktury ładowania: uwalnia operatora od jednego dostawcy, spełnia wymagania regulacyjne i daje gotowy model smart chargingu. Wersja 2.0.1 wnosi model urządzenia, ISO 15118 i profile bezpieczeństwa, których 1.6J nie ma.
W FSS Technology projektujemy urządzenia połączone od schematu i PCB, przez firmware, po backend chmurowy i integracje. Planujesz ładowarkę EV, retrofit floty stacji albo własny CSMS? Porozmawiajmy o projektowaniu urządzeń połączonych.