Figure 10.20: Use case Transfer Vehicle Data

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Use-Case-Diagramm (Anwendungsfalldiagramm) unter Verwendung des AUTOSAR Adaptive Platform (AP) Metamodell-Profils mit den Stereotypen «aapUseCase», «aapFunctionalCluster», «aapTriggers» und «aapParticipates».
• Technischer Zweck & Einordnung:
  • Spezifiziert den Anwendungsfall Transfer Vehicle Data innerhalb der Subdomäne Vehicle Update and Configuration Management (VUCM / UCM Master) der AUTOSAR Adaptive Platform (R24-11).
  • Dient der standardisierten Einbringung von fahrzeugweiten Software- und Konfigurationsdaten (Software Packages, Vehicle Packages, Kampagnendaten) in das Zielfahrzeug.
  • Grenzt externe/anwendungsbezogene Akteure (Trigger/Teilnehmer) von den intern beteiligten funktionalen Basis-Clustern («aapFunctionalCluster») der Adaptive Platform ab.

2. Komponenten, Entitäten & Schnittstellen

• Akteure (from Actors):
  • OTA Client: Extern angebundene oder plattforminterne Applikation zur drahtlosen Einbringung von Update-Paketen über Backend-Verbindungen (Telematik).
  • Diagnostic Application: Diagnosetool bzw. On-Board-Diagnose-Applikation (z. B. UDS-basierte Dienste via DoIP gemäß ISO 13400 / ISO 14229).
  • Flashing Adapter: Hardwarenaher/stationärer Programmieradapter (z. B. Werkstatt-Tester oder Bandende-Flash-Interface).
• Use Case & Subsystem:
  • Vehicle Update and Configuration Management: Umfassende Systemgrenze/Komponente für das fahrzeugweite Update- und Konfigurationsmanagement.
  • «aapUseCase» Transfer Vehicle Data: Zentraler Service-Use-Case zur Entgegennahme, Pufferung und Validierung eingehender Fahrzeugdatenpakete.
• Funktionale Cluster («aapFunctionalCluster»):
  • Update and Configuration Management daemon-based (UCM Daemon): Zentraler Hintergrunddienst zur Entgegennahme und orchestrationalen Vorbereitung der Softwarepakete auf Platform-Ebene.
  • Persistency (ara::per): Stellt nicht-flüchtigen Speicher (File- und Key-Value-Storage) für die persistente Ablage der empfangenen Pakete und Transaktionszustände bereit.
  • Log and Trace (ara::log): Protokolliert Statusübergänge, Übertragungsfortschritte, Audit-Logs und Fehlerereignisse (Anbindung an DLT).
• Beziehungen & Stereotypen:
  • «aapTriggers»: Gerichtete Assoziation für auslösende Initiatoren. Sowohl der OTA Client als auch die Diagnostic Application besitzen die Auslöser-Rolle auf den Use Case Transfer Vehicle Data.
  • «aapParticipates»: Assoziation für teilnehmende/unterstützende Entitäten:
    • Flashing Adapter (unterstützt den physikalischen/protokollarischen Transferpfad).
    • Update and Configuration Management daemon-based (verarbeitet die Datenströme).
    • Persistency (speichert die Nutzlast).
    • Log and Trace (schreibt Diagnose- und Systemlogs).

3. Dynamisches Verhalten & Sequenzablauf

1. Initiierung (Trigger):
   • Ein Übertragungsvorgang wird asynchron entweder über den OTA Client (Remote-Kampagne) oder die Diagnostic Application (Tester-Initiiert via Diagnostic Management / RoutineControl) angestoßen («aapTriggers»).
2. Datenstrom-Verarbeitung:
   • Der Update and Configuration Management daemon-based öffnet eine Transfersitzung (z. B. TransferVehiclePackage bzw. TransferStart).
   • Nutzdaten werden sequenziell über den Flashing Adapter oder direkte Netzwerkkanäle gestreamt und in Blöcken empfangen.
3. Persistierung & Statustracking:
   • Eintreffende Datenblöcke werden parallel via ara::per in dedizierten, transaktionssicheren Partitionen/Dateibereichen abgelegt.
   • Jeder Blocktransfer sowie Zwischen-Prüfsummen werden synchron über ara::log für Audit-Zwecke aufgezeichnet.
4. Validierung & Abschluss:
   • Nach vollständigem Transfer (TransferExit) validiert der UCM-Daemon Signaturen und Integrität (Hash-Verifikation).
   • Bei Prüfsummenfehlern, Quota-Überschreitung in Persistency oder Kommunikationsabbruch erfolgt ein definierter Rollback des temporären Datenbestands mit Fehlereintrag über Log and Trace.

4. Normative Relevanz & Entwickler-Hinweise

• UCM-Dienst-Architektur:
  • Der UCM-Cluster muss zwingend als Daemon (daemon-based) im Execution Management (ara::exec) instanziiert sein, um unabhängig vom Lebenszyklus einzelner User-Applikationen kontinuierliche Übertragungsströme verwalten zu können.
• Speicher- und Persistenzdimensionierung (ara::per):
  • Für den Transfer vollständiger Vehicle Packages müssen in den Deployment-Manifesten hinreichende Speicher-Quotas für die Persistency-Ports des UCM-Daemons reserviert werden (Berücksichtigung von A/B-Partitionen oder Staging-Dateisystemen).
• Entkopplung der Ingestion-Kanäle:
  • OTA- und Diagnosepfade greifen auf dieselbe Core-Logik des UCM zu. Applikationsentwickler dürfen keine proprietären Flashing-Mechanismen am UCM vorbei implementieren; Diagnosetreiber und OTA-Clients dienen rein als Trigger-/Transportadapter.
• Lebenszyklus-Semantik:
  • Der Use Case umfasst ausschließlich den Schritt Transfer (Zustand: TRANSFERRING → TRANSFERRED). Die nachgelagerten Phasen Process, Activate und ggf. Rollback sind separate Anwendungsfälle des UCM-Zustandsautomaten.