Objektorientierte Modellierung zur Simulation des Steuerverhaltens von modularen Transfersystemen

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Aufbau der Arbeit

2 Einführung in die objektorientierte Programmierung

3 Simulation
3.1 Grafische und textuelle Programmdarstellung
3.2 Zeitdarstellung in der Simulation
3.2.1 Echtzeitsteuerung
3.2.2 Quasikontinuierliche Zeitsteuerung
3.2.3 Ereigniszeitsteuerung
3.2.4 Prozeßzeitsteuerung
3.2.5 Multimodelling
3.3 Differenzen zwischen Simulation und Realität
3.4 Objektorientierte Simulation
3.5 Trennung zwischen Material- und Datenfluß
3.6 Petri-Netze in der Simulation

4 Beschreibung von Bausteinen für Transfersysteme
4.1 Beschreibung des Bausteinkastens TS0 von Bosch
4.1.1 Beschreibung der Materialflußfunktionen
4.1.2 Zu den Bausteinen gehörige Steuerungs-Funktionen
4.2 Darstellung der Bausteine als Objekte
4.2.1 Objektbeschreibungen
4.2.1.1 Materialflußgrundverhalten
4.2.1.2 Aktoren
4.2.1.3 Sensoren
4.2.1.4 Eingänge
4.2.1.5 Ausgänge
4.2.1.6 Steuerungen
4.2.1.7 Kommunikations-Dienste
4.2.2 Klassendefinition

5 Objektorientierte Simulation von Prozeß und SPS
5.1 Nutzungs- und Anforderungsstruktur
5.1.1 Anforderungen an ein kombiniertes System
5.1.1.1 Modellierung
5.1.1.2 Modellkomponenten
5.1.1.3 Spezifikation der Simulationsläufe
5.1.1.4 Auswertung
5.1.1.5 Programmierung von Einrichtungen
5.2 Realisierung
5.2.1 Modellierungskomponenten
5.2.2 Modellkomponenten
5.2.2.1 Prozeßbausteine
5.2.2.2 Steuerungsbausteine
5.2.2.3 Interaktion zwischen Steuerungs- und Prozeßbausteinen
5.2.3 Darstellungskomponenten
5.2.4 Zeit und Ablaufsteuerung
5.2.4.1 Ein Ansatz zur Darstellung von SPS-Zyklen bei ereignisorientierter Simulation
5.2.5 Durchführung des Simulationsexperiments
5.2.6 Übertragung der SPS-Programme auf die Steuerungen
5.3 Ein einfaches Simulationsbeispiel in Simple++
5.3.1 Beschreibung von SIMPLE++
5.3.1.1 Warum SIMPLE++?
5.3.1.2 Zeitsteuerung
5.3.2 Modellierung des Beispiels
5.3.3 Die Elemente des Prozesses
5.3.3.1 Die Strecke
5.3.3.2 Der Positionsschalter
5.3.3.3 Der Vereinzeler
5.3.4 Die Elemente zur Modellierung des Steuerverhaltens
5.3.4.1 Petri-Netze
5.3.4.2 Abbildsteuerungen und Verknüpfungen
5.3.5 Der OSIMPROST-Bausteinkasten
5.3.6 Resümee der Modellierung

6 Zusammenfassung

7 Anhang
7.1 Abbildungen und Steuerungen der Bausteine
7.1.1 Positioniereinheit PE 0
7.1.2 Elektrische Quertransporte EQ 0
7.1.3 Quertransporte in Tandemanordnung EQ 0/T
7.2 Abbildungsverzeichnis
7.3 Tabellenverzeichnis

8 Literatur

1 Einleitung

Die vorliegende Arbeit verknüpft die Bereiche Materialflu ß -Simulation und SPS- Programmierung . Die Ergebnisse werden in einem Softwarekonzept, das den Arbeitstitel Ob- jektorientierte Simulation von Prozeß und Steuerung (OSIMPROST) erhält, zusammengeführt.

In der modernen Anlagenplanung, bei der die Materialfluß-Simulation zunehmend eine Rolle spielt, bietet die Kombination der beiden Bereiche Materialfluß-Simulation und SPS- Programmierung Vorteile. Die Steuerungslogik, die in der Simulation den Materialfluß steuert, kann als Grundlage für die Erzeugung von SPS-Programmen für die spätere Anlage dienen. Um die SPS-Programmierung effizient zu entlasten - die Programme also möglichst automa- tisch zu erzeugen und auf die Steuerung zu übertragen - sind neue Konzepte nötig. Während für die getrennte Simulation und Steuerung bereits eine Reihe erprobter Softwareprodukte und Ansätze zur Verfügung stehen, fehlen diese für den kombinierten Einsatz. Es werden Konzepte vorgestellt und erarbeitet, mit deren Hilfe die simulationsgestützte Projektierung von Transfer- systemen schneller und wirtschaftlicher als mit getrennter Software durchzuführen ist. Diese Arbeit stellt eine Arbeitsgrundlage für die Entwicklung eines Computerprogramms für die An- lagenplanung dar. Es wird der Versuch gemacht, die dabei auftretenden Probleme zu lösen, und so die Voraussetzungen für die Realisierung zu schaffen.

1.1 Motivation

Die SPS-Technik hat sich historisch aus der Anlagensteuerung mit Relais (Schütze), den soge- nannten Verbindungsprogrammierten Steuerungen , entwickelt. Nach einem Verdrahtungsplan wurden die Schütze in den Schaltschränken miteinander, und mit den Schaltern (Sensoren) und Aktoren der Maschinen, verbunden. Diese aufwendige und inflexible feste Verdrahtung wurde durch prozessorgesteuerte Einrichtungen, bei denen sie Steuerungslogik in Form von digitalen Programmen im Speicher vorliegt, ersetzt. Diese digitalen Steuerungen heißen Speicher- Programmierbare Steuerungen (SPS). Bei der Entwicklung von Programmiersprachen lehnte man sich an die gewohnten Verdrahtungspläne an, und schuf z.B. den bis heute gängigen Kon- taktplan . Um mit einem Programmiergerät mit Tastatur, Bildschirm, Datenträgern usw. mehre- re Steuerungen programmieren zu können, wurde die Offline-Programmierung eingeführt. Die auf einem separaten Programmiersystem erstellten Programme werden über Datenträger oder Kabel auf die Steuerungen übertragen.

Die Computersimulation hat sich, weitgehend getrennt von der SPS-Programmierung, auf der Basis von höheren Programmiersprachen wie z.B. FORTRAN entwickelt. Um die Tätigkeiten der Simulationsprogrammierung zu rationalisieren, wurden Bausteinbibliotheken zu den Pro- grammiersprachen hinzugefügt wie z.B. GPSS-FORTRAN. Mit der Einführung der Animation konnte der Ablauf der Simulation auf dem Monitor verfolgt werden. Eine weitgehend grafisch- interaktive Modellerstellung mit objektorientierten Konzepten kennzeichnet den heutigen Stand der Simulation.

Durch die getrennte Entwicklung von SPS-Programmierung und Simulation, sind die Struktu- ren beider Bereiche sehr weit voneinander entfernt, und lassen ihre Zusammenführung als schwierig erscheinen. Diese Arbeit möchte eine Brücke zwischen den Bereichen schlagen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Ziel der Arbeit

Der normale Gang beim Projektieren von Anlagen mit SPS ist nach Friedrich Janzen folgender /JANZEN 90/:

1. Konstruktion,
2. Erstellen der Zeichnungen und Unterlagen
3. Ermittlung der Steuerungslogik,
4. Steuerungsauswahl,
5. Bau,
6. Aufstellung,
7. Programmierung,
8. Inbetriebnahme.

Bei dieser Methode ist die Integration einer Simulationsphase schwierig, weil sich die Planungsphase durch das Einschieben von Simulationszeiten verlängert. Aus Zeitgründen kann nur in einer kurzen Zeitspanne mit dem Modell experimentiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Projektierungsabschnitte

Für den Fall, daß ein kombiniertes Planungs-, Simulations- und Programmiersystem zur Verfügung steht, ist eine neue Vorgehensweise für die Anlagenprojektierung möglich. Der neue Ablauf gliedert sich in die Phasen:

1. Anlagenkonzeption und Simulation,
2. Bau,
3. Inbetriebnahme.

Zusätzlich zu den Vorteilen der Simulation¹ kann die Anzahl der Planungsschritte, und damit die Zeit und die Kosten, die diese in Anspruch nehmen, entscheidend reduziert werden. Zu- sätzlich können einsatzfertige und erprobte SPS-Programme erzeugt und eingesetzt werden. Abbildung 3 zeigt den Planungs- und Aufstellungsablauf unter Einsatz der kombinierten Soft- ware.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Projektierung mit Simulation

Ein mit OSIMPROST vergleichbares kombiniertes Programm ist bisher nicht auf dem Markt verbreitet /ISIS 94//SCHNEIDER 95/. Eine Reihe von Grundlagen, die zu dessen Entwicklung notwendig sind, liegen jedoch schon vor.

Da das Interesse in der Wirtschaft durch die möglichen großen Einsparungen groß ist, und die Zusammenführung von Simulation und SPS ein interessanter Forschungsgegenstand ist, wurde die vorliegende Diplomarbeit geschrieben.

1.2 Aufbau der Arbeit

Da bisher kaum Untersuchungen zum gestellten Thema existieren, müssen für die in folgenden Bereichen auftretenden Fragestellungen Antworten und Lösungen gesucht werden.

- Bei der Materialfluß-Simulation ist für eine Darstellung, die jedem Sensor und Aktor der Anlage abbildet, ein sehr hoher Detaillierungsgrad erforderlich. Hieraus ergeben sich Probleme im Speicherbedarf und in der Simulationsgeschwindigkeit, welche ge- löst werden müssen.
- In der Materialfluß-Simulation hat sich die Ereigniszeitsteuerung² am besten bewährt. SPS arbeiten ihre Programme zyklisch ab, um in Echtzeit³ auf Systemveränderungen reagieren zu können. In der Simulation führt die Kombination beider Zeitdarstellungen zu einer Verringerung der Geschwindigkeit, weil der Prozessor des Simulationsrech- ners durch die vielen SPS-Programmzyklen stark belastet wird.
- Zum projektbegleitenden Einsatz muß die Simulation der zunehmenden Präzisierung und Verfeinerung des Erkenntnisstandes folgen. Aus der Simulation sind hierfür die Techniken Prototyping und Hierarchisierung/Modelrefinement bekannt⁴.
- Transfersysteme⁵ werden aus Modulen wie beispielsweise Strecken und Verzweigun- gen zusammengesetzt. Da diese immer wiederkehrende Grundelemente darstellen, werden sie von den meisten Simulatoren als Bausteine angeboten, die in ein Modell eingesetzt werden können. Zu diesen Bausteinen von Transfersystemen gehören Steuerungsabläufe, die in der realen Anlage von einer zugeordneten SPS übernommen werden. Diese Zusammengehörigkeit von Bausteinen und Steuerprogrammabschnitten soll in der kombinierten Simulation ausgenutzt werden, um den kompletten Steue- rungscode möglichst automatisch zu erzeugen. Für ihre kombinierte Darstellung ist ein Konzept zu entwickeln.
- Für die übergeordneten Aufgaben der Materialflußsteuerung sind SPS-Programme nö- tig, die die Abläufe der einzelnen Bausteine der Anlage koordinieren. Diese müssen vom Programmierer aufgabenbezogen erstellt werden. Hieraus leitet sich die Forderung an das Simulationssystem ab, daß es die erforderliche Steuerungslogik abbilden können muß. Auch hier besteht die Möglichkeit, durch SPS-Programm-Makros oder Unterprogrammtechnik die Arbeit zu erleichtern.
- Das System steht Simulationsexperten ebenso wie Anlagenplanern und SPS- Programmierern als Werkzeug zur Verfügung. Für die gemeinsame Nutzung ist eine allgemeinverständliche Benutzeroberfläche der Software wünschenswert.

Der Lösung der oben aufgezählten Probleme widmet sich diese Diplomarbeit.

Eine Reihe von Methoden und Konzepten, die für die gestellte Aufgabe in Frage kommen, findet sich bereits in der Literatur. Daher werden als Arbeitsgrundlage die Bereiche 2 Objektorientierte Programmierung und 3 Simulation genauer dargestellt.

Es soll sichergestellt werden, daß mit den gewählten Konzepten die Probleme der Praxis sinn- voll abgebildet werden können. Dazu werden die Transfersystem-Bausteine eines Herstellers und die zugehörigen Steuerungsfunktionen beispielhaft beschrieben, und im Kapitel

4 Beschreibung von Bausteinen für Transfersysteme auf ihre grundsätzliche Struktur hin untersucht und objektbezogen beschrieben.

Zur Darstellung der Bausteine im Simulationsmodell wird ein objektorientierter Ansatz gewählt. Um diesen zu realisieren, ist die Definition einer Objektklassenhierarchie erforderlich. Diese wird im Abschnitt 4.2 Darstellung der Bausteine als Objekte vorgenommen. Durch sie ist die Übertragung der Bausteine auf Rechnerebene möglich.

Um die Ziele der Arbeit zu erreichen, ist eine Reihe weiterer Fragen zu klären. Das geschieht im Kapitel 5 Objektorientierte Simulation von Prozeß und SPS.

Hier werden für das Projekt OSIMPROST u.a. die Bereiche der

- Zeitsteuerung,
- der Handhabung und
- der SPS- Programmübertragung

genauer betrachtet und Ansätze zu ihrer Lösung vorgestellt.

Abgeschlossen wird die Arbeit durch die Beschreibung der Implementation eines Beispiels, das den vorhandenen Simulator SIMPLE++⁶ einsetzt. Dieses Programm wurde in der Arbeit be- gleitend eingesetzt, um durch Testen verschiedener Lösungsansätze, sich ergebende Probleme zu erkennen. Einschränkungen der Möglichkeiten ergeben sich in SIMPLE++ durch die Vorga- ben der Software, die teilweise nicht mit den Konzepten von OSIMPROST vereinbar sind. Die Implementierung der wesentlichen Aspekte von OSIMPROST auf SIMPLE++ ist aber schließ- lich gelungen und im Abschnitt 5.3 Ein einfaches Simulationsbeispiel in SIMPLE++ darge- stellt.

2 Einführung in die objektorientierte Programmierung

Die objektorientierte Programmierung ist ein Merkmal der aktuellen Softwareerstellung. Wäh- rend bei der herkömmlichen Programmierung Daten und Funktionen zur deren Manipulation getrennt vorliegen, sind Funktionen und Daten bei der objektorientierten Programmierung in ihrer funktionalen Zusammengehörigkeit eine Einheit. Diese Einheit wird als Objekt aufgefaßt. Ein Objekt ist also ein Programmteil mit zugeordneten Daten, der mit einer H ü lle umgeben ist. Dieser Hülle ist ein Name zugeordnet, über den der Inhalt angesprochen werden kann. Inner- halb dieser Hülle werden die Daten, die den Zustand des Objektes beschreiben, als Attribute , die Funktionen und Prozeduren als Methoden bezeichnet. Bei einer sauberen objektorientierten Programmierung sollten keine Daten oder Programmteile außerhalb von Objekten eine Rolle spielen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Elemente eines Objekts

Die Hülle der Objekte sollte über möglichst wenig Löcher verfügen und somit möglichst wenig von ihrem Inhalt nach Außen preisgeben. Diese Gestaltungsweise wird Informationhiding (Kapselung oder Versteckprinzip) genannt, und soll die Beziehungen zwischen den Objekten übersichtlich halten und sie möglichst leicht wiederverwendbar machen. Attribute und Methoden können als Private definiert und somit für die Außenwelt versteckt, oder als Public , und so für andere Objekte anwendbar und sichtbar gemacht werden⁷.

Objekte müssen, bevor sie benutzbar sind, definiert werden. Das geschieht durch die Definition von Klassen . Eine Klasse stellt einen allgemeinen Bauplan oder Schablone für die Erzeugung von Objekten dar. In ihnen werden die Attribute und Methoden definiert. Attribute können mit Defaultwerten vorbelegt werden.

Um nun ein Objekt ( Instanz oder Exemplar ) zu erzeugen, das innerhalb des Programms ange- sprochen werden kann, wird dieses aus der Klasse abgeleitet . Dazu erhält es einen Namen, und die Attribute, die nicht durch Defaultwerte belegt sind, werden spezifiziert. Durch Spezifizie- rung entsteht so aus dem abstrakten ein konkretes Objekt. Ableiten ist ein Vorgang, der äußer- lich wie das Kopieren der Klasse aussieht, mit dem Unterschied, daß unter dem Namen der neuen Instanz lediglich ein Verweis auf die Klasse, von der sie abstammt, angelegt wird. Die Instanz auf Programmebene besteht also nur aus einem Namen und einem Verweis auf die Klasse, für den Anwender stellt sie sich aber wie ein real existierendes Objekt dar.

Ein Beispiel soll den Begriff der Klassenhierarchie veranschaulichen /PAGE 91/. Die Basisklasse Fahrzeuge (Abbildung 5) könnte z.B. die Attribute Abmessungen, Gewicht und Position [ X,Y ] enthalten. Nur die Luftfahrzeuge haben das zusätzliche Attribut Flughöhe Z . Durch immer weitere Spezifizierung von Attributen gelangen wir von einer abstrakten Klasse schließlich zu Klassen, die über einen vollständigen Satz von Eigenschaften verfügen und aus denen funktionsfähige Instanzen abgeleitet werden können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Klassenhierarchie von Luftfahrzeugen /BECKER 91/

Wenn bei einer höheren Klasse Änderungen vorgenommen werden, verändern sich auch alle Instanzen, die von ihr abstammen , sie erben alle Eigenschaften. Das ist nicht immer erwünscht, außerdem sollen Instanzen möglich sein, die von der Klasse und untereinander abweichende Attributzustände haben. In jeder Instanz können deshalb alle Attribute und Methoden über- schrieben, verändert oder gelöscht werden. Bei Attributen bezieht sich das auf Name, Daten- format und Inhalt, bei Methoden auf Name und Deklaration. Der Mechanismus der Vererbung wird dadurch bei diesen Elementen ausgeschaltet, die Instanzen enthalten jetzt neben ihrem Namen und dem Verweis auf die Klasse außerdem die individuellen Elemente.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Vererbung von Attributen

Bei dem Überschreiben von Methoden gibt es noch eine Besonderheit, die von einigen Programmiersprachen wie z.B. C++ unterstützt wird. Eine Methode kann mit gleichem Namen mehrfach definiert werden und sich nur durch die Deklaration ihrer Eingabeparameter (Zahl und Typ der Argumente) unterscheiden. Wird eine solche Methode angesprochen, kommt automatisch die Methode mit einem passenden Eingabeparametersatz zur Anwendung. Diese Möglichkeit heißt Ü berladung oder Polymorphismus . Durch sie können Objekte flexibler gestaltet werden, weil sie unterschiedliche Parametertypen akzeptieren können.

Die so erzeugten Instanzen können nicht nur im Programm verwendet werden, sondern auch als Bauplan für weitere Objekte dienen und somit selbst wieder Klassen sein. In dieser Weise erhalten Programme eine baumartige Klassenhierarchie , jede Instanz läßt sich auf eine Basisklasse zurückführen. Klassen können neben eigenen Attributen und Methoden auch aus anderen Objekten bestehen. Mit dieser Möglichkeit können Objekte auch aus hierarchisch zusammengeführten Klassen bestehen ( Modellhierarchie ).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Klassenhierarchie und Modellhierarchie

Die erzeugten Objekte liegen nun inaktiv nebeneinander. Um das Programm zu starten, müssen die Methoden der Objekte auch angesprochen werden. Nach einem initialisierenden Aufruf beim Programmstart können die Objekte einander durch Nachrichten ( Messages ) ansprechen. Dieses Messagepassing geschieht über das Aufrufen der als Public definierten Methoden des jeweils anderen Objekts. Die aufgerufenen Methoden können

- den Zustand aller Attribute innerhalb des Objekts lesen und manipulieren,
- Public-Attribute anderer Objekte lesen und manipulieren,
- Public-Methoden anderer Objekte aufrufen und
- interne Methoden aufrufen.

Die Regelung der Zugriffsrechte ist nicht in allen objektorientierten Sprachen und Systemen einheitlich. In C++ beispielsweise lassen sich Attribute und Methoden auch als protected defi- nieren. Diese können dann nur von Objekten, die in der Klassenhierarchie aus dieser Klasse abgeleitet sind, angesprochen werden. Die Möglichkeit, Elemente durch die Klassifizierung als Private zu verstecken, besteht bei allen objektorientierten Programmiersprachen, da sie für das Objecthiding erforderlich ist.

Durch eine objektorientierte Programmierung ergeben sich eine Reihe von Vorteilen. Durch die Vererbung sind Aktualisierungen, die sich auf mehrere Objekte beziehen, leicht durchzuführen, sie müssen nur einmal auf einer höheren Ebene⁸ vorgenommen werden, die abgeleiteten Ob- jekte und Klassen übernehmen die Änderungen automatisch. Dadurch, daß die Informationen nicht in jedem Programmelement redundant gespeichert sind, kann sich außerdem eine erhebli- che Datenreduktion ergeben. Die Vermeidung von Redundanz ist ein wichtiger Grundsatz, um große Systeme wartungsgerecht zu halten. Durch die Verknüpfung von Daten und Methoden innerhalb der Objekte, bleiben die Auswirkungen von Methodenänderungen immer überschau- bar, da sich die Maßnahmen durch das Informationhiding nicht auf andere Programmbereiche auswirken. Durch die Beschränkung der Interaktionen zwischen Objekten auf die Public- Methoden bleibt auch der Gesamtzusammenhang des Programms übersichtlich. Der Program- mierer wird durch das Objektkonzept bei der Softwareerstellung, der Softwareanwender beim Programmumgang in seinem Denken unterstützt. Das Konzept, das auf Gegenständen, Funk- tionen, die diese ausüben können und Beziehungen, in denen diese zueinander stehen aufbaut, entspricht der menschlichen Auffassung besser, als gewöhnliche Programme. Nach G. Färber ist der Objektansatz die Lösung der seit den 70er Jahren bestehenden Softwarekrise /HEUMANN 93/.

Objektorientierte Programmierung hat zwei wesentliche Aspekte. Der Eine ist die Erstellung objektorientierter Software. Das bezieht sich auf die Oberfläche, die dem Anwender die Be- schreibung seiner Probleme in Objekten ermöglicht. Dieser Ansatz ist unabhängig von der ein- gesetzten Programmiermethode, die nicht notwendigerweise objektorientiert sein muß. Der zweite Aspekt bezieht sich auf die verwendete Programmiersprache. Die klassische Sprache für objektorientierte Programmierung ist SMALLTALK. Die meisten modernen Programmier- hochsprachen bieten aber heute auch die nötigen Erweiterungen für objektorientierte Program- mierung an, beispielsweise BORLAND-PASCAL ab Version 6.0, C in der Variante C++. Ob- wohl der Einsatz objektorientierter Sprachen nicht zwingend für die Erstellung objektorien- tierter Software nötig ist, wird die Programmierung durch die angebotenen speziellen Sprache- lemente doch erheblich besser unterstützt und damit vereinfacht /FISHWICK 95/.

Der objektorientierte Beschreibungsansatz kann nicht nur bei der Computerprogrammierung eingesetzt werden, sondern auch für die Beschreibung realer Objekte . Von diesem Umstand wird im nächsten Kapitel Gebrauch gemacht, indem die Bausteine von Transfersystemen und ihre Funktionalität objektorientiert beschrieben werden. In dieser Arbeit ist die Simulation ein zentraler Gegenstand der objektorientierten Programmierung.

3 Simulation

Simulation ist überall dort einzusetzen, wo sich die Problematik aufgrund ihrer Beschaffenheit einer mathematischen Analyse entzieht, was bei den meisten realen Prozessen der Fall ist. Allgemein läßt sich als ihr Ziel formulieren, Aussagen über Systeme zu treffen, ohne daß diese direkt zur Lösung der Aufgabe herangezogen werden. Die Simulation schafft ein abstraktes dynamisches Abbild der Realität. Dabei werden Zustände und Zusammenhänge soweit abstrahiert, daß sie in dem gewählten Medium, z.B. Planspiel oder Computerprogramm, darstellbar sind. Bei dieser Umsetzung müssen die wesentlichen Verhaltensmerkmale zutreffend erfaßt werden, weil davon die Richtigkeit der erzielten Planungs- und Optimierungsergebnisse abhängt. Der VDI definiert Simulation folgendermaßen /VDI 3633/:

„ Simulation ist die Nachbildung eines dynamischen Prozesses in einem Modell, um zu Erkenntnissen zu gelangen, die auf die Wirklichkeit ü bertragbar sind. “

Kormanicki setzt den Schwerpunkt bei seiner Definition auf einen anderen Aspekt /HEUMANN 93/:

„ Simulation ist in erster Linie eine Technik, die eine Modellgenerierung enth ä lt, d.h. das Abbilden des wahren Zustandes erlaubt; danach werden Experimente an diesem Modell durchgef ü hrt. “

Der Modellierungsaspekt steht bei dieser Definition im Vordergrund und verweist auf die Möglichkeit, durch die eindeutige Beschreibung des Modells ein besseres Verständnis der Problematik eines Projektes zu gewinnen.

Deshalb werden Simulationsprogramme schon in vielen Bereichen eingesetzt. Regelkreisauslegung, Elektronikschaltungsentwurf, CNC-Programmierung, Roboter-Programmie- rung und -Bewegungsanalyse, Materialflußsteuerung und Werkstatt-/Logistikplanung sind nur einige Beispiele dafür. Simulatoren stehen für Experimente aller Art uneingeschränkt zur Verfügung, was sie als Untersuchungswerkzeug dem realen Prozeß überlegen macht.

Das Werkzeug für die Anwendung stellt der Simulator dar, worunter eine Menge von zusam- menarbeitenden Rechnerprogrammen, sowie die zugehörige Hardware zu verstehen ist. Das Kernstück stellt das eigentliche Simulationsprogramm dar. Es wird durch Hilfsprogramme zur Eingabedatengenerierung, Ergebnisdarstellung, Kopplung mit anderer Software usw. ergänzt. Zusammen werden sie als Softwarepakete von den Herstellern angeboten. Teilweise kann durch Updates und Zukauf das Anwendungsspektrum der Systeme noch erweitert werden. Eine große Einschränkung ist dabei die Herstellergebundenheit der einzelnen Programmteile.

Bestehende Simulatoren sind meistens parametrisch auf sequentiellen Programmiersprachen aufgebaut. Durch eine klare Modularität der aktuellen Programme ist eine hohe Leistungsfähig- keit und Flexibilität erreicht worden. Eine Begrenzung erfahren sie jedoch durch die mangelnde Fähigkeit, den komplexen, verschieden aufgebauten Zusammenhängen der Realität gerecht zu werden. Hier greifen Konzepte, die zum Beispiel auf der Modellierung in Netzwerken beruhen. Ein anderer Ansatz ist die wissensbasierte Simulation mit Sprachen der künstlichen Intelligenz wie z.B. ROSS, LISP, PROLOG, POP. Der Ursprung dieser Methode liegt in militärischen Planspielen, wurde aber auch für andere Bereiche umgesetzt, zum Beispiel für ein CIM-System /BEN-ARIEH 88/.

