Patent Description:
<CIT> discloses a microservice in a cloud platform.

A recent trend of industry <NUM> is the IT/OT convergence. The current disclosure relates to integration of generic IT application - typically microservices - into OT application in the form of PLC programs. Such microservices can expose a wide variety of functions, e.g., AI application, communication with the Enterprise Resource Planning System, Database Applications, etc. A central component of an automation system is the Programmable Logic Controller (PLC). PLCs are real-time capable devices that control critical applications in industries like factory automation. The PLC processes the inputs from the system and generates outputs to control it, often with real-time constraints. They are designed to run their program deterministically in order meet the real-time constraints of the processes that they control. Therefore, compute-intense functionalities (e.g. data analytics, execution of AI models) are separated from the PLC program and run on other devices, e.g. IPCs (Industrial PCs) or within cloud environments. The PLC program only invokes those functionalities and receives the result upon completion without blocking the control program.

Most modern software architectures use the microservice architecture paradigm. This is a variant of the service-oriented architecture which arranges an application as a collection of loosely coupled services. The communication between a service-consumer (client) and a microservice as well as between microservices is realized via an API (application programming interface) that is offered by the microservice to invoke remote procedures (in general called RPC, remote procedure calls) within the microservice in order to transfer data, but also to invoke functionalities (e.g., business rules, functions) that return a result. The most used protocol is HTTP in order to build APIs using approaches like REST or OpenAPI. Another common communication approach is the usage of messaging with a message-oriented middleware e.g., by using publish/subscribe mechanisms. Participants (e.g., clients, microservices) can publish a topic and send data to it via messages, and other participants can subscribe to those topics and receive the messages. A common protocol for M2M/IOT messaging is MQTT.

Most conventional PLCs support communication based on TCP/IP and accordingly, it is challenging to efficiently integrate the communication between PLC program and microservices. The conventional approach still suffers from inflexibility and require manual integration efforts by automation engineers to enable communication between PLCs and microservices. Particularly, all approaches utilized in modern software architecture require data structures to be serialized by the sender and de-serialized into the original data structure by the receiver. Most commonly, data is expected to be serialized as JSON (JavaScript Object Notation) string. However, the current capabilities of PLC programming languages (Function Block Diagram, Ladder Logic, SCL) do not support mechanism like reflection and therefore are not suitable for generic JSON serialization/deserialization.

Accordingly, often automation engineers manually write code that parses PLC data structures into the pre-defined serialization format that is expected by the receiving end and de-serialize the received data back into PLC data structures. The manual integration effort increases with every new API call that is used or message to be send or received. Implementation of such custom code is often errorprone and has high implementation costs which increase rapidly along the integration of additional service calls in the PLC program. Accordingly, there is a need for a method and system which addresses the problems mentioned above.

Accordingly, the current disclosure describes a method of communicating with a microservice in an industrial facility. The method is implemented by a controller and comprises obtaining one or more data structure types, wherein the one or more data structure types are generated based on an API definition associated with the microservice, generating one or more variables based on the obtained data structure types, wherein the one or more variables are associated with one or more function blocks of the controller, and transmitting data associated with the one or more variables to the microservice via a proxy component. The controller transmits the data associated with the one or more variables in a serialized binary format associated with the one or more variables to the proxy component. The proxy component is configured to translate to translate the data from the serialized binary data to a first serialization format and transmit the data in the first serialization format to the microservice.

Accordingly, the current disclosure describes a method of communication between the controller (including the programmable logic controller) and the microservice. The communication is enabled using a proxy component which is able to translate the data formats of the data exchanged between the controller and the microservice such that the data is the data format which can be understood by the corresponding controller or the microservice. Such translation is enabled via the API definition of the microservice which is used by the controller to generate variables. Accordingly, using the API definition, communication between the controller and the microservice is implemented without requiring considerable manual efforts and proprietary protocols.

In an example, the method further comprises receiving a response from the microservice via the proxy component, wherein the proxy component is configured to translate the response from the first serialization format to the serialized binary format and transmit the response in serialized binary format to the controller. Accordingly, the current disclosure provides for bidirectional communication between the controller and the microservice. In an example, the proxy component is embedded in the controller. Accordingly, this no need for additional hardware for implementation of the above method.

In an example, the data associated with the one or more variables includes a data identifier, wherein the data identifier is for mapping the data to a corresponding response from the microservice. The proxy component is able to track responses to their corresponding communication from the controller on the basis of the data identifiers in the data sent from the controller.

In an example, the one or more data structure types are generated based on an API definition associated with the microservice by a data structure generation module. The data structure generation module acts as an intermediate component for defining the data structure types from the API definition associated with the micro service. Accordingly, inclusion of additional microservices may be done by modifying the data structure generation module and without changing anything on the side of the controller. In an example, the proxy component is configured to receive the one or more data structure types for translating the data from the serialized binary format to a first serialization format. Accordingly, the proxy component is able to data structure types for translation for new microservices which may be added later on.

