8. Entwurf und Implementation der FMS-Koordination

8.1. Herleitung der Entitäten und ihrer Struktur

Da die Beschreibung der Gesamtheit der Steuerungsprozesse für ein Flexibles Fertigungssystem den Rahmen dieser Arbeit sprengen würde, beschränken wir uns hier auf die Darstellung der Systemkoordination. Entsprechend der in Kapitel 6 abgeleiteten Steuerungsprozeßstruktur hat die Systemkoordination die Basisprozesse 'FMS-Auftrag' und 'Palettenauftrag' zu steuern.

Für diese Basisprozesse können wir die zugeordneten Basiselemente bestimmen.

Elemente der Basis für die Systemkoordination

Übergeordnete Prozeßeinheit Untergeordnete Prozeßeinheiten Systemelemente Operandeneinheiten
FMS-Auftrag Spannzellenauftrag
Palettenauftrag
Spannzelle
FMS-"Rest"
Teile
Paletten
Palettenauftrag Bearbeitungszellenauftrag
Bereitstellungsoperation
Virtuelle Zellen
VWP-Operator
Paletten mit Teilen
Werkzeugsätze

Nun müssen wir erneut die Beziehungen der Basiselemente zueinander beschreiben, jedoch unter den sich aus dem Steuerungsentwurf ergebenden Gesichtspunkten. Dieser Schritt ähnelt in vielem der Basisanalyse, stellt er doch in gewisser Weise eine Basisanalyse für die Systemkoordination dar. Wir erhalten damit eine Menge von Aussagen über den Ablauf der Steuerung.


            ________________________________________
           |                                        |
           |           FMS-Koordination             |
           |________________________________________|
                  |                          ^
                  V                          |
            ________________________________________
           |                                        |
           |      Palettenauftragskoordination      |
           |________________________________________|


Prozeßstruktur der Systemkoordination (ohne Schnittstellen nach außen)



Da auch auf die Basisprozesse der Systemkoordination die Methoden der Steuerungsprozeßstrukturierung angewandt werden können, erhalten wir zwei Ebenen der Systemkoordination: die FMS-Koordination und die Palettenauftragskoordination, von denen wir hier nur die FMS-Koordination betrachten wollen.

Zunächst analysieren wir die Aufgaben der FMS-Koordination, die sich aus der Basisanalyse ergeben:

  1. Ein FMS-Auftrag kann in ein System von Operanden- und Prozeßstrukturen dekomponiert werden. Operanden sind die dem Auftrag zugeordneten Teile und zeitweilig zugeordneten Paletten, die Prozeßstruktur enthält Spannaufträge und Palettenaufträge.
  2. Spannaufträge werden von den Spannzellen ausgeführt. Ihre Bearbeitung erfolgt durch die virtuellen Zellen der Spannplätze.
  3. Spannaufträge können angewiesen werden, wenn die dazu erforderliche Anzahl von Teilen und eine Palette zur Verfügung steht bzw. wenn ein Palettenauftrag beendet wurde.
  4. Die Spannzellensteuerungen können eine beliebige Anzahl von Spannaufträgen gleichzeitig hantieren, es kann ihnen aber nicht zu jeder Zeit ein Spannauftrag angewiesen werden (bedienerarme 3. Schicht).
  5. Durch Beendigung eines Spannauftrages entstehen Paletten mit Teilen bzw. Einzelteile.
  6. Palettenaufträge werden im 'FMS-"Rest"' bearbeitet. Sie werden zur Bearbeitung an die Palettenauftragskoordination der Systemkoordination angewiesen. Palettenaufträge werden durch die Palettenauftragskoordination weiter dekomponiert.

Aus diesen Feststellungen läßt sich eine Struktur der Basiselemente für die FMS-Koordination ableiten. Die Relationen zwischen den Elementen der Struktur ergeben sich aus den angeführten Aussagen.


                         _______________
         +------------->|               |<-------------+
         |              |  FMS-Auftrag  |              |
         |              |_______________|<--+          |
         |                                  |          |
         |                                  |          |
         |                                  V          |
         |   _______________         _______________   |
         |  |               |       |               |  |
         |  |    Palette    |<----->|     Teil      |  |
         |  |_______________|       |_______________|  |
         |     ^        ^                       ^      |
         |     |        +---------------+       |      |
         |     V                        V       V      |
         |   _______________         _______________   |    
         |  |               |       |               |  |    
         +->|Palettenauftrag|<----->| Spannauftrag  |<-+    
            |_______________|       |_______________|       
                    ^                       ^
                    |                       |
                    V                       V
             _______________         _______________ 
            |               |       |               |
            |  FMS-"Rest"   |       |  Spannzelle   |
            |_______________|       |_______________|