Simulatoren lassen sich nach Aufbau und Dateneingabe in verschiedene Gruppen einteilen (Tabelle 1). Neue Ansätze für Simulationsprogramme sollten aufgrund der großen Vorteile objektorientiert aufgebaut sein. Um ein Programm über einen längeren Zeitraum zu nutzen, muß es mit betrieblichen und technologischen Entwicklungen schritthalten. Diese Forderung kann nur erfüllt werden, wenn das Programmkonzept Erweiterungsmöglichkeiten und eine hohe Wartungsfreundlichkeit aufweist. Diese wird in der Regel durch einen streng modularen und objektorientierten Aufbau verbessert.

Um eine Simulation durchführen zu können, wird die Realität durch Daten abgebildet. Diese haben eine unterschiedliche Beschaffenheit. Es liegen die Regeln des Systemverhaltens in Form von Strukturen und Methoden vor, welche sich während der Simulationsläufe nicht ändern. Der Zustand des Systems stellt sich in dynamisch veränderlichen Fakten dar. Der dritte Datentyp, der bei der Simulation auftritt, sind statistische Daten, die bei der Simulation aufgenommen werden, um das Systemverhalten auswerten zu können. Tabelle 2 nennt Beispiele zu den einzelnen Gruppierungsmerkmalen.

Aufgrund der unterschiedlichen Komplexität, Beschaffenheit, Änderungshäufigkeit und Verwendung sollte zwischen ihnen sauber unterschieden werden, um das Programm übersichtlich und wartungsfreundlich zu halten /KUK 88/.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Datentypen nach /KUK 88/

Die in einem System stattfindenden Ereignisse haben ebenfalls eine unterschiedliche Beschaf- fenheit. Es ist zwischen kausal verknüpften und zufälligen Ereignissen zu differenzieren. Die kausalen Ereignisse stellen bei Computerprogrammen kein Problem dar, weil sie der Art der elektronischen Datenverarbeitung entsprechen. Problematisch sind die in der Realität auftre- tenden zufälligen Ereignisse. Sie auf Programme zu übertragen erfordert eine genaue Kenntnis ihrer Wahrscheinlichkeit und Verteilungsfunktion, welche jedoch in der Praxis fast nie vorhan- den ist. Das liegt einerseits am Einsatz der Simulation in der Planungsphase, in der noch keine Anlagen vorhanden sind, an denen statistische Untersuchungen vorgenommen werden könnten, andererseits am hohen Aufwand der statistischen Datenermittlung. Simulation mit deterministi- schem Verhalten durchzuführen, ist deshalb nicht als praxisgerecht zu bezeichnen. Um den- noch simulieren zu können, werden stochastisch auftretende oder variierende Ereignisse durch Zufallszahlen, die der realen Verteilung entsprechen sollen, dargestellt. Zufällige Ereignisse in unterschiedlichen Kombinationen können das System auf viele Weisen beeinflussen, ohne daß die Auswirkungen dieser Ereignisse einer Analyse zugänglich wären. Durch mehrere Simulati- onsläufe mit zufälligen Ereignissen versucht man daher, auf statistischem Wege zu abgesi- cherten Daten zu gelangen, was natürlich seine Grenzen in der statistischen Theorie und der Anzahl durchführbarer Simulationsläufe findet. Um Verteilungen wirklichkeitsnah beschreiben zu können, sollten Simulatoren verschiedene Generierungsmöglichkeiten für Zufallszahlen anbieten, wie z.B. Histogrammverteilung, Normalverteilung, Lognormalverteilung, Bernoulliund Poissonverteilung.

Soll eine Anlage mit Hilfe einer Simulation konzipiert werden, liegen nicht von Anfang an alle Daten detailliert vor. Auch bei Simulationsprojekten ist davon auszugehen, daß anfangs nur grobe, abstrakte, unvollständige und unsichere Daten vorliegen. Trotzdem besteht schon früh- zeitig das Interesse, zu Simulationsergebnissen über das Systemverhalten zu gelangen. Die Si- mulation wird daher auf einem höheren Abstraktionsniveau durchgeführt. Diese Methode wird als Prototyping bezeichnet. Die verschiedenen Ebenen der Abstraktion und Detaillierung sind hierarchisch aufgebaut. Mit der konventionellen parametrischen Simulation sind die Möglich- keiten hierfür begrenzt, weil das Systemverhalten aus allgemeinen Funktionsblöcken mit indi- viduellen Parametern dargestellt wird. Diese müssen eine bestimmte Vollständigkeit haben, damit das Programm lauffähig ist. Bei der objektorientierten Simulation kann unter Verwen- dung verschieden detaillierter Funktionsblöcke, ein Prototyping ermöglicht werden.

Die moderne Automatisierung erfordert Planungssicherheit und Flexibilität, um die Nutzung der Investitionsgüter auf lange Sicht zu garantieren. Kombinierte Systeme, die neben dem rea- len Prozeß auch die Prozeßsteuerung einschließlich der Softwarekomponenten simulieren, er- fahren eine erhöhte Nachfrage, weil sie neben der Prozeß- auch die Softwareoptimierung er- lauben. Diese Entwicklung ist erst in wenigen Anwendungen realisiert wie z.B. CNC- oder Roboter-Programmierung, so daß sie heute eines der wichtigen Entwicklungspotentiale in der Simulation darstellt. Die Gegenstände der Simulation und Steuerung weisen in ihrer Be- schreibbarkeit Unterschiede auf. Regelkreise und Schaltungen z.B. müssen kontinuierlich, be- ziehungsweise quasikontinuierlich beschrieben werden. CNC- und Robotersysteme weisen, je nach Detaillierungsgrad, teils kontinuierliche, teils diskrete Komponenten auf. Bei Materialfluß und SPS überwiegen die diskreten Daten bei der Zustandsbeschreibung. Die Simulation und Steuerung von diskreten Prozessen stellt das Schwerpunktthema dieser Arbeit dar.

