Verhaltensbeschreibung und Spezifikationssprachen

Ähnliche Dokumente
Verhaltensbeschreibung und Spezifikationssprachen

Verhaltensbeschreibung und Spezifikationssprachen

Verhaltensbeschreibung und Spezifikationssprachen

Verhaltensbeschreibung und Spezifikationssprachen

Verhaltensbeschreibung und Spezifikationssprachen

Verhaltensbeschreibung und Spezifikationssprachen

Diskrete Ereignissysteme. Spezielle Netzstrukturen- Übersicht. Beispiele zu speziellen Netzstrukturen. Petri-Netze und Zustandsautomaten

Die intuitionistische Natur von Statecharts

Example Ptolemy Model of Comp.: Synchronous Reactive

Statecharts in UML Grundlagen und Übersetzung in Colored Petri Nets

Kapitel 4 Ereignisdiskrete Systeme (V)

Petrinetze und GPSS/H

Dipl.-Inform. Lars Ebrecht

Einführung: Zustandsdiagramme Stand:

Eingebettete Systeme

Petri-Netze. Teil 2. Chandran Goodchild. Department of Automata Theory University of Freiburg. Pro Seminar, 2017

Vorlesung Qualitative Methoden der Regelungstechnik II WiSe 2014/15 Master PO2008, DPO 02, weitere

Die Belegung der Stellen heißt Markierung und repräsentiert den Zustand des Petri- Netzes.

An Overview of the Signal Clock Calculus

Verteilte Systeme. Diffusionsalgorithmen. Secure Identity Research Group

Spezifikation von Kommunikationssystemen

3.0 VU Formale Modellierung

IHS2 Seminar. Simulation. Steffen Ostendorff

Betriebssysteme. G: Parallele Prozesse. (Teil B: Klassische Problemstellungen, Mutual Exclusion, kritische Regionen)

7. Konkretisierungen im Feindesign. 7.1 Zustandsdiagramme 7.2 Object Constraint Language

Modellierung verteilter Systeme (Grundlagen der Programm- und Systementwicklung II)

MODELLIERUNG UND SPEZIFIKATION

Spezifikation von Kommunikationssystemen

UML - Zustandsdiagramm

SYNTHESE ELEMENTARER PETRINETZE

UML Grundlagen, Zustandsautomat. Zustandsautomaten bilden eine Erweiterung der endlichen Automaten

Korrektheit durch modulare Konstruktion. Wie kann man die Korrektheit reaktiver Systeme gewährleisten?

Aufgaben Petrinetze Aufgabe 1

Wie kann man die Korrektheit reaktiver Systeme gewährleisten?

Verteilte Systeme CS5001

Zustände Zustandsdiagramme

GTI Bonus VHDL - EXTRA

OOA-Dynamische Konzepte

Message Sequence Charts, Live Sequence Charts

Modellieren im Informatikunterricht

Einfaches MSI-Writeback-Inval-Protokoll

Systemmodellierung. Teil Ereignisdiskrete Systeme

Synthese Eingebetteter Systeme. Übung 3

Modellierung verteilter Systeme (Grundlagen der Programm- und Systementwicklung II)

Modellierung verteilter Systeme (Grundlagen der Programm- und Systementwicklung II)

Endliche Automaten 1 WS 00/01. Steuerautomaten

WS Parallele Prozesse. Prof. Hannelore Frank. Parallele Prozesse. PetriNetze. Synchronisation UNIX. Wettbewerb PC Krit.Abschnitt Spinlocks

Petri-Netze / Eine Einführung

VHDL Simulation. Dr.-Ing. Matthias Sand. Lehrstuhl für Informatik 3 (Rechnerarchitektur) Friedrich-Alexander-Universität Erlangen-Nürnberg SS 2011

Vorlesung Software-Engineering I

Kapitel 3 Ereignisdiskrete Systeme (III)

Sven Osterwald Concurrent Objects. Proseminar Parallele Programmierung in Java

Media Engineering. Objektorientierte Modellierung. Verhaltensmodellierung. R. Weller University of Bremen, Germany cgvr.cs.uni-bremen.

Modellierung - Wiederholung

Musterklausur 2 für PMfE

Analyse von Petri-Netz-Modellen. Von Prof. Dr. rer. nat. habil. Peter H. Starke Humboldt-Universitat Berlin

Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung

Modellierung verteilter Systeme

Softwaretechnik. Kapitel 11 : Zustandsdiagramme. Statecharts / State Machines Historisches. State Machines in UML Verwendung in OO

Nebenläufige und verteilte Programme CS2301

Modellierung verteilter Systeme (Grundlagen der Programm- und Systementwicklung II)

Invalidierungs- und Update-basierte Cache-Kohärenz-Protokolle

Synchronisation und Kommunikation über Nachrichten

UML / Fujaba. Generierung von Java-Quellcode aus UML-Diagrammen. Marcel Friedrich

Laborübung 4. Zustandsautomaten (Finite State Machines)

Modellierungsmethoden der Informatik

Vorlesung Informatik II

MODELLIERUNG UND SPEZIFIKATION

Electronic Design Automation (EDA) Spezifikation

Petri-Netze / Eine Einführung (Teil 2)

Sommersemester Analyse II: Verhalten (Zustandsautomaten)

Grundlagen: Überblick

Software Engineering in der Praxis

Besteht aus Aktoren (actors) und use-cases sowie deren Verbindungen.

Anomalien und andere folk lores

Kapitel 3 Systementwurf

Generierung von Steuerungsprogrammcode für SPS und μc aus Petri-Netz-Modellen

Warum Modellierung? OE-Vorlesung 2016 Einführung in Petrinetze. Was ist ein Modell? Und warum Petrinetze? Petrinetze sind ein Modellierungswerkzeug.

Wechselseitiger Ausschluss in verteilten Systemen / Elektionsalgorithmen. Özden Urganci Ulf Sigmund Ömer Ekinci

UML fürs Pflichtenheft

Software Engineering in der Praxis

Domänenorientierte Softwarearchitektur mit CÉU und RUST am Beispiel eines Heizungsgateways zur Fernüberwachung und Fernparametrisierung

Software Engineering in der Praxis

1. Einführung in Temporallogik CTL

Vorlesung und Übung. Modellierung, Simulation, Entwurf heterogener Systeme. Dr. Christoph Grimm Professur Technische Informatik

Kapitel 1 Parallele Modelle Wie rechnet man parallel?

Zeit als Mittel der Reihenfolgebestimmung

Protokoll-Spezifikationen

Stochastische Petrinetze

Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung

Hardware Praktikum 2008

Synchrone Botschaften

17 Zähler. Hochschule für Angewandte Wissenschaften Hamburg FACHBEREICH ELEKTROTECHNIK UND INFORMATIK DIGITALTECHNIK 17-1

Modellierung verteilter Systeme (Grundlagen der Programm- und Systementwicklung II)

State diagrams (Zustandsautomaten)

Verhaltensanalysegraph für Petrinetze

Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung

Transkript:

TECHNISCHE UNIVERSITÄT ILMENAU Verhaltensbeschreibung und Spezifikationssprachen Integrated Kommunikation Systems http://www.tu-ilmenau.de/iks Verhaltensmodelle Zustandsautomaten (FSM) Nicht-deterministische Zustandsautomaten (NDFSM) Parallele Zustandsautomaten Petri-Netz (PN) Datenflussgraph (DFG) Kontrollflussgraph (CFG) Kontroll-Datenflussgraph (CDFG) Grundkonzepte Nebenläufigkeit Hierarchie Kommunikation Synchronisation Ausnahmebehandlung Nicht-Determinismus Timing Spezifikationssprachen StateCharts SDL VHDL SystemC...

Synchrone vs. asynchrone FSMs Synchrone FSMs (z.b. StateCharts): Kommunikation mit Hilfe von gemeinsamen Variablen (shared variables) => lesen und schreiben ohne zusätzlichen Zeitaufwand Sofortige Kommunikation und Berechnung zu definierten Zeitpunkten alle Zustandsübergänge laufen gleichzeitig ab (lock-step) unter Umständen schwierig zu implementieren multi-rate specifications???? verteilte/heterogene Architekturen Asynchrone FSMs (z.b. SDL, CSP) : voneinander unabhängige Abläufe möglich keine gleichzeitigen Übergänge (Ausnahme: CSP rendezvous) Ggfs. Zeitstempel zur Synchronisation erforderlich leicht zu implementieren Vielzahl (nicht-)kommerzieller graphischer Sprachen und Tools: StateCharts, UML, SDL, StateFlow Tool-Support für Design, Simulation, Validierung, Code-Generierung, HW- Synthese, 2

