Enhanced pairing in agent-based process automation

Abstract

A method for automating a process plant includes the representation of field components by respective agents. Requests are generated by requesting agents with defined priority values and with penalty values that are updated as the requests are forwarded via neighboring agents. If an agent in the path of a forwarded request is capable of reacting to it, a convenience value is set by that agent for reacting to the request. The information from the requesting agents and reacting agents is collected by a pairing service and is used compute a reward for each possible combination of a requesting agent and a reacting agent. The reward is defined such that the reward increases with priority value and with convenience value and decreases with penalty value. An optimal pairing between requesting agents and reacting agents is determined such that a sum total of the rewards of all pairings is maximized.

Description

ENHANCED PAIRING IN AGENT-BASED PROCESS AUTOMATIONTECHNICAL FIELD

[0001] The present disclosure relates to automation of process plants, and in particular, to an agent-based process automation in which components of a process plant, such as actuators, sensors, process equipment, etc., are represented by agents.BACKGROUND

[0002] Process plant automation may typically involve recording measurement signals from the physical process, evaluating automation logics (closed-and open-loop controls, including sequences and interlocks) , and sending the corresponding commands to the process plant’s actuators. The automation software may be run on a centralized automation server.

[0003] In traditional process plant automation, the automation software may be engineered manually by correspondingly experienced persons or automatically by using appropriate engineering tools. In case of manual engineering, significant engineering efforts may be required. Even in case of automated engineering, certain tasks, e.g., connecting sensors and actuators to a control loop, may still need to be carried out manually. Furthermore, if the topology of the physical plant is changed, e.g., by adding or removing certain sensors or actuators, the engineering of the automation software must be changed accordingly. The same may apply if the requirements for automatic plant operation like recipes are modified. Additionally, the current engineering may not be valid anymore if certain sensors or actuators drop out. Thus, significant engineering efforts may be required in the beginning, as well as for any change in plant configuration later. Additionally, plant flexibility and availability may be limited.

[0004] To increase plant flexibility and reduce engineering efforts, an agent-based approach to process automation may be adopted, an example of which has been disclosed in the patent publication WO 2022207107 A1. In this approach, field components (e.g., sensors, actuators, process equipment, etc. ) may be represented by self-organizing agents where an agent can communicate with neighboring agents (in a topological sense) and is configured to generate a  request based on its present needs, forward a request or react to a request generated by another agent. Improvements are desirable to augment this approach in order to provide a reliable and robust solution for a wide range of scenarios involving multiple requesting agents and multiple reacting agents.SUMMARY

[0005] Briefly, aspects of the present disclosure provide an improved methodology for pairing between requesting agents and reacting agents in agent-based process automation that can address at least the above-mentioned technical problems.

[0006] A first aspect of the disclosure provides a method for automating at least part of a process plant comprising a plurality of field components represented by respective agents. The method comprises carrying out by a requesting agent: generating a request associated with a defined a priority value and an updatable penalty value, forwarding the request to one or more neighboring agents and communicating information on the request to a pairing service. The method further comprises carrying out by a receiving agent: receiving a forwarded request, updating the penalty value and forwarding the request to a next neighboring agent along a request path, and, if capable of reacting to the request, defining a convenience value for reacting to the request and communicating the convenience value and the updated penalty value to the pairing service. Thereby requests generated by multiple requesting agents are each forwarded along one or more request paths, wherein each request path is defined by a chain of receiving agents that include one or more reacting agents. The method further comprises carrying out by the pairing service: using information collected from the requesting agents and the reacting agents to compute a reward for each possible combination of a requesting agent and a reacting agent, the reward defined such that the reward increases with priority value and with convenience value and decreases with penalty value, and determining an optimal pairing between requesting agents and reacting agents such that a sum total of the rewards of all pairings is maximized.

[0007] A further aspect of the disclosure is directed to a computer program product for implementing the above-described method.

[0008] Additional technical features and benefits may be realized through the techniques of the present disclosure. Embodiments and aspects of the disclosure are described in detail herein and are  considered a part of the claimed subject matter. For a better understanding, refer to the detailed description and to the drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The foregoing and other aspects of the present disclosure are best understood from the following detailed description when read in connection with the accompanying drawings.

[0010] FIG. 1 illustrates a control system for a process plant according to an embodiment of the disclosure.

[0011] FIG. 2 shows a simplified topological representation of portion of a process plant according to an illustrative example.

[0012] FIG. 3A, 3B and 3C illustrate examples of flow requests for a merging pipe branch agent.

[0013] FIG. 4 illustrates an example of a temperature request for a merging pipe branch agent.

[0014] FIG. 5A, 5B and 5C illustrate examples of temperature requests for a splitting pipe branch agent.DETAILED DESCRIPTION

[0015] The present disclosure is directed to improvements in agent-based process automation. An example of an agent-based process automation is disclosed in the above-mentioned patent publication WO 2022207107 A1, which is incorporated by reference herein in its entirety. Such an agent-based process automation deals with the creation of an automation solution based on an interaction between self-organizing agents that are able to generate requests, forward requests to neighboring agents and react on requests generated by other agents. A process plant typically includes a large number of field components or agents, wherein multiple requests may be generated by respective requesting agents and some reacting agents may be capable of reacting to multiple requests. In this case, it may be of critical importance to decide which request should be reacted on by which agent during the operation.

[0016] The methodology of the present disclosure addresses the technical problem of establishing  an optimal pairing between requesting agents and reacting agents in scenarios involving multiple requesting agents and multiple reacting agents. In this context, pairing is referred to as a systematic methodology for determining a unique combination between requesting agents and reacting agents, such that, at a time, one requesting agent is assigned to only one reacting agent.

[0017] In accordance with the disclosed methodology, during a pairing run prior to operation, requests are created by requesting agents and forwarded to other agents in the plant along multiple request paths. To deal with different pairing possibilities, each request is associated with a penalty value, which gets updated (increases or remains unchanged) as the request gets received and forwarded by a chain of neighboring agents. The penalty value thus reflects a limitation to influence a requesting agent by a receiving agent. The present disclosure further improves on this approach by defining a priority value of each request by the requesting agent, and a convenience value set by a reacting agent for reacting to a forwarded request. The three values, namely, the priority value, the convenience value and the (updated) penalty value, are combined to compute a reward for each possible combination of a requesting agent and a reacting agent. The reward is defined as a function of the three values, such that it increases with the priority value and with the convenience value and decreases with the penalty value. An optimal pairing between requesting agents and reacting agents is determined such that a sum total of the rewards of all pairings is maximized. After the pairing run, the process plant can be operated based on a direct communication of request values from the requesting agents to the respective paired reacting agents. The idea behind determining a reward in this manner is to ensure that a higher priority of a request and / or a higher convenience for reacting to the request by reacting agent can offset the effect of increasing distance of the reacting agent from the requesting agent. A reliable and robust solution can thereby be implemented for a wide range of scenarios involving multiple requesting agents and multiple reacting agents.

[0018] Before undertaking a detailed description, certain terms used in the description are explained below.

[0019] A “field component” refers to a device or part of the process plant which interacts with the process. A field component can be, for example, a sensor, an actuator (e.g., pump, valve) , a pipe branch, and process equipment (e.g., tank, heat exchanger, reactor, crystallizer) , among others.

[0020] An “agent” represents one field component of the process plant by way of a piece of  software, which can be executed to carry out defined agent functions. The piece of software may run on the field component itself, if the field component has a required processing capability, or may run on another device, such as a nearby field component, or on a centralized computing system, such as an agent server.

[0021] A “pipe branch” refers to a segment of a pipe network where three or more pipe branches meet (i.e., merging / splitting of flow) . This segment can be represented as an agent according to the disclosed methodology because it can influence one or multiple requests (e.g., flow, temperature, and pressure) . A pipe branch agent is a special agent which is only used during a pairing run.

[0022] A “request” refers to information about a certain need of an agent in the process plant. A request is generated during a pairing run and may carry, among other information, a request type, information about the requesting agent, a priority value, and a penalty value.

[0023] A “request value” or “ReqVal” includes a quantitative measure of a request. A request value is generated during actual operation of the process plant and may, for example, represent the requested quantity in deviation form, i.e., as an incremental change from its current amount.

[0024] A “reaction” refers to performance of a certain activity by an agent towards fulfilling a request or request value generated by another agent.

[0025] A “requesting agent” , a “receiving agent” and a “reacting agent” respectively refer to an agent that generates a request, an agent that receives a forwarded request and an agent capable of reacting to a received request. Note that the three terms need not refer to mutually exclusive agents. For example, a requesting agent, such as a sensor agent, can also be capable of reacting to an incoming request, by adjusting a request value. Furthermore, in some scenarios, a reacting agent, such as an actuator agent, may also generate a request if it has reached an operating limit during operation.

[0026] “Neighboring” agents refers to agents representing field components that are adjacently connected topologically, e.g., via a respective pipe.

[0027] FIG 1 shows a part of a control system 100 for a process plant according to a first aspect of the disclosure. The shown control system 100 is exemplary and represents one possible  implementation of the disclosed methodology. The control system 100 may comprise an operator station server 102 and an operator station client 104. Further, the control system 100 may comprise a plurality of field components, herein including package units 106, 108, sensors / actuators 110, 112, and IO-racks 114, 116 each carrying one or several IO-modules which may be connected to further field components (e.g., sensors / actuators 118, 120, 122, 124) . In addition, the control system 100 may optionally comprise an automation server 126 and an agent server 128.