Beziehungen der Basiselemente der FMS-Koordination



Da prinzipiell jedes Basiselement ein Operand der Steuerung, d.h. eine Entität werden kann, müssen wir die Beziehungen zwischen den Basiselementen unter dem Aspekt der Steuerungsaufgabe analysieren.

Die FMS-Aufträge bilden die Voraussetzung für die Arbeit der FMS-Koordination. Ihnen sind Fertigstellungstermine, Prioritäten und andere Informationen zugeordnet, die für die Realisierung eines FMS-Auftrages notwendig sind. Schon die eindeutige Zuordnung solcher Informationen rechtfertigt die Hantierung der FMS Aufträge als Entitäten.

Durch die Dekomposition der FMS-Aufträge ergeben sich die Beziehungen zwischen Spannaufträgen, Palettenaufträgen, Teilen und Paletten. Die Dekomposition als informationeller Prozeß führt also zur Erzeugung von Entitäten, die diesen Basiselementen zugeordnet sind. Dieser Prozeß kann kein einmaliger Vorgang sein, da die einen FMS-Auftrag beschreibende Prozeßstruktur nicht operandenunabhängig ist. Er muß also bei Bedarf und unter Berücksichtigung der bereits existierenden Spann- bzw. Palettenaufträge ausgeführt werden.

Da konkrete Spann- und Palettenaufträge nicht unbedingt einem konkreten FMS-Auftrag zugeordnet werden können (mehrere Teile verschiedener Aufträge auf einer Palette), kann die Beendigung eines FMS-Auftrages nur an der vollständigen Bearbeitung aller seiner Teile erkannt werden.

Teile und (konkrete) Spann- und Palettenaufträge werden damit zu Entitäten der FMS-Koordination. Anders sieht es mit den Paletten aus. Diese sind (falls belegt) eindeutig einem Palettenauftrag zugeordnet. Da davon ausgegangen wird, daß immer genügend eingerichtete Paletten für Aufspannoperationen zur Verfügung stehen (Abschnitt 4.2.) und ihnen auch keine weiteren Informationen zugeordnet werden müssen, brauchen sie nicht explizit als Entität hantiert werden. Es genügt, wenn die Teile, die auf den Paletten gespannt sind, den Paletten- bzw. Spannaufträgen zugeordnet werden. Anders wäre es, müßten wir auch die Anzahl entsprechend eingerichteter Paletten berücksichtigen. Dann müßten die Paletten als Entität geführt werden.

Da Paletten- und Spannaufträge von anderen Steuerungsprozessen ausgeführt werden, erscheint es auf den ersten Blick nicht notwendig, Spannzellen und FMS-"Rest" als Entitäten zu hantieren. Für den FMS-"Rest" trifft dies auch zu, da von ihm (bzw. der Palettenauftragskoordination) stets Palettenaufträge ausgeführt werden können. Die Spannzellen können aber nicht zu jeder Zeit einen Auftrag annehmen. Aus diesem Grund muß der FMS-Koordination bekannt sein, ob zu einem gegebenen Zeitpunkt Spannaufträge ausgelöst werden können. Diese Information kann keiner bisher angeführten Entität eindeutig zugeordnet werden, so daß Spannzellen als Entitäten hantiert werden müssen.

Übrigens ist, streng genommen, für die Systemkoordination nicht die Spannzelle, sondern ihre Koordination der ausführende Operator für die Spannaufträge. Um eine größtmögliche Einheitlichkeit zwischen Basisanalyse und Steuerungsentwurf zu erzielen, hantieren wir hier die Spannzelle und nicht ihre Steuerung als Entität, wohl wissend, daß wir alle Informationen nur durch letztere erhalten.

Somit entsteht eine erste Entitätsstruktur für den Steuerungsprozeß FMS-Koordination. Da in dieser alle Entitäten, die aus der Basisanalyse abgeleitet werden können, enthalten sind, wollen wir diese Struktur "funktionale Entitätsstruktur" nennen. Sie enthält bisher lediglich die Entitäten, die für die Hauptfunktionen des Steuerungsprozesses erforderlich sind. Sobald noch andere, nicht aus der Basisanalyse abgeleitete Steuerungsprozesse berücksichtigt werden (Planung, Dispatching, Kommunikation), muß diese Struktur erweitert werden. Dabei betreffen die notwendigen Erweiterungen sowohl neu aufzunehmende (Steuerungs-) Entitäten und deren Beziehungen zu den bisher vorhandenen als auch neue Beziehungen der letzteren untereinander.

