Port-independent, topologically planned real-time network

Abstract

Port-independent topologically planned real-time network with a target configuration (40) of the network topology for use in industrial networks for the transmission of time-critical data in (process) automation systems with at least two network participants (A, B, C, D, E, F, G, H, I, J, X) each with at least one network interface (1, 2, 3, 4) for connection to the port-independent topologically planned real-time network, wherein a first of these network participants is a device (200) which has means for data processing and for executing program code as well as means for data exchange with the at least one other network participant, wherein at least one further network participant is connected to the device via the network, characterized in that the device includes means for configuring at least one other network participant with regard to data exchange over the network according to a target state; the device is programmed in such a way that, in response to at least one configuration-relevant piece of information provided by an operator, it generates a set of configuration data required for configuring at least one other network participant; the device transmits at least a subset of this generated set of configuration data to at least one other network participant via the network; the physical connection of the network participants to the topologically planned real-time network via the network interfaces, regardless of the use of a topologically planned network interface for this purpose, which is at least one network interface of the respective network participant; and By specifying a target value for a neighborhood of at least two network participants, the guarantee of communication planning is ensured.

Description

Field of the invention

[0001] The present invention relates to a port-independent topologically planned real-time network (IRTnet - isochronous real time network), which can be used in particular in industrial networks such as PROFINET-IRT (Process Field Network isochronous real time), but also in other, preferably Ethernet-based communication or data transmission networks, in particular in the field of (process) automation technology (so-called Industrial Ethernet). Background of the invention

[0002] Real-time capable or real-time bound, and especially isochronous or isochronous communication and data transmission networks, require a complete specification of the network topology for their implementation. Examples of isochronous networks, i.e., networks that ensure real-time-based or real-time bound and synchronous or isochronous, and thus deterministic and possibly equidistant, communication or data transmission between at least two of their participants, hereinafter also referred to as network participants.

[0003] Since network cabling in industrial environments is usually done from machine to machine, these Industrial Ethernet networks are usually implemented in a line or ring topology.

[0004] To achieve deterministic communication properties with Ethernet technology, access to the communication medium is subject to additional rules. Different approaches exist here. Some standards reserve the medium entirely for real-time telegrams, while others reserve time periods for real-time telegrams. Knowledge of the exact network topology is a prerequisite for such scheduling of media access, as well as for the purposes of topological address assignment.

[0005] The operation of a topologically planned Real-Time Ethernet (RTE) network therefore requires precise advance planning of which device in the topologically planned RTE network, which device adjacent to the first device, is connected to which predetermined Ethernet interface (so-called "port") of the first device. Furthermore, the cable length of the connection between two devices is often predetermined.

[0006] Precise advance planning concerns at least the logical configuration of the network, in particular with regard to the sequence of data to be transmitted, and, where appropriate, also the physical configuration, in particular with regard to the data transmission paths in order to optimise data transmission depending on the topology of the network.

[0007] Clock-synchronous or isochronous communication or data transmission using topologically planned real-time Ethernet networks is particularly necessary for controlling movements in drive technology (motion control), for example for motor control or positioning processes.

[0008] For the purposes of this application, communication or data transmission networks, i.e., interconnected systems that enable data exchange and thus communication between the participants connected by or via them, are also referred to simply as networks. The participants mentioned are, in particular, computers, programmable logic controllers, or other machines or devices, particularly from the field of (process) automation technology, such as sensors or actuators, that communicate with each other via the network, exchange data, and, in particular, process data.

[0009] The control program is preferably modular and preferably comprises corresponding program sections for each device type and each configuration of the system or device list for its control, whereby each program section can comprise one or more function blocks. When the control program is executed by the control device, the program sections required to control the devices or devices actually located in the system and thus connected to the network and to the control device are then executed.

[0010] The IO configuration is the definition of the composition of the process or IO data in a data telegram, particularly with regard to their structure, quantity and sequence.

[0011] The physical configuration includes the definition of a network topology, i.e. the network participants and the connections between them or their network interfaces.

[0012] Furthermore, on the basis of at least some of such information resulting from the logical and physical configuration for an RTE network, an RTE planning algorithm additionally calculates RTE communication parameters for the network, which in particular define transmission and reception times, i.e. times at which a data telegram is to be transmitted from a first to another network participant.

[0013] To plan or configure the logical and physical configuration of a real-time and isochronous network during the planning and setup of the network for its commissioning, for example, after a new construction or conversion of a (process) automation system, for a PROFINET IRT network, for example, a person familiar with the configuration of such networks or systems uses a so-called engineering system. Such an engineering system is usually formed by an engineering tool running on a data processing device, in the context of which an RTE planning algorithm can also run to calculate RTE communication parameters for the RTE network. At the end of this planning step, the RTE communication parameters are calculated by the RTE planning algorithm.Subsequently, the engineering system, which is at least temporarily connected to the network for this purpose, transmits the following information to the control device: a control program, a device list, an IO assignment, an IO configuration, a target topology as a specification for setting up the network with its nodes and connections, as well as the other RTE communication parameters. In general, such engineering systems are known and available for a variety of network types, especially Ethernet-based networks.

[0014] From the information available to the control unit, in particular the target topology and the RTE communication parameters, the relevant parts are transmitted to each network node. The network nodes then independently check whether their direct neighboring nodes match the planned nodes and network interfaces according to the target topology. If each node has identified a corresponding match, the target topology can be activated as the actual topology and the network with its nodes or the system with its devices can be put into operation. However, if a node detects deviations between the actual state and the target topology when checking its neighbors, it uses state-of-the-art technology to send a diagnostic alarm to the control unit, which prevents the network from being put into operation until the cause has been remedied.

[0015] In Fig. 1 shows a schematic diagram of this known solution, where the physical configuration is represented by the target topology and the logical configuration by the IO assignment, the latter being represented by the arrows between the device list and the control program.

[0016] A disadvantage of this Fig. 1 schematically illustrated solution according to the prior art is that although the control program is designed in such a way that individual devices, i.e. plant or machine parts and functions, are represented by corresponding program modules, so that several variants of a plant or machine can be controlled by the control program, with each change to the actual topology or the actual state of the network, for example due to modification of the plant, removal and / or addition of devices, above all the target topology must be adapted accordingly by means of the engineering system and transmitted again to the control device together with the RTE communication parameters newly calculated on this basis, from where in particular the affected participants and their neighboring participants receive the corresponding parts of the new information, in particular the target topology and RTE parameters, before the network orthe system can be put back into operation in its modified state.

[0017] According to another known solution for project engineering or planning a real-time capable and isochronous network, it is provided that several alternative configurations and in particular the respective target topologies and, if applicable, the associated RTE parameters are kept on the control device according to the possible variants of a system or machine, which then, without the need for an additional engineering system, only need to be selected according to the respective actual topology or the respective actual state of the network of a specific variant of the system, for example via a human-machine interface assigned to the control device, in particular a simple display and operating unit connected to the control device.

