Vollautomatisches Testen von Steuergeräten
Mit der Verwendung von eingebetteten Steuergeräten geht eine tiefe Verantwortung mit ein. Es gibt nur einen einzigen Weg der langfristig die Qualität und Zuverlässigkeit ihrer Steuergeräte sicherstellt: Intensives automatisches Testen. Control Research bietet Produkte, Lösungen und Dienstleistungen an im Bereich vollautomatische Tests. Im folgenden werden Ihnen darlegen, wieso automatische Tests nötig sind, und diese implementiert werden.
Warum herkömmliches manuelles Testen nicht funktioniert
Manuelles Testen bedeutet, dass ein Mensch manuell zahlreiche Tätigkeiten durchführt, um die Tests zu absolvieren. Obwohl dieser Ansatz nach wie vor weit verbreitet ist, kann kein optimales Ergebnis erzielt werden. Die Gründe dafür sind zahlreich:
- Manuelle Tests sind zeitaufwendig
- Manuelle Tests halten Entwickler von der Weiterentwicklung des Produktes ab
- Vor Freigaben ist Zeit knapp, es wird eher zu wenig als zu viel getestet
- Manuelle Tests sind eine monotone Angelegenheit und sind deshalb unbeliebt
- Wer weniger testet gibt schneller frei. Fehler rächen sich erst später
- Nach jeder Änderung, sei sie noch so klein, müssen sämtliche Tests wiederholt werden um Seiteneffekte zu vermeiden.
Automatisches Testen
Wie gezeigt wurde, ist automatisches Testen mehr als nur Bequemlichkeit. Es ist eine Notwendigkeit. Control Research bietet mit der CENTURIO M Plattform eine Möglichkeit, Embedded Devices vollautomatisch zu testen. Ziel des Automatisierten Testens ist es, die gesamte Soft- und Hardware einer elektronischen Steuerung zu testen, ohne dabei auf die Einflussnahme von Menschen angewiesen zu sein.
Folgendes Bild zeigt beispielhaft ein typisches Testsystem, wie es für einen Servodrive verwendet wird (der prinzipielle Aufbau kann aber auf beliebige Systeme erweitert werden):
Kern ist CENTURIO M Hardware in the Loop System. Dieses ist in der Lage sämtliche Sensorschnittstellen anzusteuern und sämtlich Aktorschnittstellen auszulesen. Dadurch können unterschiedlichste Tests implementiert werden: vom simplen Test der Schnittstelle bis hin zu komplexen Funktions- und Sicherheitstests. Der Build- und Testserver compiliert die Firmware und steuert den Test. Das Device Power Supply simuliert verschiedenste Stromversorgungszenarien (Einschaltrampen, Spannungseinbrüche, ...). Der Load Simulator ist eine hochdynamische elektronische Last, welche komplexe Lasten simulieren kann (wie z.B. einen Servomotor).
Der Testablauf
Der Gesamttest einer elektronischen Steuerung besteht aus 8 Segmenten welche im folgenden beschrieben sind.
1. Nightly Builds
Um alle Änderungen immer zeitnah erfassen zu können, ist ein sogenanntes Nightly Build System nötig. Dieses wird zeitgesteuert aktiviert, und holt sich die neusten Quellcodes aus dem Software Version Tracking System, compiliert diese, und lädt sie auf das zu testende Gerät. Hierbei sollte nicht nur der Kern der Firmware neu compiliert werden, sondern sämtliche Softwarepakete inklusive Firmware, Betriebssystem, Third Party Software, Protokollstacks, Falls es zusätzliche Applikationsspezifische Schichten gibt, werden diese auch ausgecheckt und getestet. FPGA, CPLD, Sicherheits-CPUs, Kommunikationscontroller: Für alle gilt, das die Software komplett aus den Sourcen neu gebaut werden sollte. Dadurch ist immer garantiert, dass die aktuelle (nicht freigegebene) Version compilierbar ist und getestet wird. Eventuelle Fehler werden so zeitnah zu ihrem Entstehen erkannt, und können gelöst werden solange die Erinnerung an die Änderung „frisch“ ist.
2. Ein/Ausschalttests
Das Einschalten ist der Anfang. Was sich trivial anhört ist in Wahrheit ein hochkomplexer Vorgang. Pro Geräte sind es meist mehrere getaktete Spannungsversorgungen die eingeschaltet werden: CPUs und FPGAs haben Core-, IO- und PLL- Spannungen. Manchmal ist eine Safety CPU mit an Bord. Speicher benötigen meist eine eigene Versorgung, ebenso analoge und digitale Peripherie sowie Kommunikationscontroller.
Nicht nur muss das Hochfahren sämtlicher Spannungen kontrolliert erfolgen, sondern auch das Laden des Programms, die Initialisierung und die Kommunikationsaufnahme sämtlicher Subsysteme (CPU, FPGA, Safety-CPU, Kommunikationscontroller) will zeitlich geordnet ablaufen. Sorgt eine Softwareänderung oder Hardwareänderung für Verzögerungen, können unterschiedlichste negative Seiteneffekte auftreten.
Neben dem Einschalten selbst wird auch das Ausschalten geprüft: Verhalten sich alle IO wie erwartet, oder toggelt ein Signal verbotenerweise? Wie reagiert das Gerät auf Spannungseinbrüche? Erkennt das Gerät den Einbruch und initialisiert sich neu, oder bleibt es in einem Zustand hängen den es eigentlich gar nicht gibt? Wie verhalten sich die IO beim Einschalten? Definiert und ruhig oder eher stochastisch? Ein anderer Test misst die Bootup Zeit: Diese ändert sich zunehmend mit dem Produktalter und kann Kompatibilitätsprobleme im Systemverbund erzeugen.
3. Schnittstellen
Jedes Steuergerät besitzt zahlreiche Schnittstellen um Sensoren und Aktoren zu betreiben. Zu den diskreten IO-Schnittstellen gehören sowohl digitale (24V, Sicherheitsrelais) und analoge IO (4..20mA, +-10V, Temperatur, Kraft,...) als auch komplexere Schnittstellen für Positionsgeber (Inkrementalencoder, SSI, Heidenhain, Hiperface,...). Jede dieser Schnittstellen besitzt zahlreiche Hardwarekomponenten. Des Weiteren erstreckt sich die die Software über Treiber, Kalibrierroutinen, Notfallroutinen bis hin zu Applikationssoftware. Nur ein Fehler in dieser Kette kann fatale Folgen haben. Ein regelmäßiger Test ist unerlässlich.
Das HIL-System ist in der Lage sämtliche Sensoreingänge mit Testsignalen zu beaufschlagen. Das Testsystem überwacht dann, ob das DUT die Signale korrekt wandelt. Neben den Minima, Maxima, Sprüngen und Rauschen können auch unerlaubte Signalverläufe geprüft werden, und ob das System diese erkennt. Übersprechen von einzelnen Eingängen lässt sich auch prüfen, wobei Fehler in diesem Bereich nicht unbedingt von der Hardware herrühren müssen: Ein falsch initialisierter Multiplexer kann alle möglichen negativen Effekte bewirken.
Ein anderes wichtiges Element ist die Echtzeitfähigkeit: nur zu oft bewirkt eine kleine Änderung, dass ein gewandelter Wert erst im nächsten Zyklus zur Verfügung steht.
4. Feldbusse
Der Großteil der eingebetteten Steuergeräte wird mit Feldbusschnittstellen ausgeliefert. Tests in diesem Bereich umfassen alle Kommunikationsprimitive (bei CanOpen z.B. PDO, SDO,...). Der Transfer aller unterstützten Datentypen wird getestet ebenso wie das Geräteverhalten bei Vollast. Neben komplexeren Vorgängen (wie z.B. das Ändern der Node-ID) wird auch die Echtzeitfähigkeit geprüft: Wie schnell erreicht ein Sollwert den Regler? Schleichen sich hier Fehler ein, kann es im Feld zu fatalen Folgen führen.
5. Funktionstest
Kommen wir zum Kern des Gerätes: Seinen eigentlichen Funktionen. Eine Funktion, die bei der Freigabe nicht geprüft wird, hat einen ungewissen Zustand. Dementsprechend sollte jedes Stück Funktion mindestens einmal getestet werden. Jedes Gain, jeder Softwareschalter, jeder Zustand einer Zustandsmaschine und jede Ablaufsteuerung sollten derart getestet werden, dass ihre Funktion sichergestellt ist. Dieser Aufwand mag auf den ersten Blick groß erscheinen, aber noch sehr viel größer ist der Aufwand bei jeder Freigabe diese Tests manuell durchzuführen oder etwa gar nicht zu testen.
Folgendes Bild zeigt eine Möglichkeit einen Regler mit Hilfe des HIL Systems zu testen. Es ist sofort ersichtlich, wie tief und durchdringend der Test ist. Es wird nicht nur eine Teilkomponente (in diesem Fall ein kleiner Teil der Software) getestet, sondern die Funktion im Gesamtkontext, also mit der endgültigen CPU, Speicher, FPGA, Datenbus, IO, ... wodurch sich eine der größten erreichbaren Testtiefen ergibt.
Während den Funktionstest werden ebenfalls die Ausführungszeiten gemessen. Weichen diese zu sehr ab von einem vorgegeben Maß, wird ein Fehler gemeldet. Dies verhindert Überraschungen bei der Inbetriebnahme oder im Dauerbetrieb.
Wird ein Produkt in genügend großen Stückzahlen für eine dedizierte Applikation eingesetzt, sollte überlegt werden, ob diese Applikation nicht in ihrer Gänze einmal im HIL System simuliert wird. Besonders bei hohen Stückzahlen ist ein Feldupgrade besonders teuer, hier können spezialisierte Tests Fehler minimieren.
6. Sicherheitsfunktionen
Sicherheitsfunktionen werden ebenso wie gewöhnliche Funktionen mit Hilfe des HIL-Systems getestet. Aufgrund ihrer Kritikalität werden sie jedoch gesondert betrachtet und meist auch intensiver geprüft. Fehlerfälle, die eine bestimmte Reaktion des Gerätes hervorrufen müssen, können gefahrenlos simuliert und ausgewertet werden. Selbst eine Kombination von mehreren Fehlern zu simulieren ist ebenso einfach wie Fehlerfälle beliebig oft und beliebig genau zu wiederholen.
Dieses Modell prüft ein redundes Sensorsystem, wie es oft in IEC 61508 Applikationen gefordert ist. In einem physikalischen Modell wird die tatsächliche Position berechnet, und dann über verschiedene Fehlermodi an zwei Encodersimulatoren weitergeleitet.
7. Crosstests
Sind alle Tests abgeschlossen, sind alle Subsysteme geprüft und für gut befunden, fällt immer die eine große Frage: Beeinflussen sich die Subsysteme gegenseitig? Hat eine kleine Änderungen einen Seiteneffekt bewirkt, der im Feld Probleme bereitet? Um diese Frage auszuräumen, werden Kombinationstests durchgeführt.
Nehmen wir ein vereinfachtes System mit 3 Modulen A, B und C. Bei der Ausführung von C wird der Speicherbereich von A korrumpiert.
Werden die Module innerhalb des CENTURIO M HIL-Systems einzeln getestet, wird jeder Test für gut befunden, auch wenn nach der Ausführung des dritten Tests das Modul A nicht mehr integer ist.
Testet man hingegen Permutationen in der Reihenfolge ABC, ACB, BAC, BCA, und CAB so wird im letzten Fällen der Seiteneffekt erkannt. Kombinationstests sind ein mächtiges Werkzeug bei der Fehlersuche, und gleichzeitig bauen Sie größtenteils auf bereits vorhandenen Tests auf.
8. Bediensoftware
GUIs beinhalten einen nicht unerheblichen Teil des Entwicklungsaufwandes. Aus Sicht der Kundenzufriedenheit sind sie wichtig, weil GUIs das Tor zum Produkt sind. Ob das GUI fehlerhaft ist oder das Produkt spielt im Grunde keine Rolle: unzufrieden ist der Kunde in beiden Fällen. Entsprechend wichtig ist den GUIs nicht weniger Aufmerksamkeit beim Testen zu schenken als dem Produkt selbst.
Abhängig von der Entwicklungsplattform des GUIs können unterschiedliche Ansätze zur Testautomatisierung verwendet werden. Allen Tests gleich ist, dass sie auf den üblichen Plattformen geprüft werden müssen. Hierzu können, um teure Serverhardware zu sparen, virtuelle Betriebssysteme verwendet werden. Im Falle von Windows ist das Minimum Windows XP, Windows Vista und Windows 7, jeweils in der 32 Bit und der 64 Bit Version. Hierbei sollte neben dem eigentlichen Betreiben des GUI auch dessen Installation jedes mal neu geprüft werden.
Manuelles Testen führt zwangsläufig zu schlechten Produkten
Manuelles Testen funktioniert nicht und kann nicht funktionieren! Wir demonstrieren Ihnen an einem Beispiel wieso. Der Einfachheit halber nehmen wir an, dass ein Entwickler 60% seiner Zeit implementiert, und 40% testet. Der Verlauf sieht stark vereinfacht folgendermaßen aus:
Das Problem: Mit jedem Zyklus steigt die Menge Code. Das bedeutet, dass mit konstanter Testzeit immer mehr Code immer weniger gut getestet wird. Der Entwickler könnte zwar nur den neu hinzugekommenen Code testen. Es sind aber oft Seiteneffekte die im Feld zu Fehlern führen. Simple Änderungen die an ganz anderer Stelle der Software zu Fehlern führen. Es muss also nach jeder Änderung die gesamte Software getestet werden. Die Abhilfe: der Entwickler erhöht proportional zur Code Menge die Testzeit:
Das Problem: Die Testzeit überwiegt irgendwann die Implementierungszeit. Das Produkt wird nicht mehr genügend schnell weiterentwickelt, Kundenwünsche werden sehr spät erfüllt, irgendwann ist das Produkt veraltet bevor es den Markt überhaupt erreicht.
Die einzige Lösung: Automatisches Testen. Anstatt Zeit auf manuelle Tests zu verwenden wird die Zeit in die Entwicklung von automatischen Tests investiert. Parallel zur Entwicklung werden Tests permanent ausgeführt. Mit der Menge Code steigt auch die Menge Tests.
Die Wahrheit ist: manuelles Testen degradiert die Produktivität kontinuierlich. In der Realität wird meist ein Mittelweg aus steigender Testzeit und vermehrten Fehlern gewählt, die zu Kosten der Wettbewerbsfähigkeit geht. Vollautomatische CENTURIO M Testsysteme ermöglichen es Entwicklern, sich auf das Kerngeschäft zu konzentrieren und gleichzeitig höchste Qualität und Zuverlässigkeit zu liefern.
Die Vorteile automatischer Tests
Zusammengefasst lässt sich über automatische Testsysteme sagen:- Selbst nach kleinen Änderungen werden alle Tests wiederholt, Geräte werden zu 100% getestet bevor Sie der Kunde erhält. Dies erhöht die Qualität der Produkte, minimiert Fehler, verhindert Schäden und erhöht die Reputation des Unternehmens.
- Entwickler werden vom Testen entlasten und können sich auf die Kerngebiete des Unternehmens konzentrieren. Vom monotonen manuellen Testen entlastet steigt die Arbeitsfreude und Motivation.
- Automatische Tests können im Grunde jede Nacht oder nach jedem Checkin neuer Sourcen durchgeführt werden. Fehler fallen dadurch sofort auf und können sofort korrigiert werden.
- Kosten werden gesenkt, weil zwar mehr getestet werden, durch die Automatisierung fallen aber keine Lohnkosten an. Außerdem sinken die Kosten drastisch durch weniger Fehler im Feld. Bessere Produkte verkaufen sich auch besser.
- Der Projektstatus ist klarer. Für jedes geforderte Feature werden Tests definiert. Sind alle Tests implementiert und bestanden, ist das Produkt fertig. Die Verhältnis zu bestandenen Tests zu ausbleibenden Tests gibt einen sehr viel besseren Einblick in das Projektgeschehen als die sonst üblichen vagen Prozentschätzungen, die erst exponentiell gegen 90% schießen um dann asymptotisch gegen 99% zu kriechen.
- Bei mittleren und großen Entwicklerteams kann jedes einchecken fehlerhafter Sourcen die ganze Projektarbeit zum erliegen bringen. Automatische Tests reduzieren hier Stillstandszeiten.
- In einer Endanwendung können Fehler auftreten mit erheblichen Konsequenzen, ohne das die Schuld für den Fehler einem Systemteil zugewiesen werden kann. Zumindest rechtlich sind Unternehmen mit ausgiebigen automatisierten Tests meist glaubwürdiger als ihre manuell testenden Konkurrenten.
- In größeren Systemen (z.B. ein Kraftwerk) werden eine Vielzahl von Steuergeräten verwendet. Zudem kommen diese von unterschiedlichen Herstellern mit unterschiedlichen Updateintervallen. Um Seiteneffekte im Gesamtsystem aufgrund von Updates einzelner Komponenten zu verhindern bieten sich ebenfalls automatische Tests an. In dem Moment in dem eines der Steuergeräte eine neue Firmware erhält werden sämtliche Tests mit dem Gesamtsystem ausgeführt.