Workspace-Einstellungen

In den Workspace-Einstellungen können Meta-Informationen zum aktuellen Workspace (Hauptworkspace) hinterlegt werden.

Es kann ein Titel und eine Version für den Hauptworkspace eingetragen werden. Über die Option Ist eine Bibliothek wird festgelegt, dass der vorliegende Hauptworkspace von anderen Workspaces als Bibliotheksworkspace eingebunden werden kann. In diesem Fall muss ein eineindeutiger Namespace festgelegt werden, über welchen die Elemente des Workspace zugegriffen werden können. Dabei sollte es sich um einen Bezeichner handeln, der auch in Python ein gültiger Variablenname ist.

Info

Titel und Version haben bisher keinen funktionalen Hintergrund und werden nur in der Titelleiste von ecu.test und als Meta-Information bei der Konfiguration von Bibliotheksworkspaces angezeigt.

Verzeichnisse

Hier werden die ecu.test-Standardverzeichnisse für die Konfiguration, Packages, Testreports, Traceschrittvorlagen und Utilities eingestellt.

Alle Pfadangaben werden hier nach Möglichkeit relativ angegeben. Dies ermöglicht es, den Workspace ohne weitere Anpassungen komplett zu verschieben. Wird ein Standardverzeichnis außerhalb des Workspaces über die Schaltfläche Ordner wählen… angegeben, wird der Pfad absolut hinterlegt.

Im Folgenden werden die Auswirkungen der einzelnen Einstellungen vorgestellt:

Konfigurationsverzeichnis:

In diesem Verzeichnis liegen in ecu.test verwendete Testkonfigurationen und Testbenchkonfiguration

Packageverzeichnis:

In diesem Verzeichnis liegen Package- und Projektdateien

Testreportverzeichnis:

In diesem Verzeichnis legt ecu.test standardmäßig Testreports ab (kann durch die Testkonfiguration überschrieben werden)

Parameterverzeichnis:

In diesem Verzeichnis legt ecu.test standardmäßig Dateien für globale Konstanten und Mappingdateien ab.

Traceschrittvorlagenverzeichnis:

In diesem Verzeichnis liegen die Vorlagen für die Analyseschritte der Traceanalyse

Tracedateienverzeichnis

In diesem Verzeichnis liegen Tracedateien zur Verwendung in der Traceanalyse

Utility-Verzeichnis:

In diesem Verzeichnis liegen (Benutzer-) Utilities

Projektgeneratorenverzeichnis:

In diesem Verzeichnis liegen Parametersatz- und Packagegeneratoren zur Verwendung im Projekt (siehe Projektelemente)

Benutzer-Python-Bibliotheksverzeichnis:

In diesem Verzeichnis liegen Benutzer-Python-Bibliotheken

Vorlagenverzeichnis:

In diesem Verzeichnis liegen Package-, Projekt- und Reportvorlagen.

Offline-Modellverzeichnis:

In diesem Verzeichnis legt ecu.test alle Dateien ab, die für den Umgang mit verschiedenen Modellen (Modellzugriff - Modellsimulation) notwendig sind:

• *.cfg, *.sdf und *.trc für ControlDesk

• *.mdl, *.slx und *.m für MATLAB/Simulink

• *.dbc, *.xml für Vector: CANoe / CANalyzer

Offline-SGBD-Verzeichnis:

In diesem Verzeichnis liegen die *.xrg-Dateien für EDIABAS

Offline-Fehlersimulationsverzeichnis:

In diesem Verzeichnis liegen alle Dateien, die zur Fehlersimulation benötigt werden (*.fss, *.xml)

Bildverzeichnis:

In diesem Verzeichnis können Masken und Bilddateien abgelegt werden. Diese können zusammen mit Toolanbindungen verwendet werden, die das Lesen von Bildern unterstützen, beispielsweise tracetronic: Multimedia.

Externe Python-Bibliotheken:

In diesem Verzeichnis werden externe Python-Bibliotheken installiert, welche dann dem Anwender in ecu.test zur Verfügung stehen. Es kann nur in Unterordner des Workspaces oder in leere Ordner installiert werden. Nähere Informationen siehe Externe Python-Bibliotheken.

