Home

Formale Spezifikation reaktiver Systeme mit einer

1. einfache Forderung unbegrenzt einfaches Verbot unbegrenzt BB G BB i F A rk Ia gt SPS Zyklen n SPS Zyklen n erweiterte Forderung unbegrenzt erweiterte M glichkeit unbegrenzt B B P YY FL T kp T rk SPS Zyklen n SPS Zyklen n Abbildung 16 Timingdiagramme Unbegrenzt 3 2 Temporale Logik als formale Basis der SFS Die zuvor beschriebenen Anforderungskategorien m ssen formal dargestellt werden F r die zuvor beschriebene Einbindung der Sicherheitsfachsprache in eine Verifikati onsumgebung wird eine Darstellung der Programmanforderungen in Form von For meln der Temporalen Logik ben tigt Die folgenden Abschnitte geben einen ber blick ber die logischen Grundlagen und leiten die notwendigen Darstellungsformen ab 3 2 1 Aussagenlogik Das Alphabet der Aussagenlogik besteht aus atomaren Formeln und Symbolen Rupp96 Zu den Symbolen geh ren Negation nicht ffnende Klammer schlie ende Klammer Konditional wenn dann p v q Formeln werden durch folgende Regeln gebildet Jede atomare Formel ist eine Formel Wenn p eine Formel ist dann ist p auch eine Formel Wenn p und q Formeln sind dann ist p q auch eine Formel 51 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Mit diesen Grundlagen lassen sich andere Operatoren und Symbole abl
2. 12 BOOL VAR_GLOBAL tr_sys_ready Transportsystems TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 13 BOOL VAR_GLOBAL tr_sys_finished TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt die Fertigmeldung des Transportsystems Formale Spezifikation mit dem SFS Editor 144 gt gt gt Satz 4 lt lt lt einfache Forderung direkt Wenn der aktuelle Stand der Auftragsbearbeitung Neu ist und die Bearbeitungsart ist Pressen und die Bereitschaftsmeldung der Produktionszelle 1 ist gesetzt und die Bereitschaftsmeldung des Transportsystems ist gesetzt dann muss der aktuelle Stand der Auftragsbearbeitung unmittelbar auf Rohteile holen gesetzt werden und die Transportart muss unmittelbar auf 1 Rohteile holen gesetzt werden und die anzufahrende Produktionszelle muss unmittelbar 1 Anhang werden und die Bereitschaftsmeldung der Produktionszelle 1 muss unmittelbar zur ckgesetzt werden und die Bereitschaftsmeldung des Transportsystems muss unmittelbar zur ckgesetzt werden AG rdy_in amp order_status 1 amp order_work 1 amp cell_l_ready amp tr_sys_ready gt Al rdy_plc U rdy_plc amp order_status 2 amp tr_kind 1 amp tr_place 1 amp cell_l_ready amp tr_sys_ready gt gt gt Satz 5 lt lt lt einfache Forderung direkt Wenn der
3. Variante 1 es liegt ein Teil auf dem Hubdrehtisch die Presse und das Ablageband sind leer Darstellung 1a gt Arm 1 transportiert das Teil in die Presse 1b 1c weiter mit Variante 2 165 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Variante 2 es liegt ein bearbeitetes Teil in der Presse der Hubdrehtisch und das Ablageband sind leer Darstellung 2a gt Arm 2 transportiert das Teil auf das Ablageband 2b 2c Variante 3 es liegt ein Teil auf dem Hubdrehtisch und es liegt ein bearbeitetes Teil in der Presse das Ablageband ist leer Darstellung 3a gt Arm 1 nimmt das Teil vom Hubdrehtisch auf 3b Arm 2 entnimmt das bearbeitete Teil aus der Presse 3c Arm 2 legt das fertige Teil auf dem Ablageband ab 3d Arm 1 legt das neue Teil in die Presse ein 3e Definition neuer Daten mit dem SFS Editor Der Roboter soll einerseits Rohteile vom Hubdrehtisch zur Presse bef rdern und an dererseits Fertigteile aus der Presse entnehmen und auf dem Ablageband ablegen Da es wiederum keine Sensoren zur direkten Bestimmung des Vorhandenseins von Werkst cken gibt ben tigt die Robotersteuerung wieder zus tzliche Signale wann sie mit ihrer Arbeit beginnen soll F r den Beschickungsvorgang der Presse bedeutet dies dass es sowohl eine Meldung geben muss wann der Hubdrehtisch mit einem Rohteil in Position ist ist bereits definiert und dass es auch eine Meldung geben muss wann die Presse zur Auf
4. gt gt gt Satz 122 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 11 ist und der Roboterarm 1 ist am Hubdrehtisch dann muss das Ausfahren des Roboterarms 1 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 12 gesetzt werden und der Magnetgreifer des Roboterarms 1 muss unmittelbar aktiviert werden und das Einziehen des Roboterarms 1 muss unmittelbar gestartet werden AG rdy_in amp Robot_state 11 amp Arml_ext 0 52 gt Al rdy_plc U rdy_plc amp Arml_forward amp Robot_state 12 amp Arml_mag_on amp Arml_backward gt gt gt Satz 123 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 12 ist und der Roboterarm 1 ist hinten dann muss das Einziehen des Roboterarms 1 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 13 gesetzt werden und die Fertigmeldung Roboter hat Teil vom Tisch genommen muss unmittelbar gesetzt werden und die Drehung des Roboters nach links muss unmittelbar gestartet werden 210 Anhang AG rdy_in amp Robot_state 12 amp Arml_ext 0 0 gt Al rdy_plc U rdy_plc amp Arml_backward amp Robot_state 13 amp Robot_done_take_table amp Robot_left gt gt gt Satz 124 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Ro
5. Definition neuer Daten mit dem SFS Editor Sensor des Ablagebands Technische Bezeichnung SPS Variable Datentyp Kommentar Lichtschranke am Ablageband LB_at_dbelt Bool TRUE Lichtschranke frei Tabelle 40 Datenebene 4 Sensor des Ablagebands 3102 BOOL VAR LB_at_dbelt die Lichtschranke am Ende des Ablagebands TRUE Lois frei FALSE_I blockiert Aktor des Ablagebands Technische Bezeichnung SPS Variable Datentyp Kommentar Antriebsmotor Ablageband DBelt_start Bool Tabelle 41 Datenebene 4 Aktor des Ablagebands 3103 BOOL VAR DBelt_start der Antrieb des Ablagebands TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gestartet FALSE_O gestoppt 224 Anhang Informelle Spezifikation Die Steuerung des Ablagebands verbleibt solange in Ruhe bis durch die Zellen steuerung entweder das Startsignal zum Transport eines Fertigteils zum Bandende erfolgt Danach wird die geforderte Transportroutine bearbeitet Die innerhalb dieser Routinen abzuarbeitenden Teilvorg nge sind unbedingt in der festgelegten Reihen folge abzuarbeiten es bietet sich die Entwicklung einer Ablaufstruktur an Definition neuer Daten mit dem SFS Editor Interne Variable der Steuerung des Ablagebands Technische Bezeichnung SPS Variable Datentyp Kommentar Zustandsvariable des Abl
6. Nur wenn irgendwann lt past_cond_pl gt dann lt PO3_for_pl gt Nur nachdem lt past_cond_pl gt lt PO3_for_pl gt lt POe3_back_pl gt wenn irgendwann lt past_cond_pl gt DI DI lt POe3_back_pl gt wenn vorher lt past_cond_pl gt Wenn lt pres_cond_pl gt dann lt PR1_for_pl gt lt PRsl_back_pl gt wenn lt pres_cond_pl gt Solange lt pres cond pls lt PR3_for_pl gt lt PRs3_back_pl gt solange lt pres_cond_pl gt Wenn irgendwann lt past_cond_pl gt dann lt PR3_for_pl gt bis lt pres_cond_pl gt Nachdem lt past_cond_pl gt lt PR3_for_pl gt bis lt pres_cond_pl gt Wenn irgendwann lt past_cond_pl gt dann lt PR3_for_pl gt Nachdem lt past_cond_pl gt lt PR3_for_pl gt lt PRs3_back_pl gt wenn irgendwann lt past_cond_pl gt DI DI lt PRs3_back_pl gt wenn vorher lt past_cond_pl gt 119 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Ebene 4 Definition der konjunktiven Verknupfungen _Sg Singular lt pres_cond_pl gt lt pres_cond_sg gt lt pres_cond_sg gt und lt pres_cond_pl gt lt past_cond_pl gt lt past_cond_sg gt lt past_cond_sg gt und lt past_
7. lt Nomen gt darf niemals lt Wert gt werden darf lt Nomen gt niemals lt Wert gt darf niemals lt Nomen_Wert_Paar gt werden werden darf niemals lt Nomen gt lt Wert gt werden lt Nomen gt darf nicht irgendwann ox lt Nomen_Wert_Paar gt darf nicht lt Wert gt werden irgendwann werden lt Nomen gt darf niemals lt Wert gt lt Nomen_Wert_Paar gt darf niemals werden werden 137 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache A 6 Erzeugbare Beispielsatze auf verbaler Ebene An dieser Stelle soll noch einmal kurz der Sprachumfang der Sicherheitsfachsprache gezeigt werden Es werden bewusst nur Beispielsatze der Kategorie DEs1 einfache Forderung Zustand dargestellt um den Rahmen dieser Darstellung nicht zu spren gen Der Leser wird sich sicher vorstellen k nnen wie viele M glichkeiten der Bil dung korrekter S tze es gibt In Anhang A 3 wurden in der genannten Kategorie vier Musters tze gezeigt Durch Aufteilung des Nomen Wert Paares dargestellt durch B1 B2 F1 F2 in einzelne No men und Werte hier unspezifisch dargestellt als x1 x2 y1 sowie y2 und True und zus tzliche Umstellung der Wortreihenfolge lassen sich die nachfolgend ge zeigten verbalen Anforderungss tze erzeugen Wenn B1 ist und B2 ist dann muss gleichzeitig F1 sein und muss g
8. A ormale Spezifikation Modellierung des Automatisierungssystems Anlagen beschreibungssprache Modell der Modell des SPS SC Modell der rogramm mgebung Verkn pfung Zr Ar GG u A GA RG AG A GA GAR A RA GA RG Bibliothek Sicherheits fachsprache Petri Netz Generator Formelsatz Temporale Logik Systemmodell Petri Netz Fehler Inkonsistenzen Verifikationsverfahren Verifiziertes SPS Programm Abbildung 9 bersicht ber das Verifikationsverfahren Das SPS Programm wurde durch einen Automatisierungstechniker mit herk mmli chen Methoden entworfen und programmiert es wird dann auf der SPS ausgef hrt Die zu steuernde Anlage ist entweder direkt oder ber ein Bussystem mit der SPS verbunden Hierf r gibt es einen Beschaltungsplan der eine Auflistung der verwen deten Aktoren und Sensoren sowie spezifische Details der Signalparameter enth lt Dieser Beschaltungsplan ist die Grundlage f r die Verbindung der Aktoren und Sen soren mit den Ausgangs und Eingangsbaugruppen der SPS Gleichzeitig dient er auch als inhaltliche Schnittstelle zwischen dem SPS Programm und der Anlage da er auch eine Auflistung der Signale darstellt die im SPS Programm wieder zu benut zen sind Die Schaffung des Modells des Automatisierungssystems das als Basis f r den Verifizierungsvorgang dienen soll umfasst somit drei Komponenten 1 die zu steuernde Anlage mit ihren Se
9. Die inhaltlichen quivalenzen die bei komplexen sprachlichen Formulierungen nicht immer sofort zu erkennen sind lassen sich also auf temporallogischer Ebene ein deutig nachweisen 3 2 4 Darstellung der Anforderungskategorien in CTL Formeln Es folgt nun die ausf hrliche Darstellung der Umsetzung der einzelnen Anforde rungskategorien der Sicherheitsfachsprache die in Abschnitt 3 1 5 abgeleitet wur den in CTL Formeln Bevor dies geschehen kann m ssen jedoch noch innerhalb des Systemmodells Beobachtungsvariablen definiert werden um die zyklische Aus f hrung der einzelnen Abschnitte des SPS Zyklus Eing nge lesen Programm bear beiten Ausg nge schreiben beobachten zu k nnen vgl Abbildung 17 und Ab schnitt 2 3 2 Beobachtungsvariable Bedeutung rdy_in Einlesen der Eingangsvariablen ist abgeschlossen rdy_plc Bearbeitung des SPS Programms ist abgeschlossen rdy_out Ausgeben der Ausgangsvariablen ist abgeschlossen rdy_env Berechnung des Umgebungsmodells ist abgeschlossen Tabelle 8 Definition von Beobachtungsvariablen 54 Die Sicherheitsfachsprache JE rdy_in Anwenderprogramm bearbeiten JL rdy_ple 1 Ausgangsaboid ausgeben SPS Betriebs system rdy_out SL rdy_env Abbildung 17 Beobachtungsvariablen zur Identifikation des Systemzu
10. Zu den Bestandteilen eines Pflichtenheftes geh rt neben einer verbalen Kurzbe schreibung des Programms die Darstellung der verf gbaren Input Parameter Sen soren Bedienereingaben und die Beschreibung der notwendigen Output Parameter Aktoren Anzeigen Ausgaben usw Die Funktionsbeschreibung soll dabei allge meinverst ndlich aber auch bersichtlich sein Zu diesem Zweck haben sich in der Vergangenheit verschiedene grafische Darstellungsformen wie Funktionsdiagramme VDI3260 Funktionspl ne DIN 40719 6 und auch Petri Netze als praktikabel erwiesen Das Pflichtenheft umfasst prim r die gew nschten Funktionsanforderungen eines Systems d h die Funktionen die w hrend des normalen standardm igen Be triebs des Systems auftreten Betriebsfunktionen Dar ber hinaus z hlen zu den Funktionsanforderungen aber auch die Reaktionen des Programms auf ungew hnli che au erplanm ige Ereignisse wie St rungen oder Not Aus St rungsfunktio nen W hrend der Normalbetrieb eines Systems noch relativ einfach beschrieben werden kann m ssen f r die Beschreibung der Programmreaktionen auf anormale Ereignisse weitaus mehr globale Systemzusammenh nge betrachtet werden Be triebsfunktionen werden w hrend des Normalbetriebs st ndig durchlaufen St rungsfunktionen werden nur im Ausnahmefall aktiviert f r sie ist ein Test oder eine Pr fung in der realen Anlage meist nicht mehr m glich Eine gemeinsame Eigen schaft der Funkt
11. Verbote die lediglich einzelne Zust nde des Systems beschreiben die nie erreicht werden d rfen k nnen ebenfalls auf die gezeigte Satzstruktur berf hrt werden 3 1 2 Definition des G ltigkeitsbereichs einer Anforderung Es wurde bereits festgestellt dass es drei grunds tzliche Kategorien von Anforde rungen an ein Steuerungsprogramm gibt a Forderungen demands DE beschreiben notwendige und erforderliche Reaktionen des Steuerungsprogramms auf festgelegte Ereignisse b Verbote prohibitions PR beschreiben untersagte Reaktionen des Steuerungsprogramms unter bestimmten Umst nden c M glichkeiten possibilities PO beschreiben erlaubte Reaktionen des Steuerungsprogramms unter bestimmten Umst nden Eine Anforderung setzt sich aus einer Bedingung und einer Folgerung zusammen Betrachtet man eine Bedingung und eine Folgerung unter Ber cksichtigung des er zeugten System bzw Kontrollmodells so lassen sich innerhalb des Zustandraumes des Systems einzelne oder mehrere Zust nde identifizieren bei denen die Werte der betrachteten Variablen mit den in den Bedingungen und Folgerungen definierten Va riablenwerten bereinstimmen Man spricht dann davon dass diese Zust nde die jeweilige Bedingung bzw Folgerung erf llen Systemzust nde die eine Bedingung erf llen werden als Startzustand S be zeichnet Systemzust nde die eine Folgerung erf llen werden als Zielzustand Z be zeichnet Es wird ein Beobach
12. 1 Entwurf Konstruktion 2 Implementierung Integration a Abnahmetest Kundenwiitisch E Inbetriebnahme Planung Systemtest Verifikation 4 Realisierung Anforderung Spezifikation Pr fung des Integrationstest Pflichtenheftes Modularisierung Modulintegration Dekomposition Komposition Pr fung des Entwurfs Modultest Codierung der Module Abbildung 5 Das V Modell Entwicklung der Module Das V Modell ist im Besonderen f r die Bew ltigung gro er Projekte geeignet 1 4 2 Ma nahmen w hrend der Softwareentwicklung Ungeachtet der im vorherigen Abschnitt dargestellten M glichkeiten f r die Erh hung der Softwarequalit t durch vorbereitende und begleitende Ma nahmen gibt es na t rlich auch beim eigentlichen Vorgang der Softwareerstellung spezifische fehlerver meidende Ma nahmen Dabei bedient man sich beispielsweise hnlicher Ans tze wie bei der Hardwaregestaltung sicherheitskritischer Systeme D Hablawetz be schreibt in Habl98 die diversit re Programmierung eines Programms als eine L sung Hierbei wird durch unterschiedliche Programmierteams m glicherweise auch mit unterschiedlichen Programmiersprachen ein und dasselbe Problem gel st An schlie end l sst man die erstellten Programme parallel laufen und vergleicht die ge zeigten Reaktionen 1 4 2 1 Spezifikationsmethoden Bereits im Abschnitt 1 1 2 wurde deutlich gemacht dass die aktuell verwendeten Me thoden und Werkzeuge f r d
13. Nur solange lt pres_cond_pl gt lt DE3_for_pl gt lt DEe3_back_pl gt solange gleichzeitig lt pres_cond_pl gt A DEe4 gt Nur wenn irgendwann lt past_cond_pl gt dann lt DE3_for_pl gt bevor lt pres_cond_pl gt Nur nachdem lt past_cond_pl gt lt DE3_for_pl gt bevor lt pres_cond_pl gt DI 118 Anhang A DEe5 gt lt POel gt lt POe3 gt lt POe4 gt lt POe5 gt lt PRsl gt lt PRs3 gt lt PRs4 gt lt PRs5 gt Nur wenn irgendwann lt past_cond_pl gt dann lt DE3_for_pl gt Nur nachdem lt past_cond_pl gt lt DE3_for_pl gt lt DEe3_back_pl gt wenn irgendwann lt past_cond_pl gt DI A DEe3_back_pl gt wenn vorher lt past_cond_pl gt DI Nur wenn lt pres_cond_pl gt dann lt POl_for_pl gt lt POel_back_pl gt wenn gleichzeitig lt pres_cond_pl gt DI Nur solange lt pres_cond_pl gt lt PO3_for_pl gt lt POe3_back_pl gt solange gleichzeitig lt pres_cond_pl gt DI Nur wenn irgendwann lt past_cond_pl gt dann lt PO3_for_pl gt bis lt pres_cond_pl gt Nur nachdem lt past_cond_pl gt dann lt PO3_for_pl gt bis lt pres_cond_pl gt
14. Umsetzung Nomen und Werte werden umgestellt und zusammengefasst lt Nomen gt lt Wert gt ist gt lt Nomen_Wert_Paar gt ist lt Nomen gt ist lt Wert gt lt Nomen gt Mertz war gt lt Nomen_Wert_Paar gt war lt Nomen gt war lt Wert gt lt Nomen gt muss gleichzeitig lt Wert gt sein muss lt Nomen gt gleichzeitig muss gleichzeitig lt Nomen_Wert_Paar gt gt lt Wert gt sein sein muss gleichzeitig lt Nomen gt lt Wert gt sein lt Nomen gt muss gleichzeitig lt Wert gt bleiben muss lt Nomen gt gleichzeitig muss gleichzeitig lt Nomen_Wert_Paar gt gt Mertz bleiben bleiben muss gleichzeitig lt Nomen gt Mertz bleiben lt Nomen gt muss gleichzeitig lt Wert gt lt Nomen_Wert_Paar gt muss gleichzeitig sein sein lt Nomen gt muss gleichzeitig Si lt Nomen_Wert_Paar gt muss gleichzeitig Mertz bleiben bleiben lt Nomen gt muss nur lt Wert gt SE sein 2 lt Nomen_Wert_Paar gt muss nur sein SE lt Nomen gt muss nur lt Wert gt gt lt Nomen_Wert_Paar gt muss nur bleiben 134 Anhang bleiben lt Nomen gt muss unmittelbar Mertz werden DI muss lt Nomen gt unmit
15. es darf kein Z geben auBerhalb des BI es muss ein Z geben innerhalb des BI es muss ein Z geben auBerhalb des BI es muss ein Z geben innerhalb des BI es darf ein Z geben auBerhalb des BI es muss ein Z geben innerhalb des BI es darf kein Z geben auBerhalb des BI es darf ein Z geben innerhalb des BI es muss ein Z geben auBerhalb des BI es darf ein Z geben innerhalb des BI es darf ein Z geben auBerhalb des BI es darf ein Z geben innerhalb des BI es darf kein Z geben auBerhalb des BI es darf kein Z geben au erhalb des BI es darf kein Z geben auBerhalb des BI es darf kein Z geben Tabelle 3 Matrix aus Modalkategorie und abstraktem Beobachtungsintervall Zu erkennen sind neun Kombinationstypen von denen einige grau unterlegt jedoch nicht relevant bzw untereinander redundant sind 44 Die Sicherheitsfachsprache Bei den Kombinationen I V und IX ist die Existenz des Zielzustandes in der gewahl ten Modalkategorie unabh ngig vom Beobachtungsintervall Der Zielzustand ist also unabh ngig von einer aufgestellten Bedingung d h die Folgerung w rde im ge samten Zustandsraum des betrachteten Systems g ltig sein Die Kombinationen V und IX entfallen somit weil sie nicht dem vorgegebenen Aufbau einer Anforderung Bedingung und Folgerung entsprechen Andererseits k nnen sie im Weiteren auch auf andere Kombina
16. Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache AG rdy_plc amp Robot_done_unload amp Press_run_prepare A 7 2 7 Kommunikation mit dem Ablageband Das Ablageband dient dazu die Fertigteile die der Roboter auf des Ablageband ab gelegt hat zum Kran zu bef rdern Im Gegensatz zum Zuf hrband besteht der Transportvorgang auf dem Ablageband nur aus einer Phase f r die Entnahme des Teils vom Anlageband ist nur der Kran zust ndig Der Transport eines Teils ist also erst dann m glich wenn der Kran das vorherige Teil vom Ablageband genommen hat Au erdem wird f r die Steuerung des Ablagebands ein Signal ben tigt wann der Roboter ein Teil auf dem Ablageband abgelegt hat Erst dann kann der Transport beginnen Aus Effizienzgr nden kann jedoch eine Beladung des Ablagebands durch den Roboter auch bereits dann erfolgen wenn ein Teil am Bandende liegt der Kran es jedoch noch nicht entnom men hat Mit dem Transport wird dann erst begonnen wenn der Kran das Teil ent nommen hat Definition neuer Daten mit dem SFS Editor Es wird eine Meldung ber die Beladung des Ablagebands durch den Roboter be n tigt Es muss weiterhin eine Meldung dar ber geben wann der Kran ein Teil vom Ablageband genommen hat Es wird ein Startsignal zur Ausf hrung des Transports definiert Variablen zur Kommunikation mit dem Ablageband Technische Bezeichnung Variable Datentyp Kommen
17. H Balzert beschreibt in Balz96 die besondere Rolle des Systemanalytikers im Kon text moderner Softwareerstellung dieser muss sich aktiv um die Ermittlung der An forderungen k mmern Hierf r stehen ihm nur manchmal schriftlich formulierte Anfor derungen zur Verf gung die durch eigene Interviews und Befragungen erg nzt wer den m ssen In der Regel werden Produktanforderungen durch den Auftraggeber weder systematisch strukturiert noch vollst ndig festgelegt In den eventuell vorhan denen Dokumenten wird oft zwischen abstrakten Angaben und konkreten W nschen hin und hergesprungen Dies f hrt dazu dass die Gespr chspartner lange Zeit kein vollst ndiges Modell des zu entwickelnden Systems im Kopf haben 1 1 2 Die Softwarekrise in der Steuerungstechnik Ein wesentlicher Grund f r das fehlerhafte Verhalten von Software l sst sich also bereits in der Phase der Vorbereitung der Softwareerstellung finden einer mangel haften Spezifikation der Software Eine Ursache hierf r liegt wiederum darin dass in der ingenieurtechnischen Praxis die Anwendung formaler Methoden nicht in dem heute notwendigen Ma e erfolgt Diese Tatsache ist unter anderem historisch be gr ndet der Ausbildungsstand der involvierten Ingenieure und die f r die Software erstellung verwendeten Methoden haben nicht mit der rasanten Entwicklung der ver wendeten Hardware Schritt gehalten Mit der Entwicklung und Anwendung der Relais und Sch tztechnik bestand seit
18. lt Nomen gt muss nur sofort Mertz werden lt Nomen gt wird nur unmittelbar lt Wert gt lt Nomen gt wird nur sofort lt Wert gt lt Nomen gt muss irgendwann Mertz werden lt Nomen gt wird irgendwann lt Wert gt lt Nomen gt muss nur irgendwann lt Wert gt werden lt Nomen gt wird nur irgendwann lt Wert gt lt Nomen gt kann gleichzeitig lt Wert gt sein 133 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache lt Nomen gt lt Nomen gt lt Nomen gt lt Nomen gt lt Nomen gt lt Nomen gt lt Nomen gt lt Nomen gt lt Nomen gt lt Nomen gt lt Nomen gt lt Nomen gt lt Nomen gt werden darf gleichzeitig lt Wert gt sein kann nur lt Wert gt sein darf nur lt Wert gt sein kann irgendwann lt Wert gt werden darf irgendwann lt Wert gt werden kann nur irgendwann lt Wert gt werden darf nur irgendwann lt Wert gt werden darf nicht gleichzeitig lt Wert gt sein darf niemals gleichzeitig lt Wert gt sein darf nur nicht gleichzeitig lt Wert gt sein darf nicht irgendwann lt Wert gt werden darf niemals lt Wert gt werden darf nur nicht irgendwann lt Wert gt lt Nomen gt darf nur niemals lt Wert gt werden
19. werden muss lt Nomen gt sofort lt Wert gt werden muss sofort lt Nomen gt lt Wert gt werden lt Nomen gt wird unmittelbar lt Wert gt wird lt Nomen gt unmittelbar lt Wert gt wird unmittelbar lt Nomen gt lt Wert gt lt Nomen gt wird sofort lt Wert gt wird lt Nomen gt sofort lt Wert gt wird sofort lt Nomen gt lt Wert gt lt Nomen gt muss irgendwann lt Wert gt werden muss lt Nomen gt irgendwann lt Wert gt werden muss irgendwann lt Nomen gt lt Wert gt werden lt Nomen gt wird irgendwann lt Wert gt 132 Anhang wird lt Nomen gt irgendwann lt Wert gt wird irgendwann lt Nomen gt lt Wert gt lt Nomen gt kann gleichzeitig lt Wert gt sein kann lt Nomen gt gleichzeitig lt Wert gt sein kann gleichzeitig lt Nomen gt lt Wert gt sein lt Nomen gt darf gleichzeitig lt Wert gt sein darf lt Nomen gt gleichzeitig lt wert gt sein darf gleichzeitig lt Nomen gt lt Wert gt sein lt Nomen gt kann irgendwann lt Wert gt werden kann lt Nomen gt irgendwann lt Wert gt werden kann irgendwann lt Nomen gt lt Wert gt werden lt Nomen gt darfirgendwann lt Wert gt werden darf lt Nomen gt ir
20. 87 5 3 3 Ger teebene 3 Der Kran 90 5 3 4 Definition weiterer Eigenschaften cccccccceeeeeeeeeeeeeeneeeeeeeeeeeeeeeeenaeees 94 5 4 Kommentare zur Fallstudie uuuunnnnssnnannnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 98 6 Zusammenfassung und Ausblick uuesssssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 99 T era nie 102 A 1 Begriffsbestimmungen uuusssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 113 VIII Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache A 2 Formale Definition der Sicherheitsfachsprache cccccesssssseeeeeeeteees 117 A 3 Beispiele f r erzeugbare S tze uunsssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 123 A 4 Struktur der Datei zur Definition und Zuordnung der Nomen und Werte EE 129 A 5 Formale Definition des PreLexelrs ecccccceeseeeeeeeeeeeeeeeeeeseeeeeneeeeeeeees 131 A 6 Erzeugbare Beispiels tze auf verbaler Ebene nuuuuunnnnnnnnnnnnnnnnnnnnn 138 A 7 Fallstudie Erweiterte Produktionszelle uu uu20000000000n00000n0n00nnnnnnnnn 140 A 7 1 Spezifikation der Ger teebene 1 Auftragsverwaltung 140 A 7 2 Ger teebene 2 Zentrale Steuerung der Produktionszelle 146 A 7 2 1 Kommunikation mit MMI und bergeordneter Ebene 146 A 7 2 2 Kommunikation mit dem Kran I 44444444400nnnn nennen 156 A 7 2 3 Komm
21. Al rdy_plc U rdy_plc amp Arm2_backward amp Robot_state 39 amp Robot_done_dbelt amp Robot_left gt gt gt Satz 144 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 39 ist und der Roboter ist mit dem Arm I vor der Presse dann muss die Drehung des Roboters nach links unmittelbar 215 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 40 gesetzt werden und die Bereitschaftsmeldung Roboter wartet vor Presse muss unmittelbar gesetzt werden AG rdy_in amp Robot_state 39 amp Robot_angle 90 gt Al rdy_plc U rdy_plc amp Robot_left amp Robot_state 40 amp Robot_wait_mix gt gt gt Satz 145 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 40 ist und das Startsignal Roboter weiter im Mix ist gesetzt dann muss das Startsignal Roboter weiter im Mix unmittelbar zur ckgesetzt werden und die Zustandsvariable des Roboters muss unmittelbar auf 41 gesetzt werden und das Ausfahren des Roboterarms I muss unmittelbar gestartet werden m AG rdy_in amp Robot_state 40 amp Robot_run_cont gt Al rdy_plc U rdy_plc amp Robot_run_cont amp Robot_state 41 amp Arml_forward gt gt gt Satz 146 lt lt lt einfache Forderung direkt Wenn die Zustandsvariab
22. Mahr B Fundamentals of algebraic Specification Springer Verlag Berlin Heidelberg New York Tokyo 1985 Emerson E A Temporal and Modal Logic in J v Leeuwen ed Handbook of theoretical computer science vol B Elsivier Science Publishers B V Amsterdam 1990 Feindt E G Entwurf und Simulation industrieller Steuerungen f r den PC und die SPS Oldenbourg Verlag Wien 1997 Fisher M Owens R Executable Modal and Temporal Logics Springer Verlag IJCAI 93 Workshop Chambery France 1993 Fleisch W Validierung von Entwurfsspezifikationen komponen tenbasierter Software fur verteilte eingebettete Automatisierungs systeme mittels Simulation 4 Berichtskolloquium des GK PVS Universitat Stuttgart 13 Juni 1997 Fliegner J Grammatik verstehen und gebrauchen Scriptor Verlag Frankfurt am Main 1986 Frey G Litz L Entwurf und formale Verifikation von Steuerun gen mit interpretierten Petri Netzen GMA Kongress Ludwigsburg 18 19 06 1998 VDI Berichte Nr 1397 1998 Frey G Litz L Formal methods in PLC programming IEEE Conference System Man and Cybernetics SMC 2000 Nashville TN USA Oct 2000 Frappier M Habrias H Eds Software Specification Methods Springer Verlag London Berlin Heidelberg 2001 Futschek G Programmentwicklung und Verifikation Springer Verlag Wien New York 1989 105 Formale Spezifikation reaktiver Systeme m
23. SE OS E fab sie alt Set ne SPS Zyklen n erweiterte M glichkeit Zustand es gir agi ee SPS Zyklen n Abbildung 12 Timingdiagramme Zustand einfache Forderung direkt i F er es a R SPS Zyklen n erweiterte Forderung direkt B F SPS Zyklen n nicht definiert nicht definiert Abbildung 13 Timingdiagramme Direkt nur Forderungen sind definiert Die Sicherheitsfachsprache 49 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache einfache Forderung selbstbegrenzt SPS Zyklen n erweiterte Forderung selbstbegrenzt SPS Zyklen n einfaches Verbot selbstbegrenzt SPS Zyklen n erweiterte M glichkeit selbstbegrenzt SPS Zyklen n Abbildung 14 Timingdiagramme Selbstbegrenzt einfache Forderung fremdbegrenzt SPS Zyklen n erweiterte Forderung fremdbegrenzt SPS Zyklen n gt einfaches Verbot fremdbegrenzt SPS Zyklen n erweiterte M glichkeit fremdbegrenzt ISS SPS Zyklen Abbildung 15 Timingdiagramme Fremdbegrenzt 50 Die Sicherheitsfachsprache
24. Transparente Spezifikation komplexer Maschinen und Anlagen Grundlage einer systematischen Entwicklung von SPS Software Anwenderforum Fortschrittliche Automatisierung mit SPS 4 5 12 1991 Bad Soden VDI Berichte 914 1991 Kohring A Systematisches Projektieren und Testen von Steue rungssoftware f r Werkzeugmaschinen Dissertation an der RWTH Aachen Verlag Shaker Band 13 93 1993 107 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache K st00 K ster L Meyer M Thomsen T Automatische Code Generie rung f r Steuerger te Elektronik 18 2000 Koto97 Kotonya G Sommerville l Requirements engineering Proc esses and techniques Wiley amp Sons Ltd Chichester England 1997 Kowa96 Kowalewski S Verifikation von Steuerungen mit Hilfe von Bedin gung Ereignis Systemen VD VDE GMA Kongre Me und Au tomatisierungstechnik Baden Baden 1996 VDI Bericht Nr 1282 1996 Kowa98 Kowalewski S Preu ig J Stursberg O Treseler H Blockori entierte Modellierung und formale Verifikation von diskret gesteu erten kontinuierlichen Prozessen GMA Kongress Ludwigsburg 18 19 06 1998 VDI Berichte Nr 1397 1998 Kowa01 Kowalewski S Herrmann P Engell S Huuck R Krumm H Lakhnech Y Lukoschus B Treseler H Approaches to the formal verification of hybrid systems Automatisierungstechnik 49 2001 at 2 2001 Krau00 Kr
25. gt Al rdy_plc U rdy_plc amp Press_rdy_give amp Dbelt_rdy_take amp Robot_run_unload Informelle Spezifikation weiterer Eigenschaften Es darf keine Beladung erfolgen wenn die Presse nicht zur Beladung bereit ist Es darf kein Entladen erfolgen wenn die Presse nicht zur bergabe bereit ist Es darf keine Beladung erfolgen wenn der Hubdrehtisch nicht zur bergabe bereit ist Es darf kein Entladen erfolgen wenn das Ablageband nicht zur bernahme bereit ist Der Mixbetrieb darf nicht gestartet werden wenn der Hubdrehtisch nicht zur ber gabe bereit ist Der Mixbetrieb darf nicht gestartet werden wenn die Presse nicht zur bergabe bereit ist Der Mixbetrieb darf nicht gestartet werden wenn das Ablageband nicht zur ber name bereit ist Der Mixbetrieb darf nicht fortgesetzt werden wenn die Presse nicht f r eine Bela dung bereit ist 170 Anhang Formale Spezifikation mit dem SFS Editor gt gt gt Satz 43 lt lt lt erweiterte M glichkeit Zustand das Startsignal Roboter bel dt Presse darf nur gesetzt sein wenn gleichzeitig die Bereitschaftsmeldung Presse ist f r Beladung bereit gesetzt ist AG rdy_plc amp Press_ready_take amp Robot_run_load gt gt gt Satz 44 lt lt lt erweiterte M glichkeit Zustand das Startsignal Roboter entl dt Presse darf nur gesetzt sein wenn gleichzeitig die Bereitscha
26. men ausgedr ckten Systemaspekte Eindeutigkeit durch pr zise Semantik der benutzten Notationen Konsistenzpr fung ber mehrere Ebenen durch berdeckung mehrerer Ebe nen durch die Notation Lewe97 C Aguilera et al fassen diese Anforderungen an die Spezifikation folgenderma en zusammen sie muss sowohl f r den Kunden als auch f r den Entwickler verst ndlich sein sie muss in allen Bereichen konsistent sein jede einzelne Anforderung muss vollst ndig sein jede Anforderung muss nachweisbar und auffindbar sein die Implementierung muss testbar sein es soll eine maximale Designfreiheit bei gleichzeitig minimaler Detaillierung bestehen Agui90 27 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache In Alag98 sind weitere grundlegende Eigenschaften einer Spezifikation zusammen gefasst worden es muss m glich sein das beobachtbare Verhalten zu definieren das Interface einer Softwarekomponente muss exakt und einfach sein das Verhalten des Ganzen muss ausdr ckbar sein in Form des Verhaltens der Teile bzw es muss m glich sein Spezifikationen zusammenzusetzen es muss m glich sein ein Programm aus einer detaillierten Designspezifika tion zu entwickeln die Designspezifikation muss eine Beschreibung des gesamten Verhaltens enthalten ausgedr ckt in einer Verhaltensspezifikation Als ein besonders wichtiges Kriterium wird in Kohr91 und Kohr93 eine abteilungs bergreifende Spezifika
27. wenn der Roboter mit dem Arm 2 vor der Presse ist und der Roboterarm 2 ist in der Presse AG rdy_plc amp Robot_angle 0 amp Arm2_ext 0 79 amp Press_upward 97 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache 5 4 Kommentare zur Fallstudie Die dargestellten Ausf hrungen zur Fallstudie zeigen dass es mit der Sicherheits fachsprache m glich ist s mtliche Anforderungen an ein Steuerungsprogramm na t rlichsprachlich und dennoch formal darzustellen Hierbei besteht dar ber hinaus die M glichkeit eine Vielzahl unterschiedlicher Formulierungen f r dieselbe Problem stellung zu verwenden Die gewollte Redundanz der Formulierungen innerhalb einer Kategorie dient dazu dem potentiellen Anwender eine Reihe von sprachlichen Vari anten anzubieten aus denen er sich diejenige ausw hlen kann die ihm am Besten gef llt Die erstellten formalen Anforderungen k nnen nun f r eine Synthese des ge w nschten Programms oder f r eine Verifikation durch Model Checking herangezo gen werden Bei letzterem Verfahren erh lt der Nutzer zu jeder Analyseanfrage eine Antwort ob diese spezielle Anforderung erf llt wird oder nicht Zus tzlich kann je nach Typ der Analyseanfrage ein Zeugniszustand bzw ein Gegenbeispiel aufge zeigt werden Meist wird durch den Model Checker sogar der komplette Pfad bis zu diesem relevanten Zustand dargestellt Der Anwender ist bei der Verifikation oft nega
28. zur bergabe Startsignal Rohteil Fbelt_run_table Bool Zuf hrband soll Teil zum Hubdrehtisch auf Tisch transportie transportieren ren bergabemeldung Fbelt_done_give Bool Zuf hrband hat Teil des Zuf hrbands auf Tisch transportiert Definition neuer Daten mit dem SFS Editor Sensor des Zuf hrbands Technische Bezeichnung SPS Variable Datentyp Kommentar Lichtschranke am Zuf hrband LB_at_fbelt Bool TRUE Lichtschranke frei Tabelle 28 Datenebene 4 Sensor des Zuf hrbands 12 BOOL VAR LB_at_fbelt die Lichtschranke am Ende des Zuf hrbands FALSE_I unterbrochen TRUE_I frei 193 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Aktor des Zuf hrbands Technische Bezeichnung SPS Variable Datentyp Kommentar Antriebsmotor Zuf hrband FBelt_start Bool TRUE Band l uft Tabelle 29 Datenebene 4 Aktor des Zuf hrbands TRUE_I FALSE_I TRUE_O FALSE_O 73 BOOL VAR FBelt_start aktiv nicht aktiv gestartet gestoppt 1 der Antrieb des Zuf hrbands Informelle Spezifikation Der Steuerung des Zuf hrbands verbleibt solange in Ruhe bis durch die Zellen steuerung entweder das Startsignal zum Transport eines Rohteils zum Bandende oder zur Ubergabe auf den Hubdrehtisch erfolgt Danach wird die geforderte Trans portroutine bearbeitet Es sind als
29. 1938 vergleiche Rein96 zum ersten Mal die M glichkeit komplexe boolesche Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Funktionen fur mathematische Berechnungen 1941 Zuse Z3 und zur Steuerung von Maschinen heranzuziehen Diese wurden durch die geeignete Verschaltung der Offner und SchlieBer Kontakte von Relais verwirklicht und spater durch mechani sche Zeit und Z hlglieder erweitert Die Programmierung erfolgte hierbei durch die Verdrahtung eine Ver nderung der Funktion der Steuerung war also nur mit hohem Aufwand m glich Da der r umliche technische und auch finanzielle Aufwand dieser elektrischen Steuerungen recht hoch war wurden auch nur relativ kleine und abge schlossene Steuerungsl sungen verwirklicht Wegen des hohen Aufwandes bei der Realisierung der gew nschten Funktionalit t und wegen deren geringen Komplexit t konnte man jedoch im Allgemeinen gut durchdachte und funktionssichere L sungen erhalten Mit der Einf hrung der kontaktlosen und nahezu verschlei freien Halbleitertechnik nderte sich das Bild schlagartig Man war in der Lage weitaus mehr Funktionen zu einem g nstigen Preis zu realisieren Jedoch ging dies mit einer weitaus schwieri geren Anderbarkeit bis hin zur Neuerstellung von Leiterkarten und einem h heren Schulungsaufwand sowie einer komplizierten Fehlersuche einher Die Programmie rung erfolgte weiterhin durch die Verschaltung von Bauelementen deren Funktio
30. AG rdy_in amp Table_state2 22 amp Table_statel 22 gt Al rdy_plc U rdy_plc amp Table_state2 0 amp Table_statel 0 Informelle Spezifikation weiterer Eigenschaften Es muss eine Bewegungsbegrenzung bez glich der Tischh he erfolgen Formale Spezifikation mit dem SFS Editor gt gt gt Satz 115 lt lt lt einfaches Verbot Zustand Wenn der Hubdrehtisch oben ist dann darf das Anheben des Hubdrehtischs nicht gleichzeitig gestartet sein AG rdy_plc amp Table_top amp Table_upward gt gt gt Satz 116 lt lt lt einfaches Verbot Zustand Wenn der Hubdrehtisch unten ist dann darf das Absenken des Hubdrehtischs nicht gleichzeitig gestartet sein AG rdy_plc amp Table_bottom amp Table_downward 203 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache A 7 7 Ger teebene 3 Steuerung des Roboters Die Steuerung des Roboters erh lt von der bergeordneten Zellensteuerung Start signale zur Ausf hrung bestimmter Aktionen Durch verschiedene Sensoren und Aktoren ist die Steuerung des Zuf hrbands mit den Maschinenelementen verbunden Gegebene Daten Technische Bezeichnung Variable Datentyp Kommentar Fertigmeldung Roboter hat Robot_done_take_table Bool Teil vom Tisch genommen Startsignal Presse be Robot_run_load Bool laden Startsi
31. Ausgangspuffer a Kran Roboter Presse A Eingangspuffer gt gt Zuf hrf rderband Hubdrehtisch Abbildung 28 Materialfluss in der Produktionszelle Diese Beschreibung stellt einen vollst ndigen und sicheren jedoch nicht unbedingt effizienten Bearbeitungsvorgang dar Im Anhang sind mehrere M glichkeiten darge stellt um den Durchsatz von Werkst cken zu erh hen Die hierzu nutzbaren Ans tze zielen auf eine Verfeinerung der einzelnen Transportvorg nge sowie die Koordinie rung einzelner Transport und Ubergabevorgange ab Aufgabe Die zentrale Steuerung der Produktionszelle 1 muss zwei Kommunikationsaufgaben erf llen Kommunikation mit der bergeordneten Auftragsverwaltung Bereitstellung der Bereitschafts bzw Fertigmeldung Kommunikation mit den untergeordneten Steuerungen der Einzelkomponen ten Dar ber hinaus erfolgt die Ankopplung der Bedien und Anzeigeelemente der Pro duktionszelle 1 direkt an die zentrale Steuerung Gegebene Daten bereits definierte Bereitschafts und Fertigmeldung der Produktionszelle siehe Tabelle 11 und Tabelle 12 Anhang Seite 143 Sensor und Aktorsignale der Bedien bzw Anzeigeelemente siehe Tabelle 14 Anhang Seite 146 und Tabelle 15 Anhang Seite 147 Die nachfolgenden Ausf hrungen beziehen sich ausschlie lich auf die Kommunika tion der zentralen Steuerung mit der Steuerung des Krans die Kommun
32. Bereitschafts und Fertigmeldung des Transportsystems GENEE ed ENEE EEN SEN ENEE 144 Tabelle 14 Datenebene 3 Sensoren des HMI Bedienelemente nnnne0000nnn 146 Tabelle 15 Datenebene 3 Aktoren des HMI Anzegen seen 147 Tabelle 16 Datenebene 3 Interne Variablen des HM 148 Tabelle 17 Datenebene 3 Interne Variablen des HM 149 Tabelle 18 Datenebene 3 Interne Variablen des HM 150 Tabelle 19 Datenebene 3 Variablen zur Kommunikation mit dem Zuf hrband 159 Tabelle 20 Datenebene 3 Variablen zur Kommunikation mit dem Hubdrehtisch 162 Tabelle 21 Datenebene 3 Variablen zur Kommunikation mit dem Roboter 167 Tabelle 22 Datenebene 3 Variablen zur Kommunikation mit der Presse 172 Tabelle 23 Datenebene 3 Variablen zur Kommunikation mit dem Ablageband 174 Tabelle 24 Datenebene 3 Variablen zur Kommunikation mit dem Kran 176 Tabelle 25 Datenebene 4 Sensoren des krans nnnnnnnnnnnnnrnnnrrrrrrrnnrrrnnnnnnn nna 181 Tabelle 26 Datenebene 4 Aktoren des KranS nnnnnnnnnnnnnnnnnnnrrnnrnrrnnrnnnnnn nenna 181 Tabelle 27 Datenebene 4 Interne Variable der Steuerung des Krans 183 Tabelle 28 Datenebene 4 Sensor des Zuf hrbandS nnnnnnnnnrnrrrrrrrrrrrnrrrrenn 193 Tabelle 29 Datenebene 4 Aktor des Zuf hrbandS AAA 194 Tabelle 30 Datenebene 4 Interne Variable der Steuerung des Zuf hrbands 194 Tabelle 31 Dateneben
33. Eingangspuffer gangspuffer Schalter Kranposition Crane_at_drain Bool TRUE Kran ist am Aus Ausgangspuffer gangspuffer Wegmesssystem Crane_height Integer 0 00 Greifer ist oben Greiferh he 0 35 Greifer ist auf Ausgangspuffer 0 66 Greifer auf Abl band 0 85 Greifer ist auf Ein gangspuffer 180 Anhang 0 94 Greifer auf Zuf band 1 00 Greifer ist unten Tabelle 25 Datenebene 4 Sensoren des Krans 61 BOOL VAR Crane_at_dbelt der Kran TRUE_I am Ablageband FALSE_I nicht am Ablageband 62 BOOL VAR Crane_at_fbelt der Kran TRUE_I am Zuf hrband FALSE I nicht am Zuf hrband 63 BOOL VAR_INPUT Crane_at_source der Kran TRUE_I am Eingangspuffer FALSE_I nicht am Eingangspuffer 64 BOOL VAR_INPUT Crane_at_drain der Kran TRUE_I am Ausgangspuffer FALSE_I nicht am Ausgangspuffer 65 INT VAR Crane_height der Greifer des Krans DU oben 0 35_I auf Ausgangspuffer 0 66_I auf dem Ablageband 0 85_I auf Eingangspuffer 0 94_I auf dem Zuf hrband 1 0_I unten Aktoren des Krans Technische SPS Variable Datentyp Kommentar Bezeichnung Motor Kranposition Crane_to_fbelt Bool TRUE Kran f hrt zum Zuf L R band Crane_to_dbelt Bool TRUE Kran f hrt zum Abl band Motor Greiferh he Cr
34. Hierbei geht es darum Fehler und Unzul nglichkeiten der Programme vollst ndig und sicher zu erkennen und geeignete Schritte wie Korrekturen oder eine Neucodierung einzuleiten Je nach Wirksamkeit und Abdeckungsgrad unterscheidet man testende und verifizie rende Verfahren 1 4 3 1 Test Der einfachste Fall der berpr fung der Korrektheit eines Programms ist der Test Hierbei unterscheidet man statische Tests wie Quelltextanalyse Inspektion und Walkthrough bei denen der Code visuell von einer Person untersucht und in Ge danken abgearbeitet wird Bei dynamischen Tests wird das Programm dagegen tat s chlich ausgef hrt bzw simuliert Man unterscheidet hierbei nochmals in den funk tionalen Black box Test und den strukturorientierten White box Test In Mewe95 wird eine Testumgebung vorgestellt mit der es m glich ist Software bereits in fr hen Entwicklungsstufen pr fen zu k nnen Der reale Code wird dabei in eine Umgebung eingebettet die auf die Ergebnisse des Programms reagiert und aufgrund bestimmter Algorithmen neue Eingangswerte f r den zu testenden Code generiert Diese Systeme sind heute weit verbreitet und auch unter der Bezeichnung Software in the loop SIL bekannt Als eine M glichkeit zur Unterst tzung der Abnahme von Softwareprodukten enth lt die DIN 66285 siehe Lind93 eine detaillierte Beschreibung der Pr fbedingungen f r Software Der Autor f hrt dabei die Umsetzung der Vorgaben der DIN 66285
35. Kategorie POe4 erweiterte M glichkeit fremdbegrenzt Nur wenn irgendwann B1 war und B2 war dann kann irgendwann F1 werden und kann irgendwann F2 werden bis B3 ist und B4 ist Nur wenn irgendwann B1 war und B2 war dann darf irgendwann F1 werden und darf irgendwann F2 werden bis B3 ist und B4 ist Nur nachdem B1 war und B2 war dann kann irgendwann F1 werden und kann irgendwann F2 werden bis B3 ist und B4 ist Nur nachdem B1 war und B2 war dann darf irgendwann F1 werden und darf irgendwann F2 werden bis B3 ist und B4 ist Kategorie POe5 erweiterte M glichkeit unbegrenzt Nur wenn irgendwann B1 war und B2 war dann kann irgendwann F1 werden und kann irgendwann F2 werden Nur wenn irgendwann B1 war und B2 war dann darf irgendwann F1 werden und darf irgendwann F2 werden 126 Anhang Nur nachdem B1 war und B2 war kann irgendwann F1 werden und kann irgendwann F2 werden Nur nachdem B1 war und B2 war darf irgendwann F1 werden und darf irgendwann F2 werden F1 kann nur irgendwann werden und F2 kann nur irgendwann werden wenn irgendwann B1 war und B2 war F1 darf nur irgendwann werden und F2 darf nur irgendwann werden wenn irgendwann B1 war und B2 war F1 kann nur irgendwann werden und F2 kann nur irgendwann werden wenn vorher B1 war und B2 war F1 darf nur irgendwann werden und F2 darf nur irgendwann werden wenn vorher B1 war und B2 war Kategorie PRs1 einfaches Verbot Zus
36. Not Aus wurde bet tigt Tabelle 15 Datenebene 3 Aktoren des HMI Anzeigen 18 INT Count_in VAR_OU auf 0 gese um 1 erh ht PP UL der Eingangsz hler EZE 19 INT Count_out VAR_OU TPUT der Ausgangszahler 1 0 um 1 erh ht O_O auf 0 gesetzt 20 BOOL VAR_OUTPUT LED_cell_rdy die Anzeige Zell TRUE_I aktiv FALSE_I nicht aktiv TRUE_O aktiviert FALSE_O deaktiviert 21 BOOL VAR_OUTPUT LED_cell_run die Anzeige TRUE_I aktiv FALSE_I nicht aktiv TRUE_O aktiviert FALSE_O deaktiviert 322 BOOL VAR_OUTPUT LED_em_stopp die Anzeige Not Aus TRUE_I aktiv FALSE_I nicht aktiv bereit Automatik l uft 147 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache TRUE_O aktiviert FALSE_O deaktiviert Informelle Spezifikation Jede einzelne Produktionszelle muss die Bereitschafts sowie eine Fertigmeldung generieren die der bergeordneten Auftragsverwaltung anzeigen soll dass die Pro duktionszelle zur Ausf hrung eines neuen Auftrags bereit ist bzw dass ein zuvor ge stellter Auftrag fertig bearbeit wurde Definition neuer Daten mit dem SFS Editor Um die notwendigen Meldungen zu generieren m ssen innerhalb der zentralen Steuerung der Produktionszelle eindeutige Zust nde unterschieden werden k nnen in
37. Simulation R net requirements network grafische Darstellungsform Das Einsatzgebiet von SREM liegt bei der Entwicklung von komplexen Realtime Systeme mit Parallelverarbeitung DGQ92 Zur Unterst tzung gro er Projekte wurden strukturierte Methoden entwickelt In die sem Zusammenhang sollen SA Structured Analysis SADT Structures Analysis and Design Technique und SA RT erw hnt werden Reck91 Part98 In den letz 17 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache ten Jahren wurden neue objektorientierte Methoden entwickelt OOA OMT und die UML Unified modeling language Die UML Oest98 Booc99 Frap01 hat sich in der j ngsten Vergangenheit zu einer Standard Spezifikationssprache f r objektorientierte Software vor allem im Be reich der Informationstechnik herausgebildet Sie ist sowohl eine Visualisierungs Dokumentations und Konstruktionssprache und besteht aus verschiedenen Dia grammen mit verschiedenen grafischen Elementen die je nach spezieller Aufgabe eingesetzt werden k nnen Bei vielen Tools die UML benutzen ist eine automati sierte Ubersetzung der Spezifikation in C oder Java m glich Braa01 und West01 stellen dar ber hinaus mit ODEMA eine Methode zur Softwarespezifikation fur die Produktionsautomatisierung vor Die UML dient dabei als Notationswerkzeug die einzelnen Diagrammtypen werden in ihrer Semantik soweit prazisiert dass sie den Aktivit ten eines Entwi
38. Teile vom Typ xy gefertigt werden Definition neuer Daten mit dem SFS Editor Es werden die folgenden Variablen definiert order_number Auftragsnummer order_quantity Anzahl der zu fertigenden Teile order_work Art der zu fertigenden Teile order_status Bearbeitungsstatus des Auftrags Der detaillierte Aufbau eines Produktionsauftrages sowie die Verbalphrasen der No men und Werte k nnen der Tabelle 9 Anhang Seite 140 entnommen werden 83 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Bearbeitung der Produktionsauftrage Aufgabe Eingehende Produktionsauftr ge m ssen schnellstm glich und vollst ndig bearbeitet werden Innerhalb des Produktionsauftrages nimmt die soeben definierte Variable order_status eine herausragende Rolle ein Der aktuelle Wert muss durch die Auf tragsverwaltung durch geeignete Kommunikation mit den anderen Elementen der Produktionsanlage bestimmt werden Informelle Spezifikation Produktionsauftr ge die den Status Neu Rohteile liefern usw haben m ssen irgendwann den Status Fertig haben Formale Spezifikation mit dem SFS Editor gt gt gt Satz 1 lt lt lt einfache Forderung unbegrenzt Wenn irgendwann der aktuelle Stand der Auftragsbearbeitung Neu war dann muss der aktuelle Stand der Auftragsbearbeitung irgendwann auf Fertig gesetzt werden AG rdy_in amp order_status 1 gt AF rdy_plc amp orde
39. amp Robot_angle 70 gt Al rdy_plc U rdy_plc amp Robot_left amp Robot_state 24 amp Arm2_forward 212 Anhang gt gt gt Satz 132 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 24 ist und der Roboterarm 2 ist am Ablageband dann muss das Ausfahren des Roboterarms 2 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 25 gesetzt werden und der Magnetgreifer des Roboterarms 2 muss unmittelbar deaktiviert werden und das Einziehen des Roboterarms 2 muss unmittelbar gestartet werden AG rdy_in amp Robot_state 24 amp Arm2_ext 0 57 gt Al rdy_plc U rdy_plc amp Arm2_forward amp Robot_state 25 amp Ami mag on amp Arm2_backward gt gt gt Satz 133 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 25 ist und der Roboterarm 2 ist hinten dann muss das Einziehen des Roboterarms 2 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 26 gesetzt werden und die Fertigmeldung Roboter hat Teil auf Ablageband gelegt muss unmittelbar gesetzt werden AG rdy_in amp Robot_state 25 amp Arm2_ext 0 0 gt Al rdy_plc U rdy_plc amp Arm2_backward amp Robot_state 26 amp Robot_done_dbelt gt gt gt Satz 134 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable de
40. auf 34 gesetzt 35_0 auf 35 gesetzt 36 0 auf 36 gesetzt 3120 auf 37 gesetzt 38 0 auf 38 gesetzt 39 0 auf 39 gesetzt 40_0 auf 40 gesetzt 41_0 auf 41 gesetzt 42_0 auf 42 gesetzt 43_0 auf 43 gesetzt 208 Anhang oC robot_run_load Irobot_run_load robot_right robot_angle 50 robot_right arm1_forward arm1_ext 0 52 nt T larm1_forward 12 armi_mag_on arm1_backward arm1_ext 0 0 larm1_backward 13 robot_left robot_angle 90 robot_done_take_table 23 robot_run_unload robot_run_unload 2 robot_right robot_angle 0 robot_right arm2_forward arm2_ext 0 79 larm2_forward 22 arm2_mag_on arm2_backward 21C arm2_ext 0 0 arm2_backward robot_done_unload robot_left robot_angle 70 robot_run_mix robot_run_mix robot_right robot_angle 50 robot_right arm1_forward arm1_ext 0 52 larm1_forward arm1_mag_on arm1_backward arm1_ext 0 0 larm1_backward 33 robot_done_take_talble robot_left 32 robot_angle 0 Irobot_left arm2_forward arm2_ext 0 57 larm2_forward larm2_mag_on arm2_backward arm2_ext 0 0 larm2_backward robot_done_dbelt robot_left robot_angle 90 Irobot_left robot_wait_mix robot_run_cont robot_left robot_right Irobot_left Irobot_run_cont 14 arm1_forward 24 arm2_forward 34 arm2_forward 41 arm1_forward arm1_ext 0 65 arm2_ext 0 57 arm2_ext 0 79 arm ext 0 65 larm1
41. backward R ckw rtskonstruktion A Bel Ss Wenn lt pres_cond_pl gt dann lt DE1_for_pl gt lt DEsl_back_pl gt wenn lt pres_cond_pl gt DI A DES2 gt Wenn lt pres_cond_pl gt dann lt DE2_for_pl gt lt DEs2_back_pl gt wenn lt pres_cond_pl gt DI lt DESs3 gt Solange lt pres_cond_pl gt lt DE3_for_pl gt lt DEs3_back_pl gt solange lt pres_cond_pl gt A DES4 gt Wenn irgendwann lt past_cond_pl gt dann DE3_for_pl gt bevor lt pres_cond_pl gt Nachdem lt past_cond_pl gt lt DE3_for_pl gt bevor lt pres_cond_pl gt A DI rei A DEsS5 gt Wenn irgendwann lt DES For pl za Nachdem lt past_cond_pl gt lt DE3_for_pl gt lt DEs3_back_pl gt wenn irgendwann lt past_cond_pl gt lt past_cond_pl gt dann lt DEs3_back_pl gt wenn vorher lt past_cond_pl gt A DEel gt Nur wenn lt pres_cond_pl gt dann lt DEl_for_pl gt lt DEel_back_pl gt wenn gleichzeitig lt pres_cond_pl gt A DEe2 gt Nur wenn lt pres_cond_pl gt dann lt DE2_for_pl gt lt DEe2_back_pl gt wenn lt pres_cond_pl gt A DEe3 gt
42. ckgesetzt 42 BOOL VAR_GLOBAL Robot_done_take_table die Fertigmeldung Roboter hat Teil vom Tisch genommen TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 43 BOOL VAR_GLOBAL Table_run_lower das Startsignal Hubdrehtisch senken und rechts drehen TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt Formale Spezifikation mit dem SFS Editor gt gt gt Satz 34 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Automatikbetrieb ist und die Fertigmeldung Zuftihrband hat Teil auf Tisch abgelegt ist gesetzt dann muss die Fertigmeldung Zufiihrband hat Teil auf Tisch abgelegt unmittelbar zur ckgesetzt werden und das Startsignal Hubdrehtisch heben und links drehen muss unmittelbar gesetzt werden AG rdy_in amp cell_l_state 1 amp Fbelt_done_give gt Al rdy_plc U rdy_plc amp Fbelt_done_give amp Table_run_lift gt gt gt Satz 35 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Automatikbetrieb ist und die Fertigmeldung Roboter hat Teil vom Tisch genommen ist gesetzt dann muss die Fertigmeldung 163 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Roboter hat Teil vom Tisch ge
43. die sich aus den unterschiedlichen Betrachtungsweisen und Anforderungen der poten tiellen Anwender ergeben So ist es zwingend notwendig die Funktionalit t und vor allem auch die Benutzerschnittstellen einer zu entwickelnden Methode bzw eines Tools auf die tats chlichen Gegebenheiten und Erfordernisse des zuk nftigen Ein satzes abzustimmen Dieser Abschnitt beleuchtet einige dieser Aspekte und be schreibt dabei gleichzeitig wichtige Eigenschaften die von einem formalen Beschrei bungsmittel speziell im Bereich der Steuerungstechnik verlangt werden 2 1 Allgemeine Anforderungen Das Programmieren von Software z B die Erstellung eines Steuerungsprogramms f r eine Maschine oder Anlage ist ein kreativer Prozess bei dem eine gestellte Auf gabe in ein korrektes Programm berf hrt werden muss Dieser Prozess ist sehr komplex so dass er auch in absehbarer Zukunft nur von Spezialisten zu bew ltigen ist Dabei stellt die Erstellung der Spezifikation das herausragende Problem dar In Litz99 wird dies so dargestellt Erst die Formalisierung d h die Umsetzung der informellen in eine formale Spezifikation ist der Schl ssel zur systematischen L sung der Steuerungsaufgabe Diese Umsetzung kann rechnerunterst tzt aber nicht automatisch erfolgen Sie ist im Kern eine Leistung des Menschen Die Erstellung eines Programms aus einer Idee heraus l sst sich auch als Abbildung der Realit t in ein Programm bezeichnen Part98 Diese
44. entweder das Startsignal zum Transport eines Rohteils oder eines Fertigteils gesetzt wird Danach wird die geforderte Transportroutine bearbeitet In der Abbildung 27 wurde beispielhaft fur den Transport eines Rohteils vom Ein gangspuffer zum Zuf hrband die Verfeinerung dieses Transportvorgangs dargestellt Informelle Spezifikation Damit der Kran den Eingangspuffer korrekt anfahren kann muss er zun chst seine relative Position zu ihm bestimmen Erst dann kann entschieden werden in welche Richtung der Kran fahren soll d h welches Aktorsignal zu aktiveren ist Prinzipiell kann davon ausgegangen werden dass sich der Kran nach einem zuvor erfolgten Transportvorgang entweder am Zuf hrband oder am Ausgangspuffer befindet Diese beiden Positionen und auch wenn sich der Kran bereits am Eingangspuffer oder am Ablageband befindet k nnen durch die vorhandenen Sensoren erkannt werden Sollte sich der Kran an einer unbekannten Position befinden wenn also keiner der vier Sensoren aktiv ist so muss zun chst eine Fahrtrichtung festgelegt und durch nachfolgende erstmalige Erkennung eines Sensors die Position bestimmt werden Unter Umst nden ist dann die Fahrtrichtung wieder umzukehren Hat der Kran je doch die Position des Eingangspuffers erreicht so wird der Magnetgreifer auf die H he des Eingangspuffers abgesenkt Dann wird der Magnetgreifer aktiviert Danach beginnt das Anheben des Greifers Sobald dieser wieder oben ist f hrt der Kran zum
45. keiten f r die einzelnen Ereignisse festlegen so dass auch eine Gesamtausfallwahr scheinlichkeit f r das gesamte System errechnet werden kann In der Praxis geht man bei der Fehlerbaumanalyse von der zu vermeidenden Situa tion aus diese bildet die Wurzel des Baumes die Wurzel befindet sich in der grafi schen Darstellung jedoch oben Nun ist zu analysieren welche Voraussetzungen und Bedingungen eintreten m ssten damit diese gef hrliche Situation schlie lich eintritt Sollte es mehrere Vorbedingungen f r die Existenz einer Situation geben so k nnen diese entweder konjunktiv die aufgef hrten Vorbedingungen m ssen gleich zeitig erf llt sein oder disjunktiv lediglich eine der Vorbedingungen muss erf llt sein verkn pft sein Auf diese Weise baut sich eine hierarchische Baumstruktur auf Be zogen auf eine konkrete Anlage oder Maschine sind bei der Analyse die gegebenen konstruktiven und technologischen Zusammenh nge zu betrachten Die Abbildung 29 stellt ein Beispiel f r eine Fehlerbaumanalyse innerhalb der vorgestellten Fallstu die dar 76 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache 5 Validierung des Prototypen anhand einer Fallstudie Die folgende Fallstudie dient der Illustration des Sprachumfangs und der Handha bung der Sicherheitsfachsprache und spiegelt die Einsatzm glichkeiten der SFS in den verschiedenen Bereichen eines automatisierten Systems wider Die Fallstudie Erweiterte Pr
46. lz96 und H lz98a die so genannte Schablonen f r die nat rlichsprachliche Spezifikation benutzen siehe Abschnitt 1 4 3 2 die parallele Darstellung von formalen Anforderungen mit tempo rallogischen Formeln und nat rlichsprachlichen Darstellungen durch Bits02 zu nen nen Hier erfolgt die Darstellung der Spezifikation mit Safety Patterns die vordefi nierte Satzstrukturen bereitstellen und durch den Anwender zu vervollst ndigen sind Einen etwas anderen Weg gehen die beiden folgenden Tools deren Ziel es ist aus einem Text die wesentlichen Aussagen und Anforderungen herauszufinden Diese m ssen meist aus einer gro en Menge an Text gefunden werden der von Kunden und Anwendern zusammengestellt wurde Das Programm Findphrases dient zum Auffinden wiederholter Phrasen in einem willk rlichen Text Agui90 Hier geht es darum die urspr ngliche Aufgabenstellung zu pr zisieren und zu abstrahieren Abstfinder Gold94 dient ebenfalls zum Auffinden der Abstraktion innerhalb eines nat rlichsprachlichen englischen Textes F r den speziellen Bereich der Software f r Steuerungssysteme gibt es eine sehr gro e Auswahl von Beschreibungsmitteln In Polk92 werden diese dargestellt und kategorisiert Man unterscheidet demnach prozedurale und logik orientierte Spra chen Eine weitere Unterteilung wird jeweils noch in grafische und textorientierte Beschreibungsmittel getroffen so dass insgesamt vier Kategorien unterschieden werden Prozed
47. r eine solche Funktionsanforderung ist dass bei Bet tigung eines bestimmten Tasters durch den Anlagenbediener un verz glich ein Motor einzuschalten ist Diese genannten Anforderungen werden weiterhin als Forderungen engl de mands bezeichnet Sie beschreiben die notwendigen und erforderlichen Reaktionen des Steuerungsprogramms auf festgelegte Ereignisse Forderungen lassen sich weiterhin hinsichtlich ihres zeitlichen Horizonts betrachten Man kann auf diese Weise kurzfristige und langfristige Programmanforderungen be schreiben Unter kurzfristigen Anforderungen kann man solche verstehen die eine m glichst schnelle Reaktion des Steuerungsprogramms auf das Eintreten bestimm ter Ereignisse beschreiben Ein Beispiel hierf r ist das notwendige Abschalten eines Motors sobald ein durch ihn bewegtes Maschinenelement einen bestimmten Endla genschalter erreicht hat und somit ein Signal ausgel st wurde Bei langfristigen An forderungen ist der Zeitpunkt f r das Erreichen der beschriebenen Reaktion nicht exakt definiert Hierbei werden bergeordnete Systemziele definiert so z B dass ein Werkst ck das in eine Produktionszelle gelangt diese auch irgendwann wieder verlassen muss Bei Sicherheitsanforderungen werden blicherweise einzelne Zust nde des Systems beschrieben die innerhalb der Betrachtungszeit des Systems niemals erreicht wer den d rfen Beispiele hierf r sind Zust nde die zu einer Gef hrdung von Personen der Umgebung
48. unbegrenzt Wenn irgendwann der aktuelle Stand der Auftragsbearbeitung Neu war dann muss der aktuelle Stand der Auftragsbearbeitung irgendwann auf Bearbeiten gesetzt werden AG rdy_in amp order_status 1 gt AF rdy_plc amp order_status 3 gt gt gt Satz 3 lt lt lt einfache Forderung unbegrenzt Wenn irgendwann der aktuelle Stand der Auftragsbearbeitung Bearbeiten war dann muss der aktuelle Stand der Auftragsbearbeitung irgendwann auf Fertig gesetzt werden AG rdy_in amp order_status 3 gt AF rdy_plc amp order_status 5 141 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Informelle Spezifikation die untergeordneten Komponenten mussen koordiniert werden Definition neuer Daten mit dem SFS Editor Datenebene 2 Transportauftrag Technische Variable Daten Kommentar Bezeichnung typ Auftragsart tr_kind Integer welche Art von Transport auftrag soll ausgef hrt werden Bearbeitungsort tr_place Integer welche Produktionszelle soll angefahren werden Teileanzahl tr_quantity Integer wie viele Teile sollen transportiert werden Tabelle 10 Datenebene 2 Datensatz Transportauftrag 5 INT VAR_GLOBAL tr _ kind die Transportart 0 kein Transport I Rohteile holen 2 Fertigteile wegbringen O auf 0 kein Transport gesetzt O auf 1 Rohteile holen gesetzt O a
49. von Material oder der Maschine selbst f hren k nnen So k nnte f r eine betrachtete Maschine festgelegt sein dass es niemals eine Situation geben darf in der eine Sicherheitsvorrichtung ge ffnet ist und gleichzeitig eine Maschinen bewegung ausgef hrt wird 37 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Sicherheitsanforderungen werden im Folgenden als Verbote engl prohibitions be zeichnet Sie beschreiben Zustande des Steuerungsprogramms die nicht eintreten d rfen bzw verbotene Reaktionen auf festgelegte Ereignisse Es erweist sich als brauchbar und w hrend der Software Entwicklungsphase als durchaus blich eine weitere Kategorie von Anforderungen zu definieren So gibt es Situationen in denen eine bestimmte Reaktion des Steuerungsprogramms zwar er laubt ist aber noch nicht ausgef hrt werden darf weil eine andere zus tzliche Be dingung noch nicht erf llt ist Eine solche typische Freigabesituation ist gegeben wenn z B eine Maschinenbewegung ausgef hrt werden darf wenn eine Sicher heitsvorrichtung geschlossen ist die Aktion aber erst dann erfolgen soll wenn gleichzeitig auch ein bestimmter Taster bet tigt wurde Diese Anforderungen werden im Folgenden als M glichkeiten engl possibilities bezeichnet Sie beschreiben erlaubte Reaktionen des Steuerungsprogramms auf festgelegte Ereignisse 2 5 Einbindung der Sicherheitsfachsprache in eine Verifikationsumgebung Die Sicherheitsf
50. 1 Konstruktive Gestaltung des Systems z B der Einsatz von fail safe Konstruk tionen bzw sicheren Bauteilen oder die Reduzierung von Stressfaktoren durch Uberdimensionierung von Bauteilen 2 Einsatz von technischen Schutzeinrichtungen Aufbau redundanter Systeme Einsatz von fehlererkennenden bzw tolerierenden Systemen 3 Durchsetzung organisatorischer Ma nahmen regelm ige Inspektion der Systeme fachgerechte Schulung des Personals Die vorgestellten Handlungen sind sicherlich nicht vollst ndig jedoch stellt die ge zeigte Reihenfolge bereits eine Priorisierung der Ma nahmen dar Das oberste Ziel muss es sein das System von sich aus eigensicher zu gestalten Erst wenn diese Ma nahmen ausgesch pft sind sollten zus tzliche Schutzeinrichtungen integriert werden die die Funktionsf higkeit des Systems berwachen und eventuelle Fehler aufdecken und melden sollen Sollten auch diese Ma nahmen nicht zu einer ausrei chenden Verringerung des Restrisikos f hren muss dieses durch weitere nichttech nische Ma nahmen unter die noch akzeptable Grenze Grenzrisiko gesenkt werden Auch im Bereich der Softwaretechnik gibt es einige sowohl technische als auch or ganisatorische Ma nahmen um die Korrektheit und Sicherheit und somit auch die Qualit t der betrachteten Software zu erh hen Einige davon sollen anschlie end kurz erl utert werden Ebenso wie bei den technischen Systemen lassen sich die Ma nahmen in unterschie
51. 25419 DIN 25419 Ereignisablaufanalyse Verfahren graphische Sym bole und Auswertung November 1985 DIN 25424 DIN 25424 Fehlerbaumanalyse Methoden und Bildzeichen 1981 DIN 25448 DIN 25448 Ausfalleffektanalyse Fehler M glichkeits und Einflu Analyse Mai 1990 DIN 40719 DIN 40719 Schaltungsunterlagen Teil 6 Regeln f r Funktions plane 1992 Teil 11 Zeitablaufdiagramme Schaltfolgediagramme 1978 DIN 44300 DIN 44300 Informationsverarbeitung Begriffe Nov 1988 104 DIN 66255 DIN 66285 DIN 66270 Dill94 Dwye98 Ehri85 Emer90 Fein97 Fish93 Flei97 Flie86 Frey98 Frey00 Frap01 Futs89 Literatur DIN 66255 Informationsverarbeitung Programmiersprache PL I 1980 DIN 66285 G tebedingungen und Pr fbestimmungen Anwendersoftware ISO IEC CD 12199 DIN 66270 Informationstechnik Bewerten von Softwaredoku menten Qualit tsmerkmale 1998 Dillon L K Kutty G Moser L E Melliar Smith P M Rama krishna Y S A Graphical Interval Logic for Specifying Concur rent Systems ACM Transactions on Software Engineering and Methodology Vol 3 No 2 pp 131 165 April 1994 Dwyer M B Avrunin G S Corbett J C Property specification patterns for finite state verification Proc 2 Workshop on Formal Methods in Software Practice FMSP 98 March 1998 Ehrig H
52. 32 amp Arml_mag_on amp Arml_backward gt gt gt Satz 137 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 32 ist und der Roboterarm 1 ist hinten dann muss das Einziehen des Roboterarms 1 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 33 gesetzt werden und die Fertigmeldung Roboter hat Teil vom Tisch genommen muss unmittelbar gesetzt werden und die Drehung des Roboters nach links muss unmittelbar gestartet werden AG rdy_in amp Robot_state 32 amp Arml_ext 0 0 gt Al rdy_plce U rdy_plc amp Arml_backward amp Robot_state 33 amp Robot_done_take_table amp Robot_left gt gt gt Satz 138 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 33 ist und der Roboter ist mit dem Arm 2 vor der Presse dann muss die Drehung des Roboters nach links unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 34 gesetzt werden und das Ausfahren des Roboterarms 2 muss unmittelbar gestartet werden AG rdy_in amp Robot_state 33 amp Robot_angle 0 gt Al rdy_plc U rdy_plc amp Robot_left amp Robot_state 34 amp Arm2_forward gt gt gt Satz 139 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 34 ist und der Roboterarm 2 ist in der Presse dann muss d
53. Ausf hrung bestimmter Aktionen Durch verschiedene Sensoren und Akto ren ist die Steuerung der Presse mit den Maschinenelementen verbunden Gegebene Daten Technische Bezeichnung Variable Datentyp Kommentar Meldung Presse bereit zur Press_rdy_take Bool bernahme eines Rohteils Meldung Presse bereit zur Press_rdy_give Bool bergabe eines Fertigteils Startsignal Pressen Press_run_work Bool Startsignal Beladen Vorbe Press_run_prepare Bool reiten Definition neuer Daten mit dem SFS Editor Sensoren der Presse Technische SPS Variable Datentyp Kommentar Bezeichnung Schalter untere Pres Press_bottom Bool TRUE Presse unten senposition Schalter mittlere Pres Press_middle Bool TRUE Presse in der Mitte senposition Schalter obere Pres Press Top Bool TRUE Presse oben senposition Tabelle 37 Datenebene 4 Sensoren der Presse 96 BOOL VAR 97 BOOL VAR Press_bottom die Presse TRUE_I unten FALSE_I nicht unten 98 BOOL VAR Press_middle die Presse TRUE_I in der Mitte FALSE_I nicht in der Mitte Press_top die Presse TRUE_I oben FALSE_I nicht oben 219 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Aktor der Presse Technische SPS Variable Datentyp Kommentar Bezeichnung Motor Presse
54. By gt AF rdy_plc a F a AF rdy_in a B Kategorie PRs4 einfaches Verbot Fremdbegrenzt Analyseinhalt Bei dieser Anforderungskategorie darf es im Beobachtungsintervall keinen Zustand geben in dem die Folgerung erf llt ist Das Beobachtungsintervall beginnt mit einem Zustand in dem die erste Bedingung B erf llt wird und endet mit einem Zustand in dem die zweite Bedingung Bz erf llt wird Dieses Verhalten l sst sich durch Erweiterung der Kategorie PRs5 erzielen indem zus tzlich eine Endbe dingung vereinbart wird AL rdy_in A By gt AG rdy_plca F U rdy_in A Be Kategorie POe4 erweiterte M glichkeit Fremdbegrenzt Analyseinhalt Diese Kategorie l sst sich durch Verkn pfung der Kategorien POe5 und PRs5 erstellen Eine bestimmte Folgerung darf nur zwischen zwei verschiede nen Bedingungen ausgef hrt werden Das Beobachtungsintervall wird durch die bei den Bedingungen B und B2 begrenzt In der Umkehrung ergibt sich wiederum dass die Folgerung nicht au erhalb des Beobachtungsintervalls erf llt werden darf d h weder vor der ersten Bedingung B noch nach der zweiten Bedingung Ba AG rdy_in a Bz gt AEF rdy_plc F a A rdv oe F U rdy_in a By Kategorie DEe4 erweiterte Forderung Fremdbegrenzt Analyseinhalt Sobald es einen Zustand gibt in dem rdy_in und eine Startbedingung B erf llt werden muss es danach einen Zustand geben in dem rdy_plc und eine Folgerung F erf llt werden be
55. Chapter of the Acciciation for Computer Linguistics EACL 95 Dublin Ireland March 27 31 1995 Dali95b Dalianis H Aggregation Formal specification and Natural lan guage Generation proc 1 International Workshop on the Appli cations of Natural Language to Data Base NLDB 95 Versailles France June 28 29 1995 DeSm00 DeSmet O Couffin S Rossi O Canet G Lesage J J Schnoebelen Ph Papini H Safe Programming of PLC using formal verification methods 4 international PLCopen conference on Industrial Control Programming ICP2000 Utrecht Nether lands October 2000 DGQ86 Deutsche Gesellschaft f r Qualit t Software Qualitatssicherung Aufgaben M glichkeiten L sungen DGQ ITG Schrift Nr 12 51 Beuth Verlag Berlin 1986 DGQ92 Deutsche Gesellschaft f r Qualit t Methoden und Verfahren der Software Qualitatssicherung DGQ ITG Schrift Nr 12 52 Beuth Verlag Berlin 1992 DGQ98 Deutsche Gesellschaft f r Qualit t e V Zuverl ssigkeit komple xer Systeme aus Hardware und Software DGQ Band 17 01 1998 DIN 31000 DIN VDE 31000 Allgemeine Leits tze f r das sicherheitsgerechte Gestalten technischer Erzeugnisse 1987 DIN 19226 DIN 19226 Leittechnik Regelungstechnik und Steuerungstech nik Teile 1 bis 6 1994 97 DIN 19250 DIN V 19250 Vornorm Leittechnik Grundlegende Sicherheits betrachtungen f r MSR Schutzeinrichtungen 1994 DIN
56. Crane_lower Crane_to_fbelt 12 Crane_mag_on 24 Crane ower Crane _lift 7 Crane_height 0 0 Crane_height 0 35 ICrane _lift ICrane_lower 13 Crane_to_fbelt 25 Crane_mag_on Crane_lift Crane_at_fbelt F Crane_height 0 0 ICrane_to_fbelt O 14 Crane_lower 26 lene IM Crane_height 0 94 true Crane_lower 15 Crane_mag_on Crane_lift Crane_done_give_fbelt ag Crane_height 0 0 16 ICrane_lift true Formale Spezifikation mit dem SFS Editor gt gt gt Satz 64 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 0 ist und das Startsignal Kran holt Rohteil vom Eingangspuffer ist gesetzt und das Startsignal Kran holt Fertigteil von Ablageband ist nicht gesetzt dann muss das Startsignal Kran holt Rohteil vom Eingangspuffer unmittelbar zur ckgesetzt werden und die Zustandsvariable des Krans muss unmittelbar 1 werden AG rdy_in amp Crane_state 0 amp Crane_run_source amp Crane_run_dbelt gt Al rdy_plc U rdy_plc amp Crane_run_source amp Crane_state 1 gt gt gt Satz 65 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 0 ist und das Startsignal Kran holt Fertigteil von Ablageband ist gesetzt dann muss das Startsignal Kran holt 185 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Fertigteil von Ablageband unmittelbar zur ckgesetzt werden und die Zusta
57. Drehung Zustandsvariable des Hubdrehtischs Table_state2 Integer H he Tabelle 33 Datenebene 4 Interne Variablen der Steuerung des Hubdrehtischs 82 INT VAR Table_statel die Zustandsvariable der Hubtischdrehung DET sen TOT en Zop te SH Dr ZN 21_ WE 225 22N O_O auf 0 gesetzt 10 auf 1 gesetzt 2_0 auf 2 gesetzt A e auf 11 gesetzt 120 auf 12 gesetzt 21_0 auf 21 gesetzt 22_0 auf 22 gesetzt 383 INT VAR Table_state2 die Zustandsvariable der Hubtischh he DU o Lt EE Nee EC 12 21_ TZIN 22 2 W220 O_O auf 0 gesetzt 1_O auf 1 gesetzt 2_0 auf 2 gesetzt 199 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache _O auf 11 gesetzt 12_0 auf 12 gesetzt 21_0 auf 21 gesetzt 22_0 auf 22 gesetzt table_rdy_give Itable_left itabble_upward table_angle 50 table_top mi table_left a table_run_lift table_upward DR table_run_litt able_run_lower table_run_lower l table downward tabel_angle 0 table_bottom ltable_right Itable_downward 22 1 table_rdy_take Formale Spezifikation mit dem SFS Editor gt gt gt Satz 105 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Hubt
58. Hardwaredesigner und Softwareingenieure vertraut sind Man erh lt somit eine intuitive grafische Darstellung Mit GILED dem zugeh rigen Editor werden grafisch Intervalle definiert in denen Eigenschaften erf llt sein m ssen Die TL Operatoren Eventually Until und Henceforth sowie logi sche Operatoren UND ODER Implikation Aquivalenz Negation k nnen somit ausgedr ckt werden Das gesamte Tool Set enth lt dar ber hinaus einen Proof Checker und einen Model Generator so dass eine grafische berpr fung und ein Beweis von Systemeigenschaften m glich sind Die Anzahl der bekannten Entwicklungswerkzeuge die nat rliche Sprache zur For mulierung der Anforderungen nutzen ist gering AMADEUS Blac87 ALECSI Cauv91 Von H Dalianis wird in Dali95a und Dali95b ein Spezifikations und Validierungswerkzeug beschrieben das zur Entfernung von Redundanzen in Texten verwendet werden kann Mit VINST Visual and Natural language specification tool erfolgt die Spezifikation mit der Visual Language VL und einer begrenzten Nat rli chen Sprache NL Ziel ist die Generierung eines redundanzfreien nat rlichsprach lichen Textes speziell f r die Funktionen von Telekommunikationsdiensten Eine an 18 Einleitung und Ausgangssituation schlie ende bersetzung nach LOXY First Order Logic extended with Time einer speziellen Form der Temporalen Logik ist m glich Im deutschsprachigen Raum ist neben den Arbeiten von H
59. INT VAR Robot_angle der Roboter 90_I mit dem Arm 1 vor der Presse 50_I mit dem Arm 1 vor dem Hubdrehtisch DIr mit dem Arm 2 vor der Presse 70_I mit dem Arm 2 vor dem Ablageband Aktoren des Roboters Technische SPS Variable Datentyp Kommentar Bezeichnung Motor Roboterarm Arml_forward Bool TRUE Arm 1 f hrt aus 1 L R Arm1_backward Bool TRUE Arm 1 fahrt ein Motor Roboterarm Arm2_forward Bool TRUE Arm 2 fahrt aus 2 L R Arm2_backward Bool TRUE Arm 2 fahrt ein Motor Roboterdre Robot_left Bool TRUE Roboter dreht nach links hung L R Robot_right Bool TRUE Roboter dreht nach rechts Greifer Roboterarm Am mag on Bool TRUE Magnet eingeschaltet 4 Greifer Roboterarm Am mag on Bool TRUE Magnet eingeschaltet 2 Tabelle 35 Datenebene 4 Aktoren des Roboters 205 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache 87 BOOL VAR Arml_forward das Ausfahren des Roboterarms 1 TRUE_O gestartet FALSE_O gestoppt TRUE_I aktiv FALSE_I nicht aktiv 88 BOOL VAR Arml_backward das Einziehen des Roboterarms 1 TRUE_O gestartet FALSE_O gestoppt TRUE_I aktiv FALSE_I nicht aktiv 89 BOOL VAR Arm2_forward das Ausfahren des Roboterarms 2 TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gestarte
60. Krans OTI amp ToT q 7 Dial So Ech q 1 T q 1 W a 2 I q 2 W 183 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache 3 13 4 I 14 92 e WIESN 16_ D 76 VB ECH kr ve 15 Zit ge 0 EA 22 T220 23_ 23 24 24 253 WE 26270 M26 O_O auf 0 gesetzt 10 auf 1 gesetzt 2 0 auf 2 gesetzt 11_O auf 11 gesetzt 12_0 auf 12 gesetzt 13_0 auf 13 gesetzt 14_O auf 14 gesetzt 15_O auf 15 gesetzt 16_O auf 16 gesetzt 17_0 auf 17 gesetzt 18_0 auf 18 gesetzt 21_0 auf 21 gesetzt 22_0 auf 22 gesetzt 2 3 0 auf 23 gesetzt 24_0 auf 24 gesetzt 250 auf 25 gesetzt 26_0 auf 26 gesetzt 184 Anhan oC crane_run_source Crane_run_dbelt amp Crane_run_dbelt ICrane_run_dbelt 1 Crane_run_source 2 C Crane_to_dbelt Crane_at_dbelt ICrane_at_dbelt Crane_at_dbelt amp Crane_fbelt amp Crane_sourec 21 C Crane_to_dbelt Crane_at_fbelt Crane at source Crane_at_drain amp Crane_at_drain Crane_lower 17 Crane_to_dbelt 18 Crane_to_fbelt Crane_height 0 66 22 Crane_lower Crane_at_source Crane_at_source Crane_mag_on Crane_lift Crane_height 0 0 ICrane _lift 11 ICrane_to_fbelt 23 Crane_done_take_dbelt Crane_lower Crane_to_fbelt Crane_height 0 85 Crane_at_drain
61. LED_celll_rdy amp Count_in 0 amp Count_out 0 ER gt gt gt Satz 9 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Automatikbetrieb ist und der Not Aus Taster ist gedr ckt dann muss die Produktionszelle 1 unmittelbar in den Not Aus Zustand berf hrt werden und die Anzeige Automatik l uft muss unmittelbar deaktiviert werden und die Anzeige Not Aus muss unmittelbar aktiviert werden und das Not Aus Signal f r den Kran muss unmittelbar gesetzt werden und das Not Aus Signal f r das Zuftihrband muss unmittelbar gesetzt werden und das Not Aus Signal f r den Hubdrehtisch muss unmittelbar gesetzt werden und das Not Aus Signal f r den Roboter muss unmittelbar gesetzt werden und das Not Aus Signal f r die Presse muss unmittelbar gesetzt werden und das Not Aus Signal f r das Ablageband muss unmittelbar gesetzt werden 153 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache AG rdy_in amp cell_l_state 1 amp Em_stopp gt Al rdy_plc U rdy_plc amp cell_l_state 3 amp LED_celll_run amp LED_em_stopp amp Em_stopp_crane amp Em_stopp_fbelt amp Em_stopp_table amp Em_stopp_robot amp Em_stopp_press amp Em_stopp_dbelt gt gt gt Satz 10 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Not Aus Zustand ist und der Not Aus Taster ist nicht gedr
62. Roboterarm 1 ausge fahren ist der Roboter darf sich nicht nach rechts drehen wenn der Roboterarm 1 aus gefahren ist der Roboter darf sich nicht nach links drehen wenn der Roboterarm 2 ausge fahren ist der Roboter darf sich nicht nach rechts drehen wenn der Roboterarm 2 aus gefahren ist die Presse darf sich nicht schlieBen wenn der Roboter mit dem Roboterarm 1 vor der Presse steht und der Roboterarm 1 ausgefahren ist die Presse darf sich nicht schlieBen wenn der Roboter mit dem Roboterarm 2 vor der Presse steht und der Roboterarm 2 ausgefahren ist Formale Spezifikation mit dem SFS Editor gt gt gt Satz 155 lt lt lt einfaches Verbot Zustand Wenn der Roboter mit dem Arm 1 vor der Presse ist und die Bereitschaftsmeldung Presse ist f r Beladung bereit ist nicht gesetzt dann darf das Ausfahren des Roboterarms 1 nicht gleichzeitig gestartet sein AG rdy_plc amp Robot_angle 90 amp Press_ready_take amp Arml_forward gt gt gt Satz 156 lt lt lt einfaches Verbot Zustand Wenn der Roboter mit dem Arm 2 vor der Presse ist und die Bereitschaftsmeldung Presse ist zur bergabe eines Teils bereit ist nicht gesetzt dann darf das Ausfahren des Roboterarms 2 nicht gleichzeitig gestartet sein AG rdy_plc amp Robot_angle 0 amp Press_ready_give amp Arm2_forward gt gt gt Satz 159 lt lt lt einfaches Verbot selbstbegre
63. Spezifikation weiterer Eigenschaften Sicherheitskritische Punkte Einschrankung der Bewegung der Roboterarme Roboterarme m ssen beim Drehen hinten sein Kollision mit Presse beim Ausfahren der Arme Formale Spezifikation mit dem SFS Editor gt gt gt Satz 149 lt lt lt einfaches Verbot selbstbegrenzt Solange der Roboterarm 1 hinten ist darf das Einziehen des Roboterarms 1 niemals gestartet werden AG rdy_plc amp Arml_ext 0 0 amp Arml_backward gt gt gt Satz 150 lt lt lt einfaches Verbot selbstbegrenzt Solange der Roboterarm 1 in der Presse ist darf das Ausfahren des Roboterarms 1 niemals gestartet werden AG rdy_plc amp Arml_ext 0 65 amp Arml_forward gt gt gt Satz 151 lt lt lt einfaches Verbot selbstbegrenzt Solange der Roboterarm 2 hinten ist darf das Einziehen des Roboterarms 2 niemals gestartet werden AG rdy_plc amp Arm2_ext 0 0 amp Arm2_backward gt gt gt Satz 152 lt lt lt einfaches Verbot selbstbegrenzt Solange der Roboterarm 2 in der Presse ist darf das Ausfahren des Roboterarms 2 niemals gestartet werden AG rdy_plc amp Arm2_ext 0 79 amp Arm2_forward gt gt gt Satz 153 lt lt lt erweiterte M glichkeit Zustand die Drehung des Roboters nach links darf nur gestartet sein wenn gleichzeitig der Roboterarm 1 hinten ist und
64. Zuf hrband Dort angekommen wird der Greifer wieder abgesenkt Auf der H he des Zuf hrbands wird der Greifer angehalten und der Magnet wird abgeschalten Gleichzeitig kann die Meldung Kran hat Teil auf Zuf hrband gelegt gesetzt werden Danach wird der Greifer wieder angehoben Sobald der Greifer wieder in seiner obe ren Position ist wird er gestoppt und gelangt wieder in den Ruhezustand Da die gezeigten Teilvorg nge unbedingt in der festgelegten Reihenfolge abzuar beiten sind bietet sich die Entwicklung einer Ablaufstruktur an Definition neuer Daten mit dem SFS Editor Es wird eine Zustandsvariable definiert die den aktuellen Zustand darstellt in dem sich der Kran bzw die Ablaufsteuerung des Krans befindet Crane_state Zustandsvariable des Krans siehe Tabelle 27 Anhang Seite 183 Formale Spezifikation mit dem SFS Editor gt gt gt Satz 64 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 0 ist und das Startsignal Kran holt Rohteil vom Eingangspuffer ist gesetzt und das Startsignal Kran holt Fertigteil von Ablageband ist nicht gesetzt dann muss das Startsignal Kran holt Rohteil vom Eingangspuffer unmittelbar zur ckgesetzt werden und die Zustandsvariable des Krans muss unmittelbar 1 werden 91 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache AG rdy_in amp Crane_state 0 amp Crane_run_source amp Cran
65. Zustand nm Wenn die Presse gestartet sein unten ist dann darf das ffnen der Presse nicht gleichzeitig AG rdy_plc amp Press_bottom amp Press_down gt gt gt Satz 172 lt lt lt einfaches Verbot Zustand Wenn die Presse oben ist dann darf das Schliessen der Presse nicht gleichzeitig gestartet sein AG rdy_plc amp Press_top amp Press_upward gt gt gt Satz 173 lt lt lt erweiterte M glichkeit Zustand das Schliessen der Presse darf nur gestartet sein wenn gleichzeitig der Roboterarm 1 hinten ist und der Roboterarm 2 ist hinten AG rdy_plce amp Arml_ext 0 0 amp Arm2_ext 0 0 amp Press_upward 223 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache A 7 9 Ger teebene 3 Steuerung des Ablagebands Die Steuerung des Ablagebands erh lt von der bergeordneten Zellensteuerung Startsignale zur Ausf hrung bestimmter Aktionen Durch verschiedene Sensoren und Aktoren ist die Steuerung des Ablagebands mit den Maschinenelementen verbun den Gegebene Daten Technische Bezeichnung Variable Datentyp Kommentar Meldung Ablageband fertig Dbelt_rdy_take Bool zur bernahme eines Teils Startsignal Ablageband Dbelt_run Bool transportiert Teil zum Kran Meldung Ablageband f r Dbelt_rdy_give Bool bergabe eines Fertigteils bereit
66. aktuelle Stand der Auftragsbearbeitung Bearbeiten ist und die Fertigmeldung der Produktionszelle 1 ist gesetzt und die Bereitschaftsmeldung des Transportsystems gesetzt ist dann muss der aktuelle Stand der Auftragsbearbeitung unmittelbar auf Fertigteile wegbringen gesetzt werden und die Transportart muss unmittelbar auf 2 Fertigteile wegbringen gesetzt werden und die anzufahrende Produktionszelle muss unmittelbar 1 werden und die Fertigmeldung der Produktionszelle 1 muss unmittelbar zur ckgesetzt werden und die Bereitschaftsmeldung des Transportsystems muss unmittelbar zur ckgesetzt werden AG rdy_in amp order_status 3 amp cell_l_finished amp tr_sys_ready gt Al rdy_plc U rdy_plc amp order_status 4 amp tr_kind 2 amp tr_place 1 amp cell_l_finished amp tr_sys_ready e 145 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache A 7 2 Gerateebene 2 Zentrale Steuerung der Produktionszelle A 7 2 1 Kommunikation mit MMI und bergeordneter Ebene Gegebene Daten F r die zentrale Steuerung der Produktionszelle k nnen die Bereitschafts und Fer tigmeldung zur Kommunikation mit der Auftragsverwaltung als bekannt vorausge setzt werden Definition neuer Daten mit dem SFS Editor An dieser Stelle erfolgt die Definition der Sensor und Aktorsignale die direkt an die zentrale Steuerung der Produktionszelle angeschlossen sind Sensoren des MMI B
67. als Ergebnis der berpr fung entweder eine Best tigung f r die Einhaltung der Spezifikation in allen modellierten Zust nden des Sys tems oder m gliche Gegenbeispiele in denen eine oder mehrere Anforderungen nicht erf llt werden Die Aussagekraft des Verifikationsergebnisses h ngt jedoch im mer von der Qualit t der gegebenen Voraussetzungen Programm Umgebungsmo dell Anforderungen ab Als Ergebnis einer erfolgreichen Verifikation kann man somit 99 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache von einem korrekten SPS Programm beztglich der gegebenen Voraussetzungen sprechen Fur die Weiterentwicklung der vorgestellten Sicherheitsfachsprache existieren meh rere Ankn pfungspunkte Diese liegen in der Vielfalt der Einsatzm glichkeiten einer verbalen Spezifikationssprache begr ndet Zwar wurde die SFS speziell f r die For mulierung der Anforderungen an reaktive Systeme konzipiert die Ausweitung der Nutzung auf andere Gebiete ist jedoch denkbar Zu diesem Zweck bieten die formale Definition und die Struktur der Sicherheitsfachsprache die M glichkeit einer einfa chen Erweiterung der Syntax und die Einbindung neuer sprachlicher Konstruktionen Hier ist vor allem die Erweiterung der M glichkeiten zur Benutzung der Variablenty pen Integer oder Real zu nennen Diese Erweiterungen bieten dann die M glichkeit andere Anwendungsbereiche zu erschlie en Als Beispiel sei hier die Fuzzylogik er
68. amp Robot_done_dbelt amp Crane_done_take_dbelt gt Al rdy_plc U rdy_plc amp Robot_done_dbelt amp Crane_done_take_dbelt amp Dbelt_run Informelle Spezifikation weiterer Eigenschaften Das Ablageband darf nicht starten solange der Roboter kein Teil auf das Ablageband gelegt hat Das Ablageband darf nicht starten solange der Kran das Teil nicht vom Band genommen hat Formale Spezifikation mit dem SFS Editor gt gt gt Satz 57 lt lt lt einfaches Verbot Zustand das Startsignal Ablageband soll Teil transportieren darf nicht gleichzeitig gesetzt sein wenn die Fertigmeldung Roboter hat Teil auf Ablageband gelegt nicht gesetzt ist I AG rdy_plc amp Robot_done_dbelt amp Dbelt_run gt gt gt Satz 58 lt lt lt einfaches Verbot Zustand das Startsignal Ablageband soll Teil transportieren darf nicht gleichzeitig gesetzt sein wenn die Fertigmeldung Kran hat Fertigteil vom Ablageband genommen nicht gesetzt ist I AG rdy_plc amp Crane_done_take_dbelt amp Dbelt_run 175 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache A 7 2 8 Kommunikation mit dem Kran Il Die Steuerung der Produktionszelle muss an die Steuerung des Krans ein Signal ge ben wenn dieser ein Fertigteil vom Ablageband holen soll Dazu m ssen der Zellen steuerung die folgenden Informatio
69. aus der Presse entnommen hat Danach kann die Presse in die Ausgangsstellung zur ck kehren Definition neuer Daten mit dem SFS Editor Variablen zur Kommunikation mit der Presse Technische Bezeichnung Variable Datentyp Kommentar Startsignal Pressen Press_run_work Bool Startsignal Beladen Vorbe Press_run_prepare Bool reiten Tabelle 22 Datenebene 3 Variablen zur Kommunikation mit der Presse 6655 BOOL VAR_GLOBAL Press_run_ work das Startsignal Presse soll pressen TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 56 BOOL VAR_GLOBAL Press_run_prepare das Startsignal Presse soll Beladung vorbereiten TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt 172 Anhang FALSE_O zur ckgesetzt Formale Spezifikation mit dem SFS Editor gt gt gt Satz 52 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Automatikbetrieb ist und die Fertigmeldung Roboter hat Teil in Presse gelegt ist gesetzt dann muss die Fertigmeldung Roboter hat Teil in Presse gelegt unmittelbar zur ckgesetzt werden und das Startsignal Presse soll pressen muss unmittelbar gesetzt werden AG rdy_in amp cell_l_state 1 amp Robot_done_load gt Al rdy_plc U rdy_plc amp Robot_done_
70. ckgesetzt 52 BOOL VAR_GLOBAL Robot_run_mix das Startsignal Presse TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 53 BOOL VAR_GLOBAL Roboter Presse ist zur Ablageband ist entl dt Roboter hat Teil aus Roboter hat Teil auf Roboter be und entl dt 168 Anhang Robot_wait_mix die Bereitschaftsmeldung Roboter wartet vor Presse TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 54 BOOL VAR_GLOBAL Robot_run_cont das Startsignal Roboter weiter im Mix TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt Formale Spezifikation mit dem SFS Editor gt gt gt Satz 39 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Automatikbetrieb ist und die Bereitschaftsmeldung Hubdrehtisch ist zur bergabe eines Teils bereit ist gesetzt und die Bereitschaftsmeldung Presse ist zur bergabe eines Teils bereit ist gesetzt und die Bereitschaftsmeldung Ablageband ist zur bernahme eines Teils bereit ist gesetzt dann muss die Bereitschaftsmeldung Hubdrehtisch ist zur bergabe eines Teils bereit unmittelbar zur ckgesetzt werden und die Bereitschaftsmeldung Presse ist zur bergabe eines Teils bereit muss unmittelbar zur ckgeset
71. des Krans muss unmittelbar 24 werden und das Absenken des Krangreifers muss unmittelbar gestartet werden AG rdy_in amp Crane_state 23 amp Crane_at_drain gt Al rdy_plc U rdy_plc amp Crane_to_fbelt amp Crane_state 24 amp Crane_lower gt gt gt Satz 84 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 24 ist und der Greifer des Krans ist auf dem Ausgangspuffer dann muss das Absenken des Krangreifers unmittelbar gestoppt werden und die Zustandsvariable des Krans muss unmittelbar 25 werden und der Magnet des Krangreifers muss unmittelbar deaktiviert werden und das Anheben des Krangreifers muss unmittelbar gestartet werden AG rdy_in amp Crane_state 24 amp Crane_height 0 35 gt Al rdy_plc U rdy_plc amp Crane_lower amp Crane_state 25 amp Crane_mag_on amp Crane_lift gt gt gt Satz 85 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 25 ist und der Greifer des Krans ist oben dann muss das Anheben des Krangreifers unmittelbar gestoppt werden und die Zustandsvariable des Krans muss unmittelbar 0 werden AG rdy_in amp Crane_state 25 amp Crane_height 0 gt Al rdy_plc U rdy_plc amp Crane_lift amp Crane_state 0 190 Anhang Informelle Spezifikation weiterer Eigenschaften Sicherheit Kran Neben den Funktionsanforderungen
72. einger ckt mit Rahmen Formale Sprachdefinitionen in Backus Naur Form Courier New 12pt Terminalsymbole innerhalb einer Sprachdefinition Times New Roman 12pt Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Kurzfassung Rechnersysteme und automatische Steuerungen durchdringen in immer starkerem Ma e unser t gliches Leben Sie helfen uns bei der L sung komplizierter zeitauf w ndiger und monotoner Aufgaben sie geben uns die M glichkeit den Menschen von k rperlich schweren und gef hrlichen Arbeiten zu entlasten Rechnersysteme dringen heute auch immer mehr in Bereiche vor f r die es vor wenigen Jahren noch als undenkbar galt die Kontrolle an eine Maschine zu bergeben Grundvorausset zung f r einen solchen Migrationsprozess ist neben der Entwicklung immer kleinerer und leistungsf higerer Hardware die Entwicklung der zugeh rigen Software ohne die der eingesetzte Rechner oder das Steuerungssystem nutzlos bleiben w rde Ein methodisches und wohl berlegtes Vorgehen bei der Erstellung von Software das so genannte Software Engineering war bisher eine Dom ne der Informatik Jedoch auch in der Automatisierungstechnik erfordern die zunehmende Komplexit t das steigende Sicherheitsbed rfnis der Endanwender sowie die st rkere Verbreitung konventioneller Rechentechnik inklusive der eingesetzten Programmiersprachen neue Herangehensweisen bei der Entwicklung Realisierung und Qualit t
73. in konkrete Handlungsschritte aus Wesentliche Ziele dieser Darstellung sind Reduktion des Schreib und Protokollierungsaufwands durch standardisiertes Vorgehen Reduktion des Pr faufwandes durch produktabh ngige Festlegung der Pr f tiefe Die hersteller und pr fstellenseitigen Pr funterlagen werden hier ebenso beschrie ben wie die Ergebnisdokumente und Pr fberichte 22 Einleitung und Ausgangssituation Eine weitere Variante wird in Grel93 dargestellt Hier wird durch eine diversitare Ruckwartsanalyse des erzeugten Programmcodes berpr ft ob das erstellte Prog ramm den urspr nglichen Anforderungen entspricht 1 4 3 2 Verifikation Die im vorherigen Abschnitt erw hnten Tests hinsichtlich der Korrektheit von Pro grammen m ssen aufgrund der Komplexit t von Programmen mit einer industriell relevanten Gr e immer als unvollkommen betrachtet werden Als ein weiteres m chtigeres Werkzeug zur berpr fung der Korrektheit einer Software hat sich des halb in den vergangenen Jahren die Verifikation herausgebildet Man unterscheidet hier zwei rechnergest tzte Verfahren f r die formale Verifikation das Theorem Pro ving und das Model Checking Beim Theorem Proving wird ein Beweisen der Kor rektheit aufgrund syntaktischer Formelumwandlungen durch vollst ndige Induktion bzw Deduktion gef hrt Beim Model Checking wird der mathematische Beweis durch berpr fung der formalen Spezifikation an einem Modell des Systems erbra
74. ist Aus Effizienzgr nden kann man den Transportvorgang in zwei Phasen unterteilen So kann in der ersten Phase das Rohteil bereits zum Bandende transportiert werden auch wenn der Hubdrehtisch noch nicht zur Aufnahme des Teils bereit ist Erst wenn dieser Zustand erreicht ist findet in der zweiten Transportphase die bergabe des Rohteils auf den Hubdrehtisch statt Dieses Vorgehen hat den weiteren Vorteil dass das Zuf hrband bereits wieder mit einem neuen Rohteil beladen werden kann w h rend noch auf die Bereitschaft des Hubdrehtischs gewartet wird F r diesen Zeitraum w rden sich dann zwei Rohteile auf dem Band befinden Informelle Spezifikation Der Transportvorgang wird in zwei separate Phasen mit eigenen Startbedingungen unterteilt 1 Transport des Rohteils bis zum Bandende 2 bergabe des Rohteils auf den Hubdrehtisch zu 1 Durch den Kran wird bereits eine Meldung zur Verf gung gestellt dass er das Zuf hrband beladen hat Das Zuf hrband muss seinerseits eine Meldung zur Verf gung stellen dass es zum Weitertransport dieses Teils bereit ist das Ende des Zuf hrbands muss frei sein Au erdem ist ein Startsignal f r diesen Transport zu generieren zu 2 Durch den Hubdrehtisch muss eine Meldung zur Verf gung gestellt werden dass er zur Annahme eines Teils bereit ist wenn er also in der richtigen H he und Position ist das Zuf hrband muss seinerseits eine Meldung zur Verf gung stellen dass es zur bergabe e
75. ist F1 muss nur sofort werden und F2 muss nur sofort werden wenn B1 ist und B2 ist F1 wird nur unmittelbar und F2 wird nur unmittelbar wenn B1 ist und B2 ist F1 wird nur sofort und F2 wird nur sofort wenn B1 ist und B2 ist Kategorie DEe3 erweiterte Forderung selbstbegrenzt Nur solange B1 ist und B2 ist muss irgendwann F1 werden und muss irgendwann F2 werden Nur solange B1 ist und B2 ist wird irgendwann F1 und wird irgendwann F2 F1 muss nur irgendwann werden und F2 muss nur irgendwann werden solange gleichzeitig B1 ist und B2 ist F1 wird nur irgendwann und F2 wird nur irgendwann solange gleichzeitig B1 ist und B2 ist Kategorie DEe4 erweiterte Forderung fremdbegrenzt Nur wenn irgendwann B1 war und B2 war dann muss irgendwann F1 werden und muss irgendwann F2 werden bevor B3 ist und B4 ist Nur wenn irgendwann B1 war und B2 war dann wird irgendwann F1 und wird irgendwann F2 bevor B3 ist und B4 ist Nur nachdem B1 war und B2 war muss irgendwann F1 werden und muss irgendwann F2 werden bevor B3 ist und B4 ist Nur nachdem B1 war und B2 war wird irgendwann F1 und wird irgendwann F2 bevor B3 ist und B4 ist Kategorie DEe5 erweiterte Forderung unbegrenzt Nur wenn irgendwann B1 war und B2 war dann muss irgendwann F1 werden und muss irgendwann F2 werden Nur wenn irgendwann B1 war und B2 war dann wird irgendwann F1 und wird irgendwann F2 Nur nachdem B1 war und B2
76. muss unmittelbar gestartet werden AG rdy_in amp Crane_state 1 amp Crane_at_drain gt A rdy_ple U rdy_plc amp Crane_state 17 amp Crane_to_fbelt gt gt gt Satz 69 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 1 ist und der Kran ist am Ablageband dann muss die Zustandsvariable des Krans unmittelbar Ib werden und die Bewegung des Krans nach links zum Zufiihrband muss unmittelbar gestartet werden AG rdy_in amp Crane_state 1 amp Crane_at_dbelt gt Al rdy_plc U rdy_plc amp Crane_state 17 amp Crane_to_fbelt 186 Anhang gt gt gt Satz 70 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 1 ist und der Kran ist nicht am Ablageband und der Kran ist nicht am Zuf hrband und der Kran ist nicht am Eingangspuffer und der Kran ist nicht am Ausgangspuffer dann muss die Zustandsvariable des Krans unmittelbar Ib werden und die Bewegung des Krans nach links zum Zuf hrband muss unmittelbar gestartet werden AG rdy_in amp Crane_state 1 amp Crane_at_dbelt amp Crane_at_fbelt amp Crane_at_source amp Crane_at_drain gt Al rdy_plc U rdy_plc amp Crane_state 17 amp Crane_to_fbelt gt gt gt Satz 71 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans la ist und der Kran ist am Eingangspuf
77. r jede dieser Aufgaben ist genau ein Arm des Roboters zust ndig Die Beladung der Presse erfolgt mit dem Roboterarm 1 die Entladung mit dem Roboterarm 2 Zur Steigerung der Effizienz der Anlage sind die dargestellten Vorg nge nicht nur alter nativ sondern unter Ber cksichtigung bestimmter Koordinierungsbedingungen auch gleichzeitig m glich Es ist sinnvoll die Best ckung der Presse und die Entnahme von Fertigteilen aus der Presse zu koordinieren Abbildung 31 So kann der Roboterarm 2 ein Teil von der Presse zum Ablageband bef rdern w hrend der Roboterarm 1 gleichzeitig nur un terbrochen durch die Bewegungsvorg nge des Arms 2 ein Teil vom Hubdrehtisch zur Presse bef rdert Auf Grund der variablen Anzahl der Werkst cke muss diese Steuerung des Roboters dann jedoch so flexibel ausgelegt werden das verschie dene von der Anzahl der Werkst cke abh ngige Verhaltensmodi abgearbeitet wer den k nnen 1a 1b 1c a e A so een qo pol e D Abbildung 31 Arbeitsmodi des Roboters
78. sein lt Nomen gt kann nur irgendwann ar lt Nomen_Wert_Paar gt kann nur lt Wert gt werden irgendwann werden lt Nomen gt darf nur irgendwann lt Nomen_Wert_Paar gt darf nur lt Wert gt werden irgendwann werden lt Nomen gt darf nicht gleichzeitig lt Wert gt sein darf lt Nomen gt nicht gleichzeitig darf nicht gleichzeitig lt Wert gt sein lt Nomen_Wert_Paar gt sein darf nicht gleichzeitig lt Nomen gt lt Wert gt sein lt Nomen gt darf niemals gleichzeitig lt Wert gt sein darf lt Nomen gt niemals darf niemals gleichzeitig gleichzeitig lt Wert gt sein lt Nomen_Wert_Paar gt sein darf niemals gleichzeitig lt Nomen gt lt Wert gt sein lt Nomen gt darf nicht gleichzeitig lt Nomen_Wert_Paar gt darf nicht lt Wert gt sein gleichzeitig sein lt Nomen gt darf niemals gleichzeitig lt Nomen_Wert_Paar gt darf niemals lt Wert gt sein gleichzeitig sein lt Nomen gt darf nicht irgendwann ei darf nicht irgendwann lt Wert gt werden lt Nomen_Wert_Paar gt werden 136 Anhang darf lt Nomen gt nicht irgendwann Mertz werden darf nicht irgendwann lt Nomen gt Mertz werden
79. sofort F1 und wird sofort F2 F1 muss unmittelbar werden und F2 muss unmittelbar werden wenn B1 ist und B2 ist F1 muss sofort werden und F2 muss sofort werden wenn B1 ist und B2 ist F1 wird unmittelbar und F2 wird unmittelbar wenn B1 ist und B2 ist F1 wird sofort und F2 wird sofort wenn B1 ist und B2 ist Kategorie DEs3 einfache Forderung selbstbegrenzt Solange B1 ist und B2 ist muss irgendwann F1 werden und muss irgendwann F2 werden Solange B1 ist und B2 ist wird irgendwann F1 und wird irgendwann F2 F1 muss irgendwann werden und F2 muss irgendwann werden solange B1 ist und B2 ist F1 wird irgendwann und F2 wird irgendwann solange B1 ist und B2 ist 123 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Kategorie DEs4 einfache Forderung fremdbegrenzt Wenn irgendwann B1 war und B2 war dann muss irgendwann F1 werden und muss irgendwann F2 werden bevor B3 ist und B4 ist Wenn irgendwann B1 war und B2 war dann wird irgendwann F1 und wird irgendwann F2 bevor B3 ist und B4 ist Nachdem B1 war und B2 war muss irgendwann F1 werden und muss irgendwann F2 werden bevor B3 ist und B4 ist Nachdem B1 war und B2 war wird irgendwann F1 und wird irgendwann F2 bevor B3 ist und B4 ist Kategorie DEs5 einfache Forderung unbegrenzt Wenn irgendwann B1 war und B2 war dann muss irgendwann F1 werden und muss irgendwann F2 werden Wenn irgendwann B1 war u
80. sselw rter zur Formulierung der Anforderungskategorien Sprachtechnisch gesehen wird der Inhalt einer Anforderung durch diese Modalver ben ausgedr ckt Flie86 Weiterhin lassen sich bei der Analyse der verbalen Formulierungen Schl sselw rter identifizieren die bestimmte zeitliche logische oder inhaltliche Zusammenh nge zwischen verschiedenen Aussagen herstellen Zeitliche Zusammenh nge nach nachdem danach vor bevor zuerst sofort dabei bis solange nie niemals Logische Zusammenh nge und oder nicht Bedingungen Konditionale wenn dann falls Implikationen Erweiterte Bedingungen nur dann wenn genau dann wenn Bikonditionale Aquivalenz Tabelle 2 Auflistung weiterer Schl sselw rter Aus sprachtechnischer Sicht handelt es sich hierbei um Konjunktionen die S tze oder Teile von S tzen verkn pfen K rs93 Man unterscheidet in anreihende Konjunktionen und disjunktive Konjunktionen oder temporale Konjunktionen nachdem solange w hrend und durative Konjunktionen solange Weiterhin fin det man Adverbien wie Temporaladverbien nie w hrenddessen Modaladverbien anders irgendwie so und Konditionaladverbien dann Neben den aufgezeigten Schl sselw rtern enthalten Anforderungen weitere kon krete applikationsspezifische Formulierungen die sich auf die Sensoren und Aktoren oder auf interne Zust nde des Systems beziehen Erst durc
81. und lt PR1_for_pl gt lt PRsl_back_pl gt lt PRsl_back_sg gt lt PRsl_back_sg gt und lt PRsl_back_pl gt lt PR3_for_pl gt lt PR3_for_sg gt lt PR3_for_sg gt und lt PR3_for_pl gt lt PRs3_back_pl gt lt PRs3_back_sg gt lt PRs3_back_sg gt und lt PRs3_back_pl gt Ebene 5 ausformulierte Satzteile DI lt pres_cond_sg gt lt Nomen_Wert_Paar gt ist lt past_cond_sg gt lt Nomen_Wert_Paar gt war lt DE1_for_sg gt muss gleichzeitig lt Nomen_Wert_Paar gt sein muss gleichzeitig lt Nomen_Wert_Paar gt bleiben lt DEsl_back_sg gt lt Nomen_Wert_Paar gt muss gleichzeitig sem lt Nomen_Wert_Paar gt muss gleichzeitig bleiben lt DEel_back_sg gt lt Nomen_Wert_Paar gt muss nur sein lt Nomen_Wert_Paar gt muss nur bleiben lt DE2_for_sg gt muss unmittelbar lt Nomen_Wert_Paar gt werden muss sofort lt Nomen_Wert_Paar gt werden wird unmittelbar lt Nomen_Wert_Paar gt wird sofort lt Nomen_Wert_Paar gt lt DES2_back_sg gt lt Nomen_Wert_Paar gt muss unmittelbar werden lt Nomen_Wert_Paar gt muss sofort werden lt Nomen_Wert_Paar gt wird unmittelbar lt Nomen_Wert_Paar gt wird sofort lt DEe2_back_sg gt Nomen_Wert_Paar gt muss nur unmittelbar werden Nomen_Wert_Paar gt m
82. zisierung der Programmanforderungen gezeigt Ungeachtet dessen wird innerhalb dieser Arbeit kein Anspruch auf die Sinnf lligkeit dieser Me thodik erhoben 4 Datenebene 1 Produktionsauftrag S Leitsystem Ee Auftragsverwaltung 4 Datenebene 2 Koordination der Produktionszellen und des Transportsystems g Steuerung Steuerung Gerateebene 2 Produktionszelle 1 1 Datenebene 3 H 4 Koordination der Einzelsteuerungen Datenebene 4 F Sensor Aktorsignale Bedienelemente Abbildung 26 Ger tetechnischer Aufbau Die Abbildung 26 zeigt eine m gliche technische Realisierung der Gesamtanlage Zu erkennen sind verschiedene Ebenen wobei sich Datenebenen mit Ger teebenen 80 Validierung des Prototypen anhand einer Fallstudie abwechseln In den Gerateebenen befinden sich die einzelnen Steuerungssysteme wie das Leitsystem die Gruppen oder Einzelsteuerungen und schlie lich die Senso ren und Aktoren Zwischen den Gerateebenen befindet sich jeweils eine Datenebene durch die spezi fische Daten zwischen den Ger teebenen ausgetauscht werden Technisch be trachtet kann die Realisierung der Datenebenen durch verschiedene Netzwerksys teme z B Ethernet LAN oder Feldbusse erfolgen Die dargestellte Struktur stellt sicherlich nur eine der m glichen Realisierungsvarianten dar
83. zum Bandende transportieren TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 36 BOOL VAR_GLOBAL Fbelt_ready_give die Bereitschaftsmeldung Zuf hrband ist zur bergabe bereit TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 37 BOOL VAR_GLOBAL Table_ready_take die Bereitschaftsmeldung Hubdrehtisch ist zur bernahme eines Teils bereit TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 159 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache 38 BOOL VAR_GLOBAL Fbelt_run_table das Startsignal Zuf hrband soll Teil auf Tisch bef rdern TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 39 BOOL VAR_GLOBAL Fbelt_done_give die Fertigmeldung Zuftihrband hat Teil auf Tisch abgelegt TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt Formale Spezifikation mit dem SFS Editor gt gt gt Satz 27 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Automatikbetrieb ist und die Fertigmeldung Kran hat eine Rohteil auf das Zuf hrband gelegt ist g
84. zur Ubernahmebereit schaft ben tigt F r den Lade bzw Entladevorgang werden separate Startsignale vereinbart 166 Anhang Variablen zur Kommunikation mit dem Roboter Technische Bezeichnung Variable Datentyp Kommentar Meldung Presse bereit zur Press_rdy_take Bool bernahme eines Rohteils Startsignal Presse beladen Robot_run_load Bool Meldung Presse bereitzur Press_rdy_give Bool bergabe eines Fertigteils Meldung Ablageband fertig Dbelt_rdy_take Bool zur bernahme eines Teils Startsignal Presse entladen Robot_run_unload Bool Startsignal Mixbetrieb Robot_run_mix Bool Meldung Roboter wartet vor Robot_wait_mix Bool Presse Startsignal Weiter im Mix Robot_run_cont Bool Fertigmeldung Presse bela Robot_done_load Bool den Fertigmeldung Presse entla Robot_done_unload Bool den Fertigmeldung Roboter hat Robot_done_dbelt Bool Band beladen Tabelle 21 Datenebene 3 Variablen zur Kommunikation mit dem Roboter 44 BOOL VAR_GLOBAL Press_rdy_take die Bereitschaftsmeldung Presse ist f r Beladung bereit TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 345 BOOL VAR_GLOBAL Robot_run_load das Startsignal Roboter bel dt Presse TRUE_I gesetzt FALSE_I nicht gesetzt
85. zwischen den Beteiligten an einer technischen Aufgabenstellung soll erm glicht werden Die Mitarbeiter kommen hierbei oft mals aus unterschiedlichen technischen Bereichen und haben deshalb auch einen verschiedenartigen technischen Hintergrund 2 Die Darstellung der Anforderungen in verschiedenen Stufen des Ent wicklungsprozesses soll mit einem einzigen Hilfsmittel durchf hrbar sein In den einzelnen Phasen eines Projektes gibt es abweichende Anforderungen an ein Beschreibungsmittel 3 Das Beschreibungsmittel soll die Darstellung von Anforderungen die mit den bereits bekannten Mitteln nicht darstellbar sind erm glichen Momentan ge br uchliche Darstellungsformen in der Steuerungstechnik erlauben nur die Darstellung des gew nschten Verhaltens wogegen die Darstellung uner w nschten Verhaltens nicht m glich ist 1 2 Parameter der Softwarequalit t Ebenso wie f r andere technische Systeme ist der Begriff der Qualit t auch auf Soft ware und somit auch auf die in dieser Arbeit betrachteten Steuerungsprogramme anwendbar Qualit t wird bereinstimmend definiert als die Gesamtheit von Merk malen einer Einheit bzw eines Systems bez glich ihrer Eignung festgelegte und vorausgesetzte Erfordernisse zu erf llen Auch in Bezug auf Software lassen sich Merkmale und Parameter identifizieren de ren Erf llung bzw Nichterf llung Aussagen ber die Qualit t der betrachteten Soft ware gestattet Die folgende bersicht f hrt
86. 00x auf die Verbesserung der industriellen Produktion ab Sie ist in den vergangenen Jahren zu einem werbewirksamen de facto Qualit tssymbol der Industrie geworden Die ISO 900x Normen legen allgemeing ltigen Anforderun gen an die Aufbau und Ablauforganisation von Unternehmen fest sie definieren Do kumente und deren Inhalte Durch sie wird die Regelung von Zust ndigkeiten Ver antwortlichkeiten Befugnissen gef rdert Die ISO 9000 1 enth lt eine allgemeine Einf hrung und einen Leitfaden zur Auswahl und Anwendung der weiteren Normen ISO 9001 beschreibt Modelle zur Darlegung der Qualit tssicherung in Design und Entwicklung Produktion Montage und Kun dendienst Die ISO 9002 definiert Modelle zur Darlegung der Qualit tssicherung in Produktion und Montage ISO 9003 beschreibt die Qualit tssicherung in der End pr fung Herauszuheben ist die Teilnorm ISO 9000 3 sie stellt eine Richtlinie zur Anwendung der ISO 9001 f r die Entwicklung Lieferung und Wartung von Software dar Der Nachweis der Konformit t eines Unternehmens zur ISO 900x erfolgt durch eine externe Zertifizierung Das Total Quality Management TQM kann man als eine Erweiterung der ISO 900x ansehen TQM wird definiert als eine auf der Mitwirkung aller ihrer Mitglieder basierende F hrungsmethode einer Organisation die Qualit t in den Mittelpunkt stellt und durch Zufriedenheit der Kunden auf langfristigen Gesch ftserfolg sowie auf Nutzen f r die Mitglieder der Org
87. 1 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Zufiihrbands 21 ist dann muss die Zustandsvariable des Zufiihrbands unmittelbar auf 0 gesetzt werden AG rdy_in amp Fbelt_state 21 gt Al rdy_plc U rdy_plc amp Fbelt_state 0 Informelle Spezifikation weiterer Anforderungen Sicherheitskritische Punkte Satz 102 bergabe auf Hubdrehtisch Formale Spezifikation mit dem SFS Editor gt gt gt Satz 102 lt lt lt einfaches Verbot Zustand Wenn die Lichtschranke am Ende des Zuf hrbands unterbrochen ist und die Bereitschaftsmeldung Hubdrehtisch ist zur bernahme eines Teils bereit ist nicht gesetzt dann darf der Antrieb des Zufiihrbands nicht gleichzeitig gestartet sein AG rdy_plc amp LB_at_fbelt amp Table_ready_take amp FBelt_start 196 Anhang A 7 6 Ger teebene 3 Steuerung des Hubdrehtischs Die Steuerung des Hubdrehtischs erh lt von der bergeordneten Zellensteuerung Startsignale zur Ausf hrung bestimmter Aktionen Durch verschiedene Sensoren und Aktoren ist die Steuerung des Hubdrehtischs mit den Maschinenelementen verbun den Gegebene Daten Technische Bezeichnung Variable Datentyp Kommentar Fertigmeldung Tisch bereit Table_rdy_take Bool Tisch ist zu Entge zur bernahme gennahme eines Teils bereit Startsignal Heben Dre
88. 1996 Rust H Zuverl ssigkeit und Verantwortung Die Ausfallsicherheit von Programmen DUD Fachbeitr ge Nr 21 Vieweg Verlag 1994 Sche00 Schr92 Somm97 Star92 Stet87 St lgs Stru91 Tres00a Tres00b Varp95 VDI2180 VDI3542 VDI3694 Wehr96 West01 Literatur Sched P Nahtlos von der Spezifikation zum Code Modellba sierte Entwicklung von Kfz Steuerger ten Elektronik Automotive 2000 Schr fer E VDI Lexikon Me und Automatisierungstechnik Springer Verlag Berlin Heidelberg 1992 Sommerville l Software Engineering Addison Wesley Harlow England 1997 Starke P H INA Integrated Net Analyser Manual Berlin 1992 Stetter F Softwaretechnologie Eine Einf hrung Reihe Informa tik Band 33 Wissenschaftsverlag Mannheim Wien Z rich 1987 St lzl S Isermann R Rieth P Nell J Methodik zur Erarbei tung von berwachungsverfahren f r sicherheitskritische verteilte Echtzeitsysteme GMA Kongress Ludwigsburg 18 19 06 1998 VDI Berichte Nr 1397 1998 StruB P Wissensreprasentation Oldenbourg Verlag M nchen 1991 Treseler H Bauer N Kowalewski S Verification of IL pro grams with an explicit model of their PLC execution 5 Workshop on Discrete Event Systems WODES August 2000 Treseler H Bauer N Kowalewski S Model Checking von AWL Programmen Fachtagung Vertei
89. 28 Materialfluss in der ProduktionsZelle nenn 88 Abbildung 29 Fehlerbaumanalyse f r die Kollision des Roboters mit der Presse 95 Abbildung 30 Betriebsartensteuerung der Produktionszelle ssnsnssnnnnneeeeeennne 152 Abbildung 31 Arbeitsmodi des Poboiers nnna 165 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Tabellen Tabelle 1 Schl sselw rter zur Formulierung der Anforderungskategorien 42 Tabelle 2 Auflistung weiterer Schl sselw rter nennen 42 Tabelle 3 Matrix aus Modalkategorie und abstraktem Beobachtungsintervall 44 Tabelle 4 Matrix aus automatisierungstechnisch relevanten Kategorien und Beobachtungsintervallen unn 47 Tabelle 5 Verwendung der Kategorien der Sicherheitsfachsprache 47 Tabelle 6 Abh ngigkeit des Wahrheitsgehaltes einer Aussage vom Zeitpunkt der Belrachtungsee beer ee ee ea 52 Tabelle 7 Beispiele f r Temporaloperatoren uuss4444444nnnnnnnnnnnnnnnnnnnnnnnnn 52 Tabelle 8 Definition von Beobachtungsvariablen 44444440nennnnnn nennen 54 Tabelle 9 Datenebene 1 Datensatz Produktonsauftrag 140 Tabelle 10 Datenebene 2 Datensatz Transportauftrag ruunsss seen 142 Tabelle 11 Datenebene 2 Bereitschaftsmeldungen der Produktionszellen 143 Tabelle 12 Datenebene 2 Fertigmeldungen der Produktionszellen 143 Tabelle 13 Datenebene 2
90. 4 Anforderungen an ein formales Beschreibungsmittel ben was das System tun soll manchmal auch was es nicht tun soll Die nichtfunk tionalen Anforderungen beschreiben weitere Bedingungen die erf llt werden m s sen wie z B die Gestaltung des Entwicklungsprozesses das Einhalten von Normen usw Hierdurch bestimmen sich auch die Validierungskriterien des Systems zum einen die Eigenschaften die vom System erwartet werden fehlerfreies Verhalten und zum anderen nicht erw nschte Eigenschaften deren Abwesenheit zu berpr fen ist Flei97 2 4 1 Das Pflichtenheft Bei der Festlegung der gew nschten Eigenschaften eines Produktes unterscheidet man zwischen der Anfertigung eines Lastenheftes und eines Pflichtenheftes Das Lastenheft ist vom Auftraggeber vollst ndig und widerspruchsfrei zu erstellen Es enth lt eine Zusammenstellung aller Anforderungen des Auftraggebers hinsichtlich Liefer und Leistungsumfang also das Was und Wof r Das Pflichtenheft wird vom Auftragnehmer unter Beachtung der im Lastenheft genannten Anforderungen erstellt Es enth lt die Beschreibung der Realisierung aller Anforderungen des Las tenheftes also das Wie und Womit Das Pflichtenheft zu einem Steuerungspro gramm muss alle Informationen enthalten die f r die vollst ndige eindeutige und korrekte Beschreibung aller Funktionen des Programms notwendig sind Die VDI3694 legt den Aufbau eines Pflichtenheftes fest siehe auch Balz96
91. 98b Die Spezifikation der Eigenschaften und Annahmen erfolgt mit nat rlichsprachlichen Schablonen IMMER GILT SOLANGE GILT NIE GILT in die mit Programmvariablen gebil dete Ausdr cke eingesetzt werden alle_spindeln_aus 1 Diese Verifikations methode wurde in HiGraph eingebettet und bot die M glichkeit zur Generierung einer Widerlegungssequenz und zur Darstellung der Variablenzustande f r jeden SPS Zyklus In Canv97 wird das System VSE Verification Support Environment beschrieben ein Werkzeug zur formalen Spezifikation und Verifikation von sicherheitsrelevanten Softwaresystemen Dieses entstand im Auftrag des Bundesamtes f r Sicherheit in der Informationstechnik und umfasst neben Spezifikations und Verifikationswerk zeugen auch die zugeh rige Entwicklungsmethodik f r Systeme mit Sicherheitsver 23 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache antwortung Die Sicherheitsanforderungen dieser Systeme k nnen formal spezifiziert und deren Einhaltung mathematisch nachgewiesen werden Anschlie end kann Pro grammcode in Ada oder C generiert werden Innerhalb des Systems VSE erfolgt die Erstellung eines Sicherheitsmodells sowie eines Funktionsmodells des untersuchten Systems Die Beschreibung wird mit der Spezifikationssprache VSE SL vorgenom men Kowalewski et al arbeiten ebenfalls mit einer modellbasierten Verifikation Kowa96 und Kowa01 Die zu untersuchenden Steuer
92. 997 Cottbus Dez 1997 26 Seiten 1997 Hein97b Heiner M Menzel T Petri Netz Semantik f r de SPS Anwen derprogrammiersprache Anweisungsliste BTU Bericht Reihe Informatik I 20 1997 Cottbus 1997 Hein99 Heiner M Menzel T Modellierung und Analyse von SPS Anwenderprogrammen mit Petri Netzen EKA 99 6 Fachtagung 247 265 Braunschweig 1999 Hein00a Heiner M Menzel T Time related modelling of PLC systems with time less Petri nets Proc WODES 2000 275 282 2000 Hein00b Heiner M Mertke T Menzel T Safety Knight Methoden und Werkzeuge zur Verifikation von SPS Anwenderprogrammen SPS IPC DRIVES N rnberg November 2000 Hein01 Heiner M Mertke T Deussen P A safety oriented Technical Language for the Requirement Specification in Control Engineer ing in deutsch Computer Science Reports 09 01 May 2001 65 pages 106 Heri92 Hofm00 Hogr89 H lz96 H lz98a H lz98b Hore89 Hube97 IEC1131 IEC1508 J rn96 Kasp94 Kohr91 Kohr93 Literatur Hering E Software Engineering Vieweg Verlag Braunschweig 1992 Hofmann P Fasolt J Geretschl ger P Sakretz R Wohlge muth F Automotive UML eine neue objektorientierte Entwick lungstechnik Elektronik Automotive 2000 Hogrefe D Estelle LOTOS und SDL Standard Spezifikations sprachen f r verteilte Systeme Springer Ve
93. ADEMOOI EE 51 3 2 2 Lemporale Bee EE 52 32 3 COMpPULALION Ree e 53 3 2 4 Darstellung der Anforderungskategorien in CTL Formeln 54 4 Prototypische Realisierung und Einsatz der Sicherheitsfachsprache 63 4 1 Technische Umsetzung Aufbaustruktur uuuursesssssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 63 4 2 Erstellung von Programmanforderungen mit dem SFS Editor 64 4 3 berf hrung der Programmanforderungen in CTL Formeln s sas212122 67 SN EE 67 4 3 2 COMPIE EE 69 4 4 Bildung von Verbalphrasen durch Interpretation der SPS Variablen 69 4 5 Nutzung der Sicherheitsfachsprache f r Verifikation oder Synthese 74 4 6 Systematische Erstellung von Sicherheitseigenschaften 74 5 Validierung des Prototypen anhand einer Fallstudie 4ss00000000 77 5 1 Einf hrung in die Fallstudie uunnnnssssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 77 5 1 1 Die Gesamtanlage runs areas aha 77 5 1 2 Das LESSER 78 5 1 3 Die Materiallager sii presoari 78 5 1 4 Die ProdukiionS elle Trisin aaa aE AE 78 5 2 Erl uterungen zur Vorgehensweise bei der Spezifikation 80 5 3 Ausf hrung der Spezifikation uuruussssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 82 5 3 1 Ger teebene 1 Die Auftragsvenawalung nennen 83 5 3 2 Ger teebene 2 Steuerung der Produktionszelle 1
94. AG n 1Aln 0U FAAFn 1 mit ro V z sat Bo r V z sat B Kategorie PRs3 einfaches Verbot Selbstbegrenzt Analyseinhalt Es wird gefordert dass eine bestimmte Folgerung nicht ausgef hrt werden darf solange gleichzeitig eine bestimmte Bedingung erf llt ist Das Beo bachtungsintervall umfasst also alle Zust nde in denen die Bedingung erf llt ist Dieser Umstand entspricht jedoch auch der Kategorie PRs1 einfaches Verbot Zu stand Die benutze Formel ist deshalb dieselbe AG rdy_plc a B gt F bzw wiederum AG rdy_plc Ba F 61 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Kategorie POe3 erweiterte Moglichkeit Selbstbegrenzt Analyseinhalt Innerhalb dieser Anforderungskategorie wird gefordert dass eine be stimmte Folgerung E nur dann ausgef hrt werden darf solange gleichzeitig auch eine festgelegte Bedingung erf llt ist Das Beobachtungsintervall wird also durch alle Zust nde gebildet in denen die Bedingung erf llt ist Bei Invertierung des Beobach tungsintervalls bedeutet dies dass die bezeichnete Folgerung nicht ausgef hrt wer den darf wenn die Bedingung nicht erf llt ist Dieses Verhalten kann auf die Katego rie POe1 erweiterte M glichkeit Zustand zur ckgef hrt werden AG rdy_plc a F gt B bzw AG rdy_plc a B gt F bzw nach Umformung AG rdy_plc AaB A F Kategorie DEe3 erweiterte Forderung Selbstbegrenzt Analyseinhal
95. Abbildung erfolgt in mehre ren Schritten 1 Aus der gegebenen Realit t wird in einem Erkenntnisprozess ein mentales Modell dieser Realit t erzeugt 2 Ein nachfolgender Abstraktionsprozess schafft ein mentales Modell des rele vanten Ausschnittes der Realit t bez glich einer spezifischen Anwendung 3 Der folgende Darstellungsprozess repr sentiert dieses mentale Modell z B mit einem nichtformalen Beschreibungsmodell 4 In einem Formalisierungsprozess erfolgt die formale Repr sentation d h die berf hrung in ein formales Modell 5 Im Programmspezifikationsprozess werden die Spezifikationsdaten definiert 6 Im abschlie enden Implementierungsprozess erfolgt die Erstellung des Pro gramms Part98 Die ersten f nf Schritte sind nichts anderes als der Spezifikationsprozess den man selbst als eine Sequenz von Aktivit ten betrachten kann die zur Entwicklung eines ersten Produkts n mlich der Spezifikation f hrt Frap01 Hierbei sind die Charak teristiken des Systems aufzustellen seine funktionalen Anforderungen Effizienzan forderungen oder auch Implementierungsanforderungen Der Aufwand f r die 26 Anforderungen an ein formales Beschreibungsmittel anschlie ende Umsetzung der hoffentlich korrekten Spezifikation in das eigentliche Programm wird allgemein als vernachl ssigbar klein beschrieben Um den Spezifikationsprozess sicherer und schneller zu gestalten und an die heuti gen Bed rfnisse sich
96. Arbeitsweise einer GP 34 Abbildung 9 bersicht ber das Verfkatlonsvertabren 39 Abbildung 10 Definition der Beobachtungsintervalle rn 46 Abbildung 11 Legende f r die folgenden Tummnodagramme 22 48 Abbildung 12 Timingdiagramme Zustand 49 Abbildung 13 Timingdiagramme Direkt nur Forderungen sind definiert 49 Abbildung 14 Timingdiagramme Gelbetbegrenzt 50 Abbildung 15 Timingdiagramme Fremdbegrenzt nnnnnnneennnn 50 Abbildung 16 Timingdiagramme Ulnbegrenzt A 51 Abbildung 17 Beobachtungsvariablen zur Identifikation des Systemzustandes 55 Abbildung 18 Struktur des Prototypen der Sicherheitsfachsprache 63 Abbildung 19 Ablauf der Erstellung von Anforderungen mit dem SFS Editor 65 Abbildung 20 Erstellung der Verbalphrasen nennen 66 Abbildung 21 Erstellung der Aniorderungss tze AAA 66 Abbildung 22 Erstellung der Bedingungen 4 4ussssnsssnnnnnnnnnnnnnnnnnnnnennnnnn 67 Abbildung 23 M glichkeiten zur Erstellung der Verbalphrasen 73 Abbildung 24 Schema der Erweiterten Produkionszelle 77 Abbildung 25 Interner Aufbau der erweiterten Produktionszelle 1 79 Abbildung 26 Ger tetechnischer Aufbau cccceeeeeeeeeeeceeeeeeeeeeeeeeeeeneeeeeeeeeeeeeees 80 Abbildung 27 Abstrakte Problemzerlegung als Funktionsbaum 82 Abbildung
97. Balz96 Hala98 beschreibt dass heute zur berpr fung der Korrektheit von Steuerungssoft ware zwei Verifizierungsschritte notwendig sind einerseits der mathematische Nachweis der Korrektheit gem der gegebenen Spezifikation andererseits m sste auch gezeigt werden dass die gegebene Spezifikation auch die mehr oder weniger vage formulierten Forderungen oder gar unausgesprochenen Gedanken des Spezifi zierers erf llt Litz98 f hrt ebenso an dass Verfahren ben tigt werden die die Erkennung von Fehlern oder Unvollst ndigkeiten in der Spezifikation unterst tzen 1 1 Softwarefehler und ihre Ursachen 1 1 1 Begriffsbestimmung Stark vereinfacht gesagt ist ein Programm dann korrekt bzw fehlerfrei wenn es sich w hrend seiner gesamten Betriebszeit also in allen Situationen denen es ausge setzt ist exakt so verh lt wie der Anwender es erwartet Der Anwender entwickelt bei der Benutzung des Programms eine gewisse Erwartungshaltung die unter ande rem auf einer bestimmten Zielvorgabe z B der L sung einer gestellten Aufgabe beruht Stimmt das aktuelle Verhalten des Programms nicht mit seiner Erwartungs haltung berein so wird im Allgemeinen von einem Programmfehler gesprochen siehe auch www rvs uni bielefeld de publications incidents und www esrin esa it htdocs tidc Press Press96 arianebrep html Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Das Fehlverhalten eines Pr
98. DE 3542 In Erweiterung zur Verifikation wird bei einer Validierung auch die Richtigkeit der Spezifikation gegen ber der urspr nglichen Aufgabenstellung berpr ft Eine Validie rung erfolgt haupts chlich durch experimentelle Verfahren und Ma nahmen zur berpr fung der Systemeigenschaften z B durch Simulationen und Tests Ein Ausfall engl failure defect kennzeichnet die Funktionsunf higkeit einer Kom ponente eines Systems VDI VDE 3542 Char92 Kr c90 Ausf lle lassen sich durch unterschiedliche Kriterien unterscheiden Ursache zuf llig deterministisch Umfang Totalausfall Teilausfall Geschwindigkeit Sprungausfall Driftausfall Er kennbarkeit Wirkung Richtung u a Ein Fehler engl error DIN 19226 ist eine unzul ssige Abweichung vom aufgaben gem en Verhalten des Systems oder einer seiner Komponenten Nichterf llung einer festgelegten Forderung Im Zusammenhang mit einem Steuerungsger t las sen sich aktive und passive Fehler unterscheiden Bei einem aktiven Fehler werden Steuerungsfunktionen ausgel st ohne dass die programmgem festgelegten Be dingungen erf llt sind Von einem passiven Fehler spricht man wenn Steuerungs funktionen blockiert sind obwohl alle programmgem festgelegten Bedingungen erf llt sind Litz98 Ein Spezifikationsfehler liegt vor wenn bereits bei der Spezifikation der Soll Eigen schaften eines Systems Fehler auftreten Sicherheit DIN 31004 ist eine Sac
99. E Gayen J T Moik A Formale Spezifikation der Steuerungssoftware einer elektrisch ortsbedienten Weiche Automatisierungstechnische Praxis 39 1997 atp 5 97 Cauvet C et al An expert System for requirement engeneering in Proc of Computer aides Information System Engineering CAISE 91 Eds R Andersen et a Trondheim 1991 Charwat H J Lexikon der Mensch Maschine Kommunikation Oldenbourg Verlag M nchen 1992 Chouikha M Schnieder E Modellbasierter Steuerungsentwurf mit Petri Netzen GMA Kongress Ludwigsburg 18 19 06 1998 VDI Berichte Nr 1397 1998 Chouikha M Jahnsen A Schnieder E Klassifikation und Be wertung von Beschreibungsmitteln f r die Automatisierungstech nik Automatisierungstechnik 46 1998 at 12 98 1998 Clarke E M Emerson E A Sistla A P Automatic Verification of finite state concurrent systems using temporal logic specifica tions ACM Transactions on Programming Languages and Sys tems Vol 8 No 2 April 1986 Clarke E M Wing J M Formal Methods State of the art and future directions Computer Science Department Carnegie Mel lon University Pittourgh ACM Press New York 1996 103 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Dali95a Dalianis H Aggregation in the NL generator of the Visual and Natural Language specification tool proc 7 International Con ference of the European
100. Folgerung F nicht erf llt sein AG rdy_plc a B gt F Diese Formel lasst sich umformen sie erhalt dadurch das typische Aussehen einer Sicherheitseigenschaft AG rdv pe Ba F Kategorie POe1 erweiterte M glichkeit Zustand Analyseinhalt Hier wird verlangt dass eine bestimmte Folgerung nur dann eintreten darf wenn gleichzeitig eine bestimmte Bedingung erf llt wird In der Umkehrung be deutet dies dass in jedem Zustand in dem zwar rdy_plc aber eine Bedingung B nicht erf llt ist die Folgerung F nicht erf llt sein darf AG rdy_plc a F gt B bzw AG rdy_plc a B gt F Nach Umformung erhalt man AG rdy_plc AaB A F Kategorie DEe1 erweiterte Forderung Zustand Analyseinhalt In jedem Zustand in dem rdy_plc und eine Bedingung B erf llt ist muss auch eine Folgerung F erf llt sein Zus tzlich darf in jedem Zustand in dem zwar rdy_plc aber die Bedingung B nicht erf llt ist die Folgerung F nicht erf llt sein AG rdy_plc B gt F rdy_plc a B gt F 57 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Die gezeigte Formel lasst sich umformen und vereinfachen AG rdy_plc B e rdy_plc a F AG rdy_plc gt Bo F Zeitparameter Direkt Kategorie DEs2 einfache Forderung Direkt Analyseinhalt Nach jedem Zustand in dem rdy_in und eine Bedingung B erf llt ist muss im n chstm glichen Zustand in dem rdy_plc erf llt ist auc
101. Formale Definition der Sicherheitsfachsprache Die Darstellung der formalen Syntax der Sicherheitsfachsprache erfolgt in Backus Naur Form siehe Ried83 Zur Verbesserung der bersichtlichkeit der Darstellung erfolgt die Definition in verschiedenen Abstraktionsebenen Ebene 0 Definition der Satzliste lt satzliste gt lt statement gt lt satzliste gt lt statement gt Ebene 1 Definition des Modalparameters lt statement gt lt comment gt lt DEs gt lt DEe gt erwei lt POe gt erwei lt PRs gt Ebene 2 Definition des Zeitparameters lt DES gt lt DEs1 gt lt DES2 gt lt DES3 gt selbs lt DESs4 gt lt DES5 gt ZZ F lt DEe gt lt DEel gt lt DEe2 gt lt DEe3 gt lt DEe4 gt lt DEe5 gt lt POe gt i lt POel gt lt POe3 gt lt POe4 gt lt POe5 gt lt PRs gt lt PRs1 gt lt PRs3 gt lt PRs4 gt lt PRs5 gt lt comment gt undefined einfache Forderung terte Forderung terte M glichkeit einfaches Verbot Zustand direkt tbegrenzt fremdbegrenzt unbegrenzt 117 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Ebene 3 Aufteilung in Satzvarianten ab hier beruhen die Anforderungssatze auf gleiche CTL Formeln _pl Pluralkonstruktion _for_ forward Vorw rtskonstruktion _back_
102. Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Von der Fakult t f r Mathematik Naturwissenschaften und Informatik der Brandenburgischen Technischen Universit t Cottbus zur Erlangung des akademischen Grades Doktor der Ingenieurwissenschaften Dr Ing genehmigte Dissertation vorgelegt von Diplom Ingenieur Thomas Mertke geboren am 01 06 1969 in W Pieck Stadt Guben jetzt Guben Gutachter Prof Dr Ing Monika Heiner Gutachter Prof Dr Ing Ulrich Berger Gutachter Prof Dr Ing Hans Michael Hanisch Tag der m ndlichen Pr fung 24 Oktober 2003 Vorwort Die Grundlagen zu dieser Arbeit entstanden wahrend meiner Tatigkeit am Lehrstuhl Automatisierungstechnik der Brandenburgischen Technischen Universitat Cottbus Ein besonderer Dank gilt deshalb dem damaligen Lehrstuhlinhaber Herrn Prof Dr Ing H Meier sowie Frau Prof Dr Ing M Heiner f r die Initiierung des zugrunde liegenden Forschungsprojekts und die wissenschaftliche Betreuung der Arbeit Herrn Prof Dr Ing U Berger dem jetzigen Lehrstuhlinhaber danke ich f r die Ubernahme der Betreuung gerade in der letzten Phase der Arbeit Ein weiterer Dank gilt den Herren T Menzel und P Deussen die gerade im Bereich der Informationstechnik und der Temporalen Logik viele notwendige und n tzliche Hinweise geben konnten Die Zusammenarbeit zwischen der klassischen Automa tisierungstechnik und der Informatik hat hier zu vielen neuen und wertvoll
103. G rdy_plc amp Table_ready_take amp Fbelt_run_table gt gt gt Satz 32 lt lt lt einfaches Verbot Zustand das Startsignal Zuf hrband soll Teil auf Tisch bef rdern darf nicht gleichzeitig gesetzt sein wenn die Bereitschaftsmeldung Zufiihrband ist zur bergabe bereit nicht gesetzt ist AG rdy_plc amp Fbelt_ready_give amp Fbelt_run_table 161 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache A 7 2 4 Kommunikation mit dem Hubdrehtisch Informelle Spezifikation Der Hubdrehtisch dient dazu die Rohteile die durch das Zuf hrband auf dem Hub drehtisch abgelegt wurden in eine Position zu bringen von der sie durch den Robo ter bernommen werden k nnen Nachdem der Roboter das Rohteil vom Hubdreh tisch entnommen hat muss sich dieser wieder in seine Ausgangsposition zur ckbe wegen Der Hubdrehtisch kann nicht selbst erkennen wenn er mit einem Teil beladen wurde er muss deshalb von der zentralen Steuerung ein Startsignal bekommen Au erdem ben tigt er ebenso ein Startsignal wann der Roboter das Rohteil wieder vom Tisch genommen hat und er sich wieder in seine Ausgangsposition bewegen kann Auch der Transportvorgang durch den Hubdrehtisch kann wieder in zwei Phasen unterteilt werden 1 Anheben und Drehen des beladenen Tisches 2 Absenken und Zur ckdrehen des leeren Tisches Definition neuer Daten mit dem SFS Editor Die Meldung dass das
104. Im ein fachsten Fall entstehen Fehler durch Schreibfehler bei der Codierung des Pro gramms d h es werden Variablen falsch geschrieben hnlich lautende Variablen namen werden vertauscht oder es werden unbewusst falsche Programmoperationen niedergeschrieben Viele dieser syntaktischen Probleme lassen sich durch eine ge eignete Unterst tzung bei der Programmierung aufdecken und vermeiden z B durch geeignete Compilerroutinen oder Inspektion des Codes Bestimmte Problemstellungen f hren interessanterweise bei vielen Programmierern zu Unsicherheiten und Fehlern vor allem wenn es darum geht mit Situationen um zugehen mit denen sie nicht gen gend vertraut sind z B selten benutzte physikali sche Gr en oder Einheiten inverse Problemstellungen mehrdeutige Beschreibun gen D Hablawetz nennt in HabI98 folgende Ursachen f r mangelnde Software Qualit t deutlich gestiegener Aufgaben und Programmumfang falsche oder unvollst ndige Spezifikation unzureichender Ausbildungsstand im Software Engineering zu geringer Informationsaustausch zwischen den an Projekten beteiligten Ab teilungen mangelnde oder unvollst ndige Dokumentation unzureichendes und unsystematisches Testen ohne vorher klar definierte Testf lle Einleitung und Ausgangssituation Die Deutsche Gesellschaft f r Qualit t bekr ftigt in DGQ92 diese Aufstellung in dem sie als Ursachen f r Software Qualit tsprobleme schlechte Planung schlecht
105. L VAR_GLOBAL Fbelt_rdy_take die Bereitschaftsmeldung Zuftihrband ist zur bernahme eines Teils bereit TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 6 32 BOOL VAR_GLOBAL Crane_run_source das Startsignal Kran holt Rohteil vom Eingangspuffer TRUE_I gesetzt 156 Anhang FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 33 BOOL VAR_GLOBAL Crane_done_give_fbelt die Fertigmeldung Kran hat ein Rohteil auf das Zuf hrband gelegt TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt Formale Spezifikation mit dem SFS Editor gt gt gt Satz 23 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Automatikbetrieb ist und der Eingangspuffer ist belegt und die Bereitschaftsmeldung Zuf hrband ist zur bernahme eines Teils bereit ist gesetzt dann muss die Bereitschaftsmeldung Zuf hrband ist zur ber nahme eines Teils bereit unmittelbar zur ckgesetzt werden und das Startsignal Kran holt Rohteil von Eingangspuffer muss unmittelbar gesetzt werden AG rdy_in amp cell_l_state 1 amp Piece_at_source amp Fbelt_rdy_take gt Al rdy_plc U rdy_plc amp Fbelt_rdy_take amp Crane_run_source Weite
106. Linksdrehung des Hubdrehtischs TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gestartet FALSE_O gestoppt 79 BOOL VAR Table_right die Rechtsdrehung des Hubdrehtischs TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gestartet FALSE_O gestoppt 80 BOOL VAR Table_upward das Anheben des Hubdrehtischs TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gestartet FALSE_O gestoppt 81 BOOL VAR Table_downward das Absenken des Hubdrehtischs TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gestartet FALSE_O gestoppt 198 Anhang Informelle Spezifikation Die Steuerung des Hubdrehtischs verbleibt solange in Ruhe bis durch die Zellen steuerung entweder das Startsignal zum Heben und Linksdrehen oder zum Absen ken und Rechtsdrehen erfolgt Danach wird die geforderte Bewegungsroutine bear beitet Es sind zwei separate Routinen zu unterscheiden die alternativ voneinander ablaufen k nnen Die innerhalb dieser Routinen abzuarbeitenden Teilvorg nge sind wiederum unbedingt in der festgelegten Reihenfolge abzuarbeiten es bietet sich wiederum die Entwicklung einer Ablaufstruktur an Definition neuer Daten mit dem SFS Editor Interne Variablen der Steuerung des Hubdrehtischs Technische Bezeichnung SPS Variable Datentyp Kommentar Zustandsvariable des Hubdrehtischs Table_statel Integer
107. Sie wurde gew hlt um verschiedene typische Automatisierungsstrukturen aufzuzeigen und die weitreichen den Anwendungsm glichkeiten der Sicherheitsfachsprache zu demonstrieren Die Beschreibung der Gesamtanlage ist bis zu diesem Zeitpunkt sehr informell Au Ber einer ungef hren Ahnung von der gew nschten Funktionsweise der Gesamt anlage sind kaum konkrete Anforderungen an die einzelnen Elemente und erst recht keine Informationen ber auszutauschende Daten vorhanden Die Zusammenh nge Abl ufe und die informationstechnischen Verbindungen werden sukzessive nach der Top Down Methodik aufgebaut In diesem Zusammenhang werden schrittweise die konkreten Programmanforderungen formuliert und weitere Daten Bereitschafts Fertigmeldungen sowie Koppelsignale erzeugt Dabei wird nach dem folgenden Schema vorgegangen vgl Abbildung 19 1 Zusammenstellung der gegebenen Daten aus der bergeordneten und falls bereits bekannt der untergeordneten Datenebene 2 informelle Spezifikation Darstellung der technisch technologische Anforderun gen 3 falls notwendig erfolgt die Definition neuer Daten aus der informellen Spezifikation 4 formale Spezifikation der Anforderungen mit der Sicherheitsfachsprache Die Punkte 2 bis 4 sind dabei wenn notwendig mehrfach zu durchlaufen Speziell bei einer Programmsynthese ist oftmals ein iteratives Vorgehen notwendig Die Anwendung des gezeigten Schemas auf die Fallstudie bringt den folgenden
108. Spezifikationsablauf 1 Zusammenstellung der gegebenen Daten aus der Datenebene 1 2 Spezifikation der Ger teebene 1 Auftragsverwaltung dabei sukzessive Definition von neuen Daten der Datenebene 2 Transport auftrag Kommunikation mit Transportsystem und Produktionszellen 3 Spezifikation der Ger teebene 2 Mastersteuerung Produktionszelle 1 dabei sukzessive Definition von neuen Daten der Datenebene 3 Start und Fertigmeldungen der dezentralen Steuerungen MMI Daten 4 Spezifikation der Ger teebene 2 Transportsystem 5 Spezifikation der Ger teebene 3 Einzelsteuerungen der Zellenkomponenten wie Kran Transportb nder etc dabei sukzessive Definition der verwendeten Aktor und Sensordaten 81 Validierung des Prototypen anhand einer Fallstudie 5 3 Ausf hrung der Spezifikation Das Problem wird nun schrittweise unter Beachtung der technischen und technologi schen Gegebenheiten zerlegt Aus Platzgr nden wird innerhalb dieser Arbeit auf eine vollst ndige Spezifikation des Gesamtsystems verzichtet auf den folgenden Seiten wird lediglich das grunds tzliche Vorgehen dargestellt Dar ber hinaus gehende In formationen k nnen dem Anhang A 6 entnommen werden Die Abbildung 27 zeigt wie in Analogie zum ger tetechnischen Aufbau die technologische Aufgabenstellung in den einzelnen Ebenen zerlegt verfeinert und pr zisiert werden kann aus Platzgr nden wurde die Darstellung um 90 gekippt die oberste Ebene ist jet
109. System eigent mlichen Gesetzm ig keiten beeinflussen Hierzu z hlen alle Ma nahmen zur gerichteten und planm i gen Beeinflussung von Abl ufen und Prozessen um ein vorgegebenes Sollziel zu erreichen Schr92 Die Berechnungsvorschrift nach der das Steuern stattfindet wird als Steueralgorithmus bezeichnet Das Steuerger t bzw das Automatisierungsger t ist das Betriebsmittel das die Steuerungsaufgaben bearbeitet Schr92 Es stellt die technische Realisierung der Steuereinrichtung dar Oftmals wird auch der Begriff der Steuerung synonym ver wendet ein typisches Automatisierungsger t ist eine Speicherprogrammierbare Steuerung SPS engl PLC 114 Anhang Anforderungen engl requirements sind qualitative und oder quantitative Festle gungen der Eigenschaften eines Produkts Die Spezifikation engl specification ist ein Dokument das die Anforderungen bzw Merkmale eines Produkts oder einer Dienstleistung festlegt DIN 66255 Sie enth lt Aussagen zu Qualit tsanforderungen Gebrauchstauglichkeit Sicherheit Abmes sungen usw des Produkts Die Spezifikation stellt eine generalisierte Bedarfsanfor derung dar DGQ98 Gl e98 Eine Spezifikation eines Programms ist eine Formu lierung dessen was ein Programm tun soll Man kann hierbei eine externe und eine interne Spezifikation unterscheiden Die externe Spezifikation ist eine informelle meist verbale Beschreibung des Programmverhaltens also ein Katalog von Anfor de
110. TRUE_O gesetzt FALSE_O zur ckgesetzt 346 BOOL VAR_GLOBAL Robot_done_load die Fertigmeldung Roboter hat Teil in Presse gelegt TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 167 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Robot_done_unload die Bereitschaftsmeldung ils bereit W gese W gesetzt die Bereitschaftsmeldung ur bernahme eines Teils bereit W gese W gesetzt das Startsignal W gese W gesetzt 47 BOOL VAR_GLOBAL Press_rdy_give bergab ines T TRUE_I gesetzt FALSE_I nicht TRUE_O gesetzt FALSE_O zur ck 48 BOOL VAR_GLOBAL Dbelt_rdy_take Z TRUE_I gesetzt FALSE_I nicht TRUE_O gesetzt FALSE_O zur ck 49 BOOL VAR_GLOBAL Robot_run_unload Presse TRUE_I gesetzt FALSE_I Hache TRUE_O gesetzt FALSE_O zur ck 350 BOOL VAR_GLOBAL die Fertigmeldung Presse genommen TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 51 BOOL VAR_GLOBAL Robot_done_dbelt die Fertigmeldung Ablageband gelegt TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur
111. Zuf hrband ER Bedienelemente Anzahl EI Anlage bereit Anzahl e Eingang ET Automatik l uft Ausgang Re Start Not Aus Hubdrehtisch Abbildung 25 Interner Aufbau der erweiterten Produktionszelle 1 Zu erkennen sind der bereits beschriebene Eingangspuffer und der Ausgangspuffer Der Kran holt die Rohteile vom Eingangspuffer und legt sie auf dem Zuf hrband ab Ebenso nimmt er die Fertigteile vom Ablageband und transportiert sie zum Ausgangspuffer Alle anderen Bauelemente und Transportvorg nge entsprechen den bereits dargestellten Vorgaben der Produktionszelle Die folgenden Bedien und Anzeigeelemente wurden hinzugef gt Anzeige f r die Anzahl der Teile die dem Eingangspuffer entnommen wurden Anzeige Anlage bereit Anzeige Automatik l uft Anzeige f r die Anzahl der Teile die im Ausgangspuffer abgelegt wurden Re Start Taster zum Wiederanlauf nach Not Aus nichtrastend Not Aus Schalter rastend nullaktiv Anzeige Not Aus in Not Aus Schalter integriert Mit diesen Darstellungen sind die konstruktiven Gegebenheiten der Produktions zelle 1 und der Gesamtanlage ausreichend beschrieben auf weitere Bedien und Anzeigeelemente wird aus Gr nden der bersichtlichkeit verzichtet 79 Validierung des Prototypen anhand einer Fallstudie 5 2 Erlauterungen z
112. Zuf hrband ein Rohteil auf dem Tisch abgelegt hat existiert bereits Es wird ein Signal definiert dass die Positionierung gestartet werden kann Der Hubdrehtisch muss die Beendigung der Positionierung melden Es wird eine Meldung ben tigt dass der Roboter das Teil vom Hubdrehtisch ge nommen hat Danach kann die R ckbewegung gestartet werden Der Hubdrehtisch muss auch die Beendigung dieser Aktion best tigen die Variable Table_ready_take ist bereits definiert Variablen zur Kommunikation mit dem Hubdrehtisch Technische Bezeichnung Variable Datentyp Kommentar Startsignal He Table_run_lift Bool ben Drehen Meldung Hubdrehtisch Table_ready_give Bool ist zur bergabe bereit Fertigmeldung Roboter Robot_done_take_table Bool hat Teil vom Tisch ge nommen Startsignal Sen Table_run_lower Bool ken Drehen Tabelle 20 Datenebene 3 Variablen zur Kommunikation mit dem Hubdrehtisch 162 Anhang 40 BOOL VAR_GLOBAL Table_run_lift das Startsignal Hubdrehtisch heben und links drehen TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 6641 BOOL VAR_GLOBAL Table_rdy_give die Bereitschaftsmeldung Hubdrehtisch ist zur bergab ines Teils bereit TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur
113. _forward arm2_forward arm2_forward larm1 forward 15 larm1_mag_on 25 larm2_mag_on 35 arm2_mag_on 42 larm1_mag on arm1_backward arm2_backward arm2_backward arm1 backward arm1_ext 0 0 arm2_ext 0 0 arm2_ext 0 0 ami ext 0 0 Peeka larma backward larm2_backward arm t_oackwari arm2_backwari robot_done_unload larm1_backward 16 Q robot_done_load 26 Q robot_done_dbelt 36 Tet 43 true Formale Spezifikation mit dem SFS Editor robot_left robot_angle 70 robot_done_load true gt gt gt Satz 118 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 0 ist und das Startsignal Roboter belddt Presse ist gesetzt dann muss das Startsignal Roboter belddt Presse unmittelbar zuriickgesetzt werden und die Zustandsvariable des Roboters muss unmittelbar auf 1 gesetzt werden und die Drehung des Roboters nach rechts muss unmittelbar gestartet werden AG rdy_in amp Robot_state 0 amp Robot_run_load gt Al rdy_plc U rdy_plc amp Robot_run_load amp Robot_state 1 amp Robot_right gt gt gt Satz 119 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 0 ist und das Startsignal Roboter entl dt Presse ist gesetzt dann muss das Startsignal Roboter entl dt Presse unmittelbar zur ckgesetzt werden und die Zustandsvariable des Roboters muss unmittelbar auf 2 gesetzt werden und die Drehung des Robot
114. achsprache wurde nicht losgel st in einem Einzelprojekt erarbeitet vielmehr ist sie Bestandteil eines Forschungsprojektes Hein97a Meie98 Hein00b das sich mit der Entwicklung von Methoden und Werkzeugen zur Zertifi zierung von SPS Anwenderprogrammen besch ftigt Ziel dieses Forschungsprojek tes ist es bekannte Methoden und Verfahren zur Programmverifikation aus der In formatik auf den speziellen Bereich der Steuerungstechnik zu adaptieren Im erw hnten Forschungsprojekt wurde speziell das Model Checking Verfahren aus gew hlt dieses gliedert sich ebenso wie das Gesamtprojekt in zwei Hauptbereiche Abbildung 9 Die notwendigen Grundlagen f r eine Verifikation durch Model Che cking sind das Vorhandensein eines Modells des zu analysierenden Systems linker Bereich der Abbildung sowie eine formale Spezifikation der Funktions und Sicher heitseigenschaften die durch dieses System erf llt werden sollen rechter Bereich der Abbildung Das zu untersuchende System besteht aus einer speicherprogram mierbaren Steuerung dem Steuerungsprogramm und der zu steuernden Anlage Das eigentliche Untersuchungsobjekt ist jedoch nur das Steuerungsprogramm auch SPS Programm Anwenderprogramm da die Anlage und die verwendete Steuerung als feste unver nderliche Komponenten angenommen werden m ssen 38 Anforderungen an ein formales Beschreibungsmittel Funktions und Sicherheits erungen Ungepr ftes SPS Programm
115. agebands Dbelt_state Integer Tabelle 42 Datenebene 4 Interne Variable der Steuerung des Ablagebands 104 INT VAR Dbelt_state die Zustandsvariable des Ablagebands O_I D W 0 Allen 1 Zi W 2 O_O auf 0 gesetzt 1 0 auf 1 gesetzt 2 0 auf 2 gesetzt Dbelt_run Dbelt_run 1 Dbelt_start IB at delt Dbelt_start 2 Dbelt_rdy_give Dbelt_rdy_take true Formale Spezifikation mit dem SFS Editor gt gt gt Satz 175 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Ablagebands 0 ist und das Startsignal Ablageband soll Teil transportieren ist gesetzt dann muss das Startsignal Ablageband soll Teil transportieren unmittelbar zur ckgesetzt werden und die Zustandsvariable des Ablagebands muss unmittelbar auf I gesetzt werden und der Antrieb des Ablagebands muss unmittelbar gestartet werden AG rdy_in amp Dbelt_state 0 amp Dbelt_run gt Al rdy_plc U rdy_plc amp Dbelt_run amp Dbelt_state 1 amp DBelt_start 225 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache gt gt gt Satz 176 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Ablagebands 1 ist und die Lichtschranke am Ende des Ablagebands ist blockiert dann muss der Antrieb des Ablagebands unmittelbar gestoppt werden und die Zustand
116. agram Editor Eine automatische Code generierung sowie eine formale Verifikation durch Model Checking mit SVE Software Verification Environment geh ren ebenfalls zum Umfang der Forschun gen Tools f r die automatische Codegenerierung stehen auch bereits f r den industriellen Einsatz zur Verf gung Besonders die Automobilindustrie ist hier ein bevorzugtes Einsatzgebiet stellt doch der st ndige Drang nach innovativen L sungen bei gleich 21 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache zeitiger Sicherung der Funktion Stichwort R ckrufaktionen eine gro e treibende Kraft dar Die Firma dSPACE bietet mit TargetLink ein Softwarepaket an mit dem eine Generierung und Optimierung von Steuerungscode der mit Matlab Simulink und Stateflow erzeugt wurde m glich ist K st00 Ebenfalls in diesem Bereich angesiedelt ist Rhapsody in MicroC Sche00 Hiermit l sst sich extrem kompakter Code f r Kfz Steuerger te mit einer grafischen Pro grammierumgebung durchg ngig von der Spezifikation bis zur Implementierung generieren Als Besonderheit wird OSEK ein Standard f r eine offene Ger tearchi tektur in der Automobilindustrie unterst tzt 1 4 3 Ma nahmen im Anschluss an die Softwareentwicklung Als abschlie endes Kapitel im Zusammenhang mit Wegen zur Erh hung der Qualit t von Software sind diejenigen Ma nahmen zu nennen die auch noch im Anschluss an die Erstellung der Software ergriffen werden k nnen
117. ame gt lt name gt lt Wertzuordnung_BOOL gt lt Wertzuordnung_INT gt ERUR 12 lt wert gt IRUE_O lt Wert gt FALSE_I lt Wert gt FALSE_O lt Wert gt lt Wertl gt _I lt Wert gt Jr lt Wert1 gt _O lt Wert gt lt Wert2 gt _I lt Wert gt lt Wert2 gt O lt Wert gt lt zahl gt 129 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache lt name gt lt zeichen gt lt zeichen gt lt name gt lt zahl gt lt ziffer gt lt ziffer gt lt zahl gt lt zeichen gt DI b DI Arr B Z 73 aA GE EES 2 99 5 S EUREN TE I an lt ziffer gt 0 Ir 9 St KK EE SS 130 Anhang A 5 Formale Definition des PreLexers Ebene a grundlegende Satzkonstruktionen DI lt statement gt Wenn lt cond_pl gt dann lt for_concl_pl gt Wenn irgendwann lt cond_pl gt dann lt for_concl_pl gt Wenn irgendwann lt cond_pl gt dann lt for_concl_pl gt bevor lt cond_pl gt DI Wenn irgendwann lt cond_pl gt dann lt for_concl_pl gt bis lt cond_pl gt DI DI Nur wenn lt cond_pl gt dann lt for_concl_pl gt Nur wenn irgendwann lt cond_pl gt dann lt for cone
118. amp Crane_state 18 amp 187 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Crane_to_dbelt gt gt gt Satz 74 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 1b ist und der Kran ist am Eingangspuffer dann muss die Bewegung des Krans nach rechts Ablageband unmittelbar gestoppt werden und die Zustandsvariable des Krans muss unmittelbar 11 werden und das Absenken des Krangreifers muss unmittelbar gestartet werden AG rdy_in amp Crane_state 17 amp Crane_at_source gt Al rdy_plc U rdy_plc amp Crane_to_dbelt amp Crane_state 11 amp Crane_lower gt gt gt Satz 75 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 11 ist und der Greifer des Krans ist auf dem Eingangspuffer dann muss das Absenken des Krangreifers unmittelbar gestoppt werden und die Zustandsvariable des Krans muss unmittelbar 12 werden und der Magnet des Krangreifers muss unmittelbar aktiviert werden und das Anheben des Krangreifers muss unmittelbar gestartet werden AG rdy_in amp Crane_state 11 amp Crane_height 0 85 gt Al rdy_plc U rdy_plc amp Crane_lower amp Crane_state 12 amp Crane_mag_on amp Crane_lift gt gt gt Satz 76 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 12 ist und der Greifer des Krans is
119. and ist zur Aufnahme eines Teils bereit Crane_run_source Kran soll Rohteil holen Die Details k nnen wieder der Tabelle 24 Anhang Seite 176 sowie der Tabelle 19 Anhang Seite 159 entnommen werden Formale Spezifikation mit dem SFS Editor gt gt gt Satz 23 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Automatikbetrieb ist und der Eingangspuffer ist belegt und die Bereitschaftsmeldung Zuf hrband ist zur bernahme eines Teils bereit ist gesetzt dann muss die Bereitschaftsmeldung Zufiihrband ist zur bernahme eines Teils bereit unmittelbar zur ckgesetzt werden und das Startsignal Kran holt Rohteil von Eingangspuffer muss unmittelbar gesetzt werden 89 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache AG rdy_in amp cell_l_state 1 amp Piece_at_source amp Fbelt_rdy_take gt Al rdy_plc U rdy_plc amp Fbelt_rdy_take amp Crane_run_source weitere informelle Spezifikationen Es ist nicht sinnvoll den Kran zu starten wenn der Eingangspuffer leer ist d h keine Rohteile vorhanden sind Au erdem darf der Kran dann auch nur gestartet werden wenn er ein Teil auf dem Zuf hrband ablegen kann Dieses muss also dazu bereit sein Formale Spezifikation mit dem SFS Editor gt gt gt Satz 24 lt lt lt erweiterte M glichkeit Zustand I das Startsignal Kran holt Rohteil vom Eingangspu
120. ane_lift Bool TRUE Greifer wird angehoben L R Crane_lower Bool TRUE Greifer wird abgesenkt Greifer Kran Crane mag on Bool TRUE Magnet eingeschaltet Tabelle 26 Datenebene 4 Aktoren des Krans 181 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache 66 BOOL VAR Crane_to_fbelt die Bewegung des Krans nach links zum zuf hrband TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gestartet FALSE_O gestoppt 67 BOOL VAR Crane_to_dbelt die Bewegung des Krans nach rechts Ablageband TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gestartet FALSE_O gestoppt 68 BOOL VAR Crane_lift das Anheben des Krangreifers TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gestartet FALSE_O gestoppt 369 BOOL VAR Crane_lower das Absenken des Krangreifers TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gestartet FALSE_O gestoppt 70 BOOL VAR Crane_mag_on der Magnet des Krangreifers TRUE_I aktiv FALSE_I nicht aktiv TRUE_O aktiviert FALSE_O deaktiviert Informelle Spezifikation Der Steuerung des Krans verbleibt solange in Ruhe bis durch die Zellensteuerung entweder das Startsignal zum Transport eines Rohteils oder eines Fertigteils gesetzt wird Danach wird die geforderte Transportroutine bearbeitet Rohteile vom Eingangspuffer holen Damit der Kran den Eingangspuffe
121. anisation und f r die Gesellschaft zielt ISO 8402 TQM ist also ein umfassendes Konzept das das gesamte Unternehmen einbezieht das die Bed rfnisse des Kunden und die Kundenorientierung in den Mittelpunkt stellt W hrend die ISO 900x berwiegend die technischen Aspekte der Arbeit und der Qualit tssicherung behandelt und in diesem Zusammenhang als relativ statisch be zeichnet werden muss betont TQM die Zusammenarbeit der Mitarbeiter zum Zweck der Erreichung der Qualit tsziele als einen st ndigen kontinuierlichen Prozess Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Das Capability Maturity Model CMM das 1987 vom Software Engineering Institut der Carnegie Mellon Universit t entwickelt wurde siehe DGQ98 und Balz98 ist rein software orientiert und bewertet den aktuellen Stand der Qualitatssicherungs ma nahmen in einem Unternehmen mit f nf Stufen Levels Level 1 Initial keine stabilen wiederholbaren Prozesse Erfolge werden durch Einzelpers nlichkeiten erzielt Level 2 Repeatable es sind wiederholbare Prozesse und etablierte Manage mentma nahmen vorhanden Level 3 Defined Standardprozesse sind etabliert Level 4 Managed Prozesse werden bewusst gesteuert Qualit tsziele sind quantifizierbar und werden durch standardisierte Verfahren gepr ft Level 5 Optimizing die Prozesse werden weiterhin verbessert Die Beurteilung ber die Erre
122. ariab len in SPS Programmen so fallen einige wenige typische Anwendungsfalle auf ohne dass die folgende Liste vollst ndig ist intern als Zustandsvariable zur Kodierung von Programmzust nden externe Sensorwerte externe Aktorwerte Die Anzahl der unterscheidbaren Zust nde eines Programms ist begrenzt so dass hier eine Erstellung der Werte f r jeden der einnehmbaren Variablenzust nde m g lich ist z_1 1 als Bedingung das Programm ist im Zustand 1 als Folgerung das Programm wird in den Zustand 1 berf hrt z_1 2 als Bedingung das Programm ist im Zustand 2 als Folgerung das Programm wird in den Zustand 2 berf hrt 71 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache In ereignisorientierten Steuerungsprogrammen in denen Integer Variablen zum Ein lesen analoger Sensorwerte bzw zum Ausgeben analoger Aktorwerte verwendet werden erfolgt in vielen Fallen eine Intervallbildung bzw Diskretisierung des verf g baren Wertebereichs Bei analogen Sensoren werden bestimmte Grenzwerte ab gefragt bei deren Uber oder Unterschreitung Aktionen auszul sen sind Auf diese Weise lassen sich relevante Werte dieser Variablen identifizieren f r die verbale Entsprechungen zu formulieren sind In diesem Zusammenhang ist auch die Benut zung von Vergleichsoperatoren m glich x_t 50 die Temperatur ist gleich 50 C x_t gt 50 die T
123. as Ausfahren des Roboterarms 2 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 35 gesetzt werden und der Magnetgreifer des Roboterarms 2 muss unmittelbar aktiviert werden und das Einziehen des Roboterarms 2 muss unmittelbar gestartet werden AG rdy_in amp Robot_state 34 amp Arm2_ext 0 79 gt Al rdy_plc U rdy_plc amp Arm2_forward amp Robot_state 35 amp Ami mag on amp Arm2_backward gt gt gt Satz 140 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 35 ist und der Roboterarm 2 ist hinten dann muss das Einziehen des Roboterarms 2 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 36 gesetzt 214 Anhang werden und die Fertigmeldung Roboter hat Teil aus Presse genommen muss unmittelbar gesetzt werden und die Drehung des Roboters nach links muss unmittelbar gestartet werden AG rdy_in amp Robot_state 35 amp Arm2_ext 0 0 gt Al rdy_plc U rdy_plc amp Arm2_backward amp Robot_state 36 amp Robot_done_unload amp Robot_left gt gt gt Satz 141 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 36 ist und der Roboter ist mit dem Arm 2 vor dem Ablageband dann muss die Drehung des Roboters nach links unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmit
124. aur Form CNC Computerized Numerical Control CPU Central Processing Unit CTL Computation Tree Logic EBNF Extended Backus Naur Form FMEA Fehler M glichkeits und Einflussanalyse engl Failure Mode and Effect Analysis MDE Maschinendatenerfassung MMI HMI Mensch Maschine Interface engl Human Machine Interface NC Numeric Control RC Robot Control SFS Sicherheitsfachsprache SPS PLC Speicherprogrammierbare Steuerung engl programmable logic controller XII Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Verwendete Symbole zur Darstellung der Temporalen Logik CTL CTL Darstellung im SFS Editor Darstellung Standard ASCll Zeichensatz Konjunktion 8 logisches Und De We E der v nicht definiert Negation l logisches Nicht E Implikation Konditional a wenn dann g Aquivalenz Bikonditional Si nur wenn dann SC ffnende Klammer Schlie ende Klammer Symbole der BNF EBNF Se nichtterminale Symbole Zuweisung S terminale Symbole Alternative Ce goa Kommentare Trennzeichen f r Aufz hlungen undefined undefinierte Zeichenketten XIV Einleitung und Ausgangssituation 1 Einleitung und Ausgangssituation Bei der heutigen kundenorientierten Fertigung von Maschinen und Anlagen stellt die Erzeugung der zugeh rigen Steuerungssoftware einen wesentlichen Zeit un
125. ause F L Heimann R Sprache zur Beschreibung von Pro duktentwicklungsprozessen Zeitschrift f r wirtschaftlichen Fab rikbetrieb 95 2000 zwf 6 2000 Kr g87 Kr ger F Temporal Logics of Programs Monographs on Theo retical Computer Science Springer Verlag 1987 Kr c90 Kr ckeberg F Spaniol O Lexikon Informatik und Kommunika tionstechnik VDI Verlag D sseldorf 1990 K rs93 K rschner W Grammatisches Kompendium Francke Verlag T bingen 1993 Lamp99 Lamperiere Couffin S Rossi O Roussel JM Lesage J J Formal validation of PLC programs a survey ECC 99 European Control Conference 1999 Karlsruhe 31 August 3 September 1999 Lamp00 Lamperiere Couffin S Lesage J J Formal Verification of the sequential part of PLC Programs 5 workshop on Discrete Event Systems WODES 2000 pp 247 254 Gent Belgium August 2000 Lemm95 Lemmer K Ober B Schnieder E Model based Programming and Diagnosis for programmable logical Controllers IEEE Inter national Conference on Systems Man and Cybernetics SMC95 Vancouver Canada 22 25 10 1995 Leve95 Leveson N G Safeware System safety and computers Addi son Wesley Publishing Company 1995 108 Lewe95 Lewe97 Lind93 Litz98 Litz99 Mann92 Mann95 McMi92 Meff99 Meie98 Meie99 MertO1 Mewe95 Mont00 Literatur Lewerentz C L
126. boters 13 ist und der Roboter ist mit dem Arm I vor der Presse dann muss die Drehung des Roboters nach links unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 14 gesetzt werden und das Ausfahren des Roboterarms 1 muss unmittelbar gestartet werden AG rdy_in amp Robot_state 13 amp Robot_angle 90 gt Al rdy_plc U rdy_plc amp Robot_left amp Robot_state 14 amp Arml_forward gt gt gt Satz 125 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 14 ist und der Roboterarm 1 ist in der Presse dann muss das Ausfahren des Roboterarms 1 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 15 gesetzt werden und der Magnetgreifer des Roboterarms 1 muss unmittelbar deaktiviert werden und das Einziehen des Roboterarms 1 muss unmittelbar gestartet werden AG rdy_in amp Robot_state 14 amp Arml_ext 0 65 gt Al rdy_plc U rdy_plc amp Arml_forward amp Robot_state 15 amp Am mag on amp Arml_backward gt gt gt Satz 126 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 15 ist und der Roboterarm 1 ist hinten dann muss das Einziehen des Roboterarms 1 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 16 gesetzt werden und die Fertigmeldung Roboter hat Teil in Pres
127. ch die Auswahl des Modal und Zeitparameters ein bestimmtes Satzmuster festgelegt siehe Anhang A 2 und A 3 Die noch bestehenden Freiraume innerhalb des Bedin gungs und des Folgerungsteils dieses Satzmusters m ssen anschlie end mit appli kationsspezifischen Verbalphrasen ausgef llt werden Bei Betrachtung der Grund struktur einer beliebigen Anforderungskategorie besteht diese zun chst aus dem konditionalen Grundmuster Konjunktion aus zwei Teils tzen und verschiedenen allgemeinen Schl sselw rtern Zeitadverbien Modalverben Zur Vervollst ndigung des Satzes fehlen gem den Grammatikregeln der deutschen Sprache weitere typische Elemente wie z B Subjekte f r die Teils tze und die zugeh rigen Pr di kate 69 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Wenn ist dann muss gleichzeitig sein Diese fehlenden Satzbausteine m ssen durch den Benutzer der Sicherheitsfach sprache durch Interpretation der gegebenen SPS Variablen und deren relevanten Werten gebildet werden Der Variablendeklarationsteil des gegebenen SPS Pro gramms mit den dort festgehaltenen Informationen ber die vorhandenen Aktor und Sensorsignale sowie die internen Variablen bildet die Grundlage f r die Erstellung der Verbalphrasen Eine Verbalphrase besteht immer aus zwei Teilen einem Nomen und einem Wert Man kann eine Verbalphrase deshalb auch als eine Nomen Wert Kombination be zeichnen Das Nomen wird dab
128. ch sind hier der Auf wand und die Fehleranf lligkeit weitaus gr er Die Erstellung der Anforderungss tze erfolgt in mehreren Stufen die in einer Vorbe reitungsphase und einer Durchf hrungsphase zusammengefasst werden k nnen siehe Abbildung 19 In der Vorbereitungsphase ist zun chst die Verf gbarkeit der ben tigten Verbalphra sen zu berpr fen Hier unterscheidet sich die Anwendung des SFS Editors inner halb einer Verifikationsumgebung von der Benutzung innerhalb eines Synthesepro zesses W hrend bei der Verifikation eines bereits bestehenden Steuerungspro gramms alle SPS Variablen festgelegt sind und aus dem Variablendeklarationsteil des Programms ausgelesen werden k nnen sind diese Variablen bei der Erstellung eines neuen Programms noch nicht bekannt und m ssen erst definiert werden Der SFS Editor ist f r die Nutzung in beiden Umgebungen geeignet SPS Variablen k n nen sowohl aus bereits vorhandenen Programmen eingelesen als auch neu definiert und editiert werden Ziel der Vorbereitungsphase ist es f r alle ben tigten SPS Vari 64 Prototypische Realisierung und Einsatz der Sicherheitsfachsprache ablen nat rlichsprachliche applikationsspezifische Verbalphrasen Nomen und Werte zu definieren Idee Informelle Spezifikation Vorbereitungsphase ben tigte SPS Variablen neue SPS Variablen vorhanden informell definieren neue SPS Variablen i ben tigte formal definieren Nomen und Werte Nomen
129. che Forderung Unbegrenzt Analyseinhalt Nach jedem Zustand in dem rdy_in und eine Bedingung B erf llt ist muss es irgendwann einen Zustand geben in dem rdy_plc und F erf llt sind Es be steht die Forderung dass das Steuerungsprogramm auf ein beim Einlesen der Sen sorwerte erkanntes Ereignis immer irgendwann reagiert Die ausl sende Bedingung muss dann jedoch nicht mehr erf llt sein Das Beobachtungsintervall beginnt mit dem 58 Die Sicherheitsfachsprache Zustand in dem beim Einlesen der Sensorwerte erstmalig die Bedingung erf llt ist AG rdy_in a B gt AF rdv plc F Kategorie PRs5 einfaches Verbot Unbegrenzt Analyseinhalt Sobald es einen Zustand gibt in dem rdy_in und eine Bedingung B erf llt werden darf es danach keinen Zustand mehr geben in dem rdy_plc und eine Folgerung F erf llt werden Diese Kategorie ist wiederum vergleichbar mit der Kate gorie DEs5 einfache Forderung unbegrenzt nur dass hierbei nach dem Erkennen des Ereignisses die beschriebene Reaktion niemals wieder eintreten darf AG rdy_in a B gt EF rdy_ plc F bzw AG rdy_in a B gt AG rdy_plc a F Kategorie POe5 erweiterte M glichkeit Unbegrenzt Analyseinhalt Bei dieser Kategorie wird gefordert dass eine bestimmte Folgerung erst dann ausgef hrt werden darf wenn vorher eine bestimmte Bedingung erf llt wurde Das Beobachtungsintervall beginnt also mit der erstmaligen Erf llung der Be dingung Kehrt man diese Anf
130. che Formeln umgewandelt werden k nnen 4 1 Technische Umsetzung Aufbaustruktur Die im Zusammenhang mit der SFS erstellten Software Tools unterteilen sich in zwei Bereiche SFS Editor ein syntaxgesteuerter Editor zur Erstellung SFS konformer Anforderungss tze Compilersequenz die aus den nat rlichsprachlichen Anforderungen CTL For meln generiert Mit dieser strikten Trennung siehe Abbildung 18 zwischen erstellenden und ber f hrenden Softwarekomponenten ist eine einfache Austauschbarkeit und Anpassbar keit der einzelnen Module an sich andernde Anforderungen gegeben SFS Editor Compiler Sequenz Ausgangstext d gleichzeitig die Lampe eingeschaltet sein interne Darstellung Li L der Anforderungen eech Zwischentext Metatext i Wenn x_1 ist dann muss gleichzeitig y_2 sein Nomendeklaration x_1 der Taster TRUE gedr ckt FALSE nicht gedr ckt Formeltext x1 y2 Abbildung 18 Struktur des Prototypen der Sicherheitsfachsprache 63 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Als Datenschnittstellen zwischen den einzelnen Modulen dienen ASCIlI Textdateien die auch unabh ngig von den einzelnen Modulen erstellt und ausgewertet werden k nnen Dies sind Nomendeklaration diese enth lt die Zuordnung zwischen den SPS internen Vari ablenbezeichnungen und den nat rlichsprachlichen Ausdr cken Ausgangstext dieser enth lt die syntakt
131. chen Verk rzung ei nige Aussagen beziehen sich auf vorherige Aussagen kennt man diese nicht k nnen Missverst ndnisse auftreten der metaphorische Sprachgebrauch oder poetische Sprachausdr cke k nnen zu Missverst ndnissen f hren die menschliche Sprache entwickelt sich st ndig weiter und ist nicht konstant neue W rter und Redewendungen werden geschaffen Ein formales verbales Beschreibungsmittel wie die Sicherheitsfachsprache muss diese Nachteile umgehen oder durch Restriktionen beseitigen Der Gebrauch einer formalen Spezifikationssprache zwingt den Spezifizierer genau festzulegen welche Information gegeben werden sollen und welche nicht Dieses Vorgehen erscheint sicher sehr streng eventuell auch unkomfortabel dennoch erh lt man dadurch qua litativ viel bessere Beschreibungen als mit nat rlicher Sprache Hogr89 Ein weiteres Problem der Spezifikation mit nat rlicher Sprache besteht in einer unzu reichenden Strukturierungsm glichkeit Dadurch passiert es dass oft ungewollt zwi schen Abstraktionsebenen gewechselt wird Sommerville fasst dies in drei Typen von Problemen zusammen 1 Mangel an Klarheit 2 Durcheinander der Anforderungen 3 Verschmelzung von Anforderungen Somm97 10 Einleitung und Ausgangssituation 1 4 Stand der Technik zur Erhohung der Softwarequalitat Um die Sicherheit eines technischen Systems zu erh hen haben sich unterschiedli che Ma nahmen herausgebildet Zu diesen geh ren
132. cht Das Modell kann dabei auf verschiedene Arten beschrieben werden h ufig wird eine Darstellung als endlicher Automat verwendet Zur Beschreibung der Spezifikation werden h ufig Formeln der Temporalen Logik genutzt Die Anf nge dieser Methodik reichen bereits einige Jahre zur ck In Moon91 wird bereits die Anwendung der Verifikation im Bereich der Chemieindustrie beschrieben Beispiele f r gebr uchliche Model Checking Werkzeuge sind SMV Carnegie Mellon University McMi92 INA Star92 PROD Varp95 PEP Best95 HyTech U C Berkeley Alur96 und Kronos Verimag Das Model Checking Verfahren liefert als Ergebnis der berpr fung entweder eine Best tigung d h einen formalen Beweis f r die vollst ndige Einhaltung der Spezifikation in allen modellierten Zust nden des Systems oder m g liche Gegenbeispiele in denen eine oder mehrere Anforderungen nicht erf llt wer den Nachfolgend werden einige der aktuellen Projekte dargestellt die nicht nur den Stand der Forschungen auf dem Gebiet der Verifikation von Steuerungsprogrammen sondern auch die Vielfalt der dabei eingesetzten Werkzeuge zeigen sollen Frey00 gibt hierzu einen ausf hrlichen berblick ber aktuelle Validation und Verifikations ans tze Bereits 1996 wird ber eine formale Verifikationsmethode einschlie lich eines Werk zeugs berichtet mit denen die Korrektheit von SPS Programmen vollautomatisch berpr ft werden kann H lz96 H lz98a und H lz
133. chzeitig gestartet sein wenn der Greifer des Krans unten ist AG rdy_ple amp Crane_height 1 0 amp Crane_lower gt gt gt Satz 90 lt lt lt einfaches Verbot Zustand das Absenken des Krangreifers darf nicht gleichzeitig gestartet sein wenn der Kran am Ablageband ist und der Greifer des Krans auf dem Ablageband ist AG rdy_plc amp Crane_at_dbelt amp Crane_height 0 66 amp 191 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Crane_lower gt gt gt Satz 91 lt lt lt einfaches Verbot Zustand das Absenken des Krangreifers darf nicht gleichzeitig gestartet sein wenn der Kran am Eingangspuffer ist und der Greifer des Krans auf dem Eingangspuffer ist AG rdy_plc amp Crane_at_source amp Crane_height 0 85 amp Crane_lower gt gt gt Satz 92 lt lt lt einfaches Verbot Zustand das Absenken des Krangreifers darf nicht gleichzeitig gestartet sein wenn der Kran am Ausgangspuffer ist und der Greifer des Krans auf dem Ausgangspuffer ist AG rdy_plce amp Crane_at_drain amp Crane_height 0 35 amp Crane_lower gt gt gt Satz 93 lt lt lt einfaches Verbot Zustand das Absenken des Krangreifers darf nicht gleichzeitig gestartet sein wenn der Kran am Zuftihrband ist und der Greifer des Krans auf dem Zufiihrband ist AG
134. ckgesetzt werden und die Zustandsvariable der Presse muss unmittelbar auf 2 gesetzt werden und das Schliessen der Presse muss unmittelbar gestartet werden AG rdy_in amp Press_state 0 amp Press_run_prepare gt Al rdy_plc U rdy_plc amp Press_run_prepare amp Press_state 2 221 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache amp Press_upward gt gt gt Satz 166 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Presse 1 ist und die Presse ist oben dann muss das Schliessen der Presse unmittelbar gestoppt werden und die Zustandsvariable der Presse muss unmittelbar auf 11 gesetzt werden und das ffnen der Presse muss unmittelbar gestartet werden AG rdy_in amp Press_state 1 amp Press_top gt Al rdy_plc U rdy_plc amp Press_upward amp Press_state 11 amp Press_down gt gt gt Satz 167 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Presse 11 ist und die Presse ist unten dann muss das Offnen der Presse unmittelbar gestoppt werden und die Zustandsvariable der Presse muss unmittelbar auf 12 gesetzt werden und die Bereitschaftsmeldung Presse ist zur bergabe eines Teils bereit muss unmittelbar gesetzt werden AG rdy_in amp Press_state 11 amp Press_bottom gt Al rdy_plc U rdy_plc amp Press_down amp Press_state 12 amp P
135. cklungsprozesses zugeordnet werden k nnen So wird z B das Verteilungs Deployment Diagramm f r die Darstellung der Schichten der Automatisierungspyramide verwendet In Xu01 wird die Erweiterung der UML zu UML RT Real Time beschrieben die als geeignete Modellierungssprache f r die Maschinenmodellierung dienen soll Aus dem Bereich der Automobilindustrie kommt ein Vorschlag f r die Erweiterung der Standard UML um automobiltechnische As pekte zur Automotive UML Hofm00 Als aktuelle Entwicklung im Bereich der Spezifikationstechniken soll auf XML Exten sible Markup Language verwiesen werden Birk00 an die gerade im Bereich des Anforderungsmanagements der Webtechnologien gro e Erwartungen gestellt wer den Die Besonderheit der XML besteht in der Trennung von Inhalt Struktur und Layout der zu entwickelnden Applikation Die Darstellung von Programmanforderungen mit Temporaler Logik hat sich bereits als sinnvoll erwiesen und wird auch so gefordert IEC1508 Da diese jedoch schwie rig zu verstehen und zu benutzen ist werden alternative Darstellungsm glichkeiten gesucht mit denen ein leichterer Zugang m glich wird In Dill94 wird GIL Graphical Interval Logic vorgestellt GIL ist die Basis f r ein Toolset zur Unterst tzung der for malen Spezifikation und Verifikation von Softwaresystemen mit Hilfe einer so ge nannten visuellen Temporalen Logik Die Darstellung der Anforderungen erfolgt in Form von Timing Diagrammen mit denen
136. ckt dann muss die Produktionszelle 1 unmittelbar in den Not Aus Zustand 2 berf hrt werden und die Anzeige Not Aus muss unmittelbar aktiviert werden AG rdy_in amp cell_l_state 2 amp Em_stopp gt Al rdy_plc U rdy_plc amp cell_l_state 4 amp LED_em_stopp gt gt gt Satz 11 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Not Aus Zustand 2 ist und der ReStart Taster ist gedr ckt dann muss die Produktionszelle 1 unmittelbar in den Ruhezustand berf hrt werden und die Anzeige Not Aus muss unmittelbar deaktiviert werden und die Anzeige Zelle ist bereit muss unmittelbar aktiviert werden und das Not Aus Signal f r den Kran muss unmittelbar zur ckgesetzt werden und das Not Aus Signal f r das Zufiihrband muss unmittelbar zur ckgesetzt werden und das Not Aus Signal f r den Hubdrehtisch muss unmittelbar zur ckgesetzt werden und das Not Aus Signal f r den Roboter muss unmittelbar zur ckgesetzt werden und das Not Aus Signal f r die Presse muss unmittelbar zur ckgesetzt werden und das Not Aus Signal f r das Ablageband muss unmittelbar zur ckgesetzt werden AG rdy_in amp cell_l_state 4 amp Restart gt Al rdy_plc U rdy_plc amp cell_l_state 0 amp LED_em_stopp amp LED_celll_rdy amp Em_stopp_crane amp Em_stopp_fbelt amp Em_stopp_table amp Em_stopp_robot amp Em_stopp_press amp Em_stop
137. cond_pl gt lt DEl_for_pl gt lt DE1_for_sg gt lt DEl_for_sg gt und lt DE1_for_pl gt lt DES1l_back_pl gt lt DEsl_back_sg gt lt DEsl_back_sg gt und lt DEs1_back_pl gt A DEel_back_pl gt A DEel_back_sg gt lt DEel_back__sg gt und lt DEel_back_pl gt A DE2_for_pl gt A DE2_for_sg gt DE2_for_sg gt und lt DE2_for_pl gt A A A DES2_back_pl gt DES2_back_sg gt lt DEs2_back_sg gt und lt DEs2_back_pl gt A DEe2_back_pl gt A Dei back sos DEe2_back_sg gt und lt DEe2_back_pl gt A A DE3_for_pl gt A DE3_for_sg gt DE3_for_sg gt und lt DE3 for pls A A A DES3_back_pl gt DES3_back_sg gt lt DEs3_back_sg gt und lt DEs3_back_pl gt lt DEe3_back_pl gt Dei back sos lt DEe3_back_sg gt und lt DEe3_back_pl gt lt POl_for_pl gt lt POl_for_sg gt lt POl_for_sg gt und lt POl_for_pl gt lt POel_back_pl gt lt POel_back_sg gt lt POel_back_sg gt und lt POel_back_pl gt lt PO3_for_pl gt lt PO3_for_sg gt lt PO3_for_sg gt und lt PO3_for_pl gt lt POe3_back_pl gt lt POe3_back_sg gt lt POe3_back_sg gt und lt POe3_back_pl gt lt PRl_for_pl gt lt PR1_for_sg gt 120 Anhang lt PR1_for_sg gt
138. d Kos tenfaktor dar Software ist zu einem integralen Bestandteil zeitgem er Infrastruktu ren geworden und viele technische Systeme sind ohne die Leistungsfahigkeit moderner Rechentechnik nicht mehr denkbar Der Einsatz klassischer festver drahteter Sicherheitssysteme nimmt deutlich zugunsten rechnergest tzter Systeme ab Hala98 Habl98 Andererseits kommt es immer wieder zu Ausf llen solcher Sys teme Die Medien berichten ber Unf lle und Katastrophen in sicherheitssensiblen Anwendungen Stichworte Flugzeug Ungl cke Meff99 Ariane 5 Erststart Habl98 und Oftmals l sst sich das Fehlverhalten nach gr ndlicher Analyse auf Fehler in den Steuerungssystemen und speziell auf M ngel in der verwendeten Software zur ckf hren siehe auch Leve95 Die zunehmende Komplexit t moderner Soft ware das steigende Sicherheitsbed rfnis der Endanwender Hala98 und die diesen Gegebenheiten entgegenstehenden Vorbehalte gegen ber programmierbaren elekt ronischen Systemen Meff99 erfordern neue Methoden und Herangehensweisen mit denen die Korrektheit und somit die Sicherheit von Steuerungsprogrammen verbes sert werden kann Wie stark wir in unserem t glichen Leben von der Zuverl ssigkeit von Software abh ngig sind zeigen die Tatsachen dass eine Softwarefehlerquote von 0 1 bedeuten w rde dass t glich 16 000 Briefe bei der Post verloren gingen t glich 18 Flugzeuge abst rzten und st ndlich 22 000 Schecks falsch gebucht w r den
139. d der entsprechen den Reaktion durch die SPS immer eine gewisse Zeit vergeht Im ung nstigsten Fall tritt ein Ereignis genau dann ein wenn die SPS gerade begonnen hat das Pro gramm zu bearbeiten Das Eingangssignal kann also erst mit dem darauf folgenden Zyklus eingelesen und verarbeitet werden Die worst case Reaktionszeit einer SPS betr gt demnach das Doppelte der Zykluszeit im g nstigsten Fall betr gt sie immer hin auch noch die einfache Zykluszeit Diesen SPS typischen Umst nden muss bei der sp teren Formulierung der Anforderungen unbedingt Rechnung getragen wer den Die Ber cksichtigung des SPS Zyklusses in Rahmen der Sicherheitsfachsprache erfolgt durch spezielle Zeitangaben bei der Formulierung der Anforderungen sowie durch Einf hrung von Monitoring Variablen in den temporallogischen Formeln siehe Abschnitte 3 1 4 bzw 3 2 4 2 4 Inhaltliche Anforderungen Die Spezifikation also die technologischen und technischen Vorgaben f r die ge w nschte Funktionsweise einer Maschine oder einer Software wird blicherweise in Kooperation zwischen Auftraggeber und Auftragnehmer erstellt und in einem Pflich tenheft schriftlich festgehalten Die Darstellung erfolgt gew hnlich zun chst als ver bale Beschreibung der Anforderungen oder mit anderen spezifischen Darstellungs formen Nach Somm97 k nnen die Systemanforderungen in funktionale und nicht funktionale Anforderungen unterteilt werden Funktionale Anforderungen beschrei 3
140. d deren Nutzbarmachung als kon kretes Wissen um den Prozess und das System erfordern einen Formalismus der die Akquisition des erforderlichen Wissens aus einer Quelle in einer Form erm glicht die dieses Wissen sowohl f r den Menschen als auch f r die Maschine verst ndlich repr sentiert und zur m glichst effizienten Probleml sung beitr gt siehe Bibe93 Der Autor f hrt weiter an dass mit der Formalisierung des Wissens der Formalisie rung des Problems und einer geeigneten Verarbeitung unmittelbar die L sung des Problems gegeben ist 28 Anforderungen an ein formales Beschreibungsmittel Es gibt die unterschiedlichsten Formalismen zur Reprasentation des Wissens Bibe93 nat rliche Sprache in Form geschriebenen oder gesprochenen Textes Bilder Grafiken Fregesche Repr sentationen Pr dikatenlogik Formeln die eine quivalente Dar stellung nat rlichsprachlicher Sachverhalte enthalten assoziative Netze Repr sentationssprachen wie KL ONE neuronale Netze Bei der berf hrung von der nat rlichen Umgangssprache zur formalen Sprache wird immer ein Bruch entstehen Dieser ist unvermeidlich da ein semantisch mehr deutiges Problem nicht aufgrund logischer Schlussweisen in ein eindeutiges ber f hrt werden kann Die Spezifikation f hrt prinzipiell zur L sung der Aufgabe Diese L sung ist zwar noch nicht in der Basissprache der Maschine formuliert somit ist noch keine Entscheidung f r die Implement
141. das Startsignal Roboter weiter im Mix darf nur gesetzt sein wenn gleichzeitig die Bereitschaftsmeldung Presse ist f r Beladung bereit gesetzt ist AG rdy_plc amp Press_ready_take amp Robot_run_cont 171 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache A 7 2 6 Kommunikation mit der Presse Die Presse ist die eigentliche Bearbeitungsmaschine innerhalb der Produktionszelle 1 Sie wird durch den Roboter mit Rohteilen beladen Roboterarm 1 und auch wie der durch den Roboter entladen Roboterarm 2 Die Presse wird durch den Roboter beladen und auch wieder entladen Es existiert wiederum kein Sensor um die Beladung der Presse direkt feststellen zu k nnen Durch die Presse sind zwei verschiedene Bewegungsphasen auszuf hren nachdem der Roboter die Presse mit einem Rohteil beladen hat vollzieht diese die Arbeitsbe wegung und bearbeitet das Rohteil Danach bewegt sich die Presse in eine Position in der der Roboter die Presse entladen kann Erst danach bewegt sich die Presse wieder in die Beladeposition Die Bewegung der Presse wird in zwei Phasen unterteilt 1 der eigentliche Pressvorgang 2 die Vorbereitung auf die Aufnahme eines neuen Teils zu 1 Es wird eine Meldung des Roboters ben tigt dass er ein neues Rohteil in die Presse gelegt hat Danach kann die Presse mit dem Pressvorgang beginnen zu 2 Es wird eine Meldung des Roboters ben tigt dass er das Fertigteil
142. denen sich die Produktionszelle befinden kann Diese Zust nde sind Ruhezustand wartend Bereitschafts und Fertigmeldung sind gesetzt Automatikbetrieb Not Aus aktiv Not Aus quittiert Not Aus Situation wurde beseitigt aber noch nicht freigege ben Interne Variable des HMI Technische Bezeichnung Variable Datentyp Kommentar Zustandsvariable der Zellensteue cell_1_state Integer rung Tabelle 16 Datenebene 3 Interne Variablen des HMI 23 INT VAR_GLOBAL cell_1_ state die Produktionszelle 1 I im Ruhezustand 0 im Automatikbetrieb im Not Aus Zustand im Not Aus Zustand 2 in den Ruhezustand berf hrt in den Automatikzustand berf hrt in den Not Aus Zustand berf hrt in den Not Aus Zustand 2 berf hrt rn oOOOHHH H Dar ber hinaus muss eine erkannte Not Aus Situation auch an die noch zu definie renden Steuerungen der Einzelkomponenten bertragen werden Auch hierf r sind spezielle Variablen zu definieren 148 Anhang Interne Variablen des HMI Technische Bezeichnung Variable Datentyp Kommentar Not Aus Signal f r die Kransteuerung Em_stopp_crane Bool Not Aus Signal f r die Steuerung des Em_stopp_fbelt Bool Zuf hrbands Not Aus Signal f r die Steuerung des Em_stopp_table Bool Hubdrehtischs Not Aus Signal f r die Robotersteue Em_stopp_robot Bool ru
143. der Roboterarm 2 ist hinten AG rdy_plce amp Arml_ext 0 0 amp Arm2_ext 0 0 amp Robot_left 217 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache gt gt gt Satz 154 lt lt lt erweiterte M glichkeit Zustand die Drehung des Roboters nach rechts darf nur gestartet sein wenn gleichzeitig der Roboterarm 1 hinten ist und der Roboterarm 2 ist hinten AG rdy_plce amp Arml_ext 0 0 amp Arm2_ext 0 0 amp Robot_right gt gt gt Satz 155 lt lt lt einfaches Verbot Zustand Wenn der Roboter mit dem Arm 1 vor der Presse ist und die Bereitschaftsmeldung Presse ist f r Beladung bereit ist nicht gesetzt dann darf das Ausfahren des Roboterarms 1 nicht gleichzeitig gestartet sein AG rdy_plc amp Robot_angle 90 amp Press_ready_take amp Arml_forward gt gt gt Satz 156 lt lt lt einfaches Verbot Zustand Wenn der Roboter mit dem Arm 2 vor der Presse ist und die Bereitschaftsmeldung Presse ist zur bergabe eines Teils bereit ist nicht gesetzt dann darf das Ausfahren des Roboterarms 2 nicht gleichzeitig gestartet sein AG rdy_plc amp Robot_angle 0 amp Press_ready_give amp Arm2_forward 218 Anhang A 7 8 Ger teebene 3 Steuerung der Presse Die Steuerung der Presse erh lt von der bergeordneten Zellensteuerung Startsig nale zur
144. der urspr nglichen Fallstudie war Es wird dar auf verwiesen dass die anderen Produktionszellen der Anlage hnlich aufgebaut sind und die Spezifikation mit denselben Methoden und Verfahren erfolgen kann Das Steuerungssystem der Produktionszelle wurde als hierarchisches Steuerungs system aufgebaut Jede Komponente innerhalb der Produktionszelle Kran Roboter Presse usw ist mit einer separaten Steuerung ausgestattet Die zentrale Master Steuerung die in dieser Ger teebene 2 beschrieben wird koordiniert die dezentralen Steuerungen so dass der geforderte Bearbeitungsablauf realisiert wird vergleiche Abbildung 28 Sobald erkannt wird dass im Eingangspuffer ein Rohteil liegt wird dieses durch den Kran aufgenommen und auf das Zuf hrband gelegt Das Zuf hr band transportiert das Teil auf den Hubdrehtisch Dieser vollf hrt eine Drehung und hebt das Teil gleichzeitig etwas an so dass sich das Teil anschlie end in einer Posi tion befindet in der es vom Roboterarm 1 aufgenommen werden kann Der Roboter arm 1 legt das Teil in der Presse ab Diese presst anschlie end das Teil Das Fer tigteil wird durch den Roboterarm 2 aus der Presse genommen und auf dem Ablage 87 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache band abgelegt Dieses bef rdert das Teil zum Kran der anschlie end das Teil wie der vom Ablageband nimmt und in den Ausgangspuffer legt A 1 Ablagef rderband
145. derndes Ereignis befindet sich die Kollision eines Roboterarms mit der Presse in der Wurzel des Baums Abbildung 29 Roboterarm und Presse kollidieren i A j t Roboterarm st t Roboterarm st t in geschlossene seitlich gegen Presse klemmt i 22 Roboterarm ein Presse Presse Roboterarm wird Presse ist nicht Roboterarm ist Presse wird ausgefahren bereit ausgefahren geschlossen Arm steht vor Arm steht vor Presse Presse Roboterarm ist ausgefahren ae Roboter dreht Roboter dreht sich nach links sich nach rechts Abbildung 29 Fehlerbaumanalyse f r die Kollision des Roboters mit der Presse Das genannte unerw nschte Ereignis k nnte durch die darunter aufgezeigten Ursa chen eintreten Diese einzelnen Ursachen werden solange aufgeschl sselt bis sich Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache die elementaren Ursachen ergeben Aus diesen erfolgt die Zusammenstellung der informellen Spezifikation der Sicherheitseigenschaften Informelle Spezifikation Ausgehend von Abbildung 29 lassen sich die folgenden Situationen identifizieren die unbedingt zu vermeiden sind der Roboterarm 1 darf nicht ausfahren wenn der Roboter mit dem Arm 1 vor der Presse und die Presse nicht in der erforderlichen Position ist der Roboterarm 2 darf nicht ausfahren wenn der Roboter mit dem Arm 2 vor der Presse und die Presse nicht in der erforderlichen Position ist der Roboter darf sich nicht nach links drehen wenn der
146. des Sys tems die gew nschten Ausgangsgr en erzeugt werden Ein Programm engl program l st ein bestimmtes Problem anhand einer Folge lo gisch aufeinander abgestimmter Anweisungen DIN 44300 Die Formulierung erfolgt in einer Programmiersprache die verwendeten Anweisungen werden dann Befehle genannt Voraussetzung f r ein Programm ist die Berechenbarkeit der L sung Eine Sprache engl language ist ein Formalismus zur Darstellung von Sachverhal ten durch Folgen von Zeichen deren Reihenfolge durch die Syntax der Sprache festgelegt ist Kr c90 Die Semiotik der Sprache beschreibt die definierte Menge von Zeichen bzw Sym bolen Die Syntax engl syntax beschreibt mit Hilfe von Regeln f r zul ssige Zeichenkom binationen die Anordnung der W rter f r formal korrekte S tze einer Sprache Die Semantik beschreibt deren Bedeutung Ahre00 Eine Programmiersprache engl programming language ist eine k nstliche Spra che mit der Programme so formuliert werden k nnen dass Rechner in der Lage sind sie abzuarbeiten Sie zeichnen sich durch eine strikte Zweckgebundenheit so wie eine klare und einfache Syntax aus Sie sind ein semi formales Beschreibungs bzw Ausdrucksmittel f r Algorithmen Steuerungstechnik DIN 19226 Unter Steuern bzw einer Steuerung engl control versteht man den Vorgang in einem System bei dem eine oder mehrere Gr en als Eingangsgr en andere Gr Ben als Ausgangsgr en aufgrund der dem
147. dliche Materiallager Im Rohteil lager befindet sich jederzeit ein gewisser Vorrat an Rohteilen in das Fertigteillager kann eine beliebige Menge an Fertigteilen abgelegt werden Bei der Entnahme von Rohteilen aus dem Rohteillager durch das Transportsystem wird auf eine hier nicht n her bestimmte Art und Weise die gew nschte Anzahl von Rohteilen bergeben Ebenso erfolgt eine vollst ndige bergabe aller Fertigteile in das Fertigteillager 5 1 4 Die Produktionszelle 1 Die Produktionszelle des urspr nglichen Fallbeispiels wurde erweitert um den Ge gebenheiten der Integration in das Gesamtsystem Rechnung zu tragen und um einen m glichst realen technischen Aufbau zu gew hrleisten Nachdem in der urspr ngli chen Produktionszelle der Kran f r die Uberf hrung der Werkst cke vom Ablageband zur ck zum Zuf hrband diente wird diese zyklische Arbeitsweise wieder aufgebrochen Die Be und Entladung der Produktionszelle erfolgt ber den Ein gangs bzw den Ausgangspuffer Au erdem wurde die Produktionszelle 1 um einige Bedien und Anzeigeelemente erweitert Es wird wiederum weder Anspruch auf die Vollst ndigkeit der Elemente noch auf ihre Realisierbarkeit oder Sinnf lligkeit erho ben 78 Validierung des Prototypen anhand einer Fallstudie Die Abbildung 25 zeigt den Aufbau der erweiterten Produktionszelle 1 ep Ablageband TAusgangs 5 Presse Roboter Arm 2 i ben Laufkran ww TEingangs d Arm 1 E
148. dliche Bereiche unterteilen An dieser Stelle wird eine Ein teilung hinsichtlich der Einordnung der Ma nahmen in den Softwareentstehungspro zess vorgenommen 1 Ma nahmen im Vorfeld und Umfeld der Softwareerstellung 2 Ma nahmen w hrend der Softwareerstellung 3 Ma nahmen im Anschluss an die Softwareerstellung Zu den unter 1 genannten Ma nahmen im Vor und Umfeld der Softwareerstellung geh ren planerische administrative und organisatorischen Ma nahmen wie z B die Einf hrung von Qualit tssicherungssystemen Normen und Richtlinien f r die Soft wareerstellung die Durchf hrung von Audits sowie die geeignete Ausbildung und Motivation der Mitarbeiter DGQ86 Balz96 und Balz98 W hrend der eigentlichen Erstellung der Software k nnen geeignete Hilfsmittel Werkzeuge Methoden und Sprachen eine technische Unterst tzung geben und so zu einer Verbesserung der Softwarequalit t beitragen Aber auch nach der Erstellung der Software gibt es weiterhin gen gend M glichkei ten die Korrektheit der Software zur berpr fen und sicherzustellen Hierzu gibt es wiederum geeignete technische Ma nahmen zur Pr fung der Software z B pr fende oder auch analytische Verfahren Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Diese drei genannten Bereiche werden in den folgenden Abschnitten noch weiter vertieft Neben den bereits angesprochenen organisatorischen Ma nahmen zur Erh hung der Softwarequal
149. dy_plc wird erstmalig gesetzt Durch diese beiden Beobachtungsvariablen kann diese Tatsache berwacht werden 55 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Im Abschnitt 3 1 5 wurden die folgenden Kategorien des Modalparameters abgelei tet Einfache Forderung innerhalb des BI muss es ein F geben innerhalb des Bl darf es kein F geben auBerhalb des B darf es ein F geben Erweiterte Forderung innerhalb des B muss es ein F geben innerhalb des B darf es ein F geben au erhalb des B darf es kein F geben au erhalb des B darf es kein F geben An dieser Stelle lassen sich auch wieder Verbindungen zwischen den Kategorien des Modalparameters ableiten Bei der einfachen Forderung muss es innerhalb des Beobachtungsintervalls ein F geben Das einfache Verbot ist eine Umkehrung der einfachen Forderung innerhalb des Beobachtungsintervalls darf es kein F geben Bei der erweiterten M glichkeit wird das Beobachtungsintervall im Vergleich zum einfachen Verbot invertiert es darf auBerhalb des Beobachtungsintervalls kein F geben Die erweiterte Forderung kann man als Verkn pfung zwischen der einfachen Forderung innerhalb des Bl muss es ein F geben und der erweiterten M g lichkeit au erhalb des BI darf es kein F geben betrachten Diese Zusammenh nge spiegeln sich auch nachfolgend in den CTL Formeln wieder Die folgende Auflistung der Anforderungskategorien mit ihrer CTL Darstellung ist durc
150. e Kommunikation unvollst ndige unklare Anforderungen sich ndernde Anforderun gen Komplexit t unzureichende Transparenz sowie eine unzureichende Ausbildung anf hrt Diese Aufstellung macht eindrucksvoll deutlich dass es im Zusammenhang mit der Korrektheit von Software keine einzelnen und losgel sten Ursachen gibt sondern dass es vielmehr immer eine komplexe Verkn pfung mehrerer Ursachen gibt die f r die Entstehung unzureichender Software verantwortlich sind Als ein wesentlicher Bereich der Fehlerentstehung l sst sich jedoch eindeutig der Zeitraum im Vorfeld der eigentlichen Softwareerstellung herausarbeiten A Kohring stellt bereits in Kohr91 und Kohr93 fest dass Softwarefehler in fr hen Phasen der Entwicklung entstehen aber erst viel sp ter entdeckt und beseitigt wer den k nnen Als Ursache hierf r wird auch die unzureichende Kl rung der Aufga benstellung genannt Es sind keine universellen und allgemeinverst ndlichen Be schreibungsmethodiken verf gbar die umfassend geeignet sind und akzeptiert wer den Halang und Konakovski gehen in Hala98 genauer auf diese Problematik ein Sie f hren aus dass Softwarefehler bereits beim Entwurf und der Programmierung ge macht werden also systematischer Natur sind Die gr te Fehlerquelle sind Spezifi kationsfehler und nichtber cksichtigte Situationen wie sie bei einer extrem gro en und somit nicht mehr handhabbaren Zahl diskreter Systemzust nde auftreten k n nen
151. e 4 Sensoren des Hubdrehtischs nnnnnnnnnnnnnnnnnnneeenne 197 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Tabelle 32 Datenebene 4 Aktoren des Hubdrehtischs ecceeeeeeeeeeeeeeeeeees 198 Tabelle 33 Datenebene 4 Interne Variablen der Steuerung des Hubdrehtischs 199 Tabelle 34 Datenebene 4 Sensoren des Hoboiers nennen 205 Tabelle 35 Datenebene 4 Aktoren des Hoboters nennen 205 Tabelle 36 Datenebene 4 Interne Variable der Steuerung des Roboters 207 Tabelle 37 Datenebene 4 Sensoren der Presse 219 Tabelle 38 Datenebene 4 Aktor der Dresee nnna 220 Tabelle 39 Datenebene 4 Interne Variable der Steuerung der Presse 220 Tabelle 40 Datenebene 4 Sensor des AblagebandsS 42H 224 Tabelle 41 Datenebene 4 Aktor des Ablagebands ss 224 Tabelle 42 Datenebene 4 Interne Variable der Steuerung des Ablagebands 225 XII Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Verzeichnis der verwendeten Symbole und Abkurzungen A Anforderung B B4 B2 Bedingung F F4 F2 Folgerung BI Beobachtungsintervall S Startzustand E Endzustand Z Zielzustand DE DEs DEe Anforderungskategorien demand simple demand extended demand PR PRs Anforderungskategorien prohibition simple prohibition PO POe Anforderungskategorien possibility extended possibility BDE Betriebsdatenerfasssung BNF Backus N
152. e zu definieren um den ver nderten Gegebenheiten bei der Benut zung in einer Bedingung oder einer Folgerung Rechnung zu tragen Bei Bedingun gen wird der Wert einer Variablen abgefragt bzw mit einem anderen Wert vergli chen bei Folgerungen wird einer Variablen ein neuer Wert zugewiesen bzw es wird die Zuweisung eines Wertes verboten y_1 bei Verwendung in einer Bedingung der Motor ist aktiv bei Verwendung in einer Folgerung der Motor wird gestartet y_1 bei Verwendung in einer Bedingung der Motor ist nicht aktiv bei Verwendung in einer Folgerung der Motor wird gestoppt Durch die unterschiedliche Verwendung des Hilfsverbs sein in den Bedingungen und Folgerungen einerseits in einem passiven Zusammenhang andererseits in ei nem aktiven Zusammenhang ergibt sich die Notwendigkeit einer unterschiedlichen Definition der Werte Formulierung der Nomen Wert Kombinationen f r Bool bzw Integer Variablen W hrend Variablen des Datentyps Bool nur zwei Zust nde aufweisen und somit die Anzahl der formulierbaren Werte begrenzt ist siehe oben besteht diese Begren zung f r Variablen des Datentyps Integer nur aufgrund des darstellbaren Werteberei chs Jedoch ist es auf der anderen Seite nicht m glich und auch nicht notwendig den gesamten Wertebereich einer Integer Variablen vollst ndig verbalisieren zu wollen Betrachtet man sich die Art und Weise der Verwendung von Integer V
153. e_run_dbelt gt Al rdy_plc U rdy_plc amp Crane_run_source amp Crane_state 1 gt gt gt Satz 65 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 0 ist und das Startsignal Kran holt Fertigteil von Ablageband ist gesetzt dann muss das Startsignal Kran holt Fertigteil von Ablageband unmittelbar zur ckgesetzt werden und die Zustandsvariable des Krans muss unmittelbar 2 werden und die Bewegung des Krans nach rechts Ablageband muss unmittelbar gestartet werden AG rdy_in amp Crane_state 0 amp Crane_run_dbelt gt Al rdy_plc U rdy_plc amp Crane_run_dbelt amp Crane_state 2 amp Crane_to_dbelt gt gt gt Satz 66 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 1 ist und der Kran ist am Eingangspuffer dann muss die Zustandsvariable des Krans unmittelbar 11 werden und das Absenken des Krangreifers muss unmittelbar gestartet werden AG rdy_in amp Crane_state 1 amp Crane_at_source gt Al rdy_plc U rdy_plc amp Crane_state 11 amp Crane_lower Weitere informelle Spezifikationen Neben den Funktionsanforderungen m ssen durch die Kransteuerung weitere Si cherheitsanforderungen realisiert werden Hierbei k nnen die folgenden sicherheits kritischen Punkte identifiziert werden Begrenzung der Kranbewegung an den Endpunkten der Kranbahn Begrenzung der Grei
154. ealerweise jeder einzelne Systemzu stand dahingehend bewertet werden wie sich das Programm verhalten soll wenn das System diesen Zustand einnimmt bzw ob das System diesen Zustand ber haupt einnehmen darf Durch diese Bewertung und die Festlegung der Reaktion des Steuerungsprogramms auf diese Systemzust nde wird das gew nschte Verhalten des Steuerungsprogramms festgelegt Einleitung und Ausgangssituation Jedoch ist bei Systemen technisch relevanter Gr e eine vollst ndige Spezifikation also die Betrachtung aller Systemzust nde nicht mehr ohne weiteres m glich Infol gedessen bleibt eine Menge von Systemzust nden oft unbewertet unspezifiziert Hierbei entsteht ein Problem weil es innerhalb der Menge der unbewerteten System zust nde auch wiederum riskante Zust nde geben kann die zudem noch unerkannt sind Wird die festgeschriebene Spezifikation in reale Software berf hrt so weist das Programm oftmals die bereits beschriebenen Fehlfunktionen auf Die Gr nde hierf r sind in zwei Tatsachen zu finden Abbildung 3 1 unvollst ndige Umsetzung des gew nschten Verhaltens d h einige der ge forderten Reaktionen werden nicht ausgef hrt nachfolgend als Fehlerklasse a bezeichnet 2 Implementierung zus tzlicher Eigenschaften d h das Programm ist zu uner warteten Reaktionen in der Lage nachfolgend als Fehlerklasse b bezeichnet Diese Klassifizierung ist auch konform zu der in Abschnitt 1 1 1 getroffenen Eintei
155. eb ist und die Bereitschaftsmeldung Ablageband ist zur bergabe eines Teils bereit ist gesetzt und der Ausgangspuffer ist frei dann muss die Bereitschaftsmeldung Ablageband ist zur bergabe eines Teils bereit unmittelbar zur ckgesetzt werden und muss das Startsignal Kran holt Fertigteil von Ablageband unmittelbar gesetzt werden AG rdy_in amp cell_l_state 1 amp Dbelt_rdy_give amp Piece_at_drain gt Al rdy_plc U rdy_plc amp Dbelt_rdy_give amp Crane_run_dbelt Definition weiterer Eigenschaften mit dem SFS Editor Der Kran darf nicht starten wenn das Ablageband nicht bereit ist Der Kran darf nicht starten wenn der Ausgangspuffer nicht frei ist Formale Spezifikation mit dem SFS Editor gt gt gt Satz 61 lt lt lt einfaches Verbot Zustand das Startsignal Kran holt Fertigteil vom Ablageband darf nicht gleichzeitig gesetzt sein wenn die Bereitschaftsmeldung Ablageband ist zur bergabe eines Teils bereit nicht gesetzt ist AG rdy_plc amp Dbelt_ready_give amp Crane_run_dbelt gt gt gt Satz 62 lt lt lt einfaches Verbot Zustand das Startsignal Kran holt Fertigteil vom Ablageband darf nicht gleichzeitig gesetzt sein wenn der Ausgangspuffer belegt ist AG rdy_plc amp Piece_at_drain amp Crane_run_dbelt 177 Formale Spezifikation reaktiver Systeme mit eine
156. ecker in diesem Fall Cadence SMV analysiert werden kann Die zu berpr fenden Eigenschaften werden hierbei direkt in CTL oder LTL formuliert Dieser Ansatz verzichtet auf ein Modell der ungesteuerten Strecke das Verhalten des SPS Programms wird inklusive des SPS Zyklus nachgebildet Hanisch Vyatkin beide Uni Halle und Starke HU Berlin bearbeiten innerhalb des Projektes VEDA Verification Environment for Distributed Applications die Proble matik der Modellierung und Verifikation der Abarbeitungssteuerung von Funktions bl cken nach IEC 61499 mit Signal Ereignis Netzen http at iw uni halle de valeriy project project html Die hier verwendeten Funktionsbl cke nach IEC 61499 unterst tzen Formalismen um verteilte Steuerungssysteme zu spezifizieren Aus gangspunkt der Verifikation ist also eine Steuerung gem IEC 61499 die in ein Modell berf hrt wird Zus tzlich erfolgt eine Spezifikation des korrekten bzw inkor rekten Verhaltens durch CTL Ausdr cke die mit einer speziellen Beschreibungs sprache der Timing Diagram Specification Language TDSL erstellt werden Anschlie end erfolgen Untersuchungen am Erreichbarkeitsgraf mit einem internen Model Checker oder dem an der HU Berlin entwickeltem SESA In Bits00 wird ein Verfahren vorgestellt mit dem eine formale Verifikation von Soft warespezifikationen durchgef hrt werden kann Die Verifikation erfolgt dabei anhand von Modellen die mit industriell blichen Entwurfswerk
157. ed require new approaches in development realisation and quality assurance of control software In this case an essential problem is the complete and correct description of the desired control functions Today we have a lot of different even partly standardised forms of representations but there is no homogeneous and above all no area overlapping tool for the description of the de sired control functions Depending on application area user knowledge and problem definition these forms of representations are that unique that they can only be used by experts The development of a description language has to be oriented to the users needs With the Safety oriented Technical Language in German Sicherheitsfachsprache SFS which is presented in this work the formulation of control problems in an easy clear and common way of understanding is possible Because it comes near the natural language it fulfils the main objectives an overlapping communication between different persons who are involved in a project and an overlapping commu nication between different levels of a hierarchical control structure As a third main feature the SFS offers the possibility to describe unwanted and prohibited situations of a control system Thus a wide application field to solve different problems is given On the other side the SFS is well defined enough to ensure a clear problem specifi cation Within this work the SFS is represented as follows Sect
158. edienelemente Technische Daten Bezeichnung Variable typ Kommentar Sensor Ein Piece_at_source Bool TRUE Teil vorhanden gangspuffer be legt Sensor Aus Piece_at_drain Bool TRUE Teil vorhanden gangspuffer be legt Not Aus Schalter Em_stopp Bool TRUE Not Aus nicht ak rastend tiv Re Start Taster Restart Bool TRUE Restart gedr ckt nichtrastend Tabelle 14 Datenebene 3 Sensoren des HMI Bedienelemente 614 BOOL VAR_INPUT Piece_at_source der Eingangspuffer TRUE_I belegt FALSE_I leer 6615 BOOL VAR_INPUT Piece_at_drain der Ausgangspuffer TRUE_I belegt FALSE_I frei 616 BOOL VAR_INPUT Em_stopp der Not Aus Taster FALSE_I gedr ckt TRUE_I nicht gedr ckt 17 BOOL VAR_INPUT Restart der ReStart Taster 146 Anhang TRUE_I FALSE_I gedr ckt nicht gedr ckt Aktoren des MMI Anzeigen Technische Bezeichnung Variable Datentyp Kommentar Anzeige Eingangs Count_in Integer Anzahl Teileeingang z hler Anzeige Ausgangs Count_out Integer Anzahl Teileausgang z hler Anzeige Anlage be LED_Cell_ready Bool TRUE Zelle ist bereit reit Anzeige Automatik LED_Cell_run Bool TRUE Zelle l uft au l uft tomatisch Anzeige Not Aus LED_em_stopp Bool TRUE
159. efiniert Durch diesen wird das Transport system veranlasst entweder Rohteile oder Fertigteile zu transportieren bzw in Ruhe zu verharren Details des Transportauftrags k nnen der Tabelle 10 Anhang Seite 142 entnommen werden Aufgabe Die Ausl sung eines Transportauftrages muss mit der jeweiligen Produktionszelle und dem Transportsystem koordiniert werden Das Transportsystem kann einen neuen Transportauftrag nur ausf hren wenn es frei d h unbesch ftigt ist Die Pro duktionszellen k nnen nur beladen werden wenn sie dazu bereit sind und sie k n nen erst entladen werden wenn der aktuelle Produktionsauftrag beendet wurde Definition neuer Daten mit dem SFS Editor F r jede Produktionszelle sowie f r das Transportsystem werden Bereitschafts bzw Fertigmeldungen definiert die den aktuellen Zustand dieser Elemente anzeigen cell_1_ready Produktionszelle 1 ist f r neuen Auftrag bereit cell_1_finished Produktionszelle 1 hat den Auftrag bearbeitet analog f r die weiteren Produktionszellen tr_sys_ready Transportsystem ist f r neuen Auftrag bereit tr_sys_finished Transportsystem hat Auftrag ausgef hrt Details zu diesen Meldungen k nnen der Tabelle 11 Anhang Seite 143 Tabelle 12 Anhang Seite 143 und Tabelle 13 Anhang Seite 144 entnommen werden Die Unterteilung in Bereitschafts und Fertigmeldungen wurde vorgenommen weil sich somit durch logische Verkn pfung dieser Signale w
160. ei durch Interpretation einer SPS Variablen der Wert durch Interpretation eines bestimmten Wertes den diese SPS Variable annehmen kann gebildet Da SPS Variablen typischerweise mehrere Werte annehmen k nnen gibt es zu einem Nomen immer auch mehrere Werte und somit auch immer mehrere Nomen Wert Kombinationen zu einer SPS Variablen So kann z B zu der boole schen SPS Variablen x_1 die einen bestimmten Taster repr sentiert das Nomen der Start Taster erstellt werden f r den TRUE Zustand kann der Wert gedr ckt und der FAL GE Zustand der Wert nicht gedr ckt vereinbart werden F r diese Va riable ergeben sich die beiden Nomen Wert Kombinationen x_1 der Start Taster ist gedr ckt x_1 der Start Taster ist nicht gedr ckt Diese Zuordnung ist f r alle verwendeten Variablen einmal zu erstellen Bei der an schlie enden Formulierung der Anforderungen werden nur noch diese erzeugten Nomen und Werte benutzt ohne dass sich der Anwender st ndig ber die dahinter liegenden steuerungstechnischen Gegebenheiten im Klaren sein muss Bei der Ver vollst ndigung der Anforderungss tze werden die Nomen als Subjekte innerhalb der Teils tze verwendet die Werte bilden zusammen mit den bereits vorhandenen Hilfs verben Lier sein werden die zugeh rigen Pr dikate Als Wert und damit auch als Pr dikat k nnen dabei nicht nur einzelne W rter dienen hier sind je nach Problemstellun
161. eigenschaften Steuerung kurzfristig DEe2 Sollverhalten der DEs3 DEs5 DEe3 Lebendigkeitseigenschaften Steuerung langfristig DEe5 auszuschlie ende PRs1 PRs5 Sicherheitseigenschaften Reaktionen eingeschrankt auch POe1 POe5 Tabelle 5 Verwendung der Kategorien der Sicherheitsfachsprache 47 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache 3 1 6 Grafische Repr sentation der SFS Kategorien Der nun folgende Abschnitt fasst die zuvor zusammengestellten Kategorien der Si cherheitsfachsprache nochmals zusammen und stellt die Zusammenh nge zwischen Bedingung und Folgerung in diesen Kategorien grafisch in ihren zeitlichen Abl ufen dar Dieser zeitliche Zusammenhang ist anhand der ablaufenden SPS Zyklen nach zuvollziehen Die Abbildung 11 zeigt wie die nachfolgenden Diagramme zu interpretieren sind Zustand False Zustand True K Zustand beliebig Abbildung 11 Legende f r die folgenden Timingdiagramme Mit B B1 und B2 sind einzelne Bedingungen oder auch mehrere konjunktiv ver kn pfte Bedingungen gemeint F bezeichnet eine einzelne Folgerung oder mehrere konjunktiv verkn pfte Folgerungen Diese Bedingungen bzw Folgerungen k nnen zum aktuellen Zeitpunkt identifizierbar durch den SPS Zyklus entweder erf llt True oder nicht erf llt False sein Dar ber hinaus besteht jedoch auch die M glichkeit dass der beschriebene Zusammenha
162. einige dieser Parameter n her aus Hore89 DGQ86 Litz99 Korrektheit Zuverl ssigkeit reliability F higkeit der Software Aktionen so auszu f hren wie sie in der Spezifikation definiert wurden Robustheit F higkeit der Software sich auch in ungew hnlichen Situationen ver n nftig zu verhalten dies betrifft vor allem das Verhalten der Software in zuvor nicht spezifizierten und bewerteten Situationen Erweiterbarkeit Anpassbarkeit F higkeit der Software sich leicht an ver nderte Anforderungen oder Spezifikationen anzupassen d h wie leicht sich Anderungen und Erweiterungen implementieren lassen Einleitung und Ausgangssituation Wiederverwendbarkeit Fahigkeit der Software einzelne Komponenten der Software zur Schaffung anderer Software nutzen zu k nnen Effizienz Leistungsf higkeit efficiency F higkeit der Software gut mit den Hard wareressourcen und Betriebssystemdiensten umzugehen Modularit t Eigenschaft der Software in mehr oder weniger autonome Komponen ten zerlegbar zu sein bzw aus autonomen Komponenten zu bestehen Kontinuit t Eigenschaft der Software dass kleinere Ver nderungen der Anforderun gen nicht zu einer gewaltigen Anderung der Software f hren m ssen d h kleine Anderungen nur wenige Module betreffen Benutzbarkeit usability Eignung der Software f r den Benutzer dessen Funktio nen die Bedienung und Handhabbarkeit der Software zu erlernen und deren Meldungen und Er
163. eiten PAG lt a pq pva p q peq p gt q aA q p TRUE pv p FALSE TRUE 3 2 2 Temporale Logik Die Temporale Logik TL ist eine um zeitliche Operatoren erweiterte Aussagenlogik Sie dient als Werkzeug um zeitliche Besonderheiten in der logischen Struktur eines Programms beschreiben zu k nnen Fish93 Kr g87 Mann92 Mann95 Emer90 Clar86 Mord83 Die Temporale Logik kann zur Programmverifikation verwendet werden Man formalisiert hierbei den Begriff des Zeitpunktes und be trachtet nicht mehr feste Interpretationen sondern vielmehr Interpretationen die zu verschiedenen Zeitpunkten einen unterschiedlichen Wahrheitsgehalt haben k nnen So k nnen bestimmte Aussagen in Abh ngigkeit vom aktuellen Zeitpunkt wahr oder unwahr sein Zeitpunkt Aktion a b c A farb cna gt 0 gt b gt 0l pot jalslol Fra e exb afals e Fase Tabelle 6 Abhangigkeit des Wahrheitsgehaltes einer Aussage vom Zeitpunkt der Betrachtung In der oben stehenden Tabelle 6 Kr g87 ist die Aussage A Wenn die Summe aus a und b gleich c ist und a ist gr er als Null dann ist b gr er als Null f r die Zeit punkte 1 und 3 falsch w hrend sie im Zeitpunkt 2 richtig war F r die Darstellung solcher Besonderheiten existieren in der Temporalen Logik spe zielle Operatoren Tabelle 7 die sich auf zeitliche Abh ngigkeiten beim Ablauf eines Programms beziehen Operator Bedeutung Symbol Bezeichnung Bezug zum Ref
164. eitere Informationen Ubertra gen lassen z B mit altem Auftrag fertig UND nicht bereit f r neuen Auftrag be deutet Defekt bzw St rung Aufgabe Die Transportauftr ge k nnen nur unter Beachtung von Bereitschafts und Fertigmel dungen der Produktionszellen bzw des Transportsystems ausgegeben werden Informelle Spezifikation Eine Beladung mit Rohteilen erfolgt wenn es einen Produktionsauftrag f r die jewei lige Produktionszelle gibt wenn die Bereitschaftsmeldung dieser Produktionszelle gesetzt ist und wenn die Bereitschaftsmeldung des Transportsystems gesetzt ist 85 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Eine Entladung der Produktionszelle erfolgt wenn die Fertigmeldung einer Produk tionszelle gesetzt ist und wenn die Bereitschaftsmeldung des Transportsystems ge setzt ist Formale Spezifikation mit dem SFS Editor gt gt gt Satz 2 lt lt lt einfache Forderung direkt Wenn der aktuelle Stand der Auftragsbearbeitung Neu ist und die Bearbeitungsart ist Pressen und die Bereitschaftsmeldung der Produktionszelle 1 ist gesetzt und die Bereitschaftsmeldung des Transportsystems ist gesetzt dann muss der aktuelle Stand der Auftragsbearbeitung unmittelbar auf Rohteile holen gesetzt werden und die Transportart muss unmittelbar auf 1 Rohteile holen gesetzt werden und die anzufahrende Produktionszelle muss unmittelbar 1 werden und die Be
165. elbar gestartet werden AG rdy_in amp Table_state2 0 amp Table_statel 0 amp Table_run_lower gt Al rdy_plc U rdy_plc amp Table_run_lower amp Table_state2 2 amp Table_statel 2 amp Table_downward amp Table_right gt gt gt Satz 107 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Hubtischh he 1 ist und der Hubdrehtisch ist oben dann muss das Anheben des Hubdrehtischs unmittelbar gestoppt werden und die Zustandsvariable der Hubtischh he muss unmittelbar auf 11 gesetzt werden AG rdy_in amp Table_state2 1 amp Table_top gt Al rdy_plc U rdy_plc amp Table_upward amp Table_state2 11 gt gt gt Satz 108 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Hubtischdrehung 1 ist und der Hubdrehtisch ist vor dem Roboter dann muss die Linksdrehung des Hubdrehtischs unmittelbar gestoppt werden und die Zustandsvariable der Hubtischdrehung muss unmittelbar auf 11 gesetzt werden AG rdy_in amp Table_statel 1 amp Table_angle 50 gt A rdy_ple U rdy_plc amp Table_left amp Table_statel 11 gt gt gt Satz 109 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Hubtischh he 11 ist und die Zustandsvariable der Hubtischdrehung ist 11 dann muss die Bereitschaftsmeldung Hubdrehtisch ist zur Ubergabe eines Teils bereit unmi
166. emperatur ist gr er als 50 C x_t lt 50 die Temperatur ist kleiner als 50 C Sichtenorientierte Formulierung der Nomen Wert Kombinationen Ein weiterer Punkt der kreativen Einflussnahme des Anwenders der Sicherheitsfach sprache auf die Lesbarkeit und Verst ndlichkeit seiner Anforderungss tze ergibt sich durch einen unterschiedlichen Abstraktionsgrad bei der Erstellung der Nomen und Werte M glich sind hier eine vorwiegend variablenorientierte Beschreibung eine prozessorientierte Beschreibung Bei einer variablenorientierten Beschreibung erfolgt lediglich eine direkte nichtinter pretierte berf hrung der SPS Variablen und ihrer Werte in die Nomen und Werte x_1 die Variable x_l ist TRUE alternativ wahr gesetzt x_1 die Variable x_l ist FALSE alternativ falsch nicht gesetzt Mit dieser Darstellung kann man prinzipiell bereits umgehen die entscheidenden M glichkeiten der Sicherheitsfachsprache bestehen jedoch vor allem auch darin die verwendeten SPS Termini prozessorientiert zu interpretieren und somit eine bessere Verst ndlichkeit und auch eine Erh hung der Anwendungssicherheit zu erzielen Hierbei kann der Anwender genau die technische Bedeutung der einzelnen Vari ablenzust nde angeben und somit Missverst ndnisse und Fehlinterpretationen ver meiden x_2 die Variable x_2 ist gesetzt variablenorientiert der Not A
167. en Erkennt nissen gef hrt Herrn L Scharf danke ich speziell f r die Programmierung des Edi tors der Sicherheitsfachsprache und des Compilers die trotz der vielen Anderungen und Erweiterungen einen hervorragenden Reifegrad erreicht haben Den Mitarbeitern des Lehrstuhls Automatisierungstechnik Herrn R Schulze Herrn K Kreusch Herrn U Steffen und Herrn K Henning danke ich f r die zahlreichen Ge spr che und Hinweise zum Gelingen dieser Arbeit Nicht zuletzt gilt ein besonderer Dank meiner Familie allen Freunden und Kollegen die mich bei der Durchf hrung dieser Arbeit unterst tzt und motiviert haben Viele mussten die H hen und Tiefen in der Zeit dieser Arbeit miterleben Ich m chte ihnen f r ihr Verst ndnis und ihre Geduld danken Ingolstadt Cottbus Januar 2003 Thomas Mertke Bemerkungen zum Schriftbild Einige Passagen dieser Arbeit beinhalten formale Definitionen der Sicherheitsfach sprache sowie Beispiele und Erlauterungen zu ihrer Anwendung Um diese Darstel lungen vom eigentlichen Text optisch abzugrenzen werden diese Bereiche beson ders dargestellt Normaler FlieBtext Arial 12pt Verbale Anforderungen die mit dem SFS Editor erstellt wurden Times New Roman 12pt kursiv einger ckt mit Rahmen Metatext der Sicherheitsfachsprache Arial 12pt kursiv einger ckt mit Rahmen Temporallogische Formeln die durch den SFS Editor bzw den Compiler erzeugt wurden Courier New 12pt
168. en Zustand ger t Lebendigkeitseigenschaften engl live ness properties dr cken aus dass das System irgendwann in einen bestimmten er 36 Anforderungen an ein formales Beschreibungsmittel w nschten Zustand geraten kann Fortschrittseigenschaften versch rfen dies da durch dass das System auch in diesen geforderten Zustand kommen muss 2 4 3 Anforderungen aus dem Bereich der Steuerungstechnik Ausgehend vom vorherigen Abschnitt wird nun gezeigt welche speziellen Anforde rungen an ein Steuerungsprogramm gestellt werden und wie diese kategorisiert wer den k nnen Die festgelegten Vorgaben an das Steuerungsprogramm werden im Folgenden all gemein als Anforderungen engl requirements bezeichnet Im vorherigen Abschnitt wurde bereits eine grobe Einteilung dieser Anforderungen in Funktions und Sicher heitsanforderungen dargelegt Bei der Formulierung dieser Anforderungen werden bestimmte Zust nde des Systems betrachtet es werden bestimmte Aussagen ber diese Systemzust nde getroffen sowie spezielle Zusammenh nge zwischen ver schiedenen Systemzust nden hergestellt Funktionsanforderungen zeichnen sich dadurch aus dass sie zun chst einen be stimmten Ausgangszustand beschreiben von dem aus ein anderer Systemzustand Zielzustand erreicht werden muss Der Ausgangs und der Zielzustand unterschei den sich dabei mindestens um den Wert einer einzelnen Systemvariablen z B die Aktivit t eines Motors Ein typisches Beispiel f
169. en an ein Steu erungsprogramm k nnen nun der Modalparameter und der Zeitparameter in einer Matrix vereinigt werden Einfache Forderung ES Einfaches Verbot DEs1 Zustand PRs1 Zustand DEs2 Direkt DEs3 Selbstbegrenzt PRs Selbstbegrenzt DEs4 Fremdbegrenzt PRs4 Fremdbegrenzt DEs5 Unbegrenzt PRs5 Unbegrenzt Erweiterte Forderung DEe1 Zustand DEe2 Direkt Nicht definiert DEe3 Selbstbegrenzt DEe4 Fremdbegrenzt DEe5 Unbegrenzt Tabelle 4 Matrix aus automatisierungstechnisch relevanten Kategorien und Beobachtungsintervallen Die nichtrelevanten Kategorien wurden in der Tabelle 4 wiederum grau hinterlegt Da die Formulierung von direkten Beobachtungsintervallen nur f r Forderungen sinnvoll ist werden letztendlich durch den Modal und den Zeitparameter insgesamt 18 An forderungskategorien definiert Diese 18 Anforderungskategorien unterscheiden sich jedoch auch stark hinsichtlich ihrer Relevanz bzw ihren Einsatzm glichkeiten bei der Spezifikation eines Steue rungsprogramms Sie umfassen neben den bereits dargestellten Anforderungen aus der Automatisierungstechnik auch Eigenschaftsklassen wie sie in der Informatik be kannt und blich sind Zu diesen geh ren z B Fortschritts Lebendigkeits und Si cherheitseigenschaften die sich in der Matrix nach Tabelle 5 wiederfinden lassen Thematik Darstellung mit SFS Bezeichnung in der Informatik Sollverhalten der DEs1 DEs2 DEe1 Fortschritts
170. endungsnahen forma len Spezifikation beschreibt Ziel ist die Erzeugung einer Steuerung mit spezifizierten Sicherheitseigenschaften wobei der Generierungsprozess die Einhaltung der Sicherheitsbedingungen garantiert Mit einer nicht n her ausgef hrten Spezifika tionssprache CSLxt kann die Funktion durch die Angabe bedingter Zielzust nde be schrieben werden Diese enth lt die Beschreibung von Eingangszust nden Aus gangszust nden internen Zust nden sowie die Definition von Sicherheitseigen schaften In einem anschlie enden Minimax Verfahren wurde die Steuerung gene riert K Lemmer et al beschreiben in Lemm95 wie dieser Synthesevorgang durchge f hrt werden kann Der vorgestellte Ansatz wird auch in Hani96 und Hani98 beschrieben wobei Hanisch Rausch Thieme und L der Uni Magdeburg eine auto matische Codegenerierung auf der Basis von Netzmodellen pr sentieren Durch Modellierung der ungesteuerten Strecke der zu steuernden Maschine bzw Anlage mit Netzstrukturen erfolgt eine Beschreibung des physikalisch m glichen Verhaltens dieser Maschine Mit Hilfe der Spezifikation verbotener Zust nde Fakten sowie der Beschreibung geforderter Abl ufe Start und Zielstellen f r Marken l sst sich die zugeh rige Steuerung berechnen Die vorgestellte Methodik wurde in den Tools SAFECODE und MASC umgesetzt und erlaubte die automatische Codeerzeugung in IEC 1131 3 konforme Sprachen Zwei weitere Forschungsprojekte sollen noch erw h
171. ensweisen zu sein Wie in der Abbildung 4 zu erkennen ist stellt die formale Spezifikation als direkte Repr sentation des Pflichtenheftes eine Grundlage f r beide Vorgehensweisen dar und ist somit ein zentraler Bestandteil al ler weiteren Bem hungen um eine korrekte Software 12 Einleitung und Ausgangssituation 1 4 1 MaBnahmen im Vorfeld der Softwareentwicklung Wie bereits angedeutet gibt es bereits im Vorfeld der Erstellung eines Programms eine Reihe von M glichkeiten Einfluss auf die Qualit t des sp teren Produktes also der Software zu nehmen An dieser Stelle sollen zwei Ma nahmen in diesem Be reich kurz vorgestellt werden die Einf hrung von Qualit tsmanagement Prozessen und die Arbeit gem Vorgehensmodellen 1 4 1 1 Qualit tsmanagement Prozesse In den letzten Jahren haben sich verschiedene spezielle Formen von Qualit tsmana gement Prozesse herausgebildet die sich aufgrund ihres Konzeptansatzes ihrer Zielstellung ihrer Durchf hrung und ihres Detaillierungsgrades unterscheiden Zu s tzlich sind durch den Einsatz in verschiedenen technischen Branchen weitere Un terscheidungsmerkmale gegeben Allen gemeinsam ist ihr Ziel die Prozessqualit t zu verbessern Durch die Norm ISO 9000 und die mit ihr verbundenen Normen wird das Verh ltnis von Auftraggebern und Lieferanten in einem allgemeinen bergeordneten organisa torischen Rahmen zur Qualit tssicherung festgelegt Balz98 Dabei zielt die Normengruppe ISO 9
172. er halten Durch das Verhalten des Systems in bestimmten Situationen werden seine Eigenschaften engl characteristics bestimmt Ein Prozess engl process ist die Gesamtheit von aufeinander einwirkenden Vor g ngen in einem System durch die Materie Energie oder Information umgeformt transportiert oder gespeichert wird Ein Modell engl model ist eine Abbildung eines Systems oder Prozesses in ein anderes begriffliches oder gegenst ndliches System das aufgrund der Anwendung bekannter Gesetzm igkeiten einer Identifikation oder auch getroffener Annahmen gewonnen wird und das System oder den Prozess be z glich ausgew hlter Fragestellungen hinreichend genau abbildet Es stellt die als wesentlich erachteten Eigenschaften eines Systems in einer zweckm igen Form dar 113 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Eine Methode engl method bestimmt und beschreibt die planmaBige Vorgehens weise um ein bestimmtes wissenschaftliches oder praktisches Ziel zu erreichen Chou98b Durch sie wird die Art und die Anwendung der einzusetzenden Mittel so wie die Reihenfolge der durchzuf hrenden Aktivit ten festgelegt In Verbindung mit einem Werkzeug Tool rechnerunterst tztes Hilfsmittel wird aus einer Methode ein Verfahren engl procedure Ein Algorithmus engl algorithm DIN 19226 1 ist eine vollst ndig festgelegte end liche Folge von Vorschriften nach denen aus zul ssigen Eingangsgr en
173. er Arbeit wird die Sicherheitsfachsprache wie folgt dargestellt Der Abschnitt 1 beinhaltet grundlegende Aussagen zur Korrektheit und Sicherheit von Software und stellt Wege und Mittel dar wie sich die Qualit t von Software erh hen l sst Im Abschnitt 2 werden typische Anforderungen an ein formales Beschreibungsmittel zusammengefasst das den Gegebenheiten eines Einsatzes in der modernen Steue rungstechnik gerecht werden soll Aus diesen Anforderungen wird im Abschnitt 3 die Sicherheitsfachsprache abgeleitet Dazu werden die steuerungstechnischen Anforderungen kategorisiert die Parameter der SFS werden abgeleitet und erl utert Au erdem wird in diesem Abschnitt die F Snezifikati ktiver diner Si itst berf hrung der Anforderungen in die formale Basis der SFS die Temporale Logik dargestellt Im Abschnitt 4 schlie t sich eine Darstellung der prototypischen Realisierung der Sicherheitsfachsprache und deren Anwendung an Hier wird erl utert wie die kon kreten steuerungstechnischen Objekte Sensoren Aktoren in die SFS eingebunden werden wie die Anforderungen erstellt und in die temporallogischen Formeln ber f hrt werden Au erdem wird ein Verfahren vorgestellt mit dem ein m glichst umfas sendes Set an Anforderungen erstellt werden kann Der Abschnitt 5 enth lt eine Fallstudie mit deren Hilfe die umfassenden M glichkei ten der SFS an einem realen Beispiel demonstriert und nachgewiesen werden sollen Wegen des gr
174. erden sobald ein Rohteil im Eingangspuffer liegt erkennbar durch den Sensor am Eingangspuffer und keine anderen Bedingungen gegen den Beginn der Bear beitung sprechen In diesem Fall soll die Anzeige Anlage bereit verl schen und die Anzeige Automatik l uft soll aufleuchten Durch jedes Teil das ber den Eingangspuffer in die Produktionszelle hineingelangt soll der Eingangszahler um den Wert 1 erh ht werden durch jedes Teil das die Produktionszelle verl sst Sensor im Ausgangspuffer soll der Ausgangsz hler um den Wert 1 erh ht werden Der automatische Betrieb wird solange aufrechterhalten wie sich Rohteile im Eingangspuffer befinden Befinden sich keine Rohteile mehr im Eingangspuffer werden alle Teile die sich noch in der Produktionszelle befinden weiter bearbeitet bis auch sie die Zelle verlassen haben In diesem Fall zeigen der Eingangs und der Ausgangsz hler den gleichen Wert an d h die Bearbeitung die ser Charge wurde vollst ndig abgeschlossen Dadurch werden die Fertig und die Bereitschaftsmeldung der Produktionszelle gesetzt die Anzeige Automatik l uft erlischt und die Anzeige Anlage bereit leuchtet auf Tritt w hrend des automatischen Betriebs der Produktionszelle eine St rung auf so kann z B durch das Bedienpersonal ein Not Aus ausgel st werden In diesem Fall m ssen alle Aktionen innerhalb der Produktionszelle gestoppt werden d h alle Aktoren bis auf die Magnetgreife
175. erden und die Bereitschaftsmeldung Zuf hrband ist zur bernahme eines Teils bereit muss unmittelbar gesetzt werden 195 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache AG rdy_in amp Fbelt_state 1 amp LB_at_fbelt gt Al rdy_plc U rdy_plc amp FBelt_start amp Fbelt_state 11 amp Fbelt_ready_give amp Fbelt_ready_take gt gt gt Satz 99 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Zufiihrbands 2 ist und die Lichtschranke am Ende des Zufiihrbands ist frei dann muss der Antrieb des Zuftihrbands unmittelbar gestoppt werden und die Zustandsvariable des Zufiihrbands muss unmittelbar auf 21 gesetzt werden und die Fertigmeldung Zuf hrband hat Teil auf Tisch abgelegt muss unmittelbar gesetzt werden und die Bereitschaftsmeldung Zuf hrband ist zum Transport bereit muss unmittelbar gesetzt werden AG rdy_in amp Fbelt_state 2 amp LB_at_fbelt gt Al rdy_plc U rdy_plc amp FBelt_start amp Fbelt_state 21 amp Fbelt_done_gqgive amp Fbelt_ready_transport gt gt gt Satz 100 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Zuf hrbands 11 ist dann muss die Zustandsvariable des Zufiihrbands unmittelbar auf 0 gesetzt werden AG rdy_in amp Fbelt_state 11 gt Al rdy_plc U rdy_plc amp Fbelt_state 0 gt gt gt Satz 10
176. erenzzeitpunkt nexttime Operator im n chsten Zeitpunkt gilt eventually sometime finally i A RE Operator irgendwann gilt schlie lich henceforth always globally Ee A generally Operator von nun an gilt immer until Operator X gilt solange bis y gilt Tabelle 7 Beispiele f r Temporaloperatoren 52 Die Sicherheitsfachsprache 3 2 3 Computation Tree Logic Innerhalb der Temporalen Logik sind zwei Sichtweisen der Zeit mdglich 1 Lineare Sichtweise Hierbei gibt es f r jeden Zeitpunkt nur eine m gliche Zu kunft Verzweigungen zu alternativen Varianten sind nicht m glich linear TL 2 Verzweigte Sichtweise Hierbei gibt es an bestimmten Zeitpunkten die M g lichkeit dass sich die Zeit durch Nichtdeterminismus verzweigt Es gibt meh rere Alternativen der Zukunft branching time TL Um Zustandssequenzen eines Systems beschreiben zu k nnen ben tigt man eine Logik die es gestattet die relativen Zeitbegriffe der Sicherheitsfachsprache sofort nie solange zu verwenden Die Wahl fiel auf CTL Computation Tree Logic eine Temporale Logik die sich an der zweiten Sichtweise orientiert Neben den bereits erw hnten TL Operatoren gibt es f r branching time Logiken die zus tzlichen Pfad bzw Wegquantoren A on all paths bzw E on some paths Damit ergeben sich die folgenden Grundoperationen EX in mindestens einem Pfad der dem aktuellen Zu
177. erigen nicht starr festgelegt Der Zeitpunkt des Endzustandes wird durch den Bedingungsteil der Anforderung gegeben Selbstbegrenzt Der Startzustand ist hierbei wie blich mit der Erf llung der Bedingung gegeben S entspricht dem Zustand in dem B erfullt wird Der Endzustand ist gegeben sobald die definierte Bedingung erstmals nicht mehr erf llt ist E entspricht dem Zustand in dem B nicht mehr erf llt wird Fremdbegrenzt Das Beobachtungsintervall wird vom Startzustand eingeleitet S entspricht dem Zustand in dem B erf llt wird der Endzustand ist durch die Erf llung einer zus tzlichen Bedingung gegeben E entspricht dem Zustand in dem B2 erf llt wird Die Bedingung B muss dabei inner halb des Beobachtungsintervalls nicht unbedingt wahr bleiben Unbegrenzt Das Beobachtungsintervall wird ebenfalls vom Startzustand ein geleitet hat jedoch kein Ende Es handelt sich hierbei um ein offenes Intervall Die Abbildung 10 soll diese f nf Varianten des Beobachtungsintervalls noch einmal verdeutlichen S E S Startzustand Zustand Soe E Endzustand B B B Bedingung Zustandswechsel J False gt True Beobachtungsintervall Direkt Selbstbegrenzt Fremdbegrenzt Unbegrenzt Zeit Zyklusanzahl z Abbildung 10 Definition der Beobachtungsintervalle 46 Die Sicherheitsfachsprache 3 1 5 Anforderungsmatrix Fur die Zusammenstellung der verschiedenen Arten von Anforderung
178. ermeidenden Schadensfall werden die m glichen Ursachen und Wege da hin analysiert Beispiel Fehlerbaumanalyse engl Fault tree analysis FTA Cause tree method CTM nach DIN 25424 Wie zu erkennen ist sind die meisten dieser Verfahren bereits standardisiert dar ber hinaus gibt es auch intensive Forschungen auf diesem Gebiet In Hube97 wird ein Verfahren der qualitativen Systemanalyse beschrieben HAZOP das eine com puterunterst tzte Gefahrenidentifikation im Bereich der Chemietechnik erm glicht Hierbei werden gesicherte Wertebereiche der jeweiligen technischen Gr en fest gelegt mit denen anschlie end so genannte Situationstabellen berechnet werden die anzeigen sollen ob eine gef hrliche Situation eintreten kann oder nicht Ein hnliches Verfahren der Gefahrenanalyse wird in Bieg98 dargestellt Das Ver fahren SQMA beinhaltet eine simulationsbasierte qualitative Modellbildung und Ana lyse des untersuchten Systems wobei alle technischen M glichkeiten die das Sys tem einnehmen kann aufgestellt werden An dieser Aufstellung lassen sich anschlie Bend die gef hrlichen Zust nde identifizieren Ein besonderer Schwerpunkt der Aktivit ten erw chst aus dem Bereich der Luftfahrt und Automobilindustrie St l98 Gerade der Einsatz moderner X by wire Technik erfordert strengere Ma nahmen bei der sicherheitsorientierten Systemanalyse Die Autoren beschreiben eine methodenbasierte Erarbeitung von Uberwachungsverfah re
179. ers nach rechts muss unmittelbar gestartet werden 209 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache AG rdy_in amp Robot_state 0 amp Robot_run_unload gt Al rdy_plc U rdy_plc amp Robot_run_unload amp Robot_state 2 amp Robot Tighe gt gt gt Satz 120 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 0 ist und das Startsignal Roboter be und entl dt Presse ist gesetzt dann muss das Startsignal Roboter be und entl dt Presse unmittelbar zur ckgesetzt werden und die Zustandsvariable des Roboters muss unmittelbar auf 3 gesetzt werden und die Drehung des Roboters nach rechts muss unmittelbar gestartet werden AG rdy_in amp Robot_state 0 amp Robot_run_mix gt Al rdy_plc U rdy_plc amp Robot_run_mix amp Robot_state 3 amp Robot_right gt gt gt Satz 121 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 1 ist und der Roboter ist mit dem Arm 1 vor dem Hubdrehtisch dann muss die Drehung des Roboters nach rechts unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 11 gesetzt werden und das Ausfahren des Roboterarms I muss unmittelbar gestartet werden AG rdy_in amp Robot_state 1 amp Robot_angle 50 gt Al rdy_plc U rdy_plc amp Robot_right amp Robot_state 11 amp Arml_forward
180. es Kriterium einer Spezifikationsmethodik ist ihr potenzielles Einsatzgebiet Bei der in dieser Arbeit vorgestellten Sicherheitsfachsprache ist dies die Spezifikation von Steuerungsprogrammen f r industrielle Fertigungsanlagen Deshalb muss zun chst definiert werden welche Strukturen in solchen Fertigungs anlagen bereits gegeben sind 2 3 1 Strukturen von automatisierten Systemen Moderne Fertigungsbetriebe sind typischerweise hierarchisch in verschiedene Betriebsebenen unterteilt Wenn auch die in der Literatur dargestellten Gliederungen selten exakt bereinstimmen so wie auch ein Betrieb selten exakt wie ein anderer aufgebaut ist so l sst sich dennoch eine gemeinsame Struktur herausarbeiten Abbildung 6 vergleiche Polk92 Kasp94 Beus94 Ahre00 PPS Unternehmensleitebene CAx EDV Planungsebene B ronetzwerk Fabrikbus Fertigungs Produktionsleitebene leitrechner Backbone Netzwerk Prozessbus F hrungsebene DEREN Zellenrechner 1 Prozessleitebene PLC NC CNC RC MDE BDE Steuerungsebene Zellennetzwerke Feldbus H Wd Sensor Aktor Bus Sensoren Aktoren Feldebene Abbildung 6 Betriebliches Ebenenmodell Man findet eine hierarchische Gliederung des betrieblichen Ebenenmodells in vier oder auch f nf Ebenen wobei die F hrungs und die Steuerungsebene immer weiter miteinander verschmelzen Insgesamt l sst sich feststellen dass die bisherigen Strukturen durch ver
181. esetzt und die Bereitschaftsmeldung Zuf hrband ist zum Transport bereit ist gesetzt dann muss die Fertigmeldung Kran hat eine Rohteil auf das Zuf hrband gelegt unmittelbar zur ckgesetzt werden und muss die Bereitschaftsmeldung Zuf hrband ist zum Transport bereit unmittelbar zur ckgesetzt werden und muss das Startsignal Zuf hrband soll Teil zum Bandende transportieren unmittelbar gesetzt werden AG rdy_in amp cell_l_state 1 amp Crane_done_give_fbelt amp Fbelt_rdy_transport gt Al rdy_plc U rdy_plc amp Crane_done_give_fbelt amp Fbelt_rdy_transport amp Fbelt_run_transport gt gt gt Satz 28 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Automatikbetrieb ist und die Bereitschaftsmeldung Hubdrehtisch ist zur bernahme eines Teils bereit ist gesetzt und die Bereitschaftsmeldung Zuf hrband ist zur bergabe bereit ist gesetzt dann muss die Bereitschaftsmeldung Hubdrehtisch ist zur bernahme eines Teils bereit unmittelbar zur ckgesetzt werden und muss die Bereitschaftsmeldung Zuf hrband ist zur bergabe bereit unmittelbar zur ckgesetzt werden und das Startsignal Zuf hrband soll Teil auf Tisch bef rdern muss unmittelbar gesetzt werden AG rdy_in amp cell_l_state 1 amp Table_rdy_take amp Fbelt_rdy_give gt Al rdy_plc U rdy_plc amp Table_rdy_take amp Fbelt_rdy_give am
182. estoppt und gelangt wieder in den Ruhezustand Fertigteile zum Ausgangspuffer bringen Bei diesem Transportvorgang ist die Fahrtrichtung eindeutig bestimmbar da das Ablageband am u eren Ende des Verfahrbereichs liegt Die anschlie enden Vor g nge verlaufen analog zu den soeben beschriebenen Vorg ngen Am Ablageband muss der Greifer bis auf die H he des Ablagebands abgesenkt werden der Mag netgreifer wird aktiviert und der Greifer wieder angehoben Gleichzeitig kann auch die Meldung Kran hat Teil vom Ablageband genommen gesetzt werden Nach der Fahrt zum Ausgangspuffer wird der Greifer wieder abgesenkt der Magnet wird deak tiviert und der Greifer wieder angehoben Nachdem der Greifer seine obere Position wieder erreicht hat wird er gestoppt und gelangt wieder in den Ruhezustand Da die gezeigten Teilvorg nge unbedingt in der festgelegten Reihenfolge abzuar beiten sind bietet sich die Entwicklung einer Ablaufstruktur an Definition neuer Daten mit dem SFS Editor Es wird eine Zustandsvariable definiert die den aktuellen Zustand darstellt in dem sich der Kran bzw die Ablaufsteuerung des Krans befindet Interne Variable der Steuerung des Krans Technische Bezeichnung SPS Variable Datentyp Kommentar Zustandsvariable des Krans Crane_state Integer Tabelle 27 Datenebene 4 Interne Variable der Steuerung des Krans 71 INT VAR Crane_state die Zustandsvariable des
183. eug dargestellt das den spezifischen Gegebenheiten eines Ein satzes in der Steuerungstechnik gerecht werden soll Ausgehend von diesen Anfor derungen wurde die Sicherheitsfachsprache entwickelt siehe Meie99 Hein01 und Mert01 die folgende Anforderungen erf llen soll 1 eindeutige nat rlichsprachliche Formulierung von steuerungstechnischen Anforderungen 2 durchg ngige und bereichs bergreifende Anwendung in allen Phasen der Softwareentwicklung 3 Abdeckung aller steuerungstechnisch relevanten Kategorien auch solcher die mit herk mmlichen Methoden nicht darstellbar sind 3 1 Definition der SFS Herausragende Anforderung an die Sicherheitsfachsprache ist die Verwendung der nat rlichen deutschen Sprache f r die Spezifikation Deshalb ist es notwendig sich mit dem Aufbau und den Strukturen der deutschen Sprache auseinander zu setzen Die nat rliche Sprache mit der wir t glich umgehen unterliegt bestimmten Regeln Flie86 K rs93 Sie hat wie eine k nstliche Sprache eine Semiotik Syntax und Grammatik Ihre Semantik ist jedoch nicht eindeutig die bestehenden Mehrdeutig keiten wurden bereits erw hnt Ziel ist es deshalb nicht ein komplexes System zur Sprach bzw Texterkennung zu entwickeln wof r es andere vielversprechende Forschungsprojekte gibt Vielmehr wird mit der Sicherheitsfachsprache ein Weg eingeschlagen der eine st rkere Reg lementierung der formulierbaren S tze benutzt Vergleichbare deutschs
184. fer dann muss die Bewegung des Krans nach rechts Ablageband unmittelbar gestoppt werden und die Zustandsvariable des Krans muss unmittelbar 11 werden und das Absenken des Krangreifers muss unmittelbar gestartet werden AG rdy_in amp Crane_state 16 amp Crane_at_source gt Al rdy_plc U rdy_plc amp Crane_to_dbelt amp Crane_state 11 amp Crane_lower gt gt gt Satz 72 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 1b ist und der Kran ist am Eingangspuffer dann muss die Bewegung des Krans nach links zum Zuf hrband unmittelbar gestoppt werden und die Zustandsvariable des Krans muss unmittelbar 11 werden und das Absenken des Krangreifers muss unmittelbar gestartet werden AG rdy_in amp Crane_state 17 amp Crane_at_source gt Al rdy_plc U rdy_plc amp Crane_to_fbelt amp Crane_state 11 amp Crane_lower gt gt gt Satz 73 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 1b ist und der Kran ist am Zuf hrband dann muss die Bewegung des Krans nach links zum Zuf hrband unmittelbar gestoppt werden und die Zustandsvariable des Krans muss unmittelbar Ic werden und die Bewegung des Krans nach rechts Ablageband muss unmittelbar gestartet werden AG rdy_in amp Crane_state 17 amp Crane_at_fbelt gt Al rdy_plc U rdy_plc amp Crane_to_fbelt
185. ferbewegung an den Endpunkten unter Ber cksichtigung der Position des Krans H he der F rderb nder sowie des Eingangs bzw Ausgangspuffers Der Greifer des Krans darf nur an bestimmten sicheren Orten deaktiviert werden Formale Spezifikation mit dem SFS Editor gt gt gt Satz 86 lt lt lt einfaches Verbot Zustand die Bewegung des Krans nach links zum Zuf hrband darf nicht gleichzeitig gestartet sein wenn der Kran am Zuf hrband ist AG rdy_plc amp Crane_at_fbelt amp Crane_to_fbelt 92 Validierung des Prototypen anhand einer Fallstudie gt gt gt Satz 87 lt lt lt einfaches Verbot Zustand die Bewegung des Krans nach rechts Ablageband darf nicht gleichzeitig gestartet sein wenn der Kran am Ablageband ist AG rdy_plc amp Crane_at_dbelt amp Crane_to_dbelt gt gt gt Satz 88 lt lt lt einfaches Verbot Zustand das Anheben des Krangreifers darf nicht gleichzeitig gestartet sein wenn der Greifer des Krans oben ist AG rdy_plc amp Crane_height 0 amp Crane_lift gt gt gt Satz 89 lt lt lt einfaches Verbot Zustand das Absenken des Krangreifers darf nicht gleichzeitig gestartet sein wenn der Greifer des Krans unten ist AG rdy_plc amp Crane_height 1 0 amp Crane_lower gt gt gt Satz 90 lt lt lt einfaches Verbot Zustand das Ab
186. ffer darf nur gesetzt sein wenn gleichzeitig der Eingangspuffer belegt ist AG rdy_plc amp Piece_at_source amp Crane_run_source gt gt gt Satz 25 lt lt lt erweiterte M glichkeit Zustand I das Startsignal Kran holt Rohteil vom Eingangspuffer darf nur gesetzt sein wenn gleichzeitig die Bereitschaftsmeldung Zuf hrband ist zur Ubernahme eines Teils bereit gesetzt ist AG rdy_plc amp Fbelt_ready_take amp Crane_run_source 5 3 3 Ger teebene 3 Der Kran Bei Beschreibung der Spezifikation f r die Komponenten der Ger teebene 3 wird ausschlie lich der Kran betrachtet die Spezifikation der anderen Komponenten er folgt analog und kann dem Anhang entnommen werden Gegebene Daten Die Steuerung des Krans erh lt von der bergeordneten Zellensteuerung Startsig nale zur Ausf hrung bestimmter Aktionen Durch verschiedene Sensoren und Akto ren ist die Kransteuerung mit den Maschinenelementen verbunden aus der Datenebene 3 sind die Kommunikationssignale bekannt siehe Tabelle 24 Anhang Seite 176 und Tabelle 19 Anhang Seite 159 in der Datenebene 4 sind die Sensoren bekannt siehe Tabelle 25 Anhang Seite 181 in der Datenebene 4 sind die Aktoren bekannt siehe Tabelle 26 Anhang Seite 181 90 Validierung des Prototypen anhand einer Fallstudie Aufgabe Der Steuerung des Krans verbleibt solange in Ruhe bis durch die Zellensteuerung
187. ftsmeldung Presse ist zur bergabe eines Teils bereit gesetzt ist AG rdy_plc amp Press_ready_give amp Robot_run_unload gt gt gt Satz 45 lt lt lt erweiterte M glichkeit Zustand das Startsignal Roboter bel dt Presse darf nur gesetzt sein wenn gleichzeitig die Bereitschaftsmeldung Hubdrehtisch ist zur bergabe eines Teils bereit gesetzt ist AG rdy_plc amp Table_ready_give amp Robot_run_load gt gt gt Satz 46 lt lt lt erweiterte M glichkeit Zustand I das Startsignal Roboter entl dt Presse darf nur gesetzt sein wenn gleichzeitig die Bereitschaftsmeldung Ablageband ist zur bernahme eines Teils bereit gesetzt ist AG rdy_plc amp Dbelt_ready_take amp Robot_run_unload gt gt gt Satz 47 lt lt lt erweiterte M glichkeit Zustand das Startsignal Roboter be und entl dt Presse darf nur gesetzt sein wenn gleichzeitig die Bereitschaftsmeldung Hubdrehtisch ist zur bergabe eines Teils bereit gesetzt ist und die Bereitschaftsmeldung Presse ist zur bergabe eines Teils bereit ist gesetzt und die Bereitschaftsmeldung Ablageband ist zur bernahme eines Teils bereit ist gesetzt AG rdy_plc amp Table_ready_give amp Press_ready_give amp Dbelt_ready_take amp Robot_run_mix gt gt gt Satz 48 lt lt lt erweiterte M glichkeit Zustand
188. ftware vol 13 pp 209 230 1990 Alag98 Alagar V S Periyasamy K Specification of Software Systems Springer New York 1998 Alur96 Alur R Henzinger T A Ho P H Automatic Symbolic Verifica tion of Embedded Systems IEEE Transactions on Software Engineering 22 181 201 1996 Balz96 Balzert H Lehrbuch der Software Technik Software Entwick lung Spektrum Akademischer Verlag GmbH Heidelberg Berlin Oxford 1996 Balz98 Balzert H Lehrbuch der Software Technik Software Manage ment Software Qualit tssicherung Unternenmensmodellierung Spektrum Akademischer Verlag GmbH Heidelberg Berlin 1998 Best95 Best E Grahlmann B PEP Programming Environment Based on Petri Nets Documentation and User Guide Universit t Hil desheim Institut f r Informatik 1995 Beus94 Beuschel J Prozesssteuerungssysteme Oldenbourg Verlag M nchen 1994 Bibe93 Bibel W Wissensreprasentation und Inferenz Eine grundle gende Einf hrung Vieweg Verlag Braunschweig Wiesbaden 1993 Bieg98 Biegert U Gefahrenanalyse auf der Basis von qualitativen Modellen Institut f r Automatisierungs und Softwaretechnik der Universit t Stuttgart Dechema Jahresbericht 1998 Birk00 Birkhofer H Schulz J N tzke D Anforderungen nutzen Um fassende Dokumentation und effizienter Zugriff auf Anforderungen durch AM Technologie Zeitschrift f r wirtschaftlic
189. g 21 2 q 1 SE Ww 1 W q 2 I q 2 W Anhang SR we ZA O_O auf 0 gesetzt _O auf 1 gesetzt O auf 2 gesetzt O auf 11 gesetzt 12_0 auf 12 gesetzt O auf 21 gesetzt Press_run_work Press_run_prepare Press_run_prepare Press_run_work 2 Press_upward Press_upward Press_top Press_middle Press_upward Press_down Press_upward a Press_rdy_take Press_bottom true Press down Press_rdy_give true Formale Spezifikation mit dem SFS Editor Ablauf Presse gt gt gt Satz 164 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Presse 0 ist und das Startsignal Presse soll pressen ist gesetzt dann muss das Startsignal Presse soll pressen unmittelbar zur ckgesetzt werden und die Zustandsvariable der Presse muss unmittelbar auf 1 gesetzt werden und das Schliessen der Presse muss unmittelbar gestartet werden AG rdy_in amp Press_state 0 amp Press_run_work gt Al rdy_plc U rdy_plc amp Press_run_work amp Press_state l amp Press_upward gt gt gt Satz 165 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Presse 0 ist und das Startsignal Presse soll Beladung vorbereiten ist gesetzt dann muss das Startsignal Presse soll Beladung vorbereiten unmittelbar zur
190. g und Ausblick 6 Zusammenfassung und Ausblick Mit der vorgestellten Sicherheitsfachsprache ist es m glich die gew nschten Funk tions und Sicherheitseigenschaften eines Steuerungsprogramms verbal zu formulie ren Durch die Nutzung der nat rlichen Sprache ist jetzt eine sehr elementare und auch f r Nichtspezialisten verst ndliche Darstellungsform gegeben Die SFS geht damit ber die M glichkeiten bisheriger Beschreibungsmittel hinaus weil mit ihr ei nerseits eine Verst ndigung zwischen verschiedenen Projektpartnern m glich wird und mit der Kategorie der Verbote au erdem Anforderungen darstellbar werden die mit bisher verf gbaren Beschreibungsmitteln nicht formulierbar waren Da die Formulierung von Programmanforderungen mit Hilfe der nat rlichen Sprache aufgrund ihrer Mehrdeutigkeit zun chst sehr problematisch ist wurde die Sicher heitsfachsprache gem den typischen steuerungstechnischen Zusammenh ngen Anforderungen und Formulierstilen definiert Sie bietet durch die formale Vorgabe einer Syntax die M glichkeit der Hinterlegung einer formalen Semantik durch die Vorgabe fester Satzmuster und strukturen werden klare und leicht lesbare Darstel lungen erzeugt Ziel der SFS ist es weiterhin den Anwender durch eindeutige und leicht verst ndliche Formulierungen zu einer klaren Problemdefinition zu zwingen Als Grundmuster der S tze dient das Konditional wenn dann weil dem An wender das Denken in solchen Ka
191. g und Initiative des Anwenders auch gr ere Zusammensetzungen m glich Verbindungen von weiteren Verben Substantiven und Adjektiven Adver bien Umstandsbestimmungen Vergleichsoperatoren usw Die Erstellung der Nomen und Werte ist ein Prozess der eine gewisse Kreativit t und Weitsicht des Anwenders verlangt Hierbei sind verschiedene Randbedingungen zu beachten damit einerseits die bestehenden Restriktionen der SFS eingehalten werden andererseits eine m glichst freie und nat rliche Formulierung m glich ist In den folgenden Abs tzen werden einige Informationen und Anregungen gegeben wie die erforderlichen Nomen und Werte zu erstellen sind 70 Prototypische Realisierung und Einsatz der Sicherheitsfachsprache Einsatz der Nomen Wert Kombinationen in Bedingungen bzw Folgerungen Die erzeugten Nomen Wert Kombinationen werden sowohl bei der Formulierung des Bedingungs als auch des Folgerungsteils der Anforderungss tze verwendet Als Besonderheit ist zu erw hnen dass SPS Variablen die Sensoren repr sentieren nur innerhalb von Bedingungen sinnvoll verwendet werden k nnen Aktor Variablen wer den dagegen typischerweise f r die Darstellung der Folgerungen verwendet k nnen aber auch in Bedingungen eingesetzt werden SPS interne Variablen werden in Be dingungen und in Folgerungen gleicherma en verwendet Es erweist sich aus die sem Grund als sinnvoll und auch notwendig f r Aktor und f r interne Variablen zu s tzliche Wert
192. gebnisse zu interpretieren Funktionsabdeckung Funktionalit t functionality Eignung der Software seine spe zifizierten Funktionen entsprechend den gegebenen Erfordernissen auszuf hren Instandsetzbarkeit Pflegbarkeit maintainability Eignung der Software die Erken nung von Fehlerursachen und die Beseitigung von Fehler zu gew hr leisten Portabilit t portability Eignung der Software zum Einsatz in unterschiedlichen vor gegebenen Hardware oder Softwaresystemen Sicherheit Eigenschaft der Software frei von Gef hrdungen zu sein Verkn pfbarkeit Eigenschaft des Programms mit anderen Softwaresystemen ver bunden zu werden Dar ber hinaus gibt es jedoch auch f r Dokumente die im Zusammenhang mit einer Software existieren eine Reihe von Qualit tsmerkmalen Gl e98 DGQ98 DGQ86 DIN 66270 Qualit t der Dokumente Dokumentation nderbarkeit Eignung von Dokumenten zur Ermittlung aller von einer nderung be troffenen Dokumententeilen und zur Durchf hrung der Anderung Aktualit t bereinstimmung der Beschreibung eines Programms in Dokumenten mit dem jeweils geltenden Zustand des Programms Eindeutigkeit Eignung von Dokumenten zur unmissverst ndlichen Vermittlung der gleichen Information an den Leser Identifizierbarkeit Eindeutige Ansprechbarkeit der Teile von Dokumenten die Anga ben zu einem abgegrenzten Sachverhalt enthalten Normenkonformit t Erf llung der f r die Erstellung von Dokumente
193. gendwann lt Wert gt werden darf irgendwann lt Nomen gt lt Wert gt werden lt Nomen gt darf nicht gleichzeitig lt Wert gt sein darf lt Nomen gt nicht gleichzeitig lt Wert gt sein darf nicht gleichzeitig lt Nomen gt lt Wert gt sein lt Nomen gt darf niemals gleichzeitig lt Wert gt sein darf lt Nomen gt niemals gleichzeitig lt Wert gt sein darf niemals gleichzeitig lt Nomen gt lt Wert gt sein lt Nomen gt darf nicht irgendwann lt Wert gt werden darf lt Nomen gt nicht irgendwann lt Wert gt werden darf nicht irgendwann lt Nomen gt lt Wert gt werden lt Nomen gt darf niemals lt Wert gt werden darf lt Nomen gt niemals lt Wert gt werden darf niemals lt Nomen gt lt Wert gt werden lt back_concl_sg gt lt Nomen gt muss gleichzeitig lt Wert gt sein lt Nomen gt muss gleichzeitig lt Wert gt bleiben lt Nomen gt muss nur lt Wert gt sein lt Nomen gt muss nur lt Wert gt bleiben lt Nomen gt muss unmittelbar lt Wert gt werden lt Nomen gt muss sofort lt Wert gt werden lt Nomen gt wird unmittelbar lt Wert gt lt Nomen gt wird sofort lt Wert gt lt Nomen gt muss nur unmittelbar lt Wert gt werden
194. gmeldungen der Produktionszellen Technische Bezeichnung Variable Datentyp Kommentar Fertigmeldung cell_1_finished Bool Zelle 1 ist mit Auftrag fertig Zelle 1 Fertigmeldung cell_2_finished Bool Zelle 2 ist mit Auftrag fertig Zelle 2 Fertigmeldung cell_n_finished Bool Zelle n ist mit Auftrag fertig Zellen Tabelle 12 Datenebene 2 Fertigmeldungen der Produktionszellen 143 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache 6611 U 610 BOOL VAR_GLOBAL cell_1_finished TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt BOOL VAR_GLOBAL cell_2_finished W TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt die Fertigmeldung der Produktionszelle 1 die Fertigmeldung der Produktionszelle 2 Datenebene 2 Bereitschafts und Fertigmeldung des Transportsystems portsystem Technische Variable Datentyp Kommentar Bezeichnung Bereitschaftsmeldung tr_sys_ready Bool Transportsystem ist f r Transportsystem neuen Auftrag bereit Fertigmeldung Trans tr_sys_finished Bool Transportsystem hat Auf trag ausgef hrt Tabelle 13 Datenebene 2 Bereitschafts und Fertigmeldung des Transportsystems die Bereitschaftsmeldung des
195. gnal Presse ent Robot_run_unload Bool laden Startsignal Mixbetrieb Robot_run_mix Bool Meldung Roboter wartet Robot_wait_mix Bool vor Presse Startsignal Weiter im Mix Robot_run_cont Bool Fertigmeldung Presse be Robot_done_load Bool laden Fertigmeldung Presse Robot_done_unload Bool entladen Fertigmeldung Roboter hat Robot_done_dbelt Bool Band beladen Definition neuer Daten mit dem SFS Editor Sensoren des Roboters Technische SPS Variable Datentyp Kommentar Bezeichnung Wegmesssystem Ro Arml_ext Integer 0 00 Arm hinten boterarm 1 0 37 Arm an Presse 0 52 Arm am Hubdrehtisch 0 65 Arm in Presse 1 00 Arm vorn Wegmesssystem Ro Arm2_ext Integer 0 00 Arm hinten boterarm 2 0 57 Arm am Ablageband 0 79 Arm in Presse 1 00 Arm vorn Drehgeber Roboter Robot_angle Integer 95 Minimum 90 Arm 1 vor Presse 70 Arm 2 ber Abl band 204 Anhang 0 Arm 2 an Presse 50 Arm 1 an Hubdrehtisch 65 Maximum Tabelle 34 Datenebene 4 Sensoren des Roboters 84 INT VAR Arml_ext der Roboterarm 1 0 0_I hinten 0 37_I an der Presse 0 52_I am Hubdrehtisch 0 65_I in der Presse T0 Ee vorn 685 INT VAR Arm2_ext der Roboterarm 2 0 0_I hinten 0 57_I am Ablageband 0 79_I in der Presse E re orn 6686
196. gspro zesse sowie die Koordinierung der daf r notwendigen Ger te Die technische Aus stattung dieser Ebene besteht in Prozessdatenverarbeitungsger ten SPS Roboter steuerungen NC CNC sowie RC und weiteren Ger ten zur Betriebsdatenerfassung Funktionen wie Steuern und Regeln die Gew hrleistung der Sicherheit und St rungs berwachung das An und Abfahren oder die Rezeptursteuerung sind hier an gesiedelt Die Produktionsleitebene dient zum F hren der Fabrik Produktionsvorgaben werden hier bernommen und detailliert Es werden Kapazit ten geplant und Auftr ge abge wickelt weitere Funktionen sind die Bestandsdisposition Lagerverwaltung Qualit ts kontrolle Logistik und Optimierung Die Unternehmensleitebene betrifft vor allem betriebswirtschaftliche Bereiche also die F hrung des gesamten Unternehmens Sie ist die zielsetzende langfristig pla nende Ebene sie beurteilt den Abnehmermarkt steuert den Einkauf und erstellt Pro duktionsvorgaben Ein allgemeing ltiges formales Beschreibungsmittel muss die Darstellung von Anfor derungen in allen betrieblichen Ebenen erm glichen Dies betrifft inhaltlich haupt s chlich die Beschreibung eines geforderten Ablaufes muss aber auch verschiedene zeitliche Horizonte wie dispositive Anforderungen in den oberen Hierarchieebenen ber cksichtigen 2 3 2 Ber cksichtigung der Arbeitsweise einer Steuerung An dieser Stelle erfolgt eine kurze Einf hrung zur Arbeitsweise einer speicher
197. h den Zeitparameter gegliedert Zuerst werden die Kategorien mit dem Zeitparameter Zustand dargestellt danach wird die Umsetzung der beiden Kategorien mit dem Zeitparameter Di rekt gezeigt im Gegensatz zum Zeitparameter Direkt wird die Erf llung der Folgerung bei Kategorien mit dem Zeitparameter Unbegrenzt nicht im n chsten SPS Zyk lus sondern lediglich irgendwann danach gefordert bei Kategorien mit dem Zeitparameter Fremdbegrenzt wird der Zeitraum f r die Erf llung der Folgerung jedoch wieder durch eine zweite unabh ngige Bedingungen eingegrenzt bei Kategorien mit dem Zeitparameter Selbstbegrenzt ist das Ende des Beo bachtungsintervalls nicht durch eine zweite Bedingung sondern durch die Nichterf llung der urspr nglichen Bedingung gegeben 56 Die Sicherheitsfachsprache Es folgt nun die formale Beschreibung der Menge der syntaktisch korrekten CTL Formeln und deren Bedeutung Die Darstellung orientiert sich an der eingef hrten Terminologie f r Registernetze Hein01 die als Basis des Systemmodells dienen Zeitparameter Zustand Kategorie DEs1 einfache Forderung Zustand Analyseinhalt In jedem Zustand in dem rdy_plc und eine Bedingung B erf llt ist muss gleichzeitig auch eine Folgerung F erf llt sein AG rdy_plc a B gt F Kategorie PRs1 einfaches Verbot Zustand Analyseinhalt In jedem Zustand in dem rdy_plc und eine Bedingung B erf llt ist darf eine
198. h eine Folgerung F erf llt sein Es besteht die Forderung dass das Steuerungsprogramm auf ein beim Einlesen der Sensorwerte erkanntes Ereignis unmittelbar reagiert Diese Forderung ist erf llt wenn die Reaktion nach der unmittelbar folgenden Abarbeitung des SPS Programms eingetreten ist d h sobald die Beobachtungsvariable rdy_plc erstmals von FALSE auf TRUE gewechselt hat AG rdy_in a B gt A rdy_plc U rdy_plcA F Die CTL Formel enth lt den Until Operator U durch die Verbindung mit rdy_plc und rdy_plc wird die steigende Signalflanke der Beobachtungsvariablen erkannt Die Formel kann folgenderma en interpretiert werden Wenn nach dem Einlesen der Sensorwerte eine Bedingung B erf llt ist muss die darauf folgende Phase der Bear beitung des SPS Programm immer die zugeh rige Reaktion F liefern Kategorie DEe2 erweiterte Forderung Direkt Analyseinhalt Nach jedem Zustand in dem rdy_in und eine Bedingung B erf llt ist muss im n chsten Zustand in dem rdy_plc erf llt ist auch eine Folgerung F erf llt sein In Erweiterung zur Kategorie DEs2 gilt innerhalb dieser Anforderungskategorie dass unmittelbar nach denjenigen Zust nden in denen zwar rdy_in jedoch nicht die bezeichnete Bedingung B erf llt ist die genannte Folgerung auch nicht erf llt sein darf AG rdy_in a B gt A rdy_plcU rdy_plc A A rdy_in a B A rdy_plc U rdy_plc a F Zeitparameter Unbegrenzt Kategorie DEs5 einfa
199. h sie ergibt sich der ei gentliche Inhalt einer Anforderung Die Formulierung erfolgt durch Verben und Sub stantive die den Satz vervollst ndigen Die verwendeten Substantive werden nach folgend als Nomen bezeichnet Die verwendeten Verben repr sentieren die Werte die der hinter einem Nomen stehende Sensor oder Aktor annehmen kann Dabei bezeichnen Vollverben eine Handlung ein Geschehen oder einen Zustand Flie86 Hinzu kommen Hilfsverben wie haben sein werden Ausf hrliche Information zur Erstellung der Nomen und Werte k nnen dem Abschnitt 4 4 entnommen werden Das Grundmuster einer Anforderung die mit der Sicherheitsfachsprache formuliert wird ist das Konditional ein zusammengesetzter Satz Dieser besteht aus zwei Tei 42 Die Sicherheitsfachsprache len die durch ein Komma voneinander getrennt sind In einem Teilsatz wird eine Be dingung oder ein bestimmtes Ereignis formuliert wird erkennbar am Schl sselwort Wenn Dieser Satzteil wird im Folgenden als Bedingung B bezeichnet Im ande ren Teilsatz wird eine zugeh rige Reaktion formuliert erkennbar am Schl sselwort dann Dieser Teilsatz wird als Folgerung F bezeichnet Die Reihenfolge von Be dingung und Folgerung innerhalb des Satzes wird zun chst nicht festgelegt Eine Anforderung A setzt sich aus einer Bedingung B und einer Folgerung F zusammen Zwischen einer Bedingung und einer Folgerung besteht ein implikativer Zu sammenhang
200. haltbilder und Baupl ne Die Syntaxen von Spezifikationstechniken sind teilweise standardisiert z B Protokollspezifikationen LOTOS Estelle SDL ASN 1 oder auch nichtstandardisiert Petri Netze Unter Programmsynthese versteht man das automatische Erstellen eines Pro gramms das ein vorgegebenes Problem l sen soll Grundlage der Synthese ist eine formale Problem bzw Programmspezifikation au erdem muss bekannt sein in wel cher Zielsprache das Programm erstellt werden soll Ein Programmtest beinhaltet die berpr fung der Einhaltung der Programmspezifi kation durch ein probeweises Ausf hren des Programms Dazu werden Testf lle be stimmt die erwarteten Ergebnisse werden mit den Reaktionen des Programms ver glichen Je nach Kenntnis von der realen Implementierung des Programms unter scheidet man den black box Test und den white box Test Programmtests sind im mer partiell und zeigen nur das Vorhandensein von Fehlern nicht aber deren Abwe senheit Verifikation bedeutet dass die Soll Eigenschaften eines Programms durch einen exakten Beweis nachgewiesen werden Die F hrung des Beweises erfolgt durch lo 115 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache gische Schl sse auf der Grundlage von Axiomen und bereits bewiesenen Aussagen Hierf r ist eine Formalisierung der Soll Eigenschaften notwendig Die Verifikation stellt die Korrektheit von Programmen gegen ber ihrer Spezifikation sicher VDI V
201. he Fertigung 95 2000 zwf 10 2000 Bits00 Bitsch F Gunzert M Formale Verifikation von Softwarespezifi kationen in ASCET SD und MATLAB Fachtagung Verteilte Automatisierung 22 23 M rz 2000 Magdeburg 102 Bits02 Blac87 Booc99 Braa01 Cane00 Canv97 Cauv91 Char92 Chou98a Chou98b Clar86 Clar96 Literatur Bitsch F G hner P Spezifikation von Sicherheitsanforderun gen mit Safety Patterns Tagungsband Software Engineering in der industriellen Praxis VDI Bericht Nr 1666 VDI Verlag D sseldorf S 29 40 2002 Black W J Acquisition of conceptual data models from natural language descriptions in Proc of 3 Conference of the euro pean Chapter of computational linguistics Copenhagen Denmark 1987 Booch G et al Das UML Benutzerhandbuch Addison Wesley Bonn 1999 Braatz A GroBe Rhode M Ehrig H Westkamper E UML basierte Software Spezifikation und Entwicklungswerkzeuge fur Systeme der Automatisierungstechnik Tagungsband EKA 2001 7 Fachtagung Engineering komplexer Automatisierungssysteme 25 27 April 2001 Braunschweig Canet G Couffin S Lesage J J Petit A Schnoebelen Ph Towards the automatic verification of PLC programs written in Instruction List IEEE International Conference of Systems Man and Cybernetics SMC 2000 pp 2449 2454 Nashville Tennes see USA 2000 Canver
202. he r ck bersetzt werden sofern sie die Syntax der SFS benutzen Mit dieser Festlegung und den CTL Formeln als formale Basis lassen sich bersetzer zwischen verschiedenen Sprachen konstruieren die eine in Deutsch formulierte Anforderung zun chst in eine CTL Formel bersetzen und dann in einen nat rlichsprachlichen englischen Satz berf hren Abschlie end ist der m gliche Ausbau des SFS Editors zu nennen Hierbei lassen sich vor allem durch eine geeignete hierarchische Strukturierung der Anforderungen z B gem der in der Fallstudie gezeigten Zerlegung eines Produktionsauftrages die notwendige Gliederung und bersichtlichkeit verbessern Die vorliegende Arbeit hat gezeigt dass eine nat rlichsprachliche und gleichzeitig formale Anforderungsformulierung m glich ist Denn nur durch eine konsequente Vereinfachung der Methoden und Werkzeuge f r die Softwareerstellung wird es zu 100 Zusammenfassung und Ausblick k nftig m glich sein die notwendige Sicherheit der uns umgebenden technischen Systeme zu gew hrleisten 101 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache 7 Literatur Ahre00 Ahrens W Felleisen M Schnieder E Chouikha M Formale Prozessbeschreibungen gestern heute und morgen Automati sierungstechnische Praxis 42 2000 atp 9 2000 Agui90 Aguilera C Berry D M The Use of Repeated Phrase Finder in Requirement Extraction Journal of Systems and So
203. hen Table_run_lift Bool Startsignal Table_run_lower Bool Ssenken Drehen Meldung Hubdrehtisch ist Table_rdy_give Bool zur bergabe bereit Definition neuer Daten mit dem SFS Editor Sensoren des Hubdrehtischs Technische Bezeichnung SPS Variable Datentyp Kommentar Schalter untere Tischposition Table_bottom Bool TRUE Tisch unten Schalter obere Tischposition Table_top Bool TRUE Tisch oben Drehgeber Hubdrehtisch Table_angle Integer 0 Tisch vor Band 50 Tisch vor Ro boter 85 Maximum Tabelle 31 Datenebene 4 Sensoren des Hubdrehtischs 75 BOOL VAR Table_bottom TRUE_I unten FALSE_I nicht unten 6676 BOOL VAR Table_top TRUE_I oben FALSE_I nicht oben 77 INT VAR Table_angle DU TI vor dem Roboter der Hubdrehtisch der Hubdrehtisch der Hubdrehtisch 197 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache 0_I vor dem Zuf hrband Aktoren des Hubdrehtischs Technische SPS Variable Datentyp Kommentar Bezeichnung Motor Tischdrehung Table_left Bool TRUE Tisch dreht nach L R links Table_right Bool TRUE Tisch dreht nach rechts Motor Tischh he L R Table_upward Bool TRUE Tisch hebt sich Table_downward Bool TRUE Tisch senkt sich Tabelle 32 Datenebene 4 Aktoren des Hubdrehtischs 6678 BOOL VAR Table_left die
204. hlage bei der das Risiko kleiner als das Grenz risiko ist Das Grenzrisiko ist dabei das gr te noch vertretbare anlagenspezifische Risiko eines bestimmten technischen Vorgangs oder Zustands F r die daraus folgende Notwendigkeit der Definition des Grenzrisikos f hrt die DIN 31004 aus Es wird in der Regel durch sicherheitstechnische Festlegungen abgegrenzt die den Schutzzielen des Gesetzgebers folgend nach der unter Sachverst ndigen vorherr schenden Auffassung getroffen werden Es gibt also keine absolute Ma angabe f r das Risiko Um eine gewisse Quantifizierung des Risikos zu erm glichen haben sich verschiedene Ans tze herausgepr gt die das Risiko in Klassen oder Levels eintei len So legt die DIN 19250 acht Anforderungsklassen fest wobei h here Anforde rungsklassen eine h here Zuverl ssigkeit der eingesetzten Systemkomponenten verlangen Die Zuverl ssigkeit VDI VDE 2180 engl reliability eines Systems ist deren F higkeit eine vorgegebene Funktion innerhalb vorgegebener Grenzen und f r eine bestimmte Zeit zu erf llen Die Verf gbarkeit engl availability ist eine Ma zahl f r die Zuverl ssigkeit die kennzeichnet die Wahrscheinlichkeit dass ein betrachtetes System zu einem bestimmten Zeitpunkt funktionsf hig ist Weiterf hrende zusammenh ngende Darstellungen und Erl uterungen der genann ten Begriffe k nnen Rust94 Litz98 Gl e98 und DGQ98 entnommen werden 116 Anhang A 2
205. i cherweise in einem Pflichtenheft abgelegt das durch Kooperation von Auftraggeber und Steuerungstechniker erstellt wird Ein Pflichtenheft also die Spezifikation ent h lt die notwendige Funktionalit t des Programms die erforderlichen Reaktionen auf festgelegte Ausnahmesituationen aber auch Festlegungen welches Programmver halten unbedingt vermieden werden muss Konventionell also per Hand erstellte Programme weisen jedoch h ufig nicht nur die gew nschten und erforderlichen Eigenschaften auf Die eingangs genannten Katastrophen und die pers nliche Erfahrung jedes Einzelnen zeigen dass sich Soft ware mitunter anders verh lt als es eigentlich gefordert und erwartet wird Dieses 5 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Fehlverhalten wie es dann immer genannt wird beruht unter anderem darauf dass die erzeugte Software auch zus tzliche versteckte Eigenschaften hat Diese wur den nicht spezifiziert und vom Programmierer auch nicht direkt implementiert sie sind dennoch vorhanden Viele dieser Eigenschaften k nnen harmlos sein es gibt mit gro er Wahrscheinlichkeit jedoch auch solche die w hrend des Betriebes zu ris kanten und gef hrlichen Reaktionen des Programms f hren k nnen Ein weiterer typischer Fehler ist dass das gew nschte Verhalten nicht in allen Kombinationen sichergestellt wird dass es also Spezialf lle gibt in denen das Programm versagt Der Spezifikationspr
206. ichung eines bestimmten Levels erfolgt durch Frageb gen mit reinen Ja Nein Fragen in so genannten Assessments Bei der Bootstrap Methode einem Sonderfall des CMM erfolgt die Bewertung durch eine externe Be gutachtung statt durch Eigenbewertung Auf Initiative der ISO und der IEC wurde 1993 SPICE Software Process Improve ment and Capability Determination entwickelt Hier finden sich hnliche Reifegrad stufen wie bei CMM jedoch wird auch das Prozessumfeld bei der Beurteilung der Prozesse ber cksichtigt SPICE ermutigt die Anwender zur Selbstbewertung diese erfolgt in einer f nfstufigen Skala nicht mehr nur durch Ja Nein Fragen In Zukunft sollen Ans tze wie ISO 9000 und CMM in SPICE integriert werden Inwieweit solch komplexe Ma nahmen in eine betriebliche Struktur integriert werden k nnen letztendlich m ssen alle Mitarbeiter beteiligt sein h ngt nat rlich von indi viduellen Einfl ssen ab Jedoch lassen sich auch mit der Auswahl einzelner kleiner Komponenten bereits gute Ergebnisse bei der Fehlervermeidung erzielen In Mont00 werden drei grunds tzliche Schritte vorgestellt Pr vention Test Fehlerbe handlung Mit einer Vereinfachung der Arbeitsweise der Protokollierung alter Fehler durch die Durchf hrung von Inspektionen bzw Audits oder auch durch die Mehr fachentwicklung von Komponenten l sst sich die Qualit t von Programmen bereits rapide verbessern 1 4 1 2 Vorgehensmodelle Zur Reduzierung der Komplexit
207. ie Erstellung von Steuerungsprogrammen nicht mit der Komplexit t der eingesetzten Hardware bereinstimmen Dieser Umstand kann nur durch den konsequenten Einsatz formaler Methoden die auf den Anwendungsfall angepasst sind behoben werden Bereits in Wehr96 wird dieser Einsatz formaler Methoden f r den Entwurf verteilter reaktiver Systeme gefordert besonders in der IEC1508 wird eine Definition der Anforderungen mit Temporaler Logik vorgeschla gen Dieser Trend l sst sich in vielen Forschungsprojekten und den zugeh rigen Ver ffentlichungen nachweisen So gibt es bereits seit fast 20 Jahren Standard Spe zifikationssprachen f r einzelne Einsatzgebiete die Urspr nge hierf r sind im Be 16 Einleitung und Ausgangssituation reich der Kommunikationsdienste zu finden Der folgende Abschnitt soll einige der aktuellen Methoden und Werkzeuge und die dabei verwendeten Spezifikationstech niken darstellen Diese lassen sich in drei Kategorien zusammenfassen 1 Grafische Notationen 2 Mathematische Spezifikationen 3 Strukturierte nat rliche Sprache Estelle LOTOS Language of Temporal Ordering Specification ISO IEC 8807 und SDL Specification and Description Language sind ereignisbasierte Methoden die f r die Spezifikation verteilter Systeme und Kommunikationsprotokolle und dienste zum Einsatz kommen Hogr89 Frap01 Reck91 SDL erlaubt speziell die Model lierung eines reaktiven Systems als ein aus mehreren Komponenten a
208. ierung gef llt 2 2 Formale Anforderungen Ein zu entwickelndes formales Beschreibungsmittel das Anforderungen an ein Steu erungssystem mit Hilfe der nat rlichen Sprache beschreiben soll ist eine k nstliche Sprache K nstliche Sprachen besitzen ebenso wie nat rliche Sprachen eine Syntax Semantik und Grammatik Im Gegensatz zur nat rlichen Sprache ist ihre Semantik aber eindeutig Reck91 Es ist notwendig s mtliche Mehrdeutigkeiten und M glich keiten f r missverst ndliche Formulierungen zu eliminieren Aus diesem Grund wer den k nstliche Sprachen formal definiert als Sprachbeschreibungssprache dient eine Metasprache die Backus Naur Form BNF Die BNF ist ein Formalismus zur Beschreibung kontextfreier Grammatiken und ist somit auch zur Syntaxdefinition geeignet Grundlage bildet ein Alphabet dessen Be standteile als Terminalsymbole bezeichnet werden Aus diesen Terminalsymbolen lassen sich unter Verwendung von Produktionsregeln Nichtterminalsymbole Zei chenfolge von Terminal und Nichtterminalsymbolen ableiten Krau00 Der GMA Fachausschuss 7 21 Formale Prozessbeschreibungen hat in seinem Richtlinienentwurf Stand 2001 zur VDI VDE Richtlinie Mensch Prozess Kommuni kation unter besonderer Ber cksichtigung der formalen Prozessbeschreibungen den Begriff der formalen Prozessbeschreibung folgenderma en definiert Notwendig sind eine definierte Semiotik die Menge von Symbolen und Zeichen die die Spra che bes
209. ikation mit den Steuerungen der anderen Komponenten der Ger teebene 3 erfolgt analog und kann dem Anhang entnommen werden 88 Validierung des Prototypen anhand einer Fallstudie Kommunikation mit der Steuerung des Krans Der Kran hat innerhalb der Produktionszelle zwei Aufgaben Transport von Rohteilen vom Eingangspuffer zum Zuf hrband Transport von Fertigteilen vom Ablageband zum Ausgangspuffer Diese Aufgaben k nnen nur alternativ bearbeitet werden da der Kran immer nur ein Teil transportieren kann Nachfolgend wird nur der Transport der Rohteile betrachtet Gegebene Daten bereits definiertes Not Aus Signal f r die Steuerung des Krans Sensorwert f r die Belegung des Eingangspuffers Informelle Spezifikation Die Steuerung der Produktionszelle muss an die Steuerung des Krans das Signal geben wenn dieser ein Rohteil aus dem Eingangspuffer holen soll Dazu m ssen der Zellensteuerung die folgenden Informationen bekannt sein im Eingangspuffer liegt ein Rohteil das Rohteil kann auf dem Zuf hrband abgelegt werden W hrend die erste Information ein bereits bekanntes Sensorsignal ist ist die letztere Information noch unbekannt Definition neuer Daten mit dem SFS Editor Das Zuf hrband muss eine Meldung generieren dass es zur bernahme eines neuen Teils bereit ist Weiterhin wird ein Startsignal definiert das den Kran zum Transport eines Rohteils vom Eingangspuffer zum Zuf hrband veranlasst Fbelt_rdy_take Zuf hrb
210. il zum Bandende transportieren unmittelbar zur ckgesetzt werden und die Zustandsvariable des Zuf hrbands muss unmittelbar auf 1 gesetzt werden und der Antrieb des Zuf hrbands muss unmittelbar gestartet werden AG rdy_in amp Fbelt_state 0 amp Fbelt_run_transport gt Al rdy_plc U rdy_plc amp Fbelt_run_transport amp Fbelt_state 1 amp FBelt_start gt gt gt Satz 97 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Zuftihrbands 0 ist und das Startsignal Zuf hrband soll Teil auf Tisch befordern ist gesetzt dann muss das Startsignal Zuf hrband soll Teil auf Tisch bef rdern unmittelbar zur ckgesetzt werden und die Zustandsvariable des Zuf hrbands muss unmittelbar auf 2 gesetzt werden und der Antrieb des Zuf hrbands muss unmittelbar gestartet werden AG rdy_in amp Fbelt_state 0 amp Fbelt_run_table gt Al rdy_plc U rdy_plc amp Fbelt_run_table amp Fbelt_state 2 amp FBelt_start gt gt gt Satz 98 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Zufiihrbands 1 ist und die Lichtschranke am Ende des Zufiihrbands ist unterbrochen dann muss der Antrieb des Zufiihrbands unmittelbar gestoppt werden und die Zustandsvariable des Zufiihrbands muss unmittelbar auf 11 gesetzt werden und die Bereitschaftsmeldung Zuf hrband ist zur bergabe bereit muss unmittelbar gesetzt w
211. in dieser Arbeit ebenfalls nicht eingegangen Formale Spezifikation mit dem SFS Editor Auf die Details der formalen Spezifikation wird in dieser Arbeit nicht eingegangen Der Leser m ge sich jedoch vorstellen dass die Vorgehensweise analog zu der Spezifikation der Produktionszelle 1 ist 179 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache A 7 4 Ger teebene 3 Steuerung des Krans Aufgabe Die Steuerung des Krans erh lt von der bergeordneten Zellensteuerung Startsig nale zur Ausf hrung bestimmter Aktionen Durch verschiedene Sensoren und Akto ren ist die Kransteuerung mit den Maschinenelementen verbunden Gegebene Daten Technische Bezeichnung Variable Datentyp Kommentar Startsignal Rohteil Crane_run_source Bool holen Fertigmeldung Kran Crane_done_give_fbelt Bool Kran hat Rohteil auf Zuf hrband abgelegt Startsignal Fertigtel Crane_run_dbelt Bool holen Fertigmeldung Kran Crane_done_take_dbelt Bool hat Teil vom Ablage band genommen Definition neuer Daten mit dem SFS Editor Sensoren des Krans Technische SPS Variable Datentyp Kommentar Bezeichnung Schalter Kranposition Crane_at_fbelt Bool TRUE Kran ist am Zu Zuf hrband f hrband Schalter Kranposition Crane_at_dbelt Bool TRUE Kran ist am Ab Ablageband lageband Schalter Kranposition Crane_at_source Bool TRUE Kran ist am Ein
212. indkessel el gr er als 6 1 bar Anfangsbedingung lt N gt lt w gt ist fa Nomen der Druck im Windkessel E Wert gr er als 6 1 bar kd OK Hilfe Abbrechen laln if Hilfe Hoch Runter OK Neu Bearbeiten L schen Abbildung 22 Erstellung der Bedingungen An dieser Stelle k nnen auch immer mehrere Bedingungen und Folgerungen verein bart werden diese sind in der Anforderung dann jeweils konjunktiv miteinander ver kn pft In einem letzten Schritt werden die erstellten S tze in eine Textdatei ausgegeben und stehen nun f r die Kompilierung in eine CTL Formel zur Verf gung 4 3 berf hrung der Programmanforderungen in CTL Formeln Die nat rlichsprachlichen Programmanforderungen die im so genannten Ausgangs text abgelegt sind werden durch eine Compilersequenz in CTL Formeln berf hrt Dieser Umwandlungsvorgang besteht aus zwei Stufen 1 Im urspr nglichen Text ersetzt ein PreLexer die applikationsspezifischen Wortphrasen durch die in der Nomendeklarationsdatei hinterlegten SPS Vari ablen und deren Werte Der dadurch entstandene Zwischen Meta text ent h lt dann nur noch sprachinterne applikationsunabh ngige Schl sselw rter sowie formale Ausdr cke des SPS Programms 2 Im eigentlichen Umwandlungsvorgang wird der Zwischentext hinsichtlich der Bedeutung analysiert und in CTL Formeln umgewandelt 4 3 1 PreLexer Der PreLexer ist das erste Modul innerhalb der Compilersequenz Als A
213. indner Th Eds Formal Development of Reac tive Systems Case study Production Cell Springer Verlag Berlin Heidelberg New York 1995 Lewerentz C Rust H Zur Bedeutung von Spezifikationen in verschiedenen Teilaufgaben der Entwicklung kundenspezifischer Software Informatik Berichte 1 21 1997 Brandenburgische Tech nische Universit t Cottbus 1997 Lindermeier R Softwarequalit t und Softwarepr fung Olden bourg Verlag GmbH M nchen 1993 Litz L Grundlagen der sicherheitsgerichteten Automatisierungs technik Automatisierungstechnik 46 1998 at 2 98 Litz L Frey G Methoden und Werkzeuge zum industriellen Steuerungsentwurf Historie Stand Ausblick Automatisie rungstechnik 47 1999 at 4 99 Manna Z Pnueli A The temporal logic of reactive and concur rent systems specification Springer Verlag New York 1992 Manna Z Pnueli A Temporal Verification of Reactive Systems Safety Springer Verlag New York 1995 McMillan K L The SMV System Techn Report Carnegie Mel lon Univ 1992 Meffert K Reinert D Sicherheitsreport Mikroprozessoren in sicherheitskritischen Anwendungen Teile 1 und 2 Elektronik 4 6 99 Meier H Mertke T Verifikation zertifizierungspflichtiger Steue rungssoftware Zeitschrift f r wirtschaftlichen Fabrikbetrieb ZwF 6 98 S 247 250 1998 Meier H Mertke T Eine Sicherheitsfachs
214. ine For mulierung der Anforderungen in Frage kommenden Variablen sind bereits definiert und m ssen dementsprechend verwendet werden Dagegen sind bei einer Spezifi kation f r eine nachfolgende Programmsynthese lediglich die verf gbaren Sensor und Aktor Variablen bekannt weitere programminterne Variablen wie Zustands oder Hilfsvariablen sind noch nicht bekannt und m ssen definiert werden Realisierungsunabh ngige Anforderungen sind somit umfassender einsetzbar reali sierungsabh ngige Anforderungen sind dagegen nur auf bereits existierende Steue rungsprogramme anwendbar 4 6 Systematische Erstellung von Sicherheitseigenschaften Als ein besonderes Problem bei der Erstellung von allgemeing ltigen realisie rungsunabh ngigen Anforderungen an ein Steuerungsprogramm erweist sich die Zusammenstellung von Situationen Zust nden bzw Programmreaktionen die nie mals erreicht bzw ausgef hrt werden d rfen weil sie eine Gef hrdung des beteilig ten Personals der Umwelt der Anlage oder des eingesetzten Materials darstellen Der Steuerungstechniker sieht sich hierbei auch in Kooperation mit verschiedenen anderen Projektbeteiligten meist nicht in der Lage alle denkbaren Gef hrdungssi tuationen zu erkennen zu beurteilen und zu verhindern Solche Gef hrdungssitua tionen werden oft erst bei bzw nach einem Ungl ck erkannt die notwendigen steue rungstechnischen Gegenma nahmen k nnen erst anschlie end in das Programm integrier
215. iner Menge aufeinander folgender Zust nde Die L nge eines Beo bachtungsintervalls d h die Anzahl der aufeinander folgenden relevanten Zust nde wird durch den Zeitparameter festgelegt Ein Beobachtungsintervall BI beginnt mit einem Startzustand S und endet mit einem Endzustand E Typische automatisierungstechnische Anforderungen an ein Steuerungsprogramm beziehen sich auf zwei Zeitebenen tritt auf eine Bedingung die zugeh rige Reaktion innerhalb einer vorgegebenen m glichst kurzen Zeitspanne ein kurzfristige opera tive Anforderungen bzw tritt auf eine Bedingung die zugeh rige Reaktion berhaupt ein langfristige strategische Anforderungen Ausgehend von dieser Tatsache lassen sich zwei Hauptgruppen mit insgesamt f nf Varianten von Beobachtungsintervallen differenzieren Die beiden ersten Varianten 45 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache beziehen sich auf die typische Arbeitsweise einer speicherprogrammierbaren Steue rung Der Zeitpunkt des Endzustandes und somit auch die Lange des Beobach tungsintervalls ist an den SPS Zyklus gekoppelt Zustand das Beobachtungsintervall ist auf alle Zustande begrenzt die im sel ben SPS Zyklus liegen Direkt das Beobachtungsintervall ist auf alle Zustande beschrankt die im sel ben und im direkt nachfolgenden SPS Zyklus liegen Die Lange der folgenden drei Varianten der Beobachtungsintervalle ist im Gegensatz zu den beiden vorh
216. ines Teils bereit ist Bandende muss belegt sein Au erdem ist ein Startsignal f r diese bergabe zu generieren Definition neuer Daten mit dem SFS Editor Technische Variable Datentyp Kommentar Bezeichnung Bereitschaftsmeldung Fbelt_ready_transport Bool Zuf hrband ist Zuf hrband bereit zum zum Transport Transport bereit Startsignal Rohteil zum Fbelt_run_transport Bool Zuf hrband soll 158 Anhang Bandende transportie Teil zum Ban ren dende transpor tieren Bereitschaftsmeldung Fbelt_ready_give Bool Zuf hrband ist Zuf hrband bereit zur zur bergabe bergabe bereit Fertigmeldung Tisch Table_ready_take Bool Tisch ist zu Ent bereit zur bernahme gegennahme eines Teils bereit Startsignal Rohteil zum Fbelt_run_table Bool Zuf hrband soll Hubdrehtisch transpor Teil auf Tisch tieren transportieren bergabemeldung des Fbelt_done_give Bool Zuf hrband hat Zuf hrbands Teil auf Tisch transportiert Tabelle 19 Datenebene 3 Variablen zur Kommunikation mit dem Zuf hrband 34 BOOL VAR_GLOBAL Fbelt_ready_transport die Bereitschaftsmeldung Zuf hrband ist zum Transport bereit TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 35 BOOL VAR_GLOBAL Fbelt_run_transport das Startsignal Zuftihrband soll Teil
217. ion 1 contains basic statements concerning the correctness and safety of soft ware and shows ways and means how to increase the quality of software In section 2 typical requirements for a formal description tool are summarized which should fulfil the conditions of a use in modern control technology In section 3 the Safety oriented Technical Language is derived from these require ments For thus the technical requirements will be classified the parameters of the SFS are derived and explained The transfer of requirements into the formal base of the SFS temporal logic is additionally represented in this section In section 4 a representation of the technical realisation of the SFS its use is given It is explained how the concrete control technical objects sensors actuators are V F Snezifikati ktiver diner Si itst included into the SFS how the requirements can be explained and transferred into formulas In addition a method will be explained how to arrange a complete set of requirements Section 5 contains a case study to demonstrate the extensive possibilities of the SFS using a real example Because of the high complexity of this case study only selected problems are presented Further details can be taken from the appendix Finally section 6 summarises the most important results Some statements about further possibilities for development and use cases of the SFS are closing this work Formale Spezifikation reakti
218. ion_links html Links zum Thema Formale Methoden www comlab ox ac uk archive formal methods html Formale Methoden Tools www comp mpce mq edu au didar seweb tools html Requirement engineering Tools and techniques www cs toronto edu chechik courses00 csc2108 www science unitn it masini FORMAL local formal html Links zum Thema Model Checking Tools www cc ioc ee juhan fmmf modchk links html www fi muni cz paradise acp_tools acsedit cgi cs iso 8859 2 Verifikationswerkzeuge www cs indiana edu formal methods education tools Formale Methoden Tools 112 Anhang Anhang A 1 Begriffsbestimmungen Bei der berf hrung formaler Methoden in die praktische Anwendung ergeben sich h ufig Verst ndigungsschwierigkeiten weil bestimmte Begriffe aus dem Kontext der Informatik oder der Automatisierungstechnik heraus unterschiedlich verwendet wer den Deshalb sollen an dieser Stelle einige relevante Begriffe und deren Verwendung innerhalb dieser Arbeit erl utert werden Zun chst sollen einige Begriffe der Systemtheorie dargestellt werden Dieser Bereich ist erwiesenerma en sehr vielschichtig die verwendeten Begriffe sind oftmals durch die Betrachtungsweise der jeweiligen Wissenschaftsrichtung gepr gt Die folgende Ausf hrung orientiert sich am Bereich der Steuerungs Regelungs und Leittechnik DIN 19226 1994 Ein System engl system ist eine in einem betrachteten Zusammenhang gegebene Anordnung von Komponen
219. ionsanforderungen besteht darin dass bestimmte Ereignisse und Zusammenh nge eine eindeutige Reaktion innerhalb einer fest definierten und hin reichend minimalen Reaktionszeit verlangen z B Notabschaltungen Das Pflichtenheft beinhaltet au er den notwendigen Abl ufen des Programms aber auch Festlegungen welche Programmreaktionen unbedingt vermieden werden m s sen Diese Sicherheitsanforderungen lassen sich jedoch meist nicht so einfach wie die bereits erw hnten Funktionseigenschaften beschreiben Es ist oft problematisch 35 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache die kritischen Situationen eines Steuerungssystems vollstandig zu identifizieren bzw die komplexen Einflussfaktoren und Wechselwirkungen der Systeme untereinander zu erkennen Das maBgebliche Problem besteht jedoch darin dass es keine ingenieurtechnische Darstellungsform f r die Darstellung auszuschlieBender Reaktionen eines Steue rungssystems gibt 2 4 2 Kategorisierung aufgrund des Analyseverfahrens Bei einer Verifikation durch Model Checking werden die Anforderungen an ein Sys tem an einem Modell des Systems berpr ft Die Untersuchung erfolgt am Erreich barkeitsgrafen einer Reprasentation aller erreichbaren Zustande des Systems Durch diese Vorgehensweise ergeben sich verschiedene Klassen analysierbarer Ei genschaften Man kann zun chst eine Unterteilung bez glich der zu untersuchenden Systemzust nde vornehmen die im F
220. isch ist zur bergabe eines Teils bereit ist gesetzt und die Bereitschaftsmeldung Presse ist f r Beladung bereit ist gesetzt dann muss die Bereitschaftsmeldung Hubdrehtisch ist zur bergabe eines Teils bereit unmittelbar zur ckgesetzt werden und die Bereitschaftsmeldung Presse ist f r Beladung bereit muss unmittelbar zur ckgesetzt werden und das Startsignal Roboter bel dt Presse muss unmittelbar gesetzt werden AG rdy_in amp cell_l_state 1 amp Table_rdy_give amp Press_rdy_take gt Al rdy_plc U rdy_plc amp Table_rdy_give amp Press_rdy_take amp Robot_run_load gt gt gt Satz 42 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Automatikbetrieb ist und die Bereitschaftsmeldung Presse ist zur Ubergabe eines Teils bereit ist gesetzt und die Bereitschaftsmeldung Ablageband ist zur bernahme eines Teils bereit ist gesetzt und die Bereitschaftsmeldung Hubdrehtisch ist zur bergabe eines Teils bereit ist nicht gesetzt dann muss die Bereitschaftsmeldung Presse ist zur bergabe eines Teils bereit unmittelbar zur ckgesetzt werden und die Bereitschaftsmeldung Ablageband ist zur bernahme eines Teils bereit muss unmittelbar zur ckgesetzt werden und das Startsignal Roboter entl dt Presse muss unmittelbar gesetzt werden AG rdy_in amp cell_l_state 1 amp Press_rdy_give amp Dbelt_rdy_take amp Table_rdy_give
221. isch korrekten vollst ndigen nat rlich sprachlichen Anforderungen Zwischentext Metatext dieser enth lt den bereits syntaktisch analysierten und berf hrten Metatext Formeltext dieser enth lt die in CTL Formeln dargestellten Programmanforderun gen Prinzipiell k nnen diese Dateien vielleicht abgesehen vom Formeltext separat per Hand erstellt werden und einzeln und unabh ngig in die berf hrungssequenz ein gespeist werden Wegen der Komplexit t und Fehleranf lligkeit dieses Vorgangs bietet sich jedoch die Verwendung des nutzerfreundlichen SFS Editors an Die folgenden Abschnitte beschreiben in kurzer Form die einzelnen Softwaremodule im Umfeld der Sicherheitsfachsprache und erl utern dar ber hinaus die Vorgehens weise bei der Erstellung von Anforderungen mit der SFS Dabei werden zun chst die Erstellung der verbalen Anforderungen beschrieben bevor auf die berf hrenden Module d h den PreLexer und den Compiler eingegangen wird Dabei wird auch dargestellt in welcher Form die Schnittstellen zwischen den einzelnen Modulen be schaffen sein m ssen 4 2 Erstellung von Programmanforderungen mit dem SFS Editor Mit Hilfe des syntaxgesteuerten Editors f r die Sicherheitsfachsprache ist es auf einfache Weise m glich SFS konforme Anforderungss tze zu erstellen Nat rlich k nnen diese Anforderungss tze prinzipiell vom Anwender auch per Hand mit einem Texteditor erzeugt und anschlie end kompiliert werden jedo
222. ischh he 0 ist und die Zustandsvariable der Hubtischdrehung ist 0 und das Startsignal Hubdrehtisch heben und links drehen ist gesetzt dann muss das Startsignal Hubdrehtisch heben und links drehen unmittelbar zur ckgesetzt werden und die Zustandsvariable der Hubtischh he muss unmittelbar auf 1 gesetzt werden und die Zustandsvariable der Hubtischdrehung muss unmittelbar auf 1 gesetzt werden und das Anheben des Hubdrehtischs muss unmittelbar gestartet werden und die Linksdrehung des Hubdrehtischs muss unmittelbar gestartet werden AG rdy_in amp Table_state2 0 amp Table_statel 0 amp Table_run_lift gt Al rdy_plc U rdy_plc amp Table_run_lift 200 Anhang amp Table_state2 1 amp Table_statel 1 amp Table_upward amp Table_left gt gt gt Satz 106 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Hubtischh he 0 ist und die Zustandsvariable der Hubtischdrehung ist 0 und das Startsignal Hubdrehtisch senken und rechts drehen ist gesetzt dann muss das Startsignal Hubdrehtisch senken und rechts drehen unmittelbar zur ckgesetzt werden und die Zustandsvariable der Hubtischh he muss unmittelbar auf 2 gesetzt werden und die Zustandsvariable der Hubtischdrehung muss unmittelbar auf 2 gesetzt werden und das Absenken des Hubdrehtischs muss unmittelbar gestartet werden und die Rechtsdrehung des Hubdrehtischs muss unmitt
223. it einer Sicherheitsfachsprache Gl e98 Gl e G Jack O Mehl R M llerburg M Zuverl ssigkeit kom plexer Systeme aus Hardware und Software Automatisierungs technische Praxis 40 1998 atp 1 98 Gold94 Goldin L Berry D M AbstFinder A Prototype Natural Lan guage Text Abstraction Finder for Use in requirements Elicitation proc 1 International Conference on Requirement Engineering Colorado Springs USA 1994 Grel93 Grell D H mbs W Safety First Sicherheitstechnik im Compu terzeitalter c t 4 93 HabI98 Hablawetz D Applikationssoftware und Systemsicherheit in speicherprogrammierbaren Systemen Automatisierungstechnik 46 1998 at 2 98 Hala98 Halang W A Konakovsky R Sicherheitsgerichtete Software Automatisierungstechnik 46 1998 at 2 98 Hani96 Hanisch H M Lider A Rausch M Automatische Codegene rierung f r sicherheitsrelevante Steuerungen auf der Basis von Netzmodellen 3 Fachtagung Anlagen Arbeits und Umweltsi cherheit K then 7 8 November 1996 Hani98 Hanisch H M Thieme J L der A Steuerungssynthese auf der Basis von Netz Condition Event Systemen GMA Kongress Ludwigsburg 18 19 06 1998 VDI Berichte Nr 1397 1998 Hein97a Heiner M Meier H Menzel T Mertke T Petri Netz basierte Methoden zur sicherheitstechnischen Zertifizierung von SPS An wenderprogrammen BTU Bericht Reihe Informatik I 19 1
224. itat haben sich im Bereich der technischen Ma nahmen in den letzten Jahren zwei Hauptstr mungen herausgebildet Ein Ansatz besteht darin den Nachweis der geforderten Eigenschaften am bereits erstellten Steuerungsprogramm durch Tests oder besser durch Verifikation zu erbringen siehe Abbildung 4 Eine andere M glichkeit besteht darin direkt und automatisch aus einer gegebenen Spe zifikation ein Steuerungsprogramm zu generieren das exakt den gestellten Anforde rungen entspricht Pflichtenheft Maschine Spezifikation Anlage ungepr ftes SPS Programm formale formales Spezifikation Maschinenmodell Verifikation Synthese korrektes SPS Programm Abbildung 4 Vergleich von Synthese und Verifikation Heute sind mehr oder weniger leistungsf hige Werkzeuge zur Verifikation vorhan den zuk nftig liegen gr ere Potenziale aber in der direkten Synthese von Steue rungsprogrammen aus der gegebenen Aufgabenstellung Beiden Methoden Syn these Verifikation ist die Notwendigkeit einer korrekten vollst ndigen und wider spruchsfreien Darstellung der geforderten Programmeigenschaften gemeinsam Deshalb liegt ein entscheidender Ansatz zur Verbesserung der Softwarequalit t in der Anwendung formaler Methoden in der Darstellungs Design Spezifikations und Entwicklungsphase der Software Ziel der in dieser Arbeit vorgestellten Sicherheitsfachsprache ist es ein geeignetes Werkzeug f r beide Vorgeh
225. ittelbar deaktiviert werden und das Anheben des Krangreifers muss unmittelbar gestartet werden AG rdy_in amp Crane_state 14 amp Crane_height 0 94 gt Al rdy_plc U rdy_plc amp Crane_lower amp Crane_state 15 amp Crane_mag_on amp Crane_lift gt gt gt Satz 79 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 15 ist und der Greifer des Krans ist oben dann muss das Anheben des Krangreifers unmittelbar gestoppt werden und die Zustandsvariable des Krans muss unmittelbar 0 werden AG rdy_in amp Crane_state 15 amp Crane_height 0 gt Al rdy_plc U rdy_plc amp Crane_lift amp Crane_state 0 gt gt gt Satz 80 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 2 ist und der Kran ist am Ablageband dann muss die Bewegung des Krans nach rechts Ablageband unmittelbar gestoppt werden und die Zustandsvariable des Krans muss unmittelbar 21 werden und das Absenken des Krangreifers muss unmittelbar gestartet werden AG rdy_in amp Crane_state 2 amp Crane_at_dbelt gt Al rdy_plc U rdy_plc amp Crane_to_dbelt amp Crane_state 21 amp Crane_lower gt gt gt Satz 81 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 21 ist und der Greifer des Krans ist auf dem Ablageband dann muss das Absenken des Krangreifers unmi
226. le Teile sollen bear beitet werden Auftragsfortschritt order_status Integer Stand der Auftragsbearbei tung Tabelle 9 Datenebene 1 Datensatz Produktionsauftrag 1 INT VAR_GLOBAL order_number die laufende Nummer des Produktionssauftrages q1 T D LUNA 21 2 1o 1 20 2 2 INT VAR_GLOBAL order_work die Bearbeitungsart 1_I Pressen 2_I Bohren 3_I Fr sen 3 INT VAR_GLOBAL order_quantity Teileanzahl 7 7 7 m SI 5 7 0 Bis W 1 0 W 140 Anhang SU E e TO 4 INT MAR GLOBAL order_status der aktuelle Stand der Auftragsbearbeitung 1_I Neu 2_1 Rohteile liefern Set Bearbeiten AT Fertigteile wegbringen oi Fertig 1_0 auf Neu gesetzt 2 20 auf Rohteile holen gesetzt 3 20 auf Bearbeiten gesetzt A CO auf Fertigteile wegbringen gesetzt 520 auf Fertig gesetzt Formale Spezifikation mit dem SFS Editor Auftragsfortschritt gt gt gt Satz 1 lt lt lt einfache Forderung unbegrenzt Wenn irgendwann der aktuelle Stand der Auftragsbearbeitung Neu war dann muss der aktuelle Stand der Auftragsbearbeitung irgendwann auf Fertig gesetzt werden AG rdy_in amp order_status 1 gt AF rdy_plc amp order_status 5 Dar ber hinaus sind weitere Anforderungen formulierbar gt gt gt Satz 2 lt lt lt einfache Forderung
227. le des Roboters 41 ist und der Roboterarm 1 ist in der Presse dann muss das Ausfahren des Roboterarms 1 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 42 gesetzt werden und der Magnetgreifer des Roboterarms I muss unmittelbar deaktiviert werden und das Einziehen des Roboterarms 1 muss unmittelbar gestartet werden AG rdy_in amp Robot_state 41 amp Arml_ext 0 65 gt Al rdy_plc U rdy_plc amp Arml_forward amp Robot_state 42 amp Am mag on amp Arml_backward gt gt gt Satz 147 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 42 ist und der Roboterarm 1 ist hinten dann muss das Einziehen des Roboterarms 1 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 43 gesetzt werden und die Fertigmeldung Roboter hat Teil in Presse gelegt muss unmittelbar gesetzt werden AG rdy_in amp Robot_state 42 amp Arml_ext 0 0 gt Al rdy_plce U rdy_plc amp Arml_backward amp Robot_state 43 amp Robot_done_load gt gt gt Satz 148 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 43 ist dann die Zustandsvariable des Roboters muss unmittelbar auf 0 gesetzt werden 216 Anhang AG rdy_in amp Robot_state 43 gt Al rdy_plc U rdy_plc amp Robot_state 0 Informelle
228. leichzeitig F2 sein Wenn xl True ist und x2 ist True dann muss gleichzeitig yl True sein und muss gleichzeitig y2 True sein Wenn xl True ist und x2 True ist dann muss gleichzeitig y1 True sein und muss gleichzeitig y2 True sein Wenn xl True ist und x2 ist True dann muss yl gleichzeitig True sein und muss y2 gleichzeitig True sein Wenn xl True ist und x2 ist True dann muss yl gleichzeitig True sein und y2 muss gleichzeitig True sein Wenn B1 ist und B2 ist dann muss gleichzeitig F1 bleiben und muss gleichzeitig F2 bleiben Wenn xl True ist und x2 ist True dann muss gleichzeitig y1 True bleiben und muss gleichzeitig y2 True bleiben Wenn xl True ist und x2 True ist dann muss gleichzeitig yl True bleiben und muss gleichzeitig y2 True bleiben Wenn xl True ist und x2 ist True dann muss yl gleichzeitig True bleiben und muss y2 gleichzeitig True bleiben Wenn xl True ist und x2 ist True dann muss yl gleichzeitig True bleiben und y2 muss gleichzeitig True bleiben F1 muss gleichzeitig sein und F2 muss gleichzeitig sein wenn B1 ist und B2 i
229. lischen Besonderheiten ausgelegt der An wender kann die ihm passend erscheinende Wortfolge ausw hlen Bei der berf h 73 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache rung der Anforderungssatze in die temporallogischen Formeln werden diese Varia tionsm glichkeiten ebenfalls ber cksichtigt 4 5 Nutzung der Sicherheitsfachsprache f r Verifikation oder Synthese Neben der inhaltlichen Kategorisierung der Anforderungen durch den Modal und den Zeitparameter lassen sich die Anforderungen an ein Steuerungsprogramm auch hinsichtlich ihrer Erzeugbarkeit in Abh ngigkeit der Existenz eines realen Steue rungsprogramms einteilen So sind die beiden folgenden Kategorien unterscheidbar Realisierungsunabh ngige Anforderungen diese beziehen sich aus schlie lich auf die generell bekannten Variablen Sensoren Aktoren und sind somit unabh ngig von einem untersuchten SPS Programm anwendbar Realisierungsabh ngige Anforderungen diese beziehen sich neben den verwendeten Sensoren und Aktoren auch auf die internen Variablen des un tersuchten SPS Programms und sind somit auch nur auf dieses anwendbar Diese Einteilung wird besonders dann deutlich wenn man sich die unterschiedlichen Anforderungen bei der Spezifikation eines Steuerungsprogramms f r eine Verifika tion bzw f r eine Synthese des Steuerungsprogramms betrachtet Im ersten Fall existiert das zu untersuchende Steuerungsprogramm bereits d h alle f r e
230. load amp Press_run_work 1 gt gt gt Satz 53 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Automatikbetrieb ist und die Fertigmeldung Roboter hat Teil aus Presse genommen ist gesetzt dann muss die Fertigmeldung Roboter hat Teil aus Presse genommen unmittelbar zur ckgesetzt werden und das Startsignal Presse soll Beladung vorbereiten muss unmittelbar gesetzt werden AG rdy_in amp cell_l_state 1 amp Robot_done_unload gt Al rdy_plc U rdy_plc amp Robot_done_unload amp Press_run_prepare Informelle Spezifikation weiterer Eigenschaften Die Presse darf nicht gestartet werden wenn der Roboter kein Teil in die Presse gelegt hat Die Presse darf nicht vorbereitet werden wenn der Roboter das Teil nicht aus der Presse genommen hat Formale Spezifikation mit dem SFS Editor gt gt gt Satz 54 lt lt lt einfaches Verbot selbstbegrenzt das Startsignal Presse soll pressen darf nicht irgendwann gesetzt werden solange die Fertigmeldung Roboter hat Teil in Presse gelegt nicht gesetzt ist AG rdy_plc amp Robot_done_load amp Press_run_work gt gt gt Satz 55 lt lt lt einfaches Verbot selbstbegrenzt das Startsignal Presse soll Beladung vorbereiten darf niemals gesetzt werden solange die Fertigmeldung Roboter hat Teil aus Presse genommen nicht gesetzt ist 173
231. lte Automatisierung 22 23 Marz 2000 Magdeburg Varpaaniemi K Halme J Hiekkanen K Pyssyslao T PROD Reference Manual Helsinki Univ of Technology Digital Systems Laboratory Series B Techn Report no 13 Espoo 1995 VDI VDE 2180 Sicherung von Anlagen der Verfahrenstechnik mit Mitteln der Prozessleittechnik PLT Blatt 1 bis 5 1998 VDI VDE 3542 Sicherheitstechnische Begriffe fur Automatisie rungssysteme Blatt 1 bis 4 Oktober 2000 VDI Richtlinien VDI VDE 3694 Lastenheft Pflichtenheft f r den Einsatz von Automatisierungssystemen April 1991 Wehrheim H Specifying reactive Systems with action dependencies PhD thesis University of Hildesheim 1996 Westk mper E Braatz A Eine Methode zur objektorientierten Softwarespezifikation von zentralen Automatisierungssystemen mit der Unified Modeling Language UML Automatisierungstech nik 49 2001 at 5 2001 111 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Xu01 Xu L Bender K Wiederverwendungsorientierter Aufbau einer Modulbibliothek f r die Maschinensimulation Tagungsband EKA 2001 7 Fachtagung Engineering komplexer Automatisierungs systeme 25 27 April 2001 Braunschweig 2001 WWW Links zum Thema Pr fen und Testen von Software www informatik uni koeln de winfo prof mellis tav links_inhalt html Links zum Thema Verifikation www cs tu bs de ips huhn lehre verificat
232. lung die Fehlerklasse a beinhaltet nun die passiven Fehler Fehlerklasse b beinhaltet die aktiven Fehler Die Fehlerklasse b kann man unter Beachtung der Spezifikation noch weiter unter gliedern in b1 die unerwartete Ausf hrung von Aktionen obwohl diese bei der Spezi fikation bereits als unerw nscht oder sogar gef hrlich eingestuft wurde b2 die unerwartete Ausf hrung von Aktionen die zu dem Zeitpunkt ber haupt noch nicht ber cksichtigt und beurteilt wurden erw nschter Zustand unbewertete Zust nde Abbildung 3 Ursachen f r Softwarefehler Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Somit entstehen bei der Erstellung von Software verschiedene kritische Bereiche die in der Abbildung 3 schraffiert hervorgehoben wurden Ziel der anschlie enden Inbe triebnahmephase muss es dann sein diese unbeabsichtigt erzeugten Unzul nglich keiten zu erkennen und zu beseitigen Die berpr fung der Eigenschaften wird heute blicherweise durch verschiedene Tests durchgef hrt Diese Tests beinhalten haupt s chlich die Inspektion der geforderten Solleigenschaften des Programms die Kon trolle der Programmreaktionen auf zuvor festgelegte Fehlerszenarien sowie wenn auch nur stichprobenartig die Vermeidung gef hrlicher Situationen Ausgehend von diesen Anforderungen wurde die Sicherheitsfachsprache entwickelt die drei haupts chliche Zielstellungen verfolgt 1 Die eindeutige Kommunikation
233. m ssen durch die Kransteuerung weitere Si cherheitsanforderungen realisiert werden Hierbei k nnen die folgenden sicherheits kritischen Punkte identifiziert werden e S tze 86 87 Begrenzung der Kranbewegung an den Endpunkten e S tze 88 89 90 91 92 93 Begrenzung der Greiferbewegung an den Endpunkten unter Ber cksichtigung der Position des Krans H he der F rderb nder sowie des Eingangs bzw Ausgangspuffers e Satz 94 Der Greifer des Krans darf nur an bestimmten Orten deaktiviert werden Formale Spezifikation mit dem SFS Editor gt gt gt Satz 86 lt lt lt einfaches Verbot Zustand die Bewegung des Krans nach links zum Zuf hrband darf nicht gleichzeitig gestartet sein wenn der Kran am Zuf hrband ist AG rdy_plc amp Crane_at_fbelt amp Crane_to_fbelt gt gt gt Satz 87 lt lt lt einfaches Verbot Zustand die Bewegung des Krans nach rechts Ablageband darf nicht gleichzeitig gestartet sein wenn der Kran am Ablageband ist AG rdy_plc amp Crane_at_dbelt amp Crane_to_dbelt gt gt gt Satz 88 lt lt lt einfaches Verbot Zustand das Anheben des Krangreifers darf nicht gleichzeitig gestartet sein wenn der Greifer des Krans oben ist AG rdy_plc amp Crane_height 0 amp Crane_lift gt gt gt Satz 89 lt lt lt einfaches Verbot Zustand das Absenken des Krangreifers darf nicht glei
234. muss unmittelbar gestartet werden und der Zustand 1 der Presse muss unmittelbar zur ckgesetzt werden und der Zustand 2 der Presse muss unmittelbar gesetzt werden Satz 2 Wenn der Zustand 2 der Presse aktiv ist und die Presse ist oben dann muss das Offnen der Presse unmittelbar gestoppt werden und der Zustand 2 der Presse muss unmittelbar zur ckgesetzt werden und der Zustand 3 der Presse muss unmittelbar gesetzt werden Satz 3 Wenn die Presse unten ist dann darf das Ausfahren des Roboterarmes 1 nicht gleichzeitig gestartet sein wird durch den PreLexer der Metatext Satz 1 WENN press_z1 IST UND press_bottom IST DANN MUSS UNMITTELBAR I press_ down WERDEN UND MUSS UNMITTELBAR press _upward WERDEN UND MUSS UNMITTELBAR press_z1 WERDEN UND MUSS UNMITTELBAR press_z2 WERDEN Satz 2 WENN press_z2 IST UND press_top IST DANN MUSS UNMITTELBAR Ipress_upward WERDEN UND MUSS UNMITTELBAR press_z2 WERDEN UND MUSS UNMITTELBAR press_z3 WERDEN Satz 3 WENN press bottom IST DANN DARF NICHT GLEICHZEITIG arm1_forward SEIN 68 Prototypische Realisierung und Einsatz der Sicherheitsfachsprache erzeugt Dieser Text enth lt nur noch SFS typische Schl sselw rter sowie SPS Vari ablen 4 3 2 Compiler W hrend die Arbeitsweise des PreLexers in einer reinen Texterkennung um
235. n uussussssannnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 26 2 2 Formale Anforderungen uuuusssnnnnnnnnnnnunnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 29 2 3 Anforderungen aus dem Bereich der Steuerungstechnik uueeernnnn 31 2 3 1 Strukturen von automatisierten Systemen nennen 31 2 3 2 Ber cksichtigung der Arbeitsweise einer Steuerung ccceeeeeeeeeeeeeees 32 2 4 Inhaltliche Anforderungen uunnuunsssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 34 2 4 1 Das Pflichtenhefl rss 35 2 4 2 Kategorisierung aufgrund des Analyseverfahrens gt 36 2 4 3 Anforderungen aus dem Bereich der Steuerungstechnik 37 2 5 Einbindung der Sicherheitsfachsprache in eine Verifikationsumgebung 38 3 Die Sicherheitsfachsprache uunnesnssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnennnnnnnnnnn 41 3 1 Definition der Eege dE EENEG 41 3 1 1 Ausdrucksm glichkeiten der nat rlichen deutschen Gorache 41 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache 3 1 2 Definition des G ltigkeitsbereichs einer Anforderung sssessessessssreeeee 43 3 1 3 Ableitung des Modalparameters nennen 44 3 1 4 Ableitung des Zeitparameters nn nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 45 S Reiter ie un EE 47 3 1 6 Grafische Repr sentation der SFS Kategorien nenn 48 3 2 Temporale Logik als formale Basis der SFS eeeeeeeeeeeeeeseeneeeteeees 51 9 2 wil AUSS
236. n anhand einer Fallstudie Aufgabe In Anlehnung an die soeben formulierten Anforderungen d rfen Transportauftrage jedoch nicht ausgel st werden wenn die betreffende Produktionszelle nicht bereit ist Informelle Spezifikation Eine Beladung mit Rohteilen darf nicht erfolgen wenn die Bereitschaftsmeldung ei ner Produktionszelle nicht gesetzt ist Eine Entladung der Produktionszelle darf nicht erfolgen wenn die Fertigmeldung einer Produktionszelle nicht gesetzt ist Formale Spezifikation mit dem SFS Editor gt gt gt Satz 7 lt lt lt einfaches Verbot Zustand Wenn die Bereitschaftsmeldung der Produktionszelle 1 nicht gesetzt ist dann darf die Transportart nicht gleichzeitig auf 1 Rohteile holen gesetzt sein und die anzufahrende Produktionszelle darf nicht gleichzeitig 1 sein AG rdy_plc amp cell_l_ready amp tr_kind 1 tr_place 1 gt gt gt Satz 8 lt lt lt einfaches Verbot Zustand Wenn die Fertigmeldung der Produktionszelle 1 nicht gesetzt ist dann darf die Transportart nicht gleichzeitig auf 2 Fertigteile wegbringen gesetzt sein und die anzufahrende Produktionszelle darf nicht gleichzeitig 1 sein AG rdy_ple amp cell_l_finished amp tr_kind 2 tr_place 1 5 3 2 Ger teebene 2 Steuerung der Produktionszelle 1 Innerhalb dieser Arbeit wird nur die Produktionszelle 1 betrachtet Es handelt sich hierbei um diejenige die Bestandteil
237. n geltenden Vor schriften und Normen Verst ndlichkeit Eignung von Dokumenten zur erfolgreichen Vermittlung der darin enthaltenen Information an einen sachkundigen Leser Vollst ndigkeit Vorhandensein der f r den Zweck der Dokumente notwendigen und hinreichenden Information Widerspruchsfreiheit Nichtvorhandensein sich entgegenstehender Aussagen in Do kumenten Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Vertiefende Informationen zu diesem Thema k nnen den Normen DIN 66272 Softwarequalit tsmerkmale DIN ISO 8402 Qualitatssicherung DIN 66230 Benutzerdokumentation IEC 1508 3 Functional Safety Software requirements DIN V VDE 0801 Grunds tze f r Rechner mit Sicherheitsaufgaben entnommen werden Habl98 1 3 Nat rliche Sprache als Beschreibungsmittel Die Zusammenstellung der Qualit tsparameter f r Software und ihre Dokumente hat gezeigt dass Spezifikationen gleichzeitig kompakt vollst ndig konsistent genau und eindeutig sein m ssen Gem der vorherrschenden Meinung wird die nat rli che Sprache jedoch als ungeeignet als Spezifikationsmittel betrachtet Dies liegt an einigen Eigenarten Stru91 Die nat rliche Sprache ist mehrdeutig die Bank ist das Geldinstitut oder die Sitzgelegenheit gemeint nat rlichsprachliche Aussagen sind oftmals vage etwas mehr wie viel ist das innerhalb eines Textes besteht die M glichkeit der elliptis
238. n und Sicherheitskonzepten die auf einer System FMEA basieren und eine Risi koanalyse und bergreifende Fehleranalyse 75 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache AbschlieBend in diesem Zusammenhang sei Leve95 empfohlen Hier werden aus f hrlich die Grundlagen der Risikountersuchungen in technischen Systemen die verwendeten Begriffe Grundlagen der Systemsicherheit sowie Techniken der Risi koanalyse behandelt Anhand von Unfallbeispielen wird die Rolle von Computern in modernen technischen Systemen deutlich gemacht Als besonderes Beispiel eines deduktiven Verfahrens zur Gefahrenanalyse eines technischen Systems wird nachfolgend die Fehlerbaumanalyse beschrieben Dies geschieht vor allem auch deshalb weil mit ihr innerhalb der nachfolgenden Fallstudie besondere Systemanforderungen identifiziert werden k nnen siehe Abschnitt 5 3 4 Bei der Fehlerbaumanalyse werden alle Ursachen gesucht die zu einer Gef hrdung f hren k nnen Diese Ereignisse werden durch logische Operatoren Disjunktion Konjunktion verkn pft Durch die hierarchische Staffelung von Zwischenergebnissen und Folgebedingungen ergibt sich daraus der Fehlerbaum der die logische grafi sche Darstellung des zu untersuchenden Systems ist Ziel der Fehlerbaumanalyse ist die systematische Identifizierung aller m glichen Ursachen die zu einem Ausfall f h ren k nnen Als eine Besonderheit lassen sich Ausfall bzw Eintrittswahrscheinlich
239. nahme des Rohteils bereit ist F r die Entnahme des Fertigteils aus der Presse muss es einerseits eine Meldung geben wann die Presse mit dem Bearbeitungsvorgang fertig und somit zur bergabe des Teils bereit ist und wann das Ablageband zur bernahme des Fertigteils bereit ist Wie bereits dargestellt gibt es insgesamt drei Betriebsmodi des Roboters vergleiche Abbildung 31 deren Start auf unterschiedliche Bedingungen zur ckgef hrt werden muss 1 gleichzeitiges Ent und Beladen der Presse 2 nur Beladen der Presse 3 nur Entladen der Presse zu 1 Zun chst wird eine Meldung des Hubdrehtischs ben tigt dass er zur bergabe eines Rohteils bereit ist ebenso wird eine Meldung der Presse ben tigt dass sie zur bergabe eines Fertigteils bereit ist Letztendlich wird noch eine Meldung des Ablagebands ben tigt dass es zur bernahme des Fertigteils bereit ist Daraus kann ein Startsignal f r den Mix Modus generiert werden Zus tzlich muss beim Wiederbeladen der Presse die Koordination mit der Pressent tigkeit beachtet wer den Der Roboter muss also mitteilen dass er zum erneuten Beladen der Presse be reit ist Wenn die Presse dann ihrerseits die Beladestellung erreicht hat kann der Vorgang fortgesetzt werden zu 2 und 3 Es werden wiederum die bereits dargestellten Bereitschaftsmeldungen ben tigt jedoch werden diesmal andere Wahrheitswerte abgefragt zus tzlich wird f r die ausschlie liche Beladung der Presse eine Meldung
240. nd B2 war dann wird irgendwann F1 und wird irgendwann F2 Nachdem B1 war und B2 war muss irgendwann F1 werden und muss irgendwann F2 werden Nachdem B1 war und B2 war wird irgendwann F1 und wird irgendwann F2 F1 muss irgendwann werden und F2 muss irgendwann werden wenn irgendwann B1 war und B2 war F1 wird irgendwann und F2 wird irgendwann wenn irgendwann B1 war und B2 war F1 muss irgendwann werden und F2 muss irgendwann werden wenn vorher B1 war und B2 war F1 wird irgendwann und F2 wird irgendwann wenn vorher B1 war und B2 war Kategorie DEe1 erweiterte Forderung Zustand Nur wenn B1 ist und B2 ist dann muss gleichzeitig F1 sein und muss gleichzeitig F2 sein Nur wenn B1 ist und B2 ist dann muss gleichzeitig F1 bleiben und muss gleichzeitig F2 bleiben F1 muss nur sein und F2 muss nur sein wenn gleichzeitig B1 ist und B2 ist F1 muss nur bleiben und F2 muss nur bleiben wenn gleichzeitig B1 ist und B2 ist Kategorie DEe2 erweiterte Forderung direkt Nur wenn B1 ist und B2 ist dann muss unmittelbar F1 werden und muss unmittelbar F2 werden Nur wenn B1 ist und B2 ist dann muss sofort Fi werden und muss sofort F2 werden 124 Anhang Nur wenn B1 ist und B2 ist dann wird unmittelbar F1 und wird unmittelbar F2 Nur wenn B1 ist und B2 ist dann wird sofort F1 und wird sofort F2 F1 muss nur unmittelbar werden und F2 muss nur unmittelbar werden wenn B1 ist und B2
241. ndsvariable des Krans muss unmittelbar 2 werden und die Bewegung des Krans nach rechts Ablageband muss unmittelbar gestartet werden AG rdy_in amp Crane_state 0 amp Crane_run_dbelt gt Al rdy_plc U rdy_plc amp Crane_run_dbelt amp Crane_state 2 amp Crane_to_dbelt gt gt gt Satz 66 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 1 ist und der Kran ist am Eingangspuffer dann muss die Zustandsvariable des Krans unmittelbar 11 werden und das Absenken des Krangreifers muss unmittelbar gestartet werden AG rdy_in amp Crane_state 1 amp Crane_at_source gt Al rdy_plc U rdy_plc amp Crane_state 11 amp Crane_lower gt gt gt Satz 67 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 1 ist und der Kran ist am Zuf hrband dann muss die Zustandsvariable des Krans unmittelbar la werden und die Bewegung des Krans nach rechts Ablageband muss unmittelbar gestartet werden AG rdy_in amp Crane_state 1 amp Crane_at_fbelt gt Al rdy_plc U rdy_plc amp Crane_state 16 amp Crane_to_dbelt gt gt gt Satz 68 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 1 ist und der Kran ist am Ausgangspuffer dann muss die Zustandsvariable des Krans unmittelbar 1b werden und die Bewegung des Krans nach links zum Zuf hrband
242. ne Ablaufsteuerung mit einer Zustandsvariable Integer aufgebaut Weiter schaltbedingungen innerhalb dieses Ablaufs sind der Eingangspuffer ist belegt d h es gibt unbearbeitete Teile Not Aus wurde bet tigt Not Aus wurde wieder entriegelt Re Start Taster wurde bet tigt Die berf hrung vom Zustand Automatikbetrieb in den Ruhezustand darf nicht al lein durch blo e berwachung der Belegung des Eingangspuffers mit Rohteilen er folgen Dieser bergang darf vielmehr erst dann erfolgen wenn alle Werkst cke die in die Zelle hineingelangt sind auch wieder herausgekommen sind berwachung der Differenz zwischen Eingangs und Ausgangsz hler Interne Variable des HMI Technische Bezeichnung Variable Datentyp Kommentar Teiledifferenz pieces_diff Integer Tabelle 18 Datenebene 3 Interne Variablen des HMI 30 INT VAR_GLOBAL nieces_diff die Differenz zwischen Eingangs und Ausgangsz hler De se ON O_T gr er als 0 10 um 1 erh ht 1_0 um 1 verringert 150 Anhang Informelle Spezifikation Die Produktionszelle befindet sich standardm ig im Bereitschaftszustand die An zeige Anlage bereit soll leuchten Die Z hleranzeigen f r die Anzahl der eingegan genen sowie der ausgegangenen Teile soll auf O stehen Die Produktionszelle soll komplett selbst ndig arbeiten Mit dem Bearbeitungsprozess soll unmittelbar begon nen w
243. nen bekannt sein auf dem Ablageband liegt ein Fertigteil bereit der Ausgangspuffer ist frei F r den Ausgangspuffer war vorausgesetzt dass dieser jederzeit Teile aufnehmen kann Definition neuer Daten mit dem SFS Editor Das Ablageband muss eine Meldung generieren wenn es zur bergabe eines Fer tigteils bereit ist existiert bereits Es wird ein Startsignal definiert das den Kran zum Holen des Fertigteils veranlasst Variablen zur Kommunikation mit dem Kran Technische Bezeichnung Variable Datentyp Kommentar Startsignal Fertigteil holen Crane_run_dbelt Bool Fertigmeldung Kran hat Crane_done_take_dbelt Bool Teil vom Ablageband ge nommen Tabelle 24 Datenebene 3 Variablen zur Kommunikation mit dem Kran 59 BOOL VAR_GLOBAL Crane_run_dbelt das Startsignal Kran holt Fertigteil von Ablageband TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 60 BOOL VAR_GLOBAL Crane_done_take_dbelt die Fertigmeldung Kran hat Fertigteil vom Ablageband genommen TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 176 Aang nhan Formale Spezifikation mit dem SFS Editor gt gt gt Satz 60 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Automatikbetri
244. ng Not Aus Signal f r die Pressensteue Em_stopp_press Bool rung n Not Aus Signal f r die Steuerung des Em_stopp_dbelt Bool Ablagebands Tabelle 17 Datenebene 3 Interne Variablen des HMI 6624 BOOL VAR_GLOBAL Em_stopp_crane das Not Aus Signal f r den Kran TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gesetzt FALSE_O zur ckgesetzt 25 BOOL VAR_GLOBAL Em_stopp_fbelt das Not Aus Signal f r das Zuf hrband TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gesetzt FALSE_O zur ckgesetzt 26 BOOL VAR_GLOBAL Em_stopp_table das Not Aus Signal f r den Hubdrehtisch TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gesetzt FALSE_O zur ckgesetzt 27 BOOL VAR_GLOBAL Em_stopp_robot das Not Aus Signal f r den Roboter TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gesetzt FALSE_O zur ckgesetzt 28 BOOL VAR_GLOBAL Em_stopp_press das Not Aus Signal f r die Presse TRUE_I aktiv FALSE_I nicht aktiv 149 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache TRUE_O gesetzt FALSE_O zur ckgesetzt 29 BOOL VAR_GLOBAL Em_stopp_dbelt das Not Aus Signal f r das Ablageband TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gesetzt FALSE_O zur ckgesetzt Es wird ei
245. ng nicht mit einem eindeutigen Zu stand der Bedingung oder Folgerung verkn pft ist Die Abbildung 12 zeigt zun chst die einzelnen Diagramme f r die vier Anforderungs kategorien mit dem Zeitparameter Zustand So wird f r die einfache Forderung mit diesem Zeitparameter DEs1 verlangt dass in jedem SPS Zyklus in dem die Bedingung B wahr ist auch die Folgerung F erf llt sein muss Ist die Bedingung nicht erf llt so kann der Zustand der Folgerung belie big sein Erst bei der erweiterten Forderung DEe1 wird zus tzlich verlangt dass bei nichterf llter Bedingung B auch die Folgerung nicht erf llt sein darf Die Interpretation der weiteren Diagramme Abbildung 13 Abbildung 14 Abbildung 15 Abbildung 16 ergibt sich auf analoge Weise Hier sind besonders deutlich die Zusammenh nge der einzelnen Anforderungskategorien zu erkennen das einfache Verbot stellt eine Umkehrung der einfachen Forderung dar die erweiterte M glichkeit ergibt sich durch Invertierung des einfachen Verbo tes die erweiterte Forderung ergibt sich durch Verschmelzung der einfachen For derung mit der erweiterten M glichkeit Diese Zusammenh nge werden nachfolgend auch bei der Erstellung der temporallo gischen Formeln wieder aufgegriffen siehe Abschnitt 3 2 4 48 einfache Forderung Zustand de SPS Zyklen n erweiterte Forderung Zustand erh de oct gl are ni SPS Zyklen n einfaches Verbot Zustand
246. ngsmethodik und der Bezeichnung der Phasen erkennen die Unterschiede treten erst bei der Be trachtung der Verbindungen und Schnittstellen zwischen den einzelnen Phasen her vor Am Beispiel des weit verbreiteten V Modells soll der Inhalt eines solchen Vorge hensmodells kurz erkl rt werden Der Entwicklungszyklus eines Produktes l sst sich vereinfacht in die folgenden sieben Phasen einteilen 1 Planung Zielvorgabe durch den Auftraggeber hier entsteht das Lastenheft 2 Problemanalyse definition Problemspezifikation hier entsteht das Pflichten heft 3 Entwurf des Systems Systemspezifikation Zergliederung in Komponenten 4 Implementierung und Realisierung der Einzelmodule Test Dokumentation 5 Vervollst ndigung des Gesamtsystems Funktions und Leistungspr fung hier ist das funktionsf hige System fertig 6 Installation und Abnahme durch den Auftraggeber 7 Betrieb und Wartung Im V Modell werden diese Schritte ebenfalls durchlaufen die grafische Anordnung der einzelnen Schritte erfolgt in Form eines V siehe Abbildung 5 Dies geschieht um die inhaltlichen Zusammenh nge der Einzelphasen des linken Astes mit denen des rechten Astes gegen berstellen zu k nnen Hierbei werden in einer zusammen 15 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache hangenden Darstellung die Entwurfs und Implementierungsschritte mit den jeweili gen Testprozeduren und verfahren verkn pft
247. nhub Press_upward Bool TRUE Presse schlie t sich L R Dress down Bool TRUE Presse 6ffnet sich Tabelle 38 Datenebene 4 Aktor der Presse 6699 BOOL VAR Press_upward das Schliessen der Presse TRUE_O gestartet FALSE_O gestoppt TRUE_I aktiv FALSE_I nicht aktiv 100 BOOL VAR Press_down das ffnen der Presse TRUE_O gestartet FALSE_O gestoppt TRUE_I aktiv FALSE_I nicht aktiv Informelle Spezifikation Der Steuerung der Presse verbleibt solange in Ruhe bis durch die Zellensteuerung entweder das Startsignal zum Presse eines Rohteils oder zur Positionierung der Presse f r eine bernahme eines neuen Rohteils erfolgt Danach wird die geforderte Routine bearbeitet Es sind zwei separate Routinen zu unterscheiden die alternativ voneinander ablaufen k nnen Die innerhalb dieser Routinen abzuarbeitenden Teilvorg nge sind unbedingt in der festgelegten Reihenfolge abzuarbeiten es bietet sich die Entwicklung einer Ablaufstruktur an Defintion neuer Daten mit dem SFS Editor Interne Variable der Steuerung der Presse Technische Bezeichnung SPS Variable Datentyp Kommentar Zustandsvariable der Presse Press_state Integer Tabelle 39 Datenebene 4 Interne Variable der Steuerung der Presse 33101 INT VAR Press_state die Zustandsvariabl der Presse Ov al age EON T wa
248. nommen unmittelbar zur ckgesetzt werden und das Startsignal Hubdrehtisch senken und rechts drehen muss unmittelbar gesetzt werden AG rdy_in amp cell_l_state 1 amp Robot_done_take_table gt Al rdy_plc U rdy_plc amp Robot_done_take_table amp Table_run_lower Informelle Spezifikation weiterer Eigenschaften Der Hubdrehtisch darf sich nicht heben wenn das Zuf hrband nicht bergeben hat Der Hubdrehtisch darf sich nicht senken wenn der Roboter das Teil nicht ent nommen hat Formale Spezifikation mit dem SFS Editor gt gt gt Satz 36 lt lt lt einfaches Verbot Zustand das Startsignal Hubdrehtisch heben und links drehen darf nicht gleichzeitig gesetzt sein wenn die Fertigmeldung Zuf hrband hat Teil auf Tisch abgelegt nicht gesetzt ist AG rdy_plc amp Fbelt_done_give amp Table_run_lift gt gt gt Satz 37 lt lt lt einfaches Verbot Zustand das Startsignal Hubdrehtisch senken und rechts drehen darf nicht gleichzeitig gesetzt sein wenn die Fertigmeldung Roboter hat Teil vom Tisch genommen nicht gesetzt ist AG rdy_plc amp Robot_done_take_table amp Table_run_lower 164 Anhang A 7 2 5 Kommunikation mit dem Roboter Der Roboter hat in der Produktionszelle zwei Aufgaben Transport von Rohteilen vom Hubdrehtisch zur Presse Transport von Fertigteilen von der Presse zum Ablageband F
249. ns weise nun jedoch von au en nicht mehr unbedingt nachvollziehbar war Als 1968 in den USA die erste kommerzielle speicherprogrammierbare Steuerung MODICON 084 Richard E Morley auf den Markt gebracht wurde kam es wie derum zu einer sprungartigen Ver nderung der Situation Zun chst verf gten diese Systeme zwar nur ber begrenzte Rechen und Speicherkapazit ten jedoch war es nur eine Frage der Zeit und es begann eine hnlich rasante Entwicklung wie bei Personalcomputern Moderne industrielle Steuerungssysteme sind hnlich leis tungsf hig wie B rorechner selbst Steuerungssysteme auf reiner PC Basis werden heute eingesetzt Diese hohe Leistungsf higkeit f hrt jedoch auch zu dem Wunsch immer mehr und komplexere Funktionalit ten auf diesen Systemen auszuf hren Applikationen die man vor Jahren noch f r undurchf hrbar hielt sollen nunmehr durch Steuerungssysteme bew ltigt werden Folglich werden Ingenieure und Techni ker heute mit Problemstellungen beauftragt deren L sung neben dem ingenieurwis senschaftlichen Wissen ein weitaus h heres Verst ndnis der Informatik voraussetzt als dies bisher der Fall war Steuerungstechniker werden zunehmend als Software entwickler t tig Die dabei verwendeten Methoden und Verfahren haben jedoch of fensichtlich mit der rasanten technischen Entwicklung nicht Schritt gehalten Einleitung und Ausgangssituation 1 1 3 Spezifikation von Steuerungssystemen G Futschek visualisiert in Fu
250. nsoren und Aktoren 2 die verwendete Steuerung mit den integrierten Betriebssystemfunktionen 3 das vom Automatisierungstechniker erstellte Steuerungsprogramm Diese drei Komponenten werden einzeln modelliert und in einem anschlie enden Kompositionsschritt zu einem Systemmodell vereinigt Die am Modell zu verifizierende Spezifikation ist durch die Anforderungen des Pflichtenheftes gegeben Diese Festlegungen liegen jedoch in automatisierungstech nisch spezifischen Darstellungsformen bzw verbal vor Da f r das Model Checking 39 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache jedoch Formeln der Temporalen Logik ben tigt werden m ssen die Anforderungen zun chst formalisiert und in die ben tigten Formeln berf hrt werden Die hierbei verwendete Sicherheitsfachsprache und die notwendigen Schritte werden in den Ka piteln 3 1 und 4 2 dargestellt Die anschlie ende berpr fung der Anforderungen erfolgt im Verifizierungsschritt durch den Model Checker Sollten alle Anforderungen erf llt und als richtig verifiziert worden sein kann das Steuerungsprogramm als korrekt bez glich den gegebenen Bedingungen bezeichnet werden Treten dagegen Fehler auf ist eine Modifikation des SPS Programms notwendig 40 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache 3 Die Sicherheitsfachsprache In den vorherigen Abschnitten wurden verschiedene Anforderungen an ein formales Spezifikationswerkz
251. nt sein Innerhalb des Schwer punktprogramms Integration von Techniken der Softwarespezifikation f r ingenieur wissenschaftliche Anwendungen SPP 1064 besch ftigt sich das Teilprojekt SpeciMen mit der Integration von Spezifikations und Modellierungstechniken bei der Modellsynthese im Steuerungsentwurf http mathsrv ku eichstaett de MGF informatik Projekte Specimen specimen html KU Eichst tt Prof Desel Uni Halle Prof Hanisch Ziel ist die Entwicklung einer Methodik zur Kon struktion eines integrierten Modells aus gegebenen verschiedenartigen Spezifikatio nen so dass das Verhalten des Modells den Spezifikationen gen gt und eine Syn these des Modells m glich ist Als formales Modell werden geeignet definierte Petri Netze verwendet Innerhalb desselben Schwerpunktprogramms wird in Bits02 die Spezifikation von Sicherheitsanforderungen mit so genannten Safety Patterns vor geschlagen Hierbei handelt es sich um einen Katalog fest vorgegebener Sprachkon strukte die mit konkreten Programmanforderungen zu vervollst ndigen sind und eine temporallogische Basis haben Das Projekt SACRES Safety Critical Real Time Embedded Systems www tni fr sacres befasst sich mit der Entwicklung von zuverl ssigen sicherheitskri tischen eingebetteten Systemen Ziel ist die Reduzierung von Designfehlern und eine Verringerung der Entwicklungszeiten und kosten Die Spezifikation erfolgt mit SILDEX Statemate und TDE dem Timing di
252. nzt die Drehung des Roboters nach links darf niemals gestartet werden solange der 96 Validierung des Prototypen anhand einer Fallstudie Roboterarm 1 vorn ist AG rdy_plc amp Arml_ext 1 0 amp Robot_left gt gt gt Satz 160 lt lt lt einfaches Verbot selbstbegrenzt die Drehung des Roboters nach rechts darf niemals gestartet werden solange der Roboterarm 1 vorn ist AG rdy_plc amp Arml_ext 1 0 amp Robot_right gt gt gt Satz 161 lt lt lt einfaches Verbot selbstbegrenzt die Drehung des Roboters nach links darf niemals gestartet werden solange der Roboterarm 2 vorn ist AG rdy_plc amp Arm2_ext 1 0 amp Robot_left gt gt gt Satz 162 lt lt lt einfaches Verbot selbstbegrenzt die Drehung des Roboters nach rechts darf niemals gestartet werden solange der Roboterarm 2 vorn ist AG rdy_plc amp Arm2_ext 1 0 amp Robot_right gt gt gt Satz 174 lt lt lt einfaches Verbot Zustand das Schlie en der Presse darf nicht gleichzeitig gestartet sein wenn der Roboter mit dem Arm 1 vor der Presse ist und der Roboterarm 1 ist in der Presse AG rdy_plc amp Robot_angle 90 amp Arml_ext 0 65 amp Press_upward gt gt gt Satz 175 lt lt lt einfaches Verbot Zustand das Schlie en der Presse darf nicht gleichzeitig gestartet sein
253. o en Umfangs dieser Fallstudie werden in diesem Abschnitt jedoch nur ausgew hlte Problembereiche pr sentiert weitere Details k nnen dem Anhang entnommen werden Abschlie end werden im Abschnitt 6 die wichtigsten Ergebnisse der Arbeit zusam mengefasst Einige Aussagen zu weiteren Entwicklungsm glichkeiten und Anwen dungsfeldern der Sicherheitsfachsprache runden die Ausf hrungen ab Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Abstract Computer systems and automatic controls have an increasing influence upon our daily life They are useful for the solution of complex time consuming and monoto nous problems They give us the possibility to relieve employees of physically serious and dangerous work Today we can find computers in some areas where it was still unthinkable a few years ago to transfer control to a machine The main condition for this migration process is apart from the development of smaller but more efficient hardware the development of the accompanying software Without this software the computer or the control system would remain useless A methodical and well considered procedure for the development of software the so called software engineering is a domain of computer science by now Though the increasing complexity in automation engineering the rising needs of safety of the user as well as the growing spread of conventional computer hardware used pro gramming languages includ
254. o zwei separate Transportvorg nge zu unterschei den die alternativ voneinander ablaufen k nnen Die innerhalb dieser Routinen ab zuarbeitenden Teilvorg nge sind wiederum unbedingt in der festgelegten Reihen folge abzuarbeiten es bietet sich wiederum die Entwicklung einer Ablaufstruktur an Defintion neuer Daten mit dem SFS Editor Interne Variable der Steuerung des Zuf hrbands SPS Variable Kommentar Fbelt_state Technische Bezeichnung Datentyp Zustandsvariable des Zuf hrbands Integer Tabelle 30 Datenebene 4 Interne Variable der Steuerung des Zuf hrbands 374 INT VAR Fbelt_state die Zustandsvariable des Zuf hrbands VE 0 E e ILL 2_ w2 21_ WI O_O auf 0 gesetzt 10 auf 1 gesetzt _O auf 11 gesetzt 2 0 auf 2 gesetzt 21_0 auf 21 gesetzt 194 Anhang fbelt_run_transport fbelt_run_table fbelt_run_transport fbelt_run_table Fbelt_start Fbelt_start ILB_at_fbelt LB_at_fbelt Fbelt_start Fbelt_start Fbelt_rdy_give Fbelt_done_give Fbelt_rdy_take Fbelt_rdy_transport true true Formale Spezifikation mit dem SFS Editor gt gt gt Satz 96 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Zuf hrbands 0 ist und das Startsignal Zufiihrband soll Teil zum Bandende transportieren ist gesetzt dann muss das Startsignal Zuf hrband soll Te
255. oduktionszelle basiert auf der bekannten und in der Lite ratur oft verwendeten Fallstudie Produktionszelle Lewe95 Betrachtungsobjekt ist eine reale Produktionsst tte in einem metallverarbeitenden Betrieb In ihr werden Metallschienen durch eine Presse bearbeitet Die Anlieferung der Rohteile erfolgt ber ein Zuf hrband und einen Hubdrehtisch von dort wird die Presse durch einen Roboter beladen vergleiche Abbildung 25 Nach dem Bearbeitungsvorgang wird die Presse wieder durch den Roboter entladen die Fertigteile werden durch ein Ablageband abtransportiert Um einen zyklischen Betrieb zu simulieren wurde die reale Anlage in der Studie um einen Kran erweitert Dieser nimmt das Fertigteil am Ende des Ablagebands auf und legt es wieder auf dem Zuf hrband ab 5 1 Einf hrung in die Fallstudie 5 1 1 Die Gesamtanlage Die in der Erweiterten Produktionszelle zus tzlich eingebrachten Komponenten sollen dazu dienen die urspr ngliche Produktionszelle in eine Produktionsanlage mit einem m glichst realen technischen Hintergrund zu integrieren Die Gesamtanlage Abbildung 24 umfasst jetzt mehrere Produktionszellen unterschiedlichen Typs wo bei die urspr ngliche Produktionszelle jetzt als Produktionszelle 1 wiederzufinden ist ein Transportsystem sowie jeweils ein Lager f r Roh bzw Fertigteile Die ge naue technische Realisierung dieser zus tzlichen Komponenten sowie der Daten austausch zwischen den einzelnen Komponenten soll un
256. oduktionszelle 1 unmittelbar in den Automatikzustand berf hrt werden und die Anzeige Zelle ist bereit muss unmittelbar deaktiviert werden und die Anzeige Automatik l uft muss unmittelbar aktiviert werden AG rdy_in amp cell_l_state 0 amp Piece_at_source gt Al rdy_plc U rdy_plc amp cell_l_state 1 amp LED_celll_rdy amp LED_celll_run gt gt gt Satz 6 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Ruhezustand 0 ist und die Differenz zwischen Eingangs und Ausgangsz hler ist gr er als 0 dann muss die Produktionszelle 1 unmittelbar in den Automatikzustand berf hrt werden und die Anzeige Zelle ist bereit muss unmittelbar deaktiviert werden und die Anzeige Automatik l uft muss unmittelbar aktiviert werden 152 Anhang AG rdy_in amp cell_l_state 0 amp pieces_diff 0 gt Al rdy_plc U rdy_plc amp cell_l_state 1 amp LED_celll_rdy amp LED_celll_run gt gt gt Satz 7 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Ruhezustand 0 ist und der Not Aus Taster ist gedr ckt dann muss die Produktionszelle 1 unmittelbar in den Not Aus Zustand berf hrt werden und die Anzeige Zelle ist bereit muss unmittelbar deaktiviert werden und die Anzeige Not Aus muss unmittelbar aktiviert werden und das Not Aus Signal f r den Kran muss
257. ogramms l sst sich folgenderma en grob klassifizieren Litz98 a das Programm f hrt eine Aktion aus die nicht erwartet wurde diese Fehler werden als aktive Fehler bezeichnet b das Programm f hrt eine erwartete Aktion nicht aus diese Fehler werden als passive Fehler bezeichnet Bei einem aktiven Fehler werden also Steuerungsfunktionen ausgel st ohne dass die programmgem festgelegten Bedingungen erf llt sind Von einem passiven Fehler spricht man wenn Steuerungsfunktionen blockiert sind obwohl alle pro grammgem festgelegten Bedingungen erf llt sind Die Ursachen f r ein solches Verhalten k nnen vielgestaltig sein Zun chst muss man festhalten dass Software ein anderes Ausfallverhalten als Hardware hat Typi sche Probleme der Hardware wie Abnutzung und Verschlei treten bei Software abgesehen von einer moralischen Alterung prinzipiell nicht auf Software ver n dert nicht von selbst ihre Eigenschaften sie ist inh rent fehleranf llig Hala98 Habl98 Vielmehr muss man davon ausgehen dass Software die sich im laufenden Betrieb als mangelhaft herausstellt diese Eigenschaften bereits bei der Inbetriebnahme besa Softwarefehler sind also ausschlie lich systematische Feh ler die aus der Planung dem Entwurf und der Programmierung hervorgehen H Balzert beschreibt in Balz96 die Ursachen f r solche Programmierfehler Irrt mer Schnitzer ber individuelle Denkfallen sowie individuelle Fehler
258. olgenden als statische bzw dynamische Analysen bezeichnet werden Statische Analysen untersuchen entweder die prinzipielle Erreichbarkeit eines erw nschten Zustandes sie zeigen mit ei nem Zeugniszustand dass das System diesen Zustand berhaupt einnehmen kann ohne den Weg dorthin zu betrachten die prinzipielle Abwesenheit eines m glicherweise unerw nschten Zustan des dies betrifft die typischen Sicherheitsanforderungen an ein System Dynamische Analysen untersuchen die prinzipielle Erreichbarkeit eines erw nschten Zustandes von einem gegebenen Anfangspunkt aus hierdurch kann nachgewiesen werden dass das System einen definierten Zielzustand dessen Existenz durch eine stati sche Analyse bereits nachgewiesen wurde auch von einem oder mehreren definierten Startpunkten erreicht werden kann die schnellstm gliche Erreichbarkeit eines erw nschten Zustandes durch Identifizierung des k rzesten Pfades unter Beachtung der Programmausf h rung In Wehr96 Mann92 und anderen Quellen werden relevante Kategorien von Eigen schaften definiert Man unterscheidet demnach Sicherheitseigenschaften Fortschrittseigenschaften Lebendigkeitseigenschaften Die Klassifizierung ist in der Literatur leider nicht durchg ngig gegebenenfalls tritt eine Vermischung der Fortschritts und Lebendigkeitseigenschaften auf Sicherheitseigenschaften engl safety properties beinhalten dass das System nie mals in einen unerw nscht
259. orderung wieder um so bedeutet dies dass die Folge rung solange nicht ausgef hrt werden darf bis die Bedingung nicht mindestens ein mal erf llt wurde D h au erhalb des Beobachtungsintervalls darf es keinen Zustand geben in dem rdy_plc x F wahr ist A ry De F U rdy_in a B Kategorie DEe5 erweiterte Forderung Unbegrenzt Analyseinhalt Nach jedem Zustand in dem rdy_in und eine Bedingung B erf llt ist muss es irgendwann einen Zustand geben in dem rdy_plc und F erf llt sind Zus tz lich darf es keinen Zustand mit rdy_plc und F geben bevor nicht rdy_in und eine Be dingung B erf llt worden sind Dieses Verhalten l sst sich aus den beiden Kategorien DEs5 und POe5 zusammensetzen Einerseits besteht die Forderung dass das Steuerungsprogramm auf ein beim Einlesen der Sensorwerte erkanntes Ereignis immer irgendwann reagiert andererseits darf die genannte Reaktion auch nicht vor her eintreten AG rdy_inaB gt AF rdy_plc a F A A rdy_pleA F U rdy_in B 59 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Zeitparameter Fremdbegrenzt Kategorie DEs4 einfache Forderung Fremdbegrenzt Analyseinhalt Sobald es einen Zustand gibt in dem rdy_in und eine Startbedingung B erf llt werden muss es danach immer einen Zustand geben in dem rdv ole und eine Folgerung F erf llt werden bevor es einen Zustand gibt in dem rdy_in und eine Endbedingung B2 erf llt sind AG rdy_in a
260. orie PRs5 einfaches Verbot unbegrenzt Wenn irgendwann B1 war und B2 war dann darf nicht irgendwann F1 werden und darf nicht irgendwann F2 werden Wenn irgendwann B1 war und B2 war dann darf niemals F1 werden und darf niemals F2 werden Nachdem B1 war und B2 war darf nicht irgendwann F1 werden und darf nicht irgendwann F2 werden Nachdem B1 war und B2 war darf niemals F1 werden und darf niemals F2 werden F1 darf nicht irgendwann werden und F2 darf nicht irgendwann werden wenn irgendwann B1 war und B2 war F1 darf niemals werden und F2 darf niemals werden wenn irgendwann B1 war und B2 war F1 darf nicht irgendwann werden und F2 darf nicht irgendwann werden wenn vorher B1 war und B2 war F1 darf niemals werden und F2 darf niemals werden wenn vorher B1 war und B2 war 128 Anhang A 4 Struktur der Datei zur Definition und Zuordnung der Nomen und Werte lt Zuordnung gt lt Nr gt A Datentyp gt lt Variablentyp gt lt SPS_Variable gt lt Nomen gt lt Wert zuordnung gt lt Wert zuordnung_BOOL gt lt Wert zuordnung_INT gt lt Wert gt Pp lt Nr gt lt Datentyp gt lt Variablentyp gt lt SPS Variable gt TT lt Nomen gt lt Wert zuordnung gt Py ko gr SE BER BOOL INT REAL VAR VAR_ACCESS VAR_EXTERNAL VAR_GLOBAL VAR_IN_OUT VAR_INPUT VAR_OUTPUT lt n
261. orit t VAR der Verdichtermotor 2 VAR_OUTPUT der Verdichtermotor 1 VAR_OUTPUT der Verdichtermotor 2 VAR_INPUT der Verdichtermotor 1 VAR_INPUT der Druck im AA fesch aoool MAD INMDUIT a ar Deklarationstyp VAR_OUTPUT Kommentar Verdichtermotor 1 an Motor 1 hat die Priorit t Verdichtermator 2 an Verdichtermator 1 an Motor 2 gest rt Motor 1 gest rt Drueksansne zB Ih SPS Variable Datentyp al BOOL z Verbalname der Verdichtermotor 1 Wertvorgaben f r Bedingungen Wertvorgaben f r Forderungen SPS Zuordnung SPS Zuordnung nicht aktiv FALSE ausgeschaltet FALSE aktiv TRUE eingeschaltet TRUE ndern L schen Neu ndern L schen OK Hilfe Abbruch Uebernehmen Abbildung 20 Erstellung der Verbalphrasen Bearbeiten L schen Importieren exportieren speichern laden Nachdem alle SPS Variablen interpretiert worden sind k nnen die eigentlichen An forderungss tze erstellt werden Dazu wird im SFS Editor ein neuer Satz erzeugt und es werden der Modalparameter und der Zeitparameter bestimmt Abbildung 21 Bean kltr He AipRB IS gt gt gt Satz 1 lt lt lt werden und der Verdichtermotor 2 muss unmittelbar eingeschaltet werden gt gt gt Satz 3 lt lt lt Wenn der Druck im Windkessel gr er als 6 1 bar ist dann darf nicht gleichzeitig der Verdichtermotor 2 eingeschaltet sein Satzauswahl f r Satz 2 von 3 in Windkessel 2 sfs Wenn der Druck im Windkessel kleiner als 5 9 ba
262. ozess von Software kann folgenderma en veranschaulicht wer den In dem betrachteten System in das die Software integriert werden soll gibt es blicherweise eine Anzahl von variablen Gr en die w hrend des Betriebes ver schiedene Werte Zust nde einnehmen k nnen Durch Kombination dieser Vari ablenzust nde entsteht eine oftmals sehr gro e aber dennoch endliche Menge von Zust nden die das gesamte System einnehmen kann Innerhalb dieser Menge von theoretisch einnehmbaren Systemzust nden gibt es nun einerseits solche die er w nscht d h normale Betriebszust nde des Systems sind Abbildung 2 Auf der anderen Seite gibt es auch Systemzust nde die unbedingt vermieden werden m s sen weil sie eine Gef hrdung des Systems oder der Umwelt z B des Bedieners darstellen Das zu entwickelnde Steuerungsprogramm soll nun den Zustandsraum des Systems so eingrenzen dass einerseits die gew nschten Systemzust nde und zwar in einer geforderten Reihenfolge erreicht und andererseits die unerw nschten Systemzust nde nicht mehr eingenommen werden erw nschter Sa Se Zustand ustande erw nschter erw nschter Zustand Zustand erw nschter System zust nde erkannte riskante Zust nde Spezifikations fortschritt unbewertete Zust nde unerkannte riskante Zust nde Abbildung 2 Spezifikation als Bewertung von Systemzust nden Bei der Spezifikation des Programms sollte id
263. p Fbelt_run_table 160 Anhan Informelle Spezifikation weiterer Eigenschaften Es darf kein Transport erfolgen wenn der Kran kein Rohteil abgelegt hat Es darf kein Transport erfolgen wenn das Zuf hrband nicht zum Transport bereit ist Es darf keine bergabe erfolgen wenn der Hubdrehtisch nicht bereit ist Es darf keine bergabe erfolgen wenn das Zuf hrband nicht zur bergabe bereit ist Formale Spezifikation mit dem SFS Editor gt gt gt Satz 29 lt lt lt einfaches Verbot Zustand das Startsignal Zuf hrband soll Teil zum Bandende transportieren darf nicht gleichzeitig gesetzt sein wenn die Fertigmeldung Kran hat ein Rohteil auf das Zuf hrband gelegt nicht gesetzt ist AG rdy_plc amp Crane_done_give_fbelt amp Fbelt_run_transport gt gt gt Satz 30 lt lt lt einfaches Verbot Zustand das Startsignal Zuf hrband soll Teil zum Bandende transportieren darf nicht gleichzeitig gesetzt sein wenn die Bereitschaftsmeldung Zuf hrband ist zum Transport bereit nicht gesetzt ist AG rdy_plc amp Fbelt_ready_transport amp Fbelt_run_transport gt gt gt Satz 31 lt lt lt einfaches Verbot Zustand das Startsignal Zuf hrband soll Teil auf Tisch bef rdern darf nicht gleichzeitig gesetzt sein wenn die Bereitschaftsmeldung Hubdrehtisch ist zur Ubernahme eines Teils bereit nicht gesetzt ist A
264. p_dbelt gt gt gt Satz 12 lt lt lt einfache Forderung direkt Wenn der Eingangspuffer belegt ist dann muss die Differenz zwischen Eingangs und Ausgangsz hler unmittelbar um 1 erh ht werden AG rdy_in amp Piece_at_source gt Al rdy_plc U rdy_plc amp pieces_diff 1 gt gt gt Satz 13 lt lt lt einfache Forderung direkt Wenn der Eingangspuffer belegt ist dann muss der Eingangsz hler unmittelbar um 1 erh ht werden AG rdy_in amp Piece_at_source gt Al rdy_plc U rdy_plc amp Count_in 1 154 Anhang gt gt gt Satz 14 lt lt lt einfache Forderung direkt Wenn der Ausgangspuffer belegt ist dann muss die Differenz zwischen Eingangs und Ausgangsz hler unmittelbar um I verringert werden AG rdy_in amp Piece_at_drain gt Al rdy_plc U rdy_plc amp pieces_diff 1 gt gt gt Satz 15 lt lt lt einfache Forderung direkt Wenn der Ausgangspuffer belegt ist dann muss der Ausgangsz hler unmittelbar um 1 erh ht werden AG rdy_in amp Piece_at_drain gt Al rdy_plc U rdy_plc amp Count_out 1 Informelle Spezifikation weiterer Eigenschaften Ein von der zentralen Steuerung erkanntes Not Aus Signal muss unverz glich an die untergeordneten Steuerungen der Einzelkomponenten weitergeleitet werden Formale Spezifikation mi
265. pi gt ys Nur wenn irgendwann lt cond_pl gt dann lt for_concl_pl gt bevor lt cond_pl gt DI Nur wenn irgendwann lt cond_pl gt dann lt for_concl_pl gt bis lt cond_pl gt DI Nachdem lt cond_pl gt lt for_concl_pl gt Nachdem lt cond_pl gt lt for_concl_pl gt bevor lt cond_pl gt Nachdem lt cond_pl gt lt for_concl_pl gt bis lt cond_pl gt Nur nachdem lt cond_pl gt lt for_concl_pl gt Nur nachdem lt cond_pl gt lt for_concl_pl gt DI bevor lt cond_pl gt Nur nachdem lt cond_pl gt dann lt for_concl_pl gt bis lt cond_p1 gt DI DI Solange lt cond_p1l gt lt for_concl_p1 gt DI Nur solange lt cond_pl gt lt for_concl_pl gt DI lt back_concl_pl gt wenn lt cond_pl gt lt back_concl_pl gt wenn gleichzeitig lt cond_pl gt lt back_concl_pl gt wenn irgendwann lt cond_pl gt lt back_concl_pl gt wenn vorher lt cond_pl gt lt back_concl_pl gt solange lt cond_pl gt lt back_concl_pl gt solange gleichzeitig lt cond_pl gt DI 131 Formale Spezifikation reak
266. pp_fbelt amp Em_stopp_table amp Em_stopp_crane amp 155 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Em_stopp_robot amp Em_stopp_press A 7 2 2 Kommunikation mit dem Kran I Informelle Spezifikation Die Steuerung der Produktionszelle muss an die Steuerung des Krans ein Signal ge ben wenn dieser ein Rohteil aus dem Eingangspuffer holen soll Dazu m ssen der Zellensteuerung die folgenden Informationen bekannt sein im Eingangspuffer liegt ein Rohteil das Rohteil kann auf dem Zuf hrband abgelegt werden Definition neuer Daten mit dem SFS Editor W hrend die Variable f r die Belegung des Eingangspuffers bereits definiert ist m ssen weitere Variablen noch definiert werden So muss das Zuf hrband eine Mel dung generieren dass es zur bernahme eines neuen Teils bereit ist Weiterhin wird ein Startsignal definiert das den Kran zum Transport eines Rohteils vom Eingangs puffer zum Zuf hrband veranlasst Der Kran wiederum muss mit einer weiteren Vari ablen die erfolgreiche Ausf hrung des Transports an die zentrale Steuerung wei terleiten Technische Bezeichnung Variable Datentyp Kommentar Meldung Zuf hrband Fbelt_rdy_take Bool f r Aufnahme eines Rohteils bereit Startsignal Rohteil Crane_run_source Bool holen Fertigmeldung Kran Crane_done_give_fbelt Bool Kran hat Rohteil auf Zuf hrband abgelegt 31 BOO
267. prache zur Formulie rung steuerungstechnischer Anforderungen Zeitschrift f r wirt schaftlichen Fabrikbetrieb ZwF 11 99 S 660 664 1999 Mertke T Deussen P Heiner M Eine anwenderorientierte Sicherheitsfachsprache zur Verifikation von Steuerungsprogram men Tagungsband EKA 2001 7 Fachtagung Engineering kom plexer Automatisierungssysteme S 297 310 25 27 April 2001 Braunschweig Mewes J M ller U Software fr hzeitig aus Kundensicht pr fen Qualit t und Zuverl ssigkeit 40 1995 4 95 Montenegro S Doppelt gedacht h lt besser Fehlertoleranz ge gen Entwicklungsfehler Elektronik 8 2000 109 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Moon91 Mord83 Oest98 Part98 Polk92 Reck91 Rein96 Rein99 Reis85 Ried83 Ross00a Ross00b Rupp96 Rust94 110 Moon l Powers G J Burch J R Clarce E M An automatic verification method using temporal logic for sequential chemical process control systems AIChE Journal vol 38 p 67 1991 Mordechai B A Pnueli A Manna Z The temporal logic of branching time Acta Informatica Springer Verlag 1983 Oesterreich B Objektorientierte Softwareentwicklung Analyse und Design mit der Unified Modeling Language Oldenbourg Verlag M nchen Wien 1998 Partsch H Requirements Engineering systematisch Springer Ve
268. prachige An s tze hierzu sind H lz98a Nutzung von Schablonen Bits02 Nutzung von Safety Patterns Innerhalb der Sicherheitsfachsprache wurden 18 Kategorien von Anforderungen definiert die sich sprachlich und in ihrer Bedeutung vollst ndig unter scheiden Wie diese Kategorien ermittelt und dargestellt wurden wird in den folgen den Abschnitten dargestellt 3 1 1 Ausdrucksm glichkeiten der nat rlichen deutschen Sprache Jede Anforderung die mit der Sicherheitsfachsprache formuliert wird ist eine Regel Regeln sind ein weitverbreitetes Mittel zur Wissensrepr sentation Balz96 Sie bestehen aus einer Vorbedingung wenn und einer Aktion dann Man kann zwei Typen von Regeln unterscheiden Implikationen Deduktionen mit denen der Wahrheitsgehalt einer Feststellung hergeleitet wird wenn dann ist Handlungen mit denen ein Zustand ver ndert wird wenn dann wird 41 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Die im Abschnitt 2 4 3 definierten Anforderungskategorien zeichnen sich in ihrer An wendung bei der verbalen Formulierung der Programmanforderung durch die Ver wendung bestimmter sprachlicher Konstruktionen und typischer Schl sselw rter aus Kategorie Beispiele Forderungen muss m ssen soll sollen ist zu sind zu Verbote darf nicht soll nicht M glichkeiten darf d rfen kann k nnen Tabelle 1 Schl
269. prog rammierbaren Steuerung da sich hieraus weitere grundlegende Schlussfolgerungen bez glich der Formulierung von Anforderungen an ein Steuerungsprogramm und somit auch an den Aufbau der Sicherheitsfachsprache ergeben 32 Anforderungen an ein formales Beschreibungsmittel Die folgende Abbildung zeigt den allgemeinen Aufbau einer automatisierten Anlage vergleiche Lemm 95 Verbindungen zu bergeordneten Steuerungen AA Steuerung z B SPS CPU Betriebs Steuerungsprogramm system Anwenderprogramm Verbindungen zu benachbarten Steuerungen Eingange Ausgange digital analog digital analog ungesteuerter Prozess Sensoren Aktoren Endschalter Taster Motoren Anzeigen Komponenten der Anlage SH Verbindungen zu benachbarten Prozessen Daten Materialfluss Abbildung 7 Informationsfluss in einem automatisierten System Eine SPS arbeitet immer mit einer Maschine oder Anlage zusammen sie empfangt Informationen aus der Umgebung verarbeitet diese entsprechend einem vorgege benen Algorithmus und gibt wiederum Informationen an die Umgebung ab Die Informationen der Umgebung werden durch Sensoren aufgenommen und in elektri sche Signale umgewandelt Diese werden Uber digitale oder analoge Eingangsbau gruppen in das SPS System eingebracht und durch das Betriebssystem eingelesen Diese Eingangssignale werden entsprechend dem Steuerungsprogramm verarbeitet Die berechne
270. r werden auf FALSE gesetzt Die Magnetgreifer behalten aus Sicherheitsgr nden ihren aktuellen Zustand bei Gleichzeitig muss die Anzeige Automatik l uft verl schen die Anzeige Not Aus muss aufleuchten Nachdem die gef hrliche Situation beseitigt und der Not Aus Taster entriegelt wurde kann der automatische Betrieb der Produktionszelle durch Bet tigen des Tasters Re Start wieder aufgenommen werden dieses Verhalten entspricht der Stop Kategorie I f r eine Not Aus Funktion gem DIN EN 418 151 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Em_stopp Pieces_diff 0 Piece_at_source ILED_cell1_rdy LED Gell rum Piece_at_source amp pieces_diff 0 Em_stopp LED_cell1_rdy LED_em_stopp Em_stopp_crane Em_stopp_fbelt Em_stopp_table Em_stopp_robot ILED_cell1_run 3 LED_cell1_rdy Count_in 0 Count_out 0 Em_stopp_press Em_stopp_dbelt true Em_stopp LED_em_stopp Restart 5 LED_em_stopp LED_celli_rdy Em_stopp_crane Em_stopp_fbelt Em_stopp_table Em_stopp_robot Em_stopp_press Em_stopp_dbelt true Abbildung 30 Betriebsartensteuerung der Produktionszelle Formale Spezifikation mit dem SFS Editor gt gt gt Satz 5 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Ruhezustand 0 ist und der Eingangspuffer ist belegt dann muss die Pr
271. r Sicherheitsfachsprache A 7 3 Gerateebene 2 Steuerung des Transportsystems Da sich die Darstellung der Fallstudie auf die Spezifikation der Produktionszelle kon zentriert wird die Spezifikation des Transportsystems nur ansatzweise dargestellt Diese erfolgt jedoch nach den gleichen Prinzipien wie sie bereits im Falle der Pro duktionszelle dargestellt und angewandt wurden Das Transportsystem dient innerhalb der Produktionsanlage dazu die einzelnen Produktionszellen mit Rohteilen zu versorgen bzw die bearbeiteten Fertigteile wieder von den Produktionszellen abzuholen Gegebene Daten Das Transportsystem erhalt von der Auftragsverwaltung neue Transportauftrage und informiert die Auftragsverwaltung Uber seinen Bereitschaftszustand und den Status der Ausf hrung des vorherigen Auftrags Details des Transportauftrags siehe Tabelle 10 Anhang Seite 142 Informelle Spezifikation Das Transportsystem meldet an die Auftragsverwaltung wenn es zur Ausf hrung eines neuen Transportauftrags bereit ist Sobald die Auftragsverwaltung einen neuen Transportauftrag generiert hat die Variable tr_kind ver ndert ihren Wert von 0 auf 1 oder 2 beginnt das Transportsystem automatisch mit der Ausf hrung dieses Auftrags Dazu muss das Transportsystem selbst ndig bestimmte Positionen innerhalb der Gesamtanlage anfahren k nnen und die Ubergabe bzw die bernahme von Werkst cken realisieren Wenn sich das leere Transpor
272. r ist dann muss der Verdichtermotor 1 unmittelbar eingeschaltet Modalparameter einfaches Verbot wenn dann darf nicht jel Zeitparameter Zustand gleichzeitig z Satzauswahl Wenn lt B gt ist dann darf nicht gleichzeitig lt F gt sein verf gbare Elemente Anzahl be 1 lt B gt 1 SFS Windkessel 2 sfs lolx E Projekt Definition Bearbeiten Satz Hilfe Window 8 x a S tze 3 Nomen 11 Abbildung 21 Erstellung der Anforderungss tze Durch die Bestimmung des Modal und Zeitparameters ist der Anforderungsinhalt prinzipiell bestimmt durch eine weitere Auswahl kann die Struktur des Satzes be stimmt werden An dieser Stelle werden dem Anwender mehrere inhaltlich redun dante Satzmuster angeboten die er nach seinem Geschmack auswahlen kann Diese inhaltliche Redundanz bezieht sich vor allem auf die Stellung der Bedingung und der Folgerung im Satz und auf die Auswahl verschiedener gleichwertiger Schl sselw rter 66 Prototypische Realisierung und Einsatz der Sicherheitsfachsprache Anschlie end ist der Anforderungssatz durch Erstellung der Bedingung en und der Folgerung en zu vervollst ndigen Abbildung 22 Auch hier werden wieder gleich wertige Formulierungen angeboten die sich jedoch nur durch die Stellung der ein zelnen W rter innerhalb der Formulierung unterscheiden T Nomen SPS Variable Wert Anfangsbedingung lt N gt lt w gt ist der Druck im W
273. r korrekt anfahren kann muss er zun chst seine relative Position zu ihm bestimmen Erst dann kann entschieden werden in welche Richtung der Kran fahren soll d h welches Aktorsignal zu aktiveren ist Prinzipiell 182 Anhang kann davon ausgegangen werden dass sich der Kran nach einem zuvor erfolgten Transportvorgang entweder am Zuf hrband oder am Ausgangspuffer befindet Diese beiden Positionen und auch wenn sich der Kran bereits am Eingangspuffer oder am Ablageband befindet k nnen durch die vorhandenen Sensoren erkannt werden Sollte sich der Kran an einer unbekannten Position befinden wenn also keiner der vier Sensoren aktiv sein so muss zun chst eine Fahrtrichtung festgelegt und durch nachfolgende erstmalige Erkennung eines Sensors die Position bestimmt werden Unter Umst nden ist dann die Fahrtrichtung wieder umzukehren Hat der Kran je doch die Position des Eingangspuffers erreicht so wird der Magnetgreifer auf die H he des Eingangspuffers abgesenkt Dann wird der Magnetgreifer aktiviert Danach beginnt das Anheben des Greifers Sobald dieser wieder oben ist f hrt der Kran zum Zuf hrband Dort angekommen wird der Greifer wieder abgesenkt Auf der H he des Zuf hrbands wird der Greifer angehalten und der Magnet wird abgeschalten Gleichzeitig kann die Meldung Kran hat Teil auf Zuf hrband gelegt gesetzt werden Danach wird der Greifer wieder angehoben Sobald der Greifer wieder in seiner obe ren Position ist wird er g
274. r_status 5 Analog zum dargestellten Satz k nnen weitere Anforderungen definiert werden order_status 2 3 oder 4 Aufbereitung der Produktionsauftr ge und Kommunikation mit der Ger te ebene 2 Die Auftragsverwaltung kommuniziert in geeigneter Weise mit dem Transportsystem und den Produktionszellen um die Ausf hrung der Produktionsauftr ge zu gew hr leisten Neben der Verwaltung der Produktionsauftr ge besteht eine wesentliche Aufgabe der Auftragsverwaltung in einer gezielten Kommunikation mit dem Transportsystem und den Produktionszellen um die einzelnen Produktionsauftr ge auszuf hren Durch die Analyse eines Produktionsauftrages ergeben sich die folgenden Kommu nikationsbeziehungen Kommunikation mit dem Transportsystem um Rohteile aus dem Lager zu ei ner Produktionszelle zu bef rdern Kommunikation mit der Produktionszelle um die erforderlichen Bearbeitungs vorg nge auszul sen nochmalige Kommunikation mit dem Transportsystem um die Fertigteile von der Produktionszelle zum Lager zu transportieren 84 Validierung des Prototypen anhand einer Fallstudie Informelle Spezifikation Es wurde dargestellt dass die Auftragsverwaltung in geeigneter Weise mit dem Transportsystem kommunizieren und dieses zum Best cken der Produktionszellen mit Rohteilen bzw zum Entladen der Produktionszellen veranlassen soll Definition neuer Daten mit dem SFS Editor Es wird ein Datensatz Transportauftrag d
275. rdy_plce amp Crane_at_fbelt amp Crane_height 0 94 amp Crane_lower gt gt gt Satz 94 lt lt lt einfaches Verbot selbstbegrenzt IT It Solange der Magnet des Krangreifers aktiv ist und der Kran ist nicht am Ablageband und der Kran ist nicht am Zuftihrband und der Kran ist nicht am Eingangspuffer und der Kran ist nicht am Ausgangspuffer darf der Magnet des Krangreifers niemals deaktiviert werden AG rdy_plc amp Crane_mag_on amp Crane_at_dbelt amp Crane_at_fbelt amp Crane_at_source amp Crane_at_ Crane_mag_on 192 Anhang A 7 5 Ger teebene 3 Steuerung des Zuf hrbands Die Steuerung des Zuf hrbands erh lt von der bergeordneten Zellensteuerung Startsignale zur Ausf hrung bestimmter Aktionen Durch verschiedene Sensoren und Aktoren ist die Steuerung des Zuf hrbands mit den Maschinenelementen verbunden Gegebene Daten Technische Bezeichnung Variable Datentyp Kommentar Meldung Zuf hrband Fbelt_rdy_take Bool f r Aufnahme eines Rohteils bereit Bereitschaftsmeldung Fbelt_rdy_transport Bool Zuf hrband ist zum Zuf hrband bereit Transport bereit zum Transport Startsignal Rohteil Fbelt_run_transport Bool Zuf hrband soll Teil zum Bandende zum Bandende transportieren transportieren Bereitschaftsmeldung Fbelt_rdy_give Bool Zuf hrband ist zur Zuf hrband bereit bergabe bereit
276. re informelle Spezifikationen Es darf kein Start erfolgen wenn der Eingangspuffer nicht belegt ist Es darf kein Start erfolgen wenn das Zuf hrband nicht bereit ist Formale Spezifikation mit dem SFS Editor gt gt gt Satz 24 lt lt lt erweiterte M glichkeit Zustand das Startsignal Kran holt Rohteil vom Eingangspuffer darf nur gesetzt sein wenn gleichzeitig der Eingangspuffer belegt ist AG rdy_plc amp Piece_at_source amp Crane_run_source gt gt gt Satz 25 lt lt lt erweiterte M glichkeit Zustand das Startsignal Kran holt Rohteil vom Eingangspuffer darf nur gesetzt sein wenn gleichzeitig die Bereitschaftsmeldung Zuf hrband ist zur Ubernahme eines Teils bereit gesetzt ist AG rdy_plc amp Fbelt_ready_take amp Crane_run_source 157 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache A 7 2 3 Kommunikation mit Zuf hrband Vor berlegung Das Zuf hrband dient dazu die Rohteile die der Kran auf dem Zuf hrband abgelegt hat auf den Hubdrehtisch zu bef rdern Das Zuf hrband kann nicht selbst ndig erkennen wenn ein Rohteil an seinem Bandanfang abgelegt wurde es ben tigt also von der Zellensteuerung ein Signal wenn es mit dem Transport des Rohteils beginnen soll Dieser Transport kann aber erst erfolgen wenn der Hubdrehtisch auch zur Aufnahme eines Teils bereit also leer und korrekt positioniert
277. reitschaftsmeldung der Produktionszelle 1 muss unmittelbar zur ckgesetzt werden und die Bereitschaftsmeldung des Transportsystems muss unmittelbar zur ckgesetzt werden AG rdy_in amp order_status 1 amp order_work 1 amp cell_l_ready amp tr_sys_ready gt Al rdy_plc U rdy_plc amp order_status 2 amp tr_kind 1 amp tr_place 1 amp cell_l_ready amp tr_sys_ready gt gt gt Satz 3 lt lt lt einfache Forderung direkt Wenn der aktuelle Stand der Auftragsbearbeitung Bearbeiten ist und die Fertigmeldung der Produktionszelle 1 ist gesetzt und die Bereitschaftsmeldung des Transportsystems gesetzt ist dann muss der aktuelle Stand der Auftragsbearbeitung unmittelbar auf Fertigteile wegbringen gesetzt werden und die Transportart muss unmittelbar auf 2 Fertigteile wegbringen gesetzt werden und die anzufahrende Produktionszelle muss unmittelbar 1 werden und die Fertigmeldung der Produktionszelle 1 muss unmittelbar zur ckgesetzt werden und die Bereitschaftsmeldung des Transportsystems muss unmittelbar zur ckgesetzt werden AG rdy_in amp order_status 3 amp cell_1I_finished amp tr_sys_ready gt Al rdy_plc U rdy_plc amp order_status 4 amp tr_kind 2 amp tr_place 1 amp cell_l_finished amp tr_sys_ready Tia Analog zu den dargestellten S tzen k nnen weitere Anforderungen definiert werden 86 Validierung des Prototype
278. ress_ready_give gt gt gt Satz 168 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Presse 12 ist dann die Zustandsvariable der Presse muss unmittelbar auf 0 gesetzt werden AG rdy_in amp Press_state 12 gt Al rdy_plc U rdy_plc amp Press_state 0 gt gt gt Satz 169 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Presse 2 ist und die Presse ist in der Mitte dann muss das Schliessen der Presse unmittelbar gestoppt werden und die Zustandsvariable der Presse muss unmittelbar auf 21 gesetzt werden und die Bereitschaftsmeldung Presse ist f r Beladung bereit muss unmittelbar gesetzt werden AG rdy_in amp Press_state 2 amp Press_middle gt A l rdy_plc U rdy_plc amp Press_upward amp Press_state 21 amp Press_ready_take gt gt gt Satz 170 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Presse 21 ist dann die Zustandsvariable der Presse muss unmittelbar auf 0 gesetzt werden 222 Anhang AG rdy_in amp Press_state 21 gt Al rdy_plc U rdy_plc amp Press_state 0 Informelle Spezifikation weiterer Daten Sicherheit Presse Bewegungsbegrenzung bei Pressenh he Kollision mit Roboterarmen muss vermieden werden Formale Spezifikation mit dem SFS Editor gt gt gt Satz 171 lt lt lt einfaches Verbot
279. rf niemals gleichzeitig sein lt PR3_for_sg gt darf nicht irgendwann lt Nomen_Wert_Paar gt werden darf niemals lt Nomen_Wert_Paar gt werden lt PRs3_back_sg gt lt Nomen_Wert_Paar gt darf nicht irgendwann werden lt Nomen_Wert_Paar gt darf niemals werden 122 Anhang A 3 Beispiele f r erzeugbare S tze Es folgt eine Aufstellung der erzeugbaren S tze auf Ebene 5 der formalen Syntax ausformulierte Satzteile Es werden S tze mit jeweils zwei konjunktiv verkn pften Bedingungen B1 und B2 bzw Folgerungen F1 und F2 dargestellt selbstverst nd lich ist die Anzahl der verwendeten Bedingungen und Folgerungen beliebig Die Darstellung erfolgt in Metatext Kategorie DEs1 einfache Forderung Zustand Wenn B1 ist und B2 ist dann muss gleichzeitig F1 sein und muss gleichzeitig F2 sein Wenn B1 ist und B2 ist dann muss gleichzeitig F1 bleiben und muss gleichzeitig F2 bleiben F1 muss gleichzeitig sein und F2 muss gleichzeitig sein wenn B1 ist und B2 ist F1 muss gleichzeitig bleiben und F2 muss gleichzeitig bleiben wenn B1 ist und B2 ist Kategorie DEs2 einfache Forderung direkt Wenn B1 ist und B2 ist dann muss unmittelbar F1 werden und muss unmittelbar F2 werden Wenn B1 ist und B2 ist dann muss sofort F1 werden und muss sofort F2 werden Wenn B1 ist und B2 ist dann wird unmittelbar F1 und wird unmittelbar F2 Wenn B1 ist und B2 ist dann wird
280. rlag Berlin 1998 Polke M Prozessleittechnik Oldenbourg Verlag GmbH M n chen 1992 Reck M Methoden und Beschreibungsmittel f r die Programm entwicklung Schriftenreihe Integrierte Datenverarbeitung in der Praxis Band 47 Forkel Verlag Wiesbaden 1991 Reinhard H Automatisierungstechnik Theoretische und ger tetechnische Grundlagen SPS Springer Verlag Berlin Heidelberg New York 1996 Reinert D Schaefer M B rner Th Regeln f r den Entwurf und die Programmierung sicherheitsbezogener Software Auto matisierungstechnische Praxis 41 1999 atp 6 99 Reisig W Systementwurf mit Netzen Springer Verlag Berlin Heidelberg New York Tokyo 1985 Riedewald G Maluszynski J Dembinski P Formale Beschrei bung von Programmiersprachen Akademie Verlag Berlin 1983 Rossi O deSmet O Couffin S Lesage J J Papini H Guen nec H Formal Verification A Tool to improve the safety of con trol systems A Symposium on Fault Detection Safety and Su pervision of Technical Processes SafeProcess 2000 pp 885 890 IFAC Budapest Hungary June 2000 Rossi O Schnoebelen P Formal Modeling of Times Function Blocks for the automatic Verification of Ladder Diagram Pro grams 4 International Conference Automation of Mixed Proc esses ADPM 2000 pp 177 182 Dortmund September 2000 Ruppen P Einstieg in die formale Logik Lang Verlag Bern
281. rlag Berlin 1989 H lzlein M Filkorn Th Warkentin P Formale Verifikation von SPS Programmen VDI VDE GMA KongreB Me und Automati sierungstechnik Baden Baden 1996 VDI Bericht Nr 1282 1996 H lzlein M Filkorn Th Warkentin P Wei M Erfahrungen mit der formalen Verifikation von Zustandsgraphen Programmen GMA Kongress Ludwigsburg 18 19 06 1998 VDI Berichte 1397 1998 H lzlein M Filkorn Th Warkentin P Wei M Eine Verifika tionskomponente f r HiGraph GMA Kongress Ludwigsburg 18 19 06 1998 VDI Berichte Nr 1397 1998 Horebeek I v Lewi J Algebraic specifications in software engi neering an introduction Springer Berlin Heidelberg 1989 Huber E Burgbacher G Biegert U Billmann W Qualitative Systemanalyse und computerunterst tzte Gefahrenidentifikation HAZOP Wiley VCH Chemie Ingenieur Technik 7 1997 DIN IEC 61131 3 IEC 1131 3 Speicherprogrammierbare Steu erungen Teil 3 Programmiersprachen 1993 IEC 61508 Functional Safety of Electrical Electronic Program mable Electronic Safety Related Systems 2000 J rns C Spezifikation und Verifikation hierarchischer Steuerun gen VDI VDE GMA KongreB Me und Automatisierungstechnik Baden Baden 1996 VDI Bericht Nr 1282 1996 Kaspers W K fner H J Heinrich B Vogt W Steuern Regeln Automatisieren Vieweg Fachb cher der Technik 1994 Kohring A
282. rt werden werden lt Nomen gt wird nur unmittelbar lt Nomen_Wert_Paar gt wird nur lt Wert gt unmittelbar lt Nomen gt wird nur sofort lt Wert gt lt Nomen_Wert_Paar gt wird nur sofort lt Nomen gt muss irgendwann EN muss irgendwann lt Nomen_Wert_Paar gt Mertz werden werden DI muss lt Nomen gt irgendwann Mertz werden 135 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache muss irgendwann lt Nomen gt Mertz werden lt Nomen gt wird irgendwann lt Wert gt wird lt Nomen gt irgendwann gt wird irgendwann lt Nomen_Wert_Paar gt lt Wert gt wird irgendwann lt Nomen gt Mertz lt Nomen gt muss irgendwann lt Nomen_Wert_Paar gt muss irgendwann Mertz werden werden lt Nomen gt wird irgendwann lt Wert gt lt Nomen_Wert_Paar gt wird irgendwann lt Nomen gt muss nur irgendwann en lt Nomen_Wert_Paar gt muss nur lt Wert gt werden irgendwann werden lt Nomen gt wird nur irgendwann Er lt Nomen_Wert_Paar gt wird nur lt Wert gt irgendwann lt Nomen gt kann nur lt Wert gt sein lt Nomen_Wert_Paar gt kann nur sein lt Nomen gt darf nur lt Wert gt sein lt Nomen_Wert_Paar gt darf nur
283. rung direkt Wenn die Zustandsvariable der Hubtischdrehung 2 ist und der Hubdrehtisch ist vor dem Zuf hrband dann muss die Rechtsdrehung des Hubdrehtischs unmittelbar gestoppt werden und die Zustandsvariable der Hubtischdrehung muss unmittelbar auf 21 gesetzt werden AG rdy_in amp Table_statel 2 amp Table_angle 0 gt Al rdy_plc U rdy_plc amp Table_right amp Table_statel 21 gt gt gt Satz 113 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Hubtischh he 21 ist und die Zustandsvariable der Hubtischdrehung ist 21 dann muss die Bereitschaftsmeldung Hubdrehtisch ist zur bernahme eines Teils bereit unmittelbar gesetzt werden und die Zustandsvariable der Hubtischh he muss unmittelbar auf 22 gesetzt werden und die Zustandsvariable der Hubtischdrehung muss unmittelbar auf 22 gesetzt werden AG rdy_in amp Table_state2 21 amp Table_statel 21 gt Al rdy_plc U rdy_plc amp Table_ready_take amp Table_state2 22 amp Table_statel 22 202 Anhang gt gt gt Satz 114 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Hubtischh he 22 ist und die Zustandsvariable der Hubtischdrehung ist 22 dann die Zustandsvariable der Hubtischh he muss unmittelbar auf 0 gesetzt werden und die Zustandsvariable der Hubtischdrehung muss unmittelbar auf 0 gesetzt werden
284. rungen die das Programm erf llen soll Aus der externen Spezifikation versucht man eine interne formale Spezifikation abzuleiten Diese enth lt die formale Definition der Aufgaben des Programms vgl auch Lastenheft Pflichtenheft Zur Erstellung einer Spezifikation werden Beschreibungsmittel engl means of description representation verwendet Diese dienen zur Beschreibung und Dar stellung der Struktur und oder des Verhaltens eines Systems und stellen bestimmte Sachverhalte in grafischer Form zur visuellen Wahrnehmung und Speicherung dar z B durch alphanumerische Zeichen Symbole Diagramme oder sonstige grafische Darstellungselemente Je nach Definitionsgrad erfolgt eine Unterscheidung in infor male semi formale oder formale Beschreibungsmittel Formale Beschreibungsmittel haben eine mathematische Basis und eine definierte vollstandige Syntax semi for male Beschreibungsmittel besitzen zwar eine definierte vollstandige Syntax aber keine mathematische Basis Informale Beschreibungsmittel haben grunds tzlich keine vollst ndige Auspr gung dieser Merkmale Chou98b Formale Spezifikationstechniken zeichnen sich dadurch aus dass mathematische Methoden zur Absch tzung wesentlicher Eigenschaften der zu beschreibenden Systeme anwendbar sind Kr c90 F r verschiedene Arten von Systemen haben sich Spezifikationstechniken entwickelt die auf die jeweilige Problemstellung zuge schnitten sind Einfache Beispiele hierf r sind elektrische Sc
285. s ist 50 der Roboter ist vor der Presse UpM Start oder Ende einer Aktion Ubergang in einen neuen Zustand y_1 TRUE z_1 TRUE die Presse wird geschlossen der Zustand 1 der Presse wird der Magnet wird aktiviert gesetzt in einer Folgerung bergang in einen neuen Zustand Ver nderung einer Aktion dann y_2 50 die Drehzahl des Motors wird auf 50 UpM gesetzt z 2 50 der Merker wird auf 50 gesetzt Integer Abbildung 23 M glichkeiten zur Erstellung der Verbalphrasen Eine letzte Anmerkung soll den grammatikalischen M glichkeiten der Sicherheits fachsprache gelten Bei Anforderungen deren Bedingungs bzw Folgerungsteil mehrere konjunktiv verkn pfte Teilbedingungen bzw Teilfolgerungen enth lt kann gem den Gegebenheiten der deutschen Umgangssprache eine Umstellung der Satzglieder erfolgen Wenn die Variable 1 ist gesetzt und die Variable 2 ist gesetzt dann Wenn die Variable 1 gesetzt ist und die Variable 2 ist gesetzt dann Wenn die Variable 1 gesetzt ist und die Variable 2 gesetzt ist dann Im vorliegenden Fall wurde die Reihenfolge des Hilfsverbs ist und des Wertes ge setzt vertauscht um die geforderte Wortreihenfolge einzuhalten Die Sicherheits fachsprache ist auf solche grammatika
286. s Roboters 26 ist dann die Zustandsvariable des Roboters muss unmittelbar auf 0 gesetzt werden AG rdy_in amp Robot_state 26 gt Al rdy_plc U rdy_plc amp Robot_state 0 gt gt gt Satz 135 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 3 ist und der Roboter ist mit dem Arm 1 vor dem Hubdrehtisch dann muss die Drehung des Roboters nach rechts unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 31 gesetzt werden und das Ausfahren des Roboterarms I muss unmittelbar gestartet werden AG rdy_in amp Robot_state 3 amp Robot_angle 50 gt Al rdy_plc U rdy_plc amp Robot_right amp Robot_state 3l amp Arml_forward gt gt gt Satz 136 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 31 ist und der Roboterarm 1 ist am Hubdrehtisch dann muss das Ausfahren des Roboterarms 1 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 32 gesetzt werden und der Magnetgreifer des Roboterarms 1 muss unmittelbar 213 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache aktiviert werden und das Einziehen des Roboterarms 1 muss unmittelbar gestartet werden AG rdy_in amp Robot_state 31 amp Arml_ext 0 52 gt Al rdy_plc U rdy_plc amp Arml_forward amp Robot_state
287. schnell ndernder Anforderungen anzupassen m ssen neue Methoden und Werkzeuge f r den Softwareentwurf bereitgestellt werden Einige der Anforderungen an zuk nftige Methoden und Werkzeuge sind in Litz99 dargestellt sie m ssen durchg ngig in allen Phasen des Entwicklungsprozesses einsetz bar sein sie m ssen die Entwicklung hybrider technischer Systeme kontinuierlich dis kret sowie die Erstellung verteilter Realisierungen unterst tzen ein flexibler Simulationsteil muss den Test der Software bereits in fr hen Pha sen erm glichen die Software muss in genormten Darstellungen z B nach DIN EN 61131 3 erstellt werden eine automatische Codeerzeugung sowie die Analyse und Verifikation der Software soll m glich sein Die formale Spezifikation dient der eindeutigen Festlegung von Anforderungen an das Gesamtsystem Lewe97 Sie wird aus einer informellen Spezifikation die zu n chst nur gedanklich existiert abgeleitet Von der berf hrung in die formale Spe zifikation werden folgende Ergebnisse erwartet die einengende Notation die die Beschreibung der Anforderungen erschwert soll zu einer gr eren Eindeutigkeit zwingen Inkonsistenzen der informellen Spezifikation sollen beim Formulierungsver such explizit werden Zwang zu einem einfacheren Entwurf da nur von einfachen Entw rfen wich tige Eigenschaften formal bewiesen werden k nnen Fokussierung der Aufmerksamkeit der Entwerfer auf die durch die Formalis
288. se gelegt muss unmittelbar gesetzt werden AG rdy_in amp Robot_state 15 amp Arml_ext 0 0 gt Al rdy_plc U rdy_plc amp Arml_backward amp Robot_state 16 amp Robot_done_load gt gt gt Satz 127 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 16 ist dann die Zustandsvariable des Roboters muss unmittelbar auf 0 gesetzt werden AG rdy_in amp Robot_state 16 gt Al rdy_plc U rdy_plc amp Robot_state 0 211 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache gt gt gt Satz 128 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 2 ist und der Roboter ist mit dem Arm 2 vor der Presse dann muss die Drehung des Roboters nach rechts unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 21 gesetzt werden und das Ausfahren des Roboterarms 2 muss unmittelbar gestartet werden AG rdy_in amp Robot_state 2 amp Robot_angle 0 gt Al rdy_plc U rdy_plc amp Robot_right amp Robot_state 21 amp Arm2_forward gt gt gt Satz 129 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 21 ist und der Roboterarm 2 ist in der Presse dann muss das Ausfahren des Roboterarms 2 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar a
289. senken des Krangreifers darf nicht gleichzeitig gestartet sein wenn der Kran am Ablageband ist und der Greifer des Krans auf dem Ablageband ist AG rdy_plc amp Crane_at_dbelt amp Crane_height 0 66 amp Crane_lower gt gt gt Satz 91 lt lt lt einfaches Verbot Zustand das Absenken des Krangreifers darf nicht gleichzeitig gestartet sein wenn der Kran am Eingangspuffer ist und der Greifer des Krans auf dem Eingangspuffer ist AG rdy_plc amp Crane_at_source amp Crane_height 0 85 amp Crane_lower gt gt gt Satz 92 lt lt lt einfaches Verbot Zustand das Absenken des Krangreifers darf nicht gleichzeitig gestartet sein wenn der Kran am Ausgangspuffer ist und der Greifer des Krans auf dem Ausgangspuffer ist AG rdy_plce amp Crane_at_drain amp Crane_height 0 35 amp Crane_lower 93 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache gt gt gt Satz 93 lt lt lt einfaches Verbot Zustand das Absenken des Krangreifers darf nicht gleichzeitig gestartet sein wenn der Kran am Zuftihrband ist und der Greifer des Krans auf dem Zufiihrband ist AG rdy_plce amp Crane_at_fbelt amp Crane_height 0 94 amp Crane_lower gt gt gt Satz 94 lt lt lt einfaches Verbot selbstbegrenzt IT It Solange der Magnet des Krangreifers aktiv is
290. spezifiziert bleiben Auftragsverwaltung TE Produktions zelle 1 Abbildung 24 Schema der Erweiterten Produktionszelle 77 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Mit Hilfe der verschiedenen Produktionszellen ist es m glich unterschiedliche Bear beitungsauftr ge auszuf hren Durch die zentrale Auftragsverwaltung erfolgen die Koordinierung der einzelnen Bearbeitungsauftr ge und die Steuerung des Transport systems Dieses holt Rohteile aus dem Rohteillager und bringt diese zu der ge w nschten Produktionszelle Zur bergabe der Werkst cke besitzt jede Produktions zelle jeweils einen Eingangspuffer E und einen Ausgangspuffer A Nach Ferti gungsabschluss werden die bearbeiteten Teile wieder durch das Transportsystem abgeholt und zum Fertigteillager gebracht 5 1 2 Das Transportsystem Das Transportsystem nimmt in der erweiterten Produktionszelle eine zentrale Rolle ein Es dient dazu die einzelnen Produktionszellen mit Rohteilen zu versorgen und nach Beendigung des Bearbeitungsprozesses die Fertigteile wieder abzuholen Die technische Realisierung soll innerhalb dieser Fallstudie jedoch nicht weiter ausge f hrt werden denkbar w re jedoch ein automatisch und autonom arbeitendes und frei bewegliches Transportsystem Dazu erh lt es Vorgaben aus der bergeordneten zentralen Auftragsverwaltung 5 1 3 Die Materiallager Innerhalb der Produktionsanlage gibt es zwei unen
291. ssicherung von Steuerungssoftware Ein wesentlicher Problempunkt hierbei ist die vollst ndige und korrekte Beschreibung der zu l senden Steuerungsaufgabe Heute existieren eine Vielzahl unterschiedlicher teilweise auch genormter Darstellungsformen jedoch gibt es kein einheitliches und vor allem kein durchg ngiges Werkzeug f r die Beschreibung der gew nschten Steuerungsfunktionen Je nach Anwendungsgebiet Anwenderkenntnissen und Problemstellung sind die verschiedenen Darstellungsfor men so speziell dass sie nur f r Fachleute zu handhaben sind Der Entwurf einer solchen Sprache muss sich an den Bed rfnissen der Anwender orientieren Mit der in dieser Arbeit vorgestellten Sicherheitsfachsprache SFS ist eine allge meinverst ndliche und eindeutige Formulierung von Steuerungsaufgaben m glich Durch ihre N he zur nat rlichen Sprache wird sie ihren grundlegenden Zielstellungen gerecht eine fach bergreifende Kommunikation zwischen den verschiedenen Betei ligten eines Projektes sowie eine ebenen bergreifende Kommunikation in den ver schiedenen Ebenen einer Steuerungsstruktur Als drittes herausragendes Merkmal bietet die Sicherheitsfachsprache die M glichkeit unerw nschte und verbotene Situ ationen des Steuerungssystems zu beschreiben Somit ist ein weites Anwendungs feld in vielen Problembereichen gegeben Trotz allem ist die Sicherheitsfachsprache formal genug um eine eindeutige Problemdarstellung zu gew hrleisten Innerhalb dies
292. st yl muss gleichzeitig True sein und y2 muss gleichzeitig True sein wenn X1 True ist und x2 True ist yl muss gleichzeitig True sein und y2 muss gleichzeitig True sein wenn 138 Anhang xl True ist und x2 ist True F1 muss gleichzeitig bleiben und F2 muss gleichzeitig bleiben wenn B1 ist und B2 ist yl muss gleichzeitig True bleiben und y2 muss gleichzeitig True bleiben wenn xl True ist und x2 True ist yl muss gleichzeitig True bleiben und y2 muss gleichzeitig True bleiben wenn xl True ist und x2 ist True 139 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache A 7 Fallstudie Erweiterte Produktionszelle A 7 1 Spezifikation der Ger teebene 1 Auftragsverwaltung Gegebene Daten nur Idee Produktionsauftrag Informelle Spezifikation es sollen Produktionsauftr ge bearbeitet werden Definition neuer Daten mit dem SFS Editor Datenebene 1 Produktionsauftrag Technische i Variable Datentyp Kommentar Bezeichnung Auftragsnummer order_number Integer laufende Nummer des Auf trags Bearbeitungsart order_work Integer wie sollen diese Teile bear beitet werden Teileanzahl order _quantity Integer wie vie
293. st rkten ebenen bergreifenden Einsatz von Netzwerken und Bussystemen immer weiter reduziert werden Moderne Systeme erm glichen sogar die Durchg ngigkeit eines einzelnen Bussystems z B Ethernet durch den gesam ten Betrieb Bezogen auf ihre Arbeitsinhalte und Aufgaben lassen sich zwischen diesen Ebenen gro e Unterschiede feststellen w hrend in den oberen Ebenen den Leitebenen dispositive Aufgaben im Vordergrund stehen gehen diese in den unteren Ebenen zu operativen Aufgaben ber Bei der Analyse der Aufgabenstellungen und der dabei verwendeten Informationen werden zwei grunds tzliche Fakten deutlich von oben 31 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache nach unten erfolgt eine Pr zisierung und Verfeinerung der Aufgaben w hrend in der Gegenrichtung eine zielgerichtete Verdichtung der zugeh rigen Informationen statt findet In der Feldebene befinden sich die Mess und Stelleinrichtungen Diese liefern Pro zesssignale Prim rdaten zur Verarbeitung an die Prozessleit Steuerungsebene und erh lt von dieser Stellbefehle zum Eingriff in den Prozess In der Feldebene fin den die Erfassung und Beeinflussung der Prozessgr en und eine Signalaufberei tung statt Die Prozessleit bzw Steuerungsebene hat bereits leittechnische Funktionen sie dient zum F hren von einzelnen Verfahrensgruppen oder Apparaten Hier erfolgen die Umsetzung der Produktionsauftr ge in verfahrenstechnische Realisierun
294. stand folgt wird im unmittelbar nachfolgenden Zustand g ltig werden AX o ist in allen unmittelbar nachfolgenden Zust nden g ltig EF o in mindestens einem Pfad der dem aktuellen Zustand folgt wird ir gendwann g ltig werden AF o in allen Pfaden die dem aktuellen Zustand folgen wird irgendwann g ltig werden EG in mindestens einem Pfad der dem aktuellen Zustand folgt wird o im mer g ltig sein AG o ist in allen nachfolgenden Zust nden g ltig E 91 U 2 in mindestens einem Pfad der dem aktuellen Zustand folgt gilt 91 so lange bis 9 gilt A 91 U 2 oe Pfaden die dem aktuellen Zustand folgen gilt om solange bis 2 gilt F r CTL Formeln gelten alle Aquivalenzen der Aussagenlogik Mann95 Dwye98 EX AX 9 AX EX EFQ AG AFQ EG EG AF 9 AG EF9 EF E TRUE U ol AF A TRUE U 9 Elo U 2 2 v 91 AEX Elo U ol Alp U ol G2 v 1 A AX Am U ga 53 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Die oben dargestellten Umwandlungsoperationen erlangen im Zusammenhang mit einer nat rlichsprachlichen bersetzung dieser Gleichungen eine besondere Be deutung So kann die Gleichung EF AG 9 auch folgenderma en interpretiert werden Wenn in mindestens einem Pfad der dem aktuellen Zustand folgt ir gendwann g ltig wird dann ist es nicht wahr dass in allen nachfolgen den Zust nden ung ltig ist
295. standes Der Abschluss eines einzelnen Abschnittes ist am kurzzeitigen TRUE Zustand der entsprechenden Beobachtungsvariablen zu erkennen f r die restliche Zeit stehen diese Variablen immer auf FALSE F r die Umsetzung der Anforderungen in die CTL Formeln gelten folgende generelle Bedingungen Die aufgestellten Anforderungen gelten immer f r den gesamten Erreichbar keitsraum des Systems Diesem Umstand muss durch die Benutzung der CTL Operatoren AG generell gilt in allen nachfolgenden Zust nden Rech nung getragen werden Wenn der G ltigkeitsbereich einer Anforderung nur f r bestimmte Abschnitte Sequenzen gelten soll so ist dieser Bereich durch die aufgestellten Bedingungen bzw das Beobachtungsintervall zu beschr nken Alle Anforderungen die sich auf die korrekte Ausf hrung des SPS Programms beziehen m ssen mit den eingef hrten Beobachtungsvariablen verkn pft werden Viele Analysen sind erst dann sinnvoll durchf hrbar wenn die Bear beitung des SPS Zyklus abgeschlossen ist erkennbar durch rdy_plc TRUE Die k rzeste Reaktionszeit einer realen SPS ist von ihrer Zykluszeit und der zeitlichen Abfolge ihrer Betriebssystemroutinen abh ngig vergleiche Abbildung 8 und Abbildung 10 Die schnellste Reaktion einer SPS ist somit dann gegeben wenn ein relevantes Ereignis im Moment des Einlesens der Sensorsignale eintritt rdy_in und dieses Ereignis unmittelbar anschlie end im Steuerungsprogramm verarbeitet wird r
296. stgelegten Reihenfolge abzuarbeiten es bietet sich die Entwicklung einer Ablaufstruktur an Definition neuer Daten mit dem SFS Editor Interne Variable der Steuerung des Roboters Technische Bezeichnung SPS Variable Datentyp Kommentar Zustandsvariable des Roboters Robot_state Integer Tabelle 36 Datenebene 4 Interne Variable der Steuerung des Roboters 95 INT VAR Robot_state die Zustandsvariable des Roboters Or T D wou EE EE Do oe ZN E ay te D m7 q EE 3 EZ IS 1 q1 A D UN 4 Hu MSN 156 E r MAGN AoT o TA 24 E o MQM eet EAA 24 ae e man 25 H Sp Es 26 SL E vss KH S25 32 33h AN BS 3a E 35 2 2 135 Sp Ar 36 el e RE 207 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache 38 E e SB SE N39 40_I 40 41_I 41 42_I 42 e 72 143 O_O auf 0 gesetzt 10 auf 1 gesetzt 2 0 auf 2 gesetzt 3 0 auf 3 gesetzt 11_O auf 11 gesetzt 12_0 auf 12 gesetzt 13_0 auf 13 gesetzt 14_O auf 14 gesetzt 15_O auf 15 gesetzt 16_0 auf 16 gesetzt 21_0 auf 21 gesetzt 22 0 auf 22 gesetzt 23 0 auf 23 gesetzt 24_0 auf 24 gesetzt 25 20 auf 25 gesetzt 26_0 auf 26 gesetzt 31_0 auf 31 gesetzt 32_0 auf 32 gesetzt 33 0 auf 33 gesetzt 34_0
297. svariable des Ablagebands muss unmittelbar auf 2 gesetzt werden und die Bereitschaftsmeldung Ablageband ist zur bergabe eines Teils bereit muss unmittelbar gesetzt werden und die Bereitschaftsmeldung Ablageband ist zur bernahme eines Teils bereit muss unmittelbar gesetzt werden AG rdy_in amp Dbelt_state 1 amp LB_at_dbelt gt Al rdy_plc U rdy_plc amp DBelt_start amp Dbelt_state 2 amp Dbelt_ready_give amp Dbelt_ready_take gt gt gt Satz 177 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Ablagebands 2 ist dann die Zustandsvariable des Ablagebands muss unmittelbar auf 0 gesetzt werden AG rdy_in amp Dbelt_state 2 gt Al rdy_plc U rdy_plc amp Dbelt_state 0 Informelle Spezifikation weiterer Anforderungen Sicherheit Ablageband Bewegungsbeschr nkung am Bandende Formale Spezifikation mit dem SFS Editor gt gt gt Satz 178 lt lt lt einfaches Verbot Zustand Wenn die Lichtschranke am Ende des Ablagebands blockiert ist dann darf der Antrieb des Ablagebands niemals gleichzeitig gestartet sein AG rdy_plc amp LB_at_dbelt amp DBelt_start 226
298. t FALSE_O gestoppt 90 BOOL VAR Arm2_backward das Einziehen des Roboterarms 2 TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gestartet FALSE_O gestoppt 91 BOOL VAR Arml_mag_on der Magnetgreifer des Roboterarms 1 TRUE_I aktiv FALSE_I nicht aktiv TRUE_O aktiviert FALSE_O deaktiviert 92 BOOL VAR Arm2_mag_on der Magnetgreifer des Roboterarms 2 TRUE_I aktiv FALSE_I nicht aktiv TRUE_O aktiviert FALSE_O deaktiviert 93 BOOL VAR Robot_left die Drehung des Roboters nach links TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gestartet FALSE_O gestoppt 394 BOOL VAR Robot_right die Drehung des Roboters nach rechts 206 Anhang TRUE_I aktiv FALSE_I nicht aktiv TRUE_O gestartet FALSE_O gestoppt Informelle Spezifikation Die Steuerung des Roboters verbleibt solange in Ruhe bis durch die Zellensteue rung entweder das Startsignal zur ausschlie lichen Beladung der Presse zur aus schlie lichen Entladung der Presse oder zur koordinierten Be und Entladung der Presse erfolgt Danach wird die geforderte Transportroutine bearbeitet Es sind drei separate Transportvorg nge zu unterscheiden die alternativ voneinander ablaufen k nnen Die innerhalb dieser Routinen abzuarbeitenden Teilvorg nge sind unbedingt in der fe
299. t oben dann muss das Anheben des Krangreifers unmittelbar gestoppt werden und die Fertigmeldung Kran hat eine Rohteil auf das Zufiihrband gelegt muss unmittelbar gesetzt werden und die Zustandsvariable des Krans muss unmittelbar 13 werden und die Bewegung des Krans nach links zum Zufiihrband muss unmittelbar gestartet werden AG rdy_in amp Crane_state 12 amp Crane_height 0 gt Al rdy_plc U rdy_plc amp Crane_lift amp Crane_done_give_fbelt amp Crane_state 13 amp Crane_to_fbelt gt gt gt Satz 77 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 13 ist und der Kran ist am Zuf hrband dann muss die Bewegung des Krans nach links zum Zuf hrband unmittelbar gestoppt werden und die Zustandsvariable des Krans muss unmittelbar 14 werden und das Absenken des Krangreifers muss unmittelbar gestartet werden AG rdy_in amp Crane_state 13 amp Crane_at_fbelt gt Al rdy_plc U rdy_plc amp Crane_to_fbelt amp Crane_state 14 amp 188 Anhang Crane_lower gt gt gt Satz 78 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 14 ist und der Greifer des Krans ist auf dem Zuf hrband dann muss das Absenken des Krangreifers unmittelbar gestoppt werden und die Zustandsvariable des Krans muss unmittelbar 15 werden und der Magnet des Krangreifers muss unm
300. t Sobald es einen Zustand gibt in dem rdy_in und eine Bedingung B erf llt werden muss es danach einen Zustand geben in dem sowohl rdy_plc die Bedingung B und eine Folgerung F erf llt werden bevor die ausl sende Bedingung B wieder ung ltig wird Zus tzlich darf in allen Zust nden in denen zwar rdy_plc je doch nicht die Bedingung B erf llt wird die Folgerung F auch nicht erf llt sein Diese Kategorie l sst sich wiederum durch Verkn pfung zweier anderer Kategorien n m lich DEs3 und POe3 erstellen AG fo 1 gt A n 0 U Fa AF n 1 a AIC U r 1 v AG C a AG n 1 gt A CU m 1 v AG OH mit C rdy_plc a B a AF Ergebnis der Ubersetzung der mit der Sicherheitsfachsprache formulierten Anforde rungen ist eine Menge temporallogischer Formeln Die atomaren Pr positionen die ser Formeln korrespondieren mit Variablen des Systemmodells also letztendlich auch wiederum mit den Eintragen im Variablendeklarationsteil des SPS Programms 62 Prototypische Realisierung und Einsatz der Sicherheitsfachsprache 4 Prototypische Realisierung und Einsatz der Sicherheitsfach sprache In den vorherigen Abschnitten wurde deutlich gemacht welche typischen steue rungstechnischen Problemstellungen es gibt und wie diese mit der Sicherheitsfach sprache dargestellt werden k nnen In diesem Abschnitt wird nun dargelegt auf wel che Art und Weise und mit welchen Hilfsmitteln diese Anforderungen niedergeschrie ben und in temporallogis
301. t bei der L sung von Entwicklungsaufgaben wurden Vorgehensmodelle auch Phasenmodelle entwickelt Diese sollen eine Strukturie rung und somit eine Vereinfachung der Aufgabenstellung in einzelne Teilaufgaben und Entwicklungsabschnitte erm glichen Ausgehend von diesem Hauptziel lassen sich weitere Teilziele formulieren Unterst tzung des Projektmanagements durch Segmentierung des gesamten Lebenszyklusses in kleinere Entwicklungsschritte 14 Einleitung und Ausgangssituation Vorgabe eines ablauforganisatorischen Rahmens mit Festlegung von Schnitt stellen zwischen den einzelnen Projektphasen Definition exakter Ziele in den einzelnen Projektphasen Unterst tzung der Kommunikation durch Pr fungen und bergabe der Ergeb nisse von einer Projektphase in die folgende Beispiele f r gebr uchliche Vorgehensmodelle sind siehe DGQ98 und Balz98 Code and Fix Programmiere und Repariere Modell sequentielles Modell Stagewise Model Schleifen Wasserfallmodell Prototyping Modell Sichtenmodell Spiralmodell V Modell u a Allen Modellen gemeinsam ist die Unterteilung des Projektes in einzelne Phasen Die Aufgabe wird jedoch nicht nur zeitlich zerlegt es erfolgt auch eine Gliederung in ein zelne Teilbereiche des Produktes so dass man von einer vertikalen und einer hori zontalen Projektorganisation sprechen kann Dabei l sst sich bei den einzelnen Mo dellansatzen sogar eine weitgehende Ubereinstimmung in der Gliederu
302. t dem SFS Editor gt gt gt Satz 16 lt lt lt einfache Forderung direkt Wenn der Not Aus Taster gedr ckt ist dann muss unmittelbar das Not Aus Signal f r das Ablageband gesetzt werden und das Not Aus Signal f r das Zuf hrband muss unmittelbar gesetzt werden und das Not Aus Signal f r den Hubdrehtisch muss unmittelbar gesetzt werden und das Not Aus Signal f r den Kran muss unmittelbar gesetzt werden und das Not Aus Signal f r den Roboter muss unmittelbar gesetzt werden und das Not Aus Signal f r die Presse muss unmittelbar gesetzt werden rdy_plc U rdy_plc amp amp Em_stopp_table amp amp Em_stopp_press Em_stopp_dbelt amp Em_stopp_fbelt AG rdy_in amp Em_stopp gt Al Em_stopp_crane amp Em_stopp_robot gt gt gt Satz 17 lt lt lt einfache Forderung Zustand Wenn der Not Aus Taster gedr ckt ist dann muss gleichzeitig das Not Aus Signal f r das Ablageband gesetzt sein und das Not Aus Signal f r das Zufiihrband muss gleichzeitig gesetzt sein und das Not Aus Signal f r den Hubdrehtisch muss gleichzeitig zur ckgesetzt sein und das Not Aus Signal f r den Kran muss gleichzeitig gesetzt sein und das Not Aus Signal f r den Roboter muss gleichzeitig gesetzt sein und das Not Aus Signal f r die Presse muss gleichzeitig gesetzt sein AG rdy_plc amp Em_stopp gt Em_stopp_dbelt amp Em_sto
303. t und der Kran ist nicht am Ablageband und der Kran ist nicht am Zuftihrband und der Kran ist nicht am Eingangspuffer und der Kran ist nicht am Ausgangspuffer darf der Magnet des Krangreifers niemals deaktiviert werden AG rdy_plc amp Crane_mag_on amp Crane_at_dbelt Crane_at_fbelt amp Crane_at_source amp Crane_at Crane_mag_on Die Fallstudie w rde an dieser Stelle mit der Spezifikation der anderen Teilger te Zuf hrband Hubdrehtisch usw fortfahren Diese Spezifikationen unterscheiden sich jedoch nicht grunds tzlich sondern nur in speziellen Details von der Spezi fikation des Krans Aus diesem Grund wird an dieser Stelle auf diese Darstellung verzichtet die Details k nnen dem Anhang entnommen werden 5 3 4 Definition weiterer Eigenschaften Neben der Betrachtung der Einzelsteuerungen hinsichtlich der Einhaltung von Si cherheitsanforderungen m ssen auch bergeordnete Zusammenh nge zwischen den einzelnen Komponenten betrachtet werden Im Abschnitt 5 3 2 wurden bereits einige Anforderungen im Zusammenhang mit der Sicherung der korrekten bergabe der Werkst cke zwischen den einzelnen Zellenelementen formuliert Auch in der urspr nglichen Fallstudie wurden bereits einige Sicherheitsaspekte be nannt die vom Steuerungsprogramm unbedingt einzuhalten sind Diese wurden vier Prinzipien zusammengefasst 1 Begrenzung der Maschinenbeweglichkeit z B Vermeidung der Besch di g
304. t werden Demnach ist es au erordentlich wichtig besonders sorgf ltig und m glichst umfassend bei der Erstellung von Sicherheitseigenschaften vorzugehen Erkannte Fehler und Gefahrensituationen ausl sende Bedingungen d rfen nach ei 74 Prototypische Realisierung und Einsatz der Sicherheitsfachsprache ner berarbeitung des Programms nicht ein zweites Mal auftreten Aus diesem Grund ist es sinnvoll mit geeigneten Verfahren und Methoden das betrachtete Sys tem zielgerichtet zu analysieren um eventuelle Risiken aufzudecken In diesem Abschnitt werden einige Verfahren gezeigt mit deren Hilfe es m glich ist denkbare St rungen und Risiken sowie die zu dem unerw nschten Ereignis f hren den Ursachen zu identifizieren Die Vielzahl der derzeit verf gbaren Verfahren l sst sich je nach Herangehensweise an das Problem in induktive und deduktive Verfah ren unterteilen Bei den induktiven Verfahren werden ausgehend vom Ausfall eines Elementes oder dem Eintreten einer bestimmten Bedingung die Ereignisse ermittelt die dieser Aus fall bzw diese Bedingung hervorrufen kann Beispiele hierf r sind Vorl ufige Gefahrenquellenanalyse engl preliminary hazard analysis PHA Ausfall und Wirkungsanalyse engl failure mode and effect analysis FMEA nach DIN 25448 Ereignis St rablauf analyse engl event tree analysis ETA nach DIN 25419 Bei den deduktiven Verfahren wird der umgekehrte Weg gegangen ausgehend von dem zu v
305. tand Wenn B1 ist und B2 ist dann darf nicht gleichzeitig F1 sein und darf nicht gleichzeitig F2 sein Wenn B1 ist und B2 ist dann darf niemals gleichzeitig F1 sein und darf niemals gleichzeitig F2 sein F1 darf nicht gleichzeitig sein und F2 darf nicht gleichzeitig sein wenn B1 ist und B2 ist F1 darf niemals gleichzeitig sein und F2 darf niemals gleichzeitig sein wenn B1 ist und B2 ist Kategorie PRs3 einfaches Verbot selbstbegrenzt Solange B1 ist und B2 ist darf nicht irgendwann F1 werden und darf nicht irgendwann F2 werden Solange B1 ist und B2 ist darf niemals F1 werden und darf niemals F2 werden F1 darf nicht irgendwann werden und F2 darf nicht irgendwann werden solange B1 ist und B2 ist F1 darf niemals werden und F2 darf niemals werden solange B1 ist und B2 ist Kategorie PRs4 einfaches Verbot fremdbegrenzt Wenn irgendwann B1 war und B2 war dann darf nicht irgendwann F1 werden und darf nicht irgendwann F2 werden bis B3 ist und B4 ist Wenn irgendwann B1 war und B2 war dann darf niemals F1 werden und darf niemals F2 werden bis B3 ist und B4 ist Nachdem B1 war und B2 war darf nicht irgendwann F1 werden und darf nicht irgendwann F2 werden bis B3 ist und B4 ist 127 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Nachdem B1 war und B2 war darf niemals F1 werden und darf niemals F2 werden bis B3 ist und B4 ist Kateg
306. tar Startsignal Ablageband Dbelt_run Bool transportiert Teil zum Kran Meldung Ablageband f r Dbelt_rdy_give Bool bergabe eines Fertigteils bereit Tabelle 23 Datenebene 3 Variablen zur Kommunikation mit dem Ablageband 57 BOOL VAR_GLOBAL Dbelt_run das Startsignal Ablageband soll Teil transportieren TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 58 BOOL VAR_GLOBAL Dbelt_rdy_give die Bereitschaftsmeldung Ablageband ist zur Ubergab ines Teils bereit TRUE_I gesetzt 174 Anhang FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt Formale Spezifikation mit dem SFS Editor Ablageband gt gt gt Satz 56 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Automatikbetrieb ist und die Fertigmeldung Roboter hat Teil auf Ablageband gelegt ist gesetzt und die Fertigmeldung Kran hat Fertigteil vom Ablageband genommen ist gesetzt dann muss die Fertigmeldung Roboter hat Teil auf Ablageband gelegt unmittelbar zur ckgesetzt werden und die Fertigmeldung Kran hat Fertigteil vom Ablageband genommen muss unmittelbar zur ckgesetzt werden und das Startsignal Ablageband soll Teil transportieren muss unmittelbar gesetzt werden AG rdy_in amp cell_l_state 1
307. telbar muss unmittelbar lt Nomen_Wert_Paar gt Mertz werden werden muss unmittelbar lt Nomen gt Mertz werden lt Nomen gt muss sofort lt Wert gt werden muss lt Nomen gt sofort lt Wert gt Er muss sofort lt Nomen_Wert_Paar gt werden werden muss sofort lt Nomen gt lt Wert gt werden lt Nomen gt wird unmittelbar lt Wert gt wird lt Nomen gt unmittelbar gt wird unmittelbar lt Nomen_Wert_Paar gt lt Wert gt wird unmittelbar lt Nomen gt lt Wert gt lt Nomen gt wird sofort lt Wert gt wird lt Nomen gt sofort lt Wert gt wird sofort lt Nomen_Wert_Paar gt wird sofort lt Nomen gt lt Wert gt lt Nomen gt muss unmittelbar lt Nomen_Wert_Paar gt muss unmittelbar 66 gt 66 lt Wert gt werden werden lt Nomen gt muss sofort lt Wert gt Ges lt Nomen_Wert_Paar gt muss sofort werden werden lt Nomen gt wird unmittelbar Mertz lt Nomen_Wert_Paar gt wird unmittelbar lt Nomen gt wird sofort lt Wert gt gt lt Nomen_Wert_Paar gt wird sofort lt Nomen gt muss nur unmittelbar lt Nomen_Wert_Paar gt muss nur lt Wert gt werden unmittelbar werden lt Nomen gt muss nur sofort lt Wert gt a lt Nomen_Wert_Paar gt muss nur sofo
308. telbar auf 37 gesetzt werden und das Ausfahren des Roboterarms 2 muss unmittelbar gestartet werden AG rdy_in amp Robot_state 36 amp Robot_angle 70 gt Al rdy_plc U rdy_plc amp Robot_left amp Robot_state 37 amp Arm2_forward gt gt gt Satz 142 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 37 ist und der Roboterarm 2 ist am Ablageband dann muss das Ausfahren des Roboterarms 2 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 38 gesetzt werden und der Magnetgreifer des Roboterarms 2 muss unmittelbar deaktiviert werden und das Einziehen des Roboterarms 2 muss unmittelbar gestartet werden AG rdy_in amp Robot_state 37 amp Arm2_ext 0 57 gt Al rdy_plc U rdy_plc amp Arm2_forward amp Robot_state 38 amp Ami mag on amp Arm2_backward gt gt gt Satz 143 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 38 ist und der Roboterarm 2 ist hinten dann muss das Einziehen des Roboterarms 2 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 39 gesetzt werden und die Fertigmeldung Roboter hat Teil auf Ablageband gelegt muss unmittelbar gesetzt werden und die Drehung des Roboters nach links muss unmittelbar gestartet werden AG rdy_in amp Robot_state 38 amp Arm2_ext 0 0 gt
309. tellenden Steuerungsprogramme in den jeweiligen Leitsystemen bzw Steuerungen abgearbeitet werden erfolgt nun die Darstellung der Spezifikation f r ausgew hlte Steuerungskomponenten in den dargestellten Ger teebenen unter Be r cksichtigung der angrenzenden Datenebenen 5 3 1 Ger teebene 1 Die Auftragsverwaltung Die Produktionsanlage der Fallstudie Erweiterte Produktionszelle besteht aus ver schiedenen Objekten deren koordinierter Einsatz eine m glichst effektive und kor rekte Produktion verschiedener Fertigteile erm glichen soll Die eingehenden Produktionsauftr ge m ssen innerhalb der Auftragsverwaltung ge sammelt und f r die untergeordnete Ebene in geeigneter Weise aufbereitet werden Jede Produktionszelle kann nur eine bestimmte Bearbeitungsart z B Bohren Pres sen Fr sen usw ausf hren die Zuordnung von Bearbeitungsart und Produktions zelle ist eineindeutig Zur Steigerung der Effektivit t der Gesamtanlage soll es m g lich sein mehrere Produktionsauftr ge gleichzeitig zu bearbeiten d h Produktions auftr ge werden entsprechend der Auslastung der Produktionszellen unmittelbar ge startet Gegebene Daten Die Auftragsverwaltung erh lt von einer bergeordneten nicht n her spezifizierten Ebene neue Produktionsauftr ge Weitere konkrete Daten sind in diesem Zusam menhang nicht bekannt Informelle Spezifikation Es m ssen Produktionsauftr ge der folgenden Art spezifiziert werden Es sollen n
310. ten die in einem bestimmten inneren Zusammenhang zueinander stehen Diese Anordnung wird aufgrund bestimmter Vorgaben gegen ber ihrer Umgebung abgegrenzt Ein System hat eine durch seine Struktur gegebene Ordnung und eine durch seine Dynamik und Kausalit t gegebene Funktion Die Struktur engl structure ist die Gesamtheit der Beziehungen zwischen den Kompo nenten des Systems Diese Beziehungen k nnen r umlich zeitlich begrifflich oder funktionell sein sie beschreiben welche Komponenten wie miteinander verkn pft sind d h die statischen Eigenschaften des Systems Die Systemparameter eines Systems sind Gr en deren Werte das Verhalten des Systems bei gegebener Struktur kennzeichnen Eine Gr e beschreibt die Eigenschaft eines Vorgangs oder K rpers die einer qualitativen Identifizierung und einer quantitativen Bestimmung zug nglich ist Der Wert einer Gr e ist das Ergebnis ihrer quantitativen Bestim mung das als Produkt aus Zahlenwert und Einheit angegeben wird Der Zustand eines Systems ist seine Beschaffenheit im Augenblick der Betrachtung Das Verhal ten engl behaviour eines Systems beschreibt die Gesamtheit der zeitlichen und kausalen Anderungen von Merkmalen des Systems Es bezeichnet die Form des Agierens und Reagierens des Systems infolge bestimmter Bedingungen es be schreibt somit die Dynamik des Systems Besteht eine feste Beziehung zwischen dem Reiz und der zugeh rigen Reaktion so spricht man von deterministischem V
311. ten Ergebnisse werden wiederum durch das Betriebssystem an die Ausgangsbaugruppen geliefert Diese Ubermitteln die neuen Anweisungen als elekt rische Signale an die Aktoren der Maschine wo die gew nschten Aktionen ausge f hrt werden Eine speicherprogrammierbare Steuerung zeichnet sich durch eine zyklische Arbeitsweise aus Der zuvor beschriebene Prozess erfolgt in einem festgelegten und konstanten Rhythmus der auch als SPS Zyklus bezeichnet wird Dabei werden zu Beginn des Zyklusses die Signale der Umgebung eingelesen und zwischengespei chert Mit diesen Werten und internen Variablen des Steuerungsprogramms werden danach die Berechnungen durchgef hrt Nach Beendigung des Zyklus werden die Ergebnisse der Berechnungen an die Umgebung ausgegeben Zus tzlich gibt es noch eine gewisse Wartezeit bis der SPS Zyklus wieder von vorn gestartet wird Der 33 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Neustart des SPS Zyklusses erfolgt in einem konstanten Zeitraster der Zyk us oder Abtastzeit Variante A Eingangsabbild einlesen H SPS Programmbearbeitung Ausgangsabbild ausgeben freie Rechenkapazitat Abbildung 8 Zyklische Arbeitsweise einer SPS Die Reihenfolge der dargestellten Teilprozesse wird in der Literatur recht unter schiedlich beschrieben Varianten A B C Allen Varianten ist gemeinsam dass zwi schen dem Eintreten bestimmter Ereignisse in der Umgebung un
312. timmen eine definierte Syntax die Menge von Regeln f r zul ssige Zeichenkombina tionen und Operationen bzw Kombinationen und eine formale Semantik die definierte Menge von Operationen mit Sym bolen und Symbolkombination nach Ma gabe der Zeichenbedeutung Ahre00 29 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Nach Alag98 m ssen Spezifikationssprachen die folgenden Charakteristiken enthal ten Formalismus definierte Syntax und formale Semantik Abstraktion es gibt Primitive f r die Definition und Manipulation von Daten auf dem logischen Level Modularit t Konstruktionen zur Erweiterung einer Spezifikation durch Anrei cherung und Komposition In diesem Zusammenhang wird auch auf die Arbeit des GMA Unterausschluss 1 8 1 hingewiesen der u a f r diese Beschreibungsmittel qualitative Kriterien zusammen gestellt hat Formale Basis M glichkeiten zur Abbildung der Systemstruktur Modularit t Hierarchie und Dynamik Kausalit t Logik von Abl ufen Abbildung paralleler Prozesse Abbildung se quentieller Prozesse Abbildung der Zeit Simulierbarkeit zusammen mit einem Tool Analysierbarkeit Diagnose Phasenorientierte Bewertung durchg ngige Anwendung f r Spezifikation Mo dellbildung Implementierung und Betrieb 30 Anforderungen an ein formales Beschreibungsmittel 2 3 Anforderungen aus dem Bereich der Steuerungstechnik Ein weiteres wichtig
313. tionsmethodik gefordert Die systematische Erstellung von Steuerungsprogrammen erfordert pr zise Vorgaben aus allen vorgelagerten und pa rallel arbeitenden Bereichen Gerade mit dem Bereich der mechanischen Konstruk tion gibt es enge Verzahnungen wenn es darum geht die Sensorik und Aktorik eines Systems zu spezifizieren oder zu ver ndern Hieraus ergeben sich weitere Anforde rungen eine zentrale Informationshaltung muss Redundanzen vermeiden existierende Unterlagen m ssen wieder verwendbar und durchg ngig durch alle Mitarbeiter nutzbar sein die verwendeten Tools m ssen von allen Mitarbeitern beherrscht und akzep tiert werden Beim Vergleich dieser Anforderungen mit den aktuellen Gegebenheiten wird deutlich dass es gerade im Bereich der durchg ngigen Anwendung von Spezifikationsmitteln gro e Defizite gibt In jeder Branche und jedem Bereich haben sich spezielle eigene Vorgehensweisen herausgebildet die einen Austausch von Informationen erschwe ren wenn nicht gar verhindern Wie eingangs gezeigt stellt der Vorgang des Programmierens einen kreativen Pro zess dar der eine berf hrung geforderter Abl ufe und Aktionen in maschinenaus f hrbare Algorithmen beinhaltet Hierbei stellt sich zun chst die Frage wie diese Anforderungen und Erwartungen an das System ermittelt geordnet und derart ab gelegt werden so dass sie auch sp ter wieder verwendet werden k nnen Die Pr sentation der dahinter liegenden Informationen un
314. tionstypen abgebildet werden die Bedingung w re dann gene rell TRUE Die Kombinationen Il und IV Ill und VII bzw VI und VIII k nnen durch Negation der Beobachtungsintervalle auf die jeweils andere Kombination abgebildet werden sie sind also redundant Aus diesem Grund entfallen die Kombinationen II und Ill Die Kombination VI wird jedoch trotzdem beibehalten da sich hier sp ter auf sprachli cher Ebene unterschiedliche Formulierungen ergeben werden Nach Abzug der ausgeschlossenen Kombinationen bleiben lediglich vier Varianten brig diese stellen die automatisierungstechnisch stark relevanten Anforderungen an Steuerungsprogramme dar IV Einfache Forderung DEs simple demand VI Einfaches Verbot PRs simple prohibition VII Erweiterte Forderung DEe extended demand VIIL Erweiterte M glichkeit POe extended possibility 3 1 4 Ableitung des Zeitparameters Neben der Kategorisierung der SPS Anforderungen hinsichtlich ihrer Bedeutung be steht ein weiteres Unterscheidungsmerkmal innerhalb dieser Kategorien in der Reichweite der jeweiligen Aussage Mit ihr wird spezifiziert ber welchen Zeitraum die entsprechende Anforderung g ltig sein soll Es wurde bereits ein Beobachtungsintervall definiert in dem je nach Modalparameter ein festgelegter Zielzustand entweder existieren muss existieren darf oder nicht existieren darf Das Beobachtungsintervall beginnt immer mit einem Startzustand und besteht aus e
315. tiv ber die verh ltnism ig hohe An zahl von Analyseergebnissen berrascht die als falsch zur ckgewiesen werden Im ersten Moment wird die Ursache hierf r in einem fehlerhaften Systemmodell und speziell einem fehlerhaften Programm vermutet Das Erstaunen ist umso gr er wenn sich das Programm zuvor im praktischen Einsatz als scheinbar korrekt und si cher gezeigt hat Die Ursachen f r eine relativ starke Fehlerquote beim Model Checking liegen jedoch meist an anderer Stelle Diese zeigen sich erst bei einem detaillierten statischen oder dynamischen Test des Programms bzw der gr ndlichen Analyse des zum Fehlerzu stand f hrenden Pfads Eine wesentliche Ursache liegt in der Anforderung selbst Viele Anfragen an das Verifikationswerkzeug werden zu allgemein oder zu oberfl ch lich gestellt so dass bei der Analyse weitaus mehr Systemzust nde analysiert wer den m ssen als dem Nutzer bewusst ist Grund hierf r ist die bereits dargestellte Eigenschaft nat rlicher Sprache dass man sich bei der Formulierung einer Anforde rung auch auf vorherige Anforderungen beziehen kann Bei einer formalen Darstel lung darf diese elliptische Verk rzung jedoch nicht auftreten Jede Aussage muss inhaltlich vollst ndig und abgeschlossen sein und muss im Besonderen alle Neben bedingungen enthalten Durch Verfeinerung und Vervollst ndigung der Analyseanfrage erh lt man schlie lich auch eine inhaltlich korrekte Spezifikation 98 Zusammenfassun
316. tiver Systeme mit einer Sicherheitsfachsprache Ebene b lt cond_pl gt lt cond_sg_start gt lt cond_sg_start gt und lt cond_pl_follow gt lt for_concl_pl gt lt for_concl_sg gt lt for_concl_sg gt und lt for_concl_pl gt lt back_concl_pl gt lt back_concl_sg gt lt back_concl_sg gt und lt back_concl_pl gt Ebene c lt cond_sg_start gt lt Nomen gt lt Wert gt ist lt Nomen gt lt Wert gt war lt cond_pl_follow gt lt cond_sg_start gt lt cond_sg_follow gt lt cond_sg_start gt und lt cond_pl_follow gt lt cond_sg_follow gt und lt cond_pl_follow gt lt cond_sg_follow gt lt Nomen gt ist lt Wert gt lt Nomen gt war lt Wert gt lt for_concl_sg gt lt Nomen gt muss gleichzeitig lt Wert gt sein muss lt Nomen gt gleichzeitig lt Wert gt sein muss gleichzeitig lt Nomen gt lt Wert gt sein lt Nomen gt muss gleichzeitig lt Wert gt bleiben muss lt Nomen gt gleichzeitig lt wert gt bleiben muss gleichzeitig lt Nomen gt lt Wert gt bleiben lt Nomen gt muss unmittelbar lt Wert gt werden muss lt Nomen gt unmittelbar lt Wert gt werden muss unmittelbar lt Nomen gt lt Wert gt werden lt Nomen gt muss sofort lt Wert gt
317. ts89 den Softwareentstehungsprozess mit folgender Darstellung Abbildung 1 Abstraktionsgrad abstrakt Spezifikation Programm konkret maschinennah informell formal Sprachliche Freiheit Abbildung 1 Entstehung eines Programms aus einer Idee Ausgehend von einem Anfangszustand in dem es eine f r den Menschen verst nd liche abstrakte und informelle Idee f r ein Programm gibt besteht das Ziel darin zu einem formalen auf dem Rechner ablauff higen Programm zu kommen F r die Er reichung dieses Ziels gibt es viele Wege jeder Pfad dorthin ist ein ganz spezieller Programmentwicklungsprozess Darunter gibt es solche die ausgehend von der Idee sehr schnell auf eine maschinennahe und dennoch informelle Darstellung berf hrt werden z B so genannte quick hack s Prototypen Ein anderer Weg der von ihm und vielen anderen favorisiert wird besteht darin m glichst lange in einer abstrakten Ebene zu verbleiben dort zu einer formalen Darstellung zu gelangen und erst zum Schluss auf eine konkrete Kodierung des Problems zu wechseln Hierbei definiert die Spezifikation was das Programm leisten soll Gleichsam ist durch das Programm der Erf llungsgrad der Spezifikation bestimmt Futs89 Die Entwicklung eines Steuerungsprogramms f r eine zu automatisierende Anlage kann man als einen Prozess betrachten bei dem geforderte und gew nschte Eigen schaften in Software implementiert werden Diese Soll Eigenschaften werden bl
318. tsystem am Rohteilelager befindet bernimmt es selbst ndig die festgelegte Anzahl von Rohteilen Nachdem das beladene Transportsystem die Produktionszelle erreicht hat bergibt es selbst ndig alle Rohteile an den Eingangspuffer der Produktions zelle Nachdem das leere Transportsystem die Produktionszelle erreicht hat ber nimmt es selbst ndig alle Fertigteile aus dem Ausgangspuffer der Produkti onszelle Nachdem das beladene Transportsystem das Fertigteillager erreicht hat bergibt es selbst ndig alle Fertigteile an das Fertigteillager Nach der Beendigung des Transportauftrags generiert das Transportsystem seine Fertig bzw Bereitschaftsmeldung Definition neuer Daten mit dem SFS Editor Es m ssen Daten zur Lagebestimmung definiert werden zus tzlich dazu werden Signale vereinbart die die Einnahme von bestimmten Positionen anzeigen Auf die Details dieser Daten wird in dieser Arbeit nicht eingegangen 178 Anhang Zur Realisierung der Material bernahme aus dem Rohteilelager muss eine Z hlung der bernommenen Rohteile erfolgen Die bernahme ist beendet wenn die ge w nschte Anzahl von Rohteilen entnommen wurde Dasselbe gilt f r die bernahme der Fertigteile aus dem Ausgangspuffer der Produktionszelle Die bergabe der Rohteile an die Produktionszelle bzw die bergabe der Fertigteile an das Fertigteil lager erfolgt solange bis das Transportsystem leer ist Auf die Details dieser Daten wird
319. tte gezeigt haben besteht ein allgemein hohes Interesse an der Nutzbarmachung formaler Methoden f r die Softwareentwicklung Dies dr ckt sich durch ein breites Spektrum an universit ren und industriellen Forschungs und Entwicklungsaktivit ten aus und ist nat rlich auch durch die zwingende Notwendig keit einer Erh hung der Softwaresicherheit begr ndet Es wurde gezeigt dass es sowohl Ma nahmen gibt die im Vorfeld der Softwareentwicklung angewendet wer den k nnen und dass es dar ber hinaus Methoden und auch bereits Tools gibt die eine Verbesserung der Softwarequalit t w hrend des Entstehungsprozesses errei chen Weiterhin wurden einige Methoden und Verfahren vorgestellt die auch nach der Erstellung der Software einsetzbar sind um bestehende Fehler oder Unzul ng lichkeiten zu beseitigen Dennoch bestehen allgemein gro e Bef rchtungen dass der sehr hohe Aufwand der z B bei einer formalen Spezifikation betrieben werden muss nicht durch die Ergebnisse gerechtfertigt wird Lewe97 Dieser Umstand kann nur durch Werkzeuge behoben werden die schnell erlernbar und anwendbar sind und somit eine hohe Nutzerakzeptanz erwerben 25 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache 2 Anforderungen an ein formales Beschreibungsmittel in der Steuerungstechnik Damit ein formales Beschreibungsmittel als geeignet f r die Anforderungen der Steuerungstechnik gelten kann muss es verschiedenen Bedingungen gen gen
320. ttelbar gestoppt werden und die Zustandsvariable des Krans muss unmittelbar 22 werden und der Magnet des Krangreifers muss unmittelbar aktiviert werden und das Anheben des Krangreifers muss unmittelbar gestartet werden AG rdy_in amp Crane_state 21 amp Crane_height 0 66 gt Al rdy_plc U rdy_plc amp Crane_lower amp Crane_state 22 amp Crane_mag_on amp Crane_lift gt gt gt Satz 82 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 22 ist und der Greifer des Krans ist oben dann muss das Anheben des Krangreifers unmittelbar gestoppt werden 189 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache und die Zustandsvariable des Krans muss unmittelbar 23 werden und die Fertigmeldung Kran hat Fertigteil vom Ablageband genommen muss unmittelbar gesetzt werden und die Bewegung des Krans nach links zum Zuf hrband muss unmittelbar gestartet werden AG rdy_in amp Crane_state 22 amp Crane_height 0 gt Al rdy_plce U rdy_plc amp Crane_lift amp Crane_state 23 amp Crane_done_take_dbelt amp Crane_to_fbelt gt gt gt Satz 83 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Krans 23 ist und der Kran ist am Ausgangspuffer dann muss die Bewegung des Krans nach links zum Zuftihrband unmittelbar gestoppt werden und die Zustandsvariable
321. ttelbar gesetzt werden und die Zustandsvariable der Hubtischh he muss unmittelbar auf 12 gesetzt werden und die Zustandsvariable der Hubtischdrehung muss unmittelbar auf 12 gesetzt werden AG rdy_in amp Table_state2 11 amp Table_statel 11 gt 201 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Al rdy_plc U rdy_plc amp Table_ready_give amp Table_state2 12 amp Table_statel 12 gt gt gt Satz 110 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Hubtischh he 12 ist und die Zustandsvariable der Hubtischdrehung ist 12 dann die Zustandsvariable der Hubtischh he muss unmittelbar auf 0 gesetzt werden und die Zustandsvariable der Hubtischdrehung muss unmittelbar auf 0 gesetzt werden AG rdy_in amp Table_state2 12 amp Table_statel 12 gt Al rdy_plc U rdy_plc amp Table_state2 0 amp Table_statel 0 gt gt gt Satz 111 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable der Hubtischhohe 2 ist und der Hubdrehtisch ist unten dann muss das Absenken des Hubdrehtischs unmittelbar gestoppt werden und die Zustandsvariable der Hubtischh he muss unmittelbar auf 21 gesetzt werden AG rdy_in amp Table_state2 2 amp Table_bottom gt Al rdy_plc U rdy_plc amp Table_downward amp Table_state2 21 1 gt gt gt Satz 112 lt lt lt einfache Forde
322. tungsintervall BI definiert das mit einem Startzustand be ginnt und eine momentan nicht n her definierte L nge aufweist Ein Beobach tungsintervall umfasst eine bestimmte Anzahl zeitlich aufeinander folgender Systemzust nde 43 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Die Unterteilung der Anforderungen an ein Steuerungsprogramm erfolgt nachfolgend durch zwei Parameter 1 der Modalparameter gibt die logische Bedeutung der Anforderung an er stellt einen modalen Zusammenhang zwischen einem Zielzustand und einem Beo bachtungsintervall her 2 der Zeitparameter gibt die Lange eines Beobachtungsintervalls d h die zeit liche Reichweite einer Anforderung an 3 1 3 Ableitung des Modalparameters Zunachst wird eine Tabelle erstellt Tabelle 3 in der die modalen Zusammenhange zwischen dem Zielzustand Z also der Erf llung einer Folgerung und dem Beo bachtungsintervall BI dargestellt werden Dabei erfolgt eine Betrachtung Uber die Existenz eines Zielzustandes sowohl innerhalb als auch au erhalb des Beobach tungsintervalls Innerhalb des Beobachtungsintervalls Bl Forderung muss M glichkeit darf Verbot darf nicht E gt Bes KA oO E gt oO bal Q oO a N me 2 Be e gt lt Forderung D x ra 2 D dei innerhalb des BI es muss ein Z geben innerhalb des BI es darf ein Z geben innerhalb des BI
323. uf 2 Fertigteile wegbringen gesetzt 6 INT VAR_GLOBAL ZE tr place die anzufahrende Produkt ionszel lei 7 T qu Do 2a 1 6 1 W SC SH 7 INT VAR_GLOBAL tr quantity die Anzahl der zu transportierenden Teile 11 g SAT on TORE 25 LON ZONE QO 10 auf 1 gesetzt 5_0 auf 5 gesetzt 10_0 auf 10 gesetzt 20_0 auf 20 gesetzt 142 Anhang Datenebene 2 Bereitschaftsmeldungen der Produktionszellen Technische Bezeichnung Variable Datentyp Kommentar Bereitschaftsmeldung cell_1_ready Bool Zelle 1 ist f r neuen Auftrag bereit Zelle 1 Bereitschaftsmeldung cel1_2_ready Bool Zelle 2 ist fur neuen Auftrag bereit Zelle 2 Bereitschaftsmeldung cell_n_ready Bool Zelle n ist f r neuen Auftrag bereit Zellen Tabelle 11 Datenebene 2 Bereitschaftsmeldungen der Produktionszellen 8 BOOL VAR_GLOBAL cell_l1_rdy die Bereitschaftsmeldung der Produktionszelle JP TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt 9 BOOL VAR_GLOBAL cell_2_rdy die Bereitschaftsmeldung der Produktionszelle PAL TRUE_I gesetzt FALSE_I nicht gesetzt TRUE_O gesetzt FALSE_O zur ckgesetzt Datenebene 2 Ferti
324. uf 22 gesetzt werden und der Magnetgreifer des Roboterarms 2 muss unmittelbar aktiviert werden und das Einziehen des Roboterarms 2 muss unmittelbar gestartet werden AG rdy_in amp Robot_state 21 amp Arm2_ext 0 79 gt Al rdy_plce U rdy_plc amp Arm2_forward amp Robot_state 22 amp Ami mag on amp Arm2_backward gt gt gt Satz 130 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 22 ist und der Roboterarm 2 ist hinten dann muss das Einziehen des Roboterarms 2 unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 23 gesetzt werden und die Fertigmeldung Roboter hat Teil aus Presse genommen muss unmittelbar gesetzt werden und die Drehung des Roboters nach links muss unmittelbar gestartet werden AG rdy_in amp Robot_state 22 amp Arm2_ext 0 0 gt Al rdy_plc U rdy_plc amp Arm2_backward amp Robot_state 23 bk Robot_done_unload amp Robot_left gt gt gt Satz 131 lt lt lt einfache Forderung direkt Wenn die Zustandsvariable des Roboters 23 ist und der Roboter ist mit dem Arm 2 vor dem Ablageband dann muss die Drehung des Roboters nach links unmittelbar gestoppt werden und die Zustandsvariable des Roboters muss unmittelbar auf 24 gesetzt werden und das Ausfahren des Roboterarms 2 muss unmittelbar gestartet werden AG rdy_in amp Robot_state 23
325. ufgebautes System Die einzelnen Systeme werden durch einen endlichen Automaten beschrie ben und kommunizieren asynchron miteinander Lewe97 Z 1988 von Spivey entwickelt B und VDM Jones 1986 sind zustandsbasierte Methoden die besonders f r die Beschreibung des Verhaltens von sequentiellen Systemen geeignet sind Clar96 FrapO1 Die haupts chlichen Einsatzgebiete von CSP Hoare 1985 Statecharts Harel 1987 und der Temporalen Logik Manna Pnueli 1991 ist die Beschreibung des Verhaltens von nebenl ufigen und parallelen reaktiven Systemen Clar96 Mann92 Mann95 Statecharts modellieren reaktive Systeme als System kommu nizierender und hierarchisch organisierter endlicher Automaten Temporale Logiken erlauben die Formulierung von Anforderungen durch modallogische Formeln Lewe97 VHDL und Verilog sind Notationen die zur Beschreibung von digitalen Schaltkreisen eingesetzt werden Lewe97 Frap01 SREM Software Requirement Engineering Method DGQ92 ist ein Werkzeug zur bersetzung funktionaler Anforderungen in detaillierte und maschinell nachpr fbare Spezifikationen SREM enth lt drei Komponenten RSL requirement statement language Formulierung von Anforderungen in lesbarem Englisch mit strenger Syntax berpr fung auf Widerspruchsfrei heit und Vollst ndigkeit m glich REVS requirement engineering and validation system Unterst tzung bei der bersetzung der RSL statements Speicherung Analyse
326. und Werte definiert formal definieren Durchf hrungsphase Bestimmung der Anforderungskategorie Erstellung der S tze Formale Spezifikation Ausgabe der S tze Abbildung 19 Ablauf der Erstellung von Anforderungen mit dem SFS Editor In der Durchf hrungsphase bestimmt der Nutzer zun chst die Anforderungskatego rie die seiner Idee von einer speziellen Programmanforderung entspricht Damit ist ein Anforderungskonstrukt festgelegt das mit den zuvor erstellten Verbalphrasen ausgef llt wird In der Abbildung 20 ist die Erstellung der Verbalphrasen mit dem SFS Editor darge stellt Die in der Fallstudie verwendeten SPS Variablen k nnen dem Variablendekla rationsteil des zu analysierenden SPS Programms entnommen werden Anschlie Bend ist f r jede Variable und f r jeden Wert den diese annehmen kann eine ver bale Interpretation zu erstellen Die Auflistung der Variablen und ihre verbale Inter pretation wird in der Nomendeklarationsdatei abgelegt und in der Compiler Sequenz wieder verwendet Sollten zun chst nicht alle Variablen bekannt sein kann das Erstellen der Nomen und Werte auch zu einem sp teren Zeitpunkt erfolgen 65 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Verbalname Deeklarationstyp SPS Variable Datentyp Kommentar der Zustand 4 des Windkessels VAR der Zustand 3 des Windkessels VAR der Zustand 2 des Windkessels VAR der Zustand 1 des Windkessels VAR die Pri
327. ung der Presse falls sie sich zu weit ffnen w rde 2 Vermeidung von Maschinenkollisionen z B der Roboterarme mit der Presse falls deren Bewegung nicht exakt koordiniert ist 3 die Werkst cke sollen innerhalb so genannter sicherer Bereiche abgelegt wer den z B darf der Magnet des Krangreifers nur an bestimmten Stellen deakti viert werden 4 ausreichende Trennung der Werkst cke d h durch die Funktion der Licht schranken auf den F rderb ndern ist ein bestimmter Mindestabstand der Werkst cke f r die sichere Erkennung notwendig 94 Validierung des Prototypen anhand einer Fallstudie Auch diese informellen Anforderungen konnen mit der Sicherheitsfachsprache for muliert werden Ein weiterer Problembereich zur Sicherung der Gesamtanlage ist die Vermeidung von Zusammenst en bzw Kollisionen zwischen verschiedenen beweglichen Ele menten der Produktionszelle Beispiele hierf r sind Kollision des Krangreifers mit dem Zuf hrband dem Ablageband dem Ein gangspuffer oder dem Ausgangspuffer Kollision eines Roboterarms mit der Presse Kollision des Pressenwerkzeugs mit einem Roboterarm Nachfolgend soll beispielhaft mit Hilfe der in Abschnitt 4 6 dargestellten Fehlerbaum analyse gezeigt werden welche Voraussetzungen und Zusammenh nge zu einer Kollision der Roboterarme mit der Presse f hren k nnen Die erzielten Analyseer gebnisse flie en anschlie end in zus tzliche Programmanforderungen ein Als zu verhin
328. ungsprogramme liegen hierbei in Ablaufsprache SFC oder in Anweisungsliste AWL vor und werden in Bedingungs Ereignis Systeme Sreenivas Krogh B E Systeme engl condition event systems C E systems berf hrt Ein zus tzliches B E System wird f r die Modellierung der ungesteuerten Anlage verwendet Durch Verschmelzung dieser beiden Systeme ent steht ein Modell der gesteuerten Anlage Durch Erreichbarkeitsanalysen wird nach gewiesen ob die Spezifikation dargestellt durch verbotene Zust nde erf llt wird Die Besonderheit dieses Ansatzes besteht vor allem in der Ausrichtung auf anla gentechnische Prozesse Chemietechnik und den sich daraus ergebenden Beson derheiten bei der Modellierung kontinuierlicher Prozesse Diese Arbeiten wurden mit dem Tool VERDICT Kowa98 Tres00a TresOOb fortgesetzt bei dem eine Verifi kation mit KRONOS und HyTech auch mit SMV erfolgt Die Zielstellung dieses Tools liegt in der Untersuchung diskreter Steuerungen f r technische Systeme mit kontinuierlicher Dynamik und hybrider Systeme Lesage Couffin de Smet Rossi u a DeSm00 Lamp99 von Alcatel und der Ecole Normale Superieure Cachan Frankreich berf hren innerhalb des Projektes VULCAIN Steuerungsprogramme die in den IEC 61131 3 Standard Programmier sprachen Anweisungsliste Cane00 Kontaktplan Ross00a Ross00b oder Ablauf sprache Lamp00 geschrieben sind in ein Transitionssystem bzw direkt in Code der durch einen Model Ch
329. unikation mit Zuf hrband nennen 158 A 7 2 4 Kommunikation mit dem Hubdrehtisch 444444 gt 162 A 7 2 5 Kommunikation mit dem Roboter 165 A 7 2 6 Kommunikation mit der Presse 172 A 7 2 7 Kommunikation mit dem Ablageband 44 nnnennenn gt 174 A 7 2 8 Kommunikation mit dem Kran Il 244444400s4nn nennen 176 A 7 3 Ger teebene 2 Steuerung des Transportevstems 40 178 A 7 4 Ger teebene 3 Steuerung des Krans 44244444400nnnnnn none 180 A 7 5 Ger teebene 3 Steuerung des Zut brbande 444200 193 A 7 6 Ger teebene 3 Steuerung des Hubdrehtischs esssssseenneeeeeeeeene 197 A 7 7 Ger teebene 3 Steuerung des Roboters Aen 204 A 7 8 Ger teebene 3 Steuerung der Presse EE 219 A 7 9 Ger teebene 3 Steuerung des AblagebandS ssesssssssrnrreeeeeeenne 224 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Abbildungen Abbildung 1 Entstehung eines Programms aus einer dee 5 Abbildung 2 Spezifikation als Bewertung von Systemzust nden 6 Abbildung 3 Ursachen f r Softwarefehler HH nnnnnnnnnnnnnnnnnnnnnnnnnnn 7 Abbildung 4 Vergleich von Synthese und Verifikation sssesseseeseeeeeeeeeeeee 12 ees UR EE ee E WEE 16 Abbildung 6 Betriebliches Ebenenmodell uuss24244440nnnnnnnnnnnnnnnnnnnnnnn 31 Abbildung 7 Informationsfluss in einem automatisierten Gysiem 00 33 Abbildung 8 Zyklische
330. unmittelbar gesetzt werden und das Not Aus Signal f r das Zuftihrband muss unmittelbar gesetzt werden und das Not Aus Signal f r den Hubdrehtisch muss unmittelbar gesetzt werden und das Not Aus Signal f r den Roboter muss unmittelbar gesetzt werden und das Not Aus Signal f r die Presse muss unmittelbar gesetzt werden und das Not Aus Signal f r das Ablageband muss unmittelbar gesetzt werden AG rdy_in amp cell_l_state 0 amp Em_stopp gt Al rdy_plc U rdy_plc amp cell_l1_state 3 amp LED_celll_rdy amp LED_em_stopp amp Em_stopp_crane amp Em_stopp_fbelt amp Em_stopp_table amp Em_stopp_robot amp Em_stopp_press amp Em_stopp_dbelt gt gt gt Satz 8 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Automatikbetrieb ist und der Eingangspuffer ist leer und die Differenz zwischen Eingangs und Ausgangsz hler ist 0 dann muss die Produktionszelle I unmittelbar in den Ruhezustand berf hrt werden und die Anzeige Automatik l uft muss unmittelbar deaktiviert werden und die Anzeige Zelle ist bereit muss unmittelbar aktiviert werden und der Eingangsz hler muss unmittelbar auf 0 gesetzt werden und der Ausgangsz hler muss unmittelbar auf 0 gesetzt werden AG rdy_in amp cell_l_state 1 amp Piece_at_source amp pieces_diff 0 gt Al rdy_plc U rdy_plc amp cell_l_state 0 amp ILED_celll_run amp
331. ur Vorgehensweise bei der Spezifikation Bevor im Abschnitt 5 3 die formale Spezifikation der Erweiterten Produktionszelle mit Hilfe des SFS Editors dargestellt wird sollen an dieser Stelle einige Vorbemer kungen und Erl uterungen erfolgen Es wurde bereits dargestellt dass die formale Darstellung der Programmanforderun gen sowohl grundlegender Ausgangspunkt f r die Synthese eines neuen Steue rungsprogramms als auch eine notwendige Voraussetzung f r die Verifikation eines bereits existierenden Steuerungsprogramms ist Prinzipiell unterscheidet sich eine Spezifikation im Rahmen einer Programmsynthese von einer Spezifikation im Zu sammenhang mit einer Programmverifikation nur geringf gig realisierungsunabh n gige bzw realisierungsabh ngige Anforderungen vergleiche Abschnitt 4 5 Die nachfolgende Spezifikation der Erweiterten Produktionszelle soll diesmal unter dem Blickwinkel der Erstellung eines neuen Programms stehen Im Verlauf der Spezifikation wird eine Vorgehensweise angewendet wie sie typisch f r komplexe und hierarchisch aufgebaute Systeme ist Die benutzte Top Down Methodik vgl Stet87 orientiert sich an den gegebenen Strukturen des Gesamtsys tems und spiegelt vor allem auch die Aufteilung des Systems in verschiedene Infor mationsebenen wider Bei dieser deduktiven Methode wird ausgehend von einer re lativ allgemeinen Problemstellung in den oberen Hierarchieebenen eine immer feine re Detaillierung und Pr
332. ural grafische Beschreibung der Funktion Ablaufdiagramm Bewegungsdiagramm Weg Schritt Diagramm Weg Zeit Diagramm Zustandsdiagramm Flussdiagramm Programmablaufplan DIN 66001 DIN 66262 Funktionsplan DIN 40719 6 Fein97 Struktogramm nach Nassi Sheidermann DIN 66261 Automatengraf Heri92 Petrinetz Reis85 SPS Programmierung nach DIN 61131 3 Kontaktplan KOP Funktionsbau steinsprache FBS grafische Ablaufsprache AS Prozedural textuell Pseudocode SPS Programmierung nach DIN 61131 3 Anweisungsliste AWL Strukturier ter Text ST textuelle Ablaufsprache AS Logik orientiert grafisch Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Schaltnetz Logikplan Schalttabelle Entscheidungstabelle nach DIN 66241 Logik orientiert textuell algebraische Spezifikationen logik orientierte Sprachen In Chou98b sind mehr als 40 Beschreibungssprachen zusammengetragen klassi fiziert und bewertet worden Vom selben Autor wird in Chou98a die Spezifikation einer Steuerung mit einer TL hnlichen Sprache beschrieben Hierbei werden die Anforderungen mit so genannten Verbots und Gebotsoperationen verbal ausgedr ckt ist verboten ist verboten nach ist verboten vor soll soll vor soll nach Als weiteres grafisches Werkzeug zur formalen Spezifikation von Steuerungssys temen berichten J rn96 und Frey98 ber die Steuerungsentwicklung mit IPN Interpretierte Petri Net
333. us Taster ist nicht gedr ckt prozessorientiert x_2 die Variable x_2 ist nicht gesetzt variablenorientiert der Not Aus Taster ist gedr ckt prozessorientiert 72 Prototypische Realisierung und Einsatz der Sicherheitsfachsprache Der Grad der Interpretation kann nat rlich je nach Notwendigkeit angepasst wer den x3 die Variable x_3 ist gesetzt variablenorientiert der Endlagenschalter x_3 ist gedr ckt _ prozessorientiert der Werkzeugschlitten ist in der linken Endstellung Die Abbildung 23 fasst die verschiedenen M glichkeiten der Erstellung der Verbalphrasen noch einmal zusammen Einsatz der Variablen Datentyp Sensoren Aktoren int Variablen Abfrage eines Sensorzustandes Abfrage einer laufenden Aktion Abfrage eines besteh Zustandes x Is TRUE y_1 TRUE z_1 TRUE der Hydraulikzylinder ist oben das ffnen der Presse ist aktiv der Zustand 1 der Presse ist aktiv der Kran ist in Entnahmeposition der Magnet ist aktiv in einer die Lichtschranke ist blockiert Bedingung Abfrage eines Sensorzustandes Abfrage einer laufenden Aktion Abfrage eines besteh Zustandes Wenn x_2 50 y_2 50 z 2 50 Integer die Temperatur ist 50 Celsius die Drehzahl des Motors ist 50 der Wert des Merker
334. usalketten auf eine erf llte Bedingung folgt eine Reaktion entgegenkommt Die Anforderungskategorien werden durch einen Modal und einen Zeitparameter definiert Der Modalparameter bestimmt dabei den Inhalt einer Anforderung der Zeitparameter bestimmt deren zeitliche Reichweite Insge samt sind in der Sicherheitsfachsprache 18 Anforderungskategorien definiert wobei innerhalb jeder Kategorie weitere sprachlich unterschiedliche jedoch inhaltlich gleichwertige Satzmuster vorhanden sind Die Vielfalt und Redundanz wurde be wusst gew hlt um dem Anwender verschiedene M glichkeiten der Formulierung seiner Aufgabenstellung zur Verf gung zu stellen F r die berpr fung der Handhabbarkeit wurden mehrere Fallstudien angefertigt die sowohl die Umsetzung der SPS Variablen in die elementaren Verbalphrasen als auch die Erstellung kompletter Anforderungss tze beinhalten Eine dieser Fallstudien ist auszugsweise im Text sowie im Anhang dargestellt Durch einen Compiler werden die Anforderungen in Formeln der Temporalen Logik hier CTL umgewandelt Die Anwendung der Sicherheitsfachsprache gibt durch ihre anwenderfreundliche Schnittstelle jedem Nutzer die M glichkeit mit den Darstel lungs und Beschreibungsm glichkeiten der Temporalen Logik umzugehen Die er zeugten CTL Formeln k nnen innerhalb der vorgestellten Projektstruktur f r eine an schlie ende Verifikation des Steuerungsprogramms durch einen Model Checker verwendet werden Dieser liefert
335. usgangsin formationen liegen dem PreLexer die nat rlichsprachlichen Anforderungen sowie die Nomendeklaration in Form von zwei ASCII Dateien vor Aufgabe des PreLexers ist es die rein verbalen Anforderungen f r den nachfolgenden Kompiliervorgang vorzu bereiten und zu vereinfachen Hierbei werden die logisch zusammengeh rigen No men und Werte innerhalb des Ausgangstextes wieder zu Nomen Wert Paaren zu 67 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache sammengefasst und in die SPS internen Variablendarstellungen berf hrt z B die Presse und gestoppt zu x_2 Im Gegensatz zum eigentlichen Compiler kennt der PreLexer weder die Bedeutung noch die Reichweite einer Anforderung Er ori entiert sich lediglich am Satzbau bzw der Positionierung der in der Nomendeklarati onsdatei abgelegten Wortphrasen sowie SFS typischer Schl sselw rter Die interne Umsetzung erfolgt dabei in zwei Schritten 1 Umstellen einzelner W rter im Satz so dass danach das Nomen und der Wert nebeneinander und im richtigen Verh ltnis zu den anderen Schl ssel w rtern stehen 2 Zusammenfassen des Nomens und des Wertes und Ersetzen durch die SPS Variable mit dem entsprechenden Wert Aus dem Text Satz I Wenn der Zustand I der Presse aktiv ist und die Presse ist unten dann muss das Schliessen der Presse unmittelbar gestoppt werden und das ffnen der Presse
336. uss nur sofort werden Nomen_Wert_Paar gt wird nur unmittelbar Nomen_Wert_Paar gt wird nur sofort lt lt lt lt lt DE3_for_sg gt muss irgendwann lt Nomen_Wert_Paar gt werden wird irgendwann lt Nomen_Wert_Paar gt lt DES3_back_sg gt lt Nomen_Wert_Paar gt muss irgendwann werden lt Nomen_Wert_Paar gt wird irgendwann lt DEe3_back_sg gt lt Nomen_Wert_Paar gt muss nur irgendwann werden 121 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache lt Nomen_Wert_Paar gt wird nur irgendwann lt POl_for_sg gt kann gleichzeitig lt Nomen_Wert_Paar gt sein darf gleichzeitig lt Nomen_Wert_Paar gt sein lt POel_back_sg gt lt Nomen_Wert_Paar gt kann nur sein lt Nomen_Wert_Paar gt darf nur sein lt PO3_for_sg gt kann irgendwann lt Nomen_Wert_Paar gt werden darfirgendwann lt Nomen_Wert_Paar gt werden lt POe3_back_sg gt lt Nomen_Wert_Paar gt kann nur irgendwann werden lt Nomen_Wert_Paar gt darf nur irgendwann werden lt PR1_for_sg gt darf nicht gleichzeitig lt Nomen_Wert_Paar gt sein darf niemals gleichzeitig lt Nomen_Wert_Paar gt sein lt PRsl_back_sg gt lt Nomen_Wert_Paar gt darf nicht gleichzeitig sein lt Nomen_Wert_Paar gt da
337. ver Systeme mit einer Sicherheitsfachsprache Inhalt 1 Einleitung und Ausgangssituation uuuusessssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 1 1 1 Softwarefehler und ihre Ursachen uuunusssssannnnnennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 1 1 1 1 Begriffsbestimmung nn nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 1 1 1 2 Die Softwarekrise in der Steuerungstechnik nennen 3 1 1 3 Spezifikation von Steuerungssystemen ssssssseeeerreeeseesrrrnrrrrsserrrrrrrnn 5 1 2 Parameter der Softwarequalit t uuuuuunnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 8 1 3 Nat rliche Sprache als Beschreibungsmittel uuuuusnnnnnnnnnnnnnnnnnnnnnnnnnnn 10 1 4 Stand der Technik zur Erh hung der Softwarequalit t nuuesenennnnnnn 11 1 4 1 Ma nahmen im Vorfeld der Softwareentwicklung 44424240000 13 1 4 1 1 Ouslt ismanagement Prozessee 13 14 1 2Vorgehensmodele rasen range 14 1 4 2 Ma nahmen w hrend der Softwareentwicklung usss44 0 16 1 4 2 1 Spezifikationsmethoden sa es 16 1 4 2 2 E REESEN 20 1 4 at 20 1 4 3 Ma nahmen im Anschluss an die Softwareentwicklung 22 POW TSU EE 22 RE REM enn pp a ee a OOD Perera earn ee eee ter trae 23 2 Anforderungen an ein formales Beschreibungsmittel in der Steuerungstechnik ci ssvscatecessctuecauccarenestaaseustcaueia suasanauseancuavtadednunssiuscencuavsiavinanauandaal 26 2 1 Allgemeine Anforderunge
338. vor es einen Zustand gibt in dem rdy_in und eine Endbedingung B erf llt sind Zus tzlich darf es keinen Zustand mit rdy_plc und F geben bevor rdy_in und B erstmals g ltig waren und es darf auch keinen Zustand mit rdy_plc und F geben darf nachdem rdy_in und Bz erstmals g ltig waren AG rdy_in a B gt AF rdy_plc a Fa AF rdy_in Be A A C U By v AG C a AG B2 gt A C U Bi v AG Ou mit C rdy_plea B a F 60 Die Sicherheitsfachsprache Zeitparameter Selbstbegrenzt Kategorie DEs3 einfache Forderung Selbstbegrenzt Analyseinhalt Sobald es einen Zustand gibt in dem rdy_in und eine Bedingung B erf llt werden muss es danach einen Zustand geben in dem sowohl rdy_plc die Bedingung B und eine Folgerung F erf llt werden bevor die ausl sende Bedingung B wieder ung ltig wird Die Forderung F findet also irgendwann innerhalb des Beo bachtungsintervalls Bo rdy_in A B und B rdy_in A B statt Forderungen die ser Form k nnen in CTL nicht formuliert werden F muss irgendwann f r eine ge wisse Zeitspanne nach dem Eintreten von Bo gelten ist diese Zeitspanne jedoch ab gelaufen und gilt wiederum F gilt noch immer Bo ohne dass gefordert w re dass F wiederum irgendwann G ltigkeit erlangt Diese beiden F lle sind in CTL jedoch nicht unterscheidbar Dieses Problem wurde durch eine Modifikation des Modells d h des Registernetzes V welches das System Anlage Steuerung repr sentiert gel st Hein01
339. w hnt wo gerade die Formulie rung von Anforderungen mit nat rlichsprachlichen Mitteln eine gro e Rolle spielt Die Anwendung einer formalen Systembeschreibung f r die Synthese von Steue rungsprogrammen wurde bereits ausf hrlich dargestellt Auch hier bietet die Sicher heitsfachsprache gen gend M glichkeiten und mit der Kategorie DEs2 Einfache Forderung Direkt auch bereits eine geeignete Kategorie um den gew nschten Ablauf eines Steuerungsprogramms vollst ndig zu beschreiben Die Uberf hrung von CTL Formeln in ein SPS Programm ist bereits heute Inhalt anderer Forschungs vorhaben Ein weiteres Feld der Weiterentwicklung ist die Portierung der Sicherheitsfachspra che auf andere Sprachen wie z B Englisch Die hierf r notwendigen Anderungen w ren relativ einfach zu bewerkstelligen Unter Beachtung des gegebenen Satzbaus der englischen Sprache sind die formale Syntax der SFS in den Ebenen 3 4 und 5 sowie der PreLexer anzupassen Mit der Portierung auf weitere Sprachen erschlie t sich umgehend ein weiteres An wendungsfeld der Sicherheitsfachsprache Der Vorgang der berf hrung eines na t rlichsprachlichen Satzes in eine CTL Formel ist reversibel allerdings m sste hierzu jeweils eine Standard Formulierung pro Anforderungskategorie definiert werden da keine eineindeutige Zuordnung eines nat rlichsprachlichen Satzes zu einer CTL Formel besteht Es k nnen also auch CTL basierte Anforderungen in nat rliche Sprac
340. wandlung und umstellung besteht erfordert die Programmierung des Compilers weitreichendere Analysefunktionen Aus diesem Grund wurde der Compiler mit den beiden Werkzeugen flex und bison Abarten der bekannten Compilergeneratoren lex und yacc erstellt die eine zeit und kosteng nstige Erstellung des Compilers aber auch eine leichte Anpassbarkeit an zuk nftige Erfordernisse gew hrleisten Ein weiterer Vorteil dieser Vorgehensweise ist dass die im Abschnitt 3 1 definierte und im Anhang A 2 dargestellte Struktur der Sicherheitsfachsprache direkt als Input f r die Compilergeneratoren dienen kann Der Compiler generiert automatisch aus dem Zwischentext des PreLexers die CTL Formeln Satz 1 7 AG rdy_in amp press zl amp press_bottom gt Al rdy_plc U rdy_plc amp press_down amp press_upward amp press_zl amp press_z2 Satz 2 AG rdy_in amp press_z2 amp press_top gt A rdy_plc U rdy_plc amp press_upward amp press_z2 amp press_z3 Satz 3 AG rdy_plc amp press_bottom amp arml_forward Diese CTL Formeln k nnen anschlie end beispielsweise durch einen Model Checker an einem Kontrollmodell des Steuerungsprogramms verifiziert oder f r an dere Zwecke verwendet werden 4 4 Bildung von Verbalphrasen durch Interpretation der SPS Variablen Bei der Formulierung einer Anforderung mit der Sicherheitsfachsprache wird dur
341. war muss irgendwann F1 werden und muss irgendwann F2 werden Nur nachdem B1 war und B2 war wird irgendwann F1 und wird irgendwann F2 F1 muss nur irgendwann werden und F2 muss nur irgendwann werden wenn irgendwann B1 war und B2 war F1 wird nur irgendwann und F2 wird nur irgendwann wenn irgendwann B1 125 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache war und B2 war F1 muss nur irgendwann werden und F2 muss nur irgendwann werden wenn vorher B1 war und B2 war F1 wird nur irgendwann und F2 wird nur irgendwann wenn vorher B1 war und B2 war Kategorie POe1 erweiterte M glichkeit Zustand Nur wenn B1 ist und B2 ist dann kann gleichzeitig F1 sein und kann gleichzeitig F2 sein Nur wenn B1 ist und B2 ist dann darf gleichzeitig F1 sein und darf gleichzeitig F2 sein F1 kann nur sein und F2 kann nur sein wenn gleichzeitig B1 ist und B2 ist F1 darf nur sein und F2 darf nur sein wenn gleichzeitig B1 ist und B2 ist Kategorie POe3 erweiterte M glichkeit selbstbegrenzt Nur solange B1 ist und B2 ist kann irgendwann F1 werden und kann irgendwann F2 werden Nur solange B1 ist und B2 ist darf irgendwann F1 werden und darf irgendwann F2 werden F1 kann nur irgendwann werden und F2 kann nur irgendwann werden solange gleichzeitig B1 ist und B2 ist F1 darf nur irgendwann werden und F2 darf nur irgendwann werden solange gleichzeitig B1 ist und B2 ist
342. ze nach K nig und Qu ck Es handelt sich hierbei um den systematischen und hierarchischen Entwurf von Steuerungen mit dem Tool Netmate 1 4 2 2 Programmierregeln Als ein wichtiges Mittel zur direkten und schnellen Verbesserung der Softwarequalit t haben sich Entwurfs und Programmierregeln bew hrt die grob in drei Bereiche auf geteilt werden k nnen Ausf hrliche Dokumentation Kommentare im Code Referenzlisten Schrift bild Ubersichtlichkeit Anderungen bersichtlichkeit Defensive Programmierung keine Tricks geringe Schachtelungstiefe von Mo dulen Vollst ndigkeit des Codes alle Variablen deklarieren und initialisieren voll st ndige Fallunterscheidungen Wertebereichs und Plausibilit ts berpr fun gen Abbruchbedingungen in Schleifen In Rein99 und Balz96 sind einige dieser leicht anzuwendenden und wirksamen Ma nahmen aufgef hrt 1 4 2 3 Softwaresynthese Schon seit l ngerer Zeit gibt es das Bestreben Software und auch speziell Steue rungsprogramme automatisch aus einer vorgegebenen Aufgabenstellung heraus zu generieren Parallelen hierzu gibt es aus dem Bereich der Regelungstechnik wo es m glich ist bei gen gend genauer Kenntnis der Regelstrecke und der Vorgabe eines Regelziels den dazugeh rigen Regler zu berechnen 20 Einleitung und Ausgangssituation Bereits 1996 wurde durch K Winkelmann ein Patent eingereicht WO 96 32667 das ein Verfahren zur Generierung einer Steuerung aus einer anw
343. zeugen ASCET SD und Matlab erstellt wurden Diese Modelle werden in SMV Code berf hrt die Spezifika tion der Anforderungen erfolgt mit CTL Formeln 24 Einleitung und Ausgangssituation Zum Abschluss dieses Kapitels seien noch die beiden Forschungsprogramme OFFIS und KORSYS genannt unter deren Federf hrung weitere Teilprojekte unter ande rem auch im Bereich der formalen Verifikation von Steuerungsprogrammen durch gef hrt werden Innerhalb von OFFIS www offis uni oldenburg de werden grafik orientierte Methoden entwickelt die es den Systementwickler erm glichen sollen vorwiegend grafische Beschreibungsmittel sowohl f r die Systeme als auch die Spezifikationen zu verwenden Grafische Methoden wurden gew hlt weil diese leichter zug nglich sind und somit eine h here Akzeptanz f r die Einf hrung formaler Methoden bieten Die Systembeschreibungen erfolgen hierbei mit Statemate die Spezifikationen werden mit symbolischen Zeitdiagrammen ausgef hrt die in Temporale Logik bersetzt werden k nnen Unter dem Titel KORSYS Korrekte Soft ware f r sicherheitskritische Systeme werden Verifikationstechniken f r eingebettete Systeme weiterentwickelt und angewendet www offis uni oldenburg de projekte damm KB_KORSYS html Der hierbei verwendete Model Checking Ansatz verwen det ein Modell des Systems das aus Statemate in Automaten bersetzt wird und die Darstellung der Eigenschaft in Formeln Fazit Wie die vorherigen Abschni
344. zt werden und die Bereitschaftsmeldung Ablageband ist zur bernahme eines Teils bereit muss unmittelbar zur ckgesetzt werden und das Startsignal Roboter be und entl dt Presse muss unmittelbar gesetzt werden AG rdy_in amp cell_l_state 1 amp Table_rdy_give amp Press_rdy_give amp Dbelt_rdy_take gt Al rdy_plc U rdy_plc amp Table_rdy_give amp Press_rdy_give amp Dbelt_rdy_take amp Robot_run_mix gt gt gt Satz 40 lt lt lt einfache Forderung direkt Wenn die Produktionszelle 1 im Automatikbetrieb ist und die Bereitschaftsmeldung Roboter wartet vor Presse ist gesetzt und die Bereitschaftsmeldung Presse ist f r Beladung bereit ist gesetzt dann muss die Bereitschaftsmeldung Roboter wartet vor Presse unmittelbar zur ckgesetzt werden und die Bereitschaftsmeldung Presse ist f r Beladung bereit muss unmittelbar zur ckgesetzt werden und das Startsignal Roboter weiter im Mix muss unmittelbar gesetzt werden m AG rdy_in amp cell_l_state 1 amp Robot_wait_mix amp Press_rdy_take gt Al rdy_plc U rdy_plc amp Robot_wait_mix amp Press_rdy_take amp Robot_run_cont gt gt gt Satz 41 lt lt lt einfache Forderung direkt 169 Formale Spezifikation reaktiver Systeme mit einer Sicherheitsfachsprache Wenn die Produktionszelle 1 im Automatikbetrieb ist und die Bereitschaftsmeldung Hubdreht
345. zt links Kran nimmt Teil aus Kran zum Ein gangspuffer fahren gt Eingangspuffer und legt F gt es auf Zuf hrband Zuf hrband transportiert Teil auf Hubdrehtisch gt gt Magnet einschalten vr gt Greifer anheben gt Roboter nimmt Teil vom gt Hubdrehtisch und legt es r gt Kran an gt in Presse Hubdrehtisch positioniert das Teil gt gt Greifer absenken gt 5 Rohteile gt aus Lager holen und zu Zelle 1 liefern l l l l l I L 1 1 1 1 I 1 D 1 1 1 1 1 1 r 1 l l l l l gt l Zale Tabholen nd gt Magnet ausschalten in Lager ablegen Roboter nimmt Teil aus gt der Presse und legt es auf Ablageband 5 Teile vom 5 Teile in J Typ xy fertigen Zelle 1 fertigen L gt Greifer absenken gt Presse bearbeitet das Teil 5 Fertigteile an i e gt Greifer anheben gt Ablageband transportiert das Teil zum Kran gt Kran nimmt Teil vom gt Ablageband und legt es in Ausgangspuffer I l l l 1 1 1 1 1 D 1 1 1 1 1 1 1 1 k 1 I l l l l l l L l l l l 1 1 1 1 r 1 1 l l l l l l t l l l l l l l 1 D 1 1 1 1 1 1 1 1 I Datenebene 1 Datenebene 2 Datenebene 3 Datenebene 4 Ger teebene 1 Ger teebene 2 Ger teebene 3 Ger teebene 4 Abbildung 27 Abstrakte Problemzerlegung als Funktionsbaum 82 Validierung des Prototypen anhand einer Fallstudie Da die zu ers

Formale Spezifikation reaktiver Systeme mit einer

Contents

Download Pdf Manuals

Related Search

Related Contents