Methode zur Entwicklung sicherheitskritischer eingebetteter Systeme

mittels deterministischer UML-Modelle ∗

Zamira Daw, Flor Alvarez, Marcus VetterInstitut fur Embedded Systems

Hochschule MannheimD-68163 Mannheim, Deutschland

Email: {z.daw, f.alvarez, m.vetter}@hs-mannheim.de

Zusammenfassung

Parallele Verarbeitungen erhohen die Komplexitat beider Entwicklung von signalverarbeitenden eingebet-teten Systemen. Die Synchronisierung der Ressour-cen und die Gewahrleistung von deterministischemVerhalten werden haufig nicht betrachtet. Infolge-dessen erfordern die Suche und die Behebung vonFehlern mehr Zeit. Diese Arbeit stellt eine Metho-de zur Entwicklung von signalverarbeitenden ein-gebetteten Systemen vor. Durch das in dieser Ar-beit vorgestellte DMOSES-Profil werden deterministi-sche Modelle in UML unabhangig von der Hardware-Plattform gewahrleistet. Bei der Entwicklung vonsicherheitskritischen Systemen wird die DMOSES-Methode zur Sicherstellung eines deterministischesAusfuhrungsverhalten genutzt.Schlusselworten : UML, Aktivitat, determinitischesVerhalten, eingebette Systeme.

1 Einfuhrung

Die Entwicklung von eingebetteten Systemen wirdstets komplexer und anspruchsvoller. Die wenighandhabbare Komplexitat in der Entwicklungsphaseerhoht den Aufwand bei sicherheitsrelevanten Anwen-dungen. Durch den Einsatz von modellbasierten Me-thoden ist die Entwicklung von eingebetteten Syste-men ubersichtlicher und infolgedessen weniger fehler-behaftet. Die Unified Modeling Language (UML) [2]hat sich zur Modellierung und Entwicklung von einge-betteten Systemen bedeutend verbreitet. Durch Pro-file ermoglicht UML die Spezialisierung der Modellie-rungssprache auf konkrete Domanen. Eine bedeuten-de Anzahl von UML-Profilen wird zur Modellierungvon Embedded-Systemen mit unterschiedlichen Ziel-setzungen entwickelt. Unter diesen befindet sich dasTURTLE-Profil [3]. Es erweitert die Klassen- und Ak-tivitatsdiagramme zur Modellierung von Echtzeitsys-temen. SysML (Systems Modeling Language) [4] ver-folgt insbesondere die Beschreibung von Systemanfor-derungen und ermoglicht die Analyse und Evaluierung

∗Diese Arbeit erfolgt im Rahmen des MERSES-Projekts[1] mit Unterstutzung der EU und des Landes Baden-Wurttemberg.

des Systems. MARTE: A UML Profile for Modelingand Analysis of Real-Time and Embedded Systems [5]richtet sich auf die Analyse von Scheduling und Per-formance. Außerdem ist MARTE der Nachfolger vomUML Profile for Schedulability, Performance and Ti-me (UML/SPT) [6] , das von der OMG (Object Mana-gement Group) 2002 angenommen wurde. eXecutableUML (xUML)[7] ist ein UML-Profil, das die Erstel-lung direkt ausfuhrbarer Modelle ermoglicht.

Diverse CASE-Tools bieten die Moglichkeit, ausden UML-Modellen automatisch Code zu generieren.Manche Entwicklungsfehler werden durch die automa-tische Codeerzeugung vermieden. Trotzdem ist dieseEigenschaft der CASE-Tools stark eingeschrankt, dahaufig nur aus den Klassen- und ZustandsdiagrammenCode generiert werden kann und dies nur in spezifi-schen Programmierungssprachen wie C++ oder Java.Ein anderes bestehendes Problem bei der Codegene-rierung ist die nicht ausreichende Information inner-halb des Modells. UML-Profile wie MARTE, SysMLund xUML erweitern die UML-Semantik, um diesenInformationsmangel zu beheben.

Diese Arbeit stellt eine Methode zur Entwick-lung sicherheitsrelevanter Systeme vor. Sie basiertauf einem Ansatz zur Modellierung und Implemen-tierung von deterministischen signalverarbeitendeneingebetteten Systemen (DMOSES). Die DMOSES-Entwicklungsmethode stellt ein deterministisches Ver-halten von der Modell- bis zur Codeebene sicher. Siebenutzt das DMOSES-Profil, das eindeutige imple-mentierbare UML-Modelle gewahrleistet. Aus diesenModellen wird mit einem in Eclipse integrierten ToolCode generiert. Unser Ansatz deutet eine Vorgehens-weise zur Verifizierung und Zuverlassigkeitsmessungeines sicherheitstechnischen Systems an.

2 Stand der Technik

2.1 UML-ProfileDie UML-Semantik kann durch die in einem Pro-fil definierten Stereotypen und Tagged Values erwei-tert bzw. auf einen ausgewahlten Bereich spezialisiertwerden. MARTE [5] ist ein UML-Profil zur Model-lierung von echtzeitbasierte eingebetteten Systemen.

Dieses Profil fugt UML-Modellen Konzepte fur Zeitund Ressourcen hinzu. Mit MARTE konnen multi-ple Zeittypen modelliert werden, was im SPT-Profilnicht moglich war. Außerdem lassen sich in verschie-denen UML-Diagrammen die Hardware-Plattformenmit verschiedenem Detailgrad beschreiben. Das Pro-fil legt mehrere Stereotypen fur die Modellierung vonScheduling fest, um die Analyse des Schedules undder Leistung des Systems zu ermoglichen. Der indieser Arbeit vorgestellte Ansatz unterscheidet sichvon MARTE darin, dass die Zeit eine zentrale Rol-le in MARTE spielt. Stattdessen konzentriert sichDMOSES darauf, ein deterministisches Systemverhal-ten zu gewahrleisten. Daruber hinaus ermoglicht dasDMOSES-Profil nicht die Modellierung von Schedule,die in DMOSES inharent definiert sind und auf stati-schen Prioritaten basieren.

SysML [4] ist ein Modellierungsstandard der OMGfur Systems Engineering. SysML basiert auf einer Un-termenge von UML 2.0 [2]. Die aus UML stammendenDiagramme werden durch Stereotypen und TaggedValues erweitert. Außerdem bietet SysML neue Dia-grammean, durch die die Modellierung von komple-xen Systemen erleichtert wird. Ein Schwerpunkt vonSysML ist die Analyse von Systemen. Durch das An-forderungsdiagramm konnen die Systemanforderun-gen miteinander bzw. mit anderen Modellelementenverbunden werden.

Sowohl MARTE als auch SysML verfolgen ande-re Zielsetzungen als das DMOSES-Profil. Die Ziel-domane von DMOSES sind die signalverarbeitendeneingebetteten Systeme, in denen die Modellierung vonDatenflussen eine wichtige Rolle spielt. Aus diesemGrund basiert unser Ansatz zur Modellierung des Sys-temverhaltens auf den UML-Diagrammen fur Akti-vitaten und Zustandsautomaten. Die Zielsetzung desDMOSES-Profiles ist das Hinzufugen hinreichenderInformationen zu den Modelle, um ein deterministi-sches Systemverhalten sicherzustellen.

2.2 Modellunterstutzte Entwicklung vonsicherheitsrelevanten eingebettetenSystemen

Aufgrund der zunehmenden Komplexitat der Ent-wicklung von sicheren eingebetteten Systemen wirdihr Entwicklungsprozess mit der Modellierung un-terstutzt. Die vorgestellte Methode in [8] unterstutztdie Modellierung von Hardwareplattformen. Diese Ar-chitektur erhoht die Verlasslichkeit des Systems. [9]und [10] verwenden die automatische Codegenerie-rung aus UML-Modellen fur die Entwicklung voneingebetteten Systemen. Unter Verwendung des Co-degenerators openArchitectureWare [11], der auchin dieser Arbeit eingesetzt wird. [9] beschreibt einetemplate-basierte Methode, um Codegenerierung furverschiedene Plattformen zu ermoglichen. [10] erwei-tert UML-Modelle zur Erganzung um Informationen,die fur die automatische Codegenerierung von sicher-

heitskritischen Systemen relevant sind. Das xUML[7] Profil wird [12] zur Modellierung von eingebet-teten Systemen benutzt. In dieser Arbeit wird ei-ne Methode zur Verifizierung von xUML mittels desCOSPAN-Checkers vorgestellt. Die in [13] beschriebe-ne Methode fuhrt eine Co-Verifizierung ein, die inner-halb der Transformation der xUML-Modelle stattfin-det. Die Verifizierung von DMOSES-Modellen findetauch innerhalb der Codegenerierung in der Modell-zu-Modell-Transformation statt(Sektion 4).

3 DMOSES Deterministische MOdel-le fur Signalverarbeitende Eingebet-tete Systeme

Die Entwicklung von deterministischen Systemenwird aufgrund zunehmender Parallelverarbeitung im-mer komplexer. Aus diesem Grund haben wir dieDMOSES-Methode zur Sicherstellung von determinis-tischen Modellen fur die Entwicklung von signalverar-beitenden eingebetteten Systemen entwickelt. Nicht-deterministisches Verhalten wird somit bei der Imple-mentierung unabhangig von der Hardware-Plattformausgeschlossen. In unserem Ansatz werden die Ak-tivitats- und Zustandsdiagramme zur Verhaltensbe-schreibung eines Systems verwendet. Das Vertei-lungsdiagramm wird zur Modellierung der Hardware-Struktur genutzt. Datenflusse konnen innerhalb vonAktivitatsdiagrammen modelliert werden. Ereignisge-steuerte Systeme konnen mit dem Zustandsdiagrammbesser als mit den anderen UML-Diagrammen model-liert werden. Seit der UML 2.0 sind die Aktivitats-und Zustandsdiagramm vollstandig voneinander un-abhangig. Diese Trennung erreicht eine Orthogona-litat zwischen den beiden Modelltypen. Die kombi-nierte Anwendung beider Modelle ermoglicht damitein umfassenderes Systemmodell.

3.1 Die fundamentale ausfuhrbare Ein-heit in DMOSES

Eine Aktion ist die fundamentale Einheit vonausfuhrbarer Funktionalitat im Modell (Abbildung 1).In unserem Ansatz ist das Verhalten der Aktion un-abhangig sowohl vom Modell, das sie beinhaltet, alsauch von der Hardware-Einheit, auf der sie ausgefuhrtwird. Dies ermoglicht ein deterministisches Verhal-ten, das von der Hardware unabhangig ist. Die Akti-on kann einfache oder komplexe Funktionalitaten re-prasentieren, die auf der Codeebene innerhalb einerCalculate-Methode implementiert werden.

Die Pins bekommen eine wichtige Bedeutung alsSchnittstelle der geschlossenen ausfuhrbaren Ein-heit, da sie die Datenintegritat sicherstellen. DieAusfuhrung einer Aktion findet nur statt, wenn al-le Tokens [2] an ihren Eingangspins anliegen und dieVorbedingungen erfullt sind. Daruber hinaus sind diePins verantwortlich fur die Weitergabe der Daten. Aufdiese Weise wird die Interoperabilitat zwischen ver-schiedenen Hardware-Plattformen gewahrleistet. Das

Abbildung 1: Modellierung einer FFT-Aktion, die diefundamentale ausfuhrbare Einheit in DMOSES be-schreibt

Aktionskonzept lasst die Funktionalitat der Akti-on getrennt testen und verifizieren. Die Verifizie-rung der Aktion wird durch die Verifizierung des Co-des innerhalb der Calculate-Methode mittels Qua-litatsmetriken erreicht. Zur Sicherstellung eines deter-ministischen Systemsverhaltens sollten innerhalb derAktion parallele Verarbeitungen vermieden werden.

3.2 Nicht-deterministische Modelle in-nerhalb der UML

Nicht-deterministisches Verhalten kann insbesonderedurch die parallele Bearbeitung von Teilaufgaben auf-treten, wenn ihre Ausfuhrung bzw. ihre Wechselwir-kungen nicht vollstandig definiert sind. Die Abbildung2 zeigt ein Beispiel der Modellierung von parallelenFlussen durch die Parallelisierungsknoten. Aus diesemModell kann nicht hergeleitet werden, welche Aktionzuerst ausgefuhrt wird, wenn nur eine sequenziell ar-beitende Hardware-Ressource zur Verfugung steht.

Abbildung 2: UML-Modellierung von nebenlaufigenFlussen

Die Ungewissheit der Reihenfolge tritt bei derAusfuhrung der Zustandsverhalten entry, do, exit in-nerhalb von orthogonale Regionen und nebenlaufigenZustandsautomaten auf. Die Abbildung 3 zeigt einnicht-deterministisches Modell eines Zustandsauto-maten.

Nicht-deterministische Modelle sind Modelle, in de-nen die Ausfuhrungsreihenfolge nicht festgelegt ist.Zur Codegenerierung ist diese Information uber dieAusfuhrung notwendig. Das Verhalten von nicht-deterministischen Systemen kann zu nicht exakt vor-hersagbaren Systemzustanden fuhren, das heißt, sol-che Systeme konnen bei gleichen Eingabedaten zu un-terschiedlichen Ergebnissen fuhren oder ein Ergebniswird zu unterschiedlichen Zeitpunkten produziert. Einsolches Verhaltens kann zu einem instabilen Systemfuhren. Fur sicherheitskritische Aufgaben ist ein de-terministisches Systemverhalten unabdingbar.

Abbildung 3: UML-Modellierung von orthogonalenRegionen

3.3 DMOSES-ProfilDie UML-Modelle werden durch das DMOSES-Profilzur Sicherstellung eines deterministischen Verhaltenserweitert. Dadurch kann das Verhalten des Modellseindeutig vorhersagt werden.Das Profil ist in zweiSub-Profile unterteilt: Deterministic Behavior undHardware-Management.

Das Paket Deterministic Behavior hat die Aufga-be, den Determinismus des Modellverhaltens sicher-zustellen. Dieses Paket stellt den async-Stereotyp so-wohl im Aktivitats- als auch im Zustandsdiagrammzur Verfugung. Dieser Stereotyp trennt die Modellie-rung der Funktionalitat von der Ausfuhrung. Dankdieser Unterscheidung kann das gleiche Modell fur eineunterschiedliche Ressourcenanzahl angewendet wer-den. Das Systemverhalten wird beibehalten, aber sei-ne Ausfuhrung wird anhand der Ressourcen unterBerucksichtigung der Stereotypen angepasst. Bei par-allelen Datenflussen ohne den Stereotyp async wer-den die Flusse sequenziell ausgefuhrt. Durch diesenStereotyp kann der Entwickler festlegen, ob zwei ne-benlaufige Flusse gleichzeitig ausgefuhrt werden sol-len (Abbildung 4). Beispielsweise kann die Thread-Erzeugung in einem Multitasking-System durch denasync-Stereotyp auf den Kanten definiert werden.Trotzdem kann diese Stereotype eine gleichzeitigeAusfuhrung nicht erzwingen, wenn nicht genugendRessourcen dafur zur Verfugung stehen.

Abbildung 4: DMOSES-Modellierung von gleichzeitigausfuhrbaren parallelen Flussen

Das Paket Deterministic Behavior ermoglicht dieFestlegung der Ausfuhrungsreihenfolge im Modelldurch die Priorisierung der Kanten beziehungsweiseder Regionen. Durch die Priorisierung von orthogo-nalen Regionen wird die Ausfuhrungsreihenfolge der

Zustandsverhalten im Modell festgelegt. Bei async-Datenflussen wird die Prioritat der Flusse von derKantenprioritat abgeleitet . Die Prioritat der Flussebestimmt die Ausfuhrungsprioritat der Aktionen, diezu dem Fluss gehoren. Durch die Prioritat der Flussekonnen die Ressourcen verwaltet werden. Bei ne-benlaufigen Implementierungen basiert der Scheduleauf den Kantenprioritaten.

Abbildung 6: Priorisierung von parallelen Flussen

Die Prioritatswerte werden nur innerhalb der Ak-tivitat oder des orthogonalen zusammengesetzten Zu-stands gultig. Auf diese Weise wird die Modularitatder Elemente nicht gefahrdet.

Haufig bestehen eingebettete Systeme aus mehre-ren Ressourcen wie zum Beispiel Mikrocontrollern,FPGAs, DSPs oder Multicore-Prozessoren. Deshalbist die Beschreibung der Hardware-Einheiten im Mo-dell wichtig. Aus diesem Grund unterstutzt das Pa-ket Hardware-Management die Festlegung der Bezie-hung zwischen Hardware-Struktur und den Modell-komponenten. Dieses Paket erweitert das Verteilungs-diagramm zur Modellierung der Verarbeitungseinhei-ten. Unser Ansatz verwendet dieses Diagramm, umRessourcen zu instanziieren und ihre Eigenschaftenzu beschreiben. Die in dem Verteilungsdiagramm de-finierten Eigenschaften der Zielplattform wird bei derCodegenerierung verwendet, um den entsprechendenCode zu erzeugen.

Die Stereotypen des Pakets Hardware-Managementfugen den Elementen der Aktivitats- und Zustands-

Abbildung 7: Verteilung der Hardware-Ressourcen imAktivitatsdiagramm

diagramme Eigenschaften hinzu, so dass die Elementein den Verhaltensdiagrammen mit ihrer ausfuhrendenRessource in Bezug gesetzt werden (Abbildung 7). DieInformationen uber die Hardware helfen bei den Ana-lysen von Synchronisierung und Parallelitat im Mo-dell.

4 DMOSES-Toolchain

Die Entwicklung der signalverarbeitenden eingebette-ten Systeme wird von der DMOSES-Toolchain von derModellierung bis zur Realisierung eines Systems un-terstutzt. Auf diese Weise kann das deterministischeSystemverhalten, das auf der Modellebene durch dasDMOSES-Profil sichergestellt wurde, bis zur Imple-mentierungsebene beibehalten werden. Die Toolchainbesteht aus einem Modellierungstool, einem Codege-nerator und einer Entwicklungsumgebung (Abbildung5). Alle diese Tools sind in Eclipse durch Plug-ins in-tegrierbar.

In unserem Ansatz wird das ModellierungstoolMagicDraw [14] angewendet. MagicDraw kann mitdem Codegenerator durch das XMI-Austauschformatkommunizieren. Das Softwarepaket openArchitectWa-re (oAW) [11] wird als Codegenerator eingesetzt.Die Codegenerierung basiert auf einem Metamodellund Templates. Die Phasen des Codegenerierungspro-zess sind in der Abbildung 5 gezeigt. In der M2M-Transformation wird ein aus einer XMI-Datei gelese-nes UML-Modell in ein DMOSES-Modell umgewan-

Abbildung 5: DMOSES-Toolchain

delt. In der nachsten Phase werden die DMOSES-Modelle verifiziert. Fehler in der Modellierung wer-den identifiziert und die Datenintegritat sowie dasVerhalten des Modells werden uberpruft, um nicht-deterministische Ergebnisse zu vermeiden. Die M2T-Transformation wandelt das verifizierte DMOSES-Modell in Quellcode um. Fur jede Type von Ziel-sprache und -plattform existieren Code-Frameworks,fur die entsprechende Templates entworfen werdenmussen. Diese Frameworks haben zwei Voraussetzun-gen. Zunachst mussen sie die Ableitung des deter-ministisches Verhalten, das im Modell beschriebenist, gewahrleisten. Weiterhin muss der Code leichtverstandlich bleiben, um eine Weiterentwicklung zuvereinfachen.

