Det korta svaret

OCPP och ett API är inte konkurrerande versioner av samma teknik. OCPP är ett offentliggjort protokoll för kommunikation mellan en laddstation och ett laddningshanteringssystem (CSMS eller CPMS). Ett API är ett generellt gränssnitt genom vilket ett programvarusystem begär data eller åtgärder från ett annat.

 

De flesta laddningsnätverk använder båda. OCPP hanterar anslutningen till laddaren, medan API:er kopplar samman CPMS med system för fakturering, fordonsflotta, energi, rapportering och kundhantering. Ett API kan också göra laddarens styrfunktioner tillgängliga via tillverkarens molntjänst, men det är en annan arkitektur.

Jämförelse mellan OCPP och API:er

OCPP

OCPP kopplar vanligtvis samman en laddstation med ett CPMS. Det är en öppen specifikation som underhålls av Open Charge Alliance. Typiska meddelanden avser laddarens status, auktorisering, laddningssessioner, mätvärden, fel och fjärrkommandon. Standarden är utformad för support och hanteringssystem från olika leverantörer, även om kompatibla versioner och funktioner fortfarande behöver testas.

API

Ett API kopplar samman två mjukvarusystem. Det kan vara ett proprietärt API, ett API med offentlig dokumentation eller ett API som bygger på en separat standard. Inom laddning av elfordon kopplar API:er ofta samman fakturering, tariffer, fordonsparksdata, energistyrning, appar och rapportering. De kan också ge molnbaserad åtkomst till laddningsstationernas styrsystem. Portabiliteten beror på API-ägaren, dokumentationen, åtkomsträttigheterna och avtalet.

Två vanliga laddningsarkitekturer

Direkt OCPP

Laddstation ↔ operatörens CPMS

Laddaren upprättar sin OCPP-anslutning direkt med den plattform som operatören har valt. Detta innebär att den obligatoriska tillverkarmolntjänsten inte längre ingår i den väg som används för den centrala hanteringen av laddaren. Det kan göra ansvarsfördelningen tydligare och göra det enklare att byta CPMS i ett senare skede, förutsatt att operatören har laddarens inloggningsuppgifter, support kompatibla protokoll support en beprövad migreringsplan.

Tillverkare Cloud Plus API

Laddstation ↔ tillverkarens molntjänst ↔ operatörens plattform

Laddaren ansluts till en tjänst som förvaltas av tillverkaren, vilken gör utvalda data och styrfunktioner tillgängliga via ett API. Detta kan förenkla driftsättningen, tillhandahålla produktspecifika verktyg och erbjuda ett gemensamt gränssnitt för tillverkarens hårdvara. Det innebär också att molntjänsten, API-villkoren och den fortsatta tillgången till data blir en del av operatörens beroendekedja.

 

Ett avbrott innebär inte automatiskt att den fysiska laddningen avbryts. En laddare kan fortsätta att fungera enligt lokala behörighetsinställningar eller offline-regler medan fjärrkommandon och datasynkronisering inte är tillgängliga. Resultatet beror på laddaren, molntjänsten, CPMS och det konfigurerade reservbeteendet.

Vad bör en operatör kontrollera?

  • Kan laddaren kopplas direkt till ett annat CPMS, och vem hanterar dess inloggningsuppgifter?
  • Vilka OCPP-versioner, profiler och tillvalsfunktioner har implementerats och testats?
  • Vilka processer kräver tillverkarens molntjänst?
  • Vad händer med auktorisering, debitering, mätdata och support ett strömavbrott?
  • Kan driftsdata exporteras, och är API-åtkomst, begränsningar av antalet förfrågningar eller avgifter reglerade i avtalet?
  • Vem ansvarar för firmware, säkerhetsuppdateringar och skyldigheter vid driftsavslutning?

Var amina passar in

De nuvarande sidorna för amina C/C2 och amina M/M2 anger lokal OCPP 1.6J-kompatibilitet samt hårdvarukompatibilitet för OCPP 2.0.1. De är utformade för att anslutas direkt till den CPMS som operatören valt, utan att det krävs någon amina-molnlösning mellan laddaren och den plattformen.

 

Det innebär inte att API:er är överflödiga. CPMS samt Aminas specialiserade mjukvaru- och energipartner kan använda API:er eller andra gränssnitt för funktioner som ligger utanför förbindelsen mellan laddaren och CPMS. Denna uppdelning är avsiktlig: specialiserad laddningshårdvara, öppen kommunikation med styrsystemet och valfrihet på mjukvarunivå.

Frågor om API och OCPP

Kan ett API ersätta OCPP?

Ett egenutvecklat API kan ge en annan plattform åtkomst till laddarens data och styrfunktioner via en leverantörs molntjänst. Det tillhandahåller inte det standardgränssnitt mellan laddare och CPMS som definieras av OCPP.

Eliminerar OCPP leverantörsberoendet?

Det minskar en källa till inlåsning, men eliminerar inte alla beroenden. Protokollversioner, implementerade funktioner, laddarens inloggningsuppgifter, äganderätten till firmware, CPMS-registrering, avtal och datatillgång spelar fortfarande en viktig roll.