Det korte svar

OCPP og et API er ikke konkurrerende versioner af den samme teknologi. OCPP er en offentliggjort protokol til kommunikation mellem en ladestation og et ladestyringssystem (CSMS eller CPMS). Et API er en generel grænseflade, hvorigennem et softwaresystem anmoder et andet om data eller handlinger.

 

De fleste ladenetværk bruger begge dele. OCPP styrer forbindelsen til laderen, mens API’er forbinder CPMS med systemer til fakturering, flådeadministration, energistyring, rapportering og kundeservice. Et API kan også give adgang til laderstyringen via en producents cloud, men det er en anden arkitektur.

Sammenligning af OCPP og API’er

OCPP

OCPP forbinder normalt en ladestation med et CPMS. Det er en åben specifikation, der vedligeholdes af Open Charge Alliance. Typiske meddelelser omfatter ladestationens status, autorisation, sessioner, målerværdier, fejl og fjernkommandoer. Standarden er udviklet til support og styringssystemer fra forskellige leverandører, selvom kompatible versioner og funktioner stadig skal testes.

API

Et API forbinder et softwaresystem med et andet. Det kan være proprietært, offentligt dokumenteret eller baseret på en separat standard. Inden for opladning af elbiler forbinder API’er typisk fakturering, takster, flådedata, energistyring, apps og rapportering. De kan også give cloudbaseret adgang til styringen af ladestationerne. Overførbarheden afhænger af API-ejeren, dokumentationen, adgangsrettighederne og kontrakten.

To almindelige opladningsarkitekturer

Direkte OCPP

Ladestation ↔ operatørens CPMS

Opladeren opretter sin OCPP-forbindelse direkte til den platform, som operatøren har valgt. Dette fjerner en obligatorisk producent-cloud fra den rute, der anvendes til den centrale styring af opladeren. Det kan gøre ansvarsfordelingen mere overskuelig og gøre et senere skift af CPMS mere praktisk, forudsat at operatøren har adgangsoplysningerne til opladeren, support kompatible protokoller support en afprøvet migrationsplan.

Producentens Cloud Plus API

Ladestation ↔ producentens cloud ↔ operatørens platform

Opladeren opretter forbindelse til en tjeneste, der administreres af producenten, og som stiller udvalgte data og kontrolfunktioner til rådighed via et API. Dette kan forenkle konfigurationen, give adgang til produktspecifikke værktøjer og skabe én samlet grænseflade på tværs af producentens hardware. Det betyder også, at cloudtjenesten, API-vilkårene og den fortsatte adgang til data bliver en del af operatørens afhængighedskæde.

 

Et strømsvigt betyder ikke nødvendigvis, at den fysiske opladning standses. En oplader kan fortsætte driften i henhold til lokale tilladelser eller offline-regler, selvom fjernkommandoer og datasynkronisering ikke er tilgængelige. Resultatet afhænger af opladeren, cloud-systemet, CPMS og den konfigurerede fallback-adfærd.

Hvad bør en operatør kontrollere?

  • Kan opladeren pege direkte på et andet CPMS, og hvem styrer dens adgangsoplysninger?
  • Hvilke OCPP-versioner, profiler og valgfrie funktioner er implementeret og testet?
  • Hvilke processer kræver producentens cloud?
  • Hvad sker der med godkendelse, afregning, målerdata og support et strømsvigt?
  • Kan driftsdata eksporteres, og er API-adgang, hastighedsbegrænsninger eller gebyrer fastlagt i aftalen?
  • Hvem står for håndtering af firmware, sikkerhedsopdateringer og forpligtelser i forbindelse med udløb af support?

Hvor Amina passer ind

De nuværende amina C/C2- og amina M/M2-sider angiver lokal OCPP 1.6J-kompatibilitet samt hardwareklarhed til OCPP 2.0.1. De er udviklet til at oprette direkte forbindelse til den CPMS, som operatøren har valgt, uden at der kræves en amina-cloud mellem laderen og den pågældende platform.

 

Det betyder dog ikke, at API’er er overflødige. CPMS samt Aminas specialiserede software- og energipartnere kan anvende API’er eller andre grænseflader til funktioner, der ligger uden for forbindelsen mellem opladeren og CPMS. Denne opdeling er bevidst: målrettet opladningshardware, åben kommunikation i styringssystemet og valgfrihed på softwareniveau.

Spørgsmål om API og OCPP

Kan et API erstatte OCPP?

Et proprietært API kan give en anden platform adgang til opladerdata og -styring via en leverandørs cloud. Det understøtter ikke den standardgrænseflade mellem oplader og CPMS, der er defineret af OCPP.

Fjerner OCPP leverandørbinding?

Det mindsker én kilde til låsning, men fjerner ikke alle afhængigheder. Protokolversioner, implementerede funktioner, opladningsoplysninger, ejerskab af firmware, CPMS-tilkobling, kontrakter og dataadgang spiller stadig en rolle.