Figure 9.120: Interfaces for SOVD data

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Schnittstellenspezifikation mit Komponentenannotationen.
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Functional Cluster Diagnostic Management (DM) in einer Daemon-basierten Implementierungsarchitektur (daemon-based).
• Technischer Zweck: Definition der nativen C++-Schnittstellen zur Modellierung, Serialisierung, Deserialisierung und dynamischen Handhabung hierarchischer Nutzdaten für SOVD (Service-Oriented Vehicle Diagnostics, ASAM SOVD / ISO 13170). Es entkoppelt die standardisierte Datenrepräsentation (JSON-analoge Strukturen: Primitive, Records/Maps, Arrays) zwischen der anwendenden Adaptive Application und dem ausführenden DM-Daemon.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Komponenten

• Adaptive Application (UML Component): Konsument der SOVD-Datenstrukturen im Prozesskontext der Anwendung.
• Diagnostic Management («aapFunctionalCluster», Ausprägung: daemon-based): AUTOSAR-Basissoftware-Cluster, der die konkrete Implementierung der Schnittstellen bereitstellt bzw. instanziiert und IPC/Routing übernimmt.

Schnittstellen & Datenstrukturen

1. DiagnosticSovdAbstractContentData («aapAPI, aapNativeInterface»):
   • Semantik: Typunabhängiger, abstrakter Knoten zur Repräsentation dynamischer SOVD-Ressourcen-Payloads (analoge Semantik zu JSON-DOM / Variant-Trees).
   • Fabrikmethoden (statisch, unterstrichen):
     • CreateContentElement()
     • CreateRecordContentElement(), CreateArrayContentElement()
     • CreatePrimitiveContentBool(), CreatePrimitiveContentDouble(), CreatePrimitiveContentSignedInt(), CreatePrimitiveContentUnsignedInt(), CreatePrimitiveContentString()
   • Typabfrage & Generische Inspektion:
     • GetType(), GetPrimitiveContentValueType(), HasContentElement(), HasError(), SetError()
   • Primitive Getter/Setter:
     • GetBool(), SetBool(), GetDouble(), SetDouble(), GetSignedInt(), SetSignedInt(), GetUnsignedInt(), SetUnsignedInt(), GetString(), SetString()
   • Array- / Sequenz-Operationen (STL-orientiert):
     • Begin(), End(), CBegin(), CEnd(), Size(), Capacity(), Reserve(), Empty(), Clear(), PushBack(), Add(), Remove(), Erase(), Find(), operator[](), GetArrayView()
   • Record- / Map-Operationen (Key-Value-Container):
     • RecordBegin(), RecordEnd(), RecordCBegin(), RecordCEnd(), RecordCount(), RecordCapacity(), RecordReserve(), RecordEmpty(), RecordRemoveAll(), GetRecordView()
2. DiagnosticSovdAbstractContentDataWithKey («aapAPI, aapNativeInterface»):
   • Semantik: Schlüssel-Wert-Paar-Kapselung zur Konstruktion benannter Felder innerhalb von Records/Objektstrukturen.
   • Methoden:
     • GetName(), SetName(): Zugriff auf den Key (Property-Identifier).
     • GetContent(), SetContent(): Assoziierter Content-Knoten (DiagnosticSovdAbstractContentData).

Beziehungen & Abhängigkeiten

• Realisierung (--▷): Diagnostic Management implementiert beide abstrakten Interfaces (DiagnosticSovdAbstractContentData und DiagnosticSovdAbstractContentDataWithKey).
• Nutzungsbeziehung («use»): Die Adaptive Application interagiert typisiert über die deklarierten Methoden der Interfaces mit den Payload-Datenstrukturen, ohne an systemspezifische IPC- oder Daemon-Details gebunden zu sein.

3. Dynamisches Verhalten & Sequenzablauf

• Lebenszyklus & Instanziierung:
  • Instanziierung erfolgt speicherschonend über statische Factory-Methoden (Create*), typischerweise polymorph auf einem Memory-Pool oder Arena-Allokator des DM-Laufzeitstacks.
• Schreibpfad (Provider / Application-to-Daemon):
  • Die Applikation baut hierarchische SOVD-Datenobjekte über Factory-Calls auf (CreateRecordContentElement, CreateArrayContentElement), füllt Primitive via Setter (Set*), mappt Key-Bindings über DiagnosticSovdAbstractContentDataWithKey und übergibt den DOM-Baum an den DM-Daemon.
• Lesepfad (Consumer / Daemon-to-Application):
  • Der DM-Daemon parst eingehende SOVD-HTTP/REST-Requests oder Diagnosedaten und übergibt der Applikation ein DiagnosticSovdAbstractContentData-Wurzelelement.
  • Die Applikation prüft den Typ via GetType(), nutzt Container-Views (GetRecordView(), GetArrayView()) oder iteriert direkt über STL-analoge Iteratoren (Begin(), End(), Indexoperator operator[]).
• Fehlerbehandlung:
  • Inband-Fehlersignalisierung über HasError() und SetError(), wodurch Parsing- oder Datenkonvertierungsfehler direkt am betroffenen Datenelement annotiert werden können.

4. Normative Relevanz & Entwickler-Hinweise

• Architektonischer Schnitt (Daemon-Architektur):
  • Da DM als Daemon realisiert ist, arbeiten die Interfaces im Applikationsprozess als Proxy-/Wrapper-Objekte. Speicher-Allokationen (insb. PushBack, Reserve, String-Zuweisungen) müssen auf deterministische Heap-Nutzung in sicherheitskritischen POSIX-Umgebungen geprüft werden.
• API-Vertrag:
  • Keine direkten Roh-JSON-Strings im API-Vertrag der Applikation; stattdessen typsichere, strukturierte Abstraktion (DiagnosticSovd*). Dies garantiert Portabilität und statische Typprüfung bei AUTOSAR-AP-Applikationen.
• Performance & Allokation:
  • Exzessives dynamisches Resizen vermeiden: Capacity(), Reserve(), RecordReserve() zwingend nutzen, um dynamische Reallokationen bei großen Diagnosedatensätzen (z. B. Freeze Frames, Logging-Snapshots) zu minimieren.
• View-Semantik:
  • GetArrayView() und GetRecordView() erzeugen typischerweise Zero-Copy-Read-Only-Views (ara::core::Span / std::string_view ähnlich) auf bestehende Puffer; Gültigkeit der Views ist strikt an den Lebenszyklus des zugrunde liegenden Content-Data-Objekts gebunden.