So arbeiten wir

Für uns ist das Produkt nur ein Teil der Lösung

Wir haben nicht nur die Tool-Auswahl und -Anpassung im Blick, sondern erarbeiten und ergänzen in enger Abstimmung mit unseren Kundinnen und Kunden auch die Methoden und Prozesse, die am besten zu ihnen und ihren Projekten passen. Dabei orientieren wir uns hauptsächlich an den in der Software-Entwicklung etablierten agilen Vorgehensmodellen und verwenden feature-getriebene Ansätze zur iterativen Lösungsfindung. Wir setzen Methoden gezielt ein, um neben einer großen Testabdeckung in allen Phasen der Funktionsentwicklung (MiL, SiL, Hil, ViL) auch die notwendige Testtiefe zu erreichen. Bei uns gibt's keine „One size fits all“-Versprechen. Aber wir greifen auf ausreichend Erfahrung, Enthusiasmus und Ehrgeiz zurück, um den Nutzen auf Seiten der Kundschaft auf Basis der richtigen Tools immer wieder zu maximieren.

Mit unseren nachhaltig entwickelten Lösungsansätzen für die Bereiche autonomes Fahren, Infotainment und Virtuelles Testen heben wir die Testautomatisierung auf eine neue Ebene und testen moderne Fahrzeugfunktionen schon lange bevor das Fahrzeug auf die Straße kommt.

ADAS

Fahrerassistenzsystemen und autonomen Fahrfunktionen gehört die Zukunft – und mit unseren Lösungen werden sie getestet. Szenarienbasiert, skalierbar und kompatibel zu komplexen Systemen.

Infotainment-Test

Sprachbedienung, Smartphone-Kopplung, Web-Radio, Lieblingslieder, Navi – und alles am besten parallel? Kein Problem! Wir testen genau das unaufhörlich.

Virtuelles Testen

Neue Funktionen erst im Fahrzeug testen? Das ist bei der heutigen Komplexität von Automobil-Software undenkbar. In der virtuellen Welt laufen die Tests schon lange vor dem Bau des ersten Prototyps.

Doch damit nicht genug! Wir lassen an dieser Stelle noch einige unserer Kolleginnen und Kollegen zu Wort kommen, die (fast) ungefiltert aus den Projekten heraus sprechen. Denn wir können noch viel mehr, da unsere Arbeit nicht mit unseren Produkten beginnt und endet.

Show content

... mehr als 80 Steuergeräte über kilometerlange Kabelverbindungen miteinander und tauschen Informationen zum aktuellen Betriebszustand aus. Um diese komplizierten und stetig komplexer werdenden mechatronischen Zusammenhänge verstehen, beherrschen und auch belastbar testen zu können, kommen in unserem Projekt digitale Streckenmodelle zum Einsatz. Diese ermöglichen Simulationen zur Absicherung neuer Funktionen für Steuergeräte-Software bereits in frühen Entwicklungsphasen. Darüber hinaus unterstützen die Modelle die Entwicklung von Funktionen, die Interpretation von Messwerten sowie die Diagnose.

Mithilfe von Streckenmodellen werden in der Prüfumgebung mechanische, thermische und elektronische Funktionsweisen von Fahrzeugbauteilen virtuell nachgebildet. In Abhängigkeit von der Aufgabenstellung und dem Einsatzgebiet bilden diese Modelle verschiedene Detaillierungstiefen ab: Vom Kennlinienmodell über das Verhaltensmodell bis hin zum physikalischen Modell. Die gesendeten und empfangenen Signale sowie die ausgeführten Aktionen innerhalb der virtuellen Prüfumgebung werden dabei genauestens analysiert und hinsichtlich Echtzeitfähigkeit getestet.

Beispielsweise sendet ein Streckenmodell alle wesentlichen Sensorgrößen, wie z. B. die aktuelle Drehzahl oder die Motortemperatur, in Richtung Steuergerät, während das Steuergerät dann die resultierenden Aktorgrößen, wie z. B. das Signal zur Bestromung eines Stellmotors, an das Streckenmodell schickt. Der Anwendende kann sich während der Funktionsabfolge einen Echtzeiteinblick verschaffen und durch Pausieren, Fortsetzen oder Abbrechen Details des Testvorgangs für jeden beliebigen Zeitschritt untersuchen – ganz ohne reale Hardware. Auf diese Weise lassen sich vielzählige Was-wäre-wenn-Szenarien testen und schon vor der produktiven Inbetriebnahme prüfen, ob noch Optimierungsbedarf für die Steuergeräte-Software besteht. An diese Form der digitalen Transformation werden hohe Erwartungen gesetzt. Denn entspricht das Verhalten des Streckenmodells nicht ausreichend genau der Realität, kann auch die Funktion der Steuergeräte-Software nicht sicher getestet werden.

