Simulation

1

Entwickler von Geräten allerArt sehen sich hohem An-spruch an Design und Bedie-

nungskonzept ausgesetzt. So wün-schen Anwender aktuell immermehr die komfortable Handhabungihrer Geräte ähnlich einesSmartphones. Um diesen Ansprü-chen gerecht zu werden, steigt dieKomplexität des HMI. Folglich sindGerätehersteller gefordert, zweikomplexe Systeme in einem End-produkt zu integrieren. Dabei blei-ben die Vorgaben der Entwick-lungsressourcen im Verhältnis zuden alten Produkten annäherndvergleichbar. Doch für das Design

von Mensch-Maschine-Schnittstel-len (HMI) steht ein breites Spek-trum leistungsstarker Hardware zurVerfügung. Abbildung 1 zeigt denZeitstrahl möglicher Projekt- bzw.Projektabschnittverläufe wie Mei-lensteine in Bezug auf den Hard-ware- und den Softwareentwick-lungsprozess. Hier seien alle Pro-zesse zur Entwicklung der Ma-schine zusammengefasst als Hard-wareentwicklungsprozess. Analogsind alle Entwicklungsprozesse fürden Softwareanteil des Systems,das HMI, als Softwareentwick-lungsprozess zu verstehen. Im se-quentiellen Projektverlauf (a) wird

zunächst mit der Entwicklung derMaschine begonnen. Ist ein gewis-ser Fertigungsgrad erreicht, setztder Softwareentwicklungsprozessauf. Die anschließende Integrati-onsphase erweist sich als kurzerZeitraum, da das HMI von Beginnan ohne Berücksichtigung der Ma-schine entwickelt werden kann.Naheliegender Ansatz – um Zeitund Kosten zu sparen – ist die di-rekte Parallelisierung beider Ent-wicklungsprozesse (b). Dies birgt je-doch aufgrund einer direktenKopplung und sich sequentiell ent-wickelnden Schnittstellen Risiken:Verzögerungen im Verlauf der Ma-

Autor: Steffen Sammann, Embedded Software-Entwicklungsingenieur, macio GmbH

60

Szenarien mit separaten Hardware- und Softwareprozessen: (a) Klassischer Projektverlauf mit sequentiellen Entwicklungspro-zessen und kurzer Integrationsphase, (b) Parallele Hardware- und Software-Entwicklung mit Verzögerungen und langer Inte-grationsphase, (c) Entwicklungsverlauf mit optimaler Parallelisierung der Hardware- und Softwareentwicklungsprozesse.

Human Machine Interfaces (HMI) sind gefragt: Sie erlauben die Steuerung und Visualisierung von Prozessen unterUsability-Aspekten in Embedded-Geräten. Entwickler solcher Hardware-Software-Systeme begegnen der Heraus-forderung, zwei komplette Systeme ohne großen Zeitverlust zum Endprodukt zu integrieren: Es bedarf parallelisierterEntwicklungsprozesse für HMI und Maschine. Grundvoraussetzung sind klar definierte Schnittstellen, um das HMImittels Simulation der Schnittstellen von der Maschine isolieren zu können. Die Entwicklung des HMI ist somit un-abhängig von Hardwareprototypen, Entwickler können flexibel auf den Maschinen-Entwicklungsprozess reagieren.

Schneller zum Produkt

Schnittstellen-Simulation

schinenentwicklung wirken sichdirekt auf den Software-Entwick-lungsprozess aus. In der Rolle desSoftware-Dienstleisters kann diessogar bis zum Entwicklungsstoppreichen, wenn beispielsweise Pro-totypen oder Spezifikationen nichtverfügbar sind. Das Ideal ist je-doch die vollständige Parallelisie-rung beider Prozesse mit minima-len Störeinflüssen der Prozesse un-tereinander. Doch die Realitätkann sich diesem Ideal nur annä-hern. Dies ist in dem dritten Sze-nario (c) abgebildet. Dort beginntder Software-Entwicklungsprozessnach einer kurzen Spezifikations-phase und wird bis zum Ende desHardwareentwicklungsprozessesabgeschlossen. Dies gelingt nur,wenn sich beide Entwicklungspro-zesse ausreichend entkoppelt las-sen, ohne dabei den Bezug zu ver-lieren und in langen Integrations-phasen zu resultieren.

Parallelisierung von Entwicklungsprozessen

