Toolkategorien¶
Die Toolkategorien stellen thematisch getrennt die konfigurierbaren Standardtestschritte von ecu.test zur Verfügung. Jede Toolkategorie ermöglicht das Einlesen von Beschreibungsdateien und stellt anwenderfreundliche Dialoge zur Konfiguration der spezifischen Testschritte sowie die Funktionen zum Ausführen und für den Testreport bereit.
Modellzugriff - Modellsimulation¶
Die Toolkategorie Modellzugriff kommt dann zum Einsatz, wenn mit Messgrößen und Parametern eines Modells in einer HiL- oder MiL-Umgebung interagiert werden soll. Auch einige HiL-Umgebungen können mit der Modell-Schnittstelle addressiert werden.
Bei einer Interaktion mit einem Modell stehen deutlich erweiterte Möglichkeiten der Stimulation von Ereignissen zur Verfügung als beispielsweise bei Tests im Fahrzeug. Für die Erstellung von Testfällen werden Testschritte zum Auslesen und Verstellen von Modellgrößen angeboten.
Beispiele verwendbarer HiL-Plattformen:
Beispiele verwendbarer Mil und SiL-Plattformen:
MATLAB/Simulink (MiL)
FMI tool adapter (SiL)
Verwendung:
Applikation - Applikationszugriff¶
Mit Hilfe der Toolkategorie Applikation wird der Applikationszugriff auf die am Test beteiligten, real vorhandenen, Steuergeräte mit den beiden Varianten Messung und Kalibrierung ermöglicht. Dabei stellt Messung Testschritte für den Lesezugriff auf interne Steuergerätegrößen (sog. Labels) zur Verfügung, wohingegen Kalibrierung sowohl Lese- als auch Schreibzugriff auf Systemkonstanten, Kennlinien und -felder anbietet.
Die Einteilung in Messung und Kalibrierung hält sich dabei an den Standard ASAM MCD-2MC (ASAP2), in welchem nach Measurement- und Calibration-Größen unterteilt wird.
Verwendbare Peripheriesoftware:
Verwendung:
Diagnose - Diagnosekommunikation¶
Die Toolkategorie Diagnose bietet die Möglichkeiten der Ausführung von Diagnose-Services auf den beteiligten Steuergeräten. Mit Hilfe dieser Services können u. a. Statuswerte abgefragt, Bauteilansteuerungen vorgenommen und der Fehlerspeicher ausgelesen werden.
Funktionen dieser Toolkategorie können auf drei verschiedene Arten genutzt werden:
Diagnose
Mit dieser Art des Zugriffs ist es möglich UDS-Diagnose über CAN durchzuführen. Die Kommunikation basiert auf der Unterstützung für hardwarenahe Bus-Anbindungen. Außer dem Gerätetreiber für die Hardwareschnittstelle wird dabei keine zusätzliche Software benötigt. Unter Tab Diagnose findet sich eine Funktionsübersicht.
Unterstützt werden folgende Protokollstandards:
UDS (ISO 14229-1)
KWP2000 (ISO 14230)
ISO-TP (ISO 15765-2)
DoIP (ISO 13400)
FlexRay TP (AUTOSAR FrTp, ISO 10681-2)
OBD DTC Definitions (ISO 15031-6 / SAE J2012)
SAE J1939
Info
Die Diagnosefunktion ist nur mit dem Add-on ecu.test diagnostics verfügbar
Diagnose(EDIABAS)
Diese Zugriffsart ist speziell an das Diagnose-Basissystem EDIABAS der Firma Softing angepasst. Unter Tab Diagnose(EDIABAS) findet sich eine Funktionsübersicht.
Diagnose(DTS)
Diese Zugriffsart ermöglicht die ASAM MCD-2D/3D-kompatible Ansteuerung des Diagnose-Werkzeugs DTS der Firma Softing. Unter Tab Diagnose(DTS) findet sich eine eine Funktionsübersicht.
Rohdiagnose mit KWP2000 über ISO-TP¶
Daneben besteht mit den hardwarenahen CAN-Bus-Anbindungen die Möglichkeit, in Form von ByteStreams codierte Diagnoseaufrufe nach KWP2000 über ISO-TP (ISO 15765-2) zu tätigen. Zu diesem Zweck stehen bei den entsprechenden Diagnose-Busports die Port-Jobs OpenKwp2000overIsoTpSession, CallService und CloseSession zur Verfügung.
Zunächst ruft man den Portjob OpenKwp2000overIsoTpSession auf. Als Parameter muss man Request- und die Response-ID (CAN-Message-IDs für die die Diagnoseanfragen bzw. -Antworten) angeben. Alle weiteren Parameter sind optional. Der Rückgabewert dieses Aufrufs dient als Identifizierungsmerkmal für die soeben geöffnete Diagnosesitzung. Er muss bei künftigen Aufrufen von CallService und CloseSession übergeben werden, daher sollte man ihn in einer Variable ablegen.
Um eine Diagnosefunktion aufzurufen ruft man nun den Portjob CallService auf. Neben der Session-ID (die man als Rückgabewert vom Portjob OpenKwp2000overIsoTpSession erhalten hat) muss man einen Request in Form eines ByteStream angeben. Optional kann ein Timeout (in ms) angegeben werden. Der Rückgabewert ist ein DiagResult-Objekt.
Die Ausführung des Tooljobs CallService ist sofort abgeschlossen, auch wenn die Übertragung des Diagnose-Request oder das Warten auf die Antwort im Hintergrund noch andauert. Erst beim Lesezugriff auf das DiagResult wird so lange gewartet, bis das Ergebnis vorliegt.
Buszugriff¶
Mit Hilfe der Toolkategorie Buszugriff werden die notwendigen Funktionen für das Senden und Empfangen von PDUs auf den Bussystemen zur Verfügung gestellt. Dies ist insbesondere für den Test von Funktionen erforderlich, die auf mehrere Steuergeräte verteilt sind.
Verwendbare Peripheriesoftware:
Verwendung:
Die hardwarenahen Bus-Tool-Adapter bieten einige Zusatzfunktionen an:
Automatische E2E-Berechnung¶
Für die E2E-Profile 1, 2, 4, 5 und 7 kann ecu.test auf Wunsch die E2E-Signale Data-ID(-Nibble), DataLength, Counter und CRC (soweit für das jeweilige Profil anwendbar) automatisch berechnen. Dazu legt man in der Testbenchkonfiguration einen Platzhalterwert fest, und weist im Testfall diesen Wert an die automatisch zu befüllenden Signale zu.
Mini-Restbussimulation¶
Für CAN, CAN FD und FlexRay steht eine eingeschränkte Restbussimulation zur Verfügung. Um diese zu verwenden, kann in der Testbenchkonfiguration ein Port vom Typ BUSACCESS mit dem Implementierungstyp CAN, CAN-FD bzw. FLX eingerichtet werden, welcher in der Testkonfiguration als Manipulationsport ausgewählt wird.
Nun wählt man auf dem Tab Buszugriff für eine PDU die Option PDU-Timing ändern und aktiviert dort die zyklische Aussendung dieser PDU. Mit PDU-Timing ändern kann man jederzeit die Zykluszeit ändern und das zyklische Senden der PDU deaktivieren oder wieder aktivieren. Der Inhalt der PDU lässt sich jederzeit (auch vor dem Einschalten der zyklischen Aussendung) ändern, indem einzelne Signale per Schreiben (vgl. Abschnitt Tab Buszugriff) verändert werden.
Die PDUs werden zyklisch mit den konfigurierten Daten gesendet. Die Konfiguration kann ohne einen Zyklusneustart geändert werden. Dabei bleibt der Aktivierungsstatus der PDU unverändert.
Berechnete Frames und Signale
Bei der Verwendung der Mini-Restbussimulation oder des Testschritts Signalgruppe-Schreiben für CAN, CAN FD und FlexRay hat man die Möglichkeit statt eines festen Frame- oder Signalwerts ein Python-Objekt zu erstellen, das den entsprechenden Wert dynamisch ermittelt. Damit ist es beispielsweise möglich, sich beim zyklischen Senden die jeweils gültigen Signalwerte für Prüfsummen oder Alive-Zähler ermitteln zu lassen.
Die Berechnungsklasse des Objekts ist in Python zu implementieren und in das Verzeichnis für Benutzer Python-Bibliotheken in das Unterverzeichnis BusCalcFunctions zu hinterlegen. Ein Grundgerüst für diese Klassen kann automatisch erzeugt werden, indem man auf dem Tab Buszugriff eine PDU selektiert und im Kontextmenü Erzeuge Berechnungsklassen auswählt. Wie die Implementierung zu erfolgen hat, kann der generierten Vorlage entnommen werden.
Das Frame-Berechnungsobjekt kann nur im Rahmen der Mini-Restbussimulation verwendet werden. Um
eine Instanz dieser Klasse für eine bestimmte PDU zu aktivieren, muss diese im Eingabefeld
Berechnungsobjekt im Testschritt PDU-Timing ändern angegeben werden.
(Z.B. user.BusCalcFunctions.MyProject.MyCalculationObjects.CalculateFrame(), wenn die Klasse
im Projekt (Unterverzeichnis) MyProject sowie im Modul MyCalculationObjects
liegt und CalculateFrame heißt. Das Projekt kann optional angelegt werden und wird durch
ein Unterverzeichnis in BusCalcFunctions repräsentiert)
Möchte man nur für ein einzelnes Signal ein Berechnungsobjekt zur Ermittlung des Rohwerts angeben, erfolgt dies im Testschritt Schreiben oder Signalgruppe-Schreiben, indem man die Instanz einer Berechnungsklasse statt des Signalwerts als Rohwert angibt.
Der Zugriff auf die Berechnungsklasse, z.B. zur Instanziierung, kann unter Benutzer Python-Bibliotheken nachgelesen werden.
Info
Die Skripte mit den Berechnungsklassen müssen im Verzeichnis BusCalcFunctions liegen. Um eine Berechnugsklasse einem Projekt zuzuweisen, können diese in einem Unterverzeichnis gespeichert werden. Der Name des Verzeichnisses entspricht in diesem Fall dem Namen des Projekts.
Info
Die Skripte mit den Berechnungsklassen werden zu Beginn der Packageausführung in ecu.test importiert und müssen daher zu diesem Zeitpunkt bereits vorliegen.
Unterstützung für PDUs mit Multiplexern
Bei CAN-, CAN FD- und FlexRay-PDUs mit Multiplexern gibt es verschiedene Varianten, wie der Multiplexer-Wert gesetzt werden kann:
Er kann in der entsprechenden Signalberechnungsfunktion in der Berechnungsklasse gesetzt werden.
Er kann explizit im Package geschrieben werden (mit Signalgruppe-Schreiben). Die PDU wird dann so lange mit diesem Multiplexer-Wert versendet, bis er mit einem anderen Wert überschrieben wird.
Er erhält den Multiplexer-Wert der aktivierten PDU. Falls mehrere PDUs aktiviert sind, werden deren Multiplexer-Werte zyklisch durchgeschaltet.
Info
Es werden nur Signale von aktivierten PDUs gesendet. Signale der statischen PDU werden jedoch bei jedem Versenden einer der dynamischen PDUs mit berücksichtigt.
Info
Wenn man in einem gemultiplexten Frame nur die statische PDU aktiviert, sind implizit alle dynamischen PDUs aktiviert, für die mindestens ein Signalwert vorgegeben ist.
Info
Verschachtelte Multiplexer werden nur unterstützt, wenn die Multiplexer-Signale im Frame aneinander grenzen.
Mini-Restbussimulation mit komplexen Signalverläufen
Als Erweiterung zur Mini-Restbussimulation ist es möglich, auch komplexe Verläufe auf Basis von Stimulus-Dateien auf dem Bus zu erzeugen. Diese Signalverläufe können mit dem Signal Editor modelliert werden. Um Bus-Signale mit Signalen aus einer Stimulus-Datei zu verknüpfen, wird den Testschritt Start Stimulus verwendet. Zu beachten ist, dass bei einem Aufruf des Testschritts nur Signale, die zu einem Bus gehören, zugeordnet werden dürfen. Dies betrifft sowohl die Eingangs- als auch die Ausgangssignale. Alle Signalwerte werden dabei als physikalische Signale betrachtet. Es muss darauf geachtet werden, dass in der Mapping-Größe für alle verwendeten Bus-Signale der Haken Manipulation gesetzt ist. Um das Senden einer PDU zu aktivieren/deaktivieren, wird wie bisher der Testschritt PDU-Timing ändern verwendet. Wird der Wertebereich bei der Wiedergabe verletzt, können undefinierte Zustände auftreten. Bei Verwendung des leeren Abschnitts wird der Signal-Rohwert auf 0 gesetzt.
Weitere Funktionen der hardwarenahen Bus-Anbindungen¶
Frames mit Zusatzinformationen lesen
Der Portjob ReadFrameEx gibt ein CanFrame-, FlexRayFrame- bzw. LinFrame- Objekt zurück, das in einer Testfallvariable abgelegt werden kann. Anschließend kann (z.B. mit einem Berechnungsschritt) auf die Objekte und ihre Eigenschaften zugegriffen werden. Nicht alle Implementierungen befüllen alle Eigenschaftsfelder. Die Werte 0 und False können auch auftreten, wenn die betreffende Eigenschaft von der jeweiligen Implementierung nicht ausgewertet werden kann.
Frames in eine Inbox streamen
Der Porttyp BUSACCESS besitzt in der Kombination mit den Implementierungstypen CAN, FLX und LIN die Portjobs RegisterFrameForInbox und DeregisterFrameForInbox. Mit diesen Jobs ist es möglich, wenn die Hardware-Anbindung über Tool Server erfolgt (im Gegensatz zu lokaler Anbindung), ein oder mehrere Frames mit einer als Variable anzulegenden Inbox zu verknüpfen bzw. diese Verknüpfung wieder aufzuheben. Auf dem Bus empfangene Frames werden nach der Registrierung automatisch in die Inbox-Datenstruktur abgelegt und können von dort aus weiterverarbeitet werden (näheres siehe Inbox und „Aus Inbox lesen“). Damit erhält man die Möglichkeit, verlustfrei Frames im Testfall auszuwerten. Neben den Identifizierungsmerkmalen für ein Frame, welches sich für CAN, CANFD und FlexRay unterscheidet und als Job-Beschreibung hinterlegt sind, besitzt der Job RegisterFrameForInbox den Parameter saveAsCanFrame, saveAsFlxFrame bzw. saveAsLinFrame. Ist dieser aktiviert werden die Frames als CanFrame-, FlexRayFrame bzw. LinFrame- Objekt in der Inbox abgelegt. Andernfalls wird nur die Payload des Frames als ByteStream-Objekt gespeichert.
Rohdiagnose
Siehe Abschnitt Rohdiagnose mit KWP2000 über ISO-TP.
Service-Zugriff¶
Die Toolkategorie Service-Zugriff ermöglicht den Zugriff auf SOME/IP-Services. Sie erlaubt Zugriff auf Methoden und Events sowie deren Parameter.
Verwendbare Tooladapter:
Info
ControlDesk Service-Manager kann nur Blatt-Elemente lesen und schreiben.
Verwendung:
Service-Simulation¶
Neben dem Zugriff auf von Steuergeräten angebotene Services kann ecu.test auch selbst Services bereitstellen, die die zu testenden Steuergeräte dann nutzen können.
Zu diesem Zweck müssen zunächst Python-Module generiert werden, die das Verhalten der vom jeweiligen Service angebotenen Methoden und Events implementieren. Durch Bearbeiten dieser Module lässt sich das Verhalten anpassen.:
Für jede Methode und jedes Event ist die Struktur der zugehörigen Eingabe- und Rückgabeparameter im Kopf der Methode dokumentiert, die die Methode bzw. das Event implementiert. Man kann Daten aus den Eingabeparametern beziehen und Werte in die initial leeren Rückgabeparameter hineinschreiben.
Die Intervalle für zyklische Events können konfiguriert werden.
Eigene Methoden zum Ändern von Daten oder Verhalten können zur ServiceIntance-Klasse hinzugefügt werden. Diese können später vom Testfall aus aufgerufen werden.
Anschließend kann man über die Service-API die Simulation steuern.
In der Testbenchkonfiguration können simulierte Services festgelegt werden, die automatisch gemeinsam mit dem Testfall gestartet werden (ohne dass die entsprechende API-Funktion benutzt werden muss), und festgelegt werden, dass die Simulation nach Ende des Testfalls, der sie gestartet hat, noch weiter läuft.
Info
Aktuell ist es nur möglich, Services simulieren zu lassen, wenn der jeweilige Tooladapter im local-Modus angebunden ist, nicht bei Verwendung über Tool Server.
Info
Event senden bzw. Methode anbieten und Service-Simulation können gleichzeitig verwendet werden, wenn unterschiedliche Services angeboten werden und sich die IP-Adressen unterscheiden.
Low-Level Simulation
Manchmal ist es erforderlich, Netzwerkdienste abseits von SOME/IP zu simulieren. Zu diesem
Zweck bieten Ports der niedrigeren Netzwerkschichten einen Job StartSendPacketCyclic an.
Über diesen ist es möglich eine selbstdefinierte Bytefolge zyklisch zu senden. Es gibt zwei Optionen
um den Payload zu definieren: Es kann ein statischer ByteStream (z.B. ByteStream('11:22:33'))
übergeben werden oder ein selbstdefiniertes Objekt. Für den zweiten Fall muss unter
WORKSPACE/UserPyModules/CyclicPayloadFunctions/ eine neue Pythondatei angelegt werden
welche eine aufrufbare Klasse enthält. Im folgenden Beispiel wurde eine Klasse unter
WORKSPACE/UserPyModules/CyclicPayloadFunctions/SimpleCyclicFunction.py angelegt.
from tts.lib.dataStructures.ByteStream import ByteStream
class SimpleCyclicFunction:
def __init__(self, a="11", b="22", c="33"):
self.a = a
self.b = b
self.c = c
def __call__(self, *args, **kwargs):
return ByteStream("{0}:{1}:{2}".format(self.a, self.b, self.c))
Als Payload kann nun eine Instanz wie
user.CyclicPayloadFunctions.SimpleCyclicFunction.SimpleCyclicFunction('11', '22', '33')
angegeben werden. Bei der Erstellung der Klasse muss darauf geachtet werden, dass bei der Verwendung
von Parametern ein Defaultwert angegeben wird. Des Weiteren muss die __call__ Methode
Überschrieben werden. Diese muss ein ByteStream Objekt zurückgeben.
Debugging¶
Die Toolkategorie Debugging ermöglicht den Zugriff auf Debuggerwerkzeuge. Es erlaubt den Zugriff auf globale wie lokale Variablen der auf dem Steuergerät ausgeführten Applikation.
Verwendbare Peripheriesoftware:
Verwendung:
Funktionszugriff¶
Die Toolkategorie Funktionszugriff ermöglicht die synchrone/asynchrone Ausführung einfacher externen Funktionen (z.B. aus einer DLL). Als Argumente und Rückgabewerte werden nur Basisdatentypen wie Zeichenketten und Zahlen unterstützt.
Konfiguration:
Verwendung:
Fehlersimulation¶
Die Toolkategorie Fehlersimulation (FIU) ermöglicht es, elektrische Fehler an ein Steuergerät anzulegen. Normalerweise werden diese durch Einträge im Fehlerspeicher des Steuergerätes angezeigt. Die simulierbaren Fehler sind:
Unterbrochene Leitung, bzw. Wackelkontakt zu einem Sensor/Aktor
Kurzschluss der Leitung gegen Masse oder Spannung
Verbindung mehrerer Pins über eine gemeinsame Sammelschiene
Konfiguration:
Verwendung (EES):
Verwendung (FIU):
Testschritte - Spezifische Testschritte¶
Die Toolkategorie Testschritte stellt ein großes Spektrum von Testfunktionen zur Verfügung. Dazu zählen u. a. die Testablaufsteuerung mit Schleifen, Pausen und bedingten Ausführungen, Datenoperationen, Schritte zur Teststrukturierung, das Erzeugen elektrischer Fehler an Hardwarepins sowie weitere spezielle Implementierungen. Alle Testschritte sind Spezialisierungen der gleichnamigen Toolkategorie. Dadurch ist es sehr einfach möglich, weitere nutzerspezifische Funktionen zu implementieren und als Plug-In in die bestehende Installation von ecu.test einzubinden.
Verwendung:
Multimedia - Zugriff¶
Die Toolkategorie Multimedia ermöglicht es, auf ein Videogerät - zum Beispiel eine Webcam - zuzugreifen. Bilder und einzelne Bildbereiche können miteinander verglichen, über benutzerdefinierte Filter manipuliert und im Report gespeichert werden.
Konfiguration:
Verwendung:
Erweiterungen:
Umfeldsimulationszugriff¶
Für den Test komplexer Fahrerassistenzsysteme und das autonome Fahren werden auch neue Anforderungen an Testmethodiken und Testtools gestellt. Dabei nimmt die Bedeutung des Fahrzeugumfeldes immer weiter zu. In einem Umfeldsimulationstool kann man dieses Umfeld modellieren und in einem Test verwenden.
Das Umfeld besteht dabei in der Regel aus:
der Strecke (Straßengeometrie, Fahrbahnbelag, Straßenschilder, Ampeln, Bäume, …)
den beteiligten Akteuren (Ego-Fahrzeug, weitere Fahrzeuge, Fußgänger, …)
den konkreten Aktionen bzw. Manövern der Akteure (z.B. ein Einschervorgang)
Mit Hilfe der Toolkategorie Umfeldsimulationszugriff können Umfeldsimulationstools konfiguriert, parametriert und angesteuert werden.
Konfiguration:
Verwendung:
Umfeldkommunikationszugriff¶
Die Toolkategorie Umfeldkommunikationszugriff erlaubt die Verarbeitung von Umfeldinformationen durch den Empfang von nachrichtenbasierter Kommunikation.
Konfiguration:
Verwendung: