Integrierte Simulation mit EPOS
EPOS steht für Enterprise Production Planning and Optimization System. Es ist ein System zur Integration der Simulation in die Geschäftsprozesse der Produktionsplanung (Integrierte Simulation). Im Folgenden soll die Systemarchitektur von EPOS, das sich bei der IBM Deutschland Speichersysteme GmbH, Mainz, im Einsatz befindet, erläutert werden.
Systemarchitektur
Die verschiedenen Anforderungen an die Funktionalität von EPOS bedingen eine verteilte Systemarchitektur, die über eine reine Client/Server-Architektur hinausgeht. Anhand des stereotypisierten UML-Einsatzdiagramms in Abbildung 3 wird die Architektur von EPOS näher erläutert. Im Zentrum des Systems steht der Datenbank-Server, der den gesamten Datenbestand von EPOS mit Hilfe einer relationalen Datenbank (IBM DB2) verwaltet. Zur Distribution der Indexblätter dient eine dokumentenorientierte Lotus-Notes Datenbank, die auf einem Notes/Domino-Server verwaltet wird. Dieser gestattet zum einen die Distribution im Intranet, zum anderen kann die Notes-Datenbank über mehrere Domino-Server repliziert werden, womit die Distribution der Daten an verschiedenen Lokationen vereinfacht wird. Mit Hilfe eines Notes-Agenten, d. h. einem auf Basis eines Zeitplans automatisch gestarteten Notes-Programms, das auf einem der Domino-Server ausgeführt wird, werden die Indexblätter in der Notes-Datenbank mit den Daten aus der relationalen EPOS-Datenbank aktualisiert.
Verteilte Dateneingabe
Zur verteilten Dateneingabe dient ein in Notes eingebettetes Java-Applet. Dieses kommuniziert per JDBC mit der relationalen Datenbank. Auf diese Weise können die Notes-Sicherheitsmechanismen ausgenützt werden und eine zusätzliche Eingabe eines Passworts zur Authentisierung entfällt. Da das Indexblatt-Applet per JDBC mit der relationalen Datenbank kommuniziert entfällt weiterhin eine Installation auf dem Client-Rechner, womit eine äußerst einfache verteilte Installation der Anwendung erreicht werden kann.
Applikations-Server
Die Anwendungslogik des Systems befindet sich auf dem Applikations-Server. Dort läuft ein in Java geschrieben Programm, das in regelmäßigen Abständen Simulations-modelle erstellt und berechnet. Dabei wird in einem ersten Schritt ein Objektmodell aus den Daten der relationalen Datenbank erstellt. Aus diesem Modell kann mit Hilfe von Transformationsparametern ein simulierbares Objektmodell abgeleitet werden. Dieses wird dann im zweiten Schritt mittels CORBA auf dem Simulations-Server erstellt und anschließend berechnet. Die Ergebnisse der Simulation werden dann zurück in die Datenbank geschrieben.
Simulations-Client "JAMeS"
Zur Analyse von Szenarien kann der Simulations-Client "JAMeS", eine Java-Anwendung, die mittels CORBA mit dem Simulations-Server kommuniziert, genutzt werden. Mit Hilfe von JAMeS lassen sich sowohl die vom Applikations-Server automatisch generierten als auch interaktiv erstellte Simulationsmodelle editieren und simulieren.
Distribution der Ergebnisse
Zur Distribution der Simulationsergebnisse dient der Reporting-Server. Dieser erstellt aus den in der Datenbank gespeicherten Simulationsergebnissen Standardberichte im HTML-Format, die im Intranet zur Verfügung gestellt werden. Die Auswertungen bilden zusammen mit den Informationen aus der Notes-Datenbank, die über den Domino-Server publiziert werden, die EPOS Intranet-Site, in der alle Informationen strukturiert zusammenfließen.
Optimierung
Um Simulationsmodelle bezüglich Maschineneinsatz, Bearbeitungslosgrößen, Einlastung und Arbeitsplänen zu optimieren, kann ein Optimierungs-Server mittels CORBA auf den Simulations-Server zugreifen. Dabei können die automatisch generierten Simulationsmodelle benutzt werden, die bei der Modellgenerierung vom Applikations-Server mit zusätzlichen zur Optimierung notwendigen Informationen angereicht werden. Die zur Optimierung verwendeten Methoden sind Genetische Algorithmen, die es erlauben, sowohl reellwertige wie auch strukturelle Entscheidungsvariablen in die Optimierung mit einzubeziehen.
Middleware-Technologien
Die Implementation von EPOS nutzt die Vorteile zweier neuer Middleware-Technologien: CORBA und JDBC. Während CORBA eine sprach- und betriebssystemunabhängige Interaktion von verteilten Objekten ermöglicht, eröffnet JDBC die Möglichkeit, Datenbank-Applikationen ohne jegliche Software-Installation auf dem Client-Rechner zu verteilen.
CORBA
EPOS verwendet CORBA als Kommunikationsschnittstelle zwischen dem Simulations-Server und dem Applikations- sowie dem Optimierungs-Server. Dabei spielt es keine Rolle, dass der Simulations-Server in C++ geschrieben ist und auf einem UNIX-System betrieben wird, während der Applikations-Server auf Java basiert und auf einem Windows NT-Rechner betrieben wird. Die Verwendung von CORBA bietet noch weitere Vorteile. Eine Alternative wäre es beispielsweise, die Kommunikation zwischen Client und Server mit Hilfe von TCP/IP-Sockets zu realisieren. Dabei wird der Software-Entwickler mit der Implementation eines eigenen Protokolls belastet. CORBA setzt auf einem höheren Abstraktionsgrad an. Die gesamte Kommunikation findet für den Anwendungsentwickler völlig transparent im ORB sowie Stub und Skeleton statt. Damit kann sich der Entwickler auf die Implementation der Anwendungslogik konzentrieren.
JDBC
Für die Kommunikation zwischen dem Datenbank-Server und einer Datenbankanwendung muss bei Verwendung von ODBC eine Datenquelle definiert werden. Dies erfordert eine Installation und Konfiguration des Datenbanktreibers für das Betriebssystemdes Client-Rechners. Die Anwendung kann dann über die Datenquelle auf die Datenbank zugreifen (Client 1 in Abbildung 3). JDBC erlaubt es, einem Java-Applet den Datenbanktreiber für die Kommunikation zwischen Server und Client mit dem Applet zu laden. Damit entfällt die Installation und Konfiguration des ODBC-Treibers auf dem Client-Rechner. Dies ermöglicht eine äußerst effiziente Verteilung der Anwendung, insbesondere wenn ein großer Personenkreis die Anwendung nutzen soll.
