Figure 9.119: Interfaces for SOVD operations

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Schnittstellen- und Architekturdiagramm (Komponenten- und Realisierungsbeziehungen) gemäß AUTOSAR_AP_EXP_SWArchitecture (Release R25-11, Kapitel Diagnostic Management, Figure 9.119).
• Technischer Zweck & Einordnung: Spezifikation der C++-Schnittstellenarchitektur zur Integration von SOVD (Service-Oriented Vehicle Diagnostics, ASAM SOVD / RESTful Diagnostics) in der AUTOSAR Adaptive Platform. Das Diagramm definiert den Entkopplungsmechanismus zwischen der daemon-basierten Plattform-Infrastruktur (Diagnostic Management, DM) und den eigentlichen Applikations-Funktionen (Adaptive Application), welche SOVD-Ressourcen (Inhalte und Operationen) bereitstellen.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Komponenten

• Adaptive Application (UML-Komponente): Applikationsprozess im POSIX-User-Space, der Diagnosedaten und Diagnose-Routinen implementiert und via ara::diag anbietet.
• «aapFunctionalCluster» Diagnostic Management (daemon-based) (UML-Komponente): Zentraler System-Daemon der Adaptive Platform. Er terminiert externe Diagnoseprotokolle (SOVD über HTTP/REST/WebSockets bzw. UDS über DoIP) und routet Anforderungen über plattforminterne IPC an die zuständigen Applikationen.

Schnittstellen & Klassifikation

• «aapAPI, aapPortInterface» GenericDiagnosticSovdOperation:
  • Metamodell-basiertes Port-Interface (ara::diag::GenericDiagnosticSovdOperation, [SWS_DM_02203]).
  • Ermöglicht die Bereitstellung generischer SOVD-Operationen (Routinen, Stellgliedtests, komplexe Aktionen).
  • Methoden: + Offer(), + StartExecution(), + StopOffer().
• «aapAPI, aapNativeInterface» SovdOperationExecution:
  • Reines C++ Native Interface (ara::diag::SovdOperationExecution, [SWS_DM_02197]), kein separates Metamodell-Port-Mapping.
  • Repräsentiert das Lifecycle-Handle für die Ausführung einer asynchronen Operation.
  • Methoden (geschützt/pure virtual): # GetStatus(), # Terminate().
• «aapAPI, aapPortInterface» GenericDiagnosticSovdContent:
  • Metamodell-basiertes Port-Interface (ara::diag::GenericDiagnosticSovdContent, [SWS_DM_02187]).
  • Erlaubt den standardisierten Lese- und Schreibzugriff auf parametrisierte SOVD-Ressourcendaten (analytische Parameter, Statuswerte, Konfigurationsdaten).
  • Methoden: + Offer(), + Read(), + StopOffer(), + Write().

Beziehungen & Abhängigkeiten

• Interface Realization (--|>): Das funktionale Cluster Diagnostic Management realisiert die Infrastruktur und Dispatcher-Logik der Interfaces bzw. stellt die Basisklassen im SDK bereit.
• Usage Dependency («use»): Die Adaptive Application bindet die Schnittstellen ein, leitet von den abstrakten Basisklassen ab (Implementierung der reinen virtuellen Callback-Methoden) und steuert den Lebenszyklus über Service-Offerings.

3. Dynamisches Verhalten & Sequenzablauf

A. Registrierung & Lifecycle (Offer / StopOffer)

1. Die Adaptive Application instanziiert GenericDiagnosticSovdOperation oder GenericDiagnosticSovdContent unter Übergabe eines ara::core::InstanceSpecifier und des Concurrency-Typs (kSynchronous / kAsynchronous).
2. Aufruf von Offer() registriert den Handler beim DM-Daemon via IPC. Erst nach erfolgreichem Return (ara::core::Result<void>) routet der DM eingehende SOVD-Requests an diese Instanz.
3. Vor Terminierung der Applikation deregistriert StopOffer() den Endpunkt beim Daemon.

B. Content-Zugriff (Read / Write)

1. Ein externer SOVD-Client sendet HTTP GET / PUT an den SOVD-Server des DM.
2. Der DM deserialisiert die URI/Payload und ruft an der Applikation asynchron Read() bzw. Write() auf.
3. Die Applikation liefert die Daten asynchron über ara::core::Future<DiagnosticSovdContentData> zurück.

C. Operationsausführung & Asynchrones Monitoring

1. Eingehender SOVD-Request zur Ausführung einer Operation triggert StartExecution(...) in der Applikation.
2. Synchron: Die Operation schließt sofort ab und liefert StartSynchronousExecutionResponse.
3. Asynchron: Die Operation dauert an; die Applikation meldet StartAsynchronousExecutionResponse zurück und bindet die Instanz von SovdOperationExecution.
4. Der DM pollt während der Ausführung zyklisch via # GetStatus(...) den Fortschritt oder bricht die Operation bei Verbindungsverlust/Client-Cancel über # Terminate(...) ab.

4. Normative Relevanz & Entwickler-Hinweise

• ARXML-Modellierung vs. Native Implementierung:
  • GenericDiagnosticSovdOperation und GenericDiagnosticSovdContent müssen im AUTOSAR-Modell als DiagnosticPortInterface deklariert und im Execution Manifest über Port-Prototypes an den jeweiligen InstanceSpecifier gebunden werden.
  • SovdOperationExecution wird nicht im Metamodell modelliert, sondern applikationsseitig als C++-Klasse zur Steuerung der asynchronen Operationsinstanz implementiert.
• Kooperatives Task-Cancelling:
  • Den Callbacks (Read, Write, StartExecution, GetStatus, Terminate) wird ein ara::diag::CancellationHandler übergeben. Applikationsentwickler müssen diesen in rechenintensiven oder blockierenden Schleifen abfragen, um Deadlocks bei Timeout/Client-Abbruch zu verhindern.
• Concurrency & Threading:
  • Abhängig vom übergebenen ConcurrencyType muss die Applikation reentrant implementiert sein, wenn parallele SOVD-Requests auf denselben Content- oder Operations-Handler konfiguriert sind.
• Fehlerbehandlung:
  • Keine C++ Exceptions über ABI-Grenzen: Alle Rückgaben basieren auf ara::core::Result<...> / ara::core::Future<...> unter Verwendung der DiagSovdErrorDomain (Fehlercodes für ungültige Parameter, Zugriffsverweigerung oder Ausführungsfehler gemäß SOVD-Spezifikation).