Communication interface architecture for providing data from a data source to a data sink

Abstract

The invention relates to a communication interface architecture for providing data from a data source to a data sink. A data source interface is configured to access data from one or more data sources and provide requested data to a data sink. A data sink interface is configured to communicate with the data source interface to request data from the one or more data sources for provision to the data sink, wherein the data source interface and / or the data sink interface are configured to provide a data exchange architecture independent of a communication protocol and extended by a remote procedure call protocol.

Description

Technical Field

[0001] This invention relates to a communication interface architecture, method, and computer program product for providing data from a data source to a data receiver. Furthermore, this invention relates to a distributed computing system utilizing a communication interface architecture and a data exchange method utilizing a communication interface architecture. Background Technology

[0002] In modern software design, microservices play a crucial role in enabling the easy and efficient exchange of components, functions, and services, and also allowing the distribution of computational tasks across multiple computers without centralized control. However, leveraging microservices increases the communication load between distributed computers. Therefore, it would be advantageous to provide a communication interface that improves data communication and is highly adaptable. Summary of the Invention

[0003] The decoupling of components and layers in data communication architecture is particularly relevant in modular systems that undergo frequent changes. For example, sub-components are loosely coupled only to other sub-components within the architecture to allow for interchangeability without affecting other components. This is especially important in modern software design, where microservices play a crucial role in facilitating distributed computing. It is particularly important in modern production applications, especially in chemical production, where data sources and services are distributed across multiple computer systems, and production data must be frequently exchanged and utilized in other parts of production. In such applications, it is advantageous to decouple the corresponding data services from the corresponding upper layers of the system (e.g., enterprise resource planning layer, manufacturing execution system layer, etc.).

[0004] Since the present invention provides a communication interface architecture that provides a data exchange architecture that is independent of the communication protocol and extended by the remote procedure call protocol between the data source interface and the data receiver interface, it provides an adaptable communication interface that can be adapted to modern software architectures, especially for the use of microservices and distributed computing.

[0005] In a first aspect of the invention, a communication interface architecture for providing data from a data source to a data receiver is provided, wherein the architecture includes a) a data source interface configured to access data from one or more data sources and provide requested data to a data receiver, and b) a data receiver interface configured to communicate with the data source interface to request data from the one or more data sources to provide to the data receiver, wherein the data source interface and / or the data receiver interface are configured to provide a data exchange architecture independent of communication protocols and extended by remote procedure call protocols.

[0006] The communication interface architecture serves as a service layer between the data source and the data receiver, and can be a data source interface, a data receiver interface, or a combination of both. The communication interface architecture provides the rules, protocols, and structures for data exchange between the data source and the data receiver. The participants in the data exchange (i.e., the data source and the data receiver) are defined by different address spaces. Therefore, the data source and the data receiver can refer to different computer systems or the same system including different address spaces. Preferably, the communication interface architecture is configured to control data exchange in a chemical production system. For example, the communication interface architecture can be part of a computational framework for processing plant process data acquired regarding the production processes of an industrial plant, where the plant process data is provided on one or more data sources and processed on one or more data receivers.

[0007] A data source can refer to any computing system or part of a computing system that can provide data. For example, a data source can refer to a database, historical database, sensor, etc. A data receiver can refer to any computing system that uses the data for further processing. For example, a data receiver can be an application, service, process, etc., that utilizes the relevant data. In some cases, a computing system can be a data source for one application but a data receiver for another. Therefore, the terms "data source" and "data receiver" relate to specific functions during data exchange performed by the computing system and can vary depending on the respective application.

[0008] The data exchange architecture between the data source interface and the data receiver interface used for data exchange can be any architecture independent of the communication protocol, and is therefore configured to utilize a communication protocol with a semantic layer different from the data exchange architecture. A communication protocol-independent data exchange architecture refers to a class of data exchange architectures that are independent of the communication protocol. Remote Procedure Call (RPC) protocols define inter-procedure communication that enables the execution of a procedure (e.g., a subroutine or service) in an address space different from the procedure utilizing the RPC protocol. A different address space can refer to, for example, another part of a computer or another physically different computing system. Furthermore, an advantage of RPC protocols is that they can be used as if they were local procedure calls calling procedures in the same address space. Therefore, the specific details of remote interaction during the call process are not required, making the use and implementation of RPC protocols easy and direct.

[0009] Preferably, the data exchange architecture includes a protocol layer independent of the semantic layer, wherein the semantic layer defines the data model, and the protocol layer defines communication using the data model that utilizes the semantic model. This independence between the protocol layer and the semantic layer allows for communication protocol independence of the data exchange architecture. The semantic layer of the data exchange architecture defines the data model of the data exchange architecture. The data model is an abstract model that organizes relationships between data and entities and / or relationships between data. Preferably, the data model defines the relationships between data and characteristics of real-world entities; however, entities can also be more abstract. In particular, the data model can define data structures, data formats, or data symbols. Protocol binding connects the protocol layer to the semantic layer and defines the use of the data model in communication utilizing the data exchange architecture. Preferably, the data exchange architecture is the OPC Unified Architecture (OPC UA). OPC UA is a cross-platform, open-source IEC 62541 data exchange standard that is independent of the communication protocol. The remote procedure call protocol that extends the data exchange architecture is preferably gRPC or SOAP. gRPC is a free, cross-platform, open-source, high-performance remote procedure call framework that utilizes a protocol buffer as an interface description language. SOAP is a message passing protocol specification that uses XML information sets as the message format to exchange structured data. Preferably, the remote procedure call is gRPC. Therefore, it is preferable that the extended data exchange architecture is an OPC UA architecture extended from the gRPC protocol.

[0010] In an embodiment, the extended data exchange architecture includes a data encoding system for converting the data model of the data exchange architecture into a corresponding data encoding system for a remote procedure call protocol. Converting the data model of the data exchange architecture into a corresponding data encoding system for the extended remote procedure call protocol allows the utilization of the data model of the data exchange architecture within the remote procedure call protocol. In a preferred example, the extended data exchange architecture is OPC UA, and a Protocol Buffer Interface Description Language interface is used to convert the information model of OPC UA into a corresponding protocol buffer, wherein the information model of OPC UA is the data model of OPC UA. The corresponding protocol buffer can then be used for data communication, and allows the use of the information model of OPC UA by leveraging the protocol buffer of gRPC. Preferably, the converted data model is predetermined, such that the most commonly used data models are converted. In particular, not all data models need to be converted to provide useful additional functionality for data communication within the extended data exchange architecture.

[0011] In an embodiment, the extended data exchange architecture includes a translator that translates the data model of the data exchange architecture into a corresponding data encoding system of a remote procedure call protocol. A translator, also known as a conversion compiler, is more often a conversion protocol that translates source code written in one programming language into equivalent source code in another programming language. Therefore, the translator performs conversions between programming languages ​​that operate at roughly the same level of abstraction. In this embodiment, the translator is configured to translate the data model of the data exchange architecture into a corresponding data encoding system of a remote procedure call protocol. Therefore, using the translator, a user can easily leverage the data model of the data exchange architecture and implement the data model in the corresponding remote procedure call protocol by translating the data model. For example, if the data exchange architecture is OPC UA, the extended OPC UA may include a translator for translating an OPC UA NodeSet file referencing the information model of the OPC UA into a protocol buffer interface description language.

[0012] In this embodiment, the data source interface is configured to provide at least two ports for access by the data receiver interface, wherein at least one port is configured to use a Data Exchange Architecture (DAO) data transfer protocol, and at least one other port is configured to communicate using a Remote Procedure Call (RPC) data transfer protocol. For example, at least one port may be configured to use the OPCUA data transfer protocol, and at least one other port may be configured to use a Protocol Buffer Transfer (PBR) protocol for data communication. In this way, the data source interface allows the use of both common DAO data transfer protocols and new data transfer protocols extended by DAO. This implementation improves the compatibility of the communication interface architecture.

[0013] In an embodiment, the extended data exchange architecture includes a data encoding system that converts each data model of the data exchange architecture into a corresponding data encoding system for the remote procedure call protocol. With each data model of the data exchange architecture provided, a corresponding data encoding system for conversion to the remote procedure call protocol is provided, allowing the remote procedure call protocol to be considered fully implemented in the data exchange architecture, so that all the functionality provided by the data exchange architecture can also be used in the extended data exchange architecture. For example, in this case, the extended OPC UA includes a protocol buffer for each information model of the OPC UA based on a protocol buffer interface description language.

