Patent Description:
In a real-world scenario, data is generated by a plurality of sources. Non-limiting examples of sources include field devices, computing devices, controllers and diagnostic systems. The data generated by a source is further processed using one or more client applications. For example, the client applications may be associated with data preprocessing, data analytics, data visualization etc. The client applications may be hosted on one or more clients. However, it may so happen that the source and the client may support different interfaces, data formats and/or communication protocols. Often, the data format supported by two devices in communication may be different, even though the communication protocol remains the same. Alternatively, the data format may be same for both the devices, but the communication protocol may differ. In such situations, different hardware or software components may be required to manage communication between the devices. Consequently extensive efforts and resources are required for enabling such communication.

In light of the above, there exists a need for managing communication between devices operating on diverse interfaces, data formats and communication protocols.

<CIT> relates to an alleged advancements in the field of the Internet of Things (IoT) focusing on a publish-subscribe (pub-sub) data model to enhance data exchange among interconnected devices.

<CIT> relates to an integrated message publisher and subscriber system designed for factory or production automation, focusing on facilitating communication across diverse tools and technologies within manufacturing environments.

<CIT> relates to a method for managing and optimizing energy systems by integrating devices across multiple domains using a specialized system. This system bridges devices of various protocols by employing native and foreign nodes, which represent the devices in their respective protocol languages.