[0028] A communication network may be established between the field components via hardwired connections (e.g., including physical buses) and / or wireless connections (e.g., using Wi-Fi) . For example, as shown, the operator station server 102, the operator station client 104, the sensors / actuators 110, 112, the two IO-racks 114, 116, the automation server 126 and the agent server 128 may be connected to one another via a bus 130, and optionally, to other components of the control system 100, not shown. For the purpose of operating and monitoring, a user or operator can access the operator station server 102 or other operator station servers (not shown) via the operator station client 104 via the bus 130. The bus 130 can, without being limited thereto, be designed, for example, as an Industrial Ethernet. The sensors / actuators 118, 120 may be connected to an IO-module in one IO-rack 114 via a field bus or via wires 132. Analogously, the sensors / actors 122, 124 may be connected to an IO-module in the other IO-rack 116 via a field bus or via wires 134. Field buses 132, 134 can be designed, without being limited thereto, for example, as an Industrial Ethernet. The bus 130 may thus provide a communication network between the single field components 106, 108, 110, 112, and via the IO-modules in the IO-racks 114, 116, also to the field components 118, 120, 122, 124 of the control system 100. There can also be wireless connections between the field components 106, 108, 110, 112, 118, 120, 122, 124 alternatively or in addition to hardwired connections.

[0029] The automation server 126 may be used for registering input sensor signals from the process plant, archiving the signals, communicating with the operation station server 102, sending output signals to the actuators in case of manual operations and so on. The disclosed embodiment does not require any orchestration software, as it is known from state-of-the-art automation control systems, to be running on the automation server 126.

[0030] There could still be a necessity of an operator station (server and client) to allow the operator of the process plant to interact with the process. This can include, for example, the  visualization of process values and also the possibility to define setpoints or to drive actuators manually. How a process plant shall be automated does not depend on the physical setup of the process plant only. Process plants with the same setup might be automated differently. A certain process plant might run in different operation modes requesting different automatic controls. The definition of corresponding boundary conditions for plant automation, like specific operation modes, can be possible via the operation station (server / client) 102, 104. The operator station (server / client) 102, 104 may also handle the input / output-signals and organize the interaction between the operator station (server / client) 102, 104 and the field components 106, 108, 110, 112, 118, 120, 122, 124.

[0031] To allow an agent-based process automation as it is described herein, each field component configured as an agent needs the information about other agents to which it is adjacently physically connected, i.e., via pipe. Thereby, the single agents do not need all information about the topology of the overall process plant. For example, each pipe section may be individually identified, for example, via RFID or QR-code. Once a field component 106, 108, 110, 112, 118, 120, 122, 124, is connected to a pipe, the information to exactly which pipe section the connection was established may be read and stored in the agent representing the field component 106, 108, 110, 112, 118, 120, 122, 124. Based on this information, by communicating to each other the agents can identify all other agents, which are connected to the same pipe section. In other embodiments, the optional agent server 128, or a superordinate server of the process plant, may include a topological representation of the process plant, such as a process and instrumentation diagram (P&ID) . Based on the topological representation, information may be provided to each agent about its neighboring agent.

[0032] The field components, including the sensors / actuators 110, 112, 118, 120, 122, 124, as well as the pipe branches (not shown in FIG. 1) may be represented as agents by way of a respective piece of software that can be executed to implement the defined functionalities of an agent. The piece of software may run on the field component itself, if the field component has a required processing capability, or may run on another device, such as a nearby field component, or on a centralized computing system, such as the optional agent server 128. Thus, it is possible to implement aspects of the proposed agent-based process automation without having to modify hardware of existing field components that may lack the required processing capability to execute the defined agent functionalities.

[0033] The disclosed methodology can be broadly described as including a request handling stage and a pairing stage, that constitute a so-called “pairing run” . After an optimal pairing is established by the pairing run, the process plant can be operated based on a direct communication of request values from the requesting agents to the respective paired reacting agents without intervening agents. The stages are explained in detail below.

[0034] Request Handling

[0035] In the request handling stage, requests are generated by requesting agents and forwarded to one or more neighboring agents. In general, requesting agents may include sensor agents with defined setpoints or limits (e.g., in case of dead-band control) . The setpoint or limit may be defined by an operator of the process plant, for example, via the operation station (server / client) 102, 104. Alternately, the setpoint or limit may be defined in an automated way by a superordinate system of the process plant, such as the automation server 126. According to a disclosed embodiment, all sensor agents with setpoints or limits may generate corresponding requests and forward them in multiple directions (e.g., upstream and downstream directions) to neighboring agents. An exception may be made for temperature requests, which may only be forwarded in an upstream direction. In some situations, a requesting agent may be an actuator agent that generates a new request during operation when it has reached an operating limit.

[0036] Each request generated by a requesting agent may contain information including an ID of the requesting agent, a request type (e.g., flow, temperature, pressure, etc. ) , a priority value, and an initial penalty value, among others. Information on each generated request is communicated by the requesting agent to a centralized pairing service. The pairing service may be implemented as a software module, which may run, for example, on a superordinate system of the process plant (e.g., the automation server 126 or the agent server 128) , or another computing system, such as an edge device.

[0037] The priority value of a request is assigned by the requesting agent and may be indicative of a relative importance of the request. The priority value can be different if the request is generated due to a setpoint or due to a limit violation. The priority value may also reflect the importance of the setpoint or limit for a particular entity (e.g., flow or pressure) and act as a tiebreaker when not all requests can be fulfilled by available reacting agents. Thus, priority values can be critically useful in  deciding that agents guarantee the fulfillment of the most important setpoints and / or limits. Every agent may have a default priority for requests created by it. For example, in some cases, a default priority value for a flow request may be set higher than a pressure request, ensuring that, between meeting a flow setpoint and a pressure setpoint, an agent will preferentially choose to meet the flow setpoint.

