Tab Diagnose¶
Info
Die Diagnosefunktion ist nur mit dem Add-on ecu.test diagnostics verfügbar
Der Tab Diagnose bietet symbolischen Zugriff auf die Diagnosefunktionalität von Steuergeräten.
Um den Tab Diagnose verwenden zu können, muss eine Testkonfiguration mit einer Diagnosedatenbasis gestartet sein (siehe Tab Steuergeräte). Abhängig vom Format der gewählten Diagnosedatenbasis bietet der Diagnose Tab die Testschritte DIAG-SERVICE ausführen, Fehlerspeicher lesen, DID-Lesen, DID-Schreiben und IOControl sowie Routine Control ausführen an. Um die bestmögliche Unterstützung durch symbolische Diagnose zu erhalten, wird empfohlen als Datenbasis das standardisierte ODX-Format zu wählen.
Die enthaltenen Testschritte sind so angelegt, dass sie bei einer schrittweisen Ausführung in Simulationszeitzeit die Ausführung des Modells jeweils fortsetzen.
Unterstützte Datenbasisformate
Open Diagnostic Data Exchange Format (ODX):
Alle in der ODX- bzw. PDX-Datei enthaltenen Diagnose-Services werden als generische DIAG-SERVICE Testschritte zur Ausführung in Packages aufbereitet. Die Darstellung erfolgt übersichtlich als Baumstruktur gegliedert nach Service-Identifier.
Das Diagnoseprotokoll (UDS/KWP2000) wird automatisch aus der Datenbasis ermittelt.
Für das Auslesen von DTCs wird zusätzlich der Testschritt Fehlerspeicher lesen angeboten.
Global Diagnostic Data Export (GDX, MDX), CANdela Diagnostic Data (CDD):
Ausgewählte in der GDX-, MDX- oder CDD-Datei enthaltene Diagnose-Services werden als spezifische Testschritte Fehlerspeicher lesen, DID-Lesen, DID-Schreiben und IOControl sowie Routine Control zur Ausführung in Packages aufbereitet.
Das Diagnoseprotokoll (UDS/KWP2000) wird automatisch aus der Datenbasis ermittelt.
Die Knoten der ersten Ebene des Tabs Diagnose entsprechen den Steuergeräten. Ein Steuergerät besitzt einen Eintrag, wenn ihm in der Testkonfiguration eine Diagnose-DB und ein Diagnose-Port zugeordnet wurde. Existiert kein solches Steuergerät, bleibt der Tab Diagnose ausgeblendet.
Testschritt DIAG-SERVICE ausführen
Dieser Testschritt ist eine generische Repräsentation eines in der Diagnose-Datenbasis enthaltenen Services.
Der Testschritt kann per Drag&Drop oder Rechtsklick in ein Package eingefügt werden, in beiden Fällen öffnet sich der Ausführen-Dialog.
Die Parameterwerte entsprechen denen des Request, die Rückgabewerte denen der Positive Response.
Für jeden Rückgabewert kann in der Spalte Werte als eine der Repräsentationen BITS, TEXT oder PHYS ausgewählt werden. Weitere Informationen zu den verschiedenen Repräsentationen sind im Abschnitt Repräsentation zu finden.
Die Response kann als Variable im Response Speichern Dialog gespeichert werden. Die dahinterliegende Datenstruktur entspricht entweder einem DiagServiceResult oder einem NegativeResponse.
Eine Unerwartete Response oder ein Timeout führt zur ERROR Bewertung des Testschritts.
Eine Negative Response kann in dem separaten TAB Negative Response evaluiert werden.
Testschritt Fehlerspeicher lesen
Die Aktion Fehlerspeicher lesen wendet den UDS (ISO 14229) Service Read DTC Informations (SID $19) an. Der Testschritt kann über das Kontext-Menü (rechte Maustaste) des Eintrags Fehlerspeicher –> oder durch Ziehen in den Testfall eingefügt werden.
Es erscheint ein neues Fenster Fehlerspeicher lesen, in dem der Testschritt parametriert wird.
Der Bereich Request legt die Subfunktionen und gegebenfalls die Statusmaske fest. Die Statusmaske kann direkt eingetippt, über das DropDown-Menü aus den einzelnen Feldern zusammengestellt, oder aus einer Testfallvariable oder einem sonstigen Python-Ausdruck bezogen werden.
Das Ergebnis kann in einer Variable unter der Option Wert speichern gespeichert werden. In Abhängigkeit von der Diagnoseantwort erhält man als Rückgabewert einen der folgenden Typen:
Ein Objekt aus der Liste ReadDtcInformation, abhängig von der gewählten Subfunktion.
NegativeResponse -Objekt: Negative UDS-Antwort (z.B. Service wird von Steuergerät nicht unterstützt)
DiagResult -Objekt: Ergebnis bei sonstigen Fehlern (z.B. Timeout)
Info
Anders als die meisten anderen Testschritte speichert Fehlerspeicher lesen auch dann einen Wert in der Variable, wenn der Testschritt mit ERROR bewertet wird.
Bei der Bewertung gibt es unter dem Tab Vergleich die Möglichkeit DTCs zu prüfen und zu tolerieren. Des Weiteren kann die Repräsentation der DTCs eingestellt werden.
Die Option DTCs prüfen stellt eine Liste zum Filtern von erwarteten oder unerwarteten
DTCs dar. Diese kann über den Plus-Button in einem Such-Dialog sowie über die Aus Liste
Option befüllt werden. Im Eingabefeld Aus Liste kann man einen Einleitung Python -Ausdruck
eingeben, der auf Testfallvariablen und/oder auf api.GlobalConstants verweisen kann.
Der Wert des Ausdrucks muss eine Liste von DTCs ergeben. Jeder DTC in der Liste kann entweder
eine Zeichenfolge oder Zahl entsprechend der gewählten Repräsentation sein, oder
ein DTCAndStatusRecord -Objekt.
Letzteres ermöglicht, das bei einer früheren Ausführung dieses Testschritts in einer Variable
gespeicherte DTCListDiagResult -Objekt
wiederzuverwenden.
Die Option DTCs tolerieren behandelt alle DTCs, die nicht explizit geprüft, aber trotzdem toleriert werden sollen. Es besteht die Option, alle aufkommenden DTCs, welche nicht in der Prüf-Liste vorhanden sind, zu tolerieren (Häkchen bei setzen) oder eine Liste (wie bei DTCs prüfen) anzugeben.
Zeitoptionen können auf dem gleichnamigen Tab festgelegt werden.
Testschritte DID-Lesen, DID-Schreiben und IOControl
Viele DIDs können über den UDS (ISO 14229) Service Read Data By Identifier (SID $22) gelesen werden. Dazu wird ein spezieller -Testschritt verwendet, der nur Rückgabewerte besitzt. Schreiben ist dagegen auf unterschiedliche Arten möglich:
Manche DIDs unterstützen Write Data By Identifier (SID $2E), wofür in ecu.test ein spezieller -Testschritt verwendet wird, der nur Eingabeparameter besitzt.
Für andere DIDs muss Input/Output Control By Identifier (SID $2F) verwendet werden. Dabei stehen einige oder alle der Modi , , und als -Testschritte zur Verfügung.
Die Parameter der Testschritte können als PHYS oder TEXT angegeben werden. PHYS steht für ganzzahlige oder Fließkommawerte wie „42“ oder „3.14“. TEXT wird z.B. für ID- oder Versionsnummern verwendet wie „‚XA05‘“ oder für Byte-Folgen, wie sie beim Übermitteln von Zertifikaten oder Challenges bei der Authentifizierung verwendet werden, z.B. „ByteStream(‚0a:0b:0c‘)“. Die Rückgabewerte für Byte-Folgen werden ebenfalls als TEXT als ByteStream zurückgegeben.
Im Fall von kann ein Sollwert angegeben werden; alle Modi akzeptieren u.U. als letzten Parameter eine Bitmaske zur Festlegung dass nur ein Teil der dem DID zugeordneten Datenstruktur beeinflusst werden soll. Der aktuelle Wert steht immer zusätzlich als Rückgabe zur Verfügung.
Bei Verwendung von Zeitoptionen in Bezug auf eine Erwartung an den Rückgabewert wird nur initial Input/Output Control By Identifier (SID $2F) aufgerufen. Für jede erneute Auswertung des Rückgabewerts wird dieser per Read Data By Identifier (SID $22) gelesen.
Sämtliche erwähnten Testschritte lassen sich wie üblich über das Kontextmenü des DID oder oder durch Ziehen des DID in den Testfall erstellen. Weitere Informationen zum Lesen-, Schreiben- und Ausführen-Dialog sind im Kapitel Lesen-/ Schreiben-/ Ausführen-/ Stimulus-Dialog zu finden.
Testschritt Routine Control ausführen
Die Aktion Routine Control ausführen ruft den UDS (ISO 14229) Service Routine Control (SID $31) auf. Durch Hereinziehen einer Routine Control in den Testfall öffnet sich der Ausführen-Dialog. Weitere Informationen sind im Kapitel Ausführen-Dialog zu finden. Antwortet das Steuergerät nicht oder mit einer negativen Antwort, wird der Testschritt mit ERROR bewertet. Die Fehlerursache wird im Report dokumentiert.
Info
Auf Ergebnisse der Routine (Subfunktion 0x03, requestRoutineResults) kann mit der
Zeitoption Warte bis wahr gewartet werden. Um diesen Fall zu unterstützen,
wird die negative Antwort (NRC) 0x24 (requestSequenceError) in ~NotPresent~
umgewandelt.
Komplexe Strukturen
Um auf Elemente einer Struktur zuzugreifen, kann analog zu gängigen Programmiersprachen die Attributnotation genutzt werden. Für Elemente primitiven Datentyps lassen sich dann wie gewohnt Erwartungen formulieren.
Einzelne Elemente von Arrays können über ihren entsprechenden Index in eckigen Klammern angesprochen werden.
ODX-Tables nehmen eine besondere Rolle ein, da Tables durch eine besondere Art und Weise in ODX abgebildet werden. Ein Table-Struct stellt die tatsächlich gewünschte Parametrisierung dar,hat aber keinen statisch eindeutigen Typ. Dieser wird dynamisch durch den Wert des referenzierten Table-Keys bestimmt. Daher ändert sich je nach Wahl des Table-Key-Parameters die Autovervollständigung des Table-Struct-Parameters.