MONITORING DATA TRANSFER IN A CLIENT-SERVER-BASED DEVICE ACCESS SYSTEM

Description

[0001] The invention relates to a device access device for a client-server system comprising a server and a client, wherein the device access device can be used to access components of a fieldbus system. Furthermore, the invention relates to a server that can be connected to a fieldbus network and to an automation system comprising a server and a client. Furthermore, the invention relates to a method for monitoring data traffic between a server and a client of a client-server system, via which components of a fieldbus network can be accessed.

[0002] In automation technology, field devices are often used to record and / or influence process variables. Examples of such field devices include level measuring devices, mass flow meters, pressure and temperature measuring devices, etc., which act as sensors to record the corresponding process variables: level, flow, pressure, or temperature.

[0003] The parameterization, configuration, and status monitoring of the field devices in a fieldbus network are usually carried out using a device access device. The device access device comprises a framework application into which a number of drivers are integrated. The drivers can be used to access the components of the fieldbus network. When implementing device access units that can be used to access components of a field device network, there is often a need to implement the device access unit using a client-server structure. This enables, for example, the connection of mobile devices to a central server. The user can then, for example, parameterize and configure the field devices and other components of a fieldbus network on site. However, errors in the data transmission between server and client repeatedly occur in such systems.For example, newly established data connections are not terminated correctly, so that more and more system resources are used, which after some time leads to system failures.

[0004] DE 10 2010 040 055 A1 discloses a system which is designed to detect, report and, in certain cases, resolve general error conditions in the communication between a communication driver and a device driver or a gateway driver.

[0005] It is an object of the invention to provide a more reliable connection of a client to the server in a client-server based system for accessing components of a fieldbus network.

[0006] This object is achieved by the features specified in claims 1, 11, 12 and 13.

[0007] Advantageous further developments of the invention are specified in the subclaims.

[0008] The invention is explained in more detail below with reference to exemplary embodiments illustrated in the drawings. They show: Fig. 1 the structure of a fieldbus network and associated device access software with integrated drivers; Fig. 2 a two-way data transfer between a client, a server and a field device; Fig. 3 a detailed description of the connection of two clients to a server, with data exchange being handled via a communication proxy; and Fig. 4 the verification of the data transmission by the communication proxy, which compares the data transmission between client and server with a predefined set of rules. Figure 1shows a fieldbus network 100 comprising a plurality of field devices and gateway devices. A field access device 101 is located at the highest hierarchical level of the fieldbus network 100. The field access device 101 is connected to a field device 103 and a gateway device 104 via a Profibus segment 102. The Profibus segment 102 is coupled to a HART segment 105 via the gateway device 104, with the gateway device 104 being designed to convert data traffic from the Profibus protocol to the HART protocol and vice versa. The two HART field devices 106 and 107 are connected to the HART segment 105.

[0009] The parameterization, configuration, and condition monitoring of the field devices of a fieldbus network is performed using a frame application 109 installed on a host 108. The host 108 is connected to the fieldbus network 100 via an Ethernet connection 110. The frame application 109 provides access to the various components of the fieldbus network 100. In particular, the parameters of the various components of the fieldbus network 100 can be read, displayed, and modified from the frame application 109. In addition, the frame application 109 enables condition monitoring of the components of the fieldbus network 110. The data exchange required for these tasks is generally handled via so-called acyclic data traffic.

[0010] In order to correctly address the various components of the fieldbus network 100, the frame application 109 requires information about the properties and parameters of the field devices, gateways, remote I / Os, etc. of the fieldbus network 100. This information is usually provided by the manufacturers of the various devices in the form of device description files or device drivers. For the device description for acyclic data exchange, the Profibus-DP, Profibus-PA, Fieldbus Foundation, and HART fieldbus protocols use device descriptions according to the DTM (Device Type Manager), DD (Device Description), EDD (Enhanced Device Description), and FDI device package standards.In particular, the EDD and DTM standards specify not only device parameters, device functionality, and address space allocation, but also graphic features and graphical user interfaces designed to facilitate the parameterization and configuration of the respective field device. To generate these graphical interfaces, the EDD standard provides special graphical commands that are processed like an interpreter language.

