DE19513801A1

DE19513801A1 - Verfahren zur automatischen Erzeugung einer Steuerung

Info

Publication number: DE19513801A1
Application number: DE19513801A
Authority: DE
Inventors: Klaus Dr Ing Winkelmann
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 1995-04-11
Filing date: 1995-04-11
Publication date: 1996-10-17
Also published as: CN1181822A; EP0820610B1; EP0820610A1; US6047278A; DE59601384D1; JPH11503543A; WO1996032667A1

Description

Die rationelle Entwicklung zuverlässiger Software für reakti ve Systeme, wie es Steuerungen aller Art sind, ist heute vor rangiges Ziel. Fig. 1 zeigt ein Prinzipbild eines Systems bestehend aus einer Steuerung und einem zu steuernden Prozeß. Die Steuerung muß so ausgeführt sein, daß der Prozeß nur zu lässige Zustände einnimmt. Der Steuerung werden an den Ein gängen Eingangswerte, z. B. Sensorwerte, zugeführt, die im folgenden Eingangszustände genannt werden. An den Ausgängen gibt die Steuerung Ausgangswerte, im folgenden Ausgangszu stände genannt, ab, die den Prozeß so beeinflussen, daß er nur die zulässigen Zustände annehmen kann.

Bei der Programmierung derartiger speicherprogrammierbarer Steuerungen sind jeweils folgende Vorgaben zu beachten:

- die Funktionsweise der zu steuernden Geräte oder Prozesse - d. h. was bewirkt jeder einzelne Ausgangszustand der Steue rung, und wie sind die Sensorwerte, die der Steuerung ge liefert werden, zu interpretieren.
- die von der Steuerung zu realisierende Funktion; z. B. Bewe gungsabläufe.
- ggf. vorhandene einschränkende Sicherheitsbedingungen; z. B. sind bestimmte Kombinationen von Zuständen, oder bestimmte geometrische Konfigurationen zu vermeiden, bestimmte Akto ren dürfen nur aktiviert werden, wenn zugehörige Vorbedin gungen (Verriegelungen) erfüllt sind etc.

Diese Vorgaben liegen jeweils in unterschiedlicher, meist in formeller Form vor. Das technische Problem besteht nun darin, eine Steuerung so zu programmieren, daß sie den Vorgaben ent spricht.

Im Gegensatz zu regelungstechnischen Aufgaben, bei denen die Theorie abhängig von Prozeßmodellen bestimmte (Standard-) Re gelungsalgorithmen kennt, müssen diskrete Steuerungsaufgaben jeweils neu programmiert werden.

Die Programmierung speicherprogrammierbarer Steuerungen ge schieht heute in der Weise, daß der Programmierer die logi schen Verknüpfungen festlegt, nach denen die Ausgangszustände sich aus den Eingangszustände und den Programmzuständen be stimmen.

Zur Programmierung von Abläufen existieren entsprechende Kon strukte von Programmiersprachen, um sog. Schrittketten und parallele Abläufe zu beschreiben. In jedem Fall ist es aber Sache des Programmierers, die Einhaltung der Funktion und der Sicherheitsbedingungen zu garantieren. M.a. W., der Zusammen hang zwischen dem Programm und den oben genannten Vorgaben ist nicht explizit dokumentiert.

Ein Problem bei diesem Vorgehen ist die Fehleranfälligkeit, denn schon bei mittelgroßen Systemen ist die Vielfalt der möglichen Systemzustände praktisch unüberschaubar groß; so werden nahezu immer Fälle übersehen, und bei der Inbetrieb nahme müssen mit erheblichem Aufwand Programme umgeschrieben werden.

Noch gravierender ist das Problem, daß jedes Umschreiben, sei es wegen eines Fehlers, wegen geänderter Umgebungsbedingungen oder wegen neuer Anforderungen, die ganze Software betrifft - d. h. es gibt keinen Mechanismus, der die Auswirkungen einer Änderung lokal hält oder auch nur die von einer Änderung be troffenen Stellen markiert.

Der Erfindung liegt die Aufgabe zugrunde, aus einer anwen dungsnahen Spezifikation einer Steuerungsaufgabe eine Steue rung zu erzeugen. Diese Aufgabe wird gemäß den Merkmalen von Patentanspruch 1 gelöst.

