A data-efficient and automated architecture for managing a pump

Abstract

The present disclosure relates to controlling pumps. The disclosure provides a data-efficient and automated architecture for managing one or more pumps. To this end, a management entity for managing one or more pumps and a control entity for a pump are proposed. The control entity is configured for event-driven minimal data transfer to the management entity. It transmits data related to an event, if such an event is detected. The management entity is configured to instruct the control entity to set or change a configuration of the event-driven data transfer.

Description

[0001] A D ATA-EFFICIENT AND AUTOMATED ARCHITECTURE FOR MANAGING A PUMP

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to controlling one or more pumps. The disclosure proposes a data-efficient and automated architecture for managing the one or more pumps. To this end, a management entity for managing the pumps, and a control entity for controlling a pump are presented. Additionally, a smart pump, a smart pump system, and methods for managing and controlling pumps are presented.

[0004] BACKGROUND

[0005] Smart pump systems are essential in both industrial and residential settings. Smart pump systems increasingly integrate Internet of Things (loT) and connected technologies. A typical smart pump system comprises one or more pumps, which are equipped with sensors and communication modules, and are configured to facilitate a range of functions. These functions including remote monitoring, control, and optimization. The pumps of the smart pump system are usually managed by a backend command center or a management entity.

[0006] Smart pump systems face significant challenges due to the extensive data transfer, which is required between the pumps (which may be referred to as “edge devices”) and the centralized backend command center. This data exchange is, however, crucial for commissioning, provisioning, monitoring, analysis, control, updating, and optimization of the pumps.

[0007] The high volume of data transfer, which is necessary for these operations, also places considerable demands on the network infrastructure, which can lead to increased costs, potential data bottlenecks, a relatively poor scalability, and security vulnerabilities. Additionally, constant connectivity requirements, which are essential for a smooth operation of a smart pump system, may not be sustainable in environments with limited network availability. SUMMARY

[0008] In view of the above, there is a need for innovations in smart pump technology, which reduce the reliance on continuous large-scale data transfer, and thus enhance the network efficiency, security, and overall reliability of a smart pump system.

[0009] An objective of this disclosure is therefore to provide an improved architecture for remotely managing one or more pumps. A specific objective is thereby to minimize the data transfer between the pumps and a management entity at the backend. This has the aim to lower data costs, and to minimize risks associated with connectivity. In particular, a communication solution is desired that significantly reduces the volume of the transferred data, while still being able to conveniently and effectively operate and optimize the pump operations.

[0010] Another objective is to enable a high degree of automation of a smart pump system, and to enable modular scalability, in order to allow for a high degree of evolutionary feature adaptations, if required in the future.

[0011] An additional objective is to also enable data transfer for deep analysis. Another objective is to facilitate monitoring and analyzing the status and performance of the pumps. Moreover, remotely installing and updating software or applications on the pumps, or remotely changing control settings of the pumps is a further objective.

[0012] The above-mentioned and other objectives are achieved by features of the solution of this disclosure described in the claims.

[0013] A first aspect of this disclosure is a control entity for a pump, wherein in a first data transfer mode the control entity is configured to monitor one or more parameters related to the pump; resume a wireless connection with a management entity, if an event is detected based on the one or more parameters; transmit data related to the detected event to the management entity using the wireless connection; and suspend the wireless connection immediately after transmitting the data related to the detected event to the management entity.

[0014] The control entity of the first aspect embodies and provides an event-based communication solution, which significantly reduces the volume of data transferred to the management entity. This can be achieved by sending data only if the event is detected - for example, detected based on operating parameters of the pump - and only sending data that is necessary, for example, for the purposes of obtaining information about and handling the event. Nevertheless, the solution allows to conveniently and effectively operate and optimize the pump. The control entity is able to run without continuous connection to the management entity, e.g., without continuous connection to a cloud which hosts the management entity. Thus, the solution minimizes risks associated with connectivity. The solution ensures further that the control entity, which may be installed on premise into the pump, handles as much functions as possible, so as to avoid unnecessary upload of data to the management entity, and also processing by the management entity. The pump maybe a centrifugal pump. The pump maybe a fluid pump, or a liquid pump, or a water pump.

[0015] By means of the control entity, the pump is provided with additional intelligence, and may referred to as a smart pump. Each of multiple pumps connected to the management entity maybe equipped with a control entity of the first aspect. In this way, by decentralizing the intelligence of the smart pump system, each control entity (and thereby each pump) may become its own master, and may be equipped with the capability to parse through data and autonomously execute decisions. This localized control mitigates the need for constant human oversight and streamlines operations to a degree that was once only imaginable. The solution of this disclosure may also implement a continuous self-learning system.

[0016] The data related to the detected event maybe saved by the control entity, for instance, for the purpose of sending the data (again) if requested. It may also be possible to save all data - including event-related data - for a limited amount of time (e.g., 5 minutes or 1 hour), so that all the data can be sent if requested. A request could, for instance, be made by the management entity associated with the control entity, or another management entity, or another control entity.

[0017] In an implementation, the control entity is configured to exclusively transmit data related to the event after the wireless connection is resumed and before the wireless connection is suspended.

[0018] Thus, the event-based communication solution embodied by the control entity significantly reduces the volume of the data transferred to the management entity, as no unnecessary data is transmitted and the control entity is able to resolve many issues on its own. This also lowers the data costs and minimizes risks associated with connectivity of the pump.

[0019] In an implementation, the control entity is configured to detect the event if a value of at least one of the parameters related to the pump changes by more than a threshold value and / or fulfills a certain condition.

[0020] The control entity may thereby detect predefined events in the parameters, for instance, wherein the threshold value or condition to identify the event based on the the parameters is known. The control entity may, however, also detect non-predefined events - for instance, the control entity may take own decisions based on abnormal parameter behavior - and may in this way, or by external input, learn new events. The control entity may employ a trained model like a neural network for detecting events based on the one or more parameters related to the pump being input into the model.

[0021] In an implementation, the control entity is further configured to change from the first data transfer mode to a second data transfer mode; wherein in the second data transfer mode the control entity is configured to transmit a data burst to the management entity, wherein the data burst has a higher resolution and / or transmission frequency than the data transmitted in the first data transfer mode.

[0022] The second data transfer mode enables a data transfer for deep analysis. The second data transfer mode may override the settings in the first data transfer mode. Notably, the control entity may comprise further data transfer modes. The control entity may change on its own account, i.e., may decide based on at least one criterion whether to change data transfer mode. The control entity may also receive an instruction, for instance from the management entity, to do so. In the second data transfer mode, the control entity may also transmit more than one data burst to the management entity.

[0023] In an implementation, the control entity is configured to automatically resume the first data transfer mode at a predetermined time after transmitting the data burst.

[0024] This ensures that the minimal data transfer is performed if the data burst transfer is not needed. The predetermined time maybe configurable. If the control entity sends multiple data bursts, the predetermined time may be calculated from the end of the last data burst. In an implementation, the control entity is configured to receive, in response to transmitting the data related to the detected event, a request for additional data from the management entity; and transmit the data burst comprising the requested additional data to the management entity.

[0025] The request of the management entity may comprise an instruction or an indication to the control entity, to send the additional data in the data burst mode. The requested additional data may be data related to the event, which may allow the management entity to further analyze, for example, to perform a root-cause analysis regarding the event. The additional data may comprises one or more of: operational performance metrics, historical data, trends, events, anomalies, error codes, diagnostic information, and user-defined operating parameters.

[0026] In an implementation, the control entity is further configured to receive a data transfer configuration message from the management entity; and set or change, based on the data transfer configuration message, at least one of: the first or second data transfer mode; a threshold value for at least one of the parameters related to the pump; a condition for at least one of the parameter related to the pump.

[0027] Thus, the control entity and the data transfer mode it uses are configurable by the management entity. The event detecting at the control entity is also configurable by the management entity. It is moreover possible to configure control entities related to different pumps in different manners as needed.

[0028] In an implementation, the control entity is configured to receive one or more data flows indicating the one or more parameters related to the pump; and associate the one or more data flows to respectively one or more topics.

[0029] The data flows may be received from the pump the control entity is controlling, but may also be received from the management entity, from other pumps of the pump system, or from other entities, for example, devices that monitor the environment. These devices may include environmental sensors. The data flows may include, or may be based on, one or more sensor signals of one or more sensors of the pump, and / or one or more sensors connected to the pump, and / or one or more sensors connected to the control entity.

[0030] In an implementation, the control entity is further configured to transmit a notification message related to a topic to one or more client entities, which are subscribed for the topic at the control entity; wherein the notification message includes information regarding at least one of the parameters related to the pump.

[0031] In an implementation, the topic includes at least one of: a status of the pump; an operation mode of the pump; a data transfer mode of the control entity; a performance of the pump.

[0032] In an implementation, the control entity is configured to obtain one or more sensor signals from respectively one or more sensors integrated in or connected to the pump or the control entity; wherein the one or more sensor signals indicate at least one of the parameters related to the pump.

[0033] At least one of the pump and the control entity may accordingly have at least one built in sensor. At least one sensor signal may also stem from at least one sensor connected to the pump or connected to the control entity.

[0034] In an implementation, the one or more parameters related to the pump indicated by the one or more sensors signals comprise at least one of: a flow rate of the pump; a pressure of the pump; a temperature of the pump; a vibration of the pump; an acoustic profile of the pump; a power consumption of the pump.

[0035] Consequently, the control entity is able to autonomously monitor and act based upon realtime operation data of the pump. For example, the control entity may monitor the one or more parameters for a determined period of time, like for at least 5 minutes, and may decide based on the behavior of the one or more parameters during the determined period of time, whether an event occurred and / or how to act. The parameters indicated by the sensor signals may specifically be operating parameters of the pump, and may change over time. Events detected may indicate an abnormal change over time.

[0036] In an implementation, the one or more parameters related to the pump comprise at least one of: a standard pump parameter; a parameter received by user input; an environmental parameter; a process parameter; a system parameter.

[0037] An environmental parameter may, for example, be an ambient temperature or an ambient humidity level. A process parameter may, for example, be a fluid characteristic of the pumped fluid, or may be a customer preference, or supply chain data. A system parameter maybe a demand, e.g. energy, of the system. In an implementation, the control entity is configured to pre-process at least one of the one or more parameters related to the pump when monitoring the one or more parameters, wherein the pre-processing comprises at least one of: filtering at least one of the parameters; aggregating at least some of the parameters; transforming at least one of the parameters.

[0038] This may allow the control entity to more accurately or more efficiently detect events. The control entity may also provide the result of its pre-processing to the management entity, for example, for learning purposes. The pre-processing may be performed by a trained model of the control entity, taking the parameters as input.

[0039] In an implementation, the control entity is configured to perform an analytics operation on the one or more parameters related to the pump, in order to detect an event, wherein the analytics comprise at least one of: a pressure and / or flow analysis based on parameter indicating a pressure and / or flow-rate of the pump; a vibration analysis based on a parameter indicating a vibration of the pump; an energy efficiency analysis based on a parameter indicating a power consumption of the pump.

[0040] The analytics operation may be a specific algorithm of software that is run by the control entity. However, the control entity may also employ artificial intelligence, specifically, a trained model to perform the analytics.

[0041] In an implementation, the control entity is further configured to select at least one control action based on the detected event; and execute the at least one control action to control the pump accordingly.

[0042] In an implementation, the at least one control action comprises an adjustment of a pump speed of the pump.

[0043] The control entity is configured to autonomously control at least some aspects of the pump without need to interact with the management entity. In this way, root-causes responsible for an event may be addressed.

[0044] In an implementation, the control entity is further configured to provide, to the management entity, learning data based on the detected event and / or based on a control action selected based on the detected event; and / or receive, from the management entity, learning data related to detecting events and / or selecting a control action based on a detected event.

[0045] The control entity may include a trainable and / or trained model, for instance a neural network, which can be trained using the received learning data. The learning data may allow the trained model to correlate events with certain changes or conditions of at least one of the parameters related to the pump and / or with control actions to address the events. The management entity may also include a trainable and / or trained model, for instance a neural network, which can be trained using the provided learning data. The model of the management entity may learn to provide the control entities data transfer instruction messages or other input to manage the pumps in an optimized way, for example, to reduce the amount of events.

[0046] A second aspect of this disclosure is a management entity for managing one or more pumps, the management entity being configured to wirelessly transmit a data transfer configuration message to a control entity of at least one of the pumps; wherein the data transfer configuration message is adapted to instruct the control entity to set or change a configuration of an event-driven data transfer from the control entity to the management entity.

[0047] By configuring the control entity, particularly, the event-driven data transfer embodied by the control entity, the management entity can ensure that the volume of the data received from the control entity is reduced, while the control entity is still able to conveniently and effectively operate and optimize the pump operations. The management entity can thus also help to lower the data costs and to minimize risks associated with connectivity. The management entity is in this way configured to manage data minimization in the pump system by configuring each control entity in the pump system with a respective data transfer configuration message.

[0048] In an implementation of the management entity, the data transfer configuration message is adapted to instruct the control entity to set or change at least one of: a data transfer mode of the control entity; a threshold value for at least one parameter related to the pump, wherein a change of a value of the parameter by more than the threshold value indicates that an event occurred; a condition for at least one parameter related to the pump, wherein the parameter fulfilling the condition indicates that an event occurred. Thus, the management entity can influence the event detection at the control entities. The management entity can thus control the pump system, while the control entities individually take care of the event detection and minimized data transfer, and may also implement control actions to control the pumps autonomously.

[0049] In an implementation, the management entity is further configured to receive data related to an event detected by the control entity; and / or send the data transfer configuration message to the control entity in response to received data related to an event detected by the control entity.

[0050] In an implementation, the management entity is further configured to send, in response to receiving the data related to the detected event, a request for additional data to the control entity; and receive a data burst comprising the requested additional data from the control entity.

[0051] The management entity may be configured to, by sending the request, instruct the control entity to use the burst mode, for instance, to switch to the burst mode, i.e. to switch from the first data transfer mode to the second data transfer mode. The management entity may also indicate a specific type of the additional data, for instance, additional data that the management entity deems necessaiy to further analyze the event and / or its root-cause. The management entity maybe configured to perform an analysis regarding the event, for instance, a root-cause analysis, based on the received additional data. The additional data maybe as described above in relation to the control entity of the first aspect.

[0052] In an implementation of the management entity, the data transfer configuration message is adapted to instruct the control entity to set or change at least one criterion for changing between a first data transfer mode, a second data transfer mode, and a third data transfer mode by the control entity.

[0053] For example, in the first data transfer mode, the control entity is configured for the event- driven data transfer, as explained above. For example, in the second data transfer mode, the control entity is configured for data burst transfer, as explained above. For example, in the third data transfer mode, the control entity is configured for an interrupt-driven data transfer. The interrupt-driven data transfer means that the control entity waits (and, e.g., listens) passively until it receives an interrupt signal, wherein the interrupt signal indicates that the control entity should perform a specific data transfer. The advantages of the data transfer configuration message are as described above for the control entity.

[0054] A third aspect of this disclosure is a pump for pumping a fluid, wherein the pump comprises the control entity according to the first aspect or any implementation thereof.

[0055] The pump may be a smart pump, e.g., a pump integrated with processing capabilities, sensors, software, and connectivity features that is able to perform automated monitoring and control, and particularly benefits from the above-described advantages provided by the control entity. The pump of the third aspect may be a centrifugal pump. The pump may be a fluid pump, or a liquid pump, or a water pump.

[0056] A fourth aspect of this disclosure is a system comprising at least one pump according to the third aspect and comprising a management entity according to the second aspect or any implementation thereof, wherein the management entity is configured to wirelessly communicate with the at least one pump.

[0057] The system may be a smart pump system, and benefits from the above-described advantages provided by the control entity and the management entity, respectively.

[0058] A fifth aspect of this disclosure is a method for controlling a pump, wherein in a first data transfer mode the method comprises: monitoring one or more parameters related to the pump; resuming a wireless connection with a management entity, if an event is detected based on the one or more parameters; transmitting data related to the detected event to the management entity using the wireless connection; and suspending the wireless connection immediately after transmitting the data related to the detected event to the management entity.

[0059] The method of the fifth aspect achieves the same advantages as the control entity of the first aspect, and may be extended by respective implementations as described above for the control entity of the first aspect.

[0060] A sixth aspect of this disclosure is a method for managing one or more pumps, the method comprising wirelessly transmitting a data transfer configuration message to a control entity of at least one of the pumps; wherein the data transfer configuration message is adapted to instruct the control entity to set or change a configuration of an event-driven data transfer from the control entity to the management entity. The method of the sixth aspect achieves the same advantages as the management entity of the second aspect, and maybe extended by respective implementations as described above for the management entity of the second aspect.

[0061] A seventh aspect of this disclosure is a computer program comprising instructions which, when the program is executed by a processor of a control entity or a management entity, instruct the processor to cause the control entity or the management entity, respectively, to perform the method according to the fifth aspect or seventh aspect.

[0062] An eight aspect of this disclosure is a management entity for managing one or more pumps, the management entity being configured to wirelessly transmit a software profile configuration message to a control entity of at least one of the pumps; wherein the profile configuration message is adapted to instruct the control entity to set or change a software profile of the control entity.

[0063] The configuration of the event-driven data transfer from the control entity to the management entity, which is described in the third aspect, may be a specific implementation of the confirmation of the software profile. The data transfer configuration message may accordingly be a specific implementation of the software profile configuration message. The management aspect of the eights aspect may have similar implementations as the management entity of the third aspect.

[0064] In summaiy, this disclosure proposes a data-efficient and highly automated solution for managing pumps “on edge”. The solution comprises pump edge devices with local decision-making capabilities, i.e. pumps and control entities of the first aspect for these bumps, and further comprises a backend command center including a management entity of the third or eighth aspect. The solution is an asynchronous message-based software architecture, which is functionally characterized by event-driven, minimal data transfer communication from the edge devices to the backend platform (thereby prioritizing the autonomy of edge device). The solution further enables data burst mode transfer, thus allowing for data transmission at a higher resolution or frequency, desired state and software configuration based on communicating software profiles or data transfer configurations from the backend to the edge devices, and learning system feedback loops.

[0065] BRIEF DESCRIPTION OF THE DRAWINGS The above described aspects and implementations are explained in the following description of embodiments with respect to the enclosed drawings:

[0066] FIG. 1 shows a control entity and a management entity, respectively, according to this disclosure.

[0067] FIG. 2 shows a method according to this disclosure for controlling a pump.

[0068] FIG. 3 shows a method according to this disclosure for managing one or more pumps.

[0069] FIG. 4 shows various features of the solution of this disclosure, which may be achieved with the control entity and the management entity.

[0070] FIG. 5 shows an exemplary implementation of a control entity for a pump with local decision-making capabilities.

[0071] FIG. 6 shows an exemplary implementation of a management entity at a backend platform hub.

[0072] FIG. 7 illustrates an exemplary flow of an event-driven minimal data transfer from a control entity to a management entity.

[0073] FIG. 8 illustrates another exemplary flow of an event-driven minimal data transfer from a control entity to a management entity.

[0074] FIG. 9 illustrates an exemplary flow for data burst mode activation at a control entity.

[0075] FIG. io illustrates an exemplary flow for state configuration at a control entity by the management entity.

[0076] DETAILED DESCRIPTION OF EMBODIMENTS

[0077] FIG. 1 shows a control entity 10 according to this disclosure, and shows a management entity 15 according to this disclosure. The control entity 10 is configured to control a pump 11. The control entity 10 may be integrated into the pump 11, or may be operatively connected to the pump to (for exchange of data, e.g., wired). The control entity to maybe a controller, a control device, or a computer, and may comprise a processor. The management entity 15 may be cloud-based, that is, it may be in a cloud 16. For instance, the management entity 15 may be implemented on a server, or may be a server. The management entity 15 may also be a computer or the like, and may comprise a processor. The management entity 15 is configured to manage one or more pumps - specifically one or more control entities related to the pumps - for instance, in FIG. 1 it manages the control entity 10 associated with the pump 11. The management entity 15 may, to this end, interact with the control entity 10 wirelessly.

[0078] The control entity 10 may have different data transfer modes. The control entity 10 has at least a first data transfer mode (an event-driven data transfer mode, as described in the following), and may have also a second data transfer mode (a data burst transfer mode, as described further below). The control entity 10 may also have a third data transfer mode (e.g., an interrupt-driven data transfer mode, as described above), or even further data transfer modes. The control entity 10 may switch, e.g. autonomously or upon instruction, between at least these three data transfer modes.

[0079] In the first data transfer mode - which is also referred to as a minimal data transfer mode - the control entity 10 is configured to monitor one or more parameters 12 related to the pump 11. As illustrated, these parameters 12 may be provided by the pump 11. These parameters 12 maybe operational parameters of the pump. For example, the control entity 10 may receive sensor signals and / or data flows from the pump 11, for instance, via a wired or wireless communication connection. The sensor signals may be or may comprise sensor readings from one or more sensors integrated into the pump or external to the pump and / or connected to the pump. The sensor signals or data flows may comprise, or may indicate the one or more parameters 12 related to the pump 11. The control entity 10 may be configured to extract or derive the one or more parameters 12 related to the pump 11 from the sensor signals or from the data flows. The data flows may also come from other pumps or other entities in the pump system. Additionally, the control entity 10 may be able to pre-process at least one or some of the one or more parameters 12, for example, by filtering, or aggregating, or converting, or transforming one or more of the parameters 12.

[0080] The control entity 10 may be configured to detect an event based on the one or more parameters 12. Alternatively, the control entity 10 may receive an indication about an event, for example, from the pump 11. The event may be a predefined event. The control entity 10 maybe aware of multiple predefined events that could occur, and maybe aware of the behavior of the one or more parameters 12 in case that event occurs. However, the event can also be unknown to the control entity 10, and it can take decisions on its own, and decide whether certain, e.g. abnormal, behavior of the one or more parameters 12 justifies identification of an event.

[0081] If the event (any event) is detected based on the one or more parameters 12, for instance in the one or more parameters 12 or derived from their behavior, the control entity 10 is configured to resume a wireless connection 13 with the management entity 15. The wireless connection 13 may already be established when the control entity 15 operates in the event-driven data transfer mode. However, it is possible that when the first event is detected, the control entity 10 establishes the wireless connection 13. Resuming the wireless connection 13 may include reusing an active link between the control entity 10 and the management entity 15, wherein the link is based on a wireless communication technology such as Wi-Fi, Bluetooth, NFC, or cellular network technology. This may also involve the control entity 10 and the management entity 15 detecting each other and / or agreeing on the wireless communication protocol. Resuming the wireless connection 13 may also include reviving a dormant but existing link, such as reactivating a previously configured link that has gone inactive or has been temporarily disconnected, or has been set to a power saving mode.

[0082] The control entity 10 is further configured to transmit data 14 related to the detected event to the management entity 15 using the wireless connection 13. The data 14 may be sent according to any conventional wireless communication protocol. The control entity 10 accordingly is configured for event-based data transfer. The identified event may trigger the data transfer.

[0083] The control entity 10 is further configured to suspend the wireless connection 13 after transmitting the data 14 related to the detected event to the management entity 15. Suspending the wireless connection 13 may include actively pausing the link between the control entity 10 and the management entity 15, such as setting the link to a power saving mode. Suspending the wireless connection 13 could also include terminating the wireless connection 13 or disabling the wireless functionality on the control entity 10, but then the wireless connection would have to be re-established when the next event is detected, which may be less preferred. Preferably, suspending the wireless connection 13 involves maintaining the ability to quickly resume the wireless connection 13. In any case, suspending the wireless connection 13 results at least in the temporary cessation of data exchange between the two entities 10 and 15. The control entity to may be configured to suspend the wireless connection 13 immediately after transmitting the data 14 related to the detected event to the management entity 15. Suspending the wireless connection 13 “immediately” after sending the data 14 means that no further data is sent before the end of the wireless transmission. “Immediately”, however, is not meant to imply a fixed duration after which the suspension is effected, or even an instantaneous suspension. However, the control entity 10 knows when the related data 14 has been transmitted, and then proceeds to stop the wireless transmission of data over the wireless connection 13, for instance, until another event is detected or until there is an instruction or configuration from e.g. the management entity 15-

[0084] The control entity 10 may thus exclusively transmit the data 14 related to the event, after the wireless connection 13 has been resumed and before the wireless connection 13 is suspended. That is, the control entity 10 may send only the related data 14 and no other data. In particular, the control entity 10 may, upon detecting the event, send only relevant data to the management entity 15, for example, to the cloud for further analysis and / or historical record-keeping. The data 14 may consist of the information needed by the management entity 15 to identify and / or handle the event.

[0085] The management entity 15 may accordingly be configured to receive the data 14 related to the event, and may perform analysis, for example, root-cause analysis, so as to determine a root cause of the event. The management entity 15 may also store the data 14 in associated with the event, for example, for historical record keeping. The management entity 15 may also use the data 14 of the control entity 10 for training or updating a trainable model at the management entity. The model maybe dedicated to analyzing and dealing with events, for example, to remove root-causes responsible for the event. The event and the data 14 and optionally a root-cause or label maybe input into the model to train or update the model. The model may also be trained or updated with a training set including events, data respectively related to the event that corresponds to the behavior or the one or more parameters 12 and optionally possible root-causes and / or actions to remove the root-causes. The trained or updated model may be provided to the control entity 10 for the pump 11 (or to multiple control entities 10, which are associated with multiple pumps 11 managed by the management entity 15).

[0086] The management entity 15 is configured to wirelessly transmit a data transfer configuration message 17 to the control entity 10, or to one or more control entities 10 of one or more pumps n. The data transfer configuration message 17 is adapted to instruct the control entity 10 to set or change a configuration of an event-driven data transfer 14 from the control entity 10 to the management entity 15. The control entity 10 may be configured to set its data transfer mode, or to configure the event-driven data transfer to the management entity 15 based on the data transfer configuration message 17.

[0087] For example, the data transfer configuration message 17 may instruct the control entity 10 to set or change at least one of a data transfer mode of the control entity 10, a threshold value for at least one parameter 12 related to the pump 11, or a condition for at least one parameter 12 related to the pump 11. Thereby, a change of a value of the parameter 12 by more than the threshold value or the parameter 12 fulfilling the condition, respectively, may indicate that an event occurred. For example, the control entity 10 may, based on the data transfer configuration message 17, set or change the threshold value for the at least one parameter 12 related to the pump 11 and / or may set or change a condition for at least one of the parameters 12 related to the pump 11. The control entity 10 may be configured to detect the event, if a value of the at least one monitored parameter 12 related to the pump 11 changes by more than the threshold value and / or fulfills the certain condition.

[0088] The management entity 10 may also send, more generally, a software profile configuration message to the control entity 10, so that the control entity 10 can set or change a software profile. Each software profile may be associated with a data transfer mode. Each software profile could also be associated with an event detection configuration. Each software profile could also be associated with a configuration related to obtaining the one or more parameters 12 and / or pre-processing these parameters 12.

[0089] The control entity 10 and the management entity 15 may, respectively, comprise a processor or processing circuitry (not shown in FIG. 1), which is configured to perform, conduct, or initiate the various operations of the entities 10, 15 described in this disclosure. The processing circuitry may comprise hardware and / or the processing circuitry may be controlled by software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. The control entity 10 and the management entity 15 may further, respectively, comprise memoiy circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various described operations of the entities to and 15 to be performed. In one embodiment, the circuitry of the entity 10 or 15 comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the entities 10 or 15 to perform, conduct or initiate the operations or methods described in this disclosure.

[0090] FIG. 2 shows a flow-diagram of a method 20 according to this disclosure. The method 20 is for controlling a pump, for instance, the pump 11 shown in FIG. 1. The method 20 can be performed by the control entity 10 shown in FIG. 1. For instance, the control entity 10 may include a computer program that, when the program is executed by the control entity 10, causes the control entity 10 to perform the method 20.

[0091] The steps of the method 20 that are shown in FIG. 2 are related to a first data transfer mode. In this first data transfer mode, the method 20 comprises a step 21 of monitoring one or more parameters 12 related to the pump 11. If an event is detected based on the one or more parameters 12, the method 20 further comprises a step 22 of resuming a wireless connection 13 with a management entity 15, a step 23 of transmitting data 14 related to the detected event to the management entity 15 using the wireless connection 13, and a step 24 of suspending the wireless connection 13 immediately after transmitting the data 14 related to the detected event to the management entity 15.

[0092] FIG. 3 shows a flow-diagram of a method 30 according to this disclosure. The method 30 is for managing one or more pumps, for instance, the pump 11 shown in FIG. 1. The method 30 can be performed by the management entity 15 shown in FIG. 1. For instance, the management entity 15 may include a computer program that, when the program is executed by the management entity 15, causes the management entity 15 to perform the method 30.

[0093] The method 30 comprises a step 31 of wirelessly transmitting a data transfer configuration message 17 to a control entity 10 of at least one of the pumps 11. Thereby, the data transfer configuration message 17 is adapted to initiate a step 32 of instructing the control entity 10 to set or change a configuration of an event-driven data transfer from the control entity 10 to the management entity 15. FIG. 4 shows a summary of features of the solution presented in this disclosure with respect to control entities to, the management entity 15 and the methods 20 and 30 described above. Implementation details and advantages will be presented in the following parts of the description. The solution of this disclosure generally provides a data-efficient and highly automated architecture for managing pumps 11 that are controlled by the control entities 10.

[0094] Each pump 11 may comprise a respective control entity 10. The pumps 11 maybe referred to as edge devices, and may include, as the control entities 10, e.g., slim clients and minicontrollers with local decision-making capabilities. To this end, the control entities 10 may have considerable computing power, edge I / O interfaces, data storage capabilities, and intelligence. The control entities 10 are able to analyze data locally, and make decisions for the pump 11.

[0095] The management entity 15 may be at a backend command center for managing and orchestrating multiple connected pumps 11. The management entity 15 may serve as a central hub for user interaction, data collection, storage, processing, analytics and decision-making. The management entity 15 and the pumps 11 with their control entities 11 may form a smart pump system.

[0096] The solution of this disclosure for controlling and managing the pumps 11, respectively, may implement an asynchronous message-based software architecture, and may be functionally characterized as follows (with reference to FIG. 4).

[0097] A first feature of the solution (1.) is an event-driven, minimal data transfer communication from the edge devices (control entities 10) to the backend command center (management entity 15), wherein the autonomy of the edge devices in making decisions and taking actions may be prioritized. The communication over the wireless connection 13 is automatically initiated based on the occurrence of a detected event, e.g. one of multiple predefined events, on the edge (in contrast to continuous or periodic data streaming). The data transfer may be limited to data necessary for the purposes of obtaining information about and handling events, i.e. the data 14 related to the detected event.

[0098] A second, optional feature of the solution (2.) is a data burst mode transfer from the edge device to the backend, which may override the default behavior of the minimal data transfer according to (1.), and allows for a more intensive transmission of data at a higher resolution or frequency. A third, optional feature of the solution (3.) is a desired state configuration based on communicating data transfer configuration messages 17 or software profiles (e.g. central declarative configuration files of specific predetermined states) from the backend to the edge devices. Once the desired configuration of the event-driven data transfer or the desire state is defined, the control entity 10 at the edge device may automatically ensure that the edge device remains or is brought into this configuration or state. The edge devices may be configured to automatically maintain their desired operational state, and to resolve detected issues wherever possible. Local algorithms may be used to predict potential deviations and proactively apply corrective measures, thereby ensuring the edge devices to operate optimally with minimal human intervention.

[0099] A fourth, optional feature (4.) is a learning system feedback loops, which may be used to utilize information generated by edge devices and the backend platform to continuously enhance the accuracy of the solution, for example of the previous features of the solution, its efficiency and overall performance. The system comprising the management entity 15 and the control entities 10 may accordingly be self-improving, and may automatically gather data when needed for learning, without human intervention.

[0100] The system can include one pump 11 or multiple pumps 11, and correspondingly one control entity 10 or multiple control entities 10, for instance, in a master-slave relationship and / or in a booster system setup. The system may comprise pumps 11 connected to other equipment. The system includes at least the two fundamental blocks one control entity 10 for a pump 11, i.e. an edge device with local decision-making capabilities, and the management entity 15 as the backend platform (command center).

[0101] FIG. 5 shows an exemplary implementation of a control entity 10 for a pump 11 with local decision-making capabilities. The control entity 10 is equipped with the necessary computing power and intelligence to analyze data locally and make decisions without needing to consult the management entity 15 for every action. The control entity 10 can be or include any slim client, mini-controller, or any other pump-internal or external solution for processing, controlling and operating pumps 11 and variable frequency drives.

[0102] The control entity 10 may comprise an edge 1 / O responsible for gathering data and signals, which may include a data coordinator function for collecting and preprocessing raw data (filtering, aggregating, and / or transforming) and managing data flows to various topics or endpoints. The gathered data can include sensor signals such as flow rate, pressure, temperature, vibration, acoustics and power consumption, which are provided by one or more sensors 51. The sensors 51 may belong to the pump 11. The gathered data may also include standard pump parameters such as operating hours, starts and stops, speed and duty cycles, motor electrical parameters and leak detection. The gathered data can include a user input (typically Operations Manager or Service Manager) such as operational setpoints, maintenance history and manual controls. The gathered data may also include environmental data such as ambient temperature and humidity levels. The gathered data may also include process variables such as fluid characteristics, customer preferences, supply chain data and system demand.

[0103] The control entity 10 may comprise a message broker (server) that is configured to act as an intermediary for messages. The message broker may receive data flows and may map them onto topics, and may distribute them to subscribing clients interested in those messages. The message broker can be based on Message Queuing Telemetry Transport (MQTT) protocols, web services, Advanced Message Queuing Protocol (AMQP), Constrained Application Protocol (CoAP), web socket protocols, or other message broker setups and protocols. The topics published by the message broker may include pump status, pump operation mode, pump performance flow rate, pump performance pressure, pump control set speed, pump control start and / or stop, pump control set mode, pump maintenance schedule, pump maintenance logs, pump alerts warnings, pump diagnostics heartbeat, pump diagnostics error codes, pump energy usage, pump energy efficiency, pump configuration update, pump firmware update, etc.

[0104] The control entity 10 may comprise an edge processor for local (on edge) data processing, analytics, and decision making. The edge processor may utilize a container engine (may be software) for creation, management and use of containers to runs functionalities on the edge device. Containers may be standalone, executable software packages that include everything needed to run a piece of software, including the code, runtime, system tools, libraries, and settings. These functionalities can include analytics containers for pressure and flow analysis, vibration analysis, energy efficiency analysis and anomaly detection containers. The functionalities can further include control and adjustment containers for motor (drive) speed adjustment or adaptive control and safety monitoring. Further, the functionalities can also include request containers for internal commands and external system requests, or communication containers for threshold and / or limit alerts, or machine learning inference. The functionalities can also include maintenance containers for diagnostics and predictive maintenance, etc. The control entity to may comprises an edge data memory for storing data on the edge, which may include a data logger software that writes data on the database. A rolling window (optimal time frame) may be kept with backup data / snapshots of events, stored locally.

[0105] The control entity to may comprise embedded control systems to execute control actions locally based on the data they process. This allows for immediate adjustments to machinery or process settings, facilitating automated control systems that can operate with minimal latency.

[0106] The control entity to may provide edge connectivity supporting various protocols for communication for sending and receiving messages between the edge and the backend platform message brokers.

[0107] FIG. 6 shows an exemplary implementation of a management entity 15 at a backend platform hub. The management entity 15 is used for centralized control and orchestration of the edge devices (control entities 10, pumps 11), thus enabling remote monitoring, commissioning, analysis and optimization. Managing, processing and analyzing data collected from the edge devices, management entity 15 orchestrates the overall system, sending back commands, configurations and updates based on the data received and analyses conducted. The architecture of the management entity 15 maybe based on cloudnative principles. It may be cloud-agnostic and may be operated based on cloud services (including hybrid clouds, multi-cloud, distributed clouds and other cloud solutions) or on premise (e.g., if national, regional or industry-specific regulations mandate it).

[0108] The management entity 15 may comprise a connectivity module that is configured to handle the communication protocols and network interfaces that enable the management entity 15 to connect with edge devices and message brokers, ensuring seamless data transfer.

[0109] The management entity 15 may comprise a message broker that is configured to manage the ingestion and distribution of messages, commands and requests for data, routing them efficiently to and from the correct clients within the platform. The message broker may include a platform application programming interface (API) that provides standardized endpoints for interaction with the backend system, allowing external systems and services to request data, send commands, and listen for changes via API calls. The management entity 15 may comprise microservices for creating a collection of independent, single-purpose services that perform their small part of the larger platform functionality. With a cloud storage infrastructure of data repositories used by microservices, enabling easy access and retrieval of information. The microservices can include pump status monitoring, alarm and event management, task management, data analytics, device management, configuration management, provisioning, commissioning, remote control, authentication and authorization, firmware update, etc.

[0110] The management entity 15 may comprise a functionality engine that facilitates the deployment, scaling and management of applications (using containers) to run backend functionalities including analytics, using cloud processing infrastructure.

[0111] The management entity 15 may comprises a user interface that enables users to interact with the backend system, monitor processes and input commands.

[0112] The management entity 15 may also comprise a digital device representation (digital twin) that virtually represents the physical devices (pump systems), serving as a simulation and testing environment to its physical counterpart.

[0113] In the following, some exemplary operations based on the architecture including the control entity 10 and the management entity 15 are described with respect to the FIGs. 7- 10. FIG. 7 illustrates an exemplary flow of an event-driven minimal data transfer from the control entity 10 to the management entity 15. FIG. 8 illustrates another exemplary flow of an event-driven minimal data transfer from the control entity 10 to the management entity. FIG. 9 illustrates an exemplary flow for data burst mode activation at the control entity 10. FIG. 10 illustrates an exemplary flow for state configuration at the control entity 10 by the management entity 15.

[0114] The event-driven, minimal data transfer communication from the control entity 10 (or control entities 10) to the management entity 15 at the backend platform shown in FIG. 7, may be configured to prioritize the autonomy of the control entities 10 devices in making decisions and taking actions. A control entity 10 may monitor for and detect specific events, conditions or thresholds that are met (e.g., changes in environmental parameters, device status updates, or critical events) before initiating communication with the management entity 15. The events may be predefined events. The events can include operational threshold events, such as system throughput, excessive pressure, flow rate anomalies, temperature variances and vibration levels. The events maybe environmental condition events, such as ambient temperature changes, humidity levels and water ingress; system status updates such as start / stop cycles, energy usage spikes and runtime intervals, critical events such as seal failures, power failures, loss of communication, and hardware faults. It can also include wear and tear patterns, energy efficiency ratios, pump performance degradation, unauthorized access attempts, safety limit violations, demand response signals, manual overrides, set-point adjustments, mode switching, time-based controls and periodic testing.

[0115] Communication may be automatically initiated based on the occurrence of events on the edge, i.e. by the control entity to. On detection of events, the control entities may send relevant data to the cloud for further analysis and historical record-keeping. The data transfers may be kept to a minimum, i.e. they may be limited to what is necessary for the purposes of obtaining information about and handling events. To this end, the control entities to may employ algorithms to filter out redundant, irrelevant, or non-critical data, and aggregate essential information. This may ensure that only meaningful, compressed, and relevant data sets are transmitted, further optimizing bandwidth usage and reducing costs. This is in contrast to continuous or periodic data streaming, and can significantly reduce the volume of data transferred over the network. The solution may also comprises event producers that generate events and event consumers that respond to them, mediated by event brokers that distribute events efficiently.

[0116] The control entities to maybe able to dynamically adjust data transmission frequency and payload based on current network conditions, device (e.g. pump) status, and the importance of the information. For example, it may choose to disallow high-frequency data in the event of poor bandwidth availability. The solution may prioritizes the autonomy of the control entities to in making decisions about when to send data to the command center, based on the occurrence of specific, e.g. predefined events.

[0117] As the architecture of this disclosure may be modularly scalable, it allows for high degree of evolutionary feature adaptations if required in the future. The architecture may be designed for extensibility if additional capabilities are identified at later stages.

[0118] An example of an event-driven minimal data transfer edge-to-backend communication flow may be, like shown in FIG. 7, as follows:

[0119] 1. Pump raw data (e.g., a signal or command) input is collected from the pump on the edge I / O by the data coordinator of the control entity 10 (from sensors or on-pump user interface). The data coordinator may filter, aggregate and transform the raw data.

[0120] 2. The message broker server of the control entity to receives the data, and maps the data onto a topic (stores measured sensor values), which allows for subscription of the data by a core module.

[0121] 3. The core module consumes the data and produces core data.

[0122] 4. The core module routes the processed data onto a designated topic for core values.

[0123] 5. In parallel, an edge database is fed with data by a data logger. It continuously logs data provided by the core module. The database may store historical and real-time data for retrieval and analysis for a predefined period of time in order to not fill the memory.

[0124] 6. A limits container (e.g., analytics function) monitors data thresholds and generates an event when a predefined threshold or limit is exceeded. The limits container may be a software construct that may define the boundaries or thresholds within which data must fall, may monitor compliance with these boundaries or thresholds, and may triggers alerts if the data falls outside these limits.

[0125] 7. An analytics event topic is created and is sent along.

[0126] 8. A request telemetry topic is created.

[0127] 9. A request handler functionality is notified and / or triggered and takes the relevant data out the database. It compiles telemetry data associated with the event to understand the problem context.

[0128] 10. A send telemetry topic is created.

[0129] 11. An edge connectivity module (e.g., loT hub client) listens in on events and can sends the minimal data package along to the backend platform via the platform connectivity module for further action or record. 12. On the platform, a message broker publishes (ingestion) an event topic that is consumed by microservices designated to handle such events, e.g. a functionality event service, a task service, a device service, etc.

[0130] 13. A microservice registers the event in the respective database (e.g., cloud storage).

[0131] 14. Based on the nature of the event, different platform functionalities can be called on to by the microservice (via the message broker topics) to act on the event. For example, to analyze the root cause of the event, analyze if the pump know is running optimally or if settings should be changed, etc. The event can also trigger an event task (“ticket”) to be published in the user interface for command center user to act on. In some embodiments it can also utilize the digital device representation (digital twin) in analyzing and simulating pump performance based on the event. And it will determine if it is necessary to send further data (requests, instructions, etc.) to edge device.

[0132] A complementary example of an event-driven minimal data transfer edge-to-backend communication maybe, like shown in FIG. 8, as follows:

[0133] Steps 1-5 are the same as in the example of FIG. 7 above.

[0134] 6. An auto-settings container (e.g., analytics function) monitors core data and generates an event when a predefined data point is triggered, indicating that pump settings automatically should be adjusted (e.g. to avoid critical failure).

[0135] 7. An analytics event topic is created and is sent along.

[0136] 8. An adjust settings / control mode topic is created.

[0137] 9. The command handler functionality is notified / triggered and instructs embedded control systems to make adjustments. Task resolution automation may be performed. For example, leveraging artificial intelligence (Al), the solution can automate the resolution of detected issues wherever possible. For instance, if a common issue is detected and verified, the solution may also automatically apply a known fix without human operator intervention (if allowed by, in in compliance with regulation such as the EU Al Act). By automating routine, repetitive tasks, the solution ensures that human operators are engaged only when their expertise is genuinely needed. This not only conserves human resources but also speeds up resolution times, enhancing system reliability and user satisfaction. to. The embedded control systems actuates changes on the pump according to the current situation (if agreed in customer contract).

[0138] In accordance with the steps 8-14 of the previous example shown in FIG. 7, telemetry data is requested and retrieved, resulting in the connectivity module sending the minimal data package along to the backend platform for further action or record, handed via microservices on the platform (the steps 11-17 in this example).

[0139] FIG. 9 illustrates an exemplary flow for data burst mode activation for the data transfer from a control entity 10 to the management entity 15.

[0140] The data burst mode transfer from the edge (control entity 10) to the backend (management entity 15) may override the default behavior of the minimal data transfer (see e.g., FIG. 7 and FIG. 8), and allows for intensive transmission of data at a higher volume, resolution, or frequency (e.g. raw time-series data). This functionality can be activated under specific conditions or upon request, catering to various scenarios where enhanced data granularity is critical for short periods. For instance, for serviceability and remote troubleshooting.

[0141] The data burst mode can be activated through various triggers, such as a manual request from a user via a control interface (e.g., end-customer or by command center service experts), the occurrence of a (predefined) event, or when the system's Al detects a scenario requiring detailed data analysis. This flexibility ensures that the mode is used effectively and in situations where it provides the most value.

[0142] Before activation, users may specify parameters for data burst mode, including the duration (how long the mode should last) and the resolution or granularity of the data to be transmitted (e.g., second-by-second telemetry). This allows for tailored data collection efforts that meet the precise needs of the situation. Despite the increased data transmission, the system may optimally manage device resources to prevent overload or excessive consumption of compute resources through intelligent resource management. After the specified duration ends, the control entity 10 may automatically revert to its standard operational mode, resuming minimal data transfer (automatic return to baseline). This ensures that the intensive data transmission does not persist beyond its useful period, maintaining overall system efficiency and resource conservation.

[0143] The burst of high-resolution data provides an opportunity for in-depth analysis, either in real-time or after the fact. This analysis may uncover trends, anomalies, or insights that are not visible under normal operation modes, leading to actionable intelligence for system optimization, predictive maintenance, or training or re-training of algorithms and machine learning models.

[0144] An example of a data burst mode activation maybe, like shown in FIG. 9, as follows:

[0145] 1. A command center user (of the management entity 15) determines the need for more data and activates data burst mode (can also be automatically activated by the system, e.g. by the management entity 15 or by the control entity 10), and specifies the parameters for what the data burst mode shall collect and the duration. That is, the management entity 15 may request additional data from the control entity, and may ask the control entity 10 to send the requested additional data using the data burst mode.

[0146] 2. Via message broker module and connectivity module, the data burst request is sent from the management entity 15 to the control entity 10.

[0147] 3. The message broker of the control entity 10 registers a request data burst topic.

[0148] 4. A data burst request handler functionality is notified and / or triggered and takes the relevant data out the edge database based on the specified parameters and duration. The data can be historical and (near) real-time data managed by the data logger.

[0149] 5. A send data burst topic is created.

[0150] 6. The edge connectivity module (e.g., loT hub client) listens in on events and can sends the data burst along to the backend platform via the platform connectivity module for further action or record.

[0151] 7. Upon data burst completion, the device automatically reverts to its standard operational mode of resuming minimal data transfer. FIG. 10 illustrates an exemplary flow for state configuration at the control entity 10 by the management entity 15.

[0152] The edge devices (control entities 10) may be provisioned (set up, commissioned, configured, updated, settings adjusted, change operational mode, etc.) through desired state configuration events. The desired state for how a control entity 10 should operate, including its settings, behaviors and the software that it runs, can be defined through a set of central, declarative configuration files called “software profiles”. These software profiles can be seen as “bill of materials” combining for example configurations, container images and APT packages for the functionality that is going to be provisioned. Software profiles allow device settings to be tested as one collective configuration on the backend. This ensures that the entire complement of devices is configured optimally and harmoniously. By using these profiles with digital twin implementations, the backend platform can simulate and validate system performance before deployment, which helps to preemptively identify and resolve any potential issues. This preemptive testing and configuration help guarantee that the customer will have a good experience with it, as it reduces the likelihood of encountering unexpected problems during actual operation.

[0153] The software profiles can be stored in a provisioning database on the backend platform. Through a provisioning microservice, different software profiles (desired state configurations) can be selected and deployed for different devices, or the same configurations across all devices in a system. The software profile (describing the desired state configuration) is communicated from the management entity 15 to the control entity 10 as an event.

[0154] The control entity 10 may automatically ensures that it is brought into the desired state. The control entity 10 may automatically ensure that it remains in the desired state. Any drift from this configuration can be identified or auto-corrected by the system. This involves continuously monitoring the device's configuration and automatically applying corrective actions if deviations from the desired state are detected.

[0155] Local algorithms can predict potential deviations and proactively apply corrective measures, ensuring devices operate optimally with minimal human intervention. This allows for modular, repeatable deployment of configurations.

[0156] An example of a desired state configuration maybe, like shown in FIG. 10, as follows: The management entity 15 (backend center or a command center) user sees the need to make changes on e.g. a pump 11 (provision, set up, commissioned, configured, updated, settings adjusted, etc.), and instructs the management entity 15 to act. This maybe a response to pump events and tickets raised from the control entity 10 (see above in the event-driven, minimal data transfer communication). Via the platform message broker and the API, a provisioning microservice is called upon. The microservice extracts e.g. the pump’s software profile from the database. The API layer could also ensure that the call is authenticated and authorized for the operation. The provisioning microservice processes the request and interacts with a provisioning application and / or functionality to analyze the software profile and define the desired state. It could use available related data such as operational performance metrics, historical data and trends, events and anomalies, error codes and diagnostic information, and user-defined operating parameters to analyze the situation. The system may request a data burst to get additional data to analyze (see e.g. data burst mode communication above). In particular, the management entity 15 may send a request for the additional data and / or the use of the data burst mode to the control entity 10. By utilizing the related digital device representation (digital twin) the software profile is tested as one collective configuration. The virtual model of the pump 11 is used to simulate the operation and assess the desired state configuration, ensuring that it is optimal before applying them to the actual physical pump 11. This lessens the risk of misconfiguration and downtime. Once the settings are confirmed to be satisfactory, the provisioning microservice defines a desired state configuration for the pump, which includes all the necessary parameters and settings required for its operation, and stores it in the software profile database. The message broker system send the desired state configuration message to the pump 11 via the platform connectivity module (secure connection). The message broker ensures that the configuration message is delivered efficiently and securely to the target entity, accounting for network conditions and reliability. 7. The control entity to for the pump to receives the software profile (describing the desired state configuration) and automatically ensures that the pump 11 and / or control entity to is brought into the desired state. This is directed by the message broker creating relevant topics consumed by analytics and control functionalities implementing changes to pump settings and software. This includes installing, updating, or configuring software, modifying system settings, or even adjusting the device's operational parameters. The control entity to may perform self-checks to ensure the desired state configuration is applied correctly.

[0157] 8. Throughout this process, the edge data storage is updated for logging and recordkeeping.

[0158] 9. When the desired state is reached, the control entity 10 sends a list of updates to the backend platform which does the record keeping, to ensure that the complete desired state has been obtained. If the desired state cannot be reached, or if the edge device fails in any way, an analytics event is generated and sent with relevant event data to the backend platform (see e.g. the event-driven, minimal data transfer communication above).

[0159] 10. Subsequently, a success notification or status update is provided to the user through the user interface, confirming that the provisioning is complete (or not).

[0160] 11. The backend platform updates the system to reflect the newly provisioned state of the pump, including updating the respective digital twin implementation to match the new state.

[0161] In the following, a learning system feedback loop is described. Based on the architecture and the communication means it provides (described above), the system of management entity 15 and control entity 10 may automatically and / or user-initiated run learning system feedback loops. This may be done to utilize information generated by the control entities 10 and / or pumps 11, and / or the management entity 15, to continuously enhance the accuracy, efficiency and overall performance of the solution of this disclosure.

[0162] The system may self-improve and automatically gathers data when needed for learning, without human intervention. Regular feedback loops are run to backend analytics for increased insight into the resolution of problems and root causes related to device operations, alerts and errors. By collecting outputs and results, analyze them, and use that information to improve future performance or decision-making. These loops allow systems to adapt and evolve over time, enhancing their effectiveness or efficiency based on their experiences and the data collected through their operations. This approach involves using data collected to iteratively refine and improve e.g., algorithms, models and task resolution templates.

[0163] The feedback loops may include events from functionality modules. The aim of the feedback loop is to refine the accuracy of predicted root causes as well as identify false positives. The feedback loop collects: Predicted root cause (to be compared with actual root cause) and Transmitted events (to be compared with rejected events).

[0164] The feedback loops may include user action and usability. The aim of the feedback loop is to increase the usability of task resolution by analyzing user actions. The analysis can lead to improvements (e.g., automation) of task resolution by e.g., pre-loading specific data, removing rarefy used subtasks etc.

[0165] The feedback loops may include continuous size evaluation. The aim of the feedback loop is to improve the logic behind pump selection. The feedback loop collects and compares pump suggested during sizing and purchasing with pump suggested by a continuous size evolution algorithm (post-installation).

[0166] The feedback loops may be based on a demand. The aim of the feedback loop is to gain insight into the purchasing process and whether supply (in terms of e.g., QH-ranges) matches demand. The feedback loop may collect: Which parameters (e.g., Q, H) did the customer input? Was there a match? Was an order placed?

[0167] The feedback loops may aim for product improvement. The aim of the feedback loop is to enable data-driven product improvement by providing structured and aggregated data on failures in the field. The feedback loop collects Information on which parts are being replaced. Location of replacements (in case parts are installed in more than one location in the pump, e.g., impellers), Repairs (type, location, etc.), Root cause of repair or replacement. In addition, the collected information can be explored in different context, e.g., failures in relation to pump type (rotation of in- / outlet), pump placement, geography, business segment, location etc.

[0168] The feedback loops may aim for field service. The aim of the feedback loop is to improve the instructions that accompany a field service ticket for an installer acting on behalf of the pump owner. The feedback loop may collects: information on actual root cause (to be compared with predicted root cause), information on actual action taken (to be compared with suggested action).

[0169] In summary, the solution of this disclosure, as implemented by the control entity to, the management entity 15, and / or the methods 20, 30 provides several advantages.

[0170] For instance, it provides reduced data transfer and costs. In particular, it significantly reducing the volume of data transferred over the network. Addresses the challenges of bandwidth limitations and associated costs (e.g., centralized storage of data).

[0171] Further, it provides system scalability. In particular, the architecture enables a scaling the number of devices without requiring a linear increase in network capacity or central processing resources, allowing organizations to expand their fleet of connected pumps with minimal impact on network infrastructure, effectively avoiding the bottleneck that could occur with a more centralized system. As the system scales to include more edge devices, the centralized command center isn't linearly taxed with additional operational oversight, which would be the case in traditional architectures, and the network is not burdened with the data traffic that would result if all raw data were sent back to a central point for processing. As the system scales and the number of edge devices grows, this selective data transmission ensures that the network traffic increases only marginally relative to the number of devices. The solution also eases the management of a large number of pumps 11 and / or control entities 10, by applying the same configuration across multiple devices efficiently.

[0172] Further, it provides sustainability. For example, by minimizing the amount of data that needs to be transmitted across networks, organizations can achieve more environmentally friendly operations.

[0173] Further, it enables automation. A high degree of automation is key to achieving scalability and efficiency, particularly regarding resources staffing the command center. Reducing the need for manual configuration and intervention, thereby lowering the potential for human error and freeing up resources for other tasks.

[0174] Further, it ensured continuous operation. The automated nature of the architecture allows systems to remain in, or return to, their desired operational state with minimal manual oversight, ensuring continuous and reliable operation. Also when connection to the backend is limited.

[0175] Further, it is compatible with a learning system. Feedback loops enable continuous improvements in the system's operations. Edge devices and the backend platform can use collected data and previous resolutions of the same problem in a previous setting to finetune processes, increasing overall efficiency, reliability, and performance without human intervention.

[0176] Further it allows for self-healing and self-improvement. Control entities to may be enabled to automatically return to their desired state after a failure or deviation, improving system resilience and uptime.

[0177] Further, it decreases latency and increases responsiveness. An intelligent edge device with local decision-making capabilities can respond to local events much faster, enhancing the efficiency and responsiveness of the device (i.e., the pump or set of pumps).

[0178] Further, it enhances privacy and security compliance. With reduced data transfer, there’s a decreased risk of sensitive information being intercepted during transmission. Furthermore, the concept incorporates robust encryption and security protocols to protect the data that is transmitted, enhancing the overall security posture.

[0179] In the claims as well as in the description of this disclosure, the word ‘comprising’ does not exclude other elements or steps and the indefinite article ‘a’ or ‘an’ does not exclude a plurality. A single element may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

CLAIMS1. A control entity (io) for a pump (11), wherein in a first data transfer mode the control entity (io) is configured to monitor one or more parameters (12) related to the pump (11); resume a wireless connection (13) with a management entity (15), if an event is detected based on the one or more parameters (12); transmit data (14) related to the detected event to the management entity (15) using the wireless connection (13); and suspend the wireless connection (13) after transmitting the data (14) related to the detected event to the management entity (15).

2. The control entity (10) according to claim 1, configured to exclusively transmit the data (14) related to the event after the wireless connection (13) is resumed and before the wireless connection (13) is suspended.

3. The control entity (10) according to claim 1 or 2, configured to detect the event, if a value of at least one of the parameters (12) related to the pump (11) changes by more than a threshold value and / or fulfills a certain condition.

4. The control entity (10) according to one of the claims 1 to 3, further configured to change from the first data transfer mode to a second data transfer mode; wherein in the second data transfer mode the control entity (10) is configured to transmit a data burst to the management entity (15), wherein the data burst has a higher resolution and / or transmission frequency than the data (14) transmitted in the first data transfer mode.

5. The control entity (10) according to claim 4, configured to automatically resume the first data transfer mode at a predetermined time after transmitting the data burst.

6. The control entity (10) according to claim 4 or 5, configured to receive, in response to transmitting the data (14) related to the detected event, a request for additional data from the management entity (15); and transmit the data burst comprising the requested additional data to the management entity (15).7- The control entity (10) according to one of the claims 1 to 6, further configured toreceive a data transfer configuration message (17) from the management entity (15); and set or change, based on the data transfer configuration message (17), at least one of: the first or the second data transfer mode; a threshold value for at least one of the parameters (12) related to the pump (11); a condition for at least one of the parameters (12) related to the pump (11).

8. The control entity (10) according to one of the claims 1 to 7, configured to receive one or more data flows indicating the one or more parameters (12) related to the pump (11); and associate the one or more data flows to respectively one or more topics.

9. The control entity (10) according to claim 8, further configured to transmit a notification message related to a topic to one or more client entities, which are subscribed for the topic at the control entity (10); wherein the notification message includes information regarding at least one of the parameters (12) related to the pump (11).

10. The control entity (10) according to claim 8 or 9, wherein the topic includes at least one of: a status of the pump (11); an operation mode of the pump (11); a data transfer mode of the control entity (10); a performance of the pump (11).

11. The control entity (10) according to one of the claims 1 to 10, configured to obtain one or more sensor signals from respectively one or more sensors (51) integrated in or connected to the pump (11) or the control entity (10); wherein the one or more sensor signals indicate at least one of the parameters (12) related to the pump (11).

12. The control entity (10) according to claim 11, wherein the one or more parameters (12) related to the pump (11) indicated by the one or more sensors signals comprise at least one of: a flow rate of the pump (11); a pressure of the pump (11);a temperature of the pump (11); a vibration of the pump (11); an acoustic profile of the pump (n); a power consumption of the pump (n).

13. The control entity (10) according to one of the claims 1 to 12, wherein the one or more parameters (12) related to the pump (11) comprise at least one of: a standard pump parameter; a parameter received by user input; an environmental parameter; a process parameter; a system parameter.

14. The control entity (10) according to one of the claims 1 to 13, configured to pre- process at least one of the one or more parameters (12) related to the pump (11) when monitoring the one or more parameters (12), wherein the pre-processing comprises at least one of: filtering at least one of the parameters (12); aggregating at least some of the parameters (12); transforming at least one of the parameters (12).

15. The control entity (10) according to one of the claims 1 to 14, configured to perform an analytics operation on the one or more parameters (12) related to the pump (11), in order to detect an event, wherein the analytics operation comprises at least one of: a pressure and / or flow analysis based on a parameter (12) indicating a pressure and / or flow-rate of the pump (11); a vibration analysis based on a parameter (12) indicating a vibration of the pump (n); an energy efficiency analysis based on a parameter (12) indicating a power consumption of the pump (11).

16. The control entity (10) according to one of the claims 1 to 15, further configured to select at least one control action based on the detected event; and execute the at least one control action to control the pump (11) accordingly.

17. The control entity (10) according to claim 16, whereinthe at least one control action comprises an adjustment of a pump speed of the pump (11).

18. The control entity (10) according to one of the claims 1 to 17, further configured to provide, to the management entity (15), learning data based on the detected event and / or based on a control action selected based on the detected event; and / or receive, from the management entity (15), learning data related to detecting events and / or selecting a control action based on a detected event.

19. A management entity (15) for managing one or more pumps (11), the management entity (15) being configured to wirelessly transmit a data transfer configuration message (17) to a control entity (10) of at least one of the pumps (11); wherein the data transfer configuration message (17) is adapted to instruct the control entity (10) to set or change a configuration of an event-driven data transfer (14) from the control entity (10) to the management entity (15).

20. The management entity (15) according to claim 19, further configured to receive data (14) related to an event detected by the control entity (10); and / or send the data transfer configuration message to the control entity (10) in response to received data (14) related to an event detected by the control entity (10).

21. The management entity (15) according to claim 20, further configured to send, in response to receiving the data (14) related to the detected event, a request for additional data to the control entity (10); and receive a data burst comprising the requested additional data from the control entity (10).

22. The management entity (15) according to one of the claims 19 to 21, wherein the data transfer configuration message (17) is adapted to instruct the control entity (10) to set or change at least one of: a data transfer mode of the control entity (10); a threshold value for at least one parameter (12) related to the pump (11), wherein a change of a value of the parameter (12) by more than the threshold value indicates that an event occurred; a condition for at least one parameter (12) related to the pump (11), wherein the parameter (12) fulfilling the condition indicates that an event occurred.

23. The management entity (15) according to one of the claims 19 to 22, wherein the data transfer configuration message (17) is adapted to instruct the control entity (10) to set or change at least one criterion for changing from between any two of a first data transfer mode, a second data transfer mode, and a third data transfer mode by the control entity (10).

24. A pump (11) for pumping a fluid, wherein the pump (11) comprises the control entity (10) according to one of the claims 1 to 18.

25. A system comprising at least one pump (11) according to claim 24 and comprising a management entity (15) according to one of the claims 19 to 23, wherein the management entity (15) is configured to wirelessly communicate with each of the at least one pump (11).

26. A method (20) for controlling a pump (11), wherein in a first data transfer mode the method (20) comprises: monitoring (21) one or more parameters (12) related to the pump (11); resuming (22) a wireless connection (13) with a management entity (15), if an event is detected based on the one or more parameters (12); transmitting (23) data (14) related to the detected event to the management entity (15) using the wireless connection (13); and suspending (24) the wireless connection (13) after transmitting the data (14) related to the detected event to the management entity (15).

27. A method (30) for managing one or more pumps (11), the method (30) comprising wirelessly transmitting a data transfer configuration message (17) to a control entity (10) of at least one of the pumps (11); wherein the data transfer configuration message (17) is adapted to instruct the control entity (10) to set or change a configuration of an event-driven data transfer from the control entity (10) to the management entity (15).

28. A computer program comprising instructions which, when the program is executed by a processor of a control entity (10) or a management entity (15), instruct the processor to cause the control entity (10) or the management entity (15), respectively, to perform the method (20, 30) according to claim 26 or 27.

Images