API vs. OCPP: Worin besteht der Unterschied beim Laden von Elektrofahrzeugen?
OCPP verbindet eine Ladestation für Elektrofahrzeuge mit seinem Managementsystem. APIs verbinden Softwaresysteme miteinander. Erfahren Sie, wie beide Architekturen funktionieren und was Betreiber überprüfen sollten.
Die kurze Antwort
OCPP und eine API sind keine konkurrierenden Varianten derselben Technologie. OCPP ist ein offenes Protokoll für die Kommunikation zwischen einer Ladestation und einem Lademanagementsystem (CSMS oder CPMS). Eine API ist eine allgemeine Schnittstelle, über die ein Softwaresystem Daten oder Aktionen von einem anderen anfordert.
Die meisten Ladenetzwerke nutzen beides. OCPP verwaltet die Verbindung zum Ladegerät, während APIs das CPMS mit Abrechnungs-, Flotten-, Energie-, Berichts- und Kundensystemen verbinden. Eine API kann auch die Steuerung des Ladegeräts über die Cloud eines Herstellers bereitstellen, doch dabei handelt es sich um eine andere Architektur.
OCPP und APIs im Vergleich
OCPP
OCPP verbindet in der Regel eine Ladestation mit einem CPMS. Es handelt sich um eine offene Spezifikation, die von der Open Charge Alliance gepflegt wird. Typische Nachrichten betreffen den Ladestatus, die Autorisierung, Ladesitzungen, Zählerstände, Fehlermeldungen und Fernbefehle. Das Protokoll ist darauf ausgelegt, support und Managementsysteme verschiedener Anbieter support , wobei kompatible Versionen und Funktionen noch getestet werden müssen.
API
Eine API verbindet ein Softwaresystem mit einem anderen. Sie kann proprietär sein, öffentlich dokumentiert sein oder auf einem separaten Standard basieren. Im Bereich der E-Auto-Ladeinfrastruktur verbinden APIs üblicherweise Abrechnung, Tarife, Flottendaten, Energiesteuerung, Apps und Berichterstellung. Sie können zudem einen cloudbasierten Zugriff auf die Steuerung der Ladestationen ermöglichen. Die Portabilität hängt vom API-Eigentümer, der Dokumentation, den Zugriffsrechten und dem Vertrag ab.
Zwei gängige Ladearchitekturen
Direktes OCPP
Ladestation ↔ CPMS des Betreibers
Das Ladegerät stellt seine OCPP-Verbindung direkt mit der vom Betreiber gewählten Plattform her. Dadurch entfällt die obligatorische Hersteller-Cloud aus dem Prozess der zentralen Ladegeräteverwaltung. Dies kann zu einer klareren Zuordnung der Verantwortlichkeiten führen und einen späteren Wechsel des CPMS erleichtern, vorausgesetzt, der Betreiber verfügt über die Zugangsdaten für das Ladegerät, support kompatibler Protokolle support einen erprobten Migrationsplan.
Hersteller-Cloud plus API
Ladestation ↔ Hersteller-Cloud ↔ Betreiberplattform
Das Ladegerät ist mit einem vom Hersteller verwalteten Dienst verbunden, der ausgewählte Daten und Steuerungsfunktionen über eine API bereitstellt. Dies kann die Bereitstellung vereinfachen, produktspezifische Tools bereitstellen und eine einheitliche Schnittstelle für die gesamte Hardware dieses Herstellers bieten. Außerdem werden dadurch der Cloud-Dienst, die API-Bedingungen und der fortlaufende Datenzugriff Teil der Abhängigkeitskette des Betreibers.
Ein Ausfall bedeutet nicht automatisch, dass der physische Ladevorgang unterbrochen wird. Ein Ladegerät kann unter lokaler Autorisierung oder gemäß Offline-Regeln weiterarbeiten, während Fernbefehle und Datensynchronisation nicht verfügbar sind. Das Ergebnis hängt vom Ladegerät, der Cloud, dem CPMS und dem konfigurierten Ausweichverhalten ab.
Was sollte ein Bediener überprüfen?
- Kann der Aufladepunkt direkt mit einem anderen CPMS verbunden werden, und wer verwaltet dessen Zugangsdaten?
- Welche OCPP-Version, Profile und optionalen Funktionen sind implementiert und getestet?
- Für welche Vorgänge ist die Hersteller-Cloud erforderlich?
- Was geschieht support eines Stromausfalls mit der Autorisierung, der Abrechnung, den Zählerdaten und support ?
- Können Betriebsdaten exportiert werden, und sind API-Zugriff, Ratenbegrenzungen oder Gebühren vertraglich geregelt?
- Wer ist für die Verwaltung der Firmware, der Sicherheitsupdates und der Verpflichtungen im Zusammenhang mit dem Ende des Supports zuständig?
Wo Amina hingehört
Auf den aktuellen Seiten zu amina C/C2 und amina M/M2 werden die lokale OCPP 1.6J-Kompatibilität sowie die Hardware-Voraussetzungen für OCPP 2.0.1 beschrieben. Sie sind so konzipiert, dass sie eine direkte Verbindung zum vom Betreiber gewählten CPMS herstellen, ohne dass eine amina-Cloud zwischen dem Ladegerät und dieser Plattform erforderlich ist.
Das bedeutet jedoch nicht, dass APIs überflüssig sind. Das CPMS sowie die auf Software und Energie spezialisierten Partner von amina können APIs oder andere Schnittstellen für Funktionen nutzen, die über die Verbindung zwischen Ladegerät und CPMS hinausgehen. Diese Aufteilung ist bewusst gewählt: fokussierte Ladehardware, offene Kommunikation mit dem Managementsystem und Wahlfreiheit auf der Softwareebene.
Fragen zu API und OCPP
Kann eine API OCPP ersetzen?
Eine proprietäre API kann einer anderen Plattform über die Cloud eines Anbieters Zugriff auf Ladegerätdaten und -steuerungsfunktionen gewähren. Sie bietet jedoch nicht die von OCPP definierte Standardschnittstelle zwischen Ladegerät und CPMS.
Beseitigt OCPP die Herstellerabhängigkeit?
Dadurch wird zwar eine Ursache für die Bindung an einen Anbieter verringert, jedoch nicht jede Abhängigkeit beseitigt. Protokollversionen, implementierte Funktionen, Anmeldedaten für Ladegeräte, Eigentumsverhältnisse bei der Firmware, die Einbindung in das CPMS, Verträge und der Datenzugriff spielen weiterhin eine Rolle.