Hereinafter, the term 'server' may refer to any computer program or device that provides data and the term `client refers to any computer program or device that uses the data provided by the server for one or more client applications.

The object of the present invention is achieved by a method for managing communication between at least one server and at least one client. Here, the server is associated with a technical system that generates source data.

The method comprises obtaining source data associated with the technical system from at least one first endpoint associated with the server, by a processing unit, wherein the first endpoint publishes the source data in a predefined source format. In an embodiment, the step of obtaining source data associated with the technical system from at least one first endpoint associated with the server further comprises, polling the at least one first endpoint associated with the server to obtain the source data.

The method further comprises converting the source data in the source format to a generic format. In an embodiment, the generic format comprises key-value pairs indicative of the source data. In an embodiment, the step of converting the source data in the source format to the generic format comprises, firstly, identifying the source format associated with the first endpoint. Further, a first data structure associated with the source data is determined based on the identified source format. Based on the determined first data structure, the source data in the source format is converted to the generic format. The method may further comprise storing the source data in the generic format to an intermediary storage location.

Advantageously, the conversion of the source data in source format to the generic format helps in standardizing the source data. Consequently, the standardized source data may be utilized by a plurality of clients operating on diverse protocols.

The method further comprises converting the source data in generic format to a target format based on the configuration setting corresponding to the server. The configuration setting indicates at least one of an association of the server with the client and the target format associated with the client. In a further embodiment, the method may further comprise identifying the configuration setting corresponding to the server from a plurality of configuration settings stored in a database. In an embodiment, the step of converting the source data in generic format to the target format based on the configuration setting comprises, determining a second data structure associated with the target format of the client. Based on the determined second data structure, the source data in generic format is converted to the target format.

Advantageously, the present invention provides a mechanism for converting generic data to any target format based on the second endpoint. Consequently, the present invention enables scalability to any number of servers and clients operating on diverse protocols.

The method further comprises providing the source data in the target format to the client. In an embodiment, the step of providing the source data in the generic format to the at least one client comprises, publishing the source data in the target format to at least one second endpoint (<NUM>) associated with the client. The method may further comprise analyzing the source data in the target format using at least one client application hosted on the client.

Advantageously, the present invention facilitates communication between a client and a server via endpoints that operate on different communication protocols without the need for customized converter units. The present invention is also extensible to accommodate newer communication protocols by adding corresponding configuration settings to the database, without the need for additional hardware resources.

The object of the present invention is also achieved by an apparatus for managing communication between at least one server and at least one client. The apparatus comprises one or more processing units and a memory unit communicatively coupled to the one or more processing units. The memory unit comprises a communication management module stored in the form of machine-readable instructions executable by the one or more processing units, wherein the communication management module is configured to perform method steps described above.

The object of the present invention is also achieved by a system for managing communication between at least one server and at least one client. The system comprises an apparatus as described above, communicatively coupled to the server and the client. The apparatus is configured to manage communication between the server and the client in accordance with any of the method steps described above.

Disclosed herein is also a computer-readable medium, on which program code sections of a computer program are saved, the program code sections being loadable into and/or executable by a processor which performs the method as described above when the program code sections are executed.

The realization of the invention by a computer program product and/or a non-transitory computer-readable storage medium has the advantage that computer systems can be easily adopted by installing computer program in order to work as proposed by the present invention.

The computer program product can be, for example, a computer program or comprise another element apart from the computer program. This other element can be hardware, for example a memory device, on which the computer program is stored, a hardware key for using the computer program and the like, and/or software, for example a documentation or a software key for using the computer program.

The above-mentioned attributes, features, and advantages of the present invention and the manner of achieving them, will become more apparent and understandable (clear) with the following description of embodiments of the invention in conjunction with the corresponding drawings. The illustrated embodiments are intended to illustrate, but not limit the invention.

<FIG> shows a block diagram of a system <NUM> for managing client-server communication, in accordance with an embodiment of the present invention. The system <NUM> comprises an apparatus <NUM> configured to manage communication between a plurality of servers 110A-N (henceforth collectively called server <NUM>) and a plurality of clients 115A-M (henceforth collectively called client <NUM>). The apparatus <NUM> may be communicatively coupled to the servers 110A-N and the clients 115A-M over a network <NUM>. Each of the clients 115A-M may host a client application that performs operations based on source data received from at least one of the servers 110A-N. More specifically, the client <NUM> may analyze the source data using the client application.

Each of the servers 110A-N may be associated with a technical system or device in an industrial environment that generates source data. The source data is generated based on one or more operational parameters of the technical system. The term `technical system` as used herein may refer to field devices including, but not limited to, motors, pumps, sensing units, control systems etc. Operational parameters of the technical system may include parameters that indicate at least one of operational status, events, output signals, input signals, failure messages etc..

In the present embodiment, each of the servers 110A-N corresponds to a field device in a railway infrastructure. The field device may be a hardware system that is communicatively coupled to the server <NUM> for publishing one or more operational parameters via at least one endpoint. The term 'endpoint` as used herein refers to an Input/Output interface exposed by a virtual or physical device on the network <NUM>. The endpoint may be associated with a physical network address that enables the device to send or receive data via the network <NUM>. Each endpoint is associated with a predefined communication protocol.