[0014] In another aspect of the invention, a distributed computing system is proposed, which includes multiple computers, each of which includes the communication interface architecture described above.

[0015] In another aspect of the invention, a communication interface method for providing data from a data source to a data receiver is proposed, wherein the method includes a) providing a data source interface configured to access data from one or more data sources and provide requested data to a data receiver, and b) providing a data receiver interface that allows a data receiver to communicate with the data source interface to request data from the one or more data sources, wherein the data source interface is configured to provide a data exchange architecture independent of communication protocols and extended by a remote procedure call protocol.

[0016] In another aspect of the invention, a data exchange method is proposed for transmitting data between a data source and a data receiver using the communication interface architecture described above, wherein the method includes requesting and receiving data from the data source at the data receiver based on the extended data exchange architecture.

[0017] In another aspect of the invention, a computer program product for providing data from a data source to a data receiver is provided, wherein the computer program product causes the communication interface architecture described above to perform the method described above.

[0018] It should be understood that the methods, apparatus and computer program products described above have similar and / or identical preferred embodiments, particularly as defined in the dependent claims.

[0019] It should be understood that the preferred embodiments of the present invention may also be any combination of the dependent claims or the above embodiments and the corresponding independent claims.

[0020] These and other aspects of the invention will become apparent and will be illustrated with reference to the embodiments described below. Attached Figure Description

[0021] In the attached diagram:

[0022] Figure 1 A distributed computing system including a communication interface architecture is illustrated schematically and exemplary.

[0023] Figure 2 and Figure 3 An implementation of the communication interface architecture is illustrated schematically and exemplary, and

[0024] Figure 4 A computer framework for processing plant process data using a communication interface architecture is illustrated schematically and exemplary. Detailed Implementation

[0025] Figure 1A distributed computing system 100 is illustrated schematically and exemplary, comprising two computers 120 and 130 in this embodiment. In this example, computer 120 refers to a data source configured to control and access data stored in database 121. Although data source 120 is described as a computer in this example, it could also be another device, such as a sensor, a historical database, etc. Computer 130 is an example of a data receiver running a process 131 based on the data stored in database 121. Therefore, computer 130 must access the data stored in database 121, which is controlled by computer 120 as the data source. Thus, data for process 131 must be transferred from computer 120 as the data source to computer 130 as the data receiver. Distributed computing system 100 utilizes communication interface architecture 110 for this data transfer.

[0026] The communication interface architecture 110 includes a data source interface 111, provided by computer 120, acting as a data source, and a data receiver interface 113, provided by computer 130, acting as a data receiver. The data source interface 111 is configured to access data from database 121, for example, using a corresponding control mechanism provided by the computer 120 acting as the data source. Therefore, the data source interface 111 is configured to provide requested data to the data receiver. The data receiver interface 113 is configured to request corresponding data from the data source via the data source interface 111. Data exchange is then performed using an extended data exchange architecture 112. The extended data exchange architecture 112 refers to a data exchange architecture that is independent of communication protocols and has been extended using a remote procedure call (RPC) protocol. Extending a communication protocol-independent data exchange architecture using a RPC protocol allows for the use of more efficient communication protocols and RPC services, as well as commonly used data exchange architectures. This provides the advantage that distributed computing systems can utilize efficient, communication protocol-independent data exchange architectures, while also enabling modern microservice solutions.

[0027] The following section describes in more detail possible implementations of an extended data exchange architecture for an OPC UA extended via the gRPC protocol. However, other combinations of data exchange architectures and remote procedure call protocols independent of the communication protocol are also possible and can be implemented based on the following examples. For instance, an OPC UA extended via SOAP can also be advantageous.

[0028] The communication interface architecture, including the Extended Data Exchange Architecture (which extends OPC UA via gRPC), enables communication with industrial automation systems and historical databases based on a microservices architecture. Furthermore, it simplifies the implementation of this communication and thus improves adoptability by significantly enhancing developer friendliness. The Extended Data Exchange Architecture can be implemented using various embodiments described in more detail below; for example, it can reuse traditional protocol data models based on transpilers or manual conversion, and remote process protocols can be implemented at the protocol layer or fully integrated into standards. The potential synergies between OPC UA and gRPC can be further subdivided into several embodiments that offer different advantages and improvements.