[0018] However, one problem with this solution is that for machines with a wide variety of variants, such as in modular machine construction, where the number of machine variants is almost unlimited, it is no longer practical to have the required configuration, including the target topology and the RTE communication parameters, already available on the control device for each possible variant.

[0019] Another known solution, according to German patent application DE 102006042949.4, is based on the actual topology of the network and, to a certain extent, dispenses with the specification of a target topology. A so-called topology server in a communications network with additional main nodes is programmed to check whether an internal network event has occurred. If the internal network event occurs, it automatically determines the current actual topology, automatically determines topology-dependent communication data based on the communication relationships assigned to the main nodes, and automatically transmits the relevant portion of the topology-dependent communication data to each main node.

[0020] While this solution offers greater flexibility compared to the previously described approach, it poses a security risk due to the lack of a target topology independent of the actual topology or the current state of the network. Without the ability to perform a target-actual comparison, errors such as incorrect wiring or the absence of at least one device that would be required for a specific variant of the machine or system cannot be reliably detected. Furthermore, while this solution allows an operator to initiate the automatic configuration process from outside, it does not provide any other means of influencing the configuration.

[0021] Thus, while solutions are known that at least partially enable dynamic adaptation of the physical configuration to changed network topologies, dynamic adaptation of the logical configuration to changes in the IO assignments and / or IO configurations is not known. Rather, IO assignments and / or IO configurations are always rigidly predefined by an engineering system and, if an adaptation is required, generally require the assistance of the engineering system again. This is impractical if, for example, a device in a system or machine is to be replaced due to a defect and the new device, although it offers the same functions as the old device, requires, for example, a different process or IO data wiring and / or a different composition of the process or IO data in a data telegram because it is of a different type and / or comes from a different manufacturer than the old device.

[0022] The handling of an engineering system is usually only mastered by appropriately specialized personnel and can therefore be overwhelming for the operator of a plant.

[0023] It is common to create this planning using software-based tools that allow, for example, graphical representation and editing of the network topology. Fig. 4 shows an example topology.

[0024] The fact that the topology must be fully defined in advance results in limitations. A PROFINET system, for example, ensures that an RTE system only starts up if all installed neighboring devices also correspond to the neighboring devices planned in advance. In this case, not only the device names but also the occupied Ethernet interfaces must match the planning. As a result, errors during the installation phase or after a device replacement can lead to a machine and / or an entire system failing to start up. This situation can only be remedied by diagnosing the difference between the target and actual configuration and correcting the installation. In previous methods, this was checked by informing each device of the planned neighboring devices along with the respective port information.If differences are detected between the actual configuration and the previously planned target configuration, a diagnosis is triggered, which usually leads to the user program being stopped and thus possibly to the entire system coming to a standstill.

[0025] Precisely planning the target topology using an engineering system requires the user to precisely define how the devices and their Ethernet interfaces are to be installed. These considerations, as well as the installation itself, are unusual with conventional Ethernet due to the "plug-and-play" approach enabled by dynamic port addressing.

[0026] In summary, this means that the installation of the PROFINET network must exactly match the planning. The installer must also strictly adhere to the specifications regarding the interfaces to be selected.

[0027] This isn't always easy in practice, as local conditions may require deviations from the plan during installation. These deviations lead to increased effort in adapting the plan, as the interface assignments must be revised and the network reconfigured.

[0028] Even when replacing one of the devices, for example, due to maintenance work or a defect, it often happens that an incorrect network interface selection leads to lengthy troubleshooting. In particular, an error can occur during a device replacement because the network interface cannot be assigned to the previously installed one. The use of PROFINET IRT in practical tests has shown that swapping ports is a very common cause of errors. General description of the invention

[0029] The invention therefore has the object of providing a method which is able to solve at least one of the problems mentioned.

[0030] One object underlying the present invention is therefore to be able to start operation for the planning and implementation of a system as well as for the replacement of a device despite the safety-relevant specification of the target topology and the target-actual comparison thus made possible, even with swapped or otherwise incorrectly connected network connections between the network participants.

[0031] When creating the target structure of the network topology, it is not necessary to define a specific port, and in particular, when setting up the physical network structure of the Ethernet connections, it is not necessary to use the exact ports planned for the respective network participants. Rather, the object of the invention is to enable the operation of the network or system as a whole, even when using non-standard network interfaces.

[0032] Advance planning in the engineering system can therefore be performed without detailed specifications of the network interfaces of the network participants. This simplifies planning while still ensuring secure network operation.

[0033] In particular, this option should be suitable for networks with real-time and synchronous or isochronous data transmission between the participants, ie the network participants.

[0034] In particular, the invention is intended to make the use of an engineering system to maintain operations largely unnecessary.

[0035] In particular, a target-actual comparison should continue to be possible, especially with regard to the network topology.

[0036] In particular, however, the preparation and maintenance of a large number of target topologies should be avoided so that, for example, a swap of a network interface does not represent a new target topology and thus represents a potential source of error.

[0037] In particular, a logical configuration and / or physical configuration of the communication and the network should be possible.

[0038] This option should be particularly suitable for systems or machines with a wide variety of variants.

[0039] The problem is solved by the subject matter of independent claim 1. Preferred embodiments are recited in the subclaims.

[0040] According to the invention, each device compares the planned (target) neighboring devices and their (target) Ethernet ports with the installed (actual) neighboring devices and (actual) Ethernet ports. If the specified (target) neighborhood matches the physical (actual) neighborhood, the port information from the planned target configuration is applied to the physical ports.

[0041] By specifying a target, i.e., planning in advance, at least the proximity of at least two network devices, communication planning can be ensured. This communication planning, which can be defined in advance, determines the transmission path through the network based on the devices. Communication planning based on the devices' Ethernet ports is no longer necessary, allowing for more flexible installation of network cables while still ensuring a minimum level of security.

[0042] The network connection is released if the verification of the actual physical configuration of the port connection against the target configuration of the network topology shows a match in the proximity. The RTE network starts up after the target / actual comparison has been carried out, and the network connections are released. The application of the communication parameters defined by means of communication planning to the at least one port of a device is determined by the configuration check. This means that only when the verification of the actual physical configuration of the port connection against the target configuration of the network topology shows a match in the proximity are the communication parameters applied to the at least one network interface of the at least one device. This activates the port and / or the connection, depending on the selection of the communication parameters.

[0043] This improvement can be achieved through implementations in the devices themselves. There is no need to expand the PROFINET standard, if used, nor do engineering systems need to be modified. This can significantly simplify and improve handling during installation, maintenance, and device replacement for networks planned according to the current state of the art, without requiring the entire network to be rebuilt.

[0044] When planning the target topology for a new or existing network, specific port information can be omitted. Only the devices that will be connected to which neighboring devices are planned in advance. Attributes such as cable length or the number of connections (in the example, between "C" and "D") can be specified for the connection between the devices. This simplifies the engineering process for both the user and the engineering tool manufacturers themselves.