Generell sollte die Simulation nur dort eingesetzt werden, wo analytische Verfahren versagen. Auch bei der Vorauswahl von Versuchsbedingungen für die Simulation sollten die mathematisch-/analytischen Möglichkeiten voll ausgeschöpft werden, da hierdurch die Experimentierphase entscheidend verkürzt werden kann. Die Simulation ist jedoch sehr oft das einzige Mittel, um zu gestützten Erkenntnissen zu gelangen. Deshalb werden in den folgenden Abschnitten einige grundlegende Zusammenhänge vorgestellt.

3.1 Grafische und textuelle Programmdarstellung

Die geschichtlichen Anfänge der Simulation liegen in der direkten Benutzung von Program- miersprachen. Häufige simulationsspezifische Funktionen werden durch Simulationsbibliothe- ken unterstützt, um die Simulatoren komfortabler zu gestalten. Ein Klassiker dieser Kategorie ist z.B. die FORTRAN-Simulationsbibliothek GPSS. Der Bedienungskomfort dieser Simula- torkategorie kann durch eine konsequente Modularisierung oder Objektorientierung gesteigert werden. Der Programmierer kann alle seine Wünsche verwirklichen, weil in den eingesetzten Hochsprachen je nach Bedarf eigene Funktionen implementiert werden können. Dieser Flexi- bilität stehen aber Nachteile durch einen hohen Qualifikations- und Zeitbedarf gegenüber, au- ßerdem sind die großen Mengen von Programmtext schwer zu warten und anzupassen. Eine Erleichterung bieten parametrische Simulationssysteme, in denen die Bausteine vordefiniert sind, und durch reine Parametrierung nach Belieben in ein Modell eingesetzt werden können. Der großen Einfachheit dieses Konzepts stehen die beschränkten Möglichkeiten gegenüber. Die Gemeinsamkeit der beiden vorgenannten Verfahren ist die textgebundene Arbeitsweise.

Um Simulationergebnisse anschaulich darzustellen und das Simulationsmodell leicht verständlich zu machen, sind Grafiken das adäquate Mittel. Eine entsprechende Visualisierung des Modells und dessen Zustands ist mit textorientierten Simulatoren möglich, erfordert aber nach der Modellierung noch eine explizite Programmierung der Grafikausgabe.

Diesen zusätzlichen Arbeitsaufwand umgehen Simulationssysteme, bei denen die Modellierung grafisch- interaktiv erfolgt. Das Modell wird dabei aus vorgefertigten oder selbstdefinierten Bausteinen am Bildschirm mit Hilfe einer Maus oder eines anderen Eingabegerätes grafisch erzeugt. Jeder eingesetzte Baustein verfügt über eine definierte Funktionalität, die eigentliche Programmerstellung auf Codeebene kann dem Benutzer verborgen bleiben. Für den Anwender sind also keine Programmierkenntnisse erforderlich und Modellierung und Visualisierung des Modells geschehen in einem Arbeitsschritt.

Das Verbergen des eigentlichen Programmcodes der Bausteine vor dem Benutzer ist auch ein Aspekt der objektorientierten Programmierung. Die überschaubare Struktur der Interaktionen zwischen Objekten durch Informationhiding (Versteckprinzip) prädestiniert den objektorien- tierten Ansatz für die grafische Simulation. Durch die Mechanismen der Vererbung und der Erweiterbarkeit von Bausteinkästen durch die Spezifizierung eigener Klassen, erhält der An- wender weitere Unterstützung, die den grafisch- objektorientierten Ansatz als den der Zukunft erscheinen lassen.

Ein Maximum an Flexibilität bieten grafisch- objektorientierte Simulatoren. Sie haben zusätzlich die Fähigkeit, Probleme, die die Möglichkeiten der vordefinierten Bausteine übersteigen, durch die Integration einer objektorientierten Programmiersprache, zu lösen.

Nach dem Vergleich grafischer und textueller Simulation erfolgt nun die Betrachtung der Zeitdarstellung, die ein wichtiges Klassifikationsmerkmal von Simulatoren ist.

3.2 Zeitdarstellung in der Simulation

Ein wichtiges Merkmal von Simulatoren ist ihr Konzept zur Zeitsteuerung. Um Zeiten für Computerprogramme handhabbar zu machen, muß Zeit abstrahiert und diskretisiert werden. Kontinuierliche Darstellungen sind nur bei Analogrechnern möglich. Eine weitere erwünschte Abweichung von der Realität ist die Beeinflussung der Ablaufgeschwindigkeit durch den Be- nutzer. Einige schnell ablaufende Vorgänge erfordern eine „Zeitlupe“ zur Beobachtung, andere eine „Zeitraffung“, um möglichst schnell Simulationsergebnisse zu erhalten. Im Folgenden werden die verschiedenen Möglichkeiten, Zeit auf Programmebene darzustellen, beschrieben.

3.2.1 Echtzeitsteuerung

Die in allen gängigen Computern eingebaute Uhr kann abgefragt werden und als Eingangsva- riable für zeitabhängige Funktionen genutzt werden. Hierfür müssen aber alle Größen als Funktion der Zeit bekannt sein. Bei Differentialgleichungen f(dt) oder den Zustandsvektoren komplexer oder stochastischer diskreter Systeme ist das aber nicht möglich. Das Verfahren läßt sich deshalb in den meisten Fällen, wo Simulation interessant ist, nicht einsetzen. Bei Syste- men, die simuliert werden sollen, können aber Aussagen über Zeitabschnitte getroffen werden. Bei der Simulation von Differentialgleichungen ist dieses jeweils das Zeitinkrement Δ t , bei diskreter Simulation können wir Ereignisse vorausbestimmen, z.B. daß ein Werkstück n Se- kunden nachdem es in eine Maschine eingetreten ist, diese wieder verlassen wird. Die so er- mittelten Zeitpunkte können an der Rechneruhr synchronisiert werden. Das geschieht dadurch, daß in jedem Abfragezyklus getestet wird, ob die Systemzeit schon größer als die Endzeit eines Ereignisses ist, gegebenenfalls wird dieses Ereignis durchgeführt. Eine Voraussetzung für die Simulation in Echtzeit ist also die Gewährleistung, daß alle Berechnungsergebnisse vor der nächsten Zeitabfrage vorliegen.

Bei schnell ablaufenden Vorgängen oder komplexen Berechnungen kann die Berechnung des Endzustandes zu lange dauern, wodurch die Echtzeitanforderung verletzt wird. In Fällen wo dieses eintritt, ist das Echtzeitverfahren ungeeignet. Nützlich ist das Verfahren dort, wo Programme mit Prozessen interagieren, bei Steuerungen von Maschinen und Anlagen, bei der Prozeßüberwachung und der Steuerung durch Simulation wie beispielsweise bei Fernmanipulatoren der unbemannten Raumfahrt. Für die reine Simulationsanwendung ist der Programmablauf in Echtzeit meistens nicht von Interesse.

3.2.2 Quasikontinuierliche Zeitsteuerung

Eine gängige Methode, die Zeit von Simulationen zu steuern, ist die Definition einer program- minternen Variablen t . Die Berechnungen und Abfragen des Programms werden wiederholt ausgeführt und nach jeder Ausführung wird die Variable t um ein Inkrement Δ t erhöht. Bei zeitschrittabhängigen Funktionen f(dt) bzw. f( Δ t) wird der aktuelle Zustand am Ende des Zyk- lusses gespeichert. Bei Ereignissen wird untersucht, ob t schon größer oder gleich als ihr vorausberechneter Eintrittszeitpunkt ist. Wird der Grenzübergang Δ t → 0 durchgeführt, liegt eine kontinuierliche Darstellungsweise vor. Da dieser wegen der gegen unendlich strebenden Zykluszahl nicht realisierbar ist, werden die Schritte >0 gewählt, weshalb diese Darstellung nur als quasikontinuierlich bezeichnet werden kann.

Die Größe der Konstanten Δ t beeinflußt das Programm durch den Diskretisierungsfehler. Bei Gleichungen ist jedoch f(dt) ≠ f( Δ t) , bei Ereignissen ist t-1<TEreignis und t>TEreignis , wodurch sich Ungenauigkeiten ergeben. Je kleiner Δ t gewählt wird, um so besser ist in der Regel die Genauigkeit der Simulation. Um einen bestimmten Zeitraum zu simulieren, sind aber auch um so mehr Programmschritte nötig. Die Wahl von Δ t ist also immer ein Kompromiß zwischen Programmgeschwindigkeit und der zu erwartenden Genauigkeit der Ergebnisse.

Bei diskreten Simulationsmodellen kann die Methode sehr unwirtschaftlich sein, wenn über längere Zeiträume keine Ereignisse anstehen, aber alle laufenden Prozesse in jedem Zyklus abgefragt werden müssen, wodurch die Diskrepanz zwischen Genauigkeit und Geschwindigkeit sehr groß werden kann. Bei kontinuierlichen Modellen ist die Zeitschrittmethode die weitaus verbreitetste Zeitdarstellung.

[...]

---

¹ Als wesentlich sind die erhöhte Planungssicherheit und eine Anlagenoptimierung in der Planungsphase zu nennen. Auch im Bereich der Auftragssteuerung kann die Simulation hilfreich sein. Nach einer Erhebung des VDI beträgt die Kostenersparnis durch Simulation 20%. Dieser Wert weist aber je nach Einsatzfall extreme Schwankungen auf.

² Die Uhr des Simulators springt zum jeweils nächsten Ereignis. Eine genaue Beschreibung der Ereignissteuerung findet sich in Kapitel 3.2.3

³ Der Begriff Echtzeit besagt, daß eine Steuerung sofort - oder zumindest innerhalb einer vorgegebenen Zeit - auf Eingangssignale reagiert.

⁴ Prototyping bezeichnet die Analyse von Modellen, die auf vorläufigen Ergebnissen beruhen. Bei der Hierarchisierung werden Blöcke, bei denen nur das äußere Verhalten beschrieben wurde, durch eine detailliertere Beschreibung aus mehreren Blöcken ersetzt.

⁵ Transfersysteme transportieren Material automatisch zu den einzelnen Stationen innerhalb eines Fertigungssystems. Der Transport der Teile kann z.B. an Hakenketten hängend, auf Förderbändern oder auf selbstfahrenden Transportfahrzeugen erfolgen.

⁶ Ein Simulator der Firma AESOP Stuttgart, der neben der grafisch-objektorientierten Modellierung, eine Programmiersprache zur Modellmanipulation bereitstellt.

⁷ Die Spezifikation der Zugriffsrechte auf Attribute und Methoden ist von der Programmiersprache abhängig und deshalb uneinheitlich. Es ist die Aufgabe des Programmierers, die Anzahl der Verknüpfungen zur Außenwelt im Sinne einer übersichtlichen objektorientierten Programmierung gering zu halten.

⁸ Innerhalb einer Klassenhierarchie werden die Basisklassen, die abstrakter sind und von denen abgeleitet wird, als höher bezeichnet.