Eine Fahrerin tippt auf Start. Die App wartet, zeigt einen Fehler und bietet einen zweiten Versuch an. Der Ladepunkt hat den ersten Auftrag inzwischen erhalten. Wenig später beginnt das Fahrzeug zu laden. Für die Kundin sieht es nach einem misslungenen Versuch aus; im Hintergrund existiert bereits ein Vorgang, den Support und Abrechnung erklären müssen.
Wer in Deutschland eine Lade-App, ein Betreiberportal oder eine Flottenintegration entwickeln lässt, sollte genau diese Situation zur ersten Demonstration machen. Eine schnelle Karte und eine grüne Starttaste sind leicht zu verstehen. Der eigentliche Wert der Software entsteht, wenn Nachrichten verspätet eintreffen, Verbindungen abbrechen und verschiedene Systeme unterschiedliche Ausschnitte desselben Vorgangs kennen.
Infrastruktur finden und einen Ladevorgang steuern sind verschiedene Aufgaben
Die Bundesnetzagentur stellt Listen öffentlich zugänglicher Ladeinfrastruktur zum Download bereit. Solche Registerdaten sind für Verzeichnisse und Datenabgleiche nützlich. Aus einem vorhandenen Registereintrag folgt jedoch keine aktuelle Aussage darüber, ob ein bestimmter Anschluss gerade verfügbar ist oder Energie liefert.
Für die Kommunikation zwischen Ladestation und Managementsystem beschreibt die Open Charge Alliance OCPP und seine Versionen. Ihre Erläuterung zu OCPP 2.0.1 behandelt Transaktionsereignisse, konfigurierbare Start- und Endpunkte sowie Sequenznummern. Für Käufer folgt daraus eine konkrete Frage: Welche Version und welche Konfiguration unterstützt der tatsächlich eingesetzte Gerätebestand?
Geben Sie dem Auftrag und der Transaktion eigene Identitäten
Die App benötigt eine Kennung für den Kundenwunsch. Das Managementsystem kennt den daraus entstehenden Auftrag. Die Ladestation beziehungsweise das verwendete Protokoll liefert die Kennung des beobachteten Ladevorgangs. Diese Kennungen gehören zusammen, sind aber nicht automatisch identisch.
Eine saubere Integration speichert diese Beziehungen ausdrücklich. Dann kann der Support sehen, dass ein bestimmter Startwunsch zunächst unbestätigt blieb und später einer Transaktion zugeordnet wurde. Ein erneuter Klick erhält eine definierte Behandlung. Er darf nicht nur deshalb einen neuen abrechenbaren Vorgang erzeugen, weil die ursprüngliche HTTP-Anfrage im Mobilfunknetz verloren ging.
Legen Sie mit dem Betreiber fest, wie lange ein Auftrag als ungeklärt gelten darf. Die Antwort kann vom Gerät und vom Kommunikationsweg abhängen. Ein pauschaler Timer, der jeden offenen Vorgang nach kurzer Zeit auf fehlgeschlagen setzt, vereinfacht das Dashboard und erschwert anschließend die Wahrheitssuche.
Ein Abbruch in der Oberfläche ist noch keine Bestätigung vom Gerät
Die Oberfläche sollte zwischen einem zurückgenommenen Kundenwunsch und einem bestätigten Ende unterscheiden. Wenn die App einen Stopauftrag sendet, braucht dieser einen eigenen nachvollziehbaren Verlauf. Ein ausgegrauter Knopf beweist nicht, dass das Fahrzeug keine Energie mehr bezieht.
Stellen Sie sich als illustrativen Test vor, dass die Kundin Start und direkt danach Abbrechen wählt. Anschließend kommt zuerst ein verspätetes Startereignis und später eine Endmeldung an. Die Software muss diesen Verlauf zusammenführen können, ohne die ursprüngliche Absicht zu verlieren oder fälschlich zwei unabhängige Sitzungen anzuzeigen.
Die Formulierungen in der App sind dabei Teil der Entwicklung. „Anfrage wird geprüft“ vermittelt einen anderen Zustand als „Ladevorgang beendet“. Produktverantwortliche und Support sollten diese Texte gemeinsam abnehmen. Andernfalls korrigiert eine sorgfältig gebaute Schnittstelle nicht das falsche Versprechen der Benutzeroberfläche.
Abrechnung braucht eine eigene Freigabeschwelle
Entscheiden Sie, welche Informationen vorliegen müssen, bevor ein Vorgang zur Abrechnung freigegeben wird. Dazu können die Zuordnung zum Vertrag, relevante Messwerte, Anfang und Ende sowie die zum Vorgang passende Preisversion gehören. Welche fachlichen und rechtlichen Anforderungen gelten, muss der Betreiber für sein Angebot prüfen; ein erfolgreicher API-Aufruf ersetzt diese Prüfung nicht.
Unvollständige Vorgänge gehören in eine sichtbare Klärungsliste. Ein fehlender Endwert ist kein Nullverbrauch. Ein korrigierter Messwert darf nicht einfach eine bereits ausgegebene Abrechnung unbemerkt verändern. Speichern Sie die Änderung mit ihrem Anlass und führen Sie die weitere Behandlung über den dafür vorgesehenen Geschäftsprozess aus.
Diese Trennung hilft auch dem Kundenservice. Er kann unterscheiden, ob eine Station noch Daten liefert, ein Auftrag unklar ist oder eine Rechnung bereits freigegeben wurde. Ohne diese Sicht bekommt jeder Anruf dieselbe unpräzise Antwort: Das System werde sich wahrscheinlich bald aktualisieren.
Kaufen Sie eine Geräteprüfung, keine Versionsbehauptung
Ein Angebot mit dem Wort OCPP sagt noch wenig über den Umfang aus. Fordern Sie eine Liste der unterstützten Funktionen für die relevanten Geräte und Firmwarestände. Erfassen Sie außerdem, welche Informationen über einen zwischengeschalteten Betreiber verfügbar sind und welche nur dessen eigenes System kennt.
Die Abnahme sollte Verbindungsverlust, doppelte Nachrichten, Wiederanlauf nach einem Neustart und Ereignisse in abweichender Empfangsreihenfolge umfassen. Lassen Sie mindestens einen Fall mit zwei Anschlüssen demonstrieren. Ein globaler Stationsstatus darf nicht versehentlich als Zustand jedes einzelnen Anschlusses verwendet werden.
Wichtig ist auch die Rücknahme einer fehlerhaften Softwareversion. Ein neuer Parser kann alte Ereignisse anders interpretieren. Die Wiederverarbeitung muss kontrolliert erfolgen, damit ein technisches Update keine neuen Rechnungen für bereits bearbeitete Vorgänge erzeugt.
Ein sinnvoller erster Auftrag bleibt überschaubar
Beginnen Sie mit einem konkreten Gerätebestand, einem Startverfahren und einer Verbindung zur Abrechnung. Das erste Ergebnis sollte eine durchgängige Ereignisspur liefern: Kundenaktion, Auftrag, Gerätebeobachtung, Klärung und fachliche Freigabe. Zusätzliche Bezahlwege oder weitere Betreiber lassen sich anschließend auf dieser Grundlage bewerten.
Messen Sie, wie viele Vorgänge ungeklärt bleiben und wie lange der Support benötigt, um einen davon zu erklären. Diese Zahlen entstehen im eigenen Betrieb; sie sind aussagekräftiger als ein allgemeines Versprechen zur Verfügbarkeit. Prüfen Sie daneben, ob die Anwendung bei unbekanntem Zustand verständlich bleibt und keine unbelegten Erfolgsmeldungen ausgibt.
Für die Ausschreibung helfen unsere Beiträge zu Abnahmenachweisen bei Individualsoftware und zu den Kostentreibern individueller Softwareentwicklung. TuniCyberLabs kann die Integration im Rahmen einer individuellen Softwareentwicklung umsetzen. Beschreiben Sie Ihren Gerätebestand und einen problematischen Ladevorgang, damit aus der nächsten Vorführung ein überprüfbarer Betriebsablauf wird.