Device and method for linking automation components

• US 20020194315A1
• Filed: 06/10/2002
• Published: 12/19/2002
• Est. Priority Date: 12/08/1999
• Status: Abandoned Application

• Current Assignee: Andreas Macher, Dieter Gollwitzer, Heinrich Kulzer, Josef Portner-Von-Der Marwitz, Stefan List
• Original Assignee: Andreas Macher, Dieter Gollwitzer, Heinrich Kulzer, Josef Portner-Von-Der Marwitz, Stefan List
• Inventors: Marwitz, Josef Portner-von-der, Gollwitzer, Dieter, List, Stefan, Macher, Andreas, Kulzer, Heinrich
• Application Number:
  US10/149,529
• Publication Number:
  US 20020194315A1
• Time in Patent Office: Days
• US Class Current: 709/220
• CPC Class Codes: G05B 19/0426 Programming the control sequence
• CPC Class Codes: G05B 23/0216 Human interface functionality, e.g. monitoring system providing help to the user in the selection of tests or in its configuration

Abstract

The invention relates to a device and method for configuring, projecting, documenting and/or diagnosing modules and/or automation components in an automation system or process control system. The aim of the invention is to link automation components into an engineering system of the automation system or process control system. To this end, a released interface which is, in particular, versioned is provided via which a software component of an automation component couples to the engineering system. The automation component is made known to the engineering system and offers its functionality thereto. The software component can likewise interrogate relevant information of the engineering system via corresponding interfaces.

Claims

1. A device for configuring, planning and designing, documenting and/or diagnosing modules and/or automation components in an automation system or process control system, having at least one public interface, which is in particular versioned via which a software component couples to an engineering system for the running time.

2. The device as claimed in claim 1, characterized in that the engineering system is informed of the component, and provided with its functionality, via the interface.

3. The device as claimed in claims 1 or 2, characterized in that the interface is provided for interrogating relevant information of the engineering system by means of the software component.

4. The device as claimed in one of claims 1 to 3, characterized in that the component accesses other components or information of the engineering system by means of defined interfaces.

5. The device as claimed in one of claims 1 to 4, characterized in that the individual objects which are generated by means of instantiation of the respective components are connected to one another via various relations.

6. The device as claimed in one of claims 1 to 5, characterized in that the relations and relationships are defined by means of an abstract object model.

7. The device as claimed in one of claims 1 to 6, characterized in that, by reference to the respective relation, the engineering system determines those objects which have the stated relation with the inquiring entity of the component.

8. The device as claimed in one of claims 1 to 7, characterized in that the components independently determine whether separate subcomponents are to be used for specific functions or corresponding subcomponents of the engineering system are to be used.

9. The device as claimed in one of claims 1 to 8, characterized in that the components are based on standard technologies, for example the COM/DCOM model of Microsoft or the CORBA model of the Object Management Group (OMG) which permit the components to be used both on the same computer as the engineering system and also distributed in a computer network.

10. The device as claimed in one of claims 1 to 9, characterized in that an instantiation model is provided.

11. The device as claimed in one of claims 1 to 10, characterized in that a context-related interpretation of the information by the respective component is provided in such a way that both use-specific behavior of module is controlled, in particular a central or decentralized use, and/or security-oriented aspects, in particular an access via authorization, are implemented uniformly.

12. The device as claimed in one of claims 1 to 11, characterized in that the integration of automation components into the engineering system takes place only via a corresponding interface specification which is implemented in particular on the basis of COM/DCOM or CORBA.

14. The method as claimed in claim 13, characterized in that the engineering system is informed of the component, and provided with its functionality, via the interface.

13. A method for configuring, planning and designing, documenting and/or diagnosing modules and/or automation components in an automation system or process control system, having at least one public interface, which is in particular versioned, via which a software component couples to an engineering system for the running time.

15. The method as claimed in one of claims 13 or 14, characterized in that the interface is provided for interrogating relevant information of the engineering system by means of the software component.

16. The method as claimed in one of claims 13 to 15, characterized in that the component accesses other components or information of the engineering system by means of defined interfaces.

17. The method as claimed in one of claims 13 to 16, characterized in that the individual objects which are generated by means of instantiation of the respective components are connected to one another by means of various relations.

18. The method as claimed in one of claims 13 to 17, characterized in that the relations and relationships are defined by means of an abstract object module.

19. The method as claimed in one of claims 13 to 18, characterized in that, by reference to the respective relation, the engineering system determines those objects which have the stated relation with the inquiring entity of the component.

20. The method as claimed in one of claims 13 to 19, characterized in that the components independently determine whether separate subcomponents are to be used for specific functions, or corresponding subcomponents of the engineering system are to be used.

21. The method as claimed in one of claims 13 to 20, characterized in that the components are based on standard technologies, for example the COM/DCOM model of Microsoft or the CORBA model of the Object Management Group (OMG) which permit the components to be used both on the same computer as the engineering system and also distributed in a computer network.

22. The method as claimed in one of claims 13 to 21, characterized in that an instantiation model is provided.

23. The device as claimed in one of claims 13 to 22, characterized in that a context-related interpretation of the information by the respective component is provided in such a way that both use-specific behavior of module is controlled, in particular a central or decentralized use, and/or security-oriented aspects, in particular an access via authorization, are implemented uniformly.

24. The device as claimed in one of claims 13 to 23, characterized in that the integration of automation components into the engineering system takes place only via a corresponding interface specification which is implemented in particular on the basis of COM/DCOM or CORBA.