DE10151119C2 - Method for detecting multiple field devices in a device configuration - Google Patents

Description

The invention is in the field of remote controlled Operating field devices, especially for the purpose of Beo and operating field devices.

Field devices are used in the automation of various used the most technical processes, for example for Ü monitor a production or manufacturing process or of a processing process. With field devices, it can the production facilities themselves or devices for practice monitor, preferably to control and / or regulate in Dependency on recorded field data, the used, tech trade means or systems.

The field devices are often in star coupler confi gurations arranged in which transmission protocols based on a master-slave architecture. To the Operating the field devices in the star coupler configuration the field devices that are connected to a Mas ter device are connected, so that the Field devices via a respective address from the master device can be controlled electronically.

From German published patent application DE 197 33 906 A1 known, for example, an automatic in a bus system Address assignment to serial communication participants (Slaves). For this purpose, a master device so-called preamble sent out by those to the master connected slaves is received. Sen each slave device will then answer. The slave device that itself does not receive a response from the other slave devices, is the last one in the serial order and becomes the ad Preservation of stress activated. During the following, further  The device baptized in this way does not accept address assignments more part.

Furthermore, DE 693 19 059 T2 describes a method for addressing allocation to end devices, in particular cable television sets, be knows, in which a server continuously verge This provisional address is broadcast. Detects one newly connected terminal device this provisional address, it sends an acknowledgment back to the server.

In addition, in Japanese Patent JP 07 231329 A described a method in which a in a star network newly added slave from the master an unoccupied address assigned from an address table.

Known star coupler configurations are based on the Transmission protocols based on master-slave architecture used. Address collisions are avoided with these protocols prevents.

Practically all known protocols for serial connection of protective or field devices are based on one in the standard cast E DIN 19244 specified link layer. This norment litter has been further developed into the European standard IEC 870-5. In addition to the link layer, the European standard also defines the Protocols for connecting or recognizing field devices  with a station control system or a remote control system tem.

Corresponding to the way a master-slave protocol works the master or master device requests a be correct of the slave devices. At the request ant only words the specific slave device. Everyone else at that Master devices connected to slave devices behave quiet. Since the star coupler i. d. Usually only one master device can be achieved in this way that a serial transmission channel between the star coupler and the slave devices are only occupied by one of the slave devices becomes. Additional circuit components for arbitration the connection is not required.

In order to enable the master device, all of the mas to be able to address the slave device to be managed, the master device requires a list of the connected slaves ve devices. The master device must therefore all connected Slave devices. Only if he meets this requirement is filled, the slave devices can be specified via their address be spoken. Since the parameterization of the telecontrol or Station control master is time-consuming and complex, these activities require a considerable amount of time and costs.

The object of the invention is to provide an improved method for Detect connected field devices to create which also in connection with a high number of address requests time and cost-effective work possible light.

This object is achieved by the method according to claim 1 solves.

An essential idea of the invention is, Teilbe ranges of a total address range with a single request  according to the presence of field devices in the respective Query partial area. It is not necessary here at first dig to address the field devices with their respective addresses. Several field devices can also respond to a request. This is consciously accepted. With the successive, targeted reduction of the queried sub-areas then the addresses of the connected field devices in the further Process automatically recognized.

From German published patent application DE 195 44 027 A1 a bus system, especially for house installation, known, in order to simplify the construction of a Communication collision of several bus participants in purchase is taken; however, there is no ad here in any way address recognition or assignment instead.

Furthermore, from "Algorithms and Data Structures with Modula-2" (Wirth, N .; B.G. Teubner-Verlag, Stuttgart, 4th edition, 1986, Pages 56-58) a binary search method known in which for Determination of an object from a search area in the optimal If the middle of the range is chosen and a statement about whether the object is in the top or lower half. With this procedure, however, only a single object can be determined; an acquisition Multiple addresses in a device configuration can be used with this Procedure does not take place.

In an advantageous development of the invention is before seen that the respective electronic address of the Feldge advise a binary address so that half of the addressab question area and the remaining half of the address query area by setting a measurement bit to one Value 0 or 1 are formed, whereby the division of Ge complete address range in a simple manner and with little time effort is possible.  

If the addresses are designed as binary addresses, in the case of electronic queries, the measuring bit and one Bit mask are transmitted to the field devices, the Bit mask includes bits that are not output by the field devices be evaluated, d. H. go unnoticed.

The bit mask is used to find the address of the field devices when repeating the electronic query n times successive repetitions always shortened by one bit. Repeating n times is aborted if the bit mask no longer includes bits, i. H. the electronic query summarizes the exact address of the addressed field device.

An expedient development of the invention provides that the recorded electronic responses or the other electro responses in the central device using an OR Gatters can be processed electronically, resulting in low Circuit effort can be recognized whether in a query ad field devices.  

In an advantageous embodiment of the invention provided that electronic and / or other electronic Responses are recorded that collide in time, such that they're essentially at the same time with the central device received. A detection of the temporal collision of Ant words of the field devices is therefore not necessary, whereby the circuitry effort kept as low as possible can be. It is sufficient to see if at all there was an answer.

To the procedure for recognizing the connected field devices in terms of the time required to be as efficient as possible talten, in a preferred embodiment of the inventor be provided that the detection of the electronic Response from the at least one of the field devices from the half te of the address query area and capturing the other e electronic response from the at least one of the other Field devices from the remaining half of the address query Reichs by means of the central device to a predetermined Period after submitting each electronic or after sending the other individual, electronic limited request.

The method can advantageously be used in conjunction with control / Telecontrol systems used by energy systems become.

The method and / or the device can advantageously be used for Monitoring energy systems are used.

The invention is described below with reference to exemplary embodiments play explained 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 is a surface configuration of a browser device with graphical representations for re several field devices;

Fig. 3 is a different surface configuration of the browser device with a graphical representation of a front view of a field device;

Fig. 4 is a schematic representation of a field unit and a user's personal computer;

Fig. 5 a. Flow chart for downloading HTML pages as part of an observation and operating system;

Fig. 6 is a block diagram for explaining an RPC call;

Fig. 7 is a representation of the arrangement with the device network and the company intranet of Figure 1, with individual elements of the proxy server are shown schematically ge.

Fig. 8 is a schematic block diagram of the Proxyser vers;

9 is a schematic diagram illustrating a client / server interaction.

Fig. 10 is a schematic view showing a device identification in a master / slave arrangement;

FIG. 11 is a Nassi-Schneiderman diagram;

Fig. 12 is a schematic tree diagram of a method of device discovery;

FIG. 13 is a schematic representation ask a master / slave arrangement for explaining a Konfigurationsab;

FIG. 14 is a schematic block diagram of a Gerätver administration in the proxy server;

Figure 15 is a schematic block diagram for explaining the functional integration of an XSL parser in the proxy server. (XSL - "Extended Stylesheet Langua ge"), and

Fig. 16 is a schematic block diagram for explaining an XSLT processor (XSLT - "Extended Stylesheet Language Transformations").

In the following, a usable in connection with field devices so-called observation and operating system (BuB system) be wrote.

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 facilities N1. , , NN, preferably 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, information, for example measurement and / or status data, is obtained from the field devices FG1. , , FGN recorded and sent to user facilities N1. , , NN transmitted to a user of the user devices N1. , , NN about the operating state of the field devices FG1. , , To inform FGN. On the other hand, the BuB system is used to record operator input or control inputs with the help of the user devices N1. , , NN and to convert 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-technical 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 home page in the form of HTML data (HTML - "HyperText Markup Langua ge"), which provides an overview of the field devices FG1 that can be reached in the device network. , , FGN shows (see Fig. 2); the homepage can be accessed using a standard browser in the user facilities N1. , , NN are shown.

Referring to FIG. 1, the field devices FG1. , , FGN only permitted with the star coupler 3 and a modem 4 connected to it. In this case, the field devices are FG1. , , FGN 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. As a protocol for access to the field devices FG1. , , FGN uses an IP protocol (IP - "Internet Protocol") over a PPP link layer.

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 .

User devices connected to the local network have N1 on the company intranet. , , NN access to a modem 5 , which can be connected to the modem 4 of the device network via a telecommunications network 6 , for example a telephone network based on an ISDN or a mobile radio network. Is in the user facilities N1. , , NN each set up a dial-up connection (DFÜ - remote data transmission) can be set up by the user equipment N1. , , NN each have access to the field devices FG1. , , FGN done. Now the proxy server 1 from the user devices N1. , , NN addressed, can from any of the user facilities connected to the company intranet N1. , , NN to the field devices FG1. , , FGN can be accessed for monitoring and operation. The proxy server 1 "mirrors" all field devices FG1. , , FGN, ie information about the field devices FG1. , , FGN, on 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. These are around data that is only transmitted once to the proxy server 1 and is then stored there in a file memory for later calls by the user devices N1 ... NN The RPC protocol, which is also an IP-based protocol, is used for the transmission The dynamic data are, in particular, measured values and / or event lists recorded in the field devices FG1... FGN, relating to information about events in the field devices FG1... FGN.

The HTTP protocol allows the user devices N1. , , NN access to 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 whose help in the browser device of the retrieving user device, a representation of the field device can be generated, as is shown for example in Fig. 3. The retrieval of the HTML data for generating the representation according to FIG. 3 can be triggered by the user using a selection of one of the field devices shown in the overview in FIG. 2, 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 (cf. left-hand side in FIG. 3): field device family (eg SIPROTEC4), field device type and field device type 21 , an operating tree 22 , the version of the BuB -Tools 23 (version and date) and details of connection 24 with the field device (MLFB - "machine-readable manufacturing designation", BF number, connection status and IP address). The HTML page 25 assigned to a link or branch in the operating tree 22 is also shown on the surface. Depending on the link selected in the operating tree 22 , the associated HTML page 25 is displayed on the surface 20 of the browser device.

The field devices FG1. , , FGN-stored HTML pages, ie also the HTML page 25 used to generate the representation shown in FIG. 3, can include Java code that the browser device of the respective user device N1. , , NN causes parallel to the existing HTTP connection to display the field devices FG1. , , FGN loaded HTML page another connection with the field devices FG1. , , To build 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 the display in the user facilities N1. , , NN to be transmitted 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 representation for a more detailed explanation of the retrieval of the information within the BuB system from the field devices FG1. , , FGN in the user facilities N1. , , NN.

According to FIG. 4 is on a user personal computer 30, an exemplary embodiment of the user facilities N1. , , NN represents, a browser device 31 installed. 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 telecommunication network 6 . The field device 33 has an HTTP server 34 . In the field device 33 , HTML pages 35 are stored, which comprise 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 tailored to the field device 33 and can be called up by the user personal computer 30 by means of an HTTP download from the HTTP server 34 of the field device 33 . The request for the HTML pages 35 from the field device 33 can be triggered by entering a URL (URL - "Uni form Resource Locator") in the browser device 31 or by means of a reference from another HTML page ("Link") become. 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 the raw data 36 available in the field device 33 . 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. These data formats can then be used by the program, for example for displaying the screen in connection with analysis options. 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 from the field device 33 and thus also to access the raw data 36 of the field device 33 referenced herein. According to FIG. 5, the HTML page (s) 35 is (are) requested by the user personal computer 30 for this purpose 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 with suitable programs. To execute the RPC protocol, the field device 33 additionally comprises an RPC server 34 a.

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 file with the raw data 36 of the field device 33 is referenced with the parameter “SRC”. 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 could look as follows:

<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 . For this there are different procedures depending on the operating system used of the user personal computer 30 and the browser device 31 used . 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 program for raw data processing started by the browser device 31 takes over the conversion of the downloaded raw data 36 . The program for raw data processing can be implemented as a browser plug-in, as an Active X 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 updating 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). With the help of the additional RPC protocol a separation of the in the user devices N1. , , NN (or the user personal computer 30 ) to be presented information about the field device (s) FG1. , , FGN or 33 in static and dynamic information. The static information is transmitted using the HTTP standard protocol, while the dynamic, ie changeable, data is transmitted via the more effective RPC protocol. The effort that would be incurred when establishing 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 generally 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 remote procedures are called (RPC), a local program calls a procedure on a remote system. 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 avoids that the application programs (client and server) focus on details such as B. conversion EBCDIC <--- <ASCII, number conversion, socket, session etc., must take care of. One goal of RPC is to simplify the implementation of distributed applications. UDP ("User Defined Protocol") is used by some applications that 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. Instead of putting the data in a TCP envelope and then in the IP envelope, they now migrate to 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 few data are to be transferred quickly. In application programs there is an exchange of short questions and answers between client and server. In this case, the effort incurred by establishing / clearing 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 equipment N1. , , NN in the company intranet using different protocols is optimized by the provision and specific training of the proxy server 1 described in detail later.

The use of the RPC protocol for calling up 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 the browser 31 (cf. FIG. 4) calls an RPC interface 101 . This client process 100 can e.g. B. be a Java applet embedded in an HTML page. The RPC interface 101 has the task of specifying the subroutine jump. 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 by 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 34 a.
• 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) The interface 104 packs the return parameters and then transports the data to the network routines.
• h) The network routines transport the data via network-dependent calls to the client process 100 .
• 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 passed back 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 in the RPC interface and in the Network routines remains hidden. This avoids that the application programs (client and server) are De tails such as B. conversion EBCDIC <--- <ASCII, number conversion,  Socket, session etc. A before part of the use of the RPC protocol for the dynamic data is to simplify the implementation of distributed applications applications.

Operating the field devices

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

The field device 33 contains a storage device 35 a, 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 trigger certain operating functions of the field device 33 with the aid of a mouse click on the screen of the user personal computer 30 . The transmission of the user negotiation to the field device 33 takes place 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 33 and, on the other hand, reads back reactions of 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, for. B. Keyboard buffer, display buffer, LED status.

As part of the operation by the user, there is an exchange of short inquiries and answers within the framework of a client-server relationship between the user personal computer 30 and the field device 33 . In this case, the effort that arises in connection with the setup / teardown and the monitoring of the HTTP connection between the user personal computer 30 and the field device 33 would exceed the effort that arises when the data is sent and received again according to 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. Methods for compressing data are used to reduce the amount of data exchanged (eg display content) between the user personal computer 30 and the field device 33 .

Internet protocols, such as TCP / IP and HTTP, do not offer any security mechanisms. Additional protocols are necessary 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) a protected connection with ei another network (e.g. Internet).
• - The field device 33 is set in the delivery state in such a way that keys which allow 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.
• - The parameterization of the field device 33 in the front view emulation is possible with knowledge of the passwords as on the field device 33 if the lock of the keys required for this is released.
• - Security-relevant actions on the field device 33 (switching, controlling, deleting buffers,...) Are protected by authentication protocols, z. B. 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 procedure, a message of any length is formed into 128-bit information, the so-called "message digest", which is appended to the original message. The receiver (field device 33 ) compares the "Message Di gest" with that determined by the field device 33 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. The recording of security-relevant logs and a later repetition of these recorded logs is thus ineffective.

proxy server

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, the proxy server is 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, both of which are provided by the field devices FG1. , , FGN protocols used (HTTP, RPC) are supported.

A major advantage that when using the proxy vers 1 over the coupling of the device network to the company intranet using a router or, if there is no WAN connection (WAN - "Wide Area Network") between the device network and the intranet, one Direct coupling of the device network segment via a hub or a switch means using so-called "caching".

The principle underlying this process ("caching") is generally referred to below without reference to the above called figures, briefly described.

If a client makes a request for an object to a server organization, this request initially runs through a so called proxy facility. The proxy device looks according to whether the object in question is already in a local Memory (cache) of the proxy device, which is in is usually formed on a hard disk. Here found that the object was not locally in memory the proxy device forwards the request to ner actual target server setup. From there, the Proxy sets up the object and stores a copy of the Ob project for further requests for this object in the local Memory before the proxy device sends the object to the passes on questioning client. However, if the object is in the loka If the memory of the proxy device is found, the To do not ask the client to the target server facility provided, but the client gets the desired object transmitted directly from the proxy device. requirement for optimal execution of the described method is a sufficiently large memory area in the proxy device, d. H. in the order of several hundred MB to several ren GByte. Otherwise the local memory runs in the proxy Setup over and there has to be a "garbage collector" (a so-called  Cleaning service) are started, the obsolete ob filters out objects from memory to make room for new ones To create objects.

Advantages of the described method ("caching") are: one Improved performance (faster data transfer port as external); a saving of external bandwidth (more space for other services remains free); a woman response times; Relief of the target server setup; when transporting the ob There are no objects from the proxy device to the client or lower transmission costs, and the hit rates in The proxy facility's local storage may vary depending on usage be very high.

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 training, which will be described in detail later, also has the advantages mentioned below.

The use of the proxy server 1 (cf. FIG. 1) results in significant speed advantages when accessing the device network. The proxy server 1 includes a file memory or file cache optimized for use in the BuB system, all of which are from the field devices FG1. , , FGN retrieved files with static data in proxy server 1 . If such a file is accessed for the first time, then this file must be directly from one of the field devices FG1. , , FGN can be fetched. 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 FG1 field devices. , , FGN is, there are significant speed advantages when accessing the device network, since during operation only the dynamic data, which is significantly smaller than the HTML pages and the Java archives, is 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 from the company intranet only those from a browser on the user facilities N1. , , NN to the field devices FG1. , , FGN generated requirements are transferred. In the opposite direction, only those from the field devices FG1. , , FGN generated responses transmitted. 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 can occur due to cross communication between the field devices FG1. , , FGN does not increase the network load on the company intranet.

The use of the RPC protocol by means of the proxy server 1 has the advantage that it is ensured that the field devices FG1 can be accessed. , , FGN remains limited to the company intranet connected to Proxy Server 1 . A company intranet is usually connected to the Internet via an HTTP gateway. This gateway assumes a firewall function here (see FIG. 7) by blocking the transmission of the RPC protocol. As a result, outside of the company intranet, the data of the field devices FG1 can no longer be accessed. , , FGN can be accessed because all dynamic data of the field devices FG1. , , FGN are transmitted over the RPC protocol.

The proxy server 1 enables a wide range of functions, which with the previously customary direct access to the field devices FG1. , , FGN are not available. 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 the all connected field devices FG1. , , FGN reachable are.
• - The connected field devices FG1. , , FGN are automa table addressed and recognized; Representation of these field devices te FG1. , , FGN in the homepage as the start page on the Nut deconstruct N1. , , NN for direct device access.
• - There is access via device names of the field devices FG1. , , FGN enables; this is versus access over the IP address more user-friendly.
• - The proxy server 1 can by means of a browser on the user devices N1. , , NN can be configured (e-mail addresses, telephone numbers, device names,...)
• - The proxy server 1 defines the possible access routes ("firewall function").
• - The proxy server 1 can receive data from the field devices FG1. , , Cache the FGN. This function is suitable for. B. for logging the accident information or the operating measured values. This data is stored internally in an XML database (XML - "Extended Markup Language").
• - The proxy server can from the field devices FG1. , , Provide FGN with data transmitted via the RPC protocol in XML format. In this way, for example, user-specific expansions of the representations available in the proxy server 1 can be carried out. For this purpose, an XSL parser (XSL - "Extended Stylesheet Language") integrated in the proxy server 1 is available.
• - Thanks to the filters on the XML database that can be implemented using the XSL parser, the proxy server 1 can also be used as a client for other 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 used by means of a POP3 client (POP3 - "Post Office Protocol Stepping 3"), such as. B. 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 .

In the following the training of the proxy server 1 will be described in more detail.

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 Funktionsblö blocks of the proxy server 1 in a block diagram.

According to Fig. 7, each of the field devices FG1. , , FGN a respective HTTP server HS1. , , HSN, which correspond to the respective HTTP server 34 (see FIG. 4) and are connected to a star coupler 39 . The proxy server 1 also has an HTTP server 40 . In the following, the mode of operation of the proxy server 1 will be described 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 in the device network comprising the field devices, which can comprise a substation or several substations. If one of the user devices N1. , , NN addressed via the associated, local IP address as a server, 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 uses a file filter 42 to contact a cache manager 43 . The file filter 42 typically forwards the request to the cache manager 43 . Only certain requirements are recognized based on the requested file type and passed on to their 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 the proxy server 1 nor in the file cache 45 , the file request is forwarded to an HTTP client 46 . This establishes a connection to the HTTP server HS1,... Via a further TCP / IP stack 47 . , , or HSN of the addressed field device FG1,. , , or FGN in the device network in order to obtain the requested file from there.

As a connection to the device network, a modem connection with the PPP protocol is preferably used (cf. FIG. 1). However, since the proxy server 1 has several connections to different field devices FG1 via this modem connection. , , FGN can hold, an arbitration of this modem connection is required, since the PPP protocol can only manage a point-to-point connection. A block slot protocol 48 is used for this . 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 all field devices FG1 active in the device network. , , Recognize FGN. 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 via the HTTP server 40 in the browser of a user device N1, connected to the proxy server 1 . , , or NN loaded HTML page Java code that establishes a parallel UDP connection (UDP - "User Defined Protocol") for the RPC protocol, then an RPC server 51 is removed from the company intranet in this way addressed. Since the RPC protocol is based on the standardized UDP / IP protocol for performance reasons, a connection management 52 must be included here in the proxy server 1 , since the UDP protocol does not operate in a connection-oriented manner. The connection management 52 ensures that for each user device N1. , , NN from the company intranet, a separate communication port is reserved for an RPC client 53 of the proxy server 1 in the device network. The RPC requests from the company intranet are then forwarded directly to the device network via the RPC client 53 of the proxy server 1 .

The answers of the field devices FG1. , , FGNs on RPC requests are forwarded to the RPC server 51 . This gives the answer of the respective field device FG1,. , , or FGN to the user facilities via the company intranet. In parallel, 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 transformation instructions required for this must be stored locally in proxy server 1 as an XSL script file. In order to trigger such a transformation process, an * .XML file must be requested from the HTTP server 40 . Such a request is filtered out by the file filter 42 connected to the HTTP server 40 from the normal access path to the cache administration 43 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 dynamically from an XSL template with the current data of the field devices FG1. , , FGN generated 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 function 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 configured 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 on which Internet content - data - is available). Port 80 is defined as the connection point, ie an HTTP server listens to new client connections at this port. Alternatively, the vast majority of HTTP server software can also be instructed via a corresponding configuration dialog 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. The 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 type of data this can understand. So there must be one for each request Communication between the HTTP client and the HTTP server about how the data should be transferred. This communication creates a so-called surplus or Overhead; HTTP is therefore also considered stateless Protocol ("stateless protocol") called because the Verbin does not go through several phases, from logging in via Data exchange through to logging out through the HTTP client. On the one hand, this facilitates the development of HTTP Client / HTTP server software, but is in terms of Use of the available bandwidth is not very ef fizient.

The HTTP protocol is used to access sources in the Obtain URL format (URL - "Uniform Resource Locator"). The HTTP client, usually a web browser on the computer of the internet user. He requests an HTML page and gene It then creates a sequence of requests for the file refer to this HTML page. After that, the user probably a link in the requested HTML page click, and the HTTP client sends a request regarding of the HTML pages linked to this link, to the same or another HTTP server. This further communication Connections no longer have any information about one established connection. This works with simple ones Client / server environments. With more extensive communication However, this way of working can become a problem because for every little amount of data that is transmitted that is, this excess ("overhead") is incurred, which the Efficiency reduces.  

Fig. 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". A TCP connection to the HTTP server 61 is opened 62 from the HTTP client side 60 , that is to say generally from the Internet browser. 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 which, in addition to 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 again. This process can be repeated any number of times.

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"
  • - Specify 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 (pictures, sound...)
• 4. "close" (disconnection)
  • - Usually from the HTTP server after data transfer
  • - In special cases from the HTTP client (transmission time, storage space)

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 host). The last field specifies the protocol version of the HTTP client 60 used , for example HTTP / 1.0. The "request header fields" transfer additional information about the request and the HTTP client 60 . The fields are used as a kind 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 information packets 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 that is present 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. Since the file system of the field devices FG1. , , However, FGN can only be loaded as a unit in the form of a KON file (converted file format that can be loaded into the user devices N1... NN files), such a comparison is not necessary for every file. The dynamics in the field devices FG1 are an exception here. , , FGN generated files, for example the file MLFB.TXT (MLFB machine-readable manufacturer name), which are not from the file system of the field devices FG1. , , FGN read out, but from that in the respective field device FG1,. , , or FGN set MLFB is generated.

An entry in a file "noca che.txt" serves as a distinguishing feature between these two file forms, namely the static files and the files with dynamic data. All dynamically in the field devices FG1. , , FGN generated files must be listed in this file. Static files are generated by the HTTP server HS1. , , HSN of the field devices 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
Do, Oct 24, 2000 7:50:00 AM 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) arbitration of the star coupler arrangement. The device detection is used for the automatic detection of all field devices FG1 connected to the star coupler 39 . , , FGN. The arbitration must collide datagrams of different field devices FG1. , , FGN on the communication link between the Pro xyserver 1 and the individual field devices FG1. , , Prevent FGN.

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

device Discovery

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

Fig. 10 is a master-slave arrangement is shown with a star coupler for explanation of the device discovery.

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 from a slave S1. , , SN occupies which the field devices FG1. , , FGN according to FIG. 1 correspond. The master 70 could be any address of the connected slaves S1. , , Query SN and, in response to this request, find slave S1,. , , or SN in the list of devices known to master 70 . However, this procedure can no longer be carried out with an address range of 32 bits. Here 2 ^{^} 32 queries would be required. However, this number can no longer be carried out, since the time required for this query would exceed the lifespan of the system. In order to be able to automatically recognize the devices still 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, there is a simultaneous response from several of the slaves S1. , , In this case, SN inevitably leads to a collision. 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.

Is the address space of the addressable slaves S1. , , SN 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 area has been received, the mask is reduced by one bit and the next fixed bit is tested with two inquiries as to whether there are slaves in the now smaller address area. If there is an answer to the request for the now smaller address area, then 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 is S1. , , SN clearly identified on the bus. If answers to both states of the bit just 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 can respond to the request, no collisions can occur with the last request, and the response telegram from the slaves to be detected can provide spontaneous information included 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, for an address space from 0 to 15. It is assumed that the devices with the addresses 3, 4 and 7 in the Arrangement. The most significant bit is started. So on the one hand the address space 0 to 7 and in a second query the address space 8 to 15 is tested with a 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. The 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 S1. , , Sn or the field devices FG1. , , FGN connected to 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 0x8D8D8000 thus 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 flowchart of the method as Nassi- Schneidersmann 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 the 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 on a request datagram sent out by the master 70 . , , Answer SN at the same time. The fact that in the star coupler 71 all of the slaves S1. , , SN received signals are linked via a logical OR gate and this sum signal is forwarded to the master 70 , it can be ensured that in the master 70 a response from one of the slaves S1. , , SN is recognized in any case. If the response datagrams of several of the slaves S1. , , SN overlap in time, an incorrect datagram is received in master 70 . This case is also recognized as the answer.

By specifying a maximum response time for slaves S1. , , SN on 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 range. 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 with a complete resolution of the address in the request of the master 70 (ie the mask becomes empty) only one of the slaves S1. , , In this case, no collision can occur if SN is allowed to respond. In this case, the error protection of the received datagram can be used to rule out 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 Resolution of the mask is detected.

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.84.0; Mask: 255.255.255.192;
Test: 141.141.84.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, wherein the bold outlined fields characterize the queries made by one or more slaves S1. , , SN or field devices were answered.

Broadcast service

For connecting the proxy server 1 to the field devices FG1. , , FGN can use an IP-based network instead of the simple architecture with star coupler 39 . In this case, arbitration of this network by 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 uses a broadcast service to configure the observation and operating system itself.

In both cases, detection of the connected field devices FG1. , , FGN, d. H. in the embodiment with a star coupler order and when using a network, especially one LANs, the detection when commissioning the observer control and operating system automatically executed and carried out without prior parameterization of the com components.  

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 0 × D000 reserved. A free port is dynamically selected on the client side. Through the use of the standard UDP / IP protocol, interfaces to common operating systems such as e.g. B. MS Windows or Linux. This enables the proxy server 1 to 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 of 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 187 ff.

All field devices are then configured answer the master's question with a UDP telegram, which one contains the most important configuration data of the field device. Now that everyone is connected to the IP-based network In theory, field devices want answers at the same time First there are some collisions on the bus used by the CSMA / CD process (CSAM - "carrier sense, multiple access / collision detect "). One Description of this process is also in Karanjit S. Siyan: "Inside TCP / IP", Third Edition, New Riders Publishing,  Indianapolis, 1997, ISBN 1-56205-714-6, page 97 ff the. The UDP response telegrams of all active field devices that of the querying master within a certain Time to arrive. Thus the interrogator is able to fix determine how many and which field devices are in the network and can then find further information from the field devices information via the HTTP protocol or other IP-based Request logs.

The broadcast service also has the role of a spon tan event occurring in one of the field devices in the IP based network to the participants of the broadcast service to distribute. Because the field devices have no information have which master is responsible for this signal and on the other hand it may be possible that the IP based network multiple masters with distributed tasks e exist, the event telegram is broadcast to everyone Network participants sent. The masters can use this signal depending on the event type and sender ignore or take an action trigger which via another protocol, e.g. B. HTTP, too retrieves additional information from the field device. This Ab call additional information to the person sending the event Field device by the responsible master also serves as Acknowledgment of receipt from the master. Will an event telegram not confirmed, it will be on a regular basis for so long den (for example about 10 s or with a logarithmic growing time) repeated until confirmation from one Master takes place.

Fig. 13 shows a schematic diagram for explaining the procedure 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 is a specific matic block diagram showing the connection of the device manager 49 in the proxy server 1.

The device manager 49 provides the cache manager 43 and the XML database 50 with information about the field devices FG1 known in the device network. , , FGN available. For this purpose, the device management 49 obtains its information about the connected field devices FG1. , , FGN from the procedure running in the context of slot protocol 48 . In this way, the IP addresses of the connected field devices FG1. , , FGN provided. The device management 49 is from the slot protocol 48 with the information about the detected field devices FG1. , , FGN supplied. The slot protocol 48 only provides the device management 49 with the IP addresses of the recognized field devices FG1. , , FGN. All further information about the FG1 field devices. , , FGN, which are to be provided by the device management 49 in the proxy server 1 , are downloaded from the field devices FG1 with the downloading of HTTP data in specified files. , , FGN procured. Device management 49 uses the known IP addresses of all recognized field devices FG1. , , FGN the cache manager 43 the following information about the field devices FG1. , , FGN 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. This means that when a file is requested from a specific one of the field devices FG1. , , FGN can be decided on the basis of this information as to whether the file present in file cache 45 is identical to the file available in the field device, without reading the file header of the requested file from the specific field device. It is only necessary to compare the version information for the file in the file cache 45 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 in the form of an XML file from the field devices FG1. , , FGN loaded. The following table shows an overview of the contents of this file:

All of this information is stored in a "DevData.xml" file. The device manager 49 initiates an HTTP download of this file if one of the field devices FG1. , , FGN from slot protocol 48 was found. All other files are only loaded by the device management 49 from 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 into the internal format of the proxy server 1 in the proxy server 1 after downloading using the XSL parser 54 and then entered in the XML database 50 of the proxy server 1 .

XSL parser

The XSL parser 54 (cf. 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 proxy server 1 using an admin page.

Fig. 15 shows the integration of the XSL parser 54 in the Pro xyserver. 1

An XML file is created by the user devices N1 via the HTTP server 40 . , , NN requested from the intranet, then 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 matching process is necessary because a lot of data stored in the XML database 50, such as e.g. 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, then it is requested again by the connection manager 52 from the RPC client 53 from the device, updated in the XML database 50 and forwarded to the XSL parser 54 .

The device management 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 display of the current FG1 field devices. , , FGN received data from the XML database 50 . Each XSL script specifies transformation rules that determine the way in which certain data from the XML database 50 in the form of HTML pages in the user devices N1. , , NN are to be displayed. One of the basic principles of XML is the separation of content and presentation. An XML document only contains "content"; his 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 form that can be presented according to a style sheet, or the style sheet guides the display mechanism in how the individual elements of the document are to be presented. These two basic processes can be varied in different ways:

CSS stylesheet + XML document → XML-capable 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 according to the transformation apply an XSL stylesheet from an XSL transformer transforms an (X) HTML document that is then Browser can be displayed.

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 Xview.XSL belonging to the requested 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 with the help of the user facilities N1. , , NN displayed information pass through an XSLT processor when it is requested, it is expedient, as already described, to check the validity of the information requested here with the aid of the XML front end RPC cache 57 and to check the result for an update mechanism use. For this purpose, the XSLT parser must be manipulated in such a way 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 then the parsing process is started again, whereby only those data are updated that are currently in any form to a user with the help of one or more of the user devices N1. , , NN are displayed. 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 number of field devices FG1. , , FGN and the proxy server 1 transmitted data, because on the one hand only on request and on the other hand only the data required for the respective display are fetched.

Claims (8)

1. A method for detecting a plurality of field devices (FG1,..., FGN) which are connected to a central device in a device configuration, in particular a star coupler configuration, the plurality of field devices (FG1,..., FGN ) can be electronically addressed by the central device in the device configuration using a respective electronic address from a total address range, the method comprising the following method steps:

• a) electronic interrogation of half of an address interrogation area with the aid of a single, electronic inquiry from the central device to the field devices (FG1,..., FGN);
• b) electronically querying a remaining half of the address query area with the aid of a further individual, electronic query from the central device to the field devices (FG1,..., FGN);
• c) detecting an electronic response from at least one of the field devices (FG1,..., FGN) from half of the address query range to the individual electronic request and / or another electronic response from at least one other of the field devices (FG1,... , FGN) from the remaining half of the address query area to the further individual, electronic request using the central device;
• d) repeating steps a), b) and c) n times (n ≧ 1) for half of the address range, if a step half of the address range is detected in step c) and / or for the remaining half the address query area when a response from the remaining half of the address query area is detected in method step c); and
• e) aborting the n-times repetition after method step d) if the address query area comprises exactly one electronic address from the total address area;

wherein the address query area for electronic queries in accordance with method steps a) and b) of the total address range and for a repetition of method steps a) and b) in accordance with method step d) of half of the address query area and / or the remaining half of the address query area of a previous one Repetition is formed. 2. The method according to claim 1, characterized in that the respective electronic address of the field devices (FG1, , , ., FGN) is a binary address, so half of the Address range and the remaining half of the Address range by setting one Measurement bits are formed to a value of 0 or 1. 3. The method according to claim 2, characterized in that when querying electronically according to the procedural step ten a) and b) each on the measurement bit and a bit mask the field devices (FG1,..., FGN) are transmitted. 4. The method according to claim 3, characterized in that the bit mask when repeating n times according to the procedure Step d) in successive repetitions is always shortened by one bit and repeated n times fetch is canceled if the bit mask has no bits includes more. 5. The method according to any one of the preceding claims, characterized in that the elect ronic replies and / or the other electronic replies  in the central device by means of an OR gate are processed electronically. 6. The method according to any one of the preceding claims, characterized in that electronic and / or other electronic responses are detected, which collide in time, such that they essentially at the same time on the central device received. 7. The method according to any one of the preceding claims, characterized in that capturing the electronic response from the little one at least one of the field devices (FG1,..., FGN) from half of the address query area and capturing the others electronic response from the at least one other of the field devices (FG1,..., FGN) from the remaining Half of the address query area using the central Device for a predetermined period of time after an ab send the appropriate electronic request be be limited. 8. Use of a method according to claims 1 to 7 in control / telecontrol systems of energy technology Attachments are used.