Het korte antwoord

OCPP en een API zijn geen concurrerende versies van dezelfde technologie. OCPP is een gepubliceerd protocol voor communicatie tussen een laadstation en een laadbeheersysteem (CSMS of CPMS). Een API is een algemene interface waarmee het ene softwaresysteem gegevens of acties opvraagt bij het andere.

 

De meeste laadnetwerken maken van beide gebruik. OCPP regelt de verbinding met de lader, terwijl API’s het CPMS koppelen aan systemen voor facturering, wagenparkbeheer, energiebeheer, rapportage en klantbeheer. Een API kan ook de bedieningsfuncties van de lader via de cloud van een fabrikant beschikbaar stellen, maar dat is een andere architectuur.

OCPP en API’s vergeleken

OCPP

OCPP koppelt doorgaans een laadstation aan een CPMS. Het betreft een open specificatie die wordt onderhouden door de Open Charge Alliance. Typische berichten hebben betrekking op de status van de lader, autorisatie, laadsessies, meterwaarden, storingen en opdrachten op afstand. Het is ontworpen om support en beheersystemen van verschillende leveranciers support , hoewel compatibele versies en functies nog moeten worden getest.

API

Een API koppelt het ene softwaresysteem aan het andere. Deze kan eigen software zijn, openbaar gedocumenteerd zijn of gebaseerd zijn op een afzonderlijke standaard. Bij het opladen van elektrische voertuigen koppelen API’s doorgaans facturering, tarieven, wagenparkgegevens, energiebeheer, apps en rapportage aan elkaar. Ze kunnen ook cloudgebaseerde toegang tot de bediening van laadpunten bieden. De overdraagbaarheid hangt af van de eigenaar van de API, de documentatie, de toegangsrechten en het contract.

Twee veelvoorkomende oplaadarchitecturen

Directe OCPP

Laadstation ↔ CPMS van de exploitant

De lader brengt zijn OCPP-verbinding rechtstreeks tot stand met het door de exploitant gekozen platform. Hierdoor wordt de verplichte cloud van de fabrikant uit het traject voor het kernbeheer van de lader gehaald. Dit kan de verantwoordelijkheden duidelijker maken en een latere overstap naar een ander CPMS praktischer maken, mits de exploitant beschikt over de inloggegevens voor de lader, support compatibele protocollen support een getest migratieplan.

Fabrikant Cloud Plus API

Laadstation ↔ cloud van de fabrikant ↔ platform van de exploitant

De oplader maakt verbinding met een door de fabrikant beheerde dienst, die via een API geselecteerde gegevens en bedieningsmogelijkheden beschikbaar stelt. Dit kan de inbedrijfstelling vereenvoudigen, productspecifieke tools bieden en één interface bieden voor alle hardware van die fabrikant. Hierdoor worden de clouddienst, de API-voorwaarden en de voortdurende toegang tot gegevens ook onderdeel van de afhankelijkheidsketen van de exploitant.

 

Een storing betekent niet automatisch dat het fysieke laadproces wordt onderbroken. Een lader kan op basis van lokale toestemming of offline-regels blijven werken terwijl commando’s op afstand en gegevenssynchronisatie niet beschikbaar zijn. Het resultaat hangt af van de lader, de cloud, het CPMS en het geconfigureerde fallback-gedrag.

Wat moet een operator controleren?

  • Kan de oplader rechtstreeks naar een ander CPMS worden gekoppeld, en wie beheert de toegangsgegevens daarvan?
  • Welke OCPP-versie, profielen en optionele functies zijn geïmplementeerd en getest?
  • Voor welke bewerkingen is de cloud van de fabrikant nodig?
  • Wat gebeurt er met autorisatie, facturering, metergegevens en support op afstand support een stroomstoring?
  • Kunnen operationele gegevens worden geëxporteerd, en zijn API-toegang, verwerkingslimieten of kosten contractueel vastgelegd?
  • Wie is verantwoordelijk voor het beheer van firmware, beveiligingsupdates en verplichtingen bij het beëindigen van de dienstverlening?

Waar Amina past

Op de huidige amina C/C2- en amina M/M2-pagina’s wordt de lokale OCPP 1.6J-ondersteuning en de hardware-gereedheid voor OCPP 2.0.1 beschreven. Ze zijn ontworpen om rechtstreeks verbinding te maken met het door de exploitant gekozen CPMS, zonder dat er een amina-cloud tussen de lader en dat platform hoeft te staan.

 

Dat betekent niet dat API’s overbodig zijn. Het CPMS en de gespecialiseerde software- en energiepartners van amina kunnen API’s of andere interfaces gebruiken voor functies die buiten de verbinding tussen de lader en het CPMS vallen. Deze scheiding is bewust gekozen: gerichte laadhardware, open communicatie met het beheersysteem en keuzevrijheid op softwareniveau.

Vragen over API en OCPP

Kan een API OCPP vervangen?

Een eigen API kan een ander platform via de cloud van de leverancier toegang geven tot gegevens en bedieningsfuncties van de laadpaal. Deze API biedt niet de door OCPP gedefinieerde standaardinterface tussen de laadpaal en het CPMS.

Maakt OCPP een einde aan vendor lock-in?

Het vermindert één bron van lock-in, maar neemt niet alle afhankelijkheden weg. Protocolversies, geïmplementeerde functies, inloggegevens voor opladers, eigendom van firmware, CPMS-onboarding, contracten en toegang tot gegevens blijven van belang.