The term 'first endpoint` as used hereinafter, refers to an endpoint associated with the server <NUM>. Similarly, the term 'second endpoint` as used hereinafter refers to an endpoint associated with the client <NUM>. It must be understood that the server <NUM> may have multiple first endpoints and each of the first endpoints may be associated with a specific communication protocol. In the present embodiment, the server 110A is associated with at least one first endpoint 120A, the server 110B is associated with at least one first endpoint 120B, the server 110N is associated with the at least one first endpoint 120N and so on. Consequently, each of the first endpoints 120A-N (hereinafter collectively referred to as first endpoint <NUM>) may generate the source data in a unique source format. Each of the clients 115A-M may also have multiple second endpoints 125A-M (hereinafter collectively referred to as second endpoint <NUM>). Each of the second endpoints 125A-M may be associated with a specific communication protocol. Similarly, the client 115A is associated with at least one second endpoint 125A, the client 115B is associated with at least one second endpoint 125B, the client 115N is associated with the at least one second endpoint <NUM> and so on.

The apparatus <NUM> comprises a processing unit <NUM>, a memory <NUM>, a storage unit <NUM>, a communication module <NUM>, a network interface <NUM>, an input unit <NUM>, an output unit <NUM>, a standard interface or bus <NUM> as shown in <FIG>. The apparatus <NUM> can be a (personal) computer, a workstation, a virtual machine running on host hardware, a microcontroller, or an integrated circuit. As an alternative, the apparatus <NUM> can be a real or a virtual group of computers (the technical term for a real group of computers is "cluster", the technical term for a virtual group of computers is "cloud").

The term `processing unit`, as used herein, means any type of computational circuit, such as, but not limited to, a microprocessor, a microcontroller, a complex instruction set computing microprocessor, a reduced instruction set computing microprocessor, a very long instruction word microprocessor, an explicitly parallel instruction computing microprocessor, a graphics processor, a digital signal processor, or any other type of processing circuit. The processing unit <NUM> may also include embedded controllers, such as generic or programmable logic devices or arrays, application specific integrated circuits, single-chip computers, and the like. In general, the processing unit <NUM> may comprise hardware elements and software elements. The processing unit <NUM> can be configured for multithreading, i.e., the processing unit <NUM> may host different calculation processes at the same time, executing the either in parallel or switching between active and passive calculation processes.

The memory <NUM> may include one or more of a volatile memory and a non-volatile memory. The memory <NUM> may be coupled for communication with the processing unit <NUM>. The processing unit <NUM> may execute instructions and/or code stored in the memory <NUM>. A variety of computer-readable storage media may be stored in and accessed from the memory <NUM>. The memory <NUM> may include any suitable elements for storing data and machine-readable instructions, such as read only memory, random access memory, erasable programmable read only memory, electrically erasable programmable read only memory, hard drive, removable media drive for handling compact disks, digital video disks, diskettes, magnetic tape cartridges, memory cards, and the like.

The memory <NUM> comprises a communication management module <NUM> stored in the memory <NUM> in the form of machine-readable instructions and executable by the processing unit <NUM>. These machine-readable instructions when executed causes the processing unit <NUM> to manage communication between the servers 110A-N and the clients 115A-M. The communication management module <NUM> comprises at least one converter module <NUM> and at least one publisher module <NUM>. The converter module <NUM> is configured to obtain source data associated with a technical system from the at least one first endpoint <NUM> associated with the server <NUM>. The source data is in a predefined source format.

The term 'source format` as used herein, refers to a data format indicative of a communication protocol associated with the first endpoint <NUM> of the server <NUM>. For example, the first endpoint 120A of the server 110A may publish the source data in accordance with HTTP protocol. More specifically, the first endpoint 120A may generate a binary stream when a change in one or more operational parameters of the corresponding field device occurs. In another example, the first endpoint 120B of the server 110B may publish the source data in accordance with HTTP protocol. More specifically, the first endpoint 120B may generate an XML file when a change in one or more operational parameters of the corresponding field device occurs. In yet another example, the first endpoint 120C of the server 110C publishes the source data in accordance with OPC UA protocol. More specifically, the first endpoint 120C may generate an event when a change in operational parameters of the corresponding field device occurs. The converter module <NUM> is further configured to convert source data published by the corresponding first endpoint <NUM> in a predefined source format to a generic format. The generic format may indicate the source format of the source data, keys or variables present in the source data, values corresponding to the keys etc..

The publisher module <NUM> is configured to convert the source data in generic format to a target format based on a configuration setting associated with the server <NUM>. The configuration setting provides an indication of association between the server <NUM> and one or more of the clients <NUM>. The term 'association' as used herein refers to a mapping between network addresses of a server and a respective client, wherein the client-server communication takes place. More specifically, the first endpoint of the server is mapped to the second endpoint of the client. The configuration setting also provides an indication of a target format associated with the one or more clients <NUM> associated with the server <NUM>. The term 'target format` as used herein, refers to a data format indicative of a communication protocol associated with the second endpoint <NUM> of the client <NUM>. The publisher module <NUM> is further configured to provide the source data in the target format to the client <NUM>.

