Figure 9.12: Interface for software update handling

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm mit Service-Interface-Spezifikation (AUTOSAR Adaptive Platform Modellierung).
• Architektur-Kontext: AUTOSAR Adaptive Platform (R21-11), Functional Cluster Update and Configuration Management (UCM) in Interaktion mit State Management (SM).
• Technischer Zweck: Entkopplung der Update-Orchestrierung von der Systemzustandskontrolle. Das UCM (hier in der Rolle des UCM Subordinate) führt Software-Updates nicht eigenmächtig auf Prozessebene aus, sondern steuert den Lebenszyklus und die Ausführungsmodi der Machine über das servicifizierte Interface UpdateRequest, welches vom State Management bereitgestellt wird.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Komponenten:
  • UCM Subordinate: Adaptive Application / Functional Cluster Component; agiert als Service-Consumer (Client) für Update-Abläufe auf Maschinenebene.
  • State Management («aapFunctionalCluster», Ausprägung: daemon-based): Zentraler System-Daemon zur Koordination von Funktionsgruppen (FunctionGroupState), Maschinenmodi und Prozess-Lebenszyklen; agiert als Service-Provider (Server).
• Ports & Bindungen:
  • Client-Port: «aapRequiredPort» an UCM Subordinate mit Abhängigkeitsbeziehung («use») auf das Service-Interface.
  • Server-Port: «aapProvidedPort» an State Management mit Realisierungsbeziehung (Interface-Implementierung).
• Service Interface UpdateRequest:
  • Stereotypen: «aapAraComServiceInterface», «aapInterface». Bindung erfolgt über die IPC-Transportschicht von ara::com.
  • Methodenspezifische Stereotypen: «aapAccessControlled» (Absicherung über Identity and Access Management / IAM), «aapServiceMethod».
  • Methoden:
    • RequestUpdateSession(): Beantragt die exklusive Berechtigung zur Durchführung einer Update-Sitzung beim State Management.
    • PrepareUpdate(): Weist SM an, betroffene FunctionGroups bzw. Software-Cluster in einen update-fähigen Ruhezustand zu überführen.
    • VerifyUpdate(): Beauftragt SM mit der Funktions- und Integritätsprüfung nach Aktivierung des neuen Softwarestands.
    • PrepareRollback(): Signalisiert SM die Einleitung der Rückfallebene bei fehlgeschlagener Verifikation oder Update-Abbruch.
    • ResetMachine(): Fordert einen deterministischen Warmstart/Reboot der Machine an, um neue Partitionen/Softwarestände über das Execution Management zu mounten/starten.
    • StopUpdateSession(): Beendet die Update-Sitzung und versetzt die Machine zurück in den regulären Betriebsmodus.

3. Dynamisches Verhalten & Sequenzablauf

1. Session-Initialisierung (Trigger: Eingehendes Software-Paket):
   • UCM Subordinate ruft synchron/asynchron RequestUpdateSession() via ara::com.
   • State Management prüft globale System-Preconditions (z. B. Fahrzeugstillstand, Klemmenstatus, Diagnosemodus) und quittiert oder verweigert die Sitzung.
2. Vorbereitung (Staging Phase):
   • Nach erfolgreichem Transfer/Extrahieren der Software-Cluster ruft UCM PrepareUpdate().
   • SM stoppt bzw. degradiert abhängige Applikationsprozesse über das Execution Management (ara::exec).
3. Aktivierung & Neustart:
   • Nach erfolgreicher Vorbereitung triggert UCM ResetMachine().
   • SM initiiert den kontrollierten Machine-State-Wechsel (Reboot/Shutdown).
4. Verifikation & Abschluss / Rollback:
   • Nach dem Hochlauf veranlasst UCM über VerifyUpdate() die Verifikationsphase.
   • Erfolgspfad: SM meldet stabile Prozesszustände; UCM ruft StopUpdateSession(), womit die neue Version persistent geschaltet wird.
   • Fehlerpfad: Timeout oder Fehlfunktion; UCM initiiert PrepareRollback(), gefolgt von ResetMachine(), um den vorherigen Softwarestand zu reaktivieren.

4. Normative Relevanz & Entwickler-Hinweise

• Access Control & IAM (SWS / Manifeste): Da das Interface mit «aapAccessControlled» annotiert ist, muss im Service Instance Manifest und Execution Manifest ein entsprechendes Grant für den UCM-Prozess konfiguriert sein. Nicht autorisierte Aufrufe werden vom ara::com/IAM-Layer mit Security-Fehlern abgewiesen.
• Plattform-Zustandsverantwortung: Applikations- und UCM-Entwickler dürfen keine direkten OS-Reboots (z. B. POSIX reboot(), kill()) aufrufen. Der Maschinenzustand darf ausschließlich deklarativ über SM und dessen Anbindung an Execution Management gewechselt werden.
• Fehlerbehandlung (ara::core::Result): Sämtliche Methodenaufrufe erfordern robuste Auswertung von Rückgabecodes / Exceptions (insb. UcmErrorDomain bzw. SmErrorDomain). Ein Ablehnen von RequestUpdateSession() muss von UCM an das externe Diagnose- bzw. OTA-Backend propagiert werden (z. B. NRC ConditionsNotCorrect).
• Daemon-Abhängigkeit: State Management läuft als nativer Plattform-Daemon. Startreihenfolgen und IPC-Verbindungsaufbau via ara::com müssen über das Execution Manifest so synchronisiert sein, dass UpdateRequest vor Beginn jeglicher UCM-Aktivitäten bindbar ist.