von Dr. Kurt Böhringer

Der Anteil und die Bedeutung der Software für Embedded-Produkte nimmt unaufhaltsam zu. Immer mehr Funktionen der Systeme, die bisher durch Hardware gesteuert wurden, werden von der Software übernommen und immer mehr Eigenschaften werden von der Software bestimmt. Dies gilt auch in steigendem Maße für sicherheitsrelevante Funktionen. Die perfekte Funktionsweise der Software bestimmt also nicht nur die Produkteigenschaften und damit den Markterfolg, sondern auch die Qualität und Sicherheit und letztlich das Marktimage.

Die Qualität der Software kann weder alleine im Design noch alleine im Test erreicht werden. In allen Phasen der Entwicklung gibt es die Möglichkeit, Qualität einzuarbeiten, und Hitex bietet für sämtliche Entwicklungsschritte die passenden Werkzeuge. Am Beispiel einer 68HCS12-Entwicklung werden im Folgenden diese Phasen des Entwicklungszyklus und die zugehörigen Methoden und Werkzeuge aufgezeigt. Beginnend beim Design über die Hardware-/Software-Integration, den automatisierten Funktionstest, die Optimierung und Verifizierung bis zum automatisierten System-Endtest wird eine zusammenpassende Kette von Werkzeugen gezeigt, die helfen, den Slogan von Hitex "Embedding Software Quality" zu verwirklichen.

Software-Design
Es ist allgemein bekannt, dass ein gutes Design die Grundlage für eine stabile Software und im Wesentlichen zuständig für eine rasche und optimale Weiterentwicklung und Pflege der Produkte ist. Jedoch sieht die Realität meist nicht so optimal aus. Die ursprüngliche Stärke der modularen Programmierung in C, nämlich die Portierbarkeit und Wiederverwertbarkeit, hat dazu geführt, dass sich die meisten Projekte vom ursprünglichen Designziel entfernt haben. Das Übernehmen von bestehenden Modulen, das Hinzufügen von Features, was fast immer unter Zeitdruck geschieht, kann eine Applikation bis zur totalen Unübersichtlichkeit wachsen lassen, obwohl eigentlich eine Überarbeitung des Designs nötig wäre. Viele Experten sprechen heute deshalb von einer enormen Softwarekrise.

Tatsächlich stehen wir vor einem Umbruch. Ähnlich wie ca. 1985, als die portierbare und allgemein anwendbare Programmiersprache C die Assemblerprogrammierung abgelöst hat, beginnen heute graphische Designwerkzeuge mit automatischer Codegenerierung in der Embedded Welt Fuß zu fassen. Hierbei gibt es die vergleichbaren Anfangsschwierigkeiten und Vorbehalte. Zu uneffektiver Code, nicht geeignet für Mikrocontroller mit wenig Memory, zu hohe Einarbeitungszeiten sind die Argumente. Heute sind die gebräuchlichen C-Compiler in der Codeerzeugung genauso effektiv wie ein geübter Assemblerprogrammierer, und nur noch in Ausnahmefällen wird auf Assemblerprogrammierung zurückgegriffen. In einigen Jahren wird das bei graphischen Programmierwerkzeugen genauso akzeptiert sein. Deren Vorteile sind allerdings besonders schlagkräftig. So lässt das Designtool Trice ein komplettes Systemdesign zu, das automatisch beim Design auch gleich Konsistenzchecks durchführt und Fehler oder noch fehlende Komponenten anzeigt. Auch die Interaktion von Komponenten kann durch Protokolle definiert werden, die auf die korrekte Abhandlung geprüft werden. Eine Weiterentwicklung der Applikation wird gleich im Systemdesign durchgeführt, was nicht nur dafür sorgt, dass das Design immer zu den Anforderungen passt, sondern auch keine Entfernung des Codes vom Design zulässt. Designkomponenten und Protokolle können auch einfach per cut & paste in andere Applikationen übernommen werden. Sehr wichtig ist, dass der anschließende Test auch in der Sicht des Designs stattfinden kann, was genau das Zusammenspiel zwischen allen Entwicklungswerkzeugen, in diesem Fall zwischen Designtool und In-Circuit-Emulator, erfordert.