5 Einsatz von DMOSES fur die Ent-wicklung sicherheitsrelevanter ein-gebetteter Systeme

Anwendungen von eingebetteten Systemen, in denendie funktionale Sicherheit ein relevanter Aspektist, mussen besondere Anforderungen erfullen. Zudiesen Anforderungen gehoren: Zuverlassigkeit,Verfugbarkeit, Systemintegritat, Datenintegritat,Wartbarkeit, Systemwiederherstellbarkeit und fehler-sicherer Betrieb. Einige von diesen Anforderungenkonnen durch die Unterstutzung der DMOSES-Methode direkt erfullt werden. In dieser Sektionerklaren wir, welche Eigenschaften der hier vorge-stellten Methode bei der Entwicklung von sichereneingebetteten Systemen vorteilhaft sein konnen.

Die DMOSES-Methode verfolgt als Hauptziel dieGewahrleistung eines deterministischen Systemver-haltens. Die Stabilitat des Systems ist eine wichti-ge Voraussetzung bei sicherheitskritischen Anwendun-gen. Die Zerlegung von funktionalen Einheiten in Ak-tionen oder Zustande macht den Entwicklungspro-zess leichter verstandlich und uberschaubarer. DasKonzept der Aktion als fundamentale Einheit vonausfuhrbarer Funktionalitat ermoglicht es, eine int-rinsische Modularitat im System direkt abzubilden.Diese geschlossenen Elemente kommunizieren mit an-deren Elementen durch die Pins als Schnittstelle. Ei-ne Anderung, Verbesserung oder ein Austauschen derAktion kann muhelos realisiert werden, ohne das gan-ze System zu beeinflussen. Durch die in UML definier-ten Vor- und Nachbedingungen von Aktionen und Ak-tivitaten wird eventuelles Fehlerverhalten der Kom-ponente vermieden. Durch die Pins kann auch dieAktion vor falschen Eingangswerten geschutzt wer-den, zu Beispiel durch Grenzwerte. Die Implementie-rung der Aktion findet auf der Codeebene statt. Beider Programmierung der Aktion kann sich der Ent-wickler auf nur ein Element konzentrieren. Außerdemkann der Entwickler eine Implementierung wahlen,die den spezifischen Anforderungen am besten ge-recht wird. Auf der Codeebene konnen unterschied-liche Qualitatseigenschaften des Software, z.B. Aus-

fallrate oder Ausfuhrungsdauer ermittelt werden, diedann bei der Modellierung zur Verfugung stehen. Aufdieser Weise kann die Qualitat der Aktion auf der Mo-dellebene beschrieben werden.

C++ / VHDLUML-Modell<<DMOSES>>

DMOSES-Framework

z.B. MCUHardware1

z.B. FPGAHardware2

Spezifizierung

Verifizierung

CodegenerierungEntw

ickl

ung

Lauf

zeit

M2M - Transformation

M2T - Transformation

Abbildung 8: Architektur des DMOSES-Entwicklungsprozesses

Die Architektur des Entwicklungsprozesses vonDMOSES wird in der Abbildung 8 dargestellt. DieEntwicklungsphase besteht aus der Spezifizierung, Ve-rifizierung und Codegenerierung. Die Verifizierungdes Modells findet wahrend der M2M-Transformationstatt. In diesem Schritt werden die Datenintegritatsowie die Korrektheit der Verbindung der Elementeverifiziert.In der Codegenerierungsphase findet nichtnur die Realisierung des Modells statt, sondern auchdie automatische Generierung von Tests fur jedesAbstraktionsniveau (z.B. Aktionen und Aktivitaten).Auf dieser Weise lasst sich jedes Element getrennt undauch im Zusammenspiel mit den anderen automatischtesten.

