A computer-implemented method for determining the operating state of an industrial device

Abstract

A computer-implemented method (100) for determining the operating state of an industrial device (1) performing an industrial process, the method (100) comprising: "adding an alarm (2) issued within the device (1) to a first pool (3a) of critical alarms (2);" determining (120) whether a physical state (1c) indicated by a first acquired alarm (2) has caused a second alarm (21) based on the device (1) topology, process, and / or physical state (1c) of a part of the device (1), and if so, moving (130) the first alarm (2) from the first pool (3a) to a second pool (3b) of informational alarms (2); and / or "determining (140) whether a predefined state-related condition (5) is met for at least one first acquired alarm (2), based on the device (1) topology, and / or process, in combination with the physical state (1c) of a part of the device (1), and if this is the case, moving (150) the first alarm (2) from the first pool (3a) to the second pool (3b); and" determining (160) the operating state (1a) of the device (1) and / or a corrective action (1b) based on the alarms (2) in the first pool (3a).

Description

Technical Field

[0001] The present invention relates to determining an operating state of an industrial device from a plurality of alerts issued within the device. Background Art

[0002] Industrial devices typically perform a given process according to a given engineering recipe that specifies which actions will be performed in what order. The successful execution of the process, and in particular the quality of the final product obtained, may critically depend on whether the given recipe is adhered to. Accordingly, it is necessary to monitor the industrial device at many places to detect any deviation from the recipe and device malfunctions. Whenever an abnormal situation is detected, an alert is issued.

[0003] By issuing alerts, the industrial device draws the attention of the device operator so that the operator can perform corrective actions such as changing a faulty part or cleaning a blocked container. However, during the operation of a complex device, a very large number of alerts may be issued at any given time. Similar to log files generated in a computing system, significant information may thus be masked by a large amount of noise, making it difficult to draw correct conclusions from many alerts. Specifically, a human operator faced with a large number of alerts may not even know where to start solving the problem.

[0004] WO 2019 / 104 296 A1 discloses an alert management system to assist an operator in identifying high-priority alerts based on the number of events occurring.

[0005] Object of the Invention

[0006] The object of the present invention is to extract from a large number of alerts those alerts that are particularly meaningful for the operating state of the device, such that the operating state and / or corrective actions for improving the operating state can be easily determined.

[0007] This object is achieved by a computer-implemented method for determining an operating state of an industrial device, wherein the industrial device will perform a given industrial process. Summary of the Invention

[0008] The inventors have developed a computer-implemented method for determining an operating state of an industrial device. The industrial device is configured to typically perform a given industrial process according to a given recipe. Such a recipe details which actions will be performed on one or more isolates in order to manufacture one or more products. Specifically, the topology of the device (including different device parts and their interconnections) can be designed to fit a previously designed recipe.

[0009] Each device part may issue one or more alerts. The most commonly issued alerts are so-called "service alerts" and "process alerts".

[0010] A service alert is issued in response to a service or operation in an industrial device being interrupted or unable to start. Specifically, the industrial device can consist of process modules that can be interconnected and separated from each other again, such that different modular devices can be assembled from a given set of physical process modules available on-site to manufacture different products. In such a setup, each physical process module provides one or more services. When the topology of the device is designed according to a recipe for performing a process, the physical process module can be inserted at a specific location as it provides the specific services required according to the recipe.

[0011] For example, the service can specifically include one or more of the following:

[0012] Heating or cooling a substance and / or maintaining the temperature of the substance at a desired value;

[0013] Agitating a substance;

[0014] Filling at least one container with a desired amount of a substance;

[0015] Discharging a desired amount of a substance from at least one container;

[0016] Incorporating a desired amount of a second substance into a first substance;

[0017] Mixing a mixture of two or more substances by mechanical interaction with the mixture;

[0018] Distilling at least one substance from a mixture of two or more substances;

[0019] Converting at least one substance; and

[0020] Inerting at least one substance.

[0021] When performing each physical action to provide a service, certain variables are monitored and it is checked whether these variables meet predetermined conditions. If such conditions are met, a process alert is issued. For example, a process alert can be issued in response to the temperature, pressure, and / or mass flow deviating from the nominal value or exceeding the upper or lower threshold.

[0022] Specifically, in a modular industrial device, each process module can be configured to monitor the mass flow and / or pressure on each of its input and output ports. Each module itself does not "know" which other modules it will be interconnected with, but monitoring the mass flow and / or pressure on the ports still allows detection of many faults in the interoperability of the interconnected process modules. For example, a module with normal internal device operation may not be able to obtain sufficient feedstock from an upstream module due to a valve being closed or a pipeline being blocked. In such a case, the pressure and mass flow at the input port of the working module may drop too low. Similarly, if there is a problem in a downstream module, the working module's output port may pump against a closed valve in the input port of the downstream module. In such a case, the pressure at the output port of the working module may climb too high, and the mass flow at that output port may drop to zero. At the same time, if the mass flow is also assumed to transfer heat flow to the downstream module, the temperature at that output port may climb too high.

[0023] Process alarms are indications of problems, but do not necessarily mean that the overall operation of the industrial device is affected. Specifically, the alarm thresholds for process alarms can be set relatively strictly, such that for example, the device can physically withstand overpressure for a period of time. If corrective action can be taken within this period, the operation of the device may continue without interruption.

[0024] However, a service alarm means that certain specific actions assumed to be performed according to a process recipe cannot be carried out. If the product to be serviced cannot be obtained from another source, such as from another module connected in parallel with the faulty module, or from a certain reservoir, then the fault indicated by the service alarm may stop the entire industrial process.

[0025] Therefore, in the context of an industrial device, service alarms may have a higher priority than process alarms.

[0026] From the examples presented above, it is obvious that a single event (such as a closed valve on the input port of a faulty module) may trigger multiple alarms, such as overpressure, overtemperature, and underflow on the output port of an upstream module. In addition to these alarms, the faulty module itself may issue more process alarms, and if the fault cannot be compensated for in some way, a service alarm may be issued. If all these alarms are presented to the operator, the operator may be overwhelmed by information overflow and not know where to start solving the problem. Similarly, if the operating state of the device is evaluated by a machine, it is difficult to extract significant information from the noise.

[0027] The solution to this problem starts with obtaining multiple alerts issued within the device. Initially, all these alerts are added to a pool of critical alerts. Later, the operating state of the device and / or corrective actions for improving that operating state will be determined based on the alerts in the pool of critical alerts. But first, the alerts are filtered according to one or both of the two criteria presented below, and this filtering causes some alerts to be moved from the pool of critical alerts to a pool of informational alerts. Here, "informational" may specifically mean that the alert does not immediately draw attention but is saved in a file to track the problem in the device that caused the alert.

[0028] For at least one first obtained alert, it can be determined whether the physical state of the device or any of its parts indicated by that alert has caused the issuance of a second alert that has also been obtained. This determination is based at least in part on the topology of the device and / or a given industrial process and / or the physical state of the device or any of its parts. If the state indicated by the first alert has caused the second alert to be issued, then the first alert is moved from the pool of critical alerts to the pool of informational alerts.

[0029] The reasoning behind this is that in the context of industrial equipment, if the state indicated by the first alert causes the second alert to be issued, then this second alert indicates a high likelihood of problem escalation and needs to be addressed more urgently than the initial problem indicated by the first alert. An old pre-industrial proverb says: "For want of a nail, the shoe was lost; for want of a shoe, the horse was lost; for want of a horse, the rider was lost; for want of a rider, the battle was lost; for want of a battle, the kingdom was lost; all for the want of a nail." This is even more true in industrial settings, where the process recipe clearly defines the correlations between successive processing steps and between different equipment parts.

[0030] In the example presented above, the root cause of the closed valve in the input port of the faulty module may be overpressure in the reaction vessel of that faulty module. With the help of a safety interlock circuit, in response to the overpressure that has caused the first process alert to be issued, the valve on the input port of the faulty module is closed. This in turn causes other process alerts to be issued on the output port of the upstream working module. In addition to this, more process alerts may be issued in the faulty module, such as low mass flow at the input port, too high a temperature in the reaction vessel (because the vessel is no longer adequately cooled by that mass flow), and low mass flow at the output port. The ultimate consequence of the initial fault may be further downstream, too little of the product to be produced by the faulty module, and the service that requires that product is thus stopped, resulting in the issuance of a service alert.

[0031] In this case, what really needs attention is the service alert, as this has the potential to bring the whole process to a halt. To avoid this consequence, the remedial efforts should be focused on this area, for example: "Now, regardless, put more of this substance into the service and worry about everything else later." The best short-term solution may have nothing to do with the root cause of the problem. For example, the input port of the module where the service has stopped working can be connected to a different process module that supplies the required substance, or even to an emergency reservoir of the required substance, so that the process can continue while the root cause is being traced. If the operator has been presented with too many process alerts, this may lead to a rather inappropriate reaction, namely, starting to deal with the faulty module in detail while the equipment is producing nothing. This can be done later, and then the alerts from the information alert pool can be used to trace the root cause.

[0032] This example shows that each acquisition alert in the acquisition alerts can be specifically marked with a priority, and if the state indicated by the first alert has caused a second alert with a higher priority to be issued, the first alert can be moved to the information alert pool. But even if only alerts of the same priority (such as only process alerts) are considered, there is still a tendency for the problem indicated by the second alert to be magnified compared to the problem indicated by the first alert.

[0033] In this example, the best short-term remedy (i.e., putting the required substance into the closed service) has also been achieved by a very simple method of moving all process alerts to the information alert pool, only retaining the service alerts in the important alert category. But this will eliminate the chance of detecting any other problems early before they become major problems. As discussed above, the whole point of having process alerts is to be able to remedy problems before they escalate to service outages or even the entire industrial process. By classifying alerts as "informative" to those within the causal chain of important alerts, significant information in other process alerts is retained, so that the signal-to-noise ratio is increased without increasing the tendency for larger problems to occur.

[0034] Alternatively or in combination with the classification based on the causal chain, for at least one acquisition alert, in combination with the physical state of the device or any of its parts, it can be determined whether a predetermined state-related condition is met, at least in part based on the topology of the device and / or the given industrial process. If the condition is met, then the alert will be moved from the important alert pool to the information alert pool. The reason behind this is that many of the conditions that cause process alerts to be issued are only relevant to the operation of the entire industrial process during certain situations.

[0035] In the toy example, for a roll-on / roll-off vehicle ferry, it would surely be advantageous to emit an audible warning on the bridge if the ferry is about to leave the port while the large loading door is still open. When the ferry is moored at a port where loading is taking place, the open door is not a problem. Nevertheless, the sensor registering whether the door is open should always be operational so that if a problem occurs it can be immediately identified. However, when the ship is moored at the port, the audible alarm should not sound continuously.

[0036] By filtering out process alarms that are irrelevant due to the situation, unnecessary alarm clutter is avoided while the monitoring of variables within the device can still remain active.

[0037] For example, although service alarms for a particular service may generally have a higher priority than process alarms, if a service alarm occurs at a time when the service is not actually needed, then the service alarm is only relevant to the overall process. There may be many services that are only intermittently needed, so during times when the service is not required, whether the state of the device permits the start of the service is not important.

[0038] This is particularly important in a situation where a process module is used in a device as a shared resource to manufacture a product that will be used as a feedstock in different downstream services. For example, the same tempering module can be used at one time to heat substance A for a first downstream module, and it can be used at another time to cool substance B for a second downstream module. At any given time, either the first downstream module or the second downstream module may be active, but they can never be active simultaneously. Therefore, at any time, one of the two downstream modules will emit a service alarm even if the device is working perfectly as expected. Every alarm in the device that is not a real problem is a bad thing because it tends to desensitize the operator to alarms. The next time an alarm occurs, they may think "Well, it's just always on, it's okay", but if they think there's an error, they should actually not respond.

[0039] Both filtering methods (i.e., filtering according to the causal chain and filtering according to state-related conditions) can be used in sequence. The order of the sequence has an impact on the final result and can be chosen according to the specific requirements of the industrial device under consideration.

[0040] For example, in the case where the causal chain of a process alert is escalated to a service alert, first, the causal chain is evaluated such that all process alerts will be classified as informational alerts, so that only the service alert will remain as a critical alert. If it is then determined that the service alert is not critical because the service is not currently in use, then all alerts will be in the informational alert pool and will not be retained in the critical alert pool. However, if the service alert is classified as an informational alert only because the service is not currently in use and then the causal chain of the process alert is evaluated, then the last process alert issued before the escalation to the service alert will be retained in the critical alert pool. All other alerts will be in the informational alert pool.

[0041] In a particularly advantageous embodiment, determining whether a process alert has led to a service alert is at least partially based on a set of rules. Each rule specifies that, in response to one or more process alerts, a service alert will be issued.

[0042] For example, if the mass flow of either substance is below a threshold, if the pressure in the mixing vessel climbs too high, or if the motor current of the stirrer is above a threshold, a combined stirring and mixing module that receives two substances and mixes them by stirring may issue a service alert for the service "stirring and mixing". For each variable, there may be different process alerts associated with different thresholds. For example, at a first threshold, a "high" process alert for pressure may be issued, and at a higher second threshold, a "high - high" process alert for the same pressure may be issued. Then, the rule can specify that only the "high - high" pressure will issue a service alert, such that the service alert can be retained in the critical alert pool while the high - high pressure process alert can be moved to the informational alert pool. If the pressure is only high enough to issue a high - pressure process alert, the service alert may not be issued and the high - pressure process alert may be retained in the critical alert pool.

[0043] Rules can also combine multiple conditions. For example, if the duration of the over - current in the stirrer motor exceeds the time the motor is designed to withstand that over - current, it may only result in a service alert.

[0044] The rules in the set of rules can come from any source. Specifically, they can be designed. But preferably, as many rules as possible are automatically generated.

[0045] One way to achieve this is to determine for at least one service or operation of the device that the service or operation utilizes at least one resource of the device. In a modular device, the resource may be within the same module, but the resource can also be, for example, another module from which the module performing the service or operation obtains input. For at least one process alert that can be issued for the resource being used, then a rule can be created such that, in response to the process alert being issued, a service alert will be issued.

[0046] This can be refined because process alerts that may cause a service alert to be issued must be specifically related to the state variables upon which the operation of the service depends. For example, if the service downstream of the agitation mixing module requires a certain mass flow of the agitated mixed product, a process alert for the agitation mixing module indicating a low output mass flow of the product may cause a service alert for the downstream service to be issued. However, an overcurrent in the agitator motor will not immediately affect the quality or quantity of the agitated mixed product, so this process alert may not cause a service alert for the downstream service to be issued.

[0047] Another way of generating rules begins with determining that a service or operation requires a particular state of a device or any part thereof. Based at least in part on the topology of the device and / or a given industrial process, it is then determined that the issuance of a particular process alert will cause the device or part thereof to switch to a state different from the required state. Then a rule is created such that in response to the process alert being issued, a service alert will be issued.

[0048] For example, a service or operation may require certain valves to be open so that a segregate can be drawn in, and certain valves to be closed so that the segregate cannot escape until the service or operation is complete. However, the issuance of certain process alerts may immediately change the configuration of the valves, regardless of which configuration the process currently requires. For example, if overpressure in a container is detected, a safety circuit may open a valve to release the pressure, even if the valve was previously intentionally closed for the execution of the service or operation. Also, a process alert that the module housing has been manually opened may prompt an interlock circuit to cut off certain hazardous components of the module, such as a high-voltage power supply or a laser.

[0049] Therefore, it can be specifically determined, at least in part based on safety or interlock functions in the topology of the device, that the issuance of a particular process alert will cause the device or part thereof to switch to a state different from the required state.

[0050] In the case where the service is specifically a service provided by a process module of a modular industrial device, the process alert that can trigger a service alert for that service can specifically be a process alert issued when a predetermined condition is met within the same process module. Specifically, the process module can be designed to check all conditions for the service operation through its own sensors, without having to rely on communication of process alerts from other modules. If the process module is self - contained in this way, the need to monitor the required variables does not impose any further conditions on the combination of this module with other modules. Then physical process modules from a given on - site inventory can be combined more flexibly.

[0051] Specifically, at least one rule in the rule set can be generated at least in part based on the metadata of the process module interface. For example, this metadata can be obtained from the module type package MTP description of the module, which is currently standardized to the VDI standard 2658. This ensures that even if modules from different manufacturers are combined in a device, the computerized generation of rules will be able to evaluate the description and draw the correct conclusions as to which process alerts may lead to which service alerts being issued.

[0052] Specifically, at least one rule may already be built into the metadata of the process module interface (such as MTP). Specifically, if the module is self - contained in the sense that it checks all the conditions of its service operation as described above by itself, the rule may have been formulated when designing the module.

[0053] The module can then be sold together with the added value of the alert management, so that no additional work needs to be performed on - site to implement the alert management.

[0054] In yet another particularly advantageous embodiment, determining whether the physical state of the device or any of its parts indicated by a first acquired alert has caused a second acquired alert specifically includes simulating the behavior of the device in response to the physical state. In this way, the filtering of the above - mentioned alerts can be extended to parts of the device, such as modules, for which no machine - readable metadata is available. For example, a modular device may also include old modules for which no MTP is available. Moreover, the topology of the device may contain interdependencies between modules, and the behavior of these modules cannot be fully described by aggregating information from the corresponding MTPs.

[0055] For example, the safety or interlock functions in the device topology outside the module are not described in any MTP. For example, a factory floor where a modular device is assembled from physical process modules may be equipped with a leak detector that will cut off the water supply in case of a leak.

[0056] Therefore, the simulation can specifically include a state change triggered by the safety or interlock function in the device topology in response to the state indicated by the first acquired alert.

[0057] In yet another particularly advantageous embodiment, the representation of the alerts in the pool of important alerts is rendered on at least one display device. As discussed before, the alerts that then appear on the display device are a clearer and more concise indication for the operator of the device as to which short - term corrective actions should be taken to keep the device running as a whole or to return it to a functional state as quickly as possible.

[0058] Preferably, at least one hyperlink is provided in association with the representation of at least one alert in the critical alert pool to at least one other alert that has been moved to the informational alert pool because it has caused a critical alert.

[0059] In this way, the operator is assisted in tracing the root cause of the problem that caused the critical alert.

[0060] Alternatively or in combination, on at least one display device, at least one representation of the physical state that has caused at least one alert to move from the critical alert pool to the informational alert pool can be rendered. In this way, the operator is given an indication of why an alert he might have expected was not issued.

[0061] In the example of a tempering module for heating or for cooling, the representation of the physical state can indicate for which purpose the tempering module is currently being used. The operator then knows that when the module is being used for heating, alerts related to cooling are not displayed, and vice versa.

[0062] Optionally, a hyperlink can be provided in association with the representation of the physical state to at least one alert that does not move to the informational alert pool due to a particular physical state. This assists the operator in preparing the device for a different physical state related to these alerts.

[0063] For example, if the process is being performed in a vacuum and the chamber is open for maintenance, then many alerts will not require immediate attention because the process is not currently running anyway. Instead of alerts, the display can then indicate that the pressure in the chamber is 1*10 +3 mbar. But before evacuation, the operator can click on this indication in order to check if anything needs to be repaired while the chamber is still open. For example, if one of the process alerts indicates that the filament of the evaporator does not allow any current to pass through, the operator may be reminded of this, thus avoiding disappointment after evacuation.

[0064] In yet another particularly advantageous embodiment, in response to at least one alert in the critical alert pool, a control signal is provided to at least one actuator of the device. The purpose of this control signal is to move the device towards a physical state in which

[0065] the problem that has caused the alert is alleviated, and / or

[0066] if the problem persists, the tendency for damage to the device is reduced.

[0067] For example, if certain substances are lost due to the operation of the service, then the control signal can be used to switch to a different source of the substance, such as another module that produces the substance or an emergency reservoir of the substance.

[0068] For example, the tendency to break can be reduced by shutting down components that may break if the problem persists or worsens, or by shutting off one or more valves to contain the problem within a part of the device.

[0069] As detailed above, many advantages of the method are brought about by the computerization of the method. Accordingly, the present invention also provides a computer program having machine-readable instructions that, when executed by one or more computers and / or industrial control systems, cause the one or more computers and / or industrial control systems to perform the above-described method. The present invention also provides a non-transitory computer storage medium and / or download product having the computer program. BRIEF DESCRIPTION OF THE DRAWINGS

[0070] In the following, the present invention will be illustrated with the aid of the drawings, without, however, intending to limit the scope of the present invention. The drawings show:

[0071] Figure 1 : an exemplary embodiment of method 100;

[0072] Figure 2 : an exemplary incorporation module 10 having a source of process alarms 2b;

[0073] Figure 3 : an exemplary simple device consisting of two incorporation modules 10, 10'; DETAILED DESCRIPTION

[0074] Figure 1 is a schematic flow chart of an exemplary embodiment of method 100. In step 110 of method 100, a plurality of alarms 2 issued within device 1 are acquired. These alarms are initially all added to a pool 3a of critical alarms 2.

[0075] In step 120, it is determined whether the physical state 1c of device 1 indicated by a first acquired alarm 2 has caused a second alarm 2' that has also been acquired. In the case where such a causal pair 2, 2' is found, in step 130, the corresponding first alarm (cause) 2 is moved to an information alarm pool 3b.

[0076] In step 140, it is determined whether alarm 2 satisfies a condition 5 that is independent of the specific physical state 1c of the device 1 to which it belongs. If this is the case (true value 1), then in step 150, the alarm 2 is moved to the pool 3b of information alarms 2.

[0077] In step 160, the operating state 1a of device 1 and / or a corrective action 1b for improving the operating state 1a are determined based on the alarms 2 that are still in the pool 3a of critical alarms 2 (i.e., the alarms 2 that have not yet been moved to the pool 3b of information alarms 3). The pool 3a of critical alarms and the pool 3b of information alarms can still be used for further evaluation.

[0078] In step 170, the representation of alert 2' in pool 3a of critical alert 2 can be rendered on the display device. In step 175, a hyperlink can be provided from these alerts 2' to other alerts 2 that have been moved to information alert pool 3b due to these critical alerts 2'.

[0079] In step 180, the representation of physical state 1c that has caused alert 2 to be moved to information alert pool 3b can be rendered on the display device. In step 185, a hyperlink to this alert 2 can be provided.

[0080] In step 190, a control signal can be provided to at least one actuator of the device to move device 1 to a more favorable physical state 1c.

[0081] Within block 120, embodiments of how the causal relationship between alerts 2 and 2' can be established are detailed.

[0082] According to block 121, this relationship can be established based on rule set 4.

[0083] According to block 128, the relationship is specifically established between process alert 2b and service alert 2a issued within the same physical process modules 10, 10' that define the set of available services.

[0084] According to block 129, the behavior of device 1 is simulated to establish the causal relationship.

[0085] Within block 121, exemplary embodiments of how rule 4 can be obtained are detailed.

[0086] According to block 122, the resources used by a service or operation can be determined, and according to block 123, a rule can be created such that in response to at least one process alert 2b that may be issued by the resource, service alert 2a will be issued.

[0087] According to block 124, it can be determined that a service or operation requires a certain specific state 1c of device 1 or a part thereof. According to block 125, it can be determined that the issuance of process alert 2b will cause device 1 or a part thereof to switch to a state 1c different from the required state 1c. Specifically, according to block 125a, this may be the result of a safety or interlock function in the topology of device 1. According to block 126, rule 4 can be created such that in response to process alert 2b being issued, service alert 2a will be issued.

[0088] According to block 127, at least one rule 4 can be generated at least in part based on the metadata of the process module interface. Specifically, according to block 127a, the process module interface can specifically include at least one such rule 4.

[0089] Figure 2 An exemplary incorporation module 10 is shown. The incorporation module 10 is configured to aspirate a substance via its input port 11 and deliver a limited quantity of the substance via its output port 12a. A buffer container 16 is provided to temporarily store the substance so as to decouple the speed and pressure at which the substance can be incorporated at the output port 12a from the speed and pressure at which the substance is available at the input port 11. The incorporated substance is pumped to the output port 12a by a pump 17.

[0090] Thus, the incorporation module 10 provides two services, namely, possible actions: "filling" and "incorporating". To this end, the incorporation module 10 has a first valve 13a in the pipeline from the input port 11 to the buffer container 16 and a second valve 13b in the pipeline from the buffer container 16 to the output port 12a. For safety reasons, a pressure relief valve 13c is also provided in the pipeline from the buffer container 16 to the pressure relief port 12b.

[0091] Three basic parameters to be monitored in the incorporation module 10 are the pressure p1 in the pipeline from the input port 11 to the buffer container 16, the pressure p2 in the buffer container 16, and the mass flow f in the pipeline from the buffer container 16 to the output port 12a.

[0092] The pressure p1 is monitored by a pressure sensor 14a. If the pressure p1 climbs too high, then the valve 13a will be automatically closed and a process alarm 2b will be issued. In this state, no further substance can be aspirated, so a service alarm 2a for the "filling" service will be issued, and this will cause the process alarm 2b to be moved to the pool 3b of the information alarm 2. If filling is in progress, it will be put on hold.

[0093] The pressure p2 is monitored by a pressure sensor 14b. If the pressure p2 climbs too high, then the valve 13c will be automatically opened and a process alarm 2b will be issued. In this state, no further substance can be aspirated either, so the service alarm 2a for the "filling" service will be issued again, and if filling is in progress, it will be put on hold. The service alarm 2a will cause the process alarm 2b to be moved to the pool 3b of the information alarm 2.

[0094] The mass flow f is monitored by a flow sensor 15. If the mass flow f drops too low, a process alarm 2b will be issued. In this state, reliable incorporation of the substance is not possible, so a service alarm 2a for the "incorporating" service will be issued and the pump 17 will be automatically stopped. If incorporation is in progress, depending on the magnitude of the deficiency of the mass flow f, it will be temporarily stopped or aborted completely.

[0095] The service alarm 2a will cause the process alarm 2b to be moved to the pool 3b of the information alarm 2.

[0096] Thus, the process alarms 2b issued by the pressure sensors 14a and 14b may affect the service "filling", and the process alarm 2a issued by the mass flow sensor 15 may affect the service "admixture". Any process alarm 2b that does not affect the service with the service alarm 2a present (e.g., overpressure p2 when there is a service alarm 2a for admixture) will be retained in the pool 3a of critical alarms 2.

[0097] According to the module type packaging MTP, on the one hand, the relationships between different process alarms 2b and service alarms 2a, and on the other hand, the automatic actions of the device and the consequences of the currently running services are included in the metadata in the process module interface.

[0098] The MTP also contains requirements for each service operation. For the service "filling", the valve 13a in the filling pipeline to the buffer container 16 must be opened, but the pressure reducing valve 13c from the buffer container 16 to the pressure reducing port 12b must be closed. For the service "admixture", the valve 13b in the pipeline to the pump 17 must be opened, and the pump 17 must be running.

[0099] If it is intended to run a service, but one of the conditions for the service is not met due to some reason (such as the valve being opened or closed due to a process alarm 2a, or a power failure in the pump 17), then the service alarm 2a for the corresponding service is issued. Note that in this example, the requirements for the services "filling" and "admixture" do not conflict with each other, so these two services can be run simultaneously. If it is not intended to run a service, violating the corresponding conditions will not result in a service alarm 2a.

[0100] Figure 3 A very simple device 1 consisting of two admixture modules 10, 10' is shown. The output port 12a of the first admixture module 10 is connected to the input port 11' of the second admixture module 10'. Like the first admixture module 10, the second admixture module 10' also has its output port 12a' and pressure reducing port 12b'.

[0101] As discussed previously, alarms can propagate in this device, for example, from the second admixture module 10' to the first admixture module 10. If the pressure p1 in the second admixture module 10' climbs too high, then the valve 13a in the input port 11' will be closed. The source of this overpressure is the active "admixture" service in the first admixture module 10. The high pressure p1 in the second admixture module 10' will affect the mass flow f in the first admixture module 10 because its pump 17 pumps relative to the closed valve 13a in the input port 11' of the second admixture module 10'. This will in turn result in a service alarm 2a for the service "admixture" in the first admixture module 10.

[0102] List of reference numerals

[0103] 1 Industrial equipment

[0104] 1a Operating state of equipment 1

[0105] 1b Corrective actions for improving operating state 1a

[0106] 1c Physical state of equipment 1 or its parts

[0107] 2, 2’ Alarms

[0108] 2a Service alarms

[0109] 2b Process alarms

[0110] 3a Pool of critical alarms 2

[0111] 3b Pool of information alarms 2

[0112] 4 Rules for causal relationships between alarms 2, 2’

[0113] 5 State-related conditions with low correlation of alarms 2

[0114] 10, 10’ Incorporation modules

[0115] 11, 11’ Input ports of incorporation modules 10, 10’

[0116] 12a, 12a’ Output ports of incorporation modules 10, 10’

[0117] 12b, 12b’ Pressure relief ports of incorporation modules 10, 10’

[0118] 13a Valves in input ports 11, 11’

[0119] 13b Valves leading to pump 17

[0120] 13c Valves in pressure relief ports 12b, 12b’

[0121] 14a Sensor for pressure p1

[0122] 14b Sensor for pressure p2

[0123] 15 Sensor for mass flow f

[0124] 16 Buffer container

[0125] 17 Pumps in output ports 12a, 12a’

[0126] 100 Method

[0127] 110 Obtain alarm 2

[0128] 120 Determine the causal relationship between alarms 2 and 2'

[0129] 121 Determine the relationship based on Rule 4

[0130] 122 Determine the utilization of resources

[0131] 123 Connect the process alarm 2b of the resource with the service alarm 2a

[0132] 124 Determine the required state 1c of the service

[0133] 125 Determine that the process alarm 2a changes the state 1c

[0134] 125a Determine 125 based on the safety or interlock function

[0135] 126 Connect the process alarm 2b with the service alarm 2a

[0136] 127 Generate Rule 4 based on the process module interface metadata

[0137] 127a Obtain Rule 4 directly from the process module interface metadata

[0138] 128 Connect the process alarm 2b and the service alarm 2b within the modules 10 and 10'

[0139] 129 Simulate the behavior of the device 1

[0140] 130 Move the "cause" alarm 2 to the pool 3b

[0141] 140 Determine whether the alarm 2 is less relevant due to condition 5

[0142] 150 Move the alarm 2 to the pool 3b

[0143] 160 Evaluate the operating state 1a and the corrective action 1b

[0144] 170 Render the representation of the important alarm 2' in the pool 3a

[0145] 175 Provide a hyperlink to the alarm 2 in the pool 3b

[0146] 180 Render the representation of the state 1c on which condition 5 depends

[0147] 185 Provide a hyperlink for condition 5 to the alarm 2 sent to the pool 3b

[0148] 190 Provide a control signal to improve the physical state of the device 1

Claims

1. A computer-implemented method (100) for determining the operating state of an industrial device (1), wherein the industrial device (1) is configured to perform a given industrial process, the method (100) comprising: · Obtaining (110) a plurality of alarms issued within the device (1) and adding these alarms to a pool (3a) of critical alarms; · For at least one first alarm among the obtained alarms, determining (120), at least in part based on the topology of the device (1), and / or the given industrial process, and / or the physical state (1c) of the device (1) or any part thereof, whether the physical state (1c) of the device (1) or any part thereof indicated by the alarm has caused a second alarm that has also been obtained and is in the pool (3a) of critical alarms, where the second alarm represents an escalation of the original problem indicated by the first alarm and needs to be resolved more urgently than the original problem, and if so, moving (130) the first alarm from the pool (3a) of critical alarms to a pool (3b) of informational alarms; and / or · Based on the alarms in the pool (3a) of critical alarms, determining (160) the operating state (1a) of the device (1) and / or a corrective action (1b) for improving the operating state (1a).

2. The method (100) according to claim 1, further comprising: For at least one first alarm, determining (140), at least in part based on the topology of the device (1) and / or the given industrial process, in combination with the physical state (1c) of the device (1) or any part thereof, whether a predetermined state-related condition (5) is satisfied, and if so, moving (150) the first alarm from the pool (3a) of critical alarms to the pool (3b) of informational alarms.

3. The method (100) according to any one of claims 1 to 2, wherein each alarm is marked with a priority, and wherein the second alarm caused by the physical state (1c) indicated by the first alarm has a higher priority than the first alarm.

4. The method (100) according to any one of claims 1 to 2, wherein the alarms at least include · Alarms from a first type of service alarm (2a) issued in response to a service or operation in the industrial device (1) being interrupted or unable to start; and · Alarms from a second type of process alarm (2b) issued when a predetermined condition of one or more physical acquisition variables of the device (1) or any part thereof is satisfied, wherein the first type of service alarm (2a) has a higher priority than the second type of process alarm (2b).

5. The method (100) according to claim 4, wherein the service specifically includes one or more of the following: · Heating or cooling a substance and / or maintaining the temperature of the substance at a desired value; · Agitating a substance; · Filling at least one container with a desired amount of a substance; · Discharging a desired amount of a substance from at least one container; · Incorporating a desired amount of a second substance into a first substance; · Mixing a mixture by mechanical interaction with a mixture of two or more substances; · Distilling at least one substance from a mixture of two or more substances; · Converting at least one substance; and · Inerting at least one substance.

6. The method (100) according to claim 4, wherein at least one process alarm (2b) is specifically issued in response to a temperature, pressure, and / or mass flow deviating from a nominal value or exceeding an upper threshold or a lower threshold.

7. The method (100) according to claim 4, wherein the determination (120) of whether a process alarm (2b) has resulted in a service alarm (2a) is at least partially based on (121) a set of rules, where each rule specifies that a service alarm (2a) will be issued in response to one or more process alarms (2b).

8. The method (100) according to claim 7, wherein at least one rule in the set of rules is generated by: · Determining (122) that a service or operation utilizes at least one resource of the device (1); and · Creating (123) a rule for at least one process alarm (2b) that can be issued for the resource, such that a service alarm (2a) will be issued in response to the process alarm (2b) being issued.

9. The method (100) according to claim 8, wherein the process alarms (2b) that can be issued for the resource specifically relate to state variables on which the operation of the service depends.

10. The method (100) according to claim 7, wherein at least one rule in the set of rules is generated by: Determining (124) that a service or operation requires a specific physical state (1c) of the device (1) or any part thereof; At least partially based on the topology of the device (1) and / or the given industrial process, determining (125) that the issuance of a specific process alarm (2b) will cause the device (1) or a part thereof to switch to a physical state (1c) different from the required physical state (1c); and Creating (126) a rule such that a service alarm (2a) will be issued in response to the process alarm (2b) being issued.

11. The method (100) according to claim 10, wherein it is specifically determined (125a) that the issuance of a specific process alarm (2b) will cause the device (1) or a part thereof to switch to a physical state (1c) different from the required physical state (1c) at least partially based on a safety or interlock function in the topology of the device (1).

12. The method (100) according to claim 4, wherein at least one service in the industrial device (1) is specifically a service provided by a process module (10) of the industrial device (1), and the process alarm (2b) that can trigger a service alarm (2a) for the service is specifically a process alarm (2b) issued when a predetermined condition within the same process module (10, 10’) is satisfied.

13. The method (100) according to claim 12, wherein at least one rule in the set of rules is generated (127) at least in part based on metadata of the process module interface.

14. The method (100) according to claim 13, wherein the metadata of the process module interface specifically includes (127a) at least one rule in the set of rules.

15. The method (100) according to any one of claims 1 to 2, wherein determining (120) whether the physical state (1c) of the device (1) or any part thereof indicated by the first alert has caused the second alert specifically comprises: Simulate (129) the behavior of the device (1) in response to the physical state (1c).

16. The method (100) according to claim 15, wherein the simulation (129) specifically includes a state change triggered by a safety or interlock function in the topology of the device (1) in response to the physical state (1c) indicated by the first alert.

17. The method (100) according to any one of claims 1 to 2, further comprising: Render (170) a representation of the alerts in the pool (3a) of critical alerts on at least one display device.

18. The method (100) according to claim 17, further comprising: Provide (175) at least one hyperlink to another alert in association with the representation of at least one alert in the pool (3a) of critical alerts, the other alert having been moved to the pool (3b) of informational alerts due to having caused the critical alert.

19. The method (100) according to any one of claims 1 to 2, further comprising: Render (180) at least one representation of the physical state (1c) that has caused at least one alert to move from the pool (3a) of critical alerts to the pool (3b) of informational alerts on at least one display device.

20. The method (100) according to claim 19, further comprising: Provide (185) a hyperlink to at least one alert in association with the representation of the physical state (1c), the at least one alert having been moved to the pool (3b) of informational alerts due to the physical state (1c).

21. The method (100) according to any one of claims 1 to 2 further comprises: In response to at least one alert in the pool (3a) of critical alerts, provide (190) a control signal to at least one actuator of the device (1) to move the device (1) towards the following physical state (1c): · The problem that has caused the alert is mitigated, and / or · If the problem persists, the tendency for damage to the device (1) is reduced.

22. A computer program product comprising machine-readable instructions that, when executed by one or more computers and / or industrial control systems, cause the one or more computers and / or the industrial control systems to perform the method (100) according to any one of claims 1 to 21.

23. A non-transitory computer storage medium having stored thereon machine-readable instructions that, when executed by one or more computers and / or industrial control systems, cause the one or more computers and / or the industrial control systems to perform the method (100) according to any one of claims 1 to 21.

Images