Automation arrangement
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2026-01-13
- Publication Date
- 2026-08-13
Smart Images

Figure EP2026050651_13082026_PF_FP_ABST
Abstract
Description
[0001] Description
[0002] Automation setup
[0003] The invention relates to an automation arrangement comprising: an IT level in which, by means of an IT infrastructure, the processing, creation, storage, exchange and retrieval of data is realized,
[0004] an OT level in which monitoring and control of industrial processes is implemented using automation components,
[0005] An Ethernet-based data network designed and arranged for communication between the IT level and the OT level, wherein at least one automation component is designed as a field device and a field device has at least one module, wherein the module(s) communicate with each other and with the field device via a field device bus.
[0006] The automation system therefore comprises two main levels: an IT level and an OT (Operational Technology) level. These levels are interconnected by an Ethernet-based data network, enabling seamless communication between the two. The IT level is equipped with an advanced IT infrastructure. This infrastructure is responsible for various data operations, including processing, creating, storing, exchanging, and retrieving data. It forms the backbone for information processing and management within the automation system. The OT level, on the other hand, houses the automation components. These components are specifically designed to monitor and control industrial processes. They form the interface between digital control and physical production processes. Field devices are a key element of the OT level.At least one of the automation components is designed as a field device. Each field device can contain one or more modules. These modules are connected to each other and to the higher-level field device via a dedicated field device bus, enabling efficient internal communication.
[0007] German patent application DE 102020 115439 A1 discloses a virtualization system for process plants with a back-end environment (IT level) and a front-end environment (OT level). Virtual nodes simulate the behavior of physical components. Communication takes place via an Ethernet network with an I / O switch. Configuration data is managed in databases.
[0008] WO 2018 / 204225 A1 describes an industrial control system with an open architecture in which virtual controllers run on generic hardware. The system uses hardware-location-independent addressing and self-describing data messaging. A hypervisor manages virtual devices and can move them between hardware components. The system is protocol-agnostic. Since a strong trend towards the convergence of IT (Information Technology) and OT (Operational Technology) levels has become established in industrial automation, one of the aims of the invention is to solve the resulting technical challenges in order to create added value for plant operators.
[0009] The task is solved by assigning at least some of the physical field devices in the OT level to a corresponding virtual field device in the IT level, whereby the assigned physical field devices and the virtual field devices are designed to communicate via the data network using a convergence protocol.
[0010] In the automation arrangement according to the invention, the mapping of virtual field devices in the IT layer to physical field devices in the OT layer is a key aspect. Each physical field device is assigned at least one virtual counterpart in the IT infrastructure. This pairing enables enhanced functionality and improved integration between IT and OT.
[0011] The invention offers several significant advantages for industrial automation systems:
[0012] 1. Improved integration of IT and OT:
[0013] The mapping of virtual field devices to physical field devices creates a seamless connection between the IT and OT levels. This enables more efficient data processing and analysis, as information from the production level can be directly integrated into IT systems.
[0014] 2. Increased flexibility: Virtualizing field devices makes the configuration and management of automation components more flexible. Changes can first be tested in the virtual environment and then transferred to the physical devices, reducing risks associated with system changes.
[0015] 3. Improved scalability:
[0016] The architecture allows for easier system expansion or modification by adding new virtual devices or adapting existing ones without directly interfering with the physical infrastructure. The convergence protocol enables efficient, bidirectional, real-time communication between virtual and physical devices. This improves data transmission and enables faster response times in automation. Storing configuration data on the virtual field devices allows for centralized management and rapid reconfiguration of physical devices, simplifying system maintenance and updates.
[0017] The virtual representations of field devices enable more detailed monitoring and diagnostics without disrupting ongoing operations. The integration of IT and OT layers facilitates the implementation of advanced analytics methods, machine learning, and AI applications in industrial processes.
[0018] Communication between the physical and virtual field devices takes place via the data network using a specially developed convergence protocol. This protocol is based on the Industrial Ethernet standard and establishes an application relationship between the corresponding devices.
[0019] In this AR structure, the virtual field device acts as a PROFINET controller, while the physical field device is configured as a PROFINET device. This configuration enables a clear division of roles and efficient communication between the levels.
[0020] The Application Relationship includes at least two Communication Relationships (CRs) for the exchange of cyclic I / O data as well as Record Communication, which is used for the transmission of acyclic data.
[0021] The physical field devices are equipped with various communication means: 1. A data network communication means for interaction with the Ethernet network.
[0022] 2. An inter-process communication tool for internal data processing.
[0023] 3. A backplane bus communication means for interaction with the modules.
[0024] The data network communication device includes a special field device bus proxy whose task is to adapt and convert different data formats.
[0025] The virtual field devices have corresponding virtual components that mimic the functions of the physical devices. In addition, they have a virtual switching node and a virtual field device bus proxy with an integrated data switch. These components enable flexible and efficient data processing and forwarding within the virtual environment.
[0026] Data exchange between physical and virtual field devices follows a defined communication path. The data to be transmitted is encapsulated in special PROFINET frames (for cyclic data) or PROFINET acyclic frames (for acyclic data) and transported via the data network.
[0027] Another important feature is the storage of configuration data from physical field devices on their virtual counterparts. This data can be transferred to the physical devices via the convergence protocol as needed, enabling centralized management and rapid reconfiguration.
[0028] Overall, the convergence protocol enables bidirectional, real-time communication between physical and virtual field devices via the established application relationship. This leads to seamless integration of the IT and OT layers, improves the flexibility and efficiency of the automation setup, and opens up new possibilities for advanced control and monitoring functions in industrial environments.
[0029] As stated above, an automation arrangement is obtained, comprising: an IT level in which data processing, creation, storage, exchange and retrieval are realized by means of an IT infrastructure; an OT level in which industrial processes are monitored and controlled by means of automation components.
[0030] An Ethernet-based data network designed and arranged for communication between the IT level and the OT level, wherein at least one automation component is designed as a field device and a field device has at least one module, wherein the module(s) communicate with each other and with the field device via a field device bus, wherein at least some of the physical field devices in the OT level are assigned a virtual field device in the IT level, wherein the assigned physical field devices and the virtual field devices are designed to communicate via the data network using a convergence protocol.
[0031] A physical field device comprises the following components: a data network communication means, an interprocess communication means, and a backplane bus communication means. The data network communication means is designed to exchange information on the data network and includes a field device bus proxy equipped with a convergence protocol means to adapt data records in telegrams from the convergence protocol to different data formats of the backplane bus communication means. The interprocess communication means is designed to perform bidirectional information exchange between the data network communication means and the backplane bus communication means. The backplane bus communication means is further designed for communication with the modules via the field device bus.
[0032] In contrast, a virtual field device comprises the following components: a virtual data network communication means, a virtual interprocess communication means, and a virtual convergence protocol means. The virtual data network communication means is configured to exchange information on the data network and to exchange information with the physical field device on the data network. It also includes a virtual switching node connected to the virtual convergence protocol means via a virtual communication channel and a virtual field device bus proxy equipped with a data switch. The virtual interprocess communication means is configured to perform bidirectional information exchange between the virtual data network communication means and the virtual convergence protocol means.wherein the components interact and are designed in such a way that data records in telegrams from the physical field device take the following communication path: arriving in the virtual data network communication medium via the switching node into the virtual communication channel and finally into the virtual convergence protocol medium, which is designed to adapt data records from the telegrams of the convergence protocol to different data formats of fieldbus protocols.
[0033] A major advantage is that the coupled physical field devices in the OT level, such as a physical decentralized Ethernet device of type ET200 IM from Siemens, have reduced software complexity, since more complex communication and data processing tasks are handled by the virtual decentralized Ethernet device instance.
[0034] When a coupled Ethernet device of type ET200 IM communicates with the corresponding virtual device according to the PROFINET principle, the path a telegram takes in a PROFINET network is also referred to as the "communication path" or "data path." In an industrial automation network like PROFINET, the communication path describes the route that data packets or telegrams take from the source (e.g., a control unit or controller) to the destination (e.g., a field device or actuator) through the network. This path can include various network components such as switches, routers, and other network devices that enable the forwarding of the telegrams.
[0035] In typical Profinet communication, the following elements and terms are important: Controller, here the virtual convergence protocol means in the virtual device: The central control unit that handles the communication and control of the field devices.
[0036] Device: The field devices or end devices that communicate with the controller.
[0037] This means that the device process is (from a PROFINET perspective) a PROFINET device instance, and the IT / OTconv process is (from a PROFINET perspective) a PROFINET controller instance that communicates with exactly one "IT / OTconv device" (coupled physical ET200 IM). Switches: Network nodes that handle the forwarding of data packets between the various devices in the network.
[0038] Profinet telegrams: The data packets that contain the control commands, status information and other data.
[0039] The communication path is crucial for the real-time capability and reliability of the Profinet system, as it influences the efficiency and speed of data transmission.
[0040] According to the invention, an IT / OT-converged device is equipped with a technology that aims to integrate the two traditionally separate worlds of information technology (IT) and operational technology (OT). This integration aims to improve efficiency, security, and interoperability in industrial automation and control systems. Here are some fundamental aspects of an IT / OT-converged device:
[0041] Integration of IT and OT:
[0042] IT (Information Technology) encompasses technologies and systems used to manage and process data, such as networks, servers, databases, and software applications.
[0043] OT (Operational Technology) refers to hardware and software used to monitor and control physical devices and processes in industrial environments, such as PLCs (Programmable Logic Controllers), SCADA (Supervisory Control and Data Acquisition) systems, and field devices.
[0044] Communication interfaces:
[0045] IT / OT converged devices offer interfaces and protocols that enable seamless communication between IT systems and OT devices. This can be achieved through the use of standardized protocols such as Profinet, OPC UA, or MQTT.
[0046] Data integration and management:
[0047] These devices enable the collection, processing, and analysis of data from both the IT and OT worlds. This allows companies to make informed decisions based on a more comprehensive data foundation.
[0048] Safety aspects:
[0049] IT / OT convergence requires robust security mechanisms to ensure data integrity and confidentiality. This can be achieved through encryption, access controls, and other security protocols. Benefits:
[0050] Increased efficiency: By integrating IT and OT systems, companies can optimize their processes and increase operational efficiency.
[0051] Improved decision-making: By combining IT and OT data, companies can gain more comprehensive and accurate insights into their business operations.
[0052] Cost savings: Reducing complexity and maintenance requirements can lead to significant cost savings.
[0053] A concrete example of an IT / OT convergent device is the "IT / OTconv device" described in your invention disclosure. This device integrates physical distributed Ethernet devices and virtual distributed Ethernet devices via a special protocol (IT / OTconv protocol) to enable consistent and secure communication between IT and OT layers.
[0054] For the purposes of this invention, virtual devices are software-based representations of physical devices that operate in a virtual environment. Virtual devices play a central role in IT / OT convergence, as they bridge the gap between the IT and OT worlds. They offer a number of advantages over purely physical devices, particularly with regard to flexibility, scalability, and maintenance.
[0055] Software-based implementation:
[0056] Virtual devices are fully implemented in software and run on virtual machines (VMs) or in container environments hosted on standard IT infrastructures such as servers or cloud platforms.
[0057] Virtual representation:
[0058] They represent the functionality and interfaces of physical devices without requiring the actual hardware to be present. This allows them to perform the same tasks as their physical counterparts.
[0059] Pairing with physical devices:
[0060] Virtual devices are tightly coupled with physical devices. In your case, the IT / OTconv protocol connects the virtual distributed Ethernet devices (ET200V IM) to the physical distributed Ethernet devices (ET200 IM). Engineering and configuration:
[0061] All necessary engineering data and configuration information are stored and managed in the virtual devices. This data is transferred to the physical devices as needed.
[0062] Data processing and forwarding:
[0063] Virtual devices can take over complex data processing tasks and forward the processed data to the physical devices or make it available at the IT / OT level.
[0064] Scalability and flexibility:
[0065] Because they run in a virtual environment, virtual devices can be easily scaled to meet demand. This is particularly advantageous in cloud environments, where additional resources can be dynamically provisioned as needed.
[0066] Communication interface:
[0067] The virtual devices (ET200V IM) act as a central communication interface to the IT / OT level. They enable data exchange between IT systems (e.g., ERP systems, cloud applications) and OT devices (e.g., PLCs in the OT level).
[0068] When used as a Profinet controller:
[0069] In your IT / OTconv device, the virtual devices act as Profinet controllers, establishing and maintaining a Profinet AR (Application Relationship) with the physical devices (ET200 IM).
[0070] Data management:
[0071] The virtual devices store all relevant engineering data and ensure that this data is consistent and up-to-date. They also handle data preprocessing and aggregation.
[0072] Reduction of physical device complexity:
[0073] By shifting complex functions and communication tasks to virtual devices, the software complexity of the physical devices is reduced. This leads to less maintenance effort and lower hardware requirements for the physical devices.
[0074] A major advantage is seen in reduced hardware requirements and lower maintenance costs for physical devices. Definitions
[0075] A PROFINET AR (Application Relation) is a central concept in PROFINET communication. It represents a logical connection between two PROFINET devices, used for data transmission and application synchronization. This connection is established and managed during the initialization of the communication process.
[0076] Key points regarding Profinet-AR:
[0077] Establishing a connection: An AR (Advanced Connection) is typically created during the commissioning phase of a Profinet system. This is done by exchanging configuration data and setting up communication parameters between the devices involved.
[0078] Communication quality: An AR can use different communication methods, such as real-time (RT) and isochronous real-time (IRT). This enables various data transfer options with different priorities and time requirements.
[0079] Data and control channels: An AR can be used for both cyclic data exchange (process data) and acyclic communication (diagnostic and parameter data).
[0080] AR parameters: The AR contains various parameters, such as the identification of partner devices, the type of data transmitted, cycle times, and priorities. These parameters are set during initialization and can be monitored and adjusted as needed during runtime.
[0081] Redundancy and fault tolerance: Profinet-AR can also include mechanisms to increase system reliability and fault tolerance, for example by supporting redundant connections.
[0082] Resource management: AR management also includes managing the resources in the devices involved to ensure that communication is efficient and reliable.
[0083] The Profinet-AR concept enables flexible and efficient communication in industrial automation networks by providing a clear structure and defined mechanisms for data exchange and synchronization.
[0084] Profinet AR (Application Relation) contains an Output CR (Communication Relation) and an Input CR. In Profinet communication, an Application Relation (AR) is used to define and manage the logical connection between two devices, and within this AR there are specific Communication Relations (IOCRs) that represent the actual communication channels for cyclic I / O data.
[0085] Coupled physical devices are hardware-based devices installed in an industrial environment that interact directly with process data (sensors, actuators, etc.). They serve as a link between the physical process level and the IT / OT level through the use of the IT / OTconv protocol.
[0086] The physical devices collect, process, and send process data (input and output data) to and from the connected sensors and actuators. They contain a backplane bus process that manages the data flow between the various electronic modules and the main controller within the device.
[0087] Data conversion: The device process in the virtual device handles the conversion and adaptation of data formats between the backplane bus and the different fieldbus protocols (e.g. Profinet, EtherNet / IP, Modbus TCP).
[0088] System architecture: Device process in the virtual device: This process includes the hardware and software components responsible for communication via various fieldbus types with PLC controllers (Virtual / Hardware PLC_x) from different manufacturers.
[0089] Backplane bus process: This process controls the backplane bus and enables data exchange with the connected electronic modules.
[0090] Interprocess communication: There is a bidirectional exchange of information between the device process and the backplane bus process. This exchange includes configuration data, cyclic I / O data, and dynamic events (e.g., plugging / unplugging modules).
[0091] Advantages:
[0092] Reduced software complexity: Since many of the complex communication and data processing tasks are outsourced to the virtual device, the software complexity of the physical devices is reduced. This leads to less frequent software updates and reduced maintenance effort for the physical devices. Profinet records: Profinet records are used for exchanging acyclic data, such as configuration and diagnostic data. The initiative for data exchange always comes from the virtual device, which sends record write or record read telegrams.
[0093] Polling and status signaling: The virtual device can use cyclic data read telegrams to check if new acyclic data is available. Alternatively, the physical device can provide a status element in the input data telegram that signals the presence of new acyclic information.
[0094] Tasks of the field device bus proxy or backplane bus proxy:
[0095] Data conversion:
[0096] Protocol conversion: The backplane bus proxy is responsible for converting data formats between the various fieldbus protocols (e.g., Profinet, EtherNet / IP, Modbus TCP) and the backplane bus protocol. This ensures that the data is in a correct format for both sides.
[0097] Data formatting: Converts complex data structures coming from PLC controllers (Virtual / Hardware PLC_x) via various fieldbus systems into a format expected by the backplane bus.
[0098] Bidirectional information exchange between physical and virtual devices:
[0099] Input data: The virtual device receives cyclic input data from the electronic modules (EM_x) and forwards it to the device process.
[0100] Output data: The virtual device sends cyclic output data from the device process to the corresponding electronic modules (EM_x) via the backplane bus.
[0101] Configuration data: Handles the configuration and parameterization data of the electronic modules, both towards the fieldbuses and towards the backplane bus.
[0102] Event data: Processes dynamic events such as the insertion or removal of electronic modules and various alarm telegrams, and forwards this information accordingly.
[0103] Consistency assurance:
[0104] Data integrity: Ensures that the data exchanged between the device and backplane bus processes is consistent and synchronous.
[0105] Synchronization: Uses mechanisms to synchronize data between different processes to ensure consistent and up-to-date data. Communication control / process coordination: Coordinates communication between different processes to ensure the right data reaches the right place at the right time.
[0106] Error handling: Handles communication errors and provides mechanisms to restore communication.
[0107] Resource management:
[0108] Storage management: Managing the storage resources required for data conversion and storage.
[0109] Performance optimization: Optimizes performance through efficient use of available resources.
[0110] The field device bus proxy, or backplane bus proxy, is an essential component of the system architecture of a physical field device, specifically the ET200 IM. Its main tasks include converting and synchronizing data between different protocols and processes, ensuring data integrity and consistency, controlling communication, and managing resources. By fulfilling these tasks, the backplane bus proxy enables the smooth and efficient operation of the overall system.
[0111] Detailed task of the backplane bus proxy:
[0112] Data conversion between fieldbus and backplane bus:
[0113] Protocol conversion: The backplane proxy converts the data formats between the various fieldbus protocols (e.g., Profinet, EtherNet / IP, Modbus TCP) and the backplane protocol. This means that the backplane proxy converts data arriving via the fieldbus into a format expected by the backplane bus, and vice versa.
[0114] Example: When data arrives via Modbus TCP, the backplane bus proxy converts this data into a backplane bus-compatible format, which is then forwarded to the appropriate electronic modules (EM_x).
[0115] Bidirectional information exchange:
[0116] Input data: Receives cyclic input data from the electronic modules (EM_x) and forwards it to the device process.
[0117] Output data: Sends cyclic output data from the device process to the corresponding electronic modules (EM_x) via the backplane bus.
[0118] Configuration and parameterization data: Handles the configuration and parameterization data of the electronic modules, both towards the fieldbuses and towards the backplane bus. Role of the convergence protocol:
[0119] The convergence protocol, or IT / OTconv protocol, comes into play when it comes to exchanging data between the physical ET200 IM and the virtual instance (ET200V IM). According to the new model, data transmission is enabled by the convergence protocol. Here are the steps related to the IT / OTconv protocol:
[0120] Communication between physical and virtual ET200 IM:
[0121] IT / OTconv protocol: Serves as a communication medium between the physical ET200 IM and the virtual ET200V IM. The data that the backplane bus proxy processes and passes on to the device process is then taken over by the IT / OTconv process and transmitted to the virtual ET200V IM via the IT / OTconv protocol.
[0122] Data flow in the IT / OTconv protocol:
[0123] Input data: Cyclic input data, converted by the backplane bus proxy and forwarded to the device process, is sent to the virtual ET200V IM via the IT / OTconv protocol.
[0124] Output data: Cyclic output data sent from the virtual ET200V IM to the physical ET200 IM via the IT / OTconv protocol is forwarded by the IT / OTconv process to the device process and then to the backplane bus proxy, which distributes it to the appropriate electronic modules (EM_x).
[0125] The backplane bus proxy converts the data between the various fieldbus protocols (e.g., Modbus TCP) and the backplane bus protocol within the physical ET200 IM. The actual communication takes place between the physical ET200 IM and the virtual ET200.
[0126] Tasks and functions of the data switch:
[0127] The "data switch" in the context of the described system architecture plays an important role in processing and distributing data within the physical ET200 IM. Here is a detailed explanation of its tasks and functions:
[0128] Distribution of data streams:
[0129] Cyclic I / O data: The data switch ensures that cyclic input and output data coming from the backplane bus process are correctly forwarded to the device process. This data can have various sources and destinations within the system. Acyclic data: In addition to cyclic data, the data switch also manages acyclic data, such as configuration and parameterization data, as well as dynamic events (e.g., alarm telegrams).
[0130] Directional control of the data:
[0131] From fieldbus to backplane bus: The data switch forwards data arriving from the fieldbus systems (e.g., Profinet, EtherNet / IP, Modbus TCP) to the backplane bus process. This data may need to be converted and provided in the correct format.
[0132] From backplane bus to fieldbus: The data switch also forwards data coming from the backplane bus process to the corresponding fieldbus systems. This can include cyclic I / O data or acyclic status information.
[0133] Data consistency and synchronization:
[0134] Consistent data transmission: The data switch ensures that data is transferred consistently and synchronously between the different processes (device process and backplane bus process). This is particularly important to guarantee data integrity.
[0135] Synchronization: The data switch helps synchronize data between the different communication channels and ensures that all processes are on the same page.
[0136] Data conversion:
[0137] Internal conversion: The data switch handles the task of converting complex data structures between the various protocols and processes within the physical ET200 IM. This can include adapting data formats or converting protocols.
[0138] Error handling and diagnosis:
[0139] Error detection: The data switch can detect errors in the data streams and initiate appropriate measures to correct them.
[0140] Diagnostic information: It can also provide diagnostic information that helps identify and resolve problems in the system.
[0141] Connection to the Convergence Protocol:
[0142] The data switch operates within the physical ET200 IM as follows; for communication via the IT / OTconv protocol.
[0143] Preparing the data for the convergence protocol, consolidating the data, the data switch consolidates and formats the data coming from the backplane bus process so that it can be transferred to the virtual ET200V IM via the convergence protocol.
[0144] The invention will now be explained in more detail with reference to an exemplary embodiment shown in the drawing:
[0145] FIG 1 shows a schematic representation of an automation arrangement according to the prior art,
[0146] FIG 2 shows a system diagram of an integrated IT / OT architecture comprising an IT / OT layer and an OT layer, according to the basic idea,
[0147] FIG 3 shows a system diagram of a state-of-the-art physical field device,
[0148] FIG 4 shows a system diagram of a virtual field device,
[0149] FIG 5 a system diagram of a coupled physical field device,
[0150] FIG 6 shows a block diagram of the addressing and parameterization of a coupled field device in the context of the convergence protocol.
[0151] FIG 7 shows a virtual field device and a coupled physical field device with respect to the data traffic of output and input data,
[0152] FIG 8 shows a virtual field device and a coupled physical field device with respect to the data traffic of configuration data.
[0153] FIG 9 shows a virtual field device and a coupled physical field device with respect to the data traffic of event data,
[0154] FIG 10 shows a block diagram of communication between input and output data using a data buffer. FIG 1 illustrates previous approaches to coupling the IT and OT levels. Currently, distributed Ethernet devices (ET200 IM_x) support a wide range of OT fieldbus protocols to make cyclic input data from the process level accessible and usable for automation tasks by PLCs (both virtual and hardware-based) from various manufacturers. The upper level is designed as a cloud or on-premise data center CD. This section contains virtual components such as a virtual PLC (Virtual_PLC_1), an MQTT broker, and an OPC UA client.
[0155] Furthermore, according to current technology, it is possible to read a wide range of status information (e.g., existing configuration, active parameterization, etc.) from the distributed Ethernet devices ET200 IM_x via standardized Ethernet telegrams (e.g., PROFINET records). If access to status information (Status_Info_x) is required via IT / OT level protocols (e.g., MQTT, OPC UA, etc.), the distributed Ethernet device is generally not addressed directly. Instead, the data traffic is routed through an IoT gateway or the existing PLCs. These "representatives" then provide the actual status information of the distributed Ethernet devices (ET200 IM_x) by using the supported OT fieldbus protocols (e.g., reading standardized PROFINET records). The Ethernet devices do not ensure consistency between current process values (cyclic I / O data) and those transmitted via standardized Ethernet telegrams (e.g.,...).The status information supplied via Profinet records (Status- lnfo_x) is guaranteed.
[0156] Figure 1 also shows various communication protocols: IT / OT protocols (MQTT = +++, OPC UA = — ) in the IT layer and OT fieldbus protocols (Profinet = AAA, Modbus TCP = ooo, EtherNet / IP = ***) in the OT layer. An IoT gateway is required to access status information.
[0157] The lower half shows the OT layer, which includes hardware components such as hardware PLC PLC1, hardware PLC2 and several ET200IM_x devices (1 to n).
[0158] FIG 2 This drawing illustrates a system architecture that combines the IT (Information Technology) and OT (Operational Technology) layers. The upper half of the image again shows the cloud data center CD. This section contains virtual components such as a virtual PLC, MQTT broker, OPC UA client, and several virtual ET200V IM (1 to n) devices, which correspond to the virtual field devices vFG1,...,vFG4. The lower half shows the OT layer, the hardware components such as hardware PLC1, hardware PLC2, and several ET200IM_x (1 to n) devices, which correspond to the physical field devices FG1,...,FG4. A crossed-out "IoT Gateway" is shown in the OT layer, indicating its elimination in this architecture.
[0159] FIG 2 again shows the different communication protocols: MQTT = +++, OPC UA = — , Profinet = AAA, Modbus TCP = ooo, EtherNet / IP = ***, with a convergence protocol CP now added, namely IT / OTconv = ###.
[0160] The IT and OT layers are connected through the exchange of status information, represented by small boxes labeled "Status Info". Communication between the IT and OT layers using MQTT and OPC UA protocols, listed as "IT / OT Protocols" in the legend in the upper right corner, occurs directly through access to the virtual field devices (vFG).
[0161] This diagram effectively illustrates the integration of IT and OT systems and shows how data can flow between the cloud data center CD and the operating equipment a in the workshop.
[0162] FIG 3 shows an abstracted system architecture of a physical field device ET200 IMs (state of the art). A clear separation exists between a device process and a backplane bus process.
[0163] The device process essentially includes the hardware and software components to enable communication with PLC controllers (virtual / hardware PLC_x) from different manufacturers via various fieldbus types (e.g. Profinet, EtherNet / IP, Modbus TCP).
[0164] The backplane bus process includes all hardware and software components to control the backplane bus and to interact with the existing electronic modules EM_x and EM_x, respectively.
[0165] To be able to exchange M1, M2, M3, M4 data.
[0166] There is a bidirectional exchange of information between the two processes, namely interprocess communication. The device process is responsible for performing any necessary complex data conversions between the fieldbus and backplane bus (backplane bus proxy). Typical data exchanged between the device and backplane bus processes includes:
[0167] first projected configuration data PKD1,
[0168] first Current Initial Data AA1 and
[0169] First current input data AE1 for a first protocol block B1.
[0170] According to FIG. 3, the field device, namely the physical ET200IM, has a data network communication interface DP, which contains a TCP / IP stack 31 that is connected to a PROFINET stack 32. Further protocols are implemented via an Ethernet / IP stack 33 and a MODBUS TCP stack 34. To enable communication via the PN network, there is an Ethernet interface 36, which is equipped with a first port P1 and a second port P2. The Ethernet interface 36 is connected to an I / O frame RAM 37 and a standard frame RAM 38. An Ethernet software driver 35 is assigned to the Ethernet interface 36. With regard to PROFINET communication, the data network communication interface DP forms a "device process". Within this device process, i.e., the data network communication means DP, a field device bus representative RBSt is arranged.The field device bus proxy RBSt can also be considered a "backplane bus proxy." It contains a data area for PROFINET data 39, a data area for Ethernet / IP data 40, and a data area for Modbus TCP data 41. These data areas are connected to their corresponding stacks 32, 33, and 34, and also to a data switch DW. An interprocess communication device (IPC) enables the transmission of configured data and current input / output data, according to their respective protocols, in a first area B1, a second area B2, a third area B3, and a fourth area B4. The first area B1 corresponds to a first protocol block B1 and contains the first configured configuration data PKD1 for Ethernet / IP communication. In addition to the configuration data, the first current output data AE1 is also present.
[0171] The second protocol block, B2, contains data for PROFINET communication. Specifically, it includes the second configured configuration data (PKD2), the second current output data (AA2), and the second current input data (AE2). The third protocol block, B3, contains data for Modbus TCP communication, including the third configured configuration data (PKD3), the third current output data (AA3), and the third current input data (AE3). The fourth protocol block, B4, contains configuration data (Konfig) and events (E1, E2, E3, E4).
[0172] The interprocess communication medium (IPC) is connected to a backplane bus communication medium (RBP). The backplane bus communication medium (RBP) can also be referred to as a "backplane bus process". To receive data from the aforementioned protocol blocks or areas B1, B2, B3, and B4, the backplane bus communication medium (RBP) has a software driver 42. This software driver 42 is in turn connected to a control register 43, a status register 44, a transfer RAM 45, and an I / O RAM 46.
[0173] To enable the backplane bus communication device RBP to communicate with the modules M1, M2, M3, M4, a bus interface 47 is available.
[0174] As shown in FIG. 4, a virtual field device vFG1 is depicted. It comprises the following components: a virtual data network communication medium vDP, a virtual inter-process communication medium vIPC, and a virtual convergence protocol medium vCPP. The virtual data network communication medium vDP, which implements the device process in PROFINET communication, is configured to exchange information with a physical field device FG1 on the data network PN. In contrast to the prior art, it also includes a virtual switching node vVK. The special feature of the virtual field device vFG1 is that the additional virtual switching node vVK is connected to the virtual convergence protocol medium vCPP via a virtual communication channel vKK. Analogous to FIG. 3, a virtual field device bus proxy vRBSt is also present.It is also equipped with a data switch (DW) and communicates with the virtual interprocess communication medium (vIPC). The virtual interprocess communication medium (vIPC) is designed to perform bidirectional information exchange between the virtual data network communication medium (vDP) and the virtual convergence protocol medium (vCPP).
[0175] The aforementioned components interact in such a way that data records in a Profinet telegram PNT from the physical field devices FG1,...,FG4 take the following communication path KP: Arriving in the virtual data network communication medium vDP via the virtual switching node vVK into the virtual communication channel vKK and finally into the virtual convergence protocol medium vCPP, which is designed to adapt the data records from the Profinet telegram PNT of the convergence protocol CP to the different data formats of the different fieldbus protocols and to make them available to the vDP via vIPC.
[0176] On the virtual field device vFG1, analogous to the protocol blocks or areas B1, B2, B3, and B4, a first data record DS1, a second data record DS2, a third data record DS3, and a fourth data record DS4 are stored. This means that configuration data (Config) for the physical field devices FG1,...,FG4 is stored on the virtual field device vFG1 and can be transmitted to the physical field devices FG1,...,FG4 via the convergence protocol CP as needed.
[0177] Especially when configured for PROFINET communication, the CP convergence protocol is designed with an Application Relations Clip AR, i.e., a PROFINET AR structure. In this configuration, the virtual field device vFG1 acts as the PROFINET controller, and the physical field device FG1 functions as the PROFINET device. The Application Relations Clip AR comprises at least two Communication Relations Clips CRs: an Output Communications Clip OCR with current output data and an Input Communications Clip ICR with current input data.
[0178] In other words, as shown in FIG. 4, a new topology is now obtained with a functional division between a virtual field device and a physical field device. The "device process" in the virtual field device still has the primary task of communicating with PLCs from different manufacturers via various fieldbus types, e.g., PROFINET, Ethernet / IP, Modbus-TCP. A conventional backplane bus process is now replaced by an IT / OT convergence process, or the virtual convergence protocol (vCPP). Its task is now to enable bidirectional information exchange between the "device process" and the backplane process in the coupled physical field device.
[0179] This means that from a Profinet perspective, the device process is a Profinet device instance, and from a Profinet perspective, the IT / OT convergence process is a Profinet controller instance that communicates with exactly one IT / OT convergence device.
[0180] Figure 5 now presents a "slimmed-down" physical field device FG1. In contrast to the device shown in Figure 3, the device in Figure 5 only has the Profinet Stack 32 and the associated Profinet Data 39. The field device bus representative RBSt, however, now features the convergence protocol medium CPP instead of the data switch DW.
[0181] Assuming that the data network communication medium DP operates as the device process, the function of the device process is now limited to being able to establish a Profinet AR (as a Profinet device) with the virtual field device vFG1 (as a Profinet controller) and then, in this context, to enable consistent bidirectional information exchange with the backplane bus process. Since many software components, such as the data switch DW and the various fieldbus stacks, e.g., Ethernet / IP Stack 33 and Modbus DCP Stack 34, have been moved from the device process of the physical field device to the device process of the virtual field device, the complexity of the software in the physical field device FG1 is significantly reduced.
[0182] Figure 6 illustrates a possible module configuration of a Profinet AR or Application-Relation Chip AR. It requires a head module KM, an output data module ADM, and an input data module EDM. The head module KM contains a slot number SN and a subslot number SSN. The same applies to the output data module ADM (ADM dimensions the OCR) and the input data module EDM (EDM dimensions the ICR). The exemplary module configuration shown in Figure 6 is configured for a physical field device FG1 with an Ethernet interface that has two Ethernet ports. The head module KM is assigned a slot number 0 and corresponding subslot numbers 1, 0X8000, 0X8001, and 0X8002.
[0183] FIG 7 symbolizes the information exchange between the virtual field device vFG and the physical field device FG. A PROFINET output telegram PNOT, a summed output data telegram SAD, and an output communications relation chip OCR transmit the first current output data AA1, the second current output data AA2, and the third current output data AA3 from the virtual field device vFG to the physical field device FG using the virtual convergence protocol vCPP. The summed output data telegram SAD is represented in the device process or the data network communication medium DP. The field device bus proxy RBSt, namely the backplane bus proxy, forwards the data to the interprocess communication medium IPC, and from there the backplane bus process sends it to the electronic modules.Conversely, the current input data from the electronic modules is read via the backplane bus process and then made available to the interprocess communication device (IPC). This data is then mapped from the IPC to a summed input data telegram (SED) as the first current input data (AE1), second current input data (AE2), and third current input data (AE3) in the convergence protocol (CPP) of the field device bus proxy (RBSt) or in the backplane bus proxy. This data is then transported via a PROFINET input telegram (PNIT) over the data network (PN) to the virtual field device (vFG). There, the summed input data telegram (SED) is again mapped in the virtual convergence protocol (vCPP), which in turn is mapped to the virtual interprocess communication device (vIPC) along with the first current input data (AE1), second current input data (AE2), and third current input data (AE3).Afterwards, the input data is available to the device process in the virtual IM for further processing.
[0184] Analogous to FIG. 7, FIG. 8 illustrates the mapping of projected configuration data. In a copy step 1, the virtual interprocess communication medium vIPC transports the first projected configuration data PKD1 in a data record write telegram DSS to the physical field device FG using the virtual convergence protocol medium vCPP. Upon arrival at the physical device, the device process again receives the first projected configuration data PKD1 in the data record write telegram DSS, which is mapped in an interprocess communication medium IPC in a receive step 2. In a send step 3, a data record read telegram DSL informs the virtual field device vFG that an acknowledged data record containing projected configuration data qPKD1 is now available.These acknowledged initial configuration data qPKD1 are transported in a data record read telegram DSL through the virtual convergence protocol means vCPP - and then, in a transmission step 4, made available again to the virtual interprocess communication means vIPC.
[0185] In other words, considering PROFINET communication terminology, an Application Relations Chip (AR), i.e., the PROFINET AR described above, is used for output communication (an Output Communication Chip, or OCR) for exchanging cyclic output data, and an Input Communication Chip (ICR) for exchanging cyclic input data. A IC telegram buffer can then transmit the maximum possible output and input data volumes of the physical field devices in a single PROFINET I / O telegram. Since the ownership of a submodule can change dynamically via a PLC connection, and errors during configuration are possible, it is necessary to synchronize the currently valid submodule connections and their connection information between virtual and physical field devices using a parameter record.
[0186] Figure 9 illustrates how communication is carried out according to the event data E1, E2, E3, and E4. For example, the physical field device FG1 sends a request step 10. In request step 10, a data record read telegram (DSL) is used to inquire whether new acyclic data, such as events E1, E2, E3, and E4, is available. And indeed, an event E1 = "Module inserted into slot 3" is present. This data record read telegram (DSL) is then transmitted via the PROFINET record telegram to the virtual field device (vFG) and arrives there as a data record read telegram (DSL) containing the event E1. In transmission step 20, this information is communicated to the virtual interprocess communication device (vIPC).In response step 30, an acknowledged event qE1 is transmitted via the Profinet record telegram to the physical field device FG in a data record write telegram DSS, which then enters this back into the interprocess communication medium IPC in an acknowledgment step 40.
[0187] FIG 10 illustrates the communication structure regarding process data between a virtual field device VFG1, a Profinet AR application relationship AR, and a physical field device FG1. The diagram is divided into three main columns, each representing one of these components.
[0188] On the left, the virtual field device VFG1 ET200 IM displays an I / O mapping parameterization table with two columns containing various parameters and their corresponding values. In the middle, the PROFINET-AR column shows two sets of IPC Output Data Modules and IPC Input Data Modules, each containing several subslot entries. The right column shows the physical field device vFG1 with similar structures for IPC Output Data Modules and IPC Input Data Modules.
[0189] Arrows between the columns show the data flow between the virtual and physical field devices. The Profinet-AR demonstrates how information is exchanged in both directions using this communication structure.
Claims
25 Patent claims 1. Automation arrangement (101), comprising: an IT level (IT) comprising an IT infrastructure with one or more servers, processors and storage means, wherein the IT infrastructure is designed for processing, creating, storing, exchanging and retrieving data; an OT level (OT) comprising automation components (AG1, AG2, FG1,...,FG4) for monitoring and controlling industrial processes (100), wherein the automation components (AG1, AG2, FG1,...,FG4) include physical devices for direct interaction with the industrial processes (100), an Ethernet-based data network (PN) designed and arranged for communication between the IT level (IT) and the OT level (OT), wherein at least one automation component (AG1, AG2, FG1,...,FG4) is designed as a field device (FG1,...,FG4) and a field device (FG1,...,FG4) has at least one module (M1,...,M4), wherein the module(s) (M1,...,M4) communicate with each other and with the field device (FG1,...,FG4) via a field device bus (RB), characterized in that In the IT infrastructure, at least some of the physical field devices (FG1,...,FG4) in the OT level (OT) are assigned a virtual field device (vFG1,...,vFG4) in the IT level (IT), whereby the assignment is realized by a configuration database which assigns each physical field device (FG1,...,FG4) a unique identifier that is linked to a corresponding virtual field device (vFG1,...,vFG4). wherein the associated physical field devices (FG1,...,FG4) and the virtual field devices (vFG1,...,vFG4) communicate via the data network (PN) using a convergence protocol (CP), wherein the convergence protocol (CP) defines a communication method based on the Industrial Ethernet standard and establishes an application relationship (AR) between each physical field device (FG1,...,FG4) and its associated virtual field device (vFG1,...,vFG4), where the virtual field device (vFG1,...,vFG4) is configured as a Profinet controller and the physical field device (FG1,...,FG4) is configured as a Profinet device, and wherein the Application Relationship (AR) includes at least two Communication Relationships (CRs) for the exchange of cyclic I / O data and at least one Record Communication Relationship for the exchange of acyclic data.
2. Automation arrangement (101) according to claim 1, wherein a physical field device (FG1,... ,FG4) comprising the following components: a data network communication means (DP), an interprocess communication (IPC) tool and a backplane bus communication device (RBP), wherein the data network communication means (DP) is configured to exchange information on the data network (PN) and includes a field device bus proxy (RBSt) which is configured with a convergence protocol means (CPP) to adapt data records in telegrams (PNT) from the convergence protocol (CP) to different data formats for a bus interface (47) of the field device bus (RB), wherein the interprocess communication means (IPC) is configured to perform a bidirectional exchange of information between the data network communication means (DP) and the backplane bus communication means (RBP), and wherein the backplane bus communication means (RBP) is configured for communication with the modules (M 1 , ... ,M4) via the field device bus (RB).
3. Automation arrangement (101) according to one of claims 1 or 2, characterized in that a virtual field device (vFG1,...,vFG4) has the following components: a virtual data network communication means (vDP), a virtual interprocess communication tool (vIPC), and a virtual convergence protocol tool (vCPP), wherein the virtual data network communication means (vDP) is configured to exchange information on the data network (PN) and to communicate with the physical field device (FG1,...,FG4) via an additional virtual switching node (vVK) which is connected to the virtual convergence protocol means (vCPP) via a virtual communication channel (vKK), wherein the virtual data network communication means (vDP) continues to have a virtual field device bus proxy (vRBSt) which is equipped with a data switch (DW), wherein the virtual interprocess communication medium (vIPC) is designed to perform a bidirectional exchange of information between the virtual data network communication medium (vDP) and the virtual convergence protocol medium (vCPP), wherein the components interact and are designed such that data records in telegrams (PNT) from the physical field device (FG1,... ,FG4) take the following communication path (KP): arriving at the virtual data network communication medium (vDP), via the switching node (vVK), into the virtual communication channel (vKK) and finally into the virtual convergence protocol medium (vCPP), and wherein the virtual Convergence Protocol Means (vCPP) is designed to adapt data sets from the telegrams (PNT) of the Convergence Protocol (CP) to different data formats of fieldbus protocols and to make them available in the virtual Interprocess Communication Means (vIPC).
4. Automation arrangement (101) according to one of claims 1 to 3, wherein configuration data (Config) of the physical field devices (FG1,... ,FG4) are stored on the virtual field devices (vFG1,... ,vFG4) in order to transmit them to the physical field devices (FG1,... ,FG4) via the Convergence Protocol (CP) when required.
5. Automation arrangement (101) according to claims 1 to 4, characterized in that: The Communication-Relationship (CR) for the IO-Data data set is configured for the exchange of cyclic I / O data between the virtual field device (vFG1,...,vFG4) and the physical field device (FG1,...,FG4). and the Communication-Relationship (CR) for which the record data set is configured for the exchange of acyclic data between the virtual field device (vFG1,...,vFG4) and the physical field device (FG1,...,FG4).
6. Automation arrangement (101) according to claim 5, characterized in that the exchange of cyclic I / O data takes place via the Communication-Relationship (CR) for the data set for IO-Data, wherein: Input data is transferred from the physical field device (FG1,... ,FG4) to the virtual field device (vFG1,...,vFG4), Output data is transferred from the virtual field device (vFG1,... ,vFG4) to the physical field device (FG1,...,FG4), the I / O data are encapsulated in Profinet frames, which are transported over the data network (PN).
7. Automation arrangement (101) according to one of claims 5 or 6, characterized in that the exchange of acyclic data takes place via the data record for Record-Data, wherein: 28 Read and write access to data records of the physical field device (FG1,... ,FG4) is enabled by the virtual field device (vFG1,..,vFG4) and the acyclic data are encapsulated in Profinet acyclic frames, which are transported over the data network (PN).
8. Automation arrangement (101) according to one of claims 1 to 7, characterized in that the convergence protocol (CP) enables bidirectional real-time communication between the physical field devices (FG1,...,FG4) and the virtual field devices (vFG1,... ,vFG4) via the established application relationship (AR).
9. Automation arrangement (101) according to one of claims 1 to 8, characterized in that the physical field device (FG1,...,FG4) has reduced software complexity by having more complex communication and data processing tasks for several different fieldbus protocol types taken over by the virtual field device (vFG1,...,vFG4).
10. Automation arrangement (101) according to one of claims 1 to 9, characterized in that the virtual field device (vFG1,...,vFG4) has a data switch (DW) which is designed for distributing and adapting data sets from the convergence protocol (CP) to different fieldbus protocol data formats, The data switch (DW) manages cyclic I / O data and acyclic data and forwards them to the appropriate fieldbus systems.