Figure 9.121: Interfaces for SOVD array data

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm mit Komponentenkontext (Adaptive Application und «aapFunctionalCluster»).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R25-11, Functional Cluster Diagnostic Management (DM, daemon-basiert).
• Technischer Zweck: Spezifikation der standardisierten C++ Native Interfaces («aapAPI,aapNativeInterface») für den Zugriff auf strukturierte Array-Daten innerhalb von SOVD (Service-Oriented Vehicle Diagnostics, ISO 22989 / ASAM SOVD). Die Schnittstellen kapseln dynamische, JSON-kompatible Array-Inhalte in typsichere, STL-konforme Abstraktionen für Adaptive Applications.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Komponenten

• Adaptive Application: Konsument der API, nutzt die View- und Iterator-Klassen für Diagnoseoperationen.
• Diagnostic Management («aapFunctionalCluster», daemon-based): Realisiert die Backend-Logik, Datenhaltung und IPC-Kommunikation zum Plattform-Daemon.

Schnittstellen & Datentypen («aapAPI,aapNativeInterface»)

• DiagnosticSovdArrayContentElementDataView (Read/Write View):
  • Methoden: Begin(), End(), CBegin(), CEnd(), Size(), Capacity(), Empty(), Reserve(), Clear(), Erase(), PushBack(), operator[](), HasError(), SetError().
  • Semantik: Lese- und schreibbarer Container-Proxy für SOVD-Array-Elemente.
• DiagnosticSovdArrayContentElementDataConstView (Read-Only View):
  • Methoden: Begin(), End(), CBegin(), CEnd(), Size(), Capacity(), Empty(), operator[](), HasError().
  • Semantik: Unveränderliche Sicht auf Array-Daten (z. B. für reine Messwert-/Sensordatenabfragen).
• DiagnosticSovdArrayContentElementDataIterator:
  • Operatoren: operator*(), operator->(), operator++(), operator==(), operator!=().
  • Semantik: STL-konformer Mutable-Forward-/Bidirektional-Iterator.
• DiagnosticSovdArrayContentElementDataConstIterator:
  • Operatoren: operator*(), operator->(), operator++(), operator==(), operator!=().
  • Semantik: STL-konformer Const-Iterator für schreibgeschützten Durchlauf.

Beziehungen & Abhängigkeiten

• Adaptive Application –«use»→ View / ConstView / Iterator / ConstIterator: Direkte API-Nutzung über C++-Header (ara::diag).
• Diagnostic Management ⇢ View / ConstView: Interface-Realization (gestrichelte Linie mit geschlossener Dreiecksspitze). Der DM-Daemon stellt die konkrete Laufzeit-Implementierung bereit.
• View / ConstView ⇢ Iterator / ConstIterator: Realisierungs-/Bereitstellungsbeziehung zur Erzeugung typisierter Iteratoren über Begin() / End().

Generische Element-Operationen (Tabellarischer Kontext)

• Allokation & Abfrage: Size(), Reserve(), Capacity(), Empty(), wahlfreier Zugriff via operator[]().
• SOVD Primitive Setter: SetBool(), SetDouble(), SetSignedInt(), SetUnsignedInt(), SetString().
• Fehlersignalisierung: SetError(), HasError().
• Record-/Dictionary-Operationen: RecordReserve(), RecordEmpty(), RecordEnd(), RecordRemoveAll(), Remove().

3. Dynamisches Verhalten & Zugriffsmuster

1. Sicht-Akquise: Die Adaptive Application erhält bei SOVD-Operationen (z. B. Read/Write DataIdentifier oder SOVD REST Request Processing) eine Instanz von DiagnosticSovdArrayContentElementDataView bzw. ...ConstView.
2. Speicher-Reservierung (Synchron): Vor dem Befüllen variabler Daten ruft die Applikation Reserve() auf, um Heap-Fragmentierung zu verhindern und Reallokationen im Daemon/Shared-Memory deterministisch zu halten.
3. Traversierung & Befüllung:
   • Zugriff wahlfrei via operator[](index) oder sequentiell via Iterator (Begin() bis End()).
   • Anfügen von Elementen über PushBack(), Löschen über Erase() oder Clear().
4. Fehlerbehandlung ohne Exceptions:
   • Tritt während der Datenverarbeitung ein Fehler auf, markiert die Applikation das Element via SetError().
   • Konsumenten prüfen den Status non-invasiv über HasError(), ohne dass C++ Stack-Unwinding ausgelöst wird.

4. Normative Relevanz & Entwickler-Hinweise

• View-Semantik & Zero-Copy: Die *View-Klassen halten die Daten in der Regel nicht selbst, sondern verweisen auf Shared-Memory- bzw. IPC-Puffer des DM-Daemons. Entwickler müssen die Lebensdauer der übergeordneten Diagnosesitzung/Transaktion beachten (Dangling-View-Gefahr nach Methoden-Return).
• MISRA & Echtzeit-Determinismus (AUTOSAR C++14):
  • PushBack() und Reserve() triggern Speicherallokationen; in zeitkritischen Tasks ist die Zielkapazität vorab zwingend über Reserve() anzufordern.
  • Exception-Freiheit: Fehler werden explizit über HasError() und SetError() transportiert; die API wirft im Fehlerfall keine C++-Exceptions (noexcept-Policy gemäß ara::core::Result).
• Const-Correctness: Reine Datenquellen (z. B. Sensor-Provider) dürfen ausschließlich gegen DiagnosticSovdArrayContentElementDataConstView arbeiten, um unbeabsichtigte Modifikationen der SOVD-Ressourcen im Plattform-Daemon zu verhindern.