[0045] In response to at least one piece of configuration-relevant information specified by an operator, the device generates a set of configuration data required for configuring at least the at least one further participant and transmits at least a subset of this generated set of configuration data to the at least one further participant via the network.

[0046] To program the device, an engineering system or a comparable system is essentially required only once. After that, a node connected to the network and, via the network, to the device can be configured with regard to data exchange over the network according to a target state without further assistance from an engineering system. The operator is involved in the configuration process due to the required specification of at least one piece of configuration-relevant information. Another advantage is that the operator does not need to be trained in handling a generally very complex engineering system in order to be able to configure a network node with regard to data exchange over the network.

[0047] Conveniently, the at least one configuration-relevant information can be specified by the operator by means of a human-machine interface preferably assigned to the device, in particular by means of an operating unit connected to the device with input and output means.

[0048] Preferably, the device is programmed to configure at least the at least one further participant with regard to logical and / or physical aspects of the data exchange via the network.

[0049] Logical aspects include, as already mentioned at the beginning, the IO data to be sent or received, the IO assignment, and the IO configuration. Physical aspects, as already mentioned, particularly concern the network topology.

[0050] Thus, the device and the method can advantageously be used or applied for the configuration of participants in networks such as PROFINET IRT, which require a physical configuration.

[0051] As will be explained in more detail in connection with the description of the figures, the logical configuration enabled by the present invention without the aid of an engineering system is particularly advantageous when, for example, a device in a system or machine is to be replaced and the new device, while offering the same functions as the old device, requires, for example, a different process or IO data wiring and / or a different composition of the process or IO data in a data telegram because it is of a different type and / or originates from a different manufacturer than the old device. This can also affect the configuration of the network interface, in particular.

[0052] It should be mentioned at this point that the device and the method can also be designed in such a way that only the logical or only the physical configuration is carried out by means of the device, while the other configuration, if required by the respective network, continues to be carried out by means of an engineering system.

[0053] Particularly preferably, the set of configuration data generated and required for configuring at least one further participant with regard to physical aspects comprises a target topology for the network.

[0054] The target topology is generated by the device based on the amount of configuration-relevant information specified by the user, for example, for the respective variant of a modular system or machine. This eliminates the need to maintain multiple target topologies for several possible variants, from which the appropriate one would then have to be selected. However, an actual target topology is still provided as a target specification, which enables an actual target-actual comparison and thus, in particular, the detection of errors such as incorrect wiring or the absence of at least one device that would be provided for a specific variant of the machine or system, thus ensuring safety.

[0055] Depending on the type or specification of the network and its other participants, the device expediently comprises means for data exchange configured for cyclic, real-time, and / or isochronous data exchange via the network. The device, which preferably comprises means for real-time data exchange, is particularly preferably programmed to configure at least the at least one other participant for real-time data exchange via the network. Alternatively or additionally, the device, which preferably comprises means for isochronous data exchange, is particularly preferably programmed to configure at least the at least one other participant for isochronous data exchange via the network.

[0056] Preferably, the device comprises means for data exchange for data exchange via the network, which are designed according to the PROFINET IRT specification.

[0057] Particularly preferably, the set of configuration data generated and required for configuring at least one additional participant comprises a set of RTE-specific parameters calculated by the device. Thus, the device is advantageously designed to also calculate the RTE communication parameters required for configuring, for example, a PROFINET IRT network, so that neither multiple RTE parameter sets need to be maintained for multiple possible variants of a modular system or machine, from which the appropriate one would then have to be selected, nor does an engineering system need to be used to recalculate these parameters.

[0058] According to a particularly preferred embodiment, the device reads a set of configuration-relevant information from the network and / or the at least one further participant, generates the set of configuration data required for configuring at least the at least one further network participant based thereon, and transmits at least a subset of this generated set of configuration data to the at least one further participant via the network in response to at least one piece of configuration-relevant information specified by the operator, in particular a release of the generated set of configuration data.

[0059] According to a preferred embodiment, the device first checks the set of configuration data generated and required for configuring at least one further participant for plausibility before transmitting at least a subset of this generated set of configuration data to the at least one further participant via the network.

[0060] According to a particularly preferred embodiment, the device first checks the set of configuration data generated and required for configuring at least the at least one further participant for plausibility with regard to the actual state of the network and at least the at least one further participant before transmitting at least a subset of this generated set of configuration data to the at least one further participant via the network.

[0061] Preferably, the device is programmed to configure itself with respect to data exchange via the network using at least a subset of the generated set of configuration data.

[0062] According to a particularly preferred embodiment, the device is programmed to control the at least one additional participant after configuration, wherein the device is, in particular, a programmable logic controller. Thus, according to the invention, it is preferably provided that a programmable logic controller is programmed such that it not only controls participants of a network, which are, in particular, devices of a system or machine, but can also configure them with regard to data exchange via the network prior to the operating phase, and thus executes, for this purpose, not only the program code of a control program but also the program code of a configuration program.

[0063] Furthermore, according to another of the independent claims, the present invention provides a data processing and transmission system comprising a device according to one of the embodiments described above and at least one further participant which are connected to one another via a network and can exchange data with one another.

[0064] Furthermore, according to another of the independent claims, the present invention provides a data carrier with a program code stored thereon, wherein the program code is designed such that a device according to one of the embodiments described above is designed when it is programmed with the program code.

[0065] In the following, the invention is explained in more detail using exemplary embodiments and with reference to the figures, wherein identical and similar elements are partly provided with the same reference numerals and the features of the various exemplary embodiments can be combined with one another. Short description of the characters

[0066] From the attached drawings show Fig. 1 a schematic representation of a prior art solution for configuring participants in a network; Fig. 2a a schematic representation of an embodiment variant according to the invention for configuring participants in a network; Fig. 2b and Fig. 2c a schematic representation of an example of the configuration of devices of a second extended system variant ( Fig. 2c) starting from a first basic variant of the system ( Fig. 2b) using the embodiment of the invention according to Fig. 2a; Fig. 3a a schematic representation of a further embodiment variant according to the invention for configuring participants in a network; Fig. 3b and Fig. 3c is a schematic representation of an example of the configuration of devices of a system using the embodiment of the invention according to Fig. 3a, after a device of a first type ( Fig. 3b) by a device of a second type ( Fig. 3c) was replaced; Fig. 4 a schematic representation of a ring topological network Detailed description of the invention

[0067] The Fig. 1 shows a schematic representation of a solution known from the prior art for configuring participants in a network, ie network participants, as essentially already described at the beginning.

[0068] For the logical and physical configuration of the devices A, B, C, D and E as well as the control S, which belong to a specific variant of a Fig. 1 not shown in detail and are simultaneously participants in a network via which they are connected according to an actual topology 300 and are to be able to transmit data or exchange data with each other, is to be Fig. 1, which is already known from the prior art, always requires an engineering system 100, which is usually formed by an engineering tool executed on a data processing device, usually a PC or a workstation.

