Mastering Software Complexity

Contract Based Testing für Embedded Systeme

Das Testen von Embedded Systemen wird mit zunehmender Komplexität erheblich schwerer. Die Methode des Contract Based Design eröffnet eine neue Perspektive und sehr effektive Vorgehensweisen, wenn man sie erweitert und auf Tests anwendet.

Was ist der Zweck von Tests?

Testen wird häufig reduziert auf das Entwickeln und Durchführen manueller oder automatisierter Testabläufe. Betrachten wir zunächst die wesentlichen Ziele von Tests:

Wir erweitern den Begriff des Tests daher auf alle Methoden, welche diese beiden Ziele unterstützen. Dies können z.B. auch Reviews, formale Verifikation oder Laufzeitmonitoring sein.

Die Herausforderung beim Testen

Um die Ziele zu erreichen müssen vor allem drei Fragen beantwortet werden:

In vielen Fällen kann man diese Fragen recht elegant durch den Einsatz von Contracts beantworten.

Klassische Contracts nach Bertrand Meyer

Design by Contract (DbC) wurde entwickelt und eingeführt durch Bertrand Meyer. DbC erlaubt die Definition formaler Verträge für Schnittstellen und Verhalten von Software-Komponenten. Pre- und Post-Conditions, Invarianten und Seiteneffekte definieren die Semantik von Funktionen. Sprachen wie Ada und Eiffel unterstützen die Definition und Validierung von Contracts.

Hier ein Beispiel für die Umsetzung eines sehr einfachen Contracts mit Pre- und Post-Conditions in der Sprache C mit Hilfe von Asserts.

Contracts in der Sprache C

Diese Art von Contracts wird auf der Komponentenebene definiert, also für Schnittstellen von Funktionen, Klassen oder C-Modulen. Die daraus resultierenden Prüfungen können daher auch nur auf dieser Ebene erfolgen. Für Prüfungen zur Designzeit benötigt man die Unterstützung der Sprache (z.B. Ada und Eiffel). Integrations- und Systemtests für Embedded Systeme sind damit kaum möglich.

Test Ebenen und Test Zeitpunkt für klassische Contracts

Contract Erweiterungen für Embedded Systeme

Wir benötigen Erweiterungen der Contracts die es ermöglichen asynchrones, nebenläufiges Verhalten für alle Ebenen eines Systems formal zu beschreiben. Eine exzellente Methode hierfür sind Interface Statemachines. Reihenfolgen und zeitliches Verhalten (temporale Logik) von synchronen oder asynchronen Aufrufen können damit sehr exakt spezifiziert werden. Außerdem sind Statemachines eine Methode, die den meisten Embedded Entwicklern bekannt ist.
Die Interface Statemachine definiert zu jedem Zeitpunkt welche Aufrufe erlaubt sind. Jeder andere Aufruf ist verboten. Dies reduziert die Anzahl der erlaubten Aufrufreihenfolgen um Größenordnungen. Kann man die Einhaltung des spezifizierten Verhaltens testen oder zur Laufzeit überwachen, führt dies zu erheblich einfacheren Systemen, die wesentlich weniger Fehler enthalten.

Das folgende Beispiel zeigt die Spezifikation aller erlaubten Aufrufe an einer einfachen Schnittstelle als Interface Statemachine. Nur auf Grund der C-API kann man z.B. folgende Fragen nicht beantworten:

Spezifiziert man die erlaubte Reihenfolge als Interface Statemachine, so kann man die Fragen schnell und eindeutig beantworten:

Die Anzahl der erlaubten Aufrufreihenfolgen reduziert sich für den einmaligen Aufruf aller Funktionen von 120 auf 6, bei 3 Iterationen bereits von ca. 1012 auf 300.000.

Beispiel für Statemachine als Interface Contract

Interface Contracts sind also eine äußerst effektive Möglichkeit formal erlaubtes und verbotenes Verhalten an Schnittstellen auf allen Ebenen zu spezifizieren. Die zu testenden Zustände kann man damit meist um viele Größenordnungen reduzieren. Ein angenehmer Nebeneffekt ist die hervorragende und eindeutige Dokumentation der Schnittstellenabläufe.

Prüfung der Contracts

Die spezifizierten Contracts können zu drei verschiedenen Zeitpunkten überprüft werden:

Am Beispiel des Open Source Werkzeuges eTrice und der Testsprache CaGe für miniHIL Systeme wird gezeigt wie solche Prüfungen aussehen können.

Prüfung von Contracts zur Designzeit (Formale Verifikation)

Im Rahmen des Forschungsprojektes Contract Based Modeling & Design (CBMD) wurde das Werkzeug eTrice und die Sprache ROOM (Real-Time Object-Oriented Modeling) um Contracts erweitert. Die Methoden werden bereits in der Praxis eingesetzt.
Im folgenden Beispiel wird die Schnittstellenspezifikation der Ports (fct und terminal) zwischen den Komponenten (Strukturmodell) um einen Contract (Interface Statemachine) erweitert.
Die Aktoren enthalten jeweils ein Modell ihres Verhaltens als Implementierungs-Statemachine. Während der Modellierung werden die Implementierungs-Statemachines laufend gegen den Contract geprüft. Verstöße gegen den Contract werden im Modell angezeigt. Die Generierung der Implementierung aus dem Modell stellt sicher, dass das korrekte Verhalten des Modells auch im Code umgesetzt wird.

Contract Prüfung in eTrice zur Designzeit

Der Hauptvorteil ist die frühe Erkennung und Behebung von Bugs und potenziellen Problemen. Durch die formale Verifikation werden viele Probleme entdeckt, die durch Tests sehr schwer zu finden sind. Ein Beispiel sind Race Conditions die zu sporadisch auftretenden, unklaren und kaum reproduzierbaren Fehlersituationen führen.
Eine Einschränkung der formalen Verifikation ist, dass man ein formales Applikationsmodell benötigt, um es zu prüfen. Wird die Applikation nicht modelliert, sondern mit einer Programmiersprache wie C implementiert, so ist die formale Verifikation nur schwer zu realisieren.

Prüfung von Contracts zur Laufzeit (Monitoring)

Ein weiteres Ergebnis des CBMD Projektes ist die Generierung von Contract Monitoren in eTrice/ROOM Modellen. Diese Monitore werden in die Kommunikationsverbindung zwischen den Komponenten oder zu anderen Systemen eingebaut und erlauben die Prüfung von Contracts zur Laufzeit. Hierfür sind folgende Teilfunktionen nötig:

Im folgenden Beispiel hat der aus dem Contract generierte Monitor zur Laufzeit ein Fehlverhalten entdeckt. Im generierten Sequenzdiagramm sieht man den exakten Zeitpunkt, Verlauf und die Ursache.

Contract Prüfung in eTrice zur Laufzeit

Die entstehenden Systeme sind sehr robust gegen Fehlverhalten an den Schnittstellen. Dies ist ein entscheidender Vorteil auch bei Systemen die Safety oder Security Anforderungen haben.
Ein Vorteil des Laufzeit Monitorings ist, dass man auch Applikationen und Schnittstellen, die nicht modelliert wurden, sehr gut mit Monitoren verbessern kann.

Prüfung von Contracts zur Testzeit (Test Case Generierung)

Zur Generierung von Test Cases sind die Interface Statemachines im Allgemeinen nicht sehr gut geeignet, da sie keine Aussagen über das Gesamtverhalten eines Systems under Test (SUT) machen.
Statt der Interface Statemachines verwenden wir in der Test Sprache CaGe daher State Transition Tests. Mit State Transition Tests kann man das erwartete Black Box Verhalten (Contract) eines SUT als State Transition Diagramm beschreiben. Daraus können kombinatorische Test Cases generiert werden, welche mit sehr hoher Abdeckung die erlaubten und verbotenen Pfade im SUT testen. Ebenso kann man damit die Datenkombinatorik z.B. für Aufruf- oder Konfigurationsparameter testen.

State Transition Test als Contract zur Test Case Generierung

State Transition Testing ist eine effektive Methode um schnell und strukturiert zu hohen Testabdeckungen zu kommen. Für kleinere Probleme oder geringere Testabdeckungen kann man mit Stift und Papier Test Cases ableiten und die Tests manuell implementieren. Für größere Abdeckungen ist es sinnvoll Werkzeuge mit Test Case Generator zu verwenden.

Was also bringen und Contracts für die Tests?

Erweiterte Contracts …

Literatur- und Quellenverzeichnis

Über den Autor

