Figure 9.73: General Interfaces of Update and Configuration Management

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm mit Service-Interface-Spezifikation (AUTOSAR Adaptive Platform Architekturmodellierung).
• Technischer Zweck: Definition der primären Dienstschnittstelle (ara::com) des funktionalen Clusters Update and Configuration Management (UCM) zur Aktualisierung, Deinstallation und Inspektion von Software-Clustern (SoftwareCluster) und Software-Paketen (SoftwarePackage) auf einer Adaptive-Plattform-Instanz.
• Funktionale Einordnung: UCM ist als systemweiter Daemon (daemon-based) realisiert. Die Schnittstelle kapselt den atomaren, transaktionalen Update-Prozess (A/B-Partitionierung, Rollback, Manifest-Prüfung) und stellt ihn sowohl fahrzeuginternen Over-the-Air-Clients (Adaptive Application) als auch Werkstatt- bzw. Diagnose-Testern (Diagnostic Application via UDS/DoIP über das Diagnostic Management) bereit.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Komponenten

• «aapFunctionalCluster» Update and Configuration Management:
  • Ausprägung: Plattform-Kernkomponente als Daemon-basierter Dienstleister (daemon-based).
  • Stellt über einen «aapProvidedPort» die Service-Instanz bereit.
• Adaptive Application:
  • Generischer Konsumenten-Container (z. B. OTA-Update-Orchestrator oder Cloud-Gateway).
  • Bindung via «use» über einen «aapRequiredPort».
• Diagnostic Application:
  • Spezialisierte Anwendung innerhalb des Applikationskontexts zur Vermittlung zwischen externen Diagnoseprotokollen (z. B. ISO 14229-1 / UDS Service 0x34, 0x36, 0x37) und der UCM-Engine.
  • Bindung via «use» über einen separaten «aapRequiredPort».

Service-Schnittstelle: «aapAPI, aapAraComServiceInterface» PackageManagement

Vollständig typisiertes ara::com-Service-Interface unter IAM-Zugriffskontrolle («aapAccessControlled»).

• Service-Fields («aapServiceField»):
  • + CurrentStatus: Repräsentiert den aktuellen Gesamtzustand des UCM (z. B. kIdle, kReady, kProcessing, kActivating). Bietet Getter-, Setter- (intern) und Notifier-Semantik für Zustandsänderungen.
• Service-Methoden («aapServiceMethod»):
  • Transfer-Phase:
    • TransferStart(): Initialisiert die Übertragung eines neuen Software-Pakets; liefert einen Transfer-Handle (TransferIdType).
    • TransferData(): Blockweiser Payload-Streaming-Transfer (Binary Stream).
    • TransferExit(): Schließt die Übertragung ab, verifiziert Prüfsummen/Signaturen.
    • DeleteTransfer(): Verwirft einen begonnenen/abgeschlossenen Transfer vor der Verarbeitung.
  • Verarbeitungs- & Vorbereitungsphase:
    • ProcessSwPackage(): Startet das Entpacken, Dekomprimieren, Integritätsprüfungen und Staging im Ziel-Dateisystem.
    • GetSwProcessProgress(): Polling des asynchronen Verarbeitungsfortschritts (0–100 %).
    • RevertProcessedSwPackages(): Rückabwicklung bereits prozessierter, aber noch nicht aktivierter Pakete.
  • Aktivierungs- & Abschlussphase:
    • Activate(): Triggert die Aktivierung (z. B. Restart von Prozessen via Execution Management (EM), State-Wechsel oder OS-Reboot bei A/B-Partitionen).
    • Rollback(): Erzwingt Rückkehr zum vorherigen stabilen Software-Stand bei Validierungsfehlern nach der Aktivierung.
    • Finish(): Schließt die Update-Transaktion erfolgreich ab und konsolidiert den Persistenzstatus.
    • Cancel(): Bricht den aktiven Vorgang kontrolliert ab.
  • Inspektions- & Inventar-Methoden:
    • GetId(): Liefert die eindeutige UCM-Instanzkennung.
    • GetHistory(): Ruft Update-Historie und Protokolleinträge ab.
    • GetSwPackages(): Liste der aktuell im Transfer/Staging befindlichen Software-Pakete.
    • GetSwClusterInfo(): Abfrage installierter Software-Cluster und deren Versionen.
    • GetSwClusterChangeInfo(): Delta-Informationen geplanter Änderungen.
    • GetSwClusterManifestInfo(): Auslesen des Software-Cluster-Manifests zur Laufzeit.