The storage unit <NUM> comprises a non-volatile memory which stores source data in generic format upon conversion by the converter module <NUM>. The publisher module <NUM> may fetch the stored source data in generic format, from the storage unit for converting to the target format. The storage unit <NUM> may further comprise a database <NUM> of data formats and data structures corresponding to a plurality of predetermined communication protocols. The database also stores a plurality of configuration settings each of which correspond to at least one of the servers <NUM>. The term `data structure` as used herein may refer to data types, keys (variables), values associated with the keys, etc. In addition, the data structure may also indicate the sequence or hierarchy in which the variables are arranged in accordance with the communication protocol.

The input unit <NUM> may include input means such as keypad, touch-sensitive display, camera, etc. capable of receiving input signal. The output unit <NUM> may include output means such as displays. The bus <NUM> acts as interconnect between the processing unit <NUM>, the memory <NUM>, the storage unit <NUM>, and the network interface <NUM>.

The communication module <NUM> enables the apparatus <NUM> to communicate with the output device <NUM>. The communication module <NUM> may support different standard communication protocols such as Transport Control Protocol/Internet Protocol (TCP/IP), Profinet, Profibus, and Internet Protocol Version (Ipv).

According to an embodiment of the present invention, the apparatus <NUM> can be an edge computing device. As used herein "edge computing" refers to computing environment that is capable of being performed on an edge device (e.g., connected to technical systems in an industrial setup and one end and to a remote server(s) such as for computing server(s) or cloud computing server(s) on other end), which may be a compact computing device that has a small form factor and resource constraints in terms of computing power. A network of the edge computing devices can also be used to implement the apparatus <NUM>. Such a network of edge computing devices is referred to as a fog network.

In another embodiment, the apparatus <NUM> is a cloud computing system having a cloud computing based platform configured to provide a cloud service for monitoring faults in an induction motor <NUM>. As used herein, "cloud computing" refers to a processing environment comprising configurable computing physical and logical resources, for example, networks, servers, storage, applications, services, etc., and data distributed over the network <NUM>, for example, the internet. The cloud computing platform may be implemented as a service for monitoring faults in an induction motor <NUM>. In other words, the cloud computing system provides on-demand network access to a shared pool of the configurable computing physical and logical resources. The network <NUM> is, for example, a wired network, a wireless network, a communication network, or a network formed from any combination of these networks.

The client <NUM> may further process the source data published to the second endpoint <NUM>, in the target format to perform one or more functions. For example, the source data may be processed to analyze an operational cycle, operational state or failure, remaining useful life etc. associated with the field device.

In an embodiment, the client <NUM> is a cloud computing platform hosting a cloud-based service that processes time-series data. The time-series data is processed to compute, for example, an operational cycle of the server <NUM> for a specific interval of time. The operational cycle may be further compared to a standard operating cycle to determine operational stability of the field device. The computed operational cycle along with the standard operating cycle may be further displayed on a graphical user interface associated with the client <NUM> or a display device communicatively coupled to the client <NUM>. Similarly, the time-series data may be further used to compute remaining useful life of the field device using predetermined mathematical models.

In another embodiment, the client <NUM> is an OPC UA server comprising a client application that analyses event data published to the second endpoint <NUM> by the publisher module <NUM>. The event data may correspond to, for example, device failure, system messages, alarms etc. The event data may be processed to identify one or more subsequent actions to be performed at the field device. For example, the one or more subsequent actions may include resetting the field device to a normal state, displaying an indication of the event on a graphical user interface etc..

Those of ordinary skilled in the art will appreciate that the hardware depicted in <FIG> and <FIG> may vary for different implementations. For example, other peripheral devices such as an optical disk drive and the like, Local Area Network (LAN)/ Wide Area Network (WAN)/ Wireless (e.g., Wi-Fi) adapter, graphics adapter, disk controller, input/output (I/O) adapter, network connectivity devices also may be used in addition or in place of the hardware depicted. The depicted example is provided for the purpose of explanation only and is not meant to imply architectural limitations with respect to the present disclosure.