[0029] In this embodiment, the OPC UA information model referencing the OPC UA data model is reused within gRPC. In this embodiment, the Protocol Buffer Information Description Language (IDL) version of the standard OPC UA information model is converted and stored as part of the architecture, and therefore usable in the gRPC environment. Furthermore, to enable custom data model extensions to also be used in the gRPC environment, a transpiler can be provided. The transpiler is configured to convert OPC UANodeSet files into Protocol Buffer IDL. In this embodiment, OPC UA compatibility with gRPC at the connection or transport layers is not required. In practice, this affects the availability of the OPC UA information model to all gRPC-supported programming languages, meaning the OPC UA model becomes a first-class object for these languages. This allows for easier implementation of vendor-independent systems and the derivation of data models based on common underlying standards.

[0030] In another embodiment, gRPC can be integrated into OPC UA as part of the protocol layer. In this embodiment, OPC UA supports protocol buffers as a transport protocol. However, custom data models cannot be used in this embodiment. In this embodiment, the OPC UA data source interface can utilize TCP / IP to provide gRPC endpoints. This allows easy connection to all gRPC-supported programming languages ​​using automatically generated clients. However, this does not necessarily mean that the OPC UA information model can be used as a native object in all gRPC-supported programming languages. This means that handling OPC UA data remains complex for developers. Therefore, this embodiment can be combined with the embodiments described above that reuse the corresponding information model to improve developer friendliness. For example, a set of standard, generic protocol buffer definitions can be provided that can be used to connect to any OPC UA server. Furthermore, OPC UA NodeSet files can be translated into protocol buffer IDL, where the OPC UA NodeSet files describe server-specific data models. In this case, potentially generic objects can be replaced with custom objects.

[0031] Figure 2 An example implementation of this embodiment is illustrated. In this example, the data source interface is part of an OPC UA server. In this example, the communication interface architecture provides at least two data communication ports as part of the data source interface. At least one data communication port (e.g., port 4840) is configured to receive communication using the standard OPC UA binary communication protocol, and at least one other port (e.g., port 4841) is configured to receive communication using the protocol buffer protocol of extended OPC UA. The data receiver (described herein as a client) can then choose which port to connect to. Data received by the OPC UA binary protocol can be directly converted as part of the extended OPC UA architecture. Optionally, the extended OPC UA architecture can be configured to provide minimized generic calls, such as for discovering nodes and reading / writing node values. In this optional embodiment, the OPC UA binary data is embedded in a gRPC object to be processed by the extended OPC UA architecture. This optional embodiment allows for simplified implementation and can also be utilized if not all OPC UA data models are converted to gRPC.

[0032] In another embodiment, gRPC can be fully integrated into the OPC UA standard at the SDK level, or even OPC UA can be reimplemented on top of gRPC. In this case, the standard information model and custom gRPC extensions are integrated into the OPC UA standard, or the OPC UA becomes the standard implemented on top of gRPC. An example of this implementation is Apache Arrow Flight, the successor to ODBC, implemented on top of gRPC. This embodiment allows most of the OPC UA server and client implementation code (stubs) to be automatically generated using all programming languages ​​supported by gRPC.

[0033] Figure 3 An example implementation of this embodiment is shown. In this example, the OPC UA specification is extended so that all defined data models are modeled solely based on the Protocol Buffer IDL. The gRPC extension then coexists with the standard OPC UA data model and encoding to allow compliance with existing OPC UA servers and to allow corresponding communication with traditional data receivers / sources. Conflicts between the gRPC extension and deprecated OPC UA extensions can be resolved by providing custom transformations on a case-by-case basis. Extending OPC UA can only be implemented by newly implementing the extended data exchange architecture on the corresponding data source / sink.

[0034] OPC UA is the preferred protocol when interfaced with automation layers in industrial applications. In most industrial use cases, containerized microservice workloads (e.g., models and other middleware) in the backend are processing data provided by OPC UA data sources, meaning that OPC UA data must flow between microservices. This flow is significantly simplified by the embodiment described above, in which at least some OPC UA data models can be directly used as gRPC protocol buffers, and are therefore the first type of object within various programming languages.

