Schwerpunkte

Sicher per Funk

Over-The-Air-Updates für Steuergeräte

08. Juni 2021, 08:30 Uhr   |  Autor: Osvaldo Romero, Redaktion: Irina Hübner


Fortsetzung des Artikels von Teil 1 .

Client-basierte Ansätze für OTA-Updates

Abhängig von der Größe des Software-Images, dem verfügbaren nichtflüchtigen Programmspeicher und den vorhandenen Datenverarbeitungselementen gibt es verschiedene Möglichkeiten, ein OTA-Update auszuführen. Unabhängig von der verwendeten Methode muss der Client, zum Beispiel eine ECU, nach dem Update direkt mit der Ausführung des neuen Software-Images beginnen. Das bedeutet, dass das System von einem bekannten Punkt aus startet. In den meisten Fällen handelt es sich dabei um einen Neustart.

Einige Mikrocontroller unterstützen OTA-Updates mit Funktionen, die die verschiedenen Update-Optionen ermöglichen. Diese Unterstützung beginnt mit dem Bootloader, kann sich aber auch auf Hardwarefunktionen erstrecken. Dazu zählen beispielsweise die Partitionierung des nichtflüchtigen Speichers oder die Möglichkeit, Read-While-Write-Vorgänge auszuführen, bei denen derselbe Speicher gleichzeitig beschrieben und ausgelesen wird. Dadurch lässt sich ein neues Image speichern, während das Gerät weiterhin das aktuelle Software-Image ausführt.

Wenn die MCU der Anwendung keine Speicherblöcke mit Read-While-Write unterstützt oder das Software-Image so groß ist, dass mehr als die Hälfte des verfügbaren Speicherbereichs benötigt wird, muss die verwendete OTA-Methode ein direktes (In-Place-)Update sein. In diesem Fall sendet der OTA-Manager – der idealerweise mindestens zwei Versionen der Software speichert – das Update an den Client. Sobald das Update authentifiziert ist, führt der Client sein Bootloader-Programm aus, um den im nichtflüchtigen Speicher gespeicherten Programmcode byteweise zu überschreiben. Damit wird die vorherige Kopie der Software direkt im Speicher überschrieben.

Dieser Ansatz entfernt die bisherige, funktionierende Software und ersetzt sie durch das Update, was Risiken mit sich bringt. Um dem vorzubeugen, muss erstens zwischen Client und Manager ein gutes Sicherheitsprotokoll vorliegen, um die Gültigkeit der Software sicherzustellen. Zweitens sollte der Client in der Lage sein, den Status des Updates als Erfolg oder Misserfolg aufzuzeichnen.

Dies ist erforderlich, falls während der Update-Übertragung zwischen Manager und Client eine Unterbrechung oder Beschädigung auftritt. Bei In-Place-Updates kann der Client nach Beginn des Updates nicht mehr auf die vorherige Version zurückgreifen. Er müsste entweder das letzte bekannte funktionierende Image oder das aktuelle Update neu laden, indem er es beim Einschalten erneut vom Manager anfordert. Der Bootloader müsste diese Statusprüfung als Teil jedes Neustarts durchführen.

Eine andere Möglichkeit, In-Place-Updates durchzuführen, besteht darin, das OTA-Update in einem externen Speicher abzulegen und das neue Image während des Startvorgangs oder nach einem Reset, zum Beispiel Aus- und Wiedereinschalten, in den On-Chip-Programmspeicher zu laden. Der Nachteil hierbei ist der zusätzlich benötigte Speicher, der den Strombedarf, den erforderlichen Platz auf der Leiterplatte und die Gesamtkosten erhöht.

Ein weiterer Ansatz ist – wenn die Systemressourcen dies unterstützen – die A/B-Swap-Methode. Dabei belegt das Software-Image weniger als die Hälfte des verfügbaren Programmspeichers. Das neue Image wird in den Teil des Speichers geladen, der nicht zum Speichern einer aktiven Version der Software verwendet wird. Nach dem Laden und Überprüfen startet das System neu und beginnt mit der Ausführung des neuen Images, während das vorherige Image im nun unbenutzten Teil des Programmspeichers gespeichert ist.

Merkmale und Vorteile der unterschiedlichen OTA-Ansätze
© NXP

Tabelle 1. Merkmale und Vorteile der unterschiedlichen OTA-Ansätze.

Dieser Ansatz bietet gegenüber dem In-Place-Update mehrere Vorteile. Zum einen gibt es nach dem Update eine Rollback-Option auf das vorherige Software-Image, das noch im Programmspeicher abgelegt ist. Zum anderen kann das Gerät wie gewohnt weiterlaufen, während das Update in den Programmspeicher geladen wird, da das neue Image im freien Speicher abgelegt ist.

