Automatisch testen und debuggen
Modellbasiert auf Serien-Hardware testen
Time Partition Testing ist ein Verfahren, mit dem direkt aus der modellorientierten Entwicklungsumgebung getestet werden kann. Durch Kopplung mit einem Hardware Debugger kann der Test ohne Instrumentierung des Codes und ohne Einschränkung des Echtzeitverhaltens auf der Ziel-Hardware erfolgen.
Time Partition Testing (TPT) ist ein modellbasiertes Testverfahren von PikeTec, mit dem sowohl Matlab/Simulink- oder ASCET-Modelle als auch herkömmliche C-Applikationen getestet werden können. Mit Hardware-nahen Debug- und Trace-Werkzeugen wie der Universal Debug Engine (UDE) von PLS gekoppelt, lässt sich sogar Code auf Seriensteuergeräten ohne Instrumentierung oder Einschränkung des Echtzeitverhaltens testen. Außerdem kann eine Messung der Codeüberdeckung vorgenommen werden, wie sie zur Sicherstellung der Software-Qualität von den einschlägigen Normen wie ISO 26262 verlangt wird.
TPT beruht auf hybriden, hierarchischen, parallel arbeitenden Automaten mit kontinuierlichem Verhalten. Die Automaten nutzen eine Echtzeitsemantik, unterstützen kontinuierliche Signalverläufe und ermöglichen mit Hilfe von sogenannten Variationspunkten die Modellierung einer Menge von Testfällen in einem gemeinsamen Automaten. Beim TPT werden also alle Testfälle für ein Testobjekt in einem gemeinsamen Testmodell verwaltet. Durch diesen Ansatz bleibt die Übersichtlichkeit auch bei komplexen Tests mit Hunderten von Testfällen noch überschaubar und wartungsfreundlich, wobei die Tests selbst formal präzise und automatisch ausführbar sind. Mittels Kopplung mit dem Anforderungsmanagement-Werkzeug Doors und einer integrierten Testauswertung ist eine durchgängige Automatisierung von der Anforderungsspezifikation über die Testmodellierung und -durchführung bis zur Testauswertung und Dokumentation möglich.
Der Vorteil von TPT liegt in der anschaulichen grafischen Modellierung von signalorientiertem Verhalten für automatisiert ausführbare und auswertbare Tests.
Jobangebote+ passend zum Thema
Die Unterschiede zwischen den einzelnen Testfällen werden durch Verhaltensvarianten an den Zuständen und Transitionen modelliert. Jeder Zustand und jede Transition im Automat kann also nicht nur eine, sondern potenziell beliebig viele alternative Signaldefinitionen bzw. Übergangsbedingungen definieren, die wiederum unterschiedliche spezifische Testabläufe stimulieren können. Zustände und Transitionen, für die mehr als eine Variante definiert wurde, heißen Variationspunkte. Die konkreten Testfälle werden beim TPT durch Auswahl und Kombination von Varianten für alle Variationspunkte definiert. Unterschiedliche Kombinationen definieren unterschiedliche Testfälle. Bild 1 zeigt einen Ausschnitt des Hauptfensters der TPT-Software mit einem exemplarischen Automaten.
Testen in allen Phasen der Entwicklung
Die Modellierung der Testfälle erfolgt beim TPT unabhängig von der Plattform bei der Testausführung. Daher können dieselben Tests ohne irgendwelche Änderungen in allen Phasen der Entwicklung vom frühen „Model in the Loop“ (MiL) über „Software in the Loop“ (SiL) und „Processor in the Loop“ (PiL) bis hin zum anschließenden „Hardware in the Loop“ (HiL) wiederverwendet werden. So kann TPT zur Steuerung des Target und zum Setzen/Auslesen von Werten für Hardware-in-the-Loop-Tests mit verschiedenen Laufzeitumgebungen wie beispielsweise Labcar von ETAS oder dSPACE-Systemen umgehen. Ein weiterer Vorteil der plattformunabhängigen Testfälle besteht darin, dass die Ergebnisse unmittelbar gegenübergestellt werden können.
Mit Unterstützung der Universal Debug Engine (UDE) können Anwender die mittels TPT modellierten und verwalteten Tests sogar in Echtzeit auf der tatsächlichen Ziel-Hardware, also beispielsweise einem Steuerungs- oder Regelungsgerät, ausführen. Die Grundlage dafür bildet das von der UDE bereitgestellte Software Interface. Es basiert auf dem Component Object Model (COM) von Microsoft und bietet nahezu alle Funktionen des Debugger wie Flash-Programmierung, Ablaufsteuerung, Lesen und Schreiben von Target-Speicher in symbolischer und numerischer Form, Trace-Daten-Erfassung und Analyse und vieles mehr (Bild 2).
Über die Software-Schnittstelle ist der Debugger innerhalb der Benutzeroberfläche durch Makros oder extern durch Skripts steuerbar. Dabei können alle Skriptsprachen, die mit COM-Komponenten umgehen können – wie JavaScript, Perl, Python, VB Script oder auch PowerShell – zum Einsatz kommen. Die Programmierung von automatisierbaren Abläufen erfolgt also nicht in einer proprietären Syntax, sondern in der vom Entwickler gewählten bzw. gewohnten Sprache, und zwar unter voller Ausnutzung der durch das UDE-Software-API bereitgestellten Objekte, Eigenschaften und Methoden.
- Modellbasiert auf Serien-Hardware testen
- Schrittweiser Datenaustausch
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Die Cloud zum Anfassen
Referenzplattform »Visible Things«
Betriebssysteme
Virtualisierung mit Echtzeit
Hardware-Debugger
Läuft weiter - trotz Breakpoint
Für Microchip-Mikrocontroller
Entwicklungsumgebung in der Cloud
Entwicklungssystem
Testautomatisierung mit dem Debugger