[0035] Figure 4 An example of the corresponding application environment is shown in the figure. Figure 4A communication interface architecture as part of a computing framework 400 is illustrated schematically and exemplarily, which processes factory process data 412 acquired regarding the production process of an industrial plant, including a factory control system 410. Generally, an industrial plant can refer to any technological infrastructure used for industrial purposes. An industrial purpose can be the manufacture or processing of one or more industrial products; that is, the manufacturing or processing processes performed by the industrial plant. For example, an industrial purpose can refer to the production of industrial products. For example, the industrial product can be any physical product, such as chemicals, biological products, pharmaceuticals, food, beverages, textiles, metals, plastics, or semiconductors. Alternatively or alternatively, the industrial product can even be a service product, such as electricity, heating, air conditioning, waste treatment (e.g., recycling), chemical treatment (e.g., decomposition or dissolution), or even incineration. Therefore, an industrial plant can be one or more of a chemical plant, processing plant, pharmaceutical plant, fossil fuel processing facility (e.g., oil and / or gas wells), refinery, petrochemical plant, cracking plant, etc. An industrial plant can even be any of a brewery, incinerator, or power plant. Furthermore, an industrial plant can even be a combination of any of the examples given above.

[0036] To execute production processes, industrial plants include technical infrastructure that can be controlled by control parameters, which can be considered as part of plant control data implemented by process control systems into the technical infrastructure used to control the industrial plant. Technical infrastructure can include any one or more of equipment or process units, such as heat exchangers, towers like fractionation columns, furnaces, reaction chambers, cracking units, storage tanks, settlers, pipes, chimneys, filters, valves, actuators, transformers, circuit breakers, machinery (e.g., heavy rotating equipment such as turbines), generators, crushers, compressors, fans, pumps, motors, etc. Each of this technical infrastructure can provide monitoring data to monitor its operation. Furthermore, industrial plants typically include multiple sensors that allow the measurement of operating parameters of the technical infrastructure. Operating parameters measured by sensors can relate to a variety of process parameters and / or parameters related to the equipment or process unit. For example, sensors can be used to measure process parameters such as flow rate inside pipes, liquid level in tanks, furnace temperature, chemical composition of gases, etc., and some sensors can be used to measure turbine vibration, fan speed, valve operation, pipe corrosion, voltage across transformers, etc. Both functional parameters and operational parameters can be considered as part of the factory process data 412 acquired regarding the production process of an industrial plant. The factory process data 412 can typically be part of the factory control system 410, for example, it can be acquired and / or stored by the factory control system 410. Furthermore, the factory control system 410 can also be adapted to further process the factory process data 412, for example, to monitor, analyze, and / or optimize the factory process data 412. However, in many applications, the factory control system 410 is not configured to provide up-to-date in-depth analysis and possible optimization of the factory process data 412, and in many cases even refers to a conventional system that does not provide the technical hard and / or software infrastructure for up-to-date data analysis of the factory process data 412. Therefore, the factory process data is transmitted to a processing system that allows for up-to-date processing of the factory process data 412. Thus, in this example, the factory control system is considered as a data source for providing data to a data receiver for further processing.

[0037] The computing framework 400 includes an edge computing device 420. The edge computing device 420, acting as a data receiver communicatively coupled to the data source interface 411 of the plant control system 410, can also be considered part of the computing framework 400. Specifically, the edge computing device 420 includes a data receiver interface computing unit 425, which, together with the data source interface 411, provides a communication interface architecture with the extended data exchange architecture described above, for controlling communication between the edge computing device 420 and the plant control system 410. Preferably, the data receiver interface 425 is adapted to receive plant process data 412 from the data source interface 411 via communication coupling using the extended data exchange architecture, as described in more detail above.

