Monitoring unit and method for monitoring resources used by a driver of a device accessed by the device

Abstract

An equipment access device for accessing fieldbus components of a fieldbus system is described. The equipment access device is installed in a host or host environment and comprises a framework application and at least one driver bound into the framework application, which is designed to access at least one fieldbus component. Furthermore, the equipment access device comprises a monitoring unit, which is designed to record information about resources reserved by the driver and provided by an operating system of the host or host environment and to initiate at least one predetermined countermeasure upon detection of an abnormal increase in resources reserved by the driver over time.

Description

TECHNICAL FIELD

[0001] The invention relates to a device access apparatus for accessing fieldbus components of a fieldbus system. Furthermore, the invention relates to an automation system. Furthermore, the invention relates to a method for monitoring the operation of a device access apparatus. BACKGROUND

[0002] In automation technology, field devices are usually applied which serve for recording and / or influencing process variables. Examples of such field devices are level measuring devices, mass flow measuring devices, pressure and temperature measuring devices, etc., which record the respective process variables, level, flow, pressure and temperature as sensors.

[0003] For accessing fieldbus components of a fieldbus system, a large number of drivers are required which are placed in a framework application. These drivers are usually provided by the manufacturers of the fieldbus components. It has been found that the drivers provided by the manufacturers have different software qualities and can cause problems during operation which can lead to a system crash. SUMMARY

[0004] TECHNICAL PROBLEM

[0005] It is an object of the invention to be able to operate a device access apparatus durably.

[0006] This object is achieved by the features set forth in claims 1, 14 and 15.

[0007] Advantageous further developments of the invention are set forth in the dependent claims.

[0008] TECHNICAL SOLUTION

[0009] The device access apparatus corresponding to the form of the embodiment of the invention serves for accessing fieldbus components of a fieldbus system. The device access apparatus is installed in a host or host environment and comprises a framework application and at least one driver bound into the framework application which is designed to access at least one fieldbus component. The device access apparatus comprises a monitoring unit which is designed to record information about resources reserved by the driver and provided by an operating system of the host or host environment and to initiate at least one predetermined countermeasure upon detecting an abnormal increase over time of the resources reserved by the driver.

[0010] Generally, a plurality of different drivers is bound in a framework application, wherein the fieldbus components of the fieldbus system can be accessed by means of these drivers. By means of these drivers, the fieldbus components can be configured and parameterized. Furthermore, for example, a monitoring of the device status is possible. In the normal case, a dedicated driver is provided for each fieldbus component of the fieldbus system, which is generally provided by the manufacturer of the fieldbus component. This leads to the fact that generally drivers from different manufacturers are bound to the framework application. It has been found that not all drivers delivered by the manufacturers of the fieldbus components meet the usual programming quality standards. It has been found that problems occur in particular when the drivers reserve resources provided by the operating system and do not release these resources after their use. The resources required by the drivers can be, for example, memory space, handles, threads or network connections and other resources provided by the operating system of the host or host environment. When such resources are not released after their use, an abnormal increase of the resources required by the drivers occurs. The abnormal increase means in particular an increase of the reserved resources due to, for example, neglecting the usual programming standards. This can lead to a performance loss, in particular a slowing down of the operation of the device access apparatus. Furthermore, the constantly increasing resource requirement can also lead to a crash of the operating system of the host or host environment.

[0011] In order to detect such problems at an early stage, a monitoring unit is provided in the device access apparatus, which monitors the resources required by the drivers. For this purpose, the monitoring unit can be designed to retrieve and track over time parameters reflecting the resource reservation, for example, from the operating system of the host or host environment. When the monitoring unit detects an abnormal increase of the resources required by the drivers, the monitoring unit can initiate appropriate countermeasures. For example, the monitoring unit can inform the user about the problem, contact a support organization, such as a support team, initiate a reinstallation of the drivers, for example, an updated version of the drivers, initiate a restart of the host or host environment, perform a memory dump, etc. The countermeasures initiated by the monitoring unit can prevent a performance loss of the device access apparatus as well as a system crash. This increases the acceptance of the customers. Furthermore, poorly programmed drivers can be detected and their manufacturers can be prompted to eliminate these problems. By these measures, the software quality of the device access apparatus is permanently improved, so that a stable operation of the device access apparatus can be achieved.

[0012] A system corresponding to the form of the automation technology of embodiments of the invention comprises a field bus system having at least one field bus component and a device access means installed in a host or host environment. The device access means comprises a framework application and at least one driver bound into the framework application, which driver is designed to access the at least one field bus component of the field bus system. The system comprises a monitoring unit, which is designed to record information about resources reserved by the driver and provided by an operating system of the host or host environment, and to initiate at least one predetermined countermeasure upon detecting an abnormal increase over time of the resources reserved by the driver.

[0013] A method corresponding to the form of embodiments of the invention serves to monitor the operation of a device access means installed in a host or host environment. The device access means is designed to access field bus components of a field bus system. The device access means comprises a framework application and at least one driver bound into the framework application and designed to access at least one field bus component of the field bus system. The method comprises recording information about resources reserved by the driver and provided by an operating system of the host or host environment, evaluating the course over time of the resources reserved by the driver, and initiating at least one predetermined countermeasure upon ascertaining an abnormal increase over time of the resources reserved by the driver. BRIEF DESCRIPTION OF DRAWINGS

[0014] The invention will now be explained in more detail on the basis of examples of embodiments shown in the drawings. The drawings show the following:

[0015] Figure 1 is a structure of a field bus network and associated device access means in the form of a device access software having drivers bound therein;

[0016] Figure 2 is a schematic diagram of a monitoring system designed to retrieve information from a debugging interface of an operating system; and

[0017] Figure 3 is a graph as a function of time showing the average steady increase of required memory. DETAILED DESCRIPTION

[0018] Figure 1A fieldbus network 100 comprising a plurality of field devices and gateway devices is shown. A field entry device 101 is located at the top level of the fieldbus network 100. The field entry device 101 is connected, for example, via a PROFIBUS segment 102 with field devices 103 and a gateway device 104. The PROFIBUS segment 102 is coupled via the gateway device 104 with HART field devices 105 and 106, wherein the gateway device 104 is designed to convert data traffic from the PROFIBUS protocol to the HART protocol and vice versa.

[0019] Parameterization, configuration and status monitoring of the field devices of the fieldbus network is performed by means of a device access software 108 installed in a host 107 and comprising a framework application 109. The host 107 is connected via an Ethernet connection 110 with the fieldbus network 100. The various components of the fieldbus network 100 can be accessed via the device access software 108. In particular via the device access software 108, parameters of the different components of the fieldbus network 100 can be read out, displayed and changed. Furthermore, the device access software 108 allows condition monitoring of the components of the fieldbus network 100. The data exchange required for these tasks is usually performed via so-called cyclic data traffic.

[0020] In order to be able to correctly access the different components of the fieldbus network 100, the framework 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 different devices in the form of device drivers or device description files. In the case of the fieldbus protocols PROFIBUS-DP, PROFIBUS-PA, FOUNDATION fieldbus and HART, the device descriptions for the cyclic data exchange are according to the standards DTM (Device Type Manager), DD (Device Description), EDD (Enhanced Device Description) and FDI device package. In particular in the case of the standard EDD and DTM, in addition to the device parameters, device functions and address space allocation, graphical features and graphical user interfaces are predetermined in order to facilitate the parameterization and configuration of the field devices. In order to generate these graphical interfaces in the standard EDD, special graphical commands are provided which are processed in the manner of an interpreter language.

[0021] In standard FDT / DTM, the DTM (Device Type Manager) is provided in the form of a dynamically loadable library (DLL) or in the form of an executable file (EXE). The DTM also comprises the mentioned graphic features. Different DTMs for different components of a fieldbus network are bound into a shared FDT framework application, wherein FDT stands for "Field Device Tool". Thus, a shared framework application is provided, into which different devices and DTMs from different manufacturers can be bound. The FDT standard has been complemented more and more in the past years and will probably be replaced later by the standard FDI device package.

[0022] In addition to the fieldbus protocols PROFIBUS, FOUNDATION fieldbus and HART discussed previously, the so-called industrial Ethernet protocols can also be mentioned, wherein the fieldbus protocols Ethernet / IP, Profinet and EtherCAT, among others, belong to these protocols. In the case of the fieldbus protocols, Ethernet / IP, a device description file corresponding to the standard EDS (Electronic Data Sheet) is provided for describing cyclic and acyclic data exchange.

[0023] In the example of Figure 1 The device access software 108 preferably comprises a framework application 109 of the standard FDT (Field Device Tool), wherein different drivers for different devices and components of the fieldbus network 100 can be bound into the framework application 109. Bindable into the FDT framework application can be, for example, different device type managers (DTM) from different manufacturers. In addition to the DTMs, other device description files can also be bound into the framework application 109. In this case, the hierarchy of the fieldbus network 100 is imitated within the device access software 108 with the aid of the drivers or device description files, wherein the arrangement of the drivers or device description files corresponds in this case to a mirror image of the structure of the fieldbus network 100. In order to access the components of the fieldbus network 100, for example, a plurality of different device DTMs, gateway DTMs and communication DTMs can be bound into the framework application 109. At the highest position of the DTM hierarchy is the communication DTM 111. The communication DTM 111 corresponds to the field entry device 101 and communicates with the field entry device 101 via the Ethernet connection 110. The communication DTM 111 represents the external interface of the device access software 108, wherein all incoming and outgoing data traffic passes through the communication DTM 111.

[0024] The device DTM 112 is arranged below the communication DTM 111 in the DTM hierarchy. The device DTM 112 maps the functionality of the field device 103. Also arranged below the communication DTM 111 is a layer of the gateway DTM 113, which corresponds to the gateway 104. Via the gateway DTM 113, the gateway 104 can be parameterized and configured. Below the gateway DTM 113 in the DTM hierarchy, two device DTMs 114, 115 are arranged. Via the device DTMs 114, 115, the field devices 105, 106 can be accessed. In addition to the standard FDT / DTM, there is also an alternative standard for the device access software 108 and the multitude of device drivers bound therein.

[0025] Based on the information retrieved from the DTMs for the individual devices, the FDT framework application can graphically, preferably in the form of a tree structure, display the hierarchical structure of the fieldbus network 100 to the user.

[0026] The fieldbus network 100 can for example comprise fieldbus components of different manufacturers. Usually, the manufacturers of the fieldbus components provide drivers for the fieldbus components, so that in normal cases, drivers of different manufacturers are bound into the framework application 109. It has been found that these drivers can have very different software qualities. For example, there is a poor programming quality of a driver when the driver requires resources provided by the operating system and, after using the resources, cannot release them correctly. This behavior leads to a steady increase in the resource consumption of the driver.

[0027] The resources provided by the operating system can be for example memory space, handles, threads or data traffic emitted from the driver. These resources are managed by the operating system, which thus also performs their reservation and release.

[0028] A first example of a resource provided by the operating system is memory space. For example, a driver can comprise a table into which new entries are inserted during operation. In contrast to good programming rules, when the memory space allocated for the entries is not released after use, the size of the memory space allocated for the table steadily increases, which leads to a crash of the operating system after a certain time.

[0029] A further example of a resource provided by the operating system is a handle for a graphical display element, a so-called GUI handle, wherein GUI stands for "Graphical User Interface". When a driver reserves such handles and does not release them properly after use, then the number of handles reserved by the driver steadily rises during operation. However, since the number of handles that can be allocated by the operating system is limited, the increasing number of handles also inevitably leads to a crash of the operating system.

[0030] Threads are another example of resources provided by the operating system. Threads are referred to as execution threads, and thus are sequential processing processes within a process. In this case, each thread, i.e. program thread, is responsible for executing a certain task. The execution threads of a program function can be divided into manageable units in this way. A process can comprise multiple threads, or can comprise only a single thread when no parallel processing is provided in the context of program execution. Threads share the processor, memory and other operating system-related resources, such as files and network connections, within a process. Therefore, the management work of threads is generally less than that of processes. The important efficiency advantage of threads is that, on the one hand, in contrast to processes, complete alternation of the process context is not necessary in the case of thread alternation, since all threads use the shared part of the process context. On the other hand, there is easy communication and fast data exchange between threads. In the case of threads, it can happen that the driver starts multiple threads, which are not properly ended after their execution. In this case, the number of threads started by the driver steadily increases. Since the operating system can only manage a limited number of threads, this can also lead to the operating system crashing.

[0031] Another example of resources required by the driver is network traffic directed outwards from the driver. When the driver is programmed in such a way that the network traffic directed outwards continuously increases, this will also lead to problems after a certain time and, in the given case, to the system crashing.

[0032] In order to detect and overcome these problems caused by incorrectly programmed drivers and continuously increasing resource consumption, the device access software 108 in the form of an embodiment according to the application comprises a monitoring unit 116, which is designed to monitor the resources reserved by the driver in order to detect an abnormal increase in resource reservation and, in the case of such an increase, to initiate countermeasures. In Figure 1 In the case of the embodiment shown, the monitoring unit 116 is embodied as part of the framework application 109. Alternatively, the monitoring unit can be implemented as part of the device access software 108, however, as a unit separate from the framework application 109, such as Figure 1 is shown by the dashed line in.

[0033] Figure 2A monitoring unit 116 is shown, which is designed to detect excessive and abnormal demands of resources by drivers bound into the device access software 108. For this purpose, the monitoring unit 116 comprises a data interface 200 via which the monitoring unit 116 can access a debug interface 201 of the operating system 202. The debug interface 201 can be, for example, the Windows debug interface provided by the Windows operating system. Via the debug interface 201, the monitoring unit 116 can retrieve parameters of the operating system, in particular parameters which refer to memory space, handles, threads and network traffic directed outwards, which show the current resource reservations of the operating system. Parameters which can be retrieved by the monitoring unit 116 via the debug interface 201 and the data interface 200 can be, for example, the memory space required by the drivers, the number of handles granted, the number of active threads or the data rate of the network traffic directed outwards.

[0034] The extraction and evaluation of the selected parameters is controlled by a command sequence of a command language. For this purpose, the monitoring unit 116 comprises an interpreter unit 203, which is designed to process a command sequence 204 of the command language. The commands 204 can be provided, for example, in the form of a script 205. The commands 204 can comprise, for example, loop commands in order to retrieve the selected parameters from the operating system 202 via the debug interface 201 at regular time intervals. The parameter values thus recorded can be stored, for example, in the monitoring unit 116. In this way, parameters which reflect the resource reservations of the drivers can be recorded as a function of time and tracked in order to be able to monitor the resource reservations in this way.

[0035] In Figure 3 a graph 300 is plotted, which shows the values of a parameter which represents the memory reserved by the drivers as a function of time. It can be seen that the memory reservation, as a result of the activities of the individual drivers, is subject to temporal fluctuations, however, in which, in addition to these fluctuations, there is a steady increase in the memory reservation, which is shown in Figure 3 by the dashed line 301. The average steady increase in the memory required by the drivers indicates that there is at least one driver which does not release the memory space once required in a normal manner. With Figure 3 the steady increase in the memory reservation shown, a permanent, steady operation of the device access software 108 in the host 107 is not possible. Rather, after a certain time, an operating system crash is to be expected. Furthermore, in the case of other resources provided by the operating system, such as the number of handles, the number of threads and the bandwidth of the network traffic directed outwards, a steady increase over time indicates that the resources of the operating system required are not released appropriately, which in turn leads to problems which can also be foreseen in the case of these examples.

[0036] To evaluate the parameters retrieved from the debug interface 201 of the operating system 202, an evaluation unit 206 is provided in the monitoring unit 116, which is designed to track the retrieved parameters over time and to detect an abnormal increase of the reserved resources of the operating system. To this end, the evaluation unit 206 can for example record the parameters over time and then analyze based thereon whether there is an abnormal increase over time. For example, the evaluation unit 206 can for this purpose detect whether the increase of the parameters over time exceeds a predetermined limit value.

[0037] When the evaluation unit 206 determines that there is an abnormal increase over time of the resources of the operating system 202 required by the drivers, then the evaluation unit 206 in a second step finds out which of the drivers bound in the framework application 109 is responsible for the abnormal increase of the required resources. To this end, the evaluation unit 206 can track for example which driver requires memory space, requests handles, starts threads or causes network traffic. In this way, one or more drivers can be identified which are responsible for the abnormal increase of the reserved resources. In this way, potential problems can be located before a system crash occurs. In this regard, the monitoring unit 116 can be considered as an automatic debugging unit, which performs a continuous system monitoring during ongoing operation.

[0038] When the monitoring unit 116 detects a problem related to the resource requirements of the drivers, one or more appropriate countermeasures can be initiated. In the following, some possible countermeasures will now be discussed. In each case, the countermeasures described below can also be used in any combination.

[0039] One possible countermeasure is to indicate to the user on a display or other suitable display unit, for example also by means of a report sent to the mobile device, that there is a problem that the drivers increasingly require resources. For example, the user can be informed that the memory requirement of the system, the number of handles used, the number of started threads or the network traffic oriented outwards is showing an upward trend. In addition, a prediction of the expected system crash can be shown to the user when viewed in the light of the increasing resource consumption. The user can then estimate how much time is left to solve the problem. In addition, information for identifying the abnormal working drivers can also be displayed.

[0040] Another possible countermeasure is to automatically forward information about the problem, e.g. by e-mail, to a support organization, e.g. a support team. Such a support team can be operated, for example, by the producer of the framework application or the field device manufacturer. Alternatively, a manufacturer association or a manufacturer umbrella organization can maintain the support team. Upon receipt of the problem report, a member of the support team can then, for example, get in contact with the user and provide information about how to solve the problem. Alternatively or in addition, a member of the support team can interact with the host and eliminate the problem by remote access. For example, the member can perform a reinstallation of the problem driver, install an updated version of the driver or reboot the system by remote access.

[0041] It is particularly advantageous if the problem report about the problem caused by the driver is sent to a central organization, e.g. to a manufacturer association or other organization comprising manufacturers, which receives problem reports from a large number of users. By evaluating the problem reports, it can be found, inter alia, which drivers are exceptionally demanding resources. In this case, the producer of the affected driver can be contacted and requested to provide a corrected driver version.

[0042] In the case of a problem caused by an excessive demand for resources, another possible countermeasure is to write information about the problem from the monitoring unit 116 into the cloud 207, wherein problem reports from different fieldbus systems are collected in the cloud 207. Based on the problem reports collected in the cloud 207, an evaluation can then be performed in order to find out which drivers of which manufacturers often cause problems related to an exceptional demand for resources. The affected manufacturers can then be requested to provide a corrected version of the relevant drivers in order to enable reliable operation of the device access software 108.

[0043] Another possible countermeasure after detecting an excessive requirement of a resource by a driver is to reinstall the relevant driver or to install an updated version of the driver. By the reinstallation of the driver, at least it is ensured that the reserved resources are released, so that a system crash is prevented. In contrast, the installation of a newer version of the driver provides the opportunity that the newer version of the driver works properly, so that the problems caused by the driver in connection with the steadily increasing resource requirements no longer exist. In order to find out whether an updated version of the relevant driver exists, the monitoring unit 116 can compare, for example, the version of the currently installed driver with the version of the latest driver available for the relevant fieldbus component. In order to reinstall the existing driver or the driver of the updated version, on the one hand, there is the opportunity to guide the user step by step through the installation process by means of the prompts provided for this purpose. At the end of the installation process, it can be displayed to the user, for example, that the reinstallation of the driver or the installation of the updated version of the driver has been successfully completed. Alternatively, the monitoring unit 116 can automatically initiate the reinstallation of the relevant driver or the installation of an updated version of such a driver or perform such an installation after detecting a problem in connection with the resource requirements of the driver. After the completion of the installation, it can be displayed to the user, for example, that the reinstallation or the installation of the updated version has been successfully completed.

[0044] As a further possible countermeasure, it can be provided that the monitoring unit 116 initiates a restart of the host 107 after detecting an abnormally working driver. In this way, the reserved resources are released, so that an unexpected system crash is prevented.

[0045] In a further possible countermeasure, upon detecting an abnormal requirement of a resource by at least one driver, a memory dump can be performed automatically, in which case the memory is completely or partially saved. Such a memory dump is useful for analyzing what went wrong and for recovering information that would otherwise be lost.

[0046] Problems in connection with an excessive requirement of resources by at least one driver can in particular lead to a crash during the execution of a system scan, in particular during the execution of a system scan, during which the drivers for all fieldbus components are addressed or installed. When a single driver does not release the resources after use, this can lead to a system crash during a system scan by the operating system. This applies in particular, but not exclusively, to large fieldbus systems with a large number of fieldbus components. In order to avoid such a system crash, the monitoring unit 116 can be designed to suggest to the user to divide the system scan into several smaller sub-scans. As an alternative to this, the monitoring unit 116 can be designed to automatically divide the scan into a plurality of locally executed scans that are executed in succession.

Claims

1. A device access apparatus (108) for accessing field bus components (101, 103, 104, 105, 106) of a field bus system (100), wherein The device access means (108) are installed in a host (107) or host environment, wherein the device access means (108) comprise: a framework application (109); and at least one driver (111-115) bound to the framework application (109), the driver (111-115) being designed to access at least one fieldbus component (101, 103, 104, 105, 106), characterized in that the device access means (108) comprise a monitoring unit (116) designed to record information about resources reserved by the driver (111-115) and provided by an operating system (202) of the host (107) or of the host environment, on detection of an abnormal increase over time of the resources reserved by the driver (111-115), at least one predetermined countermeasure is initiated.

2. The device access arrangement (108) according to claim 1, characterized in that The resources recorded by the monitoring unit (116) comprise at least one of the following: memory space reserved by the driver (111-115), number of handles reserved by the driver (111-115), number of threads initiated by the driver (111-115), extent of network traffic caused by the driver (111-115).

3. The device access arrangement (108) according to claim 2, characterized in that At least one of the following: the monitoring unit (116) is designed to retrieve parameters from the host (107) or from the host environment, the parameters being indicative of resources reserved by the driver (111-115) and provided by the operating system (202); the monitoring unit (116) is designed to retrieve parameters from the host (107) or from the host environment via a debugging interface (201) of the operating system (202), the parameters being indicative of resources reserved by the driver (111-115) and provided by the operating system (202); the monitoring unit (116) is designed to retrieve parameters from the host (107) or from the host environment according to a predetermined time pattern, the parameters being indicative of resources reserved by the driver (111-115) and provided by the operating system (202).

4. The device access arrangement (108) according to claim 3, characterized in that At least one of the following: the monitoring unit (116) is designed based on the recorded information to ascertain the reservation of resources by the driver (111-115) over time; the monitoring unit (116) is designed based on the parameters retrieved from the operating system (202) of the host (107) or of the host environment to ascertain the reservation of resources by the driver (111-115) over time; the monitoring unit (116) is designed based on predefined criteria to detect an abnormal increase over time of the resources reserved by the driver (111-115); the monitoring unit (116) is designed to compare the increase over time of the resources reserved by the driver (111-115) to a predetermined threshold value.

5. The device access arrangement (108) according to any one of claims 1 to 4, characterized in that, Said monitoring unit (116) is designed to ascertain, in a first step, whether the resources reserved by said drivers (111-115) show an anomalous increase over time, and, when the reserved resources show an anomalous increase over time, to identify, in a second step, at least one driver (111-115) responsible for the anomalous increase over time of the reserved resources.

6. The device access arrangement (108) according to any one of claims 1 to 4, characterized in that At least one of the following: Said monitoring unit (116) is designed to track the memory space reserved by the drivers (111-115); Said monitoring unit (116) is designed to track the number of handles reserved by the drivers (111-115); Said monitoring unit (116) is designed to track the number of threads launched by the drivers (111-115); Said monitoring unit (116) is designed to track the extent of network traffic caused by the drivers (111-115).

7. The device access arrangement (108) according to claim 6, characterized in that At least one of the following: Said monitoring unit (116) is designed to ascertain whether there is an anomalous increase over time of the memory space reserved by the drivers (111-115), and, for the case in which there is an anomalous increase over time, to identify at least one driver (111-115) responsible for the anomalous increase over time of the reserved memory space; Said monitoring unit (116) is designed to ascertain whether there is an anomalous increase over time of the number of handles reserved by the drivers (111-115), and, for the case in which there is an anomalous increase over time, to identify at least one driver (111-115) responsible for the anomalous increase over time of the number of handles reserved by the drivers (111-115); Said monitoring unit (116) is designed to ascertain whether there is an anomalous increase over time of the number of threads launched by the drivers (111-115), and, for the case in which there is an anomalous increase over time, to identify at least one driver (111-115) responsible for the anomalous increase over time of the number of threads launched by the drivers (111-115); Said monitoring unit (116) is designed to ascertain whether there is an anomalous increase over time of the extent of network traffic caused by the drivers (111-115), and, for the case in which there is an anomalous increase over time, to identify at least one driver (111-115) responsible for the anomalous increase over time of the network traffic.

8. The device access arrangement (108) according to any one of claims 1 to 4, characterized in that At least one of the following: Said monitoring unit (116) comprises an interpreter unit (203) designed to process a sequence of instructions (204); Said monitoring unit (116) comprises an interpreter unit (203) designed to process a sequence of instructions (204) according to a predetermined script (205).

9. The device access arrangement (108) according to claim 8, characterized in that At least one of the following: Said instructions (204) are designed to control the retrieval of parameters from said host (107) or from the operating system (202) of said host environment, said parameters showing the reservation of resources by the drivers (111-115); the instructions (204) are designed to control an evaluation of resources reserved by the drivers (111-115) as a function of time; the instructions (204) are designed to control an evaluation of parameters retrieved from the host (107) or an operating system (202) of the host environment as a function of time; the instructions (204) comprise a loop command designed to control a periodic retrieval of parameters from the host (107) or an operating system (202) of the host environment, the parameters showing a reservation of resources by the drivers (111-115).

10. The device access arrangement (108) according to any one of claims 1 to 4, characterized in that at least one of the following: the monitoring unit (116) is implemented as an automatic debugging unit; the monitoring unit (116) is automatically implemented to track a reservation of resources by the at least one driver (111-115); the monitoring unit (116) comprises an interface (200) to a debugging interface (201) of the operating system (202), via which parameters showing a reservation of resources by the drivers (111-115) can be retrieved.

11. The device access arrangement (108) according to any one of claims 1 to 4, characterized in that one of the following: the monitoring unit (116) is implemented as part of the framework application (109); the monitoring unit is implemented as a unit provided in addition to the framework application (109).

12. The device access arrangement (108) according to any one of claims 1 to 4, characterized in that at least one of the following: bound into the framework application (109) are drivers (111-115) corresponding to one or more of the following standards: FDT / DTM, DD, EDD, EDS, FDI device package; the framework application (109) is an FDT framework application or an FDI framework application, and bound into the FDT framework application or the FDI framework application are drivers (111-115) of the standards, FDT / DTM and / or FDI device package.

13. The device access arrangement (108) according to any one of claims 1 to 4, characterized in that, the at least one predetermined countermeasure comprises at least one of the following: displaying to a user on a display that there is an anomaly in the increase over time of resources reserved by the drivers (111-115); displaying to a user on a display at least one driver (111-115) that is causing an anomaly in the increase over time of reserved resources; displaying to a user on a display when, taking into account the anomaly in the increase over time of reserved resources, a crash of the expected operating system (202) is predicted to occur; electronically reporting to a support authority; reinstalling a driver (111-115) responsible for the anomaly in the increase over time of reserved resources; remotely accessing a support instance in the host (107) or the host environment to eliminate a problem caused by resources reserved by the drivers (111-115); electronically reporting to a central instance designed to receive and evaluate driver problem reports of a plurality of fieldbus systems; writing information about the increasing over time of exceptions of resources reserved by the drivers (111-115) into a cloud (207), wherein information about problems of the drivers (111-115) from a plurality of fieldbus systems is collected and evaluated in the cloud (207); in the case of a driver (111-115) being responsible for the increasing over time of exceptions of reserved resources, ascertaining whether the installed version of the driver (111-115) is outdated and, when the installed version of the driver (111-115) is outdated, guiding a user to install a current version of the driver (111-115); in the case of a driver (111-115) being responsible for the increasing over time of exceptions of reserved resources, ascertaining whether the installed version of the driver (111-115) is outdated and, when the installed version of the driver (111-115) is outdated, automatically starting an installation of a current version of the driver (111-115); restarting the host (107) or the host environment; starting a memory dump of at least a part of the memory of the host (107) or the host environment.

14. An automation technology system, comprising: a fieldbus system (100) having at least one fieldbus component (101, 103, 104, 105, 106), and a device access apparatus (108) installed in a host (107) or a host environment, wherein the device access apparatus (108) comprises: a framework application (109); and, at least one driver (111-115) bound into the framework application (109), the driver (111-115) being designed to access at least one fieldbus component (101, 103, 104, 105, 106) of the fieldbus system (100), characterized in that the system comprises a monitoring unit (116) designed to record information about resources reserved by the drivers (111-115) and provided by an operating system (202) of the host (107) or the host environment, upon detecting an increasing over time of exceptions of resources reserved by the drivers (111-115), starting at least one predetermined countermeasure.

15. A method for monitoring the operation of a device access arrangement (108) installed in a host (107) or host environment, wherein, The device access apparatus (108) is designed to access fieldbus components (101, 103, 104, 105, 106) of a fieldbus system (100), wherein the device access apparatus (108) comprises: a framework application (109), and at least one driver (111-115) bound into the framework application (109) and designed to access at least one fieldbus component (101, 103, 104, 105, 106) of the fieldbus system (100), wherein the method comprises the following steps: - recording information about resources reserved by the drivers (111-115) and provided by the operating system (202) of the host (107) or of the host environment; - evaluating the course over time of the resources reserved by the drivers (111-115); and, - in the event of ascertaining an abnormal increase over time of the resources reserved by the drivers (111-115), initiating at least one predetermined countermeasure.

16. The method of claim 15, wherein At least one of the following steps: - retrieving parameters from the operating system (202) of the host (107) or of the host environment, which parameters show the resources reserved by the drivers (111-115) and provided by the operating system (202); - ascertaining, on the basis of the parameters retrieved from the operating system (202) of the host (107) or of the host environment, the reservation of resources by the drivers (111-115) as a function of time; - detecting an abnormal increase over time of the resources reserved by the drivers (111-115) on the basis of predefined criteria; - comparing the increase over time of the resources reserved by the drivers (111-115) with a predetermined threshold value; - ascertaining whether the resources reserved by the drivers (111-115) show an abnormal increase over time, and, when the reserved resources show an abnormal increase over time, identifying at least one driver (111-115) responsible for the abnormal increase over time of the reserved resources.

Images