Timing-fokussiertes Design eingebetteter Systeme
UML-Modell zu Timing-Modell erweitert
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.
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. 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. 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 werden 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. 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. Interrupts aus verschiedenen Quellen können unterschiedliche 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über hinaus 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) zur detaillierten Modellierung des Systemmodells in einer Darstellungsform, die vom Benutzer erweitert werden kann und dem Target-Code beliebig nahe kommen kann. 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.
Echtzeitverhalten beobachten und analysieren
m 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. 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 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.
Auswirkungen auf Echtzeitverhalten frühzeitig abschätzen
Dieser Ansatz ist als Profile in IBM Rational Rhapsody implementiert worden, das von Kunden [Molt] eingesetzt wird. Durch die in Rhapsody vorhandenen Codegenerator-Mechanismen wird automatisiert ein Echtzeitsimulationsmodell erzeugt. Dadurch entfällt der Zeitaufwand zur Erstellung eines weiteren Timing-Modells neben einem funktionalen Modell.
Autor: Matthias Dörfel, Gründer und Geschäftsführer Entwicklung der Inchron GmbH