Weiterbildungen der Erfindung ergeben sich aus den abhängigen Patentansprüchen.

Die Erfindung wird anhand eines Ausführungsbeispiels erläu tert, unter Verwendung einer Spezifikationssprache, die CSLxt genannt werden soll.

1. Grundsätzliche Darstellung der Erfindung 1.1 Grundkonzepte von CSLxt

Die Erfindung geht davon aus, daß der Entwurfsprozeß für re aktive Systeme immer mit den folgenden Komponenten beginnt (Fig. 2):

- Beschreibung der zu steuernden Prozesse,
- Beschreibung der gewünschten Funktion des Gesamtsystems, und
- Sicherheitsanforderungen.

CSLxt umfaßt zum einen Sprachmittel, um die drei Komponenten der Spezifikation zu beschreiben, zum anderen die zur Gene rierung der Steuerung nötigen Verfahren.

Die tragenden Grundelemente des Ansatzes sind:

- die Spezifikation mit dem Konzept der endlichen Automaten,
- die Unterscheidung zwischen beeinflußbaren und nicht beeinflußbaren Zustandsgrößen, und
- die Konstruktion einer Steuerung durch Iterationsverfahren.

Dem Verfahren liegt die Vorstellung zugrunde, daß auf jedes Ereignis im Prozeß, d. h. jede Änderung der Sensorwerte, eine Reaktion der Steuerung, d. h. eine Änderung der Aktor- Stellungen (Ausgangs-Werte) erfolgt. Das Zusammenwirken von Steuerung und Prozeß wird als ein Zwei-Personen-Spiel aufge faßt, wobei die Steuerung ein bestimmtes Ziel verfolgt - näm lich Sicherheit und Funktion zu garantieren -, während der Prozeß als "Gegenspieler" dieses Ziel im ungünstigsten Fall zu verhindern sucht, jedenfalls aber nicht kooperiert. Nun wird das Verhalten des Prozesses (bzw. der Prozesse) als gegeben angenommen, die durch Sensorwerte beschriebenen Zu standsgrößen sind nicht (direkt) beeinflußbar. Dagegen sind die Aktoren von der Steuerung beeinflußbar. Das Verhalten der Steuerung - d. h. hier die Übergangsfunktion des Automaten, der die Steuerung beschreibt-, wird aus der Spezifikation des Ziels synthetisiert.

Dieser gesamte Generierungsprozeß läuft wie folgt ab:

1. Definition eines nicht-deterministischen Automaten, der alle physikalisch möglichen Verhaltensweisen beschreibt.
2. Beschreibung der erlaubten Zustands-Übergänge.
3. Einschränkung des durch 1. und 2. beschriebenen Automaten auf einen, der die Sicherheitseigenschaften erfüllt.
4. Einschränkung dieses Automaten auf einen, der die Funktion erfüllt.

Die letzten beiden Konstruktionsschritte machen intensiven Gebrauch von Iterationsverfahren im Zustandsraum des Gesamt systems. Dies kann verstanden werden als ein Vorausschauen der Steuerung auf die möglichen "Spielzüge". Hierin unter scheidet sich CSLxt wesentlich von den meisten anderen Spezi fikationsmethoden für reaktive Systeme, die die Übergangs funktion eines Automaten zwar auch berechnen, aber dabei im mer nur einen Schritt (einen "Zug", eine Transition) betrach ten.

Das Verfahren zu 3. ist gekennzeichnet durch die folgenden Ar beitsschritte:

- Es wird die (in einem zu präzisierenden Sinne) größte sta bilisierbare Teilmenge der als zulässig (sicher) spezifi zierten Zustandsmenge iterativ bestimmt.
- Die Übergangsfunktion wird dadurch eingeschränkt, daß nur Übergänge zu sicheren Zuständen erlaubt werden.

Das Verfahren zu 4. ist durch die folgenden Schritte gekenn zeichnet:

- die Funktion wird durch Angabe bedingter Zielzustände be schrieben.
- Es wird iterativ die Menge all derjenigen Zustände be stimmt, von denen aus der Übergang in einen Zielzustand in endlich vielen Schritten erzwungen werden kann.
- Die Übergangsfunktion wird dadurch eingeschränkt, daß, wenn immer möglich, solche Übergänge ausgeführt werden, die "näher" an den Zielzustand führen. Ein Zustand a ist dabei dem Ziel näher als ein Zustand b, wenn von a aus weniger Schritte als von b aus benötigt werden, um in den Ziel zu stand zu gelangen.
- Bei der Berechnung dieser Zustandsmengen wird berücksich tigt, daß für das Verhalten des gesteuerten Prozesses wohl definierte "Fairness"-Annahmen gelten, d. h. daß bestimmte Ereignisse jeweils nach einer nicht bekannten, aber endli chen Anzahl von Schritten eintreten müssen

1.2 Beispiel Hubdrehtisch, Fig. 3

Zur Illustration der Erfindung dient ein einfacher Hubdreh tisch, der hier kurz beschrieben wird:
Die Funktion des Hubdrehtisches ist es, ein Teil, das von ei nem Zuführband kommt, in eine Position zu heben und (um eine vertikale Achse) zu drehen, in der es dann ein Roboter grei fen kann.

Demgemäß gibt es die Befehle up, down und stop für die verti kale Bewegung sowie rotate_plus (abgekürzt rot_plus), rot_minus, rot_stop für die Drehbewegung.

Es gibt zwei Lichtschranken "low" und "high" für die vertika le Position, sowie ein analoges Signal, das den Drehwinkel meldet. Für die Eingänge machen wir jedoch durchgängig fol gende vereinfachende Annahme: eine Schnittstellenkomponente außerhalb der hier spezifizierten Steuerung setzt die Ein gangswerte so um, daß für die beiden Dimensionen jeweils ge nau einer von drei möglichen Werten vorliegt, nämlich low, between_low_high, oder high, und rot0, between_rot0_rot45, oder rot45.

Damit arbeiten wir effektiv mit diskretisierten (qualitativen) Werten.

Die Positionen (low, rot0) bzw. (high, rot45) entspricht da bei der Stellung, in der ein Teil vom Zuführband aufgelegt bzw. vom Roboter weggenommen werden kann.

Folgende Sicherheitsanforderungen sind beim Hubdrehtisch zu beachten:
"In der unteren Stellung (Sensor low = on) darf der Tisch nicht rotiert werden" (weil nämlich der Tisch sonst mit dem unmittelbar angrenzenden Zuführband kollidieren würde) bzw. im vorliegenden Kontext gleichbedeutend:
"In der unteren Stellung (low) ist nur der Drehwinkel 0 (rot0) zulässig" (Siehe Fig. 2, schraffierter Bereich = ver botene Zustände).

Für die Bewegung des Hubdrehtisches ergibt sich daraus, daß zwar eine gleichzeitige Bewegung nach oben und Drehung mög lich ist, aber erst nachdem die Höhe between_low_high er reicht wurde. Diese Art Einschränkung ist typisch für viele in der Automatisierungstechnik auftretende Parallelabläufe.

2. Prozeßmodellierung in CSLxt

Als Voraussetzung für die Konstruktion einer sicheren und korrekten Steuerung wird eine Beschreibung der Abläufe im (ungesteuerten) Prozeß verwendet, die im folgenden erläutert wird.

2.1 Vorgaben zur Anwendung von CSLxt

Bei den Zustandsattributen der Steuerung sind zu unterschei den:

- Eingangszustände oder Sensorzustände, die direkt von außen gesetzt werden können,
- Ausgangszustände, die direkt den Prozeß beeinflussen, und
- innere Zustände oder Steuerzustände.

Es trägt zur Klarheit bei, diese drei Arten auch syntaktisch in einem CSLxt-Programm zu unterscheiden.

Dies kann am Beispiel des Hubdrehtisches etwa wie folgt aus sehen:

Anmerkung: Die Sprache CSLxt dient hier der Illustration der Konzepte, ist aber in ihrer spezifischen Ausprägung nicht Ge genstand der Anmeldung. Daher wird die Syntax nicht vollstän dig beschrieben.

2.2 Prozeßmodellierung mit Constraints