Die Beziehungen der Entitäten untereinander werden durch den Austausch von Nachrichten realisiert. Dazu ist es notwendig, daß es Abbildungen der Entitäten aufeinander gibt. Diese, analog der "Bekanntschaften" des Actor-Modells, dienen der Bestimmung und Identifizierung des Empfängers einer bestimmten Nachricht.


                         _______________
         +------------->|               |<-------------+
         |              |  FMS-Auftrag  |              |
         |              |_______________|<--+          |
         | a                                | b      c |
         |                                  |          |
         |                                  V          |
         |                           _______________   |
         |                          |               |  |
         |          +-------------->|     Teil      |  |
         |          |               |_______________|  |
         |          |                       ^          |
         |          | d                     | e        |
         |          V                       V          |
         |   _______________         _______________   |    
         |  |               |   f   |               |  |    
         +--|Palettenauftrag|<----->| Spannauftrag  |--+    
            |_______________|       |_______________|       
                                            |
                                            | g
                                            V
                                     _______________ 
                                    |               |
Erläuterung der Kanten-             |  Spannzelle   |
bewertung erfolgt im Text           |_______________|


Funktionale Entitätsstruktur der FMS-Koordination



Für die FMS-Koordination ergeben sich die folgenden Abbildungen und Nachrichten:

  1. Die zu einem Palettenauftrag notwendigen Informationen sind in der Technologie eines (beliebigen) zugeordneten FMS-Auftrag enthalten. Diese umfassen die für die FMS-Koordination nicht relevanten Informationen, die an die Palettenauftragskoordination übergeben werden müssen. Die Zuordnung existiert nur in der Form
    Palettenauftrag --> FMS-Auftrag (Technologie)
    Sie wird bei der Erzeugung des Palettenauftrags durch ein Teil generiert und besteht für die Dauer der Existenz des Palettenauftrags.
  2. Jedem FMS-Auftrag sind alle zu seiner Realisierung notwendigen Teile zugeordnet. Diese werden von ihm erzeugt. Den Teilen ist wiederum der FMS-Auftrag zugeordnet, der benachrichtigt werden muß, wenn die Bearbeitung eines Teils beendet wird. Weiterhin nutzen die Teile die technologischen Informationen des FMS Auftrages für die Ermittlung der aktuell auszuführenden Operation und die Generierung von Palettenaufträgen. Zuordnungen:
    FMS-Auftrag --> Menge von Teilen
    Teil --> FMS-Auftrag
    Die Zuordnungen werden bei Beendigung des FMS-Auftrags aufgehoben.
  3. analog a: für die Spannoperationen
  4. Jedem Teil ist der aktuell auszuführende Palettenauftrag, der dieses Teil enthält zugeordnet, falls er existiert. Ebenso ist jedem Palettenauftrag eine Menge von Teilen zugeordnet, die sich auf der dem Palettenauftrag zugeordneten Palette befinden. Palettenaufträge werden von Teilen erzeugt, die nicht einem schon existierenden Palettenauftrag zugeordnet werden können. Teile benachrichtigen noch nicht vollständige Palettenaufträge darüber, daß sie ihnen zugeordnet werden. Andererseits informieren die Palettenaufträge die Teile über die Beendigung und das Ergebnis der Bearbeitung. Zuordnungen:
    Palettenauftrag --> Menge von Teilen
    Teil --> Palettenauftrag
    Die Zuordnungen werden durch die Teile erzeugt und durch die Beendigung des Palettenauftrags aufgehoben.
  5. Den Spannaufträgen, zu denen auch Ein- bzw. Ausschleusen gehören, sind die Menge der zu hantierenden Teile zugeordnet. Sie benachrichtigen die Teile über die Beendigung des entsprechen den Spannauftrags. Ein- und Ausschleusaufträge werden von den Teilen entsprechend dem Stand ihrer Bearbeitung erzeugt. Dabei erfolgt auch die Zuordnung, die bei Beendigung der Spannaufträge wieder aufgehoben wird. Die Erzeugung der Auf- und Abspannaufträge wird von den Palettenaufträgen initiiert, da zwischen diesen eine eindeutige Zuordnung besteht (siehe f:). Zuordnungen:
    Teil --> Spannauftrag (für Teil, ergo nur Ein- oder Ausschleusen)
    Spannauftrag --> Menge von Teilen
  6. Ist ein Palettenauftrag vollständig zusammengestellt oder sind die Voraussetzungen für eine "unvollständige" Bearbeitung des Palettenauftrags gegeben, erzeugt dieser einen Spannauftrag zum Aufspannen seiner Teile. Dieser ist bis zu seiner Beendigung dem Palettenauftrag zugeordnet. Wird ein Palettenauftrag beendet, erzeugt er einen Abspannauftrag, der dem Palettenauftrag nicht fest zugeordnet ist, da seine Beendigung für einen Palettenauftrag nicht mehr relevant ist. Zuordnung:
    Palettenauftrag --> Spannauftrag
    Spannauftrag --> Palettenauftrag
  7. Einem Spannauftrag kann eindeutig eine Spannzelle zugeordnet werden, die seine Ausführung übernimmt, wenn dies die Spannzelle zuläßt. Eine umgekehrte Zuordnung ist nicht notwendig. Zuordnung:
    Spannauftrag --> Spannzelle