[0069] The actual topology 300 is designed such that controller S is initially connected to network interface 1 of device A via its network interface 1. Device A has two further network interfaces, hereinafter also referred to as ports, in which it is connected to port 1 of device B via port 2 and to port 1 of device C via port 3. Device B is connected to port 1 of device D via its additional port 2, and device C has a connection to port 1 of device E via its additional port 3. There is also a connection between port 3 of device D and port 4 of device E.

[0070] During the planning or configuration of a system with at least one controller S and a number of devices A to E that communicate via data exchange as participants in a network, the engineering system 100 is used for several subtasks. Generally, such engineering systems are known and available for a variety of different network types.

[0071] On the one hand, it serves to design a control or control program 10 with which a control device such as the controller S can be programmed to control devices such as the devices A to E, which are in particular sensors or actuators, during operation of the system. The control program 10 comprises corresponding program code for at least each of the devices A to E. On the other hand, a participant or device list 20 is created by means of the engineering system 100, which contains in particular data records for the controller S and the devices A to E, wherein each device data record comprises a set of information that describes the respective device in detail. It should be noted that even if the device list in the Fig. 1 is represented hierarchically, such that the devices A to E are subordinate to the control S, this is at least not to be understood as a topology.

[0072] By including the device list 20 and the control program 10, the engineering system 100 also carries out the logical and physical configuration of the network participants S and A to E with regard to data exchange via the network, which in this case is implemented as PROFINET IRT, so that the communication between the network participants is or should be cyclic, real-time and isochronous.

[0073] The logical configuration includes, for example, the IO assignment 30, which is Fig. 1 is shown by the arrows between the device data records contained in the device list 20 and the control program 10. In the IO assignment, which is also referred to as mapping, individual process variables or addresses 11 of the control program 10 are assigned to the process or IO data objects defined in the respective device data records of the device list 20, at least of the devices A to E. The logical configuration also usually includes the Fig. 1 IO configuration not shown, which concerns the definition of the composition of the process or IO data of the individual participants in a data telegram, particularly with regard to their structure, quantity and sequence.

[0074] The physical configuration is in Fig. 1 is represented by the target topology 40, by means of which the communication connections between the network participants, i.e., the devices A to E and the controller S, are configured. For this purpose, the information and designations contained in the device data records of the device list 20 regarding individual devices A to E and the controller S, and especially their network interfaces, are used.

[0075] It should be mentioned again that the planning of the logical configuration can be carried out essentially independently of the physical configuration, in particular independently of the topology. Furthermore, the planning of the physical configuration, in particular the target topology, can be carried out essentially independently of the logical configuration, provided that at least a device list exists that contains at least the designations of the individual devices and their individual ports.

[0076] In addition, the engineering system 100 includes Fig. 1 also an RTE planning algorithm 170 for calculating RTE communication parameters for the PROFINET IRT-based network, which, for example, define transmission and reception times, i.e. times at which a data telegram is to be transmitted from one participant to another, in particular based on information from the target topology 40 and the participant or device list 20 as well as the IO configuration.

[0077] Following the planning of the logical and physical configuration by means of the engineering system 100, the entire configuration data, including the device list 20 and the control program 10, are transferred to the controller S (referred to as download in the figure), to which the engineering system 100 is at least temporarily connected.

[0078] From this configuration data, now available on the control device S, the relevant parts are then transmitted to each other participant in the network, i.e., to devices A through E (referred to as a download in the figure). The participants in the network then independently check whether their direct neighboring participants match the planned participants and network interfaces according to the target topology.

[0079] If each node has identified a corresponding match, the configured system with its devices or the network with its nodes can be activated and commissioned. However, if a node detects deviations between the actual and the target state when checking its neighbors, it sends a diagnostic alarm to the S controller, which then prevents commissioning of the system and the network until the underlying error is corrected.

[0080] In this way, according to the Fig. 1, as soon as changes occur with regard to the participants in the actual topology, for example due to a redesign of the system design according to a different variant, be it that at least one participant is added or one is removed or the participants are connected to one another in a different way.

[0081] The disadvantage of this known solution is obvious and has already been explained at the beginning.

[0082] For better comprehensibility, the following description of embodiments according to the invention is based on the Fig. 2a, Fig. 2b and Fig. 2c and 3a, 3b and 3c which are described in the previous description of an already known solution according to Fig. 1 shall be retained, provided that they are comparable features.

[0083] The Fig. 2a shows a schematic representation of an embodiment variant according to the invention for configuring participants of a network, ie network participants.

[0084] The network participants to be configured are the devices A, B, C, D and E as well as the control S, which belong to a specific variant of a Fig. 2a belong to an industrial plant not shown in detail and are connected via a network according to an actual topology 300, via which they are intended to be able to transmit data or exchange data with each other. The actual topology 300 is designed such that, firstly, the controller S is connected via its network interface 1 to the network interface 1 of the device A. In addition to the network interface 1, the device A has two further network interfaces, hereinafter also referred to as ports, whereby it is connected via port 2 to port 1 of the device B and via port 3 to port 1 of the device C. The device B is connected via its further port 2 to port 1 of the device D and the device C has a connection to port 1 of the device E via its further port 3. In addition, there is a connection between port 3 of the device D and port 4 of the device E. Both the controller S and the devices A to E can, in addition to the Fig. 2a each have further network interfaces or ports, which are not shown in the figure, however, since they do not have a network connection according to the actual topology 300.

[0085] Within the scope of planning or project engineering of a system with expediently at least one controller and a number of devices that communicate as participants in a network via data exchange, an engineering system 100 is also used according to the invention for several subtasks. However, the following detailed description of an embodiment variant according to the invention will show the differences compared to the prior art, in particular with reference to the Fig. 1, and the resulting advantages are clear.

[0086] On the one hand, the engineering system 100 is used to design a control or control program 10, with which a control device such as the controller S can be programmed to control devices such as the devices A to E, which are in particular sensors or actuators, during operation of the system. The control program 10 comprises corresponding program code for at least each of the devices A to E, but in particular also for further devices which are used in other variants of the system than the one according to Fig. 2a would be used. On the other hand, a participant or device list 20 is created by means of the engineering system 100, which in particular contains data records for the controller S and the devices A to E, but preferably also for other devices that would be used in other variants of the system, wherein each device data record comprises a set of information that describes the respective device in detail, in particular a unique device name or other designation that allows a unique identification of the respective device, information on the device type, model and manufacturer, a functional description, a definition of the device's process data, a unique designation of each network interface of the device and the respective network interface type, for example with regard to the required transmission medium (e.g., copper or fiber optic). However, even in this example, the device list does not yet represent a topology.

[0087] By including the device list 20 and the control program 10, the engineering system 100 also carries out the logical configuration, in particular of the network nodes S and A to E, with regard to data exchange via the network, which in this case is again implemented as PROFINET IRT, so that the communication between the network nodes is or should be cyclic, real-time, and clock-synchronous. The logical configuration includes, for example, the IO assignment 30, which in Fig. 2a is shown by means of the arrows between the device data records contained in the device list 20 and the control program 10, and in Fig. 2a IO configuration not shown.