<FIG> shows a flowchart of a method <NUM> for managing client-server communication, in accordance with an embodiment of the present invention. The method <NUM> may be implemented as a machine-executable program on the apparatus <NUM>.

At step <NUM>, source data associated with a technical system from at least one first endpoint, say the first endpoint 110A associated with the server 110A, is obtained in a predefined source format, by the processing unit. In an embodiment, the converter module <NUM> polls the first endpoint 120A associated with the server 110A to obtain the source data. The term 'polling' as used herein refers to the act of periodically checking the first endpoint 120A for new source data. In an implementation, the apparatus <NUM> may poll the first endpoint 120A using a polling subscription service. The polling subscription service is an asynchronous process that involves iteratively sending subscribe requests to the server 110A over predefined time intervals. Upon polling, the server 110A provides the latest source data in the source format to the apparatus <NUM>.

At step <NUM>, the source data in the source format, obtained from the first endpoint 120A, is converted to a generic format. In a preferred embodiment, the generic format comprises one or more key-value pairs generated from the source data. The source data is converted to the generic format by firstly, identifying the source format associated with the first endpoint 120A. For example, the source format may be binary streams, OPC UA value change events, XML files, etc. For example, the source format may be identified based on a format in which the server 110A publishes the source data to the first endpoint 120A. In an implementation, a predefined logic based on number of data fields, field delimiters, NULL values, data types etc., present in the data stream corresponding to the source data. Upon identifying the source format, a first data structure associated with the source data is determined. Further, the source data in the source format is converted to the generic format based on the first data structure. More specifically, each source format is associated with a predefined first data structure.

For example, if the source data comprises a binary stream comprising <NUM> and <NUM>, the keys may indicate variable fields associated with the field device. The variable fields may indicate a unique identifier and type associated with the field device, origin timestamp of the source data and operational status of sub-components. Each of the keys have a corresponding value. The arrangement of data fields, field sizes etc. in the first data structure are used to identify keys and corresponding values in the source data. Further, the keys and values are ordered as pairs to generate the key-value pairs. The key-value pairs may be further stored in an intermediary storage location within the storage unit.

An example of a key-value pair is shown below:
{"devicename" : "TCM6_WA", "deviceType" : "TCM100", "sourceTimestamp" : "<NUM>", "LED1" : "<NUM>", "LED2" : "<NUM>". "TransitFrequency":"<NUM>"}.

Here, "devicename", "deviceType", "sourceTimestamp" etc. represent keys, while the respective values "TCM6_WA", "TCM100", "<NUM>" are paired with the keys to form ordered pairs.

At step <NUM>,
the source data is converted in generic format to a target format based on configuration setting associated with the server <NUM>. In an example, the configuration setting associated with server 110B may indicate an association between the server 110B and the client 110B. In another example, the configuration setting may also indicate association between the server 110B and a plurality of clients, say clients 115B and 115C. The configuration setting also provides an indication of the target format associated with the each of the clients <NUM> associated with the server <NUM>. In an embodiment, the configuration setting is identified from a plurality of configuration settings stored in the database <NUM>.

In another embodiment, the configuration setting may be dynamically generated based on a request for accessing the source data received from at least one second endpoint, say second endpoint 125D associated with the client 115D. For example, the request may be generated by a polling subscription service running on the client 115B. The request may include one or more data fields indicative of the target format associated with the second endpoint 125B. Further, the configuration setting is dynamically generated based on an identifier corresponding to the second endpoint 125D and the target format associated with the client 115D. For example, the target format may be identified based on the data fields in the request received from the client 115B.

Further, a second data structure is determined based on the target format. The source data is further converted to the target format based on the second data structure. More specifically, the key-value pairs are packaged in accordance with the data fields in the second data structure. Non-limiting examples of the target format may include time-series data, MQTT messages and events.

