Verhaltensbeschreibung und Spezifikationssprachen

Transkript

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

2 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

3 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

4 Beispiel Fahrstuhlsteuerung: Identifikation des Systems 4

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

6 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

7 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

8 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

9 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

10 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

11 Beispiel Fahrstuhlsteuerung: Zustandsautomat 11

12 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

13 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

14 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

15 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 => START => SEC => END 0 9 SEC => END SEC => END SEC => END 6 SEC => 8 SEC => 7 SEC => SEC => 5 SEC => 15

16 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

17 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

18 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

19 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 => SEC => END_TIMER_5 0 SEC => END_TIMER_10 9 SEC => 8 SEC => 7 SEC => 6 SEC => 5 19

20 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

21 Finite State Machines Erweiterungen: parallele Automaten 21

22 Finite State Machines Beispiel: Zustandsdiagramm (informal) 22

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

24 FSM Erweiterungen Kommunikation zwischen FSMs 24

25 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

26 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