Ein DMOSES-Modell besteht aus verifizierten undgetesteten Modellelementen (Abbildung 9). Daruberhinaus lassen sich die Eigenschaften des Systems ausden Eigenschaften der kleinsten Elemente ableiten.Beispielsweise kann die Ausfallhaufigkeit des gesam-ten Systems anhand der Ausfallrate der Aktionen ab-geschatzt werden. Auf diese Weise konnen die zeitli-chen Parameter eines Systems beschrieben werden, dieauf der Grundlage der Ausfuhrungsdauer jeder Aktionermittelt werden konnen. Durch die Darstellung sol-cher Informationen im Modell wird es dem Entwicklererleichtert, das System durch die Identifizierung vonkritischen Stellen zu analysieren und zu optimieren.

6 Diskussion und Ausblick

Aufgrund des Mangels an Ansatzen, die determinis-tische Modelle sicherstellen, fuhren wir unser UML-Profil DMOSES ein, das den Determinismus aufder Modellebene von signalverarbeitenden eingebet-teten Systemen gewahrleistet. Dieses Profil wird voneiner in Eclipse integrierten Toolchain unterstutzt,die deterministisches Systemverhalten auf der Imple-mentierungsebene sicherstellt. Durch die DMOSES-Methode konnen Systeme sowohl auf der Modell-als auch auf der Codeebene verifiziert werden, wasdie Entwicklung von sicherheitskritischen Systemen

● Spezifizierung● Test ● Verifizierung

Abbildung 9: Gewahrleistung deterministischen Verhaltens aus verifizierten Modellelementen

ubersichtlicher und sicherer macht. Unsere zukunftigeArbeit ist die Implementierung von unterschiedlichenSoftwaremetriken zur Abschatzung des Ausfallswahr-scheinlichkeit einer Aktion. Ein weiteres Arbeitspaketbeschaftigt sich mit der Einbeziehung von temporaleParameter aus Simulatoren (CPU, SystemC) in dasDMOSES-Modelle.

Literatur

[1] Modellgestutzte Entwurfs- und Realisierungs-muster fur signalverarbeitende, eingebettete Sys-teme (MERSES). Webseite: www.dmoses.org.

[2] Object Management Group: UML Unified Mode-ling Language, Superstructure, V2.1.2

[3] Apvrille, L., Saqui-Sannes, P., Khendek F. :TURTLE-P: A UML Profile for the Formal Va-lidation of Critical and Distributed Systems.In: Software and Systems Modeling (SoSyM),pp.449–466. Springer (2006)

[4] Object Management Group: Systems ModelingLanguage(SysML) V1.0 Specification (2007)

[5] Object Management Group: UML Profile forMARTE (2007)

[6] Gherbi, A., Khendek, F.: From UML/SPT mo-dels to schedulability analysis: a metamodel-based transformation. In: Proceedings of theNinth IEEE International Symposium on Objectand Component-Oriented Real-Time DistributedComputing, pp. 343–350. IEEE Computer Socie-ty (2006)

[7] Mellor, S., Balcer, M.: Executable UML: A Foun-dation for Model-Driven Architectures. Addison-Wesley Longman Publishing Co., Inc.(2002)

[8] Huber, B., Obermaisser, R.: FPlatform ModelingIn Safety-Critical Embedded Systems. LectureNotes in Electrical Engineering, Vol. 38 (2009)

[9] Regensburger, M., Buckl, C., Knoll, A., Schrott,G.: Model Based Development of Safety-CriticalSystems Using Template Based Code Generati-on. In: Proceedings of the Ninth IEEE Interna-tional 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 safety-critical real-time systems. In: Second Internatio-nal Conference on Availability, Reliability andSecurity 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 mo-dels to schedulability analysis: a metamodel-based transformation. In: Proceedings of theNinth IEEE International Symposium on Objectand Component-Oriented Real-Time DistributedComputing, pp. 343–350. IEEE Computer Socie-ty (2006)

[13] Xie, F., Song, X., Chung, H., Nandi, R.:Translation-based co-verification. In: hird ACMand IEEE International Conference on FormalMethods and Models for Co-Design MEMOCO-DE ’05, pp. 111–120 (2005)

[14] MagicDraw. Webseite: www.magicdraw.com