Wie wir

Probleme angehen

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

Die richtige Kletterausrüstung ist wichtig – aber sie allein bringt uns in den seltensten Fällen die Steilwand hoch. Auch in unserem Tätigkeitsfeld ist das richtige Werkzeug ausschlaggebend, aber nicht das einzige Kriterium auf dem Weg zur Lösung.


TraceTronic Prozesse Methoden Tools Entwicklungsprozess


Daher haben wir bei unseren Aufträgen nicht nur die Tool-Auswahl und -Anpassung im Blick, sondern erarbeiten und ergänzen in enger Abstimmung mit unseren Kunden auch die Methoden und Prozesse, die am besten zum Kunden und zum Projekt passen. Dabei orientieren wir uns hauptsächlich an den in der Software-Entwicklung etablierten agilen Vorgehensmodellen und verwenden featuregetriebene Ansätze zur iterativen Lösungsfindung. Black-Box-Tests, erfahrungsbasierte Tests und Äquivalenzklassenbildung bei der Ausarbeitung konkreter Testumsetzungen sind keine Fremdwörter für uns, denn wir setzen diese Methoden gezielt ein, um neben einer großen Testabdeckung auch die notwendige Testtiefe zu erreichen.

Wir bieten also keine „One size fits all“-Versprechen. Aber wir greifen auf ausreichend Erfahrung, Enthusiasmus und Ehrgeiz zurück, um den Nutzen auf Kundenseite auf Basis der richtigen Tools immer wieder zu maximieren. Da sich das schwer erklären lässt, ohne auf ausgetretene Floskeln und viel zu häufig genutzte Superlative zurückzugreifen, lassen wir an dieser Stelle einige unserer Kollegen zu Wort kommen, die (fast) ungefiltert aus den Projekten heraus sprechen.

Wir möchten damit vor allem vermitteln, dass unsere Arbeit nicht mit unseren Produkten beginnt und endet. Wir freuen uns, Ihre Herausforderungen anzunehmen und eine Lösung mit Ihnen gemeinsam zu erarbeiten. Lassen Sie uns wissen, wie wir sie unterstützen können.


Kontakt
Show content

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

Jan Georges - Team Mosaik, Dresden (Februar 2019)

Egal mit welchen Kunden wir zusammenarbeiten, am Anfang stehen alle Beteiligten meist vor vielen Fragen. Für den Kunden sind unsere Produkte oft komplett neu, für uns sind die Begriffswelt, die Arbeitsweise und die Mentalität immer wieder Neuland. Daher versuchen wir immer zuerst, uns so gut wie möglich in den Kunden 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 dem Kunden Werkzeuge ringsherum, um seinen 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 Kundennä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 Kundenbeziehungen zu entwickeln, die Bestand haben.

Show content

AD-Testing: Welche Themen begegnen uns im Entwicklungsalltag und wie ergibt sich daraus eine durchgängige und automatisierte Tool-Kette?

Michael Gebauer - Software-Entwicklung im Bereich ADAS, Dresden (Februar 2019)

Lassen Sie mich den Versuch starten, Ihnen diese Frage zu beantworten. Aktuell ist das szenarienbasierte Testen in aller Munde. Das werde ich als Grundlage für diesen Beitrag nehmen. Zunächst werde ich aber auf die Testautomatisierung für einen Simulationslauf eingehen.

Übersicht zur Gesamtsimulation

Für das Testen werden logische Szenarien durch eine Parametervariation in eine Vielzahl von konkreten Szenarien überführt. Mit ECU-TEST und bekannten Simulations-Tools wie CarMaker, VTD, ModelDesk oder CarSim werden die Szenarien automatisiert getriggert. Im Anschluss der Simulation werden die entstandenen Daten mit ECU-TEST automatisiert ausgewertet und Metriken bzw. KPIs berechnet.

