Figure 9.106: Common interfaces of Diagnostic Management (3 of 3)

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hybrides Architekturschaubild der AUTOSAR Adaptive Platform (AP), bestehend aus formalen tabellarischen Schnittstellendefinitionen (Native C++ Interfaces) und einem UML-Klassendiagramm/Komponentendiagramm mit Schnittstellenrealisierung.
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AUTOSAR_AP_EXP_SWArchitecture, Release R25-11), Functional Cluster Diagnostic Management (DM) (ara::diag). Das Diagramm spezifiziert die generischen Hilfsschnittstellen (CancellationHandler, MetaInfo) für langlebige bzw. kontextsensitive Diagnoseoperationen sowie das Bereitstellungs- und Zugriffsmuster für Extended Data Records (EDR) zwischen einer Adaptive Application und dem daemon-basierten Diagnostic Management.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Komponenten

1. Adaptive Application (UML-Komponente):
   • Client-/Provider-Anwendung im User Space der Adaptive Platform.
   • Nutzt die generierte API zur Interaktion mit dem Diagnosestack.
2. «aapFunctionalCluster» Diagnostic Management (daemon-based) (UML-Komponente):
   • Plattform-Daemon der Adaptive Platform für UDS/DoIP-Diagnoseservices.
   • Realisiert die Middleware- und Transport-Infrastruktur für Diagnoseanfragen.

Schnittstellen & Tabellen

1. CancellationHandler (Technology: Native interface, Usage: Public API):
   • Beschreibung: Kapselt den kooperativen Abbruchzustand langlaufender Diagnoseanfragen (z. B. Routine Control, Data Identifier, EDR-Lesen).
   • Operationen:
     • IsCanceled(): Abfrage (Polling), ob die Service-Ausführung vom Tester oder Stack abgebrochen wurde.
     • SetNotifier(notifier): Registrierung eines Callbacks/Notifiers, der asynchron ausgelöst wird, sobald der Abbruch signalisiert wird.
2. MetaInfo (Technology: Native interface, Usage: Public API):
   • Beschreibung: Liefert kontextbezogene Transport- und Sitzungsinformationen (z. B. Quell-/Zieladresse DoIP/UDS, Session-ID, Authentifizierungslevel) an die Applikation.
   • Operationen:
     • GetContext(): Liefert den globalen Ausführungskontext des aktuellen Aufrufs.
     • GetValue(key): Gibt spezifische Metainformations-Werte anhand eines Schlüssels zurück.
3. «aapAPI,aapPortInterface» {<extented-data-record-element-interface-name>}:
   • Parametrisierte Port-Schnittstelle zur Bereitstellung und Abfrage von herstellerspezifischen Zusatzdaten (Extended Data Records) zu Fehlerspeichereinträgen (DTCs).
   • Operationen:
     • + Offer(): Aktiviert die Schnittstelle und meldet die Bereitschaft zur Datenbereitstellung an den DM-Daemon.
     • + Read(): Liest den aktuellen Inhalt des Extended Data Record aus.
     • + StopOffer(): Zieht die Bereitstellung des Record-Elements zurück.

Beziehungen & Abhängigkeiten

• Realisierung (InterfaceRealization): Diagnostic Management realisiert (gestrichelte Linie mit weißer Pfeilspitze) das Port-Interface «aapAPI,aapPortInterface» {<extented-data-record-element-interface-name>}.
• Nutzungsbeziehung («use» Dependency): Adaptive Application bindet das Interface über eine gerichtete Abhängigkeit ein (Offer(), Read(), StopOffer()).

3. Dynamisches Verhalten & Sequenzablauf

1. Lebenszyklus / Registrierung:
   • Die Adaptive Application instanziiert das generierte Proxy/Skeleton-Element für das Extended Data Record.
   • Vor der Verfügbarkeit ruft die Applikation synchron Offer() auf. Der Diagnostic Management-Daemon nimmt die Registrierung für den spezifischen DTC-/Record-Kontext entgegen.
2. Datenauslese (Read):
   • Bei Eintreffen einer UDS-Anfrage (z. B. Service 0x19 0x06 - ReadDTCReportExtendedDataRecordByDTCNumber) leitet der Daemon die Leseanforderung über Read() an die Instanz weiter.
   • Der Aufruf transportiert implizit oder als Parameter Instanzen von MetaInfo (zur Validierung der Berechtigung/des DoIP-Kanals) und CancellationHandler.
3. Abbruchsteuerung (Asynchron / Kooperativ):
   • Bricht der UDS-Client die Verbindung ab (TCP-Drop, Timeout, Session-Reset), setzt der Daemon den Abbruchstatus.
   • Die verarbeitende Logik in der Applikation prüft zyklisch IsCanceled() oder reagiert auf die via SetNotifier() hinterlegte Benachrichtigungsfunktion, um blockierende E/A-Vorgänge sofort zu terminieren und Ressourcen freizugeben.
4. Deregistrierung:
   • Beim Herunterfahren oder Deaktivieren der Subfunktion ruft die Applikation StopOffer() auf; nachfolgende UDS-Anfragen quittiert der Daemon mit einem Negative Response Code (NRC, z. B. 0x31 Request Out Of Range).

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ara::diag): Entwickler von Diagnose-Providern müssen Offer() zwingend vor Freigabe der Diagnosefunktionen im System aufrufen (üblicherweise im Übergang des Execution Management nach Running).
• Kooperative Abbruchpflicht: Bei blockierenden oder zeitintensiven Berechnungen innerhalb von Read() muss der CancellationHandler implementiert bzw. ausgewertet werden. Ein Ignorieren führt bei Verbindungsabbrüchen zu Thread-Blockaden und Denial-of-Service im Diagnosestack.
• Kontextsicherheit (MetaInfo): Bei Zugriff auf sicherheitsrelevante Extended Data Records ist MetaInfo::GetValue() auszuwerten, um sicherzustellen, dass die Diagnoseanfrage über eine autorisierte DoIP-Testerverbindung (Security Access Level) empfangen wurde.
• Typo in Spezifikation: Der Schnittstellen-Platzhalter extented-data-record-element-interface-name enthält den AUTOSAR-spezifikationsinternen Tippfehler (extented statt extended); in Implementierungen entspricht dies dem kanonischen C++-Namespace ara::diag::ExtendedDataRecord bzw. anwendungsspezifisch generierten Port-Klassen.