[0011] In the FDT / DTM standard, the DTMs (Device Type Managers) are provided in the form of dynamically loadable libraries (DLLs) or executable files. A DTM also includes the aforementioned graphic features. The various DTMs for the various components of the fieldbus network are integrated into a common FDT framework application, where FDT stands for "Field Device Tool." This provides a common framework application into which the DTMs for different devices and from different manufacturers can be integrated.

[0012] In the coming years, the FDT standard will increasingly be supplemented by the FDI Device Packages standard and may later be replaced.

[0013] In addition to the previously discussed fieldbus protocols Profibus, Fieldbus Foundation, and HART, the so-called Industrial Ethernet protocols are gaining in importance. These include, among others, the fieldbus protocols EtherNet / IP, ProfiNet, and EtherCAT. The EtherNet / IP fieldbus protocol provides a device description file according to the EDS (Electronic Data Sheet) standard to describe both cyclic and acyclic data exchange.

[0014] In the example of Figure 1A frame application 109 is installed on the host 108, preferably a frame application of the FDT (Field Device Tool) standard, wherein different drivers for the various devices and components of the fieldbus network 100 can be integrated into the frame application. For example, different Device Type Managers (DTMs) from different manufacturers can be integrated into an FDT frame application. In addition to DTMs, other device description files can also be integrated into the frame application. The hierarchical structure of the field network 100 is replicated within the frame application 109 using drivers or device description files, wherein the arrangement of the drivers or device description files is a mirror image of the structure of the fieldbus network 100.To access the components of the fieldbus network 100, a number of different device DTMs, gateway DTMs, and communication DTMs can be integrated into an FDT frame application. At the top of the FDT topology is the communication DTM 111. The communication DTM 111 is assigned to the field access device 101 and communicates with it via the Ethernet connection 110. The communication DTM 111 represents, in a sense, the external interface of the device access software. All incoming and outgoing data traffic is routed via the communication DTM 111.

[0015] The device DTM 112 is located below the communication DTM 111 in the FDT topology and maps the functionality of the field device 103. A gateway DTM 113, which is assigned to the gateway 104, is also located at the level below the communication DTM 111. The gateway 104 can be parameterized and configured via the gateway DTM 113. Below the gateway DTM 113 in the FDT topology are two device DTMs 114 and 115, which can be used to access the field devices 106 and 107. In addition to the FDT / DTM standard, there are numerous alternative standards for device access software and the device drivers integrated therein.

[0016] For example, the FDT frame application can send a query to one of the field devices or to another component of the fieldbus network to request device specifications for the respective device. In response to such a query, the respective field device transmits, for example, the manufacturer ID, the device ID, the device version or device revision, the device profile or profile revision, the software version or software revision, the protocol version or command revision to the FDT frame application. Based on this information about the individual devices, the FDT frame application can graphically display the hierarchical structure of the fieldbus network 100 to the user, preferably in the form of a tree structure.

[0017] The framework application and the drivers integrated within it were originally intended to be installed on a stationary host computer, from which an automation network could be monitored. The central host computer was intended as a control center from which the user could retrieve, control, and modify parameters of the various field devices and fieldbus components. With the general availability of mobile devices such as tablets, laptops, personal digital assistants (PDAs), and smartphones, the need arose to connect such devices to the host computer in order to be able to query and modify parameters from any location in the automation network using the mobile device. It has proven very practical to be able to inspect the field devices of the automation network on site and also to check and modify the parameters of the field devices.To implement such mobile access to the parameterization and configuration of field devices and other components of the fieldbus network, it is necessary to install the device drivers for the addressed field device on the respective mobile device and to provide a data connection between the host computer and the mobile device.

[0018] In Figure 2 Such a system for accessing a fieldbus network is schematically illustrated. The access system comprises a server 200 and a client 201, which can exchange data with the server 200 via a data connection. The client 201 is preferably a mobile terminal. For example, the client 201 can have a data connection with the server 200 via a computer network 202, preferably a wireless computer network. Preferably, the client 201 is connected to the server 200 via an Ethernet connection.

