Figure 9.1: UCM composite structure - Transfer related

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Schnittstellen- und Datentyp-Strukturdiagramm (ara::com Service-Interface-Ausschnitt).
• Funktionale Einordnung: Adaptive Platform – Update and Configuration Management (UCM). Das Diagramm spezifiziert die Transfer-Teilmenge des Service-Interfaces PackageManagement (SWS_UCM_00131) zum blockbasierten Streaming von Software-Paketen (Software Package / Software Cluster) von einem UCM-Client (z. B. OTA-Client, Diagnostic Updater) in den flüchtigen bzw. persistenten Speicher des UCM.

2. Komponenten, Entitäten & Schnittstellen

• «interface» PackageManagement (Transfer): Definiert die nachrichtenorientierten RPC-Methoden zur Abwicklung des Datentransfers:
  • TransferStart(size: uint64, TransferIdType*, unsigned int*): void (SWS_UCM_00044): Initiert die Übertragungssitzung. Nimmt die Gesamtgröße des Pakets in Bytes (size) entgegen und liefert als Ausgabeparameter eine eindeutige Session-ID (TransferIdType) sowie die maximale Blockgröße (blockSize in Bytes) zurück.
  • TransferData(TransferIdType, ByteVectorType, uint32): void (SWS_UCM_00071, SWS_UCM_00395): Überträgt ein sequenzielles Datenfragment. Parameter: Transfer-Identifikator, Payload-Chunk (ByteVectorType) und fortlaufender Zähler (blockCounter ab 1).
  • TransferExit(TransferIdType): void (SWS_UCM_00396): Schließt den Übertragungsvorgang formal ab und triggert die Übergabe an die interne Integritäts- und Signaturprüfung.
• «primitive» TransferIdType (SWS_UCM_00031): Abstrakter primitiver Datentyp zur Sitzungsidentifikation; typisiert in C++ üblicherweise als 16-Byte-Array (std::array<uint8_t, 16>) bzw. UUID nach RFC 4122.
• «primitive» ByteVectorType (SWS_UCM_00032): Dynamischer Byte-Puffer für die Payload-Chunks; abgebildet auf ara::core::Vector<uint8_t>.
• Beziehungen: Strukturkopplung: Das Interface PackageManagement bindet TransferIdType als Sitzungsanker über alle drei Methoden hinweg und nutzt ByteVectorType als In-Parameter für die Payload in TransferData.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung (TransferStart):
   • Client sendet erwartete Paketgröße (uint64).
   • UCM validiert den verfügbaren Speicherplatz (Flash/RAM) und allokiert einen Transfer-Kontext.
   • UCM generiert und retourniert die TransferIdType sowie das verhandelte blockSize-Limit (Chunk-Größe).
2. Streaming-Schleife (TransferData):
   • Client sendet Payload-Chunks konform zur verhandelten blockSize.
   • Strikte Inkrementprüfung: UCM validiert blockCounter auf lückenlose Monotonie (Beginn bei 1). Bei Sequenzfehlern, ungültiger Session-ID oder Größenüberschreitung bricht die Methode mit spezifischen UcmErrorDomain-Fehlern ab (z. B. IncorrectBlockCounter, InvalidTransferId, SizeMismatch).
   • Synchrone oder asynchrone Rückmeldung via ara::core::Future<void> / ara::core::Result<void>.
3. Abschluss (TransferExit):
   • Client signalisiert Übertragungsende via TransferIdType.
   • UCM verifiziert, ob die kumulierte Bytezahl exakt der in TransferStart deklarierten Gesamtgröße entspricht.
   • Nach erfolgreichem Exit wechselt das Paket intern vom Zustand Transferring in den Zustand Transferred (bereit für ProcessPackage).

4. Normative Relevanz & Entwickler-Hinweise

• ara::com Service-Binding: Methoden werden über das SOME/IP- oder IPC-Binding als Request/Response-Pattern exponiert. Da PackageManagement potenziell megabyte- oder gigabyteweise Daten verarbeitet, müssen Entwickler SOME/IP-Transport-Protocol-Eigenschaften (TP) oder Shared-Memory-Transfers in den Deployment-Manifesten (.arxml) korrekt parametrieren.
• Speicher- und Pufferverwaltung: Die von TransferStart zurückgegebene blockSize ist bindend für den Client. Ein Senden größerer ByteVectorType-Instanzen führt zur direkten Ablehnung durch den UCM.
• Fehlerbehandlung: Methoden liefern keinen rohen void-Rückgabewert auf C++-Ebene, sondern ara::core::Future<PackageManagement::TransferDataOutput> bzw. ara::core::Result<void>. Relevante Error-Codes der UCM-Fehlerdomäne (z. B. InsufficientMemory, PackageInconsistent) müssen im Client zwingend abgefangen und verarbeitet werden.
• Parallelität: Mehrere parallele Transfers verschiedener Pakete werden über distinkte TransferIdType-Instanzen differenziert; der UCM-Stack limitiert die maximale Anzahl gleichzeitiger Transfers über Implementierungs- und Konfigurationsparameter.