Für Projekte, bei denen das Design nicht umgestellt werden soll, sind Werkzeuge vorhanden, die einen besseren Überblick über das komplette Projekt geben sollen. Der Design Assistent DA-C stellt hier eine ganze Menge Hilfsmittel zur Verfügung. Fragen wie "Wo wird FunktionXY überall aufgerufen?" oder "Wo wird Variable YZ verwendet?" werden mit der Call-Hierarchie-Darstellung oder der Type-Hierarchie-Darstellung beantwortet.

Bild 1: Call-Hierarchie-Darstellung des Design Assistenten DA-C

Die Fähigkeit, ein komplettes Projekt auf Konsistenz zu analysieren, bringt wesentliche Vorteile gegenüber den Warnings eines Compilers, der immer nur modulweise prüfen kann. Insbesondere kann hier auch auf Portierbarkeit geprüft werden. Die Definition und Überprüfung von Metriken bietet die Möglichkeit, die Einhaltung von Programmierstandards zu überwachen. Auch Abweichungen von vordefinierten Standards wie z.B. MISRA können automatisch angezeigt werden.

Integration von Hard- und Software
Nach dem Design beginnt die erste Phase des Testens. Die Hardware muss auf Funktionalität getestet werden und das Zusammenspiel zwischen Hardware und Software ist zu prüfen. Je nach Anforderungen gibt es hier verschiedene Möglichkeiten. Dank der BDM(Background Debug Modus)-Fähigkeit des HC12-Mikrocontrollers lassen sich hier bereits preisgünstige BDM-Debugger nutzen, die an die genormte BDM-Schnittstelle des HC12 angeschlossen werden. Für anspruchsvollere Applikationen, insbesondere solche mit hohem Echtzeiteinfluss großer Komplexität oder sicherheitsrelevanten Funktionen, ist ein In-Circuit-Emulator zu empfehlen, der anstelle des HC12-Mikrocontrollers in die Hardware adaptiert wird. Der In-Circuit-Emulator bietet auch Emulationsspeicher an, der es ermöglicht, die Applikation zu speichern, was das länger währende FLASH-Programmieren während des Tests erspart. Außerdem kann der Emulator auch Programme ohne Targethardware ausführen, was eine Parallelentwicklung von Hardware und Software ermöglicht.

