Durch die Basisanalyse haben wir eine Hierarchie auf Basisprozessen erhalten, die in einem Basissystem auszuführen sind. Die Steuerung hat nun die Aufgabe, die Basisprozesse so zu steuern, daß alle globalen Aufträge erfüllt werden. Dabei sollen gewisse Kriterien, wie die Einhaltung von Terminen, eine möglichst hohe Maschinenauslastung und eine möglichst geringe Durchlaufzeit für die Aufträge, berücksichtigt werden.
Auf der Grundlage der Fundamentalrelation kann jedem Basisprozeß eindeutig ein Steuerungsprozeß zugeordnet werden. Dieser ist für die Ausführung des Basisprozesses verantwortlich. Dazu ist es notwendig, daß der Steuerungsprozeß in der Lage ist, den Basisprozeß und seine Teilprozesse zu starten, seine Ausführung zu überwachen und das Ende des Prozesses zu erkennen. Wenn diese Voraussetzungen nicht gegeben sind, kann der Steuerungsprozeß den Basisprozeß nicht steuern.
Da durch die Basisanalyse nicht jeder konkrete Prozeß erfaßt werden kann, stellen die erkannten Basisprozesse nur Repräsentanten konkreter Prozesse dar, d.h., jedem Basisprozeß aus der Basisanalyse ist eine Klasse von konkreten Operationen zugeordnet.
Daraus ergibt sich, daß auch den Steuerungsprozessen Klassen von Basisprozessen zugeordnet werden. Dies sind i.a. die Operationen, die auf einem bestimmten Operator ausgeführt werden. Somit erscheint ein Steuerungsprozeß meistens einem Operator zugeordnet, dessen Operationen er zu steuern hat. Diese Zuordnung hat sich bisher als die zweckmäßigste erwiesen, ist jedoch nicht unbedingt notwendig. Wichtig ist lediglich die Feststellung, daß einer Klasse konkreter Operationen ein konkreter Steuerungsprozeß zugeordnet ist.
Ein Steuerungsprozeß führt eine angewiesene Operation (wir wollen diese Auftrag nennen) aus, indem er sie aufgrund der Basisprozeßanalyse in Teilprozesse zerlegt und diese einem anderen Steuerungsprozeß anweist. Ist durch die Basisanalyse keine Dekomposition des Auftrages vorgesehen, muß die Ausführung dessen über Effektoren an der Basis ausgelöst werden und der Fortschritt bzw. das Ende der Bearbeitung über Rezeptoren ermittelt werden. Gegebenenfalls ist eine Steuerung des Prozesses über weitere Effektoren notwendig. Solche Prozesse werden meist über CNC-Steuerungen realisiert, die Beschreibung des Prozesses ist implizit im NC-Programm enthalten.
Durch die Zuordnung von Basisprozeßklassen zu Steuerungsprozessen und durch Anwendung der Basisprozeßstruktur auf die Kopplung der Steuerungsprozesse erhalten wir eine hierarchische Steuerungsprozeßstruktur.
_____ _____
|o1 A| +--->| A |<---+
|_____| | |_____| |
_______/ \_______ | |
V V
/_____ _____ _____\ _____ _____
|o2 B|->|o3 B|->|o4 C| +--->| B |<--+ +-->| C |
|_____| |_____| |_____| | |_____| | | |_____|
__/ \__ / \ | ^ | | ^
/ \ / \ | | | | |
/_____ \ / \ | | | | |
|o5 D| ! / \ V V V | V
|_____| _____! !_____ _____! _____ _____ _____ _____
\-->|o7 E| |o8 F|->|o9 G| | D | | E | | F | | G |
_____/-->|_____| |_____| |_____| |_____| |_____| |_____| |_____|
|o6 F|
|_____|
_____ _____
|o S| o - Bezeichner der Operation | S | S - Bezeichner des
|_____| S - zugeordneter Steuerungsprozeß |_____| Steuerungsprozesses
Hierarchie der
Basisprozesse Steuerungsprozesse
Beziehungen zwischen Basis- und Steuerungsprozeßstruktur
Dabei sind Steuerungsprozesse, die dekomponierbare Basisprozesse steuern, den Steuerungsprozessen für die Basisteilprozesse übergeordnet. Steuerungsprozesse, denen Basisprozesse der gleichen Ebene zugeordnet sind, liegen in der Steuerungshierarchie auch auf gleicher Ebene. Sie werden durch ihre übergeordneten Steuerungsprozesse (von denen es mehrere geben kann, vgl. Prozeß F für o6 und o8) koordiniert und kommunizieren in der Regel nicht miteinander. Kommunikationsmöglichkeiten auf derselben Ebene ergeben sich lediglich durch Austausch von Informationen, beinhalten jedoch keine Anweisungen oder Rückmeldungen. Somit entspricht jedem Niveau der Basisanalyse eine Steuerungsprozeßebene. Die erhaltene Steuerungsprozeßstruktur ist aber nicht unbedingt eine Koordinationsstruktur.
Häufig sind nicht alle zur Steuerung eines Basisprozesses notwendigen Informationen automatisch zu erhalten. Dies betrifft insbesondere solche Informationen, die bei Störungen in der Basis benötigt werden, um eine ordnungsgemäße Fehlerbehandlung durchzuführen. Es kann auch der Fall auftreten, daß über die Art der Fehlerbehandlung keine Entscheidung getroffen werden kann (fehlende Informationen oder aufwendige Algorithmen). In den meisten Fällen kann der Mensch mit seinem Erfahrungsschatz besser und schneller entscheiden, was zu tun ist. Aus diesem Grund muß dem Menschen die Möglichkeit gegeben werden, in den Steuerungsprozeß einzugreifen. Dies setzt voraus, daß er sich zu jedem Zeitpunkt über den Ablauf des Steuerungsprozesses informieren können muß. Beobachtung und Eingriff in den Steuerungsprozeß sind Aufgabe eines Dispatchingprozesses. Prinzipiell kann jedem Steuerungsprozeß ein Dispatchingprozeß zugeordnet werden, wobei stets zu prüfen ist, ob eine solche Zuordnung notwendig und sinnvoll ist. Die Implementation der Dispatchingprozesse erfolgt meist auf den Rechnern der höheren Ebene (vgl. MOLLO).
Ein weiteres Problem der Prozeßsteuerung ist die Beachtung von Optimierungskriterien. Dieses Problem wird besonders auf den oberen Steuerungsebenen akut, da Entscheidungen dieser Steuerungsprozesse weitreichende Folgen für den weiteren Prozeßablauf im Basissystem haben. Untergeordnete Ebenen der Steuerung haben dagegen nur einen begrenzten Entscheidungsspielraum, so daß dieses Problem hier nicht im Vordergrund steht. Für die Lösung des Problems muß eine Optimierungsaufgabe gelöst werden. Um dabei gute Ergebnisse zu erreichen, müssen häufig umfangreiche und komplizierte Algorithmen abgearbeitet werden. Das kann sich ein Steuerungsprozeß in der Regel jedoch nicht leisten, da seine Reaktion auf Ereignisse im Basisprozeß so kurz wie möglich sein muß. Deshalb muß jedem Steuerungsprozeß, der solche Entscheidungen zu treffen hat, ein Prozeß der operativen Planung zugeordnet werden, der takt- und/oder ereignisorientiert die Planung der anstehenden Aufgaben ausführt. Die Planungsprozesse können dabei selbständig oder untereinander gekoppelt sein. Möglich ist auch die Ausführung der Planung durch den Menschen. Hierbei ist aber zu beachten, daß diese Planung nicht über die Dispatchingschnittstelle, sondern über die Planungsschnittstelle des Steuerungsprozesses zu erfolgen hat. Ob eine automatisierte Planung mit oder ohne menschliche Unterstützung erfolgt, ist für den Steuerungsprozeß primär unwesentlich.
Damit die Prozesse der Steuerung entsprechend ihren Aufgaben zusammenarbeiten können, muß ein Kommunikationsmedium vorhanden sein. Alle Prozesse, die miteinander verbunden sind, müssen Zugriff zu diesem Medium besitzen. Wir können hier wieder unterscheiden zwischen logischer Kommunikation und physischer Realisierung.
Notwendig ist die Definition des logischen Inhalts der Kommunikation oder, anders ausgedrückt, des Anwender- (A-) Protokolls. Dazu gehört, welche Sendungstypen verwendet werden und welche Reaktionen der Empfänger einer Sendung auszuführen hat. Für Steuerungsprozeßstrukturen werden die Haupttypen von Sendungen in ENGELIEN/STAHN 1989 beschrieben. Dies sind:
Durch Weisungen wird ein Steuerungsprozeß aufgefordert, eine bestimmte Aktion auszuführen. Meist besteht diese Aktion darin, die Steuerung eines bestimmten Basisprozesses zu übernehmen. Meldungen sind Sendungen, in denen der untergeordnete Steuerungsprozeß einen übergeordneten Prozeß über den Verlauf einer angewiesenen Aktion unterrichtet. Sie können das Ende der Operation beinhalten oder Unterbrechungen, Wiederanläufe und dergleichen. Anfragen dienen dazu, bestimmte Informationen über den Zustand eines Steuerungsprozesses oder dessen Entitäten zu erhalten. Antworten sind die Sendungen, mit denen auf Anfragen reagiert wird.
Totmannsignale sind solche Sendungen, die ein Prozeß unaufgefordert an einen anderen Prozeß schickt um ihm mitzuteilen, daß er noch arbeitet. Sie dienen zur gegenseitigen Überwachung der Funktionsfähigkeit der Steuerungen. Sendungen, durch die der Empfang einer anderen Sendung quittiert wird, heißen Echos. Echos und Totmannsignale gehören nicht zum eigentlichen A-Protokoll, da sie "nur" Diagnosezwecken dienen. Sie sind damit für die Steuerung nicht unbedingt notwendig. In Abhängigkeit von den konkreten Voraussetzungen für die Kommunikation sollte jedoch bereits festgelegt werden, welche Sendungen geechot werden müssen bzw. welche Prozesse an wen Totmannsignale zu senden haben.
Die Gestaltung des Kommunikationsprotokolls kann zwar unabhängig von der verfügbaren Hardware durchgeführt werden, sollte diese aber schon berücksichtigen. Beispielsweise dürfen in Off-Line-Kommunikationssystemen keine Echos oder Totmannsignale vor kommen, da dies mit einer hohen Belastung für den Bediener verbunden ist.
Nachdem wir die Struktur der Steuerungsprozesse festgelegt haben, ist es uns möglich, diese in die vorgegebene oder in eine zu entwerfende Hardware-Struktur einzubetten. Dazu ordnen wir jedem Steuerungsprozeß ein konkretes informationsverarbeitendes System zu, daß diesen Steuerungsprozeß ausführt. Die Zuordnung ist lediglich eindeutig, d.h., ein Rechner (als informationsverarbeitendes System) kann auch mehrere Steuerungsprozesse ausführen, im Extremfall sogar alle. Wichtig ist, daß die Verbindungen der Steuerungsprozesse untereinander auch von der Hardware realisiert werden können (lokale Netze, Punkt-zu-Punkt-Verbindungen, Off-line-Kopplungen via externe Datenträger o.ä.). Kann die Hardware diese Verbindungen nicht gewährleisten, so ist die Steuerung nicht implementierbar.
Neben der Hardware-Struktur der Steuerung müssen wir auch die Software-Struktur festlegen. Sie ist insbesondere dann vonnöten, wenn mehrere Prozesse auf einem Rechner ausgeführt werden sollen. Die Software-Struktur als Bestandteil des triadischen Automaten (vgl. HERLITZIUS et.al./S. 85ff.) hängt von der verwendeten Technik und den Betriebssystemen der Rechner ab. Sie stellt eine Struktur auf Programmen, Routinen, Tasks, Overlays oder anderen Software-Elementen dar.
Jedem Prozeß der Steuerungsprozeßstruktur wird eindeutig ein Software-Element zu seiner Ausführung zugeordnet. Die Abbildung muß nicht eineindeutig sein, da verschiedene Prozesse, die die gleiche Struktur besitzen auch mit der gleichen Software bearbeitet werden können. Die Software hat neben der Ausführung der Prozesse auch deren Kommunikation zu sichern. Dies muß bei der Gestaltung der Software-Struktur berücksichtigt werden.
Im allgemeinen müssen die Steuerungsprozesse parallel arbeiten können. Deshalb scheinen für Prozeßsteuerungen nur echtzeit- und multitaskfähige Rechner und Betriebssysteme in Betracht zu kommen (MOOS 1600, KOMI, UNIX). Durch spezielle Software-Konzepte läßt sich eine quasi-parallele Ausführung von Prozessen auch auf single user/single task - Systemen unterstützen. Zu diesen Konzepten gehört auch das des Zustandsgrapheninterpreters. Beim Entwurf von Software-Systemen müssen damit, neben der Struktur der Software und dem verwendeten Betriebssystem auch bestimmte Regeln für die Implementation festgelegt werden.
Für die Implementation von Steuerungen, die in der beschriebenen Art und Weise entworfen wurden, hat sich das Zustandsgrapheninterpreterkonzept bewährt. Es wurde sowohl für die Simulation der Basis realer Steuerungen (GRZELACHOWSKI, ENGELIEN/STAHN 1989) eingesetzt als auch zur Implementation der Steuerung selbst (GESERICH/LANGENICKEL, STURM, HOCHSTÄDT).
| voriger Abschnitt | Inhalt der Dissertation |
|
<F>-soft Homepage |
nächster Abschnitt |
Original © 1990 by Dresden University
of Technology; Dept. of Information Science; Applied Computer Science