Figure 9.122: Interfaces for SOVD record data

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Schnittstellendiagramm (AUTOSAR Adaptive Platform Architecture Modeling).
• Technischer Zweck: Spezifikation der C++-Native-APIs (ara::diag) zur typsicheren und strukturierten Handhabung von SOVD-Record-Daten (Service-Oriented Vehicle Diagnostics gemäß ASAM SOVD / ISO 22986).
• Funktionale Einordnung: Verortet im Functional Cluster Diagnostic Management (DM) der AUTOSAR Adaptive Platform (Dokument AUTOSAR_AP_EXP_SWArchitecture, Release R25-11). Es entkoppelt die speicher- und IPC-technische Repräsentation diagnostischer Record-Daten im daemon-basierten Diagnostic Management von der verarbeitenden Adaptive Application über View- und Iterator-Abstraktionen (Zero-Copy- bzw. Proxy-Zugriff auf hierarchische SOVD-Payloads).

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• Adaptive Application: Konsumierende Anwendungs-Entität (Prozess/Instanz im User Space).
• Diagnostic Management: «aapFunctionalCluster» (Ausprägung: daemon-based). Backend-Instanz des Diagnose-Stacks zur Koordination von Diagnosesitzungen, Persistenz, Transportprotokollen und Datenbereitstellung.
• DiagnosticSovdRecordContentElementDataConstView: «aapAPI, aapNativeInterface»
  • Zweck: Read-Only-Sicht auf SOVD-Record-Datenelemente.
  • Methoden: Begin(), Capacity(), CBegin(), CEnd(), Empty(), End(), Find(), HasContentElement(), HasError(), operator[](), Size().
• DiagnosticSovdRecordContentElementDataView: «aapAPI, aapNativeInterface»
  • Zweck: Mutable Sicht auf SOVD-Record-Datenelemente (Schreib- und Modifikationszugriff).
  • Methoden: Add(), Begin(), Capacity(), CBegin(), CEnd(), Clear(), Empty(), End(), Erase(), Find(), HasContentElement(), HasError(), operator[](), Remove(), Reserve(), SetError(), Size().
• DiagnosticSovdRecordContentElementDataConstIterator: «aapAPI, aapNativeInterface»
  • Zweck: Konstanter Vorwärts-/Bidirektional-Iterator für Record-Elemente.
  • Methoden: operator->(), operator!=(), operator*(), operator++(), operator==().
• DiagnosticSovdRecordContentElementDataIterator: «aapAPI, aapNativeInterface»
  • Zweck: Modifizierbarer Iterator für Record-Elemente.
  • Methoden: operator->(), operator!=(), operator*(), operator++(), operator==().

Beziehungen & Abhängigkeiten

• Realisierung («realize»): Der Functional Cluster Diagnostic Management realisiert die Schnittstellen DiagnosticSovdRecordContentElementDataConstView und DiagnosticSovdRecordContentElementDataView.
• Iterator-Kopplung / Fabrizierung: DiagnosticSovdRecordContentElementDataConstView bindet DiagnosticSovdRecordContentElementDataConstIterator ein; DiagnosticSovdRecordContentElementDataView bindet DiagnosticSovdRecordContentElementDataIterator ein (bereitgestellt über Begin(), End(), CBegin(), CEnd()).
• Nutzung («use»): Die Adaptive Application greift über gerichtete Abhängigkeiten synchron auf alle vier Interfaces (ConstView, View, ConstIterator, Iterator) zu.

3. Dynamisches Verhalten & Sequenzablauf

1. Akquise / Bereitstellung des Record-Views:
   • Die Adaptive Application fordert im Rahmen eines SOVD-Lese- oder Schreibauftrags (z. B. via SOVD-Gateway oder interner Diagnose-Routine) Record-Inhalte vom DM-Daemon an.
   • Der DM-Stack liefert je nach Kontext eine Instanz von DiagnosticSovdRecordContentElementDataConstView (Read-Operations) oder DiagnosticSovdRecordContentElementDataView (Write/Update-Operations).
2. Navigation & Traversierung:
   • Elementabfrage synchron via wahlfreiem Indexzugriff (operator[](size_t)) oder STL-kompatibler Iteration (Begin(), End(), ++, *, ->).
   • Suchen und Existenzprüfung über Find() und HasContentElement().
3. Modifikation & Kapazitätsmanagement (nur View):
   • Voraballokation über Reserve() zur Minimierung von Reallokationen.
   • Einfügen/Löschen über Add(), Erase() oder Remove(); Zurücksetzen via Clear().
4. Fehlerbehandlung / Status-Signalisierung:
   • Konsistenz- und Statusabfrage via HasError().
   • Bei Validierungsfehlern auf Applikationsebene: Setzen des Fehlerzustands im Datenelement via SetError(), wodurch der DM-Daemon über inkorrekte Record-Zustände informiert wird und entsprechende SOVD-HTTP-Statuscodes bzw. Fehler-Payloads emittieren kann.

4. Normative Relevanz & Entwickler-Hinweise

• STL-Konformität: Die Schnittstellen orientieren sich stark am C++-Standardcontainer- und Iterator-Design (std::vector- / std::span-Semantik). Algorithmen aus <algorithm> (z. B. std::find_if, Range-based for) können direkt mit den Iteratoren genutzt werden.
• Speichereffizienz & IPC-Overhead: Da der DM als Daemon-Prozess ausgelegt ist, fungieren die *View-Objekte in der Adaptive Application als typsichere Abstraktionen über Shared-Memory-Puffer oder deserialisierte IPC-Payloads. Entwickler sollten Reserve() nutzen, um wiederholte Pufferanpassungen bei dynamischen SOVD-Arrays zu vermeiden.
• Const-Correctness: Reine Abfrageoperationen (Monitoring, Telemetrie, Statusabfragen) müssen strikt über DiagnosticSovdRecordContentElementDataConstView implementiert werden, um versehentliche Modifikationen und unnötige Cache-Invalidierungen/IPC-Synchronisationen zu verhindern.
• Fehlersemantik (SetError/HasError): Fehler im Record-Payload werden nicht zwingend über C++-Exceptions abgebildet, sondern über In-Band-Statusflags (HasError(), SetError()), konform zu den AUTOSAR-Richtlinien für fehlertolerante Embedded-Systeme (ara::core::Result-Philosophie).