Beim Prozeßmodell geht es darum, zu beschreiben, wie sich die Ausgangszustände auf Eingangszustände auswirken, d. h. welche Übergänge der Eingangszustände bei gegebener Belegung der Ausgänge möglich sind. Insofern ist die eingeführte Unter scheidung zwischen Eingangszuständen, Ausgangszuständen und inneren Zuständen die Basis des Prozeßmodells.

Das Prozeßmodell kann als endlicher Automat beschrieben wer den, der mit der Steuerung gekoppelt ist, d. h. er liest die Ausgangszustände und schreibt die Eingangszustände der Steue rung. Für die praktische Notation des Prozeßmodells wird je doch eine Darstellung gewählt, die diese Sichtweise nicht ex plizit macht. Aus Benutzersicht ist das Prozeßmodell ja schlicht ein Zusammenhang von Eingangszuständen und Ausgangs zuständen - die im folgenden vorgeschlagene Notation ist da her Teil einer CSLxt-Spezifikation. Dazu wird "process_description" als neues Konstrukt eingeführt, und an hand des folgenden Beispiels beschrieben.

Ein sehr einfaches, aber praktisch häufig auftretendes Bei spiel ist die Überwachung einzelner binärer Ausgänge durch direkt zugeordnete Sensoren, etwa "Ausgangszustand: Hebel öffnen, Eingangszustand: Hebel ist offen". Diese Art Zusam menhänge wird bisher nur im Kopf des Entwicklers, aber nicht formal verarbeitet - eine häufige Fehlerquelle.

Für die folgende Darstellung wählen wir ein anderes, etwas komplexeres Beispiel, das wiederum exemplarisch ist für einen häufig vorkommenden Typ von Ausgangs-Eingangs-Zusammenhängen: Ein Ausgangswert gibt die Richtung vor, in die sich ein be stimmter Eingangswert verändert bzw. verändern soll. Diese Situation liegt immer dann vor, wenn als Aktor ein Motor dient, der die Stellung einer Komponente in zwei Richtungen verändern kann.

Es wird hier angenommen, daß alle Prozeßwerte zu qualitativen Werten abstrahiert werden. Damit hat der Ausgang den Wertebe reich [stop, up, down] und der Eingang z. B. drei Werte wie [low, between_low_high, high].

Der zugehörige Ausschnitt aus dem Prozeßmodell könnte in ei ner anwendungsnahen Darstellung nun wie folgt aussehen:

Dies soll bedeuten, daß das Attribut moving_state die quali tative Ableitung des Attributs vertical_pos darstellt, wobei die genannten Werte auftreten.

Es werden natürlich neben qual_deriv weitere Varianten ge braucht, z. B. für mehr als drei Wert-Intervalle, evtl. für Motoren mit mehr als einer Geschwindigkeit, aber auch für Zu sammenhänge anderer Art. Allerdings ist der Anwendungsbereich des hier vorgestellten qual_deriv und seiner engen Verwandten größer als es die Vorstellung von einem "Motor" und einer me chanischen Position suggeriert.

Weitere Beispiele, die ebenfalls als qualitative Ableitung beschreibbar sind, umfassen:

- Ventilstellungen bzw. Pumpen als Aktoren und Füllstand- Sensoren,
- Heizung bzw. Kühlung als Aktor und Temperatur-Sensoren.

Nach dem hier vorgeschlagenen Konzept braucht also der Benut zer zur Spezifikation des Prozeßmodells die einzelnen Zu standsübergänge nicht detailliert zu beschreiben, sondern le diglich die vordefinierten qualitativen Constraints wie z. B. qual_deriv verwenden. Das Prozeßmodell für den Hubdrehtisch besteht dabei aus genau zwei Constraints, nämlich dem oben genannten und einem entsprechenden für die Rotation.

Dies ist ein zusätzlicher Aufwand, der für die pure Erzeugung einer Steuerung nicht notwendig wäre und in heutigen Steue rungssprachen daher auch nicht üblich ist. Er wird aber durch den Nutzen der automatischen Generierung gerechtfertigt.

3. Generierung der Steuerung mit Sicherheits-Eigenschaften

Im folgenden wird ausgeführt, wie aufgrund der Spezifikation einer Sicherheitseigenschaft ein Automatenprogramm so zu transformieren ist, daß es diese Eigenschaft erfüllt. Unter Sicherheitseigenschaft wird dabei eine beliebige aussa genlogische Bedingung in den Zustandsgrößen eines Automaten verstanden.

3.1 Spezifikation von Sicherheitseigenschaften

Ein Sprachkonstrukt, das zu diesem Zweck in CSLxt eingeführt wird, heißt "safety_requirements" und kann etwa wie folgt aussehen.

Die Semantik ist einfach dadurch definiert, daß die angegebe ne Bedingung in jedem erreichbaren Zustand des Automaten gel ten soll. Es ist dabei belanglos, ob mehrere Bedingungen oder eine Konjunktion von Bedingungen angegeben wird - unter prak tischen Gesichtspunkten (debugging) ist eine Liste von (evtl. auch benannten) Bedingungen vorzuziehen.

3.2 Lösung durch ein Minimax-Verfahren

Es wird nun das System aus Steuerung und gesteuertem Prozeß als ein Zwei-Personen-Spiel zwischen der Steuerung und dem gesteuerten Prozeß, wie folgt, betrachtet:
Abwechselnd machen die Spieler, Proc (Prozeß)und Ctrl (Steuerung) ihre Züge. Ziel des Spielers Ctrl ist es, inner halb der als sicher definierten Zustände zu bleiben. Proc agiert blind - um den ungünstigen Fall zu beherrschen, wird aber ein "Gegenspieler" eingeführt, der versucht, in einen unsicheren Zustand zu kommen. Jeder Spieler wird die mögli chen Gegenzüge berücksichtigen. Aus der Spieltheorie sind Mi nimax-Algorithmen als Verfahren bekannt, die für jeden Spie ler in dieser Situation die optimale Strategie beschreiben.

A priori gegeben ist eine Sicherheitsanforderung (safety_requirement) SR wie in 3.1. angegeben, und Aufgabe der Steuerung ist es, deren Einhaltung zu garantieren. Es ge nügt aber nicht, unmittelbare Zustandsänderungen in Zuständen außerhalb SR zu vermeiden, wie das Fig. 4 verdeutlicht, die eine graphische Darstellung der aufeinander folgenden Zustän de zeigt. Die Zustände von ctrl und proc sind als Kreise dar gestellt, deren Abhängigkeit voneinander durch Pfeile ver deutlicht sind. Die weiß unterlegten Kreise stellen erlaubte Zustände ZW dar, die grau unterlegten Kreise stellen Zustände ZG dar, die als gefährlich zu meiden sind, weil gilt: kommt das System in einen grauen Zustand, kann nicht mehr garan tiert werden, daß es nicht in einen verbotenen, illegalen Zu stand ZS kommt, der durch schwarze Kreise dargestellt ist. Aufgabe des Verfahrens ist es, solche "Sackgassen" zu vermei den.

Dabei ist zu beachten:

- Ein Zustand, in dem Proc am Zug ist, ist gefährlich, falls es einen gefährlichen Folgezustand gibt.
- Ein Zustand, in dem Ctrl am Zug ist, ist gefährlich, falls alle Folgezustände gefährlich sind.

Bei Fig. 4 hat Crtl ausgehend vom Zustand ZW1 zwei Möglich keiten. Wählt Crtl den linken Ast, folgt bei Proc ein gefähr licher Zustand ZG1. ZG1 ist gefährlich, weil Proc am Zug ist und ZG2 wählen könnte. ZG2 ist gefährlich, weil keine andere Wahl als ZG3 bleibt. ZG3 ist gefährlich, weil Proc am Zug ist, durch den der Zustand ZS1 gewählt werden könnte. Die an deren Zweige können entsprechend durchlaufen werden.

Die Menge der gefährlichen Zustände auszurechnen, ist deshalb möglich, weil die gesamte Zustandsmenge endlich ist und die genannten Bedingungen immer nur Zustände hinzufügen können. Eine Iteration muß also nach endlich vielen Schritten einen Fixpunkt erreichen.

Mit "Zustandsmengen" sind im folgenden immer Mengen von Zu ständen der Steuerung bezeichnet.

Für jede Zustandmenge P bezeichnet acx(P) die Menge all der Zustände, für die in einem Schritt ein Übergang in die Menge P erzwingbar ist.

Offensichtlich besteht acx(P) aus

- allen Zuständen, in denen die Steuerung am Zug ist, sofern es wenigstens einen Folgezustand in P gibt, sowie
- allen Zuständen, in denen der Prozeß am Zug ist und für die jeder Folgezustand in P ist.

Für jede Zustandmenge P bezeichne die "größte stabilisierbare Teilmenge von P" die größte Menge Q für die gilt

Q ist in P enthalten und
Q ist in acx(Q) enthalten.

Es wird zunächst dargestellt, wie die größte stabilisierbare Teilmenge, einer beliebigen Zustandsmenge berechnet werden kann:

Verfahren zur Konstruktion der größten stabilisierbaren Teil menge

Es sei P eine Zustandsmenge.

1. Setze Q₀ := P
2. Wiederhole Schritt 3 solange bis gilt Q_i = Q_i+1
3. Setze Q_i+1 := acx(Q_i) ∩ Q_i
(∩ steht für den Durchschnitt zweier Mengen)

Verfahren zur Konstruktion einer sicheren Steuerung

1. Setze SR := Menge der Zustände, die die spezifizierten safety requirements erfüllen.
2. Setze G := größte stabilisierbare Teilmenge von SR
3. Definiere die Funktion der Steuerung so, daß zu jedem Zu stand immer ein Folgezustand gewählt wird, der in G liegt.

Ergebnis des Verfahrens

Falls der Anfangszustand nicht zu G gehört, dann ist die Spe zifikation nicht erfüllbar. Andernfalls garantiert die Kon struktion gerade, daß für jedes Verhalten des Prozesses die Steuerung immer einen Zug (Transition) hat, die innerhalb der Zustandsmenge G bleibt.

4. Spezifikation der Funktion

Eine Steuerung, die nur sicher ist, ist von geringem prakti schen Wert. Es muß selbstverständlich auch garantiert sein, daß sie die gewünschte Funktion erfüllt. Im Sinne formaler Verfahren ist die erste Voraussetzung hierfür eine Spezifika tion dieser Funktion.

CSLxt kennt zwei sich ergänzende Sprachmittel zur Beschrei bung funktionaler Eigenschaften:

a) Spezifikation durch explizite Angabe von Transitionen
b) Deklarative Spezifikation durch Angabe bedingter Sollzu stände.

Punkt a) erfordert kein neues Verfahren und wird daher nur kurz behandelt (Abschnitt 4.1). Punkt b) ist eine Innovation von CSLxt und wird in Abschnitt 4.2. dargestellt.

4.1 Explizite Spezifikation

Dieser Abschnitt zeigt, wie die Funktion einer Steuerung be schrieben werden kann, so daß für die Einhaltung von Sicher heitseigenschaften das Verfahren aus Abschnitt 3. zum Einsatz kommen kann.

Zulässige Übergänge der Steuerung können z. B. in der gängigen Petri-Netz-Notation wie in Fig. 5 beschrieben werden. Dabei steht jeweils ein Kreis für einen Zustand der Steue rung, ein waagrecht er Strich für einen möglichen Übergang (Transition). Neben den Zuständen stehen Aktionen (Ausgangswerte) der Steuerung, neben den Transitionen Vorbe dingungen, die zum Zeitpunkt der Transition erfüllt sein müs sen, wie z. B. Sensor-Informationen.

Das Ergebnis des Minimax-Verfahrens besteht in diesem Bei spiel darin, daß an der im Diagramm mit ** bezeichneten Stel le automatisch eine zusätzliche Vorbedingung eingebaut wird, die das Einhalten der Sicherheitsbedingung (erst drehen, wenn vertikale Stellung im sicheren Bereich ist) garantiert. Wird die Automatentafel durch solche explizite Transitionen beschrieben, schränkt dies die Freiheiten ein, die für die Generierung der Sicherheit gebraucht werden. Läßt die expli zite Spezifikation keine solchen Freiheiten, kann die Sicher heitsgenerierung nicht mehr arbeiten. Ihr Ergebnis wäre dann

- entweder sind die Sicherheitseigenschaften ohnehin erfüllt
- oder sie können auch durch das Iterationsverfahren nicht erfüllt werden; dieses liefert dann das Ergebnis "not okay".

