WO2003038536A2

WO2003038536A2 - Method for transmitting raw data and field device

Info

Publication number: WO2003038536A2
Application number: PCT/DE2002/003712
Authority: WO
Inventors: Torsten Ackerschewski; Andreas Jurisch; Stefan Walz
Original assignee: Siemens Aktiengesellschaft
Priority date: 2001-10-15
Filing date: 2002-09-26
Publication date: 2003-05-08
Also published as: WO2003038536A3; DE10151118A1

Abstract

The invention relates to a method for transmitting raw data (36) between a field device (33) and a user device (30) for observation and/or operation of said field device (33), in addition to the embodiment of said field device (33). The raw data (36) is pre-held in the field device (33). A server device (34) is embodied in the field device (33). A browser device (31) is installed onto the user device (30) for data communication with the server device (34). The inventive method comprises the following steps: a communication link is set up in order to transmit electronic data between the field device (33) and the user device (30); an electronic description page (35) which can be graphically outputted on the user device (30) is transmitted with the aid of the browser device (31) from the server device (34) of the field device (33) to the user device (30) via said communication link whereby the electronic description page (35) consists of at least one electronic reference to the raw data (36) which is pre-held in the field device (33); the raw data (36) is transmitted from the field device (3 ) to the user device (33) and the raw data (36) is automatically processed (36) in the user device (30).

Description

Description •

Process for transferring raw data and field device

The invention is in the field of remote-controlled operation, in particular for observing and operating field devices.

Field devices are used in the automation of a wide variety of technical processes, for example to monitor a production or manufacturing process or a processing process. The field devices can be the production plants themselves or devices for monitoring, preferably for controlling and / or regulating, depending on the recorded field data, the technical production means or plants used.

During operation of the field devices, raw data is generated in the field devices, which can be processed further, for example for evaluating measurement processes or for error detection.

With the help of different technologies, the field devices in particular record measurement data that can be buffered and / or processed further. In addition, the raw data present in the field device can include information about device-specific parameters, such as predefined and / or changeable settings of the field device. This raw data can be, for example, measured values, event lists, diagnostic data, error messages or fault records in a binary format internal to the field device.

To evaluate the raw data by the operating personnel, a visualization / representation of the raw data is necessary. Basically, you can choose between processing the raw data a distinction is made in the field device itself and a transmission of the raw data to an observation and operating device which can be connected to the field device.

The transmission of the raw data to the observation and operating device has the advantage of greater ease of use, since this is generally very low on the field devices; only simple operations for evaluating / processing the raw data on the field device are possible. In addition, it is often not possible to graphically prepare the raw data on the field device. Complex operating programs for remote control of the field devices have therefore been proposed. However, using these programs involves a great deal of effort if standardized communication mechanisms are to be used. In general, the well-known operating technologies of telecontrol technology, for example the use of a WIN-CC operator station, for operating field devices require the technical special features of the individual field devices to be observed.

The object of the invention is to provide an improved possibility for transferring raw data from field devices, which is essentially independent of the specific field device design and thereby ensures a high degree of compatibility.

The object is achieved by the method according to claim 1 and the device according to claim 11.

An essential advantage which the invention achieves over the prior art is that the raw data accumulating in the field device can be called up by using a browser which is based on standard Communication technologies based and therefore does not depend on the specific training of the field device. The proposed way of transferring the raw data basically allows the raw data to be called up with a standard browser on a standard personal computer in order to then process the raw data with application programs. Sufficient computing power is available for execution in the standard personal computer or the like used by the user, which is not available in the field device. This also applies to those required by the application program

Storage space that is usually also not available in the field device.

An expedient development of the invention provides that the electronic description page is automatically analyzed in the user device after transmission to the user device in order to record the reference to the raw data, and that the raw data is automatically collected by the user after the reference is recorded in the electronic description page Field device are transmitted to the user device. As a result, the raw data can be loaded from the field device onto the user device without the user having to intervene.

In order to enable the user of the user device to choose between different raw data sets in a simple manner, a preferred embodiment of the invention provides that a selection that can be assigned to the reference in the electronic description page by a user with the aid of a selection means that is electronically determined in the user device. and that the raw data is automatically transmitted from the field device to the user device after the selection of the user has been recorded. The described retrieval of the raw data can, on the one hand, be carried out with the aid of an extension module (“plug-in” module) for the browser device. This embodiment can expediently be used to retrieve static data that only change over longer periods or only sporadically The TCP protocol is advantageously used here, and execution with the help of an ActiveX component would also be possible. On the other hand, a client process can be used to call up dynamic data that is constantly changing, for example event lists and / or measured values Browser device can be used, in which an RPC protocol standard can then preferably be used.

The method can be used in conjunction with the widespread standard technology HTTP (HTTP - “Hypertext Transfer Protocol ^V ) if the electronic description page is expediently an HTML page.

A further development of the invention, which is preferred with regard to the optimized use of data connections, provides that the raw data are transmitted from the field device to the user device via the communication connection.

In order to improve the efficiency of the transmission of different data formats, an advantageous embodiment of the invention can provide that different protocols are used for the transmission of the electronic description page and for the transmission of the raw data. This makes it possible to choose a suitable transmission protocol.

A preferred development of the invention provides that the browser device transfers the data from the field device to the user device. raw data transmitted to the facility and that at

Processing the raw data in the user device, an application program is started automatically depending on the result of the analysis of the raw data. This ensures that the raw data are automatically processed with the application program provided for this purpose. When analyzing the raw data, for example, the file extension or its MIME type (MIME - "Multipurpose Internet Mail Extension") can be evaluated as a hint for the application program to be called.

According to a further aspect of the invention, a field device with a connection for a communication connection that can be addressed by a client device via an IP address is a server device for data communication with a browser device installed on the client device via the connection and a storage device with an electronic description page stored therein, the electronic description page comprising an electronic reference to raw data held in the field device and the electronic description page, including the raw data referenced by means of the electronic reference, about the server device and the Connection is electronically available. The raw data from the field device can be called up using a conventional browser. There is no need for an operating program that is specifically tailored to the field device, which is particularly advantageous if the operating system or operating programs based thereon have to be updated.

The devices according to the dependent device claims have the advantages listed in connection with the associated method claims. The method and / or the device can advantageously be used for monitoring energy technology systems.

The method and / or the device can advantageously be used for monitoring energy technology systems.

The invention is explained in more detail below on the basis of exemplary embodiments with reference to a drawing. Here show:

Figure 1 is a schematic representation with a device network and a company intranet, which are connected via a proxy server;

FIG. 2 shows a user interface design of a browser device with graphic representations for several field devices;

FIG. 3 shows another surface design of the browser device with a graphic representation of a front view of a field device;

Figure 4 is a schematic representation of a field device and a user personal computer;

FIG. 5 shows a flow chart for downloading HTML pages as part of an observation and operating system;

Figure 6 is a block diagram for explaining an RPC call; FIG. 7 shows the arrangement with the device network and the company intranet according to FIG. 1, individual elements of the proxy server being shown schematically;

Figure 8 is a schematic block diagram of the proxy server;

FIG. 9 shows a schematic illustration to explain a client / server interaction;

FIG. 10 shows a schematic illustration to explain device detection in a master / slave arrangement;

FIG. 11 shows a Nassi-Sneider diagram;

FIG. 12 shows a schematic tree representation of a method for device recognition;

FIG. 13 shows a schematic illustration of a master / slave arrangement to explain a configuration query;

FIG. 14 shows a schematic block diagram of a device management in the proxy server;

FIG. 15 shows a schematic block diagram to explain the functional integration of an XSL parser in the proxy server (XSL - “Extended Stylesheet Langage”); and Figure 16 is a schematic block diagram for explaining an XSLT processor (XSLT - "Extended Stylesheet Language Transformations").

A monitoring and operating system (BuB system) that can be used in conjunction with field devices is described below.

FIG. 1 shows a schematic architecture of two networks, a device network with several field devices FG1 ... FGN and a company intranet with several user devices N1 ... NN, preferably a personal computer (PC). The device network and the company intranet are connected via a proxy server 1. The proxy server 1 is part of the observation and operating system and serves as a gateway between the device network and the company intranet. With the help of the BuB system, on the one hand, information, for example measurement and / or status data, is captured by the field devices FG1 ... FGN and transmitted to the user devices N1 ... NN in order to inform a user of the user devices Nl ... NN about the

Inform the operating status of the field devices FG1 ... FGN. On the other hand, the BuB system is used to record operating or Control inputs of the user with the help of the user devices N1 ... NN and for converting the inputs of the user in the field devices FG1 ... FGN. With the field devices

FG1 ... FGN can be any device for observing, measuring, controlling and / or regulating a wide variety of physical quantities in different technical processes, for example for monitoring and / or controlling energy technology systems, for example a substation. The device network comprises individual PPP connections 2 (PPP -

"Point to Point Protocol"), which can be connected to the proxy server 1 via a star coupler 3, or a separate Ethernet segment. The proxy server 1 provides its own homepage in the form of HTML data (HTML - "HyperText Markup Language" ) is available, which shows an overview of the field devices FG1 ... FGN that can be reached in the device network (cf. FIG. 2); the homepage can be displayed in the user devices N1 ... NN using a standard browser.

According to FIG. 1, the field devices FG1 ... FGN are only equipped with the star coupler 3 and a modem 4 connected to it. In this case, the field devices FG1 ... FGN are connected to the modem 4 via an asynchronous serial interface directly via the star coupler 3. Different forms of coupling via active and passive star couplers are possible. An IP protocol (IP - "Internet Protocol") via a PPP link layer is used as the protocol for access to the field devices FG1 ... FGN.

If the field devices FG1 ... FGN are equipped with an Ethernet connection, the Ethernet connections are connected to a switch or a hub. If this switch or hub has a PPP port in addition to Ethernet ports, then this is called a router. This PPP port can then also be connected directly to the modem 4.

In the company intranet, the user devices N1... NN connected to the local network have access to a modem 5, which is connected to the modem 4 via a telecommunications network 6, for example a telephone network based on an ISDN or a mobile radio network Device network is connectable. If in the user facilities N1 ... NN a dial-up Established connection (remote data transmission), the user devices N1 ... NN can access the field devices FG1 ... FGN. If the proxy server 1 is now addressed by the user devices N1 ... NN, anyone connected to the company intranet can

User devices Nl ... NN can access the field devices FG1 ... FGN for observation and operation. The proxy server 1 "mirrors" all field devices FG1 ... FGN, ie information about the field devices FG1 ... FGN, into the company intranet. For this purpose, the following protocols are processed by proxy server 1: HTTP protocol (HTTP - "Hypertext Transfer Protocol "and RPC protocol (RPC -" Remote Procedure Call "). The HTTP protocol is used for the transmission of static data. This is data that is transmitted only once to the proxy server 1 and then there in a file memory for later calls The RPC protocol, which is also an IP-based protocol, is used to transmit dynamic data. The dynamic data is, in particular, in the field devices FG1 ... FGN recorded measured values and / or event lists, relating to information about events in the field devices FG1 ... FGN.

The HTTP protocol allows the user devices N1 ... NN to access the field devices FG1 ... FGN. When accessing the BuB system, HTML data is first transmitted from the field device to the user device used in this application by selecting the associated IP address of the field device to be operated / observed, the HTML data comprising data with the With the help of the browser device of the retrieving user device, a representation of the field device can be generated, as is shown by way of example in FIG. 3. The retrieval of the HTML Data for generating the representation according to FIG. 3 can be created with

A selection of one of the field devices shown in the overview in FIG. 2 can be triggered by the user, for example by actuating a mouse or a keyboard of the user device.

According to FIG. 3, the following information is shown on the surface 20 of the browser device (see left side in FIG. 3): field device family (e.g. SIPROTEC4), field device type and field device type 21, an operating tree 22, the

Version of the BuB-Tool 23 (version and date) and details of the connection 24 to the field device (MLFB - "machine-readable manufacturing designation", BF number, connection status and IP address). The link or branch in the HTML page 25 assigned to operating tree 22 is displayed, depending on the link selected in operating tree 22, the associated HTML page 25 is displayed on surface 20 of the browser device.

The HTML pages stored in the field devices FG1 ... FGN, i.e. The HTML page 25 used to generate the representation shown in FIG. 3 can also include Java code which causes the browser device of the respective user device N1 ... NN to display the information from the parallel to the existing HTTP connection Field devices FG1 ... FGN loaded HTML page to establish another connection with the field devices FG1 ... FGN. This second connection uses the RPC protocol to get dynamic data, such as event lists or measured values, from the field devices FG1 ... FGN particularly quickly and effectively for display in the user devices

N1 ... NN within a selected HTML page, for example the HTML page 25 shown in FIG. 3. Information retrieval from the field devices

FIG. 4 shows a schematic illustration for a more detailed explanation of the retrieval of the information in the context of the BuB system from the field devices FG1 ... FGN into the user devices N1 ... NN.

According to FIG. 4, a browser device 31 is installed on a user personal computer 30, which represents an exemplary embodiment of the user devices N1 ... NN. The user personal computer 30 is connected to a field device 33 via an IP network 32, which can include the proxy server 1, the star coupler 3, the modem 4, the modem 5 and the telecommunications network 6. The field device 33 has an HTTP server 34. HTML pages 35 are stored in the field device 33 and contain information specific to this field device 33. The HTML pages 35 contain, for example, an HTML representation of the front view of the field device 33. The HTML pages 35 are specially matched to the field device 33 and can be downloaded by the user personal computer 30 by means of an HTTP download from the HTTP server 34 of the field device 33 be retrieved. The request for the HTML pages 35 from the field device 33 can be made by entering a URL (URL - “Uniform Resource Locator”) in the browser device 31 or by means of the reference from another HTML page

In addition to the HTML pages 35, the field device 33 provides a series of raw data 36 (measured values, parameters, etc.) in the form of files. The HTML pages 35 contain references to those in the field device 33 available raw data 36. If the raw data 36 are to be evaluated or changed in some other way, a program is required which can generate high-quality data formats according to certain algorithms then from the program, for example, to on-screen display in

Connection with analysis options can be used. The computing power required for this is generally not available in the field device 33. With the help of the browser device 31, the user has the option of using the IP network 32 via communication links (modem, telephone networks, LAN - "Local Area Network", WAN - "Wide Area Network") on the HTML pages 35 to access from the field device 33 and thus also the raw data 36 of the field device 33 referenced herein. According to FIG. 5, the HTML page (s) 35 is (are) first requested from the user personal computer 30 with the aid of the browser device 31. After the HTTP server 34 of the field device 33 has provided the HTML page (s) 35, including the references to the raw data 36 contained therein, the HTML page 35 and the raw data 36 are transmitted to the user personal computer 30 , Here, the HTML page 35 and the raw data 36 are transmitted by means of separate protocols between the field device 33 and the user personal computer 30, preferably HTTP or RPC protocol. The raw data 36 can then be processed in the user personal computer 30 using suitable programs. To execute the RPC protocol, the field device 33 additionally comprises an RPC server 34a.

When downloading the HTML page 35 from the HTTP server 34, the referenced files of the raw data 36 can also be loaded automatically. The call from HTML page 35 can look like this: <EMBED SRC = "rawdata. Ext">. The parameter “SRC” is used to reference the file with the raw data 36 of the field device 33. In addition, the downloading of the raw data 36 can also be triggered via a link on the HTML page 35 to be activated by the user. In this case, the call in HTML page 35 looks like this:

<a href="rawdata.ext" type="mime type"> link </a>.

So that the browser device 31 can start the correct program for further processing the raw data 36, the browser device 31 must be informed of the content type of the raw data 36. There are different procedures for this, depending on the operating system of the user personal computer 30 and the browser device 31 used. Both the file extension (for example "* .ext") and the MIME type (MIME - "Multi-purpose Internet Mail Extension") supplied by the HTTP server 34 can be evaluated The raw data processing program converts the downloaded raw data 36. The raw data processing program can be implemented as a browser plug-in, as an ActiveX component or as an external program.

A distinction must be made between different types of raw data. The processing of sporadically generated raw data 36 is preferably carried out with the aid of a browser plug-in or an Active X component. In this context, the data is accessed using the TCP protocol. If continuously updated raw data 36 are to be processed in the form of an endless data stream, then it makes sense to use a more effective protocol for the transmission to the user personal computer 30 (the user devices N1..NN). The additional RPC protocol is used to separate the information to be displayed in the user devices N1 ... NN (or the user personal computer 30) about the field device (s) FG1 ... FGN or 33 in allows static and dynamic information. The static information is Standard protocol transmitted, while the dynamic, i.e. changing data is transmitted via the more effective RPC protocol. The effort that would be incurred when sending the dynamic data using the HTTP protocol by establishing / closing the connection and monitoring the connection would exceed the event-dependent, repeated transmission of the dynamic data using the RPC protocol. Since usually only a few data are to be transmitted quickly (measured values, message lists, ...), the use of a connectionless protocol, in particular the RPC protocol, is advantageous for the dynamic data. When a remote procedure call (RPC) is carried out, a local program calls a procedure on a remote system. The concept of the remote procedure call ensures that the entire network code is hidden in the RPC interface and in the network routines. This avoids that the application programs (client and server) focus on details such as conversion EBCDIC <> ASCII, number conversion,

Socket, session etc. One goal of RPC is to simplify the implementation of distributed applications. UDP ("User Defined Protocol") is used by some applications that can only send short messages and can repeat them. UDP is therefore an ideal protocol for distributing information that is constantly changing, such as stock exchange prices packing the data into a TCP envelope and then into the IP envelope, they now migrate into a UDP envelope before they come into the IP envelope. Although UDP is located in the same layer as connection-oriented TCP, It is a connectionless protocol. The use of the UDP protocol always makes sense if only a little data is to be transmitted quickly. For example, there is an exchange of short requests between client and server in application programs. and answers. The effort involved in establishing / closing the connection and monitoring the connection would exceed that of sending the data again. The separate transmission of static and dynamic data between the field devices FG1 ... FGN in the device network and the user devices N1 ... NN in the company intranet using different protocols is provided by the provision and the specific design of the proxy server described later in detail 1 optimized.

The use of the RPC protocol for retrieving the dynamic data in a client / server arrangement (user devices N1 ... NN / field devices FG1 ... FGN) is described below with reference to the schematic illustration in FIG. 6.

An RPC call runs as follows, for example:

(a) A client process 100 running within browser 31 (see FIG. 4) calls an RPC interface 101. This client process 100 can e.g. be a Java applet embedded in an HTML page. The RPC interface 101 has the task of specifying the subroutine entry. The specification contains the name of the function and the number and types of parameters. This defines a logical entry. The RPC interface 101 enables the remote procedure 102 to be started.

(b) The parameters of the client process 100 are read from the RPC interface 101. The purpose of the RPC interface 101 is to package and convert the parameters for the server program.

(c) The network routines send the messages to a server process 103, which runs in the RPC server 34a. (d) An RPC interface 104 of the server process 103 rebuilds the parameters from the message packets.

(e) In the next step the server program is called. A server stub is defined for this. This stub is the actual entry into the procedure lying on the server process 103.

(f) After the procedure has been processed, control is passed back to the RPC interface 104.

(g) Interface 104 packs the return parameters and then transports the data to the network routines.

(h) The network routines transport the data to the client process 100 via network-dependent calls.

(i) The RPC interface 101 of the client process 100 unpacks the parameters and supplies the specified parameters with the new data.

(j) Control is returned to the client process 100, which can process the received data further.

The concept of the remote procedure call ensures that the entire network code remains hidden in the RPC interface and in the network routines. This prevents the application programs (client and server) from looking at details such as Conversion EBCDIC <> ASCII, number conversion, socket, session etc., must take care of. One advantage of using the RPC protocol for dynamic data is that it simplifies the implementation of distributed applications.

Operating the field devices

The retrieval of information described in connection with FIG. 4 from the field device 33, which includes the HTTP server 34, can also be carried out in connection with actions within the framework of the Observation and operating system can be used, which are executed for the purpose of operating the field device 33. This makes it possible to operate the field device 33 using the browser device 31. This is described in more detail below.

The field device 33 contains a storage device 35a, in which operating software is stored in the form of HTML pages 35, and a Java archive or data from which HTML pages can be generated. The operating software is specially tailored to the field device 33. When the user enters the URL address of the field device 33, an HTTP download starts, which leads to the downloading of the operating software from the HTTP server 34 of the field device 33 into the user personal computer 30. After downloading the operating software from the field device 33 to the user personal computer 30 in the form of the HTML page (s) 35, the front view of the field device 33 is shown with all operating and display elements within the browser device (cf. FIG. 3 ). The user can then use certain operating functions of the field device 33

Trigger with the click of a mouse on the screen of the user's personal computer 30. The user action is transmitted to the field device 33 by means of a fast and effective protocol which, on the one hand, transmits the above-mentioned operating requirements from the user personal computer 30 to the field device 33 and, on the other hand, reads back reactions from the field device 33. For this purpose, the internal operating and display functions of the field device 33 to the interface of the browser device 31 are published, e.g. Keyboard buffer, display buffer, LED status.

As part of the operation by the user, there is an interface between the user personal computer 30 and the field device 33. exchange of short inquiries and answers as part of a

Client-server relationship. The effort involved in setting up / clearing down and monitoring the HTTP connection between the user personal computer 30 and the field device 33 would exceed the effort involved in retransmitting and receiving the data in accordance with a connectionless protocol. Since usually only a few data are to be transmitted quickly (e.g. key press, display content, LED status), the use of a fast, effective, connectionless protocol makes sense, for example the RPC protocol described above. In order to reduce the amount of data exchanged (e.g. display content) between the user personal computer 30 and the field device 33, data compression methods are used.

Internet protocols, such as TCP / IP and HTTP, do not offer any security mechanisms. Additional protocols are required to enable secure communication. The mechanisms for protecting security-related actions on the field device 33 via TCP / IP communication are of particular importance. With regard to protection against unauthorized access, the operating actions on the field device 33 can be classified (cf. Table 1).

Table 1

Abusive actions when operating the field device 33 can essentially be excluded by the following measures:

With the help of a firewall (e.g. proxy server), the internal network (company intranet / LAN) can establish a protected connection with another network (e.g. Internet).

The field device 33 is set in the delivery state in such a way that keys that enable the complete entry of customer passwords are blocked. This lock must be lifted by the customer on the field device 33 itself or with the operating program in the browser device 31 on the user personal computer 30 (password entry required). In the delivery state, only simple operating actions are possible via the browser device 31: navigation in the operating menu, display of measured values, parameters and message lists.

With the knowledge of the passwords, the parameterization of the field device 33 in the front view emulation is as on the field advises 33 possible if the blocking of the required

Buttons is released.

Actions relevant to security on the field device 33 (switching, controlling, deleting buffers, ...) are protected by authentication protocols, e.g. by means of a hash function and a key generated by the field device 33. This means that no conclusions can be drawn about entered passwords from the connection log. With this method, 128-bit information, the so-called "message digest", is formed from a message of any length and is appended to the original message. The receiver (field device 33) compares the "message digest" with that of the field device 33 determined from the information. As a result, field device passwords are not transmitted via the communication link.

The keys generated in the field device 33 expire after a short time and can only be used once for a transmission. This means that the recording of security-relevant logs and a later repetition of these recorded logs is ineffective.

Proxygerver

An element for the optimized implementation of the described functional interaction of the elements of the observation and operating system, for example the use of the RPC protocol, the retrieval of the raw data from the field devices FG1 ... FGN and the operation of the field devices using a browser on the user devices N1 .. .NN, is the proxy server 1. Known standard HTTP proxy servers only support the HTTP Protocol and are therefore not able to serve as a gateway between the device network and the company intranet. For this reason, a specific proxy server 1 designed for the BuB system was created, which supports both protocols used by the field devices FG1 ... FGN (HTTP, RPC).

A major advantage that when using the proxy server 1 over the coupling of the device network to the company intranet using a router or, if no WAN

There is a connection (WAN - "Wide Area Network") between the device network and the intranet, a direct coupling of the device network segment via a hub or a switch consists in the use of so-called "caching".

The principle on which this method (“caching”) is based is briefly described in the following, generally without reference to the figures mentioned above.

If a client makes a request for an object to a server device, this request initially runs via a so-called proxy device. The proxy device checks whether the object in question is already in a local memory (cache) of the proxy device, which is usually formed on a hard disk. If it is determined here that the object is not locally in memory, the proxy device forwards the request to an actual target server device. From there, the proxy device receives the object and stores a copy of the object in the local for further requests for this object

Storage before the proxy device passes the object on to the requesting client. However, if the object is found in the local memory of the proxy device, the request The client's question is not put through to the target server device, but the client receives the desired object directly from the proxy device. A prerequisite for optimal execution of the described method is a sufficiently large memory area in the proxy device, ie in the order of magnitude of several hundred MB to several GByte. Otherwise, the local memory in the proxy device overflows and a "garbage collector" (a so-called clean-up service) must be started, which filters outdated objects from the memory in order to make space for new objects there.

Advantages of the described method (“caching”) are: an improvement in performance (faster data transport than external); a saving of external bandwidth

(more space for other services remains free); a reduction in response times

Relief of the target server setup; when the object is transported from the proxy device to the client, there are no or lower transmission costs; and the hit rates in the proxy device's local memory can be very high depending on usage.

The proxy server 1 used to connect the device network and the company intranet (see FIG. 1) is based on the described basic principle and, due to the specific design, which will be described in detail later, also has the advantages mentioned below.

By using the proxy server 1 (see FIG. 1), there are significant advantages in terms of speed when accessing the device network. The proxy server 1 comprises a file memory or file system optimized for use in the BuB system. before that buffers all files with static data from the field devices FG1 ... FGN in the proxy server 1. If such a file is accessed for the first time, then this file must be fetched directly from one of the field devices FG1 ... FGN. If this file is accessed again, however, it can then be delivered directly from the file cache of the proxy server 1. Since the local company intranet is generally much faster than a modem connection to the field devices FG1 ... FGN, there are significant speed advantages when accessing the device network, since only the HTML pages and the Java archives of significantly smaller dynamic data are transmitted over the slow modem connection.

The proxy server 1 also increases security in the network. The proxy server 1 seals off the two networks, device network and company intranet, from one another and only transmits the protocols processed in the proxy server 1. This means that only the requirements generated by a browser on the user devices N1 ... NN to the field devices FG1 ... FGN are transmitted from the company intranet. Only the responses generated by the field devices FG1 ... FGN are transmitted in the opposite direction. This means that all other data packets circulating on the company intranet are kept away from the device network and therefore do not influence the throughput in the device network. Furthermore, a high data volume occurring in the device network due to cross-communication between the field devices FG1 ... FGN cannot increase the network load in the company intranet.

The use of the RPC protocol by means of the proxy server 1 has the advantage of ensuring that the field devices FG1 ... FGN can be accessed by the xyserver 1 connected company intranet remains limited.

A company intranet is usually connected to the Internet via an HTTP gateway. This gateway takes on a firewall function here (see FIG. 7) by blocking the transmission of the RPC protocol. As a result, the data of the field devices FG1 ... FGN can no longer be accessed outside the company intranet, since all dynamic data of the field devices FG1 ... FGN are transmitted via the RPC protocol.

The proxy server 1 enables a variety of functions that are not available with the direct access to the field devices FG1 ... FGN that has been customary up to now. The following compilation lists further essential functions that result in connection with the following detailed description of the proxy server 1:

A separate homepage is made available via which all connected field devices FG1 ... FGN can be reached. - The connected field devices FG1 ... FGN are automatically addressed and recognized; Representation of these field devices FG1 ... FGN on the homepage as the start page on the user devices N1 ... NN for direct device access. Access is made possible via device names of the field devices FG1 ... FGN, this is more user-friendly than access via the IP address.

The proxy server 1 can be configured using a browser on the user devices N1 ... NN (e-mail addresses, telephone numbers, device names, ...) - the proxy server 1 defines the possible access routes ("firewall function"). The proxy server 1 can temporarily store data from the field devices FG1 ... FGN This function is suitable, for example, for the logging of the accident information or the operational measured values. This data is stored internally in an XML database (XML - "Extended Markup Language"). The proxy server can make the data transmitted from the field devices FG1 ... FGN via the RPC protocol available in XML format For example, user-specific expansions of the representations available in proxy server 1 can be carried out. For this purpose, an XSL parser (XSL - "Extended Stylesheet Language") integrated in proxy server 1 is available.

Due to the filters on the XML database that can be implemented with the aid of the XSL parser, the proxy server 1 can also be used as a client for further applications. Signaling of events in the LAN (LAN - "Local Area Network") via e-mail is possible. The proxy server 1 provides its own e-mail mailboxes that can be accessed using a P0P3 client (POP3 - "Post Office Protocol Stepping 3" ) , such as Outlook, can be accessed. It is also possible to forward e-mails to another mailbox using an SMTP server (STMP - "Simple Message Transfer Protocol") integrated in the proxy server 1.

The design of the proxy server 1 is described in more detail below.

FIG. 7 shows an arrangement with the device network and the company intranet according to FIG. 1, elements of the proxy server 1 being shown schematically. FIG. 8 shows function blocks of the proxy server 1 in a block diagram.

According to FIG. 7, each of the field devices FG1... FGN has a respective HTTP server HS1... HSN, which correspond to the respective HTTP server 34 (see FIG. 4) and is connected with a star coupling. ler 39 are connected. The proxy server 1 also has an HTTP server 40. The operation of the proxy server 1 is described below with reference to FIG. 8.

Access to the proxy server 1 always takes place from the local network of the company intranet, in which the user devices N1 ... NN with the respective modem connection are located in the device network comprising the field devices, which can comprise a substation or several substations. If one of the user devices N1 ... NN is addressed as a server via the associated local IP address, this access is forwarded to the HTTP server 40 via a TCP / IP stack 41 (TCP - “Transfer Control Protocol”).

The HTTP server 40 delivers the requested files to the company intranet. For this purpose, the HTTP server 40 contacts a cache manager 43 via a file filter 42. The file filter 42 normally forwards the request to the cache manager 43. Only certain requests are recognized based on the requested file type and sent to another processing path. These exceptions are described later. The cache manager 43 first tries to find the requested file in the local files 44 or in a file cache 45. If the requested file is neither a local file of proxy server 1 nor in the file cache

45 exists, the file request to an HTTP client

46 forwarded. This establishes a connection to the HTTP server HS1,... Or HSN of the addressed field device FG1,... Or FGN in the device network via a further TCP / IP stack 47 in order to obtain the requested file from there. A modem connection with the PPP protocol is preferably used as the connection to the device network (cf. FIG. 1). Since the proxy server 1 can hold several connections to different field devices FG1 ... FGN at the same time via this modem connection, an arbiteration of this modem connection is necessary because the PPP protocol can only manage a point-to-point connection. A block slot protocol 48 is used for this purpose. This protocol allocates time slices on the modem communication link to the individual PPP connections and thus prevents collisions between the individual connections. The block slot protocol 48 is also responsible for recognizing all field devices FG1 ... FGN active in the device network. For this purpose, the device network is searched cyclically for active field devices. The detected active field devices are entered by a device manager 49 into an XML database 50 of the proxy server 1.

The XML database 50 is a data tree stored according to the standardized “Document Object Model”. Now contains a user device N1,... Or, respectively, via the HTTP server 40 in the browser of a user device connected to the proxy server 1. NN loaded HTML page Java code that establishes a parallel UDP connection (UDP - "User Defined Protocol") for the RPC protocol, then this way an RPC server 51 is addressed from the company intranet.

Since the RPC protocol is based on the standardized UDP / IP protocol for performance reasons, a connection management 52 must be contained here in the proxy server 1, since the UDP protocol does not operate in a connection-oriented manner. The connection management 52 ensures that a separate communication port for an RPC client 53 of the proxy server 1 is reserved in the device network for each usage device N1... NN from the company intranet. The RPC requirements out the company intranet is then via the RPC client 53 of the

Proxy server 1 forwarded directly to the device network

The responses of the field devices FG1 ... FGN to RPC requests are forwarded to the RPC server 51. This forwards the response of the respective field device FG1, ... or FGN to the user equipment via the company intranet. At the same time, the dynamic data currently transferred in the RPC protocol from the respective field device FG1,... Or FGN are stored in the XML database 50 in the proxy server 1.

The data stored in the XML database 50 can be converted into any other data formats using an XSL parser 54 integrated in the proxy server 1. The necessary transformation instructions must be as XSL

Script file are stored locally in proxy server 1. To trigger such a transformation process, an * .XML file must be requested from the HTTP server 40. Such a request is filtered out of the normal access path to the cache manager 43 by the file filter 42 connected to the HTTP server 40 and forwarded to the XSL parser 54. This reads an XSL file of the same name from the files stored locally in proxy server 1 in addition to the requested XML file and starts the transformation process. The result of this transformation is sent from the HTTP server 40 to the requesting user. In this way, e.g. B. HTML files generated dynamically from an XSL template with the current data of the field devices FG1 ... FGN from the XML database 50 or simply a subtree of the database can be transferred as an XML file. The file filter 42, the cache management 43, the local files 44, the file cache 45, the XSL parser 54 and the XML database 50 form a file system of the proxy server 1.

Individual functional blocks of the proxy server 1 are described in more detail below.

HTTP server

First, the basic mode of operation of the HTTP server 40 embodied in the proxy server 1 (see FIG. 8) is explained, some essential basics of the HTTP being described for better understanding.

As with other application protocols on the Internet, HTTP (HTTP - "Hypertext Transfer Protocol") is an ASCII protocol that uses a secure TCP connection between a client (computer of the Internet user) and a server (server device) for data exchange Internet access - data - are available) The port 80 is defined as the starting point, ie an HTTP server is listening on this port for new client connections, or the vast majority of HTTP server software via a corresponding configuration dialog, you can also be instructed to use a different port for establishing contact.

Unlike other protocols, e.g. B. FTP (FTP - "File Transfer Protocol") and POP3, a connection between an HTTP client and an HTTP server is very short-lived

HTTP client establishes a TCP connection to the desired HTTP server via port 80 and sends a request for a desired document to the HTTP server. The HTTP server receives the request, evaluates it and, if successful, sends the desired document back to the HTTP client. The HTTP server closes the TCP connection automatically after it has sent the HTTP client the requested document or an error message in response to its request.

An important functionality of HTTP is that the HTTP client can tell the HTTP server what kind of data it can understand. With every request, there must be communication between the HTTP client and the HTTP server about how the data should be transmitted. This communication creates a so-called “overhead”; HTTP is therefore also known as a stateless protocol because the connection does not go through several phases, from logging in, through data exchange to logging out through the HTTP client. On the one hand, this facilitates the development of HTTP client / HTTP server software, but is not very efficient with regard to the use of the available bandwidth.

The HTTP protocol is used to access sources in URL format (URL - "Uniform Resource Locator"). The HTTP client, usually a web browser on the computer of the Internet user. It requires an HTML And then generates a sequence of requests for file references in that HTML page, after which the user will likely click a link in the requested HTML page and the HTTP client will send a request for the HTML pages associated with that link , to the same or another HTTP server. These other communication connections no longer have any information about a previous connection. This works for simple ones Client / server environments. In the case of more extensive communications, however, this method of working can become a problem, because for every small amount of data that is to be transmitted, this excess ("overhead") occurs, which reduces efficiency.

Figure 9 shows a schematic representation of the syntax of a request in connection with an HTTP client / server interaction.

The HTTP client / server interaction consists of a single request / response communication. It comprises a "request line", one or more optional "request header fields" and an optional "entity body". One is sent from the HTTP client side 60, that is to say generally from the Internet browser

TCP connection to the HTTP server 61 opened 62. The HTTP client 60 then sends a command string to the HTTP server 61. The HTTP server 61 responds via the TCP connection opened by the HTTP client 60 with a header that is next to it the HTTP version supported by the HTTP server 61 also contains the MIME type and the coding of the requested file. The HTTP server 61 appends the content of the requested file to this header in ASCII format. After the HTTP server 61 has sent the complete file, it closes the TCP connection 63 opened by the HTTP client 60. This process can be repeated as often as desired.

The following compilation shows the process of a typical HTTP access:

1. "connection"

• WWW client establishes a TCP / IP connection to the WWW server 2. "request"

• Specifying an access method (GET, HEADER, POST ...)

• Specification of the desired document using URL

• Additional information in the form of MIME headers

• data (at POST)

3. "response"

• Header with status code

• Additional information in the form of MIME headers

• Document in HTML format

• Data in other formats (images, sound ...)

4. "close" (disconnection)

• Usually from the HTTP server after data transfer

• In special cases from the HTTP client (transmission time, storage space)

Here, the "request line" consists of three text fields, which are separated by spaces. The first field specifies the method (or the command). The second field specifies the name of the source (is the URL without specifying the protocol and the The last field specifies the protocol version of the HTTP client 60 used, for example HTTP / 10. The “request header fields” provide additional information about the request and the HTTP client 60. The fields are used as a type of RPC parameter. Each field consists of a name, followed by a colon and the field value. The order of the "header fields" is not important here. The "entity body" is sometimes used by HTTP clients 60 to send larger packets of information to the HTTP server 61.

file cache

In order to enable the cache manager 43 to work as efficiently as possible, the file cache 45 does not work as usual with the URL, the date and the lifespan of the files to be managed, but uses other criteria for identifying a file. If only the three criteria mentioned were used to decide whether a file locally in the file cache is identical to the file available in the field device, then a comparison of the file characteristics mentioned would be necessary to carry out this test. To do this, the header from the field device would have to be requested for each file. However, since the file system of the field devices FG1 ... FGN can only be loaded as a unit in the form of a KON file (converted files - format that can be loaded into the user devices N1 ... NN), such a comparison is not for every file required. An exception to this are the files generated dynamically in the field devices FG1 ... FGN, for example the file MLFB.TXT (MLFB - machine-readable manufacturer name), which are not read from the file system of the field devices FG1 ... FGN, but from the field device FG1, ... or FGN set MLFB is generated.

An entry in a file "nocache.txt" serves as a distinguishing feature between these two file forms, namely the static files and the files with dynamic data. All files generated dynamically in the field devices FG1 ... FGN must be in this file Static files are downloaded from the HTTP server HS1 ... HSN of the field devices. te FG1 ... FGN marked with an infinite lifespan. The following is an example of the content of the nocache.txt file:

/mlfb.txt: MLFB, BF No., display type

/ textpool. zip: device-specific texts for applets

(multilingual)

/ver.txt: version, date

/ Chartab. jar: device character set

The file "ver.txt" can have the following content:

V01.01.01 Tue, 24 Oct 2000 07:50:00 GMT

Slot protocol of the proxy server

The slot protocol 48 (cf. FIG. 8) serves to connect the proxy server 1 to the field devices FG1... FGN in an arrangement with a star coupler according to FIG. 7. The slot protocol 48 is divided into the two areas (i) device detection and (ii) Arbiting the star coupler arrangement. The device detection is used for the automatic detection of all field devices FG1 ... FGN connected to the star coupler 39. The arbitration must prevent collisions between datagrams of different field devices FG1 ... FGN on the communication link between proxy server 1 and the individual field devices FG1 ... FGN.

The device detection when using the star coupler arrangement 39 is described below. device Discovery

The device identification is a component of the slot protocol 48. This protocol part exclusively occupies the serial connection, i. H. no other communication may be active on the modem link during device detection. For this reason, device recognition is only activated when the modem connection is established. This part of the protocol is inactive during operation of the monitoring and operating system. Device detection can, however, be activated if necessary.

Figure 10 shows a master-slave arrangement with a star coupler to explain the device detection.

The slot protocol 48 works according to the master-slave principle. A master 70 is located at the upper connection in FIG. 10. The lower connections of a star coupler 71, which corresponds to the star coupler 3 in FIG. 1, are each occupied by a slave S1 ... SN, which the field devices FG1 ... FGN according to FIG 1 correspond. The master 70 could query every possible address of the connected slaves S1 ... SN and, in response to this query, add the found slave Sl, ... or SN to the list of devices known to the master 70. However, this procedure can no longer be carried out with an address range of 32 bits. 2 32 queries would be required here. However, this number can no longer be carried out since the time required for this query would exceed the life of the system. In order nevertheless to be able to automatically recognize the devices connected to the master 70, the problem is solved according to the invention in the following way: In the case of an addressing scheme with a binary-coded address with a predefined address length, an address range is always queried when a request is made. Only the slaves that are in the queried address range respond to this request. Since there can be several field devices (slaves) in the same queried address range, a collision inevitably results in a simultaneous response from several of the slaves S1 ... SN. This collision is deliberately accepted and is part of the proposed procedure. For this reason, the master 70 only checks whether an answer to its request has been received within a defined period of time.

If the address space of the addressable slaves S1 ... SN is n bits, the master 70 sends out a request with a fixed bit of the address and a mask for the other address bits. Two queries can be used to test whether there are slaves in the address range specified by the fixed bit. If a response to a request for an address range was received, the mask is changed to one

Reduced bit and tested for the next fixed bit with two inquiries whether there are slaves in the now smaller address area. If there is an answer to the request for the now smaller address area, the next bit of the address area in which slaves are located is found. This process is repeated until the mask for the address area has been reduced to 0 bits. Then one of the slaves S1 ... SN is clearly identified on the bus. If answers to both states of the bit being tested come up during a query, then both branches are followed up in the next iteration. Since with a mask size of 0 bits only the device or the slave with the requested, now completely fixed address to the request made cannot respond to the last request

Collisions occur more, and the response telegram of the slaves to be detected can contain spontaneous information about the status of the connected slaves. FIG. 12 explains the described method again using a simple addressing scheme with a 4-bit address, that is to say for an address space from 0 to 15. It is assumed that the devices with addresses 3, 4 and 7 are in the arrangement , It will start with the query of the most significant bit. Address space 0 to 7 is tested on the one hand and address space 8 to 15 in a second query with one query. No device answers this second query. The master receives one or more answers to the first query. For this reason, the mask is reduced by an additional bit in address space 0 to 7. Address ranges 0 to 3 are now checked with a third query and 4 to 7 with a fourth query. This process is repeated as shown in FIG. 12 until the addresses are completely resolved and all devices are found.

In the example described, the slaves Sl ... Sn or the field devices FG1 ... FGN are connected to the master 70 using an IP-based protocol. With the IP protocol, all bus users have a 32-bit address. The address is divided into octets and each octet is shown in decimal. The hexadecimal 32 bit number Ox8D8D8000 therefore corresponds to the IP address 141.141.128.0. A recursive variant of the procedure described in the previous paragraph is used for the actual process for device detection / interrogation.

FIG. 11 shows the flow diagram of the method as a Nassi-Sneidermann diagram. In the context of the described method, the test as to whether a field device (slave) can be addressed in the available address range is preferably initiated by master 70 with the aid of a request datagram known as such. In contrast to conventional methods, however, it is consciously accepted that several of the slaves S1 ... SN respond to a request datagram sent by the master 70 at the same time. The fact that all signals received by the slaves S1 ... SN in the star coupler 71 are linked via a logical OR gate and this sum signal is forwarded to the master 70, can ensure that a response from one of the slaves is present in the master 70 S1 ... SN is recognized in any case. If the response datagrams of several of the slaves S1 ... SN overlap temporarily, an incorrect datagram is received in master 70. This case is also recognized as the answer.

With the aid of the specification of a maximum response time for the slaves S1 ... SN to a request datagram of the master 70 and the datagram transmission time, a monitoring time for the master 70 can be defined. If the master 70 receives a response within this monitoring time, there are slaves or field devices in the requested address area. Conversely, there are no field devices in the requested address area if the master 70 has not received a response to the request within the monitoring time.

Since only one of the slaves S1 ... SN can respond to a complete resolution of the address in the request of the maters 70 (ie the mask becomes empty), a collision can no longer occur in this case. In this case, the error protection of the received datagram can be used to prevent a line fault and thus a possible fault detection of a connected slave. If a line fault occurs during the monitoring time after a request from the master, which pretends that a slave is not present, this only leads to an extension of the query process, but not to incorrect detection of connected slaves, since this line fault occurs at the latest when the slave is completely resolved Mask is recognized. The following paragraph shows the function of the method using an example:

Test 141, .141. .128.0 Mask: 255.255.128.0 Test 141. .141. .0.0 Mask: 255.255.128.0 Test 141. .141. .64, .0 Mask: 255.255.192.0 Test 141, .141. .96. .0 Mask: 255.255.224.0 Test 141. .141, .64, .0 Mask: 255.255.224.0 Test 141, .141. .80, .0 Mask: 255.255.240.0 Test 141. .141. .88, .0 Mask: 255.255.248.0 Test 141, .141, .80. .0 Mask: 255.255.248.0 Test 141. .141. .84, .0 Mask: 255.255.252.0 Test 141, .141, .86. .0 Mask: 255.255.254.0 Test 141. .141. .84. .0 Mask: 255.255.254.0 Test 141, .141. .85, .0 Mask: 255.255.255.0 Test 141. .141. .84, .0 Mask: 255.255.255.0 Test 141. .141. .84. .128 Mask: 255.255.255.128 Test 141. .141. .84. .0 Mask: 255.255.255.128 Test 141 ... 141. .84. .64 Mask: 255.255.255.192 Test 141. .141. , 84th .0 Mask: 255.255.255.192 Test 141. .141. , 84th .32 Mask: 255.255.255.224 Test 141 ... 141. .84. .0 Mask: 255.255.255.224 Test 141 ... 141. .84. .16 Mask: 255.255.255.240 Test 141 ... 141. .84. .0 Mask: 255.255.255.240 Test 141 ... 141. .84. .8 Mask: 255.255.255.248 Test 141 ... 141. .84. .0 Mask: 255.255.255.248 Test 141 ... 141. .84. .4 Mask: 255.255.255.252 Test: 141 141 84.0 Mask: 255 255.255.252

Test: 141 .141 84 .2 Mask: 255 .255 .255 .254

Test: 141 141 84 .3 Mask: 255 .255 .255 .255

Test: 141 .141 84 .2 Mask: 255 .255 .255 .255

Found: 141 141 84 .2

Test: 141 141 84 .0 Mask: 255 255 .255 254

Test: 141 141 80 .0 Mask: 255 .255 .252 .0

Test: 141 141 82 .0 Mask: 255 255 .254 .0

Test: 141 .141 80 .0 Mask: 255 .255 .254 .0

Test: 141 141 81 .0 Mask: 255 .255 .255 .0

Test: 141 141 80 0 Mask: 255 255 255 0

Test: 141 141 80 .128 Mask: 255 .255 .255 .128

Test: 141 141 80 192 Mask: 255 255 255 192

Test: 141 .141 80 .128 Mask: 255 .255 .255 .192

Test: 141 141 80 160 Mask: 255 255 255 .224

Test: 141 141 80 176 Mask: 255 255 255 240

Test: 141 141 80 160 Mask: 255 255 255 240

Test: 141 141 80 168 Mask: 255 255 255 248

Test: 141 141 80 160 Mask: 255 255 255 248

Test: 141 141 80 164 Mask: 255 255 255 252

Test: 141 141 80 166 Mask: 255 255 255 254

Test: 141 141 80 164 Mask: 255 255 255 254

Test: 141 141 80 165 Mask: 255 255 255 255

Test: 141 141 80 164 Mask: 255 255 255 255

Found: 141 141 80 164

Test: 141 141 80 160 Mask: 255 255 255 252

Test: 141 141. 80 162 Mask: 255 255 255 254

Test: 141 141 80 163 Mask: 255 255 255 255

Found: 141 141. 80 163

Test: 141 141 80 162 Mask: 255 255 255 255

Test: 141 141. 80 160 Mask: 255 255 255 254

Test: 141 141. 80 161 Mask: 255 255 255 255

Found: 141 141. 80 161 Test: 141.141.80.160 Mask: 255.255.255.255 Found: 141.141.80.160

Test 141.141.80.128 Mask 255.255.255.224 Test 141.141.80.0 Mask 255.255.255.128 Test 141.141.64.0 Mask 255.255.240.0 Test 141.141.0.0 Mask 255.255.192.0

58 queries

The queries included the address space 141.141.0.0 to 141.141.255.255. The devices with the following addresses were found: 141.141.84.2 141.141.80.164 141.141.80.163 141.141.80.161 141.141.80.160

FIG. 12 illustrates the process shown in the form of a tree representation, the fields in bold outline indicating the queries that were answered by one or more slaves S1 ... SN or field devices.

Broadcast service

For connecting the proxy server 1 to the field devices

FG1 ... FGN, an IP-based network can be used instead of the simple architecture with star coupler 39. In this case, arbiting of this network by means of a protocol, for example the slot protocol 48, is not required. This function is performed by the network itself. In this embodiment, functions of the network can also be used for device detection. With a network connection between the proxy server 1 and the field devices FG1 ... FGN becomes the self-configuration of the observation and

Operating system uses a broadcast service.

In both cases, the detection of the connected field devices FG1 ... FGN, i.e. in the embodiment with a star coupler arrangement and when using a network, in particular a LAN, the recognition is carried out automatically when the observation and operating system is started up and takes place without prior parameterization of the components involved in the system.

The broadcast service is used to identify the field devices connected to the IP-based network (e.g. LAN) that contain a server for their own operation. The broadcast service also serves to collect spontaneous events that have occurred in the connected field devices. The broadcast service is an IP application and is therefore based on the functions of the IP stack and is based on the UDP protocol. For this service server side z. B. a fixed port OxDOOO reserved. A free port is dynamically selected on the client side. Through the use of the standard UDP / IP protocol, the IP programming interfaces of common operating systems such as B. MS Windows or Linux. The proxy server 1 can thus be easily ported to classic office servers.

The broadcast service is active both in proxy server 1 and in the individual field devices. For the broadcast service, proxy server 1 is defined as the master. A configuration query is a UDP telegram sent by the master. Depending on the configuration, this telegram is directed to a broadcast or a multicast IP address. A description Broadcast or multicast IP addresses can be found, for example, in Karanjit S. Siyan: Inside TCP / IP Third Edition, New Riders Publishing, Indianapolis, 1997, ISBN 1-56205- 714-6, page 187ff.

All field devices will then respond to the configuration query of the master with a UDP telegram, which contains the most important configuration data of the field device. Since all field devices connected to the IP-based network now theoretically want to answer at the same time, there will initially be some collisions on the bus used, which are caused by the CSMA / CD method (CSAM - "carrier sense, multiple access / collision detect") A description of this method can also be found in Karanjit S. Siyan: Inside TCP / IP Third Edition, New Riders Publishing, Indianapolis, 1997, ISBN 1-56205-714-6, page 97ff. The UDP response telegrams of all Active field devices will therefore arrive at the requesting master within a certain time, so that the requesting party is able to determine how many and which field devices are in the network and can then obtain further information from the field devices via the HTTP protocol or others Request IP-based protocols.

The broadcast service also has the task of distributing an event occurring spontaneously in one of the field devices in the IP-based network to the participants of the broadcast service. Since the field devices on the one hand have no information about which master is responsible for this signal and, on the other hand, it may be possible for several masters with distributed tasks to exist in the IP-based network, the event telegram is sent as a broadcast to all network participants. The masters can use this signal Depending on the event type and sender, ignore or trigger an action which is carried out via another protocol, e.g. B. HTTP, retrieves additional information from the field device. This retrieval of additional information on the field device sending the event by the responsible master also serves as an acknowledgment of receipt by the master. If an event telegram is not confirmed, it is repeated at regular intervals (for example about 10 s or with a logarithmically increasing time) until confirmation is received from a master.

FIG. 13 shows a schematic illustration to explain the method in the context of the configuration query.

As a master, proxy server 1 sends a configuration request 72 as a broadcast to all participants in the network. All field devices FG1 ... FGN respond with a UDP datagram to the IP address of the master that sent the configuration request. As already shown, this UDP datagram contains the most important information about the connected devices.

device management

The management of the field devices or slaves recognized with the aid of the device recognition when using the star coupler 39 or the broadcast service is carried out in the proxy server 1 with the aid of the device management 49 (cf. FIG. 8). FIG. 14 shows a schematic block diagram of the connection of the device management 49 in the proxy server 1.

The device management 49 provides the cache management 43 and the XML database 50 with information about the data generated in the device network. known field devices FG1 ... FGN. The

Device management 49 their information about the connected field devices FG1 ... FGN from the procedure running in the context of the slot protocol 48. In this way, the IP addresses of the connected field devices FG1 ... FGN are provided. The device management 49 is supplied by the slot protocol 48 with the information about the recognized field devices FG1 ... FGN. The slot protocol 48 only supplies the device management 49 with the IP addresses of the detected field devices FG1 ... FGN. All further information about the field devices FG1 ... FGN, which are to be provided by the device management 49 in the proxy server 1, is obtained by downloading HTTP data in defined files from the field devices FG1 ... FGN. Device management 49 uses the known IP addresses of all recognized field devices

FG1 ... FGN of cache management 43 the following information about the field devices FG1 ... FGN is available: field device type, field device version and version of the file block for the observation and operating system.

This information is also available in the file cache 45 (cf. FIG. 8) for the files already stored there. When a file is requested from a specific one of the field devices FG1 ... FGN, this information can be used to decide whether the file in the file cache 45 is identical to the file available in the field device, without the file header of the requested file from the specific field device to read. Only the version information for the file in the file cache 45 has to be compared with the information from the device management 49 for the IP address of the specific field device. The connection of the device management 49 to the XML database 50 is used to provide information from the field devices FG1 ... FGN. This information is loaded in the form of an XML file from the field devices FG1 ... FGN. The following table shows an overview of the contents of this file:

All this information is stored in a file “DevData.xml”. The device manager 49 initiates an HTTP download of this file if one of the field devices FG1 ... FGN was found by the slot protocol 48. All other files are saved by the device manager 49 only then loaded to the field device if their file path is contained in this XML file, ie all files encapsulated with a <DEV_PATH> tag are loaded.

The file “DevData.xml” is transformed in the proxy server 1 after downloading using the XSL parser 54 into the internal format of the proxy server 1 and then entered in the XML database 50 of the proxy server 1.

XSL parser

The XSL parser 54 (see FIG. 8) is used to generate dynamically generated HTML files from the central XML database 50 of the proxy server 1. For this purpose, XSL scripts stored locally in the proxy server 1 are used. The XSL scripts can be imported into the proxy server 1 using an admin page.

FIG. 15 shows the integration of the XSL parser 54 in the proxy server 1.

If an XML file is requested by the user devices N1... NN from the intranet via the HTTP server 40, this request is filtered out by the file filter 42 and forwarded to the XML front-end HTTP 55. This front end searches for an XSL transformation script belonging to the requested XML file and starts the XSL parser 54 with these two files.

Since dynamically generated HTML pages always use the data used from the XML database 50 located locally in the proxy server 1, the content of this database must be compared with the data available in the devices. This Ab- The same process is necessary because a lot of data stored in the XML database 50, such as, for example, B. Measured values are time-varying. The block XML front-end RPC cache 57 takes care of this comparison. When the XSL parser 54 accesses the XML database 50, the intermediate XML front-end 57 checks the validity period of the requested information. If the requested information has already become invalid, the connection manager 52 requests it again from the RPC client 53 from the device, updates it in the XML database 50 and forwards it to the XSL parser 54.

The device manager 49 continuously monitors the status of the devices connected to the device network and updates this information using the XML front-end device data 56 in the XML database 50.

The XSL parser 54 is the main link in the representation of the current data received from the field devices FG1... FGN from the XML database 50. Each XSL script specifies transformation rules that determine how certain data is output the XML database 50 are to be displayed in the form of HTML pages in the user devices N1 ... NN. One of the basic principles of XML is the separation of content and presentation. An XML document only contains "content", its presentation must be defined separately in the form of a style sheet. There are various ways of adding the display information to an XML document. These are based on two basic processes: Either the document is brought into a displayable form according to a style sheet or the style sheet guides the display mechanism in how the individual elements of the document are to be displayed. These two basic processes can be varied in different ways: CSS stylesheet + XML document - »XML-enabled browser

The browser processes the document and the presentation information in the form of a CSS style sheet and creates a presentation. - XSL stylesheet + XML document -> XSL-capable display program

A display program that can process XSL stylesheets receives the presentation information in the form of an XSL stylesheet in addition to the document. - XSL stylesheet + XML document -> XSL transformer → HTML document

The XML document is transformed from an XSL transformer into an (X) HTML document according to the transformation rules of an XSL stylesheet, which can then be displayed by a browser.

FIG. 16 shows a schematic block diagram of an XSLT processor (XSL - “Extended Stylesheet Language Transformation”).

The block diagram shown in FIG. 16 again illustrates the data flow when an XML file is requested. The file Xview.XML requested by the client is forwarded from the HTTP server to the XSLT processor 54. This searches for the file belonging to the requested Xview.XSL file

Xview.XSL and starts the XSLT processor 54 with these two files. If process data from the XML database 50 of the proxy server is to be used in the transformation process started via the requested file Xview.XML, then the transformation script Xview.XSL must contain a reference to this database. In the example shown in FIG. 16, this XML database 50 has the name Siprogate .XML. Since all displayed with the help of the user facilities N1 ... NN

Through information in their request an XSLT processor ^', it is advisable to check the information requested in this case as described by the XML-RPC frontends cache 57 for validity and use the result for an update mechanism. To do this, the XSLT parser must be manipulated so that it can be determined which data from the individual databases are involved in the design of the HTML page to be generated. This information is then used to determine in a second step whether this data is current. Thereupon, the update mechanisms required for this are initiated, if this is necessary, and the parsing process is then started again, only those data being updated that are currently being displayed to a user in any form using one or more of the user devices N1 ... NN become. This is achieved by only updating the requested data in the XML database. Due to the possibly considerable overall size of the XML database 50, this mechanism results in a reduction in the data transmitted between the field devices FG1 ... FGN and the proxy server 1, since on the one hand only on request and on the other hand only the data required for the respective display be fetched.

Claims

claims

1. A method for transmitting raw data (36) between a field device (33) and a user device (30) for observing and / or operating the field device (33), the raw data (36) being held in the field device (33) whereby a server device (34) is formed in the field device (33) and a browser device (31) is installed on the user device (30) for data communication with the server device (34), the method comprising the following method steps:

Forming a communication link for transmitting electronic data between the field device (33) and the user device (30); - Transfer one using the browser setup

(31) on the user device (30) which can be graphically outputted, electronic description page (35) from the server device (34) of the field device (33) to the user device (30) via the communication link, the electronic description page (35) having at least one electronic Includes reference to the raw data (36) held in the field device (33); Transferring the raw data (36) from the field device (33) to the user device (30); and - automatic processing of the raw data (36) in the user device (30).

2. The method according to claim 1, characterized in that the electronic description page (35) after transmission to the user device (30) is automatically analyzed in the user device (30) in order to detect the at least one reference to the raw data (36), and that the raw data (36) after the acquisition of the few at least one reference in the electronic description page (35) is automatically transmitted from the field device (33) to the user device (30).

3. The method according to claim 1, characterized in that one of the at least one reference in the electronic description page (35) can be assigned electronically by a user with the aid of a selection means in the user device (30) and that the raw data (36) the detection of the selection of the user is automatically transmitted from the field device (33) to the user device (30).

4. The method according to claim 2 or 3, characterized in that the transfer of the raw data (36) from the field device (33) to the user device (30) with the aid of a client process (100) formed within the browser device (31) becomes.

5. The method as claimed in claim 4, so that essentially dynamic raw data is transmitted with the aid of the client process (100) formed within the browser device (31).

6. The method according to claim 2 or 3, characterized in that the transmission of the raw data (36) from the field device (33) to the user device (30) with the aid of an expansion module ("plug-in module") of the browser device (31 ) is performed.

7. The method as claimed in claim 6, so that essentially static raw data are transmitted with the aid of the extension module (“plug-in module”) of the browser device (31).

8. The method according to any one of the preceding claims, that the electronic description page (35) is an HTML page.

9. The method as claimed in one of the preceding claims, that different electronic protocols are used to transmit the electronic description page (35) and to transmit the raw data (36).

10. The method according to any one of the preceding claims, characterized in that the browser device (31) analyzes the raw data (36) transmitted from the field device (33) to the user device (30) and that for processing the raw data (36) in an application program is started automatically for the user device (30) depending on the result of the analysis of the raw data (36).

11. Field device with a connection for a communication connection (2) which can be addressed by a client device (30) via an IP address, a server device (34) for data communication with one on the client device (30 ) installed browser device (31) via the connection and a memory Storage device (35a) with an electronic description page (35) stored therein, the electronic description page (35) comprising an electronic reference to raw data (36) held in the field device (33) and the electronic description page (35) , including the raw data (36) referenced by means of the electronic reference, can be called up electronically via the server device (34) and the connection.

12. The apparatus of claim 11, because the electronic description page (35) is an HTML page.

13. The apparatus of claim 11 or 12, so that the server device (34) is an HTTP server.

14. Device according to one of claims 11 to 13, that the raw data (36) comprise measured values and / or event lists.

15. Use of a method according to one of claims 1 to 10 or a device according to one of claims 11 to 14 for monitoring energy technology systems.