Die Plattform hinter ChargeMeCar

Apostol CSMS — der Motor, der ChargeMeCar antreibt

Eine CSMS-Plattform auf Industrieniveau mit OCPP-Multi-Version, OCPI-Roaming 2.2.1 + 2.3.0, Stripe Connect für den europäischen Markt und AFIR-konformer Ad-hoc-Ladung. ChargeMeCar ist eines von mehreren Deployments, die heute auf dieser Plattform betrieben werden.

  • OCPP 1.5 / 1.6 / 2.0.1
  • OCPI 2.2.1 + 2.3.0
  • Stripe Connect
  • AFIR-konform
  • Multi-Tenant
  • Open Core
Worum es geht
Eine Infrastrukturschicht — kein geschlossener Cloud-Dienst
Ein CSMS (Charging Station Management System) ist die Software, die Ladestationen mit dem Rest der Welt verbindet: Fahrer, Zahlungsdienstleister, Regulatoren, Roaming-Partner. Apostol CSMS ist die Plattform; ChargeMeCar ist eine der Marken, die darauf aufbauen.

Stellen Sie es sich wie ein Shopify für das Laden von E-Fahrzeugen vor — dieselbe Plattform, viele unterschiedliche Marken, jede vollständig im Eigentum ihres Betreibers.

Wie es zusammenhängt
Wie ChargeMeCar zur Plattform steht
Drei Punkte, die man kennen sollte — zur Transparenz, nicht für die Marketingbroschüre.
01

Gleicher Motor, kein Fork

ChargeMeCar läuft als mandantenseitig betriebenes Deployment auf Apostol CSMS — derselbe Motor wie jedes andere Deployment, identischer Protokollstack, identische Zahlungsverdrahtung. Es gibt keinen «ChargeMeCar-Branch» der Plattform.

02

Reifer Kern

Das zugrundeliegende Server-Framework ist seit über neun Jahren im produktiven Einsatz. Apostol CSMS ist das Ergebnis jahrelanger Verfeinerung der Plattform, entworfen in vollem Bewusstsein der Grenzen, die im langjährigen kommerziellen Betrieb einer früheren Generation beobachtet wurden.

03

Operativ unabhängig

Unsere Stripe-Connect-Konten, unsere Infrastruktur, unsere Rechtsperson. Der Plattform-Eigentümer kann die Marke ChargeMeCar nicht ohne uns betreiben — und umgekehrt.

Protokolle
Offene Standards, kein Vendor-Lock-in
Die Plattform spricht die Protokolle, die jedes moderne Ladenetz nutzt — OCPP für die Hardware, OCPI für das netzübergreifende Roaming. Drei OCPP-Versionen werden gleichzeitig unterstützt.

OCPP — drei Versionen, eine Runtime

OCPP 1.5 (SOAP)

Legacy-Kompatibilität für ältere, weiterhin im Einsatz befindliche Geräte.

OCPP 1.6 (JSON / WebSocket)

Die am weitesten verbreitete Version am Markt — vollständig implementiert, zehn Stations-zu-Zentrale-Nachrichten und neunzehn Zentrale-zu-Stations-Befehle.

OCPP 2.0.1 (modern)

Drei-Ebenen-Modell (Station → EVSE → Connector), persistentes Device Model, String-Sitzungs-IDs. Im Kernumfang implementiert; erweiterte Erweiterungen sind in der Roadmap.

Automatische Versionserkennung beim Verbindungsaufbau. Befehle vom zentralen System werden transparent zwischen 1.6 und 2.0.1 übersetzt — gemischte Geräteflotten werden ohne zusätzlichen Aufwand unterstützt.

OCPI — Roaming mit beiden aktiven Versionen

OCPI regelt, wie unterschiedliche Ladenetze Informationen über Ladepunkte, Tarife, Nutzeridentitäten und Sitzungen austauschen. Beide aktuell aktiven Versionen des Standards werden gleichzeitig unterstützt, in beiden Rollen.

CPO-Rolle

Stellt die Stationen von ChargeMeCar Roaming-Partnern zur Verfügung — einschließlich Anbindungsfähigkeit an die Hubs Hubject und Gireve.