[0088] The physical configuration is done at the Fig. 2a, however, no longer by means of the engineering system 100. According to the invention, it is instead provided to design or create a configuration program, preferably by means of the engineering system 100, which comprises program code with which a device 200 can be programmed to configure network participants such as the devices A to E with regard to the data exchange via the network and, for this purpose, to generate a set of required configuration data in response to at least one piece of configuration-relevant information specified by an operator and to transmit at least a subset of the generated configuration data via the network to a participant to be configured, wherein for configuration with regard to physical aspects the set of configuration data generated by the device 200 expediently comprises a target topology.

[0089] As from the Fig. 2a, the device 200 in this example is a controller, so that here the device 200 is simultaneously also the controller S. For this reason, the control program 10 created by means of the engineering system 100 comprises, in addition to a set of program code for the device control with corresponding process variables and / or addresses 11, an additional program section 13 which contains program code, preferably with the integration of at least one function block, for the physical configuration of devices or network participants. Such function blocks or similar or other mechanisms can also be integrated into a standalone configuration program, especially if the device 200 is implemented separately from the controller S, which can also be provided according to the invention on an application-specific basis.

[0090] Function blocks for adding and connecting participants based on their respective unique device and port designations to generate a target topology look like this, for example:

[0091] According to the invention, in this embodiment variant, the transmission of the configuration data, including the device list 20 and the control program 10 together with the program section 13, to the device 200, which in this case is also the controller S at the same time, can therefore already take place (referred to as download in the figure), wherein the engineering system 100 is at least temporarily connected to the device 200.

[0092] Thus, according to the invention, it is preferably provided that a programmable logic controller is programmed in such a way that it not only controls participants in a network, which are in particular devices of a system or machine, but can also configure them in advance of the operating phase with regard to the data exchange via the network, and thus executes program code of a configuration program in addition to the program code of a control program.

[0093] When the control program is executed, program section 13, and thus the program code for configuring the network devices, is preferably executed first. Using an operating unit (not shown in the figure), an operator can now easily enter configuration-relevant information and, with regard to the desired network topology, determine, in particular, which device is connected to another via which port. The operator can access the information from the data records of device list 20 and thus preferably only needs to select the corresponding devices and network interfaces.

[0094] In response to this information, the device 200 or the controller S generates, in addition to the configuration data already transmitted to it by the engineering system 100 regarding logical aspects of the data exchange between the network participants, further configuration data regarding the physical aspects of the data exchange between the network participants and in particular a target topology 40. For this purpose, the information from the data records of the device list 20 regarding the individual devices A to E and the controller S and, above all, their network interfaces are expediently used.

[0095] At runtime, for example, a program section for linking the participant S and A to E to generate the target topology 40, where the above-mentioned function blocks are used accordingly often, looks as follows:

[0096] In the event of a fault, corresponding diagnostic information would be available, which can be output, for example, via a machine-human interface such as an operating unit (not shown) connected to the device 200.

[0097] Conveniently, the device 200 is programmed with additional program code 14 to check the generated target topology 40 for plausibility. In particular, this check determines whether the ports of the devices to be connected are present at least according to the device description derived from the device list 20 and are of the same interface type, and whether the topology is otherwise consistent. In the event of an error, appropriate diagnostic information would be available, which could be output, for example, via a machine-human interface. Such program code 14 could look something like this:

[0098] Preferably, the device 200 is programmed with further additional program code 15 to check the generated target topology with respect to the existing actual topology 300, in particular to determine whether the devices to be interconnected according to the target topology 40 are actually present in the actual topology 300 and whether the device type and device type match according to the target and actual. Preferably, it is also checked whether the unique device designations, as provided according to device list 20 and target topology 40, match those of devices A to E in the actual topology 300. In the event of an error, appropriate diagnostic information would be available, which could be output, for example, via a machine-human interface.

[0099] Since the network according to the actual topology 300 is designed as PROFINET IRT, the device 200 is expediently programmed with further additional program code 17 such that it has the functionality of an RTE planning algorithm for calculating RTE communication parameters, in particular with regard to the sizes of the time slots to be reserved accordingly for the data transmission, based on the device list 20 and the Fig. 2a not shown IO configuration as well as the generated target topology 40.

[0100] An example of such program code 17 could look something like this:

[0101] The program code 14, 15 and 17 is in Fig. 2a as an independent configuration program, but alternatively it could also be, for example, three program sections of a single configuration program or of the control program 10, this also depends in particular on whether the device 200 is a controller or a device separate from the controller.

[0102] Finally, the planned and generated or calculated configuration data are transmitted from device 200 or controller S to the other participants in the network according to the actual topology 300, i.e., to devices A through E (referred to as a download in the figure), with each participant receiving the relevant subset of configuration data. This occurs, for example, based on the following program code:

[0103] After receiving the configuration data, the participants then independently check whether their direct neighboring participants according to the actual topology 300 match the participants and network interfaces planned according to the target topology.

[0104] Alternatively or additionally, when specifying the at least one piece of configuration-relevant information, the operator has the option, according to the invention, of releasing a network topology, which is at least partially automatically determined by the device 200 and preferably displayed on the control unit as a so-called online visualization of the system, as the target topology. In this case, the device 200 is programmed accordingly to generate a target topology based on interconnection information read from the network and the connected devices according to the actual topology, wherein the read interconnection information preferably includes unique designations of the devices and their interfaces.

[0105] Since an operator is integrated into the configuration process according to the invention in such a way that they must specify at least one piece of configuration-relevant information, be it in the form of simply specifying, via an operating unit, which device is connected to another via which port with regard to the desired network topology, or in the form of releasing a network topology automatically determined by the device 200 as the target topology before the set of configuration data generated by the device 200 is transmitted to the network participants and activated, the security offered by an actual target-actual comparison is still guaranteed, but without the need for the re-use of an engineering system for each change to a system, wherein in principle any desired topologies can be generated by the device 200.

[0106] The Fig. 2b and Fig. 2c shows an example of the configuration of the devices of a second extended system variant ( Fig. 2c) starting from a first basic variant of the system ( Fig. 2b) using the embodiment of the invention according to Fig. 2a.

[0107] A system includes, according to its basic variant, as described in the Fig. Figure 2b shows, in addition to a controller 200, devices A, B, and C, which are interconnected and thus participants in a shared communications network. The small numbers next to the participants represent the unique designation of their respective network interfaces.

[0108] In addition to this basic variant, there are further variants according to which the system can, for example, include additional devices as optional additional components, which must also be integrated into the network as participants so that data exchange is possible for their control, at least with the controller 200. For example, there is a variant in which the system also includes a device for material supply, which can potentially be connected to various points in the network.

[0109] During the installation of the system, the individual devices are assembled according to the customer's order and the conditions on site. In this example, the Fig. As shown in Figure 2c, the material supply device (Device X) has also been added and connected via its port 1 to port 3 of Device B. This is indicated by the solid line between Devices X and B, while the dashed lines between Device X and Devices A and C indicate the other connection options.

