EP2987280A1 - Protocole de redondance logiciel - Google Patents

Protocole de redondance logiciel

Info

Publication number
EP2987280A1
EP2987280A1 EP14734779.3A EP14734779A EP2987280A1 EP 2987280 A1 EP2987280 A1 EP 2987280A1 EP 14734779 A EP14734779 A EP 14734779A EP 2987280 A1 EP2987280 A1 EP 2987280A1
Authority
EP
European Patent Office
Prior art keywords
network
redundancy protocol
middleware
ring topology
redundancy
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP14734779.3A
Other languages
German (de)
English (en)
Inventor
Vivek Kulkarni
Andreas Scholz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Siemens Corp filed Critical Siemens AG
Publication of EP2987280A1 publication Critical patent/EP2987280A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/42—Loop networks
    • H04L12/437—Ring fault isolation or reconfiguration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/22—Alternate routing

Definitions

  • the present invention relates to the technical field of redundancy protocols for a network, wherein the network comprises at least one ring topology.
  • DDS Data Distribution Service
  • MRP Media Redundancy Protocol
  • MRP Media Redundancy Protocol
  • MRP is implemented on the network components - usually together with other communication stacks such as Profinet - on managed switches such as the Siemens SCALANCE.
  • MRP (and similar protocols) is now implemented to transparently handle error handling for the higher-level layers, that is middleware systems in this case. This is achieved by implementing the implementation of the protocols on the network components, ie switches. This increases the costs for the network components because in addition to the pure network functions also computing power and memory for the implementation of the redundancy protocols must be invested.
  • the present invention is therefore based on the object to reduce the cost of network components and / or to facilitate a simplification of the design of network components.
  • a middleware includes a redundancy protocol.
  • the redundancy protocol is implemented in a network stack at the application level.
  • a method for ensuring a functionality of a network is proposed.
  • the network includes a ring topology.
  • the method comprises the step of monitoring the ring topology by means of a redundancy protocol.
  • the redundancy protocol is comprised of middleware.
  • the redundancy protocol is implemented in a network stack at the application level.
  • a network in another aspect, includes several network nodes.
  • the network nodes are arranged in a ring topology.
  • At least one of the network nodes includes middleware.
  • the middleware includes a redundancy protocol to ensure functionality of the ring topology.
  • the redundancy protocol is implemented at the application level in a network stack.
  • FIG. 1 a network according to a preferred embodiment of the invention
  • FIG. 2 shows the network of FIG. 1 with a destroyed ring topology
  • FIG. 3 shows a network node configured as a redundancy manager of the network of FIGS. 1 and 2;
  • FIG. 4 shows the redundancy manager of FIG. 3 in a stacked view.
  • FIGS 1 to 4 illustrate a network 1 according to a preferred embodiment of the invention.
  • Figure 1 shows the network 1 according to a preferred embodiment of the invention.
  • the network 1 comprises a plurality of network nodes 11, IIa, IIb, 11c, 11d, which are arranged in a ring topology 12.
  • the ring topology 12 comprises the entire network 1.
  • individual or all of the network nodes 11, IIa, IIb, 11c, 11d may be connected to further network nodes or network parts (not shown) not part of the ring topology 12.
  • At least one, several or each of the network nodes 11, IIa, IIb, 11c, 11d comprises a middleware.
  • the network node 11 is shown in more detail, for example.
  • the network node 11 comprises the middleware 16.
  • the middleware 16 comprises a redundancy protocol 17.
  • the redundancy protocol 17 is available at application level 18 in a network. technikstack 19 implemented. This can also be seen in FIG. 1, since in the network stack 19 the redundancy protocol 17 configured as MRP is implemented via a middleware protocol 16a designed as a DDS protocol.
  • the arrows 29a-d represent logical communication links between the middlware components of the individual network nodes 11, IIa, IIb, 11c, 11d, which serve to exchange state information over the network 1, i. about which communication links are functional and which are not.
  • the communication between the network nodes 11, IIa, IIb, 11c, Id is preferably bidirectional.
  • Such a monitoring function is often part of the middleware and can - if available - be shared by the invention described here. If not available, the monitoring function is implemented as part of the redundancy protocol 17.
  • the redundancy protocol 17 includes an interruption function 25 (see FIG. 3).
  • the interrupt function 25 is configured to cause the logical interrupt 15 of the ring topology 12, for example, by deactivating the port 14 of the network node 11.
  • Figure 2 shows the network 1 of Figure 1 with a (for example physically) destroyed ring topology 12 caused by the interruption 21 between the network nodes 11c and 11d.
  • the port 14 is interrupted as shown in Figure 1, there is no longer any connection to the network node lld, ie the network node lld is no longer reachable from the perspective of the middleware. This circumstance is detected by the monitoring function and reported to the network node 11.
  • the redundancy protocol on the network account 11 takes steps to compensate for the failure and therefore activates in this embodiment the Port 14.
  • all network nodes 11, IIa, IIb, 11c, 11d can again be reached.
  • FIG. 3 shows the network node 11 in a more detailed representation.
  • the network node 11 of the ring topology 12 embodied as a redundancy manager 11 comprises the middleware 16.
  • the middleware 16 comprises a redundancy protocol 17.
  • the redundancy protocol 16 serves to ensure functionality of the ring topology 12.
  • the implementation of the redundancy protocol comprises the interrupt function 25.
  • FIG. 4 shows the network node 11 of FIG. 3 in stack view.
  • a network stack 19 is implemented.
  • the network stack 19 comprises an application level 18, as well as underlying levels 28, such as the transport level (TCP) and the network level (IP).
  • TCP transport level
  • IP network level
  • protocols 16a for the application of the middleware 16 and the redundancy protocol 17 are implemented.
  • Middleware protocols 16a are implemented at application layer 18 in network stack 19.
  • the ring topology 12 is monitored by means of the redundancy protocol 17.
  • the redundancy protocol 17 is configured to break the logical interrupt 15 if the ring topology 12 is destroyed.
  • the redundancy protocol 17 is configured to cause the logical interrupt 15 of the ring topology 12 when an interrupt 21 of the ring topology 12 has been resolved.
  • the redundancy protocol 17 is a media
  • the middleware 16 includes or is an implementation of the Data Distribution Standard (also known as the Data Distribution Service Standard) of the Object Management Group (OMG).
  • OMG Object Management Group
  • the middleware is in at least one other of the network node IIa, IIb, 11c, lld or in several of the network nodes 11, IIa, IIb, 11c, lld or in all of the network nodes 11, IIa, IIb, 11c, lld the ring topology 12th implemented with the redundancy protocol 17 at application level 18. It is particularly advantageous to implement the network software in all network nodes 11, IIa, IIb, 11c, 11d. Then, in the event of an interruption 21, all network nodes 11, IIa, IIb, 11c, 11d are implemented with the aid of the implemented
  • Middleware 16 respectively, implemented in the middleware implemented redundancy protocol. If only a part of the network nodes 11, IIa, IIb, 11c, 11d has implemented the middleware with the redundancy protocol 17 at the application level 18, then the invention still functions since the communication between the middleware components on this node also works in the case of an interruption 21 can still take place. According to preferred embodiments, the implementation of the redundancy protocol 17 in the middleware 16, i. at application level 18 in the network stack 19.
  • MRP Media Redundancy Protocol
  • DDS Data Distribution Service
  • MRP requires a ring topology 12 in the network, as shown in FIG.
  • the MRP Manager 1 which must be present in every network, monitors the condition of the ring 12 he circulates special data packets in ring 12. As long as these packets reach Manager 11, it ensures that all network connections are intact. For the functioning of Ethernet is crucial that the network 1 is free of rings.
  • the MRP manager 11 therefore "interrupts" the network 1 at one of its two network ports 13, 14 by means of the logical interrupt 15, thereby creating a circular line topology (however, the special monitoring packets may pass the interrupt 15).
  • the MRP Manager 11 cancels the logical interrupt 15 again. This is permissible because at least at another point 21, the network 1 is interrupted, which has led to the absence of the monitoring packets. By removing the blocking 15 thus again creates a line topology.
  • DDS uses a data-driven approach.
  • the communication connections that are established in the network of DDS arise from the fact that DDS users make data available and other users are interested in this data.
  • the coupling of producers and users is loose, i. Users do not know who produced the data and producers do not who communicates the data. This separation makes it easy to add new participants to the network and also provides good scalability.
  • the DDS middleware In contrast to a classic client-server approach, the DDS middleware has to perform additional tasks related to participant monitoring.
  • the monitoring of the participants ie the monitoring whether all participants are still reachable
  • the server In a client-server architecture, the monitoring of the participants (ie the monitoring whether all participants are still reachable) can be easily taken over by the server, because he knows who is interested in all data. The failure of the server in turn is easily detected by the clients, since these are not Can get connection to the server. Due to the loose coupling in DDS, this is no longer the case and the middleware itself must take over the monitoring of the network subscribers. This is done by regularly sending heartbeats from the middleware to the middleware, or similar mechanisms.
  • a network 1 embodied as, for example, a soft MRP system, as shown in FIG. 2, can be realized, for example, by a middleware 16 configured as DDS based on the monitoring mechanism on one of the ring participants 11 (Soft MRP Manager).
  • port interruption function 25 is implemented as in MRP. Analogous to the operation of MRP installed on a switch, according to preferred embodiments of the invention, the interrupt 15 is released as soon as the DDS monitoring service reports that nodes / connections have failed and is restored as soon as the failure 21 has been rectified.
  • a conventional MRP implemented on the MAC layer guarantees significantly faster reaction times in the event of failures
  • a conventional MAC layer-implemented MRP requires "intelligent" network components, which results in higher costs than standard components.
  • a traditional MAC layer-implemented MRP works transparently and independently of overlaid network layers.
  • Preferred soft MRP based embodiments of the invention require the presence of middleware.
  • preferred soft MRP based embodiments of the invention provide a cost effective replacement for traditional MAC layer implemented MRP for all application areas where middleware solutions such as DDS are used. In these application areas, the response time of soft MRP is sufficient, since soft MRP uses the monitoring of DDS, the reaction time automatically scales with the requirements of a specific system in the event of an error since the monitoring is configured in DDS based on these requirements.
  • Preferred embodiments of the invention take advantage of communication middleware, such as e.g. DDS, other requirements for communication networks, such as an automation application realized with today's technology, but increasingly used in the same field of application (industrial plants).
  • the previous solution (MRP at the network level) can therefore be replaced by an alternative, lower-cost solution (MRP at the middleware level) for these new areas of application.
  • the soft MRP solution according to preferred embodiments of the invention is not a universal replacement for the existing implementation of MRP because it is only suitable for certain fields of application (where DDS is used) and also achieves poorer response times in the event of a fault. If these reaction times are tolerable and the field of application is given, however, significant cost savings can be achieved in the network components.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)