Daher ist bei der expliziten Spezifikation darauf zu achten, daß keine unnötigen Details festgelegt werden, sondern die Freiheiten, die aus technologischer Sicht bestehen, auch in der Spezifikation bestehen bleiben.

4.2 Deklarative Spezifikation

Im folgenden wird das Sprachmittel vorgestellt, das CSLxt zur deklarativen Spezifikation der funktionalen Eigenschaften bietet. Angestrebte Vorteile sind dabei

- Komplexitätsreduktion, d. h. Vereinfachung der Spezifikation durch Konzentration auf das Wesentliche, daher
- Elimination von Fehlerquellen,
- anwendungsnahe Formulierung der funktionalen Eigenschaften.

Das Konstrukt hat die Form

function: [Prae1 - Target1, Prae2 - Target2, . . . ]

d. h. es wird eine Liste von Paaren angegeben. Prae1, Target1 etc. stehen dabei für beliebige CSLxt-Bedingungen. Die Seman tik dieses Konstrukts ist beschreibbar wie folgt:
Target1 usw. geben die Soll- oder Zielzustände an. Ein Soll zustand wird jeweils abhängig von der zugehörigen Vorbedin gung Prae aktiviert. Genauer gilt für jedes Paar Prae - Tar get:
Solange Prae gilt, wird die Steuerung versuchen, einen Zu stand herzustellen, in dem Target gilt. Dieser wird erst ver lassen, wenn Prae nicht mehr gilt.

Im einfachsten Fall sind die Bedingungen Prae1, Prae2 usw. paarweise disjunkt - dies entspricht dem Umschalten zwischen verschiedenen Betriebszuständen. Es muß jedoch nicht der Fall sein.

Die Funktion des Hubdrehtischs wird mit dem function- Konstrukt wie folgt beschrieben werden:

Für jedes Paar Prae - Target wird eine separate Iterations konstruktion durchgeführt wie unter 4.3. beschrieben. Sie liefert als Ergebnis - wie für die Sicherheit - folgende In formationen

- Anfangszustand okay oder nicht okay, und
- Übergang okay oder nicht okay.

Falls beide Prüfungen "okay" ergeben, erfüllt die resultie rende Steuerung per Konstruktion die funktionale Eigenschaft. Andernfalls wird dies nicht garantiert.

4.3 Verfahren zur Funktions-Generierung

In diesem Abschnitt wird der Algorithmus zur Generierung der funktionalen Eigenschaften beschrieben.

Verwendete Bezeichnungen

- Delta bezeichne die Übergangsrelation der Steuerung. Diese ist zu Anfang vorbelegt mit einer Relation, die vorgegebene Einschränkungen darstellt, wie etwa nach Abschnitt 3 kon struierte Sicherheitseigenschaften.
Im Verlaufe des Verfahrens wird Delta weiter eingeschränkt, und bei erfolgreichem Ende des Verfahrens drückt sie am Schluß gerade die Lösung aus, d. h. die Steuerung, die die verlangte Funktion garantiert.
- Fair_i bezeichne die Menge, die durch folgende Bedingung ge kennzeichnet ist: "der aktuelle Prozeßschritt besteht in einer Aktion der i-ten Prozeßkomponente". Diese Bedingung wird auch als (i-te) Fairness-Bedingung bezeichnet. Hierin spiegelt sich die implizite Voraussetzung, daß jede unab hängige Komponente des Prozesses "immer wieder", d. h. je weils nach endlicher Zeit aktiv wird. Das Verfahren benutzt diese Annahme in folgender Weise: ein Fortschritt in Rich tung auf einen angestrebten Zustand ist auch dadurch er reichbar, daß das Eintreten einer Fairness-Bedingung einen solchen Übergang erzwingt.
- Für jede Zustandsmenge P bezeichne acx(P) die Menge all der Zustände, für die in einem Schritt ein Übergang in die Men ge P erzwingbar ist.

Die größte stabilisierbare Teilmenge von P kann berechnet werden wie unter 3. beschrieben.

Die Bezeichnungen win_n,j, winX_n, aux_n,i stehen für Zustands mengen, die im Laufe des Verfahrens berechnet werden:

