DE10161064A1

DE10161064A1 - System und Verfahren zur Kommunikation zwischen Softwareapplikationen, insbesondere MES-Applikationen

Info

Publication number: DE10161064A1
Application number: DE10161064A
Authority: DE
Inventors: Dirk Langkafel; Elmar Thurner
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2001-12-12
Filing date: 2001-12-12
Publication date: 2003-07-03
Also published as: US20050010931A1; WO2003050680A2; WO2003050680A3; EP1461697A2; US7343605B2

Abstract

Zu verbindende Anwendungen (A1-A3, MES', MES''), insbesondere MES-Applikationen, aber auch die Kommunikationsmechanismen, werden mittels Wrapper und/oder Adapter in das Objektmodell des Rahmenprogramms (IF; IF steht für Industrial Framework) abgebildet und sind dadurch in einheitlicher homogener Weise im Rahmenprogramm (IF) handhabbar. Der Vorteil liegt darin, dass die sehr heterogenen Strukturen der Applikationen auf ein gemeinsames Modell abgebildet sind und durch generische Mechanismen für einen Anwender sehr komfortabel und leicht benutzbar sind. Das heißt, der Programmierungsaufwand entfällt und diese Kommunikation ist dadurch einfach durch das Etablieren einer sogenannten Connection projektierbar.

Description

Die Erfindung betrifft ein System zur Kommunikation zwischen Softwareapplikationen, insbesondere MES-Applikationen, mit mindestens einem Kommunikationsmittel, mit mindestens einer Rechnereinheit zum Speichern der Softwareapplikationen und mit mindestens einem die Softwareapplikationen koppelnden Rahmenprogramm.
Des Weiteren betrifft die Erfindung ein diesbezügliches Verfahren, ein Computerprogramm, ein Computerprogrammprodukt sowie eine Datenverarbeitungseinrichtung.
Aus "Software für die Automatisierung-Transparenz über die Abläufe schaffen", Artikel von Dirk Kozian in Elektronik für die Automatisierung 11, 17.11.1999 ist bekannt, für die Automatisierung von Produktions- bzw. Fertigungsabläufen so genannte Manufacturing Execution Systems (MES) einzusetzen. Diese Systeme integrieren die Automatisierungsebene (Controls) mit den ERP-Systemen (ERP: Enterprise Resource Planning) der Unternehmensleitebene. Manufacturing Execution Systems sind Systeme, die z. B. Informationen zur Optimierung von Produktionsabläufen bereitstellen. Zum einen müssen die Manufacturing Execution Systems die groben Planungsdaten der ERP-Systeme um anlagenspezifische und aktuelle Feinplanungsdaten ergänzen und diese entsprechend an die unterlagerte Automatisierungsebene weiterleiten, zum anderen haben sie die Aufgabe, aus der Automatisierungsebene produktionsrelevante Informationen zu übernehmen, diese aufzubereiten und an die Unternehmensleitebene weiterzumelden. MES-Systeme erfüllen somit die Aufgabe einer vertikalen Integration zwischen der Unternehmensleitebene und der Automatisierungsebene. Typische Einzelaufgaben von MES-Systemen sind Enterprise Asset Management, Maintenance Management, Information Management, Scheduling, Dispatching und Trace & Track. Diese Aufgaben werden jeweils von MES-Komponenten bzw. MES-Applikationen ausgeführt.
Aufgrund der software- und datentechnischen Heterogenität der MES-Applikationen lassen sich diese aber nur sehr schwer in ein gemeinsames System bzw. Projekt integrieren und der Datenaustausch zwischen diesen Applikationen ist nur mit Aufwand möglich.
Aus "Massive Wiederverwendung: Konzepte, Techniken und Organisation", Artikel von Ulrich Lindner in OBJEKTspektrum 1/96, S. 10-17, ist es bekannt, Softwarekomponenten durch so genannte Adapter oder durch Wrapping (Verpacken) in ein Softwaresystem zu integrieren. Ziel ist es dabei die Wiederverwendbarkeit von Softwarekomponenten zu erhöhen.
In US 5,557,798 wird eine Kommunikationsschnittstelle zwischen Softwareapplikationen beschrieben, über die die Applikationen hochperformant kommunizieren können. Ziel ist es dabei auch die Applikationen unabhängig voneinander und modular entwickeln zu können.
In US 6,115,646 ist ein Prozessautomatisierungssystem auf der Basis eines heterogenen, verteilten Softwaresystems und eines ORBs (Object Request Broker) beschrieben. Als ORB wird dabei CORBA (Common Object Request Broker Architecture) verwendet. Ziel dieser Erfindung ist es Workflow Management Dienste zur Verfügung zu stellen.
Aufgabe der vorliegenden Erfindung ist es ein System und ein Verfahren zur Kommunikation von Softwareapplikationen, insbesondere MES-Applikationen zur Verfügung zu stellen, das es erlaubt, insbesondere heterogene Applikationen leicht zu integrieren und einen effizienten Datenaustausch zwischen ihnen zu ermöglichen.
Gemäß der Erfindung wird die oben genannte Aufgabe für ein System durch die Merkmale des Anspruchs 1 gelöst. Die Erfinder sind dabei von der Erkenntnis ausgegangen, dass durch den Einsatz eines Frameworks (Rahmenprogramms) unter Verwendung von standardisierten Schnittstellen wie OPC (OLE for Process Control), ActiveX, XML (eXtensible Markup Language) oder SOAP (Simple Object Access Protocol) die Interoperabilität zwischen heterogenen Softwareapplikationen (z. B. MES-Applikationen) erreicht wird. Dadurch wird für einen Anwender in einem MES-Projekt (Projekt zur Lösung einer Aufgabe, z. B. Auftragsbearbeitung innerhalb eines MES-Systems) das Prinzip "any data, any time, any where" realisiert. D. h. ein Anwender hat jederzeit Zugriff auf alle Daten, egal, wo sie sich im System befinden. Weiterhin erscheinen im Rahmenprogramm alle Objekte und Daten der Applikationen in homogener Art und Weise, da die Objekte bzw. die Daten der Applikationen auf das Objektmodell (entspricht somit einem einheitlichen homogenen Metaobjektmodell) des Rahmenprogramms abgebildet sind. Das Etablieren und die Handhabung einer Kommunikationsbeziehung zwischen den Applikationen wird dadurch erleichtert. Ein Anwender kann eine Kommunikationsbeziehung zwischen Applikationen Projektieren und muss sie nicht aufwendig Programmieren.
Ein Anwender (z. B. Systemintegrator) erhält eine homogene Sicht über das Gesamtsystem und muss kein spezielles (internes) Wissen über die Applikationsprogramme besitzen.
Eine erste vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein System liegt darin, dass die Kommunikationsbeziehung für einen Anwender und/oder andere Systeme transparent ist von den zugrundeliegenden Kommunikationsmitteln. Durch die Unabhängigkeit und Transparenz der zugrundeliegenden Kommunikationsmittel, z. B. HTTP (Hyper Text Transfer Protocol, COM, (Component Object Model), DCOM (Distributed Component Object Model), MSMQ (Microsoft Message Queue) von der projektierten Kommunikationsbeziehung, kann ein Anwender beim Projektieren einer Kommunikationsbeziehung von diesen Kommunikationsmitteln abstrahieren. Ein Anwender muss sich somit beim Projektieren nicht um Implementierungsdetails dieser Kommunikationsmittel kümmern. Auch bei der Integration bzw. beim "Anschließen" der Softwareapplikationen ans Rahmenprogramm (z. B. durch Wrapping oder durch Adapter) kann an Anwender von den zugrundeliegenden Kommunikationsmitteln abstrahieren und muss keine Implementierungsdetails der Kommunikationsmittel kennen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein System liegt darin, dass die Abbildung auf das Objektmodell durch Adapter und/oder Wrapping erfolgt. Adapter- und Wrappertechnologien sind in der Informationstechnologie bekannte Mechanismen, um Softwarekomponenten in ein System zu integrieren. Ein Wrapper bildet das API (Application Programmable Interface) einer Fremdkomponente (z. B. eine MES-Applikation eines Drittanbieters) in das Objektmodell des Rahmenprogramms ab. So wird z. B. aus einer Methode des API der Fremdkomponente eine Methode des Rahmenprogramms bzw. aus einem Integer-Datentyp des API der Fremdkomponente wird ein Integer-Datentyp des Rahmenprogramms, usw. Für COM- Objekte (Component Object Model) ist die Erstellung eines Wrappers für eine zu integrierende Komponente automatisierbar. Ein Wrapper entspricht einer Bridge. Wrapper lassen sich sehr schnell realisieren.
Adapter sind eine Abstraktionsstufe höher als Wrapper. Sie bieten eine einheitliche Sicht auf angekoppelte Applikationen. Ein Adapter bietet Funktionalität, um die anzukoppelnde Komponente zu starten, zu bedienen etc. Ein Adapter entspricht in der Sprache der Design Patterns einer "Facade".
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein System liegt darin, dass die Kommunikationsbeziehung mit einer Anzeigevorrichtung mit Eingabehilfsmitteln und/oder über ein selbständig arbeitendes Programm eingerichtet ist. Dadurch wird die Flexibilität für einen Anwender erhöht. Durch die Aktivierung eines Batches kann z. B. dynamisch, d. h. zur Laufzeit eine Kommunikationsbeziehung eingerichtet werden. Das selbständig arbeitende Programm kann als ein Batch definiertt und mehrmals verwendet werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein System liegt darin, dass die Kommunikationsbeziehung zwischen zwei oder mehreren Objekten durch das Verbinden der Objekte, die in unterschiedlichen Bildschirmbereichen der Anzeigevorrichtung dargestellt sind, durch ein Drag&Drop mit Hilfe der Eingabehilfsmittel eingerichtet ist. Durch eine geeignete Benutzeroberfläche (z. B. mit Grafikunterstützung, Drag&Drop-Mechanismen, Mauseingabe, Spracheingabe u. a.) wird die Projektierung für den Anwender komfortabel und einfach.
Gemäß der Erfindung wird die oben genannte Aufgabe für ein Verfahren durch die Merkmale des Anspruchs 6 gelöst. Dadurch wird für einen Anwender in einem MES-Projekt (Projekt zur Lösung einer Aufgabe, z. B. Auftragsbearbeitung innerhalb eines MES-Systems) das Prinzip "any data, any time, any where" realisiert. D. h. ein Anwender hat jederzeit Zugriff auf alle Daten, egal, wo sie sich im System befinden. Weiterhin erscheinen im Rahmenprogramm alle Objekte und Daten der Applikationen in homogener Art und Weise, da die Objekte bzw. die Daten der Applikationen auf das Objektmodell (entspricht somit einem einheitlichen homogenen Metaobjektmodell) des Rahmenprogramms abgebildet sind. Das Etablieren und die Handhabung einer Kommunikationsbeziehung zwischen den Applikationen wird dadurch erleichtert. Ein Anwender kann eine Kommunikationsbeziehung zwischen Applikationen projektieren und muss sie nicht aufwendig programmieren.
Ein Anwender (z. B. Systemintegrator) erhält eine homogene Sicht über das Gesamtsystem und muss kein spezielles (internes) Wissen über die Applikationsprogramme besitzen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass die Kommunikationsbeziehung für einen Anwender und/oder andere Systeme transparent ist von den zugrundeliegenden Kommunikationsmitteln. Durch die Unabhängigkeit und Transparenz der zugrundeliegenden Kommunikationsmittel, z. B. HTTP (Hyper Text Transfer Protocol, COM, (Component Object Model), DCOM (Distributed Component Object Model), MSMQ (Microsoft Message Queue) von der projektierten Kommunikationsbeziehung, kann ein Anwender beim Projektieren einer Kommunikationsbeziehung von diesen Kommunikationsmitteln abstrahieren. Ein Anwender muss sich somit beim Projektieren nicht um Implementierungsdetails dieser Kommunikationsmittel kümmern. Auch bei der Integration bzw. beim "Anschließen" der Softwareapplikationen ans Rahmenprogramm (z. B. durch Wrapping oder durch Adapter) kann an Anwender von den zugrundeliegenden Kommunikationsmitteln abstrahieren und muss keine Implementierungsdetails der Kommunikationsmittel kennen, da auch die Kommunikationsmittel auf das Objektmodell des Rahmenprogramms abgebildet werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass die Abbildung auf das Objektmodell durch Adapter und/oder Wrapping erfolgt. Adapter- und Wrappertechnologien sind in der Informationstechnologie bekannte Mechanismen, um Softwarekomponenten in ein System zu integrieren. Ein Wrapper bildet das API (Application Programmable Interface) einer Fremdkomponente (z. B. eine MES-Applikation eines Drittanbieters) in das Objektmodell des Rahmenprogramms ab. So wird z. B. aus einer Methode des API der Fremdkomponente eine Methode des Rahmenprogramms bzw. aus einem Integer-Datentyp des API der Fremdkomponente wird ein Integer-Datentyp des Rahmenprogramms, usw. Für COM- Objekte (Component Object Model) ist die Erstellung eines Wrappers für eine zu integrierende Komponente automatisierbar. Ein Wrapper entspricht einer Bridge. Wrapper lassen sich sehr schnell realisieren.
Adapter sind eine Abstarktionsstufe höher als Wrapper. Sie bieten eine einheitliche Sicht auf angekoppelte Applikationen. Ein Adapter bietet Funktionalität, um die anzukoppelnde Komponente zu starten, zu bedienen etc. Ein Adapter entspricht in der Sprache der Design Patterns einer "Facade".
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass die Kommunikationsbeziehung mit einer Anzeigevorrichtung mit Eingabehilfsmitteln und/oder über ein selbständig arbeitendes Programm eingerichtet wird. Dadurch wird die Flexibilität für einen Anwender erhöht. Durch die Aktivierung eines Batches kann z. B. dynamisch, d. h. zur Laufzeit eine Kommunikationsbeziehung eingerichtet werden. Das selbständig arbeitende Programm kann als ein Batch definiert und mehrmals verwendet werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass die Kommunikationsbeziehung zwischen zwei oder mehreren Objekten durch das Verbinden der Objekte, die in unterschiedlichen Bildschirmbereichen der Anzeigevorrichtung dargestellt werden, durch ein Drag&Drop mit Hilfe der Eingabehilfsmittel eingerichtet wird. Durch eine geeignete Benutzeroberfläche (z. B. mit Grafikunterstützung, Drag&Drop-Mechanismen, Mauseingabe, Spracheingabe u. a.) wird die Projektierung für den Anwender komfortabel und einfach.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung liegt darin, dass das erfindungsgemäße Verfahren durch ein Computerprogramm implementiert ist. Dadurch können eventuelle Modifizierungen bzw. Anpassungen leicht durchgeführt werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung liegt darin, dass das Computerprogramm für das erfindungsgemäße Verfahren auf einem Datenträger bzw. einem Computerprogrammprodukt (Diskette, CD usw.) gespeichert ist. Dadurch ist das Verfahren bezüglich der Logistik und Verteilung leicht handhabbar.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung liegt darin, dass das Computerprogramm für das erfindungsgemäße Verfahren auf einer Datenverarbeitungseinrichtung installiert ist. Dadurch wird die Performance erhöht.
Weitere Vorteile und Details der Erfindung ergeben sich anhand der nun folgenden Beschreibung vorteilhafter Ausführungsbeispiele und in Verbindung mit den Figuren. Soweit in unterschiedlichen Figuren Elemente mit gleichen Funktionalitäten beschrieben sind, sind diese mit gleichen Bezugszeichen gekennzeichnet.
Es zeigen:
Fig. 1 in einer Übersichtsdarstellung die "Unternehmenspyramide" mit drei Steuerungsebenen,
Fig. 2 ein beispielhaftes Übersichtsbild mit Software- und Hardwareeinheiten für MES-Lösungen,
Fig. 3 die zentrale Stellung des die Softwareapplikationen koppelnden Rahmenprogramms,
Fig. 4 die Objektstruktur einer Component als Metaobjektmodell des Rahmenprogramms in UML,
Fig. 5 ein Beispiel für die Abbildung einer Applikation (WinCC) auf eine Component als Metaobjektmodell des Rahmenprogramms,
Fig. 6 ein weiteres Beispiel für die Abbildung einer Applikation (SAP) auf eine Component als Metaobjektmodell des Rahmenprogramms,
Fig. 7 eine Kommunikationsbeziehung zwischen MES- Applikationen,
Fig. 8 die Objektstruktur einer Connection in UML,
Fig. 9 den prinzipiellen Aufbau eines Adapters und
Fig. 10 Bildschirmbereiche für die Projektierung einer Connection.
Die Darstellung gemäß Fig. 1 zeigt in einer Übersichtsdarstellung die drei Steuerungsebenen, wie sie üblicherweise in einem produzierenden bzw. fertigenden Unternehmen zu finden sind. Durch die Pyramidenform wird ausgedrückt, dass nach oben hin eine Verdichtung der Informationen stattfindet. Die oberste Ebene ist die ERP-Ebene (Enterprise Ressource Planing. Auf dieser Unternehmensleitebene werden üblicherweise die betriebswirtschaftlichen und vertrieblichen Aufgaben in einem Unternehmen durchgeführt (z. B. Finanzwesen, Vertriebswesen, Personalwesen, Berichterstattung). Aber auch produktionsanlagenübergreifende logistische Aufgaben (z. B. Auftrags- und Materialverwaltung) werden auf dieser Ebene durchgeführt. Das System SAP R/3 ist ein ERP-System, das auf der Unternehmensleitebene sehr häufig verwendet wird.
Die unterste Ebene der Pyramide ist die Automatisierungs- Ebene (Controls). Auf dieser Ebene kommen üblicherweise speicherprogrammierbare Steuerungen (SPS) in Verbindung mit Visualisierungs- und Prozessleitsystemen (PLS) zum Einsatz. Die Antriebe, Aktoren und Sensoren der Produktions- und/oder Fertigungseinrichtungen stehen direkt mit den Systemen dieser Ebene in Verbindung.
Das Verbindungsglied zwischen der ERP-Ebene und der Automatisierungs-Ebene wird durch die MES-Ebene gebildet. Die Applikationen der MES-Ebene sorgen somit für eine vertikale Integration zwischen der ERP-Ebene und der Automatisierungs-Ebene.
Die MES-Applikationen müssen einerseits die Grobplanungen der ERP-Systeme um produktionsanlagenspezifische Feinplanungen ergänzen und an die Systeme der Automatisierungs-Ebene weiterleiten, andererseits ist es Aufgabe der MES-Applikationen produktionsrelevante Daten der Automatisierungs-Ebene aufzunehmen, aufzubereiten und an die ERP-Ebene (Unternehmensleitebene) weiterzuleiten.
Typische MES-Applikationen sind u. a. Quality Management (QM), Maintenance Management (mm), Performance Analysis (PA), Process Management, Labor Management, Asset Management. Durch jeweils drei Punkte wird in Fig. 1 ausgedrückt, dass sich auf einer Ebene weitere Elemente (Applikationen, Systeme etc.) befinden können.
MES-Systeme bzw. ERP-Systeme enthalten in der Regel ein so genanntes Laufzeitsystem zur zeitlichen Ablaufsteuerung der beteiligten Komponenten (Teilkomponenten, Module, Tasks, Prozesse des Betriebssystems etc.), sowie ein so genanntes Engineeringsystem zum Erstellen und Editieren von Programmen, welche zur Ausführung im Laufzeitsystem vorgesehen sind.
Die Darstellung gemäß Fig. 2 zeigt ein beispielhaftes Übersichtsbild mit Software- und Hardwareeinheiten für MES- Lösungen. Die einzelnen MES-Applikationen A1 bis A3 sind über Adapter AD1 bis AD3 mit einem Rahmenprogramm (Framework) IF verbunden. Über einen bidirektionalen Informationspfad 11 ist ein Benutzerarbeitsplatz PIW1 mit dem Rahmenprogramm IF gekoppelt und kann somit die daran hängenden bzw. integrierten MES-Applikationen verwalten und überwachen. Der Benutzerarbeitsplatz PIW1 besteht üblicherweise aus einer Anzeigevorrichtung (Monitor, Display, etc.), einer Datenverarbeitungsanlage (z. B. PC) mit Prozessor und Speichereinrichtungen sowie Eingabeeinheiten (Keyboard, Maus, etc.). Die MES-Applikationen A1 bis A3 sowie das Rahmenprogramm IF können auf eigenen Datenverarbeitungseinheiten bzw. Prozessoren ablaufen, es ist aber auch möglich, dass sie auf der Datenverarbeitungseinheit des PIW1 ablaufen.
Über Adapter AD1 bis AD3 sind die jeweiligen MES-Applikationen A1 bis A3 mit dem Rahmenprogramm IF verbunden. Die Adapter sind somit die Koppelbausteine zwischen dem Rahmenprogramm IF und den Applikationen. Über die Adapter können somit auch an sich heterogene Applikationen miteinander verbunden werden, und durch die Integration mit dem Rahmenprogramm IF ist es möglich, zwischen den Applikationen zu kommunizieren und Datenaustausch zu betreiben. Die Adapter sind Softwaremodule, die Verbindungen zu verschiedenen Anwendungen bzw. Applikationen herstellen. In typischen Integrationsszenarien sind dies Integrationen zu Systemen aus der MES-, ERP- SCADA- oder Controls-Welt Ein Adapter bietet Funktionalität, um eine anzukoppelnde Komponente zu starten, zu bedienen, etc. Ein Adapter erlaubt den Zugriff auf Daten und Funktionen der anzukoppelnden Anwendung bzw. Applikation, stellt . bestimmte Runtimedaten zur Verfügung und erlaubt das Laden von Engineeringinformationen aus der anzukoppelnden Anwendung bzw. Applikation. Adapter können sich hinsichtlich ihres Aufbaus und Umfangs unterscheiden. So können Adapter z. B. fest programmiert sein oder sie können konfiguriert bzw. modelliert werden. Auch bezüglich der Möglichkeiten des Zugriffs auf die anzukoppelnde Applikation können sie sich unterscheiden, so können z. B. Adapter nur einen datentechnischen Zugang gestatten, es ist aber auch möglich, dass Adapter einen Zugang auf höherwertige Geschäftsabläufe zulassen. Beim Hochfahren werden die Adapter mit den hinterlegten Modellen und Zustandsinformationen geladen. Zur Laufzeit wird dann überprüft, ob und wie die unterschiedlichen integrierten Applikatonen bzw. Anwendungen zusammenpassen. Über eine Visualisierungs- bzw. Monitoringkomponente ist es möglich, den Status eines Adapters abzufragen und am Benutzerarbeitsplatz PIW1 darzustellen (auch graphisch). Durch Adapter erhält das System und auch der Anwender eine standardisierte und einheitliche Sicht auf Applikationen (je nachdem, welche Abstraktionsebene bei den Adaptern vorhanden ist).
Eine weitere Möglichkeit Softwarekomponenten zu integrieren, ist es, Wrapper einzusetzen. Ein Wrapper bildet das API (Application Programmable Interface) einer Fremdkomponente (z. B. eine MES-Applikatioh) in das Objektmodell des Rahmenprogrammes ab. So wird z. B. aus einer Methode des API der Fremdkomponente eine Methode des Rahmenprogramms bzw. aus einem Integer-Datentyp des API der Fremdkomponente wird ein Integer- Datentyp des Rahmenprogramms.
Neben MES-Applikationen können auch Applikationen aus der Unternehmensleitebene (Enterprise Resource Planning-Ebene) und/aus der Automatisierungsebene (Controls-Ebene) über das Rahmenprogramm IF integriert werden und über den Arbeitsplatz PIW1 (das Acronym PIW steht für Personalized Industrial Workplace) überwacht bzw. verwaltet werden. Das Rahmenprogramm IF bildet somit eine Integrationsplattform für den gesamten industriellen Bereich. Unterschiedliche Applikationen aus der Unternehmensleitebene, der MES-Ebene und der Automatisierungsebene lassen sich durch das Rahmenprogramm IF einfach und wirtschaftlich mit Hilfe von Adaptern und/oder Wrappern integrieren. Das Rahmenprogramm IF ist somit als Middleware-Plattform und als Manufacturing Application Integration- Werkzeug anzusehen. Über den Arbeitsplatz PIW1 kann ein Benutzer (z. B. der Anlagenfahrer) die jeweiligen Zustände der zu überwachenden Applikationen sehen, und er kann auch auf Daten und auf Methoden der Applikationen zugreifen, und weiterhin kann er durch diesen Zugriff Applikationen miteinander in Verbindung setzen.
Das Rahmenprogramm IF ermöglicht es somit, zum einen eine vertikale Integration von Applikationen aus unterschiedlichen Unternehmensebenen zu erreichen und zum anderen ermöglicht das Rahmenprogramm IF eine horizontale Integration von Applikationen der MES-Ebene.
Der Arbeitsplatz PIW1 stellt für einen Benutzer an der Frontendseite von MES-Applikationen oder anderen Applikationen aus dem Unternehmen ein "One Window to the World" dar. Das heißt, der Arbeitsplatz ermöglicht, über eine gemeinsame einheitliche Oberfläche einen integrativen Zugang auf unterschiedliche, auch heterogene Anwendungen im Unternehmen. Der Benutzer des Arbeitsplatzes PIW1 kann somit von diesem einen Arbeitsplatz aus alle integrierten MES- oder anderen Anwendungen überwachen und verwalten. Dieser Arbeitsplatz kann über das Internet, das Intranet, LAN (Local Area Network) oder andere denkbare Verbindungen mit den Applikationen verbunden sein. Es ist auch möglich, diesen Arbeitsplatz als mobile Station, z. B. als mobiles Endgerät (PDA, Handy) auszugestalten. Diese Mobilität würde für einen Benutzer noch weitere Vorteile bringen.
Die Darstellung gemäß Fig. 3 zeigt die zentrale Stellung des die Softwareapplikationen koppelnden Rahmenprogramms. Um das erfindungsgemäße System oder Verfahren zu realisieren, bietet es sich an, eine Client-Server-Architektur zu wählen. Das Rahmenprogramm (IF; Fig. 2) kann dabei auf einem einzigen Server oder auf mehreren beliebigen Servern, die sich in einer IT-Landschaft verteilen können, realisiert sein. In Fig. 3 ist dargestellt, dass sich das Rahmenprogramm (IF; FTG 2) auf einem Server IFS (Industrial Framework Server) befindet. An diesem zentralen Server IFS hängen durch die bidirektionalen Informationspfade I2-I8 verbunden, die Clients. Zu den Clients zählen zum einen die Applikationen aus der ERP-, der MES- und der Automatisierungsebene. In Fig. 3 sind diese Applikationen am unteren Bildrand dargestellt. Über die Adapter AD4-AD6 sind diese Applikationen mit dem Rahmenprogramm (IF; Fig. 2) und somit mit dem Server IFS verbunden. Die Verbindung der Adapter AD4-AD6 mit den Applikationen erfolgt über API-Schnittstellen API1-API3 (API steht für Application Programmable Interface). Ein Application Programmable Interface stellt eine Schnittstelle mit einer Menge von Kommandos dar. APIs werden auch verwendet bei der Umsetzung von Parameterlisten von einem Format in ein anderes Format und bei der Interpretation der Argumente in eine oder beide Richtungen. Die APIs sind sozusagen der Klebstoff zwischen den Applikationen und den Adaptern. Die Verbindung zwischen den Adaptern AD4-AD6 mit dem Rahmenprogramm (IF; Fig. 2) (in Fig. 3 dargestellt durch die bidirektionalen Informationspfade I3-I5) geschieht über geeignete Datenformate (z. B. XML), geeignete Protokolle (XOP, OPC, etc.) und geeignete Transportmechanismen (z. B. DCOM oder MSMQ). Auch HTTP (Hyper Text Transfer Protocol) kann hierbei verwendet werden. Auch das auf XML eXtensible Markup Language) beruhende Protokoll SOAP (Simple Object Access Protocol) kann für die Integration der Adapter AD4-AD6 an das Rahmenprogramm (IF; Fig. 2) bzw. den zugehörenden Server IFS verwendet werden. Clients bzw. Applikationen, die ActiveX-Dokumente bzw. -Aufrufe unterstützen, lassen sich besonders vorteilhaft in das Rahmenprogramm (IF; Fig. 2), bzw. den Server IFS integrieren. Die Anbindung der Applikationen an das Rahmenprogramm kann neben Adaptern auch durch Wrapper oder anderen Integrationsmechanismen erfolgen.
Als weiterer Client kann mit dem Server IFS das Repository IFR (Industrial Framework Repository) verbunden sein. In Fig. 3 ist die Verbindung durch den bidirektionalen Informationspfad 12 dargestellt. Das Repository IFR wird verwendet, um Daten sicher und persistent zu halten. Über Methodenaufrufe kann auf diese Daten zugegriffen werden. Im Repository sind u. a. Objekte, Methoden und Laufzeitdaten gespeichert.
Auf der oberen Bildhälfte sind weitere Clients des Servers IFS dargestellt. Der Personalized Industrial Workplace PIW2 und eine eventuell vorhandene Engineerungumgebung EU sind Clients des Servers IFS. Der Personalized Industrial Workplace PIW2 ist durch den bidirektionalen Informationspfad 16 mit dem Rahmenprogramm (IF; Fig. 2) bzw. mit dem Server verbunden, die Engineeringumgebung EU entsprechend durch den bidirektionalen Informationspfad 17. Durch die drei Punkte ist dargestellt, dass weitere Clients am Server IFS hängen können. In Fig. 3 ist angedeutet, dass außerdem ein weiterer Client C, verbunden durch den Informationspfad 18, am Server IFS hängt.
Die Verbindung der Clients IFR, PIW2, EU, C geschieht entsprechend über APIs bzw. über gängige Datenformate (z. B. XML), gängige Protokolle (XOP, OPC, etc.) und gängige Transportmechanismen (z. B. DCOM, HTTP oder MSMQ).
Die eingesetzten Adapter AD4-AD6 ermöglichen den Zugang zu Daten und auch zu Methoden der einzelnen Applikationen, die sie mit dem Rahmenprogramm (IF; Fig. 2) verbinden. Diese Adapter sind sehr flexibel und nicht auf einzelne spezielle Protokolle oder spezielle Transportmechanismen festgelegt. Wenn die Adapter in einer Laufzeitumgebung eingesetzt werden, dann sind sie so konfiguriert, dass sichergestellt ist, dass bestimmte benötigte Daten aus einer Applikation zum richtigen Zeitpunkt in der Serverumgebung vorhanden sind. Dies kann, wie schon gesagt, über unterschiedliche Protokolle und Transportmechanismen erfolgen. In einer Laufzeitumgebung können sich mehrere Adapter, die auch kleine Servereigenschaften (wie beispielsweise das Ausführung von Workflows, die Bereitstellung verschiedener Kommunikationsmöglichkeiten, . . .) besitzen können, befinden. Diese Adapter können auf dem jeweiligen Applikationsrechner laufen. Sie müssen aber nicht nur auf einer Maschine laufen, sie können auch verteilt sein.
Softwareapplikationen, insbesondere MES-Applikationen (Manufacturing Execution Systems), liegen oft in einer heterogenen Form vor, z. B. können sie unterschiedliche Datenformate oder Objektmodelle besitzen oder sie sind in unterschiedlichen Programmiersprachen realisiert. Das erfindungsgemäße System bzw. Verfahren ermöglicht es, solche heterogenen Applikationen mit Hilfe eines Rahmenprogramms zu integrieren. Die Kommunikation zwischen diesen Applikationen erfolgt auf der Basis von Kommunikationsmitteln wie z. B. HTTP, DCOM, MSMQ, etc. Die Kommunikation, d. h. der Datenaustausch zwischen den Applikationen ist aber unabhängig von diesen Kommunikationsmitteln, d. h. die Applikationen können von den Applikationsmitteln abstrahieren.
Die Darstellung gemäß Fig. 4 zeigt die Objektstruktur einer "Component" als Metaobjektmodell des Rahmenprogramms (IF; Fig. 2) in UML (Unified Modelling Language). Beim erfindungsgemäßen System und Verfahren werden die zu integrierenden Softwareappliaktionen und die zugrunde liegenden Kommunikationsmittel (z. B. HTTP, MSMQ, etc.) auf ein Objektmodell des Rahmenprogramms (IF; Fig. 2) abgebildet. Dadurch besitzen an sich heterogene Applikationen ein gemeinsames Objektmodell. Dadurch werden alle Methoden, Datenstrukturen, Objekte usw. der zu integrierenden Fremdapplikationen in einem gemeinsamen Objektmodell dargestellt. Dieses Objektmodell ist sehr generisch und stellt ein Metaobjektmodell dar. Der Kern dieses Objektmodells besteht aus einem Objekttyp namens "Component". Eine Component kann wiederum andere Components aggregieren und/oder spezielle Typen von Components, so genannte Variablen, denen im Betrieb bestimmte Werte zugewiesen sind, enthalten. Components und Variablen können jeweils auch zusätzliche Attribute besitzen.
Dieses Objektmodell bildet die Basis der Adaptierung von MES- Applikationen oder anderen Applikationen. Das bedeutet, dass die Strukturen der Applikationen in Strukturen dieses Objektmodells übersetzt bzw. abgebildet werden. Alle zu integrierenden Applikationen werden innerhalb des Rahmenprogramms (IF, Fig. 2) in der Darstellung dieses Objektmodells repräsentiert. Auch die zugrunde liegenden Kommunikationsmittel werden auf dieses generische Objektmodell abgebildet. Im Rahmenprogramm (IF; Fig. 2) sind nun alle Applikationen und alle zugrunde liegenden Kommunikationsmittel in einem einheitlichen und homogenen Objektmodell repräsentiert. Dadurch können sehr einfach und leicht Kommunikationsbeziehungen zwischen den Applikationen eingerichtet werden.
In der Darstellung gemäß Fig. 4 ist die generische Komponente "Component", die den Kern des Objektmodells darstellt, in UML-Notation aufgezeigt.
Die rechteckigen Kästchen stellen Teile des Objektmodells dar. Durch eine Rautenbeziehung wird eine Aggregation (ist Teil von-Beziehung) dargestellt, durch eine Dreiecksbeziehung wird die Vererbung (ist ein-Beziehung) dargestellt. In der Darstellung gemäß Fig. 4 wird somit gezeigt, dass eine Component aus mehreren Components bestehen kann, weiterhin kann eine Component Teil einer anderen Component sein. Durch die Rautenbeziehung ist eine Component mit Attributen und Variablen verbunden. Das heißt, eine Component kann Attribute und Variable beinhalten. Attribute sind beschreibende Daten. Alle Objekte einer Klasse besitzen dieselben Attribute, jedoch im Allgemeinen unterschiedliche Attributwerte. Ein Attributwert ist ein einem Attribut zugeordneter Wert aus seinem Wertebereich. Eine Variable kann Werte von bestimmten Datentypen (z. B. Integer, Real etc.) annehmen. Wie durch die Rautenbeziehung dargestellt, kann eine Component mehrere Variablen enthalten. Eine Component kann aber auch eine Oberklasse einer Variable sein, wie durch die Dreiecksbeziehung dargestellt. Das heißt, eine Variable kann eine abgeleitete Component sein. Die Rauten- und die Dreiecksbeziehungen können auch Kardinalitäten beinhalten.
Durch Abbildungsmechanismen wie z. B. Adapter oder Wrapper werden die zu integrierenden Softwareapplikationen und die zugrunde liegenden Kommunikationsmittel auf diese generische Objektstruktur, d. h. "Component"-Struktur, des Rahmenprogramms (IF; Fig. 2) abgebildet.
In der Darstellung gemäß Fig. 5 ist dargestellt, wie die MES- Applikation WinCC (WinCC ist der Name für ein Prozessbeobachtungssystem der Firma Siemens) auf die "Component"-Struktur, wie sie in Fig. 4 dargestellt ist, abgebildet wird. Durch den Pfeil in der Mitte von Fig. 5 ist dargestellt, dass es sich um eine Abbildung, d. h. um eine Transformation, handelt. Durch die Abkürzung IF oberhalb dieses Pfeils wird angedeutet, dass es sich bei der Abbildung um eine Abbildung in das Objektmodell des Industrial Frameworks, d. h. des zugrunde liegenden Rahmenprogramms (IF; Fig. 2) handelt.
Das Objektmodell von WinCC besteht aus Namensräumen (NS steht für Name Space) mit so genannten "Tags". Tags sind einfache Datenobjekte, deren Eigenschaften zwischen Server und Clients ausgetauscht werden können. Ihre Eigenschaften können dynamisch, aber auch statisch sein. In einer zu integrierenden externen Applikation können Tags in einem flachen oder einem hierarchischen Namensraum vorliegen. Tags können außerdem mit Zugriffsrechten (lesbar, schreibbar, les-/schreibbar) versehen sein. In einem Adapter ist ein Tag ein Platzhalter (Proxy) eines Objektes einer zu integrierenden externen Applikation.
Zu unterscheiden ist hierbei, dass der Begriff "Tag" in Sprachen wie HTML oder XML für Markierungen verwendet wird.
Am linken Bildrand von Fig. 5 ist dargestellt, dass der WinCC- Namensraum (NS) die Tags 1 und Tags 2 enthält. Durch drei Punkte ist dargestellt, dass er auch weitere Tags enthalten kann. Durch Adapter, Wrapper oder andere Mechanismen wird diese Struktur auf die "Component"-Struktur des Metaobjektmodells, wie es am rechten Bildrand von Fig. 5 dargestellt ist, abgebildet. Der Namensraum NS wird die Component NS, die als Variable die Tags 1 und Tags 2 enthält. Durch drei Punkte ist dargestellt, dass die Component NS weitere Elemente enthalten kann. Die gewählte Notation ist angelehnt an die Collaboration-Diagramme, wie sie in UML bekannt sind.
In der Darstellung gemäß Fig. 6 ist dargestellt, wie eine SAP- Applikation auf die "Component"-Struktur (Metaobjektmodell des Rahmenprogramms) abgebildet wird. Auch in Fig. 6 wird durch den mittig angebrachten Pfeil gezeigt, dass eine Abbildung bzw. Transformation dargestellt wird. Auf der linken Seite von Fig. 6 ist die tabellenartige IDOC-Struktur von SAP- Applikationen dargestellt. In Fig. 6 sind in der Tabelle die zwei Einträge S1 und S2 dargestellt, weiterhin ist durch einen Pfeil von S1 zu S2 dargestellt, dass ein Verweis vom Eintrag S1 auf den Eintrag S2 vorhanden ist. Durch die drei Punkte wird ausgedrückt, dass eine IDOC-Tabelle weitere Elemente enthalten kann. Eine IDOC-Tabelle wird auf eine Component IDOC des Objektmodells des Rahmenprogramms (IF; Fig. 2) abgebildet. Die Einträge der Tabelle (S1, S2) werden jeweils auf Variablen der Component IDOC abgebildet. Die gewählte Notation ist angelehnt an die Collaboration-Diagramme, wie sie in UML bekannt sind.
Auch die zugrunde liegenden Kommunikationsmechanismen (HTTP, MSMQ, DCOM, etc.) werden jeweils auf eine solche "Component"- Struktur abgebildet. Dadurch ist eine uniforme und homogene Handhabung der verschiedenen Kommunikationsmittel möglich.
In der Darstellung gemäß Fig. 7 wird dargestellt, wie eine Kommunikationsbeziehung zwischen MES-Applikation eingerichtet wird. Wie schon oben erklärt, werden die Applikationen und die zugrunde liegenden Kommunikationsmechanismen auf eine einheitliche "Component"-Struktur (Metaobjektmodell des Rahmensprogramms) abgebildet.
In Fig. 7 ist dargestellt, wie eine Kommunikationsverbindung zwischen den MES-Applikationen MES' und MES" eingerichtet wird. Über Adapter bzw. über Wrapper werden diese MES- Applikationen MES' und MES" auf die "Component"-Struktur des Rahmenprogramms (IF; Fig. 2) abgebildet. Auch die zugrunde liegenden Kommunikationsmittel (HTTP, MSMQ, DCOM, etc.) werden über Adapter oder Wrapper auf das generische Objektmodell einer "Component"-Struktur abgebildet. Im Rahmenprogramm (IF; Fig. 2) werden dann diese Kommunikationsmittel durch eine Component Transportsystem (TS) repräsentiert. Diese Component Transportsystem (TS) abstrahiert von dem zugrunde liegenden Kommunikationsmitteln. Bei der Einrichtung einer Kommunikationsverbindung ist es somit egal, welches Kommunikationsmittel letztendlich physikalisch zugrunde liegt. Die Kommunikationsmittel sind somit grundsätzlich austauschbar.
Die Kommunikationsbeziehung zwischen den MES-Applikationen MES' und MES" wird durch eine so genannte "Connection" hergestellt. Eine Connection verbindet zwei beliebige Objekte des Objektmodells. Da sich die Connection auf Objekte des generischen Objektmodells bezieht, kennt sie deren Semantik und weiß, welche Besonderheiten beim Verbinden herzustellen sind, d. h. Methodenobjekte sind anders zu handhaben als z. B. reine Datenobjekte. Weiterhin stützt sich die Connection auf ein Transportsystem ab. Auch das Transportsystem liegt als Teil des generischen Objektmodells des Rahmenprogramms (IF; Fig. 2) vor. Eine Connection kann unidirektional oder bidirektional sein.
Für die Projektierung der Kommunikationsbeziehung zwischen Applikationen können Datenflussdiagramme verwendet werden, durch Verbindung der Knoten durch entsprechende Datenflüsse.
Die Darstellung gemäß Fig. 8 zeigt die Objektstruktur einer "Connection" in UML-Notation. Eine Connection ist ein generisches Objekt, das im Wesentlichen aus zwei Teilen besteht. Zum einen aus den Wrappern des spezifischen Kommunikationsmittels und andererseits aus einer Sammlung von Properties, d. h. Eigenschaften, die über dieses Kommunikationsmittel eingestellt werden können. Diese Properties und die Connection selbst sind wiederum "Components" des Objektmodells, wobei die Properties einfach durch eine Liste von Variablen gegeben sind. Ein Transport-Wrapper enthält auch wiederum Properties, d. h. Eigenschaften. Im Falle der Verwendung von MSMQ als Kommunikationsmittel ist z. B. der Name der verwendeten Message Queue eine solche Eigenschaft. Durch die Kardinalität (1 : 2) wird angedeutet, dass die Connection aus Fig. 8 mindestens einen, aber höchstens zwei Transport-Wrappers beinhaltet. Auch die anderen Aggregationsbeziehungen (Rautensymbol), wie sie in Fig. 8 dargestellt sind, können Kardinalitäten beinhalten. Ein Transport-Wrapper kann auch Methoden beinhalten. Zum Beispiel eine Methode zum Öffnen eines spezifischen Transportkanals, eine Methode zum Schließen eines spezifischen Transportkanals, eine Methode, um einen String zu senden, eine Methode, um einen String zu empfangen, usw.
Kommunikationsmittel werden üblicherweise durch Wrappers auf das Objektmodell des Rahmenprogramms abgebildet, prinzipiell ist es aber auch möglich, Kommunikationsmittel durch Adapter im Rahmenprogramm zu integrieren.
Die Darstellung gemäß Fig. 9 zeigt den prinzipiellen Aufbau eines Adapters. Jeder Adapter ist eine spezielle Component mit der besonderen Eigenschaft, dass die Component eines Adapters jeweils in einem eigenen Prozess läuft. Jeder Adapter bringt schon eine bestimmte Default-Struktur mit, die wieder als Baumstruktur von Objekten des Rahmenprogramms, d. h. Components und Variablen, dargestellt ist, und die bestimmte Stellen zur Verfügung stellt, an denen der Adapter bestimmte Informationen nach außen legen kann. Beispiele dafür sind Statusinformationen über den Zustand des Adapters (ist der Adapter mit seiner Anwendung verbunden, läuft die Anwendung, Versionsinformationen, usw.). Weiterhin kann ein Adapter Informationen über das externe System, d. h. die externe Applikation, nach außen geben. Durch den "Object Space" kann ein Adapter Strukturen nach außen legen, auf die andere Adapter bzw. andere Applikationen zugreifen können. Auch kann ein Adapter Informationen bezüglich einer Kommunikationsinfrastruktur nach außen geben. Unter Kommunikationsinfrastruktur versteht man Objekte, um Nachrichten zu senden, zu empfangen, Nachrichten zu transformieren. Aber auch Mechanismen, um ein Routing vorzunehmen und Mechanismen, um den Datenaustausch des Adapters zu protokollieren. Weiterhin gehören zur Kommunikationsinfrastruktur eines Adapters so genannte Inports und Outports, die physikalisch die Nachrichten empfangen oder versenden. Ein Adapter ist als eigener Prozess des Betriebssystems vorhanden, d. h. wenn ein Adapter abstürzt, dann hat das keine Auswirkungen auf andere Adapter. Ein Adapter ist somit eine eigene geschlossene Anwendung, die alleine ausführbar ist.
Adapter und Wrapper sind Mechanismen für die Integration von Softwarekomponenten in ein Softwaresystem. Ein Wrapper bildet das API (Application Programmable Interface) einer Fremdkomponente bzw. einer zu integrierenden Applikation in das Objektmodell des Softwaresystems, hier Rahmenprogramms (IF; Fig. 2) ab. So wird z. B. aus einer Methode des API der zu integrierenden Applikation eine Methode des Rahmenprogramms bzw. aus einem Integer-Datentyp des API der zu integrierenden Applikation wird ein Integer-Datentyp des Rahmenprogramms, usw. Ein Wrapper bringt somit das API der zu integrierenden Applikation in die Sprache, in die Nomenklatur und in die Objektwelt des Rahmenprogramms.
Ein Adapter dagegen ist eine Abstraktionsstufe höher als ein Wrapper. Adapter stellen eine standardisierte Sicht auf zu integrierende Applikationen dar, und das Rahmenprogramm, in das die zu integrierende Applikation eingehängt wird, kann von dieser Applikation abstrahieren. Ein Adapter stellt Funktionalität zur Verfügung, um das zu integrierende System, d. h. die zu integrierende Applikation, zu starten, zu bedienen und zu handeln. Mit Hilfe der Adapter kann z. B. ein Anwender eine SAP-Applikation benutzen, ohne ein SAP-Experte zu sein. Durch die IDOC-Adapter (siehe Fig. 6) werden SAP- Applikationen in das Objektmodell des Rahmenprogramms abgebildet und werden dann als Objekte des Rahmenprogramms (Component IDOC) verwendet.
Durch das erfindungsgemäße System und Verfahren können zwei Applikationen (z. B. MES-Applikationen) peer-to-peer-mäßig zusammengebracht werden, ohne dass eine solche Verbindung jeweils peer-to-peer-mäßig programmiert werden muss. Diese Verbindungen werden erfindungsgemäß projektiert durch das Etablieren einer Connection (siehe Fig. 7).
Die Darstellung gemäß Fig. 10 zeigt eine Projektierungsoberfläche für das Einrichten einer Kommunikationsverbindung zwischen Applikationen. Die Anzeigevorrichtung A2 (z. B. ein Monitor oder ein Display) besitzt eine oder mehrere Menüleisten ML. Die Menüleisten ML enthalten Funktionsknöpfe, die vom Anwender z. B. via Mausklick aktiviert werden können. Vom Anwender sind in den Menüleisten ML auch eigen definierte Funktionsknöpfe ablegbar. Das Bedienen bzw. Aktivieren der Projektierungsoberfläche kann auch über andere Eingabehilfsmittel (z. B. Keyboard, Lichtgriffel oder ähnlichem) erfolgen. In Fig. 10 ist die Projektierungsoberfläche in die Bildschirmbereiche BB1-BB3 aufgeteilt. Es ist aber auch denkbar, dass weitere oder aber auch nur ein oder zwei Bildschirmbereiche vorhanden sind.
In den Bildschirmbereichen BB1 und BB2 sind die Objektstrukturen OB1, OB2 der Applikationen dargestellt, zwischen denen eine Kommunikationsbeziehung eingerichtet werden soll. Es ist aber auch denkbar, dass in den Bildschirmbereichen BB1 und/oder BB2 nur die Struktur der jeweiligen Adapter dargestellt wird. Ein Anwender kann nun über Drag&Drop-Mechanismen Elemente der beiden Objektstrukturen OB1, OB2 miteinander verbinden. Wenn ein Anwender eine solche Kommunikationsbeziehung einrichtet, werden in einem Bildschirmbereich BB3 Informationen bezüglich dieser Verbindung oder bezüglich der Verbindungen dargestellt. Solche Informationen können sich auf den Namen, auf den Wert (Value) oder auf den Typ der eingerichteten Verbindung beziehen. Es ist auch denkbar, dass weitere Informationen bezüglich einer Verbindung dargestellt werden. Durch den in Fig. 10 beschriebenen Mechanismus ist es für einen Anwender möglich, Kommunikationsbeziehungen zwischen zwei Applikationen zu projektieren. Kommunikationsbeziehungen zwischen zwei Applikationen müssen somit nicht mehr einzeln programmiert werden. Die Effizienz bei der Erstellung von Softwarelösungen für MES-Systeme steigt dadurch enorm, und besonders Systemintegratoren und Systementwickler können ihre Effizienz steigern.
Zu verbindende Anwendungen, insbesondere MES-Applikationen aber auch die Kommunikationsmechanismen, werden mittels Wrapper und/oder Adapter in das Objektmodell des Rahmenprogramms (Industrial Framework) abgebildet und sind dadurch in einheitlicher homogener Weise im Rahmenprogramm (Industrial Framework) handhabbar. Der Vorteil liegt darin, dass die sehr heterogenen Strukturen der Applikationen auf ein gemeinsames Modell abgebildet sind und durch generische Mechanismen (Objekt Component als Metaobjektmodell) für einen Anwender sehr komfortabel und leicht benutzbar sind. Das heißt, der Programmierungsaufwand entfällt und diese Kommunikation ist dadurch einfach durch das Etablieren einer so genannten Connection projektier bar.
Das oben beschriebene erfindungsgemäße System bzw. Verfahren lässt sich als Computerprogramm in dafür bekannten Sprachen implementieren. Ein derartig implementiertes Computerprogramm kann in ebenfalls bekannter Weise über elektronische Datenwege, aber auch auf Datenträgern abgespeichert und transportiert werden.

Claims

1. System zur Kommunikation zwischen Softwareapplikationen (A1-A3, MES', MES"), insbesondere MES-Applikationen,
mit mindestens einem Kommunikationsmittel,
mit mindestens einer Rechnereinheit zum Speichern der Softwareapplikationen (A1-A3, MES', MES"),
mit mindestens einem die Softwareapplikationen (A1-A3, MES', MES") koppelnden Rahmenprogramm (IF),
dadurch gekennzeichnet, dass
die Softwareapplikationen (A1-A3, MES', MES") auf ein Objektmodell des Rahmenprogrammes (IF) abgebildet sind, die Kommunikationsmittel auf das Objektmodell des Rahmenprogrammes (IF) abgebildet sind,
eine Kommunikationsbeziehung zwischen zwei oder mehreren Objekten des Objektmodells eingerichtet ist durch Verbindung von Methoden der Objekte und/oder Daten der Objekte und/oder der Objekte selbst und
über die Kommunikationsbeziehung ein Daten- und/oder Informations- und/oder Ereignissaustausch stattfindet, wobei über die Kommunikationsbeziehung beliebige Daten und/oder Informationen und/oder Ereignisse der Softwareapplikationen (A1-A3, MES', MES") unabhängig vom internen Format der jeweiligen Softwareapplikationen (A1-A3, MES', MES") und/oder unabhängig vom zugrunde liegenden Format der Kommunikationsmittel ausgetauscht werden.

2. System nach Anspruch 1, dadurch gekennzeichnet, dass die Kommunikationsbeziehung für einen Anwender und/oder andere Systeme transparent ist von den zugrundeliegenden Kommunikationsmitteln.

3. System nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, dass die Abbildung auf das Objektmodell durch Adapter (AD1-AD6) und/oder Wrapping erfolgt.

4. System nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Kommunikationsbeziehung mit einer Anzeigevorrichtung (AZ) mit Eingabehilfsmitteln und/oder über ein selbständig arbeitendes Programm eingerichtet ist.

5. System nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Kommunikationsbeziehung zwischen zwei oder mehreren Objekten durch das Verbinden der Objekte, die in unterschiedlichen Bildschirmbereichen der Anzeigevorrichtung (AZ) dargestellt sind, durch ein Drag&Drop mit Hilfe der Eingabehilfsmittel eingerichtet ist.

6. Verfahren zur Kommunikation von Softwareapplikationen (A1-A3, MES', MES"), insbesondere MES-Applikationen, basierend auf mindestens einem Kommunikationsmittel und mindestens einem die Softwareapplikationen (A1-A3, MES', MES") koppelnden Rahmenprogramm (IF), wobei die Softwareapplikationeri (A1-A3, MES', MES") auf mindestens einer Rechnereinheit gespeichert werden, dadurch gekennzeichnet, dass

a) die Softwareapplikationen (A1-A3, MES', MES") auf ein Objektmodell des Rahmenprogrammes (IF) abgebildet werden,

b) die Kommunikationsmitteln auf das Objektmodell des Rahmenprogrammes (IF) abgebildet werden,

c) eine Kommunikationsbeziehung zwischen zwei oder mehreren Objekten des Objektmodells eingerichtet wird durch Verbindung von Methoden der Objekte und/oder Daten der Objekte und/oder der Objekte selbst und

d) über die Kommunikationsbeziehung ein Daten- und/oder Informations- und/oder Ereignissaustausch stattfindet, wobei über die Kommunikationsbeziehung beliebige Daten und/oder Informationen und/oder Ereignisse der Softwareapplikationen unabhängig vom internen Format der jeweiligen Softwareapplikationen und/oder unabhängig vom zugrunde liegenden Format der Kommunikationsmittel ausgetauscht werden.

7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass die Kommunikationsbeziehung für einen Anwender und/oder andere Systeme transparent ist von den zugrundeliegenden Kommunikationsmitteln.

8. Verfahren nach Anspruch 6 oder Anspruch 7, dadurch gekennzeichnet, dass die Abbildung auf das Objektmodell durch Adapter (AD1-AD6) und/oder Wrapping erfolgt.

9. Verfahren nach einem der Ansprüche 6 bis 8, dadurch gekennzeichnet, dass die Kommunikationsbeziehung mit einer Anzeigevorrichtung (AZ) mit Eingabehilfsmitteln und/oder über ein selbständig arbeitendes Programm eingerichtet wird.

10. Verfahren nach einem der Ansprüche 6 bis 9, dadurch gekennzeichnet, dass die Kommunikationsbeziehung zwischen zwei oder mehreren Objekten durch das Verbinden der Objekte, die in unterschiedlichen Bildschirmbereichen der Anzeigevorrichtung (AZ) dargestellt werden, durch ein Drag & Drop mit Hilfe der Eingabehilfsmittel eingerichtet wird.

11. Computerprogramm, das ein Verfahren nach einem der Ansprüche 6 bis 10 implementiert.

12. Datenträger, auf dem ein Computerprogramm nach Anspruch 11 gespeichert ist.

13. Datenverarbeitungseinrichtung (PIW1, PIW2, IFS) auf der ein Computerprogramm nach Anspruch 11 installiert ist.