Folien als PDF

Methodischer Entwurf eingebetteter Systeme 

Modelle und Begriffe 

3. Spezifikationsmodelle 

• Petri-Netz 

• Problemgraph 

• Kontroll-Datenfluss Graph 

• Kommunizierende Sequentielle Prozesse 

• Endlicher Automat 

• UML Modelle 

S. A. Huss / Folie 3-1

Modell 



Modell : Vereinfachtes Abbild der Wirklichkeit 

• Beschreibung der Funktionalität 

• eindeutig und vollständig 

• leicht verständlich 

• Abstraktion von Details 

Zweck : Dient zur Optimierung, Validierung, Prognose, 

Entscheidungshilfe, ... 

Grundlage für eine Verifikation und Simulation einer 

Systemspezifikation 


Modellausführung 



Methode der Simulation 

Zweck : 

• Optimierung von Systemeigenschaften 

• Entscheidungshilfen (Testen von Alternativen) 

• Prognose 

• Validierung 

Gründe : 

• Mathematische Analyse nicht möglich 

• Reales System liegt nicht vor 

• Experiment zu teuer, zu schnell oder zu langsam 

• Realität erträgt Experiment nicht (Ökologie) 

Einsatzbereiche : 

• Industrielle Fertigung, Logistik, Planung, ... 

• Meteorologie 

• Volkswirtschaft 

• Architektur 


Klassifikation 



Modellklassen: 

• Kontrollfluss dominant (-> zustandsorientiert) 

• Datenfluss dominant (-> aktivitätsorientiert) 

• Struktur orientiert (Komponenten-Verbindungs-Diagramme) 

• Zeit orientiert 

• Daten orientiert 

• Heterogen 


Begriffe 



Im Zusammenhang mit der Spezifikation und dem Entwurf von 

verteilten HW/SW-Systemen sind folgende Begriffe wichtig: 

• Synchrone /Asynchrone Modelle 

• Determinismus 

• Zeit 

– metrische Zeit 

– kontinuierliche Zeit 

– diskrete Zeit 

• Parallelität, Pipelining 


M1. Petri-Netz 



Ein Petri-Netz ist ein 6-Tupel G(P,T,F,K,W,M 0 

) mit: 

• P : eine Menge von Plätzen 

• T : eine Menge von Transitionen 

• F : Flussrelation, Kanten 

• K : PfiN Kapazität der Stellen 

• W: FfiN Kantengewichte 

• M 0 

: Anfangsmarkierung 

t1 

t2 

Eine Transition t in einem Petri-Netz kann 

schalten, wenn an allen Eingangsstellen 

genügend Marken vorhanden und an den 

Ausgangsstellen genügend Plätze frei 

sind. 

Ereignisorientiertes Berechnungsmodell. 

Ressourcenkonflikt: 

Entweder kann t1 oder t2 

schalten, da der Platz in 

der Mitte nur eine Marke 

enthält. 


... Petri-Netz 



Beispiel: 

Zwei Ressourcen, die auf ein exklusives Medium (Bus) zugreifen. 


... Petri-Netz 



• Allgemeines, weit verbreitetes Model mit vielen unterschiedlichen 

Ausprägungen 

z.B. Markierte Graphen: 

• Jeder Platz hat nur einen Eingang und einen Ausgang. 

• Die Kapazität der Stellen ist immer 1. 

• Eine Vielzahl von Eigenschaften ist mathematisch belegbar, z. B. 

• Sicherheit 

(Zahl der Marken steigt nicht ins Unendliche) 

• Lebendigkeit 

(keine Verklemmungen) 

Benannt nach dem Mathematiker C. A. Petri 


M2. Problemgraph 



Definition: 

Ein Problemgraph G (V,E) ist ein gerichteter Graph mit Knotenmenge 

V und Kantenmenge E, in dem jeder Knoten v i ˛ V eine Aufgabe 

(Task, Prozess, Anweisung, Elementaroperation) und jede Kante 

e = (v i 

, v j 

) ˛ E eine Datenabhängigkeit / Kommunikationsverbindung 

darstellt. 

Ausprägungen auf unterschiedlichen Abstraktionsebenen: 

• Datenflussgraphen - einfache Operationen (Addition,Multiplikation, ...) 

• Task-Graphen - komplexere Aufgaben (Algorithmen) 


M3. Ressourcengraph 



Definition: 

Ein Ressourcengraph G R 

(V R 

, E R 

) ist ein bipartiter Graph. V R 

, seine 

Knotenmenge, enthält die Knotenmenge V des Problemgraphen G (V,E). 

Jeder Knoten r k ˛ V T 

stellt einen Ressourcentyp dar (z.B. Prozessor, ALU, 

Addierer, Multiplizierer, Speicher, Bus, etc.). Eine Kante (v i 

, r k 

) ˛ E R 

mit 

v i ˛ V und r k ˛ V T 

modelliert die Realisierbarkeit von v i 

auf einer Instanz 

des Ressourcentypen r k 

. 

Ferner gibt es eine 

• Kostenfunktion c, die jedem Ressourcentyp r k ˛ V T 

die Kosten c(r k 

) 

zuordnet, sowie eine 

• Gewichtsfunktion w, die jeder Kante (v i 

, r k 

) ˛ E R 

die Berechnungszeit 

w(v i 

, r k 

) (abgekürzt w i,k 

) zuordnet, die die Berechnungszeit von v i 

auf r k 

repräsentiert. 


...Ressourcengraph 



Beispiel: 

* 

* 

* 

2 c(r1)=1 

2 

2 

r1 

2 

2 2 

* 

* 

* 

- 

+ 

< 

1 

1 

3 

c(r2)=2 

r2 

1 

1 

- 

+ 


M4. Datenflussgraph (DFG) 



DFG 

OPS D 

D 

:= (OPS D 

, D): gerichteter Graph mit 

: Menge der Operationen aus Applikationsalgorithmus 

: Menge der Datenflusskanten 

• Geeignet für transformatorische Systeme 

• Die Knoten stellen Aktivitäten dar, die Kanten die 

Datenabhängigkeiten zwischen den Aktivitäten 

Beispiel: 

A := B + 1; 

B := A + 1; 

B 

+ 

1 

A 1 

+ 

B 


M5. Kontrollflussgraph (CFG) 



CFG=(OPS C 

B, C): gerichteter Graph mit 

OPS C 

B 

C 

:Menge der Kontrollflussknoten (bedingte Operationen) 

:Menge der Zuweisungsblöcke 

: Menge der Kontrollflusskanten 

Kontollflussgraphen stellen nicht die Datenabhängigkeiten, sondern 

den Kontrollfluss einer Berechnung dar. 

Die Verzweigungen sind Alternativen. 

Beispiel: 

case C is 

when 1 => X := X+2; 

A := X+5; 

when 2 => A := X+3; 

when others =>A := X+W; 

end case; 


M6. Kontroll-Datenfluss-Graph 

(CDFG) 



Ein Kontroll-Datenfluss-Graph 

kombiniert sowohl den 

Kontrollfluss als auch die Datenabhängigkeiten 

zu einem Modell. 

Beispiel: 

• Heterogenes Modell 

• Ein CDFG vereinigt 

die Vorteile von 

DFG und CFG. 


M7. Kommunizierende 

sequentielle Prozesse (CSP) 



• CSP ist ein Modell, um parallele Systeme formal zu beschreiben 

• Beschränkung auf die wesentlichen Strukturmerkmale 

• 1985 von Hoare streng mathematisch definiert 

• Grundlage z.B. für die (nicht mehr aktuelle) Programmiersprache OCCAM 

Modellierung einer Systemkomponente mittels 

♦ Menge von nebenläufig aktiven Prozessen 

♦ Asynchrone Interprozess-Kommunikation 

Beachte: 

Jeder Prozess ist strikt sequentiell, d.h. Aneinanderreihung von 

• Zuweisungen 

• Fallunterscheidungen 

• Iterationen 



... CSP 



• Alphabet eines Prozesses P ist die Menge der möglichen Ereignisse. 

Beispiel : Münzautomat aP={geld, ware} 

• Präfix-Operator xfiP x ˛aP: P wartet so lange, bis Ereignis x eintritt. 

Rekursive Beschreibung eines Münzautomaten: 

P = geld fi warefi P 

• Auswahl / Fallunterscheidung: (x fi P | y fi Q) 

z. B. Münzautomat mit Auswahl: 

P2 = geld fi (knopf1 fi ware1 fi P2 | knopf2 fi ware2 fi P2) 

• Nebenläufigkeit: (P||Q) bezeichnet den Prozess, der durch 

konkurrierenden Ablauf der Prozesse P und Q entsteht. 

• Kommunikation: Zwei Prozesse kommunizieren, indem beide Prozesse 

untereinander Nachrichten austauschen. 

r 

Q 

P 


M8. Finite-State Machine (FSM) 



Hinweis: Automaten werden gewöhnlich bei 

kontrollflussorientierte Problemen eingesetzt. 

Ein nichtdeterministischer Endlicher Mealy-Automat (FSM) 

ist ein 6-Tupel (I,O,X,R,f,g) mit: 

• I : Eingabealphabet 