StateCharts Grundlagen Grundlagen: Erweiterung konventioneller FSMs konventionelle FSMs für komplexe Verhaltensbeschreibungen ungeeignet flach und unstrukturiert von Natur aus sequenziell StateCharts unterstützen wiederholte Zerlegung von Zuständen in Sub-Zustände mit AND/OR, sowie synchrone Kommunikation (unmittelbare Übertragung an alle (Broadcast)) StateCharts beschreiben das Verhalten, zusätzlich (aber weniger gebräuchlich) können ModuleCharts die Struktur und ActivityCharts Datenfluss und Kontrollfluss beschreiben Quelle: Science of Computer Programming 8 (1987) 231-274, North-Holland STATECHARTS: A VISUAL FORMALISM FOR COMPLEX SYSTEMS David HAREL, Department of Applied Mathematics, The Weizmann Institute of Science, Rehovot, Israel 3

StateCharts Syntax Die allgemeine Syntax eines Übergangs in StateCharts ist E(C)/A wobei S,T Zustände darstellen E ist das Ereignis, welches den Übergang auslöst (extern oder intern) C ist die Bedingung für den Übergang (C muss wahr sein, wenn E eintritt, sonst kein Übergang) A ist die Aktion, welche beim Übergang erfolgt Für jeden Übergang gilt: Bedingung und Aktion sind optional ein Ereignis kann eine Veränderung eines Variablenwertes sein elementare Vergleiche (z. B. x > y) sind gültige Bedingungen Wertzuweisungen (z. B. x := 10) sind gültige Aktionen 4

StateCharts Syntax System-Zustand (Status): Konfiguration: Alle aktiven Zustände orthogonaler Komponenten Werte von Bedingungen und Variablen Liste der im letzten Schritt gegnerierten Ereignisse History Information Eingabe: Liste der im letzten Übergang erzeugten Ereignisse der Umgebung Änderung von Bedingungen und Variablenwerten Zustandswechsel: neuer Systemzustand 5

StateCharts Aktionen und Ereignisse Eine Aktion A beim Verlassen eines Zustandes kann als Ereignis einen Übergang in einem orthogonalen (=nebenläüfigen =parallelen) Zustand auslösen: ein Zustandswechsel erzeugt ein für alle anderen Zustände und FSMs sichtbares Ereignis, welches sofort bei allen weiteren FSMs Übergänge auslösen kann, welche wiederum Übergänge auslösen können... die Ausführung des ersten Zustandswechsels bewirkt den zweiten Zustandswechsel unmittelbar und gleichzeitig (in der Realität problematisch!!!) Aktionen und Ereignisse können mit der Ausführung orthogonaler Komponenten in Verbindung stehen: start(a), stopped(b) Orthogonale Komponenten arbeiten im Prinzip nebenläufig und unabhängig voneinander, können sich aber gegenseitig beeinflussen. Entry / Exit Aktionen in den Zuständen bei Eintritt bzw. Verlassen 6

StateCharts Hierarchie Zustandszerlegung: OR-States haben Unterzutände (sub-states) die in exklusiv-oder (XOR) Relation stehen AND-States haben orthogonale Zustandskomponenten (synchrone parallele FSMs) AND-dekomposition auf jeder Hierarchie-Ebene erlubt => besser handhabbar als in Automatennetzen (communicating FSMs), die nur eine Ebene zulassen Basic States haben keine Sub-States (Grund der Hierarchie) Root State haben keine Parent States (Spitze der Hierarchie) Initialisierung: Default (Initialzustände) können in jeder Hierarchiestufe markiert werden History Connector zum Speichern des letzten angenommenen Zustandes in Sub- States Kombination: Initiialzustand beim ersten Starten und History bei weiteren Schritten 7

StateCharts OR Dekomposition Zustand U ist eine Abstraktion der Zustände S und T Um in Zustand U zu sein, muss das System entweder in Zustand S oder in Zustand T sein g S e V f U g S f e V T f h T h Integrated Kommunikation-Systems Andreas Mitschele-Thiel / H.-D. Wuttke 11-Nov- 8