eMSP-Rolle

Akzeptiert Fahrertoken aus externen Partnernetzen; Remote-Start-Befehle laufen über denselben Kanal.

Hardware-neutral by Design

Funktioniert mit jeder OCPP-1.6/2.0.1-konformen Station — auch mit denen von Wettbewerbern. Die Plattform ist von Hause aus hardware-neutral, nicht durch eine Zertifizierungsliste.

Zahlungen
Stripe Connect für den europäischen Markt
Direct Charges auf das Stripe-Connect-Konto des Stationsbesitzers, automatischer Einbehalt der Application-Fee, SEPA-Auszahlungen in T+1…T+2, vollständige PSD2-/3-D-Secure-Konformität und ein AFIR-konformer Ad-hoc-QR-Flow.

Stripe-Connect-Funktionen

  • OAuth-Onboarding für bestehende Stripe-Konten
  • Automatische application_fee pro Transaktion
  • Erstattungen + Reverse Transfers
  • Webhooks: charge.succeeded, payment_intent.*, payout.*
  • PSD2 3-D Secure standardmäßig aktiv
  • Partnerauszahlungen über Stripe Connect

AFIR-Ad-hoc-QR — Vier-Schritte-Flow

  1. 01

    Scannen

    Der Fahrer scannt den auf der Station aufgedruckten QR-Code.

  2. 02

    Tarif ansehen

    Preise und Bedingungen werden vorab gezeigt — ohne Konto.

  3. 03

    Bezahlen

    Stripe Checkout / Payment Links übernehmen die sichere Zahlungsseite.

  4. 04

    Laden

    Beleg ausgestellt; das Laden startet sofort auf Anweisung der Plattform.

Wallet + doppelte Buchführung

Jede Geldbewegung wird gleichzeitig auf einem Konto belastet und auf einem anderen gutgeschrieben. Saldenintegrität ist strukturell, Audit-Spuren entstehen by Design, und Teilrückerstattungen werden sauber zwischen Betreiber-, Plattform- und Partnerkonten abgeglichen.

Anwendungen
Fünf Oberflächen, eine Plattform
Fünf separat ausrollbare Anwendungen ergeben ein vollständiges CSMS-Deployment. Alle fünf werden öffentlich als Docker-Images über GitHub Container Registry verteilt; jede Marke betreibt ihre eigenen Kopien, gebrandet via signiertem Manifest.

Webapp

Next.js + React + Ant Design

Betreiber-Dashboard — CRM, Analytik, mandantenübergreifende Verwaltung

Fahrer-PWA

Vite + React + Ant Design Mobile

Endnutzer-App — interaktive Karte, Sitzungen, Wallet, Verlauf, Stationsreservierung

Pay

Nuxt + Tailwind

Einmal-QR-Zahlflow ohne Registrierung (AFIR ad hoc)

Auth

Vue + Vite

OAuth2-Identity-Provider für den gesamten Perimeter

Landing

Nuxt + Quasar + GSAP

Marketing-Website der Marke — einschließlich dieser Seite

Alle fünf Apps werden öffentlich als Docker-Images über GitHub Container Registry verteilt; jede Marke betreibt ihre eigenen Kopien, gebrandet via signiertem Manifest, das zur Laufzeit ausgeliefert wird.

Architektur
Schlanker Stack, schneller Betrieb
Zweischichtiger Kern: ein Single-Loop-Transport in modernem C++ und die Geschäftslogik in PostgreSQL selbst. Beide Schichten sind unabhängig open source; das Lock-in-Risiko für den Käufer ist minimal.

C++-Transportschicht

Eine einzelne asynchrone Event-Loop, die HTTP und PostgreSQL miteinander verbindet — gebaut auf dem offenen libapostol-Framework, im produktiven Einsatz seit 2017.

Geschäftslogik in PostgreSQL

Workflow-Engine, rollenbasierte Zugriffskontrolle, doppelte Buchführung — alles geschrieben in PL/pgSQL auf dem offenen db-platform-Framework. Hot-Reload-fähig, transaktional, ohne separates ORM.

