Timing-fokussiertes Design eingebetteter Systeme Matthias Dörfel, Tapio Kramer,

Transkript

1 Timing-fokussiertes Design eingebetteter Systeme Matthias Dörfel, Tapio Kramer, Durch Design-Fehler entstandene Timing-Probleme werden häufig erst sehr spät im Entwicklungsprozess erkannt. Werden jedoch beim Systementwurf die zeitlichen Eigenschaften und Anforderungen (Antwort- und Latenzzeiten, Ressourcenauslastung) berücksichtigt, können aufwändige Re-Designs vermieden werden. Der Vortrag beschreibt einen Ansatz, in dem ein UML-Modell zu einem Timing-Modell erweitert wird und mittels Echtzeitsimulation und analyse frühzeitig überprüft wird. Motivation Besonders im Bezug auf das Echtzeitverhalten von eingebetteten Systemen steht der Systemarchitekt vor einem Dilemma: Das Zeitverhalten der später zu implementierenden Software bestimmt wesentlich, wie die Architektur des Systems ausgelegt wird, welche wiederum Einfluss auf das Zeitverhalten hat. Das betrifft sowohl so grundsätzliche Fragen wie die Auswahl der Prozessoren und Bussysteme, als auch der Partitionierung der Software- Module und deren Verteilung auf Tasks und Prozessoren Für die funktionale Architektur hat sich schon lange die Erkenntnis durchgesetzt, dass ein modellbasierter Entwicklungsprozess das Mittel der Wahl ist, die Komplexität zu beherrschen. Verwendet man hierbei zudem eine Modellierungstechnik, deren Modelle ausführbar sind, kann bereits in frühen Entwicklungsphasen das funktionale Modell simuliert, verifiziert und optimiert werden. Die gleichen Vorteile bietet eine Echtzeitsimulation für den Bereich des Echtzeitverhaltens eines eingebetteten Systems. Parallel zum funktionalen Modell wird ein zeitbehaftetes Modell (Timing-Modell) durch Erweiterung der vorhandenen Modelle um Timing- und Performance- Informationen erstellt [LOK]. Mit Hilfe dieses Timing-Modells kann der Architekt nun seine Entscheidungen mit Simulationen und Analysen des Echtzeitverhaltens der geplanten Systemarchitektur fundiert begründen. Modellierung in UML Im modellgetriebenen Entwicklungsprozess (engl. Model Driven Design, MDD) wird das System mit visuellen Mitteln und Einsatz von Industriestandards wie SysML oder UML entworfen. Komplexe Entwürfe können von den jeweiligen Domänenexperten in der Ihnen geläufigen Darstellungsform eingegeben werden, wodurch sichergestellt ist, dass die geforderte Funktion auch implementiert wird. Bereits im Entwurfsprozess können die Modelle ausgeführt werden. Auch kann Code generiert werden, der der Spezifikation entspricht. Beides dient dazu, frühzeitig sicher zu stellen, dass die geforderte Funktionalität erfüllt und die geforderten Systemreaktionen auftreten werden. Embedded Software Engineering Kongress Dez