Hitex stellt für die 68HC12-Familie ein ganzes Toolspektrum zur Verfügung, das durch die gemeinsame Bedienoberfläche HiTOP gleich zu bedienen ist und somit ohne weitere Umstände einen Wechsel von den einfacheren Produkten zu den anspruchsvolleren ermöglicht. Neben den im Mikrocontroller integrierten Hardwarehaltepunkten können auch Softpoints genutzt werden. HiTOP bietet hiermit die Möglichkeit, Programmteile in Echtzeit auszuführen und sowohl auf Assemblerebene als auch auf Hochsprachenebene im Quellfile die Korrektheit der Ausführung zu prüfen. Verschiedene Fenster erlauben auf komfortable Weise das Evaluieren und Modifizieren von Symbolen. Komplexe oder verschachtelte Strukturen oder Pointer können typengerecht evaluiert werden. Für die Peripherals der Mikrocontrollers werden vordefinierte User Windows mitgeliefert, die die Bits der Peripheral Register im Klartext anzeigen. Ein Nachschlagen der Bedeutung der Bits im Prozessorhandbuch wird somit hinfällig. Der In-Circuit-Emulator DProbeHC12 bietet einiges mehr. Neben dem genannten Emulationsspeicher, der den ganzen Adressraum des Prozessors abdecken kann, stehen beliebig viele Hardwarebreakpoints zur Verfügung. Um Schreib- oder Lesezugriffe überwachen zu können, gibt es Datenbreakpoints. Ein herausragende Besonderheit der DProbeHC12-Systeme ist die Rias-Technologie (Real time Internal Acces Supervisor). Aufgrund der Optimierung des HC12-Mikrocontrollers arbeiten hier verschiedene Prozesse parallel. Sobald der Prozessor nichts auf dem Adress-Datenbus zu tun hat, wird eine Prefetchqueue gefüllt, die einige Befehle auf Vorrat speichern kann, bevor sie ausgeführt werden. Bei Sprüngen werden Befehle in der Prefetchqueue, die nicht mehr ausgeführt werden, verworfen. Nach der Ausführung sind gegebenenfalls noch Schreibzugriffe auf den Speicher durchzuführen. Ist in einem Zyklus nichts zu lesen oder zu schreiben und die Prefetchqueue ist gefüllt, so wird ein sogenannter "free cycle" ausgeführt, der nicht von einem Read-Zyklus zu unterscheiden ist. Solch ein Zyklus ist zufällig und hat mit der Applikation nichts zu tun. Die Rias-Technologie von Hitex erkennt solche free cycles oder verworfene Prefetches und achtet darauf, dass die Emulationslogik sich hiervon nicht stören lässt. Nur durch solch eine aufwendige Technologie kann ein ungestörter und vollständiger Test der Applikation und das Einkreisen von komplexen Fehlerzuständen erfolgen. Dies wirkt besonders bei der High-end-Erweiterung DBox, bei der weitere effiziente Hilfsmittel zur Fehlersuche integriert sind. So können mit zusätzlichen Triggern komplexe Buszyklen überwacht werden. Zustände wie "das 13. Mal wird das Zeichen 'NAK' von der seriellen Schnittstelle gelesen" oder "der Wert 0x1234 wird auf die Variable XY geschrieben" können hiermit in Echtzeit verfolgt werden. Diese Trigger können auch zu einer Sequence zusammengefasst werden oder zur Überwachung von Zeiten zwischen Ereignissen auch als Timertrigger. Die Tracelogik bietet den Vorteil, den Ablauf des Programms aufzuzeichnen und zurückzuverfolgen. Mit bis zu 256k Frames ist dieser Puffer sehr groß, wobei jeder Frame sowohl die Daten, die Adressen, den Status, über eine Logikprobe einspeisbare externe Signale und einen Zeitstempel enthält. Hiermit sind auch Applikationen untersuchbar, die während des Tests nicht angehalten werden dürfen. Mit den passenden Werkzeugen in verschiedenen Ausbaustufen ist ein komfortabler Test bis zum Aufspüren der hartnäckigsten Bugs möglich.

Bild 2: DProbeHC12 mit der High-end-Erweiterung DBox

Automatisierter Funktionstest
Auf die Frage, ob ein Entwickler genau weiß, wann er seinen Test beendet hat, bekommt man oft ein Schulterzucken. In vielen Fällen entscheiden Abgabetermin oder ein mehr oder weniger gutes Gefühl über den Abschluss der Tests. Ein weiterer Problempunkt ist der Fakt, dass der Testaufwand nach kleinen Bugfixes oft größer ist als der Bugfix selbst. Oder man geht einfach davon aus, dass es keine Seiteneffekte geben kann - aber kann man sich da immer sicher sein?

Je nach Anforderung sinnvoll definierte Testfälle und die jederzeitige automatische Wiederholbarkeit der Tests sind hier die Abhilfe. Auch hierzu gibt es das richtige und zeitsparende Werkzeug: Tessy.

Mit Tessy lassen sich automatisierte Tests auf Funktionsebene durchführen. Mit dem Testdateneditor können für die Testfälle die Eingangsparameter und die zugehörigen Ergebnisse definiert werden. Gespeichert werden diese Testfälle in einer jederzeit wieder nutzbaren Testdatenbank. Tessy baut um diese Funktionen einen Testtreiber, compiliert mit der gewünschten Entwicklungsumgebung und führt dann alle gewünschten Testfälle in Zusammenarbeit mit einem Hitex In-Circuit-Emulator in Echtzeit auf Wunsch auch im Target aus. Alle erhaltenen Ergebnisse werden mit den definierten Werten verglichen und Abweichungen angezeigt. Erkannte Fehlerfälle können wiederholt aufgerufen werden. Zum Aufspüren des Fehlers setzt Tessy den Emulator an den Anfang der Funktion mit den Bedingungen des aufgetretenen Fehlerfalls und hält dann an. Nun kann mit den gewohnten Methoden der Fehler aufgespürt werden. Nach dem Bugfix kann wieder compiliert werden und alle Tests können nochmals automatisch ablaufen, wobei die korrekte Behebung des Fehlers ohne Seiteneffekte geprüft wird.