Verfahren

Der folgende Algorithmus wird für jedes Paar "Prae - Target" durchgeführt.

(1) Setze win_0,0:= größte stabilisierbare Teilmenge von Tar get,
(2) wiederhole die Schritte (3) bis (10) für n = 0, 1, 2, . . . , solange bis gilt win_n+1,0 = win_n,0
(3) wiederhole die Schritte (4) und (5) für j = 0, 1, 2, . . . , solange bis gilt win_n,j+1 = win_n,j
(4) setze win_n,j+1 := win_n,j ∪ acx(win_n,j); d. h. Die Menge win_n,j+1 besteht aus allen Zuständen der Menge win_n,j zuzüglich der Zustände, von denen aus in einem Schritt ein Übergang in die Menge win_n,j erzwingbar ist,
(5) schränke die Übergangsfunktion Delta in der Weise ein, daß, wenn immer möglich, die Menge win_n,j+1 nicht mehr verlassen wird,
(6) setze winX_n := win_n,j,
(7) wiederhole die Schritte (8) und (9) für jede Fair ness-Bedingung Fair_i:
(8) setze aux_n,i := größte stabilisierbare Teilmenge von (winX_n ∪ (Menge der Zustände S, so daß gilt:
falls S in Fair_i liegt, dann ist jeder Folgezustand in winX_n)),
(9) schränke die Übergangsfunktion Delta in der Weise ein, daß, wenn immer möglich, die Menge aux_n,i nicht mehr verlassen wird,
(10) setze schließlich win_n+1,0 := aux_n,1 ∪aux_n,2 ∪ . . . ∪ aux_n,k.

Erfolgskriterium

Die erzeugte Steuerung ist dann korrekt, wenn am Schluß fol gendes gilt:

(1) Der Anfangszustand des Systems liegt in der Menge win_n,0.
(2) Für jeden Zustand in win_n,0 liegen auch alle Folgezustän de in win_n,0.

Im Fig. 6 ist das Verfahren nochmals als Ablaufplan darge stellt.

Nachfolgend wird ein komplettes Codebeispiel für den Hubdreh tisch angegeben:

Claims

1. Verfahren zur automatischen Erzeugung einer Steuerung für einen Prozeß,

a) bei dem ein nicht deterministischer Automat, der alle phy sikalisch möglichen Verhaltensweisen der Steuerung be schreibt, festgelegt wird,
b) bei dem die erlaubten Zustandsübergänge des von der Steue rung zu beeinflussenden Prozesses beschrieben werden,
c) bei dem der Automat so eingestellt wird, daß er vorgegebe ne Sicherheitsbedingungen erfüllt,
d) bei dem der Automat so eingestellt wird, daß er die Funk tion des aus Steuerung und Prozeß bestehenden Systems er füllt.

2. Verfahren nach Anspruch 1,
bei dem zur Einstellung der Sicherheitsbedingungen die größte stabilisierbare Teilmenge der als zulässig spezifizierten Zu standsmenge iterativ bestimmt wird,
bei dem die Übergangsfunktion des Automaten so eingestellt wird, daß nur jeweils Folgezustände gewählt werden, die in dieser größten stabilisierbaren Menge liegen.

3. Verfahren nach Anspruch 2, bei dem zur Einhaltung der Sicherheitsbedingungen für das Sy stem aus Steuerung und Prozeß folgende Zustände bei der Rea lisierung ausgeschlossen werden:
jeder Zustand der Steuerung, bei dem alle Folgezustände die Sicherheitsbedingungen nicht erfüllen
jeder Zustand des Prozesses, bei dem mindestens ein Folgezu stand die Sicherheitsbedingungen nicht erfüllt.

4. Verfahren nach einem der vorhergehenden Ansprüche, bei dem zur Einstellung der Funktion des Systems

- die Funktion durch Angabe bedingter Zielzustände definiert wird,
- iterativ die Menge all derjenigen Zustände bestimmt wird, von denen aus der Übergang in einen Zielzustand in endlich vielen Schritten erzwungen werden kann,
- die Übergangsfunktion dadurch eingeschränkt wird, daß, wenn möglich, solche Übergänge ausgeführt werden, die zum Ziel zustand führen.