DE102022005152B4 - Ethernet frame, Ethernet-based network and method for data communication in an Ethernet-based network - Google Patents

Abstract

Ethernet frame for data communication in a network with a control device (1) and several terminal devices (11-14) connected to the control device (1), the Ethernet frame (EF) comprising: an Ethernet frame header (EFH) and an Ethernet frame data field (EFD); several device frames (DF11 - DF14) contained in the Ethernet frame data field (EFD), which are assigned to one or more of the terminal devices (11-14); wherein the device frames (DF11 - DF14) each have a device frame data field (DFD) with payload data to be processed and a device frame header (DFH) with a destination identification field (DestinationID) for identifying an addressee of the respective device frame (DF11 - DF14); and an intermediate level frame (LF) which is contained in the Ethernet frame data field (EFD), preferably forming the Ethernet frame data field (EFD); wherein the intermediate level frame (LF) has an intermediate level frame data field (LFD) with the plurality of device frames (DF11 - DF14) and an intermediate level frame header (LFH) common to the device frames (DF11 - DF14) with a source identification field (SourceID) for identifying a sender of the Ethernet frame (EF).

Description

The invention relates to an Ethernet-based data communication which is particularly suitable for data communication at field level.

With the introduction of the Single Pair Ethernet standards (SPE) 10BASE-T1S/L according to IEEE 802.3cg, it is now possible for the first time to implement consistent Ethernet-based communication down to the field level, i.e. down to the sensors and actuators, in the areas of factory and process automation, building automation and, in principle, other areas of automation. In addition to the direct Ethernet-based connection to a control device, such as a PLC, this also enables communication between a sensor or actuator and the control level or the cloud.

In the higher levels of the automation pyramid, Ethernet-based protocols (Industrial Ethernet) already exist, which fully implement this type of communication in various areas on 10/100/1000BASE-T2/4. However, the known solutions are defined for specific fields of application and their possibilities have grown over time. Examples include the PROFINET, Ethernet/IP, EtherCAT, POWERLINK, OPC-UA and Modbus-TCP protocols. As the possibilities have grown, so have the requirements for the hardware of the devices belonging to the network, such as the requirements for the CPU, the size of the data storage and the real-time capability. This has made it difficult and prevented the use of existing technologies in the area of "price-sensitive" sensors.

Another aspect is the usability in a safety environment, in which functionally safe communication must be guaranteed. For this purpose, the known protocols in the sense of the ISO/OSI reference model for the area of functional safety are extended by an additional safety communication layer, such as PROFISafe and FailSafe over EtherCAT (FSoE). The respective safety extension sees the protocol as a so-called black channel. The protocols extended for use in the area of functional safety require additional hardware. For example, a safety monitor is required for PROFINET plus PROFISafe.

The DE 2019 208 678 A1 discloses an Ethernet-capable network and a method for data communication in the network using an Ethernet frame having an Ethernet standard header, an IP header, a TCP header with TCP data on the OSI layer 4 and device frames with configurable payload data for the terminal devices of the network.

The WO 2020/263526 A1 uses an Ethernet frame with a standard Ethernet header and device frames for the network's end devices. The device frames each have a header and a data field with the payload for the respective end device, whereby the device frame headers can contain the destination address of the respective end device and a header checksum.

According to EP 2 466 406 A1 An Ethernet frame is divided into subframes that are assigned to the end devices of a network. The Ethernet frame contains a frame ID that is common to the subframes and is secured by a CRC check field. Each subframe is also assigned its own CRC check field.

Against this background, it is an object of the invention to enable data communication based on the Ethernet standard with terminal devices, such as in particular sensors, actuators and other actuators, i.e. communication at field level or up to the field level.

One task may also be to create a protocol for Ethernet-based data communication that places lower demands on the hardware of the communication participants than known protocols.

What is desirable is a protocol for Ethernet-based data communication, a network with network components for Ethernet-based data communication and a method for Ethernet-based data communication that enable flexible configuration of the network.

Another task may be to increase the functional safety of data communication in an Ethernet-based network that has one or more communication channels that can be classified as black channels.

The invention relates to an Ethernet frame for data communication in an Ethernet-capable network, an Ethernet-capable network with network components that are set up for data communication using the Ethernet frame according to the invention, and a method for data communication in an Ethernet-capable network using the Ethernet frame according to the invention. The network comprises a control device, several terminal devices connected to the control device and optionally one or more distributors, such as one or more switches and/or bridges and/or hubs. The invention The application is not limited in terms of the topology of the network and can be used with line structures, star structures, ring structures and also mixed forms of different topologies. The network can include several control devices connected to the end devices and/or to each other. If only one or the control device is mentioned below, these statements always apply analogously to any optional additional control device in the network.

The Ethernet frame includes an Ethernet frame header and an Ethernet frame data field for user data. The Ethernet frame header is an Ethernet standard header, preferably in accordance with IEEE 802.1q. The Ethernet frame data field contains several device frames that are assigned to one or more of the end devices. The device frames each include a device frame data field with user data to be processed and a device frame header, which can in particular contain a destination identification field for identifying an addressee of the respective device frame. The addressee of the respective device frame can be one of the end devices or the control device.

The assignment between the device frames and the end devices can be bijective, so that each of the device frames is assigned to exactly one of the end devices and each of these end devices is assigned exactly one of the device frames. Instead, the assignment can also be such that one of the end devices is assigned several or all of the device frames contained in the Ethernet frame, or several of the end devices are each assigned several of the device frames contained in the Ethernet frame. If it is an Ethernet frame sent by the control device, the payload of the respective device frame is payload data for processing by the assigned end device. If one of the end devices sends the Ethernet frame, it is payload data for processing by the control device or one or more other end devices.

The user data sent by the control device can, for example, be data for configuring the end devices (configuration data) or a request to a sensor to send measurement data or an instruction to an actuator to carry out an actuating movement. The user data sent by an end device can be measurement data of physical and/or chemical variables, such as temperature values and/or pressure values and/or volume flow values and/or fill level values and/or position data and/or speed values and/or pH values and/or values for material concentrations and the like, to name just a few examples. Other types of user data include event data and alarm data.

The Ethernet frame comprises an intermediate level frame that is contained in the Ethernet frame data field. Preferably, the Ethernet frame data field contains exactly one intermediate level frame. In particular, it can consist of the intermediate level frame. The intermediate level frame comprises an intermediate level frame data field with the multiple device frames and an intermediate level frame header common to the device frames. The device frames are summarized in the intermediate level frame under the common intermediate level frame header.

In advantageous embodiments, the intermediate level frame header includes a source identification field for identifying the sender of the Ethernet frame. The sender of the respective Ethernet frame can be the control device or one of the end devices. The creation of the destination identification field in the header of the respective device frame and the source identification field in the header of the intermediate level frame enables point-to-point (P2P) communication between the control device and the end devices and also between end devices. Only the sender in the source identification field of the intermediate level frame header and the recipient in the destination identification field of the device frame header must be clearly identified and distinguishable from all other communicating devices.

If the control device sends an Ethernet frame to several end devices, the source identification field of the intermediate level frame header contains an identification in the form of a bit sequence that identifies the control device, and the destination identification field in the header of the respective device frame contains an identification in the form of a bit sequence that identifies the end device addressed with it. If one of the end devices sends an Ethernet frame, the source identification field of this Ethernet frame contains an identification in the form of a bit sequence that identifies the sending end device. At the same time, the destination identification field in the header of the device frame(s) assigned to the sending end device contains a bit sequence that identifies the control device or another end device as the addressee of the Ethernet frame. The identification of the sender and the addressee can be a CRC signature of a parameter that uniquely identifies the respective device, for example the MAC address of the respective device. The generator polynomial for generating the respective CRC signature is advantageously chosen so that the CRC signatures clearly identify the sender and the recipient in the network. If the If a CRC signature is generated on the MAC address, CRC-16 signatures have proven to be effective for this purpose.

The intermediate level frame is therefore direction-dependent and enables directed communication between the control device and optionally one or more other control devices and the end devices, optionally also between control devices and/or end devices. The address field in the header of the Ethernet frame, i.e. the general Ethernet address field, can be set to multicast. Under this condition, the Ethernet frames are direction-independent. Ethernet frames sent by the control device or one of the end devices then reach all other devices in the network. If the network has one or more distributors that are set up to filter the Ethernet frames, such as one or more switches set up for filtering, and one or more of the end devices is fully Ethernet-capable, the respective end device can write the MAC address of the control device into the address field in the header of the Ethernet frame, instead of a multicast, in order to send a directed Ethernet frame and thereby relieve the network. A particular advantage of the invention is that data communication within the network can take place below the Ethernet standard, solely at the level of the intermediate level frame and the device frame. This means that terminal devices that do not have a standard Ethernet connection (RJ45 M12) can also be integrated into the network. A simple screw terminal, for example, is sufficient as a connection. In particular, no storage space is required for the TCP/IP stack that would otherwise be required. The computing unit of the respective terminal device can be simplified compared to a standalone Ethernet-capable terminal device and thus made considerably cheaper.

In the context of the invention, the terms "Ethernet-capable" and "Ethernet-based" mean that the network components, such as in particular the respective control device and the respective terminal device as well as one or more optionally present distributors of the network, can receive the Ethernet frame, read it in the scope of the intermediate level frame, process it in terms of data technology and generate and send an Ethernet frame with device-specific control data and user data in the respective device frame and control data in the intermediate level frame header. The network can advantageously comprise one or more network components that can also process and change the Ethernet header, for example the control device and/or an optionally further control device and/or one or more of the terminal devices; however, this is not essential. In advantageous embodiments, however, the terminal devices can read a multicast in the destination address field (DestinationADD) and the EtherType field of the Ethernet frame header and process it accordingly.

In advantageous embodiments, the intermediate level frame header contains a group identification field with a group identification that identifies several or all of the device frames contained in the intermediate level frame as device frames of a group of terminal devices that belong together, so that the terminal devices can be divided into different logical groups of terminal devices by assigning each one a specific group identification. The control device can assign different group identifications to the terminal devices and thereby divide the terminal devices in the network into logical groups. A first group identification can thus be assigned to a first terminal device and a second terminal device, optionally to one or more other terminal devices, and a second group identification can be assigned to a third terminal device and a fourth terminal device, optionally to one or more other terminal devices. After the assignment, the first and second terminal devices belong to a first logical group of devices and the third and fourth terminal devices belong to a second logical group of devices. The control device expediently assigns the respective group identification to the terminal devices before cyclic operation begins, during the setup and commissioning of the network. The network components can also be configured to change the group identifications by having the control device send an Ethernet frame with a new assignment after a period of cyclic operation and then resuming cyclic operation with the new assignments.

If the group identification field contains only one bit, only two logical groups can be formed in the network. The group identification field is preferably several bits long and occupies, for example, 1 byte. This opens up the possibility of forming three or more logical device groups and/or sending a broadcast to all end devices in the network, regardless of group membership. The group identification field can therefore contain a bit sequence for a broadcast to all end devices connected to the control device instead of a specific group identification.

The logical groups can be disjoint, meaning that the end devices each belong to only one of several logical groups in the network. In a further development, one or more of the end devices can also be set up for the assignment of several group identifications. The same end device can then belong to different device groups. For example, the first terminal can be assigned to both the first and the second group, or more groups can be formed with the same number of terminals. For example, two different groups can be formed with just three terminals if one of the three terminals belongs to both groups, but at least one of the other two terminals belongs to only one of the two groups.

The ability of one or more terminal devices to accept two or more group identifications is particularly advantageous in networks with multiple control devices. For example, a first network of the type according to the invention, which comprises a first control device, and a second network, also of the type according to the invention, which comprises a second control device, can be connected to one another, with one or more terminal devices or all of the terminal devices of the first network also belonging to the second network. The respective terminal device that belongs to both networks can have one or more group identifications in the second network in addition to the one or more group identifications that it has in the first network. Such a terminal device can receive and process Ethernet frames from the first control device and Ethernet frames from the second control device if the respective Ethernet frame identifies one of the group identifications assigned to the respective terminal device in the group identification field.

The intermediate level frame and/or the respective device frame can each contain a CRC check field for detection and, in this sense, to protect against data transmission errors. The intermediate level frame can contain a CRC check field to protect the intermediate level frame header and/or the respective device frame can contain a CRC check field to protect the device frame header and/or a CRC check field to protect the device frame data field. Instead of a CRC check field to protect the device frame header and a separate CRC check field to protect the device frame data field, the respective device frame can also be protected with a CRC check field common to its header and its data field. If the intermediate level frame header contains a CRC check field, the check code (checksum) of this check field is only formed over the binary data of the intermediate level frame header, for example by polynomial division with a suitable generator polynomial. If the CRC check field is present for the device frame header, the check code (checksum) of this check field is only formed over the binary data of the device frame header, for example by polynomial division with a suitable generator polynomial. If the device frame data field contains a CRC check field, the check code (checksum) of this check field is only formed over the binary data of the device frame data field, for example by polynomial division with a suitable generator polynomial. If a common CRC check field is provided for the header and the data field of the respective device frame, the check code (checksum) of this check field is formed only from the binary data of the header and the data of the data field of the respective device frame, for example by polynomial division with a suitable generator polynomial.

The standard CRC check field of the Ethernet frame can also be present, but does not have to be used. In principle, the check field of the Ethernet frame could be used for security. In the interests of the continuity of the protocol up to the field level, including sensors and other end devices from the low-price range, security within the intermediate level frame is advantageous, since the data fields in the standard header of the Ethernet frame do not have to be taken into account when forming the respective checksum. Compared to security only through the check field of the Ethernet frame, the security according to the invention increases the safety integrity and can increase the safety integrity level (SIL). In advantageous versions, the check field of the Ethernet frame is additionally used for security.

The intermediate level frame advantageously contains the check field for the intermediate level frame header and, in addition, for the device frames, the check field for the device frame header. The intermediate level frame particularly preferably contains the CRC check field for the intermediate level frame header and, in addition, for the device frames, the CRC check field for the device frame header and the CRC check field for the device frame data field. By separately securing at least two of these data areas and, in particular, by separately securing all three data areas, error detection is simplified and data transmission errors are detected with increased reliability. Data integrity can be guaranteed with increased reliability. An Ethernet frame detected as faulty can be resent if an error is detected. The control device and the terminal devices expediently process the CRC check fields sequentially in a predetermined order. For example, if the Ethernet frame contains the check field for the intermediate level frame header and for the device frames at least the CRC check field for the device frame header, the receiving device forms the checksum for the intermediate level frame header and compares this checksum with the checksum in the Only if these two checksums are the same does the receiving device create the checksum for the relevant device frame header and compare this checksum with the checksum in the check field of the same device frame header. The separate protection also speeds up error detection.

If the Ethernet frame has CRC check fields for different data areas, such as for the intermediate level frame header and the respective device frame header, the binary checksums or check codes are advantageously generated with adapted and therefore typically different generator polynomials, which can also differ from each other in order.

The intermediate level frame header can contain an Ethernet frame mode field to identify a specific communication mode from several optionally selectable different communication modes. The Ethernet frame mode field can contain a bit sequence that tells the end devices that the network is in a commissioning mode or in a cyclic operation mode or in an acyclic operation mode. In commissioning mode, assignments can be made, such as dividing the network components into logical groups and/or assigning new, temporary device identifications. In cyclic operation mode, cyclic data communication is carried out. In this way, the control device can request measurement data from one or more sensors in a cycle, which is then sent back by the sensor or sensors in the same cycle.

In advantageous embodiments, the terminals can each be assigned a group identification in commissioning mode by making a corresponding entry in the group identification field in order to divide the network into logical groups of terminals, as explained above. The control device can also be set up to change the group identifications and thus the grouping of the terminals.

By entering a corresponding bit sequence in the target identification field, a device identification can be assigned to the respective terminal device addressed in this way in commissioning mode. The control device can be set up to temporarily replace the device identification of the respective terminal device with a new, temporary device identification during cyclic network operation by switching the control device back to commissioning mode and generating a new bit sequence for the temporary device identification for the respective terminal device and sending an Ethernet frame with the new, temporary device identification. This Ethernet frame contains the bit sequence set by the control device for commissioning mode in the Ethernet frame mode field of the intermediate level frame, the bit sequence for the existing device identification of the respective terminal device in the target identification field of the respective device frame and the bit sequence for the new device identification in the respective device frame data field.

The end devices are set up to read their own new device identification and, in a subsequent cyclic operation mode, to use it as the new device identification for cyclic communication instead of the previous device identification. The ability of the control device to generate temporary device identifications and the ability of the end devices to use the assigned new device identification instead of the previous one enables flexible defense against eavesdropping attacks and hacker attacks.

As already explained, the respective device frame header can contain a target identification field with an identification of an addressee of the respective device frame, for example a CRC signature of a MAC address of one of the terminal devices or the control device. The respective device frame data field then contains user data for the addressee identified in the target identification field. The control device can be set up to write the device identification of the addressee into the target identification field of the respective device frame header, for example the address of the respective terminal device addressed in this way or of another control device. The terminal devices can be set up to write the device identification of the addressee into the target identification field of the device frame header, for example the address of the control device.

The destination identification field is advantageously smaller in bit size than the MAC address. The destination identification field can, for example, consist of less than four bytes or less than three bytes, but preferably comprises at least four bits or at least eight bits or one byte. A field size of two bytes has proven to be useful. With regard to the field size, the statements also apply to the source identification field in the header of the intermediate level frame.

The Ethernet network comprises network components which are set up for data communication in the form of Ethernet frames, wherein the Ethernet frames have the group identification field. The network components of a network according to the invention include at least a control device and several end devices, such as one or more sensors and/or actuators. The network comprises a first, a second, a third and a fourth end device, i.e. at least four end devices. The end devices are each connected to the control device. The network can also comprise one or more distributors, for example in the form of one or more switches. If the network comprises one or more distributors, the end devices or several of the end devices can be connected to the control device via the one or more distributors.

The network can be divided into at least two logical groups of terminals. In such embodiments, the first terminal and the second terminal are assigned a first group identification so that they belong to a first logical group. These two terminals are set up by the assignment of the first group identification to process data of the device frame data fields if the group identification field identifies the first group identification. The third terminal and the fourth terminal are assigned a second group identification so that they belong to a second logical group. By the assignment of the second group identification, the third terminal and the fourth terminal are set up to process data of the device frame data fields if the group identification field identifies a different, second group identification.

The terminal devices of the first logical group can be set up to process the payload data of the device frames if a group identification assigned to them by the control device, such as in particular the first group identification, is shown in the group identification field of the respective Ethernet frame and no further attention is paid if the group identification field shows an unassigned group identification, such as in particular the second group identification. The terminal devices of the second logical group can be set up to process the payload data of the device frames if a group identification assigned to them by the control device, such as in particular the second group identification, is shown in the group identification field of the respective Ethernet frame and no further attention is paid if the group identification field shows an unassigned group identification, such as in particular the first group identification. The respective terminal device is set up to read the group identification field and to recognize whether the bit sequence contained therein corresponds to the group identification assigned to it or identifies the Ethernet frame as a broadcast, if this option is provided as already explained. If this is the case, it processes the one or more device frames that are assigned to it by the device identification in the target identification field of the respective device frame. If the group identification does not match the assigned one and it is not a broadcast, if this option is provided, the respective Ethernet frame is ignored.

If the end devices are able to use the group identification to identify those Ethernet frames that are not intended for the respective end device, which is the case in preferred network designs, simple distributors can be used, since filtering of the Ethernet frames during distribution in the network is not necessary. On the other hand, if the network has one or more distributors, the network is relieved if the one or more distributors are set up to forward the respective Ethernet frame only to the end devices in the logical group whose group identification corresponds to the group identification shown in the group identification field. If the control device has set the group identification field to broadcast, if this option is implemented, the Ethernet frame marked as broadcast is forwarded to all end devices in the network. The distributor set up in this way can read the group identification field and filter the Ethernet frames accordingly, and only forward them to the addressed device group. The ability to differentiate and filter can be implemented, as preferred, only in the end devices or only in the distributor(s) or in both types of network components.

The control device is preferably set up to write either the first group identification or the second group identification or the bit sequence for a broadcast to all terminal devices in the network, if this option is available, into the group identification field of the intermediate level frame header of the respective Ethernet frame and thereby to identify the group of terminal devices for which the respective Ethernet frame is intended in the intermediate level frame header of the respective Ethernet frame.

Since grouping does not require any modification of the hardware and network connections, but is performed at the logical level, regrouping can be carried out flexibly by temporarily switching the control device to commissioning mode and reassigning the group identifications.

The groupability capability provided by the group identification field can be used to be used to divide the network into network areas, i.e. into device groups, with different levels of functional safety. In this way, end devices that meet the functional safety requirements can be assigned a first group identification, and one or more other end devices that do not meet the functional safety requirements can be assigned a different, second group identification. If a logical group only contains end devices that meet the functional safety requirements, the functional safety requirements of the control device can be reduced, at least for data communication with and optionally also between these end devices. If all end devices in the network meet the functional safety requirements, or if the network consists of one or more logical groups of only such end devices and one or more other logical groups in which no safety-relevant data needs to be exchanged, it is not necessary to use a control device that is classified as functionally safe. This significantly reduces the price of the control device. If the control device nevertheless meets the functional safety requirements, it is at least relieved of the burden of checking data integrity, since the functionally safe terminal devices themselves ensure data integrity with increased security and an equally high level of data integrity is not required in the other logical group(s).

The device frame header of the respective device frame can contain a control and status field (CTR & Status) with a safety value that informs the addressee of the respective device frame whether the respective device frame contains payload data relevant to functional safety. If one or more of the end devices, for example at least the first end device, meet the functional safety requirements, this or these end devices can each be set up to only process a device frame addressed to the respective end device if the safety value of the respective device frame indicates that this device frame contains payload data relevant to functional safety. For example, only one bit can be provided for the safety value, so that only the safety values "1" and "0" are distinguished, with one safety value standing for "safety-relevant" and the other for "not safety-relevant". This security feature can also be used to accelerate data communication in logical groups that include one or more functionally secure end devices, but also at least one functionally non-secure end device.

The control device and the terminal devices can each have a device identification, which, as explained above, can be, for example, a CRC signature of a MAC address of the respective terminal device or the control device. The device identification is created in such a way that it uniquely identifies the relevant network component in the network, i.e. distinguishes it from the other network components.

If the respective device frame header contains a target identification field to identify an addressee of the respective device frame, the control device and preferably also the respective terminal can be set up to read this device identification of the addressee in the target identification field and/or write it into the target identification field. If the intermediate level frame header contains a source identification field to identify the sender of the respective Ethernet frame, the control device and preferably also the respective terminal can be set up to read this device identification of the sender in the source identification field and/or write its own device identification into the source identification field.

If the Ethernet frame contains the combination of destination identification field and source identification field, this also enables data communication between end devices without switching on the control device. In this way, an end device, for example an actuator, can communicate directly with one or more other end devices, for example with one or more sensors, by generating and sending an Ethernet frame with one or more device frames, whereby this Ethernet frame contains the device identification of the sender in the source identification field and the device identification of the respective other end device in the destination identification field of the respective device frame. In addition, the sending end device can set a request for a response in the Ethernet frame, for example in the respective device frame. The sending end device is set up accordingly to set the request. Each directly addressed terminal receives and reads the Ethernet request frame of the sending terminal and generates and sends an Ethernet frame as a direct response by writing its own device identification into the source identification field of the Ethernet response frame and the device identification of the terminal that sent the request and its payload, such as measurement data, into the device frame(s) of the Ethernet response frame assigned to it.

The network components are field devices that are used at field level or are designed and intended for field use. The Data communication with the Ethernet frame according to the invention takes place at the field level.

The control device can be a control device or a controller for controlling and/or regulating one or more physical and/or chemical variables, such as temperature and/or pressure and/or volume flow and/or fill level and/or concentration and/or pH value. Instead, the control device can also be a pure monitoring device and/or logging device that monitors and/or logs a technical condition or process.

The network can be used to control and/or regulate and/or monitor a process engineering process, for example in food production or storage, such as the temperature control of a plant, or in chemistry or in production in general. The network can also form a system for recording the energy consumption of a building or for controlling or regulating the temperature(s) in a building, or be part of such a system.

The end devices can include one or more sensors, for example one or more temperature sensors and/or pressure sensors and/or volume flow sensors and/or pH sensors. A device frame for a sensor can be a request to send a measured value, for example a temperature or a pressure or a volume flow or a substance concentration or a pH value. An Ethernet frame sent by a sensor can contain payload data in the form of measurement data from the sensor in question in one or more device frames that are assigned to the respective sensor, for example temperature data or pressure data or volume flow data. The measurement data can be sent to the control device for controlling and/or regulating and/or monitoring a technical process or just monitoring the status of a technical system.

The terminal devices can comprise one or more actuators, such as one or more electric motors and/or one or more valves and/or one or more temperature control devices. An actuator can be an actuator in a control or regulating circuit. The control device can send, for example, a speed signal and/or a position signal and/or a temperature signal to the respective actuator in the associated device frame in order to set a speed and/or a position and/or a heat output of the actuator in question.

In a method according to the invention for data communication in a network, a control device is connected to several terminals, expediently via one or more distributors of the type mentioned. The control device and the respective terminal are set up for data exchange on the basis of the Ethernet frame explained, the Ethernet frame having the group identification field in advantageous embodiments. If the connection is made via one or more distributors, this preferably also applies to the respective distributor. If terminals are also connected to the control device that are not set up for data communication using the Ethernet frame, these terminals are not part of the network.

In a preferred method, the terminals are grouped into a first logical group of terminals and a second logical group of terminals by assigning a common first group identification to the terminals of the first logical group and a different, common second group identification to the terminals of the second logical group. The group assignment is preferably carried out by the control device. Once the group assignment has been made, a network component, namely a terminal of the network or in particular the control device, writes the first group identification in the intermediate level frame header of a first Ethernet frame in a phase of network operation and sends the first Ethernet frame in a first cycle of communication to at least the terminals of the first group. A network component, namely the same or another terminal of the network or in particular the control device, writes the second group identification in the intermediate level frame header of a second Ethernet frame and sends the second Ethernet frame in a second cycle of communication following the first cycle to at least the terminals of the second group. The second cycle can follow the first cycle immediately or only after one or more other cycles. The first cycle and the second cycle run in this order in an operating phase in which the described group assignment applies, but are otherwise not time-determined.

In a first variant of the process, as already explained for the network, the terminal devices are set up in such a way that they process payload data of the device frames if the assigned group identification or a broadcast is shown in the group identification field of the respective Ethernet frame, if the option of setting a broadcast in the group identification field is implemented. In the first variant of the process, the terminal devices are also set up in such a way that they no longer pay attention to the respective Ethernet frame if the group pen identification field indicates an unassigned group identification. In the first variant of the procedure, the Ethernet frames can be sent to all end devices regardless of the group identification set in the group identification field. Filtering by optional distributors is not necessary.

In the first cycle, the respective terminal device of the first logical group reads the group identification field of the first Ethernet frame, recognizes the bit sequence contained therein as the group identification assigned to it, and processes the one or more device frames that are assigned to the respective terminal device by the device identification in the target identification field of the respective device frame. If the first Ethernet frame contains a request for a response, for example the request for measurement data or other payload data, the respective terminal device of the first logical group writes the relevant payload data into the one or more device frames assigned to it and sends an Ethernet frame with its payload data back to the requesting device - control device or terminal device - as a response. The first cycle of communication is only completed when all terminal devices of the first logical group for which the first Ethernet frame contains one or more assigned device frames with a request have each sent an Ethernet frame as a response.

The end devices of the second logical group also receive the first Ethernet frame in the first cycle and read its group identification field, but recognize the bit sequence contained therein as unassigned group identification and therefore ignore the first Ethernet frame; device frames of the first Ethernet frame are not processed in the second logical group. The end devices of the second group also do not send an Ethernet response frame in the first cycle; the control device does not expect a response from these devices.

The second cycle runs in the same way: The respective terminal device of the second logical group reads the group identification field of the second Ethernet frame, recognizes the bit sequence contained therein as the group identification assigned to it and processes the one or more device frames that are assigned to the respective terminal device by the device identification in the target identification field of the respective device frame. If the second Ethernet frame contains a request for a response, for example to send measurement data or other payload data, the respective terminal device of the second logical group writes the relevant payload data into the one or more device frames assigned to it and sends an Ethernet frame with its payload data back to the requesting device - control device or terminal device - as a response. The second cycle of communication is only completed when all terminal devices of the second logical group for which the second Ethernet frame contains one or more assigned device frames with a request have each sent an Ethernet frame as a response.

The end devices of the first logical group also receive the second Ethernet frame in the second cycle and read its group identification field, but recognize the bit sequence contained therein as unassigned group identification and therefore ignore the second Ethernet frame; device frames of the second Ethernet frame are not processed in the first logical group. The end devices of the first group also do not send an Ethernet response frame in the second cycle; the control device does not expect a response from these devices.

If the network comprises one or more distributors and the one or more distributors are configured for selective forwarding of the Ethernet frames depending on the respective group identification, the method can be designed in a second method variant such that the respective distributor forwards the first Ethernet frame only to the end devices of the first logical group in the first cycle and the second Ethernet frame only to the end devices of the second logical group in the second cycle. In the second method variant, the first cycle is also ended when all end devices of the first logical group for which the first Ethernet frame contains one or more assigned device frames have each sent an Ethernet frame in response. The second cycle is correspondingly ended when all end devices of the second logical group for which the second Ethernet frame contains one or more assigned device frames have each sent an Ethernet frame in response.

In preferred embodiments, the terminal devices also receive the Ethernet frames of the other terminal devices. If a terminal device in the respective group has the corresponding "intelligence", it can be set up to read an Ethernet frame from another terminal device in the same group and to recognize whether the respective Ethernet frame contains user data that is relevant for the operation of the intelligent terminal device. For example, an actuator can recognize that a sensor relevant for the operation of the actuator is sending measurement data and process this measurement data directly without waiting for the control device to send an Ethernet frame with one or more device frames addressed to the actuator with the relevant measurement data. The control device and the network operation can be relieved in this regard.

1. 1. Ethernet-Frame zur Datenkommunikation in einem Netzwerk mit einem Kontrollgerät (1) und mehreren mit dem Kontrollgerät (1) verbundenen Endgeräten (11-14), das Ethernet-Frame (EF) umfassend:
   1. 1.1 einen Ethernet-Frame-Header (EFH) und ein Ethernet-Frame-Datenfeld (EFD);
   2. 1.2 mehrere im Ethernet-Frame-Datenfeld (EFD) enthaltene Geräte-Frames (DF11 - DF14), die einem oder mehreren der Endgeräte (11-14) zugeordnet sind;
   3. 1.3 wobei die Geräte-Frames (DF11 - DF14) jeweils ein Geräte-Frame-Datenfeld (DFD) mit zu verarbeitenden Nutzdaten und einen Geräte-Frame-Header (DFH) aufweisen; und
   4. 1.4 ein Zwischenlevel-Frame (LF), das im Ethernet-Frame-Datenfeld (EFD) enthalten ist, vorzugsweise das Ethernet-Frame-Datenfeld (EFD) bildet; wobei
   5. 1.5 das Zwischenlevel-Frame (LF) ein Zwischenlevel-Frame-Datenfeld (LFD) mit den mehreren Geräte-Frames (DF11 - DF14) und
   6. 1.6 einen für die Geräte-Frames (DF11 - DF14) gemeinsamen Zwischenlevel-Frame-Header (LFH) aufweist.
2. 2. Ethernet-Frame nach dem vorhergehenden Aspekt, wobei der jeweilige Geräte-Frame-Header (DFH) ein Ziel-Identifikationsfeld (DestinationlD) mit einer Identifikation eines Adressaten (1, 11, 12, 13, 14) des jeweiligen Geräte-Frames (DF11 - DF14), beispielsweise eine CRC-Signatur einer MAC-Adresse eines der Endgeräte (11-14) oder des Kontrollgeräts (1), und das jeweilige Geräte-Frame-Datenfeld (DFD) Nutzdaten für den im Ziel-Identifikationsfeld identifizierten Adressaten (1, 11, 12, 13, 14) enthalten.
3. 3. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei der Zwischenlevel-Frame-Header (LFH) ein Quellen-Identifikationsfeld (SourcelD) mit einer Identifikation eines Senders des Ethernet-Frames (EF) enthält, wobei die Identifikation des Senders beispielsweise eine CRC-Signatur seiner MAC-Adresse sein kann.
4. 4. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei der Zwischenlevel-Frame-Header (LFH) ein Gruppen-Identifikationsfeld (GroupID) mit einer Gruppenidentifikation (Gr1, Gr2) enthält, die die im Zwischenlevel-Frame (LF) enthaltenen Geräte-Frames (DF11 - DF14) als Geräte-Frames einer zusammengehörenden Gruppe von Endgeräten identifiziert, so dass die Endgeräte (11-14) durch Zuteilung jeweils einer bestimmten Gruppenidentifikation in unterschiedliche logische Gruppen von Endgeräten einteilbar sind.
5. 5. Ethernet-Frame nach dem vorhergehenden Aspekt, wobei das Gruppen-Identifikationsfeld (GroupID) anstelle einer bestimmten Gruppenidentifikation (Gr1, Gr2) eine Bitfolge für ein Broadcast an alle mit dem Kontrollgerät (1) verbundenen Endgeräte (11-14) enthält.
6. 6. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei das Zwischenlevel-Frame ein CRC-Prüffeld (IfhCRC) zur Absicherung des Zwischenlevel-Frame-Headers (LFH) enthält.
7. 7. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei das Geräte-Frame (DF) ein CRC-Prüffeld (dfhCRC) zur Absicherung des Geräte-Frame-Headers (DFH) enthält.
8. 8. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei das Geräte-Frame (DF) ein CRC-Prüffeld (dfdCRC) zur Absicherung des Geräte-Frame-Datenfelds (DFD) enthält.
9. 9. Ethernet-Frame nach einer Kombination von wenigstens zwei der Aspekte 6 bis 8, wobei die CRC-Prüffelder jeweils einen CRC-Wert enthalten und die CRC-Werte von wenigstens zwei der CRC-Prüffelder auf unterschiedlichen Generatorpolynomen beruhen.
10. 10. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei der Zwischenlevel-Frame-Header (LFH) ein Ethernet-Frame-Zählfeld (MsgCnt) mit einer Ethernet-Frame-Nummer enthält, die in einer Sequenz zeitlich aufeinander folgend gesendeter Ethernet-Frames (EF) die Stellung des jeweiligen Ethernet-Frames (EF) angibt, wobei das Kontrollgerät (1) dazu eingerichtet ist, die Ethernet-Frame-Nummer zu inkrementieren und die Ethernet-Frame-Nummer durch die Endgeräte (11-14) vorzugsweise nicht veränderbar ist.
11. 11. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei der Geräte-Frame-Header (DFH), ein Geräte-Frame-Zählfeld (seqCnt) mit einer Geräte-Frame-Nummer enthält, die in einer Sequenz zeitlich aufeinander folgend an das gleiche Endgerät gesendeter Geräte-Frames (DF) die Stellung des jeweiligen Geräte-Frames (DF) angibt, wobei das Kontrollgerät (1) dazu eingerichtet ist, die Geräte-Frame-Nummer beim Senden des jeweiligen Geräte-Frames (DF) zu inkrementieren und die Endgeräte (11-14) dazu eingerichtet sind, die Geräte-Frame-Nummer umzuformen, beispielsweise zu invertieren.
12. 12. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei der Zwischenlevel-Frame-Header (LFH) ein Ethernet-Frame-Modusfeld (MsgType) zur Identifizierung eines bestimmten Kommunikationsmodus aus mehreren wahlweise vorgebbaren unterschiedlichen Kommunikationsmodi (Discovery, Commissioning, Cyclic Data, Set, Get, RPC) einschließlich eines Inbetriebnahme-Modus (Commissioning) enthält, wobei das Ethernet-Frame-Modusfeld (MsgType) bei Auswahl des Inbetriebnahme-Modus den Zwischenlevel-Frame-Header (LFH) als Header für die Konfigurierung der Endgeräte (11-14) und/oder die im Zwischenlevel-Frame-Datenfeld (LFD) enthaltenen Geräte-Frames (DF11 - DF14) als Geräte-Frames für die Konfigurierung der Endgeräte (11-14) identifiziert.
13. 13. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei der Zwischenlevel-Frame-Header (LFH) ein Ethernet-Frame-Modusfeld (MsgType) zur Identifizierung eines bestimmten Kommunikationsmodus aus mehreren wahlweise vorgebbaren unterschiedlichen Kommunikationsmodi (Discovery, Commissioning, Cyclic Data, Set, Get, RPC) einschließlich eines Zyklusbetrieb-Modus (Cyclic Data) enthält, wobei das Ethernet-Frame-Modusfeld (MsgType) bei Auswahl des Zyklus-Modus den Zwischenlevel-Frame-Header (LFH) als Header für die zyklische Datenübertragung und die im Zwischenlevel-Frame-Datenfeld (LFD) enthaltenen Geräte-Frames (DF11 - DF14) als Geräte-Frames mit Prozessdaten für die Endgeräte (11-14) oder von den Endgeräten (11-14) identifiziert.
14. 14. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei der Geräte-Frame-Header (DFH) des jeweiligen Geräte-Frames (DF11 - DF14) ein Kontroll-und-Status-Feld (CTR & Status) mit einem Safety-Wert enthält und der Safety-Wert (z.B.1 Bit) dem Adressaten des jeweiligen Geräte-Frames (DF11 - DF14) mitteilt, ob das jeweilige Geräte-Frame (DF11-DF14) für die funktionale Sicherheit relevante Nutzdaten enthält.
15. 15. Ethernet-Frame nach dem vorhergehenden Aspekt, wobei mehrere der Geräte-Frames (DF11 - DF14) für die funktionale Sicherheit relevante Daten enthalten und die Safety-Werte dieser Geräte-Frames (DF11 - DF14) dies anzeigen.
16. 16. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei der Geräte-Frame-Header (DFH) des jeweiligen Geräte-Frames (DF11 - DF14) ein Kontroll-und-Status-Feld (CTR & Status) mit einem Anforderung/Antwort-Wert (z.B.1 Bit) enthält und der Anforderung/Antwort-Wert dem Adressaten des jeweiligen Geräte-Frames (DF11 - DF14) mitteilt, ob das jeweilige Geräte-Frame eine Anforderung zum Senden von Nutzdaten ist oder die im Geräte-Frame-Datenfeld des jeweiligen Geräte-Frames (DF11 - DF14) enthaltenen Nutzdaten als Antwort auf eine Anforderung gesendet werden.
17. 17. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei der Geräte-Frame-Header (DFH) des jeweiligen Geräte-Frames (DF11 - DF14) ein Kontroll-und-Status-Feld (CTR & Status) mit einem Synchronisationswert (TimeSync, z.B.1 Bit) enthält, der dem Adressaten des jeweiligen Geräte-Frames anzeigt, ob das jeweilige Geräte-Frame der Synchronisation der Geräteuhr des adressierten oder sendenden Endgeräts auf die Geräteuhr des Kontrollgeräts (1) dient.
18. 18. Ethernet-Frame nach dem vorhergehenden Aspekt, wobei das Zwischenlevel-Frame-Datenfeld (LFD) mehrere Geräte-Frames für das gleiche Endgerät enthält und der Synchronisationswert eines der an das gleiche Endgerät gerichteten Geräte-Frames auf Zeitsynchronisation gesetzt ist und der Synchronisationswert eines anderen der an das gleiche Endgerät gerichteten Geräte-Frames nicht auf Zeitsynchronisation gesetzt ist.
19. 19. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei der jeweilige Geräte-Frame-Header (DFH) ein Kontroll-und-Status-Feld (CTR & Status) mit einem oder mehreren Run/Stop-Bits enthält und der Inhalt des einen oder der mehreren Run/Stop-Bits dem Adressaten des jeweiligen Geräte-Frames im aktiven Betrieb hält oder in einen Ruhezustand versetzt.
20. 20. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei der jeweilige Geräte-Frame-Header (DFH) ein Kontroll-und-Status-Feld (CTR & Status) mit einem Fehlerstatusfeld (DataCRCErr) zum Anzeigen des Feststellens eines Fehlers in den Daten des Zwischenlevel-Frame-Headers (LFH) und/oder in den Daten des Geräte-Frame-Headers (DFH) und/oder in den Daten des Geräte-Frame-Datenfelds (DFD) enthält.
21. 21. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei das Zwischenlevel-Frame-Datenfeld (LFD) mehrere Geräte-Frames für das gleiche Endgerät enthält.
22. 22. Ethernet-Frame nach einem der vorhergehenden Aspekte, wobei wenigstens ein Geräte-Frame (DF11) der mehreren Geräte-Frames einem ersten Endgerät (11) und ein anderes Geräte-Frame (DF12) der mehreren Geräte-Frames einem anderen, zweiten Endgerät (12) zugeordnet sind.
23. 23. Ethernet-fähiges Netzwerk wenigstens mit folgenden Netzwerkkomponenten, die zur Datenkommunikation in Form von Ethernet-Frames (EF) nach einem der vorhergehenden Aspekte eingerichtet sind:
    1. 23.1 ein Kontrollgerät (1), das dazu eingerichtet ist, ein Ethernet-Frame nach einem der vorhergehenden Ansprüche als Ethernet-Anforderungs-Frame (EF1) mit einer das Kontrollgerät (1) identifizierenden Geräteidentifikation im Quellen-Identifikationsfeld (SourcelD) des Zwischenlevel-Frames (LF1) zu erzeugen und zu versenden;
    2. 23.2 optional einen oder mehrere Verteiler (3); und
    3. 23.3 ein erstes Endgerät (11) und ein zweites Endgerät (12), die mit dem Kontrollgerät (1) verbunden sind, vorzugsweise über den einen oder die mehreren optionalen Verteiler (3);
    4. 23.4 wobei das Kontrollgerät (1) dazu eingerichtet ist, in das Ziel-Identifikationsfeld (DestinationlD) des jeweiligen Geräte-Frames (DF11req, DF12req) des Ethernet-Anforderungs-Frames (EF1) eine Geräteidentifikation zu schreiben, die das Endgerät, für das das jeweilige Geräte-Frame (DF11req, DF12req) bestimmt ist, identifiziert;
    5. 23.5 und wobei jedes der Endgeräte (11, 12) dazu eingerichtet ist, das Ethernet-Anforderungs-Frame (EF1) zu empfangen, zu verarbeiten und ein Ethernet-Frame nach einem der vorhergehenden Ansprüche als Ethernet-Antwort-Frame (EF11, EF12) mit einer das jeweilige Endgerät (11, 12) identifizierenden Geräteidentifikation im Quellen-Identifikationsfeld (SourcelD) des jeweiligen Geräte-Frames (DF11resp, DF12resp) des Ethernet-Antwort-Frames (EF11, EF12) zu erzeugen und zu versenden.
24. 24. Ethernet-fähiges Netzwerk nach dem vorhergehenden Aspekt, wobei das jeweilige Endgerät (11, 12) dazu eingerichtet ist, die Geräteidentifikation des Kontrollgeräts (1) in das Ziel-Identifikationsfeld (DestinationID) des jeweiligen Geräte-Frames (DF11resp, DF12resp) seines Ethernet-Antwort-Frames (EF11, EF12) zu schreiben.
25. 25. Ethernet-fähiges Netzwerk nach einem der zwei unmittelbar vorhergehenden Aspekte, wobei
    • 25.1 die Netzwerkkomponenten zur Datenkommunikation in Form von Ethernet-Frames (EF) nach einem der vorhergehenden Aspekte jeweils in Kombination mit Aspekt 4 eingerichtet sind,
    • 25.2 dem ersten Endgerät (11) und dem zweiten Endgerät (12) eine gemeinsame erste Gruppenidentifikation (Gr1) zugeteilt ist, so dass sie einer ersten logischen Gruppe angehören,
    • 25.3 das erste Endgerät (11) und das zweite Endgerät (12) durch die Zuteilung der ersten Gruppenidentifikation (Gr1) dazu eingerichtet sind, Daten der Geräte-Frame-Datenfelder (DFD) zu verarbeiten, wenn das Gruppen-Identifikationsfeld (GroupID) die erste Gruppenidentifikation (Gr1) ausweist;
    • 25.4 dem dritten Endgerät (13) und dem vierten Endgerät (14) eine gemeinsame zweite Gruppenidentifikation (Gr2) zugeteilt ist, so dass sie einer zweiten logischen Gruppe angehören,
    • 25.5 das dritte Endgerät (13) und das vierte Endgerät (14) durch die Zuteilung der zweiten Gruppenidentifikation (Gr2) dazu eingerichtet sind, Daten der Geräte-Frame-Datenfelder (DFD) zu verarbeiten, wenn das Gruppen-Identifikationsfeld (GroupID) die zweite Gruppenidentifikation (Gr2) ausweist; und wobei
    • 25.6 die Endgeräte (11, 12) der ersten logischen Gruppe dazu eingerichtet sind, die Nutzdaten der Geräte-Frames (DF) nur zu verarbeiten, wenn im Gruppen-Identifikationsfeld (GroupID) des jeweiligen Ethernet-Frames (EF1) die erste Gruppenidentifikation (Gr1) oder ein Broadcast ausgewiesen ist, und
    • 25.7 die Endgeräte (13, 14) der zweiten logischen Gruppe dazu eingerichtet sind, die Nutzdaten der Geräte-Frames (DF) nur zu verarbeiten, wenn im Gruppen-Identifikationsfeld (GroupID) des jeweiligen Ethernet-Frames (EF2) die zweite Gruppenidentifikation (Gr2) oder ein Broadcast ausgewiesen ist.
26. 26. Ethernet-fähiges Netzwerk wenigstens mit folgenden Netzwerkkomponenten, die zur Datenkommunikation in Form von Ethernet-Frames (EF) nach einem der vorhergehenden Aspekte jeweils in Kombination mit Aspekt 4 eingerichtet sind:
    1. 26.1 ein Kontrollgerät (1);
    2. 26.2 optional einen oder mehrere Verteiler (3);
    3. 26.3 ein erstes Endgerät (11) und ein zweites Endgerät (12), die mit dem Kontrollgerät (1) verbunden sind, vorzugsweise über den einen oder die mehreren optionalen Verteiler (3), und denen eine erste Gruppenidentifikation (Gr1) zugeteilt ist, so dass sie einer ersten logischen Gruppe angehören, und die durch die Zuteilung der ersten Gruppenidentifikation (Gr1) dazu eingerichtet sind, Daten der Geräte-Frame-Datenfelder (DFD) zu verarbeiten, wenn das Gruppen-Identifikationsfeld (GroupID) die erste Gruppenidentifikation (Gr1) ausweist;
    4. 26.4 ein drittes Endgerät (13) und ein viertes Endgerät (14), die mit dem Kontrollgerät (1) verbunden sind, vorzugsweise über den einen oder die mehreren optionalen Verteiler (3), und denen eine zweite Gruppenidentifikation (Gr2) zugeteilt ist, so dass sie einer zweiten logischen Gruppe angehören, und die durch die Zuteilung der zweiten Gruppenidentifikation (Gr2) dazu eingerichtet sind, Daten der Geräte-Frame-Datenfelder (DFD) zu verarbeiten, wenn das Gruppen-Identifikationsfeld (GroupID) eine andere, zweite Gruppenidentifikation (Gr2) ausweist;
    5. 26.5 wobei der oder die Verteiler (3), f dazu eingerichtet ist oder sind, das jeweilige Ethernet-Frame (EF1, EF2) an die Endgeräte (11-14) der ersten logischen Gruppe nur weiterzuleiten, wenn die erste Gruppenidentifikation (Gr1) oder ein Broadcast im Gruppen-Identifikationsfeld (GroupID) ausgewiesen ist, und das jeweilige Ethernet-Frame (EF1, EF2) an die Endgeräte (11-14) der zweiten logischen Gruppe nur weiterzuleiten, wenn die zweite Gruppenidentifikation (Gr2) oder ein Broadcast im Gruppen-Identifikationsfeld (Group ID) ausgewiesen ist; und/oder
    6. 26.6 die Endgeräte (11, 12) der ersten logischen Gruppe dazu eingerichtet sind, die Nutzdaten der Geräte-Frames (DF) nur zu verarbeiten, wenn im Gruppen-Identifikationsfeld (GroupID) des jeweiligen Ethernet-Frames (EF1) die erste Gruppenidentifikation (Gr1) oder ein Broadcast ausgewiesen ist, und die Endgeräte (13, 14) der zweiten logischen Gruppe dazu eingerichtet sind, die Nutzdaten der Geräte-Frames (DF) nur zu verarbeiten, wenn im Gruppen-Identifikationsfeld (GroupID) des jeweiligen Ethernet-Frames (EF2) die zweite Gruppenidentifikation (Gr2) oder ein Broadcast ausgewiesen ist.
27. 27. Ethernet-fähiges Netzwerk nach einem der Aspekte 23 bis 26, wobei das Kontrollgerät (1) dazu eingerichtet ist, in das Gruppen-Identifikationsfeld (Group ID) des jeweiligen Ethernet-Frames (EF1, EF2) wahlweise die erste Gruppenidentifikation (Gr1) oder die zweite Gruppenidentifikation (Gr2) zu schreiben.
28. 28. Ethernet-fähiges Netzwerk nach einem der der Aspekte 23 bis 27, wobei das Kontrollgerät (1) und die Endgeräte (11-14) jeweils eine Geräteidentifikation haben und der jeweilige Geräte-Frame-Header (DFH) ein Ziel-Identifikationsfeld (DestinationID) mit der Geräteidentifikation eines Adressaten (1, 11, 12, 13, 14) des jeweiligen Geräte-Frames (DF11 - DF14), beispielsweise eine CRC-Signatur einer MAC-Adresse eines der Endgeräte (11-14) oder des Kontrollgeräts (1), und das jeweilige Geräte-Frame-Datenfeld (DFD) Nutzdaten für den im Ziel-Identifikationsfeld identifizierten Adressaten (1, 11, 12, 13, 14) enthalten, und wobei das Kontrollgerät (1) und vorzugsweise auch das jeweilige Endgerät (11-14) dazu eingerichtet ist/sind, die Geräteidentifikation des Adressaten im Ziel-Identifikationsfeld (DestinationlD) zu lesen und/oder in das Ziel-Identifikationsfeld (DestinationlD) zu schreiben.
29. 29. Ethernet-fähiges Netzwerk nach einem der der Aspekte 23 bis 28, wobei das Kontrollgerät (1) und die Endgeräte (11-14) jeweils eine Geräteidentifikation haben und der Zwischenlevel-Frame-Header (LFH) ein Quellen-Identifikationsfeld (SourcelD) mit der Geräteidentifikation des Senders des jeweiligen Ethernet-Frames (EF) enthält, und wobei das Kontrollgerät (1) und vorzugsweise auch das jeweilige Endgerät (11-14) dazu eingerichtet ist/sind, die Geräteidentifikation des Senders im Quellen-Identifikationsfeld (SourcelD) zu lesen und/oder die eigene Geräteidentifikation in das Quellen-Identifikationsfeld (SourcelD) zu schreiben.
30. 30. Ethernet-fähiges Netzwerk nach einem der der Aspekte 23 bis 29, wobei die erste Gruppenidentifikation (Gr1) nur Endgeräten (11, 12) zugeteilt ist, die die Anforderungen der funktionalen Sicherheit erfüllen, und die zweite Gruppenidentifikation (Gr2) einem oder mehreren oder nur Endgeräten (13, 14) zugeteilt ist, die die Anforderungen der funktionalen Sicherheit nicht erfüllen, so dass das Netzwerk aufgrund der Zuteilung der Gruppenidentifikationen (Gr1, Gr2) in Netzwerkbereiche unterschiedlicher funktionaler Sicherheit unterteilt ist.
31. 31. Ethernet-fähiges Netzwerk nach einem der der Aspekte 23 bis 30, wobei der Geräte-Frame-Header (DFH) des jeweiligen Geräte-Frames (DF11 - DF14) ein Kontroll-und-Status-Feld (CTR & Status) mit einem Safety-Wert (z.B.1 Bit) enthält, der dem Adressaten des jeweiligen Geräte-Frames (DF11 - DF14) mitteilt, ob das jeweilige Geräte-Frame (DF11 - DF14) für die funktionale Sicherheit relevante Nutzdaten enthält, und wobei wenigstens das erste Endgerät (11) die Anforderungen der funktionalen Sicherheit erfüllt und dazu eingerichtet ist, ein an das erste Endgerät (11) adressiertes Geräte-Frame (DF11) nur dann zu verarbeiten, wenn der Safety-Wert des jeweiligen, dem ersten Endgerät (11) zugeordneten Geräte-Frames (DF11) anzeigt, dass dieses Geräte-Frame für die funktionale Sicherheit relevante Nutzdaten enthält.
32. 32. Ethernet-fähiges Netzwerk wenigstens mit folgenden Netzwerkkomponenten, die zur Datenkommunikation in Form von Ethernet-Frames (EF) nach einem der vorhergehenden Aspekte eingerichtet sind:
    • 32.1 ein Kontrollgerät (1);
    • 32.2 optional einen oder mehrere Verteiler (3); und
    • 32.3 ein erstes Endgerät (11) und ein zweites Endgerät (12), die mit dem Kontrollgerät (1) verbunden sind, vorzugsweise über den einen oder die mehreren optionalen Verteiler (3); wobei
    • 32.4 das Zwischenlevel-Frame ein CRC-Prüffeld (IfhCRC) zur Absicherung des Zwischenlevel-Frame-Headers (LFH) und/oder das Geräte-Frame (DF) ein CRC-Prüffeld (dfhCRC) zur Absicherung des Geräte-Frame-Headers (DFH) und/oder das Geräte-Frame (DF) ein CRC-Prüffeld (dfdCRC) zur Absicherung des Geräte-Frame-Datenfelds (DFD) enthält/enthalten;
    • 32.5 der Geräte-Frame-Header (DFH) des jeweiligen Geräte-Frames (DF11 - DF14) ein Fehlerstatusfeld (DataCRCErr) zum Anzeigen des Feststellens eines Fehlers in den Daten des Zwischenlevel-Frame-Headers (LFH) und/oder des Geräte-Frame-Headers (DFH) und/oder des Geräte-Frame-Datenfelds (DFD) enthält;
    • 32.6 das Kontrollgerät (1) dazu eingerichtet ist, ein Ethernet-Frame (EF) mit einer Anforderung einer Antwort in einem oder mehreren der Geräte-Frames (DF) zu senden;
    • 32.7 und eines oder mehrere der Endgeräte (11-14) dazu eingerichtet ist oder sind, - die Datenintegrität des Zwischenlevel-Frame-Headers (LFH) anhand des Inhalts des CRC-Prüffelds (IfhCRC) für den Zwischenlevel-Frame-Header (LFH) und/oder die Datenintegrität des jeweils zugeordneten Geräte-Frame-Headers (DFH) anhand des Inhalts des CRC-Prüffelds (dfhCRC) für den Geräte-Frame-Header (DFH) und/oder die Datenintegrität des jeweils zugeordneten Geräte-Frame-Datenfelds (DFD) anhand des Inhalts des CRC-Prüffelds (dfdCRC) für das Geräte-Frame-Datenfeld (DFD) zu prüfen,
      • - bei Feststellung eines Datenfehlers im Fehlerstatusfeld (DataCRCErr) einen Fehlerwert zu setzen, und
      • - ein Ethernet-Frame (EF), das den Fehlerwert im Fehlerstatusfeld (DataCRCErr) enthält, als Antwort an das Kontrollgerät (1) zu senden.
33. 33. Ethernet-fähiges Netzwerk nach dem vorhergehenden Aspekt und einem der Aspekte 23 bis 31.
34. 34. Ethernet-fähiges Netzwerk nach einem der Aspekte 23 bis 33, wobei das Kontrollgerät (1) und die Endgeräte (11-14) Feldgeräte sind und die Datenkommunikation im Netzwerk auf der Feldebene erfolgt.
35. 35. Ethernet-fähiges Netzwerk nach einem der Aspekte 23 bis 34, wobei die Endgeräte (11-14) einen oder mehrere Sensoren (11, 13), beispielsweise einen oder mehrere Temperatursensoren und/oder Drucksensoren und/oder Volumenstromsensoren und/oder pH-Sensoren und/oder Konzentrationssensoren, und/oder einen oder mehrere Aktoren (12, 14), beispielsweise einen oder mehrere Motoren und/oder Ventile und/oder Heizeinrichtungen, und/oder einen oder mehrere Regler, beispielsweise Temperatur-Steuer- oder Regelgeräte und/oder Druck-Steuer- oder Regelgeräte und/oder Volumenstrom-Steuer- oder Regelgeräte, und/oder einen oder mehrere Monitore (4) umfassen.
36. 36. Ethernet-fähiges Netzwerk nach einem der Aspekte 23 bis 35, wobei das Netzwerk ein System oder Bestandteil eines Systems zur Erfassung des Energieverbrauchs eines Gebäudes oder zur Steuerung oder Regelung der Temperatur(en) in einem Gebäude ist.
37. 37. Ethernet-fähiges Netzwerk nach einem der Aspekte 23 bis 35, wobei das Netzwerk ein System oder Bestandteil eines Systems zur Erfassung, vorzugsweise Überwachung, und/oder Steuerung oder Regelung einer oder mehrerer physikalischer und/oder chemischer Größen in einer Anlage der technischen Verfahrenstechnik ist.
38. 38. Verfahren zur Datenkommunikation in einem Ethernet-fähigen Netzwerk, in dem Netzwerkkomponenten umfassend ein Kontrollgerät (1) und mehrere Endgeräte (11-14) für die Datenkommunikation verbunden sind, vorzugsweise über einen oder mehrere optionale(n) Verteiler (3) des Netzwerks, und bei dem
    • 38.1 die Netzwerkkomponenten (1, 3, 11-14) für einen Datenaustausch in Form von Ethernet-Frames (EF) nach einem der vorhergehenden Aspekte eingerichtet sind;
    • 38.2 das Kontrollgerät (1) ein Ethernet-Frame nach einem der vorhergehenden Ansprüche als Ethernet-Anforderungs-Frame (EF1) erzeugt und sendet;
    • 38.3 das Kontrollgerät (1) bei der Erzeugung des Ethernet-Anforderungs-Frames (EF1) in das Quellen-Identifikationsfeld (SourcelD) des Zwischenlevel-Frames (LF1) eine das Kontrollgerät (1) identifizierende Geräteidentifikation schreibt und in das Ziel-Identifikationsfeld (DestinationlD) des jeweiligen Geräte-Frames (DF11, DF12) eine Geräteidentifikation schreibt, die das Endgerät, für das das jeweilige Geräte-Frame (DF11, DF12) bestimmt ist, identifiziert;
    • 38.4 und die Endgeräte (11-14) das Ethernet-Anforderungs-Frame (EF1) empfangen, verarbeiten und jeweils ein Ethernet-Frame nach einem der vorhergehenden Aspekte als Ethernet-Antwort-Frame (EF11, EF12) mit einer das jeweilige Endgerät identifizierenden Geräteidentifikation im Quellen-Identifikationsfeld (SourcelD) des jeweiligen Geräte-Frames (DF11 resp, DF12resp) des Ethernet-Antwort-Frames (EF11, EF12) erzeugen und senden.
39. 39. Verfahren nach dem vorhergehenden Aspekt, wobei das jeweilige Endgerät bei der Erzeugung seines Ethernet-Antwort-Frames (EF11, EF12) die Geräteidentifikation des Kontrollgeräts (1) in das Ziel-Identifikationsfeld (DestinationlD) des jeweiligen Geräte-Frames (DF11resp, DF12resp) seines Ethernet-Antwort-Frames (EF11, EF12) schreibt.
40. 40. Verfahren nach einem der zwei unmittelbar vorhergehenden Aspekte, bei dem
    • 40.1 die Netzwerkkomponenten (1, 3, 11-14) zur Datenkommunikation in Form von Ethernet-Frames (EF) nach einem der vorhergehenden Aspekte jeweils in Kombination mit Aspekt 4 eingerichtet sind;
    • 40.2 die Endgeräte (11-14) in eine erste logische Gruppe von Endgeräten (11, 12) und eine zweite logische Gruppe von Endgeräten (13, 14) gruppiert werden, indem
    • 40.3 den Endgeräten (11, 12) der ersten logischen Gruppe eine gemeinsame erste Gruppenidentifikation (Gr1) und den Endgeräten (13, 14) der zweiten logischen Gruppe eine andere, gemeinsame zweite Gruppenidentifikation (Gr2) zugewiesen wird;
    • 40.4 eine Netzwerkkomponente, vorzugsweise das Kontrollgerät (1), die erste Gruppenidentifikation (Gr1) in den Zwischenlevel-Frame-Header (LFH) eines ersten Ethernet-Frames (EF1) schreibt und das erste Ethernet-Frame (EF1) in einem ersten Zyklus der Datenkommunikation an die Endgeräte (11-14) sendet;
    • 40.5 das jeweilige Endgerät (11, 12) der ersten logischen Gruppe das Gruppen-Identifikationsfeld (GroupID) des ersten Ethernet-Frames (EF1) liest, die darin enthaltene Bitfolge als die ihm zugewiesene Gruppenidentifikation (Gr1) erkennt und das eine oder die mehreren Geräte-Frames, das oder die dem jeweiligen Endgerät durch die Geräteidentifikation im Ziel-Identifikationsfeld (DestinationlD) des jeweiligen Geräte-Frames zugeordnet ist/sind, verarbeitet; und bei dem
    • 40.6 das jeweilige Endgerät (13,14) der zweiten logischen Gruppe das Gruppen-Identifikationsfeld des ersten Ethernet-Frames (EF1) liest, die darin enthaltene Bitfolge als eine ihm nicht zugewiesene Gruppenidentifikation (Gr1) erkennt und deshalb das erste Ethernet-Frame (EF1) nicht verarbeitet.
41. 41. Verfahren zur Datenkommunikation in einem Ethernet-fähigen Netzwerk, in dem Netzwerkkomponenten umfassend ein Kontrollgerät (1), mehrere Endgeräte (11-14) und optional einen oder mehrere Verteiler (3) für die Datenkommunikation miteinander verbunden sind, bei dem
    • 41.1 die Netzwerkkomponenten (1, 3, 11-14) für einen Datenaustausch in Form von Ethernet-Frames (EF) nach einem der vorhergehenden Aspekte jeweils in Kombination mit Aspekt 4 eingerichtet sind;
    • 41.2 die Endgeräte (11-14) in eine erste logische Gruppe von Endgeräten (11, 12) und eine zweite logische Gruppe von Endgeräten (13, 14) gruppiert werden, indem
    • 41.3 den Endgeräten (11, 12) der ersten logischen Gruppe eine gemeinsame erste Gruppenidentifikation (Gr1) und den Endgeräten (13, 14) der zweiten logischen Gruppe eine andere, gemeinsame zweite Gruppenidentifikation (Gr2) zugewiesen wird;
    • 41.4 eine Netzwerkkomponente, vorzugsweise das Kontrollgerät (1), die erste Gruppenidentifikation (Gr1) in den Zwischenlevel-Frame-Header (LFH) eines ersten Ethernet-Frames (EF1) schreibt und das erste Ethernet-Frame (EF1) in einem ersten Zyklus (T₁) der Datenkommunikation an die Endgeräte (11-14) sendet;
    • 41.5 das jeweilige Endgerät (11, 12) der ersten logischen Gruppe das Gruppen-Identifikationsfeld (GroupID) des ersten Ethernet-Frames (EF1) liest, die darin enthaltene Bitfolge als die ihm zugewiesene Gruppenidentifikation (Gr1) erkennt und das eine oder die mehreren Geräte-Frames, das oder die dem jeweiligen Endgerät durch die Geräteidentifikation im Ziel-Identifikationsfeld (DestinationID) des jeweiligen Geräte-Frames zugeordnet ist/sind, verarbeitet; und bei dem
    • 41.6 das jeweilige Endgerät (13,14) der zweiten logischen Gruppe das Gruppen-Identifikationsfeld des ersten Ethernet-Frames (EF1) liest, die darin enthaltene Bitfolge als eine ihm nicht zugewiesene Gruppenidentifikation (Gr1) erkennt und deshalb das erste Ethernet-Frame (EF1) nicht verarbeitet.
42. 42. Verfahren zur Datenkommunikation in einem Ethernet-fähigen Netzwerk, in dem Netzwerkkomponenten umfassend ein Kontrollgerät (1) und mehrere Endgeräte (11-14) über einen oder mehrere Verteiler (3) für die Datenkommunikation verbunden sind, bei dem
    • 42.1 die Netzwerkkomponenten (1, 3, 11-14) für einen Datenaustausch in Form von Ethernet-Frames (EF1, EF2) nach einem der vorhergehenden Aspekte jeweils in Kombination mit Aspekt 4 eingerichtet sind;
    • 42.2 die Endgeräte (11-14) in eine erste logische Gruppe von Endgeräten (11, 12) und eine zweite logische Gruppe von Endgeräten (13, 14) gruppiert werden, indem
    • 42.3 den Endgeräten (11, 12) der ersten logischen Gruppe eine gemeinsame erste Gruppenidentifikation (Gr1) und den Endgeräten (13, 14) der zweiten logischen Gruppe eine andere, gemeinsame zweite Gruppenidentifikation (Gr2) zugewiesen wird;
    • 42.4 der jeweilige Verteiler (3) für eine selektive Weiterleitung der Ethernet-Frames (EF1, EF2) in Abhängigkeit von der jeweiligen Gruppenidentifikation (Gr1, Gr2) konfiguriert wird;
    • 42.5 eine Netzwerkkomponente, vorzugsweise das Kontrollgerät (1), die erste Gruppenidentifikation (Gr1) in den Zwischenlevel-Frame-Header (LFH) eines ersten Ethernet-Frames (EF1) schreibt und das erste Ethernet-Frame (EF1) in einem ersten Zyklus (T₁) der Datenkommunikation an den oder die Verteiler (3) sendet; und
    • 42.6 der jeweilige Verteiler (3) das erste Ethernet-Frame (EF1) nur an die Endgeräte (11, 12) der ersten logischen Gruppe weiterleitet.
43. 43. Verfahren nach einem der Aspekte 41 und 42, bei dem
    • 43.1 eines oder mehrere der Geräte-Frames des ersten Ethernet-Frames (EF1) eine Anforderung (Request) zum Senden von Nutzdaten enthält oder jeweils enthalten;
    • 43.2 das jeweilige Endgerät (11, 12) der ersten logischen Gruppe, dem im ersten Ethernet-Frame (EF1) ein oder mehrere Geräte-Frames mit einer Anforderung zugeordnet ist/sind, die angeforderten Nutzdaten in das jeweilige die Anforderung enthaltende, zugeordnete Geräte-Frame schreibt und
    • 43.3 ein Ethernet-Frame (EF11, EF12) mit seinen Nutzdaten als Antwort als an die anfordernde Netzwerkkomponente (1) sendet; und
    • 43.4 der erste Zyklus (T₁) erst beendet ist, wenn jedes der Endgeräte (11, 12) der ersten logischen Gruppe, für die das erste Ethernet-Frame (EF1) ein oder mehrere zugeordnete Geräte-Frames mit einer Anforderung (Request) enthält, jeweils ein Ethernet-Frame (EF11, EF12) als Antwort gesendet hat.
44. 44. Verfahren nach einem der Aspekte 38 bis 43, bei dem
    • 44.1 das jeweilige Ethernet-Frame (EF1, EF2) im Zwischenlevel-Frame-Header (LFH) ein Ethernet-Frame-Zählfeld (MsgCnt) mit einer Ethernet-Frame-Nummer enthätt, die in einer Sequenz zeitlich aufeinander folgend gesendeter Ethernet-Frames (EF1, EF2) die Stellung des jeweiligen Ethernet-Frame angibt; und
    • 44.2 das Kontrollgerät (1) die Ethernet-Frame-Nummer für das jeweils als nächstes zu sendende Ethernet-Frame (EF1, EF2) inkrementiert,
    • 44.3 während die Ethernet-Frame-Nummer durch die Endgeräte (11-14) nicht veränderbar ist.
45. 45. Verfahren nach einem der Aspekte 38 bis 44, bei dem
    • 45.1 das jeweilige Ethernet-Frame (EF1, EF2) im Geräte-Frame-Header (DFH) ein Geräte-Frame-Zählfeld (seqCnt) mit einer Geräte-Frame-Nummer enthält, die in einer Sequenz zeitlich aufeinander folgend an das gleiche Endgerät adressierter Geräte-Frames (DF) die Stellung des jeweiligen Geräte-Frames (DF) angibt;
    • 45.2 das Kontrollgerät (1) die Geräte-Frame-Nummer für das als nächstes an das gleiche Endgerät zu sendende Geräte-Frame (DF) inkrementiert; und
    • 45.3 das jeweilige Endgerät (11-14) die Geräte-Frame-Nummer liest und umformt, beispielsweise invertiert, und die umgeformte Geräte-Frame-Nummer in das Geräte-Frame-Zählfeld (seqCnt) des als nächstes an das Kontrollgerät (1) zu sendenden Geräte-Frames (DF) schreibt.

Features of the invention are also described in the aspects formulated below. The aspects are formulated in the manner of claims and can replace them. Features disclosed in the aspects can also supplement and/or qualify the claims, show alternatives to individual features and/or expand claim features. Reference symbols in brackets refer to embodiments of the invention illustrated in the figures below. They do not restrict the features described in the aspects to the literal meaning as such, but on the other hand show preferred ways of implementing the respective feature.

1. 1. Ethernet frame for data communication in a network with a control device (1) and several terminal devices (11-14) connected to the control device (1), the Ethernet frame (EF) comprising:
   1. 1.1 an Ethernet frame header (EFH) and an Ethernet frame data field (EFD);
   2. 1.2 several device frames (DF11 - DF14) contained in the Ethernet frame data field (EFD) that are assigned to one or more of the end devices (11-14);
   3. 1.3 wherein the device frames (DF11 - DF14) each have a device frame data field (DFD) with user data to be processed and a device frame header (DFH); and
   4. 1.4 an intermediate level frame (LF) contained in the Ethernet frame data field (EFD), preferably forming the Ethernet frame data field (EFD); where
   5. 1.5 the intermediate level frame (LF) an intermediate level frame data field (LFD) with the several device frames (DF11 - DF14) and
   6. 1.6 has an intermediate level frame header (LFH) common to the device frames (DF11 - DF14).
2. 2. Ethernet frame according to the preceding aspect, wherein the respective device frame header (DFH) contains a destination identification field (DestinationID) with an identification of an addressee (1, 11, 12, 13, 14) of the respective device frame (DF11 - DF14), for example a CRC signature of a MAC address of one of the terminal devices (11-14) or of the control device (1), and the respective device frame data field (DFD) contains user data for the addressee (1, 11, 12, 13, 14) identified in the destination identification field.
3. 3. Ethernet frame according to one of the preceding aspects, wherein the intermediate level frame header (LFH) contains a source identification field (SourceID) with an identification of a sender of the Ethernet frame (EF), wherein the identification of the sender can be, for example, a CRC signature of its MAC address.
4. 4. Ethernet frame according to one of the preceding aspects, wherein the intermediate level frame header (LFH) contains a group identification field (GroupID) with a group identification (Gr1, Gr2) which identifies the device frames (DF11 - DF14) contained in the intermediate level frame (LF) as device frames of a group of terminal devices that belong together, so that the terminal devices (11-14) can be divided into different logical groups of terminal devices by assigning each of them a specific group identification.
5. 5. Ethernet frame according to the preceding aspect, wherein the group identification field (GroupID) contains, instead of a specific group identification (Gr1, Gr2), a bit sequence for a broadcast to all terminal devices (11-14) connected to the control device (1).
6. 6. Ethernet frame according to one of the preceding aspects, wherein the intermediate level frame contains a CRC check field (IfhCRC) for securing the intermediate level frame header (LFH).
7. 7. Ethernet frame according to one of the preceding aspects, wherein the device frame (DF) contains a CRC check field (dfhCRC) for securing the device frame header (DFH).
8. 8. Ethernet frame according to one of the preceding aspects, wherein the device frame (DF) contains a CRC check field (dfdCRC) for securing the device frame data field (DFD).
9. 9. Ethernet frame according to a combination of at least two of aspects 6 to 8, wherein the CRC check fields each contain a CRC value and the CRC values of at least two of the CRC check fields are based on different generator polynomials.
10. 10. Ethernet frame according to one of the preceding aspects, wherein the intermediate level frame header (LFH) contains an Ethernet frame count field (MsgCnt) with an Ethernet frame number which indicates the position of the respective Ethernet frame (EF) in a sequence of consecutively sent Ethernet frames (EF), wherein the control device (1) is set up to increment the Ethernet frame number and the Ethernet frame number is preferably not changeable by the terminal devices (11-14).
11. 11. Ethernet frame according to one of the preceding aspects, wherein the device frame header (DFH) contains a device frame count field (seqCnt) with a device frame number which indicates the position of the respective device frame (DF) in a sequence of device frames (DF) sent consecutively to the same terminal, wherein the control device (1) is set up to increment the device frame number when sending the respective device frame (DF) and the terminals (11-14) are set up to convert the device frame number, for example to invert it.
12. 12. Ethernet frame according to one of the preceding aspects, wherein the intermediate level frame header (LFH) contains an Ethernet frame mode field (MsgType) for identifying a specific communication mode from several optionally predeterminable different communication modes (Discovery, Commissioning, Cyclic Data, Set, Get, RPC) including a commissioning mode (Commissioning), wherein the Ethernet frame mode field (MsgType) identifies the intermediate level frame header (LFH) as a header for configuring the terminal devices (11-14) and/or the device frames (DF11 - DF14) contained in the intermediate level frame data field (LFD) as device frames for configuring the terminal devices (11-14) when the commissioning mode is selected.
13. 13. Ethernet frame according to one of the preceding aspects, wherein the intermediate level frame header (LFH) contains an Ethernet frame mode field (MsgType) for identifying a specific communication mode from several optionally predeterminable different communication modes (Discovery, Commissioning, Cyclic Data, Set, Get, RPC) including a cyclic operation mode (Cyclic Data), wherein the Ethernet frame mode field (MsgType) when the cyclic mode is selected identifies the intermediate level frame header (LFH) as a header for the cyclic data transmission and the device frames (DF11 - DF14) contained in the intermediate level frame data field (LFD) as device frames with process data for the end devices (11-14) or from the end devices (11-14).
14. 14. Ethernet frame according to one of the preceding aspects, wherein the device frame header (DFH) of the respective device frame (DF11 - DF14) contains a control and status field (CTR & Status) with a safety value and the safety value (e.g. 1 bit) informs the addressee of the respective device frame (DF11 - DF14) whether the respective device frame (DF11-DF14) contains payload data relevant to functional safety.
15. 15. Ethernet frame according to the preceding aspect, wherein several of the device frames (DF11 - DF14) contain data relevant to functional safety and the safety values of these device frames (DF11 - DF14) indicate this.
16. 16. Ethernet frame according to one of the preceding aspects, wherein the device frame header (DFH) of the respective device frame (DF11 - DF14) contains a control and status field (CTR & status) with a request/response value (e.g. 1 bit) and the request/response value informs the addressee of the respective device frame (DF11 - DF14) whether the respective device frame is a request to send payload data or the payload data contained in the device frame data field of the respective device frame (DF11 - DF14) is sent in response to a request.
17. 17. Ethernet frame according to one of the preceding aspects, wherein the device frame header (DFH) of the respective device frame (DF11 - DF14) contains a control and status field (CTR & Status) with a synchronization value (TimeSync, e.g. 1 bit) which indicates to the addressee of the respective device frame whether the respective device frame serves to synchronize the device clock of the addressed or sending terminal device with the device clock of the control device (1).
18. 18. The Ethernet frame according to the preceding aspect, wherein the intermediate level frame data field (LFD) contains multiple device frames for the same terminal, and the synchronization value of one of the device frames directed to the same terminal is set to time synchronization and the synchronization value of another of the device frames directed to the same terminal is not set to time synchronization.
19. 19. Ethernet frame according to any one of the preceding aspects, wherein the respective device frame header (DFH) contains a control and status field (CTR & Status) with one or more run/stop bits and the content of the one or more run/stop bits keeps the addressee of the respective device frame in active operation or puts it into an idle state.
20. 20. Ethernet frame according to any one of the preceding aspects, wherein the respective device frame header (DFH) comprises a control and status field (CTR & Status) with an error status field (DataCRCErr) for indicating the detection of an error in the data of the intermediate level Frame Header (LFH) and/or in the Device Frame Header (DFH) data and/or in the Device Frame Data Field (DFD) data.
21. 21. An Ethernet frame according to any preceding aspect, wherein the intermediate level frame data field (LFD) contains multiple device frames for the same terminal equipment.
22. 22. Ethernet frame according to one of the preceding aspects, wherein at least one device frame (DF11) of the plurality of device frames is assigned to a first terminal (11) and another device frame (DF12) of the plurality of device frames is assigned to another, second terminal (12).
23. 23. Ethernet-capable network with at least the following network components, which are set up for data communication in the form of Ethernet frames (EF) according to one of the preceding aspects:
    1. 23.1 a control device (1) which is configured to generate and send an Ethernet frame according to one of the preceding claims as an Ethernet request frame (EF1) with a device identification identifying the control device (1) in the source identification field (SourceID) of the intermediate level frame (LF1);
    2. 23.2 optionally one or more distributors (3); and
    3. 23.3 a first terminal (11) and a second terminal (12) connected to the control device (1), preferably via the one or more optional distributors (3);
    4. 23.4 wherein the control device (1) is configured to write a device identification into the destination identification field (DestinationID) of the respective device frame (DF11req, DF12req) of the Ethernet request frame (EF1), which device identification identifies the terminal for which the respective device frame (DF11req, DF12req) is intended;
    5. 23.5 and wherein each of the terminal devices (11, 12) is configured to receive the Ethernet request frame (EF1), to process it and to generate and send an Ethernet frame according to one of the preceding claims as an Ethernet response frame (EF11, EF12) with a device identification identifying the respective terminal device (11, 12) in the source identification field (SourceID) of the respective device frame (DF11resp, DF12resp) of the Ethernet response frame (EF11, EF12).
24. 24. Ethernet-capable network according to the preceding aspect, wherein the respective terminal device (11, 12) is configured to write the device identification of the control device (1) into the destination identification field (DestinationID) of the respective device frame (DF11resp, DF12resp) of its Ethernet response frame (EF11, EF12).
25. 25. An Ethernet-capable network according to any of the two immediately preceding aspects, wherein
    • 25.1 the network components for data communication in the form of Ethernet frames (EF) are set up according to one of the preceding aspects in combination with aspect 4,
    • 25.2 the first terminal (11) and the second terminal (12) are assigned a common first group identification (Gr1) so that they belong to a first logical group,
    • 25.3 the first terminal (11) and the second terminal (12) are configured to process data of the device frame data fields (DFD) by the allocation of the first group identification (Gr1) if the group identification field (GroupID) identifies the first group identification (Gr1);
    • 25.4 the third terminal (13) and the fourth terminal (14) are assigned a common second group identification (Gr2) so that they belong to a second logical group,
    • 25.5 the third terminal (13) and the fourth terminal (14) are configured to process data of the device frame data fields (DFD) by the allocation of the second group identification (Gr2) if the group identification field (GroupID) identifies the second group identification (Gr2); and wherein
    • 25.6 the terminal devices (11, 12) of the first logical group are set up to process the user data of the device frames (DF) only if the first group identification (Gr1) or a broadcast is indicated in the group identification field (GroupID) of the respective Ethernet frame (EF1), and
    • 25.7 the terminal devices (13, 14) of the second logical group are configured to process the user data of the device frames (DF) only if the second group identification (Gr2) or a broadcast is indicated in the group identification field (GroupID) of the respective Ethernet frame (EF2).
26. 26. Ethernet-capable network with at least the following network components, which are set up for data communication in the form of Ethernet frames (EF) according to one of the preceding aspects, each in combination with aspect 4:
    1. 26.1 a control device (1);
    2. 26.2 optionally one or more distributors (3);
    3. 26.3 a first terminal (11) and a second terminal (12) which are connected to the control device (1), preferably via the one or more optional distributors (3), and which are assigned a first group identification (Gr1) so that they belong to a first logical group, and which are set up by the assignment of the first group identification (Gr1) to process data of the device frame data fields (DFD) if the group identification field (GroupID) identifies the first group identification (Gr1);
    4. 26.4 a third terminal (13) and a fourth terminal (14) which are connected to the control device (1), preferably via the one or more optional distributors (3), and which are assigned a second group identification (Gr2) so that they belong to a second logical group, and which are set up by the assignment of the second group identification (Gr2) to process data of the device frame data fields (DFD) if the group identification field (GroupID) identifies a different, second group identification (Gr2);
    5. 26.5 wherein the distributor(s) (3), f is or are set up to forward the respective Ethernet frame (EF1, EF2) to the terminal devices (11-14) of the first logical group only if the first group identification (Gr1) or a broadcast is indicated in the group identification field (GroupID), and to forward the respective Ethernet frame (EF1, EF2) to the terminal devices (11-14) of the second logical group only if the second group identification (Gr2) or a broadcast is indicated in the group identification field (Group ID); and/or
    6. 26.6 the terminal devices (11, 12) of the first logical group are set up to process the payload data of the device frames (DF) only if the first group identification (Gr1) or a broadcast is indicated in the group identification field (GroupID) of the respective Ethernet frame (EF1), and the terminal devices (13, 14) of the second logical group are set up to process the payload data of the device frames (DF) only if the second group identification (Gr2) or a broadcast is indicated in the group identification field (GroupID) of the respective Ethernet frame (EF2).
27. 27. Ethernet-capable network according to one of aspects 23 to 26, wherein the control device (1) is configured to write either the first group identification (Gr1) or the second group identification (Gr2) into the group identification field (Group ID) of the respective Ethernet frame (EF1, EF2).
28. 28. Ethernet-capable network according to one of the aspects 23 to 27, wherein the control device (1) and the terminal devices (11-14) each have a device identification and the respective device frame header (DFH) contains a destination identification field (DestinationID) with the device identification of an addressee (1, 11, 12, 13, 14) of the respective device frame (DF11 - DF14), for example a CRC signature of a MAC address of one of the terminal devices (11-14) or of the control device (1), and the respective device frame data field (DFD) contains user data for the addressee (1, 11, 12, 13, 14) identified in the destination identification field, and wherein the control device (1) and preferably also the respective terminal device (11-14) is/are set up to contain the device identification of the addressee in the destination identification field (DestinationID) and/or write to the destination identification field (DestinationID).
29. 29. Ethernet-capable network according to one of the aspects 23 to 28, wherein the control device (1) and the terminal devices (11-14) each have a device identification and the intermediate level frame header (LFH) contains a source identification field (SourceID) with the device identification of the sender of the respective Ethernet frame (EF), and wherein the control device (1) and preferably also the respective terminal device (11-14) is/are set up to read the device identification of the sender in the source identification field (SourceID) and/or to write its own device identification in the source identification field (SourceID).
30. 30. Ethernet-capable network according to one of the aspects 23 to 29, wherein the first group identification (Gr1) is assigned only to terminal devices (11, 12) that meet the functional safety requirements, and the second group identification (Gr2) is assigned to one or more or only terminal devices (13, 14) that do not meet the functional safety requirements, so that the network is divided into network areas of different functional safety based on the allocation of the group identifications (Gr1, Gr2).
31. 31. Ethernet-capable network according to one of the aspects 23 to 30, wherein the device frame header (DFH) of the respective device frame (DF11 - DF14) contains a control and status field (CTR & Status) with a safety value (e.g. 1 bit) that informs the addressee of the respective device frame (DF11 - DF14) whether the respective device frame (DF11 - DF14) contains payload data relevant to functional safety. and wherein at least the first terminal (11) satisfies the functional safety requirements and is configured to process a device frame (DF11) addressed to the first terminal (11) only if the safety value of the respective device frame (DF11) assigned to the first terminal (11) indicates that this device frame contains useful data relevant to functional safety.
32. 32. Ethernet-capable network with at least the following network components, which are set up for data communication in the form of Ethernet frames (EF) according to one of the preceding aspects:
    • 32.1 a control device (1);
    • 32.2 optionally one or more distributors (3); and
    • 32.3 a first terminal (11) and a second terminal (12) connected to the control device (1), preferably via the one or more optional distributors (3); wherein
    • 32.4 the intermediate level frame contains a CRC check field (IfhCRC) to protect the intermediate level frame header (LFH) and/or the device frame (DF) contains a CRC check field (dfhCRC) to protect the device frame header (DFH) and/or the device frame (DF) contains a CRC check field (dfdCRC) to protect the device frame data field (DFD);
    • 32.5 the device frame header (DFH) of the respective device frame (DF11 - DF14) contains an error status field (DataCRCErr) to indicate the detection of an error in the data of the intermediate level frame header (LFH) and/or the device frame header (DFH) and/or the device frame data field (DFD);
    • 32.6 the control device (1) is arranged to send an Ethernet frame (EF) with a request for a response in one or more of the device frames (DF);
    • 32.7 and one or more of the terminal devices (11-14) is or are set up to check the data integrity of the intermediate level frame header (LFH) based on the content of the CRC check field (IfhCRC) for the intermediate level frame header (LFH) and/or the data integrity of the respectively assigned device frame header (DFH) based on the content of the CRC check field (dfhCRC) for the device frame header (DFH) and/or the data integrity of the respectively assigned device frame data field (DFD) based on the content of the CRC check field (dfdCRC) for the device frame data field (DFD),
      • - to set an error value in the error status field (DataCRCErr) if a data error is detected, and
      • - send an Ethernet frame (EF) containing the error value in the error status field (DataCRCErr) to the control device (1) as a response.
33. 33. Ethernet-capable network according to the preceding aspect and any of aspects 23 to 31.
34. 34. Ethernet-capable network according to one of aspects 23 to 33, wherein the control device (1) and the terminal devices (11-14) are field devices and the data communication in the network takes place at the field level.
35. 35. Ethernet-capable network according to one of aspects 23 to 34, wherein the terminal devices (11-14) comprise one or more sensors (11, 13), for example one or more temperature sensors and/or pressure sensors and/or volume flow sensors and/or pH sensors and/or concentration sensors, and/or one or more actuators (12, 14), for example one or more motors and/or valves and/or heating devices, and/or one or more controllers, for example temperature control or regulating devices and/or pressure control or regulating devices and/or volume flow control or regulating devices, and/or one or more monitors (4).
36. 36. An Ethernet-enabled network according to any one of aspects 23 to 35, wherein the network is a system or part of a system for measuring the energy consumption of a building or for controlling or regulating the temperature(s) in a building.
37. 37. Ethernet-capable network according to one of aspects 23 to 35, wherein the network is a system or component of a system for detecting, preferably monitoring, and/or controlling or regulating one or more physical and/or chemical variables in a technical process engineering plant.
38. 38. Method for data communication in an Ethernet-capable network, in which network components comprising a control device (1) and several terminal devices (11-14) are connected for data communication, preferably via one or more optional distributors (3) of the network, and in which
    • 38.1 the network components (1, 3, 11-14) are set up for data exchange in the form of Ethernet frames (EF) according to one of the preceding aspects;
    • 38.2 the control device (1) is an Ethernet frame according to one of the preceding claims generated and sent as an Ethernet request frame (EF1);
    • 38.3 the control device (1) writes a device identification identifying the control device (1) into the source identification field (SourceID) of the intermediate level frame (LF1) when generating the Ethernet request frame (EF1) and writes a device identification identifying the terminal for which the respective device frame (DF11, DF12) is intended into the destination identification field (DestinationID) of the respective device frame (DF11, DF12);
    • 38.4 and the terminal devices (11-14) receive the Ethernet request frame (EF1), process it and generate and send an Ethernet frame according to one of the preceding aspects as an Ethernet response frame (EF11, EF12) with a device identification identifying the respective terminal device in the source identification field (SourceID) of the respective device frame (DF11 resp, DF12resp) of the Ethernet response frame (EF11, EF12).
39. 39. Method according to the preceding aspect, wherein the respective terminal, when generating its Ethernet response frame (EF11, EF12), writes the device identification of the control device (1) into the destination identification field (DestinationID) of the respective device frame (DF11resp, DF12resp) of its Ethernet response frame (EF11, EF12).
40. 40. A method according to any of the two immediately preceding aspects, in which
    • 40.1 the network components (1, 3, 11-14) are set up for data communication in the form of Ethernet frames (EF) according to one of the preceding aspects, each in combination with aspect 4;
    • 40.2 the terminals (11-14) are grouped into a first logical group of terminals (11, 12) and a second logical group of terminals (13, 14) by
    • 40.3 the terminal devices (11, 12) of the first logical group are assigned a common first group identification (Gr1) and the terminal devices (13, 14) of the second logical group are assigned a different, common second group identification (Gr2);
    • 40.4 a network component, preferably the control device (1), writes the first group identification (Gr1) into the intermediate level frame header (LFH) of a first Ethernet frame (EF1) and sends the first Ethernet frame (EF1) to the terminal devices (11-14) in a first cycle of the data communication;
    • 40.5 the respective terminal (11, 12) of the first logical group reads the group identification field (GroupID) of the first Ethernet frame (EF1), recognises the bit sequence contained therein as the group identification (Gr1) assigned to it and processes the one or more device frames assigned to the respective terminal by the device identification in the destination identification field (DestinationID) of the respective device frame; and in which
    • 40.6 the respective terminal device (13, 14) of the second logical group reads the group identification field of the first Ethernet frame (EF1), recognises the bit sequence contained therein as a group identification (Gr1) not assigned to it and therefore does not process the first Ethernet frame (EF1).
41. 41. Method for data communication in an Ethernet-capable network in which network components comprising a control device (1), several terminals (11-14) and optionally one or more distributors (3) for data communication are connected to one another, in which
    • 41.1 the network components (1, 3, 11-14) are set up for data exchange in the form of Ethernet frames (EF) according to one of the preceding aspects, each in combination with aspect 4;
    • 41.2 the terminals (11-14) are grouped into a first logical group of terminals (11, 12) and a second logical group of terminals (13, 14) by
    • 41.3 the terminal devices (11, 12) of the first logical group are assigned a common first group identification (Gr1) and the terminal devices (13, 14) of the second logical group are assigned a different, common second group identification (Gr2);
    • 41.4 a network component, preferably the control device (1), writes the first group identification (Gr1) into the intermediate level frame header (LFH) of a first Ethernet frame (EF1) and sends the first Ethernet frame (EF1) to the terminal devices (11-14) in a first cycle (T ₁ ) of the data communication;
    • 41.5 the respective terminal (11, 12) of the first logical group reads the group identification field (GroupID) of the first Ethernet frame (EF1), recognises the bit sequence contained therein as the group identification (Gr1) assigned to it and processes the one or more device frames assigned to the respective terminal by the device identification in the destination identification field (DestinationID) of the respective device frame; and in which
    • 41.6 the respective terminal device (13, 14) of the second logical group reads the group identification field of the first Ethernet frame (EF1), recognises the bit sequence contained therein as a group identification (Gr1) not assigned to it and therefore does not process the first Ethernet frame (EF1).
42. 42. Method for data communication in an Ethernet-capable network in which network components comprising a control device (1) and several terminal devices (11-14) are connected via one or more distributors (3) for data communication, in which
    • 42.1 the network components (1, 3, 11-14) are set up for data exchange in the form of Ethernet frames (EF1, EF2) according to one of the preceding aspects, each in combination with aspect 4;
    • 42.2 the terminals (11-14) are grouped into a first logical group of terminals (11, 12) and a second logical group of terminals (13, 14) by
    • 42.3 the terminal devices (11, 12) of the first logical group are assigned a common first group identification (Gr1) and the terminal devices (13, 14) of the second logical group are assigned a different, common second group identification (Gr2);
    • 42.4 the respective distributor (3) is configured for a selective forwarding of the Ethernet frames (EF1, EF2) depending on the respective group identification (Gr1, Gr2);
    • 42.5 a network component, preferably the control device (1), writes the first group identification (Gr1) into the intermediate level frame header (LFH) of a first Ethernet frame (EF1) and sends the first Ethernet frame (EF1) to the distributor(s) (3) in a first cycle (T ₁ ) of the data communication; and
    • 42.6 the respective distributor (3) forwards the first Ethernet frame (EF1) only to the terminal devices (11, 12) of the first logical group.
43. 43. A method according to any one of aspects 41 and 42, in which
    • 43.1 one or more of the device frames of the first Ethernet frame (EF1) contains or each contains a request to send payload data;
    • 43.2 the respective terminal (11, 12) of the first logical group, to which one or more device frames with a request are assigned in the first Ethernet frame (EF1), writes the requested user data into the respective assigned device frame containing the request and
    • 43.3 sends an Ethernet frame (EF11, EF12) with its payload as a response to the requesting network component (1); and
    • 43.4 the first cycle (T ₁ ) is only terminated when each of the terminal devices (11, 12) of the first logical group, for which the first Ethernet frame (EF1) contains one or more associated device frames with a request, has sent an Ethernet frame (EF11, EF12) in response.
44. 44. A method according to any one of aspects 38 to 43, in which
    • 44.1 the respective Ethernet frame (EF1, EF2) contains an Ethernet frame count field (MsgCnt) in the intermediate level frame header (LFH) with an Ethernet frame number that indicates the position of the respective Ethernet frame in a sequence of consecutively sent Ethernet frames (EF1, EF2); and
    • 44.2 the control device (1) increments the Ethernet frame number for the next Ethernet frame to be sent (EF1, EF2),
    • 44.3 while the Ethernet frame number cannot be changed by the end devices (11-14).
45. 45. A method according to any one of aspects 38 to 44, in which
    • 45.1 the respective Ethernet frame (EF1, EF2) contains in the device frame header (DFH) a device frame count field (seqCnt) with a device frame number which indicates the position of the respective device frame (DF) in a sequence of device frames (DF) addressed consecutively to the same terminal device;
    • 45.2 the control equipment (1) increments the device frame number for the next device frame (DF) to be sent to the same terminal equipment; and
    • 45.3 the respective terminal device (11-14) reads and converts the device frame number, for example inverts it, and writes the converted device frame number into the device frame count field (seqCnt) of the next device frame (DF) to be sent to the control device (1).

• 1 ein Netzwerk für eine Datenkommunikation bis in die Feldebene mittels eines erfindungsgemäßen Protokolls basierend auf einem Ethernet-Standard,
• 2 ein erfindungsgemäßes Ethernet-Frame, in das ein Zwischenlevel-Frame mit einem Zwischenlevel-Frame-Header und mehreren Geräte-Frames eingebettet ist,
• 3 Steuerungsfelder eines Headers eines der Geräte-Frames,
• 4 ein Netzwerk mit Netzwerkkomponenten, die mittels des Ethernet-Frames in logische Gerätegruppen unterteilt sind, während eines ersten Zyklus der Datenkommunikation,
• 5 das Netzwerk der 4 während eines zweiten Zyklus der Datenkommunikation,
• 6 einen Zyklus der Datenkommunikation im Netzwerk der 4;
• 7 Zwischenlevel-Frames und Geräte-Frames als Anforderungs- und Antwort-Frames, und
• 8 das Netzwerk der 4 mit direkter Datenkommunikation zwischen Endgeräten unterschiedlicher logischer Gerätegruppen.

In the following, embodiments of the invention are explained with reference to figures. Features revealed in the embodiments, individually and in each combination of features, advantageously develop the subject matter of the claims and the above aspects. They show:

• 1 a network for data communication down to the field level using an inventive protocol based on an Ethernet standard,
• 2 an Ethernet frame according to the invention in which an intermediate level frame with an intermediate level frame header and several device frames are embedded,
• 3 Control fields of a header of one of the device frames,
• 4 a network with network components divided into logical device groups by means of the Ethernet frame, during a first cycle of data communication,
• 5 the network of 4 during a second cycle of data communication,
• 6 a cycle of data communication in the network of 4 ;
• 7 Intermediate level frames and device frames as request and response frames, and
• 8 the network of 4 with direct data communication between end devices of different logical device groups.

1 shows a network for Ethernet-based data communication. In the network, a control device 1 and several end devices 11, 12, 13 and 14 are connected to the control device 1 via an Ethernet-capable data connection 2. One or more distributors 3 can be arranged in the data connection 2 in order to forward data packets to and from the end devices 11-14. The respective distributor 3 can be, for example, a switch, a bridge or even a hub. The control device 1 contains a PLC (Programmable Logic Controller) and acts as a master in the network. The end devices can be sensors 11 and 13 and actuators 12 and 14. The respective sensor 11 and/or 13 can be a temperature sensor or pressure sensor and the respective actuator 12 and/or 14 can be a motor, control valve or heating element, to name just a few examples.

The network can include further network components, for example one or more monitors 4. The respective monitor 4 can serve purely to display, for example, measured values and/or device states and/or operating states of a system to be monitored, such as a process engineering plant. The respective monitor 4 can serve as a simple terminal, for example purely for display purposes, or in an additional function also for configuring one or more terminals. The network can include one or more further control devices 5, which is/are also connected via the data connection 2 to the other network components, such as the control device 1 and/or the terminals 11-14 and/or the respective monitor 4. The data connection 2 can also serve to supply one or more of the network components with electrical energy.

The control device 1 can be integrated into a larger network via a further data connection 7. The control device 1 can communicate with other devices via the data connection 7, for example on the basis of a known, Ethernet-based protocol, such as PROFINET and/or Ethernet/IP and/or other known protocols.

In one variant, the control device 1 can be replaced by a gateway via which the terminal devices 11-14 and the respective further network components 3, 4 and/or 5 are connected via a data connection 8 to a control device 9 located remotely, for example in the cloud. In the variant, the control device 9 present in the cloud acts as a master.

In order to enable Ethernet-based data communication down to the field level, i.e. up to the terminal devices 11-14 and the optional additional terminal and/or control devices 4 and 5, using simple, inexpensive terminal devices, the data communication in the network is based on a protocol developed for this purpose, under which the data communication takes place using data packets in the form of Ethernet frames. This protocol developed for the field level is based on an Ethernet frame according to an Ethernet standard, preferably according to IEEE 802.1q.

2 shows an Ethernet frame EF constructed according to the invention. The Ethernet frame EF comprises an Ethernet standard header EFH with the known data fields, i.e. it starts with a preamble, followed by a destination address field "Destination ADD" and a source address field "Source ADD" as well as a VLAN field and the EtherType. To recognize the protocol, a separate EtherType or, in the simplest case, the OUI Extended EtherType with the OUI from, for example, a manufacturer of essential network components can be used. The data fields of the header EFH have the usual field size, i.e. eight bytes for the preamble including SFD, six bytes for the two address fields, four bytes for the VLAN field and seven bytes for the EtherType. The header EFH is followed by the Ethernet frame data field EFD, which contains the payload data for or from the end devices. The Ethernet frame data field EFD is followed, as is also usual, by a CRC check field.

The Ethernet frame data field EFD contains an intermediate level frame LF specially developed for data communication including terminal devices from the low-price range. In advantageous embodiments, the Ethernet frame data field EFD contains only a single intermediate level frame LF, and preferably it consists of the intermediate level frame LF, as indicated by the dashed connecting lines from the Ethernet frame data field EFD to the intermediate level frame LF.

The intermediate level frame LF comprises an intermediate level frame header LFH with control data and an intermediate level frame data field LFD for the payload data for and from the end devices. The intermediate level frame LF can also have a padding field for filling the intermediate level frame data field LFD.

The intermediate level frame header LFH is divided into several control fields and a CRC check field IfhCRC, which is used to secure the intermediate level frame header LFH. The check field IfhCRC contains a binary checksum that is formed using polynomial division over the control fields of the intermediate level frame header LFH with an adapted generator polynomial. The control fields include an Ethernet frame count field MsgCnt, a group identification field GroupID, a source identification field SourceID, an Ethernet frame mode field MsgType and a length field LFDSize, which indicates the length, i.e. the number of bits, of the intermediate level frame data field LFD.

The frame count field MsgCnt is incremented each time an Ethernet frame EF is sent by control device 1 or, in the variant mentioned, by control device 9 and cannot be changed by any other network component. Control device 1 or 9 uses this to count the Ethernet frames EF it has sent. If the respective terminal device sends back an Ethernet frame EF, for example, in response to a request from control device 1 or 9, the Ethernet frame sent in response contains the same bit sequence in the Ethernet frame count field MsgCnt as the Ethernet frame EF previously sent by control device 1 or 9 as a request. The frame count field MsgCnt can have a field size of, for example, one byte.

The group identification field GroupID can be used to divide the network components, in particular the terminal devices 11-14, into logical groups when configuring the network by the control device 1 or 9 assigning each of the terminal devices 11-14 its own group identification. If the control device 1 or 9 then sends an Ethernet frame EF during operation that contains a specific bit sequence in the GroupID field that corresponds to an assigned group identification, only the terminal devices belonging to the group identified thereby process the relevant Ethernet frame EF. In addition, it can be provided that a bit sequence for "broadcast" is set in the group identification field GroupID, i.e. an Ethernet frame that is intended for the network components connected to the control device 1 or 9 regardless of any group membership and is therefore read and processed by these network components. The group identification field can have a field size of just one bit. However, at least two bits are required to distinguish between at least two group identifications and to divide into at least two logical groups, including the possibility of sending a broadcast. A field size of one byte is preferred.

The differentiation and corresponding selective processing of user data according to group membership can be carried out by means of the distributor 3, if present, by appropriate filtering of the Ethernet frames EF. The differentiation and, based on this, the selective processing is preferably carried out by the respective terminal device in that the respective terminal device is set up to only process the user data of a device frame DF if the group identification field GroupID of the respective Ethernet frame EF shows the group identification assigned to it or a broadcast if the protocol provides a broadcast as a selection option, and to ignore the intermediate level frame LF and thus the Ethernet frame EF if this is not the case, in particular if the GroupID field shows a specific other group identification. If several of the terminal devices or all of the terminal devices have the ability to differentiate and selectively process based on the information in the GroupID field, conventional distributors 3 can be used, which forward each Ethernet frame EF with the structure according to the invention to all network components connected to the respective distributor 3, such as the terminal devices 11-14.

The source identification field SourceID identifies the sender of the respective Ethernet frame EF and contains a device identification in the form of a bit sequence that uniquely identifies one of the terminal devices 11-14 or another network component. If the control device 1 or 9 is the sender, the bit sequence of the SourceID field identifies the control device 1 or 9 accordingly. If one of the terminal devices 11-14 or one of the optional additional devices 4 or 5 is the sender, the source identification field SourceID of the respective Ethernet frame EF contains the device identification. mes EF accordingly identifies this network component as the sender. The device identification can be a CRC signature, preferably a CRC16 signature, of a device parameter that uniquely identifies the sender. In particular, the device identification can be a CRC signature of the MAC address of the respective device.

The communication mode is identified in the Ethernet frame mode field MsgType. The protocol distinguishes between several communication modes, one of which can be selected and specified in the Ethernet frame mode field MsgType. In particular, this can be used to distinguish between the commissioning of the network and ongoing network operation.

To set up the network using the Ethernet frame EF, the protocol contains specific communication modes, parts of which build on one another and are run through one after the other. In a first phase, an engineering phase, for example, all parameters required for operation according to the protocol are configured. This can be done by manual input, or defined profiles are used. If control device 1 or 9 already knows all the parameters, the engineering phase can be omitted. After the parameters have been configured, a discovery phase can follow, similar to PROFINET, which is used to find and identify the network components belonging to the network. For this purpose, an Ethernet frame EF is sent by control device 1 or 9 or a supervisor as a broadcast message, to which the individual network components, in particular terminal devices 11-14, respond accordingly. This is indicated in the MsgType field by setting a bit sequence for "Discovery".

In a subsequent commissioning mode, which can extend over one or more data cycles, the control device 1 or 9 prepares the connected network components for data communication using the protocol according to the invention, in particular it makes any assignments that are still required. The control device 1 or 9 indicates the commissioning mode by setting a corresponding bit sequence in the Ethernet frame mode field MsgType and sends the respective Ethernet frame EF used for commissioning to all network components. With one or more Ethernet frames EF sent at a time, for example two Ethernet frames, the control device 1 or 9 assigns the group identification to the terminal devices 11-14 and, if applicable, other network components. The control device 1 or 9 can also be set up to assign temporary device identifications that replace the previous device identifications until further notice, provided that the ability to change the device identification is implemented in the terminal devices 11 to 14 and, if applicable, other network components.

Once commissioning is complete, you can go into ongoing operation. During ongoing operation, a distinction can be made between other communication modes, including in particular a cyclic operation mode. The cyclic operation mode is identified by a corresponding bit sequence that the control device sets to 1 or 9 in the MsgType field.

The intermediate level frame data field LFD contains the data for and from the terminal devices 11-14 and any other network components. This device-specific data is transmitted in the form of device frames DF. In 2 Four device frames DF11, DF12, DF13 and DF14 are shown as examples, which are assigned to the terminal devices 11 to 14. As an example, each of the terminal devices 11-14 is assigned exactly one of the device frames DF11 - DF14 in a bijective assignment. The intermediate level frame data field LFD can instead also contain several device frames DF for the same terminal device or for several terminal devices. It can also only contain device frames DF for the same terminal device. It is also possible to send a so-called sum frame telegram, i.e. a single device frame DF for several and, if necessary, for all network components connected in the network.

The respective device frame DF comprises a device frame header DFH and a device frame data field DFD. In addition, the respective device frame DF can comprise a check field dfdCRC to secure the data contained in the device frame data field DFD. The check field dfdCRC contains a binary checksum that is formed over the data of the device frame data field DFD with an adapted generator polynomial by polynomial division. The device frame header DFH contains a destination identification field DestinationID, a control and status field CTR&Status, a length field DFDSize that specifies the bit length of the device frame data field DFD, and a separate check field dfhCRC to secure the device frame header DFH. The check field dfhCRC contains a binary checksum that is formed over the control data of the device frame header DFD with an adapted generator polynomial by polynomial division.

The respective device frame header contains a destination identification field DestinationID. The destination identification field contains a device identification in the form of a bit sequence that uniquely identifies the addressee of the respective device frame DF, for example one of the terminal devices 11-14 or another network component. The device identification can be a CRC signature, preferably a CRC16 signature, of a device parameter that uniquely identifies the device to be identified. In particular, the device identification can be a CRC signature of the MAC address of the respective device.

By means of the two identification fields SourceID in the intermediate level frame header LFH and DestinationID in the respective device frame header DFH, both the sender and the respective addressee can be clearly identified in the Ethernet frame EF at the level of the intermediate level frame LF. If, for example, control device 1 sends, it sets its own device identification in the SourceID field and, in the respective device frame, the device identification of one of the end devices 11-14 or of another network component, such as the device identification of a monitor 4 or another control device 5. If, for example, one of the end devices 11-14 sends, it sets its own device identification in the SourceID field and, in the respective device frame, the device identification of another device, for example control device 1 or another end device, in the DestinationID field. The source identification field SourceID in the intermediate level frame header LFH and the destination identification field DestinationID in the respective device frame DF thus enable directed data communication in both directions, in particular unambiguous addressing of an Ethernet frame by one of the network components, for example one of the terminal devices 11-14, to another of the network components, for example to the control device 1 or another of the terminal devices 11-14.

Another advantage of this type of addressing within the network is that instead of six-byte MAC addresses, device identifications can be used that require smaller destination and source identification fields. The destination identification field DestinationID and the source identification field SourceID can each be reduced to a maximum of three or two bytes. The two general address fields Destination ADD and Source ADD in the standard header of the Ethernet frame EF are not required for data communication within the network. The address field Destination ADD is always set to multicast. In this sense, the Ethernet frame is direction-independent.

For the intermediate level frame header LFH, preferred field sizes, in bytes, are entered for the individual control fields of the header LFH. Preferred field sizes are also entered for the control and CRC check fields of the device frame DF. These are preferred field sizes, but only example sizes.

In 3 The structure of the device frame DF is shown again, with the control and status field CTR&Status broken down. According to the breakdown, the control data field CTR&Status contains a safety value that indicates whether the respective device frame DF contains user data that is relevant to functional safety. In particular, a single bit can be provided for the safety value, so that only a distinction is made between "safety-relevant" and "not safety-relevant".

The CTR&Status field also contains a Repeated Msg entry, which indicates to the receiving network component whether the device frame DF in question is being sent for the first time or repeatedly. For example, only one bit is provided for this entry.

Furthermore, a synchronization value TimeSync is provided for the temporal synchronization of the device clock of the receiving network component with the device clock of the control device 1 or 9. The synchronization value TimeSync can also consist of just a single bit, as shown in the example, so that it only indicates whether the device frame DF in question is used for temporal synchronization or not.

A Request/Response field indicates whether the respective device frame DF is a request to send payload data or a response to such a request. This field can also consist of just one bit.

With a Run/Stop bit, the receiving network component from control device 1 or 9 can be either stopped or kept in operation.

An error status field DataCRCError contributes to functional safety. An error value can be entered in this field, which indicates to the receiver whether an Ethernet frame previously sent by it was damaged during transmission. The error status field can, for example, consist of just one bit and in this case only distinguish between "error detected" and "no error detected".

In addition to other information, the control data field CTR&Status contains a device frame count field seqCnt with a device frame number that indicates the position of the device frames DF sent by control device 1 or 9 in a sequence of device frames DF sent consecutively to the same network component. of the respective device frame DF. The control device 1 or 9 is set up to increment the device frame number when sending the respective device frame. The terminal devices 11-14 and possibly other network components are set up to convert the device frame number, for example to invert it. For example, if 3 bits are provided for the device frame counting field seqCnt and the control device 1 or 9 sends the bit sequence 101, the network component for which the relevant device frame DF is intended responds with the bit sequence 010 in the event of a conversion by inversion in the device frame counting field seqCnt.

In many industrial applications for which the protocol and in particular the Ethernet frame EF are designed, secure data transmission cannot be guaranteed. The data connection, such as data connection 2 in the network of the 1 , is considered a black channel in such cases. The data integrity is nevertheless guaranteed by the intermediate level frame LF. The CRC check fields provided in the intermediate level frame header LFH and in the respective device frame DF contribute in particular to this. Every network component that is assigned to the area of functional safety and therefore meets the requirements of functional safety checks each of the Ethernet frames EF intended for it using the IfhCRC, dfhCRC and dfdCRC check fields.

The data integrity check is conveniently carried out in a predetermined test sequence. In a first test step, the respective network component that receives an Ethernet frame with an assigned device frame from a sender, for example control device 1, checks the data integrity of the intermediate level frame header LFH using the test field IfhCRC provided for this purpose. If the header LFH is identified as faulty, the receiving network component generates an Ethernet frame, in whose error status field DataCRCError it writes the value for "error". It also writes its own device identification into the source identification field SourceID of the intermediate level frame header LFH and the device identification of the sender from which it received the Ethernet frame EF into the destination identification field DestinationID of the respective assigned device frame DF, and sends the Ethernet frame EF, which it has provided with this information, among other things, back to the sender as a response.

If a data error is not detected in the intermediate level frame header LFH, the integrity of the data contained in the LFH header is assumed. In the next step, the receiving network component then uses the dfhCRC check field to check the integrity of the data contained in the device frame header DFH. If an error is detected in this second integrity check, the receiving network component proceeds as explained above with regard to the intermediate level frame header, i.e. sends a corresponding Ethernet frame EF as an error response.

If no error is detected in this second check, the integrity of the data contained in the device frame header DFH can be determined. The third integrity check then follows by checking the payload data contained in the device frame data field DFD using the dfdCRC check field provided for this purpose. If an error is detected, an Ethernet frame EF is generated and sent in the form of an error response, as explained above using the example of the integrity check of the intermediate level frame header LFH.

The protection of the intermediate level frame header LFH by means of its own CRC check field IfhCRC, separate from the protection of the individual device frames DF, is a first feature that helps to detect any data errors. The additional protection of the respective device frame DF further increases the reliability of error detection. In one variant, the respective device frame can be protected as a whole by a CRC check field, the checksum of which is formed over the entire device frame DF. For error detection, however, it is more advantageous if the header DFH and the data field DFD with the payload are each protected separately by their own CRC check field, as in the example. The separate protection also speeds up error detection. The generator polynomials and accordingly the field size of the respective CRC check field are selected to match the scope of the separately protected data areas in order to meet the requirements of functional safety.

The 4 and 5 show a network in which the control device 1 is connected to the terminals 11 - 14 via the data connection 2 and the distributor 3. The 4 and 5 illustrate the operation of the network, which is divided into several logical groups of terminal devices by means of the protocol according to the invention and in particular the Ethernet frame structured according to the invention. For the division, the terminal devices 11 - 14 are each assigned a group identification in the commissioning phase. For this purpose, the Ethernet frame mode field MsgType from the control device 1 is set to commissioning mode, the group identification field GroupID is set to broadcast and the terminal devices 11 - 14 are assigned a group identification by means of a common device frame in The respective group identification is assigned in the form of a summation frame telegram. For example only, it is assumed that the terminals 11 and 12 are assigned a first group identification Gr1 and the terminals 12 and 14 are assigned a different, second group identification Gr2. Gr1 and Gr2 are merely symbolic of the respective bit sequence that corresponds to the assigned group identification. The first logical group Gr1 and/or the second logical group Gr2 can each comprise further network components. The network can also have one or more further logical groups of terminals that are connected to the control device 1 via the data connection 2 and the distributor 3 or one or more further distributors. The data connection 2 is shown in solid lines and the logical connections are shown in dashed lines.

In 6 are a first cycle T ₁ of data communication and the beginning of an immediately following second cycle in the network of 4 and 5 The first cycle T ₁ only affects the terminal devices 11 and 12 of the first group Gr1, and the second cycle only affects the terminal devices 13 and 14 of the second group Gr2. The two cycles can also be referred to as the first and second group cycles. In the first group cycle T ₁ , the control device 1 sends an Ethernet frame EF1 in the cycle operation mode, in whose group identification field the group identification Gr1 is set. The Ethernet frame EF1 is therefore only directed to the terminal devices to which the group identification Gr1 has been assigned; in the exemplary embodiment, these are the terminal devices 11 and 12. If the distributor 3 is not set up to filter the Ethernet frames according to group membership, all terminal devices 11 - 14 receive the Ethernet frame EF1. The terminal devices of the logical group(s) not identified in the group identification field, here terminal devices 13 and 14, are set up to read the intermediate level frame header LF1 of the Ethernet frame EF1 and to recognize from the group identification field that the Ethernet frame EF1 is not addressed to them. The terminal devices 13 and 14 therefore ignore the Ethernet frame EF1. The terminal devices 11 and 12, however, and possibly other network components with the group identification Gr1, process the device frames assigned to them, which are contained in the intermediate level frame LF1.

For example, it is assumed that the intermediate level frame LF1 contains a device frame DF11req for the terminal 11 and a device frame DF12req for the terminal 12. The intermediate level frame LF1 can contain one or more additional device frames for the terminal 11 and/or one or more additional device frames for the terminal 12 and/or one or more additional device frames for optionally additional network components of the logical group Gr1. In response to the request transmitted with the Ethernet frame EF1, each of the terminals 11 and 12 with the group identification Gr1 sends an Ethernet frame. In response to the request identified in the request/response field of the respective device frame DF11req and DF12req of the Ethernet frame EF1, the terminal device 11 sends the Ethernet frame EF11 with the device frame DF11resp as a response and the terminal device 12 sends the Ethernet frame EF12 with the device frame DF12resp as a response. The Ethernet frames EF11 and EF12 of the terminal devices 11 and 12 are sent sequentially, i.e. one after the other, to the control device 1. After the Ethernet frame EF1 is sent, the watchdog time T _w begins, during which the control device 1 waits for the response(s) of the terminal devices addressed in the respective device frame. In the example, these are the terminal devices 11 and 12. The first cycle T ₁ is only completed when the control device 1 has received an Ethernet frame as a response from each of the terminal devices in the first logical group for which an associated device frame with a request was sent with the Ethernet frame EF1. In the example, it is assumed that the Ethernet frame EF1 contains a request for both the terminal device 11 and the terminal device 12.