In der Praxis werden Streckenmodelle oftmals aus Teilmodellen verschiedener Fachabteilungen zusammengestellt, die ursprünglich nicht für Software-Tests, sondern zur Auslegung technischer Systeme entwickelt wurden. Hier besteht die Herausforderung, dass alle erforderlichen Schnittstellen zur Kommunikation (Sensor/Aktor) mit der Software funktionieren und die Echtzeitfähigkeit des Gesamtsystems sichergestellt ist.

Ist das Streckenmodell richtig konzipiert und nicht zu kompliziert? Wie viel Rechenkapazität wird benötigt? Sind die realen Prozesse genau genug virtualisiert damit keine zu großen Abweichungen auftreten? Antworten auf solche Fragen erfordern hohe Expertise. Wir Modellierungs-Teams sind genau darauf spezialisiert und entwickeln, integrieren und erweitern Strecken- und Anlagenmodelle aller Art – und das herstellerunabhängig. So können wir nach Wünschen und Vorgaben unserer Kundschaft ganz verschiedene Tools, wie z.B. MATLAB Simulink, Modelica oder SimulationX, einsetzen. Mit den zugrunde liegenden Gleichungen der Modelle sind wir bestens vertraut und können daher vorhandene Modell-Bibliotheken mit neuen Features schnell erweitern.

Danach prüfen wir, ob Komponenten-, Teilsystem- und Systemmodelle das erwartete Verhalten fehlerfrei und numerisch stabil abbilden. Dabei stellt der Test auf Erfüllung physikalischer Gesetzmäßigkeiten eine besonders elegante Möglichkeit dar, da hierfür – anders als beim Regressionstest – keine Vergleichsergebnisse benötigt werden. Getestet wird so beispielsweise die Erfüllung von Massen- und Energieerhaltungssätzen oder das Erreichen und Halten von stationären Gleichgewichtslagen. Wenn mathematische oder physikalische Gleichungen fehlen, bauen wir sie ein!

Der Qualität dieser Modelle kommt eine entscheidende Bedeutung zu, damit Steuergeräte-Software ohne Unterbrechung und effizient getestet werden kann: Sie sollten keine Fehler verursachen und auf verschiedenen Plattformen numerisch stabil laufen.

Deshalb müssen auch die Modelle selbst getestet und abgesichert werden. Wir nutzen dafür die gleichen Workflows wie für die Software-Tests, inklusive Continuous Testing (CT) und Continuous Integration (CI). Dafür setzen wir auf unsere Tool-Kette ECU-TEST, TEST-GUIDE und ECU-TEST Jenkins Plug-in.

Werden von der Modellentwicklung Änderungen eingecheckt, startet der Jenkins über das Plug-in automatisch die Test-Software ECU-TEST mit den Modulkomponenten als Testobjekten. Die Modelltests selbst werden generisch aufgebaut. So wird automatisch erkannt, welche Eingangssignale zu stimulieren sind und welche Ausgangssignale für die Analyse benötigt werden. Aus den Ergebnisverläufen lassen sich Bewertungsgrößen bilden und damit die Modellqualität automatisiert beurteilen. Die eigentliche Analyse wird unter Verwendung der gefundenen Signale modellspezifisch generiert. Damit lassen sich die Tests auf beliebige Bibliotheken und Modelle anwenden.

Erfolgreich getestete Modulkomponenten werden in das Systemmodell integriert, welches ebenfalls getestet wird.

Besteht auch das System den Test, wird ein Modellkompilat erstellt und mithilfe eines Back2Back-Tests geprüft, ob sich das kompilierte Modell auf der Zielplattform genauso verhält wie in der ursprünglichen Modellierungsumgebung. Ist dem so, kann das Modellkompilat als neues Release für die folgende Steuergeräteabsicherung freigegeben werden.

Das komplette Reporting des Testprozesses übernimmt TEST-GUIDE, unser zentrales Testreportmanagementsystem. Es stellt der Modellentwicklung die Testergebnisse auf allen Integrationsstufen bereit und gibt ihr so schnell Feedback zur Modelländerung. Die erfolgreich getesteten Modelle werden in einem Artifactory gespeichert.

Sie möchten, dass wir auch für Sie modellieren, generische Testsuiten entwerfen und Analysejobs erstellen? Machen wir sehr gern!"

Show content