Wenn Verzeichnisse nicht auf dem lokalen PC liegen, ist die Angabe eines Netzlaufwerkes mittels UNC-Angabe (//Server/Freigabe) oder mittels fest verbundenem Laufwerksbuchstaben möglich.

Diese Einstellungen werden in der Datei directories.xml hinterlegt.

Bibliotheken

Hier können Abhängigkeiten zu anderen Bibliotheksworkspaces definiert werden.

Über den Button am unteren Rand kann eine Abhängigkeit hinzugefügt werden. Dies erfolgt über die Angabe des Pfades zum jeweiligen Verzeichnis. Dieses kann als absoluter Pfad oder relativ zum Hauptworkspace angegeben werden.

Über den Button wird ein Eintrag entfernt.

Über den Button oder durch Doppelklick kann der Pfad des aktuell markierten Eintrags verändert werden.

Info

Bei der Pfadangabe zum Bibliotheksworkspace spielt es keine Rolle, ob sich dieser außerhalb oder, wie im Tutorial Bibliotheksworkspace, innerhalb des Hauptworkspaces befindet.

Protokoll

Hier kann eingestellt werden, welche Meldungen im Meldungsfenster angezeigt werden. Dies geschieht zuerst durch die Auswahl der Stufe:

• Aus: es werden keine ecu.test-Meldungen ausgegeben

• Minimal: nur Fehlermeldungen werden ausgegeben

• Standard: Fehlermeldungen und wichtige Informationen werden ausgegeben

• Maximal: alle ecu.test-Meldungen werden ausgegeben

Die Stufe Maximal sollte nur in Ausnahmefällen verwendet werden, da sie zu einer großen Anzahl an Meldungen führt, die in der Regel nicht benötigt werden.

Über die Option Ausgabe-Logdateien synchron schreiben kann eingestellt werden, ob Einträge in die Logdatei blockierend geschrieben werden sollen. Das stellt sicher, dass die Logdatei immer den aktuellen Stand der Meldungen enthält, kann aber die Performance beeinträchtigen. Insbesondere wenn während der Testausführung viele Meldungen ausgegeben werden.

Unter Zusätzliche Ziele kann angegeben werden, ob Meldungen zusätzlich zum Meldungsfenster und den ecu.test-Logdateien auch über die Standardausgabe oder die Windows-Logging-Api ausgegeben werden sollen.

Im Abschnitt Inhalt können weitere Ausgaben aktiviert werden. Dies ist im Allgemeinen nur notwendig, wenn Sie hierzu durch den Support aufgefordert wurden.

Diese Einstellungen werden in der Datei protocol.xml hinterlegt.

Änderungen der Protokolleinstellungen werden für aktive Toolverbindungen erst nach einem Neustart der Tools übernommen.

Historie

Der erste Punkt dient zum Bereinigen der Listen zuletzt verwendeter Test- und Testbenchkonfigurationen. Bereinigen löscht nur die fehlerhaften Einträge (fehlende oder nicht-lesbare Dateien), wohingegen Leeren alle Elemente aus den Listen entfernt.

Hinweis: Damit werden nur die Elemente der Listen gelöscht, nicht aber die Dateien auf der Festplatte.

Im zweiten Teil kann man einstellen, wie viele Dateien in der Liste der zuletzt verwendeten Dateien angezeigt werden sollen. Außerdem kann man die bestehende Liste löschen oder bereinigen (nicht mehr vorhandene Elemente aus der Liste entfernen).

Diese Einstellungen werden in der Datei history.xml hinterlegt.

Testeditor

Package automatisch prüfen

Hier kann festgelegt werden, ob beim Einfügen einer Packagereferenz diese automatisch geprüft werden soll. Damit werden Fehler, wie fehlende Variablen oder Mappingreferenzen, sofort angezeigt.

Konsistenz von Übersetzungen prüfen

Diese Option sorgt dafür, dass bei jedem Speichervorgang überprüft wird, ob im aktuellen Package inkonsistente Übersetzungen vorhanden sind.

Rekursive Packageüberprüfung

Legt das Standardverhalten für Package prüfen fest.

Rekursive Projektüberprüfung

Legt das Standardverhalten für Projekt prüfen fest.

Mitgelieferte Überprüfung ausführen

Legt fest ob die Überprüfungen von ecu.test ausgeführt werden sollen.

Diese Einstellungen werden in der Datei testeditor.xml hinterlegt.

Testfallsprache

In der Einstellung Testfall-Sprache können mögliche Sprachen für den Testfalleditor aktiviert und deaktiviert werden. Diese Einstellung werden ohne Neustart wirksam. Zu jeder Zeit muss mindestens eine Sprache aktiviert sein. Daher kann die letzte aktivierte Testfallsprache nicht deaktiviert werden. Die aktuelle Testfallsprache kann in der Toolbar des Package-Editor gewählt werden. Wenn die aktuelle Testfallsprache deaktiviert wird, so wird automatisch die erste aktivierte Testfallsprache als neue aktuelle Testfallsprache gewählt.

Diese aktivierten Sprachen werden in der Datei testcaselanguages.xml hinterlegt.

Tags

Um die Informationen des Testreports übersichtlicher auswerten bzw. filtern zu können, können einzelne Test- und Traceschritte mit Attributen - so genannten Tags - gekennzeichnet werden. Die Liste an möglichen Tags kann an dieser Stelle verwaltet werden.

Wird ein Tag umbenannt oder entfernt, werden Test- und Traceschritte, welche diesen Tag verwenden, nicht aktualisiert. Enthält ein Package Tags, welche nicht in den Einstellungen definiert wurden, werden diese zusätzlich in den Editoren angeboten.

Diese Einstellungen werden in der Datei tags.spec hinterlegt.

Testausführung

Allgemein

Hier kann folgendes festgelegt werden:

• ob sich das Echtzeit-Log Fenster bei jeder Testausführung automatisch öffnen soll

• ob die Generierung zusätzlicher Reportformate (z.B HTML, TXT) in einen eigenen Prozess ausgelagert werden soll

• Dies beschleunigt die Abarbeitung von Projekten falls diese separat ausgeführte Subprojekte (siehe Projektreferenz) enthalten, da die Generierung der Reportformate parallel zur Ausführung der nächsten Projektschritte stattfinden kann.

• Es ermöglicht ebenfalls ecu.test direkt nach der Testausführung, unabhängig von der laufenden Generierung von Reports, wieder zu verwenden.

• ob Analysejobs auch nach abgebrochenen oder fehlgeschlagenen Testschritten ausgeführt werden sollen

• Falls der Nutzer manuell den Test abbricht, werden keine Analysejobs ausgeführt.

• ob die während der Ausführung erzeugten Analyse-Job-Dateien (*.ajob) sowie deren zugehörige Testreport-Dateien (*.trf) gelöscht werden sollen, nachdem sämtliche Informationen daraus automatisch in den Hauptreport übernommen wurden.

• ob bei der unterstützten Bewertung für den Typ Numeric (z.B. im Lesen-Testschritt) ganze Fließkommazahlen oder nur 14 signifikante Stellen der Fließkommazahlen berückstichtigt werden

• Damit können Probleme, die durch die Fließkomma-Arithmetik entstehen, vermieden werden (Bsp.: der Python-Ausdruck ‚50.1-50.0==0.1‘ wird zu falsch ausgewertet)

• Achtung: auf manuelle Bewertungen hat diese Einstellung keinen Einfluß!

• ob beim Teststart geprüft werden soll, ob dem Benutzer ein Warnhinweis gezeigt werden soll, falls eine Testkonfiguration zwar ausgewählt aber nicht gestartet ist

• ob Packages/Projekte vor der Ausführung geprüft werden sollen

• Wenn ein Fehler gefunden wird, öffnet sich ein Dialog mit den gefundenen Fehlern.

• Wenn keine Fehler gefunden werden, erscheint kein zusätzlicher Dialog.

• Falls ecu.test im automatischen Modus gestartet wurde, findet unabhängig von dieser Einstellung keine Prüfung statt.

Projektausführung

Hier kann folgendes festgelegt werden:

• ob der Projektreport nach jedem Projektschritt aktualisiert werden soll:

• Ist diese Einstellung aktiv, kann der Projektreport während der Projektausführung ohne Verzögerung geöffnet werden. Andernfalls muss gewartet werden, bis der aktuelle Projektschritt abgeschlossen ist.

• Das Aktivieren der Einstellung führt zu einer verlangsamten Projektausführungsgeschwindigkeit je mehr Projektschritte ausgeführt werden.

• Das .prf-Projektreportformat wird immer nach jedem Testschritt geschrieben, wobei die Subreporte im .trf-Format von dieser Option beeinflusst werden.

• Der alte .trf-Projektreport wird ebenfalls beeinflusst.

• ob bei der Projektausführung Unterprojekte standardmäßig separat ausgeführt werden sollen

• ob bei separater Ausführung von Unterprojekten die Ausführungsdialoge automatisch geschlossen werden sollen

• ob die Anzeigetiefe des Ausführungsdialogs zur Speicherbedarfsoptimierung eingeschränkt werden soll

• Diese Einstellung wird im interaktiven Ausführungsmodus ignoriert.

Garbage Collector

Hier kann festgelegt werden ob die normale Funktion des Python Garbage Collector für bessere Latenz während der Testfallausführung optimiert werden soll. Diese Expertenfunktion sollte auf default verbleiben und ist nur bei unerwarteten Verzögerungen während des Testfalls zu nutzen. Diese Optimierung geschieht auf Kosten des Speicherverbrauchs.

Diese Einstellungen werden in der Datei testexecution.xml hinterlegt.

Interaktive Testausführung

Legt Einstellungen für die interaktive Testausführung fest:

• Ob in interaktiven Blöcken ‚Aktion:‘ und ‚Erwartung:‘ vor die angezeigten und vorgelesenen Texte gestellt werden soll.

Sprachausgabe

Hier lässt sich festlegen, ob die Testfallausführung während der Sprachausgabe fortgesetzt werden soll. Diese Option bewirkt, dass beispielsweise während der Block-Testschritt noch vorgelesen wird, bereits der enthaltene Berechnungs-Testschritt ausgeführt wird.

Zudem kann konfiguriert werden, ob eine Ansage nach einer bestimmten Zeit wiederholt werden soll.

Auch die verfügbaren Vorlesestimmen für Interaktives Testen werden hier hinterlegt. Zur Auswahl stehen standardmäßig die auf dem System installierten Stimmen von Microsofts SAPI. Die Liste kann mit benutzerdefinierten Text-to-Speech Diensten erweitert werden. Für mehr Informationen siehe Nutzerdefinierte Sprachausgabe. Ist eine eingestellte Stimme nicht (mehr) vorhanden, so wird automatisch stattdessen die Standardstimme genutzt.

Tastenbelegung

Hier können verschiedene Aktionen im Ausführungsdialog der interaktiven Ausführung mit Tastaturkürzeln belegt werden.

Textbausteine

Es können Textbausteine hinterlegt werden, welche über eine festgelegte Tastenkombination automatisch in das Bemerkungsfeld des aktuellen Testschritts eingefügt werden.

Diese Einstellungen werden in der Datei interactiveexecution.xml hinterlegt.

Traceanalyse

Hier kann festgelegt werden, wie sich die Traceanalyse in verschiedenen Situationen verhalten soll.

Allgemein

In dieser Kategorie lassen sich allgemeine Einstellungen zur Analyseausführung festlegen.

Zeitstempel runden

Zeitstempel eingelesener und berechneter Signale werden auf eine festgelegte Anzahl von Nachkommastellen gerundet, um eine Vergleichbarkeit der Zeitachsen zu gewährleisten.

Signale cachen

Wenn diese Option aktiv ist, werden Signale während der Ausführung eines Projektes in einem Cache gehalten. Dadurch beschleunigt sich der Zugriff auf Signale, wenn diese in mehreren Episoden, Traceanalysen oder Packages verwendet werden, was einen positiven Einfluss auf die Ausführungsgeschwindigkeit von Traceanalysen haben kann. Am Ende der Projektausführung wird der Cache geleert. Bei großen Projekten, die sehr viele Signale verwenden, kann es zu Speicherengpässen kommen. In solch einem Fall sollte diese Einstellung deaktiviert werden. Alternativ, kann der Cache während der Projektausführung manuell geleert werden, in dem man in einem Package die Methode ClearSignalCache() der Internal API aufruft.

Fehlermeldungen bei zu kurzem Payload-Bereich unterdrücken

Legt fest, ob Fehlermeldungen unterdrückt werden sollen, falls die tätsächliche Payload-Länge kürzer ist als die von der Bus-Datenbank angegebene Payload-Länge (Nur ASC, BLF, MDF4).

ASC, BLF, GIN: Doppelte Zeitstempel in Dateien korrigieren

Legt fest, wie ecu.test damit umgehen soll, wenn sich in einer Datei Zeitstempel doppeln und dadurch für ein Signal für einen Zeitpunkt theoretisch mehrere Messwerte vorhanden sind. Ist diese Option nicht aktiv, wird ecu.test die Analyse mit einem Fehler abbrechen. Ist die Option aktiv, wird ecu.test gleiche Zeitstempel durch Einfügen von Mikrozeitschritten von 0.0000001 Sekunde voneinander separieren.

ETHERNET, DLT: Zeitstempel über gleitendes Fenster sortieren

Nur PCAP, MDF4 und DLT: Bedingt durch Interna der Netzwerkkommunikation oder der Aufzeichnung kann es vorkommen, dass Botschaften in Buslogging-Dateien zeitlich unsortiert vorliegen. Durch diese Option wird während des Einlesens ein gleitendes Fenster gepflegt, in dem Einträge zeitlich sortiert werden. Die Fenstergröße gibt vor, nach wievielen nachfolgenden Paketen ein Paket mit früherem Zeitstempel noch korrekt einsortiert werden kann. Ein größeres Fenster sorgt folglich für mehr Robustheit.

Die Größe des Fensters kann das SOME/IP TP Assembling und somit die Anzahl der SOME/IP Samples beeinflussen.

PCAP: Intelligente Filterung von SOME/IP-Botschaften

Ist diese Einstellung aktiviert, wird ein effizienter Filter anhand der SOME/IP-Kommunikation über die parametrierte Dauer angelernt. Durch Verwendung des Filters verringert sich die Dauer des Einlesens von SOME/IP-Botschaften.

Typischerweise reicht eine Dauer von etwa 2 Sekunden, sodass alle relevanten Service-Provider erfasst und in den Filter aufgenommen werden können. Services, welche erst nach der Anlernphase bereitgestellt werden, werden unter Umständen herausgefiltert.

PDU Update-bit ignoreren

Das Update-Bit einer PDU zeigt an, ob sich die enthaltenen Daten verändert haben. Ist die Option aktiviert, werden PDUs unabhängig vom Update-Bit eingelesen und ausgewertet. Andernfalls geschieht dies nur wenn das Bit auf 1 gesetzt ist.

Diese Einstellung findet nur Verwendung, wenn botschaftsbasierte Daten eingelesen werden.

Fehlermeldung für fehlerhafte PDUs unterdrücken

Standardmäßig führen fehlerhafte PDUs, z.B. aufgrund ungültiger Länge, zu einem Fehler. Diese Einstellung gibt an, dass statt eines Fehlers lediglich eine Warnung im Log ausgegeben und die entsprechende PDU ignoriert werden soll.

Diese Einstellung findet nur Verwendung, wenn botschaftsbasierte Daten eingelesen werden.

Fallback auf Rohwerte …

Legt fest, wie mit Signalen verfahren werden soll, deren Rohwerte sich nicht in physikalische Werte umrechnen lassen. Ist die Option aktiv, wird in diesem Fall stattdessen automatisch der Rohwert verwendet. Andernfalls wird im Report ein ERROR mit einem entsprechenden Fehlerhinweis gemeldet. (Nur PCAP, ASC, BLF, MDF 3/4, TTL)

Parallele Analyse-Job-Abarbeitung in Projekten

In dieser Kategorie lassen sich die Anzahl an parallelen Prozessen für die Abarbeitung und deren Prozesspriorität einstellen. Die Anzahl an Prozessen ist auf die Anzahl an CPU-Kernen des Systems begrenzt.

Report

In dieser Kategorie lassen sich Einstellungen setzen, welche Einfluss auf den resultierenden Report der Traceanalyse haben.

Dargestellte Zeitstempel auf Nachkommastellen runden

Anhand dieser Einstellung kann die Anzahl der dargestellten Nachkommastellen für Zeitstempel im Report festgelegt werden.

Achtung: Es wird nur ein neu erstellter Report beeinflusst!

Relevante Stellen im Report:

• Tabelle der Fundstellen in den Reportdetails

• Automatisch erzeugte Titel in Plots

Die Genauigkeit der Darstellung ist durch Gleitkommarithmetik begrenzt (genauer durch die Anzahl der signifikanten Stellen).

Verwendete Signale im trace.xplorer-Format ablegen

Die in der Traceanalyse verwendeten Signale werden zusätzlich im Dateiformat *.astrace gespeichert. Diese Option ist empfohlen, wenn als Signalbetrachter der trace.xplorer basic oder der trace.xplorer verwendet wird (siehe Sektion Mitgelieferte Programme in den lokalen Einstellungen).

trace.xplorer-Format (*.astrace)

In dieser Kategorie können Optionen zur automatischen Konvertierung von Daten beim Schreiben von *.astrace-Dateien gesetzt werden. Diese Einstellungen sind auch bei Verwendung des Traceschrittes Signalexport (Signalaufnahme) wirksam.

• Numerische Signale, die nur die Werte 0 und 1 enthalten, als Binärsignale speichern

• Fließkomma-Signale, die nur ganzzahlige Werte enthalten, als Ganzzahl-Signale speichern

• String-Signale, die nur numerische Werte enthalten, als Ganzzahl- oder Fließkomma-Signale speichern

• String-Signale speichern

Diese Einstellungen werden in der Datei analysisexecution.xml hinterlegt.

Versionsverwaltung

Hier können verschiedene Optionen zur Anbindung einer Versionsverwaltung festgelegt werden.

Versionsverwaltungssysteme

Im ersten Abschnitt kann das verwendete Versionsverwaltungssystem ausgewählt werden. Derzeit werden SVN und Git unterstützt. Die Programme sind im Internet frei verfügbar und können auf den jeweiligen Webseiten heruntergeladen werden.

SVN

Um SVN nutzen zu können, muss auf dem PC TortoiseSVN installiert sein. ecu.test verwendet die „command line client tools“ von TortoiseSVN. Sind diese installiert, wird jede SVN-Version unterstützt.

Git

ecu.test benötigt mindestens eine Installation der Kommandozeilenanwendung „git“ in der Version 2.11 oder neuer. Um die Git-Integration in ecu.test vollumfänglich zu nutzen, wird zusätzlich TortoiseGit benötigt.

Git ohne TortoiseGit

Das Verzeichnis, in dem sich git bzw. die git.exe befindet, muss in der PATH Variablen hinterlegt sein. Git ist unter Windows und Linux verfügbar.

Git mit TortoiseGit

Zusätzlich zur Git-Installation muss TortoiseGit installiert sein. TortoiseGit ist unter Windows verfügbar.

Funktionsumfang

Wird Git ohne TortoiseGit verwendet, steht die Versionsverwaltung in eingeschränktem Umfang zur Verfügung. Status, Revision und Url verwendeter Packages werden im Report hinterlegt. Für Icons, Kontextmenü-Einträge, Dateioperationen sowie die weiterführenden Funktionen zur automatischen Überprüfung, dem automatischen Hinzufügen neuer Dateien und ecu.test als Diff-Tool wird TortoiseGit benötigt.

Info

ecu.test ermittelt automatisch, ob zusätzlich zu Git TortoiseGit verfügbar ist.

Automatische Überprüfung

Im zweiten Einstellungsfeld Automatische Überprüfung lässt sich der automatische Abgleich von Arbeitskopie und Repository für einzelne Verzeichnisse (derzeit nur das Package-Verzeichnis) aktivieren bzw. deaktivieren. Ist die automatische Überprüfung für ein Verzeichnis, z. B. das Package-Verzeichnis, aktiviert, so prüft ecu.test bei jedem Start, ob sich im Repository aktuellere Dateien als im lokalen Arbeitsverzeichnis befinden. Außerdem überprüft ecu.test vor dem Beenden, ob das Arbeitsverzeichnis geänderte Dateien enthält, die noch nicht ins Repository übertragen wurden. Ein Dialog informiert über vorliegende Aktualisierungen bzw. Änderungen und bietet über einen Button die Möglichkeit zum Update bzw. Commit an (Update und Commit werden also nur auf Anwenderwunsch durchgeführt).

Info

Damit Automatische Überprüfung durchgeführt wird, muss das betroffene Verzeichnis (z. B. das Package-Verzeichnis) unter Versionsverwaltung stehen.

Optionen

Das Einstellungsfeld Optionen bietet Möglichkeiten, die Versionsverwaltungssysteme zu konfigurieren. Aktiviert man das Feld Neue Dateien / Verzeichnisse autom. unter Versionsverwaltung stellen werden Dateien und Verzeichnisse die in ecu.test neu angelegt, verschoben oder kopiert werden, automatisch für das Repository aktiviert, damit diese Dateien beim nächsten Übertragen mit in das Versionsveraltungssystem übernommen werden.

Diff-Tool

Beim gleichzeitigen Arbeiten an einem Package durch verschiedene Personen kann es zu Konflikten kommen. Diese werden durch SVN bzw. Git direkt in der Datei markiert. Durch diese Änderungen am Package kann ecu.test das Package bis zum Auflösen des Konflikts nicht mehr öffnen und meldet, dass das Package defekt ist.

Auf dieser Registerkarte kann auch das interne Tool ecu.test Diff Viewer als externer Diff-Viewer zum Vergleich von Packages und anderen Artefakten in TortoiseSVN bzw. Git oder TortoiseGit hinterlegt werden (siehe Diff Viewer).

Diese Einstellungen werden in der Datei versioncontrolsystem.xml im Workspace hinterlegt.

Report

Hier kann eingestellt werden, ob Testreports beim Öffnen auf ihre Echtheit geprüft werden sollen.

Die Einstellungen zur Reportprüfung werden in der Datei reportauthenticity.xml hinterlegt.

Ferner kann hier eingestellt werden, ob das neue, JSON-basierte Format .prf für Projektreporte verwendet werden soll. Es speichert die Ergebnisse aller Projektschritte und verweist pro Package auf einen .trf-Report mit den Ergebnisse der einzelnen Testschritte. Das neue .prf-Format bietet insbesondere in Zusammenhang mit test.guide Vorteile gegenüber den bisher für Projekte eingesetzten monolithischen .trf-Reporten und ist ab ecu.test 2024.3 das Standardformat für Projektreporte.

Die Einstellungen zum Projektreport werden in der Datei report.xml hinterlegt.

Systembezeichner

Hier können die Systembezeichner, zur Verwendung in der Testkonfiguration, auf den Tabs Plattform, Steuergeräte und Buszugriff konfiguriert werden.

Wählen Sie zuerst auf der rechten Seite oben die gewünschte Gruppe aus (Modell, Fehlersimulation, Steuergeräte, Busse).

Darunter sehen Sie die momentan in dieser Gruppe vorhandenen Bezeichner. Um einen neuen Bezeichner anzulegen, vorhandene zu löschen sowie die Reihenfolge zu ändern, klicken Sie unten rechts auf Bezeichner editieren.

Im sich öffnenden Fenster befinden sich oben rechts vier Schaltflächen zur Bearbeitung der Bezeichner:

• Neu erstellen

• Löschen

• Nach oben verschieben

• Nach unten verschieben

Diese Einstellungen werden in der Datei systemidentifiers.xml hinterlegt.

Python-Bibliotheken

Unter diesem Punkt sind die Einstellungen zum Import von Python-Bibliotheken zu finden.

Diese Einstellungen werden in der Datei pythonlibrary.xml hinterlegt.

Nähere Informationen sind im Kapitel Externe Python-Bibliotheken zu finden

Cache-Synchronisation

Um den lokalen Aufwand für das Einlesen einzusparen, können bereits erstellte Cachedateien ausgetauscht werden. Hierfür kann entweder ein gemeinsames Austausch-Verzeichnis oder ein test.guide-Depository angegeben werden.

Info

Ist eine Cache-Synchronisation nicht möglich, beispielsweise aufgrund von Netzwerkstörungen, können weiterhin lokale Caches erstellt und verwendet werden.

• Austauschverzeichnis

  Dieses Verzeichnis kann auf dem lokalen Rechner oder auf einem Netzlaufwerk liegen.

• test.guide Depository

  Hier kann ein test.guide Depository ausgewählt werden. Neue Depositories können auf der Seite test.guide Artefakte erstellt werden.

test.guide-Reports

In diesen Einstellungen kann der automatische Upload von Reports konfiguriert werden. Details finden sich noch in test.guide-Reports.

Für Verbindungseinstellungen siehe Verbindungseinstellungen.

test.guide-Artefakte

Hier können test.guide Depositories konfiguriert werden. Diese können dann z.B. als Ablageort für die Cache-Synchronisation verwendet werden.

Info

Diese Einstellungen sind unabhängig von den Workspace-Einstellungen für die Testreportverwaltung im Bereich test.guide-Reports.

Für Verbindungseinstellungen siehe Verbindungseinstellungen.

test.guide Test Infrastruktur

Auf dieser Einstellungsseite können Sie den Port konfigurieren, über den ecu.test seinen Ausführungsstatus an den test.guide ResourceAdapter sendet. Um diese Funktion zu verwenden, muss das RestApiActivityPlugin in der ResourceAdapter-Konfiguration aktiviert werden. Weitere Informationen zum ResourceAdapter finden Sie in der test.guide-Hilfe.

Die Einstellungen werden in der Datei testguideti.xml hinterlegt.

ecu.test lab

Die folgenden Server-Einstellungen für ecu.test lab können auf dieser Seite gesetzt werden:

• Server automatisch starten

• Passwort

• HTTP-Port

• Standard-View festlegen

Die Einstellungen werden in der Datei ecuTestLab.xml gespeichert.

ecu.test drive

The server settings for ecu.test drive can be set here:

• Server automatisch starten

• Passwort

• HTTP-Port

Die Einstellungen werden in der Datei ETdrive.xml gespeichert.

Credentials

ecu.test bietet die Möglichkeit Zertifikate, private Schlüssel, Access Tokens, Secrets, etc. zu verwalten und geschützt im Workspace abzulegen.

Vault

Der Vault ist eine per Passwort verschlüsselte Datei. In dieser können schützenswerte Informationen, z. B. Access Tokens oder Passwörter für PKCS12-Dateien, hinterlegt werden.

In den Workspace-Einstellungen lässt sich der Vault organisieren. In den Pfadeinstellungen kann ein neuer Vault angelegt, ein bereits bestehender Vault geöffnet oder ein zum Workspace zugordneter Vault wieder entfernt werden. Sobald ein Vault dem Workspace zugeornet ist, kann dieser mit dem Passwort entsperrt oder wieder gesperrt werden.

Sobald der Vault zugeordnet und entsperrt ist, lassen sich Einträge anzeigen, hizufügen oder löschen. Auf alle Vault-Einträge lässt sich während der Testfallausführung dynamisch per API zugreifen: Credentials-API.

Info

ecu.test lässt maximal einen gleichzeitig geöffneten Vault zu.

Keystores

Zertifikate und private Schlüssel können in Keystores organisiert werden. Implementiert ist derzeit das PKCS12-Format, welches mit einem Passwort versehen werden kann. Während der Testfallausführung kann dynamisch auf die Inhalte der PCKS12-Dateien zugegriffen werden.

PKCS12-Dateien lassen sich auf zwei Arten in den Vault einbinden:

• Eine neue PKCS12-Datei wird mit den entsprechenden Zertifikaten und dem privaten Schlüssel erstellt. Die Zugangsdaten werden anschließend automatisch im Vault gespeichert.

• Eine bereits existierende PKCS12-Datei wird in den Vault geladen. Die entsprechenden Zugangsdaten werden automatisch im Vault gespeichert.

Secrets

Secrets in Form von beliebigen Python-Strings können direkt im Vault gespeichert werden. Dies ist z B. für Access Tokens von besonderem Interesse.

Tester Key

Der Tester Key ist ein vom Vault generierter Schlüssel, der zusätzlich zum Passwort Lesezugriff auf die Vault-Daten erlaubt. Beim Öffnen kann dieser anstelle des Passworts angegeben werden.

Der Tester Key ist für die Verwendung in Testfällen konzipiert und ermöglicht ein effizienteres und schnelleres Öffnen des Vaults (Das Öffnen mit dem Passwort verbraucht aus Sicherheitsgründen kurzzeitig ca. 2 GB RAM). Unbeabsichtigte Modifikationen am Vault werden ebenfalls unterbunden, sodass für die Verwaltung des Vaults, z. B. dem Hinzufügen oder Entfernen von Einträgen, das Passwort notwendig ist.

Security

Sobald der Vault geöffnet wurde, sind die darin gespeicherten Daten für Dritte mit Zugriff auf ecu.test frei zugänglich bis die Anwendung geschlossen wurde. Für den Zugriffsschutz während der Verwendung der Vault ist der Nutzer verantwortlich.

Der Tester Key stellt kein kryptographisch abgesichertes Rollensystem dar, sondern ist dazu gedacht, den Testbetrieb- und ausführung zu optimieren und zu erleichtern. Der ausschließliche Lesezugriff wird im Wesentlichen durch die ecu.test Runtime erzwungen.

Für die kryptographischen Methoden wurde auf etablierte Bibliotheken wie z.B. cryptography gesetzt.

Info

Beim Anlegen des Vault Passworts wird die Passwortqualität nicht überprüft!

ecu.test agent

Siehe ecu.test agent.

Die Einstellungen werden in der Datei agent.xml gespeichert.

2025-12-05