In another aspect, the current disclosure describes a controller configured to communicate with a microservice in an industrial facility. The controller comprises a network interface connected to the microservice via the proxy component, for transmitting data and receiving responses from the microservice, and one or more processors connected to a memory module. The one or more processors are configured to obtain one or more data structure types, wherein the one or more data structure types are generated based on an API definition associated with the microservice, generate one or more variables based on the obtained data structure types, wherein the one or more variables are associated with one or more function blocks of the controller and transmit data associated with the one or more variables to the microservice via a proxy component. The controller transmits the data associated with the one or more variables in a serialized binary format to the proxy component and the proxy component is configured to translate the data from the serialized binary format to a first serialization format and transmit the data in the first serialization format to the microservice.

In another aspect, the current disclosure describes a non-transitory storage medium configured to communicate with a microservice in an industrial facility. The non-transitory storage medium comprises a plurality of instructions which when executed on one or more processors, cause the one or more processors to obtain one or more data structure types, wherein the one or more data structure types are generated based on an API definition associated with the microservice, generate one or more variables based on the obtained data structure types, wherein the one or more variables are associated with one or more function blocks of the controller, and transmit data associated with the one or more variables to the microservice via a proxy component, wherein the controller transmits the data associated with the one or more variables in a serialized binary format to the proxy component, and wherein the proxy component is configured to translate the data from the serialized binary format to a first serialization format and transmit the data in the first serialization format to the microservice. The advantages of the method as applicable to the controller and the non-transitory storage medium mentioned above. These aspects are further explained in reference to <FIG>.

<FIG> illustrates an industrial automation system <NUM> in an industrial facility. Industrial facility herein refers to any environment where one or more industrial processes such as manufacturing, refining, smelting, assembly of equipment may take place and includes process plants, oil refineries, automobile factories, etc. The industrial automation system <NUM> includes a plurality of control devices such as programmable logic controllers (shown in the figure as controller <NUM>), process con-trollers, supervisory controllers, operator devices, etc..

The control devices (for example controller <NUM>) are connected to a plurality of field devices such as actuators (not shown in figure) and sensor devices (not shown in figure) for monitoring and controlling industrial processes in the industrial facility. These field devices can include flowmeters, value actuators, temperature sensors, pressure sensors, etc. To enable the control of the industrial processes in the industrial facility, a plurality of control applications are installed on the controllers.

In addition to the control and field devices, the industrial automation system <NUM> includes one or more enterprise level systems such enterprise resource planning (ERP) servers, manufacturing execution systems, etc. The enterprise level systems include a plurality of enterprise applications which may be realized as microservices in accordance with microservice architecture. Microservice architecture is a variant of the service-oriented architecture which arranges an application as a collection of loosely coupled services. The communication between a service-consumer (client) and a microservice as well as between microservices is realized via an API (application programming interface) that is offered by the microservice to invoke remote procedures (in general called RPC, remote procedure calls) within the microservice in order to transfer data, but also to invoke functionalities (e.g. business rules, functions) that return a result. The most used protocol is HTTP in order to build APIs using approaches like REST or OpenAPI. Mostly commonly, JavaScript object notation (JSON) format is used for data transmission amongst the microservices and the service-consumers. One such microservice application is shown in the <FIG> as microservice <NUM>. However, such protocols and data formats may not be implemented or utilized by the control devices. Accordingly, the industrial automation system <NUM> includes a proxy component <NUM> for enabling communication between the control devices and the microservice applications (also referred to as microservices). This is further explained in relation to <FIG>.

<FIG> illustrates a method <NUM> of communicating with a microservice <NUM> in an industrial facility. The method <NUM> is implemented by the controller <NUM>. At step <NUM>, the controller <NUM> obtains one or more data structure types <NUM>. The one or more data structure types <NUM> are generated based on an API definition <NUM> associated with the microservice <NUM>. The one or more data structures are generated by a data structure generator or data structure generation module <NUM>.

The data structure generation module <NUM> is configured to receive the API definition <NUM> associated with the microservice <NUM>. The API definition <NUM> is a standard, language-agnostic interface to microservice enabling service consumers to discover and understand the capabilities of the microservice <NUM>. An example API definition <NUM> is shown in <FIG>. As shown in <FIG>, the API definition <NUM> defines a function 'Arithmetics' which takes two variables 'x' and 'y' of the type 'number' (also referred to as request) and performs an arithmetic operation on them. Additionally, the response from the function 'Arithmetics' is an object of the type 'number' which is the result of the arithmetic operation. Accordingly, based on the example API definition <NUM>, the data structure generation module <NUM> defines the one or more data structure types <NUM>. For example, based on the API definition <NUM>, the data structure generation module <NUM> defines a number type data structure for the request i.e. the variables 'x', 'y' and the response. The generated data structure types are then transmitted to the controller <NUM>.

At steps <NUM>, the controller <NUM> generates one or more variables based on the obtained data structure types. The one or more variables are associated with one or more function blocks of the controller. The variables are associated with the request and response of the microservice and used in the logic statements used in the function blocks defined for the control application within the controller. For example, based on the API definition <NUM> and the corresponding data structure types <NUM>, the controller <NUM> creates three variables of the type 'number' or an equivalent data format in the controller memory. The first two variables correspond to 'x' and 'y' variables as specified in the API definition <NUM>. These two variables may be associated with one or more outputs from one or more function blocks executed in the controller. The first two variables are subsequently used to invoke the microservice <NUM>. Similarly, the third variable corresponds to the response received from the microservice <NUM>.