[0019] An FDT frame application 203 is installed on the server 200. As with the Figure 1 In the conventional solution shown, at least one communication driver 204 is integrated into the FDT frame application 203, in particular a communication DTM and, if necessary, one or more gateway DTMs. The communication with the field devices and the other components of the fieldbus network is handled via the at least one communication driver 204. In contrast to the Figure 1In the solution shown, at least some of the device DTMs are not installed on the server 200, but rather outsourced to the client 201. For this purpose, an FDT framework application 205 is installed on the client 201, into which one or more device drivers 206 are integrated. To handle the communication between the server 200 and the client 201, a communication proxy 207 is provided on the server 200 side, which is in data communication with at least one communication stub 208 installed on the client 201 side. The at least one communication stub 208 is the communication driver of the client 201. The at least one communication stub 208 is provided on the client 201 side for handling the data exchange with the communication proxy 207.

[0020] At the Figure 2In the schematic representation shown, only one client 201 is provided. Alternatively, several clients can have a data connection with a central server 200, in which case at least one communication stub is installed on each of the clients, which has a data connection with the communication proxy 207 of the central server 200.

[0021] In the following, the case will be discussed in which a user sends a query to the associated field device 209 from one of the device drivers 206 on the client 201. This query is transmitted from the respective device driver 206 via the associated communication stub 208 according to arrow 210 to the communication proxy 207. There, the incoming data traffic is fed into the associated communication channel and transmitted according to arrows 211, 212 via the at least one communication driver 204 to the field device 209. As in Figure 2Illustrated by arrow 213, the field device 209 responds to the request and transmits the desired parameter according to arrows 214, 215 via the at least one communication driver 204 to the communication proxy 207. From there, the information is transmitted according to arrow 216 via the computer network 202 to the respective communication stub 208 and to the respective device driver 206, where the requested parameter is displayed to the user. For the device driver, the communication via the computer network 202 and the server 200 to the field device 209 is transparent.

[0022] In Figure 3The communication connections between a server 200, a first client 201, and a second client 300 are shown in detail, with the communication connections again being routed via the communication proxy 207 provided on the server 200. The FDT framework application 203 is installed on the server 200, into which a communication DTM 301 and a gateway DTM 302 are integrated, via which the fieldbus network can be accessed. The device DTMs for accessing the field devices or fieldbus components are not, or at least not all, integrated into the FDT framework application, but rather are relocated to the clients 201, 300. For the relocated device DTMs, placeholder DTMs 303, 304, 305 are inserted into the FDT topology on the server 200 side. These placeholder DTMs 303 to 305 serve as placeholders for the external device DTMs installed on clients 201, 300.The placeholder DTMs are used to uniquely identify the associated communication channels 306, 307, and 308, as well as the field devices or fieldbus components that can be reached via these communication channels 306 to 308. A so-called "tag" is used as a unique identifier to identify each fieldbus component and the associated communication channel. For example, a KKS identifier according to the power plant identification system can be used as a tag; however, the serial number and / or manufacturer number of a component of the fieldbus network can also be used as a tag. When defining the tag, it is important that each field device and each other component of the automation network is uniquely and distinguishably identified. There are various alternatives for defining the tags. The respective tag can be stored either in the field device or the fieldbus component.Alternatively, the respective tag can be assigned to the device and then stored in the device. Another option is to define and use the tag in the FDT topology.

[0023] In the example of Figure 3 The tags are used to identify the respective field device or fieldbus component, the associated device DTM and the communication channel, whereby the communication channel connects the field device or fieldbus component with the associated device DTM.

[0024] In the example of Figure 3The communication channel 306 is tagged with "Tag A" using the placeholder DTM 303, the communication channel 307 is tagged with "Tag B" using the placeholder DTM 304, and the communication channel 308 is tagged with "Tag C" using the placeholder DTM 305. The tags A, B, and C provided by the placeholder DTMs serve as flags for the communication proxy 207, indicating at which point the data received from the clients 201, 300 must be fed into the communication channels 306 to 308 on the server 200 side. The associated communication channel is selected according to the tag used to identify the received data traffic. The data is then transmitted to the associated field device or fieldbus component of the automation network via the selected communication channel.

