• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    In order to be able to maintain direct cross traffic between slaves in a ring topology of an Ethernet-based data network even in the event of a ring topology error that results in the ring topology being interrupted, it is provided that in case of an error (F) occurring in the ring Data network (1) of the ring master (RM) is configured for forwarding data packets or for blocking at least Mulitcast data packets and the master (M) the at least two communicating via cross-traffic slaves (S1, S2), to the respective other slaves ( S1, ..., Sn) of the ring-shaped data network to send configuration data packets (DPMC1, DPMC2) as multicast data packets in order to adapt address tables (AT1, AT2) in the at least two slaves (S1, S2) communicating with each other via cross traffic.
    公开号:AT517779A1
    申请号:T50831/2015
    申请日:2015-10-01
    公开日:2017-04-15
    发明作者:Dietmar Bruckner Dr；Prenninger Franz
    申请人:Bernecker + Rainer Industrie-Elektronik Ges M B H；
    IPC主号:
    专利说明:

    Method for cross traffic between two slaves of an annular data network
    The subject invention relates to a method of data communication in the form of cross traffic between at least two slaves of an annular data network, wherein a master is connected to a first branch of the ring data network with a number of slaves and to a second branch of the ring data network with a number of slaves and the ends of the branches are connected to a slave provided as a ring master.
    In a data network, a network protocol is implemented, with which data in data packets on the data network are transmitted between the network nodes connected to the data network. The most well-known and widely used network protocol today is the Ethernet protocol. For this purpose, Ethernet defines data packets (also called data frame or Ethernet frame) in which data of a higher-level communication protocol can be transmitted encapsulated in an Ethernet data packet. In this case, data of the communication protocol with a data length between 46 and 1500 bytes can be transmitted in an Ethernet data packet. The addressing in the Ethernet protocol takes place via the MAC (Media Access Control) addresses of the network nodes, which are assigned uniquely for each network device. From the point of view of the known OSI layer model, Ethernet is implemented exclusively on layers 1 and 2. Different communication protocols can be implemented in the higher layers. Here, a variety of communication protocols have been established, such as IP on layer 3 or TCP and UDP on layer 4, to name a few widely used communication protocols.
    In terms of hardware, today's Ethernet systems are so-called switched data networks, in which individual network nodes do not have to be directly connected to one another and can not communicate directly with one another, but can be connected via coupling elements, for example network switches or network hubs. A coupling element for this purpose has a number of network ports, to which a network participant (either a network node or another coupling element) can be connected. Such a coupling element forwards an Ethernet data packet either to all ports (hub) or to a specific port (s) (switch). So-called point-to-point connections are made in a switched data network in which Ethernet data packets are forwarded from one network node via a number of coupling elements to another network node.
    In the case of a network switch, a so-called source address table (SAT) is implemented in the switch. If the network switch receives a data packet, it stores the address of the sender (MAC address for Ethernet) and the port on which the data packet was received. This allows the network switch to automatically establish an association between addresses of network nodes and ports. This makes it possible for the network switch to send a data packet specifically via the port via which a network node (or its address) can be reached in the network according to the source table. This does not have to be configured, but the source address table is automatically set up and managed by the network switch. Also, entries from this table automatically age again after a certain period of time, when no further frames are observed by a known network node. Network switches with automatic source address tables are also called unmanaged network switches (unmanaged switches).
    Network nodes used in industrial automation often have a 3-port switch installed internally, whereby two ports are accessible from the outside and the third port is for internal wiring. This makes it possible to implement line topologies in which a network node is connected to the next network node in the form of a line, which helps reduce cabling costs in an industrial environment. Of course, external network switches or external network hubs can also be used to set up the network topology. In principle, any network topology is possible, that is to say in particular a star topology, a line topology, a tree topology, a ring topology, etc., and also any combination thereof. In a ring topology, special precautions are usually taken to prevent the uncontrolled circulating of multicast packets. For example, it is common for a network node to be designated as the ring master, which will not forward multicast traffic. In the IT environment, protocols of the so-called spanning tree family have prevailed, where the switches automatically detect multiple paths to MAC addresses and in this case do not use all paths except one. However, the possible switching times in the event of a ring break in these protocols are not sufficiently small for industrial applications, in particular for real-time applications.
    In order to be able to use Ethernet for industrial automation, real-time-capable Ethernet protocols have already been developed since the standard Ethernet network protocol is not known to have real-time capability. Examples of well-known real-time Ethernet protocols are Modbus / TCP, EtherNet / IP, ProfiNET IRT, EtherCAT or Ethernet POWERLINK, to name but a few. In this context, one often speaks of Industrial Ethernet or Real-Time Ethernet. These real-time-capable Ethernet protocols are intended to ensure sufficiently fast and deterministic data communication for the respective application. It is thus intended in particular to ensure that a real-time-relevant data packet is transmitted by the sender over the network to the receiver within a predetermined period of time. In an industrial automation environment, real-time capability means, for example, that a fixed period of time must be maintained between the acquisition of a measured value, forwarding to a control unit, calculation of a control value in the control unit on the basis of the measured value and transfer of the control value to an actuator for performing an action. With reference to the real-time capable Ethernet data network for the transmission of this data, a predetermined period of time must also be ensured.
    In an industrial automation environment, there is usually at least one master network node (in short, also a master), which communicates with at least one associated, generally several assigned, slave network node (in short, also slaves). To realize a real-time capable Ethernet data network, the known real-time Ethernet network protocols have defined a predefinable cycle time within which the master can normally communicate with each slave. This includes cyclically the possibility of a data packet from the master to each slave and vice versa, a data packet from each slave to the associated master. The achievable and in advance ascertainable minimum cycle time results from the sum of the transit times of the data packets. The runtimes are, in addition to the influence of the implemented communication protocol, hardware-dependent and result from the bit transmission times (length, payload) of the data packets, from the network infrastructure (delay times through coupling elements) and the network topology. The above-mentioned limits in the size of the Ethernet data packets are also to be considered. This cyclic data traffic, which forms the basis of the real-time capability in the real-time capable Ethernet network protocol, is usually extended by asynchronous (non-cyclic) data packets in each transmission cycle. Such asynchronous data packets are used by the data communication not subject to the real-time requirements, for example for the configuration of the slaves or for status queries. For such asynchronous data packets, bandwidth is reserved, i.e., a certain defined time is available for asynchronous data traffic in each transmission cycle. However, the network nodes have to split this asynchronous section of a transmission cycle. In the concrete implementation of the cyclic and asynchronous data traffic, the known real-time capable Ethernet protocols differ.
    In the industrial environment, for example in automation technology, a redundancy is often required, which ensures that the underlying data network in the case of an error, such. a cable break or a defective network node, does not fail. Therefore, in the industrial environment, ring topologies are due to the possibility of network redundancy, since each network node basically has two different ones
    Paths is achievable, especially interesting. If the network is physically interrupted in one place, e.g. due to a cable break, loosening of a plug connection, etc., this does not necessarily lead to the failure of the entire data network or even of the sub-network "behind" the break point. In order to be able to maintain the traffic in the network with ring topology even in the event of an error, methods have already been disclosed for dealing with such errors.
    There are well-known methods to deal with network topology errors, e.g. the known Spanning Tree method or the Media Redundancy Protocol method.
    However, these methods, which were not designed for industrial use, and certainly not for real-time networks, are usually far too slow to be used in such applications. For industrial applications, therefore, methods have been developed that allow a quick reconfiguration of the data network.
    The best-known international standards describing implementation instructions for Ethernet-based ring topologies are described in IEC 62439, such as PRP (Parallel Redundancy Protocol) or HSR (High-availability Seamless Redundancy). In both cases, there are two redundant paths between sender and receiver of a data packet, whereby the sender must be able to send two specially labeled data packets. The receiver must be able to receive these specially tagged data packets and select one of them for further processing. Another similar approach was recently standardized by the IEEE working group TSN, IEEE 802.1 CB. The main difference is that the two end nodes (transmitter and receiver) do not have to have special capabilities, but the redundant route in between is configured in the (corresponding) switches. A switch generates the two correspondingly marked data packets and forwards them on two different ports, while another switch receives both data packets and forwards an unmarked data packet (corresponds to the original data packet). As a result, any redundant paths per data packet or per device can be defined. All these methods have in common the sending of at least two independent data packets without reconfiguration of the network, which consume bandwidth in highly optimized networks. These methods are therefore only limited replaceable, especially in real-time data networks.
    The following known methods transmit the data packets only once, making more efficient use of the available bandwidth. They differ essentially in the detection of a ring break and the subsequent reconfiguration of the paths.
    For example, EP 1 476 988 B1 describes a ring topology with a network node configured as a redundancy manager connecting the beginning and the end of the ring. The redundancy manager prevents the forwarding of data packets and thus acts as an open switch. The redundancy manager periodically sends test messages in both directions to the ring. If the two test messages within a certain period of time again received by the redundancy manager, it is assumed that the physical network is free of errors. If not, it can be assumed that the ring topology is broken and the redundancy manager forwards data packets (switch closed) from this point onwards, which converts the broken ring topology into a working line topology. The functionality of the redundancy manager requires a specially implemented device, whereby standard network devices are not suitable as redundancy managers. Apart from that, the redundancy manager must be located at a certain point of the ring. Furthermore, the network is also burdened by the test messages here, which reduces the bandwidth available for the actual data communication.
    EP 1 062 787 B1 discloses a method in which the redundancy manager, after the occurrence of a fault in the ring topology physical network, sends a data packet to all network nodes with which the error is displayed. Then all network nodes delete their source address tables, which reconfigures the network. Through such a reconfiguration, the network nodes learn again on which port the master can be reached, whereby the data communication between master and slaves can be quickly restored. The reconfiguration makes all network nodes in the ring topology accessible again. In this method, all network nodes must have access to their source address table, which in turn requires specially designed devices, which means that no standard network devices can be used in the ring.
    In particular, in highly optimized industrial Ethernet-based data networks but often so-called cross-traffic is realized. Two slaves communicate directly with each other, ie without the involvement of the master, whereby the speed of the data communication can be increased considerably. In the case of a fault in the network topology (cable break, disconnection of a plug, defective network node, etc.), the cross traffic is interrupted via the fault location. On direct cross-traffic between two slaves and on the rapid reconfiguration of the cross-traffic of the said prior art is not at all.
    It is therefore an object of the subject invention to provide a method by which direct cross traffic between slaves in a ring topology of the data network can be maintained even in the event of an error in the ring topology leading to the disruption of the ring topology.
    This object is achieved according to the invention by configuring the ring master for forwarding or blocking data packets or at least multicast data packets in the event of the occurrence of an error, or in the event of an error being cleared, in the ring-shaped data network, and the master at least two calls via cross-communication with each other communicating slaves to send to each other slaves of the ring-shaped data network configuration data packets as multi-cast data packets to adapt address tables in the at least two communicating with each other via cross-traffic slaves.
    The inventive method makes no demands on the hardware used, but builds solely on the standard functionality of a network switch. This standard network components, especially standard unmanaged network switches can be used. The rewriting of the address tables thus takes place automatically. The ring master is just a function that must be activated in the control software. For implementation, the communication protocol must be defined accordingly so that the required messages can be sent and recognized. With the method according to the invention, extremely short switching times in the range of a few 100 ps to a few milliseconds can be realized in the event of a ring break, with which the method can also be used in particular in real-time networks.
    If the master sends multicast data packets to all the slaves present in the ring in both branches of the ring-shaped data network, reconfiguration of all slaves in the data network can easily be achieved. This means that after the beginning, or the end, of the forwarding of the data packets by the ring master (RM), the address tables of the slaves are automatically adjusted and thus the traffic between the slaves and the master can be maintained without further loss or necessary configuration ,
    An error can be easily detected when the master transmits ring status data packets as multi-cast data packets to both branches of the ring-shaped data network at timed intervals, which are received by the ring master and the ring master detects an error in the ring-shaped data network, if the Ring status data packets are received one or more times in succession from only one branch or the ring master detects the elimination of a fault in the ring-shaped data network when the ring status data packets are received one or more times in succession from both branches. Such a ring status data packet can easily be
    Be implemented protocol. These ring status data packets can also be used simultaneously as multicast data packets to reconfigure the data communication between master and slaves.
    In this case, it is particularly advantageous if multicast data packets already provided as ring status data packets in the communication protocol of the data communication are used anyway. If data packets which are already present and sent are established, no additional data packets are necessary which reduce the bandwidth for normal data communication.
    The ring master can easily notify the master of an error when the ringmaster sends an error data packet to the master.
    The subject invention will be explained in more detail below with reference to Figures 1 to 6, which show by way of example, schematically and not by way of limitation advantageous embodiments of the invention. It shows
    1 a ring-shaped data network with master and ring master,
    2 possible embodiments of a network node with network switch,
    3 shows the annular data network with errors,
    4 shows the notification of the master in the case of the error in the annular data network,
    5 shows the reconfiguration of the cross traffic by sending cross traffic data packets and
    6 shows a network topology with a network switch to which a master and a number of ring-shaped data networks have been shot.
    In a real-time capable Ethernet network protocol, transmission cycles are defined with a given cycle time in which the master can normally communicate with each slave S1, ..., Sn. A transmission cycle is precisely time divided by the times are fixed at which the master M or the slaves S1, ..., Sn may send data packets DP. In this way, data collisions (or delays due to growing switch queues) on the data network 1 can be avoided. Thus, each of the participating network nodes (master M, slaves S1, ..., Sn) knows at which time within a transmission cycle Z it is allowed to send data packets DP. After Ethernet allows full-duplex data communication, however, data packets DP can travel in both directions simultaneously on one network segment. The real-time-based data communication takes place cyclically and there is a time range for this cyclic (isochronous) data traffic in each transmission cycle. The number of network nodes, master M and slaves S1,..., Sn, and the size of the data sent is thus also decisive for the achievable cycle time. In each transmission cycle, however, an area for asynchronous data traffic is reserved. The asynchronous traffic serves primarily the traffic which is not subject to a real-time request and the network nodes existing in the data network 1 have to divide the asynchronous bandwidth according to an implemented scheme.
    1 shows a simplified ring-shaped data network 1 is shown. The master M is connected via the slaves S1 ..... Sn annular with these. For this purpose, the master M is connected to the branches Z1, Z2 of the annular data network 1 and the ends of the two branches Z1, Z2 are connected to each other via a slave S3, which is provided as a ring master RM. The connection is indicated in FIG. 1 by a connection between the ports P11, P12 or P21, P22, etc. of the slaves S1... Sn. The slave S3 serves as a ring master RM which is configured in a fault-free annular data network 1 in such a way that no data packets are transmitted from one branch Z1, Z2 to the respective other branch Z2, Z1. This is indicated in Fig. 1 by the unconnected ports P31, P32.
    A network node K (master M or slave S) is a network device 3 with network switch SW, which can be installed internally in the network device 3, for example as a 3-port network switch as in FIG. 2a. It is also conceivable that a network device 3 is connected to an external network switch SW to form the network node K, as shown in Fig.2b. For the subject invention, both implementations of a network node K are conceivable, which is why no further discussion of this hardware difference, but it is assumed that the master M and the slaves S1, ..., Sn are each equipped with a network switch SW , For an annular data network 1, the network switch SW must have at least two externally accessible ports P1, P2. A third port P3 of the network switch SW is often internally connected to a control unit 2 of the network node K. In the network switches SW, or generally in the network node K, an address table AT is implemented in a known manner, from which the network switch SW takes the information about which of the external ports P1, P2 another network node of the connected data network is reachable.
    A network node K can also have additional external ports P33, as indicated in FIG. 1 at the slave S3, to which further network nodes Kn can be connected. However, these further network nodes Kn are not regarded as part of the annular data network 1. However, such a further external port P33 can be reachable from both branches Z1, Z2, which is indicated by the dashed connection in FIG. 1, which does not close the ring.
    In the course of data communication on the annular data network 1 often so-called multicast data packets are sent, in which a network node (master M, slaves S1, Sn) sends a data packet to several other network nodes in the ring-shaped data network 1. Such a multicast data packet is received at one port of the network node and sent to the other port, or at the other ports, again. In order to prevent the uncontrolled circulation of such multicast data packets in the annular data network 1, the ring master RM is configured with intact annular data network 1 so that it does not forward at least no multicast data packets. Preferably, when the ring-shaped data network 1 is intact, the ring master RM is configured such that it does not forward any data packets at all, including unicast data packets.
    As part of the data communication with intact annular data network 1, the master M sends, for example, data packets DP1, DP2 in both branches Z1, Z2 of the data network 1 in ring topology. The data packets DP1, DP2 are sent either to exactly one of the slaves S1,..., Sn (unicast traffic) or to several or even all slaves S1,..., Sn, or several or even all slaves S1 ... ..Sn of a branch Z1, Z2 (multicast traffic). In multicast traffic, the data packets DP1 and DP2 can also be the same. The slaves S1,... Sn send respective data packets according to the implemented communication protocol back to the master M according to the communication protocol.
    As a ring master RM, ideally a slave is selected in the middle of the ring, ie a slave which is approximately equidistant from the master M in both branches Z1, Z2 in order to achieve approximately the same transmission times in both branches Z1, Z2.
    In the case of an error F, as shown in Figure 3, the annular data network 1 is interrupted at the fault location. An error F can be detected by the ring master RM in that the master M transmits a specific ring status data packet DPR as a multicast data packet to all slaves S1, .... Sn at regular intervals. The ring master RM can therefore detect whether the arrival of this ring status data packet DPR fails at one of its ports P31, P32 and can in this case infer an error F in the respective branch Z1, Z2. Of course, it can be configured in the ring master RM how often the sequentially following absence of the ring status data packet DPR has to be detected until an error in the ring-shaped data network 1 is assumed. In error-prone data networks 1, for example with error-prone transmission links such as slip rings, WLAN links, etc., a higher value is preferably used.
    In order not to additionally burden the data communication by sending the ring status data packets DPR, provision can also be made for data packets already provided in the communication protocol to be used for this purpose. The communication protocol can include, for example, multicast data packets from the master M to the slaves S1, Sn, which are sent in specific or in all transmission cycles, preferably in the cyclic part of the transmission cycle. The ring master RM can therefore expect these multicast data packets to arrive and, in the event of a one or more failures, emanate from an error F in the branch Z1, Z2 from which no data packet is received. The additional advantage of using such multicast data packets from the master M as ring status data packets DPR is that in error detection the previously open connection in the Ringmaster RM can be closed immediately, whereby the multicast data packets of the master can be forwarded via the Ringmaster RM. This means that the address tables of the slaves connected to the Ringmaster RM (to the master) are automatically reconfigured without having to take any further action.
    Such multicast data packets from the master M to the slaves S1, ..., Sn usually also contain data from the master M to the slaves S1 ..... Sn. This ensures at the same time sicherge that the data even in the case of a ring break all slaves S1, ..., Sn reach and all slaves S1, ..., Sn get their data in the same transmission cycle in which is switched. Data loss or delay by resending the data can thus be avoided.
    Of course, the method for detecting an error F can also be reversed. In this case, the ring master RM may be configured to periodically send a ring status data packet DPR to the master M via both branches Z1, Z2. This can again close an error F in the respective branch Z1, Z2 when x times the ring status data packet DPR.
    The master M can also detect an error without its own ring status data packet DPR. For this purpose, the master M can in turn already use data packets provided in the communication protocol. If, for example, one or each slave S1,..., Sn sends a data packet to the master M in each transmission cycle, the master M can conclude that an error F occurs in the absence of these data packets. If the master M normally receives data packets from each slave S1, ... Sn, the master can even close an exact error location due to the missing data packets, if the master M knows the topology of the data network 1 (which is normally the case).
    It should be noted that link detection is often also implemented on the physical layer of a network device, as is the case, for example, with Ethernet. However, this link detection is not reliable enough, as it may occur that a lost link (e.g., due to a wire break in the network cable) is not detected. Apart from that, this link detection would not be fast enough, as for example in
    Ethernet every 16ms a pulse is sent and the pulse on the receiver side would have to fail several times in succession, so that the link detection responds.
    After the ring master RM or the master M has detected an error F in the data network 1 in this, or another suitable manner, the connection between the ports P31, 32 of the ring master RM is closed (FIG. 3), with which data now comes unicati -on (as unicast, as well as multicast) is enabled via the Ringmaster RM. At the same time, a method for reconfiguring the data network 1 is initiated, e.g. similar to the prior art described above.
    When the master M sends multicast data packets to the slaves S1, ..., Sn for reconfiguration, the reconfiguration is done automatically by the standard Ethernet functionality, without the need for a special reconfiguration process or special ones
    Hardware requirements to the slaves S1 ..... Sn would be made. Such multicast
    Data packets can be sent at intervals or even once. For example, the ring status data packet DPR could also be used for this.
    Due to the new configuration (regardless of which method) is again every slave S1, ..., Sn reachable by the master M or each slave S1 ..... Sn can reach the master M. In the course of this reconfiguration, the address tables AT1,..., ATn of the slaves S1... Sn and the address table ATM masters M are rewritten accordingly, which is explained using the example of the address table ATM of the master M.
    In Fig. 1, the address table ATM of the master M is shown, in which is contained, via which port PM1, PM2 of the master M each slave S1, ..., Sn of the annular data network 1 is reached. In the course of the reconfiguration in the case of an error F, the address table ATM of the master M is rewritten so that it is now included in the address table ATM that the slave S2 is no longer reachable via the port PM1, but via the port PM2 (FIG. , In the same way the address tables AT1 ..... ATn of the slaves S1, ..., Sn are rewritten by the new configuration. For example, the slave S2 then sends data packets DP to the master M no longer via the port P21, but via the port P22. The normal data traffic between master M and slaves S1, ..., Sn can be quickly rearranged in this way. For this purpose, any method for the reconfiguration of the data communication between master M and the slaves S1, ..., Sn is per se applicable.
    It can be implemented in the annular data network 1 but also direct cross-traffic between slaves S1, ..., Sn. In this case, cross-traffic means that two slaves communicate directly with each other without involving the master M via the data network 1 by exchanging cross-traffic data packets DPQ with one another. For example, it may be provided that the slaves S1, S2 communicate directly with each other, without involving the master M cross-traffic data packets DPQ, as indicated in Figure 3. The slaves S1, ..., Sn, which communicate directly with each other via cross traffic, do not have to be directly adjacent, but the cross traffic could also be implemented across several slaves S1. The cross traffic is likewise configured by corresponding entries in the address tables AT of the slaves S1, S2 involved in the cross traffic, as indicated in the address tables AT2 of the slave S2.
    This cross traffic allows the participating slaves within a transmission cycle and independent of the remaining data communication (with the exception of the avoidance of collisions or any delays caused by switch queues on the data network) by means of exchanging data packets to communicate directly with each other. This allows very fast reactions of slaves S1, S2 involved in cross-traffic, which is very interesting, especially in highly dynamic, synchronized control of machines. For example, in a drive control direct cross traffic between a sensor (for example, a speed sensor) and a motor control of an electric motor can be provided, whereby the drive with a very short sampling time (corresponding to the time of a transmission cycle) could be operated. If communication via the master were necessary, then the possible sampling time would be longer due to the longer communication paths.
    Due to the above-described reconfiguration of the data network 1 in the course of an error F, however, this cross traffic would be interrupted via the fault location.
    If only the parts of the address tables AT1,..., ATn of the slaves S1,..., Sn are rewritten by the reconfiguration, which relate to the data traffic with the master M, entries in the address tables AT1 ..... ATn remain that would prevent cross traffic.
    Remains e.g. in the address table AT2 the entry about that the slave S1 from the slave S2 via the port P21 is reached (as in Figure 3), then the slave S2 would try unsuccessfully, cross traffic data packets DPQ via this port P21 to the slave S1 to send, since the error F is present between the slaves S1, S2. The same thing can happen if the entire address tables AT1, ..., ATn are deleted in the course of the reconfiguration, which also deletes the entries for the direct cross traffic. However, these entries required for the cross traffic are not rewritten by the state of the art reconfiguration, which would also prevent direct cross traffic via the fault location.
    In order to circumvent this problem, it is now provided according to the invention that the ringmaster RM sends an error data packet DPF to the master M in the event of the recognition of an error F in the ring-shaped data network 1 via the intact branch Z2 of the ring-shaped data network 1 (FIG. to notify the master M of the error F. If the error F is detected in the master M, the master M can transmit the error data packet DPF to the ring master RM, whereby it can close the data communication connection via its ports P31, P32, as described above. The bandwidth for the error data packet DPF can be permanently scheduled in the transmission cycle, preferably in the isochronous part of the transmission cycle, in order to be able to transmit the notification as soon as possible without waiting for a free slot.
    Basically, the inventive method for reconfiguring the direct cross-traffic between two slaves S1, ..., Sn but regardless of the way in which an error F in the annular data network 1 is detected.
    After an error F has been detected in the ring-shaped data network 1 and the master M has become aware of this, the master M sends to all slaves S1,..., Sn a start data packet DPN (FIG. 5), with which all slaves S1, ..., Sn of the ring-shaped data network 1 are requested to send a configuration data packet DPMC in the form of a multicast data packet to all other slaves S1,..., Sn (FIG. 5). This means that each slave S 1... Sn sends the configuration data packet DPMC over all ports P that are integrated in the ring-shaped data network 1. For example, the slave S2 transmits its configuration data packet DPMC2 via the ports P21, P22. At a slave S1, ..., Sn could also be provided additional, not integrated in the ring-shaped data network 1 ports P, are connected via the other network node Km. The slave Sn in Figure 5, for example, has an additional external port Pn3, over which another network node Km is shot. For the method according to the invention, it is not necessary that a configuration data packet DPMCn is also sent via such ports P which are not integrated into the ring-shaped data network 1.
    If the master M has knowledge of the configuration of the cross traffic, if the master M knows which of the slaves S1,..., Sn are configured for cross traffic with each other, then it is sufficient if the master only activates the start data packet DPN the slaves S1,..., Sn involved in cross traffic transmit. In this way, only the slaves S1,..., Sn participating in cross-traffic would also send a configuration data packet DPMC.
    In order to enable configuration data packets DPMC in the form of multicast data packets, the ring master RM must forward multicast data packets from slaves S1 ..... Sn in the event of an error. The Ringmaster RM must therefore cancel this restriction necessary for the intact ring in the event of a fault. However, the error F (ring break) ensures that these multicast data packets DPMC can not circulate uncontrollably. The slave S1 thus receives via the port P11 the configuration data packet DPMC2 of the slave S2 (Figure 5). Via the standard mechanisms of an unmanaged network switch, the address table AT1 in the slave S1 is automatically rewritten when the slave S1 receives a data packet of another slave S2 via a different port P11 than that which is noted in the address table AT1. By means of this automatic rewriting of the address table AT1, the slave S1 now knows that the slave S2 can not be reached via the port P12 as before, but via the port P11. In the same way, due to the configuration data packet DPMC1 of the slave S1, the address table of the slave S2 is rewritten so that the slave S2 also knows that the slave S1 can be reached via the port P22. Thus, the cross traffic can be bypassed via the fault F and the cross traffic between the slaves S1, S2 via the intact connections of the ring-shaped data network 1. This is usually no interference with the functionality of the network switches of the slaves S1, ..., Sn required because this rewriting of the address tables AT is a standard function of a network switch. The rewriting of the address tables AT and thus also the reconfiguration of the cross traffic thus takes place automatically.
    If the error F is corrected, the procedure is similar. The ring master RM or the master M recognizes, for example, that ring branches DP1 arrive again from both branches Z1, Z2, which is only possible if the fault location has been rectified. The ring master RM informs the master M (or vice versa) that the error F is canceled, for example by an error data packet DPF again. From the detection of the cancellation of the error F, the ring master RM at least again prevents the forwarding of the multicast data packet of the slaves S1,..., Sn in order to prevent an uncontrolled circulating of such data packets in the ring. The ring master RM preferably prevents the forwarding of all data packets. The master M requests via a start data packet DPN again all slaves S1, ..., Sn, or advantageously at least the slaves involved in the cross-traffic S1, S2, to any other slave S1 ..... Sn a configuration data packet To send DPMC. These configuration data packets DPMC as multicasts are not forwarded via the ring master RM. Thus, in the example according to FIG. 5, if the error F was corrected at the slave S1, the configuration data packet DPMC2 would arrive via the port P12, which would lead to the rewriting of the address table AT1. The same would happen with the address table AT2 of the slave S2, which would be rewritten on the basis of a configuration data packet DPMC1 of the slave S1. Thus, the cross-traffic between slave S1 and slave S2 would again take place via the short direct route via the ports P12 and P21.
    The start data packet DPN is preferably sent as a multicast data packet. That is, a slave S1 ..... Sn receives the start data packet DPN at one port and sends it over the other port (s). Alternatively, the Master M could also be individual start
    Send data packets DPN to slaves S1, Sn, but this would take more bandwidth of the data communication.
    It is also possible, with the ring R intact, ie without error F, to exclude cross traffic via the ring master RM. The reason is that such cross traffic, e.g. between the slaves S2 and S4, although could be configured, but can not be maintained. The configuration can be done by means of a configuration tool when setting up the data network 1. However, the ring master RM could also falsify cross traffic in the form of data packets in order to rewrite the address tables AT2, AT4 of the slaves S2, S4 accordingly. Only the configuration of cross traffic over the ringmaster RM can only be maintained until one of the participating slaves S2, S4 sends multicast data packets, which can often occur. After the ring master RM in the intact ring R blocks such multicast data packets, the multicast data packet would reach the other slave over the long distance, thus rewriting the address tables AT2, AT4. Therefore, it makes sense to completely exclude cross traffic via the Ringmaster RM.
    The reconfiguration of the normal data communication (ie not the direct cross traffic between S1 ..... Sn) after fixing the error could in turn with conventional
    Methods are performed. However, the master M could in turn send multicast data packets to the slaves S1, ..., Sn for reconfiguration, whereby the reconfiguration would be done automatically by the standard Ethernet functionality, without a special process for reconfiguration would be necessary or special hardware requirements for Slaves S1, ..., Sn would be placed. Such multicast configuration data packets can be sent at intervals or even once. For example, the ring status data packet DPR could also be used for this.
    Of course, the master M could also be integrated into the ring topology via an external network switch SW, as described with reference to FIG. Here, a network switch SW is provided, which is connected to the master M. At the network switch SW is a first ring R1 in the form of an annular data network 1 with a number of slaves S11, ..., S1n and a second ring R2 in the form of an annular data network 1 with a second number of slaves S21, ..., S2m connected. In addition, other network segments NS can also be connected to the network switch SW, as in FIG. 5 a line-shaped network segment with two slaves S3, S4. In this way, a plurality of annular data networks 1 can be operated with a master M. However, the basic procedure for dealing with an error F does not change anything and each of the rings R1, ... needs a slave with a ring master function.
    It is also conceivable that the function of the ring master RM is taken over by the master M. In this case, the error data packet DPF would not be sent via the ring-shaped data network 1, but signaled internally in the master M. This does not change anything in the basic process of reconfiguring cross traffic.
    It should also be emphasized once again that the method according to the invention for reconfiguring cross traffic is independent of the method for reconfiguring the data traffic between master M and slaves S1,..., Sn.
    The configuration data packets DPMC of the slaves S1 ..... Sn for reconfiguring the
    Cross-traffic is preferred, but not necessarily, realized as asynchronous traffic. This can be achieved that the reconfiguration is completed within a few transmission cycles, ideally within a transmission cycle, which allows a particularly fast switching of cross traffic. In this case, a slave S1 ..... Sn would receive the start data packet DPN in a transmission cycle and send the configuration data packets DPMC in the same transmission cycle in the asynchronous region. In particular, in this case, it is ensured that the cross traffic is changed before the next transmission cycle begins, whereby data loss can be prevented by data packets lost at the fault location F, which is particularly important in a real-time-capable data network.
    If the ring status data packet DPR is sent as a multicast data packet in the isochronous part of the transmission cycle (and thus precisely planned) and a threshold is set, how many data packets have to be lost before switching, then, in the context of the knowledge, how long it takes to send the error data packet DPF and the configuration data packets DPMC make an accurate estimate of how long it takes for the ring to be active again in the event of an error without data packet loss.
    However, the predetermined cycle time also influences the maximum size of the ring R. In the event of an error, the cross traffic over the fault location can not be maintained, but must be routed around it, which leads to longer transit times of the data packets of the cross traffic. Thus, the number of network nodes in the ring multiplied by the respective latency of the network nodes (the time it takes for a network node to send a data packet arriving at a first port on a second port) must be less than the cycle time. If this condition is not met, the cross-traffic can not be maintained in the event of an error since the cross-traffic may not be able to be processed within the cycle time.
    Another limitation on the allowable size of the ring R may result if the reconfiguration is to be completed within one transmission cycle. A master M can send a start data packet DPN within a transmission cycle only to a certain number of slaves S1, Sn. In addition, only a certain number of slaves S1,..., Sn can send their configuration data packets DPMC within the transmission cycle in the asynchronous region of the transmission cycle. Both limit the possible number of network nodes in the ring R, if the cross-traffic is to be switched particularly fast, ie within a transmission cycle.
    权利要求:
    Claims (7)
    [1]
    claims
    1. A method for data communication in the form of cross traffic between at least two slaves (S1, S2) of an annular data network (1), wherein a master (M) with a first branch (Z1) of the annular data network (1) with a number of slaves ( S1, S2) and with a second branch (Z2) of the annular data network (1) with a number of slaves (S4, Sn) is connected and the ends of the branches (Z1, Z2) with a ring master (RM) provided slave ( S3), characterized in that in the case of the occurrence of an error (F) in the annular data network (1) the ring master (RM) is configured to forward data packets and the master (M) the at least two slaves communicating with each other via cross traffic ( S1, S2) prompts to send configuration data packets (DPMC1, DPMC2) as multi-cast data packets to the respective other slaves (S1 ..... Sn) of the ring-shaped data network in order to send address tables (AT 1, AT2) into the at least two over Que traffic to communicate with each other slaves (S1, S2).
    [2]
    2. A method for data communication in the form of cross traffic between at least two slaves (S1, S2) of an annular data network (1), wherein a master (M) with a first branch (Z1) of the annular data network (1) with a number of slaves ( S1, S2) and with a second branch (Z2) of the annular data network (1) with a number of slaves (S4, Sn) is connected and the ends of the branches (Z1, Z2) with a ring master (RM) provided slave ( S3), characterized in that in case of fixing an error (F) in the annular data network (1) the ring master (RM) is configured to block at least multicast data packets and the master (M) the at least two via cross traffic with each other communicating slaves (S1, S2) requests to the respective other slaves (S1 ..... Sn) of the annular data network (1) to send configuration data packets (DPMC1, DPMC2) as multicast data packets to address tables (AT1, AT2 ) in the est two slaves (S1, S2) communicating with each other via cross traffic.
    [3]
    3. The method according to claim 1 or 2, characterized in that the master in both branches (Z1, Z2) of the annular data network (1) sends multicast data packets to all present in the ring slaves (S1, ..., Sn).
    [4]
    4. The method according to claim 1 or 2, characterized in that the master (M) at intervals in both branches (Z1, Z2) of the annular data network (1) ring-status data packets (DPR) are sent as multicast data packets, which are received by the ring master (RM) and the ring master (RM) detects an error (F) in the ring-shaped data network (1) if the ring status data packets (DPR) are received one or more times in succession from only one branch (Z1, Z2) or the ring master (RM) detecting the removal of a fault (F) in the annular data network (1) when the ring status data packets (DPR) one or more times in a row from both branches (Z1, Z2) are received.
    [5]
    5. The method according to claim 4, characterized in that as ring status data packets (DPR) provided in the communication protocol of the data communication multicast data packets are used.
    [6]
    6. The method according to claim 4 or 5, characterized in that the ring master (RM) sends an error data packet (DPF) to the master (M) to inform the master (M) of the occurrence of an error (F).
    [7]
    7. The method according to claim 1 or 2, characterized in that the master (M) sends a start data packet (DPN) to the at least two communicating via cross-traffic slaves (S1, S2) for sending the configuration data packets (DPMC1, DPMC2).
    类似技术:
    公开号 | 公开日 | 专利标题
    EP2634973B1|2014-10-01|Communication device for a redundant industrial communication network and method for operating a communication device
    EP2688249B1|2016-04-27|Method for message transmission in a redundant industrial communication network and communication device for a redundant industrial communication network
    EP2661023B1|2015-01-14|Communication device for a redundant industrial communication network and method for operating a communication device
    DE102014112082A1|2016-02-25|Distribution hub, automation network and method for transmitting real-time-relevant and non-real-time-relevant data packets
    EP2693700B1|2015-02-25|Method for message transmission in a redundant industrial communication network and communication device for a redundant industrial communication network
    EP2838220B1|2021-09-29|Method for the redundant transmission of messages in an industrial communication network and communication device
    WO2004021641A1|2004-03-11|Test method for message paths in communication networks, and network element
    EP2637362B1|2017-01-11|Bus participant device for connection to a line-redundant, serial data bus and method for controlling the communication of a bus participant with a line-redundant, serial data bus
    EP2127329B1|2011-04-27|Filtering of redundant frames in a network node
    EP1540895B1|2011-10-26|Method for permanent redundant transmission of data telegrams in communication systems
    EP3228036B1|2019-02-20|Method and control device for transmitting safety-relevant data in a motor vehicle by means of an ethernet standard
    EP3151476B1|2021-06-30|Method for cross-traffic between two slaves of a ring -shaped data network
    EP3151474B1|2018-09-05|Method for data communication with reduced overhead in a real-time ethernet data network
    EP3042473A1|2016-07-13|Method for transmitting messages in a computer network and computer network
    EP2670078B1|2015-04-15|Communication device for a redundant industrial communication network and method for operating a communication device
    EP2680503B1|2018-06-06|Communication device for a redundant industrial communication network and method for operating a communication device
    EP2704370B1|2018-02-07|Method for message transmission in a redundant industrial communication network and communication device for a redundant industrial communication network
    AT517782B1|2021-10-15|Method for asynchronous data communication in a real-time capable Ethernet data network
    AT517778B1|2021-10-15|Method for data communication with reduced overhead in a real-time capable Ethernet data network
    EP3422641A1|2019-01-02|Method for message delivery in a redundant operable industrial communication network and communication device for carrying out said method
    EP3694156A1|2020-08-12|Method for failsafe data transmission, network node, computer program and computer readable medium
    DE102019114303B3|2020-09-17|Method for detecting network participants in an automation network and automation network
    EP3435179B1|2020-07-08|Method for functionally secure exchange of information according to a safety standard
    DE102019131823A1|2021-05-27|Automation network and method for data transmission in an automation network
    EP2750310A1|2014-07-02|Method for synchronizing local clocks in a communication network of an industrial automation system and network infrastructure device
    同族专利:
    公开号 | 公开日
    US20170099213A1|2017-04-06|
    AT517779B1|2021-10-15|
    EP3151476B1|2021-06-30|
    CA2943885A1|2017-04-01|
    EP3151476A1|2017-04-05|
    US10182001B2|2019-01-15|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US20050243823A1|2003-05-06|2005-11-03|Overture Networks, Inc.|Multipoint protected switching ring|
    US20080025207A1|2006-05-30|2008-01-31|Shinichi Akahane|Switch and network fault recovery method|
    EP2575296A1|2011-09-30|2013-04-03|Huawei Technologies Co., Ltd.|Method and apparatus for recovering unicast traffic during ethernet ring failover|
    US3845472A|1972-12-15|1974-10-29|Johnson Service Co|Data communication system employing a series loop|
    US4677614A|1983-02-15|1987-06-30|Emc Controls, Inc.|Data communication system and method and communication controller and method therefor, having a data/clock synchronizer and method|
    US5371766A|1992-11-20|1994-12-06|International Business Machines Corporation|Clock extraction and data regeneration logic for multiple speed data communications systems|
    AUPM457694A0|1994-03-21|1994-04-14|Gerard Industries Pty Ltd|Home and building electrical control protocol|
    US5483535A|1995-01-17|1996-01-09|Zeta Music Partners|Communications network interface, and adapter and method therefor|
    DE19810587A1|1998-03-11|1999-09-16|Siemens Ag|Ethernet network with redundancy characteristics|
    DE19840562B4|1998-09-07|2007-06-28|Phoenix Contact Gmbh & Co. Kg|Security-related control and data transmission system|
    DE19904090C2|1999-02-02|2003-06-05|Wolf Gmbh Richard|Method and device for the automatic control and management of medical devices and systems|
    DE19904894B4|1999-02-06|2005-09-29|Wratil, Peter, Dr.|Method for slave-slave communication in a ring-shaped local area network|
    US7385919B2|2002-02-22|2008-06-10|Siemens Aktiengesellschaft|Local network, particularly Ethernet network having redundancy properties, and coupling device for such a network|
    DE10207529B4|2002-02-22|2004-07-29|Siemens Ag|Local network, in particular an Ethernet network with redundancy properties and a coupling device for such a network|
    US8611363B2|2002-05-06|2013-12-17|Adtran, Inc.|Logical port system and method|
    US7046621B2|2002-07-10|2006-05-16|I/O Controls Corporation|Redundant multi-fiber optical ring network|
    DE102004055330A1|2004-11-16|2006-05-24|Bosch Rexroth Aktiengesellschaft|Method and device for operating a network|
    US8451730B2|2006-01-26|2013-05-28|Broadcom Corporation|Apparatus and method for implementing multiple high speed switching fabrics in an ethernet ring topology|
    JP4739141B2|2006-02-24|2011-08-03|アラクサラネットワークス株式会社|Ring network and master node|
    US8520508B2|2007-02-13|2013-08-27|Force10 Networks, Inc.|Spanning tree ring protocol|
    WO2008107883A2|2007-03-08|2008-09-12|Corrigent Systems Ltd.|Prevention of frame duplication in interconnected ring networks|
    EP2020782A1|2007-08-03|2009-02-04|Nokia Siemens Networks Oy|Method and device for ring protection and system comprising such device|
    JP5046964B2|2008-01-10|2012-10-10|キヤノン株式会社|COMMUNICATION SYSTEM AND COMMUNICATION TERMINAL, METHOD, PROGRAM|
    US7990850B2|2008-04-11|2011-08-02|Extreme Networks, Inc.|Redundant Ethernet automatic protection switching access to virtual private LAN services|
    US7856019B2|2008-08-29|2010-12-21|Extreme Networks, Inc.|Convergence of multicast traffic|
    ES2382875T3|2009-08-28|2012-06-14|Hirschmann Automation And Control Gmbh|Procedure for multiple redundancy against faults in networks with ring topologies|
    CN101815107B|2010-05-13|2013-10-09|华为技术有限公司|Method, system and equipment for managing address in Ethernet ring|
    DE102011082965A1|2011-09-19|2013-01-24|Siemens Aktiengesellschaft|Method for operating a network arrangement and network arrangement|
    US8659993B2|2012-05-04|2014-02-25|Extreme Networks, Inc.|Priority domains for protection switching processes|
    WO2014199471A1|2013-06-12|2014-12-18|三菱電機株式会社|Communication system, communication device, and protection method|
    US9503361B2|2014-06-13|2016-11-22|Cisco Technology, Inc.|Active/static path redundancy|US11129906B1|2016-12-07|2021-09-28|David Gordon Bermudes|Chimeric protein toxins for expression by therapeutic bacteria|
    WO2021074373A1|2019-10-18|2021-04-22|Omicron Electronics Gmbh|Safe test arrangement|
    法律状态:
    优先权:
    申请号 | 申请日 | 专利标题
    ATA50831/2015A|AT517779B1|2015-10-01|2015-10-01|Method for cross-traffic between two slaves in a ring-shaped data network|ATA50831/2015A| AT517779B1|2015-10-01|2015-10-01|Method for cross-traffic between two slaves in a ring-shaped data network|
    EP16191487.4A| EP3151476B1|2015-10-01|2016-09-29|Method for cross-traffic between two slaves of a ring -shaped data network|
    US15/281,841| US10182001B2|2015-10-01|2016-09-30|Method for cross-trafficking between two slaves of an annular data network|
    CA2943885A| CA2943885A1|2015-10-01|2016-09-30|Method for cross-trafficking between two slaves of an annular data network|
    [返回顶部]