Method for expanding function of pump, in particular centrifugal pump

Abstract

The invention relates to a method for performing a function extension of a pump, in particular a centrifugal pump, comprising the following steps: providing optional pump functions for the pump on a display means of a user terminal which is or can be connected to the pump (10) and a server (30); transmitting, upon request by the user, a request to an external server for activating the selectable pump function; providing, by the server, a function-specific token for the requested pump function to the user terminal device; transmitting, by the user terminal, the function-specific token to the pump; and if it is determined that the received function-specific token is valid for the pump function to be activated, activating an optional pump function by a pump control device of the pump.

Description

Technical Field

[0001] The present invention relates to a method for expanding the functionality of pumps, particularly centrifugal pumps. Background Technology

[0002] The increasing number of pumps, especially centrifugal pumps, are equipped with control electronics and adjustable drive technology. The continuously improving performance of the installed control and regulation electronics has created numerous possibilities for expanding the functional range of control and regulation components. This particularly involves functions for optimizing pump operation in current pumping conditions, allowing the pump to adaptively adapt to existing operating conditions. Furthermore, the performance of the installed components also enables the integration of extensive monitoring and evaluation programs to acquire and analyze current operating conditions in real time.

[0003] However, the variety of possibilities increases operational complexity, making it meaningful to activate the aforementioned optional functions only as needed during continuous pump operation; that is, functions are often already included in the pump hardware or software, but require a prior commissioning process for implementation. Applications of pumps of the same structural type can also differ significantly from one another, making it more logical for certain pump functions to be available only after commissioning and interaction with the end-user. It is also reasonable to expect that certain pump functions optimizing pump operation or providing end-users with additional information about the facility will only be available under certain conditions (e.g., after signing a supplemental framework agreement or paying additional fees).

[0004] One issue that may arise during the rollout of functionality is that pumps are typically installed in specialized locations where existing network infrastructure is often inaccessible. However, installing dedicated network access equipment comes with additional costs. Summary of the Invention

[0005] The aforementioned concept regarding the activation of subsequent functions is achieved through the method described in claim 1. Advantageous embodiments of this method are the subject of the dependent claims.

[0006] According to the present invention, a proposal (Angebot) for activating optional pump functions on an external user terminal device is first presented to the pump user. The user terminal device here communicates with the pump to obtain information about the additional functions that need to be activated. For this purpose, it is sufficient for the user terminal device to temporarily connect to the pump, for example, directly via a standardized wireless interface. Of course, a connection can also be established using local network infrastructure (e.g., WLAN) or any other communication possibility for data exchange.

[0007] On the other hand, the user terminal device connects to an external server, or at least can connect to it temporarily. The server represents an administrator who manages the activation of functions and is, for example, operated by the pump manufacturer. Therefore, the user terminal device also acts as a gateway for intermediate interconnection to enable data exchange between the pump and the server.

[0008] The user terminal device can be a commercially available smartphone or tablet, preferably with a dedicated application for performing the method. Similarly, the user terminal device can also be a commercially available laptop or computer.

[0009] If a proposal is displayed to the user on their user terminal device's screen and the user accepts the proposal, the user terminal device 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 transmitted from the server to the user terminal device. This function-specific token is customized for the selected pump function to be activated. After obtaining the function-specific token from the server, the user terminal device forwards the received token to the pump to be activated.

[0010] The pump control unit receiving the pump stores a function-specific token obtained from the user terminal device in its memory, and if the received function-specific token is deemed valid, the optional pump function can be activated. After the optional pump function is activated, the pump function can be implemented by the pump control unit either after corresponding user interaction or without corresponding user interaction. Importantly, the pump's hardware or software must already be suitable for implementing the optional pump function. By receiving the token and evaluating its validity, only the already implemented pump functionality is activated, thus making it implementable by the pump control unit or the user.

[0011] It should be noted that the pump control unit is not required to be associated with the user (especially in the context of user accounts or any user authentication at the pump) and can operate completely independently of the user.

[0012] One example of optional pump functionality that can be enabled later is an implementable procedure for optimizing the pump's design point, particularly through graphical display of the pump's operating history. This design point optimization functionality can be implemented by the user, and when necessary, in conjunction with third-party devices (e.g., using user terminal devices), thereby optimizing pump operation and reducing the pump's energy requirements when necessary.

[0013] By storing function-specific tokens in the pump control unit's memory, it is further ensured that the activation of optional pump functions, or information regarding activation, is available in the pump. The stored tokens are not associated with a user, thus ensuring that the activated functionality is retained and remains implementable independently of the user, even if the pump is sold or transferred to a third party. Therefore, the activation is not linked to the user, but only to the device.

[0014] As previously stated, the software of the pump control device is, in principle, suitable for implementing optional pump functions; that is, the necessary software code is already available in the pump memory and / or the necessary hardware already exists. However, in order to present the user terminal device only with proposals to activate optional pump functions that are actually feasible on the pump but not yet activated, it is preferable that the pump control device first determines which optional pump functions are already activated and which may still be activated during pump operation or after pump commissioning. This check can be performed, for example, by comparing function-specific tokens stored in the pump memory. If at least one optional pump function is deemed not to be activated, the pump control device transmits at least one function identifier to the user terminal device, which is characterizing the inactive optional pump function. Based on the received identifier, the user terminal device can now generate a proposal to the user to activate the corresponding pump function. For this purpose, the application in the user terminal device sets up a corresponding allocation table so that a unique pump function can be assigned to the received function identifier.

[0015] Preferably, this function identification number is transmitted by the pump control device along with a unique device identification number. This device identification number is specific and individualized for each pump from the manufacturer. If the user accepts at least one of the submitted proposals for activating at least one pump function via a user terminal device, the user terminal device transmits the corresponding function identification number of the selected pump function along with the device identification number to the server.

[0016] This opens up the possibility of function-specific tokens being generated by the server in a pump-specific manner; that is, the token can thus be bound to a specific pump and is therefore only valid in conjunction with that specific pump device. Enabling pump functionality with such tokens is only feasible on pumps belonging to a specific device identifier. However, it is not mandatory for device binding requiring function-specific tokens to be performed on the server side. For example, it is conceivable that the server first generates a generic, i.e., device-independent token and provides it to the user terminal device. Subsequently, the binding to a specific pump is performed by the application in the user terminal device before being forwarded to the pump.

[0017] In principle, it makes sense that communication between the user terminal device and the server before sending a token requires user authentication; that is, the user must first create a user account on the server to enable possible pump functionality. In this case, for example, a user identifier is exchanged between the user terminal device and the server. Particularly preferred is that during the activation process, this user identifier, along with a function-specific token, is transmitted to the pump and stored in the pump's memory. This allows for the optional association of a single device with the current user, which is meaningful in the context of future processes (e.g., utilizing possible maintenance or repair services). It is conceivable that in the event of a failure or in the event of an impending maintenance task, the pump autonomously communicates with the service provider (via the user terminal device if necessary) and, in this regard, transmits the user identifier, effectively allowing the service provider to simply associate the pump with the customer.

[0018] According to an alternative embodiment of the invention, a time-limited, function-specific token can be generated and made available to the pump. Ideally, such a limited token can be generated by the user terminal device itself, and particularly preferably, it does not require communication with a server. After the limited token is transmitted, the subordinate functions in the pump are activated for the limited duration. After the limited duration ends, the token automatically loses its validity. Through this mechanism, optional pump functions can be provided on a trial basis to facilitate the user's activation decision. It is also conceivable that time-limited activation of pump functions can be achieved using limited tokens, but the functional scope of the pump functions is also limited.

[0019] After the trial period ended, activation was revoked again due to an invalid token, rendering the associated pump feature unavailable. The usage period can only be extended or extended without restriction if the user requests activation of the pump feature under these circumstances.

[0020] Preferably, the token contains information about the maximum operating duration, and the pump control device counts the pump's operating duration from the moment the pump function is temporarily activated and compares it with the maximum operating duration contained in the token. Once the counted operating duration exceeds the maximum operating duration, the activation of the optional pump function is revoked. Therefore, the validity of the token is not linked to real-time conditions but to the actual operating duration of the pump, excluding periods of pump downtime.

[0021] In addition to the method according to the invention, the invention also relates to a system comprising a server, at least one user terminal device, and at least one pump, wherein the server, user terminal device, and pump are adapted to implement the method according to the invention.

[0022] In addition to this system, the present invention also relates to a pump having a pump memory and a pump control device, the pump being configured to implement the method according to the invention. In particular, the pump control device must be configured to check the presence of a valid, function-specific token before implementing an optional pump function, and to allow implementation of the optional pump function only when a valid token is present. Similarly, the pump control device must be configured to compare the presence of a valid token with the available optional pump functions during pump operation, and to transmit the function identifiers of these optional pump functions for which no valid token is available in the pump's memory to the user terminal device. Furthermore, the pump control device is adapted to monitor compliance with the maximum usage duration of the token, particularly by comparing it with a pump operating hour counter, and to automatically deactivate the associated pump function at the end of the usage period.