2 Funktionalität System Architektur class_2 Findung und Beschreibung, was das System leisten soll actor_0 usecas e_1 Use-Case Diagramm Erstellung einer Architektur und Bewertung von Alternativen 1 object_0 1 object_0 1 object_1 1 Blockdiagramm Interaktion ENV role_0 role_1 Verhalten message_0() state_1 Definition und Validierung, wie das System reagieren soll Bild 1: Der Modellierungsvierkampf message_1() message_3() message_2() Sequenzdiagramm Spezifikation des formalen Verhaltens und Ausführung zur Überprüfung state_0 state_2 State-Chart Das System wird in vier Typen von Diagrammen grafisch modelliert. Im funktionalen Modell (z.b. In einem Use-Case-Diagramm) wird beschrieben, was das System leisten soll. In den Struktur- und Blockdiagrammen wird die Architektur des Systems beschrieben. Die Interaktion des Systems mit der Umgebung und die Kommunikation zwischen den Systemkomponenten wird mit Hilfe eines Sequenzdiagramms beschrieben. Es zeigt auch die spezifizierten Reaktionen der Komponenten, die mit dem Simulationsergebnis verglichen werden können. Das detaillierte Verhalten wird in State-Charts und Aktivitätsdiagrammen spezifiziert. Oft kann daraus durch Code-Generatoren auch die Implementierung erzeugt werden. Mit diesen vier Diagrammtypen lässt sich das System mit all seinen Facetten, die zum Teil voneinander unabhängig sind, vollständig beschreiben. Je nach Systemzweck und Anwendungsfall sind sie oft sogar unterschiedlich detailliert. Für die Echtzeiteigenschaften des Systems sind insbesondere das Architekturmodell, die Interaktion mit der Systemumgebung und die Verhaltensspezifikation ausschlaggebend. Daher werden diese Diagramme um die notwendigen Attribute erweitert, um das Timing-Modell zu erhalten. Modellierung des Zeitverhaltens Die Erweiterung des Systemmodells zu einem Timing-Modell erfolgt im Wesentlichen in drei Bereichen: der Beschreibung des Zeitbedarfs der Funktion, der Verteilung der Funktion auf Ressourcen und der Definition der Anregung des Systems. Durch Annotation der Systemteile mit ihren Netto-Ausführungszeiten lässt sich später aus dem funktionalen Verhalten das zeitliche Verhalten der Funktionen ermitteln. Diese Parameter werden als Eigenschaften der Systemteile spezifiziert. Die Funktionen werden auf die Hardware-Ressourcen verteilt (das Mapping), um festzulegen, auf welcher Ressource die Funktion ausgeführt wird und dort Zeit verbraucht. In der hier vorgestellten Lösung wird die Hardware-Zuordnung SysML-ähnlich als Relation von Klassen (Tasks) zu Blöcken (CPUs) dargestellt werden. Der für die CPU verwendete Stereotyp bietet die Möglichkeit, ein Prozessormodell aus der Simulationsbibliothek der INCHRON Tool- Suite zu referenzieren. Wesentliche Parameter dieser Modelle sind das RTOS auf diesem Prozessor, dessen Scheduling sowie Hardware- und Prozessorkerndetails. Diese Parameter können im Architekturdiagramm je nach Modell auch überschrieben werden. Embedded Software Engineering Kongress Dez

3 Stimulus Ressource Tasks Bild 2: SysML Mapping von Tasks auf Prozessoren Um die dynamischen Reaktionen und das dynamische Zeitverhalten des Systems modellieren und simulieren zu können, ist zu definieren, wie das System von Außen angeregt wird. Die Anregungen eingebetteter Systeme erfolgen zumeist als Interrupts und eintreffende Nachrichten. Interrupt aus verschiedenen Quellen können unterschiedlichen Raten haben und sind gegebenenfalls auch miteinander korreliert. Zur Eingabe ist es sinnvoll, die in den Interaktionsdiagrammen definierten Szenarien weiterzuverwenden. Dazu werden zum Beispiel Sequenzdiagramme in Interrupt-Sequenzen übersetzt, die in der INCHRON Tool- Suite weiter variiert werden können. Außerdem lassen sich aus den Diagrammen Echtzeit- Anforderungen ableiten, die in der Simulation automatisch validiert werden. Als Resultat dieser Erweiterung erhält man ein UML-Echtzeitsimulationsmodell. Neben der Simulation des funktionalen Verhaltens für eine frühzeitige funktionale Verifikation, kann nun auch das Echtzeitverhalten und die Systemperformance bereits in der Architekturphase simuliert und überprüft werden. Simulation, Analyse und Optimierung Die beschriebenen Erweiterungen der UML wurden in einem Profile in IBM Rational Rhapsody implementiert. Anders als die Profiles SPT und MARTE enthält dieser Profile nur die notwendigsten Stereotypen und Typen, um die Einstiegshürde niedrig zu halten. Darüberhinaus enthält der Profile auch Code für Code-Generatoren. Aus dem Echtzeitsimulationsmodell in UML generiert Rhapsody automatisch ein Projekt für die Echtzeitsimulation und analyse mit chronsim. Das Projekt besteht aus einer XML- Projekt-Datei und C-Code (ein Task-Model [KOM]) zur detaillierten Modellierung des Systemmodells in einer Darstellungsform, die vom Benutzer erweitert werden kann und dem Target-Code beliebig nahe kommen kann. Embedded Software Engineering Kongress Dez