StateCharts Top Down Design Zustand V ist eine Abstraktion der Zustände S und U 9

StateCharts Default State Flache Struktur Hierarchische Struktur 10

StateCharts Default State Flache Struktur Hierarchische Struktur 11

StateCharts Exit on Sub-States Inkorrekt (b=c???) Korrekt 12

StateCharts Default State und History Default: off bei erstem Aufruf Dann: History gleichbedeutend 13

StateCharts AND State Parallele Struktur: n+m Zustände Flache Struktur:??? 14

StateCharts AND State : Flache Struktur Flache Struktur: äquivalente FSM! n*m Zustände 15

StateCharts externe Übergangsvarianten zu AND States A Betreten des Top States (z.b. aufgrund des Ereignisses n ) aktiviert alle parallelen Automaten. 16

StateCharts externe Übergangsvarianten zu AND States A Betreten des Top States (z.b. aufgrund des Ereignisses n ) aktiviert alle parallelen Automaten. Verlassen des Sub-States W (z.b. aufgrund von h (ins) ) deaktiviert den Top State A. 17

StateCharts Aktionen bei Eintritt und/oder Verlassen 18

StateCharts Synchronitäts Hypothese Alle 3 Übergänge geschehen (theoretisch) gleichzeitig => instabile Konfiguration, erst nach Ablauf von A,B,D stabil 19

StateCharts Synchronitätsproblem Mit ursprünglicher Semantik Widerspruch =>Lösung: Mikroschritte (micro steps) 20

StateCharts Mikroschritte Mikro- und Makro- Schritt Semantik: Reaktionen auf Ereignisse und Änderungen geschehen im Mikroschritt und können nur danach wahrgenommen werden Ereignisse in Mikroschritten existieren nur während des einen, auf den verursachenden Mikroschritt folgenden Mikroschritt Berechnungen werden basierend auf der Situation vor dem Mikroschritt durchgeführt Die Durchführung eines Mikroschrittes ändert die Konfiguration des StateCharts Mikroschritte verbrauchen keine Zeit Zeitfortschreitung in Makroschritten nur, wenn kein Übergang stattfindet, d.h. stabile Konfiguration Takt-Ereignisse erfolgen als Makroschritte 21

StateCharts Synchronitätsproblem Aber echte Verklemmung mit Mikroschritten allein nicht lösbar 22

StateCharts AND Dekomposition (7/11)<> Komposition (8/14) k V,Z V,W V.Y U S To be in state U the system must be both in states S and T T e V Z k X.Z X,Y e W e X Y e Q k X,W R Q R Integrated HW/SW-Systems Andreas Mitschele-Thiel / H.-D. Wuttke 11-Nov- 23

StateCharts komplexes Beispiel Stopp-Uhr 24

StateCharts Zusammenfassung 25

Asynchrone Kommunikation Blockierend (Blocking vs. non-blocking) blocking read (Empfänger wartet auf Sender) Lesevorgang kann nicht auf leeren Eingabepuffer prüfen muss auf Eingabe warten A B blocking write (Sender wartet auf Empfänger) Schreibvorgang darf erst nach erfolreichen Schreiben fortsetzen (Schreibvorgang muss Schreibbestätigung abwarten???) Sprachen / Prinzipien blocking write/blocking read (CSP, CCS) (communicating seq. processes, calculus of communicating systems) non-blocking write/blocking read (FIFO, CFSMs, SDL) non-blocking write/non-blocking read (geteilte Variablen) 26

Asynchrone Kommunikation Pufferung A B Puffer (Buffer) dienen zum Ausgleich unterschiedlicher Datenraten von Sender und Empfänger => Problem: Größe des Speichers? verlustfrei oder verlustbehaftet Ereignisse/Token könnten verlorengehen Speicherbegrenzung: Überlauf (Overflow) oder Überschreiben Sender muss geblockt werden einfaches oder mehrfaches Lesen Ergebnis eines jeden Schreibens kann nur einmal oder mehrfach gelesen werden Einfacher FIFO Puffer Priorisierung Außerordentlicher (out of order) Zugriff auf FIFO 27