8.2. Die funktionalen Zustandsgraphen der FMS-Koordination

Der Erarbeitung der Zustandsgraphen für die Entitäten der FMS-Koordination legen wir die im vorigen Abschnitt erarbeitete funktionale Entitätsstruktur zugrunde. Dabei bleiben die Einflüsse von Planung, Dispatching, Kommunikation und anderen Steuerungsprozessen unberücksichtigt. Wir haben als erstes die den Entitäten zugeordneten Informationen festzulegen. Diese wollen wir klassifizieren in relativ konstante Informationen (die zur Erzeugung festgelegt werden und von den betrachteten Entitäten nicht mehr verändert werden können; ohne Kennzeichnung), Verkettungen zwischen den Entitäten (Kennzeichen V) und Zustandsmerkmale (Kennzeichen Z).

FMS-Auftrag

Palettenauftrag

Spannauftrag

Teil

Spannzelle

Wir erkennen, daß wir für jede Entität einen Zustandsgraphen entwerfen müssen. Selbstverständlich geben wir nur die Repräsentanten der Zustandsgraphen einer Entitätsklasse an, da die Zustandsgraphen für jede Entität einer Klasse paarweise isomorph zueinander sind.


Der FMS-Auftrag muß von seiner Anweisung bis zu seiner Fertigstellung von der Steuerung hantiert werden. Durch die Weisung des übergeordneten Steuerungsprozesses (Organisation) wird er für die Systemkoordination 'existent'. Mit dieser Anweisung verbindet sich die Generierung aller zu ihm gehörenden Teile. Der Zustand 'in Arbeit' drückt aus, daß die Bearbeitung mindestens eines Teils erfolgt. Ist die Bearbeitung aller Teile abgeschlossen, ist der FMS-Auftrag 'beendet'. Einen Zustand 'wartend' mit der Semantik, daß an keinem Teil eine Operation ausgeführt wird, einzuführen, ist nur in Verbindung mit dem Dispatchingprozeß sinnvoll, da dieser Zustand primär keine Bedeutung für den Ablauf der Steuerung hat. Wir wollen deshalb auf ihn verzichten.


 _______________
|               |                  x1: Anweisung durch Org.
| vor Erzeugung |                  y1: Übernahme aller zugeord-
|_______________|                      neten Informationen; Er-
        |                              zeugung aller Teile
        | x1/y1
        V
 _______________                   
|               |                  
|   existent    |
|_______________|                  x2: 1. Teil eingeschleust
        |                          y2: --                   
        | x2/y2                                             
        V
 _______________                   x3: noch nicht alle Teile
|               |<-----+               ausgeschleust
|   in Arbeit   |      | x3/y3     y3: --                   
|_______________|------+
        |
        | x4/y4
        V
 _______________                   x4: alle Teile ausgeschleust
|               |                  y4: Rückmeldung an Org.
|    beendet    |                  
|_______________|                  


Logischer Zustandsgraph eines FMS-Auftrages



Für ein Teil sind drei Zustände relevant, durch die spezifiziert wird, wo es sich befindet. 'außerhalb' ist ein Teil vor seinem Einschleusen und nach dem Ausschleusen, 'auf Palette' ist ein Teil dann, wenn es einem Palettenauftrag bereits logisch zugeordnet ist, was nicht bedeutet, daß es bereits aufgespannt ist. 'einzeln' soll ein Teil dann heißen, wenn ihm kein Palettenauftrag zugeordnet ist. Auch in diesem Zustand ist es nicht notwendig, daß es bereits physisch abgespannt ist.


    _______________
   |               |         x1: Erzeugung durch FMS-Auftrag
   | vor Erzeugung |         y1: Übernahme aller Informationen;
   |_______________|             Erzeugung Einschleusauftrag
           |
           | x1/y1
           V
    _______________
   |               |         x2: Einschleusen beendet 
   |   außerhalb   |         y2: Nachricht an FMS-Auftrag
   |_______________|         
       |       ^             x3: keine weitere Bearbeitung notw.
 x2/y2 |       | x3/y3       y3: Erzeugung Ausschleusauftrag
       V       |                 Nachricht an FMS-Auftrag 
    _______________              
   |               |
   |    einzeln    |         x4: Bearbeitung notwendig
   |_______________|         y4: Zuordnung zu existierendem oder
       |       ^                 Erzeugung eines neuen Paletten-
 x4/y4 |       | x5/y5           auftrags
       V       |                                                  
    _______________
   |               |         x5: Palettenauftrag beendet
   |  auf Palette  |         y5: Aktualisierung des Anarbei-
   |_______________|             tungsstandes