[0110] The control (PLC) 200 according to Fig. 2b and Fig. 2c is in accordance with the procedure described above and in Fig. 2a, the design variant shown is programmed to be able to control the devices of all possible variants of the system on the one hand, but on the other hand also to be able to generate the configuration data required to configure the respective devices with regard to physical aspects of the data exchange between the devices and the control system.

[0111] As a result, the controller 200 already contains, without this being in the Fig. 2b and Fig. 2c is explicitly shown, in addition to the corresponding program code, a device list and the configuration data required to configure the devices with regard to logical aspects of data exchange and in particular IO assignment and IO configuration, as already described above in connection with Fig. 2a.

[0112] To protect the devices of the Fig. To be able to configure the system variant shown in Figure 2c with regard to physical aspects of data exchange, the controller 200 still requires the operator to input at least one piece of configuration-relevant information. The operator can use the visualization terminal 400 connected to the controller 200 as an operating unit to indicate that, in addition to the basic variant, device X is now connected to port 3 of device B via its port 1. The operator can access the information from the data records of the device list and thus preferably only needs to select the corresponding devices and network interfaces.

[0113] The corresponding program section for subsequent processing of the configuration-relevant information specified by the operator and generation of a corresponding target topology could, for example, look like this at runtime:

[0114] Furthermore, a plausibility check of the generated target topology is performed on the controller 200. Furthermore, the target topology is checked against the existing actual topology. In the event of an error, appropriate diagnostic information would be available, which could be output, for example, via the visualization terminal 400 connected to the controller 200.

[0115] Furthermore, the necessary RTE communication parameters, such as the transmission and reception times of data telegrams, are calculated.

[0116] Finally, the planned and generated or calculated configuration data are transmitted from the controller 200 to the other participants in the network, i.e. to the devices A, B, C and X, whereby each participant receives the subset of configuration data relevant to it.

[0117] After that, the operation of the system in the extended version according to Fig. 2c can be activated.

[0118] The Fig. 3a is a schematic representation of a further embodiment variant according to the invention for configuring participants in a network, which are in particular devices of an industrial automation system.

[0119] The network participants to be configured are the devices A, B, C, D and E as well as the control S, which belong to a specific variant of a Fig. 3a belong to an industrial plant not shown in detail and are connected via a network according to an actual topology 300, which in this case is again implemented as PROFINET IRT, so that communication between the network devices is, or should be, cyclic, real-time, and isochronous. The small numbers next to the devices represent the unique designation of their respective network interfaces.

[0120] Within the scope of planning or designing a system with, expediently, at least one controller and a number of devices that communicate as participants in a network via data exchange, according to this embodiment, an engineering system 100 is essentially only used to design or create a control or control program 10 with which a control device such as the controller S can be programmed to control devices such as the devices A to E during operation of the system. The control program 10 comprises corresponding program code for at least each of the devices A to E, but in particular also for further devices or device types or types that are used in other variants of the system than the one according to Fig. 3a would be used.

[0121] The following detailed description of this embodiment variant according to the invention will show the differences compared to the previously described embodiment Fig. 2a to 2c and the resulting additional advantages are clearly visible.

[0122] According to this further embodiment variant of the invention, in addition to the physical configuration, the logical configuration is no longer carried out by means of the engineering system 100. Rather, it is provided instead to design or create a configuration program, preferably by means of the engineering system 100, which comprises program code with which a device 200 can be programmed to configure network participants such as devices A to E with regard to both logical and physical aspects of the data exchange via the network and, for this purpose, to generate a set of required configuration data in response to at least one piece of configuration-relevant information specified by an operator and to transmit at least a subset of the generated configuration data via the network to a participant to be configured.In this case, the device 200 can generate both a device list 20 and, with regard to the configuration, corresponding configuration data with regard to logical aspects, which in particular define the IO assignments and IO configuration.

[0123] As from the Fig. 3a, the device 200 is also a controller in this example, so that here the device 200 is simultaneously also the controller S. For this reason, the control program 10 created by means of the engineering system 100 comprises, in addition to a set of program code for the device control with corresponding process variables and / or addresses 11, an additional program section 13 which contains program code, preferably with the integration of at least one function block for the physical configuration of devices or network participants, as well as a further additional program section 12 which contains program code, preferably with the integration of at least one function block for the logical configuration of devices or network participants. Such function blocks or similar orHowever, other mechanisms can also be integrated into an independent configuration program, especially if the device 200 is designed separately from the controller S, which can also be provided according to the invention in an application-specific manner.

[0124] According to the invention, in this embodiment variant, the transfer of the control program 10 together with the program sections 12 and 13 to the device 200, which in this case is also the controller S at the same time, can therefore already take place (referred to as download in the figure), wherein the engineering system 100 is at least temporarily connected to the device 200.

[0125] As from the Fig. As can be seen in Figure 3a, a device catalog 50 (repository) with entries for device types is present on the device 200. These entries are preferably structured according to device types such as switch, IO, or drive. A large amount of additional descriptive data, such as the manufacturer's name, is already present for each device type. Such a device catalog 50 can preferably also be created using an engineering system 100 and then transferred to the device 200.

[0126] A function block for adding a data record for a specific device to the device list, using the description data stored for the device type of this device in the device catalog, could, for example, look like this:

[0127] A function block for creating an IO assignment between a variable 11 of the control program 10 and a process data address of a device contained in the device list 20 could, for example, look like this:

[0128] When the control program is executed, program section 12 and thus the program code for the logical configuration of the network participants is preferably executed first.

[0129] Using a control unit (not shown in the figure), an operator can now easily enter configuration-relevant information and, with regard to the desired network topology, in particular, which devices are included in it, so that a device list 20 with corresponding device data records can be generated. The operator can access the information from the entries in the device catalog 50 and thus preferably only needs to select the corresponding device types and specify unique device names.

[0130] In response to this information, the device 200 or the controller S generates the corresponding device list 20. For this purpose, the information contained in the device catalog 50 regarding the device types and other data of the individual devices A to E and the controller S and, above all, their network interfaces are expediently used.

[0131] A program section for generating the device list 20 using the device catalog 50 would, for example, be displayed as follows at runtime to add a data record for device "A" of device type "Switch", device type "Type 1" and manufacturer "H1" as well as a data record for device "B" of device type "IO", device type "Type 11" and manufacturer "H2", whereby the above-mentioned function blocks are used accordingly frequently:

[0132] The program code for the other devices C to E of the actual topology 300 would look similar.

[0133] The operator still has the option of entering configuration-relevant information regarding the IO assignment via the control unit not shown in the figure.

[0134] A program section for generating corresponding links between a variable 11 of the control program 10 and a process data address of a device that is now contained in the device list 20 could, for example, be represented as follows at runtime, with the above-mentioned function blocks being used accordingly often:

[0135] The program code for the other devices C to E of the actual topology 300 would look similar.