• O: Ausgabealphabet 

• X: Endliche Menge von Zuständen 

• R˝ X : Menge der Anfangszustände 

• f ˝ (X x I x X) Übergangsrelation 

• g ˝ (X x I x O) Ausgaberelation 


... FSM 



Beispiel : 

Automat, der die Folge (00),(00),(11),(10) erkennt, und dann eine e 1 ausgibt. 

I={(00),(10),(01),(11)} 

O={1,0} 

X={A,B,C,D} 

R={A} 

g={(00,A,0),(01,A,0),(10,A,0),(11,A,0), 

(00,B,0),(01,B,0),(10,B,0),(11,B,0), 

(00,C,0),(01,C,0),(10,C,0),(11,C,0), 

(00,D,0),(01,D,0),(10,D,1),(11,D,0)} 

A B C D 


... FSM: Bewertung 



• Methoden zur Verifikation von Eigenschaften verfügbar 

(`model checking`) 

• Vielzahl von Entwurfswerkzeugen vorhanden 

• Algorithmen zur Hardwaresynthese verfügbar 

Besonderheiten: 

• Moore Automat - Ausgaberelation hängt nur vom aktuellen 

Zustand ab: g ˝ (X x O). 

• Bei deterministischen FSM sind f und g Funktionen. 

Jedoch: 

• Keine Repräsentation von Nebenläufigkeit und Hierarchie 


M8. Hierarchische FSMs 



Zustandsorientierte Modelle (FSM) werden für den Entwurf 

eingebetteter Systeme um Hierarchie und Nebenläufigkeit erweitert: 

Hierarchische, nebenläufige endliche Automaten (HCFSM). 

• Ein Zustand (Superzustand) kann mehrere Subzustände 

enthalten 

• Subzustände können entweder 'AND' oder 'OR' verknüpft sein 

Bekanntes Modell: StateCharts 

Zustandsbasierte Spezifikation, 



Beispiel : 

Anfangszustand 



Hierarchische 

Gliederung der 

Zustände 

´AND´ verknüpfte 

Zustände 


M9. Objekt-orientierte Modelle: 

UML 



UML ist eine grafisch notierte, objekt-orientierte 

orientierte Modellierungssprache: 

• Entwürfe werden als interagierende Objekte modelliert 

• Zumindest einige der Objekte werden letztendlich als Softwareoder 

Hardware-Module realisiert 

• UML wird i. d. R. auch zur Modellierung der Einsatzumgebung 

eingesetzt 

• Es gibt unterschiedliche Sichten der objekt-orientierten 

Modellierung: 

•Objekt-orientierte Spezifikationen ermöglichen eine Systembeschreibung, 

die reale Objekte und ihre Interaktion direkt 

widerspiegelt. 

•Objekt-orientierte Spezifikationen stellen eine Menge von 

Primitiven bereit, die zur Beschreibung des Systems im 

Hinblick auf bestimmte Attribute genutzt wird, ohne jedoch 

direkten Bezug zu realen Komponenten zu nehmen. 

UML: Unified Modeling Language 


UML: Strukturbeschreibung 



• Modelliert die Grundkomponenten eines Systems 

• Im oo-Entwurf sind die Komponenten Objekte 

• Ein Objekt enthält eine Menge von Attributen, die 

den Zustand definieren. 

• Eine Klasse ist eine Art Typdefinition 

• Eine Klasse definiert die Attribute, die ein Objekt haben kann 

• Operationen werden ebenfalls definiert 

Ein Objekt in UML Notation: 

Eine Klasse in UML Notation: 

Pixel is 

a 2D Array 

d1:Display 

Pixel is 

a 2D Array 

Display 

Class 

name 

pixels:array[ ] 

elements 

menu_items 

pixels 

elements 

menu_items 

Attributes 

Mouse_click() 

Draw_box() 

Operations 


UML: Relationen 



Es gibt verschiedene Relationen zwischen objekten und Klassen: 

• Association –zwischen Objekten, die miteinander 

kommunizieren, aber keine gegenseitige owner 

relationship aufweisen 

• Aggregation –beschreibt die Konstruktion eines 

komplexen Objekts aus kleineren/einfachen Objekten 

• Composition –eine Art Aggregation, bei der kein Zugang zu 

Komponentenobjekten erlaubt ist 

• Generalization –unterstützt die Definition einer Klasse unter 

Bezug auf eine andere Klasse 


UML: Abgeleitete Klassen 



• UML erlaubt die Definition einer 

Klasse mit Bezug auf eine andere 

• Eine derived class erbt alle 

Attribute und Operationen von der 

base class 

Display 

pixels 

elements 

menu_items 

Mouse_click() 

