Method and device for operating and controlling a machine installation by means of a graphical development interface and generation of a field bus configuration

Abstract

A method for operating and controlling a machine installation by means of a graphical development environment (1), with which a controller on the machine side having programmable hardware modules (13, 14) situated there is graphically displayed, and via user-side inputs a programming sequence (24) is created in the development environment (1) and is supplied to the hardware modules (13, 14). According to the invention, an embedded web server (2) and an embedded browser (4) that communicates with same are integrated into the development environment (1), and the programming sequence (24) created in the development environment (1) is supplied to a field bus master (8), which supplies the programming sequence (24) via a field bus (10) to the station head (12) of a hardware station (11) in which the hardware modules (13, 14) which are programmable with the programming sequence (24) are situated and communicate with the station head (12).

Claims

1. A method for operating and controlling a machine installation by means of a graphical development environment (1), with which a controller on the machine side having programmable hardware modules (13, 14) situated there is graphically displayed, and via user-side inputs a programming sequence (24) is created in the development environment (1) and is supplied to the hardware modules (13, 14), characterized in that an embedded web server (2) and an embedded browser (4) that communicates with same are integrated into the development environment (1), and the programming sequence (24) created in the development environment (1) is supplied to a field bus master (8), which supplies the programming sequence (24) via a field bus (10) to the station head (12) of a hardware station (11) in which the hardware modules (13, 14) which are programmable with the programming sequence (24) are situated and communicate with the station head (12).

2. The method according to claim 1, characterized in that the development environment (1) is made up of Eclipse configurator components into which the web server (2) and the browser (4) are integrated.

3. The method according to claim 1, characterized in that the development environment (1) is made up of native Eclipse components in the Java and XTend programming languages.

4. The method according to claim 1, characterized in that at least the following Eclipse functionalities are preferably, but not exclusively, present in the development environment (1): Change recognition (dirty state editor action): When changes are made in the configurator via the browser, the editor should report this as a flagged change. Undo/redo action: Changes made in the browser are restored or repeated via the Eclipse undo/redo stack. Drag&Drop support: The content of the configurator (2, 4) that is integrated into the development environment (1) is transferred to an interface architecture (20) by D&D. Life cycle of UI components: When a new module (13, 14) is created, the editor should be automatically opened, and the web application for the configuration should be started. Incorporation of native SC widgets into web configurators.

5. The method according to claim 4, characterized in that the interface architecture (20) is designed as a REST API.

6. The method according to claim 1, characterized in that the Eclipse SWT Browser widget is used as the embedded browser (4) and is integrated into an editor on the development environment side, and the data exchange between the browser and the web server takes place via JSON.

7. The method according to claim 1, characterized in that 1. the application of a new hardware module (13, 14) takes place in the development environment (1), 2. the hardware module (13, 14) from the development environment (1) is opened and the web server (2) is started, 3. the SWT Browser widget (embedded browser 4) is opened, and programs the configurator (6) via a module-specific URL, and 4. the configuration data are written into the configuration module (9) in the field bus master (8) as a hardware-side programming sequence by the web server (2).

8. A device for operating and controlling a machine installation by means of a graphical development environment (1), with which a controller on the machine side having programmable hardware modules (13, 14) situated there is graphically displayed, and via user-side inputs a programming sequence (24) is created in the development environment (1) and is suppliable to the hardware modules (13, 14), characterized in that an embedded web server (2) and an embedded browser (4) that communicates with same are integrated into the development environment (1), and the programming sequence (24) created in the development environment (1) is suppliable to a field bus master (8), which supplies the programming sequence (24) via a field bus (10) to the station head (12) of a hardware station (11) in which the hardware modules (13, 14) which are programmable with the programming sequence (24) are situated and communicate with the station head (12).

9. The device according to claim 8, characterized in that the interface (3) between the embedded web server (2) and the embedded browser (4) is designed as an HTTP interface.

10. The device according to claim 8, characterized in that in an alternative embodiment, the web server (2) is situated in the area of the customer-side hardware station (11).

Description

[0079] In the drawings:

[0080] FIG. 1: shows a simplified block diagram of a development environment (solution center)

[0081] FIG. 2: shows an illustration of the programming of hardware components with the aid of the development environment illustrated in FIG. 1

[0082] FIG. 3: shows a schematic illustration of a configurator that is integrated into the development environment

[0083] FIG. 4: shows an illustration that is modified from FIG. 3, with the connection to individual hardware modules of a station head of a controller

[0084] FIG. 1 shows in general a development environment 1 which is preferably programmed in Eclipse Java and which provides the user with a graphical display for compiling the user's configuration.

[0085] It is preferred that according to the invention an embedded web server 2 is implemented in this graphical development environment 1. The embedded web server provides an HTTP interface on a local port of the development environment 1. The embedded web server 2 preferably has no connection with external components, and instead runs as a local application which thus operates in a particularly operationally secure manner without disturbances.

[0086] The embedded web server 2 generates bidirectional data traffic between the embedded web server 2 and an embedded browser 4 connected thereto via a REST-based, HTTP-based interface 3, corresponding to the illustrated arrows 5.

[0087] The embedded browser 4 obtains from the embedded web server 2 the information concerning the respectively plugged-in hardware modules 13, 14 in the hardware station 11, and provides a graphical user interface to allow the option for programming and thus, generation or a change of a configuration of the hardware modules 13, 14.

[0088] The embedded browser checks in particular that only valid configurations are implemented.

[0089] The embedded web server 2 and the embedded browser 4 together thus form a configurator 6, which is integrated into the above-mentioned development environment 1.

[0090] Further particulars of the development interface together with code generation for a field bus 10 are apparent in FIG. 2.

[0091] The same development environment 1 is schematically illustrated in FIG. 2, which as a further feature, at the output of the development environment 1 has an Ethernet connection 7 that acts on a field bus master 8.

[0092] A configuration module 9 which according to the invention is programmable by the development environment 1, namely, the configurator 6, is present in the field bus master.

[0093] A common type of field bus 10, which may be designed, for example, as a can bus, an Ethercat bus, a Profinet bus, or as a similar field bus, is connected to the output of the field bus master 8.

[0094] It is important that various bus configurations are possible for the field bus 10, and that the development environment 1 together with the configurator 6 controls all known types of field buses.

[0095] The field bus 10 acts on a station head 12 on the hardware side in the hardware station 11, which forms the head for a series of hardware modules 13, 14 that are connected to one another via individual bus connections.

[0096] The entire hardware portion is referred to as a hardware station 11, and the individual hardware modules may be, for example, input and output modules that are situated on individual circuit boards and plugged in a control cabinet, and that are in each case individually programmable via the field bus 10 and the station head 12.

[0097] Instead of the input and output modules, other modules may be used, such as alarm modules, limit value modules, temperature and moisture modules, and the like.

[0098] It is important for the hardware station 11 to contain all hardware components for a facility, such as those necessary for wind turbine controllers or machine controllers, for example.

[0099] In particular, power plant controllers may also be designed in the sense of the hardware station 11 described above.

[0100] The invention thus results in the advantage that with a development environment 1 having a relatively simple design and a configurator 6, integrated therein, that is made up of modules, namely, an embedded web server 2 that operates only locally in the development environment 1 and an embedded browser 4 connected thereto via an interface, an easily operated development environment 1 is created that may be used for various applications.

[0101] It is preferred that the development environment 1 operates with Eclipse components, and a development environment 1 is thus specified which according to the technical teaching of the invention is now refined by a particular configurator 6.

[0102] FIG. 3 illustrates such a configurator 6 in a schematic layout in which it is apparent that the embedded browser 4 cooperates with the embedded web server 2 via the above-mentioned interface 3.

[0103] In the embedded browser, one particular development module is referred to as Module 1 with which certain values and certain input and output signals (Sig1) are associated.

[0104] The specified values are now input via the bidirectional interface 3 to the embedded web server 2, which thus renews its already stored values, and outputs a message when it determines that the values generated by the embedded browser 4 are new. A user interface 16 in which a graphical message 18 is generated is then addressed via the data path 21, so that the user, based on his/her user input 17, is able to recognize that he/has initiated a new configuration.

[0105] The programming of the bidirectional interface 3 is illustrated by the information arrow 19 by way of example, that shows which data traffic is taking place via the programmable interface 3.

[0106] Provided at the output of the interface 15, which is directly connected to the embedded web server 2 via the signal path 23, is an Ethernet connection 7 which according to FIG. 2 acts on the field bus master 8 and a configuration module 9 indicated at that location.

[0107] Further particulars of the connection of the development environment to the hardware components are apparent from FIG. 4.

[0108] In a further description of the function of the embedded browser 4, it is apparent from FIG. 4 that this browser has an editing function, a verification function (Validation), and a display function (Display) for the user for displaying the input values.

[0109] Reference numeral 24 denotes the [programming sequence] according to the REST API, which is integrated into the embedded web server 2 and which determines the renewal or change of input values and outputs a certain message via the path 21 when a change in the values is determined.

[0110] A graphical output on the user interface 16 also takes place via the data path 21.

[0111] It is preferred for a configuration module 9 in the field bus master 8 to now be addressed via the Ethernet connection 7, and the configuration module thus provides a control sequence that is used for programming the hardware components in the hardware station 11. This control information or programming information is supplied to the station head 12 of the hardware station 11, which uses this information to generate the corresponding configuration signals or programming signals on the internal bus 22, and thus directly programs the hardware modules 13, 14. Thus, EEPROM values are written on the hardware side which result in a functional change in the programmable hardware modules 13, 14. This results in a functional change in the hardware modules 13, 14.

[0112] Thus, for example the inputs and outputs, the threshold values, the signal values, or other parameters in the hardware modules 13, 14 may be changed, in particular corresponding to the input values in the development environment 1.

[0113] It is preferred for the interface architecture 20 of the embedded web server 2 according to FIG. 4 to be designed as a REST API, since this is a particularly simple and operationally secure data environment.

[0114] Consequently, the active element is always the embedded browser 4 into which the data are input via a user input 17, and which then, via the embedded web server 2, transforms the data corresponding to the required development environment 1, in order to thus control the Ethernet connection 7 to the field bus master 8 and the configuration module 9 situated at that location, via the controller interface 15.

[0115] Thus, this is a field bus-independent configuration of hardware modules that are suitable for controlling machines and facilities. Accordingly, the programming takes place via a standard web browser 4 that is integrated into the development environment 1.

[0116] It is preferred for the web browser 4 to be embedded in a Java environment, which ensures particularly simple operability.

[0117] In the final layout, a standard web browser 4 would then be present on a customer-side terminal (a tablet or mobile telephone, for example), which is easily configured using the provider-side development environment 1 according to the invention.

[0118] This results in a competitive advantage over known approaches, which do not use a standard browser on the customer-side terminals; instead, a complicated development environment must be provided for the customer side.

[0119] Reprogramming and changing the configuration of customer-side hardware modules is therefore particularly simple.

LIST OF REFERENCE NUMERALS

[0120] 1 development environment [0121] 2 embedded web server [0122] 3 interface [0123] 4 embedded browser [0124] 5 data traffic [0125] 6 configuration [0126] 7 Ethernet connection [0127] 8 field bus master [0128] 9 configuration module [0129] 10 field bus [0130] 11 hardware station [0131] 12 station head [0132] 13 hardware modules [0133] 14 hardware modules [0134] 15 interface [0135] 16 user interface [0136] 17 user input [0137] 18 graphical message [0138] 19 information arrow [0139] 20 interface architecture (REST) [0140] 21 data path [0141] 22 bus [0142] 23 signal path [0143] 24 programming sequence