Verhaltensbeschreibung und Spezifikationssprachen

Ähnliche Dokumente
Verhaltensbeschreibung und Spezifikationssprachen

Verhaltensbeschreibung und Spezifikationssprachen

Verhaltensbeschreibung und Spezifikationssprachen

IHS2 Seminar. Simulation. Steffen Ostendorff

Verhaltensbeschreibung und Spezifikationssprachen

Example Ptolemy Model of Comp.: Synchronous Reactive

Verhaltensbeschreibung und Spezifikationssprachen

Verhaltensbeschreibung und Spezifikationssprachen

Integrierte HW/SW Systeme: Anforderungen

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

Grundlagen der Technischen Informatik. 13. Übung

Kapitel 3 Ereignisdiskrete Systeme (III)

Laborübung 4. Zustandsautomaten (Finite State Machines)

Outline Automaten FSM Synthesis FSM in VHDL FSM auf FPGA. State Machines. Marc Reichenbach und Michael Schmidt

ERA-Zentralübung 11. Maximilian Bandle LRR TU München Maximilian Bandle LRR TU München ERA-Zentralübung 11

Sequentielle Schaltungen 37 SS 96. Steuerpfad

Spezifikation von Kommunikationssystemen

An Overview of the Signal Clock Calculus

Sommersemester Analyse II: Verhalten (Zustandsautomaten)

Vorlesung Rechnerstrukturen Winter 2002/03. 3b. Endliche Automaten. Modellierung und Realisierung von Steuerungen

Endliche Automaten 1 WS 00/01. Steuerautomaten

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

Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung

GTI Bonus VHDL - EXTRA

Laborübung 2. Teil 1: Latches, Flipflops, Counter. Abbildung 1: Schaltkreis eines Gated D-Latch

Seminar Programmierung Eingebetteter Systeme

Endliche Automaten. Im Hauptseminar Neuronale Netze LMU München, WS 2016/17

Protokoll-Spezifikationen

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

Tristate Buffer / erste Module

Grundlagen der Technischen Informatik

Dipl.-Inform. Lars Ebrecht

Statecharts in UML Grundlagen und Übersetzung in Colored Petri Nets

Teil 1: Logik 1e: Zustandsautomaten

1.4 Spezifikation. Inhalte einer. Spezifikation

Endliche Automaten. Endliche Automaten J. Blömer 1/24

State Event Technik CT2, Donnerstag / TE402 M. Thaler, TG208, tham@zhaw.ch

Grundlagen der Technischen Informatik. 13. Übung

Realtime Studio Professional. ARTiSAN. Eine Visuelle Softwareentwicklungsumgebung zur Erstellung von Echtzeitanwendungen

Unified Modeling Language (UML )

VHDL Synthese. Dr.-Ing. Matthias Sand. Lehrstuhl für Informatik 3 (Rechnerarchitektur) Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2009/2010

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

Wie kann man die Korrektheit reaktiver Systeme gewährleisten?

Handelt es sich um ein taktzustands- oder taktflankengesteuertes D-Flipflop?

5.2 Endliche Automaten

State diagrams (Zustandsautomaten)

15 Einführung in den Entwurf von Zustandsautomaten

Johann Wolfgang Goethe-Universität

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

Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung

Together - Integrierte SWE und QA 1. Fahrstuhlsteuerung

Rechnerstrukturen WS 2012/13

Spezifikation von Kommunikationssystemen

Bounded Model Checking mit SystemC

UML - Zustandsdiagramm

Rechnerstrukturen. Michael Engel und Peter Marwedel SS TU Dortmund, Fakultät für Informatik

Electronic Design Automation (EDA) Spezifikation

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

Rechnerorganisation 8. Vorlesung

Rechnerstrukturen. Michael Engel und Peter Marwedel. Sommer TU Dortmund, Fakultät für Informatik

Software Engineering in der Praxis

Die intuitionistische Natur von Statecharts

Verifikation in der Realität. In der Industrie wird der Begriff Verifikation häufig im Zusammenhang mit nicht formalen Methoden verwendet:

Rechnerstrukturen. Michael Engel und Peter Marwedel WS 2013/14. TU Dortmund, Fakultät für Informatik

Ein ROM soll aus mehreren ROMs (vgl. Abbildung rechts: Enable-Leitung EN, Adressleitungen ADDR, Datenleitungen DATA) aufgebaut werden.

Vortrag zum Hauptseminar Hardware/Software Co-Design

Fakultät für Informatik der Technischen Universität München. Kapitel 2. Modellierung von Echtzeitsystemen und Werkzeuge

Modellieren im Informatikunterricht

Ereignisdiskrete Systeme

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

Grundbegriffe der Informatik

2.6 Verdeutlichung verwendeter Begriffe

Endliche Automaten. Endliche Automaten J. Blömer 1/23

Unified Modelling Language

Technische Informatik (RO)

Teil 1: Logik 1e: Zustandsautomaten

Grundlagen der Technischen Informatik

Grundbegriffe der Informatik

1 Entwurf und Verhalten einfacher, synchroner Automaten

D.42 D Synchroner Zähler. 6.3 Synchroner Zähler (2) 6.3 Synchroner Zähler (4) 6.3 Synchroner Zähler (3) Einsatz von JK-Flip-Flops

, SS2012 Übungsgruppen: Do., Mi.,

GTI ÜBUNG 11 AUTOMATEN

Kapitel 4 Spezifikation von Kommunikationssystemen

Modellierung von Echtzeitsystemen

FORMALE SYSTEME. Wiederholung. Beispiel: NFA. Wiederholung: NFA. 4. Vorlesung: Nichtdeterministische Endliche Automaten. TU Dresden, 19.

1) Gegeben Sei der auf der rechten Seite beschriebene Prozess mit folgenden globalen Deklarationen. const int N := 4; chan c[n]; int wert := 0;

1. Einführung in Temporallogik CTL

Aufbau und Funktionsweise eines Computers - II

Klausur zur Vorlesung. Grundlagen der Technischen Informatik (GTI) und. Grundlagen der Rechnerarchitektur (GRA)

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

Computergestützte Gruppenarbeit

FORMALE SYSTEME. Wiederholung. Beispiel: NFA. Wiederholung: NFA. 4. Vorlesung: Nichtdeterministische Endliche Automaten. TU Dresden, 20.

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

Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung

Software Engineering. 5. Architektur

Computergestützter IC- Entwurf

Zustände Zustandsdiagramme

3.0 VU Formale Modellierung

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

Paul Molitor und Jörg Ritter VHDL. Eine Einführung. ein Imprint von Pearson Education

Transkript:

TECHNISCHE UNIVERSITÄT ILMENAU Verhaltensbeschreibung und Spezifikationssprachen Integrierte Kommunikationssysteme 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...

Zustandsautomaten: Finite State Machines (FSM) Funktionelle Dekomposition in (Bearbeitungs- oder System-) Zustände Endliche (finite) Zustandsmenge, Ein- und Ausgabe(alphabet) Verarbeitet Eingangszeichenfolge zu Ausgangszeichenfolge Zeichen = Wert einer Variablen (SW) oder eines Vektors (HW) Zustandsübergänge (Transitionen): zeitlos, ereignisgesteuert, deterministisch Ausgänge schalten synchron oder asynchron zu Zustandsübergängen, deterministisch Keine Nebenläufigkeit (sequentieller Automat) Flache Struktur (keine Hierarchie) Typische Anwendungen: reaktive (Steuerungs-)Systeme Protokolle (Telekommunikation, Systembaugruppen, ) 2

Beispiel Fahrstuhlsteuerung Identifikation des zu entwickelnden Systems (Analyse) Umgebung/Schnittstellen: - Aktoren (Antrieb) für Auf- und Abfahrt - Aktoren (Antriebe) für Türen - Aktoren (Anzeigen) auf Etage und im Aufzug - Bediensensoren (auf Etagen und im Aufzug) - Zustandssensoren (Etagen, Türen) - Sicherheitsspezifische Sensoren Zu entwickelndes System: - Steuerung der Aktoren auf Basis der Eingaben/Sensorik 3

Beispiel Fahrstuhlsteuerung: Identifikation des Systems 4

Beispiel Fahrstuhlsteuerung: Identifikation des Systems Identifikation der Schnittstellen der Steuerung und Abgrenzung von der Umgebung?? 5

Beispiel Fahrstuhlsteuerung: Spezifikation der Schnittstellen Identifikation der Schnittstellen: Sensorik/Input und Aktorik/Output der Steuerung Sensorik: x0 - x3: Eingabe Zieletage im Aufzug X4 - x7: Kontakt zur Meldung der Position (Etage) des Aufzugs Aktorik: y0 y1: Antriebssteuerung auf und ab y2 y7: Anzeige zur Bestätigung der Aufzugsanforderung für auf und ab (je Etage) x8 - x10: Eingabe zur Anforderung des Aufzugs in Abwärtsrichtung je Etage x11- x13: Eingabe zur Anforderung des Aufzugs in Aufwärtsrichtung je Etage X14 x15: Bedientaste im Aufzug zum Öffnen bzw. Schließen der Tür y8 y11: Anzeige der gewählten Zieletage(n) im Aufzug y12 y15: Anzeige der Aufzugsposition (Etage 1-4) im Aufzug (ggf. auch auf Etagen) y16 y17: Antriebssteuerung für Türantrieb 6

Beispiel Fahrstuhlsteuerung: Spezifikation der Schnittstellen Sensorik: Realisierung von Tastern und Schaltern? Taster, z.b. für Fahrstuhlanforderung Einfacher Taster: kurzzeitige 1 des Tasters wird von Fahrstuhlsteuerung abgetastet und in FSM gespeichert Intelligenter Taster: Event wird an Steuerung geschickt und resultiert in Speicherung der Anforderung in FSM Schalter, z.b. für Signalisierung der Etage oder der Türenendlagen Einfacher Schalter => Ein- oder Ausschaltungen werden als zwei verschiedene Zustände des Schalters von Fahrstuhlsteuerung periodisch abgetastet; explizite Speicherung des Zustands in FSM nicht mehr nötig Intelligenter Schalter: Ein- oder Ausschaltungen werden als zwei verschiedene Events an Fahrstuhlsteuerung gesendet und entsprechend in FSM gespeichert; besondere Maßnahmen für/nach Reset der FSM nötig Intelligente Sensorik: Einfache Steuerung => Kommunikationssystem, Verteiltes System 7

Beispiel Fahrstuhlsteuerung: Spezifikation der Schnittstellen Aktorik: Ansteuerung von Motoren und Anzeigeelementen? Türantrieb Einfache Ansteuerung mit 3 Zuständen: auf, zu, halt; Motor läuft während Signal anliegt, sonst nicht Intelligente Türsteuerung: Steuersignale (Events) zum Öffnen und Schließen der Tür, integrierte automatische Endabschaltung und Meldung der Endabschaltung (Sensorik) LED-Etagenanforderungsanzeige auf Etage (bzw. im Fahrstuhl) Einfache Ansteuerung jeder LED die direkt aus Zustand der FSM (Ausgabelogik) abgeleitet wird Integriertes Fahrstuhl-Anforderungsmodul (kombinierte Sensorik/Aktorik): Generierung von Events wenn Taste (auf/ab) gedrückt wird und lokale Einschaltung der LED, Empfang eines Events zum Löschen der LED wenn Aufzug ankommt Intelligente Sensorik/Aktorikmodule: Einfache Steuerung => Kommunikationssystem, Verteiltes System 8

Abgrenzung zu Moore und Mealy (getakteten) Automaten Moore Automaten: nicht-reaktiv (Reaktion durch Takt verzögert) Einfach zu entwerfen X (Zustandsübergang bei Ausgangswechsel) für Implementierung in SW geeignet δ τ µ n Z a Z Y Mealy Automaten: reaktiv (unmittelbare Reaktion auf Eingangsänderungen) X Schwieriger zu entwerfen für SW-Implementierung weniger gut geeignet Wegen unmittelbarer Reaktion auf Eingangsänderungen (interrupts/polling) Softwaresystem muss schnell genug sein (Echtzeitforderung) In Hardware für schnelle Reaktion sinnvoll, aber asynchron! δ τ λ n Z a Z Y Hier: typischerweise eventgetriggerte Automaten Event (Interrupt statt Abtastung bei Takt) löst Zustandsübergang aus 9

Unterschiede zw. Event- und Zeitgetriebenen Automaten Eventgetriebe Automaten verhalten sich etwas anders als über Eingangsvariablen gesteuerte Mealy- oder Moore-Automaten Eventgetriebene Automaten: Events ähneln semantisch den Flanken der Eingangsvariablen zeitgetriebener Automaten, d.h. Event führt zu einer Transition, d.h. Taktung der FSM Der Zustand der Eingangsvariable muss, wenn er für das System auch später noch relevant ist, anders als bei Mealy- oder Moore-Automaten sich im Zustand es Automaten niederschlagen und darüber implizit gespeichert werden ggf. Vergrößerung des Zustandsraums modifizierte Ansteuerung der Ein- und Ausgabeschnittstellen, d.h. Events können sich zeitlich überschneiden und werden evtl. sequentiell abgearbeitet Zeitliches Verhalten kann sich ändern Beispiel Fahrstuhlsteuerung: hier könnten die Eingaben als Variable oder auch als Events realisiert werden, mit entsprechenden Folgen für die Realisierung des Steuerungsautomaten 10

Beispiel Fahrstuhlsteuerung: Zustandsautomat 11

Finite State Machines Diskussion Vorteile: Einfach nutzbar (Graphische Darstellung) Mächtiges Ausdrucksmittel für Synthese (SW and HW) Verifikation Nachteile: manchmal über-spezifizierte Implementierung (z.b. Zählfolge (Bsp: alle Etagen, bzw. Etagenkombinationen) vollständig als Zustandsübergänge spezifiziert) Anzahl der Zustände kann unbeherrschbar werden (im Bsp. viele Etagen, mehrere Aufzüge) Numerische Berechnungen können nicht kompakt (z.b. in Form von Operationen) spezifiziert werden erweiterte FSMs (informal, formal) 12

Beispiel Fahrstuhlsteuerung: Vereinfachung der Spezifikation Vereinfachung durch Divide & Conquer-Strategie: - Mehrere nebenläufige Automaten: Entkopplung z.b. - der detaillierten Türsteuerungen mit automatischer Endabschaltung von der abstrakten Fahrstuhl- Etagensteuerung, - der detaillierten Aufzugsmotorsteuerung und Geschwindigkeitsregelung von der abstrakten Etagensteuerung (Missionssteuerung) - der Aufzeichnung der Anforderungen und der detaillierten Abarbeitung der Anforderungen - Hierarchie: - Trennung der Steuerung des Systems bei fahrendem Aufzug vom Betrieb bei stehendem Aufzug (Tür) - Vererbung: - Detailverhalten der Tür je Etage ist identisch - Kopplung der Automaten über Hierarchiewechsel, Kommunikation (Variable oder Events) und Synchronisation 13

Finite State Machines Erweiterungen Erweiterungen zur Unterstützung des Divide and conquer -Prinzips Hierarchie Nebenläufigkeit Kommunikation Synchronisation Weitere hilfreiche praktische Konzepte Vererbung Nichtdeterminismus Timer Zusätzliche Variable und numerische Berechnungen Nebeneffekte der Erweiterungen: erweiterte (formale) Semantik nötig Formale Verifikation wird schwieriger bis unmöglich 14

Wiederholung: Zeitbereichsspezifikation mittels NDFSM Nichtdeterminismus: Spezialfall von unspezifiziertem bzw. unbekanntem Verhalten, aber geeignet zur effizienten Beschreibung (nichtdeterminierter Zustandsübergang = nicht bestimmt, welcher Folgezustand aus einer Menge gültiger Folgezustände angenommen wird) Beispiel: nichtdeterministische Verzögerung (z.b. zwischen 6 und 10 s) START => SEC => SEC => SEC => 1 2 3 4 START => SEC => END 0 9 SEC => END SEC => END SEC => END 6 SEC => 8 SEC => 7 SEC => SEC => 5 SEC => 15

Wiederholung: Kompakte NDFSMs statt FSMs Formal sind FSMs und NDFSMs äquivalent (Rabin-Scott Konstruktion, Rabin 59) Praktisch sind NDFSMs meist kompakter (weniger Zustände) (exponentielle Zustandsexplosion um Determiniertheit zu erreichen) Beispiel: nicht-deterministische Auswahl von Übergang a in Zustand s1 äquivalente deterministische FSM s1 a s1 a c c a s2,s3 b c s3 s2 b s3 a b a a s2 16

Modellierung von Nebenläufigkeit Parallele Automaten Systeme bestehen typisch aus Teilen mit relativ unabhängigen Funktionen, z. B. Sicherheitsgurt-Steuerung Timer Fahrer z. B. Fahrstuhlsteuerung Türsteuerung Anforderungsspeicher Systeme können physisch verteilt sein, z. B. Kommunikationsprotokolle (TCP, ARQ) Teile, die mit FSMs beschrieben sind, müssen zusammengebracht ( komponiert ) werden Ansatz: Konstruktion eines vollständigen Systemmodells Kartesisches Produkt aller Zustände führt zu Zustandsexplosion Systembeschreibung mit separaten FSMs und deren Verbindung (Kopplung) Problem: Wie kommunizieren die gekoppelten FSMs? a) alle FSMs wechseln Zustand gleichzeitig (Synchronität), d.h. Systemzustand = kartesisches Produkt der Zustände der Komponenten oder b) FSMs laufen asynchron und sind über (asynchrone) Events gekoppelt => SDL 17

FSM Komposition Beispiel Beispiel Sicherheitsgurt-Steuerung: 5 sec nach Betätigen des Zündschlüssels soll ein Alarmsignal ertönen, wenn der Gurt nicht angelegt ist Nach 10 sec soll der Alarm abgeschaltet werden Beispiel: Belt Control Timer SEC Timer START_TIMER END_TIMER_5 END_TIMER_10 Belt Control KEY_ON KEY_OFF BELT_ON ALARM_ON ALARM_OFF KEY_ON => START_TIMER OFF Belt Control KEY_OFF or BELT _ON => WAIT END_TIMER_5 => ALARM_ON END_TIMER_10 or BELT_ON or KEY_OFF => ALARM_OFF ALARM 18

FSM Komposition Beispiel Beispiel: Belt Control Timer SEC KEY_ON => START_TIMER WAIT Timer START_TIMER END_TIMER_5 Belt Control KEY_OFF or OFF BELT _ON => END_TIMER_10 or END_TIMER_5 => ALARM_ON END_TIMER_10 BELT_ON or KEY_OFF => ALARM_OFF ALARM Timer START_TIMER => START_TIMER => SEC => SEC => SEC => 1 2 3 4 SEC => END_TIMER_5 0 SEC => END_TIMER_10 9 SEC => 8 SEC => 7 SEC => 6 SEC => 5 19

FSM Komposition Beispiel Kartesisches Produkt aus Belt Control und Timer KEY_ON and START_TIMER => START_TIMER muss zusammen passieren OFF, 0 WAIT, 1 not SEC and (KEY_OFF or BELT_ON) => SEC and not (KEY_OFF or BELT_ON) => WAIT, 2 OFF, 1 SEC and (KEY_OFF or BELT_ON) => OFF, 2 20

Finite State Machines Erweiterungen: parallele Automaten 21

Finite State Machines Beispiel: Zustandsdiagramm (informal) 22

FSM Erweiterungen Beispiel: Interaktion/Prozesse Start (Inter-)aktion (Re-)aktionsfolge.... Ende (vs. FSM: zyklisch) 23

FSM Erweiterungen Kommunikation zwischen FSMs 24

Hierarchische FSM Modelle Beispiel StateCharts Problem: Wie reduziert man die Darstellung? Harel s Veröffentlichung: StateCharts (language) and bounded concurrency (model): 3 orthogonale exponentielle Reduktionen Hierarchie: Zustand a umfasst eine komplette FSM in a bedeutet: FSM in a ist aktiv Zustände von a heißen OR-Zustände Nützlich zur Modellierung von Voraussetzungen und Ausnahmen (z. B. Reset ) Parallelität/Nebenläufigkeit: 2 oder mehr FSMs sind gleichzeitig aktiv Zustände heißen AND-Zustände Nichtdeterminismus: Zur Verhaltensabstraktion a a1 done odd even a2 recovery error 25

Synchrone vs. asynchrone FSMs Synchrone FSMs (z.b. StateCharts): Kommunikation mit Hilfe gemeinsamer Variablen (shared variables) => lesen und schreiben ohne zusätzlichen Zeitaufwand Sofortige Kommunikation und Berechnung zu definierten Zeitpunkten (auch bei mehreren parallelen Ereignissen, d.h. Broadcast) alle Zustandsübergänge laufen gleichzeitig ab (lock-step) Geeignet für zentrale Implementierung Ungeeignet für dezentrale, verteilte Implementierung Asynchrone Prozesse/FSMs (z.b. SDL, CSP): typ. voneinander unabhängige Abläufe mehrere an einem Prozess bzw. einer FSM anliegende Ereignisse werden typ. sequentiell abgearbeitet keine gleichzeitigen Übergänge (Ausnahme: CSP Rendezvous) Ggfs. Zeitstempel zur Synchronisation erforderlich Semantik favorisiert verteilte Implementierung Vielzahl (nicht-)kommerzieller graphischer Sprachen: StateCharts, UML, SDL, etc. Tools für Entwurf, Simulation, Validierung/Test, Code-Generierung, HW-Synthese, 26