Draw_box() 

Base class 

Generalization 

BW display 

Color_map_display 

color_map 

Derived class 


UML: Assoziationen 



Ein Link beschreibt eine Relation zwischen Objekten/Klassen. 

Link zwischen Objekten 

Link zwischen Klassen 

m1:message 

msg=msg1 

length=2011 

m2:message 

s:message set 

count=2 

message 

msg: stream 

length:integer 

contains 

0..* 

1 

message set 

count: integer 

msg=msg2 

length=2413 


UML: Verhaltensbeschreibung 



• Es muss sowohl das Verhalten (behavior) als auch die Struktur 

des Systems beschrieben werden. 

• Eine Möglichkeit zur Beschreibung des Verhaltens einer Aufgabe 

bzw. Operation ist ein Zustandsautomat (state 

machine). 

• Ein signal ist eine asynchron auftretende Grösse 

• Ein call event entspricht einem Prozeduraufruf 

• Ein timeout event (timer 

event) bewirkt das Verlassen eines 

Zustands nach einer gewissen Zeit. 

 

Signal event 

Signal Event: 

mouse_click 

declaration 

(x,y) 

a 

mouse_click(x,y) 

b 

x,y:Position 

Call Event: 

c 

draw_box(10,5) 

d 

Timer Event: 

e 

tm(time-value) 

f 


State Machine Spezifikation 

in UML 

Start 

State 



mouse_click(x,y) 

find_region(region) 

call_menu(i) 

Region 

found 

Go menu 

item 

Call menu 

item 

region=menu/ 

which:menu(i) 

region=drawing/ 

find_object(id) 

Found 

object 

highlight(id) 

Object 

highlighted 

Stop 

State 


Sequenz-Diagram 



Strukturiertes Sequenz-Diagramm mit Timing Information 

Valve System 

Main Ctrl 

Valve Ctrl 

Valve 

Sensor 

StartValve() 

loop 

while 

Value = OK 

GetValue() {5ms} 

return(Value) {5ms} 

SetValve() {3ms} 

100ms 

Throw(ValveExep) 

CloseValve() {3ms} 

time 


UML: Einsatz in EbS 

Anwendungen 



Bewertung von UML: 

• Software orientiert 

(Zielsetzung: Beschreibung von SW-Architekturen) 

• keine eindeutige Semantik 

• nicht ausführbar 

• grosse Bandbreite der Beschreibungen, wenig Fokussierung 

(nicht direkt geeignet für kooperierende HW/SW-Architekturen in EbS) 

Anpassung auf Domänenanforderungen: 

• Definition von speziellen UML Profilen (Erweiterungen): 

-UML for SoC Profile 

-MARTE Profile for Real-Time and Embedded Systems 

-SysML Profile for Embedded System Modeling 

• Definition einer UML Untermenge –mit Schwerpunkt auf die 

Ausführbarkeit und auf Transformationen nach VHDL und C++ 

-xtUML (executable UML) 

Hinweis: Vorlesung EbS II 

im Sommersemester 


SysML 



SysML ist eine Erweiterung von UML 2 für System Design: 

• UML 2 beinhaltet bereits viele Konstrukte für Echtzeit (RT) 

System Design (z. B. zeitbehaftete Sequenz-Diagramme) 

• SysML führt zusätzliche Konstrukte ein zur Spezifikation 

nicht-funktionaler Anforderungen und von Systemkompositionen 

(insbesondere HW/SW Partitionierung) 


SysML Diagramme 




SysML: Neue Diagramme 



• Parametric Diagram: 

Repräsentiert eine Menge von Eigenschaften und 

parametrische Zusammenhänge zwischen ihnen (z. B. 

mittels mathematischer Formeln). Dadurch wird eine 

automatische Überprüfung von Wertänderungen unterstützt 

bzw. deren Einfluss auf andere Eigenschaften. 


SysML: Neue Diagramme 



• Requirement Diagram: 

Spezifiziert ‚Familien‘ von Anforderungen (ähnlich zu Klassen) 

und ihre Relationen mit Bezug zu den Systemkomponenten. 


Zukunft von SysML 



• Zur Zeit Arbeiten zwei Submission-Teams parallel 

mit dem Ziel der Annahme durch die Open 

Modeling Group (OMG) 

– Version 0.98 

– Version 1.0b 

• SysML ist momentan im Fluss. Gewissen 

Konzepte und bezeichnungen können sich bis zur 

Verabschiedung von V1.0 noch ändern 

• Für Version 1.0 ist Februar 2006 angepeilt 

• Erweiterungen für V1.1 und V2.0 sind bereits in 

Planung

Folien als PDF

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?