3. Dynamisches Verhalten & Sequenzablauf

Der Methodenaufruf folgt einem strikten deterministischen Zustandsmodell:

[Idle] ──> TransferStart() ──> TransferData()* ──> TransferExit()
                                                        │
[Idle] <── DeleteTransfer() <───────────────────────────┤
                                                        ▼
                                               ProcessSwPackage() <──> GetSwProcessProgress()
                                                        │
[Idle] <── RevertProcessedSwPackages() <────────────────┤
                                                        ▼
                                                    Activate()
                                                     │      │
                                            (Erfolg) │      │ (Fehlschlag)
                                                     ▼      ▼
                                                 Finish() Rollback()
                                                     │      │
                                                     ▼      ▼
                                                  [Idle]  [Idle]

1. Vorbereitung (Transfer): Client ruft TransferStart() auf, streamt Datenpakete sequenziell via TransferData() und schließt mit TransferExit() ab. Fehlerhafte Transfers werden per DeleteTransfer() bereinigt.
2. Asynchrone Verarbeitung (Staging): Client initiiert ProcessSwPackage(). Da dies I/O- und rechenintensiv ist, arbeitet UCM asynchron. Der Client überwacht das Feld CurrentStatus bzw. pollt GetSwProcessProgress().
3. Aktivierung: Aufruf von Activate(). UCM koordiniert mit dem Execution Management (EM) das Herunterfahren alter Applikationsinstanzen und das Starten neuer Versionen.
4. Finalisierung / Recovery:
   • Bei erfolgreicher Selbstprüfung (Sanity Check / Health Monitoring): Aufruf von Finish().
   • Bei Boot-/Startfehlern oder Timeout: Auslösung von Rollback() zur Wiederherstellung des vorigen Systemzustands.

4. Normative Relevanz & Entwickler-Hinweise

• IAM (Identity and Access Management): Alle Operationen und das Feld tragen das Stereotyp «aapAccessControlled». Applikationsentwickler müssen im Execution-Manifest (AdaptiveApplicationManifest) explizite Zugriffsrechte (SecurityEventDefinition, ServiceInterfaceDeployment) deklarieren; nicht autorisierte Aufrufe werden vom ara::com-Binding bzw. IAM mit ara::core::ErrorCode abgewiesen.
• IPC- und Performance-Einschränkungen: TransferData() transportiert Binärdaten über Inter-Process Communication (IPC). Zur Vermeidung von Pufferüberläufen und Deadlocks müssen Entwickler die in der Plattform definierte Blockgröße (chunk size) deterministisch einhalten.
• Zustandsbehafteter UCM-Lebenszyklus: Methodenaufrufe außerhalb der zulässigen Zustände (z. B. Activate() vor erfolgreichem ProcessSwPackage()) schlagen fehl und liefern definierte UCM-Fehlercodes (UcmErrc::kInvalidPackageManifest, UcmErrc::kNotAbleToProcess etc.).
• Diagnose-Integration: Wird eine Diagnostic Application implementiert, fungiert diese als Adapter: UDS RoutineControl (31) bzw. RequestDownload (34) / TransferData ($36) müssen 1:1 auf das PackageManagement-Interface gemappt werden; die atomare Transaktionsverantwortung verbleibt zwingend im UCM-Daemon.