Eine CMS-Migration wird selten durch das Protokoll blockiert. Es wird durch Dinge blockiert, die vor dem Start niemand festgelegt hat: ob Ladegeräte überhaupt umgerüstet werden können, ob historische Daten verschoben werden können und was mit den Fahrern während des Übergangs passiert.
Wenn diese drei zunächst festgelegt werden, wird aus einem riskanten Projekt eine Sequenzierungsübung.
Stellen Sie sicher, dass die Ladegeräte tatsächlich umgetauscht werden können
Die Backend-Adresse ist ein Konfigurationswert, und ob Sie sie aus der Ferne selbst ändern können, ohne die Mitarbeit des etablierten Anbieters, ist die Frage, die darüber entscheidet, ob eine Migration überhaupt möglich ist.
Wenn der etablierte Betreiber diesen Wert kontrolliert, wird die Migration zu einer kommerziellen Verhandlung, bevor sie zu einem technischen Projekt wird. Diese späte Entdeckung ist der häufigste Grund, warum Migrationen ins Stocken geraten.
Testen Sie ein Ladegerät, bevor Sie die Flotte planen
Verbinden Sie eine einzelne Einheit mit der neuen Plattform und führen Sie den gesamten Kompatibilitätssatz aus: Booten, Transaktionen, Zählerwerte, Fernbefehle, Firmware-Verwaltung und unterbrochene Fälle. Jeder Unterschied, den Sie hier finden, ist einer, den Sie sonst in der gesamten Flotte auf einmal finden würden.
Tun Sie dies mit derselben Firmware-Version, die tatsächlich auf der Flotte ausgeführt wird, nicht mit der neuesten, da diese migriert wird.
Entscheide, was mit der Geschichte passiert
Die Geschichte verläuft normalerweise nicht sauber. Die Planung eines Archivs mit definiertem Zugriff ist realistischer als die Annahme eines sauberen Imports und weitaus besser, als die Lücke während eines Abrechnungsstreits zu entdecken.
- Ob und in welchem Format historische Sitzungsdaten vom etablierten Anbieter exportiert werden können.
- Ob die neue Plattform es aufnehmen kann oder ob der Verlauf in einem Archiv zurückbleibt.
- Wie lange Sie nach der Umstellung zur Streitbeilegung weiterhin Zugriff auf die alte Plattform haben.
- Ob Fahrerkonten, RFID-Zugangsdaten und Tarife übertragen oder neu erstellt werden.
Migrieren Sie in Wellen, nicht auf einmal
Bewegen Sie zunächst eine kleine Gruppe, idealerweise an einen Ort, an dem Sie den Zugang kontrollieren und Störungen tolerieren können. Betreiben Sie es lange genug auf der neuen Plattform, bis intervallbedingte Probleme auftreten, was in der Regel mindestens einen vollständigen Abrechnungszyklus bedeutet.
Bewegen Sie sich dann in Wellen, deren Größe so groß ist, dass ein Problem einen überschaubaren Teil der Flotte betrifft, mit einem definierten Rollback für jede Welle.
Treiber sind der Teil, der zeigt
Die Ausfallzeit des Ladegeräts während der Umstellung ist kurz. Es liegt keine Störung für Fahrer vor, wenn ihre Konten, Karten oder Apps nicht mehr funktionieren. Das führt zu Beschwerden und ist eher ein Kommunikations- und Identitätsproblem als ein Protokollproblem.
Stellen Sie frühzeitig fest, ob die vorhandenen Anmeldeinformationen weiterhin funktionieren. Wenn nicht, planen Sie den Übergang für die Treiber separat und vor der Hardware.
Halten Sie beide Pfade während des Fensters am Leben
Wenn eine Routing-Schicht zwischen Ladegeräten und Backends liegt, wird die Migration zu einer Konfigurationsänderung pro Ladegerät und das Rollback erfolgt sofort. Ohne eine Neuverweisung handelt es sich um eine Änderung der Firmware-Konfiguration auf jeder Einheit und ein Rollback ist wieder die gleiche Arbeit.
Dies ist das stärkste praktische Argument für eine Routing-Schicht und es lohnt sich, vor einer Migration darüber nachzudenken, und nicht erst nach einer solchen.
Wie gut sieht bei der Umstellung aus?
- Eine getestete Kompatibilitätsposition zur aktuellen Firmware-Version.
- Ein Wellenplan mit pro Welle definiertem Rollback.
- Eine vereinbarte Antwort zu historischen Daten und Archivzugriff.
- Die Anmeldeinformationen des Fahrers werden vor der Hardware verarbeitet.
- Die Überwachung erfolgt auf der neuen Plattform vor der ersten Welle, nicht danach.