Abstract

L'invention concerne un logiciel médiateur (16), comprenant un protocole de redondance (17) qui est implémenté au niveau application (18) dans une pile réseau (19).
EP14734779.3A 2013-07-31 2014-06-24 Protocole de redondance logiciel Withdrawn EP2987280A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102013215035.0A DE102013215035B3 (de) 2013-07-31 2013-07-31 Soft-Redundanzprotokoll
PCT/EP2014/063305 WO2015014543A1 (fr) 2013-07-31 2014-06-24 Protocole de redondance logiciel

Publications (1)

Publication Number Publication Date
EP2987280A1 true EP2987280A1 (fr) 2016-02-24

Family

ID=51062798

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14734779.3A Withdrawn EP2987280A1 (fr) 2013-07-31 2014-06-24 Protocole de redondance logiciel

Country Status (5)

Country Link
US (1) US20160197766A1 (fr)
EP (1) EP2987280A1 (fr)
CN (1) CN105432044A (fr)
DE (1) DE102013215035B3 (fr)
WO (1) WO2015014543A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180026459A (ko) 2015-06-18 2018-03-12 세파론, 인코포레이티드 1,4-치환된 피페리딘 유도체
WO2016205590A1 (fr) 2015-06-18 2016-12-22 Cephalon, Inc. Dérivés de 4-benzyl et 4-benzoyl-pipéridine substitués
KR101760010B1 (ko) * 2016-07-15 2017-07-20 주식회사 인피니트헬스케어 Ｖｎａ 미들웨어에서의 페일오버 처리 방법
TWI732233B (zh) * 2019-06-24 2021-07-01 竹北動力股份有限公司 控制系統和控制方法

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW419917B (en) * 1998-03-30 2001-01-21 Toshiba Corp Communication network system
DE102007016432A1 (de) * 2007-04-05 2008-10-09 Hirschmann Automation And Control Gmbh Verfahren zur Konfiguration des Redundanzprotokolls auf Geräten in einem redundanten Ringnetzwerk
WO2003096210A1 (fr) * 2002-05-08 2003-11-20 Starrete Communications, Inc. Systeme et procede d'etablissement de visiophonie sur une infrastructure de reseau a acces par cable
US20060291378A1 (en) * 2005-06-28 2006-12-28 Alcatel Communication path redundancy protection systems and methods
US9083551B2 (en) * 2006-03-17 2015-07-14 Tellabs Operations, Inc. Method and apparatus for media distribution using VPLS in a ring topology
US8250227B2 (en) * 2007-03-02 2012-08-21 International Business Machines Corporation Providing different rates to different users of a download service
WO2010105828A1 (fr) * 2009-03-18 2010-09-23 Hirschmann Automation And Control Gmbh Exploitation en parallèle de protocoles rstp (rapid spanning tree protocol) et mrp (media redundancy protocol) et segmentation/couplage
US8509618B2 (en) * 2009-05-06 2013-08-13 Ciena Corporation Photonic routing systems and methods for loop avoidance
WO2012100671A1 (fr) * 2011-01-30 2012-08-02 华为技术有限公司 Procédé d'association de ports de réseau physiques, carte de réseau et système de communication
DE102011004064A1 (de) * 2011-02-14 2012-08-16 Siemens Aktiengesellschaft Zwischennetzwerk in Ringtopologie und Verfahren zum Herstellen einer Netzwerkverbindung zwischen zwei Netzwerkdomänen
EP2536070A1 (fr) * 2011-06-15 2012-12-19 BAE Systems Plc Transfert de données
US8670303B2 (en) * 2011-10-05 2014-03-11 Rockwell Automation Technologies, Inc. Multiple-fault-tolerant ethernet network for industrial control
US8625416B2 (en) * 2011-12-29 2014-01-07 Schneider Electric Industries Sas Verifying communication redundancy in a network
EP2713563B1 (fr) * 2012-09-28 2017-08-02 Siemens Aktiengesellschaft Système de communication industriel pouvant fonctionner de manière redondante, appareil de communication et procédé de fonctionnement redondant d'un système de communication industriel
US9800420B2 (en) * 2013-02-25 2017-10-24 Sequans Communications S.A. eMBMS over LAN
US9288138B2 (en) * 2013-12-27 2016-03-15 Dell Products L.P. N-node virtual link trunking (VLT) systems and methods

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2015014543A1 *