In the subsequent second cycle of data communication, the control device 1 sends an Ethernet frame EF2 in the cyclic operation mode, in whose group identification field the group identification Gr2 is set. The Ethernet frame EF2 is therefore only directed to the terminal devices to which the group identification Gr2 has been assigned; in the exemplary embodiment, these are the terminal devices 13 and 14. If the distributor 3 is not set up to filter the Ethernet frames according to group membership, all the terminal devices 11 - 14 also receive the Ethernet frame EF2. The terminal devices of the logical group(s) not identified in the group identification field, here the terminal devices 11 and 12, are set up to read the intermediate level frame header LF2 of the Ethernet frame EF2 and to recognize from the group identification field that the Ethernet frame EF2 is not directed at them. The terminal devices 11 and 12 therefore ignore the Ethernet frame EF2. The terminal devices 13 and 14, however, and possibly other network components with the group identification Gr2, process the device frames assigned to them, which are contained in the intermediate level frame LF2, and respond analogously to the terminal devices of the first group in the first cycle T ₁ .

In 7 are from the Ethernet frame EF1 the intermediate level frame LF1 and from the two Ethernet frames EF11 and EF12 of the end devices 11 and 12 also show the respective intermediate level frame LF11 and LF12 with the device frame DF11resp and DF12resp sent as a response. The intermediate level frame LF1 of the Ethernet frame EF1 sent by control device 1 contains, for example, the number n in the counting field MsgCnt, the group identification Gr1 in the GroupID field and the own ControllerID in the source identification field SourceID. The cycle operation mode is shown in the mode field MsgType. The payload area LFD of the intermediate level frame LF1 contains the two device frames DF11req and DF12req, each with a request for a response.

In the intermediate level frame LF11 of the Ethernet frame EF11 sent by the terminal device 11 in response, the bit sequences in the data fields MsgCnt, GroupID and MsgType correspond to the bit sequences in the corresponding fields of the Ethernet frame EF1 sent by the control device 1. In the source identification field SourceID, the terminal device 11 has entered its own device identification DeviceID-11 and in the payload area LFD the requested payload data in the form of the device frame DF11resp. Accordingly, in the Ethernet frame it sent in response, the terminal device 12 has entered its own device identification DeviceID-12 in the SourceID field and in the payload area in the device frame DF12resp the requested payload data. Apart from the CRC check field, the intermediate level frames LF11 and LF12 sent by the terminal devices 11 and 12 in the Ethernet response frame can otherwise correspond to one another.

For the Ethernet frame EF1 sent by control device 1, 7 Furthermore, the device frame DF11req is also shown as a representative of the device frame DF12req. The device frame DF11req contains the device identification DeviceID-11 in the target identification field. In the control and status field, the device frame DF11req is shown as a request. In the Ethernet frames DF11resp and DF12resp sent as a response from the terminal devices 11 and 12, the device identification ControllerID of the control device 1 is entered in the respective target identification field. In the control and status field, the device frames DF11resp and DF12resp and thus the respective Ethernet frame are identified as a response. The respective payload area DFD contains the payload data data11 and data12 of the respective terminal device.

The Ethernet frame EF according to the invention also enables direct communication between the terminal devices within the respective logical group Gr1 and Gr2, which is 4 and 5 is to be indicated by the connections shown in dashed lines. The Ethernet response frames of the terminal devices are received by all network components, at least in versions in which the distributor 3 does not carry out filtering. If, for example, the terminal device 12 requires payload data from the terminal device 11, it recognizes the device identification of the terminal device 11 in the source identification field SourceID in the Ethernet response frame EF11 of the terminal device 11 and can read and process the payload data of the terminal device 11 directly. The prerequisite for direct data communication is that at least one of the terminal devices is set up in terms of its hardware and software in such a way that it can recognize the respective device identification of one or more other terminal devices as relevant and process the payload data received with it. In the example, the terminal device 12 must be set up to process not only the Ethernet frames of the control device 1, but also the Ethernet frames of the terminal device 11. If the terminal 11 is a sensor, for example a temperature sensor, and the terminal 12 is an actuator with a control or regulation, for example a thermostat, the terminal 12 can be controlled or regulated directly using the measurement data received directly from the terminal 11. This relieves the load on the control device 1 and the network operation. The pair of thermostat and temperature sensor mentioned is only an example. In the same way, a motor control and a speed sensor and/or a position sensor or even a control valve and a volume flow sensor and/or level sensor can be components of a logical group and communicate with each other either via the control device or directly at the logical level.

8 shows the network of 4 and 5 including the division into the logical groups Gr1 and Gr2, but also indicates that direct communication between terminals can also be carried out across groups. A terminal equipped with sufficient intelligence, for example terminal 12 of the logical group Gr1, can generate an Ethernet frame for this purpose and identify this Ethernet frame as a broadcast in the group identification field GroupID of the intermediate level frame LF. In the one or more device frames for the other terminal(s) from which answers are requested, terminal 12 enters the respective device identification DestinationID in the assigned device frame. The respective terminal that is requested in this way itself sends an Ethernet frame as a broadcast in the GroupID field and enters the device identification of the requesting terminal 12 as the Destination ID in the device frame(s) intended for the requesting terminal 12. It enters its own device identification in the SourceID field. For data communication across groups, the requesting terminal itself has the capabilities of a control device. by entering the group ID field. identification field and the respective destination identification field. The terminal device in question can also conveniently set the request/response bit to request in order to mark the Ethernet frame it has sent as a request.

In the described cases of direct communication within the group and direct communication across groups, control device 1 is not absolutely necessary, but it does "listen in". Due to the listening, control device 1 can perform a diagnostic function in the respective direct communication.

Claims (16)

Method for data communication in a network with a control device (1) and several terminal devices (11-14) connected to the control device (1) by means of Ethernet frames (EF), the Ethernet frame (EF) each comprising: 1.1 an Ethernet frame header (EFH) and an Ethernet frame data field (EFD); 1.2 several device frames (DF11 - DF14) contained in the Ethernet frame data field (EFD) that are assigned to one or more of the terminal devices (11-14); 1.3 wherein the device frames (DF11 - DF14) each have a device frame data field (DFD) with user data to be processed and a device frame header (DFH) with a destination identification field (DestinationID) for identifying an addressee of the respective device frame (DF11 - DF14); and 1.4 an intermediate level frame (LF) which is contained in the Ethernet frame data field (EFD), preferably forming the Ethernet frame data field (EFD); where 1.5 the intermediate level frame (LF) has an intermediate level frame data field (LFD) with the multiple device frames (DF11 - DF14) and 1.6 an intermediate level frame header (LFH) common to the device frames (DF11 - DF14) with a source identification field (SourceID) for identifying a sender of the Ethernet frame (EF); 1.7 where the device frame header (DFH) of the respective device frame (DF11 - DF14) contains a control and status field (CTR & status) with a request/response value and the request/response value informs the addressee of the respective device frame (DF11 - DF14) whether the respective device frame is a request to send payload data or the payload data contained in the device frame data field of the respective device frame (DF11 - DF14) is sent in response to a request. Method according to the preceding claim, wherein the intermediate level frame header (LFH) contains a group identification field (GroupID) with a group identification (Gr1, Gr2) which identifies the device frames (DF11 - DF14) contained in the intermediate level frame (LF) as device frames of a group of terminal devices that belong together, so that the terminal devices (11-14) can be divided into different logical groups of terminal devices by assigning each of them a specific group identification. Method according to one of the preceding claims, and at least one of the following features 3.1 to 3.3: 3.1 the intermediate level frame contains a CRC check field (IfhCRC) to protect the intermediate level frame header (LFH); and/or 3.2 the device frame (DF) contains a CRC check field (dfhCRC) to protect the device frame header (DFH); and/or 3.3 the device frame (DF) contains a CRC check field (dfdCRC) to protect the device frame data field (DFD). Method according to one of the preceding claims, wherein the device frame header (DFH) of the respective device frame (DF11 - DF14) contains a control and status field (CTR & Status) with a safety value and the safety value informs the addressee of the respective device frame (DF11 - DF14) whether the respective device frame (DF11-DF14) contains payload data relevant to functional safety. Ethernet-capable network with at least the following network components, which are used for data communication according to a method according to one of the preceding claims, each in combination with Claim 2 are set up: 5.1 a control device (1); 5.2 optionally one or more distributors (3); 5.3 a first terminal (11) and a second terminal (12) which are connected to the control device (1), preferably via the one or more optional distributors (3), and which are assigned a first group identification (Gr1) so that they belong to a first logical group, and which, through the assignment of the first group identification (Gr1), are set up to process data of the device frame data fields (DFD) if the group identification field (Group ID) identifies the first group identification (Gr1); 5.4 a third terminal (13) and a fourth terminal (14) which are connected to the control device (1), preferably via the one or more optional distributors (3), and which are assigned a second group identification (Gr2) so that they belong to a second logical group, and which are set up to process data of the device frame data fields (DFD) by the assignment of the second group identification (Gr2), if the group identification field (Group ID) indicates a different, second group identification (Gr2); 5.5 wherein the distributor or distributors (3), if present, are or are set up to only forward the respective Ethernet frame (EF1, EF2) to the terminal devices (11-14) of the first logical group if the first group identification (Gr1) or a broadcast is indicated in the group identification field (Group ID), and to only forward the respective Ethernet frame (EF1, EF2) to the terminal devices (11-14) of the second logical group if the second group identification (Gr2) or a broadcast is indicated in the group identification field (Group ID); and/or 5.6 the terminal devices (11, 12) of the first logical group are set up to process the payload data of the device frames (DF) only if the first group identification (Gr1) or a broadcast is indicated in the group identification field (Group ID) of the respective Ethernet frame (EF1), and the terminal devices (13, 14) of the second logical group are set up to process the payload data of the device frames (DF) only if the second group identification (Gr2) or a broadcast is indicated in the group identification field (Group ID) of the respective Ethernet frame (EF2). Ethernet-capable network according to the preceding claim, wherein the control device (1) is configured to write optionally the first group identification (Gr1) or the second group identification (Gr2) into the group identification field (Group ID) of the respective Ethernet frame (EF1, EF2). Ethernet-capable network according to one of the Claims 5 and 6 , wherein the control device (1) and the terminal devices (11-14) each have a device identification and the respective device frame header (DFH) in the destination identification field (DestinationID) contains the device identification of an addressee (1, 11, 12, 13, 14) of the respective device frame (DF11 - DF14), for example a CRC signature of a MAC address of one of the terminal devices (11-14) or of the control device (1), and the respective device frame data field (DFD) contains user data for the addressee (1, 11, 12, 13, 14) identified in the destination identification field, and wherein the control device (1) and preferably also the respective terminal device (11-14) is/are set up to read the device identification of the addressee in the destination identification field (DestinationID) and/or to enter it into the destination identification field (DestinationID) to write. Ethernet-capable network according to one of the Claims 5 until 7 , wherein the control device (1) and the terminal devices (11-14) each have a device identification and the intermediate level frame header (LFH) in the source identification field (SourceID) contains the device identification of the sender of the respective Ethernet frame (EF), and wherein the control device (1) and preferably also the respective terminal device (11-14) is/are set up to read the device identification of the sender in the source identification field (SourceID) and/or to write its own device identification in the source identification field (SourceID). Ethernet-capable network according to one of the Claims 5 until 8 , wherein the first group identification (Gr1) is assigned only to terminal devices (11, 12) that meet the functional safety requirements, and the second group identification (Gr2) is assigned to one or more or only terminal devices (13, 14) that do not meet the functional safety requirements, so that the network is divided into network areas of different functional safety based on the allocation of the group identifications (Gr1, Gr2). Ethernet-capable network according to one of the Claims 5 until 9 , wherein the device frame header (DFH) of the respective device frame (DF11 - DF14) contains a control and status field (CTR & Status) with a safety value that informs the addressee of the respective device frame (DF11 - DF14) whether the respective device frame (DF11-DF14) contains payload data relevant to functional safety, and wherein at least the first terminal (11) meets the requirements of functional safety and is set up to process a device frame (DF11) addressed to the first terminal (11) only if the safety value of the respective device frame (DF11) assigned to the first terminal (11) indicates that this device frame contains payload data relevant to functional safety. Ethernet-capable network according to one of the Claims 5 until 10 , where 11.1 the intermediate level frame contains a CRC check field (IfhCRC) to protect the intermediate level frame header (LFH) and/or the device frame (DF) contains a CRC check field (dfhCRC) to protect the device frame header (DFH) and/or the device frame (DF) contains a CRC check field (dfdCRC) to protect the device frame data field (DFD); 11.2 the device frame header (DFH) of the respective device frame (DF11 - DF14) contains an error status field (DataCRCErr) to indicate the detection of an error in the data of the intermediate level frame header (LFH) and/or the device frame header (DFH) and/or the device frame data field (DFD); and 11.3 the control device (1) is arranged to transmit an Ethernet frame (EF) with a request for a response in one or more of the device frames (DF), and 11.4 one or more of the terminal devices (11-14) is or are set up to - check the data integrity of the intermediate level frame header (LFH) based on the content of the CRC check field (IfhCRC) for the intermediate level frame header (LFH) and/or the data integrity of the respectively assigned device frame header (DFH) based on the content of the CRC check field (dfhCRC) for the device frame header (DFH) and/or the data integrity of the respectively assigned device frame data field (DFD) based on the content of the CRC check field (dfdCRC) for the device frame data field (DFD), - set an error value in the error status field (DataCRCErr) if a data error is detected, and - send an Ethernet frame (EF) containing the error value in the error status field (DataCRCErr) as a response to the control device (1). Ethernet-capable network according to one of the Claims 5 until 11 , wherein the control device (1) and the terminal devices (11-14) are field devices and the data communication in the network takes place at the field level. Method according to one of the Claims 1 until 4 , which is carried out in an Ethernet-capable network, in which network components comprising a control device (1), several terminal devices (11-14) and optionally one or more distributors (3) for data communication are connected to one another, preferably via the one or more distributors (3), and in which 13.1 the network components (1, 3, 11-14) for data communication are connected to one another according to a method according to one of the Claims 1 until 4 each in combination with Claim 2 are set up; 13.2 the terminal devices (11-14) are grouped into a first logical group of terminal devices (11, 12) and a second logical group of terminal devices (13, 14) by 13.3 assigning a common first group identification (Gr1) to the terminal devices (11, 12) of the first logical group and a different, common second group identification (Gr2) to the terminal devices (13, 14) of the second logical group; 13.4 a network component, preferably the control device (1), writes the first group identification (Gr1) into the intermediate level frame header (LFH) of a first Ethernet frame (EF1) and sends the first Ethernet frame (EF1) to the terminal devices (11-14) in a first cycle (T ₁ ) of the data communication; 13.5 the respective terminal device (11, 12) of the first logical group reads the group identification field (GroupID) of the first Ethernet frame (EF1), recognizes the bit sequence contained therein as the group identification (Gr1) assigned to it and processes the one or more device frames that are assigned to the respective terminal device by the device identification in the destination identification field (DestinationID) of the respective device frame; and in which 13.6 the respective terminal device (13, 14) of the second logical group reads the group identification field of the first Ethernet frame (EF1), recognizes the bit sequence contained therein as a group identification (Gr1) not assigned to it and therefore does not process the first Ethernet frame (EF1). Method according to the preceding claim, in which 14.1 one or more of the device frames of the first Ethernet frame (EF1) contains or each contain a request to send user data; 14.2 the respective terminal (11, 12) of the first logical group, to which one or more device frames with a request is/are assigned in the first Ethernet frame (EF1), writes the requested user data into the respective assigned device frame containing the request and 14.3 sends an Ethernet frame (EF11, EF12) with its user data as a response to the requesting network component (1); and 14.4 the first cycle (T ₁ ) is only ended when each of the terminals (11, 12) of the first logical group, for which the first Ethernet frame (EF1) contains one or more assigned device frames with a request, has each sent an Ethernet frame (EF11, EF12) as a response. Procedure according to one of the Claims 13 and 14 , in which 15.1 the respective Ethernet frame (EF1, EF2) contains in the intermediate level frame header (LFH) an Ethernet frame count field (MsgCnt) with an Ethernet frame number which indicates the position of the respective Ethernet frame in a sequence of consecutively sent Ethernet frames (EF1, EF2); and 15.2 the control device (1) increments the Ethernet frame number for the next Ethernet frame (EF1, EF2) to be sent, 15.3 while the Ethernet frame number cannot be changed by the terminal devices (11-14). Procedure according to one of the Claims 13 until 15 , in which 16.1 the respective Ethernet frame (EF1, EF2) contains in the device frame header (DFH) a device frame count field (seqCnt) with a device frame number which indicates the position of the respective device frame (DF) in a sequence of device frames (DF) addressed consecutively to the same terminal; 16.2 the control device (1) the device frame number for the next device frame addressed to the same terminal to be sent is incremented; and 16.3 the respective terminal (11-14) reads and converts the device frame number, for example inverts it, and writes the converted device frame number into the device frame count field (seqCnt) of the next device frame (DF) to be sent to the control device (1).

Images