System for data transmission between client devices, server devices and multiple automation devices

Abstract

A system (0) for transmitting data between a client device (112), a server device, and a plurality of automation devices (101a, 101b), wherein the server device (100) includes a descriptive representation of each of the plurality of automation devices (101a, 101b), wherein the server device (100) includes a server entity (112) operable to load one of the descriptive representations based on a host name identifying one of the plurality of automation devices (101a, 101b), and wherein the server entity is operable to transmit data from the automation device (101a, 101b) to a client application on the client device (110) based on the loaded descriptive representation of the automation device (101a, 101b).

Description

Technical Field

[0001] The present invention relates to automation technology. Automation technology is a branch of engineering that primarily involves mechanical engineering and electrical engineering. It is generally used to automate technical processes in machines, plants, or technical systems.

[0002] In addition to freeing people from dangerous, strenuous or routine activities, improved quality, higher performance of machines or plants and reduced personnel costs are all motivations for using automation technologies. It is best to reduce human activities to eliminate interruptions, supply materials, remove and maintain prefabricated parts and other similar activities.

[0003] Automation systems are used in a variety of industries, including chemical, pharmaceutical, and wastewater treatment, to oversee the equipment that performs a process that creates or changes something. For example, in oil refining, process control systems oversee the machinery and equipment that converts crude oil into gasoline. Process control systems typically include three groups of electronic equipment: controllers, input / output ("I / O") devices, and automation equipment. Automation equipment transmits information about process activity to the controller via the I / O system, and the controller, in turn, transmits information to other field devices to adjust process activity.

[0004] Furthermore, an automated system involves the physical and organizational structures and facilities used to produce goods, such as products, processes, buildings (or groups of buildings), networks, controllers, interfaces, machines, and assembly lines. Background Art

[0005] PROFINET, Ethernet IP, or Modbus-TCP (Modbus Transmission Control Protocol) are examples of Ethernet-based communication mechanisms. A communication mechanism is typically defined by the associated, often standardized, protocols and the communication relationships they are based on. Communication relationships organize communication between devices (also called users) participating in data transmission within the network. Examples of communication relationships are client / server, master / slave, master / master, producer / consumer, or publisher / subscriber. TCP / IP is often used as the communication protocol for Ethernet-based networks. It is expected that pure Ethernet (Layer 2) communication will replace IP-based communication components. Omitting the IP stack will allow for the production of devices that are more affordable than previous devices with an IP stack. Summary of the Invention

[0006] In the process of digitalization, customers now require remote access to their automation devices, for example, from the cloud. However, this presents a challenge because the devices may no longer have an IP stack. Unlike their predecessors, automation devices without an IP stack are no longer accessible via IP-based and IP-routed networks. Consequently, existing and future Profinet and OPC UA applications must be cost-intensive and time-consuming to expand with Layer 2 communication and, in the meantime, can only be used on local fieldbuses.

[0007] Therefore, a technical solution is needed in which non-IP automation devices are made to look like automation devices with an IP stack.

[0008] Whether or not the respective automation device has an IP stack should ideally be hidden from users (e.g., users of client applications). Instead, users (e.g., via the client) should be able to address all devices via IP. Specifically, in the context of OPC UA, users can then communicate with (non-IP) automation devices via IP, just as they would with other automation devices with OPC UA servers and IP functionality.

[0009] Protocols such as "Network Address Translation (NAT)," "Application Layer Gateway (ALG)," "Proxy," and "Virtual Host" are already known and allow interoperability between network and application protocols. At the network level, so-called "Network Address Translation (NAT)" serves as a universal building block in a wide range of application scenarios. For example, NAT64 is used to connect IPv6 clients to IPv4 devices. See European Patent Application EP 3062490 A1, which describes the automatic and adaptive integration of IPv4 automation devices into IPv6 networks.

[0010] On the other hand, if it is feasible to connect significantly different application protocols to one another using different (transport) communication layers, so-called application layer gateways (ALGs) are often used. Ultimately, multiple separate OPC-UA servers are also used as application layer gateways (ALGs) for accessing various automation devices and / or fieldbuses.