Logischer Zustandsgraph eines Teils



Ein Palettenauftrag kann sich in den Zuständen 'existent', 'aktiviert', 'operend' und 'beendet' befinden. Solange dem Palettenauftrag noch nicht alle notwendigen Teile zugeordnet sind, befindet er sich im Zustand 'existent'. Sobald seine Teileanzahl erreicht ist, ist er 'aktiviert'. 'operend' heißt der Palettenauftrag, wenn er sich im "FMS-Rest" zur Bearbeitung befindet und 'beendet', wenn seine Bearbeitung abgeschlossen ist.


 _______________
|               |               x1: Erzeugung durch Teil
| vor Erzeugung |               y1: Übernahme der Informationen
|_______________|                   von Teil und FMS-Auftrag;
        |                           Vorinformation an Paletten-
        | x1/y1                     auftragskoordination
        V
 _______________
|               |<---+          x2: Zuordng. eines weiteren Teils
|   existent    |    | x2/y2    y2: Übernahme Teilinformationen
|_______________|----+
        |                       x3: Palettenauftrag vollständig
        | x3/y3                 y3: Erzeugung Aufspannauftrag
        V
 _______________
|               |
|   aktiviert   |
|_______________|
        |                       x4: Aufspannauftrag beendet
        | x4/y4                 y4: Weisung an Palettenauftrags-
        V                           koordination
 _______________ 
|               |
|    operend    |
|_______________|
        |                       x5: Endemeldung durch Paletten-
        | x5/y5                     auftragskoordination
        V                       y5: Erzeugung Abspannauftrag;
 _______________                    Endenachricht an Teile
|               |
|    beendet    |
|_______________|


Logischer Zustandsgraph eines Palettenauftrages



In der Aktion y1 ist die Vorinformation der Palettenauftragskoordination angegeben. Damit soll es diesem Steuerungsprozeß ermöglicht werden, die notwendigen Werkzeugsatzbereitstellungsaufträge anzuweisen. Dennoch kann es vorkommen, daß diese Information zu spät übergeben wird. Hier können uns nur andere Steuerungsprozesse helfen. Wenn es möglich ist, einen Palettenauftrag schon vor der Bereitstellung des ersten zugeordneten Teils zu erzeugen, kann die Vorinformation früher erfolgen. Diese Erzeugung kann durch die Prozesse "Operative Planung" oder "Dispatching" initiiert werden, da sie einen größeren Überblick über die künftigen Aufgaben besitzen. Die Systemkoordination hat in dieser Version nicht die Aufgabe, vorausschauend zu steuern oder den Ablauf des Prozesses zu optimieren, sondern lediglich die, die ordnungsgemäße Fertigung zu sichern.

Ähnliches trifft auf die Bedingung für den Zustandsübergang nach 'aktiviert' zu. Auch hier wartet die Systemkoordination bis ein Palettenauftrag vollständig mit Teilen belegt ist. Soll der Auftrag bereits vorher bearbeitet werden, sind wiederum Einfluß nahmen durch "Planung" oder "Dispatching" notwendig.

Die Spannaufträge besitzen Zustandsgraphen, die denen der Palettenaufträge ähneln. Es entfällt jedoch der Zustand 'existent', da ein Spannauftrag nach seiner Erzeugung durch ein Teil oder einen Palettenauftrag sofort ausgeführt werden kann, sich also im Zustand 'aktiviert' befindet. Neben dem Zustand 'aktiviert' enthält der Zustandsgraph eines Spannauftrages die Zustände 'operend' und 'beendet'. Die Semantik dieser Zustände ist analog der der Palettenaufträge.


 _______________
|               |               x1: Erzeugung durch Teil oder 
| vor Erzeugung |                   Palettenauftrag             
|_______________|               y1: Übernahme der Informationen
        |                           von Teil bzw. Palettenauftr.
        | x1/y1                     und FMS-Auftrag     
        V
 _______________
|               |
|   aktiviert   |
|_______________|
        |                       x2: Spannzelle verfügbar  
        | x2/y2                 y2: Weisung an Spannzellen-     
        V                           koordination
 _______________
|               |
|    operend    |
|_______________|
        |                       x3: Endemeldung durch Spann-   
        | x3/y3                     zellenkoordination
        V                       y3: Endenachricht an Teile und
 _______________                    ggf. Palettenauftrag 