Kommunikationsmechanismen Rendez-Vous (CSP) keine gemeinsamen Daten, Prozesse müssen zu bestimmten Zeiten synchronisiert Daten austauschen Lesen und Schreiben erfolgen simultan Gemeinsamer Speicher (shared memory) mehrfaches zerstörungsfreies Auslesen möglich Überschreiben gespeicherter Daten bei jedem Schreiben Buffered (FIFO) Begrenzt (bounded) (ECFSMs, CFSMs), feste Kapazität Unbegrenzt (unbounded) (SDL, ACFSMs, Kahn Process Networks, Petri- Netze) 28

Kommunikationsmodelle writer is blocked (e.g. if buffer is full) reader is blocked (e.g. if buffer is empty) data may be read once only Sender Empfänger Puffer Größe Blocking Reads Blocking Writes Single Reads Unsynchronisiert many many one no no no Read-Modify-write many many one yes yes no Unbounded FIFO one/many one unbounded yes no yes Bounded FIFO one/many one bounded yes may be yes Rendezvous one one one yes yes yes Integrated HW/SW-Systems Andreas Mitschele-Thiel / H.-D. Wuttke 11-Nov- 29

Petri-Netze (PNs) Modell eingeführt von C.A. Petri in 1962 Ph.D. Thesis: Communication with Automata Anwendungsfelder: Dezentralisierte Datenverarbeitung, Fertigung, Steuerung, Kommunikationsnetzwerke, Transport, PNs beschreiben explizit und grafisch: Sequenz/Kausalität Konflikt/nicht-deterministische Entscheidung Nebenläufigkeit Asynchrones Modell (Teilordnungsrelation) hauptsächlicher Nachteil: keine Hierarchie 30

Petri-Netz Ein PN (N,M0) ist ein Petri-Netz Graph N und eine Anfangsmarkierung M0 Plätze: repräsentieren verteilten Zustand durch Markenverteilung (Token) Markierung (Zustand) M ist ein n-vektor (m1,m2,m3 ), mit mi als nicht-negative Anzahl von Marken auf Platz pi. Anfangsmarkierung (M 0 ) bezeichnet den Initialzustand Übergänge: repräsentieren Aktionen/Ereignisse enabled transition: schaltfähige Transition t : genug Marken in den Vorplätzen firing transition: feuernde Transition : verändert Markierung ( Markenfluss ) t2 p1 t1 p2 p4 p3 t3 31

Nebenläufigkeit, Kausalität, Entscheidung t1 Nebenläufigkeit t2 Kausalität, Sequenz t5 t3 t4 Entscheidung, Konflikt t6 32

Producer-Consumer Problem Produce Buffer Consume Integrated HW/SW-Systems Andreas Mitschele-Thiel / H.-D. Wuttke 11-Nov- 33

Communication Protocol Send msg Process 1 Process 2 Send Ack Receive Ack Integrated HW/SW-Systems Andreas Mitschele-Thiel / H.-D. Wuttke 11-Nov- 34

Petri Netze - Eigenschaften Verhaltenseigenschaften: abhängig von initialer Markierung Erreichbarkeit (reachability) (einer Markierung M von einer Markierung M o ) => Erreichbarkeitsgraph, ausgehend von einer Markierung werden alle erreichbaren Situationen notiert / FSM Begrenztheit (boundedness) (begrenzte Anzahl von Token) => Begrenzung der Tokenzahl pro Platz und / oder Transition (Kapazität) Konservation (conservation) (Anzahl der Token bleibt Konstant) Lebendigkeit (liveness) (alle Transitionen können feuern bei beliebiger Anfangsmarkierung M o ) Schedulability (Festlegung der Reihenfolge) Strukturelle Eigenschaften: unabhängig von der initialen Markierung, d.h. gültig für beliebige Anfangsmarkierungen (in Praxis oft zu restriktiv, weil i.a. Anfangsmarkierung als Teil des Entwurfes bekannt ist) Konsistenz (consistency) Strukturelle Begrenztheit (structural boundedness) 35

Zusammenfassung: Steuerfluss Beschreibung Eigenschaften Specifikationssprache Nichtdeterminismus NDFSM Parallele Automaten State Charts, Petri Nets Prozesse SDL Kommunikation MSC Hierarchie State Charts Graphische Unterstützung Alle Semantik unterschiedlich ;-( 36