Wie funktioniert das Update von AUTOSAR Classic-Steuergeräten über das UCMModul? Welche Software-Komponenten müssen Fahrzeughersteller und -Zulieferer noch zu Adaptive AUTOSAR hinzufügen und welche technischen Voraussetzungen müssen erfüllt sein? Diese Fragen beantwortet Bernhard Wagner von KPIT. Er ist Mitglied der ursprünglichen Standardisierungs-Gruppe D-PDU API und Verfasser der technischen Spezifikation für Adaptive AUTOSAR.
Adaptive AUTOSAR bietet bei der Realisierung von komplexeren Softwarearchitekturen im Fahrzeug eine hohe Flexibilität. Diese Flexibilität der Software benötigt zur Wartung sogenannte Over the Air (OTA) Updates. Mit der EU7-Regulation könnte OTA für Onboard-Monitoring (OBM) sogar regulativ verpflichtend werden.
In Adaptive AUTOSAR gibt es seit dem Release 2019–11 mit dem Update und Configuration-Management (UCM) eine bordeigene Lösung für Updates von Software Clustern (SWC). Die vielen anderen Butter- und Brot-Steuergeräten im Fahrzeug, die weiterhin mit Classic-AUTOSAR oder mit proprietären Lösungen arbeiten, benötigen ebenso eine Lösung. Mit dem neuen Release 2020–11 wurde die UCM-Spezifikation um die Programmierung von Classic- Steuergeräten erweitert. Die gefundene einfache Lösung beruht auf dem seit 2009 in Off-Board-Testern etablierten Standard ISO 22900–2 „Diagnostic-Protocol Data Unit API“, einfach auch als D-PDU API bezeichnet (Bild 1).
OTA Client
Ausgangspunkt des Update Prozesses ist eine als “OTA Client“ bezeichnete adaptive Applikation. Diese für ein Fahrzeug und OEM spezifische Applikation hat die Aufgabe mit einem OEM-Backend in der Cloud oder alternativ mit einem herkömmlichen Werkstatttester zu kommunizieren und die Flash-Daten im Fahrzeug bereitzustellen. Die Kommunikationskanäle und -physik sind hierbei nicht näher von der AUTOSAR-Architektur vorgegeben. Typisch sind aber kryptografisch abgesicherte Verbindungen über ein Funknetz in die Cloud, oder mit einem lokalen Werkstatttester über Ethernet oder CAN.
Die OTA-Client Applikation ist für die externe Kommunikation verantwortlich und abstrahiert diese Kommunikation völlig. Der UCM-Master ist eine davon getrennte adaptive Service-Instanz. Er stellt die Information über Steuergeräte (ECUs), das Fahrzeug selber, die installierte Software und den Status von Aktualisierungskampagnen über ein ARA::COM Interface für den OTA-Client, aber auch für die „Vehicle Driver Application“ und den „Vehicle State Manager“ zur Verfügung. Die letzten beiden Applikationen stellen sicher, dass sowohl der Fahrer einem Update zustimmt und andererseits während einer Aktualisierungskampagne das Fahrzeug nicht in Betrieb genommen werden kann.
Der UCM-Master empfängt, die als Vehicle Packages bezeichneten Flash-Daten eines gesamten Fahrzeuges. Ein Vehicle Package wird typischerweise vom OEM für ein gesamtes Fahrzeug bereitgestellt. Es enthält neben einem einzigen Vehicle Package Manifest eine Kollektion von Software-Paketen für die verschiedenen (virtuellen) Hardware- Plattformen, ECUs und Softwarecluster.
Weiterhin enthält es für jedes Software- Paket eine eindeutige Möglichkeit, dieses seinem UCM-Client zuzuordnen.
Nachdem das Vehicle Package aus Bild 2 von dem UCM-Master korrekt empfangen wurde, kann der Update- Prozess des Fahrzeuges beginnen. Ein Update umfasst jeweils eine oder mehrere Plattformen, ECUs und (Root-) Softwarecluster.
UCM stellt mit Hilfe der Daten aus dem Vehicle Package den zeitlich korrekten Ablauf der Updates sicher.
Dieser Ablauf kann auch mehrere Reboots von ECUs, der adaptiven Plattform und von UCM selbst enthalten. Dazu werden die verschiedenen UCMClients, auch als UCM-Surrogates bezeichnet, in der notwendigen Reihenfolge aufgerufen.
Der UCM-Master beginnt dann die Programmierung eines Software-Paketes (SWP) durch den Aufruf von RequestPackage am OTA-Client, wie in Bild 3 gezeigt wird. Der UCM-Master führt für alle UCM-Clients die folgenden drei Phasen durch. Hierbei hat er alle Abhängigkeiten der verschiedenen Software-Pakete und ECUs untereinander zu berücksichtigen.
Software-Paket Datentransfer
Der Ablauf startet mit dem Transfer der eigentlichen Flash-Daten von OTA-Client über den UCM-Master zu den UCMClients.
Diese Daten werden mit einer zu UDS analogen Reihenfolge von TransferStart, mehreren TransferData gefolgt von einem finalen TransferExit zu den verschiedenen UCM-Clients übertragen.
Dieser Ablauf darf zur Geschwindigkeitsoptimierung auch parallel für verschiedene UCM-Clients erfolgen. Der Flashing Adapter wird daher die Daten zunächst zwischenspeichern.
Nachdem das Einverständnis des Fahrers vorliegt und weitere Vorbedingungen – wie ein Fahrzeugsstillstand – sichergestellt sind, kann nun die eigentliche Reprogrammierung des Classic- Steuergerätes durch den zugeordneten Flashing Adapter erfolgen.
Software-Pakete Bearbeitung
Der UCM Master entscheidet auf Basis der Daten des Vehicle Package wann die Bearbeitung des Software-Paketes im Gesamtablauf stattfinden darf. Er triggert zum definierten Zeitpunkt das Update der ECU durch den Flashing Adapter mit ProcessSw Package an.
Daraufhin führt der Flashing Adapter eine normale UDS Flash-Sequenz aus, so wie sie in der ISO 14229–1:2020 in den Kapiteln 17.2.1.1 „Pre-Programming step of phase #1“ und 17.2.1.2 „Programming step of phase #1 — Download of application software and data“ beschrieben ist. Ein Flashing Adapter kennt und beachtet den für das Steuergerät spezifischen Ablauf und stellt alle notwendigen Daten bereit, z. B. für einen Security Access und das Erase Memory.
Der Flashing Adapter baut zur Übertragung der UDS-Services auf eine im Umfang deutlich reduzierte D-PDU API „C“-Schnittstelle auf. Diese UDS-Daten werden über einen CAN- oder Ethernet- Bus an das zu reprogrammierende Classic- Steuergerät übertragen. Der Flashing Adapter stellt hierzu nur die eigentlichen Binärdaten (PDU‘s) unabhängig von einem Protokoll oder der Implementierung der D-PDU API zur Verfügung. Er kann daher in verschiedenen adaptiven Umgebungen oder unterschiedlichen Hardware Plattformen ohne Änderung genutzt werden.
Nach den TransferExit schließt dieser Ablauf mit der Berechnung und Überprüfung der Checksumme der neu programmierten Applikation der Classic- ECU ab. Das Ergebnis dieses Flashprozess wird abschließend für diesen Schritt an den UCM-Master mit Current- Status=READY zurückgemeldet.
Aktivierung
Nach dem Transfer der Daten zur Classic- ECU überprüft der UCM-Master nochmals die Abhängigkeiten der beteiligten Software Cluster untereinander und die Sicherheitsbedingungen des Fahrzeuges. Im positiven Fall ruft dann
der UCM-Master den Flashing Adapter nochmals mit Activate auf. Dieser Aufruf löst die in der ISO 14229–1:2020 unter Punkt 17.2.1.3 und 17.2.1.4 beschriebenen Post-Programming Schritte zur Finalisierung aus. Insbesondere wird dadurch auch das verbundene Classic Steuergerät durch einen „Hard Reset“ neu gestartet. Der Flashing Adapter beendet seine Tätigkeit mit der Rückmeldung an den OTA-Client, dass das neue Software-Paket CurrentStatus=ACTIVATED ist. Nach dem Ablauf der Reprogrammierung meldet seinerseits der UCM-Master den erfolgreichen Transfer des Pakets mit den State TransferState= IDLE an den OTA-Client und der Ablauf ist abgeschlossen.
Diese Architektur bringt viele Vorteile mit sich:
- Bei der Bereitstellung eines Vehicle Packages macht es für die Software- Pakete keinen Unterschied ob es sich um ein Adaptive- oder Classic- Steuergerät handelt. Ein adaptiver OTA-Client eines OEMs im Fahrzeug, kann somit alle vernetzten Steuergeräte dieses Fahrzeuges aktualisieren.
- Der Flashing Adapter als UCMClient hat nach oben (Layer 7) die AUTOSAR UCM-Schnittstelle und nach unten (Layer 5) die standardisierte D-PDU API-Schnittstelle. Er hängt somit weder von der Hardware noch von Lieferanten eines AUTOSAR-Stacks ab. Zulieferer für Steuergeräte können somit einen parametrisierten Flashing Adapter als AUTOSAR-Applikation zu ihren Classic-Steuergeräten an den OEM liefern um ihre Steuergeräte im Feld zu reprogrammieren.
- Die ISO 22900–2 (D-PDU API) hat sich seit 2008 in vielen Off-Board Diagnosesystemen im Feld bewährt. In der D-PDU API sind alle Protokollparameter und deren Verhalten vollumfänglich standardisiert, was für einen Austausch von Applikationen essenziell ist.
- Der On-Board Flashing Adapter ist in den relevanten Teilen identisch zu einer Off-Board Diagnoseapplikation entsprechend der ISO 22900–3. Dadurch können Flash-Sequenzen einfach zunächst Off-Board entwickelt und getestet werden, bevor sie dann final als Flashing Adapter in eine adaptive AUTOSAR-Umgebung integriert werden.
Fazit
KPIT hat bei mehreren großen OEMs bereits sehr gute Erfahrungen mit einem Vorläufer dieses Konzeptes, bestehend aus OTA-Client und Flashing Adapter, gesammelt. Insbesondere die standardisierten Protokollparameter sind bei notwendigen Anpassungen während einer dynamischen Entwicklung sehr vorteilhaft. Die Fahrzeug-Updates selber verlaufen problemlos, unauffällig und sind leicht zu testen. www.kpit.com
Adaptive AUTOSAR bietet bei der Realisierung von komplexeren Softwarearchitekturen im Fahrzeug eine hohe Flexibilität. Diese Flexibilität der Software benötigt zur Wartung sogenannte Over the Air (OTA) Updates. Mit der EU7-Regulation könnte OTA für Onboard-Monitoring (OBM) sogar regulativ verpflichtend werden.
In Adaptive AUTOSAR gibt es seit dem Release 2019–11 mit dem Update und Configuration-Management (UCM) eine bordeigene Lösung für Updates von Software Clustern (SWC). Die vielen anderen Butter- und Brot-Steuergeräten im Fahrzeug, die weiterhin mit Classic-AUTOSAR oder mit proprietären Lösungen arbeiten, benötigen ebenso eine Lösung. Mit dem neuen Release 2020–11 wurde die UCM-Spezifikation um die Programmierung von Classic- Steuergeräten erweitert. Die gefundene einfache Lösung beruht auf dem seit 2009 in Off-Board-Testern etablierten Standard ISO 22900–2 „Diagnostic-Protocol Data Unit API“, einfach auch als D-PDU API bezeichnet (Bild 1).
OTA Client
Ausgangspunkt des Update Prozesses ist eine als “OTA Client“ bezeichnete adaptive Applikation. Diese für ein Fahrzeug und OEM spezifische Applikation hat die Aufgabe mit einem OEM-Backend in der Cloud oder alternativ mit einem herkömmlichen Werkstatttester zu kommunizieren und die Flash-Daten im Fahrzeug bereitzustellen. Die Kommunikationskanäle und -physik sind hierbei nicht näher von der AUTOSAR-Architektur vorgegeben. Typisch sind aber kryptografisch abgesicherte Verbindungen über ein Funknetz in die Cloud, oder mit einem lokalen Werkstatttester über Ethernet oder CAN.
Die OTA-Client Applikation ist für die externe Kommunikation verantwortlich und abstrahiert diese Kommunikation völlig. Der UCM-Master ist eine davon getrennte adaptive Service-Instanz. Er stellt die Information über Steuergeräte (ECUs), das Fahrzeug selber, die installierte Software und den Status von Aktualisierungskampagnen über ein ARA::COM Interface für den OTA-Client, aber auch für die „Vehicle Driver Application“ und den „Vehicle State Manager“ zur Verfügung. Die letzten beiden Applikationen stellen sicher, dass sowohl der Fahrer einem Update zustimmt und andererseits während einer Aktualisierungskampagne das Fahrzeug nicht in Betrieb genommen werden kann.
Der UCM-Master empfängt, die als Vehicle Packages bezeichneten Flash-Daten eines gesamten Fahrzeuges. Ein Vehicle Package wird typischerweise vom OEM für ein gesamtes Fahrzeug bereitgestellt. Es enthält neben einem einzigen Vehicle Package Manifest eine Kollektion von Software-Paketen für die verschiedenen (virtuellen) Hardware- Plattformen, ECUs und Softwarecluster.
Weiterhin enthält es für jedes Software- Paket eine eindeutige Möglichkeit, dieses seinem UCM-Client zuzuordnen.
Nachdem das Vehicle Package aus Bild 2 von dem UCM-Master korrekt empfangen wurde, kann der Update- Prozess des Fahrzeuges beginnen. Ein Update umfasst jeweils eine oder mehrere Plattformen, ECUs und (Root-) Softwarecluster.
UCM stellt mit Hilfe der Daten aus dem Vehicle Package den zeitlich korrekten Ablauf der Updates sicher.
Dieser Ablauf kann auch mehrere Reboots von ECUs, der adaptiven Plattform und von UCM selbst enthalten. Dazu werden die verschiedenen UCMClients, auch als UCM-Surrogates bezeichnet, in der notwendigen Reihenfolge aufgerufen.
Der UCM-Master beginnt dann die Programmierung eines Software-Paketes (SWP) durch den Aufruf von RequestPackage am OTA-Client, wie in Bild 3 gezeigt wird. Der UCM-Master führt für alle UCM-Clients die folgenden drei Phasen durch. Hierbei hat er alle Abhängigkeiten der verschiedenen Software-Pakete und ECUs untereinander zu berücksichtigen.
Software-Paket Datentransfer
Der Ablauf startet mit dem Transfer der eigentlichen Flash-Daten von OTA-Client über den UCM-Master zu den UCMClients.
Diese Daten werden mit einer zu UDS analogen Reihenfolge von TransferStart, mehreren TransferData gefolgt von einem finalen TransferExit zu den verschiedenen UCM-Clients übertragen.
Dieser Ablauf darf zur Geschwindigkeitsoptimierung auch parallel für verschiedene UCM-Clients erfolgen. Der Flashing Adapter wird daher die Daten zunächst zwischenspeichern.
Nachdem das Einverständnis des Fahrers vorliegt und weitere Vorbedingungen – wie ein Fahrzeugsstillstand – sichergestellt sind, kann nun die eigentliche Reprogrammierung des Classic- Steuergerätes durch den zugeordneten Flashing Adapter erfolgen.
Software-Pakete Bearbeitung
Der UCM Master entscheidet auf Basis der Daten des Vehicle Package wann die Bearbeitung des Software-Paketes im Gesamtablauf stattfinden darf. Er triggert zum definierten Zeitpunkt das Update der ECU durch den Flashing Adapter mit ProcessSw Package an.
Daraufhin führt der Flashing Adapter eine normale UDS Flash-Sequenz aus, so wie sie in der ISO 14229–1:2020 in den Kapiteln 17.2.1.1 „Pre-Programming step of phase #1“ und 17.2.1.2 „Programming step of phase #1 — Download of application software and data“ beschrieben ist. Ein Flashing Adapter kennt und beachtet den für das Steuergerät spezifischen Ablauf und stellt alle notwendigen Daten bereit, z. B. für einen Security Access und das Erase Memory.
Der Flashing Adapter baut zur Übertragung der UDS-Services auf eine im Umfang deutlich reduzierte D-PDU API „C“-Schnittstelle auf. Diese UDS-Daten werden über einen CAN- oder Ethernet- Bus an das zu reprogrammierende Classic- Steuergerät übertragen. Der Flashing Adapter stellt hierzu nur die eigentlichen Binärdaten (PDU‘s) unabhängig von einem Protokoll oder der Implementierung der D-PDU API zur Verfügung. Er kann daher in verschiedenen adaptiven Umgebungen oder unterschiedlichen Hardware Plattformen ohne Änderung genutzt werden.
Nach den TransferExit schließt dieser Ablauf mit der Berechnung und Überprüfung der Checksumme der neu programmierten Applikation der Classic- ECU ab. Das Ergebnis dieses Flashprozess wird abschließend für diesen Schritt an den UCM-Master mit Current- Status=READY zurückgemeldet.
Aktivierung
Nach dem Transfer der Daten zur Classic- ECU überprüft der UCM-Master nochmals die Abhängigkeiten der beteiligten Software Cluster untereinander und die Sicherheitsbedingungen des Fahrzeuges. Im positiven Fall ruft dann
der UCM-Master den Flashing Adapter nochmals mit Activate auf. Dieser Aufruf löst die in der ISO 14229–1:2020 unter Punkt 17.2.1.3 und 17.2.1.4 beschriebenen Post-Programming Schritte zur Finalisierung aus. Insbesondere wird dadurch auch das verbundene Classic Steuergerät durch einen „Hard Reset“ neu gestartet. Der Flashing Adapter beendet seine Tätigkeit mit der Rückmeldung an den OTA-Client, dass das neue Software-Paket CurrentStatus=ACTIVATED ist. Nach dem Ablauf der Reprogrammierung meldet seinerseits der UCM-Master den erfolgreichen Transfer des Pakets mit den State TransferState= IDLE an den OTA-Client und der Ablauf ist abgeschlossen.
Diese Architektur bringt viele Vorteile mit sich:
- Bei der Bereitstellung eines Vehicle Packages macht es für die Software- Pakete keinen Unterschied ob es sich um ein Adaptive- oder Classic- Steuergerät handelt. Ein adaptiver OTA-Client eines OEMs im Fahrzeug, kann somit alle vernetzten Steuergeräte dieses Fahrzeuges aktualisieren.
- Der Flashing Adapter als UCMClient hat nach oben (Layer 7) die AUTOSAR UCM-Schnittstelle und nach unten (Layer 5) die standardisierte D-PDU API-Schnittstelle. Er hängt somit weder von der Hardware noch von Lieferanten eines AUTOSAR-Stacks ab. Zulieferer für Steuergeräte können somit einen parametrisierten Flashing Adapter als AUTOSAR-Applikation zu ihren Classic-Steuergeräten an den OEM liefern um ihre Steuergeräte im Feld zu reprogrammieren.
- Die ISO 22900–2 (D-PDU API) hat sich seit 2008 in vielen Off-Board Diagnosesystemen im Feld bewährt. In der D-PDU API sind alle Protokollparameter und deren Verhalten vollumfänglich standardisiert, was für einen Austausch von Applikationen essenziell ist.
- Der On-Board Flashing Adapter ist in den relevanten Teilen identisch zu einer Off-Board Diagnoseapplikation entsprechend der ISO 22900–3. Dadurch können Flash-Sequenzen einfach zunächst Off-Board entwickelt und getestet werden, bevor sie dann final als Flashing Adapter in eine adaptive AUTOSAR-Umgebung integriert werden.
Fazit
KPIT hat bei mehreren großen OEMs bereits sehr gute Erfahrungen mit einem Vorläufer dieses Konzeptes, bestehend aus OTA-Client und Flashing Adapter, gesammelt. Insbesondere die standardisierten Protokollparameter sind bei notwendigen Anpassungen während einer dynamischen Entwicklung sehr vorteilhaft. Die Fahrzeug-Updates selber verlaufen problemlos, unauffällig und sind leicht zu testen. www.kpit.com
