Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
20 Elektronik automotive Connected Cars 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 ReadWhile-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 OTAMethode ein direktes In-Place-Update sein In diesem Fall sendet der OTAManager 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-PlaceUpdates 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 Ausund Wiedereinschalten in den On-ChipProgrammspeicher 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 Marktanforderungen Lösungen S32K3x-Funktionen ECU-Neuprogrammierung außerhalb der Werkstatt und nahtloses Update für den Fahrer keine Ausfallzeit Nahtloses Update - Download bei laufender Anwendung - Keine Ausfallzeit - Keine Installationszeit Speicherfunktionen - Read-While-Write zwischen Flash-Bänken - Automatische Firmware-Adressübersetzung - Backup-Firmware Bereitstellung einer funktionierenden Firmware im Steuergerät als Backup zu jedem Zeitpunkt Zuverlässiges und robustes Update - Erkennung von Leistungsund Kommunikationsverlusten - Mehrere Versionen der Firmware verfügbar Systemfunktionen - Rollback-Funktionalität - Versionskontrolle - Backup-Firmware Schutz vor potenziellen Sicherheitslücken Angriffsschutz - Gegen Firmware-Diebstahl - Gegen die Installation von bösartiger Firmware Sicherheitshardware - Verschlüsselung Entschlüsselung von Daten - Prüfung der Firmware-Authentifizierung Tabelle 2 Die MCU S32K3x4 von NXP im Rahmen einer OTA-Lösung Quelle NXP Bild 2 Beispiel für die Implementierung eines A B-Swap-OTA mit der MCU S32K3 Bild NXP Parameter In-Place Interner Speicher In-Place Interner Speicher und externer Speicher A B Swap zwei Embedded-Softwareversionen im internen Speicher Download bei laufender Anwendung Nein Ja Ja Softwareversionsverfolgung Ja ausgeführt durch Bootloader Ja ausgeführt durch Bootloader Ja in Hardware Stromoder Kommunikationsverlust überwachen Ja ausgeführt durch Bootloader Ja ausgeführt durch Bootloader Ja in Hardware ECU-Ausfallzeit Ja neue Softwareversion empfangen und speichern Ja neue Softwareversion vom externen in den internen Flash-Speicher kopieren Nein Backup-Software verfügbar Verfügbar im OTA-Manager Verfügbar im externen Flash-Speicher des OTA-Client Verfügbar im internen Flash-Speicher des OTA-Client Tabelle 1 Merkmale und Vorteile der unterschiedlichen OTA-Ansätze Quelle NXP