Entwickeln Sie auch Plattformen in Embedded Systemen, um mehreren Kunden Lösungen anbieten zu können ohne für jedes Kundenprojekt eine komplette Neuentwicklung machen zu müssen?
Oder haben Sie vielleicht schon mal ein Embedded Betriebssystem eingesetzt, um möglichst unabhängig von der Hardware Ihre Applikation entwickeln zu können?
Für die Entwicklung der Systeme haben Sie vermutlich durch dieses Vorgehen profitiert, aber wie sah es bei der Verifikation bzw. beim Test aus? War es klar und einfach, die Plattform zu testen? War es einfach, eine vollständige Testabdeckung zu erzielen? Konnten Sie schnell und effizient gute Requirements erstellen? Nein? Dann sind Sie hier richtig!

Herausforderung Testen von Plattformen

Meiner Erfahrung nach, stellt der Test von Plattformen eine der größten Herausforderungen für das Testen überhaupt dar. Insbesondere in sicherheitskritischen Projekten muss aber eine hohe Testabdeckung erreicht werden. Ebenso müssen dann nachvollziehbare Requirements für die Plattform vorhanden sein.
Warum stellt ein Test eines solchen Systems nun ein besonderes Problem dar? Nun, ein wesentlicher Punkt ist, dass Tests dann recht einfach sind, wenn eine klar definierte Funktionalität getestet werden kann. Üblicherweise ist das gerade bei Plattformen nicht der Fall. Wie der Name schon impliziert, ist die Plattform nur eine Basis um darauf eine konkrete Funktionalität zu implementieren.
Eine Plattform ist in der Regel dann gut, wenn darauf möglichst viele verschieden Funktionen entwickelt werden können. Das bedeutet, die Plattform selber bietet vielfältigste Möglichkeiten. Sie schränkt wenig ein, hat sehr viele, möglichst variable Schnittstellen. Gleichzeitig abstrahiert sie die Hardware, sodass die zu entwickelnde Applikation sich nur wenig um das Zusammenspiel mit der Hardware kümmern muss. Bei Betriebssystemen als Plattformen, werden oft noch komplexere Mechanismen geliefert, um Forderungen aus der Funktionalen Sicherheit gerecht zu werden. Plattformentwicklungen laufen in der Regel parallel zu Kundenprojekten, sodass ein klassisches Requirements Engineering nur schwer möglich ist.
Jeder einzelne dieser Punkte erhöht den Testaufwand! Die Kombination der Aspekte erzeugt einen wirklich hohen Anspruch an das Testen:

1) Schnittstellen sind wenig eingeschränkt: Das bedeutet für das Testen, dass verschiedenste Kombinationen getestet werden müssen. Es sind ggf. Extremwerte im Test zu erzeugen, die das Testsystem an den Rand seiner Möglichkeiten bringt.
2) Viele Schnittstellen: Die Kombinationen von zu stimulierenden Werten sowie die Möglichkeiten der Reaktionen der Plattform, können schnell in Richtung „unendlich“ gehen. Bei Plattformen können das sowohl verschiedenste Software Schnittstellen, als auch physikalische Schnittstellen (wie Feldbusse, analoge oder digitale Signale) sein.
3) Die Plattform abstrahiert die Hardware: Daraus ergeben sich viele Mechanismen die zwar in der Plattform eingebaut, aber von außen nur schwer erkennbar sind. Bzw. ist es sehr schwer und bisweilen unmöglich Requirements dafür zu entwerfen, bevor zumindest ein Prototyp der Hardware vorhanden ist. Daraus ergibt sich in der Praxis, dass viele Aspekte nicht in Requirements beschrieben sind und sie dadurch auch nicht getestet werden (können).
4) Komplexe Mechanismen um Forderungen der Funktionalen Sicherheit zu erfüllen: Der Test von solchen Mechanismen – insbesondere wenn hier Robustnesstestfälle gefordert sind – stellt sehr hohe Anforderungen an die Testumgebungen. Oft können viele Aspekte hier aufgrund von mangelnden Fähigkeiten der Testumgebungen nicht getestet werden. Ein Beispiel ist das Taskscheduling. Es muss z.B. sichergestellt werden, dass die nicht-sicherheitskritischen Tasks die sicherheitskritischen Tasks nicht beeinflussen. D.h. es muss ein Mechanismus im Betriebssystem implementiert sein, um nicht sicherheitskritische Tasks im Fehlerfalle garantiert zu beenden, sodass die kritischen Tasks auf jeden Fall Ihre geplante Ausführungszeit bekommen. Wenn wir hier im Bereich von Millisekunden Tasks sind, dann muss das Testsystem für gewisse Testfälle u.U. doppelt so schnell oder noch schneller sein, um die Stimulation von Daten bzw. die Ergebnisabfrage entsprechend korrekt machen zu können.
5) Paralleles Requirements Engineering (System-/Kundenrequirements und Plattformrequirements): Diese Tatsache führt schnell dazu, dass sich Kundenrequirements und Plattformrequirements nicht vereinbaren lassen, d.h. die Kundenfunktionalität lässt sich mit der vorhandenen Plattform nicht vollständig implementieren. Ebenso steht die Plattformentwicklung oft vor dem Problem, mögliche Kundenrequirements noch gar nicht zu kennen. Dann werden Lösungen implementiert, die am Ende aber oft zwangsläufig zu Widersprüchen mit den Kundenanforderungen führen.