[0023] In addition to the pumps, the present invention also relates to a user terminal device configured to perform the method according to the invention. This user terminal device may be, for example, a commercially available smartphone, tablet, or personal computer / laptop, equipped with a suitable application for implementing the method. When implementing the user application, the user terminal device can communicate with the pumps to obtain, for example, function identifiers for optional pump functions for which the pumps have failed to determine a valid token. Furthermore, the application of the user terminal device can generate a proposal for activating these pump functions based on the received function identifiers and display it to the user via the user terminal device's display. Through corresponding interaction with the user, a request to an external server can then be automatically established, wherein the request transmits the corresponding function identifier number, and, if necessary, the user identifier number. Furthermore, the user terminal device can be configured to forward the obtained token to the pump control device, or, if using a device identifier number, convert a generic token into a device-bound token and transmit it to the associated pump. Attached Figure Description

[0024] Other advantages and features of the invention will now be explained in more detail with reference to the embodiments shown in the accompanying drawings. Wherein: Figure 1 This diagram illustrates the activation process for the selected pump, where activation is achieved through direct user payment. Figure 2 : Shows according to Figure 1 A slightly modified version of the process, which includes subsequent payments, and Figure 3 This diagram illustrates a method for enabling functionality when using a token that is not initially bound to a device. Detailed Implementation

[0025] Figure 1 A total of five steps are shown for the start-up procedure for a specific pump function. Figure 1Pump 10 is shown, which communicates with a user's commercially available smartphone 20 via a wireless standard (such as WLAN or Bluetooth). Pump 10 may be a centrifugal pump with an integrated control and / or regulation module. For simplicity, the electronics of pump 10 are generally referred to as a pump control device. The pump control device provides various pump functions, which have been implemented on the hardware or software side.

[0026] In particular, in the example shown here, pump 10 provides at least three optional pump functions: "Service-1", "Service-2", and "Service-3". For the pump control device to actually implement these optional functions, corresponding tokens must be stored in the pump's memory. Therefore, before a function is implemented, the pump control device checks whether a valid token exists for each optional pump function. The memory of pump 10 shown here contains a token set 11, which, in addition to the device identification number "Device-ID" individually determined for each individual pump 10 from the manufacturer, also contains tokens for functions "Service-1" and "Service-2". Regarding the third function, "Service-3", no valid token exists in the pump's memory, therefore this function is shown with a gray background and crossed out in the selected illustration. In other words: function "Service-3" cannot be implemented at this time.

[0027] Users can activate the service by paying the corresponding fee using their smartphone 20. The pump control device includes a routine that first informs the user terminal device 20 which optional pump functions are not yet activated. This information may exist, for example, in the form of a function number "Service-ID," which is transmitted to the smartphone 20. It is not important whether the pump 10 sends this information via push message or the smartphone 20 retrieves it from the pump 10. Along with this information, the device identifier "Device-ID" is also transmitted to the smartphone 20.

[0028] The smartphone 20 generates a proposal for the user based on the received information, which may be displayed on the device screen, for example. In this regard, the user may also be informed about the scope of features, usage conditions, and costs. If the user accepts the proposal (particularly via the smartphone 20), a corresponding request is sent to the pump manufacturer's external service portal 30 (server). This portal may be cloud-based.

[0029] Figure 1 Figure 2 illustrates the request made. However, in order to make a request or activate the selected function "Service-3", the user must first register and authenticate in the pump manufacturer's portal 30. The user identification number "Customer-ID" assigned within the registration framework, along with the function identification number and the device identification number, is transmitted to the portal 30. After paying the activation fee, a so-called token for the function "Service-3" is then generated and transmitted to the pump 10 via the smartphone 20 (see Figure 2). Figure 1(See images 3 and 4). Here, the generated token is produced based on the provided device identifier, thereby binding the token to a specific pump 10, and enabling the function can only be performed there.

[0030] In further pump operation, pump 10 now recognizes the presence of a token for function "Service-3" and automatically enables the function for user-controlled implementation or subsequently implements the function autonomously.

[0031] Along with the token, the smartphone 20 also transmits the user identifier used to the pump 10, where it is stored for future use and also used to associate the pump 10 with the pump manufacturer's customer. Therefore, when a request is made to the pump manufacturer's service portal 30 in the future, the user identifier can also be automatically transmitted, thus enabling a clear association between the pump 10 and the customer within the service portal 30. However, it should be noted that the token stored in the pump control device is user-independent; that is, even if the pump 10 is transferred to another user, the activated functions remain available. In other words, the "customer identifier" stored in the control device is irrelevant for token validity checks and function activation.