In der Regel gibt es neben den Simulations-Tools auch weitere Teilnehmer, die untereinander kommunizieren. Verkehrsflusssimulationen, das zu testende System, Sensormodelle … um nur ein paar Beispiele zu nennen. Verbunden werden die Teilnehmer über eine Middleware. Aufgabe einer solchen Co-Simulations-Plattform ist das Parametrieren der Teilnehmer, die Synchronisation der Simulation und der Datenaustausch der Teilnehmer untereinander. Zusammengefasst handelt es sich um eine reibungslose Gesamtsimulation auf einem oder verteilten Knoten. Oder auch zwischen mehreren Docker-Containern in der Cloud.

Verteilung der Tests

Tausende Kilometer sollen bereits in der Simulation gefahren werden. Tausende von Szenarien sollen automatisiert durchgeführt und evaluiert werden. Und die Ergebnisse müssen schnellstmöglich zur Verfügung stehen. Für die Ausführung der Simulationen ist eine Parallelisierung notwendig. Und das in den Stufen MiL, SiL und HiL. Um das zu ermöglichen, werden Testaufträge in kleinere Einheiten zerlegt und auf die Knoten verteilt. Für die Verteilung kommen Continuous-Integration-Systeme wie zum Beispiel Jenkins zum Einsatz.

Auswertung der Ergebnisse

Zunächst werden die Ergebnisse in einer zentralen Datenbank gesammelt. Hier ist eine durchgängige Traceability sehr wichtig. Neben den Simulationsergebnissen sind das z.B. berechnete Metriken, Eingangs- und Ausganggrößen oder auch Informationen über das Szenario wie Anzahl der Fahrzeuge, Fußgänger und ob es sich um ein Autobahn- oder Stadtszenario handelt. Unter Ergebnisvisualisierung verstehen wir die Aufbereitung und die geeignete und testfallübergreifende Darstellung von Ergebnissen. Ein Beispiel dafür sind Heatmaps. Mit dieser Methode können z.B. mehrdimensionale Parameterräume geeignet dargestellt werden:

ADAS Blog Heatmap

Es gibt natürlich weitere Charts, die für eine explorative Ergebnisanalyse zum Einsatz kommen. Wir haben gute Erfahrungen mit Scatter-Plots-Histogrammen und parallelen Koordinaten sammeln können.

Abschließend möchte ich die angesprochenen Punkte noch zusammenführen und eine Möglichkeit für eine durchgängige Tool-Kette aufzeigen. Hierbei sagen Bilder oft mehr als tausend Worte:

ADAS Blog Tool chain

Diese Tool-Kette basiert auf TraceTronic-Produkten und weiteren Systemen wie Simulationswerkzeugen und einer Continuous-Integration-Plattform. Diese Tool-Kette ist so flexibel aufgebaut, dass auch kundenspezifische Software integriert werden kann. Wir unterstützen Sie dabei gern.

Fazit

Dieser Artikel zeigt neben den Begrifflichkeiten auch die Komplexität des Themas. Schon bevor ich diesen Artikel verfasst habe, war mir klar, dass eine A4-Seite für dieses komplexe Thema nicht ausreichen wird. Sehen Sie es als Denkanstoß oder als Anlass mit uns in Kontakt zu treten. Wir können das Thema oder einen Themenschwerpunkt gern genauer betrachten.

Zögern Sie bitte nicht uns zu kontaktieren.

Show content

Der Weg zum hochautomatisierten Testen

David Gottwald - Test & Absicherung, Dresden (März 2019)

Die technischen Voraussetzungen für Continuous Testing bringen die Produkte von TraceTronic von Haus aus mit. Wir setzen dabei auf 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, muss 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.

CT Blog Jenkins

Absicherung von Steuergeräte-Software an Hardware-in-the-loop-Prüfständen

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 des Testers ist es dabei, die Ursache der Abweichung in diesem komplexen System aus HiL, Modell, Hardware und Software zu identifizieren.

Was bedeutet Test-...?

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.

Ein paar Grundbegriffe aus der Jenkins-Welt

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 Funktionsentwickler oder -applikateure, 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 einem unbedarften Anwender 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.

