Figure 9.10: 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:
  • Update and Configuration Management («aapFunctionalCluster», Ausprägung: daemon-based): Zentraler Plattform-Daemon zur Koordination und Ausführung von Software- und Konfigurationsaktualisierungen; agiert als Service-Consumer (Client).
  • 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 Update and Configuration Management 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.
  • Service Fields («aapAccessControlled, aapServiceField»):
    • ResetMachineNotifier: Asynchrones Benachrichtigungsfeld / Event zur Signalisierung des Machine-Reset-Status (z. B. erfolgreicher Neustart kSuccessful nach Ausführung von ResetMachine()).
  • Service Methods («aapAccessControlled, aapServiceMethod»):
    • 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):
   • Update and Configuration Management (UCM) ruft RequestUpdateSession() via ara::com auf.
   • State Management (SM) prüft globale System-Preconditions (z. B. Fahrzeugzustand, Diagnosemodus) und bestätigt oder verweigert die Sitzung.
2. Vorbereitung (Staging-Phase):
   • Nach erfolgreichem Transfer und Vorbereiten der Software-Cluster ruft UCM PrepareUpdate() auf.
   • SM überführt betroffene Funktionsgruppen und Applikationsprozesse über das Execution Management (ara::exec) in einen sicheren bzw. inaktiven Zustand.
3. Aktivierung, Neustart & Benachrichtigung:
   • UCM fordert über ResetMachine() einen kontrollierten Warmstart/Reboot der Machine an.
   • SM koordiniert das Herunterfahren und den Neustart der Maschine.
   • Nach dem Wiederhochlauf signalisiert SM über das Service-Field ResetMachineNotifier asynchron das Ergebnis des Neustarts (z. B. kSuccessful), sodass UCM den Update-Ablauf an der unterbrochenen Stelle fortsetzen kann.
4. Verifikation & Abschluss / Rollback:
   • UCM veranlasst über VerifyUpdate() die Funktions- und Integritätsprüfung des neuen Softwarestands durch SM.
   • Bei erfolgreicher Prüfung beendet UCM die Sitzung via StopUpdateSession().
   • Schlägt die Verifikation fehl oder bricht das Update ab, veranlasst UCM über PrepareRollback() die Rückführung auf den vorherigen Softwarestand.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Schnittstellenerweiterung:
  • Das Interface UpdateRequest spezifiziert ab R24-11 neben den Service-Methoden explizit das Service-Field ResetMachineNotifier. Implementierungen von State Management (Server) und UCM (Client) müssen dieses Feld VFB- und ara::com-konform bereitstellen bzw. abonnieren.
• IAM & Zugriffskontrolle («aapAccessControlled»):
  • Sowohl die Service-Methoden als auch das Field ResetMachineNotifier unterliegen der Zugriffskontrolle über das Identity and Access Management (IAM). In den Deployment-Manifesten müssen Client- und Server-Rechte für Methodenaufrufe und Event-Notifizierungen explizit konfiguriert werden.
• Asynchrone Zustandsübergänge & Persistenz:
  • Durch den Maschinen-Reset wird der Prozesskontext von UCM und SM unterbrochen. UCM muss seinen internen Zustand vor ResetMachine() persistent ablegen (ara::per) und sich nach dem Wiederanlauf am Notifier des State Managements registrieren, um die Bestätigung (ResetMachineNotifier) für den Phasenübergang zur Verifikation zu empfangen.