namespace <ExtendedDataRecord-Namespace>

Der Namensraum namespace <ExtendedDataRecord-Namespace> bündelt im Modul diag der AUTOSAR Adaptive Platform Schnittstellen wie DiagnosticExtendedDataRecordInterface zur Bereitstellung anwendungsspezifischer Extended Data Records für Fehlerspeichereinträge. Interpretation: Die Applikation dürfte die Schnittstelle während der Initialisierung instanziieren und registrieren, um eingehende Leseanfragen des Diagnose-Managers asynchron mit aktuellen Kontext- und Zählerdaten zu bedienen. Frage (offen) Dabei erfordert der nebenläufige Zugriff aus dem Diagnose-Subsystem eine thread-sichere Bereitstellung der Daten und eine rechtzeitige Beantwortung zur Vermeidung von Protokoll-Timeouts.

mehr ›

Kontext

Im Modul diag der AUTOSAR Adaptive Platform übernimmt der Namensraum namespace <ExtendedDataRecord-Namespace> die logische Kapselung von Schnittstellen zur Bereitstellung erweiterter Diagnosedaten. In der fahrzeugbezogenen Diagnose nach ISO 14229 (UDS) spielen Extended Data Records (EDR) eine zentrale Rolle, da sie einem Diagnosespeichereintrag (DTC) spezifische Zusatzinformationen wie Fehlerhäufigkeitszähler, Alterungszähler oder herstellerspezifische Zustandsdaten zuordnen. Interpretation: Der Bezeichner <ExtendedDataRecord-Namespace> dürfte als formaler Platzhalter für modellspezifisch konfigurierte Namensräume dienen, in denen anwendungsspezifische Diagnose-Schnittstellen für Datensatzelemente generiert werden. Frage Q-96107a4ff53015bb (offen) Die Kernklasse DiagnosticExtendedDataRecordInterface (im Modell als <ExtendedDataRecordElementInterface> aufgeführt) fungiert als Abstraktionsschicht zwischen dem AUTOSAR-Diagnose-Manager und der ausführenden Applikation, welche die physikalischen oder logischen Statuswerte vorhält.

Lebenszyklus

Die Lebensdauer und Zustandsverwaltung von Objekten des Typs DiagnosticExtendedDataRecordInterface ist eng an den Lebenszyklus der bereitstellenden Applikationskomponente gekoppelt. Interpretation: Die Instanziierung und Lebenszyklusverwaltung der Schnittstelleninstanz dürfte dem üblichen Dienstleister-Muster von ara::diag folgen, bei dem die Applikation die Schnittstelle während ihrer Initialisierungsphase erzeugt und dem Diagnose-Framework zur Verfügung stellt. Frage Q-9968bfe101348d1f (offen) Während der operativen Betriebsphase verbleibt die Instanz aktiv im Speicher, um eingehende Leseanfragen für Diagnosedaten zu bedienen. Bei einem geordneten Herunterfahren der Funktionssoftware muss die Instanz deregistriert oder zerstört werden, bevor abhängige Subsysteme beendet werden. Da Diagnoseanfragen asynchron über den Diagnose-Dämon eintreffen können, erfordert die Implementierung der Schnittstellenklasse ein thread-sicheres Design, um gleichzeitige Lesezugriffe auf interne Zustandsdaten der Applikation abzusichern.

Nutzungspfad

Ein typischer Nutzungsablauf umfasst die Definition, Bereitstellung und Ausführung der Datensatzabfrage. Zu Beginn instanziiert die funktionale Applikation die konkrete Implementierung von DiagnosticExtendedDataRecordInterface und bindet diese an den konfigurierten Port. Trifft anschließend ein externer Diagnosetester über ein UDS-Kommando (beispielsweise Service 0x19 zur Abfrage von Fehlerinformationen) eine Leseanfrage für einen bestimmten Extended Data Record ein, delegiert der Diagnose-Manager diese an die registrierte Schnittstelle. Interpretation: Die Schnittstelle dürfte als Service-Schnittstelle konzipiert sein, über die der Diagnose-Manager im Bedarfsfall die aktuellen Datensatzinhalte abruft. Frage Q-00d5498b4380bf74 (offen) Die Applikation sammelt die geforderten Datenwerte, kodiert sie in das spezifizierte Datenformat und liefert das Ergebnis an den Diagnose-Manager zurück, welcher die UDS-Antwortnachricht für das Testwerkzeug assembliert.

Fehlerszenarien

Beim Betrieb der Datensatz-Schnittstellen können verschiedene Fehlersituationen auftreten, die von der Applikationssoftware gezielt behandelt werden müssen. Ist die Schnittstelleninstanz zum Zeitpunkt einer Diagnoseanfrage nicht vollständig registriert oder befindet sie sich im Übergangszustand, kann der Diagnose-Manager die Anforderung nicht an die Applikation weiterleiten und antwortet dem Tester typischerweise mit einem negativen Antwortcode (NRC). Verzögert sich die Bereitstellung der Daten innerhalb der Applikation über ein definiertes Zeitfenster hinaus, drohen Protokoll-Timeouts auf der Diagnoseschnittstelle. Zudem muss die Schnittstelle robust gegenüber temporär nicht verfügbaren Messwerten sein, indem ungültige Datenzugriffe oder Fehlerzustände über die vorgesehenen Fehlermechanismen an den Diagnose-Manager gemeldet werden, anstatt ungehandhabte Ausnahmen im Prozess auszulösen.