Offene Grundlage, geschlossene Distribution

Drei Foundation-Repositories sind MIT-lizenziert und öffentlich unter github.com/apostoldevel verfügbar: libapostol — der C++-Transport (github.com/apostoldevel/apostol); db-platform — das PostgreSQL-Framework (github.com/apostoldevel/db-platform); ocpp-cs — die OCPP-Zentralsystem-Referenz (github.com/apostoldevel/ocpp-cs). Das CSMS selbst wird als Docker-Images aus github.com/apostol-csms ausgeliefert. Das Vendor-Lock-in-Risiko ist strukturell begrenzt — selbst wenn die Distributionsschicht eingestellt würde, bliebe die gesamte Grundlage aus dem Open Source betreibbar.

Multi-Tenant by Design

Ed25519-signierte Markenlizenzen und je Marke verschlüsselter Datenbankinhalt. Eine einzige Software-Distribution; vollständig getrennter Markenbetrieb.

Engineering-Prinzipien
Was diese Plattform auszeichnet
Drei Eigenschaften, die im Plattformdesign bewusst zentral sind.

Bewährung in der Praxis

Der Plattformkern läuft seit über neun Jahren produktiv. Die aktuelle Generation wurde in vollem Bewusstsein der Grenzen der vorigen neu aufgebaut, beobachtet im langfristigen kommerziellen Betrieb statt unter Laborbedingungen.

Hardware-Unabhängigkeit

Die Plattform spricht OCPP 1.6 und 2.0.1 mit jeder konformen Ladestation, unabhängig vom Hersteller — auch mit Geräten konkurrierender CSMS-Anbieter. Hardware-Neutralität ist strukturell, keine Zertifizierungsliste.

Kryptografische Markenisolation

Jedes Deployment läuft unter einer Ed25519-signierten Markenlizenz und liefert Datenbankinhalte aus, die mit einem markenspezifischen Schlüssel verschlüsselt sind, der aus dieser Lizenz abgeleitet wird. Eine einzige Software-Distribution; vollständig getrennter Markenbetrieb.

Regulatorisch
Auf EU-Konformität ausgelegt
Die Plattform ist für den europäischen Regulierungsrahmen entworfen, mit expliziten Vorkehrungen für die vier Standards, die für einen CPO-Betreiber zählen.

AFIR — Ad-hoc-Zahlung

Öffentliche Ladeinfrastruktur muss Zahlungen jedes Fahrers ohne Voraufzeichnung akzeptieren. Vollständig umgesetzt über Stripe Checkout / Payment Links und den anonymen Fahrer-QR-Flow.

DSGVO

Datenresidenz in der EU, Recht auf Löschung, Audit-Logs, signierte Einwilligungen — in der Datenschicht verankert statt nachträglich aufgesetzt.

PSD2 / 3-D Secure

Starke Kundenauthentifizierung wird für europäische Karten standardmäßig über Stripe erzwungen. Kein Zahlungsweg umgeht 3-D Secure.

ISO 15118 «Plug & Charge»

Geplant, in der OCPP-2.0.1-Roadmap. Ehrlicher Hinweis: Diese Funktion ist noch nicht ausgeliefert; sie hängt von der Arbeit des nächsten größeren Plattformschritts ab.

White-Label-Option

Wenn Sie ein CPO-Betreiber oder Energieversorger sind und Ihr eigenes CSMS betreiben wollen

Die Plattform unterstützt das nativ. Ein neuer Markenbetreiber bringt in fünf bis zehn Minuten eine vollständig konfigurierte, vollständig gebrandete, rechtlich und steuerlich angebundene Instanz zum Laufen. Sehen Sie sich unser White-Label-Programm an.

White-Label-Programm ansehen →
Kontakt aufnehmen

Möchten Sie mehr über die Plattform erfahren?

Schicken Sie uns einen Brief oder öffnen Sie die Demo des Betreiber-Dashboards. Wir führen Sie durch das, was für Sie relevant ist.

Cloud-Demo öffnen →