Method and apparatus for pump data translation
Patent Information
- Application Number
- PCT/EP2025/085299
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-02-21
- Filing Date
- 2025-12-03
- Publication Date
- 2026-08-27
Smart Images

Figure EP2025085299_27082026_PF_FP_ABST
Abstract
Description
[0001] GRUNDFOS HOLDING A / S
[0002] P25115WO
[0003] P62831 / WO
[0004] METHOD AND APPARATUS FOR PUMP DATA TRANSLATION
[0005] TECHNICAL FIELD
[0006] The present disclosure relates generally to pumps and pump systems, for instance, to smart pumps. The disclosure is concerned with pump data transmission. For instance, the disclosure proposes a method and apparatus for pump data translation.
[0007] BACKGROUND
[0008] Industrial pumps play a vital role in effectively transporting fluids across various processes and applications. In traditional pump systems, gathering and storing pump data and related sensor data is essential for providing, maintaining and managing pump operations.
[0009] Modern industrial environments and smart buildings rely heavily on a multitude of sensors for monitoring various data points such as temperature, pressure, flow rate, and so on. These data inputs / interfaces often use different protocols (e.g., OPC UA, EtherCAT, M-Bus), making it challenging to integrate and manage data from diverse sources.
[0010] SUMMARY
[0011] The lack of standardization across various protocols (e.g., data protocol, communication protocol, etc.) complicates data capture, analysis, real-time monitoring, and decision-making processes. For pump systems, this can lead to significant operational inefficiencies, as operators struggle to synthesize data from multiple sensors operating on different protocols. This can ultimately result in increasing the risk of pump downtime and failures.
[0012] In view of the above-discussed challenges, this disclosure aims to introduce a solution to enable translation (or conversion) between data points using different protocolsGRUNDFOS HOLDING A / S
[0013] P25115WO
[0014] P62831 / WO
[0015] (such as OPC UA, EtherCAT, M-Bus) to enable interoperability. Another objective may be to simplify data management and to improve data reliability during the translation.
[0016] These and other objectives are achieved by solutions of this disclosure as described in the independent claims. Advantageous implementations are further defined in the dependent claims.
[0017] A first aspect of the present disclosure provides a method of converting data into a protocol for a pump or a pump system. The method comprises receiving first data of a first protocol from at least one data interface. The first protocol is identified according to a configuration profile. The method further comprises converting the first data of the first protocol into second data of a second protocol according to the configuration profile. The second protocol is compliant with the pump or the pump system.
[0018] The method maybe executed by an apparatus, e.g., a control entity of the pump, or an external entity connectable to the pump (e.g., an edge device), which shall not be limited in the present disclosure.
[0019] The first data may comprise any data that may be of interest to the pump or the pump system. The first data could be not compliant with the pump or the pump system.
[0020] In the present disclosure, the first protocol is used to refer to a protocol before the conversion; and the second protocol, which is different from the first protocol, is used to refer to a protocol after the conversion. Similarly, the first data is used to refer to data before the conversion, and the second data is used to refer to data after the conversion.
[0021] Notably, any protocol of the present disclosure maybe understood as being associated with a specific data format, or a specific communication protocol, or a specific data format and a specific communication protocol. That is, the first data may have a first data format, while the second data has a second data format that is different from the first data format.GRUNDFOS HOLDING A / S
[0022] P25115WO
[0023] P62831 / WO
[0024] The configuration profile enables a flexible and dynamic protocol conversion. The method of the present disclosure does not perform a fixed one-to-one protocol conversation. Instead, the method enables a flexible, dynamic, and adaptive “many-to-many” protocol conversion. The first protocol before the conversion can be selected from a plurality of protocols; the second protocol after the conversion can also be selected from a plurality of protocols. Upon receiving the first data, the first protocol is adaptively determined according to the configuration profile. The configuration profile also specifics to which type of second protocol the first protocol is converted for the respective data interface.
[0025] It shall be noted that the method is not limited to converting data from one specific first protocol to a single second protocol. The method allows data of the same first protocol, received from different data interfaces, to be converted into different second protocols. For instance, data received using protocol A from data interface 1 may be converted into protocol B, while data received using the same protocol A from data interface 2 may be converted into protocol C. This capability provides significant flexibility in adapting to diverse system requirements and operational scenarios.
[0026] The configuration profile also facilitates updates to the system's protocol mappings without the need for extensive reprogramming. For example, the configuration profile can be updated to include new data interfaces or additional protocols dynamically, ensuring the system remains adaptable to evolving technological and operational needs.
[0027] The converted second data may be transmitted to any entity that consumes the data, e.g., an application or functionality of the pump, the pump itself, a further pump, an edge computing device, or a server. A publishing unit or entity may be used to determine to whom the converted second data shall be sent. Accordingly, the apparatus executing the method of the first aspect shall be informed about this information and provide the converted data to the indicated recipient accordingly.
[0028] Overall, the method supports conversion between multiple protocols, specifically data formats, enabling seamless interoperability between different types of sensors andGRUNDFOS HOLDING A / S
[0029] P25115WO
[0030] P62831 / WO
[0031] protocols (e.g. OPC UA, EtherCAT, etc.). This ensures that data from diverse sources can be integrated without the need for multiple, protocol-specific systems.
[0032] The method also eliminates the need for separate systems to handle different types of data inputs / interfaces. This facilitates easier integration and deployment in complex environments with diverse data inputs / interface networks.
[0033] The ability to dynamically detect and handle various protocols using the configuration profile or real-time identification adds flexibility and scalability. This adaptability makes it easy to expand the pump or the pump system with new data inputs / interfaces and protocols without major reconfigurations.
[0034] In an implementation form of the first aspect, the configuration profile comprises, for each data interface of the at least one data interface, one or more of:
[0035] an identifier of the data interface;
[0036] information about the first protocol;
[0037] connection information of the data interface; and
[0038] type information of the first data.
[0039] Each data interface may be assigned with a unique identifier to ensure proper association and distinction between multiple interfaces. This identifier allows to differentiate and correctly interpret data received from various sources. Examples of identifiers may include a device ID, a network address, or a specific tag assigned to the data interface during configuration.
[0040] The configuration profile specifies the type of protocol used by the respective data interface. This information enables the system to dynamically determine how to interpret and process the received data.
[0041] Connection details, such as the IP address, port number, slave ID (for Modbus), or endpoint (for OPC UA), are defined in the configuration profile. These details are crucial for establishing communication between the apparatus and the data interface. By leveraging this information, the system ensures a seamless connection for data acquisition.GRUNDFOS HOLDING A / S
[0042] P25115WO
[0043] P62831 / WO
[0044] The configuration profile may include details about the type of first data expected from the data interface, such as temperature, pressure, flow rate, or diagnostic data. This information helps the system categorize and normalize the data during protocol conversion. In some cases, multiple data types may be associated with a single data interface.
[0045] In a further implementation form of the first aspect, the first protocol is domainspecific, and the second protocol is domain-specific or universal.
[0046] Domain-specific protocols are typically designed to cater to the specific needs of particular industries or systems. Examples include OPC UA, Modbus (RTU and TCP / IP), EtherCAT, and Meter-bus. These protocols are often optimized for tasks such as real-time control, monitoring, and data acquisition within industrial or operational settings.
[0047] On the other hand, universal protocols, such as MQTT or HTTP, are designed for broader applicability and are widely used in loT systems and cross-industry applications. These protocols are particularly effective for enabling interoperability between heterogeneous systems, as they provide a common framework for data exchange.
[0048] In a further implementation form of the first aspect, converting the first data of the first protocol into the second data of the second protocol comprises normalizing the first data into a unified data structure.
[0049] Normalization involves transforming the first data, which may originate from different data interfaces and protocols and may have a respective data format or structure, into a standardized data format or structure. This ensures that all data, regardless of its source, is presented in a uniform format or structure, simplifying downstream processing and analysis.GRUNDFOS HOLDING A / S
[0050] P25115WO
[0051] P62831 / WO
[0052] In a further implementation form of the first aspect, normalizing the first data into the unified data structure comprises preserving metadata associated with the first data, the metadata comprising one or more of:
[0053] a timestamp;
[0054] a data quality indicator; and
[0055] a respective data interface identifier.
[0056] The timestamp indicates the precise time at which the first data was recorded or collected. By preserving the timestamp, it ensures temporal accuracy, which is critical for real-time monitoring, diagnostics, and historical analysis of pump operation.
[0057] The data quality indicator provides information about the reliability or validity of the first data. For instance, it may flag issues such as missing values, sensor errors, or communication disruptions. Retaining this information allows making informed decisions about the usability of the first data, enhancing its robustness and reliability.
[0058] The identifier links the first data to the specific data interface from which it originated. This linkage ensures traceability, as it can associate the first data with its source interface for diagnostics, analytics, or targeted control actions.
[0059] In a further implementation form of the first aspect, the second data is associated with pump functionality information.
[0060] The pump functionality information refers to data that corresponds to the functional / operational, diagnostic, or performance aspects of the pump or the pump system. This information is critical for ensuring seamless operation, monitoring, and optimization of the pump or the pump system. Examples of pump functionality information include, but are not limited to: operational parameters, diagnostic metrics, and control signals.
[0061] For instance, when converting the first data into a second protocol such as MQTT, the pump functionality information maybe represented using MQTT topics. Temperature readings may be associated with an MQTT topic such as “pump / temperature”.GRUNDFOS HOLDING A / S
[0062] P25115WO
[0063] P62831 / WO
[0064] Diagnostic information, such as vibration levels, may be assigned to “pump / diagnostics / vibration”.
[0065] By associating the converted data with pump functionality information, such as MQTT topics, the method enhances data usability, organization, and accessibility.
[0066] In a further implementation form of the first aspect, the method further comprises updating the configuration profile to accommodate one or more new data interfaces during operation of the pump.
[0067] The configuration profile is not static; it is designed to be updated dynamically to reflect changes in the system's operational environment. This includes the addition of new data interfaces, modifications to existing ones, or changes in protocols. These updates can be performed in real time, ensuring that the system remains adaptable and scalable without requiring downtime or manual reconfiguration.
[0068] This dynamic updating capability ensures that the system remains robust, flexible, and future-proof, accommodating changes in system architecture or operational requirements without disruption.
[0069] A second aspect of the present disclosure provides an apparatus for converting data into a protocol for a pump or a pump system. The apparatus is configured to:
[0070] - receive first data of a first protocol from at least one data interface, in which the first protocol is identified according to a configuration profile; and
[0071] - convert the first data of the first protocol into second data of a second protocol according to the configuration profile.
[0072] The second protocol is compliant with the pump or the pump system. The first protocol could not be compliant with the pump or the pump system. The apparatus may be a controller in the pump or pump system, for instance, integrated into the pump or pump system or standalone. The apparatus could also be the pump or pump system.
[0073] The apparatus may be further configured to send the converted data, i.e., the second data of the second protocol, to a recipient. Examples of the recipient may include butGRUNDFOS HOLDING A / S
[0074] P25115WO
[0075] P62831 / WO
[0076] not limited to: an application or functionality of the pump, the pump itself, a further pump, an edge computing device, or a server.
[0077] Information on the recipient maybe notified by an entity, e.g., a publishing entity (or referred to as publishing unit), which is configured to determine to whom specific second data of a specific second protocol shall be sent. The publishing entity may be included in the apparatus, i.e., it is also possible that the publishing entity and the apparatus may be combined.
[0078] In an implementation form of the second aspect, the configuration profile comprises, for each data interface of the at least one data interface, one or more of:
[0079] an identifier of the data interface;
[0080] information about the first protocol;
[0081] connection information of the data interface; and
[0082] type information of the first data.
[0083] In a further implementation form of the second aspect, the first protocol is domainspecific, and the second protocol is domain-specific or universal.
[0084] In a further implementation form of the second aspect, for converting the first data of the first protocol into the second data of the second protocol, the apparatus is configured to normalize the first data into a unified data structure.
[0085] In a further implementation form of the second aspect, the apparatus is configured to preserving metadata associated with the first data when normalizing the first data into the unified data structure, the metadata comprising one or more of:
[0086] a timestamp;
[0087] a data quality indicator; and
[0088] a respective data interface identifier.
[0089] In a further implementation form of the second aspect, the second data is associated with pump functionality information.GRUNDFOS HOLDING A / S
[0090] P25115WO
[0091] P62831 / WO
[0092] In a further implementation form of the second aspect, the apparatus is further configured to update the configuration profile to accommodate one or more new data interfaces during operation of the pump or the pump system.
[0093] In a further implementation form of the second aspect, the apparatus is a pump, or a processor (or chipset, controller) of the pump, or an external entity connectable (e.g., edge device) to the pump or the pump system.
[0094] The apparatus of the second aspect may share the same optional features and advantages as the method of the first aspect.
[0095] A third aspect of the present disclosure provides a system comprising a pump and one or more data points. The system may optionally comprise a remote server. The one or more data points are adapted to provide first data to the pump, and are thus, data interfaces to the pump. The pump maybe the apparatus according to the second aspect, or comprise the apparatus of the second aspect, or is connected with the apparatus of the second aspect. The converted second data may be transmitted to any entity or functionality that consumes the converted second data, e.g., to the pump itself, a specific application and / or functionality of the pump, a further pump, or the remote server.
[0096] A fourth of this disclosure provides a computer program product comprising instructions which, when the program is executed by a computer, cause the computer to perform the method of the first aspect.
[0097] A fifth aspect of this disclosure provide a computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of the first aspect.
[0098] 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 isGRUNDFOS HOLDING A / S
[0099] P25115WO
[0100] P62831 / WO
[0101] 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.
[0102] BRIEF DESCRIPTION OF DRAWINGS
[0103] 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
[0104] FIG. i shows a schematic of an apparatus for converting data between different protocols for a pump or a pump system according to the present disclosure;
[0105] FIG. 2 shows an exemplary structure of an apparatus according to the present disclosure;
[0106] FIG. 3 shows an example of converting data into various protocols;
[0107] FIG. 4 shows a diagram of a method 400 of this disclosure; and
[0108] FIG. 5 shows an example of a system according to the present disclosure.
[0109] DETAILED DESCRIPTION OF EMBODIMENTS
[0110] A list of abbreviations and acronyms used in the present disclosure is as follows:
[0111] OPC UA - Open Platform Communications Unified Architecture; MQTT - Message Queuing Telemetry Transport; JSON - JavaScript Object Notation; HTTP - Hypertext Transfer Protocol; SCADA - Supervisory Control and Data Acquisition; loT - Internet of Things; GENI - Generic Network Interface; RTU - Remote Terminal Unit; TCP / IP - Transmission Control Protocol / Internet Protocol; XML - Extensible Markup Language; Avro - Apache Avro; BSON - Binary JSON; PLC - Programmable Logic Controller; HMI - Human-Machine Interface; M-Bus - Meter -Bus; CCS - Command Center Server, EtherCAT - Ethernet for Control Automation Technology.GRUNDFOS HOLDING A / S
[0112] P25115WO
[0113] P62831 / WO
[0114] FIG. 1 shows a schematic of an apparatus 100 for converting data between different protocols for a pump or a pump system according to this disclosure.
[0115] The apparatus 100 is a pump, or a component (e.g., a processor, a controller) of the pump, or a unit connectable to the pump (e.g., an edge device). The pump of this disclosure is configured to pump fluid, such as water, oil, or gas. The pump may be a centrifugal pump. The pump may be a smart pump equipped with various processing functionalities and capable of communicating with a variety of sensors. Such a pump, or a system comprising multiple pumps, may be installed in environments such as households or industrial settings.
[0116] The apparatus 100 is configured to receive first data 101 of a first protocol from at least one data interface. This data 101 may comprise any data of interest to the pump or the system, such as sensor data, operational parameters, or data from other system (e.g., a SCADA system). Specific examples of the first data may include but not limited to: flow rate, temperature of the fluid, pressure, vibration, other diagnostic or performance-related data associated with the pump, environment temperature, and outdoor weather data. The first data 101 is transmitted to the apparatus 100 over a communication link, which may be wired or wireless. The first data may have a first data format or structure according to the first protocol.
[0117] The apparatus 100 is configured to identify the first protocol based on a configuration profile 109. For instance, the configuration profile may comprise information for interacting with different data interfaces. This information may, for instance, comprise one or more of: a unique identifier of each data interface, the protocol of the data provided by each data interface, connection details of each data interface, and the type of data provided by each data interface. By referencing the configuration profile 109, the apparatus 100 ensures interoperability, compatibility and accurate data interpretation across diverse protocols, such as OPC UA, EtherCAT, Modbus, or MQTT.
[0118] It could be that the first protocol is not compliant with the pump or the pump system. In this case, the data of the first protocol cannot be directly used by the pump or the pump system. The first protocol may be domain-specific, such as but not limited to:GRUNDFOS HOLDING A / S
[0119] P25115WO
[0120] P62831 / WO
[0121] OPC UA, EtherCAT, Modbus TCP / IP, and Meter-bus. If the received first data is already in a suitable format or in a protocol compliant with the pump or the system, the apparatus 100 is configured to forward the received first data without any change for further processing.
[0122] It is noted that how the configuration profile 109 is generated is not limited. For instance, the configuration profile 109 may be generated manually. Alternatively, it is contemplated that the configuration profile 109 maybe automatically generated based on system setup and configuration. For protocols that allow discovery (such as GENI and OPC UA), it is contemplated that tools or script may be used to detect devices in the system and collect the relevant information to generate the configuration profile 109. This enables an automated approach, ensuring consistent readings from all discovered devices.
[0123] Upon receiving data 101, the apparatus 100 is configured to convert the first data 101 of the first protocol into second data of a second protocol based on the configuration profile 109. The second protocol is compliant with the pump or the pump system. For instance, the data of the second protocol can be directly used by a functionality of the pump, while it is not possible for the pump functionality to directly use the first data of the first protocol. The second protocol may be domain-specific (e.g., GENI) or universal (e.g., MQTT). The second data may have a second data format or structure according to the second protocol.
[0124] Optionally, the conversion may involve normalizing the first data to a unified data format structure, which ensures consistency and facilitates further processing. For example, the received first data maybe transformed into a JSON format and assigned a corresponding MQTT topic, as dictated by the configuration profile 109.
[0125] The converted data 103 is then transmitted to its intended recipient using the second protocol. The recipient may be an application and / or functionality of the pump, the pump, a pump control system, an edge computing device, or a command center server, depending on the operational context. Information on the recipient may be provided by an entity, such as a publishing entity, which is configured to determine to whomGRUNDFOS HOLDING A / S
[0126] P25115WO
[0127] P62831 / WO
[0128] specific second data of a specific second protocol shall be sent. It is also possible that the publishing entity and the apparatus 100 maybe combined.
[0129] By performing the protocol conversion of the present disclosure, the apparatus 100 enables seamless data interoperability between disparate systems, ensuring that pump systems can function efficiently within complex, multi-protocol environments.
[0130] Optionally, during the protocol conversion, the apparatus 100 may support metadata preservation. For example, timestamps, quality indicators, and unique identifiers for each data interface are retained during the conversion process. This ensures data integrity and traceability, which are critical for diagnostic purposes and real-time decision-making.
[0131] The apparatus 100 may comprise a processor (not shown), which is configured to perform various processing steps and functionalities. The processor may be a controller or of a control module for the pump. The processor, or processing circuitry thereof, is configured to perform, conduct, or initiate various operations described in this disclosure. The processing circuitry may comprise hardware and / or the processing circuitry may be controlled by software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. The processor may further comprise memory circuitry, which can store one or more instruction(s) that can be executed by the processor or its processing circuitry, in particular, under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or its processing circuitry, causes the various described operations of the present disclosure to be performed.
[0132] FIG. 2 shows an exemplary structure of an apparatus 100 according to the present disclosure.
[0133] As shown in FIG. 2, the apparatus 100 comprises at least two functional units: an acquisition unit no, a conversion unit 120. Optionally, the apparatus 100 may furtherGRUNDFOS HOLDING A / S
[0134] P25115WO
[0135] P62831 / WO
[0136] comprise a publishing unit 130. It is also possible that the publishing unit 130 is a separate unit, since the publishing function is not essential for the apparatus for performing the data conversion.
[0137] For the avoidance of any doubt, it should be understood that the three units are illustrated schematically in a separate and distributed manner for ease of explanation of the function executed by the apparatus 100. It is contemplated that some or all of the function units may be implemented as one or more combined units.
[0138] The acquisition unit no is configured to receiving first data 101 of a first protocol from one or more data interfaces (or data sources, data points). The one or more data interfaces may include sensors, actuators, controllers, a further pump, other external devices, or SCADA systems that collect and transmit data that is of interest to the pump or the pump system.
[0139] The acquisition unit no references the configuration profile 109 to determine the protocol associated with each data interface for providing the first data. The configuration profile 109, which maybe stored in the apparatus and / or in an associated command center server, may comprise one or more of:
[0140] Data interface ID: A unique identifier for each data interface (or data source); Protocol type: The protocol employed by the data interface (e.g., OPC UA, EtherCAT, Modbus);
[0141] Connection details: Parameters for connecting to the data interface (e.g., IP address, port, slave ID);
[0142] Data type: The nature of the data to be collected (e.g., temperature, pressure); and
[0143] MQTT topic: MQTT topic where the JSON data should be published, which is specific to MQTT conversion.
[0144] Optionally, a data interface may provide more than one type of data to be collected / translated.
[0145] The acquisition unit no is configured to parse the received first data 101 to extract critical information. The first data 101 comprises information such as:GRUNDFOS HOLDING A / S
[0146] P25115WO
[0147] P62831 / WO
[0148] Data interface ID, which identifies the specific data input / interface among the group;
[0149] Timestamp, which indicates the time when the first data was recorded;
[0150] Data content, such as sensor / pump readings, including raw values like temperature, flow rate, or pressure; and
[0151] Status indicators, such as data quality or operational health of the data interface. Null values can represent unsuccessful readings.
[0152] The data provided by each data interface may be in predefined units and formats. For example, a reading for pump speed may be represented in percentage (of a maximum speed). This predefined structure reduces the payload size by eliminating the need for transmitting units and extensive metadata within the data 101.
[0153] The acquisition routine no is configured to identify the protocol of the received first data 101. How the identification is done is not limited. For example, it is contemplated that the acquisition unit 110 may access the configuration profile 109 where each data interface is associated with a specific protocol it employs.
[0154] The conversion unit 120 is configured to normalize the first data 101. The first data 101 is organized into a unified structure, ensuring consistency across different data sources and protocols. This may involve mapping essential fields such as timestamp, data point ID, and sensor readings into a standard format.
[0155] The conversion unit 120 is configured to transform the first data into second data of a second protocol as specified in the configuration profile 109. For example:
[0156] converting OPC UA data to MQTT with JSON payloads.
[0157] translating domain-specific protocols (e.g., Modbus) into a universal protocol like MQTT.
[0158] During this process, the conversion unit 120 may utilize predefined mappings from the configuration profile 109 to assign MQTT topics or other protocol-specific identifiers to the converted second data. It is noteworthy that JSON is just an example of a payload format, other formats such as XML, Avro, or BSON may also be employed, depending on system requirements.GRUNDFOS HOLDING A / S
[0159] P25115WO
[0160] P62831 / WO
[0161] As an example, the conversion unit 120 is configured to transform the received first data 101 into MQTT with JSON payload. Two main functions are executed by the conversion unit 120: MQTT topic matching, and conversion of the data into a JSON format.
[0162] For MQTT topic determination, the conversion routine 120 is configured to access the configuration profile 109 to match the correct MQTT topic based on the predefined mappings stored. In other words, the determination of the MQTT topic is not automated by the conversion routine 120 itself but is defined in the configuration profile 109.
[0163] For converting to JSON format, the conversion unit 120 is configured to access the configuration profile 109 and identify the type(s) of the first data. Having identified the type(s), the conversion unit 120 is configured to normalize the first data into a common structure to ensure consistency. This means organizing information such as data point ID, timestamp, data input / interface reading, etc. into a unified format regardless of the original protocol. After normalization, the first data is converted into JSON format. The conversion to the JSON format is to enable other devices or systems to process and understand the data. As mentioned above, it shall be understood that the use of JSON is just an example. It is contemplated that other payload formats maybe used (such as XML, Avro, BSON, etc.).
[0164] The publishing unit 130 is configured to send the converted second data 103 to its intended recipient. This recipient may include: an application and / or functionality of the pump, the pump, a further pump, a command center server (e.g., CCS no), an edge computing device for further data processing, or an external monitoring system (e.g., a SCADA system).
[0165] For instance, the publishing unit 130 maybe configured to establish a communication link with the recipient, such as connecting to an MQTT broker for publishing JSON payloads to designated topics. By doing so, the publishing unit 130 ensures real-time availability of operational data for monitoring, analysis, or integration with other systems.GRUNDFOS HOLDING A / S
[0166] P25115WO
[0167] P62831 / WO
[0168] It is further noted that, the signaling flow illustrated in FIG. 2 may be reversed. That is, the publishing unit 130 may be configured to receive internal data from the pump (or the pump system), and determine whether the internal data needs data conversion (in a reversed manner, i.e., converting the internal data from a protocol compliant with the pump to a protocol that is not compliant with the pump but is compliant with the corresponding data interface).
[0169] If the internal data is intended for an internal functionality and / or application of the same pump or the same pump system, then there may be no need for data conversion, and the publishing unit 130 may simply forward the internal data without data conversion. If the internal data is intended for an external entity, such as the one or more data interfaces that originally provide the first data, or other devices (e.g., a valve expecting a control signal according to temperature and / or pressure data from relative sensors), then there is a need for data conversion. The publishing unit 130 is in this case configured to send the internal data to the conversion unit 120 for data conversion (in a reversed manner as mentioned above). For instance, the conversion unit 120 may in this case convert data from the second protocol to the first protocol. This may involve converting the data from a first data format or structure to a second data format or structure. In the end, the apparatus 100 is configured to provide (or feedback) converted internal data from the pump (or the pump system), converted to a protocol that is compliant with the one or more data interfaces. In this case, the signalling flow illustrated in FIG. 3 maybe reversed, e.g., may originate in the pump, and go through the publishing unit 130, the conversion unit 120, and the acquisition unit no, to the one or more data interfaces. Therefore, the acquisition unit no in the present disclosure may also be a transceiver unit that is capable of receiving and sending data. Although the above examples are described with reference to converting to MQTT with JSON payload, it shall be understood that it is not limited as such. For example, it is contemplated that instead of converting, for example, OPC UA to MQTT with JSON payload, it is also possible to convert OPC UA to, another protocol, such as Modbus and the like. The function of the apparatus 100 is not limited to a “many to one” protocol conversion, but rather “many to many” protocol conversion.GRUNDFOS HOLDING A / S
[0170] P25115WO
[0171] P62831 / WO
[0172] By integrating multiple protocols into a single framework that normalizes and converts data in real-time, it is possible to manage protocol specific data acquisition while presenting a unified interface for further data processing and publishing.
[0173] FIG. 3 shows an example of converting data into various protocols. Converting the data into the MQTT with JSON payload as mentioned above may be used in certain application scenarios (e.g., root-cause detection on an edge module). However, it is also possible that it is less desirable to use MQTT with JSON protocol to communicate with a command center, in which case a MQTT with Avro protocol is preferred. As such, it is contemplated that the conversion routine 120 is configured to translate the data into MQTT with both JSON and Avro payloads, as schematically illustrated in FIG. 3. That is, in general, the apparatus 100 maybe configured to translate the same received data into two or more protocols.
[0174] FIG. 4 shows a diagram of a method 400 of this disclosure. The method is applied to an apparatus built based on FIG. 1-3, and comprises the following steps.
[0175] Step 401: receiving first data of a first protocol from at least one data interface, in which the first protocol is identified according to a configuration profile.
[0176] Step 402: converting the first data of the first protocol into second data of a second protocol according to the configuration profile. The second protocol is compliant with the pump or the pump system.
[0177] Optionally, the method comprises Step 403, sending the converted second data.
[0178] The method of FIG. 4 may share the same optional features as the apparatus mentioned in FIG. 1-3. For instance, step 401 maybe performed by the acquisition unit no. Step 402 may be performed by the conversion unit 120. Step 403 may be performed by the publishing unit 130.
[0179] FIG. 5 shows an example of a system according to the present disclosure. The system comprises one or more data sources, one or more pumps capable of data conversion capability introduced in the present disclosure, and a command center server (CCS).GRUNDFOS HOLDING A / S
[0180] P25115WO
[0181] P62831 / WO
[0182] The data sources are configured to collect and transmit first data that is of interest to the pump, and as such are communicatively coupled to the pump via a communication link that may be wired or wireless. The data sources may also be referred to as data inputs or data interfaces. Examples of data sources include but not limited to: sensors actuators, controllers, PLCs, HMIs, a SCADA system, and the like. There may be various types of sensors, such as sensors measuring vibration, motor power, motor RPM, pressure, temperature, flow rate, etc.
[0183] The pump is configured to receive, from a data source, first data of a respective protocol, such as but not limited to: GENI or other proprietary protocol (such as client’s proprietary communication protocol), OPC-UA, Modbus TCP / IP, Modbus RTU, Meter-bus, or EtherCAT.
[0184] The apparatus 100 introduced in FIG. 1-3 may be a component of the pump, or an external entity connectable the pump (not shown in FIG. 5). Alternatively, the pump itself may be the apparatus 100. In general, the pump can be adapted to perform the steps introduced in FIG. 4. The pump may comprise one or more processors (or a chipset, controller) and a memory. The processor of the pump may be configured to execute a set of computer executable program instructions, which cause the pump to perform the data translation.
[0185] The pump and the CCS may be connected via a communication link, enabling data transmission. The communication link may be wired or wireless.
[0186] The present disclosure may be applied in the pump industry. In conventional pump systems, the development of pump functionality (e.g., application layer of the pump) is tightly coupled to the specific types of sensors or data sources communicating with the pump or the system. Conventionally, incorporating new sensors or new data sources requires modifications at the application level to accommodate each protocol. This results in high development complexity, long integration cycles, and increased maintenance costs.GRUNDFOS HOLDING A / S
[0187] P25115WO
[0188] P62831 / WO
[0189] The present disclosure aims to decouple the application layer from the underlying data source infrastructure, allowing application development of the pump to be based on data of a standardized protocol, which is associated with a standardized data format or structure and that is compliant with the pump or the system. The apparatus 100 of the present disclosure shall act as a data coordinator for converting data of any protocol not compliant with the pump into data of a protocol that is compliant with the pump.
[0190] For example, in a pump system with multiple sensors (e.g., temperature, pressure, vibration, and flow sensors) using different protocols (e.g., OPC UA, Modbus, EtherCAT), employing such a data coordinator ensures that all sensor data is converted into a standardized protocol before being processed by the application and / or functionality of the pump. When a new sensor is introduced, only the configuration in the configuration profile needs to be updated— without requiring changes at the application layer of the pump system. This reduces software development efforts and ensures that the pump or the system remains scalable and future-proof.
[0191] Furthermore, this architecture enables easy transferability of applications across different pump models or even different pump systems. Since applications no longer rely on specific sensor interfaces, they can be deployed across various pump types without major modifications, facilitating cross-product compatibility and streamlined software deployment.
[0192] 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
GRUNDFOS HOLDING A / SP25115WOP62831 / WOClaims1. A method (400) of converting data to a protocol for a pump or a pump system, the method (400) comprising:receiving (401) first data of a first protocol from at least one data interface, wherein the first protocol is identified according to a configuration profile; and converting (402) the first data of the first protocol into second data of a second protocol according to the configuration profile, wherein the second protocol is compliant with the pump or the pump system.
2. The method (400) according to claim 1, wherein the configuration profile comprises, for each data interface of the at least one data interface, one or more of:an identifier of the data interface;information about the first protocol;connection information of the data interface; andtype information of the first data.
3. The method (400) according to claim 1 or 2, wherein the first protocol is domain-specific, and the second protocol is domain-specific or universal.
4. The method (400) according to any one of claims 1 to 3, wherein converting (402) the first data of the first protocol into the second data of the second protocol comprises normalizing the first data into a unified data structure.
5. The method (400) according to claim 4, wherein normalizing the first data into the unified data structure comprises preserving metadata associated with the first data, the metadata comprising one or more of:a timestamp;a data quality indicator; anda respective data interface identifier.
6. The method (400) according any one of claims 1 to 5, wherein the converted second data is associated with pump functionality information.GRUNDFOS HOLDING A / SP25115WOP62831 / WO7. The method (400) according to any one of claims 1 to 6, further comprising updating the configuration profile to accommodate one or more new data interfaces during operation of the pump or the pump system.
8. An apparatus (100) for converting data into a protocol for a pump or a pump system, the apparatus being configured to:receive first data (101) of a first protocol from at least one data interface, wherein the first protocol is identified according to a configuration profile (109);convert the first data (101) of the first protocol into second data of a second protocol according to the configuration profile (109), wherein the second protocol is compliant with the pump or the pump system.
9. The apparatus (100) according to claim 8, wherein the configuration profile (109) comprises, for each data interface of the at least one data interface, one or more of:an identifier of the data interface;information about the first protocol;connection information of the data interface; andtype information of the first data.
10. The apparatus (100) according to claim 8 or 9, wherein the first protocol is domain-specific, and the second protocol is domain-specific or universal.
11. The apparatus (100) according to any one of claims 8 to 10, wherein for converting the first data of the first protocol into the second data of the second protocol, the apparatus (100) is configured to normalize the first data (101) into a unified data structure.
12. The apparatus (100) according to claim 11, wherein the apparatus (100) is configured to preserve metadata associated with the first data (101) when normalizing the first data into the unified data structure, the metadata comprising one or more of:a timestamp;a data quality indicator; anda respective data interface identifier.GRUNDFOS HOLDING A / SP25115WOP62831 / WO13. The apparatus (100) according to any one of claims 8 to 12, wherein the second data (103) is associated with pump functionality information.
14. The apparatus (100) according to any one of claims 8 to 13, wherein the apparatus (100) is a pump, or a control entity of the pump, or an external entity connectable to the pump.
15. A computer program product comprising instructions which, when the program is executed by a computer, causes the computer to perform the method according to one of the claims 1 to 7.