|               |      
|    beendet    |
|_______________|


Logischer Zustandsgraph eines Spannauftrages



Der Zustandsgraph einer Spannzelle enthält nur zwei Zustände: 'verfügbar' und 'nicht verfügbar'. Ist die Spannzelle im Zustand 'verfügbar', so können ihr von der Systemkoordination Spannaufträge angewiesen werden, im Zustand 'nicht verfügbar' ist dies nicht möglich.


 __________________
|                  |
| nicht verfügbar  |    x1: Meldung durch Spannzellenkoordination
|__________________|    y1: --
      |      ^
x1/y1 |      | x2/y2    x2: Meldung durch Spannzellenkoordination
      V      |          y2: --  
 __________________
|                  |
|    verfügbar     |
|__________________|


Logischer Zustandsgraph einer Spannzelle

8.3. Implementation der Zustandsgraphen

Die Umsetzung des funktional-logischen Entwurfs in den Implementationsentwurf gliedert sich in zwei Schritte, den Entwurf der Datenstrukturen für alle Entitäten und die Erarbeitung der zu implementierenden Zustandsgraphen. Ausgangspunkte des Implementationsentwurfs sind neben dem logischen Entwurf der verwendete Zustandsgrapheninterpreter, die festgelegte(n) Programmiersprache(n) und die konkrete Hardware- und Software-Struktur der Steuerung.

Der Entwurf der Datenstrukturen erfolgt auf der Grundlage der den Entitäten zugeordneten Informationen. Für den Zustandsgrapheninterpreter SIRIUS 2.2 sind z.B. Datenstrukturen in der Programmiersprache C notwendig. Das erste Element jeder Struktur muß dabei eine Adresse sein, die ausschließlich von SIRIUS 2.2 benutzt wird.

Konstante Informationen werden direkt in den Datensatz aufgenommen. Für die Implementation zugeordneter Verkettungsinformationen können verschiedene Möglichkeiten genutzt werden. Die einfachste Art ist die Aufnahme aller Verweise in die Datenstruktur. Ist die Menge der zugeordneten Entitäten jedoch sehr groß (einem FMS-Auftrag sind alle seine Teile zugeordnet), so ist eine Realisierung der Zuordnung mit Hilfe von Listen besser. Dazu müssen dann jedem Teil die entsprechenden Verweise zusätzlich zu den festgelegten Informationen zugeordnet werden. Die Zustandsinformationen der Entitäten werden bezüglich der implementierten Zustandsgraphen von SIRIUS 2.2 hantiert und befinden sich damit nicht in der Datenstruktur. Zustandsinformationen für große oder unendliche Zustandsgraphen, die analytisch ermittelt werden, sind als Variable in die Struktur aufzunehmen.


Der logische Zustandsgraph ist nicht ausreichend für die Implementation. Er enthält aber alle Informationen, die zu einer Verständigung mit den Partnern im Betrieb und mit anderen Bearbeitern notwendig sind. Um ihn für die Implementation zu verwenden, ist eine Überarbeitung der Zustandsgraphen erforderlich. Dabei können weitere Zustände oder Transitionen eingeführt werden. Die Bedingungen und Aktionen müssen in jedem Fall neu formuliert werden.

Neue Zustände werden für die Umsetzung des logischen Entwurfs in den Implementationsentwurf selten benötigt. Sie werden in der Regel für Initialisierung-, Ende- oder Fehlerbehandlungstransitionen eingeführt. Im Entwurf vorhandene Zustände zu streichen, ist unzulässig, auch wenn sich Vereinfachungen ergeben könnten.

Zusätzliche Transitionen werden aus denselben Gründen wie zusätzliche Zustände benötigt. Außerdem kann mit neuen Transitionen die Kommunikation mit der Umgebung und dem Programmierer (in der Testphase) erreicht werden. Sind neu aufzunehmende Transitionen grundsätzlicher Art, d.h., stellen sie die Verbindung des entworfenen Prozesses zu solchen Prozessen her, von denen noch kein Entwurf vorliegt, so sollten sie durch den logischen Entwurf (insb. des Kommunikationsprotokolls) begründet werden.

Wir wollen diese Umsetzung am Beispiel des FMS-Auftrages einmal kurz skizzieren:

Ausgangspunkte sind der oben skizzierte logische Entwurf, die Nutzung der Programmiersprache C und des Zustandsgrapheninterpreters SIRIUS 2.2 unter DCP auf ESER-PC EC 1834. Die Entitäten müssen in Form von Datenstrukturen implementiert werden, für jede Entitätsklasse wird eine Typdefinition genutzt:


