OCPP, facturare și alte componente esențiale ale unei aplicații pentru stații de încărcare

Răspuns rapid:

Arhitectura unei aplicații pentru stații de încărcare EV este construită pe trei niveluri principale: stația schimbă date cu sistemul central de management (CSMS) prin protocolul OCPP, sistemul central transmite stările către aplicația mobilă și generează facturarea pe baza datelor furnizate de contor. OCPP este un standard deschis, însă în practică fiecare producător de echipamente necesită un strat separat de adaptoare. În continuare analizăm cele 8 componente fără de care o astfel de arhitectură nu poate funcționa fiabil.

1. Comunicarea cu stația: OCPP și alegerea versiunii
OCPP (Open Charge Point Protocol) este standardul pentru schimbul de date dintre stația de încărcare (Charge Point) și sistemul central (CSMS). În 2026, majoritatea stațiilor aflate în exploatare utilizează OCPP 1.6 (de regulă varianta OCPP 1.6J, JSON prin WebSocket), deoarece este mai simplu și mai accesibil de implementat. OCPP 2.0.1 câștigă rapid teren în proiectele comerciale noi și în rețelele publice de încărcare rapidă datorită funcțiilor avansate de securitate și Smart Charging. OCPP 2.1, care introduce suport pentru V2G (Vehicle-to-Grid) și Plug & Charge, este încă rar întâlnit, însă interesul pentru această versiune crește odată cu extinderea încărcării bidirecționale. Arhitectura trebuie proiectată astfel încât să suporte simultan cel puțin versiunile 1.6 și 2.0.1, deoarece migrarea unei întregi rețele la o singură versiune poate dura ani.

2. Sistemul central (CSMS)
CSMS acceptă conexiuni WebSocket de la stații și procesează mesajele de bază ale protocolului: BootNotification (stația anunță pornirea), StatusNotification (starea conectorului – Available, Occupied, Faulted), Authorize (verificarea dreptului de încărcare), StartTransaction și StopTransaction (începerea și încheierea sesiunii), precum și MeterValues (valorile contorului în timpul încărcării). Acesta reprezintă nucleul sistemului, prin care trec toate evenimentele înainte de a ajunge în sistemul de facturare sau în aplicația mobilă.

3. Adaptoare pentru diferiți producători de echipamente
OCPP este un standard, dar nu garantează compatibilitatea completă între echipamente. Din experiența noastră, integrarea stațiilor produse în China și a echipamentelor europene CircControl a necesitat un strat dedicat de adaptoare. Fiecare producător implementează propriile extensii ale protocolului, utilizează câmpuri nestandardizate în mesaje și are particularități în tratarea erorilor. Adaptorul normalizează datele provenite de la orice producător într-un model intern unificat înainte ca acestea să fie transmise către sistemul de facturare și aplicație.

4. Motorul de facturare
Sistemul de facturare primește datele MeterValues (kWh consumați) și calculează costul final pe baza consumului real, nu a unei estimări. Logica tarifară include tarife diferite pentru porturile AC și DC, precum și un tarif separat pentru staționare, aplicat atunci când vehiculul rămâne conectat după finalizarea încărcării. Pentru clienții B2B, sistemul trebuie să permită limite de cheltuieli per angajat sau per vehicul și să genereze rapoarte consolidate pe departamente.

5. Stratul de plăți
Stratul de plăți funcționează pe baza unui model cu sold: utilizatorul își alimentează contul în aplicație, iar costul încărcării este retras din sold în funcție de consumul efectiv, fără preautorizarea cardului pentru fiecare sesiune. Blocarea unei sume pe card este utilizată doar în scenariile fără aplicație mobilă, atunci când stația este echipată cu un terminal de plată. În acest caz, terminalul rezervă suma, iar după StopTransaction și primirea valorii finale a contorului încasează costul real și eliberează diferența. În ambele scenarii, procesarea plăților trebuie realizată asincron, astfel încât întârzierea dintre finalizarea încărcării și primirea ultimului MeterValues să nu afecteze experiența utilizatorului.

6. API-ul pentru clienți și notificările push
Aplicația mobilă primește informațiile despre starea stațiilor și sesiunile de încărcare prin intermediul API-ului, fără a comunica direct cu CSMS. Notificările push privind începerea și încheierea încărcării, precum și cele referitoare la erori, sunt generate pe baza acelorași evenimente OCPP (StatusNotification, StopTransaction) pe care CSMS le utilizează și pentru facturare. Astfel se evită diferențele dintre informațiile afișate în aplicație și starea reală a stației.

7. Panoul operatorului
Operatorul rețelei are nevoie de o interfață separată care afișează în timp real starea fiecărei stații, veniturile, istoricul sesiunilor și incidentele tehnice. Atunci când o stație intră în starea Faulted sau apare o defecțiune, sistemul trebuie să notifice imediat operatorul prin push, e-mail sau integrare cu canalele interne de comunicare, nu doar să afișeze informația într-un dashboard care poate să nu fie monitorizat permanent.

8. Cozi de procesare și toleranță la erori
O stație poate pierde conexiunea la internet în timpul încărcării. În această situație, ea trebuie să continue încărcarea local și să sincronizeze ulterior datele sesiunii (MeterValues, StopTransaction) după restabilirea conexiunii. Arhitectura trebuie să proceseze în mod idempotent mesajele duplicate sau întârziate. De exemplu, dacă StopTransaction este primit de două ori din cauza unei probleme de rețea, sistemul de facturare nu trebuie să încaseze plata de două ori.

ilab.md proiectează și dezvoltă arhitecturi software pentru stații de încărcare EV — de la integrarea echipamentelor prin OCPP, inclusiv a stațiilor produse în China și a echipamentelor CircControl, până la sisteme de facturare și aplicații mobile dezvoltate în React Native. Această expertiză este aplicată atât în Republica Moldova, cât și pe piețe internaționale.

Surse privind versiunile OCPP: chargelab.co, lembergsolutions.com, codibly.com.