... das aus der klassischen Software-Entwicklung etablierte Software-System Jenkins. Über das „ECU-TEST Jenkins Plug-in“ ist eine Interaktion von Jenkins mit ECU-TEST und damit auch mit der Testumgebung möglich. Der Workflow zur automatischen Testausführung mit Jenkins würde ungefähr so aussehen: Jenkins überwacht ein Datei-, Versionierungs- oder Ticketsystem. In diesem System werden neue Testaufträge hinterlegt. Sobald ein neuer Testauftrag erkannt wird, müssen ein geeigneter Prüfplatz bestimmt und anschließend die notwendigen Tests dort ausgeführt werden. Abschließend werden alle produzierten Ergebnisse in eine Ergebnisverwaltung, wie zum Beispiel TEST-GUIDE, zurückgespielt. Dort können sie dann letztendlich analysiert und ausgewertet werden.

Es hat sich in unserem Projektalltag allerdings gezeigt, dass die technischen Fragestellungen beim Aufbau einer Continuous-Testing-Lösung die einfacheren sind. Die größten Herausforderungen liegen in der Harmonisierung von Prozessen, der Verständlichkeit und Nachvollziehbarkeit von Arbeitsschritten, sowohl innerhalb der Tests als auch während der Ausführung, sowie in der Beschaffung von benötigten Informationen. Und leider wachsen diese Herausforderungen mit der Größe des Absicherungsteams.

Unsere Erfahrungen haben gezeigt, dass für den Aufbau einer Continuous-Testing-Lösung eine Reihe von Voraussetzungen erfüllt sein müssen. Wir haben versucht, diese Erfahrungen in Best Practices zu verpacken. Einige davon beziehen sich nicht ausschließlich auf eine hochautomatisierte Testausführung. Und nicht alle davon müssen vollständig umgesetzt sein, aber der Weg dahin sollte gegangen werden.

Um Steuergeräte (ECUs) möglichst realitätsnah abzusichern, werden diese an sogenannten Hardware-in-the-Loop-Prüfständen (HiLs) getestet. Der HiL simuliert die für den Betrieb des Steuergerätes nötigen Eingangs- und Ausgangssignale. Damit ist es möglich, die ECUs in definierte Betriebszustände zu versetzen. Die Echtzeitsteuerung des Prüfplatzes übernimmt dabei ein Modell, was auf dem HiL ausgeführt wird.

Damit kann man überprüfen, ob gewisse Stimulationen die erwarteten Reaktionen auslösen. Diese Tests werden mit der Testautomatisierungs-Lösung ECU-TEST ausgeführt.

Die wesentliche Aufgabe der Testenden ist es dabei, die Ursache der Abweichung in diesem komplexen System aus HiL, Modell, Hardware und Software zu identifizieren.

Das Testobjekt ist in unserem Projektkontext die Software, die auf dem Steuergerät ausgeführt wird. Jedoch kann immer nur Hardware und Software im Zusammenspiel getestet werden (im Gegensatz zu Software-in-the-loop-Tests).

Die Testumgebung bezeichnet die Gesamtheit aus Prüfplatz, Modell, Messtechnik, Restbussimulation, benötigten Software- und Hardware-Tools sowie Mess- und Simulationsrechner.

Ein Testfall prüft eine einzelne Anforderung oder Funktion des Testobjekts. Ein Testfall stellt die nötigen Voraussetzungen zu Beginn selbst her und setzt diese am Ende wieder zurück.

Ein Testkapitel ist eine inhaltliche Gruppierung von Testfällen.

Der Testauftrag beinhaltet alle zur Testausführung nötigen Informationen. Konkret sind das das Testobjekt, die durchzuführenden Testfälle und Testkapitel sowie alle für den Test notwendigen Artefakte.

Jenkins ist ein erweiterbares, webbasiertes Software-System zur kontinuierlichen Integration von Komponenten.

Auf Basis vonTriggern führt Jenkins sogenannte Jobs aus. In diesen Jobs ist die Abarbeitungslogik hinterlegt. Trigger können zeitlich, durch Ereignisse im Datei- oder Versionierungssystem oder durch andere Jobs ausgelöst werden.

Jenkins bietet die Möglichkeit, den Funktionsumfang über Plug-ins zu erhöhen.

Pipeline ist ein Jenkins Plug-in, das die Definition sogenannter Stages erlaubt. Stages bieten die Möglichkeit, die Job-Abarbeitung zu strukturieren, beispielsweise in „Vorbereitung“, „Testausführung“ und „Nachbereitung“. Es ist damit einfacher, Fehler im Ablauf einzugrenzen.