Lösungsansätze

Wie könnten nun Lösungsansätze dafür aussehen?
Requirementsengineering: In kaum einem anderen Bereich der Entwicklung von embedded Systemen ist die Prototypenphase so elementar wichtig wie hier. Aufgrund der starken Nähe zur Hardware und der damit verbundenen sehr hohen Komplexität bzw. vieler Abhängigkeiten verschiedenster Parameter, ist es in der Regel nicht möglich die Requirements vollständig und fehlerfrei aufzustellen und danach das System zu implementieren. Vielversprechender ist der Weg, sich zunächst ein paar grobe, und eher allgemeine Requirements aufzuschreiben und dann einen Prototyp des Systems zu bauen. Mit dem Prototypen klären sich dann meist auf eine sehr effiziente Art und Weise die Fragestellungen. Erst dann ist es möglich die Requirements in der notwendigen Detailtiefe und Genauigkeit zu spezifizieren. Leider wird oft zwar der Prototyp gebaut, die daraus gewonnen Erkenntnisse werden aber nicht zeitnah in den Requirements festgehalten, sodass gute Tests nur unter sehr erschwerten Bedingungen möglich sind.
Schnittstellen: Es sollten immer möglichst viele Grenzwerte für Schnittstellen angegeben werden. Dies erleichtert die Tests erheblich. Nach aller Erfahrung ist es auch so, dass kaum eine Software bei allen Kombinationen von extremen Parametern funktioniert. D.h. in der Regel gibt es physikalische oder programmtechnische Grenzen die oft nur nicht dokumentiert sind. Wenn man diese aber dokumentiert, werden die Grenzen für den Anwender/Integrator schneller offensichtlich und der Test vereinfacht sich ggf. erheblich.
Die Anzahl der Schnittstellen lässt sich in der Regel bei Plattformen nicht wirklich begrenzen. Hier kommt nun die Qualität des Testers zum Tragen. Er muss sinnvolle Kombinationen von Schnittstellen für den Test wählen und er muss begründete Äquivalenzklassen bilden. Je besser das gemacht wird, desto besser ist die Testabdeckung bei einer minimierten Anzahl von Testfällen.
Qualität der Testumgebung: Insbesondere beim Test von sehr sicherheitskritischen Anforderungen an das System, wird eine hohe Qualität an die Genauigkeit und die Echtzeitfähigkeit des Testsystems verlangt. Wenn hier die Grenzen des Machbaren erreicht sind, kann man oft durch eine sinnvolle Kombination von Test und Analyse, gute und akzeptable Ergebnisse erzielen. Im Einzelfall sollte aber Kontakt aufgenommen werden, zum Assessor für die Funktionale Sicherheit oder zu der zertifizierenden Behörde um diese Punkte möglichst früh zu klären. Die Erfahrung zeigt, dass eine intelligente Verifikationsstrategie schon oft die Kosten für eine Testumgebung deutlich limitiert hat.

Fazit

Wie oben dargestellt, ist das Testen von Plattformen oft sehr komplex und stellt hohe Anforderungen. Trotzdem ist es auch in diesem Bereich möglich, mit einem gut durchdachten Vorgehen qualitativ hochwertige Ergebnisse zu erzielen. In diesem Bereich ist allerdings eine möglichst große Erfahrung ein starker Erfolgsgarant.

Ihre individuellen Fragen zum Test Engineering beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).