Advanced user interaction interface for smart pump

Abstract

The present disclosure relates to a pump system. This disclosure proposes a control entity for a pump. The control entity comprises: an interface layer configured to facilitate interactions with a user, wherein the interactions comprise taking a verbal command from the user; a command interpretation module configured to interpret the verbal command using a first language model to determine a request of the user; and an action decision engine configured to determine one or more actions to be executed by the pump based on the request, and initiate the one or more actions.

Description

[0001] ADVANCED USER INTERACTION INTERFACE FOR SMART PUMP

[0002] TECHNICAL FIELD

[0003] This disclosure relates generally to the field of industrial equipment management and, more particularly, to an advanced system for controlling and optimizing the operation of industrial pumps using voice-activated commands. This disclosure involves the development of intelligent systems that can understand and respond to user commands, providing a more efficient and user-friendly experience in operating and managing pump systems.

[0004] BACKGROUND

[0005] Industrial pumps are crucial for the efficient movement of fluids in numerous processes and applications. However, the operation and maintenance of these pumps typically require significant technical expertise, traditionally provided by skilled craftsmen. With shifting workforce trends and a decrease in available skilled personnel, there is a heightened need for more accessible and user-friendly pump systems.

[0006] Traditional pump systems are characterized by their reliance on complex manual controls and user interfaces, which can be daunting for operators lacking technical expertise. This complexity not only increases the likelihood of operational errors, but also impacts the overall effectiveness and longevity of the pumps. The need for frequent and often complex interactions with the pump's control system for adjusting settings or modes further exacerbates these challenges.

[0007] Moreover, accessing detailed operational data and performing routine status checks can be cumbersome, generally involving navigating through intricate software applications or manually reviewing extensive logs. This can lead to inefficiencies in monitoring and maintaining the pump's performance, ultimately affecting the processes it supports. The integration of advanced digital functionalities into pump systems, while potentially beneficial, often adds an additional layer of complexity that can deter the optimal utilization by everyday users. Current pump systems also lack intuitive interfaces and flexible remote control capabilities, which are crucial for modern industrial environments where immediate adjustments and real-time data analysis are often required.

[0008] Given these challenges, there is a need for an innovative pump control system that simplifies user interaction, enhances accessibility to operational data, and integrates advanced digital features without overwhelming the user.

[0009] SUMMARY

[0010] In view of the above-discussed challenges, this disclosure aims to introduce a smart pump system equipped with computing means to handle user commands on the edge. One objective is to enable advanced user interactions directly with the pump using natural language. Another objective is allowing the pump to automatically analyze its operational data, metadata, and logs in real time, and respond to user requests. Yet another objective is to improve system efficiency and reduce resource costs.

[0011] These and other objectives are achieved by the solution of this disclosure as described in the independent claims. Advantageous implementations are further defined in the dependent claims.

[0012] According to a first aspect of the disclosure, a control entity for a pump is provided. The control entity comprises: an interface layer configured to facilitate interactions with a user, wherein the interactions comprise taking a verbal command from the user; a command interpretation module configured to interpret the verbal command using a first language model to determine a request of the user; and an action decision engine configured to determine one or more actions to be executed by the pump based on the request, and initiate the one or more actions.

[0013] The proposed control entity offers the advantage of providing a highly interactive and user-friendly interface, which can understand verbal user commands and can respond to the user commands effectively and efficiently. This allows the pump to be equipped with computing capabilities, such as the capability to interpret the user's intention based on the voice command, and the capability to decide on actions based on the user's intention, and provide a response to the user. The solution of this disclosure enables the pump system to understand and respond to user commands more accurately and effectively, thereby improving the overall user experience. It also allows the system to provide personalized responses and actions based on the specific needs and intentions of the user, thereby enhancing user satisfaction. Notably, the language model referred to in this disclosure maybe a large language model (LLM).

[0014] Optionally, the verbal command is a voice command and / or a text command, wherein the interface layer comprises a speech module configured to capture the voice command spoken by the user, and / or a display configured to capture the text command input by the user.

[0015] Possibly, the user is allowed to interact with the pump system using alternative input methods. For instance, the user may provide a voice command, or the user may provide a text command, or the user may provide both. This feature provides flexibility to the user in terms of how they interact with the system, catering to different user preferences and needs, thereby enhancing user convenience and satisfaction.

[0016] Optionally, the interface layer is further configured to translate the verbal command from one language to another language in real time.

[0017] Possibly, the interface layer is supported by a multilingual speech module. This feature allows the system to cater to users who speak different languages, thereby enhancing the system's accessibility and usability across different user demographics.

[0018] Optionally, the interactions further comprise outputting a verbal response to the user from the pump, wherein the verbal response includes a voice response and / or a text response.

[0019] For example, the proposed control entity is able to provide users with clear and immediate feedback about the status of their requests (e.g., including “in progress, please wait”), thereby enhancing the user experience and system transparency. In another example, after attempting an action, the control entity may provide feedback to confirm whether the action has been implemented (e.g., the problem has been resolved) or if additional action from the user is needed.

[0020] Optionally, the interface layer further comprises a dialogue management component configured to maintain a context related to one or more interactions with the user, wherein the context comprises one or more verbal commands from the user, and one or more verbal responses from the pump.

[0021] Possibly, the control entity is able to handle multi-turn conversations, where the context of the user interaction needs to be maintained over several exchanges.

[0022] Optionally, the first language model is a domain-specific language model tailored to recognize and respond to language inputs related to a pump domain.

[0023] Possibly, the first language model is trained to make the pump domain using natural language processing techniques such as tokenization, lemmatization, and parsing to enable the model to understand the structure of the pump-related language. In a different example, a general language model may also be used, such as it is designed to understand and generate human language across a wide range of topics (including pumps).

[0024] Optionally, the first language model is trained with a dataset specific to the pump domain, wherein the dataset includes one or more of the following: manuals, user commands, maintenance logs, technical documentation, terms and phrases that are commonly used in a pump industry, technical jargon, part names, error codes, metrics, operation procedures, and colloquialisms used by technicians and users.

[0025] It may be understood that each type of data in the training dataset plays a role in building a comprehensive understanding of pump operations, issues, and maintenance practices. Together, these data help in training the language model more effectively by providing real-world examples and outcomes, thereby improving reliability and intelligent interpretation through detailed analytics and adaptive learning.

[0026] Optionally, the one or more actions comprise one or more of the following:

[0027] - retrieving real-time operational data and / or historical data of the pump; - analyzing the real-time operational data and / or the historical data;

[0028] - diagnosing a system malfunction;

[0029] - generating a response to the user based on at least one of the real-time operational data, the historical data, an analysis result, or a diagnostic result;

[0030] - adjusting an operational parameter or a configuration of the pump;

[0031] - scheduling an operational parameter adjustment, a configuration adjustment, or maintenance for the pump;

[0032] - updating software for the pump;

[0033] - prompting the user to provide additional user input;

[0034] - interacting with an external system.

[0035] Based on an understanding of the user’s intention from the verbal command, the action decision engine is configured to decide on a set of one or more actions that correspond to the user's request. It may be understood that it translates the user's intention into actionable tasks that the pump can execute. These tasks mainly focus on operational decisions related to specific user commands.

[0036] Optionally, the action decision engine may comprise or interact with an autonomous agent responsible for managing advanced decision-making tasks, such as context- aware diagnostics and resolution of anomalies. The agent may be implemented using a generic or fine-tuned language model or as a rule-based module, and may operate under a structured execution framework that provides access to real-time system context and available tools. This enables the system to perform complex operations — including fault diagnosis, parameter adjustment, and escalation decisions — without requiring user input. The agent may reside as a subcomponent of the action decision engine or as a separate software layer within the control entity.

[0037] Optionally, the control entity further comprises an information analysis and output module, wherein the action decision engine is further configured to initiate the one or more actions utilizing the information analysis and output module.

[0038] Notably, the information analysis and output module may use fully or partly the same language model as the language recognition module. Alternatively, they may use separate language models. Optionally, the information analysis and output module is configured to:

[0039] - retrieve the real-time operational data and / or the historical data of the pump;

[0040] - analyze the real-time operational data and / or the historical data;

[0041] - diagnose the system malfunction;

[0042] - generate the response to the user based on at least one of: the real-time operational data, the historical data, an analysis result, or a diagnostic result; and

[0043] - transform the analysis result or the diagnostic result into an intelligible language feedback using a second language model.

[0044] Typically, the outcome of data analysis involves complex data. Possibly, the information analysis and output module is responsible for transforming complex data analysis outcomes into intelligible language that can be conveyed through voice or text to the user, thereby facilitating an informative and interactive experience.

[0045] Optionally, the response to the user includes a maintenance recommendation, an operational recommendation, or the diagnostic result, wherein the information analysis and output module is configured to generate the response based on the realtime operational data and / or the historical data of the pump utilizing a machine learning algorithm (MLA).

[0046] For instance, the user may seek advice from the control entity, e.g., the user may ask “When should the next maintenance be scheduled?”. Based on the pump's operational history and data patterns, the control entity is configured to suggest an optimal maintenance window by using the MLA. Notably, the MLA may be trained with a training dataset including a variety of data. For instance, using historical information to train the MLA helps in refining the accuracy of the diagnostic algorithms by learning from the past, such as past mistakes (false positives) and successes (accurate identification of root causes). Operational data are critical for monitoring the pump's performance, detecting anomalies, and diagnosing issues. They form the basis of operational insights and are essential for ongoing system evaluation. Optionally, the second language model is a domain-specific language model tailored to recognize and respond to language inputs related to a pump domain.

[0047] It can be understood that tailoring the language model to a specific domain helps in reducing its size. This is because focusing on a narrower subset of language allows it to be more efficiently adapted for edge computing in the pump domain.

[0048] Optionally, the control entity is further configured to update the domain-specific language model based on the interactions with the user.

[0049] It maybe understood that the first language model and / or the second language model maybe updated with a feedback loop mechanism. This mechanism ensures continuous learning where the language model can learn from new interactions and user corrections, enabling continuous improvement and adaptation to evolving pump domain language and user needs.

[0050] Optionally, the interface layer is further configured to translate the intelligible language feedback to the verbal response.

[0051] Typically, the outcome of data analysis involves complex data. Possibly, the interface layer is responsible for transforming complex data analysis outcomes into intelligible language that can be conveyed through voice or text to the user, thereby facilitating an informative and interactive experience.

[0052] Optionally, the control entity further comprises a user authentication module, configured to verify an identity of the user using an authentication process, before allowing the execution of the one or more actions, wherein the authentication process includes at least one of voice recognition, passcode identification, or a biometric method.

[0053] The user authentication module adds an extra layer of security, ensuring that only authorized users can access and operate the system, thereby preventing unauthorized use and potential misuse. Possibly, before initiating crucial actions (e.g., shutting down the pump), the control entity may request the user to provide further confirmations to avoid wrong operations. According to a second aspect of this disclosure, a smart pump is provided. The smart pump comprises a pump, and a control entity according to the first aspect or any optional implementation form of the first aspect.

[0054] Implementation forms of the smart pump of the second aspect may correspond to the implementation forms of the control entity of the first aspect described above. The smart pump of the second aspect and its implementation forms achieves the same advantages and effects as described above for the control entity of the first aspect and its implementation forms.

[0055] According to a third aspect of this disclosure, a pump system is provided. The pump system comprises one or more pumps, each according to the second aspect.

[0056] According to a fourth aspect of this disclosure, a computer program product, stored on a non-transitory computer-readable medium, is provided. The computer program product comprises instructions that, when executed by a processor of a control entity for a pump, configure the control entity to: facilitate interactions with a user, wherein the interactions comprise taking a verbal command from the user; interpreting the verbal command using a first language model to determine a request of the user; and determine one or more actions to be executed by the pump based on the request, and initiate the one or more actions.

[0057] All steps that are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity that performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements or any kind of combination thereof.

[0058] BRIEF DESCRIPTION OF DRAWINGS The above-described aspects and optional implementations will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

[0059] FIG. 1 shows a control entity according to an embodiment of this disclosure;

[0060] FIG. 2 shows a schematic system according to an embodiment of this disclosure;

[0061] FIG. 3 shows a user interface of a smart pump according to an embodiment of this disclosure; and

[0062] FIG. 4 shows a method flowchart according to an embodiment of this disclosure.

[0063] DETAILED DESCRIPTION OF EMBODIMENTS

[0064] Illustrative embodiments of a control entity for a pump, a smart pump, and a pump system are described with reference to the figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

[0065] In this disclosure, an embodiment / example may refer to other embodiments / examples. For example, any description including but not limited to terminology, element, process, explanation, and / or technical advantage mentioned in one embodiment / example is applicable to the other embodiments / examples. The same elements are labeled with the same reference signs and may function similarly or likewise.

[0066] FIG. 1 shows a control entity 100 for a pump, according to an embodiment of this disclosure. The control entity 100 comprises an interface layer no, configured to facilitate interactions with a user, wherein the interactions comprise taking a verbal command from the user. The control entity 100 further comprises a command interpretation module 120, configured to interpret the verbal command using a first language model to determine a request of the user. The control entity 100 also comprises an action decision engine 130 configured to determine one or more actions to be executed by the pump based on the request, and initiate the one or more actions. The proposed control entity 100 for the pump enables the pump to be equipped with computing means to handle user commands on the edge. The "edge" in this disclosure refers to the part of the smart pump system - which is also a communication system - that is closest to the end users or end devices, i.e., the pumps. Edge devices denote the pumps. The verbal user commands received by the interface layer no, are provided from the interface layer no to the command interpretation module for understanding the command, and based on the understanding of the command the action decision engine 130 can take corresponding action. Notably, data associated with the pump may be stored locally, so that a user can interact directly with the pump using verbal commands, such as a spoken voice command or a text command.

[0067] The control entity 100 may have language models for a) interpreting the intent of user input (no uniform or syntax-specific commands needed) and b) automatically analyzing the pump’s operational data and producing answers to the user questions and / or confirmations of actions performed using voice or text (instead of having a user requesting data from the pump and analyzing it manually).

[0068] In an advantageous embodiment, the control entity 100 may further comprise an autonomous agent responsible for managing high-level decision-making tasks. The agent may be implemented as a generic LLM or a domain-specific model fine-tuned using historical support and service data from back-office operations. It may operate within a structured execution framework, referred to herein as a Model Context Protocol (MCP)-like architecture, which grants access to real-time contextual information (such as pump status, location, and environmental conditions) and to operational tools (including data retrieval, analytics, and configuration interfaces).

[0069] Leveraging this contextual awareness, the agent is capable of executing complex functions autonomously, including fault diagnosis, corrective action execution, and escalation decision-making. When operational anomalies are detected— such as abnormal vibration patterns, pressure deviations, or error codes— the agent may initiate diagnostic routines, determine an appropriate resolution using predefined rules, heuristics, or machine-learned models, and implement the corresponding corrective action (e.g., parameter tuning, software reset, or fallback mode activation). The system may then verify whether the issue has been resolved and, if required, prompt the user for minimal input (e.g., for safety or compliance purposes). This architecture enables a high degree of operational autonomy, reduces dependence on user intervention, minimizes unnecessary data transmission, and contributes to lower downtime and enhanced system resilience.

[0070] The present disclosure allows the user to chat with the pump, possibly via voice, in order to: retrieve information, request analyses, get answers to questions, receive recommendations, and / or provide instructions to the pump. In addition, the pump system can operate independently, performing internal troubleshooting and response actions based on its own initiative.

[0071] The control entity 100 may comprise a processor or processing circuitry (not shown) configured to perform, conduct, or initiate the various operations of the control entity 100 described herein. The processing circuitry may comprise hardware and / or the processing circuitry maybe controlled by software. The hardware may comprise analog circuitry 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 100 may further comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under the 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 operations of the control entity 100 to be performed. In one example, the processing circuitry 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 control entity 100 to perform, conduct, or initiate the operations or methods described herein.

[0072] FIG. 2 illustrates a schematic system for interacting with a smart pump via voice or text, according to an embodiment of this disclosure. FIG. 2 especially shows a smart pump 10 comprising a pump configured to pump a fluid, and a control entity 100 integrated into the pump. Notably, the control entity 100 is the control entity shown in FIG. 1. The pump, which is equipped with the control entity 100, is considered a smart pump. The smart pump 10, namely a pump edge system, is enabled by the on-edge edge computer (e.g., Linux) integrated into the pump system.

[0073] The user is typically an operation manager or a service manager. User input or the output from the pump can be in the form of spoken language or text.

[0074] Examples of user questions and commands are as follows:

[0075] • “How is the pump operating?”

[0076] • "How much water have you pumped today?"

[0077] • "What was the total volume pumped last Tuesday?"

[0078] • "Could you increase the flow rate by io%?"

[0079] • "What is your current operating pressure?"

[0080] • "Do I need to adjust the pressure settings right now?"

[0081] • "Can you provide the flow rate for the last hour?"

[0082] • “Analyze the current performance of the pump”

[0083] • "Are there any alerts or warnings I should be aware of?"

[0084] • “What is malfunctioning in the pump?”

[0085] • "Are there any unusual vibration patterns you have detected?"

[0086] • "Could you guide me through the steps for a manual system check?"

[0087] • "Can you schedule a diagnostics check for tomorrow morning?"

[0088] • “How can we improve the settings to improve operating efficiency?”

[0089] • "Please analyze the efficiency trends from this week."

[0090] • "Are we approaching any critical wear on the pump components?"

[0091] • "Can you predict the expected maintenance needs?"

[0092] • “Should we replace this pump?”

[0093] • “Stop the pump.”

[0094] • “Adjust pump speed to X”

[0095] • “Change the control to use constant pressure using the connected external temperature sensor.”

[0096] • “When reach this, do that”

[0097] • “Change the setpoint to 50%.”

[0098] • “Update all packages to the latest version available.” • "What recommendations do you have to improve system efficiency?"

[0099] • "Please generate a report on system performance for the past month."

[0100] • "Can you lock the system settings until further notice?"

[0101] • "Please verify if the backup pump is in ready condition."

[0102] • "Explain why there has been a 5% drop in throughput this quarter?"

[0103] • "Determine the cause of the sudden noise coming from the pump last night."

[0104] • "Analyze and compare the pump's performance on weekdays versus weekends."

[0105] • "Provide a step-by-step guide to replace the inline filter."

[0106] • "Identify and resolve the reason for the unexpected shutdown that happened this morning."

[0107] • "Decrease the output flow to the minimum safety threshold."

[0108] • "Halt all operations for 5 minutes and then return to normal operation mode."

[0109] • "Perform a system software update during the next inactive period and provide a report afterward."

[0110] • "Compile a daily report of fluid temperatures and pressures and send it to my email."

[0111] • "Start logging detailed energy consumption metrics from now on."

[0112] • "Coordinate with the water treatment system to optimize the purification process timing."

[0113] • "Share the real-time performance data with our facility management platform for integrated resource planning."

[0114] The interface layer no of the control entity 100 may comprise a speech module 111 configured to capture the voice command spoken by the user, and / or a display 112 (not shown in this figure) configured to capture the text command input by the user.

[0115] For instance, the control entity 100 may have a built-in or externally connected microphone. The display 112 may have a keyboard or a virtual keyboard on a touchscreen. The speech module 111 may comprise a speech recognition module, which is configured to convert the captured audio signals from the microphone into text. This may involve: an acoustic model for translating audio signals into phonemes; a language model for predicting the probability of sequences of words to form coherent commands; a speech-to-text module for integrating the acoustic and language models to convert spoken words into text. The speech module may be implemented as software run by a processor.

[0116] The interface layer no maybe configured to output a verbal response to the user from the pump. The verbal response includes a voice response and / or a text response. Possibly, the speech module in may have a text-to-speech module for converting textual responses into spoken feedback. This may involve a voice synthesis engine for producing natural-sounding speech from text. The text-to-speech module may be implemented as software run by a processor. For instance, the control entity 100 may have a built-in speaker for audio feedback.

[0117] It maybe understood that the control entity 100 is designed as a modular system where each module is a functional unit performing specific tasks. These modules may utilize shared hardware resources provided by the control entity 100, such as a common processor or speaker. Possibly, each module may rely on one or more central processors to execute its operations (e.g., specific software) and the shared speaker for audio output.

[0118] The command interpretation module 120 of the control entity 100 may include a natural language processing engine for intelligent interpretation of the user's spoken intent, discerning between requests for information and commands for action. It employs natural language processing and machine learning to understand context and nuances in speech, thereby converting the user's voice requests into a precise information retrieval query or actionable command for the smart pump system. The natural language processing engine may utilize algorithms and models trained on large datasets to understand and generate human language. It may use neural networks that improve the engine's performance over time with more data and usage.

[0119] By using language models to interpret the intent behind the user's voice commands, interactions without the need for uniform or specific syntax are enabled.

[0120] Based on the understanding of the user’s intent, the action decision engine 130 of the control entity 100 decides on the set of actions that correspond to the user's request. It interprets the user's instructions provided via voice commands and translates them into actionable tasks that the pump can execute. For instance, the action decision engine 130 may use one or more processing units or processors for data analyzing and processing decision-making algorithms.

[0121] Optionally, the control entity 100 may further comprise an information analysis and output module 140. The action decision engine 130 may initiate the one or more actions utilizing the information analysis and output module 140.

[0122] The information analysis and output module 140 maybe configured to coordinate and run data analysis on the pump, by processing the pump's operational data. The information analysis and output module 140 may analyze the pump's operational data based on the user's queries, and generate answers or recommendations.

[0123] Similar to the command interpretation module 120, the information analysis and output module 140 may utilize algorithms and models trained on large datasets to understand and generate human language. It may use neural networks that improve the engine's performance over time with more data and usage.

[0124] The information analysis and output module 140 may be configured to use a second language model to interpret the results of data analytics to form coherent, summarized responses for the user.

[0125] This can be fully or partly the same language model as used by the command interpretation module 120. Alternatively, it can be a separate language model.

[0126] Optionally, the interface layer no further comprises a dialogue management component configured to maintain a context related to one or more interactions with the user. The context comprises one or more verbal commands from the user, and one or more verbal responses from the pump. For instance, the context maybe displayed on the display 112 as shown in FIG. 3.

[0127] For instance, the dialogue management component may have access to a storage unit for storing user data, session logs, and historical interaction data, for example, access to a memory. It may use a processor to process and keep track of ongoing interactions within a session. Notably, the smart pump 10 proposed in this embodiment is equipped with language model(s) for interpreting the intent of user input and analyzing data to produce answers to user questions using voice or text. This allows the user to chat with the smart pump 10 to retrieve information, request analyses, get answers to questions, receive recommendations, and provide instructions to change pump operations and make updates.

[0128] It should be understood that the system can comprise one smart pump 10, or multiple smart pumps (with master-slave relationships between pumps and / or in a booster system setup). The system may also comprise pumps connected to other equipment.

[0129] Optionally, the smart pump 10 further comprises a storage medium n configured to store real-time operational data and / or historical data of the pump 10.

[0130] The storage medium n may include a secure database or memory unit within the smart pump 10 that stores all the relevant data, which enables the smart pump 10 to perform immediate data analysis and provide responses. Therefore, instead of looking through the data or the logs of the pump, the user can interact directly with the pump using voice or chat. To some extent, the smart pump 10 can be seen as having a miniature, on-site version of the command center.

[0131] A non-exhausted list of relevant data may include:

[0132] • Operational Data: including pressure readings, flow rates, temperature, and other metrics that indicate the pump's immediate operating conditions.

[0133] • Sensor Data: various pumps might be equipped with sensors that capture data such as vibration, acoustic readings, noise levels, and wear indicators.

[0134] • Configuration Data: settings that define the pump's operational parameters, such as speed settings, pressure limits, and other customizable features as specified by the manufacturer or user.

[0135] • Performance Metrics: data related to the efficiency of the pump, such as energy consumption, output volume over time, and duty cycles.

[0136] • Environmental Data: if relevant, information on the operating environment like ambient temperature, humidity, or presence of potentially damaging substances. • Error Logs: records of any faults, warnings, or errors experienced by the pump, including timestamps and potentially the conditions that led to the fault.

[0137] • Maintenance Records: dates and details of past maintenance activities, repair history, and parts replaced. This can be used to predict future maintenance needs and avoid downtime.

[0138] • User Interactions: historical data of user commands, queries, and interactions with the pump for facilitating improvements in voice recognition and understanding user patterns.

[0139] • Firmware / Software Versions: information about the current firmware and software helping to manage version control and facilitate updates when necessary.

[0140] Optionally, the smart pump 10 may also be connected to a backend data and analytics platform and may determine to retrieve complementary information and run larger analyses on the backend.

[0141] In a different embodiment, the control entity 100 may reside on a handheld or wearable device, such as a smartphone, a tablet, a smartwatch, or smart glasses equipped with, for example, a microphone, a speaker, and Bluetooth connectivity. The handheld or wearable device can wirelessly connect to the pump 10 via Bluetooth or any other wireless communication protocol. It can be understood that the pump 10 may be equipped with a Bluetooth (or any other wireless communication) module for receiving commands.

[0142] According to this embodiment, a built-in microphone of the handheld or wearable device may capture the user’s voice command, the control entity that resides on the handheld or wearable device may convert spoken words into text, and may interpret the text to understand the user’s intent. The device may use Bluetooth to send the processed command to the pump 10. The Bluetooth module in both the handheld / wearable device and the pump 10 facilitates this communication. The handheld or wearable device may provide feedback to the user, either via voice (e.g., using a Text-to-Speech engine) or via visual confirmation on the device’s screen. FIG. 4 shows a detailed method flowchart according to an embodiment of this disclosure. In a particular embodiment, the actions shown in FIG. 4 are performed by the control entity 100 as shown in FIG. 1 or FIG. 2.

[0143] In one embodiment, this disclosure proposes a system for interacting with a smart pump via voice. This embodiment provides more accessible human interfaces with the machine. Voice command functionality allows users to interact with the pump system while multitasking, without the need to use manual controls, touchpads, or computer interfaces. Voice control interfaces are often more intuitive than graphical user interfaces (GUIs), which can alleviate the need for extensive training or technical knowledge to operate the pump system.

[0144] The interface layer no of the control entity 100 maybe a voice-controlled user interface including the speech module ill. It facilitates the communication between the user and the smart pump and serves as the front-end interface that allows for interaction with the smart pump. It takes user input in the form of voice commands or text commands. It may be integrated with a language (voice) recognition module to enable devices to understand and respond to verbal commands.

[0145] The interface layer no may cause an output of a verbal response to the user from the pump, for example, via a loudspeaker. The verbal response includes a voice response and / or a text response. Notably, the interface layer no is further configured to translate the pump's digital responses into voice or text feedback.

[0146] As shown in FIG. 3, the interface layer 110 enables a chat-like dialogue, to record multiple interactions with the user.

[0147] Notably, it comprises hardware and software capable of capturing and interpreting language inputs (voice or text), translating commands into data that the smart pump's computer can process, and analyzing and transcribing spoken language into text.

[0148] Possibly, the interface layer no is configured to provide additional modes of interacting with the smart pump 10 when voice commands are not feasible or convenient. This may include hardware components like touchscreens or keypads and software elements such as a mobile app or web interface, ensuring accessibility for all users and under all conditions.

[0149] Optionally, the interface layer no is further configured to translate the verbal command from one language to another language in real time. It is multilingual - advanced speech modules can translate spoken language from one language to another in real time, enabling cross-lingual communication. This application combines speech recognition, machine translation, and text-to-speech technologies.

[0150] Notably, the control entity 100 may further comprise a user authentication module 150, configured to verify an identity of the user using an authentication process, before allowing the execution of the one or more actions, wherein the authentication process includes at least one of voice recognition, passcode identification, or a biometric method.

[0151] For instance, the user authentication module 150 may have access to a microphone of the control entity 100. Possibly, the control entity 100 may comprise a camera for capturing images or video for facial recognition, or other sensors such a fingerprint sensor for capturing fingerprint data for biometric authentication. The user authentication module 150 may have access to a processor of the control entity 100 for processing algorithms, especially in image and voice recognition. It may also have access to a storage unit of the control entity 100, for example a memory, for retrieving, storing, and processing biometric data in real-time.

[0152] The user authentication module 150 adds an extra layer of security, ensuring that only authorized users can access and operate the system, thereby preventing unauthorized use and potential misuse. It ensures security by verifying the identity of the user interacting with the smart pump 10, allowing authorized voice commands to be executed. By using voice recognition, passcodes, or other biometric methods to ensure that voice commands and data retrieval requests are made by authorized individuals only, it maintains the privacy and security of user interactions.

[0153] Optionally, the user authentication module 150 may be responsible for personalizing the interaction experience based on user preferences and history. It maybe configured to adapt the voice command responses and information delivery to match the user's interaction style and informational needs.

[0154] Possibly, before initiating crucial actions (e.g., shutting down the pump), the control entity may request the user to provide further confirmations to avoid wrong operations.

[0155] The command interpretation module 120 is responsible for user intent comprehension using a language model (e.g. LLM). It enables a smart conversion of questions to wanted information and / or action, without a need for specific queries.

[0156] The command interpretation module 120 may include a natural language processing engine for intelligent interpretation of the user's spoken intent, discerning between requests for information and commands for action. It employs natural language processing and machine learning to understand context and nuances in speech, thereby converting the user's voice requests into a precise information retrieval query or actionable command for the smart pump system. The command interpretation module 120 works in tandem with the speech module 111 (e.g., a voice recognition module) of the interface layer no and the action decision engine 130 to ensure accurate and relevant responses and actions.

[0157] The first language model used by the command interpretation module 120 may be general (i.e., designed to understand and generate human language across a wide range of topics including pumps) or domain-specific.

[0158] Domain-specific language models are trained to make the pump domain using natural language processing techniques such as tokenization, lemmatization, and parsing to enable the model to understand the structure of the pump-related language.

[0159] Possibly, a comprehensive dataset including voice commands, phrases, and interactions specific to the pump domain, may be used to train the first language model. This includes manuals, user commands, maintenance logs, technical documentation, terms and phrases that are commonly used in the pump industry, technical jargon, part names, error codes, metrics (e.g., pressure levels, flow rate), and procedures (e.g., startup, shutdown), colloquialisms used by technicians and users, and any other relevant text or voice data.

[0160] Possibly, historical performance data can be utilized to train various pump models. This may include data on flow rates, head (pressure), efficiency, and power consumption under various operating conditions. Performance curves (e.g., head vs. flow) are particularly valuable, as they illustrate how a pump’s performance changes with different flow rates.

[0161] Optionally, the manuals mentioned above may comprise installation and alignment procedures, providing guidelines for proper pump installation, alignment, and foundation design. These procedures may address alignment tolerances, baseplate leveling, and coupling alignment.

[0162] Safety protocols and hazardous situations may also be covered in the manuals, for example, compiling safety procedures related to pump operation, maintenance, and troubleshooting. These sections may highlight hazardous situations (e.g., handling chemicals, electrical risks) and outline protective measures.

[0163] The manuals may comprise environmental considerations, for instance, detailing how factors such as temperature, altitude, and humidity affect pump performance. The impact of corrosive or abrasive fluids on the pump materials may also be considered.

[0164] The manuals may comprise energy efficiency guidelines, which provide information on optimizing pump efficiency. This may include selecting the right pump type, impeller trimming, and variable speed drives, along with explaining energy-saving practices and the importance of system design.

[0165] The manuals may also comprise industry standards and regulations, which familiarize the model with relevant standards (e.g., API, ISO) and regulations (e.g., safety codes, environmental compliance). Adhering to these standards ensures safe and reliable pump operation.

[0166] Optionally, the training dataset may extend beyond maintenance logs to include maintenance best practices. Maintenance best practices may discuss preventive maintenance schedules, lubrication, and inspections, including information on bearing replacements, seal maintenance, and impeller wear.

[0167] Optionally, the training dataset may include failure modes and root causes, e.g., which document common failure modes for pumps. This information may include issues like cavitation, seal leaks, impeller damage, and motor failures, helping to understand the root causes behind these failures (e.g., cavitation occurs due to low pressure at the impeller inlet).

[0168] Optionally, the operation procedures may include case studies and real-life examples, sharing successful pump installations, troubleshooting, and upgrades. Real-world examples provide practical insights and enhance understanding.

[0169] The training can include dialogue management components to handle multi-turn conversations, where the context of the user interaction needs to be maintained over several exchanges.

[0170] It can be understood that making the language model domain-specific helps to reduce the size of the language model, because it allows for a targeted focus on a subset of language - making it fit for an edge. This is achieved by focusing the vocabulary to a narrow, specialized vocabulary relevant to the particular field it's designed for (the model doesn't need to understand or generate a broad range of vocabulary that's outside its domain) and limiting the contexts to reduce the model complexity of handling multiple unrelated contexts. In addition, techniques such as pruning (eliminating weights or neurons that contribute little to the model's output) and quantization (reducing the precision of the numerical representations) can be used more aggressively on domain-specific models since the range of necessary responses is narrower.

[0171] In addition, the training may include system feedback loops, which ensures continuous learning where the language model can learn from new interactions and user corrections, enabling continuous improvement and adaptation to evolving pump domain language and user needs. Error handling and diagnostics mechanisms identify and address any misinterpretations of voice commands or system malfunctions. Based on the understanding of the user’s intent, the action decision engine 130 can decide on the set of actions that correspond to the user's request. The action decision engine 130 is configured to interpret the user's instructions provided via voice commands, and translate them into actionable tasks that the pump can execute.

[0172] A non-exhausted list of actions can include (but is not limited to):

[0173] • Ask for More Input from User: If a command is vague or incomplete, the action decision engine 130 may prompt the user for clarification.

[0174] • Retrieve Information Directly (Without Further Analysis): The user might ask for real-time data, such as "What is the current operating pressure?" The action decision engine 130 would then fetch this data from local storage to provide an immediate answer.

[0175] • Run Analyses on Pump: For more complex inquiries, the user could request an analysis, like "How has the pump efficiency changed over the last month?" The action decision engine 130 would command the Information Analysis Tool (i.e., the information analysis and output module 140) to process data and generate a report or summary.

[0176] • Generate Answers to Questions: When faced with a direct question like "Why is the flow rate lower than usual?", the action decision engine 130 could initiate an analysis to diagnose potential issues, such as filter clogging or leaks.

[0177] • Generate Recommendations: The user might seek advice, e.g., "When should the next maintenance be scheduled?" Based on the pump's operational history and data patterns, the action decision engine 130 can suggest an optimal maintenance window.

[0178] • Instructions: A user could request the pump to switch between different operational modes, like "Activate energy-saving mode," and action decision engine 130 would initiate the appropriate configuration changes.

[0179] • Request customer approval or consent: Handle requests for customer approval or consent for actions and updates, e.g. terms and conditions.

[0180] • Guided repair: The action decision engine 130 could output a step-by-step repair guide via voice or text for the technician to follow.

[0181] • Automatic Troubleshoot and Resolution: "Fix problems" could translate into the pump running an automated diagnostic routine and applying a known fix. The control entity, or namely the agent operating within the control entity, may be configured to autonomously detect and respond to operational anomalies— such as pressure fluctuations, abnormal vibration patterns, or fault codes. Upon detection, the agent may initiate diagnostic procedures using available tools and contextual data. Based on predefined rules, historical trends, or trained machine learning models, the agent determines an appropriate corrective action (e.g., parameter adjustment, firmware reset, or fallback mode activation), executes it, and monitors the result. If successful, the outcome maybe logged or communicated to the user. If escalation is needed, the agent may decide to contact a remote command center. This capability allows the pump to independently identify and resolve a range of known operational issues, minimizing downtime, avoiding unnecessary alerts, and reducing reliance on external support. Notably, this autonomous troubleshooting functionality may be executed entirely at the edge, within the smart pump, without requiring data transmission to an external server or cloud backend, thereby reducing latency, preserving data privacy, and ensuring real-time response.

[0182] • Provide Instructions to the Pump: For operational instructions like "Increase the flow rate by io%", the action decision engine 130 translates this into a series of actions the pump needs to take to adjust its settings accordingly. A user could request the pump to switch between different operational modes, like "Activate energy-saving mode," and the action decision engine 130 would initiate the appropriate configuration changes.

[0183] • Schedule Operations: The pump might be instructed to perform certain tasks at a later time, such as "Start a cleaning cycle at the end of the day." The action decision engine 130 would have to schedule this task and execute it at the specified time.

[0184] • Update Software: If a user says "Update to the latest firmware," the action decision engine 130 would need to initiate a software update procedure, provided that the system design allows for remote or automatic updating.

[0185] • Record data: Users might want a record of certain operations or data, for example, "Log all pressure readings for this week". The action decision engine 130 would then ensure that the requested data is stored and retrievable.

[0186] • Interact with Other Systems: For commands that pertain to integrated systems or Internet of Things (loT) networks, such as "Sync data with the central HVAC (Heating, Ventilation, and Air Conditioning) system", the action decision engine 130 would initiate the interaction and data exchange with other systems.

[0187] Optionally, the actions may involve actions needed to be executed or delegated to other systems. That is, the action decision engine 130 either directly triggers the execution of the task within the smart pump's capabilities, or it may need to delegate certain tasks to backend systems if they are outside its scope of function.

[0188] The decision may include the instance of the interaction, either interacting with the backend, with the pump itself, or with the pump system.

[0189] For example, multiple loops in the process maybe needed in the same interaction, as the following example shows:

[0190] • User: “Adjust the control settings”.

[0191] • The control entity 100 intelligence decides it needs to see how the pump is being controlled and requests control data (control variable).

[0192] • The pump (e.g., sensors of the pump) intelligence sends the data to the control entity 100 for analysis and calculate optimal control parameters.

[0193] • The control entity 100 intelligence pushes new control parameters to the pump.

[0194] • User gets confirmation of made adjustments.

[0195] In one embodiment, the action decision engine 130 initiates the one or more actions utilizing the information analysis and output module 140.

[0196] The second language model used by the information analysis and output module 140 can be fully or partly the same language model as used by the command interpretation module 120. Alternatively, it can be a separate language model.

[0197] The information analysis and output module 140 coordinates and runs data analysis on the pump by processing the pump's operational data, analyzes it based on the user's queries, and generates answers or recommendations. The information analysis and output module 140 is configured to fetch data such as operational status, history, and performance data in response to user queries, making information accessible via voice commands.

[0198] The information analysis and output module 140 uses the second language model (e.g., LLM) to interpret results of data analytics to form coherent, summarized responses for the user. Similar to the first language model used in the command interpretation module 120, the second language model can either be a general language model or a domain-specific language model.

[0199] The information analysis and output module 140 is responsible for transforming complex data analysis outcomes into intelligible language that can be conveyed through voice or text to the user, thereby facilitating an informative and interactive experience.

[0200] As needed, the information analysis and output module 140 may include one or more communication interfaces that enable exchange of data and commands between the smart pump 10 and the connected analytics platform, facilitating seamless interaction.

[0201] System feedback loops may be used for improving the second language model. This ensures continuous learning where the language model can learn from new interactions and user corrections, enabling continuous improvement and adaptation to evolving pump domain language and user needs. Error handling and diagnostics mechanisms identify and address any misinterpretations of voice commands or system malfunctions. The training of the second language model maybe similar to the training of the first language model as described in the previous embodiments.

[0202] The method flowchart shown in FIG. 4 further proposes a user feedback loop. The control entity 100 is able to provide users with clear and immediate feedback about the status of their requests (including “in progress, please wait”), thereby enhancing the user experience and system transparency.

[0203] Further, after attempting an action, the control entity 100 can provide feedback to confirm whether the action has been implemented (e.g., whether a corresponding problem has been resolved) or if additional action is needed. In a possible embodiment, the control entity 100 may further comprises an error handling and diagnostics module. For instance, the error handling and diagnostics module may use one or more processing units or processors for running diagnostics algorithms and handling error processing. This module may be incorporated with mechanisms to identify and address any misinterpretations of voice commands or system malfunctions. Possibly, it includes diagnostic tools capable of troubleshooting, analyzing, and resolving technical issues autonomously, reducing the need for user intervention, and ensuring the smart pump's reliability and user trust. It may also include machine learning models to predict and diagnose errors based on historical data.

[0204] According to another embodiment of this disclosure, a computer program product, stored on a non-transitory computer-readable medium, is provided. The computer program product comprises instructions that, when executed by a processor (of the control entity 100), perform the method steps shown in FIG. 4.

[0205] To summarize, the embodiments of this disclosure provide the following advantages:

[0206] Enhanced Convenience:

[0207] A more accessible human interfaces with the machine. Voice command functionality allows users to interact with the pump system while multitasking, without the need to use manual controls, touchpads, or computer interfaces. Voice control interfaces are often more intuitive than graphical user interfaces (GUIs), which can alleviate the need for extensive training or technical knowledge to operate the pump system.

[0208] Automated information compilation and analysis:

[0209] Instead of having a user request past data from the pump and analyzing it manually, the pump would instead be able to automatically analyze its own operational data, metadata, and logs and respond to user requests. This capability extends beyond passive analysis to include active measures such as autonomous troubleshooting and resolution of identified issues, enabling the pump to act preemptively and independently of user intervention.

[0210] No need for syntax-specific or uniform commands: The voice-command interface leverages the Language Learning Model (LLM) that understands the intention behind the user’s spoken commands without requiring uniform or syntax-specific inputs. Users can communicate with the pump system using natural language, making the interaction much more intuitive and similar to human conversation, which can lower the learning curve for new users. Users can phrase their requests in various ways, providing a more accommodating and flexible interaction that feels more organic and less constrained by technical limitations. In urgent situations, a user might not remember the exact command needed; an LLM understanding the intent can quickly interpret and execute the necessary actions, which can be crucial in preventing damage or downtime.

[0211] Increased Efficiency and Adaptive Operation:

[0212] The ability to quickly obtain operational data, analyze performance, and execute commands through voice accelerates decision-making and reduces the time required to manage pump operations. Users can easily adjust settings and operation modes to respond to changing conditions, which can be critical for systems that require flexibility, such as heating systems subject to fluctuating demand profiles.

[0213] User Empowerment:

[0214] The voice control system empowers users to feel more in control of their equipment, which can improve user satisfaction and trust in the technology.

[0215] Reduced data transfer - Cost:

[0216] By processing data locally, the system saves resources that would otherwise be spent on sending large volumes of raw data for remote processing. This means reduced bandwidth requirements and the associated costs. It also reduces dependency on external processing resources which would incur additional costs. As only pertinent data (like alerts and long-term trends) may need to be sent to the cloud or central servers, businesses can opt for less costly data communication services.

[0217] Reduced data transfer - Privacy:

[0218] Data privacy is inherently enhanced when data processing occurs locally. Sensitive data can be analyzed and leveraged without ever leaving the protected local environment, aligning with data protection regulations and reducing the risk of data breaches or unauthorized access. Furthermore, when data does need to be shared— for instance, for long-term analytics or remote monitoring— the edge computing capabilities allow for the aggregation and anonymization of such data before transmission.

[0219] Safety:

[0220] Voice commands can be issued from a safe distance or in environments where it may be hazardous to interact with control panels, thus reducing the risk of accidents

[0221] Notably, the pump 10 discussed in this disclosure maybe 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 100.

[0222] The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed matter, from the studies of the drawings, this disclosure, and the independent claims. In the claims as well as in the description 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 or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutually different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

Claims1. A control entity (100) for a pump, the control entity (100) comprising: an interface layer (no) configured to facilitate interactions with a user, wherein the interactions comprise taking a verbal command from the user; a command interpretation module (120) configured to interpret the verbal command using a first language model to determine a request of the user; and an action decision engine (130) configured to determine one or more actions to be executed by the pump based on the request, and initiate the one or more actions.

2. The control entity (100) according to claim 1, wherein the verbal command is a voice command and / or a text command, wherein the interface layer (no) comprises a speech module (111) configured to capture the voice command spoken by the user, and / or a display (112) configured to capture the text command input by the user.

3. The control entity (100) according to claim 1 or 2, wherein the interface layer (no) is further configured to: translate the verbal command from one language to another language in realtime.

4. The control entity (100) of one of the claims 1 to 3, wherein the interactions further comprise outputting a verbal response to the user from the pump, wherein the verbal response includes a voice response and / or a text response.

5. The control entity (100) of claim 4, wherein the interface layer (no) further comprises: a dialogue management component configured to maintain a context related to one or more interactions with the user, wherein the context comprises one or more verbal commands from the user, and one or more verbal responses from the pump.

6. The control entity (100) according to one of the claims 1 to 5, wherein the first language model is a domain-specific language model tailored to recognize and respond to language inputs related to a pump domain.

7. The control entity (100) according to claim 6, wherein the first language model is trained with a dataset specific to the pump domain, wherein the dataset includes one or more of the following: manuals, user commands, maintenance logs, technical documentation, terms and phrases that are commonly used in a pump industry, technical jargon, part names, error codes, metrics, operation procedures, and colloquialisms used by technicians and users.

8. The control entity (ioo) according to one of the claims 1 to 7, wherein the one or more actions comprise one or more of the following: retrieving real-time operational data and / or historical data of the pump; analyzing the real-time operational data and / or the historical data; diagnosing a system malfunction; generating a response to the user based on at least one of the real-time operational data, the historical data, an analysis result, or a diagnostic result; adjusting an operational parameter or a configuration of the pump; scheduling an operational parameter adjustment, a configuration adjustment, or a maintenance for the pump; updating software for the pump; prompting the user to provide additional user input; interacting with an external system.

9. The control entity (100) of claim 8, further comprising: an information analysis and output module (140), wherein the action decision engine (130) is further configured to initiate the one or more actions utilizing the information analysis and output module (140).

10. The control entity (100) of claim 9, wherein the information analysis and output module (140) is configured to: retrieve the real-time operational data and / or the historical data of the pump; analyze the real-time operational data and / or the historical data; diagnose the system malfunction; generate the response to the user based on at least one of: the real-time operational data, the historical data, an analysis result, or a diagnostic result; andtransform the analysis result or the diagnostic result into an intelligible language feedback using a second language model. n. The control entity (100) of claim 10, wherein the response to the user includes a maintenance recommendation, an operational recommendation, or the diagnostic result, and wherein the information analysis and output module (140) is configured to generate the response based on the real-time operational data and / or the historical data of the pump utilizing a machine learning algorithm.

12. The control entity (100) of claim 10 or 11, wherein the second language model is a domain-specific language model tailored to recognize and respond to language inputs related to a pump domain.

13. The control entity (100) according to claim 12, configured to update the domainspecific language model based on the interactions with the user.

14. The control entity (100) of one of the claims 10 to 13 and claim 4, wherein the interface layer (no) is further configured to: translate the intelligible language feedback to the verbal response.

15. The control entity (100) of one of the claims 1 to 14, further comprising: a user authentication module (150), configured to verify an identity of the user using an authentication process, before allowing the execution of the one or more actions, wherein the authentication process includes at least one of voice recognition, passcode identification, or a biometric method.

16. A smart pump (10), comprising: a pump, and a control entity (100) according to one of the claims 1 to 15.

17. The smart pump (10) according to claim 16, further comprising: a storage medium (11) configured to store real-time operational data and / or historical data of the pump (10).

18. A pump system (1), comprising one or more smart pumps (10) each according to claim 16 or 17.19- A computer program product, stored on a non- transitory computer-readable medium, comprising instructions that, when executed by a processor of a control entity (100) for a pump, configure the control entity (100) to: facilitate interactions with a user, wherein the interactions comprise taking a verbal command from the user; interpret the verbal command using a first language model to determine a request of the user; and determine one or more actions to be executed by the pump based on the request, and initiate the one or more actions.

Images