Kern eines hohen Parallelisierungs-grades mit klarem Fokus auf denSoftware-Entwicklungsprozess bil-det das Konzept des ‘Interface’,eines der Basiskonzepte Objektori-entierter Programmierung (OOP).Aus den Spezifikationen der Hard-ware-Schnittstellen lassen sich ent-sprechend Interfaces für die HMI-Software ableiten. Dafür ist eszwingend erforderlich, sich gutenund klaren Dokumentationsformenzu bedienen, um die Hardware-Schnittstellen zu spezifizieren. Jebesser die Dokumentation, destobesser ist die Grundlage für einegute Approximation des Verhaltensder Maschine in der Simulation. DieInterfaces ermöglichen es, die Im-plementierung der Schnittstellenach Belieben auszutauschen.

Somit kann statt der Kommunika-tion mit einer realen Hardware-schnittstelle auch eine entsprecheSimulation der Kommunikationbzw. des Verhaltens der Maschineals Implementierung des Interfacezum Einsatz kommen. Die HMI-Software muss für einen Wechselnicht angepasst werden, da siegegen das Interface, einen beste-henden Kontrakt, entwickelt wird.Das Verhalten der Maschine zu si-mulieren lässt sich auf verschiedenkomplexen Wegen erreichen. DieSimulationstiefe ist dabei abhängigvom dem Aufwand, der in die Si-mulation investiert wird, und vomHardware-Rahmen der Zielplatt-form. Die Herausforderung liegtdarin, den Einfluss des Simulations-codes auf die Ausführbarkeit derHMI-Software zu minimieren, so-dass keine sichtbare Beeinträchti-gung vorliegt. Mit hohem Auf-wand und entsprechenden Res-sourcen sind komplexe Algorith-men bis hin zu Anbindungen an Si-mulationsframeworks von Drittan-bietern wie OMNeT++ denkbar,die sogar Echtzeitverhalten der Ma-schine simulieren können. Die An-forderungen für diese Form desAnsatzes bieten häufig nur Desk-top-Systeme. Die Komplexität lässtsich für HMIs je nach Bedarf undverfügbaren Ressourcen auf einentsprechendes Level verringern.Dafür kann die Komplexität desZeitmodells reduzieren bis zumVerzicht auf ein Zeitmodell.

Mock-Objekte: Platzhalter fürechte Objekte

Microcontroller auf Seiten der Ma-schine enthalten zudem häufig Zu-standsmaschinen, die ein einfachesZeitmodell erlauben. Zustandsüber-gänge werden durch Aktionen derAnwender am HMI ausgelöst, und

Antwortzeiten können über festeWarteperioden realisiert werden.Auch das Datenmodell lässt sichdurch Verringerung von Präzisionbei der Datengenerierung in derAusführungszeit reduzieren. Dieeinfachste Technik zur Simulationder Maschine entstammt der test-getriebenen Software-Entwicklung.Unter ‘Mocking’ ist der Einsatz vonSoftware-Komponenten zu verste-hen, die als ‘Mock-Objekte’ reali-siert werden. Diese Objekte simu-lieren das Verhalten von konkretimplementierten Objekten. Unit-Tests werden somit auch in kom-plexen Programmen ermöglicht,wo das Mocking der Objekte dieSimulation von Funktionen mitnicht-deterministischen Ergebnissensicherstellt. Im Kontext von Geräte-simulationen enthalten Mock-Ob-jekte einen bestimmten Zustandder Maschine, d.h. das Objekt hin-ter dem Interface liefert nur einfa-che Werte und hat den gerings-tmöglichen Komplexitätsgrad. DieReduzierung der Simulationskom-plexität ermöglicht die Ausführungdes Simulationscodes auf der Ziel-plattform, ohne sichtbare Beein-trächtigung der HMI-Software.Dies schafft die Möglichkeit, GUI-orientierte HMIs testfähig zu ma-chen, ohne einen Prototypen derdarunterliegenden Maschine zubenötigen. Auf diesem Weg lässtsich eine gute Entkopplung vonHardware- und Softwareentwick-lungsprozess erreichen, die einenProjektablauf ermöglicht, wie inAbbildung 1 (c) dargestellt.

Architekturansatz zur Einbettung von Simulationscode

Um die nötige Flexibilität der HMI-Software zu erreichen, Simulations-code ohne Neukompilierung der

Simulation

61

Simulation