At step <NUM>, the source data in the target format is provided to the client 115B. The source data is provided to the client 115B, by publishing the source data in target format the second endpoint 125B associated with the client 115B. The client 115B may include one or more second endpoints 125B configured to receive the source data from the publisher unit. For example, the client 115B may be a cloud-based service hosted on a cloud platform, and the second endpoint 125B associated the cloud platform may be configured to receive time-series data. In another example, the second endpoint 125B associated with the client 115B may be configured to receive MQTT messages. In yet another example, the client 115B client may be an OPC UA server, and the second endpoint 125B may be configured to receive source data in the form of an event.

<FIG> shows a flowchart of an exemplary method <NUM> for managing communication between a Track Circuit Module (TCM) and an OPC UA server, in accordance with an embodiment of the present invention. The Track Circuit Module is a field device that generates source data corresponding to track circuits.

At step <NUM>, the TCM comprises an internal server (similar to server <NUM>) polls the TCM to obtain source data. At step <NUM>, the source data is published via a HTTP endpoint of the server in the form of a binary stream. At step <NUM>, the HTTP endpoint is polled by an apparatus (similar to apparatus <NUM>). At step <NUM>, the apparatus generates a record comprising key-value pairs corresponding to the binary stream. The record may be further stored in a storage location associated with the apparatus. At step <NUM>, the key-value pairs are fetched from the storage location and converted to OPC UA format based on a configuration setting of the server. In the present example, the configuration setting indicates an association between the TCM and the OPC UA server, and the target format as OPC UA format. At step <NUM>, the apparatus publishes the source data in OPC UA format to a second endpoint associated with the OPC UA server.

<FIG> shows a flowchart of an exemplary method <NUM> for managing communication between one or more frequency module devices and an MQTT endpoint associated with a client (similar to client <NUM>), in accordance with an embodiment of the present invention. Each of the frequency module devices is an OPC UA server that store source data in OPC UA format.

At step <NUM>, the source data in OPC UA format may be obtained from the OPC UA server. In an embodiment, the source data is fetched in OPC UA format using an OPC UA client application subscribed to the OPC UA server. At step <NUM>, an apparatus (similar to <NUM>) converts the source data from OPC UA format to key-value pairs. Further, the key-value pairs may be stored in a storage location. At step <NUM>, the apparatus fetches the key-value pairs and converts them to JSON format based on a configuration setting associated with the OPC UA server. The configuration setting indicates an association between the OPC UA server (or the frequency module device) and the MQTT endpoint. At step <NUM>, the source data in JSON format is published to the MQTT endpoint.

Advantageously, the present invention facilitates multi-protocol communication between devices without the need for customized converter units. Further, the present invention may be extended to managing communication between any number of servers and clients, without the help of additional hardware or software elements.

The present invention is not limited to a particular computer system platform, processing unit, operating system, or network. One or more aspects of the present invention may be distributed among one or more computer systems, for example, servers configured to provide one or more services to one or more client computers, or to perform a complete task in a distributed system. For example, one or more aspects of the present invention may be performed on a client-server system that comprises components distributed among one or more server systems that perform multiple functions according to various embodiments. These components comprise, for example, executable, intermediate, or interpreted code, which communicate over a network using a communication protocol. The present invention is not limited to be executable on any particular system or group of system, and is not limited to any particular distributed architecture, network, or communication protocol.

Claim 1:
A computer-implemented method for managing communication between at least one server (<NUM>) and at least one client (<NUM>), the method comprising:
obtaining (S205) source data associated with a technical system from at least one first endpoint (<NUM>) associated with the server (<NUM>), by a processing unit, wherein the first endpoint (<NUM>) publishes the source data in a predefined source format;
converting (S210) the source data in the source format to a generic format, wherein the generic format comprises key-value pairs indicative of the source data;
converting (S215) the source data in generic format to a target format based on a configuration setting corresponding to the server (<NUM>); and
providing the source data in the target format to a client (<NUM>).