EP1461697A2 - SYSTEM UND VERFAHREN ZUR KOMMUNIKATION ZWISCHEN SOFTWAREAPPLIKATIONEN, INSBESONDERE MES−APPLIKATIONEN - Google Patents

SYSTEM UND VERFAHREN ZUR KOMMUNIKATION ZWISCHEN SOFTWAREAPPLIKATIONEN, INSBESONDERE MES−APPLIKATIONEN

Info

Publication number
EP1461697A2
EP1461697A2 EP02804564A EP02804564A EP1461697A2 EP 1461697 A2 EP1461697 A2 EP 1461697A2 EP 02804564 A EP02804564 A EP 02804564A EP 02804564 A EP02804564 A EP 02804564A EP 1461697 A2 EP1461697 A2 EP 1461697A2
Authority
EP
European Patent Office
Prior art keywords
mes
communication
applications
objects
object model
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP02804564A
Other languages
English (en)
French (fr)
Inventor
Dirk Langkafel
Elmar Thurner
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Publication of EP1461697A2 publication Critical patent/EP1461697A2/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications

Definitions

  • the invention relates to a system for communication between software applications, in particular MES applications, with at least one means of communication, with at least one computer unit for storing the software applications and with at least one framework program coupling the software applications.
  • the invention relates to a related method, a computer program, a computer program product and a data processing device.
  • Manufacturing Execution Systems are systems that, for example, provide information for optimizing production processes.
  • the manufacturing execution systems have to supplement the rough planning data of the ERP systems with plant-specific and current detailed planning data and pass them on to the subordinate automation level.
  • they have the task of taking over production-relevant information from the automation level, preparing it and using it to report the company management level.
  • MES systems thus perform the task of vertical integration between the company management level and the automation level.
  • Typical individual tasks of MES systems are enterprise asset management, maintenance management, information management, scheduling ling, dispatching and trace & track. These tasks are carried out by MES components or MES applications.
  • US Pat. No. 5,557,798 describes a communication interface between software applications, via which the applications can communicate with high performance. The aim is to be able to develop the applications independently and in a modular manner.
  • No. 6,115,646 describes a process automation system based on a heterogeneous, distributed software system and an ORB (Object Request Broker).
  • ORB Object Request Broker
  • CORBA Common Object Request Broker Architecture
  • the aim of this invention is to provide workflow management services.
  • the object of the present invention is to provide a system and a method for communicating software applications, in particular MES applications, which allows in particular heterogeneous applications to be easily integrated and enables efficient data exchange between them.
  • MES applications software applications
  • the above object is achieved for a system by the features of claim 1.
  • the inventors started from the knowledge that the use of a framework (framework program) using standardized interfaces such as OPC (OLE for Process Control), ActiveX, XML (eXtensible Markup Language) or SOAP (Simple Object Access Protocol) made interoperability possible between heterogeneous software applications (e.g. MES applications).
  • OPC OPC
  • ActiveX ActiveX
  • XML eXtensible Markup Language
  • SOAP Simple Object Access Protocol
  • the principle "any data, any time, any where" is implemented for a user in an MES project (project for solving a task, eg order processing within an MES system).
  • MES project project for solving a task, eg order processing within an MES system.
  • a user has access to all data at all times, regardless of where they are in the system.
  • all objects and data of the applications appear in the framework program in a homogeneous manner, since the objects or the data of the applications are mapped to the object model (thus corresponds to a uniform, homogeneous meta-object model) of the framework program. This makes it easier to establish and manage a communication relationship between the applications.
  • a user can configure a communication relationship between applications and does not have to program it extensively.
  • a user receives a homogeneous view of the overall system and does not have to have any special (internal) knowledge of the application programs.
  • a first advantageous embodiment of the present invention for a system is that the communication relationship is transparent to a user and / or other systems of the underlying communication means. Due to the independence and transparency of the underlying communication means, e.g. HTTP (Hyper Text Transfer Protocol, COM, (Component Object Model), DCOM (Distributed Component Object Model), MSMQ (Microsoft Message Queue), from the configured communication relationship, a user can Configure a communication relationship from these commu abstract nicants. A user therefore does not have to worry about implementation details of these means of communication when configuring. Even when integrating or "connecting" the software applications to the framework program (for example by wrapping or using an adapter), users can abstract from the underlying means of communication and need not know any implementation details of the means of communication.
  • HTTP Hyper Text Transfer Protocol
  • COM Component Object Model
  • DCOM Distributed Component Object Model
  • MSMQ Microsoft Message Queue
  • a wrapper maps the API (Application Programmable Interface) of a third-party component (e.g. a MES application from a third party) into the object model of the framework program.
  • a method of the API of the external component becomes a method of the framework program, or an integer data type of the API of the external component becomes an integer data type of the framework program, etc.
  • COM objects Component Object Model
  • the creation of a wrapper for an is to be integrated Component can be automated.
  • a wrapper corresponds to a bridge. Wrappers can be realized very quickly.
  • Adapters are one level higher than wrappers. They offer a unified view of connected applications. An adapter offers functionality to start, operate, etc. the component to be coupled. An adapter corresponds to a "facade" in the language of the design pattern.
  • Another advantageous embodiment of the present invention for a system is that the communication relationship is established with a display device with input aids and / or via an independently working program. This increases the flexibility for a user who increases.
  • a communication relationship can be set up dynamically, ie at runtime.
  • the independently working program can be defined as a batch and used several times.
  • a further advantageous embodiment of the present invention for a system is that the communication relationship between two or more objects is established by connecting the objects, which are shown in different screen areas of the display device, by dragging and dropping with the aid of the input aids.
  • a suitable user interface e.g. with graphic support, drag & drop mechanisms, mouse input, voice input, etc.
  • the above object for a method is achieved by the features of claim 6.
  • the principle "any data, any time, any where" is implemented for a user in an MES project (project to solve a task, e.g. order processing within an MES system). That A user has access to all data at all times, no matter where they are in the system.
  • all objects and data of the applications appear in the framework program in a homogeneous manner, since the objects or the data of the applications are mapped to the object model (thus corresponds to a uniform, homogeneous meta-object model) of the framework program. This makes it easier to establish and manage a communication relationship between the applications.
  • a user can configure a communication relationship between applications and does not have to program it extensively.
  • a user receives a homogeneous view of the overall system and does not have to have any special (internal) knowledge of the application programs.
  • a further advantageous embodiment of the present invention for a method is that the communication relationship is transparent to a user and / or other systems of the underlying communication means. Due to the independence and transparency of the underlying means of communication, eg HTTP (Hyper Text Transfer Protocol, COM, (Component Object Model), DCOM (Distributed Component Object Model), MSMQ (Microsoft Message Queue) from the configured communication relationship, a user can A user does not have to worry about implementation details of these means of communication when configuring a communication relationship.
  • HTTP Hyper Text Transfer Protocol
  • COM Component Object Model
  • DCOM Distributed Component Object Model
  • MSMQ Microsoft Message Queue
  • a wrapper maps the API (Application Programmable Interface) of a third-party component (e.g. an MES application from a third-party provider) into the object model of the framework program.
  • a method of the API of the external component becomes a method of the framework program or an integer data type of the API of the external component becomes an integer data type of the framework program, etc.
  • COM objects Component Object Model
  • the creation of a wrapper for a component to be integrated can be automated.
  • a wrapper corresponds to a bridge.
  • Adapters are one level higher than wrappers. They offer a unified view of connected applications. An adapter offers functionality to start, operate, etc. the component to be coupled. An adapter corresponds to a "facade" in the language of the design pattern.
  • Another advantageous embodiment of the present invention for a method is that the communication relationship is established with a display device with input aids and / or via an independently working program. This increases the flexibility for a user.
  • a batch e.g. dynamic, i.e. a communication relationship can be established at runtime.
  • the independently working program can be defined as a batch and used several times.
  • a further advantageous embodiment of the present invention for a method is that the communication relationship between two or more objects is established by connecting the objects that are displayed in different screen areas of the display device using drag and drop with the aid of the input aids.
  • a suitable user interface e.g. with graphic support, drag & drop mechanisms, mouse input, voice input, etc.
  • Another advantageous embodiment of the present invention is that the method according to the invention is implemented by a computer program. This means that any modifications or adjustments can be made easily.
  • Another advantageous embodiment of the present invention is that the computer program for the method according to the invention is stored on a data carrier or a computer program product (floppy disk, CD, etc.). There- This makes the process regarding logistics and distribution easy to handle.
  • Another advantageous embodiment of the present invention is that the computer program for the method according to the invention is installed on a data processing device. This increases performance.
  • WinCC on a component as a meta object model of the framework program
  • FIG. 6 shows a further example for the mapping of an application (SAP) onto a component as a meta object model of the framework program
  • 7 shows a communication relationship between MES applications
  • FIG 10 screen areas for the configuration of a connection.
  • the illustration according to FIG. 1 shows an overview of the three control levels, as can usually be found in a manufacturing or manufacturing company.
  • the pyramid shape expresses that the information is compressed at the top.
  • the top level is the ERP level (Enterprise Resource Planning).
  • ERP level Enterprise Resource Planning
  • the business and sales tasks are usually carried out in a company (e.g. finance, sales, human resources, reporting), but also cross-production logistics tasks (e.g. order and material management) are carried out at this level.
  • the SAP R / 3 system is an ERP system that is used very frequently at the management level.
  • the lowest level of the pyramid is the automation level (controls).
  • controls programmable logic controllers
  • PLC programmable logic controllers
  • PLS visualization and process control systems
  • the drives, actuators and sensors of the production and / or manufacturing facilities are directly connected to the systems on this level.
  • the link between the ERP level and the automation level is formed by the MES level.
  • the applications at the MES level thus ensure vertical integration between the ERP level and the automation level.
  • the MES applications must supplement the rough planning of the ERP systems with production plant-specific detailed planning and forward them to the systems at the automation level; Management level).
  • Typical MES applications include Quality Management (QM), Maintenance Management (MM), Performance Analysis (PA), Process Management, Labor Management, Asset Management.
  • QM Quality Management
  • MM Maintenance Management
  • PA Performance Analysis
  • Process Management Labor Management
  • Asset Management Asset Management
  • MES systems or ERP systems usually contain a so-called runtime system for the temporal sequence control of the components involved (subcomponents, modules, tasks, processes of the operating system, etc.), as well as a so-called engineering system for creating and editing programs that are used for Execution in the runtime system are provided.
  • the illustration according to FIG. 2 shows an exemplary overview image with software and hardware units for MES solutions.
  • the individual MES applications AI to A3 are connected to a framework program (framework) IF via adapters AD1 to AD3.
  • a user workstation PIW1 is coupled to the framework program IF via a bidirectional information path II and can thus manage and monitor the MES applications which are attached or integrated thereon.
  • the user workstation PIW1 usually consists of a display device (monitor, display, etc.), a data processing system (for example a PC) with a processor and memory devices and input units (keyboard, mouse, etc.).
  • the MES applications AI to A3 and the framework program IF can run on their own data processing units or processors, however, it is also possible that they run on the data processing unit of the PIW1.
  • the respective MES applications AI to A3 are connected to the framework program IF via adapters AD1 to AD3.
  • the adapters are thus the coupling modules between the framework program IF and the applications. Applications that are heterogeneous per se can thus be connected to one another via the adapters, and integration with the framework program IF makes it possible to communicate between the applications and to exchange data.
  • the adapters are software modules that create connections to various applications. In typical integration scenarios, these are integrations to systems from the MES, ERP, SCADA or Controls world.
  • An adapter offers functionality to start and operate a component to be coupled, etc.
  • An adapter allows access to data and functions of the components to be coupled Application or application, provides certain runtime data and allows engineering information to be loaded from the application or application to be connected.
  • Adapters can differ in terms of their structure and scope. For example, adapters can be permanently programmed or they can be configured or modeled. They can also differ with regard to the possibilities of access to the application to be coupled, for example adapters can only allow data access, but it is also possible for adapters to allow access to higher-value business processes.
  • the adapters When starting up, the adapters are loaded with the stored models and status information. At runtime, it is then checked whether and how the different integrated applications or applications fit together. Using a visualization or monitoring component, it is possible to query the status of an adapter and to display it at the user workstation PIWl (also graphically). The system and the user receive a standardized and standardized adapter Before looking at applications (depending on which level of abstraction is available for the adapters).
  • a wrapper maps the API (Application Programmable Interface) of a third-party component (e.g. an MES application) into the object model of the framework program. For example, a method of the API of the external component becomes a method of the framework program or an integer data type of the API of the external component becomes an integer data type of the framework program.
  • API Application Programmable Interface
  • MES Application Programmable Interface
  • MES applications In addition to MES applications, applications from the corporate management level (Enterprise Resource Planning level) and / from the automation level (Controls level) can be integrated via the framework program IF and monitored or monitored via the workstation PIW1 (the acronym PIW stands for Personalized Industrial Workplace) . to get managed.
  • the framework program IF thus forms an integration platform for the entire industrial sector. Different applications from the management level, the MES level and the automation level can be easily and economically integrated with the framework program IF using adapters and / or wrappers.
  • the framework program IF can therefore be seen as a middleware platform and as a manufacturing application integration tool.
  • a user e.g. the plant operator
  • a user can see the respective states of the applications to be monitored via the workstation PIW1, and can also access data and methods of the applications, and can also use this access to connect applications with one another.
  • the framework program IF thus enables, on the one hand, vertical integration of applications from different company levels and, on the other hand, the framework program IF enables horizontal integration of applications at the MES level.
  • the PIWI workstation represents a "one window to the world" for a user on the front end of MES applications or other company applications. This means that the workstation enables integrative access to different, even heterogeneous, interfaces via a common, uniform interface Applications in the company.
  • the user of the workstation PIW1 can thus monitor and manage all integrated MES or other applications from this one workstation.
  • This workplace can be connected to the applications via the Internet, the intranet, LAN (Local Area Network) or other conceivable connections. It is also possible to design this workstation as a mobile station, for example as a mobile device (PDA, cell phone). This mobility would bring even more benefits to a user.
  • PDA Mobile Device
  • FIG. 3 shows the central position of the framework program coupling the software applications.
  • the framework program (IF; FIG 2) can be implemented on a single server or on any number of servers that can be distributed in an IT landscape.
  • FIG. 3 shows that the framework program (IF; FIG 2) is located on a server IFS (Industrial Framework Server).
  • the clients are connected to this central server IFS by the bidirectional information paths 12-18.
  • the clients include the applications from the ERP, MES and automation levels. These applications are shown at the bottom of the figure in FIG. These applications are connected to the framework program (IF; FIG 2) and thus to the server IFS via the adapters AD4-AD6.
  • the adapters AD4 - AD6 are connected to the applications via API interfaces API1 - API3 (API stands for Application Programmable Interface).
  • API Application Programmable Interface
  • An application programmable interface is an interface with a lot of commands.
  • APIs are also used for the implementation of pa Parameter lists from one format to another and when interpreting the arguments in one or both directions. The APIs are, so to speak, the glue between the applications and the adapters.
  • the connection between the adapters AD4 - AD6 with the framework program (IF; FIG 2) (shown in FIG. 3 by the bidirectional information paths 13 - 15) takes place via suitable data formats (eg XML), suitable protocols (XOP, OPC, etc. ) and suitable transport mechanisms (e.g. DCOM or MSMQ).
  • HTTP Hyper Text Transfer Protocol
  • SOAP Simple Object Access Protocol
  • XML eXtensible Markup Language XML eXtensible Markup Language
  • Clients or applications that support ActiveX documents or calls can be integrated particularly advantageously into the framework program (IF; FIG 2) or the server IFS.
  • the applications can also be connected to the framework program using wrappers or other integration mechanisms.
  • the repository IFR (Industrial Framework Repository) can be connected to the server IFS as a further client. 3 shows the connection through the bidirectional information path 12.
  • the IFR repository is used to keep data safe and persistent. This data can be accessed via method calls.
  • the repository includes Objects, methods and runtime data saved.
  • the Personalized Industrial Workplace PIW2 and any existing engineering environment EU are clients of the IFS server.
  • the Personalized Industrial Workplace PIW2 is connected by the bidirectional information path 16 to the framework program (IF; FIG 2) or to the server, the engineering environment EU accordingly by the bidirectional information path 17.
  • the three points show that other clients on the server IFS can hang.
  • FIG. 3 indicates that a further client C, connected by the information path 18, also hangs on the server IFS.
  • the clients IFR, PIW2, EU, C are connected accordingly via APIs or common data formats (e.g. XML), common protocols (XOP, OPC, etc.) and common transport mechanisms (e.g. DCOM, HTTP or MSMQ).
  • common data formats e.g. XML
  • common protocols XOP, OPC, etc.
  • common transport mechanisms e.g. DCOM, HTTP or MSMQ.
  • the adapters AD4 - AD6 used allow access to data and also to methods of the individual applications, which they connect to the framework program (IF; FIG 2). These adapters are very flexible and are not restricted to individual special protocols or special transport mechanisms. If the adapters are used in a runtime environment, they are configured to ensure that certain required data from an application is available in the server environment at the right time. As already mentioned, this can be done using different protocols and transport mechanisms. In a runtime environment there can be several adapters, which can also have small server properties (such as the execution of workflows, the provision of various communication options, ). These adapters can run on the respective application computer. Not only do they have to run on one machine, they can also be distributed.
  • MES applications Manufacturing Execution Systems
  • the system or method according to the invention makes it possible to integrate such heterogeneous applications with the aid of a framework program.
  • the communication between these applications takes place on the basis of communication means such as HTTP, DCOM, MSMQ, etc.
  • the communication, ie the data exchange between the applications is independent of these communication methods. teln, ie the applications can abstract from the application means.
  • the representation according to FIG. 4 shows the object structure of a "component” as a meta-object model of the framework program (IF; FIG. 2) in UML (Unified Modeling Language).
  • the software applications to be integrated and the underlying communication means e.g. HTTP, MSMQ, etc.
  • an object model of the framework program IF; FIG 2.
  • heterogeneous applications have a common object model.
  • This object model is very generic and represents a meta-object model.
  • the core of this object model consists of an object type called "Component".
  • a component can in turn aggregate other components and / or contain special types of components, so-called variables, to which certain values are assigned during operation. Components and variables can also have additional attributes.
  • This object model forms the basis for the adaptation of MES applications or other applications.
  • All applications to be integrated are represented within the framework program (IF, FIG 2) in the representation of this object model.
  • the underlying means of communication are also mapped to this generic object model.
  • In the framework program (IF; FIG 2) all applications and all underlying communication means are now represented in a uniform and homogeneous object model. This makes it very easy and easy to set up communication relationships between the applications. 4, the generic component "Component”, which represents the core of the object model, is shown in UML notation.
  • the rectangular boxes represent parts of the object model.
  • An aggregation is represented by a diamond relationship
  • inheritance is represented by a triangular relationship.
  • FIG. 4 thus shows that a component can consist of several components, furthermore a component can be part of another component.
  • a diamond is connected to a component with attributes and variables. This means that a component can contain attributes and variables. Attributes are descriptive data. All objects in a class have the same attributes, but generally different attribute values. An attribute value is a value assigned to an attribute from its value range.
  • a variable can take values of certain data types (e.g. integer, real etc.).
  • a component can contain several variables. However, a component can also be a superclass of a variable, as represented by the triangular relationship. That is, a variable can be a derived component.
  • the diamond and triangular relationships can also contain cardinalities.
  • mapping mechanisms such as The software applications to be integrated and the underlying means of communication to this generic object structure, i.e. "Component” structure, the framework program (IF; FIG 2) mapped.
  • WinCC is the name for a process monitoring system from Siemens
  • IF underlying framework program
  • the WinCC object model consists of namespaces (NS stands for Name Space) with so-called "tags".
  • Tags are simple data objects, the properties of which can be exchanged between servers and clients. Their properties can be dynamic, but also static.
  • tags can exist in a flat or a hierarchical namespace. Tags can also be assigned access rights (readable, writable, readable / writable).
  • a tag is a placeholder (proxy) for an object of an external application to be integrated.
  • tag is used in languages such as HTML or XML for markings.
  • the left-hand edge of FIG. 5 shows that the WinCC namespace (NS) contains tags 1 and tags 2. Three dots indicate that it can also contain other tags. This structure is mapped to the "component" structure of the meta-object model, as shown on the right-hand edge of FIG. 5, by means of adapters, wrappers or other mechanisms.
  • the namespace NS becomes the component NS, which contains tags 1 and tags 2 as variables. Three dots indicate that component NS can contain further elements. The chosen notation is based on the collaboration diagrams as they are known in UML.
  • FIG. 6 shows how a SAP application is mapped onto the "component" structure (meta-object model of the framework program). 6 is also shown by the centrally mounted arrow that a Abbil ⁇ dung or transformation is shown.
  • the table-like IDOC structure of SAP applications is shown on the left side of FIG. 6 shows the two entries S1 and S2 in the table. Furthermore, an arrow from S1 to S2 shows that there is a reference from the entry S1 to the entry S2.
  • the three dots indicate that an IDOC table can contain other elements.
  • An IDOC table is mapped to a component IDOC of the object model of the framework program (IF; FIG 2).
  • the entries in the table (S1, S2) are each mapped to variables of the component IDOC. The chosen notation is based on the collaboration diagrams as they are known in UML.
  • FIG. 7 shows how a communication relationship between the MES application is set up.
  • the applications and the underlying communication mechanisms are mapped to a uniform "component" structure (meta object model of the framework program).
  • FIG. 7 shows how a communication link between the MES applications MES ⁇ and MES ' ⁇ is set up.
  • the underlying means of communication (HTTP, MSMQ, DCOM, etc.) are also shown mapped to the generic object model of a "Componenf" structure using adapters or wrappers.
  • TS component transport system
  • This component Transport system (TS) abstracts from the underlying means of communication.
  • connection connects any two objects of the object model. Since the connection refers to objects of the generic object model, it knows their semantics and knows which special features are to be created when connecting, ie method objects are handled differently than, for example, pure data objects.
  • the connection is also based on a transport system. The transport system is also part of the generic object model of the framework program (IF; FIG 2).
  • a connection can be unidirectional or bidirectional.
  • Data flow diagrams can be used to configure the communication relationship between applications by connecting the nodes with corresponding data flows.
  • a connection is a generic object that essentially consists of two parts. On the one hand from the wrappers of the specific means of communication and on the other hand from a collection of properties, ie properties that can be set via this means of communication. These properties and the connection itself are in turn “components" of the object model, whereby the properties are simply given by a list of variables.
  • a transport wrapper also contains properties. If MSMQ is used as a means of communication, the name of the message queue used is one such property. The cardinality (1: 2) indicates that the connection from FIG. NEN, but contains at most two transport wrappers. The other aggregation relationships (diamond symbol), as shown in FIG. 8, can also contain cardinalities.
  • a transport wrapper can also include methods. For example, a method of opening a specific transport channel, a method of closing a specific transport channel, a method of sending a string, a method of receiving a string, etc.
  • Communication means are usually mapped to the object model of the framework program by wrappers, but in principle it is also possible to integrate communication means in the framework program by means of adapters.
  • FIG. 9 shows the basic structure of an adapter.
  • Each adapter is a special component with the special property that the component of an adapter runs in its own process.
  • Each adapter comes with a certain default structure, which is again represented as a tree structure of objects in the framework program, ie components and variables, and which provides certain places where the adapter can place certain information externally. Examples of this are status information about the status of the adapter (if the adapter is connected to its application, the application is running, version information, etc.).
  • an adapter can provide information about the external system, ie the external application.
  • the "Object Space" allows an adapter to lay out structures that other adapters or other applications can access.
  • An adapter can also provide information regarding a communication infrastructure to the outside.
  • Communication infrastructure is understood to mean objects to send, receive and transform messages. But also mechanisms for routing and mechanisms for logging the data exchange of the adapter.
  • the communication infrastructure of an adapter also includes so-called in- ports and outports that physically receive or send the messages.
  • An adapter is available as a separate process of the operating system, ie if an adapter crashes, it has no effect on other adapters. An adapter is therefore a separate, closed application that can be executed on its own
  • Adapters and wrappers are mechanisms for integrating software components into a software system.
  • a wrapper forms the API (Application Programmable Interface) of a third-party component or an application to be integrated into the object model of the software system, here the framework program (IF; FIG 2).
  • the framework program IF; FIG 2.
  • a method of the API of the application to be integrated becomes a method of the framework program or an integer data type of the API of the application to be integrated becomes an integer data type of the framework program, etc.
  • a wrapper thus brings the API of the application to be integrated into the language, into the nomenclature and the object world of the framework program.
  • An adapter is one level higher than a wrapper.
  • Adapters represent a standardized view of applications to be integrated, and the framework program in which the application to be integrated is hooked in can abstract from this application.
  • An adapter provides functionality to the system to be integrated, i.e. the application to be integrated, to start, to operate and to act. With the help of the adapter e.g. a user is using a SAP application without being a SAP expert.
  • SAP applications are mapped into the object model of the framework program and are then used as objects of the framework program (component IDOC).
  • two applications can be brought together peer-to-peer without such a connection being necessary. because it has to be programmed peer-to-peer.
  • These connections are configured according to the invention by establishing a connection (see FIG. 7).
  • the illustration according to FIG. 10 shows a configuration interface for setting up a communication link between applications.
  • the display device AZ e.g. a monitor or a display
  • the ML menu bars contain function buttons that the user e.g. can be activated with a click of the mouse. User-defined function buttons can also be stored in the ML menu bars.
  • the configuration interface can also be operated or activated using other input aids (e.g. keyboard, light pen or similar).
  • the configuration surface is divided into the screen areas BB1 - BB3. However, it is also conceivable that there are further or only one or two screen areas.
  • the object structures OB1, OB2 of the applications between which a communication relationship is to be set up are shown in the screen areas BB1 and BB2. However, it is also conceivable that only the structure of the respective adapter is shown in the screen areas BB1 and / or BB2. A user can now connect elements of the two object structures OB1, 0B2 to one another using drag & drop mechanisms. When a user establishes such a communication relationship, information relating to this connection or to the connections is displayed in a screen area BB3. Such information may refer to the name, value, or type of connection set up. It is also conceivable that further information relating to a connection is displayed.
  • the mechanism described in FIG. 10 makes it possible for a user to configure communication relationships between two applications. Communication relationships between two applications are therefore no longer necessary can be programmed individually. This increases the efficiency in the creation of software solutions for MES systems enormously, and system integrators and system developers in particular can increase their efficiency.
  • the system or method according to the invention described above can be implemented as a computer program in languages known therefor.
  • a computer program implemented in this way can also be stored and transported in a known manner via electronic data paths, but also on data carriers.

Abstract

Zu verbindende Anwendungen (A1 - A3, MES', MES''), insbesondere MES-Applikationen , aber auch die Kommunikationsmechanismen, werden mittels Wrapper und/oder Adapter in das Ob-jektmodell 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 Appli-kationen 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 so genannten Connection projektierbar.

Description

Beschreibung
System und Verfahren zur Kommunikation zwischen Softwareapplikationen, insbesondere MES-Applikationen
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 Feinplanungs- daten 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, Schedu- ling, 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 Com- ponent Object Model) , MSMQ (Microsoft Message Queue) von der projektierten Kommunikationsbeziehung, kann ein Anwender beim Projektieren einer Kommunikationsbeziehung von diesen Kommu- nikationsmitteln 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 Kommunikations- beziehung mit einer Anzeigevorrichtung mit Eingabehilfsmitteln und/oder über ein selbständig arbeitendes Programm eingerichtet ist. Dadurch wird die Flexibilität für einen Anwen- der 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 (Distribu- ted 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 erfingungsgemäß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. Da- durch 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 Metaobjekt- modell 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 Pla- ning. Auf dieser Unternehmensleitebene werden üblicherweise die betriebswirtschaftlichen und vertrieblichen Aufgaben in einem Unternehmen durchgeführt (z.B. Finanzwesen, Vertriebswesen, Personalwesen, Berichterstattung) . Aber auch produkti- onsanlagenü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 Visu- alisierungs- 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), Pro- cess 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 AI bis A3 sind über Adapter AD1 bis AD3 mit einem Rahmenprogramm (Framework) IF verbunden. Über einen bidirektionalen Informationspfad II 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 AI 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 AI 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 Applika- tonen bzw. Anwendungen zusammenpassen. Über eine Visualisie- rungs- bzw. Monitoringkomponente ist es möglich, den Status eines Adapters abzufragen und am Benutzerarbeitsplatz PIWl darzustellen (auch graphisch) . Durch Adapter erhält das System und auch der Anwender eine standardisierte und einheitli- ehe 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-Applikation) in das Objektmodell des Rahmenprogram- mes 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 Wrap- pern integrieren. Das Rahmenprogramm IF ist somit als Middle- ware-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 PIWl 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 PIWl 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; FIG 2) auf einem Server IFS (Industrial Framework Server) befindet. An diesem zentralen Server IFS hängen durch die bidirektionalen Informationspfade 12 - 18 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 Pa- rameterlisten 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 A- daptern AD4 - AD6 mit dem Rahmenprogramm (IF; FIG 2) (in FIG 3 dargestellt durch die bidirektionalen Informationspfade 13 - 15) 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 Kommunikationsmit- teln, 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 gene- risch 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 Prozessbeobach- tungssystem der Firma Siemens) auf die "Componenf-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 Metaobjektmo- dells, 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 Collaborati- on-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 Abbil¬ dung 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 Sl und S2 dargestellt, weiterhin ist durch einen Pfeil von Sl zu S2 dargestellt, dass ein Verweis vom Eintrag Sl 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 (Sl, 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 "Componenf'-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 "Componenf'-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 ge- nerischen 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 generi- sches 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 ei- nen, 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 In- ports 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 je- weils 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 AZ (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 OBl, 0B2 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. Kommunikationsbe- ziehungen 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

Patentansprüche
1. System zur Kommunikation zwischen Softwareapplikationen (AI - A3, MESΛ, MES,λ), insbesondere MES-Applikationen,
- mit mindestens einem Kommunikationsmittel,
- mit mindestens einer Rechnereinheit zum Speichern der Softwareapplikationen (AI - A3, MES \ MES Λ ) ,
- mit mindestens einem die Softwareapplikationen (AI - A3, MES , MES,λ) koppelnden Rahmenprogramm (IF) , d a d u r c h g e k e n n z e i c h n e t, dass
- die Softwareapplikationen (AI - 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 In- formations- und/oder Ereignissaustausch stattfindet, wobei über die Kommunikationsbeziehung beliebige Daten und/oder Informationen und/oder Ereignisse der Softwareapplikationen (AI - A3, MES MES Λ ) unabhängig vom internen Format der jeweiligen Softwareapplikationen (AI - A3, MESΛ,
MES Λ ) und/oder unabhängig vom zugrunde liegenden Format der Kommunikationsmittel ausgetauscht werden.
2. System nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t, 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, d a d u r c h g e k e n n z e i c h n e t, dass die Abbildung auf das Objektmodell durch Adapter (AD1 - AD6) und/oder Wrapping erfolgt.
4. System nach einem der Ansprüche 1 bis 3, d a d u r c h g e k e n n z e i c h n e t, 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, d a d u r c h g e k e n n z e i c h n e t, 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 (AI
- A3, MES MES,Λ), insbesondere MES-Applikationen, basierend auf mindestens einem Kommunikationsmittel und mindestens einem die Softwareapplikationen (AI - A3, MES MES λ λ ) koppelnden Rahmenprogramm (IF), wobei die Softwareapplikationen (AI
- A3, MES , MES Λ Λ ) auf mindestens einer Rechnereinheit gespeichert werden, d a d u r c h g e k e n n z e i c h n e t, dass a) die Softwareapplikationen (AI - A3, MES MES Λ Λ ) auf ein Objektmodell des Rahmenprogrammes (IF) abgebildet werden, b) die Kommunikationsmitteln auf das Objektmodell des Rah- menprogrammes (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 In- formations- 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, d a d u r c h g e k e n n z e i c h n e t, 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, d a d u r c h g e k e n n z e i c h n e t, dass die Abbildung auf das Objektmodell durch Adapter (AD1 - AD6) und/oder Wrapping erfolgt.
9. Verfahren nach einem der Ansprüche 6 bis 8, d a d u r c h g e k e n n z e i c h n e t, 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, d a d u r c h g e k e n n z e i c h n e t, 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 (PIWl, PIW2, IFS) auf der ein Computerprogramm nach Anspruch 11 installiert ist.
EP02804564A 2001-12-12 2002-11-28 SYSTEM UND VERFAHREN ZUR KOMMUNIKATION ZWISCHEN SOFTWAREAPPLIKATIONEN, INSBESONDERE MES−APPLIKATIONEN Ceased EP1461697A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10161064 2001-12-12
DE10161064A DE10161064A1 (de) 2001-12-12 2001-12-12 System und Verfahren zur Kommunikation zwischen Softwareapplikationen, insbesondere MES-Applikationen
PCT/DE2002/004376 WO2003050680A2 (de) 2001-12-12 2002-11-28 System und verfahren zur kommunikation zwischen softwareapplikationen, insbesondere mes-applikationen

Publications (1)

Publication Number Publication Date
EP1461697A2 true EP1461697A2 (de) 2004-09-29

Family

ID=7708952

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02804564A Ceased EP1461697A2 (de) 2001-12-12 2002-11-28 SYSTEM UND VERFAHREN ZUR KOMMUNIKATION ZWISCHEN SOFTWAREAPPLIKATIONEN, INSBESONDERE MES−APPLIKATIONEN

Country Status (4)

Country Link
US (1) US7343605B2 (de)
EP (1) EP1461697A2 (de)
DE (1) DE10161064A1 (de)
WO (1) WO2003050680A2 (de)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9785140B2 (en) * 2000-02-01 2017-10-10 Peer Intellectual Property Inc. Multi-protocol multi-client equipment server
US8639542B2 (en) * 2002-06-27 2014-01-28 Siebel Systems, Inc. Method and apparatus to facilitate development of a customer-specific business process model
US8862570B1 (en) 2004-03-02 2014-10-14 Rockstar Consortium Us Lp Method and apparatus for open management of multi-media services
US7646725B1 (en) * 2004-03-02 2010-01-12 Nortel Networks Limited Self-healing containers
US7444197B2 (en) 2004-05-06 2008-10-28 Smp Logic Systems Llc Methods, systems, and software program for validation and monitoring of pharmaceutical manufacturing processes
US7799273B2 (en) 2004-05-06 2010-09-21 Smp Logic Systems Llc Manufacturing execution system for validation, quality and risk assessment and monitoring of pharmaceutical manufacturing processes
JP4410608B2 (ja) * 2004-06-04 2010-02-03 株式会社日立製作所 Ｗｅｂサービス提供方法
EP1699005A1 (de) 2005-03-01 2006-09-06 Siemens Aktiengesellschaft Integration von MES- und Controls-Engineering
CN100580623C (zh) * 2005-05-13 2010-01-13 Abb研究有限公司 在集成应用之间保持数据一致性的方法和装置
DE102006023105A1 (de) * 2006-05-16 2007-11-22 Bödger, Daniel Realisierungsnahe Simulation von Anlagen
US7822802B2 (en) 2006-09-29 2010-10-26 Fisher-Rosemount Systems, Inc. Apparatus and method for merging wireless data into an established process control system
US8380842B2 (en) 2007-04-26 2013-02-19 Mtelligence Corporation System and methods for the universal integration of plant floor assets and a computerized management system
US8036860B2 (en) * 2007-07-23 2011-10-11 International Business Machines Corporation Modeling homogeneous parallelism
EP2071580A1 (de) * 2007-12-13 2009-06-17 Siemens Aktiengesellschaft Steuerung der Schließung einer Werkanwendung
EP2073155A1 (de) * 2007-12-20 2009-06-24 Siemens Aktiengesellschaft Steuerung der erneuten Ausführung eines Regelzweigs
DE102008047238A1 (de) 2008-09-09 2010-04-15 Khs Ag Frameworkbasierte Steuerung für Automatisierungssysteme
EP2237197A1 (de) * 2009-03-31 2010-10-06 Siemens Aktiengesellschaft Verfahren zur Auswertung von Schlüsselindikatoren der Produktion bei einem Produktionsleitsystem (MES - Manufacturing Execution System)
US8863152B2 (en) * 2009-07-13 2014-10-14 Hewlett-Packard Development Company, L.P. Communication bridge
US8429671B2 (en) * 2009-10-21 2013-04-23 Exxonmobil Upstream Research Company Integrated workflow builder for disparate computer programs
US9665088B2 (en) 2014-01-31 2017-05-30 Fisher-Rosemount Systems, Inc. Managing big data in process control systems
US10649449B2 (en) 2013-03-04 2020-05-12 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics
US10223327B2 (en) 2013-03-14 2019-03-05 Fisher-Rosemount Systems, Inc. Collecting and delivering data to a big data machine in a process control system
US10909137B2 (en) 2014-10-06 2021-02-02 Fisher-Rosemount Systems, Inc. Streaming data for analytics in process control systems
US9558220B2 (en) 2013-03-04 2017-01-31 Fisher-Rosemount Systems, Inc. Big data in process control systems
US10866952B2 (en) 2013-03-04 2020-12-15 Fisher-Rosemount Systems, Inc. Source-independent queries in distributed industrial system
US10649424B2 (en) 2013-03-04 2020-05-12 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics
US10678225B2 (en) 2013-03-04 2020-06-09 Fisher-Rosemount Systems, Inc. Data analytic services for distributed industrial performance monitoring
US10386827B2 (en) 2013-03-04 2019-08-20 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics platform
US10282676B2 (en) 2014-10-06 2019-05-07 Fisher-Rosemount Systems, Inc. Automatic signal processing-based learning in a process plant
US10296668B2 (en) 2013-03-15 2019-05-21 Fisher-Rosemount Systems, Inc. Data modeling studio
US10691281B2 (en) * 2013-03-15 2020-06-23 Fisher-Rosemount Systems, Inc. Method and apparatus for controlling a process plant with location aware mobile control devices
WO2014145977A1 (en) 2013-03-15 2014-09-18 Bates Alexander B System and methods for automated plant asset failure detection
US9842302B2 (en) 2013-08-26 2017-12-12 Mtelligence Corporation Population-based learning with deep belief networks
US10168691B2 (en) 2014-10-06 2019-01-01 Fisher-Rosemount Systems, Inc. Data pipeline for process control system analytics
US10503483B2 (en) 2016-02-12 2019-12-10 Fisher-Rosemount Systems, Inc. Rule builder in a process control network
DE102017103017A1 (de) 2017-02-15 2018-08-16 Sig Technology Ag Verpackungsanlagendatenvermittlung sowie Verfahren zum Betreiben einer Verpackungsanlagendatenvermittlung
DE102017103018A1 (de) 2017-02-15 2018-08-16 Sig Technology Ag Verpackungsanlagendatenvermittlung sowie Verfahren zum Betreiben einer Verpackungsanlagendatenvermittlung
CN115997008A (zh) 2020-04-22 2023-04-21 艾欧凡斯生物治疗公司 协调用于患者特异性免疫疗法的细胞的制造的系统和方法
DE102022200246A1 (de) 2022-01-12 2023-07-13 Robert Bosch Gesellschaft mit beschränkter Haftung System zum Anbinden einer Maschine an eine Fertigungslinie

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5557798A (en) 1989-07-27 1996-09-17 Tibco, Inc. Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US5724532A (en) * 1994-10-27 1998-03-03 Bay Networks, Inc. Method and apparatus for exchanging information between application programs according to a drag and drop operation
JPH0981486A (ja) 1994-11-17 1997-03-28 Texas Instr Inc <Ti> ソフトウェア・アプリケーション・プログラム間の共通の通信インターフェースを与えるオブジェクト指向型方法及び装置
US5995916A (en) * 1996-04-12 1999-11-30 Fisher-Rosemount Systems, Inc. Process control system for monitoring and displaying diagnostic information of multiple distributed devices
US5909368A (en) * 1996-04-12 1999-06-01 Fisher-Rosemount Systems, Inc. Process control system using a process control strategy distributed among multiple control elements
US6032208A (en) * 1996-04-12 2000-02-29 Fisher-Rosemount Systems, Inc. Process control system for versatile control of multiple process devices of various device types
US6098116A (en) * 1996-04-12 2000-08-01 Fisher-Rosemont Systems, Inc. Process control system including a method and apparatus for automatically sensing the connection of devices to a network
US6029181A (en) * 1996-09-26 2000-02-22 Honeywell, Inc. System and method for translating visual display object files from non-component object model (COM) objects to COM objects
US6687761B1 (en) * 1997-02-20 2004-02-03 Invensys Systems, Inc. Process control methods and apparatus with distributed object management
US6434435B1 (en) * 1997-02-21 2002-08-13 Baker Hughes Incorporated Application of adaptive object-oriented optimization software to an automatic optimization oilfield hydrocarbon production management system
US5890155A (en) * 1997-08-22 1999-03-30 Honeywell Inc. System and methods for providing encapsulated and performance-efficient data references in an object-oriented controller and distributed control system employing the same
US6621505B1 (en) * 1997-09-30 2003-09-16 Journee Software Corp. Dynamic process-based enterprise computing system and method
JP3162006B2 (ja) * 1997-11-10 2001-04-25 核燃料サイクル開発機構 抽出系のシミュレーション方法
US6115646A (en) 1997-12-18 2000-09-05 Nortel Networks Limited Dynamic and generic process automation system
US6119125A (en) * 1998-04-03 2000-09-12 Johnson Controls Technology Company Software components for a building automation system based on a standard object superclass
US6240326B1 (en) * 1998-04-03 2001-05-29 Johnson Controls Technology Co. Language independent building automation architecture for worldwide system deployment
US6104963A (en) * 1998-04-03 2000-08-15 Johnson Controls Technology Company Communication system for distributed-object building automation system
US6167316A (en) * 1998-04-03 2000-12-26 Johnson Controls Technology Co. Distributed object-oriented building automation system with reliable asynchronous communication
US6141595A (en) * 1998-04-03 2000-10-31 Johnson Controls Technology Company Common object architecture supporting application-centric building automation systems
US6208345B1 (en) * 1998-04-15 2001-03-27 Adc Telecommunications, Inc. Visual data integration system and method
US6138143A (en) * 1999-01-28 2000-10-24 Genrad, Inc. Method and apparatus for asynchronous transaction processing
US6789252B1 (en) * 1999-04-15 2004-09-07 Miles D. Burke Building business objects and business software applications using dynamic object definitions of ingrediential objects
WO2001002953A1 (en) * 1999-07-06 2001-01-11 Abb Ab Method of integrating an application in a computerized system
US7069101B1 (en) * 1999-07-29 2006-06-27 Applied Materials, Inc. Computer integrated manufacturing techniques
US6823495B1 (en) * 2000-09-14 2004-11-23 Microsoft Corporation Mapping tool graphical user interface
US7159185B1 (en) * 2000-09-14 2007-01-02 Microsoft Corporation Function objects
US7318015B2 (en) * 2001-06-13 2008-01-08 Verizon Business Global Llc Method, system and program product for generating scenarios utilizing graphical objects representing hierarchically arranged elements of a modeled environment
SG109956A1 (en) * 2001-06-19 2005-04-28 Eutech Cybernetics Pte Ltd Method and apparatus for automatically generating a scada system
US7146231B2 (en) * 2002-10-22 2006-12-05 Fisher-Rosemount Systems, Inc.. Smart process modules and objects in process plants

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO03050680A3 *

Also Published As

Publication number Publication date
DE10161064A1 (de) 2003-07-03
US20050010931A1 (en) 2005-01-13
US7343605B2 (en) 2008-03-11
WO2003050680A2 (de) 2003-06-19
WO2003050680A3 (de) 2004-07-22

Similar Documents

Publication Publication Date Title
EP1461697A2 (de) SYSTEM UND VERFAHREN ZUR KOMMUNIKATION ZWISCHEN SOFTWAREAPPLIKATIONEN&amp;comma; INSBESONDERE MES&amp;minus;APPLIKATIONEN
EP1456753B1 (de) System und verfahren zur modellierung und/oder realisierung von softwareanwendungen, insbesondere mes-anwendungen
DE69832354T2 (de) Netzwerkverwaltungsrahmenwerk
EP1061422B1 (de) Informationstechnisches System zur Definition, Optimierung und Steuerung von Prozessen
EP1454280B1 (de) System und verfahren zum testen und/oder debuggen von laufzeitsystemen zur lösung von mess-aufgaben
DE10206902A1 (de) Engineeringverfahren und Engineeringsystem für industrielle Automatisierungssysteme
EP1508093A2 (de) Transformation von objektbäumen, insbesondere in mes-systemen
EP2902857B1 (de) Verfahren zur Bereitstellung von Funktionen innerhalb eines industriellen Automatisierungssystems und industrielles Automatisierungsystem
EP1497714A2 (de) System und verfahren zur projektierung von transformationen von objektb umen
DE10206903A1 (de) Softwareapplikation, Softwarearchitektur und Verfahren zur Erstellung von Softwareapplikationen, insbesondere für MES-Systeme
WO2003050676A2 (de) System und verfahren zum verfolgen und/oder auswerten des informationsaustausches
EP3594810A1 (de) Computersystem-infrastruktur sowie verfahren zum hosten einer anwendungssoftware
EP2248012A1 (de) Verfahren und system zur einbindung von service-orientierten automatisierungskomponenten einer fertigungsstätte in eine flexible it-unternehmensarchitektur
EP2648094B1 (de) Verfahren und system zum erzeugen eines quellcodes für ein computerprogramm zur ausführung und simulation eines prozesses
CH701481B1 (de) Prozessmanagement.
EP1202167B1 (de) Verfahren zur modellbasierten objektorientierten Entwicklung von externen Schnittstellen für verteilte Softwaresysteme
EP2620868A1 (de) Arbeitsfluss-Management-System für Computernetze
DE10033812A1 (de) Verfahren zum Erzeugen von Informationsmodellen
DE10109876B4 (de) Verfahren und Einrichtung zum Datenmanagement
EP4332772A1 (de) Data distribution service-fähiger controller
DE202021106310U1 (de) Computerimplementiertes Prozessmodul
DE10138232A1 (de) System und Verfahren zum Verwalten von Softwareapplikationen, insbesondere MES-Applikationen
DE102008045272A1 (de) Vorrichtung und Verfahren zur Transformation eines Modells
Wood Objektorientierte Programmierung mit ABAP Objects
DE102015107150A1 (de) Vorrichtungen, Verfahren und Computerprogramme zum Erkennen koppelbarer Schnittstellen

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040521

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SK TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: THURNER, ELMAR

Inventor name: LANGKAFEL, DIRK

17Q First examination report despatched

Effective date: 20050216

17Q First examination report despatched

Effective date: 20050216

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20070323