Thomas Schütz ist Geschäftsführer von PROTOS und berät Unternehmen beim Aufbau domänenspezifischer Werkzeugketten für Embedded Systeme. Zudem ist er gemeinsam mit Henrik Rentz-Reichert Projektleiter des Eclipse Projektes eTrice.

Fragen, Anregungen oder Kritik zu dem Artikel? Schreiben Sie Thomas Schütz persönlich. Ihre Nachricht wird nicht veröffentlicht!




Einwilligung



Es gilt die PROTOS Datenschutzvereinbarung

Bitte stimmen Sie der Kontaktaufnahme zu, bevor Sie das Formular absenden können.

Kunde

Pari GmbH

Schlagworte: Produktion in der Medizintechnik, Traceability, Modellbasierte Automatisierung und Produktionssteuerung, Fertigungsoptimierung, SAP-Anbindung

Technologien: ROOM, Trice, eTrice, UML2, Rhapsody, Linux, Interbus-S, Sercos-III, Modbus, EtherCAT, Codegenerierung für C++ und Java, Eclipse EMF und RCP

Partner

Embedded for You

Embedded for You ist ein Verein von deutschen Anbietern für Software- und Hardwarelösungen im Bereich der Embedded Systeme. Mit unseren Partnern erstellen wir kundenspezifische Gesamtlösungen für alle Arten von Embedded Systemen.

Partner

Eclipseina

Die Eclipseina GmbH ist ein Beratungs- und Dienstleistungsunternehmen, das sich auf embedded Softwareentwicklung spezialisiert hat. Dabei bedient sie alle Disziplinen, die für eine erfolgreiche Softwareentwicklung sowohl in technischer als auch in organisatorischer Hinsicht notwendig sind.

Partner

oose.

oose bietet Ihnen exzellente Seminare, Workshops, Beratung und Projektunterstützung für Software & Systems Engineering, neue Arbeitswelten und Innovation.

Kunde

Visteon

Schlagworte: Entwicklung von domänenspezifischen Sprachen für Infotainmentsysteme, DSL-Entwicklung auf der Basis von Xtext, Middleware in C++ für verschiedene Architekturen, Tooling für Entwickler, GUI-Entwicklung für Eclipse-basierte Tools, Integration der eTrice Statemachine Editoren und Code Generatoren

Technologien:  Xtext, Xtend, Eclipse, C++, Java, eTrice, Statemachines

Kunde

Siemens

Schlagworte: Maschinensteuerungen, Barcode, Netzwerkapplikationen, Traceability in der Produktion, Datenbank Integration

Technologien: C++, XML

Kunde

SCHAEFFLER

Schlagworte: Entwicklung einer modellgetriebenen Toolchain für Mechatronik und Elektro-Mobilität auf Basis von Eclipse eTrice, Aufbau des technischen Entwicklungsprozesses mit hohem Automatisierungsgrad

Technologien: ROOM, Eclipse eTrice, Codegenerierung und Transformationen für verschiedene Sprachen und Formate (Eclipse Xtend, EMF), Entwicklung domänenspezifischer Sprachen (Eclipse Xtext), Continuous Integration (Hudson), C, Python, A2L, CAN

Kunde

HARMAN

Harman Automotive ist weltweit führender Hersteller von In-Car Premium Audio- und Infotainmentsystemen.

Schlagworte: Automatiserte Auswertung von Tracedaten aus Tests, Systemstabilität, Performance

Technologien: QNX, Perl, C++

Kunde

ept

Schlagworte: Automatisierungstechnik, Modellbasierte Steuerungslösungen für Serienanlagen, Harte Echtzeitsysteme, numerische Optimierung

Technologien: ROOM, Trice, Codegenerierung für C++ und C, CAN

Kunde

Infineon

Schlagworte: Modellbasierte Konfiguration für Microcontroller Varianten

Technologien: Eclipse-EMF, Xtext, JET, Codegenerierung für C, Java

Kunde

BMW Group

Schlagworte: Software Architektur für Bordnetze, Spezifikationen für elektronische Fahrzeugfunktionen, Modellbasiertes Rapid Prototyping für Steuergeräte, Modellbasierte Entwicklung, Automatisierte Steuergerätetests, Model und Hardware in the Loop

Technologien: ROOM, Trice, Codegenerierung, Java, C++, C, CAN, MOST, Flexray, Eclipse-EMF