Instrument management equipment and instrument management methods

Abstract

The invention in this application is entitled "Autonomous Instrument Management". One embodiment includes a monitoring system for a first device, wherein the first device is configured to acquire measurement data from a second device, compare the measurement data with a reference value, and send a signal when the measurement data indicates an error condition compared to the reference. Machine learning can be used, wherein the head end is able to modify the second device when the reference value so indicates an error. This enables various embodiments to repair the second device without human intervention.

Description

[0001] Cross-reference to related applications

[0002] none Background Technology

[0003] Autonomous instrument management is used in a variety of industries to achieve consistent, economical, and safe production levels that are impossible to achieve through manual control alone. Process control systems are widely used in industries such as oil refining, pulp and paper manufacturing, chemical processing, and power plants. For example, an instrument management system can be located near the plant and can operate valves, start motors, change equipment or sensor settings, or run coolers or mixing units as needed.

[0004] The instrument management system can also diagnose faults to prevent unmanaged problems. It can monitor multiple measuring devices to ensure their values ​​are within the expected range, such as the device's operation as it measures them. Measuring devices can obtain real-time values ​​during the operation of the process they control. This can include, for example, temperature readings, pressure readings, gas flow readings, etc. The instrument management system can also report the status of the controlled equipment or process. For example, this can include: the equipment is: exceeding its financial reading; out of range; experiencing equipment malfunction; and others.

[0005] Identifying the root cause of errors in equipment is a complex and time-consuming task requiring deep knowledge and experience. It typically demands highly skilled and trained technicians, who are often expensive and in short supply. There is a need for instrument management that can handle specific parts of a faulty system under its control without human intervention. This would not only improve the system's cost-effectiveness but also reduce downtime and increase overall system reliability. Attached Figure Description

[0006] Figure 1 This is a diagram of an autonomous instrument management system based on an implementation plan.

[0007] Figure 2 This is a diagram of an autonomous instrument management system based on another implementation scheme.

[0008] Figure 3 This is a diagram of an autonomous instrument management system based on another implementation scheme.

[0009] Figure 4 This is a flowchart illustrating the operation of an autonomous instrument management system according to one implementation scheme.

[0010] Figure 5 This is a flowchart illustrating the operation of an autonomous instrument management system according to another implementation scheme. Summary of the Invention

[0011] One embodiment is an instrument management device comprising: a monitoring module for a first device, wherein the first device is configured to receive measurement data from a second device, compare the measurement data with a reference value, and send a signal when the measurement data indicates an error condition compared to the reference; a recommendation module for receiving the signal from the monitoring module, analyzing the signal, and generating one or more recommendations associated with the error condition using a causal module, the causal module including a data structure having at least one row and at least one column, the recommendation module accessing data items from a row or a column of the causal module; a ticket generation module for receiving one or more recommendations including data items, obtaining a solution to the error condition by changing the state of the second device, and generating a data packet associated with the solution to the error condition; and a machine learning module configured to use the packet to determine whether to update the causal module, and if so, modify a data item in a row or a column of the causal module.

[0012] Another embodiment is a system comprising: a monitoring system for a first device, wherein the first device is configured to receive measurement data from a second device, compare the measurement data with a reference value, and send a signal when the measurement data indicates an error condition compared to the reference; a recommendation system for receiving the signal from the monitoring system, analyzing the signal, and generating one or more recommendations associated with the error condition using a causal table, the causal table comprising a data structure having at least one row and at least one column, the recommendation system accessing data items from a row or a column of the causal table; a ticket generation system for receiving one or more recommendations including data items, obtaining a solution to the error condition by changing the state of the second device, and generating a data packet associated with the solution to the error condition; and a machine learning system configured to use the packet to determine whether to update the causal table, and if so, to change a data item in a row or a column of the causal table.

[0013] In another implementation, a method includes: obtaining measurement data from a device; comparing the measurement data with a reference value; receiving a signal when the measurement data indicates an error condition compared to the reference; generating one or more recommendations associated with the error condition using a causal table, the causal table including a data structure having at least one row and at least one column, the step of which further includes accessing a data item from a row or a column of the causal table; obtaining a solution to the error condition by changing the state of the device; generating a data packet associated with the solution to the error condition; and using the packet to determine whether the causal table should be updated, and if so, changing a data item in a row or a column of the causal table. Detailed Implementation

[0014] Figure 1An exemplary autonomous instrument management system 100 according to this disclosure is shown. Figure 1 As shown, system 100 includes various components that facilitate the production or processing of at least one product or other material. For example, system 100 is used here to facilitate the control of components in one or more factory buildings. Figure 1 The plants are shown as 101a, 101b, and 101n (hereinafter referred to as 101a-101n). Each plant 101a to 101n represents one or more processing facilities (or one or more portions thereof), such as one or more manufacturing facilities for producing at least one product or other material. Generally, each plant 101a to 101n may implement one or more processes and may be referred to individually or collectively as a process system. A process system generally refers to any system or portion thereof configured to process one or more products or other materials in a certain way.

[0015] exist Figure 1 In this system 100, the Purdue model of process control is used. In the Purdue model, "Level 0" can include one or more sensors 102a and one or more actuators 102b. Sensors 102a and actuators 102b represent components in the process system capable of performing any of a variety of functions. For example, sensor 102a can measure various characteristics of the process system, such as temperature, pressure, volume, or flow rate, and can include such instruments as ultrasonic flow meters, turbines, orifices, Coriolis flow meters, gas chromatographs, P&T transmitters, flow computers, etc. Additionally, actuators 102b can alter various characteristics of the process system. Sensors 102a and actuators 102b can represent any other or additional components in any suitable process system. Each sensor in sensor 102a includes any suitable structure for measuring one or more characteristics of the process system. Each actuator in actuator 102b includes any suitable structure for operating or influencing one or more conditions in the process system. Sensors and actuators are generally referred to as field devices.

[0016] At least one network 104 is coupled to sensor 102a and actuator 102b. Network 104 facilitates interaction with sensor 102a and actuator 102b. For example, network 104 can transmit measurement data from sensor 102a and provide control signals to actuator 102b. Network 104 can represent any suitable network or combination of networks. As a specific example, network 104 can represent an Ethernet network, an electrical signal network (such as a HART or Foundation Fieldbus network), a pneumatic control signal network, or any other or additional type of network.

[0017] In the Purdue model, "Level 1" may include one or more controllers 106 coupled to network 104. Among other things, each controller 106 may use measurements from one or more sensors 102a to control the operation of one or more actuators 102b. For example, controller 106 may receive measurement data from one or more sensors 102a and use the measurement data to generate control signals for one or more actuators 102b. Multiple controllers 106 may also operate in a redundant configuration, such as when one controller 106 operates as a master controller and another controller 106 operates as a backup controller (which is synchronized with the master controller and can take over the master controller in case of failure). Each controller 106 includes any suitable structure for interacting with one or more sensors 102a and controlling one or more actuators 102b. Each controller 106 may, for example, represent a multivariable controller, such as a Robust Multivariable Predictive Control Technique (RMPCT) controller or other types of controllers implementing Model Predictive Control (MPC) or other Advanced Predictive Control (APC). As a specific example, each controller 106 may represent a computing device running a real-time operating system.

[0018] Two networks 108 are coupled to controller 106. Networks 108 facilitate interaction with controller 106, such as by transmitting data to and from controller 106. Network 108 can represent any suitable network or combination of networks. As a specific example, network 108 can represent a pair of Ethernet networks or a pair of redundant Ethernet networks, such as a fault-tolerant Ethernet (FTE) network from Honeywell International Inc.

[0019] At least one switch / firewall 110 couples network 108 to two networks 112. The switch / firewall 110 can transmit traffic from one network to another. The switch / firewall 110 can also block traffic from one network from reaching another. The switch / firewall 110 includes any suitable construct for providing communication between networks, such as a Honeywell Control Firewall (CF9) device. Network 112 can represent any suitable network, such as a pair of Ethernet networks or an FTE network.

[0020] In the Purdue model, "Level 2" may include one or more machine-level controllers 114 coupled to network 112. Machine-level controllers 114 perform various functions to support the operation and control of controllers 106, sensors 102a, and actuators 102b that can be associated with a specific industrial device, such as a boiler or other machine. For example, machine-level controllers 114 may record information collected or generated by controller 106, such as measurement data from sensor 102a or control signals for actuator 102b. Machine-level controllers 114 may also execute applications that control the operation of controller 106, thereby controlling the operation of actuator 102b. Furthermore, machine-level controllers 114 can provide secure access to controller 106. Each machine-level controller in machine-level controllers 114 includes any suitable structure for providing access to, control of, or operation of a machine or other individual device. Each machine-level controller in machine-level controllers 114 may, for example, represent a server computing device running the Microsoft Windows operating system. Although not shown, different machine-level controllers 114 can be used to control different devices in the process system (each device is associated with one or more controllers 106, sensors 102a and actuators 102b).

[0021] One or more operator stations 116 are coupled to network 112. Operator station 116 represents a computing or communication device that provides user access to machine-level controller 114, which in turn can provide user access to controller 106 (and possibly sensors 102a and actuators 102b). As a specific example, operator station 116 may allow a user to view the operational history of sensors 102a and actuators 102b using information collected by controller 106 and / or machine-level controller 114. Operator station 116 may also allow a user to adjust the operation of sensors 102a, actuators 102b, controller 106, or machine-level controller 114. Furthermore, operator station 116 may receive and display warnings, alerts, or other messages or displays generated by controller 106 or machine-level controller 114. Each operator station in operator station 116 includes any suitable architecture for supporting user access and control of one or more components in system 100. Each operator station in operator station 116 may, for example, represent a computing device running the Microsoft Windows operating system.

[0022] At least one router / firewall 118 couples network 112 to two networks 120. Router / firewall 118 includes any suitable structure for providing communication between the networks, such as a secure router or a combined router / firewall. Network 120 may represent any suitable network, such as a pair of Ethernet networks or an FTE network.

[0023] In the Purdue model, "Level 3" may include one or more unit-level controllers 122 coupled to network 120. Each unit-level controller 122 is typically associated with a unit in the process system, representing a collection of different machines operating together to implement at least a portion of the process. The unit-level controllers 122 perform various functions to support the operation and control of components in lower levels. For example, a unit-level controller 122 may log information collected or generated by components in lower levels, execute applications controlling components in lower levels, and provide secure access to components in lower levels. Each unit-level controller in the unit-level controllers 122 includes any suitable structure for providing access to, control of, or associated operation of one or more machines or other devices in the processing unit. Each unit-level controller in the unit-level controllers 122 may, for example, represent a server computing device running the Microsoft Windows operating system. Although not shown, different unit-level controllers 122 may be used to control different units in the process system (where each unit is associated with one or more machine-level controllers 114, controllers 106, sensors 102a, and actuators 102b).

[0024] Access to the unit-level controller 122 can be provided by one or more operator stations 124. Each operator station in the operator stations 124 includes any suitable structure for supporting user access and control of one or more components in the system 100. Each operator station in the operator stations 124 may, for example, represent a computing device running the Microsoft Windows operating system.

[0025] At least one router / firewall 126 couples network 120 to two networks 128. Router / firewall 126 includes any suitable structure for providing communication between the networks, such as a secure router or a combined router / firewall. Network 128 may represent any suitable network, such as a pair of Ethernet networks or an FTE network.

[0026] In the Purdue model, "Level 4" may include one or more plant-level controllers 130 coupled to network 128. Each plant-level controller 130 is typically associated with one of the plants 101a to 101n, which may include one or more processing units implementing the same, similar, or different processes. Plant-level controllers 130 perform various functions to support the operation and control of components in lower levels. As a specific example, a plant-level controller 130 may execute one or more Manufacturing Execution System (MES) applications, scheduling applications, or other or additional plant or process control applications. Each plant-level controller 130 includes any suitable structure for providing access to, control of, or associated operation of one or more processing units in the processing plant. Each plant-level controller 130 may, for example, represent a server computing device running the Microsoft Windows operating system.

[0027] Access to the plant-level controller 130 can be provided by one or more operator stations 132. Each operator station in the operator station 132 includes any suitable architecture for supporting user access and control of one or more components in the system 100. Each operator station in the operator station 132 may, for example, represent a computing device running the Microsoft Windows operating system.

[0028] At least one router / firewall 134 couples network 128 to one or more networks 136. Router / firewall 134 includes any suitable structure for providing communication between networks, such as a secure router or a combined router / firewall. Network 136 can represent any suitable network, such as an enterprise-wide Ethernet or other network, or all or part of a larger network (such as the Internet).

[0029] In the Purdue model, "Level 5" may include one or more enterprise-level controllers 138 coupled to network 136. Each enterprise-level controller 138 is typically capable of performing planning operations for multiple plants 101a to 101n and controlling various aspects of plants 101a to 101n. Enterprise-level controllers 138 may also perform various functions to support the operation and control of components in plants 101a to 101n. As a specific example, an enterprise-level controller 138 may execute one or more order processing applications, enterprise resource planning (ERP) applications, advanced planning and scheduling (APS) applications, or any other or additional enterprise control applications. Each enterprise-level controller in enterprise-level controller 138 includes any suitable structure for providing access to, control of, or control-related operations for one or more plants. Each enterprise-level controller in enterprise-level controller 138 may, for example, represent a server computing device running the Microsoft Windows operating system. In this document, the term "enterprise" refers to an organization having one or more plants or other processing facilities to manage. It should be noted that if a single plant 101a is to be managed, the functionality of the enterprise-level controller 138 can be integrated into the plant-level controller 130.

[0030] Access to the enterprise-level controller 138 can be provided by one or more operator stations 140. Each operator station in the operator stations 140 includes any suitable architecture for supporting user access and control of one or more components in the system 100. Each operator station in the operator stations 140 may, for example, represent a computing device running the Microsoft Windows operating system.

[0031] The various levels of the Purdue model may include other components, such as one or more databases. The database associated with each level may store any suitable information associated with that level or one or more other levels of system 100. For example, a historical database 141 may be coupled to network 136. Historical database 141 may represent a component that stores various information about system 100. Historical database 141 may, for example, store information used during production scheduling and optimization. Historical database 141 represents any suitable structure used for storing information and facilitating information retrieval. Although shown as a single centralized component coupled to network 136, historical database 141 may be located elsewhere in system 100, or multiple historical databases may be distributed across different locations within system 100.

[0032] In a particular implementation scheme, Figure 1The various controllers and operator stations within the system can represent computing devices. For example, each controller may include one or more processing devices 142 and one or more memories 144 for storing instructions and data used, generated, or collected by the one or more processing devices 142. Each controller may also include at least one network interface 146, such as one or more Ethernet interfaces or a wireless transceiver. Additionally, each operator station may include one or more processing devices 148 and one or more memories 150 for storing instructions and data used, generated, or collected by the one or more processing devices 148. Each operator station may also include at least one network interface 152, such as one or more Ethernet interfaces or a wireless transceiver.

[0033] Figure 2 Another example of an autonomous instrument management system is shown. Figure 2 Includes controller 200, which can be any suitable controller, such as those related to... Figure 1 The controllers described herein, or other controllers, are as follows. In one example, controller 200 is configured to monitor the status, condition, or other aspects of device 250. Device 250 can be any suitable device that may facilitate the production or processing of at least one product or other material. In one example, this includes a gas flow meter or an ultrasonic transducer. In another example, controller 200 may use headend 240 to provide automatic error correction, service recommendations, and other functions based on analysis provided by headend 240. Device 250 can be any suitable device with a microprocessor and capable of storing large amounts of data and / or performing analysis on large amounts of data. In one example, device 250 is a measuring device, such as a volumetric and / or mass flow measuring device or instrument.

[0034] In operation, controller 200 uses monitoring module 205 to monitor device 250. Monitoring module 205 continuously receives measurement data from device 250 and compares the measurement data with a reference value. For example, this could be a volumetric flow meter reporting a volumetric measurement value to monitoring module 205, and the monitoring module comparing the volumetric measurement value with measurement data representing the normal operating range. Measurement data can be stored in database 299 or other suitable storage mechanisms such as hardware, software, firmware, or any suitable combination thereof. When the measurement data and reference value indicate that device 250 is operating out of range or otherwise in a state requiring a certain action, signal 290 is sent to recommendation module 210. This may occur when the ultrasonic transducer of device 250 has a reference value indicating reduced accuracy. Alternatively, this may occur when any general-purpose sensor, instrument, or device operates out of range compared to an expected reference value.

[0035] Recommendation module 210 can access solution data 220, which is configured to provide a solution to monitoring module 205 and enable controller 200 to bring device 250 back into range or otherwise restore its normal operating characteristics. Ticket generation module 215 can also be used, configured to perform a process to resolve the error condition that caused the ticket initiation. Ticket generation module 215 can be configured to receive signal 290 from recommendation module 210. In one example, controller 200 encapsulates data associated with the error condition into a packet and sends it to headend 240. The packet can be included on a per-device basis and can also be sent with a predefined delay, which allows the system to stabilize in the error condition before sending the packet to ticket generation module 215. For example, in the case of a brief, simply disappearing disturbance, it may not be necessary to send a packet. Multiple errors and warnings can also occur based on a single error condition (e.g., a disconnected sensor cable will cause many different errors), in which case a packet can include multiple errors, or multiple packets can be sent. In another example, the package includes detailed device information collected by controller 200, such as the device's name and serial number, location, log (raw data) file, recommendation text, and so on.

[0036] Headend 240 is configured to receive packets and utilize machine learning module 225 to perform machine learning using the packets. Causal module 230 may also be included in headend 240. Causal module 230 may have a table with other data structures that pair the causes of a problem with the solutions to that problem. Causal module 230 can be updated over time by continuously utilizing machine learning module 225, for example, as it learns better solutions for existing problems. In one example, causal module 305 is configured to have one or more of any activity status, alarm, and warning messages for device 250. Thus, machine learning module 225 improves causal table 230 over time, and this, in turn, improves the performance of controller 200, recommendation module 210, and can be used to improve solution data 220.

[0037] Figure 3 Another example of an autonomous instrument management system is shown. Figure 3 The operation of the head end 240 is described in more detail in the middle. Figure 3The system includes a controller 200 configured to monitor the status, condition, or other aspects of equipment that may facilitate the production or processing of at least one product or other material. A head unit 240 is configured to provide automatic error correction, service recommendations, and other functions based on the analysis provided by the head unit 240. In operation, the controller 200 monitors the equipment by continuously receiving measurement data from the equipment and comparing that data with reference values. The measurement data is not limited to that specific equipment. Instead, it can be any industrial device (measuring device), such as a gas flow meter, gas chromatograph, temperature sensor, pressure sensor, ultrasonic transducer, or any suitable general-purpose measuring device.

[0038] Measurement data can be stored in a database 299 or other suitable storage mechanisms such as hardware, software, firmware, or any suitable combination thereof.

[0039] When measurement data and reference values ​​indicate that the device is operating out of range or otherwise in a state requiring a certain action, the ticket generation module 315 communicates with the headend 240. The headend 240 is configured to receive communication from the ticket generation module 315 and generate a ticket that can be processed and utilized by the recommendation engine 300. In one example, a new ticket number can be generated at the headend 240, and the headend's utilization of the ticket may include details encapsulated in a packet sent from the controller 200. The ticket number can be shared and stored at the headend 240; for example, it can be used to reference the ticket when processing it through a conventional ticket processing system until the problem is resolved and the ticket is closed.

[0040] Recommendation engine 300 is configured to use analysis module 330 to provide autonomous suggestions for resolving errors occurring in a device (shown here as device 390). Recommendation engine 300 is also configured to use notification module 320 to return a detailed report to ticket generation module 315. The report may include, for example, all information related to the device such as data log files, historical data, and recommendations. In one embodiment, recommendation engine 300 may provide the most probable root cause and the most probable recommendation to resolve the error situation returned to the device. The most probable root cause and the most probable recommendation may be provided to the user, the device screen, or both in plain text or other forms. In another example, each recommendation has a calculated probability indicator between 0% and 100%. Recommendation engine 300 may use the recommendation with the highest probability to represent this to the user, the device screen, or elsewhere.

[0041] The machine learning module 350 can also utilize communication from the headend 240. The machine learning module 350 can perform machine learning using a causal matrix 305, which can also be included in the headend 240. The causal matrix 305 can be a table with other data structures that pair the causes of a problem with solutions to that problem. By continuously utilizing the machine learning module 350 over time, for example, as it learns better solutions for existing problems, the causal matrix 305 can be updated. In this way, the machine learning module 350 improves the causal matrix 305 over time, and this, in turn, improves the performance of the controller 200, the recommendation module 210, and can be used to improve solution data. In one example, automatic feedback can be provided to the machine learning module 350 from the ticket generation module 315 or another source. Automatic feedback can include data associated with actual field solutions for the device, which can be used to update the causal matrix 305, the recommendation engine 300, or both.

[0042] Figure 4 This is a flowchart illustrating the operation of an autonomous instrument management system according to one embodiment. At step 400, the system waits until an active error occurs. When an active error occurs, a recommendation is then generated at step 405. This could, for example, use a causal module. Subsequently, at step 410, a package is sent to a ticketing system. For example, the package may include raw and / or historical data associated with the device that triggered the error state in step 400. In one example, the ticketing system will address the device problem associated with the package in one of two ways: 1. autonomously adjusting device parameters; or 2. requiring human intervention. The system will seek to resolve the problem at step 415 by sending the error and root cause description to the user for human intervention, or by autonomously resolving the problem by remotely adjusting the device.

[0043] At step 420, the system determines whether the error has been fixed. If not, the error resolution steps at step 415 are repeated. When the error condition is fixed, the ticketing system is updated at step 425, and the data packet is sent to the recommendation module at step 430. At step 435, the recommendation engine analyzes the data packet. At step 440, the recommendation engine determines whether the causal module needs to be updated. If not, the process ends. Otherwise, the causal module is updated at step 445, and the process ends.

[0044] Figure 5This is a flowchart illustrating the operation of an autonomous instrument management system according to another embodiment. At step 500, the system waits until a signal is received. At step 505, the signal is analyzed. For example, this signal may be sent when the ultrasonic transducer of the device is detected to be operating with reduced accuracy. At step 510, the system determines whether an active error exists. If not, the system continues waiting at step 500. If an error occurs at step 510, the system determines at step 515 whether parameter changes are possible. If parameter changes are not possible, the system generates a recommendation at step 540 (e.g., using a causal table), and, for example, creates a data packet at step 545 and sends it to the ticketing system. The process then ends.

[0045] If it is possible to change the parameters at step 515, the new parameter values ​​can be calculated at step 520. In one example, the parameters are changed gradually in a stepwise manner, as described in further detail with reference to Table 1.

[0046] Table 1

[0047] parameter Minimum Maximum Incremental step size Decrease step size Parameter 1 Data 1 Data 2 Data 3 Data 4 Parameter 2 Data 5 Data 6 Data 7 Data 8

[0048] At step 525, the system determines whether the current parameter value of the device is at a threshold at which the system can no longer increase it. This can occur, for example, by comparing the current value with the maximum value in Table 1 for the given device and determining whether the current value is equal to or greater than the maximum value. If the current parameter value at step 525 is not at a threshold at which the system can no longer increase it, the system updates the connected device at step 530. At step 535, the system determines whether an error has been resolved. If so, the process ends. Otherwise, the process is repeated at step 500, and the system then waits for an additional signal at step 500.

[0049] Table 1 and other values ​​can be used to indicate which values ​​to use when making tiered adjustments to the system for the device. In another example, the causal module includes weighting factors associated with each error or warning from the monitored device. For example, each factor can be rated on a scale of 0 to 10, where 0 has no effect and 10 indicates that it is critical to the results of the causal module. Each possible cause of error can also have a weighting factor on each possible error and warning. Each cause of error can be rated, for example, on a scale of -10 to 10, where 0 has no effect, -10 indicates a significantly reduced effect, and 10 indicates that it is critical to the results of the causal module.

[0050] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms for implementing the claims.

Claims

1. An instrument management device, comprising: A monitoring module (205) for a first device, wherein the first device is configured to obtain measurement data from a second device, compare the measurement data with a reference value, and send a signal when the measurement data indicates an error condition when compared with the reference value; A recommendation module (210) is configured to receive the signal from the monitoring module (205), analyze the signal, and generate one or more recommendations associated with the error condition by using a causal module (230), the causal module (230) including a data structure having at least one row and at least one column, the recommendation module (210) being configured to access data items from one row or one column of the causal module (230); Ticket generation module (215), the ticket generation module is configured to receive one or more recommendations including the data item, obtain a solution to the error condition by changing the state of the second device, and generate a data packet associated with the solution to the error condition; and A machine learning module (225) is configured to use the data packet to determine whether to update the causal module (230), and if so, to change the data item in a row of the row or a column of the column.

2. The device according to claim 1, wherein the first device has a microprocessor and a memory.

3. The device of claim 2, wherein the measurement data is associated with a general measuring device.

4. The device according to claim 3, wherein the error condition indicates an error.

5. An instrument management system, comprising: A monitoring system (205) for a first device, wherein the first device is configured to obtain measurement data from a second device, compare the measurement data with a reference value, and send a signal when the measurement data indicates an error condition when compared with the reference value; A recommendation system (210) is configured to receive the signal from the monitoring system (205), analyze the signal, and generate one or more recommendations associated with the error condition by using a causal table, the causal table comprising a data structure having at least one row and at least one column, the recommendation system (210) being configured to access data items from a row of the causal table or a column of the causal table; Ticket generation system (215), the ticket generation system being configured to receive one or more recommendations including the data items, obtain a solution to the error condition by changing the state of the second device, and generate a data packet associated with the solution to the error condition; and A machine learning system (225) configured to use the data packet to determine whether to update the causal table, and if so, to change a row in the row or a column in the column of the data item.

6. The system of claim 5, wherein the first device has a microprocessor and a memory.

7. The system of claim 6, wherein the measurement data is associated with a general measuring device.

8. The system of claim 7, wherein the error condition indicates an error.

9. An instrument management method, comprising: Obtain measurement data from the device; The measurement data is compared with the reference value; A signal is received when the measured data indicates an error condition compared to the reference value; One or more recommendations associated with the error condition are generated by using a causal table, the causal table comprising a data structure having at least one row and at least one column, and further comprising accessing data items from a row of the causal table or a column of the causal table; A solution to the error condition can be obtained by changing the state of the device; Generate a data packet associated with the solution to the error condition; as well as The data packet is used to determine whether the causal table should be updated, and if so, the data item in one row of the row or one column of the column is changed.

Images