Die Hauptanforderung auf Systemebene ist dabei, dass etwa doppelt so viel Programmspeicher verfügbar sein muss als eigentlich für das Programm benötigt wird. Die Vorteile können jedoch die Kosten für die zusätzliche Speicherkapazität überwiegen – insbesondere bei einer sicherheitskritischen Anwendung. Tabelle 1 gibt einen Überblick über die einzelnen Ansätze und ihre Vorteile.

Sicher durch Mikrocontroller

Die MCUs der Serie S32K3 von NXP wurden entwickelt, um OTA-Funktionen in anspruchsvollen Anwendungen zu ermöglichen. Die Architektur ist nicht nur für den Einsatz im Automobilbereich qualifiziert, sondern verfügt auch über einen Dual-Bank On-Chip-Flash-Speicher, der Read-While-Write unterstützt. Entwickler können je nach Anwendung die In-Place- oder die A/B-Swap-Methode für Software-Updates umsetzen (Bild 2).

Beispiel für die Implementierung eines A/B-Swap-OTA mit der MCU S32K3
© NXP

Bild 2. Beispiel für die Implementierung eines A/B-Swap-OTA mit der MCU S32K3.

Die On-Chip-Speicher- und Prozessor-Subsysteme handhaben die Adressneuzuweisung, die beim Wechsel von einem Block zu einem anderen im A/B-Swap-Modus erforderlich ist. Hersteller müssen sich damit nicht um die Übersetzung der Software kümmern, was die OTA-Entwicklung erleichtert. Darüber hinaus lassen sich im Flash-Speicher auch Bereiche sperren. So kann verhindert werden, dass der Bootloader einen kritischen Code löscht oder überschreibt.

Ein weiteres Merkmal ist die Option für eine Multicore-Architektur. Dies würde es einem Arm Cortex-M7 Core ermöglichen, die Ausführung aus einem Teil des Flash-Speichers heraus fortzusetzen, während der zweite Arm Cortex-M7 Core den neuen Software-Download, die Authentifizierung und die Speicherung im anderen Teil des Flash-Speichers übernimmt.

Wie erwähnt, ist einer der Vorteile der A/B-Swap-Methode, dass die ältere Version der Software weiterhin im Speicher abgelegt ist. Tritt also ein Problem mit dem neuen Software-Image auf, kann die MCU schnell zur vorherigen Version zurückkehren. Der S32K3x4 verfügt über mehrere Bänke mit 1 MB Programm-Flash-Speicher und 128 KB Daten-Flash. Die OTA-Indikatoren werden verwendet, um den aktiven Block zu identifizieren, der die Version der aktuell ausgeführten Software enthält.

Die MCU S32K3x4 von NXP im Rahmen einer OTA-Lösung
© NXP

Tabelle 2. Die MCU S32K3x4 von NXP im Rahmen einer OTA-Lösung.

Die Sicherheit der Serie S32K3 wird durch eine Hardware Security Engine (HSE) gewährleistet. Dieser Funktionsblock er-möglicht eine Ver- und Entschlüsselung durch symmetrische und asymmetrische Chiffren, einschließlich AES-128/256 und RSA. Diese Funktionen sorgen für eine sichere Kommunikation zwischen Client und OTA-Manager, indem beispielsweise eine Zufallszahl generiert wird, die bei jeder Trans-aktion zwischen Client und Manager ausgetauscht wird.

Ein auf dem S32K3 basierender Client kann sicher mit einem OTA-Manager über CAN, LIN oder Ethernet kommunizieren, die alle von Haus aus unterstützt werden. Die MCU enthält auch Hardwarefunktionen für OTA, wie OTA-Indikatoren, einen Monitor zum Erkennen und Aufzeichnen von Kommunikationsverlusten während eines Softwareaustauschs sowie die Möglichkeit, die Software basierend auf dem Status der OTA-Indikatoren zurückzusetzen.

Der Autor

Osvaldo-Romero von NXP
© NXP

Osvaldo-Romero von NXP.

Osvaldo Romero

ist System and Architecture Engineer für Automotive-Mikrocontroller bei NXP Semiconductors und verfügt über langjährige Erfahrung im Bereich von Automotive-Karosserieanwendungen. Romerohat seinen Master of Science in Elektronik an der ITESM in Guadalajara, Mexiko, abgeschlossen.

Seite 2 von 2

1. Over-The-Air-Updates für Steuergeräte
2. Client-basierte Ansätze für OTA-Updates

Auf Facebook teilen Auf Twitter teilen Auf Linkedin teilen Via Mail teilen

Das könnte Sie auch interessieren

Verwandte Artikel

NXP Semiconductors Germany, NXP Semiconductor Netherlands B.V.