[0011] Among other tasks, proxies (especially web proxies) are used to present a single application server to client applications, thereby providing a single access point ("portal"), even though there are actually multiple application servers behind the proxy (see RFC 7230, "Hypertext Transfer Protocol (HTTP / 1.1): Message Syntax and Routing," Sections 2 and 3, "Intermediaries." Similar to proxies, HTTP itself provides functionality for partitioning an application server into multiple logical application servers in the form of so-called "virtual hosts"—see RFC 7230, "Hypertext Transfer Protocol (HTTP / 1.1): Message Syntax and Routing."

[0012] The present invention provides an improvement and solution to the above situation.

[0013] According to a first aspect, a system for transmitting data between a client device, a server device, and a plurality of automation devices is proposed, wherein the server device comprises a descriptive representation of each of the plurality of automation devices, wherein the server device comprises a server entity operable to load one of the descriptive representations based on a host name identifying one of the plurality of automation devices, wherein the server entity is operable to transmit data from the automation device to a client application on the client device based on the loaded descriptive representation of the automation device.

[0014] According to a second aspect, a server device according to the first aspect is proposed.

[0015] According to a third aspect, a client device according to the first aspect is proposed.

[0016] According to a fourth aspect, an automation device according to the first aspect is proposed.

[0017] According to a fifth aspect, a method for transmitting data between a client device, a server device and one or more automation devices is proposed, wherein the server device includes a descriptive representation of each of the plurality of automation devices, wherein the server device includes a server entity, comprising the following steps: loading, by the server entity, one of the descriptive representations based on a host name, identifying one of the plurality of automation devices, and transmitting data from the automation device to a client application on the client device via the server entity. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 A diagram of an automation system including automation devices and a server is shown.

[0019] Figure 2 A diagram showing a client and a server.

[0020] Figure 3 A diagram of an automation system comprising a client device, a server device and an automation device is shown.

[0021] Figure 4 A diagram of a server capable of loading a descriptive representation of an automation device is shown.

[0022] Figure 5 The method steps of the first embodiment are shown.

[0023] Figure 6 The method steps of the second embodiment are shown.

[0024] Figure 7 The method steps of the third embodiment are shown.

[0025] Figure 8 The method steps of the fourth embodiment are shown.

[0026] Figure 9 The method steps of the sixth embodiment are shown. DETAILED DESCRIPTION

[0027] Figure 1 The diagram shows an automation system 0 comprising automation devices 6, 13, 17, 22 and various web servers 3, 10, 15, 20, 24, which are directly or indirectly connected to one another via the Internet 1. Automation technology is a subfield of plant engineering and engineering, primarily affecting mechanical and electrical engineering. It is typically used to automate technical processes in machines, plants, or technical systems.

[0028] A first web server 3 communicates directly with the Internet 1 via a connection 2. The first web server 3 is connected to an input / output module 6 of the automation system via a connection 5. A second and a third web server 10, 15 are connected to the Internet 1 via connections 9, 14, a firewall 8, and a connection 7. The second web server 10 has a connection 12 to a converter 13. The third web server 15 has a connection 17 to a drive 18. Reference numeral 20 designates a fourth web server, also known as an embedded web server, which is directly connected to the Internet 1 via a connection 19 and is embedded in the control of a valve 22. Figure 1 The fifth web server 24 shown does not have automation functionality and communicates with the Internet via connection 23. A client 26, such as a web browser, is connected to the Internet 1 via connection 25. As shown, the web server can be communicatively coupled to the automation device. To this end, the web server can be embedded in the automation device.

[0029] A website server is a process running on a computer, or distributed across multiple computers, and typically provides information to one or more clients (web browsers on different devices). This information can reside statically on the website server or be dynamically generated by another utility. Therefore, in the embodiment of the fifth website server 24 and client 26, the typical communication partner connected via the Internet 1 is a website server. The fifth website server 24 responds to requests from the client 26 and provides information, typically internet pages, via the Internet 1. The website server can be connected via a TCP / IP stack. Further details on the use of website servers in the field of automation technology are disclosed in, for example, U.S. patent application US2005198137A1.

[0030] Figure 2 An arrangement for interaction between a client and a server is shown. It will be understood that the client and the server can be configured on a single device, but can also be located on separate devices. In an exemplary embodiment, an OPC UA client and an OPC UA server according to the OPC UA specification are shown using a communication system such as a network. In this case, the OPC UA client interacts using OPC UA service calls from a set of OPC UA service calls specified in the OPC UA protocol. The application areas of OPC UA clients and servers are wide-ranging, and their functionality can be implemented in different automation devices and automation systems, such as controllers, PC-based control systems, production management systems, and in production planning.

[0031] Although reference will be made later to OPC UA clients and OPC UA servers and other details of the OPC UA protocol and / or OPC UA standard, this is for exemplary purposes only, and the scope and significance of the present invention is not limited to OPC UA but can also be applied to other protocols and standards.

[0032] OPC UA uses a client-server concept similar to classic OPC. Applications that want to expose their information to other applications are called UA servers, while applications that want to consume information from other applications are called UA clients. However, it is expected that there will be many more UA servers and UA clients in a single application than in classic OPC. One reason for this is that more UA servers will be integrated directly into devices. Implementing a UA client also enables device-to-device communication. Another reason is the use of OPC UA as a configuration interface, where a UA client is also a UA server that is configured via OPC UA.

[0033] A typical OPC UA application consists of the three software layers shown in the figure below. The complete software stack can be implemented in C / C++, .NET, or Java. OPC UA is not limited to these programming languages and development platforms, but currently only these environments are used to implement the OPC Foundation UA stack deliverables.

[0034] The OPC-UA (Web) Server is used for process visualization, monitoring, and control. By using web technology, all process variables are always available, anywhere, and via any standard web browser. The OPC-UA Web Server can be provided as a library that is loaded and executed by the runtime environment. The OPC UA Web Server features an OPC UA client interface for accessing process variables. Visualizations can be created using the HTML5-based OPC-UA Designer and uploaded to the OPC-UA Web Server via the OPC-UA Server interface.

[0035] An OPC UA application is a system that wants to expose or consume data via OPC UA. It consists of the application's specific functionality and the mapping of this functionality to OPC UA using the OPC UA Stack and the OPC UA Software Development Kit (SDK).

[0036] An OPC UA Client or Server SDK implements common OPC UA functionality as part of the application layer, since the UA stack only implements the communication channel. The OPC UA SDK reduces development effort and facilitates faster interoperability of OPC UA applications.

[0037] The Address Space Model in UA Part 3 specifies the building blocks for exposing instance and type information, and thus the OPC UA Metamodel for describing and exposing Information Models and for building the Address Space of an OPC UA Server.

[0038] The abstract UA Services defined in UA Part 4 represent the possible interactions between UA Clients and UA Server applications. Clients use Services to discover and access information provided by Servers.

[0039] To encompass all the successful features of Classic OPC, OPC UA defines information models for the area of process information, building on the basic specifications. The so-called DA (Data Access) information model defines automation-specific extensions, such as the modeling of analog or discrete data and how to demonstrate quality of service. All other DA functionalities are already covered by the basic services. The Alarm Status (AC) information model specifies a high-level model for process alarm management and condition monitoring. The History Access (HA) information model defines mechanisms for accessing historical data and historical events. The Program (Prog) information model specifies mechanisms for starting, operating, and monitoring program execution.

[0040] The Basic Information Model specified in UA Part 5 provides the framework for all information models using OPC UA. It is defined as follows:

[0041] The address space entry points used by clients to browse OPC UA Server entities and types.

[0042] Base types that establish roots for different type hierarchies

[0043] Built-in but extensible types, such as object types and data types

[0044] Server objects that provide functionality and diagnostic information.

[0045] The abstract UA services defined in UA Part 4 represent possible interactions between UA Clients and UA Server applications. Clients use services to discover and access information provided by servers. These services are abstract because they define information to be exchanged between UA applications, rather than a concrete representation on the wire or in an Application Programming Interface (API) used by the applications.

[0046] In order to connect to a server, the client needs information such as network address, protocol and security settings. For this purpose, OPC UA defines a set of discovery characteristics.

[0047] All the information needed to establish a connection between a client and a server is stored in so-called endpoints. A server can provide several endpoints, each containing:

[0048] The Uniform Resource Locator (URL) of the endpoint (protocol and network address)

[0049] Security policy (name and key length of a set of security algorithms)

[0050] Message security mode (security level of exchanged messages)

[0051] User token type (user authentication type supported by the server)

[0052] If multiple OPC UA servers exist, a discovery server can be used to provide information about available servers. Servers can register with the discovery server. Clients can then request a list of all available servers from the discovery server and then use the Get Terminal service to obtain connection information from the server.

[0053] One of the biggest challenges of OPC UA for embedded devices is the memory consumption of the enormous server address space. The standard OPC UA namespace at namespace index 0 already contains 1755 nodes, over 4000 strings, and over 80KB of pure string data. The SDK allows for multiple instances of our address space implementation. A new address space is created for each namespace, and these address spaces together form the complete server address space. The same web service can have multiple endpoints, for example, to make it available to different protocols.

[0054] The TCP / IP stack is a set of network protocols. The Open Systems Interconnection (OSI) model is a standardized way to connect devices together, and most protocols have some direct correlation to the OSI model. The OSI model has seven layers, and the TCP / IP stack, the most common protocol suite in use today, has four. The Internet Protocol layer in the TCP / IP stack is the first layer to introduce the virtual network abstraction that serves as the foundation of the Internet model.

[0055] Today, the OPC UA standard provides for a host communication parameter transmitted by OPC UA clients. According to the text of the OPC UA standard ("OPC UA Part 4 Services"), this parameter is used to ensure that the client signals the host name when communicating with the OPC UA server, thereby determining the server's network interface to which the client should address. Programmable logic controllers (PLCs) can have multiple IP network interfaces, but individual network interfaces are only accessible from certain subnets. Therefore, users must have detailed knowledge of the network topology to successfully address an OPC UA server. For example, when using the so-called GetTerminal service to list the transport endpoints of OPC servers deployed on a host, the addressed host name is contained in the so-called EndpointUrl parameter, which the client uses in its request to the GetTerminal service. Due to the lack of network connectivity, this service uses the host name to filter its responses, transmitting only those endpoint URLs that it can actually reach to the client.

[0056] Furthermore, the Host Communication parameters are used when establishing an OPC UA Server Session using the CreateSession service. In this case, the Client re-enters the Server endpoint it is actually addressing in the form of the EndpointUrl parameter.

[0057] Now go to Figure 3 , shows an automation system 0. The automation system 0 includes a client device 110, a server device 100, and a plurality of automation devices 101a, 101b. Again, reference is made to the OPC UA standard for exemplary purposes, and one or more other standards for operating the automation system 0 can be used.

[0058] According to one embodiment, the OPC UA client 110 interoperates with the OPC UA server 112, for example, where the server 112 is located on a server device such as the PLC 100, as if the server were located on each individual automation device 101a and 101b. The device-specific information model of each automation device 101a, 101b (see Figure 4 123a, 123b in the example) appears as if the corresponding OPC UA server is located directly on the corresponding automation device 101a and 101b itself. Specifically, for each automation device, the client 110 sees (apparently) a separate OPC UA server. Thus, it appears as if each automation device 101a, 101b has its own OPC UA server 112. This means multiple information models for the individual automation devices 101a, 101b, in particular the individual device information models (see Figure 4 123a, 123b) are available. However, the server 112 only provides the information model of one automation device 101a, 101b at a time, for example, by loading one information model at a time and / or loading the information models one after the other. As a result, the OPC UA client 110 does not see an OPC UA server in which all device information models are aggregated (i.e., aggregated at the same time), but rather it appears as if there are multiple separate OPC UA servers 112, each of which provides exactly one device information model 123a or 123b. This eliminates the need for the OPC UA client 110 to know whether it is using information from the automation device 101a, 101b itself or from a "virtual" OPC UA server 112, for example, located on the PLC 100. There is no mixing of information models of different automation devices, as is the case today, for example, in so-called "aggregate" OPC UA servers. Ultimately, currently, for example, PLC-based OPC UA servers are aggregate servers because they provide information about multiple automation devices to OPC UA clients via a single OPC UA server. In this case, it is no longer transparent to the user and therefore no longer transparent to one or more clients, such as OPC UA applications, from which the requested information is actually retrieved. In addition, if the automation system changes, such as replacing or adding automation devices, the URLs of the data points will change accordingly, and the changes in the data point or device URLs must be followed.

[0059] To address this issue, a registration module, such as a Domain Name System (DNS) registration module 120, can be provided on a server device, such as the PLC 100. The DNS registration module 120 can receive the host names of the automation devices 101a, 101b, for which the corresponding OPC UA server 112 needs to be instantiated, from, for example, a local database 102. The DNS registration module 120 can also take the form of a DNS client and can then register the host names of the devices 101a, 101b in a (automation system-specific) DNS server 121 via a DNS update, for example, according to RFC 2136. The allocation and / or registration of the automation device host names can include associating the host names with the server device (e.g., the PLC 100). Optionally, the host names of the devices 101a, 101b can also be dynamically allocated by the scanner 103, for example based on the Dynamic Host Configuration Protocol (DHCP), and can then be stored in the local database 102.

[0060] The OPC UA client 110 can then use an OPC URL containing the DNS name of the OPC UA server 112. According to the OPC UA protocol, for example, a client application on the client device 110 first uses the endpoint service 111 to determine an available server endpoint. At the same time, the client application also transmits the host name of the addressed automation device 101a, 101b. The endpoint service 111 can now compare the received host name not only with the host name assigned to the server device 100 (for example, the PLC 100), but also with the list of host names assigned to the automation devices 101a, 101b in the local database 102. The host name of the automation device is not assigned to the server device 100, for example, the PLC, but to the "virtual" OPC UA server of the automation device 101a, 101b.

[0061] like Figure 4 As shown in more detail in FIG, according to the OPC UA protocol, the client 110 selects one of the appropriate server endpoints and uses it to establish an OPC UA session to the OPC UA server 112. The session is initiated by Figure 4 The host name transmitted during session setup is evaluated by the OPC UA server 122 and only the information models 123a, 123b are loaded in the session corresponding to the automation device 101a, 101b for which the corresponding host name was received.

[0062] Therefore, a DNS registration module 120 is proposed, which allows registering non-IP automation devices 101a, 101b in the Domain Name System (DNS) and assigning the IP address of the OPC UA server to the non-IP input and output (IO) devices 101a, 101b. Figure 3 In the embodiment of FIG. 5 , the client device 110 and the server device 100 are communicatively coupled via a network layer protocol, and the server device 100 and the automation devices 101 a , 101 b are communicatively coupled via a data link layer protocol.

[0063] Thus, a single OPC UA server can act as multiple (virtual) OPC UA servers with the same IP address but different host names, such as different fully qualified domain names (FQDNs). Depending on the host name of the automation device specified, for example, in the session setup, only the corresponding information model is visible in this session and can be accessed via the server entity. This means that it can be said that several virtual OPC UA servers exist simultaneously in a server device, such as PLC 100.

[0064] Therefore, it is advantageous that in the event of a device exchange, for example between a device with an IP stack and a device without an IP stack, the exchange can be invisible to the OPC UA application due to the fact that neither the host name of the automation device (e.g., the FQDN) nor the OPC UA data model of the device changes. This is achieved by adding the host name of the automation device to the DNS server.

[0065] In particular, it is possible to avoid changing existing OPC UA URLs. The proposed architecture hides changes in IP addresses, which includes self-registration and automatic updating of the server device 112, especially the local database 102. Another benefit is that the FQDN of the automation device can be quickly and automatically maintained using the IP address of the associated OPC UA server. Another benefit is that there is no additional load for (cloud) applications to communicate directly with the automation device, for example via a fieldbus. Instead, it can be used, for example Figure 3 A process image 113 is shown on a server device 112 , for example the PLC 100 .

[0066] At least with respect to OPC-UA, non-IP automation devices 101 a , 101 b can now be communicatively coupled to the client 110 in a similar manner to how IP-capable automation devices are coupled to the client 110 .

[0067] Furthermore, only a single IP address is required to communicate with a plurality of automation devices 101a, 101b, namely the IP address of the server device 112. Consequently, the user no longer needs to manage multiple IP addresses.

[0068] Now go to Figure 5, exemplary method steps of an embodiment of a server are shown. In a first step S1, a server or a server entity can load a descriptive representation of an automation device. According to the OPC UA standard, the descriptive representation of the automation device can correspond to an information model. However, other descriptive representations of the automation device are feasible, for example the Electronic Device Description Language (EDDL) according to the International Electrotechnical Commission (IEC) standard IEC 61804. The server entity can be an instance of a website server, or more specifically an instance of an OPC UA website server. It should be noted that the server or server entity can preferably only load one descriptive representation of an automation device at a time. However, multiple descriptive representations are used for loading, wherein each descriptive representation is associated with a corresponding automation device.

[0069] In step S2, the server or server entity can transfer data from the automation device to a client application on the client device. Information about the automation device can then be provided to the client application using a descriptive representation, and corresponding data can be transferred from the server entity to the client application. The descriptive representation of the automation device enables the client application to utilize specific static and dynamic behaviors of the automation device.

[0070] Now go to Figure 6 , shows further exemplary method steps of an embodiment of the server. In step S3, a host name can be assigned to each of the plurality of automation devices. This can be done manually or automatically, such as Figure 3 and 4 As shown, host names can be stored in the local device list.

[0071] In step S4 , a (single) device among the plurality of automation devices is identified based on the host name of the automation device.The specific host name of the automation device can be received from a client application on a client device.

[0072] In step S5, the server entity can then load the descriptive representation of the identified automation device. The loaded descriptive representation can correspond to the identified automation device. That is, a specific descriptive representation is loaded based on the host name of the automation device.

[0073] Now go to Figure 7 , showing other exemplary method steps of an embodiment of the server.

[0074] In step S7, a first automation device from a plurality of automation devices is identified based on a first host name. In a subsequent step S8, the server entity loads a descriptive representation of the identified first automation device. Then, for example, if the server entity receives a second host name, a second automation device from the plurality of automation devices is identified based on the second host name. In a subsequent step S9, the server entity loads a descriptive representation of the identified second automation device. After receiving the second host name, the server entity can be completely deleted and a new instance can be created based on a second descriptive representation of the identified second automation device, or the server entity can be modified to reflect the second descriptive representation loaded by the server entity. In any case, after loading the second descriptive representation of the second automation device, the server entity on the server device can only provide information related to the second automation device.

[0075] Now go to Figure 8 , further exemplary method steps of an embodiment of the server are shown. In step S10, the server device is capable of receiving a host name from a client application on a client device via the server entity. In step S11, the server entity compares the host name obtained from the client application with a plurality of automation device host names, for example, in order to identify a descriptive representation of the automation device. In a subsequent step S12, the server entity is capable of selecting a (single) descriptive representation of the automation device to be loaded by the server entity. It should be understood that the above method steps can be performed by the server entity and / or other (software) modules on the server device that interact with the server entity to provide the functionality. For example, the server entity can interact with a DNS registration module in order to obtain a descriptive representation of the automation device, in particular the OPC UA information model. In the same way, the server entity and / or the DNS registration module can interact with an endpoint service and / or a client application on the client device.

[0076] Now go to Figure 9 , shows other exemplary method steps of an embodiment of the server. In step S13, the name server can be updated with a list of host names associated with the automation devices. Figure 3 The scanner identified by reference numeral 103 in step S14 collects the host name list. The scanner can perform periodic and / or event-driven scanning of one or more networks (e.g., fieldbuses) connected to the server device, for example, to identify newly installed or replaced automation devices. In step S14, the host name list can be collected by a DNS server (e.g., Figure 3 The DNS server) obtains one or more automation device host names to update the host names of the automation devices available in the automation system. Then, Figure 3As shown, the client device can retrieve the updated list of host names, for example, by querying a DNS server, and can use one or more host names, as appropriate, to retrieve data from the automation device. The DNS client and / or DNS server can be part of a name service that assigns host names to automation devices and / or stores the host names and / or makes the host names available to the client application and / or server entity.

Claims

1. A system (0) for data transmission between a client device (112), a server device (100) and a plurality of automation devices (101a, 101b), in, The server device (100) comprises a descriptive representation of each of the plurality of automation devices (101a, 101b), The server device (100) comprises a name service (121), wherein the name service assigns a host name to each of the plurality of automation devices (101a, 101b). wherein the client application on the client device is operated to obtain the host name of one or more automation devices from the name service (121), wherein the server device (100) comprises a server entity (112) operable to load one of the descriptive representations based on a host name identifying one of the plurality of automation devices (101a, 101b), wherein the host name identifying one of the plurality of automation devices (101a, 101b) is selected by the client device (110), wherein the server entity (112) is operable to load only one descriptive representation of the automation device (101a, 101b) at a time, wherein the server entity is operable to transmit data from the automation device (101a, 101b) to a client application on the client device (110) based on the loaded descriptive representation of the automation device (101a, 101b), wherein each of the plurality of descriptive representations available for loading is associated with a corresponding automation device of the plurality of automation devices, The server device (100) comprises an endpoint service (111), wherein the endpoint service (111) of the server device is configured to compare the host names of one or more automation devices obtained from a client application with host names assigned to the server device and with a list of host names of automation devices stored in a local database, and wherein the host names of one or more automation devices are not assigned to the server device.

2. The system (0) according to claim 1, in, The server entity (112) is operable to load a first descriptive representation of the first automation device (101a, 101b) based on a first host name identifying the first automation device (101a, 101b), and Therein, the server entity (112) is operated to load second descriptive representations of the second automation devices (101a, 101b) one at a time based on second host names identifying the second automation devices (101a, 101b).

3. The system (0) according to claim 1 or 2, in, The server entity (112) is an OPC / UA server entity, and / or the client application is an OPC / UA client application, and / or the descriptive representation is an OPC / UA information model.

4. The system (0) according to claim 1 or 2, in, The client device (110) and the server device (100) are communicatively coupled via a network layer protocol, and wherein the server device (100) and the automation device (101a, 101b) are communicatively coupled via a data link layer protocol.

5. The system (0) according to claim 4, in, The network layer protocol is an Internet Protocol, and the client application requests automation device data from one or more of the server entities (112) using the Internet Protocol.

6. System (0) according to claim 1 or 2, in, At least on a portion of the communication path between the server entity (112) and the automation device (101a, 101b), only data link layer protocols and physical layer protocols are used.

7. The system (0) according to claim 1 or 2, in, Each of the automation devices (101a, 101b) has a communication stack, wherein the communication stack consists of a physical protocol layer and a data link protocol layer.

8. The system (0) according to claim 1 or 2, in, The server device (100) is a programmable logic controller or includes a programmable logic controller, and the programmable logic controller is used to control and / or monitor one or more automation devices among the plurality of automation devices (101a, 101b).

9. The system (0) according to claim 1 or 2, in, The client application uses one of the corresponding automation device host names in order to obtain automation device data from the corresponding automation device (101a, 101b) via the server entity (112), and / or wherein the server device (100) comprises an endpoint service (111), wherein the endpoint service (111) is operable to select one of the descriptive representations of the automation device (101a, 101b) to be loaded by the server entity (112), preferably based on a host name received from the client application, and / or wherein the client application obtains one or more of the automation device host names, for example from the name service (121), and wherein the endpoint service (111) is used to compare the host name obtained from the client application with the plurality of automation device host names, and / or The server device (100) is operable to update the name service (121) with a list of host names associated with the respective automation devices (101a, 101b).

10. The system according to claim 1 or 2, in, The client application is operable to establish a session with the server entity (112) based on an automation device hostname selected by the client application.

11. A method for data transmission between a client device (110), a server device (100) and one or more automation devices (101a, 101b), in, The server device (100) comprises a descriptive representation of each of the plurality of automation devices (101a, 101b), The server device (100) comprises a name service (121), wherein the name service assigns a host name to each of the plurality of automation devices (101a, 101b). wherein the client application on the client device is operated to obtain the host name of one or more automation devices from the name service (121), The server device (100) includes a server entity (112), and the method includes the steps of: loading (S1) by the server entity (112) one of the descriptive representations based on a host name identifying one of the automation devices (101a, 101b), and transmitting (S2) data from the automation device (101a, 101b) to a client application on the client device (110) by the server entity (112) based on the loaded descriptive representation of the automation device (101a, 101b), wherein the host name identifying one of the plurality of automation devices (101a, 101b) is selected by the client device (110), wherein the server entity (112) is operable to load only one descriptive representation of the automation device (101a, 101b) at a time, wherein each of the plurality of descriptive representations available for loading is associated with a corresponding automation device of the plurality of automation devices, wherein the server device (100) comprises an endpoint service (111), wherein the endpoint service (111) of the server device is configured to compare the host names of one or more automation devices obtained from the client application with the host names assigned to the server device and with a list of host names of automation devices stored in a local database, and In this case, the host name of one or more automation devices is not assigned to the server device.

Images