Testen von Embedded Systemen - Mit oder ohne TDD?

November 23, 2015

Hersteller von sicherheitskritischen Systemen müssen eingebettete Software und Anwendungen regelmäßig testen, um sicher zu stellen, dass diese die geforderten Normen und Standards einhalten. Das ist im Embedded Umfeld nichts Neues! Gängige Standards solcher stark regulierten Branchen sind beispielsweise DO-178, ISO 26262 oder IEC 62304.

 

Immer häufiger aber ändern Experten ihre Vorgehensweise und testen Anwendungen, bevor sie diese fertig codieren. Diese Methode nennt man TDD. Das macht auch Sinn, denn:

 

Als Tester und Entwickler hat man mit Test-Driven Development den Vorteil, potenzielle Fehler im Projektzyklus schneller zu erkennen und kann diese dann noch im Prozess bearbeiten.

 

Wer die Methode des „zuerst Testens, dann codieren“ anwendet, vermeidet, sich erneut in bereits abgeschlossene Codierungsvorgänge hineindenken zu müssen und verkürzt somit die manchmal sehr langen Phasen zwischen Fehlererkennung und Fehlerbehebung.

 

Geht man diesen Prozess anders an, riskiert man Modultests basierend auf dem entwickelten Code zu erstellen anstatt, diese von den Anforderungen abzuleiten und somit den Code über das notwendige Maß hinaus zu entwickeln. Das passiert häufig beim sogenannten Wasserfall-Testen mit C++, das bei der traditionellen Entwicklung von Embedded-Software Anwendung findet. Hier stellt man mit Modultests (Unit Test) sicher, dass die Anforderungen korrekt umgesetzt sind, während gleichzeitig eine Code-Coverage-Analyse die Vollständigkeit der Tests überprüft.

 

Beim „Test Driven Development“ (TDD) hingegen setzt man auf automatisierte, dynamische Analyse-Testwerkzeuge. TDD ist heutzutage dafür bekannt zahlreiche Probleme von Anfang an zu lösen, denn sie zwingt den Entwickler, von Vorneherein über die dem Testen zu Grunde liegenden Anforderungen nachzudenken.

 

Bei TDD wird der Zyklus aus Testentwicklung, Codierung und Testdurchführung sehr oft in sehr kurzen Zykluszeiten wiederholt. Das ist förderlich für ein einfaches Design und verschafft einen frühen Überblick über Resultate und erfüllte Systemanforderungen.  Um TDD anzuwenden, sollte man folgenden drei Regeln folgen: 

  • Keinen Code schreiben, bevor nicht der fehlschlagenden Modultest geschrieben wurde 

  • Nur so viele Modultests schreiben, wie zum Scheitern unbedingt notwendig sind

  • Nicht mehr Produktionscodes schreiben, als zum Bestehen des noch scheiternden Tests notwendig sind 

Dass das Entwickeln und Testen von Systemen im Embedded Umfeld eine der größten Herausforderungen für Testing- und Entwicklungsexperten darstellt, macht sich auch bei dem erhöhten Testaufwand bei der Entwicklungen von Plattformen für Embedded Systeme bemerkbar. Insbesondere in sicherheitskritischen Systemen sind Tests mitunter lebenswichtig, da die Systeme  für Geräte eingesetzt werden deren Funktionalität zu 100% gegeben sein muss, um Leben zu retten oder zu sichern. Die Medizintechnik, Automobil- oder auch Luftfahrtbranche sind hierfür die besten Beispiele. 

 

 

Wenn nun ganze Plattformen getestet werden müssen, ist dies besonders kompliziert.  Denn diese Plattformen stellen die Basis dar, auf der dann eine konkrete Funktionalität implementiert werden muss. Und diese muss den branchenspezifischen Normen und Anforderungen entsprechen.

 

Gute Plattformen bieten vielfältige Möglichkeiten der Funktionenentwicklung. Mit einer solchen zu arbeiten bedeutet auch, dass sie dem Testexperten oder Entwickler im Embedded Bereich viele variablen Schnittstellen bietet, die Hardware abstrahiert  oder komplexe Mechanismen liefert, um den Anforderungen funktionaler Sicherheit gerecht zu werden.

 

Wichtig für das Testen von Plattformen im Embedded Umfeld ist also, ein Bewusstsein für die Komplexität einer solchen zu haben und den erhöhten Testaufwand unter den folgenden Punkten anzugehen:

  1. Schnittstellen: Sind diese wenig eingeschränkt, kann man verschiedenste Kombinationen testen, um  Extremwerte im Test zu erzeugen. Diese kann man nutzen, um das Testsystem an den Rand seiner Möglichkeiten zubringen. Gibt es aber viele uneingeschränkte Schnittstellen, können die Kombinationen von zu stimulierenden Werten sowie die Möglichkeiten der Reaktionen der Plattform schnell ins Unendliche gehen. Bei Plattformen können das sowohl verschiedenste Software Schnittstellen, als auch physikalische Schnittstellen (wie Feldbusse, analoge oder digitale Signale) sein. Deshalb sollten möglichst viele Grenzwerte für Schnittstellen angegeben werden

  2. Komplexität: Um die Anforderungen an komplexe Mechanismen zur Funktionalen Sicherheit zu erfüllen, muss auf den Test eben solcher ganz besonderen Wert gelegt werden. Man sollte sicherstellen, dass die nicht-sicherheitskritischen Tasks die sicherheitskritischen Tasks nicht beeinflussen. Am besten stellt man das sicher, indem man einen Mechanismus im Betriebssystem implementiert, der sicherheitskritische Tasks im Fehlerfalle beendet

  3. Requirements Engineering: Das RE wird heutzutage immer noch zu wenig beachtet. Dabei ist es ein grundlegender Baustein eines jeden Entwicklungsprozesses. Im Entwicklungsprozess sowie beim Testen von Plattformen und Systemen im Embedded Umfeld stellt ein sorgfältiges RE sicher, dass jede Anforderung einmalig ist, sich nicht mit anderen Anforderungen überschneidet (Normalisierung) oder im Widerspruch zueinander steht (Konsistenz).

Bezieht man diese Punkte in den Entwicklungsprozess ein und arbeitet unter Berücksichtigung der Test Driven Development (TDD) Methode, kann man damit rechnen ein erfolgreiches Embedded Entwicklungs- und Testingprojekt umzusetzen, bei dem die Zielplattform während der Entwicklung nicht vergessen wird,  Anforderungen erfüllt werden und Codes schlank bleiben.

 

Die Einführung von TDD für Embedded Software erfordert zwar einen ersten Zusatzaufwand. Mit TDD können sich Entwickler aber dann auf den Aufbau und die Ausführung von präzisen und effektiven Softwaretests konzentrieren. Und wenn die Methodik erfolgreich umgesetzt wurde, ergeben sich vielfältige Vorteile, denn die Arbeitsweise wirkt sich positiv auf das Softwaredesign, das Vertrauen in die Codebasis, die Entwicklungs- und die Debugging-Zeiten aus.

 

 

 

 

 

 

 

 

 

Please reload

Kontakt: 0431 - 888 2111 0

E-Mail: marketing@scope-engineering.de

  • Grey LinkedIn Icon
  • Grey Twitter Icon
RSS Feed

© 2018 SCOPE Engineering GmbH

Impressum

Datenschutz