Figure 5.1: Interfaces provided by Update and Configuration Management to other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponenten- und Serviceschnittstellen-Diagramm (AUTOSAR Adaptive Service Interface Definition).
• Technischer Zweck: Spezifikation der vom Functional Cluster (FC) Update and Configuration Management (UCM) bereitgestellten ara::com-Dienste für die Plattform-Software-Aktualisierung und -Konfiguration auf Node-/Maschinenebene.
• Architektur-Einordnung: UCM agiert als lokaler Plattform-Daemon. Die Schnittstelle kapselt das lokale Paket- und Software-Cluster-Lifecycle-Management gegen fahrzeugweite Orchestratoren (wie den Vehicle Update and Configuration Management / VUCM) oder autorisierte OTA-/Diagnose-Clients ab.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Funktionscluster

• Update and Configuration Management:
  • Stereotyp: «aapFunctionalCluster», Implementierungsform: daemon-based.
  • Rolle: Service-Provider; implementiert die Kernlogik zur Installation, Verifizierung, Aktivierung und zum Rollback lokaler Software-Pakete.
• Vehicle Update and Configuration Management:
  • Stereotyp: «aapFunctionalCluster», Implementierungsform: daemon-based.
  • Rolle: Service-Consumer; fahrzeugweiter Kampagnenmanager, der Updates über mehrere Adaptive (und Classic) ECUs koordiniert.

Schnittstelle (Service Interface)

• Update and Configuration Management::PackageManagement:
  • Stereotyp: «aapAPI, aapAraComServiceInterface».
  • Kommunikationsbindung: Serviceorientierte Kommunikation via ara::com (Skeletons/Proxies über SOME/IP oder IPC).
  • Ports & Beziehungen:
    • UCM bindet die Schnittstelle über einen «aapProvidedPort» (Interface Realization).
    • VUCM konsumiert die Schnittstelle über einen «aapRequiredPort» mit «use»-Abhängigkeit.

Schnittstellenelemente (Service Members)

• Service Field («aapAccessControlled, aapServiceField»):
  • CurrentStatus: Notifiziert und publiziert den aktuellen Zustand der UCM-State-Machine (z. B. Idle, Processing, Ready, RolledBack).
• Service Methods («aapAccessControlled, aapServiceMethod»):
  • Transfer-Pipeline: TransferStart(), TransferData(), TransferExit(), DeleteTransfer().
  • Verarbeitungs- & Lifecycle-Steuerung: ProcessSwPackage(), RevertProcessedSwPackages(), Activate(), Rollback(), Finish(), Cancel().
  • Status- & Metadaten-Abfragen: GetHistory(), GetId(), GetSwClusterChangeInfo(), GetSwClusterInfo(), GetSwClusterManifestInfo(), GetSwPackages(), GetSwProcessProgress().
• Sicherheits-Stereotyp («aapAccessControlled»): Jede Methode und jedes Feld unterliegt zwingend dem AUTOSAR Identity and Access Management (IAM); Zugriffe erfordern entsprechende Manifest-Berechtigungen (Process Execution / IAM Grants).

3. Dynamisches Verhalten & Sequenzablauf

Das Zusammenspiel folgt dem normativen UCM-Paketlebenszyklus:

1. Transfer-Phase (Streaming ins Staging-Dateisystem):
   • Aufruf von TransferStart() initiiert eine Session und liefert ein TransferId.
   • Sequenzielles Übertragen der Paketfragmente via TransferData(TransferId, ...).
   • Abschluss des Dateitransfers durch TransferExit(TransferId) oder Abbruch via DeleteTransfer().
2. Prozessierungs-Phase (Integritätsprüfung & Vorbereitung):
   • ProcessSwPackage(TransferId) dekomprimiert, validiert Signaturen/Manifeste und überführt die Software in den inaktiven Partitionierungs- bzw. Staging-Bereich.
   • Asynchrone Fortschrittsüberwachung via GetSwProcessProgress().
3. Aktivierungs-Phase:
   • Activate() instruiert das Execution Management (EM) zur Umschaltung der Funktionsgruppen/Zustände oder zum Neustart der betroffenen Applikationen (A/B-Swap oder In-Place).
4. Validierungs- & Abschluss-Phase:
   • Nach erfolgreichem Selbsttest/Validierung: Finish() markiert den Zustand als permanent und bereinigt Altbestände.
   • Bei Fehlern/Verifikationsabbruch: Rollback() (Rückkehr zum vorherigen Stand) oder RevertProcessedSwPackages() (vor Aktivierung) stellen die Systemsicherheit wieder her.
   • Cancel() dient dem deterministischen Abbruch noch nicht aktivierter Operationen.

4. Normative Relevanz & Entwickler-Hinweise

• API- und Threading-Modell: Alle Servicemethoden werden über generierte ara::com-Proxies/Skeletons aufgerufen und geben ara::core::Future<...> zurück. Blockierende Aufrufe auf dem Consumer-Thread sind zu vermeiden.
• IAM-Konfiguration (Execution Manifest): Da sämtliche Members «aapAccessControlled» sind, muss der aufrufende Prozess in seinem Execution Manifest explizit autorisierte Access Control Lists (ACL) bzw. Grant-Definitionen für den Service PackageManagement modellieren. Nicht autorisierte Requests quittiert der Stack mit Sicherheitsfehlern (SecurityErrorDomain).
• Fehlerbehandlung: Methoden nutzen ara::core::Result und werfen UCM-spezifische Fehler (z. B. UcmErrorDomain::kInvalidPackageId, kProcessFailed, kInsufficientMemory).
• Zustandskonsistenz & Persistenz: Das CurrentStatus-Feld muss konsistent zum internen Key-Value-Storage des UCM persistiert werden, um Power-Loss während TransferData oder Activate fehlertolerant abzufangen.