At step <NUM>, the controller <NUM> invokes the microservice <NUM> by transmitting data (shown in the figure as serialized binary data <NUM>) associated with the one or more variables to the microservice <NUM> via a proxy component <NUM>. The controller <NUM> transmits the data associated with the one or more variables in a serialized binary format to the proxy component <NUM>. Continuing the above example, the controller transmits the first two variables (i.e. 'x' and 'y') to the microservice <NUM> (via the proxy component <NUM> as explained below) for the performing the arithmetic operation. However, since the microservice <NUM> is not configured to receive serialized binary data, the controller <NUM> transmits the serialized data to the proxy component <NUM>.

The proxy component <NUM> is configured to translate the data from the serialized binary format to a first serialization format and transmit the data in the first serialization format (shown in the figure as first serialization data <NUM>) to the microservice <NUM>. In an example, the proxy component <NUM> is configured to receive the data structure types <NUM> from the data structure generation module <NUM> prior to the translation of the data from the serialized binary format. Accordingly, based on the received one or more data structure types <NUM>, the proxy component <NUM> translates the data from the serialized binary format to the first serialization format. In an example first serialization format is a JSON format.

In an example, the method <NUM> further comprises receiving a response from the microservice via the proxy component, wherein the proxy component is configured to translate the response from the first serialization format to the serialized binary format and transmit the response in serialized binary format to the controller. Accordingly, subsequent of the invocation of the microservice <NUM> based on the received data of the variables, the microservice <NUM> performs the arithmetic operation on the data of the variables and sends the resultant of the operation as the response in the first serialization format, which is then translated to the serialized binary data by the proxy component <NUM> which then transmits the same to the controller <NUM>.

In an example, the data associated with the one or more variables includes a data identifier, wherein the data identifier is for mapping the data to a corresponding response from the microservice. For example, the proxy component <NUM> includes a mapping table includes a entries of data (also referred to as requests) from controller <NUM> against the corresponding data identifier. The microservice sends the response with the corresponding data identifier to the proxy component <NUM> and accordingly, based on the data identifier the proxy component I able to map the response to the data from the controller.

While the data structure generation module <NUM> and the proxy component <NUM> are illustrated as independent components, they may be combined with either the microservice or the controller or a single device which includes both the data structure generation module <NUM> and the proxy component <NUM>. For example, the proxy component <NUM> is embedded in the controller <NUM>.

In another aspect, the current disclosure describes an example controller <NUM> configured to communicate with a microservice <NUM> in an industrial facility. The controller <NUM> comprises a network interface <NUM> connected to the microservice <NUM> via the proxy component <NUM>, for transmitting data and receiving responses from the microservice <NUM> and one or more processors <NUM> connected to a memory module <NUM>. The memory module <NUM> (also referred to as non-transitory storage medium <NUM>) includes a plurality of instructions <NUM> which when executed on the one or more processors <NUM>, causes the one or more processors <NUM> to obtain one or more data structure types, wherein the one or more data structure types are generated based on an API definition associated with the microservice, generate one or more variables based on the obtained data structure types, wherein the one or more variables are associated with one or more function blocks of the controller, and transmit data associated with the one or more variables to the microservice via a proxy component, wherein the controller transmits the data associated with the one or more variables in a serialized binary format to the proxy component, and wherein the proxy component is configured to translate the data from the serialized binary format to a first serialization format and transmit the data in the first serialization format to the microservice.

For the purpose of this description, a computer-usable or computer-readable non-transitory storage medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation mediums in and of themselves as signal carriers are not included in the definition of physical computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, random access memory (RAM), a read only memory (ROM), a rigid magnetic disk and optical disk such as compact disk read-only memory (CD-ROM), compact disk read/write, and DVD. Both processing units and program code for implementing each aspect of the technology can be centralized or distributed (or a combination thereof) as known to those skilled in the art.

Claim 1:
A method (<NUM>) of communicating with a microservice (<NUM>) in an industrial facility, the method (<NUM>), by a controller (<NUM>), comprising:
a. Obtaining (<NUM>) one or more data structure types (<NUM>), wherein the one or more data structure types (<NUM>) are generated based on an API definition (<NUM>) associated with the microservice (<NUM>);
b. generating (<NUM>) one or more variables based on the obtained data structure types (<NUM>), wherein the one or more variables are associated with one or more function blocks of the controller (<NUM>); and
c. transmitting (<NUM>) data associated with the one or more variables to the microservice (<NUM>) via a proxy component (<NUM>), wherein the controller (<NUM>) transmits the data associated with the one or more variables in a serialized binary format to the proxy component (<NUM>), and wherein the proxy component (<NUM>) is configured to translate the data from the serialized binary format to a first serialization format and transmit the data in the first serialization format to the microservice (<NUM>)
wherein the proxy component (<NUM>) translates the data from the serialized binary format to a first serialization format, based on the one or more data structure types (<NUM>).