[0136] A program section for generating further configuration data, in particular with regard to the IO configuration, in response to corresponding information from the operator, for example with regard to parameters such as update times or timeouts for individual devices, can also be provided.

[0137] It is also possible, if there is no suitable entry for a device in the device catalog 50, for all required data or parameters to be specified by the operator using the control unit, whereby these can also be stored in the device catalog 50 for later use, or alternatively, for an extended device catalog 50 to be loaded onto the device 200.

[0138] It is also conceivable that information about a device, if it cannot be taken from the device catalog 50, is read out from the respective device by the device 200 if the device is already connected to the device 200.

[0139] Preferably, the configuration of the physical aspects can be carried out following the configuration of the logical elements or aspects, whereby the program section 13 and thus the program code for the physical configuration of the network participants is executed for this purpose.

[0140] When generating the physical configuration data, which is essentially carried out as described above for the first embodiment, the now available device list 20 can be used.

[0141] As from the Fig. 3a, the device 200 is expediently also programmed with further program code 14 for checking the plausibility of the generated target topology 40, with program code 15 for checking the target topology 40 with respect to the existing actual topology 300, and with program code 17 for calculating RTE communication parameters, wherein reference is also made in this regard to the above explanations for the first embodiment.

[0142] Finally, according to the design variant as in Fig. 3a, the planned and generated or calculated configuration data are transmitted from the device 200 or the controller S to the other participants of the network according to the actual topology 300, i.e. to the devices A to E (referred to as download in the figure), whereby each participant receives the subset of configuration data relevant to it.

[0143] Preferably, the device 200 is programmed with further additional program code, which is not shown in the figure, in such a way that it offers the functionality to assign device names and / or other device identifications, as provided according to the target topology 40 and the device list 20, to devices A to E of the actual topology 300 (so-called device naming), so that a unique identification of the devices is ensured during subsequent operation of the system and the network. The device 200 or the controller S initially determines the devices of the actual topology to be naming based on the neighboring devices connected to them and, if applicable, based on the respective device type and / or device type. In the event of an error, for example, if a device cannot be determined in the actual topology, corresponding diagnostic information is available, to which the system then reacts accordingly.

[0144] The Fig. 3b and Fig. 3c show an example of the configuration of the devices of a system using the embodiment of the invention according to Fig. 3a, after a device of a first type ( Fig. 3b) by a device of a second type ( Fig. 3c) was replaced.

[0145] A machine or system can comprise a multitude of interconnected devices. The example assumes the operation of a wind turbine, in which, in addition to a controller 200 (PLC) and devices A and B, a type 1 frequency converter is used, which is Fig. 3b is depicted as device X1, with devices A, B, X1, and controller 200 connected to each other and thus participating in a common communications network. The small numbers next to the participants represent the unique designation of their respective network interfaces.

[0146] If a component fails, it cannot always be replaced with an identical component. Since machines and systems are often in use for many decades, it is impossible to know at the time of system construction which replacement components will be used. Thus, if a Type 1 frequency converter fails, it should be replaced by a Type 2 frequency converter, as used in Fig. 3c, which essentially fulfills the same function, but has a different identification, in particular a different device name, device type, and device manufacturer, as well as a different process data sequence. However, the configuration and integration of this replacement component of a different type is possible in a simple and secure manner according to the invention.

[0147] The control (PLC) 200 according to Fig. 3b and Fig. 3c is in accordance with the procedure described above and in Fig. 3a, the system is programmed to be able to control the devices of all possible variants of the system, but also to generate the configuration data required to configure the respective devices with regard to both logical and physical aspects of the data exchange between the devices and the controller.

[0148] As a result, the controller 200 already contains, without this being in the Fig. 3b and Fig. 3c is explicitly shown, in addition to the corresponding program code, there is also a device catalog, as already mentioned above in connection with Fig. 3a.

[0149] To Fig. In order to configure the devices of the system shown in Figure 3c, and in particular device X2, with regard to logical aspects of data exchange, the controller 200 requires the input of configuration-relevant information by the operator. The operator can use the visualization terminal 400 connected to the controller 200 as an operating unit to indicate that device X2 is now located in the system. The operator can access the descriptive data contained in the device catalog for the device type of device X2 and thus preferably only needs to specify the unique device name so that a device data record for device X2, generated by the controller 200 in response to this information, can first be inserted into the device list.

[0150] The corresponding program section for generating and adding a device data record for the device "X2", the device type "Frequency converter", the device type "Type 2" and the manufacturer "HS 23" with an update time of "1 ms" could, for example, look like this at runtime:

[0151] The operator can also use the visualization terminal 400 connected to the controller 200 to provide information regarding the IO assignment, since the device X2 has a different wiring of the process or IO data.

[0152] A program section for generating corresponding links between a variable "SetSpeed" of the control program 10 and a process data address of the device X2, which is now included in the device list, could, for example, be displayed as follows at runtime:

[0153] To Fig. In order to be able to configure the devices of the system shown in Figure 3c also with regard to physical aspects of data exchange, the controller 200 must also be informed that, instead of device X1, device X2 is now connected with its port 2 to port 1 of device B. For this purpose, the visualization terminal 400 and the information from the data records of the device list can be used, so that the operator preferably only needs to select the corresponding devices and network interfaces.

[0154] The corresponding program section for subsequent processing of the configuration-relevant information specified by the operator and generation of a corresponding target topology could, for example, look like this at runtime:

[0155] Furthermore, a plausibility check of the generated target topology is performed on the controller 200. Furthermore, the target topology is checked against the existing actual topology. In the event of an error, appropriate diagnostic information would be available, which could be output, for example, via the visualization terminal 400 connected to the controller 200.

[0156] Furthermore, the necessary RTE communication parameters, for example transmission and reception times of data telegrams, are calculated by the controller 200.

[0157] Finally, the planned and generated or calculated configuration data are transmitted from the controller 200 to the other participants in the network, i.e. to the devices A, B and X2, whereby each participant receives the subset of configuration data relevant to it.

[0158] After that, the system can be operated with the devices according to Fig. 3c can be activated.

[0159] Fig. Figure 4 shows the topological structure of a network structure according to the invention. The network nodes A to J are arranged according to the target specification from the engineering system, for example, Fig. 4 the network nodes A to I in a ring topology structure. The lengths of the lines L1 to L11 are preferably predefined and are stored in the adjacent network nodes for time synchronization purposes. A network line can be located between two network nodes, as shown, for example, between network nodes B and C via L2, but multiple network connection lines can also be connected, as in Fig. 4 shown between the network participants C and D via the lines L3 and L4.

[0160] According to the invention, the network participants, for example A to J in the Fig. 4, provided with equipment that allows each device to compare the planned (target) neighboring devices specified by the engineering system, as well as the (target) network interfaces possibly also specified there, with the existing and used (actual) neighboring devices and the corresponding (actual) network interfaces. The equipment then compares the existing (target) neighboring devices with the (target) neighboring devices specified in the engineering system. The equipment according to the invention now enables the network to start up or operate even if the installed (actual) neighboring devices are not connected to the possibly specified (target) network interfaces of the network participants. However, operation of the network is prevented if the (target) neighboring devices are not identical to the installed (actual) neighboring devices.