Also Published As

Publication number Publication date
DE102013215035B3 (de) 2014-11-06
CN105432044A (zh) 2016-03-23
US20160197766A1 (en) 2016-07-07
WO2015014543A1 (fr) 2015-02-05

Similar Documents

Publication Publication Date Title
EP2343857B1 (fr) Noeud de réseau pour un réseau de communication
DE60130285T2 (de) Reduntante Input/Output Management Einheit, insbesondere ein Wegewahlsystem
EP1297394B1 (fr) Systeme de commande redondant avec calculateur pilote, et unite peripherique pour un tel systeme de commande
EP2838220A1 (fr) Procédé de transmission redondante de messages dans un réseau de communication industriel et appareil de communication
EP1532771A1 (fr) Methode d'essai de chemins de messages dans des reseaux de communication et element de reseau
EP3753205B1 (fr) Transmission de données dans des réseaux de données sensibles au temps
DE102013215035B3 (de) Soft-Redundanzprotokoll
DE10305415B4 (de) Verfahren und Vorrichtung zum medienredundanten Betreiben eines Endgeräts in einem Netzwerk
DE19921589C2 (de) Verfahren zum Betrieb eines Datenübertragungssystems
DE102011086726B4 (de) Verfahren zur redundanten Kommunikation zwischen einem Nutzer-Terminal und einem Leitsystem-Server
DE102006004339A1 (de) Redundantes Kommunikationsnetzwerk
DE60200692T2 (de) Wegeleitsystem zur Sicherstellung der Kontinuität der Interfacedienste zu den assoziierten Nachbarnetzen
EP1399818B1 (fr) Procede et dispositif de communication dans un systeme informatique reparti tolerant aux erreurs
DE202015004439U1 (de) Überwachungsvorrichtung und Netzwerkteilnehmer
EP2881812A1 (fr) Procédé de fonctionnement d'un dispositif d'automatisation
EP3739822A1 (fr) Accouplement d'un réseau de communication à un terminal de communication
EP2817923B1 (fr) Réseau de calculateurs avec un bus de liaison de forme annulaire
DE19743758C1 (de) Responsives System zur digitalen Signalverarbeitung sowie Verfahren zum konsistenten Betrieb eines responsiven Systems
EP1843929B1 (fr) Systeme de commande pour la regulation et/ou la surveillance d'objets
DE10131135B4 (de) Verfahren zum Betreiben eines Netzwerkknotens
EP1415452B1 (fr) Moyen de couplage d'un dispositif de traitement de donnees
DE10025283B4 (de) Vorrichtung zur dynamischen Verbindung von mindestens zwei Datenringzellen
EP2290882B1 (fr) Procédé de redondance d'erreurs multiple dans des réseaux à topologies annulaires
EP1370034A1 (fr) Groupe des passerelles insensible aux défaillances
EP0974215A2 (fr) Liaison de communication de donnees dans un reseau de communication hierarchique a bus, fonctionnant selon un protocole demande/reponse, a savoir selon le "protocole d'appel selectif"

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20151119

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180103