[0038] Furthermore, the data receiver interface 425 can be communicatively coupled to the data source interface 411 via a protocol converter 430. Preferably, the protocol converter 430 is configured to isolate and tunnel the plant process data 412 from the data source interface 411 to the data receiver interface 425. This allows the plant process data 412 to be securely and efficiently transmitted from the plant control system 410 to the edge computing device 420. Additionally, the protocol converter 430 is generally adaptable to convert the plant process data 412 from a data format used by the plant control system 410 to a data format used by the edge computing device 420, particularly the interface computing unit 425 of the edge computing device 420. If the plant control system 410 refers to a conventional system utilizing conventional data formats, it is preferable that the protocol converter 430 is adapted at the data source interface 411 to convert the plant process data 412 provided in a conventional data format to a modern data format that can be utilized by the data receiver interface 425. An example of a conventional data format to modern data format conversion is the OPC DA data format still used by many plant control systems. In this case, preferably, the protocol converter 430 includes an OPC DA to UA converter that allows conversion of OPC DA data to OPC UA data format. However, if the plant control system 410 provides plant process data 412 in the same data format utilized by the data receiver interface 425, the protocol converter 430 may refer to a transparent communication unit that does not provide any conversion of the plant process data 412 but only provides isolation of the plant process data 412 and tunnels its transmission between the data source interface 411 and the data receiver interface 425. Typically, the protocol converter 430 may be provided as part of the data source interface 411, as part of the data receiver interface 425, or as part of both the data source interface 411 and the data receiver interface 425, such as... Figure 4 The schematic portion of the protocol converters 431, 432 provided at each end of the communication coupling is indicated in the diagram.

[0039] Edge computing device 420 further includes a container computing unit 421 configured to provide a container runtime environment 422, on which process containers 423 are provided. The container computing unit 421 may be, for example, part of the operating system of the edge computing device 420, or, depending on the operating system running on the edge computing device 420, may provide a virtual operating system different from the general operating system of the edge computing device 420. For example, if the edge computing device 420 typically provides a Windows operating system, the container computing unit 421 may be configured to run a virtual Linux environment operating system, since most container runtime environments 422 are provided as Linux-based runtime environments. The container runtime environment 422 is then adapted to provide process containers 423, including a processor running within the process containers 423. The processor is adapted to process factory process data 412 acquired regarding the production process of an industrial plant. For example, the processor may be adapted to analyze the factory process data 412 and, based on the analysis, provide optimized process control data that allows for optimized control of the industrial plant.

[0040] Optionally, the edge computing device 420 further includes an abstract container 424 running on a container runtime environment 422, wherein the abstract container 424 includes an abstract program. The abstract program can be provided to preprocess the factory process data 412 before it is provided to the process container 423, which includes a processor. For example, if the interface computing unit 425 provides the factory process data 412 in a format that cannot be processed by the processor, the abstract program can be adapted to preprocess the factory process data 412 so that it can be processed by the processor. Depending on the appropriate configuration and interaction between the interface server 411 and the interface computing unit 425 regarding the provision and receipt of the factory process data 412, such preprocessing may include filtering the factory process data 412, performing unit transformations on parameters that are part of the factory process data 412, rearranging the factory process data 412, selecting the factory process data 412, etc. In a preferred embodiment, the processor running on the process container 423 is adapted to provide factory control data to the factory control system 410 to be implemented based on the analysis of the factory process data 412. Then, the process container 423, running on the container runtime environment 422 of the container computing unit 421, is adapted to provide factory control data to the interface computing unit 425. The interface computing unit 425 can then, preferably via a protocol converter 430, provide the factory control data to the interface server 411 of the factory control system 410. In this case, the protocol converter 430 can be adapted to convert the factory control data from a data format used at the interface computing unit 425 to a data format used at the interface server 411, particularly by the factory control system 410. The factory control system 410 can then implement the received factory control data to control the industrial plant.

[0041] In a preferred embodiment, the containerized program running in the container runtime environment 422 is deployed via a continuous integration and continuous delivery (CI / CD) workflow. This workflow is instructed by workflow systems 440 to 442. Specifically, the CI / CD workflow is based on a control system and container registry 440, provided, for example, on a cloud-based external server. For example, the control system may be adapted to deploy and manage all versions of processors and / or abstractions, for example, by checking the availability of updated versions of the processors and then by providing updates to the container runtime environment 422, for example, by replacing the currently running processor with the updated version of the processor. Furthermore, a container registry may be provided to provide an overview of all currently utilized containerized programs, which registers all containerized programs running on edge computing devices in multiple industrial plants, respectively. Optionally, the CI / CD workflow may further include software and / or hardware 442 adapted to continuously receive and monitor the outputs and inputs to the processors, for example, plant process data 412 as input and plant control data as output. This external software / hardware 442 may then be adapted to analyze and monitor the operation of the processors, for example, using an artificial intelligence system. Based on this monitoring and analysis, software / hardware 441 can be provided, which continuously improves the processing program and, for example, provides an updated version of the processing program to the control system 440.