Anwendung einzubetten, reicht eineinfacher Plug-in- und Service-ba-sierter Architekturansatz. Abbil-dung 2 zeigt die grundlegendenKonzepte dieses Ansatzes: DieHauptapplikation enthält die Basis-funktionalität zur Verwaltung vonKonfiguration, Plug-ins und Servicesin Form von Managern. Ein Konfi-gurationsmanager hat die Aufgabe,die Konfiguration entweder auseiner Datenbank oder auf Basis vonDateien auszulesen und den ande-ren Softwarekomponenten der An-wendung zur Verfügung zu stellen.Für Dateien kommen validierbareXML-Strukturen in Frage, wennman in Betracht zieht, dass XMLein allgemein bekannter und gutdokumentierter Standard desWorld Wide Web Consortium ist.Die Konfiguration definiert, welchePlug-ins geladen werden sollen undwie die so bereitgestellten Serviceskonfiguriert werden sollen. Aufdiese Weise ist eine komfortableArt geschaffen, die HMI-Softwarezu konfigurieren, ohne sie für denEinsatz von Simulationscode neukompilieren zu müssen. Der Plug-in-Manager selbst lädt die Plug-insund versorgt jedes Plug-in mit dengelesenen Konfigurationen. JedesPlug-in stellt Services bereit, die dieInterfaces der Maschinenschnitt-

stelle implementieren. Es konfigu-riert die Services entsprechend dergegebenen Konfiguration und re-gistriert deren Interfaces beim Ser-vice-Manager der Hauptapplika-tion. Somit ist der Service-Managerdafür verantwortlich, Mechanismenbereitzustellen, die die Services ap-plikationsweit verfügbar machen.Dieser Architektureinsatz ermög-licht zwei Formen der Einbettungvon Simulationscode. Zum einenkönnen in komplexeren Plug-ins,die Services für den Zugriff aufeinzelne Maschinenteile bzw. –schnittstellen enthalten, granulareinzelne oder alle Services durch Si-mulationscode ausgetauscht wer-den und somit gezielt Bereiche derMaschinensteuerung simuliert wer-den. Zum anderen können Plug-insüber die XML-Konfiguration aus-getauscht werden. Ein Anwen-dungsfall ist der Bedarf, ein HMIfür Maschinen mit unterschiedli-chen Kommunikationsprotokollennutzbar zu machen. So könnendurch den Austausch der Plug-insauch Simulationen von Maschinengewechselt werden. Auf dieseWeise wird der Produktivcode vonSimulationscode klar getrennt undder benötigte Speicherplatz derHMI-Software kann bei der Aus-lieferung minimiert werden.

Prototypen-Simulation: VonProjektbeginn bis Lieferung

Mit dem grundlegenden Konzeptdes Interface aus der OOP und derTechnik des Mockings aus der test-getriebenen Softwareentwicklunglässt sich bereits Geräte-Simulationerreichen. Unterschiedliche Ansätzegestatten dabei unterschiedliche Si-mulationstiefen, wobei Mockingden kleinsten Fußabdruck in derPerformance und im Speicher desHMI hinterlässt. Dieser Ansatz ist ineinem 600 Manntage großen Pro-jekt für einen Marktführer für La-borgeräte zum Einsatz gekommen,bei dem der fehlende Prototyp vonProjektbeginn bis zur Lieferung si-muliert werden musste. Dabei wur-den die simplen Mock-Objekte umein einfaches Zeit- und Zustands-modell zur Abbildung des Maschi-nenverhaltens erweitert. Mit UseCase orientierter Softwareentwick-lung konnten bereits nach wenigenWochen erste Anwendungsfälleohne einen Maschinenprototypendurchgespielt und getestet werden.Der Simulationscode ist dabei aufeiner ARM11-CPU mit 128MbRAM und 256Mb ROM ohne sicht-bare Beeinträchtigung ausführbar.Die Simulation der Schnittstellenauf der Zielplattform hat zudemweitere Vorteile: Die Isolierung derHMIs von Maschinen ermöglichtdie HMIs für sich zu betreiben.Somit sind die HMIs bei anwen-dungsorientierter Entwicklung be-reits früh präsentierbar und testfä-hig, sodass bereits früh unter Usa-bility-Aspekten getestet werdenkann und Feedback in Design-Itera-tionen einfließen kann. Des Weite-ren lassen sich so fertiggestellteHMIs im Anschluss als Show-Caseswiederverwenden. ■

www.macio.de

62

Der Plug-in- und Service-basierter Architekturan-satz bietet Flexibilität,um Schnittstellensimula-tionen einzubetten.

2