Auch zur sinnvollen und übersichtlichen Definition der Testfälle nach der Klassifikationsbaum-Methode wird ein Werkzeug zur Verfügung gestellt, das ein Teil des Tessy-Softwarepaketes ist.

Bild 3: CTE Editor von Tessy zur Definition der Testfälle nach der Klassifikationsbaum-Methode

Optimierung und Verifizierung
Ist die Applikation nun ausgiebig auf Programmierfehler getestet, sind meistens noch Nacharbeiten nötig. Die Reaktionszeiten sind eventuell zu langsam und Flaschenhälse bei der Abarbeitung zu entfernen. Die DProbeHC12 mit der DBox bietet hier viele Funktionen. Mit verschiedenen Performance-Analyse-Methoden können komfortabel Messungen durchgeführt werden. Die Execute-Profile-Analyse gibt einen raschen Überblick über die CPU-Zeit, die in verschiedenen Funktionen, Modulen oder beliebigen Codeteilen verbraucht wird. Für jeden definierten Bereich wird der Anteil der CPU-Zeit angegeben. Anwendungsbereiche sind z.B. das Aufspüren von Flaschenhälsen bei der Abarbeitung, Programmstellen, bei denen es sich lohnt zu optimieren, oder auch die Auslastung der CPU durch Interrupts zu bestimmen. Weitere komfortable Methoden für diverse nützliche Zwecke sind vorhanden.

Muss die Reaktionszeit auf Echtzeiteinflüsse nachgewiesen werden, können optimal die Timer Trigger eingesetzt werden. Hiermit können zwei Events definiert und deren Zeitabstand gemessen werden. Ist der tatsächliche Zeitabstand größer oder kleiner als ein zu definierender Sollwert, wird der Timer Trigger aktiv und damit kann entweder die Emulation angehalten oder die Traceaufzeichnung gezielt gesteuert werden. Damit ist ein Aufspüren der Ursache möglich.

Mit Hilfe der Coverageanalyse lässt sich nicht ausgeführter Code anzeigen. Dies wird genutzt, um zu beweisen, dass alle Programmstellen getestet wurden, was bei sicherheitskritischen Applikationen oft verlangt wird. Bei knappem Speicherplatz kann auch nicht genutzter Code aufgespürt werden.

Automatischer System-Endtest
Mit der Kommandosprache HiSCRIPT, die die Bedienoberfläche HiTOP der Emulatoren von Hitex automatisch steuern kann, werden automatisierte Endtests des kompletten Systems möglich. HiSCRIPT hat eine an die Programmiersprache C angelehnte Syntax, mit der neben der kompletten automatisierten Bedienung des Emulators auch bedingte Verzweigungen oder Ausführungsschleifen möglich sind. Hiermit ist auch automatisiert eine fehlersensitive Abarbeitung des Scripts möglich.

Sehr hilfreich wird dieser automatisierte Systemendtest in Produktionsabteilungen zum Test aller produzierten Geräte eingesetzt. Ein Testscript, das alle relevanten Eigenschaften des produzierten Gerätes prüft, wird automatisch ausgeführt und die Ergebnisse mit einem Masterprotokoll verglichen. Abweichungen werden angezeigt und können einen Hinweis auf den gefundenen Produktionsfehler geben. Aber auch in Entwicklungsabteilungen ist so ein Test sinnvoll. Jedes neue Hardware- oder Software-Release wird diesem Testablauf unterworfen und ungewollte Abweichungen zur Vorgängerversion werden schnell und ohne wesentlichen Zeiteinsatz des Entwicklers erkannt.

Fazit:
Für alle Phasen einer Embedded-Entwicklung ist die Wahl der richtigen Werkzeuge unabdingbar für die Qualität und Wartbarkeit des Produktes und damit für den Markterfolg. Um den optimalen Nutzen zu erzielen, müssen selbstverständlich alle Werkzeuge dieser Kette nicht nur reibungslos zusammenspielen, sondern sich gegenseitig synergetisch unterstützen.