Ist eine automatisierte Testausführung durchgängig möglich?
Grundvoraussetzung für eine Continuous-Testing-Lösung ist, dass die Arbeitsschritte soweit automatisiert sind, dass zur Testausführung keine manuellen Schritte mehr nötig sind. Manuelle Schritte sind zum Beispiel das Hinzufügen fehlender Artefakte oder Anpassungen an Testumgebung oder Testobjekt.

Trennen Sie die Ausführungslogik von der Businesslogik
Die Businesslogik beinhaltet die Fragestellungen, was womit getestet wird. Dazu zählen Fragen wie:

Welche Testumfänge sind für das Testobjekt relevant?
Welche Artefakte werden für die Ausführung benötigt? Wo find ich diese?
Welche zusätzlichen Informationen gehören zu meinem Testobjekt? Woher bekomme ich diese?

Die Businesslogik erstellt bzw. ergänzt den Testauftrag. Die Ausführungslogik dagegen kümmert sich um die Abarbeitung des Testauftrags und aller notwendiger Schritte zur Vorbereitung und Einrichtung des Prüfplatzes. Gerade die Businesslogik ist sehr anspruchsvoll und bietet viele Fallstricke. Unter Umständen lässt sich diese auch nicht vollständig automatisieren. Durch die Trennung ist es zumindest möglich, die Ausführung vollautomatisiert abzuarbeiten. Ein weiterer Vorteil der Trennung ist, dass sich diese beiden komplexen Systeme unabhängig voneinander besser warten und weiterentwickeln lassen.

Versuchen Sie die Testfälle so lesbar wie möglich zu halten
Mit der automatisierten Testausführung werden auch automatisiert viele Testergebnisse erzeugt. Im Fehlerfall muss jedoch in letzter Instanz ein Mensch die Tests bewerten. Dabei ist es ungemein von Vorteil, wenn man auf einem Blick erkennt, wo das Problem liegt.

Die Lesbarkeit von Testfall-Packages in ECU-TEST kann man durch eine Strukturierung mit Blöcken erhöhen. Außerdem sollte man drauf achten, dass die Struktur im Package flach bleibt. Idealerweise sind die Testfälle so aufgebaut, dass auch Personen, die nichts vom Testen am Prüfplatz verstehen, wie aus der Funktionsentwicklung oder -applikation, diese verstehen können.

Einigen Sie sich auf eine gemeinsame Arbeitsweise
Sonderbehandlungen sind möglich, aber sehr umständlich in der Wartung. Versuchen Sie daher, Ihren Workflow bei der Absicherung möglichst gleich zu halten. Unterschiedliche Behandlungen sollten vorher bekannt und explizit angegeben sein.

Geben Sie Informationen immer explizit an
Sowohl für die Ausführung eines Testfalls als auch für die Gesamtausführung werden oftmals weitere Informationen benötigt. Diese sollten immer explizit im Testauftrag angegeben sein. Das können sein:

Testfallparametrierungen (z. B. unterschiedliche Leerlaufdrehzahl von Benziner und Diesel)
Dynamische Testumfänge (z. B. spezielle Testfälle für Automatik und Handschalter)
Exporteinstellungen bei unterschiedlichen Testtypen
Weitere Artefakte, wie die der Testkonfiguration (z. B. tcf-, gcd-Dateien)

Informationen, die erst zur Laufzeit ermittelt werden, haben zwei wesentliche Nachteile: Zum einen ist bei der unbedarften Anwendung nicht klar, warum bei zwei verschiedenen Ausführungen zwei unterschiedliche Ergebnisse auftreten können. Zum anderen besteht bei implizit ermittelten Informationen oft das Problem der Pflege und Wartung, da der Zeitpunkt der Ermittlung während der Laufzeit nicht transparent ist.

Machen Sie einen Schritt nach dem anderen
Für die Jenkins-Jobs gilt: Je modularer sie geschnitten sind, desto einfacher lassen sie sich handhaben. Für komplexere Jobs empfiehlt sich die Verwendung von Pipelines. Damit lassen sich sogenannte Stages definieren und man kann schneller sehen, an welcher Stelle der Abarbeitung es zu einem Problem kam.

Modulare Jobs bieten außerdem den Vorteil, dass man sie einzeln (neu-)starten kann. Somit ist es z. B. möglich, unterschiedlich auf Fehler zu reagieren, je nachdem ob man sich in der Vorbereitung oder Ausführung eines Tests befindet.

Versuchen Sie so viel von der Tool-Kette zu testen wie möglich
Jede Änderung an Ihrem Absicherungsprozess sollte gut geprüft werden. Nichts erzeugt mehr Frust als eine schnelle Anpassung, die mehrere dutzend Prüfplätze plötzlich nur noch Datenmüll produzieren lässt. Beispiele:

Ein neuer Testfall wurde nur für eine Variante in Betrieb genommen
Ein Bibliotheks-Package muss angepasst werden
Änderung an der Prüfplatzumgebung

Die gute Nachricht ist, die Continuous-Testing-Lösung hilft Ihnen dabei!

Mehrwerte für die Kundinnen und Kunden

Erhöhung der Auslastung von Prüfständen
Durch die automatische Abarbeitung von Testaufträgen kann ein Prüfplatz solange ausgelastet werden, wie geeignete Testaufträge vorhanden sind. Das ist besonders wertvoll für Absicherungen über Nacht oder am Wochenende.

Verbesserte Testabdeckung und -tiefe
Die Möglichkeit mehr Tests durchzuführen schafft die Kapazitäten um entweder mehr Testobjekte (Testabdeckung) oder einzelne Testobjekte intensiver (Testtiefe) abzusichern.

Schnelles Feedback für die Entwicklung
Eine höhere Prüfplatzauslastung heißt auch, dass Ergebnisse schneller zur Verfügung stehen und somit schneller wieder in die Software-Entwicklung einfließen können.

Fokussierung des Absicherungsteams
Durch die erhöhte Zuverlässigkeit und die verbesserte Lesbarkeit von Testfällen müssen Testende weniger Zeit in die Analyse von Abweichungen investieren, gegebenenfalls können funktionale Abweichungen des Testobjekts sogar direkt von der Entwicklung analysiert werden. Die Testenden haben so die Möglichkeit, frei werdende Kapazitäten in die Entwicklung von Testfällen oder die Wartung der Testumgebungen zu investieren.

Skalierbarkeit der Continuous-Testing-Lösung
Die zentrale Verwaltung und Steuerung über den Jenkins-Server ermöglichen es, neue Testumgebungen einfach zu integrieren."

Show content

... die Begriffswelt, die Arbeitsweise und die Mentalität immer wieder Neuland. Daher versuchen wir immer zuerst, uns so gut wie möglich in unsere Kundschaft reinzudenken und möglichst vor Ort dabei zu sein, um die Probleme am eigenen Leib zu spüren.

Das klingt komisch, aber genau an diesem Punkt beginnt die Lösungssuche. Die Ansätze sind dabei immer die gleichen: Entweder erweitern wir unser Produkt oder entwickeln gemeinsam mit den Auftraggebenden Werkzeuge ringsherum, um ihre Prozess besser zu automatisieren. Enge Zusammenarbeit ist aus meiner Sicht absolut essenziell, denn die Frage, wo der Schwerpunkt liegt, ist gar nicht immer so einfach zu beantworten.

Ein Skript ist schnell geschrieben, aber wir wollen erreichen, dass die Lösungsidee kein Schnellschuss ist, sondern über mehrere Jahre und mehrere Bereiche hinweg Bestand hat.

Einer unserer Kunden stellte uns zum Beispiel vor eine ziemliche Mammutaufgabe mit seiner extrem großen Variantenvielfalt von Steuergeräte-Software. Wir mussten unsere Produkte in vielen Bereichen erweitern und parallel dazu eine Vielzahl von kundenspezifischen Werkzeugen entwickeln. Die Kunst war, die Schnittstellen der Tool-Landschaft immer wieder zu synchronisieren und das in kürzester Zeit und über diverse Abteilungen hinweg, die vorher wenig Kontakt hatten.

Die Art, wie wir Testdaten vorher in ECU-TEST verwaltet haben, hat sich durch diese intensive Zusammenarbeit komplett geändert. Heute bietet das Tool viel mehr Möglichkeiten, Testfälle und Testdaten getrennt voneinander zu verwalten. Ohne diese Nähe, das Vertrauen und den offenen Austausch wäre uns die Bedeutung dieses Features vielleicht gar nicht bewusst geworden. Das ist aus meiner Sicht der einzige Weg, Lösungen und Beziehungen zu entwickeln, die Bestand haben."

Auch auf der Suche nach einer Lösung?

Wir freuen uns auf Ihre Herausforderung! Lassen Sie uns gemeinsam Methoden und Prozesse finden, die am besten zu Ihrem Projekt passen.

Klingt nach einem Plan? Dann setzen Sie sich mit unserem Vertriebsteam in Verbindung und lassen Sie uns Ihnen ein Angebot machen.

Kontakt

Für uns ist das Produkt nur ein Teil der Lösung

TraceTronic entwickelt Modellierungskompetenz

Der Weg zum hochautomatisierten Testen

Mehrwerte für die Kundinnen und Kunden

Was ist ein guter Weg für eine nachhaltige Lösung?

Auch auf der Suche nach einer Lösung?