4 abstrakter Code Delay, Eventchain UML Echtzeitsimulationsmodell Target-Code chronsim Projekt-File Bild 3: Rhapsody generiert ein Task-Model zur Echtzeitsimulation mit chronsim Für die Simulation des Echtzeitverhaltens wird aus dem Task-Modell und allen weiteren Informationen ein ausführbares Simulationsmodell erzeugt und unter Kontrolle des Echtzeitsimulators gestartet. Der Benutzer kann während der Simulation interaktiv die definierten Anregungen in die Simulation einspeisen. Das Ergebnis ist die Darstellung aller relevanten Systemereignisse und deren Auftretenszeitpunkt. So können die Abläufe in den einzelnen Mikroprozessoren des Systems zeitlich eingeordnet werden. In den verschiedenen Diagrammen kann das Echtzeitverhalten des Systems beobachtet und analysiert werden. Im Task-Zustandsdiagramm kann genau beobachtet werden, wie die Systemteile, die auf Tasks und Interrupt-Service-Routinen verteilt wurden, abhängig vom Systemmodell aktiviert werden und sich gegenseitig verdrängen. Wenn wie in Bild 4 ein zyklisch auftretender Interrupt eine Task aktiviert, ist diese Abfolge in den Kurven 1 und 2 im Diagramm zu sehen. Ein asynchroner, hochpriorer Task kann den zyklischen Task jedoch so lange verdrängen, dass eine Mehrfachaktivierung des zyklischen Tasks stattfindet. Dieser Verlust einer Aktivierung wird vom Echtzeitsimulator erkannt und im Diagramm markiert. RTOS Task-Zustände Task-Verdrängung Mehrfachaktivierung Bild 4. Task-Zustandsdiagramm mit asynchronen Prozessen Eine tiefgehende Analyse der Echtzeitabläufe ermöglicht das gegenüber der UML um eine Zeitachse erweiterte Sequenzdiagramm. Hierin wird zu allen Ereignissen die Simulationszeit gezeigt. Jede Task und ISR wird mit einer eigenen Lebenslinie dargestellt, eine Embedded Software Engineering Kongress Dez

5 unterschiedliche Strichstärke symbolisiert, ob die Task oder ISR gerade ausgeführt wird. Für jede ausgewertete Echtzeitanforderungen der Status mit roten und grünen Markierungen hervorgehoben. So wird deutlich, welche Reaktion eines Systemteils nur unter Verletzung einer Echtzeitanforderung erfolgen wird. Zusammenfassung Es wurde am Beispiel der UML eine Möglichkeit gezeigt, wie vorhandene Systemspezifikationen um eine Modellierung des zeitlichen Verhaltens eingebetteter Systeme erweitert werden können. Der Anwender kann dadurch sehr früh im Entwurfsablauf die Auswirkungen seiner Entwurfsentscheidungen auf das Echtzeitverhalten abschätzen. Dieser Ansatz ist als Profile in IBM Rational Rhapsody implementiert worden, das von Kunden eingesetzt wird. Durch die in Rhapsody vorhandenen Codegenerator-Mechanismen wird automatisiert ein Echtzeitsimulationsmodell erzeugt. Der Zeitaufwand zur Erstellung eines weiteren Timing-Modells neben einem funktionalen Modell entfällt. Literatur [KOM] T. Komarek, M. Dörfel, R. Münzenberger; Januar 2007; Developing Real-Time Constrained Embedded Software Using Task Models; Advanced Automotiv Electronics (AAE 2007), Gaydon; [LOK] M. Lokietsch; Juni 2009; Performance-Analyse von UML-Systemen; Fachkongress Echtzeitentwicklung; München; Autor: Matthias Dörfel, Gründer und Geschäftsführer Entwicklung der INCHRON GmbH, hat an der TU München Informatik studiert und anschließend als Hardware- und Firmware-Entwickler praktische Erfahrung mit der Entwicklung eingebetteter Systeme gesammelt. Die Rückkehr in das universitäre Umfeld als wissenschaftlicher Mitarbeiter der Universität Erlangen-Nürnberg führte ihn in einem DFG-Schwerpunktprogramm mit den anderen Gründern der INCHRON GmbH zusammen. Embedded Software Engineering Kongress Dez