Over-the-Air-Update ist die Funktion, die bestimmt, ob eine eingesetzte Flotte gewartet werden kann oder besucht werden muss. Es ist auch die Fähigkeit, die am wahrscheinlichsten dazu führt, dass eine Flotte offline geht, wenn sie nachlässig entworfen wird.
Die Designfrage besteht nicht darin, wie man ein neues Bild vermittelt. Dies geschieht, wenn die Lieferung, Überprüfung oder Ausführung einer Einheit an einem Standort fehlschlägt, den niemand schnell erreichen kann.
Doppelbilder und Rollback
Die sichere Anordnung behält ein funktionierendes Image bei, während ein neues geschrieben wird, und schaltet erst um, wenn das neue Image überprüft wurde und nachgewiesen hat, dass es ausgeführt werden kann. Wenn dies nicht möglich ist, kehrt der Bootloader ohne Eingriff zum bekanntermaßen fehlerfreien Image zurück.
Dies schränkt die Flash-Größe ein, weshalb OTA ebenso eine Hardware-Entscheidung wie eine Software-Entscheidung ist und schwierig zu einem Design hinzugefügt werden kann, das dies nicht vorgesehen hat.
Überprüfen Sie dies vor der Ausführung, nicht danach
Ein Image muss authentifiziert und auf Integrität überprüft werden, bevor es ausgeführt werden darf. Die Überprüfung nach dem Booten ist zu spät: Bis dahin wurde bereits nicht überprüfter Code ausgeführt.
Das Signieren gibt diese Garantie und verlagert das Sicherheitsproblem auf den Signaturschlüssel, wo er hingehört und entsprechend geschützt werden muss.
Die Schlüsselverwahrung ist der schwierige Teil
Dies ist der Teil des OTA-Designs, der am häufigsten unentwickelt bleibt, und die Folgen eines Fehlers sind die gravierendsten von allen im Update-Pfad.
- Wer besitzt den Signaturschlüssel und wo?
- Wie der Zugriff auf das Signieren kontrolliert und protokolliert wird.
- Was passiert, wenn der Schlüssel kompromittiert wird und ob die Flotte einen neuen akzeptieren kann.
- Ob und zu welchen Bedingungen ein Kunde, der einen Technologietransfer in Anspruch nimmt, die Möglichkeit zur Zeichnung erhält.
Führen Sie den Rollout durch
Das gleichzeitige Aktualisieren einer gesamten Flotte bedeutet, dass sich ein fehlerhaftes Release auf alles gleichzeitig auswirkt. Durch eine stufenweise Einführung, die mit einer kleinen Gruppe beginnt und sich ausdehnt, sobald diese Stabilität zeigt, kann der Schaden eingedämmt werden.
Die Größe der ersten Gruppe so zu bestimmen, dass ein Fehler behebbar ist, und zu definieren, was Stabilität vor Beginn bedeutet, sind die beiden Entscheidungen, die eine Inszenierung nützlich und nicht zeremoniell machen.
Aktualisieren Sie niemals mitten in der Sitzung
Wenn ein Update durchgeführt wird, während ein Fahrzeug aufgeladen wird, besteht die Gefahr, dass eine Sitzung unterbrochen wird und der Transaktionsdatensatz verloren geht. Der Update-Mechanismus muss warten, bis der Connector inaktiv ist, und eine Fahrzeugverbindung verarbeiten, während ein Update aussteht.
An einem stark frequentierten Standort bleibt ein Ladegerät möglicherweise nicht lange im Leerlauf, was bedeutet, dass der Mechanismus auch eine Richtlinie benötigt, wie lange er wartet und was er dann tut.
Unterbrochene Downloads und Stromausfall
Die Verbindung schlägt während des Downloads fehl und die Stromversorgung fällt während des Schreibens aus. In beiden Fällen muss das Ladegerät sein vorhandenes Image ausführen, wobei der teilweise Download verworfen und nicht als vollständig behandelt wird.
Der entscheidende Test besteht darin, während eines Updates an mehreren Stellen absichtlich die Stromversorgung zu unterbrechen und zu bestätigen, dass das Gerät noch bootet. Es ist leicht zu laufen und läuft selten.
Versionsverfolgung in der gesamten Flotte
Flotten sammeln Versionen. Einheiten, die während eines Rollouts offline sind, im Rahmen der Garantie ersetzt oder aus alten Lagerbeständen in Betrieb genommen werden, landen in Builds, die niemand verfolgt, wodurch Fehlermuster unleserlich werden.
Das Melden der laufenden Version und das Abgleichen der bereitgestellten Version mit der beabsichtigten Version ist Teil des Aktualisierungssystems und kein separates Berichtsproblem.