Und täglich grüßt das V-Modell – Auf Basis unterschiedlicher Theorien über den Entwicklungsprozess eines „Embedded System", haben in den letzten sieben Jahren die verschiedensten Entwicklungswerkzeuge in den Unternehmen Einzug gefunden. Leider führt dieser Wildwuchs an Werkzeugen nicht wirklich zum Ziel. Klare Forderungen der Unternehmen nach durchgängigen Entwicklungsprozessen mit fließenden bzw. automatisierten Werkzeugübergängen führen konsequenter Weise dazu, dass Hersteller, die bisher streng getrennte Abschnitte in solchen Design-Prozessen besetzt haben, zusammenarbeiten. Zum Wohle des Kunden, denn nur so können Prozesse vereinfacht und beschleunigt bzw. Produkte zuverlässig und robust werden. Die Integration von Emulations- und Debug-Technologie in die grafische Standard-Entwicklungsumgebung LabVIEW von National Instruments ist ein erster Schritt in die geforderte Durchgängigkeit. Diese Integration bringt die bislang streng getrennten Abschnitte Software-Entwicklung für die Implementierung/Integration von Software und Hardware, sowie Tests aller Art vom Modul- bis zum Systemtest, zusammen
Motivation - Embedded Systems Entwicklung und Test, eine Bestandsaufnahme
Mit der Vision der Schaffung eines „Universellen Engineering Werkzeugs" hat es vor einigen Jahren begonnen. Heute ist man schon sehr nah an der Praxistauglichkeit eines solchen universell einsetzbaren Werkzeugs. Es ist nicht von der Hand zu weisen, dass National Instruments mit der grafischen Programmierumgebung LabView und einer weiten Palette an kombinierbarer Hardware, die Mess- und Automatisierungswelt revolutioniert hat. Dabei ist der recht einfache Grundgedanke, ein Bild sagt mehr als 1000 Worte, ausschlaggebend für die hohe Akzeptanz beim Anwender heute: intuitive Bedienbarkeit, einfach zu erlernen, Wiederverwendbarkeit, breites Einsatzfeld, folgt Standards usw.
Abb. 1: Idealbild des Software/Hardware-Entwicklungsprozesses heute. Von der Idee zum Produkt unter Einsatz entsprechender Entwicklungswerkzeuge. Dabei ist es wichtig, dass die einzelnen Entwicklungsabschnitte fließend ineinander übergehen. Unterbrechungen in den Übergängen führen zu Inkonsistenzen im Gesamtentwicklungsprozess. Der Mehrwert wie z.B. Wiederverwendung, Verkürzung von Entwicklungszeiten, Erhöhung von Qualität usw. geht verloren.
Dinge von denen man bei der Entwicklung und Test von Embedded Systems noch träumt. Projekte werden nach wie vor händisch in C oder C++ umgesetzt (zum Teil auch noch in Assembler), Spezifikationen bzw. Lastenhefte liegen in Prosaform vor, getestet wird zu wenig bzw. nicht automatisiert. Seit einigen Jahren kursiert das Schlagwort modellbasiertes/grafisches Entwickeln und Testen von Embedded Systemen im Markt. Befragt man direkt Betroffene, so erhält man Antworten wie: „Modellieren ja, aber Codieren nach wie vor alles per Hand", oder „wir evaluieren Werkzeuge zur Modellierung schon seit längerem, zum Einsatz kommen diese aber nur in Teilen" oder „wir müssen den Code im Griff haben, um performant zu implementieren" usw. Im Embedded Bereich sind dies Standardantworten beim Versuch, modellbasierte Entwicklung in das tagtägliche Projektgeschäft zu integrieren. Sehr speziell und unterschiedlich sind die Anforderungen insbesondere für Echtzeit- und sicherheitskritische Systeme (limitierte Ressourcen wie Speicher, Zeitverhalten, viele verschiedene 8/16/32 Bit Mikrocontroller, hybride Formen mit DSP, ...), als dass man den Softwareentwicklungsprozess durchgängig von der Modellierung über die komplette Generierung von Code bis hin zum parallelen Test durchziehen kann. Noch!?
Der Weg dort hin ist allerdings ein muss, da man sonst die steigende Komplexität heutiger Embedded Software nicht mehr in den Griff bekommt. Kosten, Fehleranfälligkeit und damit Produktakzeptanz beim Kunden gehen verloren, Rückrufaktionen z.B. in der Autoindustrie häufen sich.
Fließende Übergänge schaffen - Virtuelle Instrumente verbinden grafische Programmierwelt mit InCircuit- und OnChip-Emulation
Es ist durchaus nahe liegend zu hinterfragen, warum man eigentlich nicht LabView zum Entwickeln und Testen von Embedded Systemen hernimmt. Immerhin wird in den frühen Phasen des Entwicklungsprozesses, zum Aufbau von Prototypen bzw. auch in den späteren Testphasen zum Aufbau von z.B. Prüfständen, bereits LabView und entsprechende NI Hardware eingesetzt. Dennoch gehen der eigentliche Entwicklungs- und Integrationsprozess von Hardware und Software und die weiteren Phasen des Entwicklungs- und Testprozesses nicht fließend in einander über. Oft wird das bereits in frühen Phasen aufgebaute Know-how bzw. Entwickelte aufgegeben, da die entsprechenden Automatismen und Verbindungen zwischen den eingesetzten Werkzeugen fehlen.
Abb. 2: Einbindung von iSYSTEM VIs in ein LabVIEW Programm. Neben der „Fern-Steuerung“ von allgemeinen Projektmanagement- und Debugger-Funktionen der Entwicklungsumgebung winIDEA aus LabVIEW heraus, werden im Speziellen VIs für Speicher- und Registerzugriffe zur Verfügung gestellt. VIs zur Ausführung spezieller InCircuit-Emulator Eigenschaften wie Trace und Profiler sind in Vorbereitung.
Da zum Entwickeln bzw. grafischen Programmieren kompletter Embedded Systems Anwendungen noch ein paar grundlegende Innovationsschritte von Seiten der Werkzeughersteller notwendig sind (wie z.B. die Weiterentwicklung von Codegeneratoren für 8/16/32 Bit Prozessoren, Schaffung grafischer Debug Möglichkeiten usw.), war für uns die Überlegung, zunächst einmal die beiden existierenden Welten, grafische Programmierung bzw. Visualisierung via LabView und die heute zur Software-/Hardwareintegration eingesetzten In-Circruit- und OnChip-Emulatoren [1], zusammen zu bringen. Die zwar intuitiv bedienbaren Benutzerschnittstellen für Emulatoren bieten oft nur wenig Möglichkeiten der grafischen Anzeige von aufgezeichneten Daten. Verbindet man nun einen Emulator mit dem Frontpanel von LabView, so steht dem Anwender automatisch eine große Vielfalt von grafischen Darstellungsmöglichkeiten zur Analyse des Verhaltens einer Embedded Anwendung auf dem Zielsystem zur Verfügung. Umgekehrt kann ein LabView Programmierer über eine solche Verbindung, ohne spezielles Know-how über die Bedienung von Emulatoren bzw. Debuggern zu besitzen, diese in der bewährten grafischen Programmiermethode von LabView (über virtuelle Instrumente) quasi fernsteuern [4]. Dies bedeutet, dass man über ein LabView Programm eine Mikrocontroller-Anwendung auf eine beliebige Ziel-Hardware laden, diese dort ausführen und testen kann. Die Ergebnisse der Tests bzw. das Verhalten der Anwendung können dann wiederum rückgekoppelt werden, in Werkzeuge wie LabView, Diadem usw. [3]
iConnect_CreateInstance.vi
Creates instance of iConnect connection to winIDEA.
iConnect_IDE_Workspace.vi
Open, close, save, create winIDEA workspace
iConnect_IDE_Document.vi
Manages winIIDEA documents
iConnect_Debug_RunControl.vi
Execution control of the CPU
iConnect_Debug_GetStatus.vi
Returns debug status
iConnect_Debug_SetBreakpoint.vi
Sets, clears, enables or disables breakpoints
iConnect_Debug_Modify.vi
Modifies string expression with numeric value
iConnect_Debug_Evaluate.vi
Evaluates string expression to numeric value
iConnect_Debug_WriteMemory.vi
Performes CPU memory write
iConnect_Debug_ReadMemory.vi
Performes CPU memory read
iConnect_Debug_WriteValue.vi
Writes numerical value to the CPU memory address
iConnect_Debug_ReadValue.vi
Reads numerical value from the CPU memory address
iConnect_Debug_ReadRegister.vi
Evaluates register name to numeric value
iConnect_Debug_GetSymbol.vi
Evaluates address to symbol C symbol expression
iConnect_Debug_GetAddress.vi
Evaluates expression to address, type info and type size
iConnect_Debug_GetSourceAddress.vi
Evaulates source line (strSourceFilename and u32LineNumber) to address
iConnect_Debug_GetAddressSource.vi
Evaluates address to source line
Tabelle 1: Liste der zur Zeit verfügbaren VIs zur Fernsteuerung der iSYSTEM InCircuit- und OnChip-Emulatoren.
Anwendungsfeld: Testautomatisierung bei der EDAG Engineering + Design AG
Diese Überlegungen sind nicht nur Visionen, bei der EDAG Engineering + Design AG ist das Thema der Durchgängigkeit im Softwareentwicklungsprozess schon seit mehreren Jahren Realität. Hierbei hat man ein durchgängiges Konzept und System entwickelt, das automatisierten Software in the Loop Test über Softwareintegrationstest von Seriensteuergeräten bis hin zum Fahrzeugtest in der Automobilindustrie umsetzt [2].
Es werden Testfälle aus einer Prüfspezifikation (vorliegend in Form einer z.B. Doors-Datenbank) extrahiert, automatisch durchlaufen, die entsprechenden Testergebnisse quantitativ sowie qualitativ bewertet und wieder in die gleiche Datenbasis zurückgeschrieben. Man spricht hierbei von einem geschlossenen Validierungsprozess, der einer Gruppe von Softwareentwicklern und Testingenieuren die Möglichkeit bietet, mit einer einheitlichen Datenbank sowie Toolkette zu arbeiten. Es können beide Parteien bezüglich ihrer Prüfkonzepte voneinander profitieren.
Abb. 3: EDAG Testautomatisierung auf NI PXI HW Basis und über die grafische Entwicklungsumgebung LabVIEW integrierte Emulations- und Debug-Technologie.
Diese Prüfkonzepte beinhalten heute im Bereich der Diagnose einen sehr hohen Softwareaufwand. Verschiedene Stellen einer Steuergerätesoftware müssen zugänglich sein, da nur so eine optimale Testdurchführng ermöglicht wird. Es sind dazu Datenaquisitionen wie Programmzustände, EEPROM-Parameter, Reglermodis etc. notwendig.
Ein klassischer Weg ist der Transport dieser Informationen über einen CAN-Bus. Der Softwareentwickler muss hierfür spezielle Zusatzfunktionen entwickeln, die in bestehenden Programmcode eingefügt werden. Dies führt zu einer erhöhten Buslast und erfordert die Validierung dieser Zusatzfunktionen.
Das Ziel ist diesen „Schwachpunkten" bzw. Mehraufwendungen so gut wie möglich entgegenzuwirken. Eine komplette Einsparung der CAN-Diagnose ist nicht sinnvoll (z.B. Kontrolle Bandende und KFZ-Werkstatt), aber dennoch muss eine Möglichkeit gefunden werden, die es auch noch beim Fahrzeugtest ermöglicht auf z.B. EEPROM-Parameter zuzugreifen.
Dies führt schließlich zur Überlegung, einen OnChip-Emulator in allen Entwicklungsphasen einzusetzen. Hiermit lassen sich ohne Beeinflussung der bestehende Software zusätzliche Diagnoseinformationen auslesen.
Ein weiterer Aspekt ist die Möglichkeit, innerhalb einer Testdurchführung anhand der erfassten Ergebnissen die Definition des Testfalls zu modifizieren bzw. den Testfall aufgrund Analogien mit schon durchlaufenden Tests zu streichen. Somit wird eine ständige Optimierung sowie Verbesserung der Testqualität erreicht.
Die oben beschriebene Testautomatisierung wurde von der EDAG Engineering + Design AG auch für eine National Instruments basierte Entwicklungsumgebung realisiert. Durch die Einbindung der iSYSTEM Emulatoren über entsprechende VIs zur „Fernsteuerung" dieser Geräte, werden zusätzliche Diagnose Informationen nicht nur über den CAN Bus ausgelesen, sondern auch direkt über einen (Echtzeit-)Speicherzugriff im Steuergerät.
Literaturverzeichnis
[1] Erol Simsek: Debug-Welten. Leistungsmerkmale von InCircuit- und OnChip-Emulation am Beispiel von Freescale-Mikrocontrollern. MECHATRONIK, Entwicklermagazin für Elektronik, Mechanik und Mikrosystemtechnik, Hanser Verlag, 11-12/2004, S. 24-26.
[2] Alexander Siegel: Durchgängiger Prozess zur Umsetzung von automatisierten Komponenten- und Systemprüfungen. Handout zum EDAG-Vortrag am Automotive-Technologietag, 12. Mai 2004, Böblingen.
[3] iSYSTEM Handbuch für iCONNECT for LabVIEW: Getting Started. November 2004.
[4] iSYSTEM Handbuch für iCONNECT for LabVIEW: Reference Guide. November 2004.
Erol Simsek ist Vertriebs- und Marketingleiter der iSYSTEM AG in Schwabhausen bei München und seit über 12 Jahren im Vertrieb und Marketing von Werkzeugen und Echtzeitbetriebssystemen für Embedded Systems Entwicklung tätig.
Jochen Zäpf ist verantwortlich für Elektrik/Elektronik Simulationsmethoden und –techniken bei der EDAG Engineering + Design AG in Fulda.
