Methode zur Entwicklung sicherheitskritischer eingebetteter Systeme mittels deterministischer UML-Modelle Zamira Daw, Flor Alvarez, Marcus Vetter Institut für Embedded Systems Hochschule Mannheim D-68163 Mannheim, Deutschland Email: {z.daw, f.alvarez, m.vetter}@hs-mannheim.de Zusammenfassung Parallele Verarbeitungen erhöhen die Komplexität bei der Entwicklung von signalverarbeitenden eingebetteten Systemen. Die Synchronisierung der Ressourcen und die Gewährleistung von deterministischem Verhalten werden häufig nicht betrachtet. Infolgedessen erfordern die Suche und die Behebung von Fehlern mehr Zeit. Diese Arbeit stellt eine Methode zur Entwicklung von signalverarbeitenden eingebetteten Systemen vor. Durch das in dieser Arbeit vorgestellte DMOSES-Profil werden deterministische Modelle in UML unabhängig von der Hardware- Plattform gewährleistet. Bei der Entwicklung von sicherheitskritischen Systemen wird die DMOSES- Methode zur Sicherstellung eines deterministisches Ausführungsverhalten genutzt. Schlüsselworten: UML, Aktivität, determinitisches Verhalten, eingebette Systeme. 1 Einführung Die Entwicklung von eingebetteten Systemen wird stets komplexer und anspruchsvoller. Die wenig handhabbare Komplexität in der Entwicklungsphase erhöht den Aufwand bei sicherheitsrelevanten Anwendungen. Durch den Einsatz von modellbasierten Methoden ist die Entwicklung von eingebetteten Systemen übersichtlicher und infolgedessen weniger fehlerbehaftet. Die Unified Modeling Language (UML) [2] hat sich zur Modellierung und Entwicklung von eingebetteten Systemen bedeutend verbreitet. Durch Profile ermöglicht UML die Spezialisierung der Modellierungssprache auf konkrete Domänen. Eine bedeutende Anzahl von UML-Profilen wird zur Modellierung von Embedded-Systemen mit unterschiedlichen Zielsetzungen entwickelt. Unter diesen befindet sich das TURTLE-Profil [3]. Es erweitert die Klassen- und Aktivitätsdiagramme zur Modellierung von Echtzeitsystemen. SysML (Systems Modeling Language) [4] verfolgt insbesondere die Beschreibung von Systemanforderungen und ermöglicht die Analyse und Evaluierung Diese Arbeit erfolgt im Rahmen des MERSES-Projekts [1] mit Unterstützung der EU und des Landes Baden- Württemberg. des Systems. MARTE: A UML Profile for Modeling and Analysis of Real-Time and Embedded Systems [5] richtet sich auf die Analyse von Scheduling und Performance. Außerdem ist MARTE der Nachfolger vom UML Profile for Schedulability, Performance and Time (UML/SPT) [6], das von der OMG (Object Management Group) 2002 angenommen wurde. executable UML (xuml)[7] ist ein UML-Profil, das die Erstellung direkt ausführbarer Modelle ermöglicht. Diverse CASE-Tools bieten die Möglichkeit, aus den UML-Modellen automatisch Code zu generieren. Manche Entwicklungsfehler werden durch die automatische Codeerzeugung vermieden. Trotzdem ist diese Eigenschaft der CASE-Tools stark eingeschränkt, da häufig nur aus den Klassen- und Zustandsdiagrammen Code generiert werden kann und dies nur in spezifischen Programmierungssprachen wie C++ oder Java. Ein anderes bestehendes Problem bei der Codegenerierung ist die nicht ausreichende Information innerhalb des Modells. UML-Profile wie MARTE, SysML und xuml erweitern die UML-Semantik, um diesen Informationsmangel zu beheben. Diese Arbeit stellt eine Methode zur Entwicklung sicherheitsrelevanter Systeme vor. Sie basiert auf einem Ansatz zur Modellierung und Implementierung von deterministischen signalverarbeitenden eingebetteten Systemen (DMOSES). Die DMOSES- Entwicklungsmethode stellt ein deterministisches Verhalten von der Modell- bis zur Codeebene sicher. Sie benutzt das DMOSES-Profil, das eindeutige implementierbare UML-Modelle gewährleistet. Aus diesen Modellen wird mit einem in Eclipse integrierten Tool Code generiert. Unser Ansatz deutet eine Vorgehensweise zur Verifizierung und Zuverlässigkeitsmessung eines sicherheitstechnischen Systems an. 2 Stand der Technik 2.1 UML-Profile Die UML-Semantik kann durch die in einem Profil definierten Stereotypen und Tagged Values erweitert bzw. auf einen ausgewählten Bereich spezialisiert werden. MARTE [5] ist ein UML-Profil zur Modellierung von echtzeitbasierte eingebetteten Systemen.
Dieses Profil fügt UML-Modellen Konzepte für Zeit und Ressourcen hinzu. Mit MARTE können multiple Zeittypen modelliert werden, was im SPT-Profil nicht möglich war. Außerdem lassen sich in verschiedenen UML-Diagrammen die Hardware-Plattformen mit verschiedenem Detailgrad beschreiben. Das Profil legt mehrere Stereotypen für die Modellierung von Scheduling fest, um die Analyse des Schedules und der Leistung des Systems zu ermöglichen. Der in dieser Arbeit vorgestellte Ansatz unterscheidet sich von MARTE darin, dass die Zeit eine zentrale Rolle in MARTE spielt. Stattdessen konzentriert sich DMOSES darauf, ein deterministisches Systemverhalten zu gewährleisten. Darüber hinaus ermöglicht das DMOSES-Profil nicht die Modellierung von Schedule, die in DMOSES inhärent definiert sind und auf statischen Prioritäten basieren. SysML [4] ist ein Modellierungsstandard der OMG für Systems Engineering. SysML basiert auf einer Untermenge von UML 2.0 [2]. Die aus UML stammenden Diagramme werden durch Stereotypen und Tagged Values erweitert. Außerdem bietet SysML neue Diagrammean, durch die die Modellierung von komplexen Systemen erleichtert wird. Ein Schwerpunkt von SysML ist die Analyse von Systemen. Durch das Anforderungsdiagramm können die Systemanforderungen miteinander bzw. mit anderen Modellelementen verbunden werden. Sowohl MARTE als auch SysML verfolgen andere Zielsetzungen als das DMOSES-Profil. Die Zieldomäne von DMOSES sind die signalverarbeitenden eingebetteten Systeme, in denen die Modellierung von Datenflüssen eine wichtige Rolle spielt. Aus diesem Grund basiert unser Ansatz zur Modellierung des Systemverhaltens auf den UML-Diagrammen für Aktivitäten und Zustandsautomaten. Die Zielsetzung des DMOSES-Profiles ist das Hinzufügen hinreichender Informationen zu den Modelle, um ein deterministisches Systemverhalten sicherzustellen. 2.2 Modellunterstützte Entwicklung von sicherheitsrelevanten eingebetteten Systemen Aufgrund der zunehmenden Komplexität der Entwicklung von sicheren eingebetteten Systemen wird ihr Entwicklungsprozess mit der Modellierung unterstützt. Die vorgestellte Methode in [8] unterstützt die Modellierung von Hardwareplattformen. Diese Architektur erhöht die Verlässlichkeit des Systems. [9] und [10] verwenden die automatische Codegenerierung aus UML-Modellen für die Entwicklung von eingebetteten Systemen. Unter Verwendung des Codegenerators openarchitectureware [11], der auch in dieser Arbeit eingesetzt wird. [9] beschreibt eine template-basierte Methode, um Codegenerierung für verschiedene Plattformen zu ermöglichen. [10] erweitert UML-Modelle zur Ergänzung um Informationen, die für die automatische Codegenerierung von sicherheitskritischen Systemen relevant sind. Das xuml [7] Profil wird [12] zur Modellierung von eingebetteten Systemen benutzt. In dieser Arbeit wird eine Methode zur Verifizierung von xuml mittels des COSPAN-Checkers vorgestellt. Die in [13] beschriebene Methode führt eine Co-Verifizierung ein, die innerhalb der Transformation der xuml-modelle stattfindet. Die Verifizierung von DMOSES-Modellen findet auch innerhalb der Codegenerierung in der Modell-zu- Modell-Transformation statt(sektion 4). 3 DMOSES Deterministische MOdelle für Signalverarbeitende Eingebettete Systeme Die Entwicklung von deterministischen Systemen wird aufgrund zunehmender Parallelverarbeitung immer komplexer. Aus diesem Grund haben wir die DMOSES-Methode zur Sicherstellung von deterministischen Modellen für die Entwicklung von signalverarbeitenden eingebetteten Systemen entwickelt. Nichtdeterministisches Verhalten wird somit bei der Implementierung unabhängig von der Hardware-Plattform ausgeschlossen. In unserem Ansatz werden die Aktivitäts- und Zustandsdiagramme zur Verhaltensbeschreibung eines Systems verwendet. Das Verteilungsdiagramm wird zur Modellierung der Hardware- Struktur genutzt. Datenflüsse können innerhalb von Aktivitätsdiagrammen modelliert werden. Ereignisgesteuerte Systeme können mit dem Zustandsdiagramm besser als mit den anderen UML-Diagrammen modelliert werden. Seit der UML 2.0 sind die Aktivitätsund Zustandsdiagramm vollständig voneinander unabhängig. Diese Trennung erreicht eine Orthogonalität zwischen den beiden Modelltypen. Die kombinierte Anwendung beider Modelle ermöglicht damit ein umfassenderes Systemmodell. 3.1 Die fundamentale ausführbare Einheit in DMOSES Eine Aktion ist die fundamentale Einheit von ausführbarer Funktionalität im Modell (Abbildung 1). In unserem Ansatz ist das Verhalten der Aktion unabhängig sowohl vom Modell, das sie beinhaltet, als auch von der Hardware-Einheit, auf der sie ausgeführt wird. Dies ermöglicht ein deterministisches Verhalten, das von der Hardware unabhängig ist. Die Aktion kann einfache oder komplexe Funktionalitäten repräsentieren, die auf der Codeebene innerhalb einer Calculate-Methode implementiert werden. Die Pins bekommen eine wichtige Bedeutung als Schnittstelle der geschlossenen ausführbaren Einheit, da sie die Datenintegrität sicherstellen. Die Ausführung einer Aktion findet nur statt, wenn alle Tokens [2] an ihren Eingangspins anliegen und die Vorbedingungen erfüllt sind. Darüber hinaus sind die Pins verantwortlich für die Weitergabe der Daten. Auf diese Weise wird die Interoperabilität zwischen verschiedenen Hardware-Plattformen gewährleistet. Das
Abbildung 1: Modellierung einer FFT-Aktion, die die fundamentale ausführbare Einheit in DMOSES beschreibt Aktionskonzept lässt die Funktionalität der Aktion getrennt testen und verifizieren. Die Verifizierung der Aktion wird durch die Verifizierung des Codes innerhalb der Calculate-Methode mittels Qualitätsmetriken erreicht. Zur Sicherstellung eines deterministischen Systemsverhaltens sollten innerhalb der Aktion parallele Verarbeitungen vermieden werden. 3.2 Nicht-deterministische Modelle innerhalb der UML Nicht-deterministisches Verhalten kann insbesondere durch die parallele Bearbeitung von Teilaufgaben auftreten, wenn ihre Ausführung bzw. ihre Wechselwirkungen nicht vollständig definiert sind. Die Abbildung 2 zeigt ein Beispiel der Modellierung von parallelen Flüssen durch die Parallelisierungsknoten. Aus diesem Modell kann nicht hergeleitet werden, welche Aktion zuerst ausgeführt wird, wenn nur eine sequenziell arbeitende Hardware-Ressource zur Verfügung steht. Abbildung 2: UML-Modellierung von nebenläufigen Flüssen Die Ungewissheit der Reihenfolge tritt bei der Ausführung der Zustandsverhalten entry, do, exit innerhalb von orthogonale Regionen und nebenläufigen Zustandsautomaten auf. Die Abbildung 3 zeigt ein nicht-deterministisches Modell eines Zustandsautomaten. Nicht-deterministische Modelle sind Modelle, in denen die Ausführungsreihenfolge nicht festgelegt ist. Zur Codegenerierung ist diese Information über die Ausführung notwendig. Das Verhalten von nichtdeterministischen Systemen kann zu nicht exakt vorhersagbaren Systemzuständen führen, das heißt, solche Systeme können bei gleichen Eingabedaten zu unterschiedlichen Ergebnissen führen oder ein Ergebnis wird zu unterschiedlichen Zeitpunkten produziert. Ein solches Verhaltens kann zu einem instabilen System führen. Für sicherheitskritische Aufgaben ist ein deterministisches Systemverhalten unabdingbar. Abbildung 3: UML-Modellierung von orthogonalen Regionen 3.3 DMOSES-Profil Die UML-Modelle werden durch das DMOSES-Profil zur Sicherstellung eines deterministischen Verhaltens erweitert. Dadurch kann das Verhalten des Modells eindeutig vorhersagt werden.das Profil ist in zwei Sub-Profile unterteilt: Deterministic Behavior und Hardware-Management. Das Paket Deterministic Behavior hat die Aufgabe, den Determinismus des Modellverhaltens sicherzustellen. Dieses Paket stellt den async-stereotyp sowohl im Aktivitäts- als auch im Zustandsdiagramm zur Verfügung. Dieser Stereotyp trennt die Modellierung der Funktionalität von der Ausführung. Dank dieser Unterscheidung kann das gleiche Modell für eine unterschiedliche Ressourcenanzahl angewendet werden. Das Systemverhalten wird beibehalten, aber seine Ausführung wird anhand der Ressourcen unter Berücksichtigung der Stereotypen angepasst. Bei parallelen Datenflüssen ohne den Stereotyp async werden die Flüsse sequenziell ausgeführt. Durch diesen Stereotyp kann der Entwickler festlegen, ob zwei nebenläufige Flüsse gleichzeitig ausgeführt werden sollen (Abbildung 4). Beispielsweise kann die Thread- Erzeugung in einem Multitasking-System durch den async-stereotyp auf den Kanten definiert werden. Trotzdem kann diese Stereotype eine gleichzeitige Ausführung nicht erzwingen, wenn nicht genügend Ressourcen dafür zur Verfügung stehen. Abbildung 4: DMOSES-Modellierung von gleichzeitig ausführbaren parallelen Flüssen Das Paket Deterministic Behavior ermöglicht die Festlegung der Ausführungsreihenfolge im Modell durch die Priorisierung der Kanten beziehungsweise der Regionen. Durch die Priorisierung von orthogonalen Regionen wird die Ausführungsreihenfolge der
Zustandsverhalten im Modell festgelegt. Bei async- Datenflüssen wird die Priorität der Flüsse von der Kantenpriorität abgeleitet. Die Priorität der Flüsse bestimmt die Ausführungspriorität der Aktionen, die zu dem Fluss gehören. Durch die Priorität der Flüsse können die Ressourcen verwaltet werden. Bei nebenläufigen Implementierungen basiert der Schedule auf den Kantenprioritäten. Abbildung 7: Verteilung der Hardware-Ressourcen im Aktivitätsdiagramm diagramme Eigenschaften hinzu, so dass die Elemente in den Verhaltensdiagrammen mit ihrer ausführenden Ressource in Bezug gesetzt werden (Abbildung 7). Die Informationen über die Hardware helfen bei den Analysen von Synchronisierung und Parallelität im Modell. Abbildung 6: Priorisierung von parallelen Flüssen Die Prioritätswerte werden nur innerhalb der Aktivität oder des orthogonalen zusammengesetzten Zustands gültig. Auf diese Weise wird die Modularität der Elemente nicht gefährdet. Häufig bestehen eingebettete Systeme aus mehreren Ressourcen wie zum Beispiel Mikrocontrollern, FPGAs, DSPs oder Multicore-Prozessoren. Deshalb ist die Beschreibung der Hardware-Einheiten im Modell wichtig. Aus diesem Grund unterstützt das Paket Hardware-Management die Festlegung der Beziehung zwischen Hardware-Struktur und den Modellkomponenten. Dieses Paket erweitert das Verteilungsdiagramm zur Modellierung der Verarbeitungseinheiten. Unser Ansatz verwendet dieses Diagramm, um Ressourcen zu instanziieren und ihre Eigenschaften zu beschreiben. Die in dem Verteilungsdiagramm definierten Eigenschaften der Zielplattform wird bei der Codegenerierung verwendet, um den entsprechenden Code zu erzeugen. Die Stereotypen des Pakets Hardware-Management fügen den Elementen der Aktivitäts- und Zustands- 4 DMOSES-Toolchain Die Entwicklung der signalverarbeitenden eingebetteten Systeme wird von der DMOSES-Toolchain von der Modellierung bis zur Realisierung eines Systems unterstützt. Auf diese Weise kann das deterministische Systemverhalten, das auf der Modellebene durch das DMOSES-Profil sichergestellt wurde, bis zur Implementierungsebene beibehalten werden. Die Toolchain besteht aus einem Modellierungstool, einem Codegenerator und einer Entwicklungsumgebung (Abbildung 5). Alle diese Tools sind in Eclipse durch Plug-ins integrierbar. In unserem Ansatz wird das Modellierungstool MagicDraw [14] angewendet. MagicDraw kann mit dem Codegenerator durch das XMI-Austauschformat kommunizieren. Das Softwarepaket openarchitectware (oaw) [11] wird als Codegenerator eingesetzt. Die Codegenerierung basiert auf einem Metamodell und Templates. Die Phasen des Codegenerierungsprozess sind in der Abbildung 5 gezeigt. In der M2M- Transformation wird ein aus einer XMI-Datei gelesenes UML-Modell in ein DMOSES-Modell umgewan- Abbildung 5: DMOSES-Toolchain
delt. In der nächsten Phase werden die DMOSES- Modelle verifiziert. Fehler in der Modellierung werden identifiziert und die Datenintegrität sowie das Verhalten des Modells werden überprüft, um nichtdeterministische Ergebnisse zu vermeiden. Die M2T- Transformation wandelt das verifizierte DMOSES- Modell in Quellcode um. Für jede Type von Zielsprache und -plattform existieren Code-Frameworks, für die entsprechende Templates entworfen werden müssen. Diese Frameworks haben zwei Voraussetzungen. Zunächst müssen sie die Ableitung des deterministisches Verhalten, das im Modell beschrieben ist, gewährleisten. Weiterhin muss der Code leicht verständlich bleiben, um eine Weiterentwicklung zu vereinfachen. 5 Einsatz von DMOSES für die Entwicklung sicherheitsrelevanter eingebetteter Systeme Anwendungen von eingebetteten Systemen, in denen die funktionale Sicherheit ein relevanter Aspekt ist, müssen besondere Anforderungen erfüllen. Zu diesen Anforderungen gehören: Zuverlässigkeit, Verfügbarkeit, Systemintegrität, Datenintegrität, Wartbarkeit, Systemwiederherstellbarkeit und fehlersicherer Betrieb. Einige von diesen Anforderungen können durch die Unterstützung der DMOSES- Methode direkt erfüllt werden. In dieser Sektion erklären wir, welche Eigenschaften der hier vorgestellten Methode bei der Entwicklung von sicheren eingebetteten Systemen vorteilhaft sein können. Die DMOSES-Methode verfolgt als Hauptziel die Gewährleistung eines deterministischen Systemverhaltens. Die Stabilität des Systems ist eine wichtige Voraussetzung bei sicherheitskritischen Anwendungen. Die Zerlegung von funktionalen Einheiten in Aktionen oder Zustände macht den Entwicklungsprozess leichter verständlich und überschaubarer. Das Konzept der Aktion als fundamentale Einheit von ausführbarer Funktionalität ermöglicht es, eine intrinsische Modularität im System direkt abzubilden. Diese geschlossenen Elemente kommunizieren mit anderen Elementen durch die Pins als Schnittstelle. Eine Änderung, Verbesserung oder ein Austauschen der Aktion kann mühelos realisiert werden, ohne das ganze System zu beeinflussen. Durch die in UML definierten Vor- und Nachbedingungen von Aktionen und Aktivitäten wird eventuelles Fehlerverhalten der Komponente vermieden. Durch die Pins kann auch die Aktion vor falschen Eingangswerten geschützt werden, zu Beispiel durch Grenzwerte. Die Implementierung der Aktion findet auf der Codeebene statt. Bei der Programmierung der Aktion kann sich der Entwickler auf nur ein Element konzentrieren. Außerdem kann der Entwickler eine Implementierung wählen, die den spezifischen Anforderungen am besten gerecht wird. Auf der Codeebene können unterschiedliche Qualitätseigenschaften des Software, z.b. Ausfallrate oder Ausführungsdauer ermittelt werden, die dann bei der Modellierung zur Verfügung stehen. Auf dieser Weise kann die Qualität der Aktion auf der Modellebene beschrieben werden. Entwicklung Laufzeit Spezifizierung Verifizierung Codegenerierung UML-Modell <<DMOSES>> C++ / VHDL DMOSES-Framework Hardware1 M2M - Transformation M2T - Transformation z.b. MCU Hardware2 z.b. FPGA Abbildung 8: Architektur des DMOSES- Entwicklungsprozesses Die Architektur des Entwicklungsprozesses von DMOSES wird in der Abbildung 8 dargestellt. Die Entwicklungsphase besteht aus der Spezifizierung, Verifizierung und Codegenerierung. Die Verifizierung des Modells findet während der M2M-Transformation statt. In diesem Schritt werden die Datenintegrität sowie die Korrektheit der Verbindung der Elemente verifiziert.in der Codegenerierungsphase findet nicht nur die Realisierung des Modells statt, sondern auch die automatische Generierung von Tests für jedes Abstraktionsniveau (z.b. Aktionen und Aktivitäten). Auf dieser Weise lässt sich jedes Element getrennt und auch im Zusammenspiel mit den anderen automatisch testen. Ein DMOSES-Modell besteht aus verifizierten und getesteten Modellelementen (Abbildung 9). Darüber hinaus lassen sich die Eigenschaften des Systems aus den Eigenschaften der kleinsten Elemente ableiten. Beispielsweise kann die Ausfallhäufigkeit des gesamten Systems anhand der Ausfallrate der Aktionen abgeschätzt werden. Auf diese Weise können die zeitlichen Parameter eines Systems beschrieben werden, die auf der Grundlage der Ausführungsdauer jeder Aktion ermittelt werden können. Durch die Darstellung solcher Informationen im Modell wird es dem Entwickler erleichtert, das System durch die Identifizierung von kritischen Stellen zu analysieren und zu optimieren. 6 Diskussion und Ausblick Aufgrund des Mangels an Ansätzen, die deterministische Modelle sicherstellen, führen wir unser UML- Profil DMOSES ein, das den Determinismus auf der Modellebene von signalverarbeitenden eingebetteten Systemen gewährleistet. Dieses Profil wird von einer in Eclipse integrierten Toolchain unterstützt, die deterministisches Systemverhalten auf der Implementierungsebene sicherstellt. Durch die DMOSES- Methode können Systeme sowohl auf der Modellals auch auf der Codeebene verifiziert werden, was die Entwicklung von sicherheitskritischen Systemen
Spezifizierung Test Verifizierung Abbildung 9: Gewährleistung deterministischen Verhaltens aus verifizierten Modellelementen übersichtlicher und sicherer macht. Unsere zukünftige Arbeit ist die Implementierung von unterschiedlichen Softwaremetriken zur Abschätzung des Ausfallswahrscheinlichkeit einer Aktion. Ein weiteres Arbeitspaket beschäftigt sich mit der Einbeziehung von temporale Parameter aus Simulatoren (CPU, SystemC) in das DMOSES-Modelle. Literatur [1] Modellgestützte Entwurfs- und Realisierungsmuster für signalverarbeitende, eingebettete Systeme (MERSES). Webseite: www.dmoses.org. [2] Object Management Group: UML Unified Modeling Language, Superstructure, V2.1.2 [3] Apvrille, L., Saqui-Sannes, P., Khendek F. : TURTLE-P: A UML Profile for the Formal Validation of Critical and Distributed Systems. In: Software and Systems Modeling (SoSyM), pp.449 466. Springer (2006) [4] Object Management Group: Systems Modeling Language(SysML) V1.0 Specification (2007) [5] Object Management Group: UML Profile for MARTE (2007) [6] Gherbi, A., Khendek, F.: From UML/SPT models to schedulability analysis: a metamodelbased transformation. In: Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing, pp. 343 350. IEEE Computer Society (2006) [7] Mellor, S., Balcer, M.: Executable UML: A Foundation for Model-Driven Architectures. Addison- Wesley Longman Publishing Co., Inc.(2002) [8] Huber, B., Obermaisser, R.: FPlatform Modeling In Safety-Critical Embedded Systems. Lecture Notes in Electrical Engineering, Vol. 38 (2009) [9] Regensburger, M., Buckl, C., Knoll, A., Schrott, G.: Model Based Development of Safety-Critical Systems Using Template Based Code Generation. In: Proceedings of the Ninth IEEE International Symposium on Object and Component- Oriented Real-Time Distributed Computing, pp. 89 92. IEEE Computer Society (2007) [10] Buckl, C., Regensburger, M., Knoll, A., Schrott, G.: Models for automatic generation of safetycritical real-time systems. In: Second International Conference on Availability, Reliability and Security ARES 2007, pp. 580 587 (2007) [11] openarchitectureware. Webseite: www.openarchitectureware.org [12] Yi, J., Woo, H., Browne, J., Mok, A., Xie, F., Atkins, E., Lee, C.: From UML/SPT models to schedulability analysis: a metamodelbased transformation. In: Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing, pp. 343 350. IEEE Computer Society (2006) [13] Xie, F., Song, X., Chung, H., Nandi, R.: Translation-based co-verification. In: hird ACM and IEEE International Conference on Formal Methods and Models for Co-Design MEMOCO- DE 05, pp. 111 120 (2005) [14] MagicDraw. Webseite: www.magicdraw.com