[0038] The penalty value of a request reflects a limitation to influence the requesting agent by a receiving agent. The penalty value may be indicative of a distance that the request has been forwarded to from the requesting agent. The initial penalty value of a request is set by the requesting agent (e.g., set to “0” ) . The penalty value of the request increases as it travels further away from the originating requesting agent, passing through more and more agents. For example, the penalty value may be increased by “+1” by every receiving agent along a request path. In some embodiments, the penalty value may be updated by receiving agents based on predefined rules, as disclosed in the international patent application No. PCT / US2022 / 023392, filed by the present applicant on April 5, 2022, which is incorporated by reference herein in its entirety.

[0039] An agent that receives a forwarded request, i.e., a receiving agent, checks if it is capable of reacting to the request. If capable, the receiving agent is considered to be a reacting agent. In general, reacting agents include actuator agents. For example, both pump agents and valve agents are capable of reacting to flow and pressure requests. A reacting agent sets the convenience value for reacting to the request. A convenience value can be indicative of a degree of convenience of a reacting agent to react to a specific type of request. The motivation behind setting a convenience value is based on the understanding that the first reacting agent in a request path need not be the best one.

[0040] In most control setups, control valves are primarily used for flow control and pumps are primarily used for pressure control. Accordingly, pump agents may have a higher convenience value for reacting to pressure requests compared to flow requests, and vice versa for valve agents. Neither a valve agent nor a pump agent may react to an incoming temperature request. To be able to react, the temperature request must be converted into a flow request or pressure request by a preceding request converting agent in the request path, as described below. In a non-limiting example, the following scheme may be applied for setting convenience values by reacting agents: (i) for a control valve agent, convenience values for flow type requests, pressure type requests, and temperature type requests may be set as 2, 1, and 0 respectively; and (ii) for a pump agent, convenience values for  flow type requests, pressure type requests, and temperature requests may be set as 1, 2, and 0 respectively.

[0041] In some situations, a reacting agent may be a sensor agent that is capable of reacting to a received request of the same type by adjusting a request value (determined based on a setpoint or limit) during operation. The convenience value of a sensor agent (e.g., pressure sensor) for reacting to a received request (e.g., pressure request) may be lower than that of a corresponding actuator agent (e.g., pump) for the same type of request.

[0042] In addition to actuator and sensor agents, receiving agents may also include request converting agents. For example, request converting agents can include agents representing process equipment, such as tanks, heat exchangers, reactors, crystallizer, etc. A request converting agent can function as a mediator that facilitates exchange of information between agents. A request converting agent may compute a conversion factor for converting a received request to a different request type (e.g., level request to flow request) and forward the request with the conversion factor to a neighboring agent along the request path. The request converting agent may store a default value of a conversion factor for a conversion between given request types, which may be updated after each new computation of the conversion factor based on a received request.

[0043] Receiving agents may furthermore include pipe branch agents, which may forward a received request without reacting. The forwarding of a request by a pipe branch may be dependent on the type of the received request and a direction of the received request in relation to a flow direction. For example, flow type requests received at any one or more upstream or downstream branches of a pipe branch may be forwarded to a remaining branch or branches. Temperature type requests may only be forwarded in an upstream direction by a pipe branch agent.

[0044] FIG. 3A, 3B and 3C illustrate various scenarios of forwarding of a flow type request by a merging pipe branch agent. As shown in FIG. 3A, a flow type request received by the downstream branch C may be forwarded to both upstream branches A and B. As shown in FIG. 3B, a flow type request received by an upstream branch A may be forwarded to the branch B. As shown in FIG. 3C, flow type requests received simultaneously at any two branches A and B (shown as Request-A and Request-B) can both be forwarded to the remaining branch C. The pairing service may eventually pair one of the requests with an actuator on branch C and other request may be fulfilled by an  actuator at the upstream of the junction. Flow type requests may be forwarded by a splitting pipe branch agent in a similar manner.

[0045] FIG. 4 shows the only possible scenario of forwarding of a temperature type request by a merging pipe branch agent. FIG. 5A and 5B illustrate two scenarios where a temperature type request is received by a splitting pipe branch agent at one of the downstream branches (i.e., B or C) of the splitting pipe branch. In both cases, the request may be forwarded by the pipe branch agent to the upstream branch (i.e., A) . FIG. 5C shows the scenario where temperature type requests are simultaneously received at both downstream branches B and C of a splitting pipe branch (shown as Request-B and Request-C) . In principle, branch A may fulfill temperature request from both the branches B and C, since it is upstream to both branches B and C. Thus, both requests may be forwarded to the branch A. Eventually, the pairing service would pair one of the requests with an actuator on branch A and other request may be fulfilled by an actuator installed on the respective branch before it reaches the junction.

[0046] All receiving agents update the penalty value of a received request and, whether they are capable of reacting to the request or not, forward the request to a next neighboring agent along the request path (in an opposite direction to where the request was received from) . Each reacting agent for a particular request communicates information, which includes an ID of the reacting agent, the convenience value of reacting to the request, the updated penalty value of the request and the conversion factor (if applicable) , to the pairing service. In this manner, requests generated by multiple requesting agents are each forwarded along one or more request paths, where each request path is defined by a chain of receiving agents that can include one or multiple reacting agents.

[0047] In one embodiment, to ensure that a request is not forwarded all over the plant, the forwarding of a request along a particular request path may be stopped when a predefined maximum penalty value has been reached. The maximum penalty value can be dependent on the number of agents already capable of reacting to the request. In addition, some agents such as tank agents can be defined such that they do not forward requests to agents on the other side, to separate individual parts of the plant.

[0048] Pairing

[0049] As described above, the pairing service collects information from each requesting agent and each reacting agent during the request handling stage. All agents may also read their status and pass that on to the pairing service, so that the pairing service may consider only active agents for the pairing. In the pairing stage, the pairing service uses the information collected from the (active) requesting agents and the reacting agents to compute a reward for each possible combination of a requesting agent and a reacting agent. The reward may be defined by any suitable relationship such that the reward increases with priority value and with convenience value and decreases with penalty value. In an example implementation, the reward may be determined as:

[0050] The exact formulation of the reward is non-limiting. For example, the “+1” in the denominator in equation (1) assumes a minimum penalty value of “0” , which need not always be the case. Also, in some variations, the above formulation may be modified to weight the influence of priority, convenience and penalty values differently.

[0051] According to a disclosed embodiment, the pairing service may create a pairing matrix, where the elements of the pairing matrix represent respective rewards for possible combinations of requesting agents and reacting agents. An illustrative example of a pairing matrix M is shown in Table 1 below. In the shown example, the rows of the pairing matrix M represent requesting agents and the columns represent reacting agents. In an alternate representation, the rows and columns of the pairing matrix M may be switched. Each element of the pairing matrix M may indicate a reward for the corresponding combination of requesting agent and reacting agent.

[0052] Table 1: Pairing Matrix M

[0053] Having computed the reward for each possible combination of requesting agent and  reacting agent, the pairing service determines an optimal pairing between requesting agents and reacting agents such that a sum total of the rewards of all pairings is maximized. According to the disclosed embodiment, the pairing service may determine the optimal pairing by permuting the rows and / or columns of the pairing matrix M such that the sum of the diagonal elements of the pairing matrix is maximized. The diagonal elements of such a permuted pairing matrix (in which the sum of the diagonal elements is maximized) then represent the optimal pairing between respective requesting and reacting agents.

[0054] As an additional feature, all elements of the pairing matrix M that do not represent a possible combination between a requesting and a reacting agent may be set to “0” value. An example scenario where a combination is not possible is when a request from a requesting agent does not reach a particular agent via forwarding. Another example could be when an agent receiving a request is not capable of reacting to the request type, although this scenario can alternately be addressed by setting the convenience value to “0” by the so-called reacting agent, such that the resulting reward is also “0” (e.g., as provided in equation (1) ) . Such a formulation of the pairing matrix M can allow the optimal pairing to be determined from the pairing matrix M using any standard optimizer algorithm, such as steepest descent, gradient-based, or numerical optimization algorithms. Furthermore, request handling and forwarding, especially in pipe branch agents, becomes simpler such that no case-based rules are necessary.

[0055] In some cases, an optimal solution might not be unique. This may be resolved in many ways, for example, based on a user input, or by considering additional aspects (e.g., the sum of the convenience values is maximized, or the sum of the penalties is minimized) , or by using a default (e.g., first) solution. If a request cannot be paired to a reacting agent, the user may be informed. In many situations, changing actuator modes from manual to automatic can resolve this issue.

[0056] FIG. 2 shows a topological representation (P&ID) of an example process plant to illustrate the above-described pairing run methodology. The illustrated process plant comprises field components that include actuators V1, V2, V3, V4 and M1, sensors S1, S2, S3 and S4, pipe branches PB1 and PB2, tanks TK1 and TK2, each of which is represented by respective agents. In the following description, the referenced components V1, V2, V3, V4, M1, S1, S2, S3, S4, PB1, PB2, TK1 and TK2 refer to the respective agents, even if not explicitly specified.

[0057] The actuators V1, V2, V3, V4 comprise valves, while the actuator M1 comprises a pump. The sensor S1 comprises a level sensor for measuring fluid level of the tank TK1, the sensor S2 comprises a temperature sensor for measuring temperature inside the tank TK1, the sensor S3 comprises a pressure sensor for measuring outlet pressure of the pump M1, and the sensor S4 comprises a level sensor for measuring fluid level in the tank TK2. The pipe branch PB1 comprises a merging pipe branch while the pipe branch PB2 comprises a splitting pipe branch, as shown by the arrows depicting the direction of flow. The tanks TK1 and TK2 function as request converting agents. The process plant further includes a heat exchanger HX which is not represented by an agent in this example.

[0058] In the request handling stage, the process plant in the present example may have four requests generated by requesting agents (sensors) , S1, S2, S3, and S4. One or multiple of these requests can be reacted to by one or more reacting agents (actuators) V1, V2, V3, V4 and M1. For example, the request generated by sensor S1 (request type=level) can reach actuator VI along a downstream request path S1-TK1-V1. The same request can reach actuator V4 along an upstream request path S1-TK1-V4, reach actuator V2 along an upstream request path S1-TK1-V4-PB1-V2, reach actuator V3 along an upstream request path S1-TK1-V4-PB1-V3 and reach actuator M1 along an upstream request path S1-TK1-V4-PB1-V3-PB2-S3-M1.

[0059] The tank TK1 may compute a conversion factor to convert the received level request from sensor S1 to a flow request, before forwarding the request along the respective request path. Each of the actuators V1, V2, V3, V4, and M1 may be capable of reacting to the converted flow request. The request may be assigned a priority value and an initial penalty value by the requesting agent S1. Each receiving agent in a request path may update the penalty value and forward the request to the next agent. Each reacting agent in the request path may set a convenience value for reacting to the request from sensor S1. In some embodiments, a maximum penalty value may be defined, depending on which the request from sensor S1 may or may not reach all of the above-mentioned actuator agents.

[0060] In a similar manner, requests generated by sensor S2 (request type= temperature) , sensor S3 (request type=pressure) and sensor S4 (request type=level) may be forwarded along multiple paths (upstream and / or downstream) to multiple reacting agents among V1, V2, V3, V4 and M1. Note that, since temperature requests may only be forwarded upstream, the request generated by  sensor S2 may not reach actuator V1, i.e., a combination of S2 and V1 is not possible.

[0061] Next, in the pairing stage, a pairing matrix MExample may be created as shown in Table 2, wherein the rows represent requesting agents and the columns represent reacting agents. Elements of the paring matrix MExample may represent respective rewards for possible combinations of a requesting agent and a reacting agent. The reward may be calculated using equation (1) or any other suitable relationship. Elements of the pairing matrix where such a combination is not possible may be set to “0” . Using the pairing matrix MExample, an optimal pairing may be determined such that the sum total of the rewards of all the pairings is maximized, as described above.

[0062] Table 3: Pairing Matrix MExample

[0063] The above-described pairing matrix MExample may be modified to include one or more actuator agents as requesting agents and one or more sensor agents as reacting agents. In this case, it may be possible for a given agent to function as a requesting agent as well as a reacting agent. Such a modification may be carried out, for example, in case of a re-pairing process, if an actuator generates a new request upon reaching an operating limit during operation, as described in the following section.

[0064] Operation

[0065] In the context of agent-based process automation, “operation” refers to the real-time operation of the process plant, where control actions are taken at each cycle time to implement a specific operating procedure within the process plant. Unlike in the request handling and pairing stage, during operation, each requesting agent may communicate directly to the respective paired reacting agent. In particular, each reacting agent (e.g., an actuator agent) receives only one request value from a requesting agent (e.g., a sensor agent) as decided by the pairing. A request value (ReqVal) may represent the requested quantity, for example, in deviation form, i.e., as an incremental change from its current amount. Each cycle of a closed loop control may include reading current measurement values by sensor agents from respective field components to generate request values based on a deviation of the measured values from respective setpoints or limits. A  limit may be defined by maximum and / or minimum limit values, e.g., for implementing dead-band control. The request values may be communicated by the sensor agents directly to respective actuator agents paired therewith based on the determined optimal pairing. The actuator agents may react by determining control actions to fulfill the request values. Different actuator agents may react to different types of request values in different ways, as described below.

[0066] A valve agent may react positively to a flow type ReqVal received at the upstream, i.e., open if ReqVal is positive (increase in flow) and close if ReqVal is negative (decrease in flow) . A flow type ReqVal received at the downstream may be handled in the same manner by a valve agent. A valve agent may react negatively to a pressure type ReqVal received at the upstream i.e., close if ReqVal is positive (increase in pressure) and open if ReqVal is negative (decrease in pressure) . A valve agent may react positively to a pressure type ReqVal received at the downstream, i.e., open if ReqVal is positive (increase in pressure) and close if ReqVal is negative (decrease in pressure) .

[0067] Note that, in this context, a valve agent represents a continuous control valve. To determine a control action, during operation, as the valve agent receives the flow or pressure ReqVal, it may also read the value of a current position from the field component and determine a new position as an increment (positive or negative) from the current position, e.g., based on a PID (proportional integral derivative) control block. The determined new position may be communicated by the valve agent to the field component.

[0068] A pump agent may react positively to a flow type ReqVal received at the upstream, i.e., increase the speed if ReqVal is positive (increase in flow) and decrease the speed if ReqVal is negative (decrease in flow) . A flow type ReqVal received at the downstream may be handled in the same manner by a pump agent. A pump agent may act negatively to a pressure type ReqVal received at the upstream, i.e., decrease the speed if ReqVal is positive (increase in pressure) and increase the speed if ReqVal is negative (decrease in pressure) . A pump agent may react positively to a pressure type ReqVal received at the downstream, i.e., increase the speed if ReqVal is positive (increase in pressure) and decrease the speed if ReqVal is negative (decrease in pressure) .

[0069] To determine a control action, during operation, as the pump agent receives the flow or pressure ReqVal, it may also read the value of a current speed from the field component and determine a new speed as an increment (positive or negative) from the current speed, e.g., based on  a PID control block. The determined new speed may be communicated by the pump agent to the field component.

[0070] Sensor agents can also react on ReqVal of incoming requests of the same type. Thus, if a sensor agent is paired (as a reacting agent) with a requesting agent, then, during the operation run, the sensor agent may directly receive a ReqVal from that requesting agent. In this case, the sensor agent may react on the received ReqVal by adding it to its own ReqVal that it generates as a requesting agent (due to setpoint or dead-band control, as discussed above) and send a total ReqVal to a paired actuator (reacting) agent. If the sensor agent is not generating any ReqVal by itself due to no setpoint or dead-band control requirement (e.g., in case of a pressure sensor) , then it may send the received ReqVal as it is to the paired actuator agent.

[0071] In some situations, an actuator agent may reach its operating limit during operation such that it is no longer able to fulfill the request value from a paired requesting agent. When this occurs, the actuator agent may generate a new request. There may be multiple approaches to address this issue. From a mathematical standpoint, it may be more beneficial to perform a complete re-pairing process based on the above-described methodology of determining an optimal pairing. In this case, the actuator agent in question may be considered also as a requesting agent, based on which an updated pairing matrix may be created, and an optimal pairing determined.

[0072] However, from an operational standpoint, it may be less desirable to change the complete control topology for small changes during operation, such as a new request from an actuator agent. Accordingly, as an immediate or temporary solution, the new request from the requesting actuator agent may be forwarded along one or more request paths to search for agents capable of reacting to the new request. If available, the reward (s) for reacting to the new request by the respective agent (s) may be computed and the new request may be paired with the agent with the highest reward for reacting. If no agent is available to react, a re-pairing process may be carried out. In one embodiment, the new request may be paired to a sensor agent capable of reacting to the new request by adjusting a request value during operation. The sensor agent with the adjusted request value may now operate as a reacting agent (reacting to the new request) and also continue to operate as a requesting agent paired to a respective reacting actuator agent.

[0073] As an illustrative example, during operation, a control valve agent (e.g., V3 in FIG. 2)  cannot react on a positive flow ReqVal if the control valve is already at its maximum limit. Similarly, it cannot react on a negative flow ReqVal if the control valve is already at its minimum limit. In this scenario, the control valve agent V3 may generate a new pressure request and assign relatively higher priority value (e.g., 4) to this request. This new request may then travel in both upstream and downstream directions to search an agent which can react on it. As it travels, various agents on the path may check to see if they are capable of reacting to it and calculate a respective reward. At the end, the control valve agent (in this case, requesting agent) may be paired with the agent that can react to the request with highest reward value. If a pressure sensor exists in the path (e.g., S3) , then the control valve agent V3 may be paired with the pressure sensor agent S3, and if not, it may be paired with a pump agent M1. This can be enforced by setting high priority (e.g., 5) for the pressure sensor agent S3 acting on the received pressure request as compared to the pump agent M1. In a subsequent step, the pressure sensor agent S3 may react by calculating a ReqVal using the received ReqVal from the control valve agent V3 and sending the adjusted ReqVal to a paired reacting actuator agent (as determined by the existing optimal pairing) .

[0074] The optimal pairing established by the pairing service may no longer be valid if one or more of the following events occur during operation:

[0075] - an agent has a failure,

[0076] - an actuator agent is set to manual mode,

[0077] - a setpoint or limit of a sensor agent is no more valid,

[0078] - a change in process plant topology has occurred, and

[0079] - an operator stops or changes pairing manually.

[0080] The pairing service may be configured to monitor the status of the agents in the plant during operation and perform a re-pairing in the event of one or more of the above-mentioned scenarios. All agents which are directly or indirectly influenced by the reason for re-pairing may be unpaired. If a requesting agent is unpaired, it may immediately send its request again, to find an optimal repairing afterwards. A directly influenced agent is one with which the agent in question is already paired, while indirectly influenced agents are those agents which are not paired with the agent in question but potentially can fulfill the request from / to the agent in question. Direct or  indirect influence of the agent can be obtained from the pairing matrix M, potentially by looking for all non-zero entries in the rows and columns of the unpaired agent.

[0081] The embodiments of the present disclosure may be implemented with any combination of hardware and software. In addition, the embodiments of the present disclosure may be included in an article of manufacture (e.g., one or more computer program products) having, for example, a non-transitory computer-readable storage medium. The computer readable storage medium has embodied therein, for instance, computer readable program instructions for providing and facilitating the mechanisms of the embodiments of the present disclosure. The article of manufacture can be included as part of a computer system or sold separately.

[0082] The computer readable storage medium can include a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network.

[0083] The system and processes of the figures are not exclusive. Other systems, processes and menus may be derived in accordance with the principles of the disclosure to accomplish the same objectives. Although this disclosure has been described with reference to particular embodiments, it is to be understood that the embodiments and variations shown and described herein are for illustration purposes only. Modifications to the current design may be implemented by those skilled in the art, without departing from the scope of the appended claims.

Claims

1.A method for automating at least part of a process plant comprising a plurality of field components represented by respective agents, comprising:by a requesting agent, generating a request associated with a defined priority value and an updatable penalty value, forwarding the request to one or more neighboring agents and communicating information on the request to a pairing service,by a receiving agent, receiving a forwarded request, updating the penalty value and forwarding the request to a next neighboring agent along a request path, and, if capable of reacting to the request, defining a convenience value for reacting to the request and communicating the convenience value and the updated penalty value to the pairing service,whereby requests generated by multiple requesting agents are each forwarded along one or more request paths, wherein each request path is defined by a chain of receiving agents that include one or more reacting agents, andby the pairing service:using information collected from the requesting agents and the reacting agents to compute a reward for each possible combination of a requesting agent and a reacting agent, the reward defined such that the reward increases with priority value and with convenience value and decreases with penalty value, anddetermining an optimal pairing between requesting agents and reacting agents such that a sum total of the rewards of all pairings is maximized.2.The method according to claim 1, wherein the requesting agents comprise sensor agents with defined setpoints and / or limits, and the reacting agents comprise actuator agents.3.The method according to claim 2, wherein the requesting agents further comprise one or more actuator agents, wherein a request is generated by the one or more actuator agents that has reached an operating limit thereof.4.The method according to any of claims 2 and 3, wherein the reacting agents further comprise one or more sensor agents capable of reacting to a received request by adjusting a request value during operation.5.The method according to any of claims 1 to 4, wherein the receiving agents further comprise one or more request converting agents that perform:computing a conversion factor for converting the received request to a different request type,forwarding the received request with the computed conversion and the updated penalty value along the request path.6.The method according to any of claims 1 to 5, wherein the receiving agents further comprise one or more pipe branch agents that perform:forwarding the received request without reacting by updating the penalty value thereof, the forwarding being dependent on a request type and a direction of the received request in relation to a flow direction.7.The method according to any of claims 1 to 6, wherein:the priority value is indicative of a relative importance of a request,the convenience value is indicative of a degree of capability of a reacting agent to react to a specific type of request, andthe penalty value is indicative of a limitation to influence a requesting agent by a receiving agent.8.The method according to any of claims 1 to 7, wherein the forwarding of each request along the respective request path is stopped when a predefined maximum penalty value has been reached.9.The method according to any of claims 1 to 8, comprising creating a pairing matrix by the pairing service including rows representing requesting agents and columns representing reacting agents, or vice versa, wherein elements of the pairing matrix represent respective rewards for possible combinations of requesting agents and reacting agents.10.The method according to claim 9, wherein all elements of the pairing matrix that do not represent a possible combination between a requesting and a reacting agent are set to “0” value.11.The method according to any of claims 9 and 10,wherein the optimal pairing is determined by the pairing service by permuting the rows and / or columns of the pairing matrix such that the sum of the diagonal elements of the pairing matrix is maximized,wherein the diagonal elements of the permuted pairing matrix represent the optimal pairing between respective requesting and reacting agents.12.The method according to claim 10, wherein the optimal pairing is determined by an optimization algorithm.13.The method according to any of claims 1 to 12, comprising carrying out operation of the process plant subsequent to the pairing by direct communication of request values from requesting agents to the respective paired reacting agents.14.The method according to claim 13, further comprising:during operation of the process plant,reading current measurement values by sensor agents to generate request values based on a deviation of the measured values from respective setpoints or limits,communicating the request values by the sensor agents directly to respective actuator agents paired therewith based on the determined optimal pairing, anddetermining control actions by the respective actuator agents to fulfill the request values.15.The method according to any of claims 13 and 14, further comprising:during operation of the process plant,receiving a request value of an incoming request by a sensor agent from a paired requesting agent,adding the received request value to an own request value generated by the sensor agent, andcommunicating a total of the received request value and the generated own request value by the sensor agent to a paired reacting actuator agent.16.The method according to any of claims 13 to 15, further comprising:during operation of the process plant,generating a new request by an actuator agent that has reached an operating limit,forwarding the new request along one or more request paths to search for agents capable of reacting to the new request, and if available, computing respective rewards for reacting, andpairing the new request with the agent with the highest reward for reacting.17.The method according to claim 16,wherein the new request is paired during operation to a sensor agent capable of reacting to the new request by adjusting a request value during operation,wherein the sensor agent with the adjusted request value operates also as a requesting agent paired to a respective reacting actuator agent.18.The method according to any of claims 1 to 17, comprising monitoring a status of the agents by the pairing service and performing a re-pairing in the event of one or more of:an agent has a failure,an actuator agent is set to manual mode,a new request is generated by an agent during operation,a setpoint or limit of a sensor agent is no more valid,a change in process plant topology has occurred, andan operator stops or changes pairing manually.19.A non-transitory computer-readable storage medium including instructions that, when processed by a computing system, configure the computing system to perform the method according to any of claims 1 to 18.

Images