[0025] Conversely, the tags A, B, and C provided by the placeholder DTMs indicate to the communication proxy 207 at which points the data traffic received from the field devices and other components of the automation network can be retrieved by the communication proxy 207 on the server 200 side. Both the field devices or fieldbus components of the automation network and the associated communication channels 306 to 308 are consistently labeled "Tag A," "Tag B," and "Tag C." The communication proxy 207 is then responsible for forwarding the respective data traffic via the communication medium 309 to one of the connected clients 201, 300.

[0026] In order to communicate with server 200, the IP address of server 200 must be known on the clients 201 and 300. Furthermore, server 200 provides clients 201 and 300 with a list of field devices and fieldbus components, which lists the assignment of the field devices or fieldbus components to the corresponding tags. Based on this list, the appropriate software components for communication with server 200 and the automation network can be installed on clients 201 and 300. The FDT frame application 205 is installed on client 201. A suitable device DTM 310 for accessing the field device or fieldbus component, which is labeled "Tag B," is installed in this FDT frame application 205.In addition, an associated communication stub 311 is installed, which handles communication with the communication proxy 207, so that this communication stub 311 assumes the function of a communication DTM for the client 201. Furthermore, another device DTM 312 is integrated into the FDT frame application 205, which is intended for accessing the field device or fieldbus component marked with "Tag A." A corresponding communication stub 313 is also installed for this device DTM 312.

[0027] Corresponding software components are also installed on the second client 300. A device DTM 315 for accessing the automation network component labeled "Tag C" is integrated into the FDT frame application 314 of the client 300, and an associated communication stub 316 is also provided.

[0028] Data exchange between the communication proxy 207 and the communication stubs 311, 313, 316 takes place via the communication medium 309. The communication medium 309 can be, for example, a computer network, such as Ethernet, wireless LAN, Internet, etc. The data connection between the communication proxy 207 and the communication stubs 311, 313, 316 is completely transparent to the user interacting with the respective device DTM 310, 312, 315. The user has the impression of being able to directly access the respective field device or fieldbus component of the automation network via their mobile device and the device DTM installed on it.

[0029] In Figure 4 the connection between the server 200, the communication proxy 207 and the client 300 is shown again, whereby the Figure 4The communication proxy 207 shown additionally comprises a test module for monitoring the data traffic between the server 200 and the client 300. On the Figure 4 The FDT framework application 203 is installed on the server 200 shown, into which the communication DTM 301 and the placeholder DTM 305 labeled "Tag C" are integrated. The FDT framework application 314 is installed on the client 300, into which the device DTM 315 for "Tag C" and the associated communication stub 316 are integrated. The data connection between the server-side communication channel 308 and the client-side device DTM 315 is established via the communication proxy 207, whereby the data can be exchanged between the server 200 and the client 300 via the communication medium 309.

[0030] On the communication proxy 207 side, the data exchange in both directions is handled by a communication module 400. The communication module 400 is responsible, among other things, for locating the appropriate tag in the FDT topology for requests directed from the client 300 to the server 200 in order to feed the data stream into the appropriate communication channel on the server 200 side. The communication module 400 is assigned the test module 401, which is designed to check incoming data from the server 200 or from the client 300. This check of the two-way data streams can be performed, in particular, taking into account the context of the data transmission in an FDT / DTM environment. When checking the data streams by the test module 401, a comparison can therefore also be made with the sequence provided for in the FDT / DTM standard and with the chronological sequence of the data transmission.The checking module 401 can, for example, be designed to compare incoming or outgoing communication against a predetermined set of rules 402 in order to detect disruptions and irregularities in the information exchange between client 300 and server 200.

[0031] In addition to analyzing incoming and outgoing data streams, test module 401 can also record and evaluate response times of the various system components. Long response times can indicate, for example, that disruptions are occurring during data transmission, triggering a retransmission of the respective data. Such connection disruptions can occur, for example, when electromagnetic interference is coupled into the connecting lines. Monitoring response times provides an important building block for monitoring data exchange.

[0032] All problems occurring during data transmission, as well as the associated parameters such as response and delay times, can be transmitted to an evaluation module 403, which logs these disruptions as a function of time. Furthermore, a statistical evaluation of the errors and disruptions that occur can be performed in order to identify hardware and software components frequently affected by disruptions.

[0033] In addition to error diagnosis and error logging, the test module 401 can be designed to correct occurring faults through appropriate measures. For example, the rule set 402 can specify suitable countermeasures for various possible faults to correct the respective fault. Such measures can include, for example, terminating a data connection, blocking faulty data streams, and restarting various hardware and software components.

[0034] The following describes some typical faults that can typically occur in a distributed FDT / DTM environment with server and client computers. For each described fault, appropriate countermeasures are discussed that can be used to respond to the respective fault. Client no longer responds

[0035] When this error occurs, the proxy does not receive any messages from the client for an extended period of time. The cause could be, for example, a failure of the connection network between the client and server, for example due to poor Wi-Fi reception quality. However, the cause could also be a software error on the client side or a failure of the client-side FDT framework application with the communication stub integrated into it. Another cause of this error could be that the user turns off their mobile device or moves their mobile device out of the range of the connection network. The occurrence of this error leads to an increasing number of open connections on the server side that are no longer served by the associated clients and therefore consume more and more of the server's resources over time.To detect this disruption, a timeout function can be provided on the communication proxy side, for example, which is set to a predefined value each time a message is received from the client. A timeout error occurs when the client does not respond within the predefined time period. As an alternative to this timer functionality, the client could also be pinged by the server at regular intervals; the regular pinging could then be used to detect a disruption on the client side. To monitor client activity, an alternative approach could be to monitor FDT data traffic. If such a client timeout occurs, the server automatically terminates the connection to the client. This way, the progressive consumption of resources by increasingly inactive connections can be prevented.To terminate the existing data connection to the client, the communication proxy can, for example, emulate the functionality of the device DTM installed on the client and feed the corresponding commands to terminate the connection into the communication with the server.

[0036] If the communication proxy 207 terminates an existing data connection, it may happen that the client contacts the server again after a long time and attempts to transmit data to the server via the already terminated data connection. The user then waits on their respective mobile device for a response from the server, which they do not receive because the data connection has already been terminated. To correctly detect this, the communication proxy could maintain a list of terminated data connections. The communication proxy would compare the request received from the client with this list, could then recognize that the request refers to a connection that has already been terminated, and could send the client a corresponding error message. This would have the advantage of informing the user about the connection timeout and giving them the opportunity to establish a new connection to the server via the client. Client sends data that does not match the current FDT state.

[0037] By analyzing the data received from the client, the communication proxy can draw conclusions about the type of message just received and, in particular, detect that the communication just received does not match the current status of the "FDT State Machine." The cause of this error could, for example, be a malfunction of the device DTM installed on the client. In this case, the communication proxy would block the obviously corrupted data and not forward it to the server. The communication proxy would thus assume a function comparable to a firewall. Furthermore, the communication proxy could be configured to issue a corresponding error message. Receiving corrupt data from the client

[0038] If the client transmits corrupted data to the communication proxy, this could be due, for example, to a software error in the device DTM. On the communication proxy side, the check module can detect corrupted data and block it so that it is not forwarded to the server. The check module also generates a corresponding error message. Using a tag that does not exist in the topology

[0039] In this error scenario, the client sends a request to the communication proxy to establish a connection to a specific tag. However, the communication proxy's verification module detects that the corresponding tag does not exist in the FDT topology. In this case, the client's request is blocked and not forwarded to the server. Furthermore, a corresponding error message is generated. Communication proxy does not receive feedback from the field device for a longer period of time

[0040] If the communication proxy receives no feedback from a field device or fieldbus component or from the communication drivers for an extended period of time, the cause could be, for example, a network failure, an error in the software components, in particular the FDT frame application and the communication drivers, an error on the field device side, or connection and grounding problems when connecting to the field device. A timer function can be provided on the communication proxy side that checks whether there is any feedback from the field device or fieldbus component within a specified period of time. If there is no feedback within the specified period of time, a timeout error has occurred. In this case, the communication proxy will terminate the data connection to the automation network via the communication drivers and issue an error message.In addition, the communication proxy can automatically take troubleshooting measures. For example, the communication proxy could initiate a restart of the field device or fieldbus component and / or a restart of software components, such as the FDT frame application, as well as one or more communication drivers. Communication proxy receives data from the communication drivers that does not match the current FDT state

[0041] The communication proxy's test module analyzes the data received from the communication drivers and checks whether this data matches the current state of the FDT state machine. If the received data does not match the current state, the communication proxy blocks the forwarding of the data to the client. In addition, the communication proxy can initiate further troubleshooting measures, such as disconnecting the connection, restarting the FDT frame application, etc. Receiving corrupt data from the communication drivers

[0042] The communication proxy's test module analyzes the data received from the communication drivers and detects that the data is corrupt. This can be caused by a fault in the field device, but connection and grounding problems can also be responsible for the corrupt data. Furthermore, the communication proxy may also receive corrupt data due to software components, particularly the FDT frame application and the communication drivers. The communication proxy blocks the corrupt data and does not forward it to the client. It is also possible, for example, that the communication proxy disconnects the connection and restarts various components to correct the error. For example, the test module could analyze the corrupt data and use this to determine which component of the fieldbus network caused the fault, and then restart that specific component.A sensible strategy could also be to first restart the field device, then detect whether the data is still corrupt, and then restart other components of the fieldbus network in the next step. Access to the wrong field device or fieldbus component

[0043] In this error, field device B is accessed instead of field device A, but superficially, it appears as if device A was accessed. This can be caused by a software error in a gateway DTM, in the communication DTM, or an error in the field access device. On the communication proxy side, this error can be detected by the fact that the serial number or device address in the transmitted data does not match the communication channel address. In this case, the communication proxy would not forward the received data to the client. In addition, the communication proxy could initiate a restart of the responsible system components. FDT frame application does not respond or only responds very slowly

[0044] A missing or non-existent response from the FDT framework application could be detected by the communication proxy through an increase in response times or the occurrence of a timeout. The communication proxy could then initiate a restart of the FDT framework application. System load on the computer is very high

[0045] A high system load can be caused, for example, by high memory consumption or high network load, and manifests itself in long response times that can be detected by the communication proxy. The communication proxy would alert the user to the high system load and, if necessary, suggest terminating individual processes. Failure of required system components

[0046] The failure of required components, such as the failure of the database server required by the FDT framework application, leads to timeout errors when responding to queries, which are detected by the communication proxy. The communication proxy could determine which component has failed based on the occurrence of the errors and initiate a restart of that component.

Claims

1. A device access device for a client-server system comprising a server (200) and a client (201, 300), wherein the device access device can be used to access components (209) of a fieldbus network, and wherein the device access device comprises: - a frame application (203) which installed on the server (200) and which is designed to exchange data with components (209) of the fieldbus network, a tag being used as a unique identifier to identify the respective component (209) of the fieldbus network and an associated communication channel; - a device driver (206, 310, 312, 315) that is installed on the client (201, 300), - a communication proxy (207) which installed on the server (200) and is designed to establish at least one data connection between the server (200) and the client (201, 300), wherein data can be transmitted via the at least one data connection between the device driver (206, 310, 312, 315) and a component (209) of the fieldbus network assigned to the device driver, wherein the communication proxy (207) is designed to monitor data traffic on the at least one data connection between the client (201, 300) and the server (200) and to detect errors in the data transmission, characterized by at least one of the following: - the communication proxy is designed to terminate the data connection in the event that a client in one of the data connections does not respond to requests or is inactive for at least a predetermined period of time; - the communication proxy is designed not to forward the request to the server in the event that the communication proxy receives a request from the client with a tag of an already terminated connection; - the communication proxy is designed to terminate the data connection in the event that a component of the field bus system does not respond to requests or is inactive for at least a predetermined period of time in one of the data connections; - the communication proxy is designed to restart at least one of the following for troubleshooting: the frame application on the server side, at least one communication driver on the server side, a field access device of the fieldbus network, a component of the fieldbus network; - the communication proxy is designed so that if the communication proxy receives corrupt data from the server's frame application, the received data is not forwarded to the client; - the communication proxy is designed so that if the communication proxy receives data from the server's frame application that does not correspond to the current status of the protocol flow in the frame application, the received data is not forwarded to the client; - the communication proxy is designed to initiate a restart of a respective component in the event that the communication proxy detects that one of the following components has crashed or is only responding with a delay: a component of the fieldbus network, a field access device of the fieldbus network, the frame application on the server, at least one communication driver on the server side, components required by the frame application, such as a database server.

2. Device access device according to claim 1, characterized in that the communication proxy is designed to compare the data transmission between client and server with a predetermined set of rules in order to detect errors.

3. Appliance access device according to claim 1 or claim 2, characterized by at least one of the following: - The communication proxy is designed to automatically initiate troubleshooting measures when errors are detected; - The communication proxy is designed to automatically initiate troubleshooting measures when errors are detected, depending on the error pattern.

4. Device access device according to any one of claims 1 to 3, characterized by at least one of the following: - The communication proxy is designed to monitor the data transfer between client and server, taking into account communication processes between the fieldbus network, frame application and device driver; - The frame application is an FDT frame application and the communication proxy is designed to monitor the data transfer between client and server, taking into account the processes in the standard FDT / DTM.

5. A device access device according to any one of claims 1 to 4, characterized by at least one of the following: - the communication proxy is designed to log detected errors; - the communication proxy includes a cache functionality that stores responses to earlier client requests and makes them available for later client requests; - The communication proxy is designed to create error statistics that show which components are prone to errors; - The communication proxy is designed to record response times from the fieldbus network and / or response times from the client, compare them with expected values and use them to derive information for fault diagnosis.

6. A device access device according to any one of claims 1 to 5, characterized by at least one of the following: - the communication proxy is designed not to forward data received from the client to the server if the data integrity is insufficient; - The communication proxy is designed to prevent data received from the fieldbus network from being forwarded to the client if the data integrity is poor.

7. Device access device according to any one of claims 1 to 6, characterized in that the communication proxy is designed to terminate data connections between server and client that are not used for a predetermined period of time.

8. Device access device according to one of claims 1 to 7, characterized in that the communication proxy is designed to monitor the data transmission and, depending on the respective error pattern, to initiate at least one of the following: - Terminating a data connection between client and server, - Non-forwarding and blocking of incorrect data, - Correcting a data stream, - Shutdown of a hardware or software component, - Restart a component of the fieldbus network, - Restart the server's frame application, - Restart of at least one of the communication drivers integrated in the frame application, - Restart a field access device of the fieldbus network.

9. Device access device according to one of claims 1 to 8, characterized in that a component of the fieldbus network, an associated communication channel and an associated device driver are identified with a unique tag that enables the fieldbus component, communication channel and device driver to be assigned to one another.

10. Device access device according to any one of claims 1 to 9, characterized by at least one of the following: - The communication proxy is designed to feed data traffic that the communication proxy receives from a device driver installed on the client side into an associated communication channel according to the tag of the data traffic; - the communication proxy is designed to forward data traffic that the communication proxy receives via the communication channels provided by the communication drivers to an associated device driver on the client side according to the tag of the data traffic, and / or characterized by at least one of the following: - the communication proxy is designed to establish at least one data connection between client and server via a computer network; - the communication proxy is designed to establish the at least one data connection between the client and the server via a computer network, wherein the computer network is at least one of the following: a wireless LAN, an Ethernet connection, an Internet connection; - The client is a mobile device; - the client is at least one of the following: a laptop, a tablet, a cell phone, a smartphone, a PDA and / or characterized by at least one of the following: Driver or user software components can be integrated into the frame application in accordance with one or more of the following standards: DTM, DD, EDD, EDS, FDI Device Packages; - The frame application is an FDT frame application and driver and user software components of the DTM standard can be integrated into the FDT frame application.

11. A server (200) connectable to a fieldbus network, wherein the server is adapted to maintain a data connection to a client (201, 300) and wherein the server (200) comprises: - a frame application (203) which is installed on the server (200) and is designed to exchange data with components (209) of the fieldbus network, a tag being used as a unique identifier to identify the respective component (209) of the fieldbus network and an associated communication channel; - a communication proxy (207) which is installed on the server (200) and is designed to establish at least one data connection between the server (200) and the client (201, 300), wherein data can be transmitted via the at least one data connection between a device driver (206, 310, 312, 315) installed on the client (201, 300) and a component (209) of the fieldbus network assigned to the device driver, wherein the communication proxy (207) is designed to monitor data traffic on the at least one data connection between the client (201, 300) and the server (200) and to detect errors in the data transmission, characterized by at least one of the following: - the communication proxy is designed to terminate the data connection in the event that a client does not respond to requests or is inactive for at least a predetermined period of time in one of the data connections; - the communication proxy is designed not to forward the request to the server in the event that the communication proxy receives a request from the client with a tag of an already terminated connection; - the communication proxy is designed to terminate the data connection in the event that a component of the fieldbus system does not respond to requests or is inactive for at least a predetermined period of time in one of the data connections; - the communication proxy is designed to restart at least one of the following for troubleshooting: the frame application on the server side, at least one communication driver on the server side, a field access device of the fieldbus network, a component of the fieldbus network; - the communication proxy is designed so that if the communication proxy receives corrupt data from the server's frame application, the received data is not forwarded to the client; - the communication proxy is designed so that if the communication proxy receives data from the server's frame application that does not correspond to the current status of the protocol flow in the frame application, the received data is not forwarded to the client; - the communication proxy is designed to initiate a restart of a respective component in the event that the communication proxy detects that one of the following components has crashed or is only responding with a delay: a component of the fieldbus network, a field access device of the fieldbus network, the frame application on the server, at least one communication driver on the server side, components required by the frame application, such as a database server.

12. An automation technology system which has: a server (200) according to claim 11; a client (201, 300), wherein the device driver (206, 310, 312, 315) is installed on the client (201, 300) and wherein an associated component (209) of the fieldbus network can be accessed from the client (201, 300) by means of the device driver (206, 310, 312, 315).

13. A method for monitoring the data traffic between a server (200) and a client (201, 300) of a client-server system, via which components (209) of a fieldbus network can be accessed, wherein a frame application (203) is installed on the server (200), which is designed to exchange data with components (209) of the fieldbus network, wherein a tag is used as a unique identifier to identify the respective component (209) of the fieldbus network and an associated communication channel, wherein a communication proxy (207) is installed on the server (200), which is designed to establish at least one data connection between the server (200) and the client (201, 300), wherein data can be transmitted via the at least one data connection between a device driver (206, 310, 312, 315) installed on the client (201, 300) and a component (209) of the fieldbus network assigned to the device driver, and wherein the method comprises: Monitoring a data traffic on the at least one data connection between the client (201, 300) and the server (200) by the communication proxy (207) and detecting errors in the data transmission, characterized by at least one of the following: - In the event that a client in one of the data connections does not respond to requests or is inactive for at least a predetermined period of time, the communication proxy terminates the data connection; - in the event that the communication proxy receives a request from the client with a tag of a connection that has already ended, the communication proxy does not forward the request to the server; - In the event that a component of the fieldbus system does not respond to requests or is inactive for at least a predetermined period of time in one of the data connections, the communication proxy terminates the data connection; - the communication proxy restarts at least one of the following for troubleshooting: the frame application on the server side, at least one communication driver on the server side, a field access device of the fieldbus network, a component of the fieldbus network; - In the event that the communication proxy receives corrupt data from the server's frame application, the communication proxy does not forward the received data to the client; - In the event that the communication proxy receives data from the server's frame application that does not correspond to the current status of the protocol flow in the frame application, the communication proxy does not forward the received data to the client; - the communication proxy initiates a restart of a respective component in the event that the communication proxy detects that one of the following components has crashed or is only responding with a delay: a component of the fieldbus network, a field access device of the fieldbus network, the frame application on the server, at least one communication driver on the server side, components required by the frame application, such as a database server.

14. Method according to claim 13, characterized by at least one of the following steps: - Synchronization of data traffic with a predefined set of rules by the communication proxy; - In the event of errors, the communication proxy initiates measures to rectify the error.