[0161] For the use and / or installation of the equipment according to the invention in a conventional network, for example, one constructed according to the PROFInet IRT standard, neither the PROFInet standard nor engineering systems need to be modified. The equipment according to the invention thus simplifies handling during installation, maintenance, and device replacement.

[0162] When planning a target topology for newly constructed networks, an exact target arrangement of the network interfaces can be omitted in the engineering system. Only the devices that will be connected to the corresponding neighboring devices are recorded. For example, in the exemplary arrangement shown in Fig.4 the devices E and H are predefined as neighboring devices to device G. Preferably, the line lengths of the connecting lines L8 and L9 are also specified, only the connection via the network interfaces 1 or 2 of the network participant G is not specified. The network participant E will therefore not disrupt the operation of the network if it is connected to interface 1, even though it could be intended for interface 2. As in the case of network participants C and D, a number of line connections between the network participants can also be specified, but it does not matter whether the line L4, for example, on the network participant C is connected to the device D via one of the interfaces 1 to 4. It is also conceivable that the line L3 is connected from interface 2 or 3 of the network participant D to one of the network interfaces 1 to 4 of the network participant C.The freedom of interface selection according to the invention significantly simplifies handling during installation or during maintenance and device replacement compared to a conventional connection according to the PROFInet IRT standard.

[0163] It will be apparent to those skilled in the art that the embodiments described above are to be understood as examples, and the invention is not limited to them, but can be varied in many ways without departing from the scope of the invention. Furthermore, it is clear that the features, regardless of whether they are disclosed in the description, the claims, the figures, or otherwise, also individually define essential components of the invention, even if they are described together with other features.

Claims

[1] Port-independent topologically planned real-time network with a target configuration (40) of the network topology for use in industrial networks for the transmission of time-critical data in (process) automation systems with at least two network participants (A, B, C, D, E, F, G, H, I, J, X) each with at least one network interface (1, 2, 3, 4) for connection to the port-independent topologically planned real-time network, wherein a first of these network participants is a device (200) having means for data processing and for executing program code as well as means for data exchange with the at least one further network participant, wherein the at least one further network subscriber is connected to the device via the network, characterized by , that the device comprises means for configuring the at least one further network subscriber with regard to the data exchange via the network according to a desired state; the device is programmed such that, in response to at least one piece of configuration-relevant information specified by an operator, it generates a set of configuration data required for configuring at least the at least one further network subscriber; the device transmits at least a subset of this generated set of configuration data to the at least one further network participant via the network; the physical connection of the network participants by means of the network interfaces to the topologically planned real-time network is independent of the use of a respective topologically planned network interface of at least one network interface of the respective network participant; and By specifying only one proximity of at least two network participants, communication planning is ensured. [2] Port-independent topologically planned real-time network according to claim 1, characterized by that a check of the actual physical configuration of the network interface (1, 2, 3, 4) used on the basis of the target configuration of the network topology, if the proximity matches, determines the application of communication parameters to the at least one network interface of the at least one further network subscriber (A, B, C, D, E, F, G, H, I, J, X), so that the network interface and / or the connection is activated. [3] Port-independent topologically planned real-time network according to one of the preceding claims, wherein the at least one configuration-relevant information can be specified by the operator by means of a human-machine interface (400) assigned to the device (200), in particular by means of an operating unit connected to the device with input and output means. [4] Port-independent topologically planned real-time network according to one of the preceding claims, wherein the device (200) is programmed to configure at least the at least one further network participant (A, B, C, D, E, F, G, H, I, J, X) with regard to logical and / or physical aspects of the data exchange via the network. [5] Port-independent topologically planned real-time network according to one of the preceding claims, wherein the set of configuration data generated and required for configuring at least the at least one further network subscriber (A, B, C, D, E, F, G, H, I, J, X) with regard to physical aspects comprises the target configuration of the network topology for the network. [6] Port-independent topologically planned real-time network according to one of the preceding claims, wherein the means for data exchange are designed for a cyclic data exchange via the network. [7] Port-independent topologically planned real-time network according to one of the preceding claims, wherein the means for data exchange are designed for real-time data exchange via the network. [8] Port-independent topologically planned real-time network according to one of the preceding claims, wherein the device (200) is programmed to configure at least the at least one further network participant with regard to a real-time data exchange via the network. [9] Port-independent topologically planned real-time network according to one of the preceding claims, wherein the means for data exchange are designed for clock-synchronous data exchange via the network. [10] Port-independent topologically planned real-time network according to the preceding claim, wherein the device (200) is programmed to configure at least the at least one further network participant with regard to a clock-synchronous data exchange via the network. [11] Port-independent topologically planned real-time network according to one of the preceding claims, wherein the means for data exchange are designed for data exchange via the network according to the Profinet IRT specification. [12] Port-independent topologically planned real-time network according to the preceding claim, wherein the set of configuration data generated and required for configuring at least the at least one further network participant (A, B, C, D, E, F, G, H, I, J, X) comprises a set of parameters calculated by the device and specific to RealTime Ethernet networks. [13] Port-independent topologically planned real-time network according to the preceding claim, wherein the device (200) reads out a set of configuration-relevant information from the network and / or the at least one further network participant (A, B, C, D, E, F, G, H, I, J, X), generates the set of configuration data required for configuring at least the at least one further network participant based thereon, and transmits at least a subset of this generated set of configuration data to the at least one further network participant via the network in response to at least one piece of configuration-relevant information specified by the operator, in particular a release of the generated set of configuration data. [14] Port-independent topologically planned real-time network according to one of claims 12 or 13, wherein the device (200) first checks the set of configuration data generated and required for configuring at least the at least one further network participant (A, B, C, D, E, F, G, H, I, J, X) for plausibility before transmitting at least a subset of this generated set of configuration data to the at least one further network participant via the network. [15] Port-independent topologically planned real-time network according to one of claims 12 to 14, wherein the device (200) first checks the set of configuration data generated and required for configuring at least the at least one further network subscriber (A, B, C, D, E, F, G, H, I, J, X) for plausibility with regard to the actual state of the network and at least the at least one further network subscriber before transmitting at least a subset of this generated set of configuration data to the at least one further network subscriber via the network. [16] A port-independent topologically planned real-time network according to any one of claims 12 to 15, wherein the device (200) is programmed to configure itself with respect to data exchange over the network using at least a subset of the generated set of configuration data. [17] Port-independent topologically planned real-time network according to one of claims 12 to 16, wherein the device (200) is programmed to control the at least one further network participant (A, B, C, D, E, F, G, H, I, J, X) after the configuration, and / or wherein the device (200) is a programmable logic controller. [18] Data carrier with a program code stored thereon, wherein the program code is designed such that a device (200) is designed according to one of the preceding claims when it is programmed with the program code.

Images