Figure 9.94: Functional Clusters in category Diagnostics

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-2.0-Komponentendiagramm (Struktur- und Architektur-Klassifikationsdiagramm) gemäß AUTOSAR Adaptive Platform (AP).
• Architektur-Kontext: Systematische Einordnung innerhalb des Dokuments AUTOSAR_EXP_SWArchitecture (Release R22-11) unter der Architektur-Kategorie Diagnostics. Das Diagramm klassifiziert das funktionale Cluster Diagnostic Management als Kernbestandteil der AUTOSAR Adaptive Foundation / Services.

2. Komponenten, Entitäten & Schnittstellen

• «aapFunctionalCluster» Diagnostic Management:
  • Repräsentiert die funktionale Architektureinheit für die fahrzeugseitige Diagnoseverarbeitung (UDS gemäß ISO 14229-1, DoIP gemäß ISO 13400-2, Fehlerspeicherverwaltung und Routinesteuerung).
• Entwurfsklassifikation (daemon-based):
  • Spezifiziert das Ausführungsmodell des Clusters: Es ist nicht als reine In-Process-Bibliothek (library-based) realisiert, sondern läuft als eigenständiger POSIX-Hintergrundprozess (Daemon) mit eigenem virtuellem Adressraum und dediziertem Betriebssystem-Kontext.
• Schnittstellen & Interaktionspunkte (Architektur-Inferenz):
  • Südwärts / Applikativ: Stellt den Adaptive Applications (AA) über IPC (Inter-Process Communication) die standardisierte C++-API ara::diag bereit (Trennung zwischen Diagnose-Server-Kern und applikativen Service-/Event-Handlern).
  • Nordwärts / Netzwerk: Anbindung an physikalische Busse/Ethernet über IP-Sockets bzw. das Communication Management (ara::com) für DoIP.
  • Plattform-Schnittstellen: Interaktion mit Execution Management (ara::exec) bezüglich Lifecycle, Persistency (ara::per) zur spannungsausfallsicheren Speicherung von DTCs/Freeze Frames sowie State Management zur Validierung von Session- und Funktionszuständen.

3. Dynamisches Verhalten & Sequenzablauf

• Lifecycle & Initialisierung:
  • Der Diagnostic Management Daemon wird beim Hochlauf des Adaptive-Systems deterministisch durch das Execution Management (EM) auf Basis des hinterlegten Execution Manifests gestartet.
• Protokoll- & Request-Handling:
  • Externe Diagnose-Tester-Requests (z. B. via DoIP auf TCP/UDP-Port 13400) werden vom Daemon entgegengenommen und autark bis zur Session-/Security-Ebene abgearbeitet (P2/P2*-Timer-Handling).
  • Bei Anfragen an applikative Daten (ReadDataByIdentifier, RoutineControl) leitet der Daemon den Request via IPC an die zuständige Adaptive Application weiter. Die Antwort erfolgt asynchron über non-blocking Future/Promise-Mechanismen (ara::core::Future).
• Event- & Fehlerspeicherverarbeitung:
  • Lokale Monitorings in Adaptive Applications melden Fehlerzustände über die ara::diag::Monitor-Schnittstelle per IPC an den Daemon. Dieser debounct die Events, aktualisiert das UDS-Statusbyte und persistiert Snapshot-/Extended-Data-Records via ara::per.

4. Normative Relevanz & Entwickler-Hinweise

• IPC-Latenz & Parallelität:
  • Durch die daemon-based-Struktur überqueren Aufrufe zwischen Applikation (ara::diag) und DM stets Prozessgrenzen. Zeitkritische Diagnose-Routinen müssen für asynchrone IPC-Latenzen ausgelegt sein; blockierende Aufrufe im Application-Thread sind unzulässig.
• Manifest- und ARXML-Konfiguration:
  • Entwickler müssen die Diagnose-Schnittstellen im Diagnostic Extract (DiagnosticContribution / DiagnosticMapping) modellieren.
  • Das Deployment erfordert die Konfiguration im Execution Manifest (UID/GID, POSIX-Scheduling-Policies, Ressourcenlimits) sowie Zugriffsrechte für Socket-Operationen (DoIP) und IPC-Endpunkte.
• Dienstverfügbarkeit (Service Availability):
  • Da der Daemon asynchron zu Applikationen hochläuft, müssen Adaptive Applications über ara::diag die Verfügbarkeit der Diagnoseinstanzen überwachen, bevor Events gemeldet oder Handler registriert werden.