[0032] Figure 2 The process is shown with slight modifications. In this scenario, there is a possibility that a customer might first use the trial phase before activating the pump function "Service-3". For this purpose, as in Figure 1 In the scenario described above, the first step is to present a proposal for the "Service-3" pump function, which is not yet activated, to the user on terminal device 20. Figure 2 Image 1). Figure 1 In contrast, in this scenario, the user receives not only an offer for the final, paid activation of the pump feature, but also a time-limited trial period. If the user accepts the offer, the smartphone 20 itself generates a time-limited token, which is then transmitted to the pump 10. Figure 2 Image 2).

[0033] The pump control unit counts the active pump operation duration using the pump's integrated operating hour counter and compares this value to the maximum duration limited by the trial period. Pump 10 receives this maximum duration along with a time-limited token, or this information is already included in the token itself. After this value is exceeded, the token is considered invalid, and the "Service-ID" function is deactivated again. Figure 2 Image 5b).

[0034] However, as long as the user pays the incurred fee, they have the possibility of permanently activating the "Service-3" feature during or after the trial period. This is in accordance with... Figure 1 The same method as explained (see Figure 2 (See images 3 and 4). Here, the generated, device-bound token is also transmitted to pump 10 and replaces the time-limited token, ensuring that the function remains active even after the trial period ends.

[0035] Figure 3 Another modification or possible implementation of the method is shown, in which the user is, for example, the owner of multiple pumps 10. Here, it might be desirable for the user to pre-purchase pump functionality "Service-3" for multiple undetermined pumps 10 by interacting with portal 30. For this purpose, the corresponding proposal is transmitted by portal 30 to smartphone 20. Figure 3 Image 1) is displayed there. Upon acceptance, the user can specify the required number of tokens Nx here. A corresponding set of generic (device-independent) tokens N is then prepared for the user in portal 30. Figure 3 (See Figure 2). If a user needs to activate one of their pumps 10, they can request a transfer, and portal 30 first provides a token not bound to a device (Figure 3). In the smartphone, the token is then associated with the specific pump 10 using the device identifier, and the device-bound token is subsequently transferred to the pump 10 (Figure 4). Finally, smartphone 20 informs the portal about the device binding of the token by transmitting the customer ID number and device identifier for the corresponding token to portal 30 (Figure 5).

Claims

1. A method for extending the functionality of a pump (10), particularly a centrifugal pump, comprising the following steps: - Optional pump functionality for the pump is provided on the display device of the user terminal device (20), which is connected to or can be connected to the pump (10) and the server (30). - After a user makes a request, a request to activate the optional pump function is sent to an external server (30). - The server (30) provides the user terminal device (20) with a function-specific token for the requested pump function. - The user terminal device (20) transmits the function-specific token to the pump (10). - If it is determined that the received function-specific token is valid for the pump function to be activated, the optional pump function is activated by the pump control device of the pump (10).

2. The method according to claim 1, characterized in that, During commissioning and / or pump operation, the pump control device determines which optional pump functions supported by the pump (10) are not enabled, in particular determining which optional pump functions do not have a valid function-specific token in the pump memory, and transmits at least one function identifier to the user terminal device, the function identifier being characterized for the associated, not yet enabled optional pump function.

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

4. The method according to claim 2 or 3, characterized in that, The user terminal device (20) provides the user with the activation of the at least one pump function based on at least one function identifier received from the pump (10).

5. The method according to claim 4, characterized in that, Based on the user input, the function identifier number of the pump function selected by the user for activation, together with the device identifier number, is transmitted to the server (30).

6. The method according to any 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 identifier, or a device-independent token is generated by the server (30) and transmitted to the user terminal device (20), wherein the user terminal device (20) subsequently associates the device-independent token with the device identifier.

8. The method according to any one of the preceding claims, characterized in that, The function-specific token has time-limited validity and is considered invalid by the pump control device after the defined duration has expired.

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

10. The method according to claim 8 or 9, characterized in that, The time-limited token contains information about the maximum operating duration, and the pump control device counts the operating duration of the pump (10) from the moment the pump function is activated and compares it with the maximum operating duration, wherein the activation of the optional pump function is deactivated after the maximum operating duration is exceeded.

11. The method according to any one of the preceding claims, characterized in that, In order to send a request to the server (30), a user identifier is required. The user terminal device (20) authenticates itself in the server (30) via the user identifier. The user terminal device (20) transmits the user identifier to the pump (10) when sending a function-specific token to the pump (10), and the pump (10) stores the user identifier in the pump memory.

12. A system comprising a server (30), at least one user terminal device (20), and at least one pump (10), wherein, The server (30), user terminal equipment (20), and pump (10) are suitable for implementing the method according to any one of the preceding claims.

13. A pump (10) having a pump storage and a pump control device, configured to perform the method according to any one of claims 1 to 11.

14. A user terminal device (20) configured to perform the method according to any one of claims 1 to 11.

Images