Figure 9.95: Interfaces required by Update and Configuration Management (part 3)

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm / Schnittstellen-Strukturdiagramm nach dem AUTOSAR Adaptive Platform Metamodell-Profil (aap*).
• Technischer Zweck: Spezifikation der externen Schnittstellenabhängigkeiten des Functional Clusters (FC) Update and Configuration Management (UCM) im Rahmen der Software-Aktualisierung (Teil 3).
• Architektonische Einordnung: Zeigt die Entkopplung von UCM gegenüber State Management (SM) und Cryptography. UCM fungiert als Orchestrator für Software-Pakete, delegiert jedoch Systemzustandsänderungen und Fahrzeugsicherheits-Entscheidungen an SM via Service-Oriented Communication (ara::com) und nutzt kryptografische Primitiven/Zertifikatsprüfungen über das native C++-API von Cryptography (ara::crypto).

2. Komponenten, Entitäten & Schnittstellen

Komponenten / Functional Clusters («aapFunctionalCluster»)

• Update and Configuration Management (daemon-based): Zentraler Dämon zur Installation, Aktualisierung und Deinstallation von Adaptive Applications und Plattform-Software.
• State Management (daemon-based): Dämon zur Kontrolle von Maschinen- und Funktionsgruppenzuständen sowie Ausführungskontexten.
• Cryptography (daemon-based): Dämon/Subsystem zur Bereitstellung kryptografischer Operationen (X.509, Hash, Signaturen, Key Storage).

Schnittstellen & Ports

• UpdateRequest:
  • Stereotypen: «aapAraComServiceInterface, aapInterface» (dienstbasierte IPC-Schnittstelle über ara::com).
  • Verbindung: Wird von State Management über einen «aapProvidedPort» bereitgestellt und von UCM über einen «aapRequiredPort» («use») konsumiert.
  • Felder (stereotypisiert als «aapAccessControlled, aapServiceField»):
    • ResetMachineNotifier: Service-Feld zur Statusbenachrichtigung über den Fortgang und das Ergebnis des Maschinen-Neustarts (ResetMachine).
  • Methoden (stereotypisiert als «aapAccessControlled, aapServiceMethod»):
    • RequestUpdateSession(): Beantragt den Eintritt in den Update-Modus.
    • PrepareUpdate(): Signalisiert SM das Herunterfahren/Einfrieren betroffener Funktionsgruppen/Prozesse vor dem Schreiben.
    • VerifyUpdate(): Triggert die Funktions- und Ausführungsprüfung nach Installation/Aktivierung.
    • PrepareRollback(): Signalisiert SM die Einleitung des Rückbaus auf den vorherigen Stand bei Validierungsfehlern.
    • ResetMachine(): Fordert einen kontrollierten Neustart der Maschine (ECU) an (z. B. nach A/B-Partitionswechsel).
    • StopUpdateSession(): Beendet die Update-Sitzung und gibt das System für den Normalbetrieb frei.
• CryptoStack:
  • Stereotypen: «aapAPI, aapNativeInterface» (In-Process C++ Bindeglied/Client-Bibliothek zu kryptografischen Routinen).
  • Verbindung: Wird von Cryptography implementiert und von UCM via direkter Funktionsaufrufe («use») konsumiert.

3. Dynamisches Verhalten & Sequenzablauf

1. Sitzungsinitiierung (RequestUpdateSession): UCM fordert bei SM eine Update-Sitzung an. SM prüft Vorbedingungen (z. B. Fahrzeugzustand „Parken“, kein aktiver Fahrbetrieb) und reserviert den Zustand exklusiv.
2. Paketvalidierung (CryptoStack): UCM verifiziert Signatur, Zertifikatskette und Hashes der eingehenden Software-Pakete (Software Package) synchron/asynchron über ara::crypto.
3. Zustandsumschaltung (PrepareUpdate): UCM benachrichtigt SM. SM instruiert das Execution Management (EM), Zielprozesse kontrolliert zu beenden oder Funktionsgruppen zu deaktivieren.
4. Partitionierung / Neustart (ResetMachine): Nach dem Schreiben der Artefakte fordert UCM einen Neustart via SM an (ResetMachine). SM signalisiert UCM über das Service-Feld ResetMachineNotifier den Ausführungsstatus des Neustarts bzw. den Eintritt in den Folgezustand, um in die neue Software-Konfiguration zu booten.
5. Verifikation (VerifyUpdate): Nach Boot/Start prüft SM das erfolgreiche Anlaufen aller Prozesse (Health Monitoring) und meldet Erfolg an UCM zurück.
6. Abschluss oder Fehlerbehandlung:
   • Gutfall: UCM ruft StopUpdateSession(); SM schaltet vollständig in den Normalbetrieb zurück.
   • Schlechtfall: Schlägt die Verifikation fehl, ruft UCM PrepareRollback(), wodurch SM die alten Funktionsgruppen reaktiviert bzw. einen Fallback-Reset anweist.

4. Normative Relevanz & Entwickler-Hinweise

• Zugriffsschutz (IAM): Sowohl alle Methoden als auch das Feld ResetMachineNotifier von UpdateRequest tragen das Stereotyp «aapAccessControlled». Der UCM-Prozess muss im Adaptive Execution Manifest mit entsprechenden Rechten (Identity and Access Management / IAM-Policies) ausgestattet sein, um die Methoden und Feld-Notifikationen an bzw. von SM über IPC nutzen zu dürfen.
• Architektonische Trennung (Separation of Concerns): UCM besitzt keine Berechtigung, Prozesse direkt per POSIX-Signals (SIGTERM/SIGKILL) zu stoppen oder System-Reboots (reboot()) auszulösen. Sämtliche Lifecycle-Aktionen müssen strikt über den Dienstvertrag von SM angefordert werden.
• API-Vertrag & Fehlerbehandlung: Aufrufe an UpdateRequest liefern ara::core::Future<ara::core::Result<void>> zurück. UCM-Entwickler müssen Timeouts und Negativ-Quittungen (z. B. Ablehnung von RequestUpdateSession wegen unsicherem Fahrzeugzustand) deterministisch mit Fehler-Rollbacks abfangen.
• Krypto-Bindung: CryptoStack wird nativ als C++-API (ara::crypto::keys, ara::crypto::cryp) eingebunden. Krypto-Operationen für große Software-Images erfordern hardwarebeschleunigte Treiber (HSM/SHE-Anbindung) im Hintergrund des Cryptography-Dämons, um Timeouts bei der Signaturprüfung zu vermeiden.