[0042] By studying the accompanying drawings, this disclosure, and the appended claims, those skilled in the art can understand and implement other variations of the disclosed embodiments when practicing the claimed invention.

[0043] The operations performed in the processes and methods disclosed herein may be implemented in different orders. Furthermore, the operations outlined are provided as examples only, and some of these operations may be optional, may be combined into fewer steps and operations, may be supplemented with more operations, or may be expanded into more operations without departing from the essence of the disclosed embodiments.

[0044] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a / an" does not exclude multiple / types.

[0045] A single unit or device can perform the functions of several items listed in the claims. The fact that certain measures are listed in different dependent claims does not indicate that combinations of these measures cannot be used advantageously.

[0046] A computational process performed by one or more units or devices can be performed by any other number of units or devices. These processes can be implemented as program code devices and / or dedicated hardware for computer programs.

[0047] Computer program products can be stored / distributed on suitable media, such as optical or solid-state storage media provided with or as part of other hardware, but can also be distributed in other forms, such as via the Internet or other wired or wireless telecommunications systems.

[0048] Any unit described herein can be a processing unit as part of a classical computing system. Processing units can include general-purpose processors and can also include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or any other special-purpose circuitry. Any memory can be physical system memory, which can be volatile, non-volatile, or some combination of both. The term "memory" can include any computer-readable storage medium, such as a non-volatile mass storage device. If the computing system is distributed, the processing and / or storage capabilities can also be distributed. A computing system can include multiple structures as "executable components." The term "executable component" is a structure that is well understood in the computing field to be software, hardware, or a combination thereof. For example, when implemented as software, those skilled in the art will understand that the structure of an executable component can include software objects, routines, methods, etc., that can be executed on the computing system. This can include executable components in the computing system heap or on a computer-readable storage medium. The structure of an executable component can exist on a computer-readable medium such that, when interpreted by one or more processors of the computing system (e.g., by processor threads), it causes the computing system to perform functions. This structure can be directly read by a processor, for example, if the executable is binary, or it can be constructed to be interpretable and / or compileable, for example, whether in a single stage or multiple stages, thereby generating such binary that can be directly interpreted by the processor. In other cases, the structure can be hard-coded or hard-wired logic gates, implemented specifically or almost specifically in hardware, such as within a field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or any other dedicated circuit. Thus, the term "executable" is a term for a structure well-known to those skilled in the art of computing, whether implemented in software, hardware, or a combination thereof. Any embodiments herein are described with reference to actions performed by one or more processing units of a computing system. If such actions are implemented in software, one or more processors direct the operation of the computing system in response to the execution of computer-executable instructions constituting the executable. The computing system may also include communication channels that allow the computing system to communicate with other computing systems via, for example, a network. A "network" is defined as one or more data links that enable the transfer of electronic data between computing systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computing system via a network or another communication connection (e.g., hardwired, wireless, or a combination of hardwired and wireless), the computing system correctly treats that connection as a transmission medium. The transmission medium may include a network and / or a data link, which may be used to carry desired program code in the form of computer-executable instructions or data structures, and may be accessed by a general-purpose computing system or a special-purpose computing system or a combination thereof.While not all computing systems require a user interface, in some embodiments, the computing system includes a user interface system for interaction with a user. The user interface, for example, acts as an input or output mechanism for the user via a display.

[0049] Those skilled in the art will understand that at least a portion of the present invention can be practiced in network computing environments with a variety of computing system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, pagers, routers, switches, data centers, wearable devices (such as glasses), etc. The present invention can also be practiced in distributed system environments, where, for example, local and remote computing systems linked by a network via hardwired data links, wireless data links, or a combination of hardwired and wireless data links jointly perform tasks. In a distributed system environment, program modules can reside on both local and remote memory storage devices.

