Wer eine Wallbox mit OCPP kauft, stellt sich eine konkrete Frage: Welche Protokollversion, welche Zertifizierung und welches Lastmanagement passt zur eigenen Infrastruktur – und was kostet eine Fehlentscheidung beim Nachrüsten? Der Vergleich richtet sich an Facility Manager, Elektroinstallateure und Bauherren, die mehr als eine Handvoll Ladepunkte planen oder gewerblich abrechnen müssen. Privathaushalte mit einem Fahrzeug und keinem Backend-Bedarf fallen aus dieser Zielgruppe heraus.
Das Gewicht der Kriterien folgt der Konsequenz eines Fehlers. OCPP-Version und Backend-Kompatibilität sind gleichauf an der Spitze, weil ein Protokollkonflikt zwischen Wallbox und Backend den gesamten Betrieb lahmlegt – kein Softwareupdate hilft, wenn der Hersteller kein OCPP 2.0.1 per Firmware liefert. Lastmanagement folgt auf Rang drei: Statische Obergrenzen genügen für Einzelobjekte, dynamisches Lastmanagement ist ab vier Ladepunkten und variablen Lasten wirtschaftlich zwingend. MID-Zertifizierung entscheidet über die rechtliche Belastbarkeit der Abrechnung – ohne Eichrecht keine Drittabrechnung gegenüber Mietern oder Kunden. Konnektivität und Installationsschnittstellen gewichten geringer, wirken sich aber auf Betriebskosten und Ausfallrisiko aus.
Die Spreizung zwischen Position 1 und Position 5 beträgt 5,7 Punkte – das ist für einen Kategorie-Vergleich ungewöhnlich groß. Der Grund: Die Kombination aus fehlender MID-Zertifizierung und proprietärem Gateway zieht mehrere Kriterien gleichzeitig nach unten. Alle Kategorien auf den Positionen 1 bis 3 teilen eine Eigenschaft: Sie kommunizieren nativ über OCPP ohne zwischengeschaltete Übersetzungsschicht. Das verhindert Mapping-Fehler bei Smart-Charging-Kommandos wie SetChargingProfile oder RemoteStartTransaction. Position 1 trennt sich durch OCPP 2.0.1 und dynamisches Lastmanagement ab – beides setzt ein Backend voraus, das ISO 15118 und bidirektionale Kommunikation versteht. Position 3 zeigt: LTE-Fallback schlägt fehlende MID nicht auf, solange keine Drittabrechnung stattfindet. Die Gateway-Lösung auf Position 5 fällt nicht wegen des Protokolls, sondern wegen der strukturellen Schwäche jeder Zwischenschicht: Jeder Firmware-Update beim Gateway kann Kompatibilität brechen.
Das folgende Raster ersetzt keine Fachplanung, gibt aber Ausschlusskriterien an die Hand: