Method for the functional extension of a pump, in particular a centrifugal pump

Abstract

The invention relates to a method for the functional extension of a pump, in particular a centrifugal pump, comprising the following steps: offering an optional pump function for a pump on a display means of a user terminal device which is or can be connected to the pump (10) and to a server (30), transmitting a request to activate the optional pump function to the external server after a requisition by the user, providing a function-specific token for the requested pump function by the server to the user terminal device, transmitting the function-specific token by the user terminal device to the pump and activating the optional pump function by the pump controller of the pump when it has been ascertained that the received function-specific token is valid for the pump function to be activated.

Description

[0001] Method for expanding the functionality of a pump, in particular a centrifugal pump

[0002] The invention relates to a method for expanding the functionality of a pump, in particular a centrifugal pump.

[0003] A growing number of pumps, especially centrifugal pumps, are being equipped with control electronics and variable-speed drive technology. The ever-increasing performance of the installed control and regulation electronics opens up a wide range of possibilities for expanding the functionality of the control and regulation components. This primarily concerns functions for optimizing the pump's operation during current pumping operation, allowing the pump to adapt to existing operating conditions. However, the performance of the installed components also enables the integration of extensive monitoring and evaluation procedures to record and evaluate the current operating conditions in real time.

[0004] However, the multitude of options increases the complexity of operation, so it is considered sensible to only activate the aforementioned optional functions when required during ongoing pump operation. This means that the functions are usually already included in the pump hardware or software, but an upstream activation process is necessary for implementation. The application cases of pumps of the same design can also differ considerably, so that certain pump functions should ideally only be available after commissioning and interaction with the end user. It may also be desirable to make certain pump functions that optimise pump operation or provide the end user with additional information about the system available only under certain conditions, for example after the conclusion of a supplementary framework agreement or payment of an additional fee.

[0005] One problem with retroactively enabling functions can be that the pumps are often installed in specific locations where there is usually no access to the existing network infrastructure. However, installing a separate network access point involves additional costs.

[0006] The above-mentioned idea for subsequent function activation is solved by a method according to the features of claim 1. Advantageous embodiments of the method are the subject of the dependent claims.

[0007] According to the invention, the pump user is initially presented with an offer to activate an optional pump function of their operating pump on an external user terminal. The user terminal communicates with the pump to initially receive information about additional functions requiring activation. For this purpose, it is sufficient for the user terminal to be temporarily connected to the pump, e.g., via a standardized radio interface using a direct connection. Of course, a connection can also be established via a local network infrastructure (e.g., Wi-Fi) or any other communication option for data exchange.

[0008] On the other hand, the user device is connected to an external server, or at least temporarily connectable to it. The server represents the administrative unit for managing the function activation and is operated, for example, by the pump manufacturer. Consequently, the user device also acts as a kind of intermediate gateway to enable data exchange between the pump and the server. The user device can be a standard smartphone or tablet, preferably with a dedicated application for implementing the process. It can also be a standard laptop or computer.

[0009] If an offer is displayed on the user's terminal and the user accepts the submitted offer via the terminal, the terminal sends a corresponding request to the server to activate the selected optional pump function. The server checks the received request and, if necessary, provides a function-specific token for the requested pump function, which is then transmitted from the server to the user terminal. Such a function-specific token is tailored to the selected pump function to be activated. After receiving the function-specific token from the server, the user terminal transmits the received function-specific token to the pump to be activated.

[0010] The pump controller of the receiving pump stores the function-specific token received from the user device in a memory and can then enable an optional pump function if the received function-specific token is deemed valid. Once the optional pump function has been enabled, it can be executed by the pump controller, with or without appropriate user interaction. Therefore, it is important that the pump's hardware or software is already capable of executing the optional pump function. Upon receipt of the token and evaluation of the token's validity, only the already implemented pump functionality is enabled, making it executable by the pump controller or the user.

[0011] Please note that the pump control does not necessarily require a connection to the user, particularly within the context of a user account or any user authentication on the pump, and can be operated completely independently by the user. An example of an optional, subsequently activated pump functionality is an executable procedure for optimizing the pump's design point, particularly by supporting a graphical display of the pump's operating history. Such a function for optimizing the design point can be executed after activation by the user, if necessary in conjunction with a third-party device, e.g., using the user's terminal, so that pump operation can be optimized and, if necessary, the pump's energy consumption can be reduced.

[0012] Storing the function-specific token in the pump controller's memory also ensures that the activation of the optional pump function or the information regarding the activation is available in the pump. The stored token also has no connection to the user, ensuring that even if the pump is sold or transferred to another third party, the activated functionality is retained and remains executable regardless of the user. The activation is therefore not linked to the user, but only to the device.

[0013] It has already been clarified above that the pump control software is already fundamentally suitable for executing the optional pump functions, i.e. the necessary software code is already available in the pump memory and / or the necessary hardware is present. However, in order to only be able to make offers to the user on the user device to activate optional pump functions that are actually possible on the pump and have not yet been activated, it is preferable if the pump control first determines during pump operation or after the pump has been put into operation which optional pump functions are already activated and which can possibly still be activated. Such a check can be carried out, for example, by comparing the function-specific tokens stored in the pump memory.If at least one optional pump function is considered not yet activated, the pump control transmits at least one function identification number to the user terminal, which is characteristic of a non-activated optional pump function. Based on the received identification number, the user terminal can then generate an offer for the user to activate the corresponding pump functions. For this purpose, the application in the user terminal provides, for example, a corresponding assignment table to assign a unique pump function to the received function identification number.

[0014] It is particularly preferred if such a function identification number is transmitted by the pump control system together with a unique device identification number. Such a device identification number is unique and individual for each pump from a manufacturer. If the user accepts at least one of the offers made via the user terminal to activate at least one pump function, the user terminal transmits the corresponding function identification number of the selected pump function along with the device identification number to the server.

[0015] This opens up the possibility of the function-specific token being generated by the server for each individual pump, i.e. the token can therefore be bound to the specific pump and is therefore only valid in conjunction with the specific pump device. Activating the pump function using such a token is only possible on the pump associated with the device identification number. However, it is not absolutely necessary for the device binding of the function-specific token to take place on the server side. It is also conceivable, for example, that the server first generates a universal, i.e. device-independent, token and makes it available to the user device. A binding to the specific pump is then only carried out by the application in the user device before forwarding it to the pump.

[0016] In principle, it is sensible for communication between the user device and the server to require user authentication before the token is sent. This means that the user must first create a type of user account on the server to enable the activation of any pump functions. In this case, for example, there is a user identification number that is exchanged between the user device and the server. It is particularly preferred if, during the activation process, such a user identification number is transmitted to the pump together with a function-specific token and stored in the pump's memory. This enables optional assignment of the individual device to the current user, which is then useful for future processes, such as the use of any maintenance or repair services.It is conceivable that in the event of a fault or in the event of pending maintenance tasks, the pump communicates independently with a service provider, possibly via the user's terminal, and in this context transmits the user identification number, which enables the service provider to easily assign the pump to a customer.

[0017] According to an optional embodiment of the invention, it can be provided that a time-limited, function-specific token can be generated and is available for the pump. Such a limited token can ideally be generated by the user terminal itself and particularly preferably does not require communication with the server. After transmission of the limited token, the corresponding function in the pump is activated for a limited period of time. After the defined period of time has expired, the token automatically loses its validity. Using such a mechanism, an optional pump function can be made available on a test basis in order to facilitate the user's activation decision. It is also conceivable that a limited token is used to temporarily activate a pump function, although the range of functions of the pump function is also limited.

[0018] After the trial period ends, the activation will be revoked due to the invalidity of the token, meaning the associated pump function can no longer be performed. Only if the user requests activation of the pump function in this case can the usage period be extended or made unlimited.

[0019] It is particularly preferred if the token contains information about a maximum operating time, and the pump control system counts the pump's operating time from the time the pump function is temporarily enabled and compares it with the maximum operating time contained in the token. Once the maximum operating time is exceeded by the counted operating time, the optional pump function is revoked. The validity of the token is therefore not linked to real time, but to the actual operating time of the pump. Periods during which the pump is idle, for example, are excluded.

[0020] In addition to the method according to the invention, the present invention also relates to a system consisting of a server, at least one user terminal and at least one pump, wherein the server, user terminal and pump are suitable for carrying out the method according to the invention.

[0021] In addition to the system, the invention also relates to a pump with a pump memory and a pump controller configured to carry out the method according to the invention. In particular, the pump controller must be configured to check for the presence of a valid, function-specific token before executing an optional pump function and to permit execution of the optional pump function only if a valid token is present. Likewise, the pump controller must be configured to compare the presence of valid tokens against the available optional pump functions during pump operation and to transmit function identifiers of those optional pump functions to a user terminal for which no valid token is available in the pump memory.Furthermore, the pump control is suitable for monitoring compliance with a maximum usage period of a token, in particular by comparing it with an operating hours counter of the pump and automatically deactivating the assigned pump function when the usage period expires.

[0022] In addition to the pump, the present invention also relates to a user terminal configured to carry out the method according to the invention. The user terminal can be, for example, a commercially available smartphone, a tablet, or a PC / laptop equipped with a suitable application for carrying out the method. When executing the user application, the user terminal can communicate with the pump in order to receive, for example, function identifiers for optional pump functions for which the pump could not determine a valid token. Furthermore, the application of the user terminal is able to generate an offer to activate these pump functions based on the received function identifiers and to display this offer to the user via a display of the user terminal.Through appropriate interaction with the user, a request can then be automatically sent to an external server, with the corresponding function ID being transmitted with this request, possibly together with a user ID. Furthermore, the user device can be configured to forward a received token to the pump controller or to convert a universal token into a device-specific token using a device ID and transmit it to the assigned pump.

[0023] Further advantages and features of the invention will be explained in more detail below with reference to the exemplary embodiments illustrated in the drawings. They show:

[0024] Fig. 1 : a schematic representation of an approval process for a selected pump with direct payment of the function activation by the user,

[0025] Fig. 2: a slightly modified version of the process according to Fig. 1 with subsequent payment and

[0026] Fig. 3: a representation of the procedure for enabling functions using initially non-device-bound tokens.

[0027] Fig. 1 shows a total of five steps in the activation process for a specific pump function. Figure 1 shows the pump 10 communicating with a user's commercially available smartphone 20 via a wireless standard, e.g., Wi-Fi or Bluetooth. The pump 10 can be a centrifugal pump 10 with an integrated control and / or regulating module. For the sake of simplicity, the electronics of the pump 10 are generally referred to as the pump control. The pump control offers various pump functions that are already implemented in hardware or software. In particular, in the example shown here, the pump 10 offers at least the three optional pump functions "Service-1", "Service-2", and "Service-3". In order for the pump control to actually execute these optional functions, a corresponding token must be stored in the pump memory. Before executing a function, the pump control therefore checks whether a valid token is present for each optional pump function.The memory of the pump 10 shown here contains a token set 11 that, in addition to the device ID, which is individually defined for each pump 10 of the manufacturer, also contains tokens for the functions "Service-1" and "Service-2." There is no valid token in the pump's memory for the third function, "Service-3," which is why this function is grayed out and crossed out in the selected display. In other words, the "Service-3" function cannot currently be executed.

[0028] The user can activate the pump using their smartphone 20 for a corresponding fee. The pump control includes a routine that first informs the user device 20 which of the optional pump functions are not yet activated. This information can, for example, be in the form of a function number "Service-3 ID," which is transmitted to the smartphone 20. It does not matter whether the pump 10 sends this information via push notification or whether the smartphone 20 retrieves this information from the pump 10. Along with this information, the device identification number "Device ID" is also transmitted to the smartphone 20.

[0029] Based on the information received, the smartphone 20 generates an offer for the user, which is displayed, for example, on the device screen. In this context, the user can also be informed about the range of functions, the terms of use, and the fee. If the user accepts the offer, in particular via the smartphone 20, a corresponding request is sent to the pump manufacturer's external service portal 30 (server). The portal can be implemented as cloud-based. The submitted request is shown in Figure 2 of Fig. 1 . However, to submit a request or to activate the selected function "Service-3," the user must first register and authenticate themselves on the pump manufacturer's portal 30. A user identification number "Customer ID" assigned during registration is transmitted to the portal 30 together with the function identification number and the device identification number.After paying the activation fee, a so-called token for the "Service-3" function is generated and then transferred to the pump 10 via the smartphone 20 (see images 3 and 4 of Fig. 1). The generated token is generated based on the provided device identification number, which binds the token to the specific pump 10, and the function can only be activated there.

[0030] During further pump operation, pump 10 now detects the existence of the token for the “Service-3” function and automatically releases this function for user-controlled execution or then executes the function independently.

[0031] Together with the token, the smartphone 20 transmits the used user identification number to the pump 10, which is stored there for later use and also for assigning the pump 10 to a customer of the pump manufacturer. For future inquiries to the pump manufacturer's service portal 30, the user identification number can thus also be automatically transmitted, so that a clear assignment of the pump 10 to a customer is also possible within the service portal 30. However, it should be noted that the tokens stored in the pump control system are not user-dependent, i.e. the activated functions are also available if the pump 10 has been handed over to another user. In other words: the "customer identification number" stored in the control system is irrelevant for checking the validity of the token and for enabling functions.

[0032] Fig. 2 shows a slightly modified process. In this scenario, it is possible for the customer to first take advantage of a test phase before activating the pump function "Service-3". For this purpose, as in the scenario in Fig. 1, the user is first presented with an offer on the terminal 20 for a pump function "Service-3" that has not yet been activated (Figure 1 of Fig. 2). In contrast to the scenario in Fig. 1, the user at least receives not only an offer for the final, paid activation of the pump function, but is also offered a time-limited test phase. If the user accepts this offer, the smartphone 20 itself generates a time-limited token, which is then transferred to the pump 10 (Figure 2 of Fig. 2).

[0033] The pump controller counts the active pump operating time using an integrated operating hour counter and compares this value with the defined maximum duration of the test period. Pump 10 receives the maximum duration along with the time-limited token, or this information is already contained in the token itself. Once this value is exceeded, the token is considered invalid, and the "Service ID" function is deactivated again (Figure 5b of Fig. 2).

[0034] However, the user has the option of permanently activating the "Service 3" function during or after the test period, provided they pay the applicable fee. This is done in the same way as explained in Fig. 1 (see Figures 3 and 4 of Fig. 2). Here, too, the generated, device-specific token is transferred to pump 10 and replaces the time-limited token, so that the function remains activated even after the test period has expired.

[0035] Fig. 3 shows a further modification or a possible embodiment of the method, in which the user, for example, is the owner of a plurality of pumps 10. Here, it may be desirable for the user to purchase the pump function "Service-3" for a plurality of unspecified pumps 10 in advance by interacting with the portal 30. The corresponding offer is transmitted from the portal 30 to the smartphone 20 (Figure 1 of Fig. 3) and displayed there. By accepting, the user can specify the number of tokens Nx required. The corresponding set of universal (device-independent) tokens N is then made available to the user in the portal 30 (Figure 2 of Fig. 3). If the user requires activation for one of their pumps 10, they can request transmission, and the portal 30 initially provides a device-independent token (Figure 3).The token is then linked to the specific pump 10 in the smartphone using the device identification number, and the device-bound token is subsequently transmitted to the pump 10 (Figure 4). Finally, the smartphone 20 informs the portal about the device binding of the token by transmitting the customer identification number and the device identification number for the corresponding tokens to the portal 30 (Figure 5).

Claims

Patent claims 1 . Method for expanding the functionality of a pump (10), in particular a centrifugal pump, comprising the steps: - offering an optional pump function for a pump on a display means of a user terminal (20) that is connected or connectable to the pump (10) and a server (30), - Transmission of a request to activate the optional pump function to the external server (30) after a request by the user, - providing a function-specific token for the requested pump function by the server (30) to the user terminal (20), - transmission of the function-specific token by the user terminal (20) to the pump (10), - Activation of the optional pump function by the pump control of the pump (10) if it has been determined that the received function-specific token is valid for the pump function to be activated.

2. Method according to claim 1, characterized in that the pump control determines during commissioning and / or during pump operation which optional pump functions supported by the pump (10) are not enabled, in particular for which optional pump functions no valid function-specific token is present in the pump memory, and transmits to the user terminal at least one function identification number which is characteristic of an assigned, not yet enabled optional pump function.

3. Method according to claim 2, characterized in that the pump (10) transmits the at least one function identification number together with its device identification number to the user terminal (20).

4. Method according to claim 2 or 3, characterized in that the user terminal (20) offers the user the activation of the at least one pump function on the basis of the at least one function identification number received from the pump (10).

5. Method according to claim 4, characterized in that, depending on the user input, the function identification number of the pump function selected by the user for release is transmitted to the server (30) together with a device identification number.

6. Method according to one of the preceding claims, characterized in that the function-specific token is bound to a specific pump (10).

7. The method according to claim 6, characterized in that the function-specific token bound to the specific pump (10) is generated by the server (30) using the device identification number or a device-independent token is generated by the server (30) and transmitted to the user terminal (20), wherein the user terminal (20) subsequently links the device-independent token to the device identification number.

8. Method according to one of the preceding claims, characterized in that the function-specific token has a time-limited validity and is considered invalid by the pump control after a defined period of time has been exceeded.

9. Method according to claim 8, characterized in that the time-limited token is generated by the user terminal (20) and transmitted to the pump (10).

10. Method according to claim 8 or 9, characterized in that the time-limited token contains information about a maximum operating time, and the pump control counts the operating time of the pump (10) from the time of activation of the pump function and compares it with the maximum operating time, wherein the activation of the optional pump function is revoked after the maximum operating time is exceeded. 11 . Method according to one of the preceding claims, characterized in that for the transmission of a request to the server (30) a user identifier is required, via which the user terminal (20) authenticates itself with the server (30), wherein the user terminal (20) transmits the user identifier to the pump (10) when transmitting a function-specific token to the pump (10) and the pump (10) stores the user identifier in the pump memory.

12. System comprising a server (30), at least one user terminal (20) and at least one pump (10), wherein the server (30), user terminal (20) and pump (10) are suitable for carrying out the method according to one of the preceding claims.

13. Pump (10) with a pump accumulator and a pump control configured to carry out the method according to one of the preceding claims 1 to 11.

14. User terminal (20) configured to carry out the method according to one of the preceding claims 1 to 11.

Images