[0050] Those skilled in the art will also understand that at least a portion of the present invention can be practiced in a cloud computing environment. A cloud computing environment can be distributed, but this is not required. When a cloud computing environment is distributed, it can be spread across multiple countries within an organization and / or have components across multiple organizations. In this specification and the appended claims, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources, such as networks, servers, storage devices, applications, and services. The definition of “cloud computing” is not limited to any of the many other advantages that can be obtained from such a model when deployed. The computing system of the accompanying drawings includes various components or functional blocks that can implement the various embodiments disclosed herein as explained. These various components or functional blocks can be implemented on a local computing system or on a distributed computing system that includes elements residing in the cloud or aspects implementing cloud computing. These various components or functional blocks can be implemented as software, hardware, or a combination of software and hardware. The computing system shown in the figures may include more or fewer components than those shown in the figures, and some of these components may be combined as needed.

[0051] Any reference numerals in the claims should not be construed as limiting the scope.

[0052] This invention relates to a communication interface architecture for providing data from a data source to a data receiver. A data source interface is configured to access data from one or more data sources and provide requested data to the data receiver. A data receiver interface is configured to communicate with the data source interface to request data from the one or more data sources to provide to the data receiver, wherein the data source interface and / or the data receiver interface are configured to provide a data exchange architecture independent of communication protocols and extended via remote procedure call protocols.

Claims

1. A communication interface architecture for providing data from a data source to a data receiver, wherein, The architecture includes: A data source interface, configured to access data from one or more data sources and provide the requested data to a data receiver, and A data receiver interface configured to communicate with the data source interface to request data from the one or more data sources to be provided to the data receiver, wherein the data source interface and / or the data receiver interface are configured to provide a data exchange architecture that is independent of the communication protocol and extended by a remote procedure call protocol.

2. The communication interface architecture according to claim 1, wherein, The data exchange architecture includes a protocol layer independent of the semantic layer, wherein the semantic layer defines the data model, and the protocol layer defines communication using the data model that utilizes the semantic model.

3. The communication interface architecture according to any one of claims 1 and 2, wherein, The data exchange architecture is OPC UA.

4. The communication interface architecture according to any one of the preceding claims, wherein, The remote procedure call protocol is either gRPC or SOAP.

5. The communication interface architecture according to any one of the preceding claims, wherein, The extended data exchange architecture includes a data encoding system that converts the data model of the data exchange architecture into the corresponding data encoding system for the remote procedure call protocol.

6. The communication interface architecture according to any one of the preceding claims, wherein, The extended data exchange architecture includes a translator in a data encoding system that translates the data model of the data exchange architecture into the corresponding data encoding system of the remote procedure call protocol.

7. The communication interface architecture according to any one of the preceding claims, wherein, The data source interface is configured to provide at least two ports for the data receiver interface to access, wherein at least one port is configured to use a data exchange architecture data transmission protocol, and at least one other port is configured to communicate using a remote procedure call data transmission protocol.

8. The communication interface architecture according to any one of the preceding claims, wherein, The extended data exchange architecture includes a data encoding system that translates each data model of the data exchange architecture into the corresponding data encoding system for the remote procedure call protocol.

9. A distributed computing system comprising a plurality of computers, the plurality of computers comprising a communication interface architecture according to any one of claims 1 to 8.

10. A communication interface method for providing data from a data source to a data receiver, wherein, The method includes: Provides a data source interface, which is configured to access data from one or more data sources and provide the requested data to the data sink. Provide a data receiver interface that allows a data receiver to communicate with the data source interface to request data from the one or more data sources, wherein the data source interface is configured to provide a data exchange architecture that is independent of the communication protocol and extended by a remote procedure call protocol.

11. A data exchange method for transmitting data between a data source and a data receiver using a communication interface architecture according to any one of claims 1 to 8, wherein, The method includes requesting and receiving data from the data source based on the extended data exchange architecture at the data receiver.

12. A computer program product for providing data from a data source to a data receiver, wherein, The computer program product enables the communication interface architecture according to any one of claims 1 to 8 to perform the method according to claim 11.

Images