Figure 9.1: UCM composite structure

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Service-Strukturdiagramm (Composite Structure nach AUTOSAR Adaptive Platform Schnittstellendefinition).
• Technischer Zweck & Einordnung:
  • Spezifikation des primären ara::com-Service-Interfaces PackageManagement (SWS_UCM_00131) des Functional Clusters UCM (Update and Configuration Management) gemäß AUTOSAR Adaptive Platform (R23-11).
  • Formalisierung der Datenstrukturen, Typdefinitionen und Enums für OTA-Updates (Over-the-Air), Flashen und Lifecycle-Management von Software-Clustern (SwCluster) auf einer Adaptive Machine.
  • UCM agiert als Server-Instanz («service» UCM), die von Update-Clients (z. B. OTA-Client-Applikation oder UDS/DoIP-Diagnose-Gateway) über standardisierte IPC/SOME/IP-Bindings konsumiert wird.

2. Komponenten, Entitäten & Schnittstellen

Service-Schnittstelle

• «service» UCM / Port PackageManagement: Stellt die Service-Schnittstelle «interface» PackageManagement (SWS_UCM_00131) bereit.
• Attribute / Fields:
  • CurrentStatus: PackageManagerStatusType (Notifizierender Status der UCM-Engine).
• Methoden:
  • Transfer-Pipeline: TransferStart, TransferData, TransferExit, Cancel, DeleteTransfer.
  • Verarbeitung & Deployment: ProcessSwPackage, RevertProcessedSwPackages, Activate, Finish, Rollback.
  • Status- & Metadaten-Abfrage: GetId, GetSwPackages, GetSwClusterInfo, GetSwClustersChangeInfo, GetSwClusterManifestInfo, GetHistory, GetSwProcessProgress.

Primitiv- und Basis-Datentypen

• «primitive» TransferIdType (SWS_UCM_00031): Eindeutige Session-/Transfer-Kennung (UUID/Token-Array).
• «primitive» ByteVectorType (SWS_UCM_00032): Dynamischer Byte-Puffer für Payload-Blöcke.
• «dataType» SwNameType (SWS_UCM_00071): Eindeutiger Bezeichner des Software-Clusters.
• «dataType» StrongRevisionLabelString (SWS_UCM_00175): Semantischer Versions-String (z. B. SemVer 2.0).
• «primitive» UCMIdentifierType (SWS_UCM_00173): Identifikator der UCM-Instanz.
• «dataType» UCMIdentifierAndVersionType (SWS_UCM_00309): Tupel aus id und UCM-version.

Aggregationen & Datenstrukturen

• Software-Cluster-Zustand:
  • SwClusterInfoVectorType (SWS_UCM_00079) aggregiert 1..n SwClusterInfoType (SWS_UCM_00078: name, size, version, state: SwClusterStateType).
  • «enumeration» SwClusterStateType (SWS_UCM_00077): kPresent (0x00), kAdded (0x01), kUpdating (0x02), kRemoved (0x03).
• Package-Übertragungsstatus:
  • SwPackageInfoVectorType (SWS_UCM_00040) aggregiert 1..n SwPackageInfoType (SWS_UCM_00039: consecutiveBlocksReceived, consecutiveBytesReceived, name, transferId, version, state: SwPackageStateType).
  • «enumeration» SwPackageStateType (SWS_UCM_00038): kTransferring (0x00), kTransfered (0x01), kProcessing (0x02), kProcessed (0x03), kProcessingStream (0x04).
• Historie & Logging:
  • HistoryVectorType (SWS_UCM_00135) aggregiert 1..n HistoryType (SWS_UCM_00134: action: ActionType, failureError, name, resolution: ResultType, time, version).
  • «enumeration» ActionType (SWS_UCM_00132): kUpdate (0x00), kInstall (0x01), kRemove (0x02).
  • «enumeration» ResultType (SWS_UCM_00133): kActivated (0x00), kActivatedAndRolledBack (0x01), kVerificationFailed (0x02).
• Manifest- & Abhängigkeitsmodell:
  • SwClusterManifestInfoType (SWS_UCM_00312): Metadaten (license, releaseNotes, typeApproval, name, version, dependencyModel: DependencyVectorType).
  • DependencyVectorType (SWS_UCM_00313): Geordnete Liste {ordered} von 1..n DependencyType (SWS_UCM_00314).
  • DependencyType referenziert:
    • DependencyRoleType (SWS_UCM_00318): dependsOn (0x00), conflictsTo (0x01).
    • LogicalOperationType (SWS_UCM_00317): kLogicalAnd (0x00), kLogicalOr (0x01).
    • DependencyCompareConditionType (SWS_UCM_00315): considerBuildNumber: bool, dependencyOperator: DependencyOperatorType, targetSwCluster: SwNameVersionType.
    • DependencyOperatorType (SWS_UCM_00316): Relationale Operatoren (kGreaterThan, kEqual, kLessThan, etc.).
    • SwNameVersionType (SWS_UCM_00176): Verbund aus SwNameType und StrongRevisionLabelString.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm bildet die statischen Schnittstellen für folgende zustandsgesteuerte Update-Phasen ab:

[kIdle] ──> TransferStart() ──> [kReady] ──> TransferData() / TransferExit()
                                                  │
[kProcessing] <── ProcessSwPackage() <────────────┘
      │
      ├── (Fehler) ──> RevertProcessedSwPackages() / Cancel() ──> [kIdle]
      │
      └── (Erfolg) ──> Activate() ──> [kActivating] ──> [kActivated]
                                                              │
               [kRolledBack] <── Rollback() <── [kRollingBack]┤
                                                              │
               [kIdle] <── Finish() <── [kCleaningUp] <───────┘

1. Transferphase (asynchron/blockweise):
   • Aufruf von TransferStart(size): UCM allokiert Ressourcen, wechselt CurrentStatus auf kReady, liefert TransferId und die maximal erlaubte Blockgröße (unsigned int*).
   • Iteratives TransferData(TransferId, ByteVector, blockCounter): Streaming der Binärdaten. Paketstatus wechselt auf kTransferring.
   • TransferExit(TransferId): Schließt Datenübertragung ab; Paketstatus wechselt auf kTransfered.
2. Verarbeitungsphase (Validierung & Staging):
   • Aufruf von ProcessSwPackage(TransferId): UCM wechselt zu kProcessing. Integritäts- und Signaturprüfungen (Crypto), Dekomprimierung und Evaluierung des DependencyVectorType (Konflikte, Abhängigkeiten via DependencyCompareConditionType). Paket geht in kProcessed.
3. Aktivierungs- & Verifikationsphase:
   • Activate() versetzt UCM in kActivating bzw. kVerifying. UCM interagiert mit dem Execution Management (EM), um Prozesse der betroffenen SwCluster zu stoppen, neue Binaries/Konfigurationen einzublenden (A/B-Partition-Switch oder In-Place-Update) und neu zu starten.
   • Erfolgreicher Abschluss führt zu Status kActivated.
4. Konsolidierung oder Abbruch:
   • Commit-Pfad: Finish() triggert Bereinigung temporärer Artefakte (kCleaningUp), persistiert den Vorgang in HistoryVectorType und kehrt nach kIdle zurück.
   • Fehlerpfad: Bei Fehlern vor der Aktivierung erfolgt RevertProcessedSwPackages() oder Cancel(). Nach fehlgeschlagener Aktivierung/Selbsttest wird via Rollback() der vorherige konsistente Cluster-Zustand restauriert (kRollingBack → kRolledBack).

4. Normative Relevanz & Entwickler-Hinweise

• Service-Binding & IPC-Serialisierung:
  • Datentypen wie ByteVectorType und SwClusterInfoVectorType erfordern optimierte ara::com-Serialisierer (z. B. Zero-Copy-Mechanismen im Shm-Binding für große Blöcke in TransferData), um Paging-Latenzen im Kernel zu verhindern.
• Transaktionale Integrität & Abhängigkeitsprüfung:
  • Das UCM-Core-Modul muss vor Activate() zwingend alle DependencyType-Prädikate normativ auswerten. Zirkuläre oder unvollständige Abhängigkeiten (conflictsTo / dependsOn) müssen die Ausführung vor Modifikation des Root-Filesystems mit einem definierten Fehlercode terminieren.
• Reentrancy & Nebenläufigkeit:
  • PackageManagerStatusType definiert ein striktes Single-Session-Modell für schreibende Operationen: Befindet sich der UCM in kProcessing, kActivating oder kRollingBack, müssen konkurrierende TransferStart- oder Modifikationsaufrufe abgewiesen werden (UCMErrorDomain::Suspended bzw. Busy).
• Fehlerprotokollierung & Nachvollziehbarkeit:
  • Jeder Rollback- oder Finish-Zyklus verpflichtet den Stack zur lückenlosen Protokollierung in HistoryType (time, failureError, resolution). Entwickler müssen sicherstellen, dass dieser Speicherbereich in einem ausfallsicheren, nicht-flüchtigen Speicher (NVRAM/Flash) abgelegt wird, um Diagnosestandards nach ISO 14229 / ISO 22900 zu genügen.