typedef struct __fms_auftrag       FMS_AUFTRAG;
typedef struct __werkstueck        TEIL;
typedef struct __pal_auftrag       PAL_AUFTRAG;

/* und so weiter */



Die Datenstruktur für den FMS-Auftrag beinhaltet zweckmäßigerweise die Anzahl der zu fertigenden Teile, die Anzahl der eingeschleusten und der ausgeschleusten Teile sowie einen Anker auf eine Liste der Teile. Die Zuordnung zu einer Technologie wird implementiert, indem die Position der gültigen Technologie im Technologiefile ermittelt wird. Weitere konstante Informationen sind die Priorität des Auftrags und dessen Termin.


struct __fms_auftrag 
     {
     inf_od    *head;         /* Pointer für SIRIUS 2.2        */
     long      ident_nr;      /* Identifikator des Auftrags    */
     long      technologie;   /* Offset der gültigen Technolo- */
                              /* gie im Technologiefile        */
     TEIL      *erstes_teil;  /* Anker für Teile-Liste         */
     int       prioritaet;    /* Auftragspriorität             */
     time_t    termin;        /* Auftragstermin                */
     int       teile_ges;     /* Soll-Teileanzahl              */
     int       teile_ein;     /* Ist -Teileanzahl (einge-      */
                              /*                   schleust)   */
     int       teile_fertig;  /* Ist -Teileanzahl (fertig)     */
     };



Diese Werte müssen in der Aktion y1 initialisiert werden. Da zum Zeitpunkt der Initialisierung der FMS-Auftrag noch nicht existiert, muß er vorher generiert werden. Dies erfolgt durch ein Unterprogramm, daß in einem anderen Zustandsgraphen aufgerufen wird. Für eine saubere Programmierung empfiehlt es sich, die Generierungs- und Initialisierungsfunktionen (hier: fms_init) in das Modul der Bedingungs- und Aktionsroutinen für die FMS-Aufträge aufzunehmen. Der eigentliche Erzeugungsprozeß ruft dann nur diese Funktion auf.

Erhält der FMS-Auftrag von einem Teil die Nachricht, daß es eingeschleust wurde (Teil ist im Zustand 'einzeln'), wird die Anzahl der eingeschleusten Teile inkrementiert. Damit wird sowohl die Transition 'existent'-->'in Arbeit' beschrieben als auch eine mögliche Transition 'in Arbeit'-->'in Arbeit', Meldet ein Teil sein Ausschleusen (Teil ist im Zustand 'außerhalb'), wird der Wert der ausgeschleusten Teile inkrementiert (Transition 'in Arbeit'-->'in Arbeit') und es erfolgt eine Selbstaktivierung, um gegebenenfalls die Transition 'in Arbeit'-->'beendet' ausführen zu können. Dabei muß dafür gesorgt werden, daß keine erneute Transition nach 'in Arbeit' erfolgen kann.

Das Ergebnis des Vergleichs von Soll-Teileanzahl und fertiggestellter Ist-Teileanzahl entscheidet über die Transition in den Zustand 'beendet'. Bei dieser letzten Transition, werden alle Teile des FMS-Auftrags gelöscht, so daß ihr Speicherplatz für andere Entitäten genutzt werden kann.


 _______________
|               |                  x1: Funktionsaufruf fms_init
| vor Erzeugung |                  y1: Generieren und initiali-
|_______________|                      sieren eines FMS-Auftrags;
        |                              Generieren und initiali-
        | x1/y1                        sieren aller Teile
        V
 _______________                   
|               |                  x2: Aktivierung durch Teil im
|   existent    |                      Zustand einzeln          
|_______________|                  y2: teile_ein ++             
        |                          
        | x2/y2                    
        V
 _______________                   x3: Aktivierung durch Teil im
|               |<-----+ x2/y2         Zustand außerhalb        
|   in Arbeit   |      | x3/y3     y3: teile_fertig ++ und  
|_______________|------+               Selbstaktivierung
        |
        | x4/y4
        V
 _______________                   x4: teile_fertig == teile_ges
|               |                  y4: Löschen aller Teile und
|    beendet    |                      Fertig-Meldung senden
|_______________|                  

Implementierter Zustandsgraph eines FMS-Auftrages


Daraus ergeben sich die zu implementierenden Funktionen. Die Namen können z.B. aus fms_ und Bedingungs- bzw. Aktionsbezeichnung gebildet werden.


/* Löschen eines FMS-Auftrags                                  */

void fms_delete (FMS_AUFTRAG *alter_auftrag)
{
/* Sicherung vor Fehllöschungen                                */
if (odtyp (alter_auftrag) != entitaet_fms_auftrag) return;

/* Abmelden bei SIRIUS 2.2 und Speicherplatzfreigabe           */
odkill (alter_auftrag); free (alter_auftrag);
}

