Mit durchgängigen Workflows und höchstfunktionalen Schnittstellen für die flexible Anbindung weiterer Werkzeuge verstehen wir die Automotive DevOps Platform als eine Kollaborationsplattform für alle Stakeholder im DevOps-Prozess der Fahrzeugentwicklung.
Gezielt streben wir eine enge Zusammenarbeit bei der Entwicklung von Testfällen (Dev) und deren Ausführung (Ops) an, die auf direktem Feedback und lückenloser Traceability basiert. Wichtig sind dafür spezielle Plattform-Features, die den Fokus auf übergreifende Arbeitsabläufe legen.
Automotive DevOps Platform
Unsere Tools passen in jede Phase des automatisierten Testens von Fahrzeugsoftware. Werden sie miteinander verknüpft, erreichen sie als Automotive DevOps Platform ein Höchstmaß an Wirkung.
DevOps bei tracetronic
Mit der Automotive DevOps Platform gehen wir vom großen Ganzen bis ins Detail und vereinen alle Phasen des Testens von Fahrzeugsoftware – von der Planung der Testumfänge bis zur Zusammenfassung der Testergebnisse. Gleichzeitig bietet das durchgängige Monitoring über alle Testphasen hinweg stets den Überblick über alle Aktivitäten - auch bei mehreren tausend Ausführungen am Tag und in unterschiedlichen Testumgebungen.
Planung der Testumfänge
In der Planungsphase werden die Testumfänge innerhalb einer Teststufe festgelegt.
Die Basis bilden Anforderungen, die aus verschiedensten Quellen eingelesen werden können – über Direktanbindung von ALM-Tools (z. B. Octane, IBM RQM, Polarion), einer eigenen API oder durch Import verschiedener Austauschformate (z. B. ReqIF).
Wird die Testsuite für eine neue Anforderung konzipiert, werden die relevanten Tests und die zugehörige Menge aller möglichen Parameterwerte (Parameterräume) festgelegt. Es wird geplant, was mit welchen Testfällen in physischen (HiL) oder virtuellen Umgebungen (MiL, SiL) getestet werden soll. Dabei steht jederzeit eine aktuelle Übersicht der Testumfänge sowie der Stand des Testprozesses nachvollziehbar zur Verfügung.
Die Basis bilden Anforderungen, die aus verschiedensten Quellen eingelesen werden können – über Direktanbindung von ALM-Tools (z. B. Octane, IBM RQM, Polarion), einer eigenen API oder durch Import verschiedener Austauschformate (z. B. ReqIF).
Wird die Testsuite für eine neue Anforderung konzipiert, werden die relevanten Tests und die zugehörige Menge aller möglichen Parameterwerte (Parameterräume) festgelegt. Es wird geplant, was mit welchen Testfällen in physischen (HiL) oder virtuellen Umgebungen (MiL, SiL) getestet werden soll. Dabei steht jederzeit eine aktuelle Übersicht der Testumfänge sowie der Stand des Testprozesses nachvollziehbar zur Verfügung.
Testfallentwicklung
In diesem Schritt liegt der Fokus auf der Entwicklung und Verwaltung von anforderungs- und erfahrungsbasierten sowie wiederverwendbaren Testfällen für die automatisierte Ausführung in physischen (HiL) sowie virtuellen Testumgebungen (SiL, MiL).
Mit jeder neuen Anforderung seitens der Fahrzeughersteller werden Softwarefunktionen für Steuergeräte entwickelt, die anhand von Testsuiten abgesichert werden müssen. Der Umfang dieser Testsuiten ist dabei variabel und abhängig von der Komplexität der Fahrzeugfunktion. Mindestens die definierten Vorgaben gesetzlicher Standardnormen zu den neu entwickelten Fahrzeugfunktionen müssen dabei durchgetestet werden. Das kann in Form vieler realer und virtueller Fahrkilometer erfolgen, aber auch anhand verschiedener Szenarien, in denen die neuen Fahrfunktionen kritisch geprüft und eingehend bewertet werden.
Mit jeder neuen Anforderung seitens der Fahrzeughersteller werden Softwarefunktionen für Steuergeräte entwickelt, die anhand von Testsuiten abgesichert werden müssen. Der Umfang dieser Testsuiten ist dabei variabel und abhängig von der Komplexität der Fahrzeugfunktion. Mindestens die definierten Vorgaben gesetzlicher Standardnormen zu den neu entwickelten Fahrzeugfunktionen müssen dabei durchgetestet werden. Das kann in Form vieler realer und virtueller Fahrkilometer erfolgen, aber auch anhand verschiedener Szenarien, in denen die neuen Fahrfunktionen kritisch geprüft und eingehend bewertet werden.
Entwicklung von Traceanalysen
Während der Durchführung eines Testfalls werden Messdaten – Traces – aufgezeichnet. Dabei werden zahlreiche Aufzeichnungsformate (z. B. MAT, ASC, MDF, MP4, WAV) unterstützt. Diese Traces bis ins Detail und hinsichtlich unterschiedlicher Kriterien zu untersuchen, ist Aufgabe der Traceanalyse. Sie beginnt mit den Anforderungen, die an einen Signalverlauf gestellt werden und endet mit der vollautomatischen Erstellung eines Testreports. Ziel ist es, mehrere Traces unterschiedlicher Aufnahmequellen entlang einer gemeinsamen, synchronisierten Zeitachse zu analysieren.
Die Entwicklung von Traceanalysen ähnelt der Testfallentwicklung – sowohl in der Logik als auch in der Abfolge. Messpunkt für Messpunkt werden die aufgezeichneten Signale verschiedener Werkzeuge unabhängig vom Messraster analysiert. Aussagekräftige Diagramme helfen dabei, schnell einen Überblick zu erlangen, wo Abweichungen in den Signalverläufen zu den gegebenen Anforderungen auftreten.
Die Entwicklung von Traceanalysen ähnelt der Testfallentwicklung – sowohl in der Logik als auch in der Abfolge. Messpunkt für Messpunkt werden die aufgezeichneten Signale verschiedener Werkzeuge unabhängig vom Messraster analysiert. Aussagekräftige Diagramme helfen dabei, schnell einen Überblick zu erlangen, wo Abweichungen in den Signalverläufen zu den gegebenen Anforderungen auftreten.
Testausführung
Die intelligente und integrierte Testausführung sorgt dafür, dass die Tests automatisch an verfügbare Prüfplätze verteilt werden.
Zu jedem Zeitpunkt kann eine bestmögliche Auslastung sichergestellt und der aktuelle Status der Testressourcen überwacht werden.
Zu jedem Zeitpunkt kann eine bestmögliche Auslastung sichergestellt und der aktuelle Status der Testressourcen überwacht werden.
Ausführung von Traceanalysen
Test und Analyse gehören zusammen wie Anfahren und Abbremsen. Allerdings muss beides nicht zwingend unmittelbar nacheinander durchgeführt werden. So kann auch die Analyse der Traces nachgelagert erfolgen - und zwar auf jedem beliebigen PC. Begehrte Prüfstände stehen dadurch schneller wieder für Tests zur Verfügung und auch der Testdurchsatz erhöht sich signifikant.
Beim Testdurchlauf entstandene Aufnahmen und definierte Traceanalysen werden automatisch als Analyseauftrag an test.guide übergeben. Das Tool organisiert dann verfügbare Ressourcen für die Traceanalyse wieder mithilfe des ResourceAdapters selbstständig.
Erfüllt das Testobjekt die Testspezifikation? Funktioniert die Messeinrichtung korrekt? Wurde der richtige Messbereich gewählt? Sämtliche Details der Traceanalyse und der Stimulation werden übersichtlich in einem Testbericht für jeden einzelnen Analyseschritt dargestellt und automatisch in test.guide hinterlegt.
Beim Testdurchlauf entstandene Aufnahmen und definierte Traceanalysen werden automatisch als Analyseauftrag an test.guide übergeben. Das Tool organisiert dann verfügbare Ressourcen für die Traceanalyse wieder mithilfe des ResourceAdapters selbstständig.
Erfüllt das Testobjekt die Testspezifikation? Funktioniert die Messeinrichtung korrekt? Wurde der richtige Messbereich gewählt? Sämtliche Details der Traceanalyse und der Stimulation werden übersichtlich in einem Testbericht für jeden einzelnen Analyseschritt dargestellt und automatisch in test.guide hinterlegt.
Review der Testergebnisse
Je weiter die Automatisierung von Testdurchführungen voranschreitet, umso höher ist auch der Testdurchsatz. Unzählig viele Testergebnisse müssen folglich gesichtet und bewertet werden. Ohne Tool-Unterstützung ist das nicht mehr zu bewerkstelligen.
Neben vielfältigen Filtermöglichkeiten für einen detaillierten Blick auf die entstandenen Ergebnisse, verfügt test.guide über einen integrierten Korrekturvorgang – dem Review. Dieses hilft dabei, Fehler und Inkonsistenzen während des Tests von Fahrzeugsoftware zu erkennen und deutlich sichtbar darzustellen. Auftretende Fehler können erfasst und an ein angebundenes Ticketsystem (z. B. Jira, Redmine, Octane usw.) direkt weitergeben werden.
Neben vielfältigen Filtermöglichkeiten für einen detaillierten Blick auf die entstandenen Ergebnisse, verfügt test.guide über einen integrierten Korrekturvorgang – dem Review. Dieses hilft dabei, Fehler und Inkonsistenzen während des Tests von Fahrzeugsoftware zu erkennen und deutlich sichtbar darzustellen. Auftretende Fehler können erfasst und an ein angebundenes Ticketsystem (z. B. Jira, Redmine, Octane usw.) direkt weitergeben werden.
Release des Softwarestands
Das Release bildet die Klammer um alle Testaktivitäten.
Die Zusammenfassung der Testergebnisse in Release- und Coverage-Übersichten basiert auf den anfangs festgelegten Testumfängen.
Die Verbindung zwischen Planung, Durchführung und Ergebnis bildet die Grundlage, um aussagekräftige Abschlussberichte zu erstellen.
Die Zusammenfassung der Testergebnisse in Release- und Coverage-Übersichten basiert auf den anfangs festgelegten Testumfängen.
Die Verbindung zwischen Planung, Durchführung und Ergebnis bildet die Grundlage, um aussagekräftige Abschlussberichte zu erstellen.
Monitoring über Testinfrastruktur und Testergebnisse
Das Monitoring ist eine entwicklungsbegleitende, kontinuierliche Phase, die einen Überblick über alle Testaktivitäten von der Planung bis hin zur Zusammenfassung der Testergebnisse bietet.
Welche Prüfstände sind angebunden? In welchem Zustand ist der Prüfstand? Welcher Testfall wird gerade wo ausgeführt? Wie hoch ist die Testfallabdeckung? Und welche Testausführungen sind „failed“? Innerhalb der Automotive DevOps Platform übernimmt dieses umfassende Monitoring test.guide.
Welche Prüfstände sind angebunden? In welchem Zustand ist der Prüfstand? Welcher Testfall wird gerade wo ausgeführt? Wie hoch ist die Testfallabdeckung? Und welche Testausführungen sind „failed“? Innerhalb der Automotive DevOps Platform übernimmt dieses umfassende Monitoring test.guide.
Plattform-Features
Ausführungsverteilung
Stell dir vor, tausende Testfälle über den gesamten Release-Prozess so effizient, also so zeit- und ressourcenoptimiert, wie möglich auszuführen. Dann laufen Testausführungen in der richtigen Reihenfolge und in der richtigen Testumgebung parallel, automatisiert und rund um die Uhr.
Schnell und kontinuierlich gibt es Feedback, keine Leerlaufzeiten der Testressourcen und einen Hub in Sachen Entwicklungsgeschwindigkeit. Geht nicht? Geht!
Wir haben die perfekte Lösung entwickelt und erfolgreich getestet – die Ausführungsverteilung mit ecu.test und test.guide.
In der Praxis wird die Suche nach dem perfekten Match von Testauftrag und Prüfstand nach wie vor meist manuell vorgenommen, aber das ist wenig effizient. Mit der Ausführungsverteilung ist diese Zuordnung automatisiert möglich. Die Einrichtung bedarf nur weniger Schritte:
Schnell und kontinuierlich gibt es Feedback, keine Leerlaufzeiten der Testressourcen und einen Hub in Sachen Entwicklungsgeschwindigkeit. Geht nicht? Geht!
Wir haben die perfekte Lösung entwickelt und erfolgreich getestet – die Ausführungsverteilung mit ecu.test und test.guide.
In der Praxis wird die Suche nach dem perfekten Match von Testauftrag und Prüfstand nach wie vor meist manuell vorgenommen, aber das ist wenig effizient. Mit der Ausführungsverteilung ist diese Zuordnung automatisiert möglich. Die Einrichtung bedarf nur weniger Schritte:
- 1. ecu.test installieren
- 2. test.guide installieren
- 3. ResourceAdapter installieren und konfigurieren
- 4. Datenablage in test.guide konfigurieren
- 5. Playbook von ecu.test nach test.guide exportieren
- 6. Zurücklehnen und zuschauen
Wie der Testauftrag lautet, steht in den Playbooks. Sie werden direkt in ecu.test oder in test.guide erstellt und über eine integrierte öffentliche Schnittstelle in die test.guide Datenablage exportiert. Sind darin neue Playbooks vorhanden, wird test.guide aktiv. Selbstständig organisiert das Tool die Verteilung der Testaufträge auf die passend konfigurierten Prüfstände in der Reihenfolge ihrer Priorisierung. Unterstützung erhält das Tool dabei vom ResourceAdapter, einer Software, die auf den Prüfständen installiert ist.
Die Ausführungsverteilung löst aber auch ein zweites oft bestehendes Problem. Nach der Zuordnung des Testauftrages müssen auf dem Prüfplatz noch alle Voraussetzungen zur Testausführung hergestellt werden. Es müssen Repositories ausgecheckt, Daten hin und her kopiert und zusätzliche Abhängigkeiten aufgelöst werden. Das alles macht auch der ResourceAdapter – anhand der Beschreibung im Playbook.
Nachgelagerte Analyseverteilung
Klassischerweise erfolgt nach jedem automatisierten Test neuer Softwareartefakte nahtlos die dazugehörende Analyse der dabei erstellten Trace-Aufzeichnungen (wie z. B. Bus-Logs) und die Testbewertung. Doch dieser Weg ist sehr zeitintensiv und für Tests mit unzähligen Varianten und Szenarien wenig praktikabel. Schon jetzt laufen speziell für den Test und die Absicherung von neu entwickelter Steuergerätesoftware umfangreich konfigurierte Hardware-in-the-loop-Prüfstände (HiL) im Dauereinsatz.
Mit dem Prinzip der nachgelagerten Analyseverteilung durch test.guide lässt sich mit der gleichen Kapazität mehr Leistung erreichen.
Nachdem ecu.test die Testaufträge auf den HiL-Prüfständen ausgeführt hat, werden Analyseaufträge erstellt und an ein konfiguriertes test.guide übergeben. In Kombination mit dem ResourceAdapter, der dauerhaft Informationen zu verfügbaren Rechenkapazitäten liefert, verteilt test.guide diese Aufträge an Prüfstandunabhängige ecu.test Instanzen (PC, Virtuelle Maschine, Cloud). Dort wird die Analyse der Testergebnisse – die sogenannte Traceanalyse – ausgeführt.
Die Ergebnisse in Form von Testreports werden automatisch in test.guide gespeichert und liefern die Basis für detaillierte Auswertungen.
Mit dem Prinzip der nachgelagerten Analyseverteilung durch test.guide lässt sich mit der gleichen Kapazität mehr Leistung erreichen.
Nachdem ecu.test die Testaufträge auf den HiL-Prüfständen ausgeführt hat, werden Analyseaufträge erstellt und an ein konfiguriertes test.guide übergeben. In Kombination mit dem ResourceAdapter, der dauerhaft Informationen zu verfügbaren Rechenkapazitäten liefert, verteilt test.guide diese Aufträge an Prüfstandunabhängige ecu.test Instanzen (PC, Virtuelle Maschine, Cloud). Dort wird die Analyse der Testergebnisse – die sogenannte Traceanalyse – ausgeführt.
Die Ergebnisse in Form von Testreports werden automatisch in test.guide gespeichert und liefern die Basis für detaillierte Auswertungen.
Auf diese Weise werden wertvolle Testressourcen nicht durch Auswertungen blockiert und der Testdurchsatz kann deutlich erhöht werden. Darüber hinaus lassen sich durch die Parallelisierung der Auswertung die durchzuführenden Testumfänge weiter skalieren.
Cache-Synchronisation
Jeder kennt das Problem: je größer eine Datei ist, umso umfangreicher ist ihr Inhalt und umso länger dauert es, sie zu öffnen. Beim Einlesen von Bus-/Service-Datenbanken und A2L-Dateien ist das genau das gleiche. Es handelt sich dabei um sehr große Datenbasen mit komplexen Formaten, die von ecu.test bei jedem Start der Konfiguration eingelesen und für die Weiterverwendung geparst werden müssen. Dieser Vorgang nimmt mitunter viel Zeit in Anspruch.
Die Idee ist daher, diese Daten nach dem erstmaligen Einlesen zentral zu speichern – in einem Cache. Caching eignet sich perfekt, wenn viele Personen die gleiche Datengrundlage verwenden. Parallel und in kurzer Zeit können sie auf denselben Cache-Speicher zugreifen. Dadurch verbessert sich nicht nur die Effizienz von Datenabfrage und Datenrückgabe enorm, auch die Performance von ecu.test steigt deutlich.
Voraussetzung ist lediglich, einen zentralen Ablageort für den Cache in den Workspace-Einstellungen von ecu.test einzurichten. Nach dem Einlesen der Datenbasis in ecu.test wird der zugehörige Cache der Bus- oder Dienstdatenbanken verschlüsselt auf dem konfigurierten Netzlaufwerk abgelegt.
Die Idee ist daher, diese Daten nach dem erstmaligen Einlesen zentral zu speichern – in einem Cache. Caching eignet sich perfekt, wenn viele Personen die gleiche Datengrundlage verwenden. Parallel und in kurzer Zeit können sie auf denselben Cache-Speicher zugreifen. Dadurch verbessert sich nicht nur die Effizienz von Datenabfrage und Datenrückgabe enorm, auch die Performance von ecu.test steigt deutlich.
Voraussetzung ist lediglich, einen zentralen Ablageort für den Cache in den Workspace-Einstellungen von ecu.test einzurichten. Nach dem Einlesen der Datenbasis in ecu.test wird der zugehörige Cache der Bus- oder Dienstdatenbanken verschlüsselt auf dem konfigurierten Netzlaufwerk abgelegt.
Da der Zugriff auf ein Netzlaufwerk zumeist keinem strukturierten Prozess unterliegt, können jedoch wichtige Artefakte versehentlich gelöscht werden. Besser ist es daher, den Cache für den Austausch in ein beliebiges konfiguriertes test.guide Depository (z. B. Artifactory oder S3) abzulegen.
Nutzende anderer ecu.test Instanzen beziehen den Cache von dort und umgehen so die aufwändige Erzeugung eines eigenen Caches. Einmalig werden dafür in test.guide AccessToken konfiguriert. Ändern sich die Eingangsdaten, wird der Cache neu erstellt und mit dem bereits abgelegten Cache synchronisiert. Damit ist das Starten der Konfiguration deutlich schneller abgeschlossen.
In unserer eigenen Testumgebung konnten wir durch dieses Feature die Dauer unseres Nachtlaufs von über 6 Stunden auf 2,5 Stunden reduzieren.
Nutzende anderer ecu.test Instanzen beziehen den Cache von dort und umgehen so die aufwändige Erzeugung eines eigenen Caches. Einmalig werden dafür in test.guide AccessToken konfiguriert. Ändern sich die Eingangsdaten, wird der Cache neu erstellt und mit dem bereits abgelegten Cache synchronisiert. Damit ist das Starten der Konfiguration deutlich schneller abgeschlossen.
In unserer eigenen Testumgebung konnten wir durch dieses Feature die Dauer unseres Nachtlaufs von über 6 Stunden auf 2,5 Stunden reduzieren.
Hier bin ich richtig!
Das ist die Lösung für dein Problem? Dann melde dich bei unserem Vertriebsteam und hol dir weitere Informatione oder vereinbare einen Termin mit uns.
Dich interessieren vor allem konkrete Anwendungsbeispiele? Dann klick dich am besten durch unsere Produkt-Demos.