CT Blog HiL

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 den 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 Entwickler
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 Tester weniger Zeit in die Analyse von Abweichungen investieren, gegebenenfalls können funktionale Abweichungen des Testobjekts sogar direkt von den Entwicklern analysiert werden. Die Tester 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

TraceTronic entwickelt Modellierungskompetenz

Uwe Schreiber - Testsysteme, Dresden (Januar 2019)

Für den Verbund-HiL-Prüfstand einer Baumaschine habe ich erfolgreich Streckenmodelle entwickelt und in Betrieb genommen. Konkret waren das MKS-Modelle für den fahrbaren Maschinenkörper und die beweglichen Arbeitsgeräte, 1D-Modelle für die mechanischen Antriebsstränge, schaltplanorientierte Netzwerkmodelle für hydraulische Antriebe sowie kennlinienbasierte Sensormodelle.

Da es hier keine Vorgaben bezüglich der zu verwendenden Modellierungs-Tools gab, habe ich mich für Modelica-Tools entschieden. Damit ließen sich die Steuerung samt neuer Technologien für die Arbeitsbewegung am HiL testen. Selbst Ursachen für vermeintliche Unstimmigkeiten in den Messwerten konnten mithilfe der Modelle gefunden und erklärt werden.

Show content

Zukunft virtuell gestalten

Jens Grünberg - Virtual Reality, Dresden (November 2015)

Lassen Sie Ihre Entwicklung virtuelle Wirklichkeit werden. Mit Hilfe von Digital Mock-ups (Digitalen Versuchsmodellen) können Sie ADAS/HAF-Funktionen (Advanced Driver Assistance Systems / Hochautomatisiertes Fahren) durch wirklichkeitsgetreue Aufbauten im virtuellen Umfeld erleben, erproben, validieren und simulieren. Dabei lassen sich Stand und Reifegrad Ihrer Entwicklung durch kurze Review-Phasen überwachen und neue Software-Revisionen schnell einpflegen.

Wir fokussieren die gesamte Wirkkette, vom Steuergerät über die Visualisierung des Fahrzeuges bis hin zur Interaktion mit dem Fahrer. Programmstände innovativer Fahrzeugsysteme können objektiv bewertet und einfacher zwischen den operierenden Teams kommuniziert werden; die Entscheidungssicherheit steigt deutlich.

Der Erfolg bei der Gestaltung und Umsetzung innovativer Assistenzfunktionen sowie der Integration von Fahrerassistenzsystemen in eine Software-in-the-loop-Umgebung basiert auf langjähriger Erfahrung. Der Einsatz von Fahrsimulatoren als realitätsnahe Testsysteme für Steuergeräte wird gerade im Bereich der Fahrerassistenzssysteme immer beliebter.

Wir unterstützen Sie beim Aufbau der Simulatoren, z.B. bei der software-seitigen Implementierung des Fahrsimulators oder der Kopplung von Hard- und Software sowie der Implementierung von Tool-Adaptern. Die Integration erfolgt mit VTD (Virtual Test Drive, einschließlich Sound) und ADTF (Automotive Data and Time-Triggered Framework) zur Einbindung der Steuergeräte als Software-Stand und Unity 3D zur Visualisierung. Wir überführen vorhandene und vermessene Streckendaten der Formate OpenDrive, OpenCRG und IVE in eine Echtzeit-Engine wie z.B. Unity 3D und ermöglichen Ihnen den Aufbau einer breiten Streckenbasis für Ihr Digital Mock-up.

Virtuelle Testfahrten können im Vorfeld auf real vermessenen Strecken simuliert und z.B. Unfallschwerpunkte virtuell und reproduzierbar nachgestellt werden. Gemeinsam stellen unsere Fachbereiche Software-Entwicklung und Test & Absicherung eine robuste Umgebung bereit und können flexibel auf Ihre Anforderungen und Anwendungsfälle eingehen.