/* Initialisierungsroutine für einen FMS-Auftrag               */
/*                                                             */
/* Generierungs- und Initialisierungsfunktionen liefern zweck- */
/* mäßig die Adresse der generierten Entität oder NULL         */

FMS_AUFTRAG *fms_init (long id, char *tech_name, int prio,
                       time_t termin, int teile)
{
FMS_AUFTRAG *neuer_auftrag; long technologie_verweis;

/* Prüfen des Vorhandenseins der Technologie (suche_technologie)
   und Generierung von Speicherplatz (malloc)                  */
if ( (technologie_verweis = suche_technologie (tech_name)) == 0L
     or
     (neuer_auftrag = malloc (sizeof FMS_AUFTRAG)) == NULL
   )
   return NULL; /* Initialisierung fehlerhaft */

/* Anmelden bei SIRIUS 2.2                                     */
odin (neuer_auftrag, entitaet_fms_auftrag, DEF_ENTE, DEF_ENTE);

/* Übernahme der Initialisierungsdaten                         */
neuer_auftrag -> ident_nr     = id;
neuer_auftrag -> prioritaet   = prio;
neuer_auftrag -> termin       = termin;
neuer_auftrag -> teile_ges    = teile;
neuer_auftrag -> teile_ein    =
neuer_auftrag -> teile_fertig = 0;
neuer_auftrag -> technologie  = technologie_verweis;

/* Erzeugung und Initialisierung der Teile (teil_init)         */
if ( (neuer_auftrag -> erstes_teil = teil_init (neuer_auftrag))
     == NULL)
   {
   /* Teile-Erzeugung fehlerhaft                               */
   fms_delete (neuer_auftrag); return NULL;
   }
return neuer_auftrag;
}

/* x2: Test, ob ein Teil eingeschleust wurde                   */
/* Das Teil meldet das Einschleusen über die Aktivierung des   */
/* Auftrages bei Übergabe seiner Adresse als Aktivierungs-     */
/* ursache.                                                    */

bool fms_x2 (FMS_AUFTRAG *fau, TEIL *teil)
{
/* Es muß geprüft werden, ob die Aktivierung durch ein Teil    */
/* erfolgte und ob sich dieses Teil im Zustand 'einzeln' be-   */
/* findet.                                                     */
return (odtyp (teil) == entitaet_teil and 
        zustand (teil, TEIL_ZGR) == TEIL_EINZELN);
}

/* y2: Zugehörige Aktion                                       */
bool fms_y2 (FMS_AUFTRAG *fau, TEIL *teil)
{
fau->teile_ein++; return true;
}

/* x3: Test, ob ein Teil ausgeschleust wurde                   */
/* Das Teil meldet das Ausschleusen analog dem Einschleusen.   */

bool fms_x3 (FMS_AUFTRAG *fau, TEIL *teil)
{
/* Es muß geprüft werden, ob die Aktivierung durch ein Teil    */
/* erfolgte und ob sich dieses Teil im Zustand 'außerhalb'     */
/* befindet.                                                   */
return (odtyp (teil) == entitaet_teil and 
        zustand (teil, TEIL_ZGR) == TEIL_AUSSER);
}

/* y3: Zugehörige Aktion                                       */
bool fms_y3 (FMS_AUFTRAG *fau, TEIL *teil)
{
fau->teile_fertig++;
 
/* Selbstaktivierung: als Ursache darf hier nicht teil angege- */
/*    ben werden, da die Bedingung fms_x3 wieder true liefern  */
/*    könnte. Das würde zu einem Endlos-Zyklus führen.         */
activate (fau, fau);
return true;
}

/* Test, ob alle Teile fertiggestellt wurden                   */
bool fms_x4 (FMS_AUFTRAG *fau, FMS_AUFTRAG *selbst)
{
/* Ein Test der Aktivierungsursache ist hier nicht notwendig,  */
/* da die Bedingung für diese Transition erst dann erfüllt ist */
/* wenn kein Teil eine Nachricht mehr senden kann.             */
return fau->teile_ges == fau->teile_fertig;
}

bool fms_y4 (FMS_AUFTRAG *fau, FMS_AUFTRAG *selbst)
{
/* Löschen der Teile und Senden der Fertigmeldung              */
teil_delete   (fau);
fertigmeldung (fau);
return true;
}




voriger Abschnitt Inhalt der Dissertation


  Copyright © 1997 by
Dr. Uwe Doetzkies

<F>-soft
Homepage
nächster Abschnitt

Original © 1990 by Dresden University of Technology; Dept. of Information Science; Applied Computer Science