EP2987280A1 - Soft-redundanzprotokoll - Google Patents

Soft-redundanzprotokoll

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
English (en)
French (fr)
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
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 filed Critical Siemens AG
Publication of EP2987280A1 publication Critical patent/EP2987280A1/de
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

Middleware (16), umfassend ein Redundanzprotokoll (17) welches auf Applikationsebene (18) in einem Netzwerkstack (19) implementiert ist.

Description

Beschreibung
Soft-Redundanzprotokoll Die vorliegende Erfindung bezieht sich auf das technische Gebiet der Redundanzprotokolle für ein Netzwerk, wobei das Netzwerk mindestens eine Ringtopologie umfasst.
(Kommunikations- ) Middleware wird heute in vielen Systemen als Basis eingesetzt um Monitoring oder Steuerungslösungen umzusetzen. Im Folgenden wird stellvertretend für die Vielzahl dieser Middleware Lösungen der Data Distribution Service (DDS) und stellvertretend für Redundanzprotokolle das Media Redundancy Protocol (MRP) verwendet. Die Grundlagen zu DDS finden sich auf
http : //portals . omg . org/dds/content/page/specifications . Seit April 2008 ist MRP im Standard IEC 62439 der International Electrotechnical Commission definiert. Um die Funktionsfähigkeit des Kommunikationsnetzwerks auch bei Fehlern auf einzelnen Leitungen sicherzustellen werden heute redundante Topologien, z.B. Ringe, verwendet. Das Management dieser Topologien wird von Redundanzprotokollen, wie zum Beispiel dem Media Redundancy Protocol (MRP) übernommen.
MRP wird heutzutage auf den Netzwerkkomponenten - meist zusammen mit weiteren Kommunikations-Stacks wie Profinet - auf Managed Switches wie z.B. dem Siemens SCALANCE implementiert. MRP (und ähnlichen Protokolle) wird heute so implementiert, dass sie die Fehlerbehandlung transparent für die übergelagerten Schichten, d.h. in diesem Fall Middleware Systeme, durchführen. Dies wird erreicht indem die Implementierung der Protokolle auf den Netzwerkkomponenten, d.h. Switches, imple- mentiert wird. Dies treibt die Kosten für die Netzwerkkomponenten in die Höhe weil neben den reinen Netzwerkfunktionen auch noch Rechenleistung und Speicher für die Implementierung der Redundanzprotokolle investiert werden muss. Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, die Kosten für Netzwerkkomponenten zu senken und/oder eine Vereinfachung der Ausgestaltung von Netzwerkkomponenten zu ermöglichen.
Diese Aufgabe wird durch die in den unabhängigen Ansprüchen beschriebenen Lösungen gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind in weiteren Ansprüchen angegeben. Gemäss einem ersten Aspekt wird eine Middleware vorgeschlagen. Die Middleware umfasst ein Redundanzprotokoll. Das Redundanzprotokoll ist in einem Netzwerkstack auf Applikationsebene implementiert. Gemäss einem weiteren Aspekt wird ein Verfahren zum Sicherstellen einer Funktionsfähigkeit eines Netzwerkes vorgeschlagen. Das Netzwerk umfasst eine Ringtopologie . Das Verfahren umfasst den Verfahrensschritt eines Überwachens der Ringtopologie mittels eines Redundanzprotokolls. Das Redundanzproto- koll wird von einer Middleware umfasst. Das Redundanzprotokoll wird in einem Netzwerkstack auf Applikationsebene implementiert .
Gemäss einem weiteren Aspekt wird ein Netzwerk vorgeschlagen. Das Netzwerk umfasst mehrere Netzwerkknoten. Die Netzwerkknoten sind in einer Ringtopologie angeordnet. Mindestens einer der Netzwerkknoten umfasst eine Middleware. Die Middleware umfasst ein Redundanzprotokoll zum Sicherstellen einer Funktionsfähigkeit der Ringtopologie. Das Redundanzprotokoll ist auf Applikationsebene in einem Netzwerkstack implementiert.
Grundlage von bevorzugen Ausführungsbeispielen der Erfindung ist die Idee, die benötigten Systemkosten zu reduzieren indem ein Redundanzprotokoll nicht auf Netzwerkebene implementiert wird sondern als Teilfunktion der eingesetzten Middleware. Dies erlaubt es (Meist mit Einbußen was die Reaktionsgeschwindigkeit angeht) , die Funktion von einem Redundanzprotokoll wie beispielsweise MRP in „Anwendungs-Software" zu rea- lisieren und im Austausch dafür preiswertere Standardkomponenten im Netzwerk zu verwenden.
Die Erfindung wird nachfolgend Anhand der Figuren beispiels- weise näher erläutert. Dabei zeigen:
Figur 1 : ein Netzwerk gemäss einem bevorzugten Ausführungsbeispiel der Erfindung; Figur 2: das Netzwerk von Figur 1 mit einer zerstörten Ringtopologie;
Figur 3 einen als Redundanzmanager ausgestalteten Netzwerkknoten des Netzwerks von Figur 1 und 2;
Figur 4 den Redundanzmanager von Figur 3 dargestellt in Stackansicht .
Figuren 1 bis 4 illustrieren ein Netzwerk 1 gemäss einem be- vorzugten Ausführungsbeispiel der Erfindung.
Figur 1 zeigt das Netzwerk 1 gemäss einem bevorzugten Ausführungsbeispiel der Erfindung. Das Netzwerk 1 umfasst mehrere Netzwerkknoten 11, IIa, IIb, 11c, lld, welche in einer Ring- topologie 12 angeordnet sind. In dem dargestellten Ausführungsbeispiel umfasst die Ringtopologie 12 das gesamte Netzwerk 1. Zusätzlich können in weiteren Varianten des Ausführungsbeispiels einzelne oder alle der Netzwerkknoten 11, IIa, IIb, 11c, lld jedoch mit weiteren Netzwerkknoten oder Netz- werkteilen (nicht dargestellt) verbunden sein, welche nicht Teil der Ringtopologie 12 sind.
Mindestens einer, mehrere oder jeder der Netzwerkknoten 11, IIa, IIb, 11c, lld umfasst eine Middleware. In Figur 3 ist der Netzwerkknoten 11 beispielsweise detaillierter dargestellt. Der Netzwerkknoten 11 umfasst die Middleware 16. Die Middleware 16 umfasst ein Redundanzprotokoll 17. Das Redundanzprotokoll 17 ist auf Applikationsebene 18 in einem Netz- werkstack 19 implementiert. In Figur 1 ist dies auch ersichtlich, da in dem Netzwerkstack 19 das als MRP ausgestaltete Redundanzprotokoll 17 über einem als DDS-Protokoll ausgestalteten Middlewareprotokoll 16a implementiert ist.
Verweisend auf Figur 1, stellen die Pfeile 29a-d logische Kommunikationsverbindungen zwischen den Middlware-Komponenten der einzelnen Netzwerkknoten 11, IIa, IIb, 11c, lld dar, welche dazu dienen, Zustandsinformationen über das Netzwerk 1 auszutauschen, d.h. darüber welche Kommunikationsverbindungen funktionsfähig sind und welche nicht. Die Kommunikation zwischen den Netzwerkknoten 11, IIa, IIb, 11c, lld ist vorzugsweise bidirektional. Eine solche Monitoring Funktion ist häufig Bestandteil der Middleware und kann - sofern vorhanden - von der hier beschriebenen Erfindung mitgenutzt werden. Falls nicht vorhanden, wird die Monitoring Funktion als Bestandteil des Redundanzprotokolls 17 implementiert.
Gemäss dem anhand der Figuren 1 bis 4 dargestellten bevorzug- ten Ausführungsbeispiel umfasst das Redundanzprotokoll 17 eine Unterbrechungsfunktion 25 (siehe Figur 3) . Die Unterbrechungsfunktion 25 ist ausgestaltet, die logische Unterbrechung 15 der Ringtopologie 12 zu veranlassen, indem beispielsweise der Port 14 des Netzwerkknotens 11 deaktiviert wird.
Figur 2 zeigt das Netzwerk 1 von Figur 1 mit einer (beispielsweise physikalisch) zerstörten Ringtopologie 12, welche durch die Unterbrechung 21 zwischen den Netzwerkknoten 11c und lld verursacht wurde. Wenn der Port 14 wie in Figur 1 dargestellt unterbrochen ist, besteht keine Verbindung mehr zum Netzwerkknoten lld, d.h. der Netzwerkknoten lld ist aus Sicht der Middleware nicht mehr erreichbar. Dieser Umstand wird von der Monitoring Funktion entdeckt und an den Netz- werkknoten 11 gemeldet. Das Redundanzprotokoll auf dem Netzwerkkonten 11 unternimmt Schritte um den Ausfall zu kompensieren und aktiviert daher in diesem Ausführungsbeispiel den Port 14. Im entstehenden Netzwerk aus Figur 2 sind wieder alle Netzwerkknoten 11, IIa, IIb, 11c, lld erreichbar.
Figur 3 zeigt den Netzwerkknoten 11 in detaillierterer Dar- Stellung. Der als Redundanzmanager 11 ausgestaltete Netzwerkknoten 11 der Ringtopologie 12 umfasst die Middleware 16. Die Middleware 16 umfasst ein Redundanzprotokoll 17. Das Redundanzprotokoll 16 dient dem Sicherstellen einer Funktionsfähigkeit der Ringtopologie 12. Dazu umfasst die Implementie- rung des Redundanzprotokolls die Unterbrechungsfunktion 25.
Figur 4 zeigt den Netzwerkknoten 11 von Figur 3 in Stack- Ansicht. In dem Netzwerkknoten 11 ist ein Netzwerkstack 19 implementiert. Der Netzwerkstack 19 umfasst eine Applikati- onsebene 18, sowie tieferliegende Ebenen 28, wie beispielsweise die Transport-Ebene (TCP) und die Netzwerk-Ebene (IP) . Auf der Applikationsebene 18 sind Protokolle 16a für die Applikation der Middleware 16 sowie das Redundanzprotokoll 17 implementiert. Das Redundanzprotokoll 17, sowie
Middlewareprotokolle 16a sind auf Applikationsebene 18 in dem Netzwerkstack 19 implementiert.
Zum Sicherstellen der Funktionsfähigkeit des Netzwerkes 1, wird mittels des Redundanzprotokolls 17 die Ringtopologie 12 überwacht.
Vorzugsweise ist das Redundanzprotokoll 17 ausgestaltet, die logische Unterbrechung 15 aufzuheben, falls die Ringtopologie 12 zerstört wird.
Vorzugsweise ist das Redundanzprotokoll 17 ausgestaltet, die logische Unterbrechung 15 der Ringtopologie 12 zu veranlassen, wenn eine Unterbrechung 21 der Ringtopologie 12 behoben wurde .
Vorzugsweise ist das Redundanzprotokoll 17 ein Media
Redundancy Protocol (MRP) gemäss dem Standard IEC 62439 der International Electrotechnical Commission. Vorzugsweise umfasst oder ist die Middleware 16 eine Implementierung des Data Distribution Standards (auch Data Distribution Service Standard genannt) der Object Management Group (OMG) .
Vorzugsweise wird die Middleware in mindestens einem weiteren der Netzwerkknoten IIa, IIb, 11c, lld oder in mehreren der Netzwerkknoten 11, IIa, IIb, 11c, lld oder in allen der Netz- werkknoten 11, IIa, IIb, 11c, lld der Ringtopologie 12 mit dem Redundanzprotokoll 17 auf Applikationsebene 18 implementiert. Besonders vorteilhaft ist es, die Netzwerksoftware in allen Netzwerkknoten 11, IIa, IIb, 11c, lld zu implementieren. Dann sind im Falle einer Unterbrechung 21 alle Netzwerk- knoten 11, IIa, IIb, 11c, lld mit Hilfe der implementierten
Middleware 16, respektive des in der Middleware implementierten Redundanzprotokolls erreichbar. Hat nur ein Teil der Netzwerkknoten 11, IIa, IIb, 11c, lld die Middleware mit dem Redundanzprotokoll 17 auf Applikationsebene 18 implementiert, so funktioniert die Erfindung nach wie vor, da die Kommunikation zwischen den Middleware-Komponenten auf diesen Knoten auch bei einer Unterbrechung 21 nach wie vor stattfinden kann . Gemäss bevorzugten Ausführungsbeispielen erfolgt die Implementierung des Redundanzprotokolls 17 in der Middleware 16, d.h. auf Applikationsebene 18 im Netzwerkstack 19.
Im Folgenden wird stellvertretend für die Vielzahl der Midd- leware Lösungen der Data Distribution Service (DDS) und stellvertretend für Redundanzprotokolle das Media Redundancy Protocol (MRP) verwendet.
Kurzüberblick MRP
MRP setzt eine Ringtopologie 12 im Netzwerk voraus, wie in Figur 1 gezeigt. Der MRP Manager 1, der in jedem Netzwerk vorhanden sein muss, überwacht den Zustand des Ringes 12 in- dem er spezielle Datenpakete im Ring 12 zirkulieren lässt. Solange diese Pakete den Manager 11 erreichen, ist sichergestellt dass alle Netzwerkverbindungen intakt sind. Für die Funktionsweise von Ethernet ist entscheidend, dass das Netzwerk 1 kreisfrei ist. Der MRP Manager 11 „unterbricht" daher das Netzwerk 1 an einem seiner beiden Netzwerkports 13, 14 mittels der logischen Unterbrechung 15 und erzeugt dadurch eine kreisfreie Linientopologie (die speziellen Pakete zur Überwachung können die Unterbrechung 15 jedoch passieren) .
Im Fehlerfall, d.h. wenn die zirkulierenden Überwachungspakete ausbleiben, hebt der MRP Manager 11 die logische Unterbrechung 15 wieder auf. Dies ist zulässig, weil zumindest an einer anderen Stelle 21 das Netzwerk 1 unterbrochen ist, was zum Ausbleiben der Überwachungspakete geführt hat. Durch das Aufheben der Blockierung 15 entsteht damit wieder eine Linientopologie .
Kurzüberblick DDS
DDS verwendet einen datengetriebenen Ansatz. Die Kommunikationsverbindungen die im Netzwerk von DDS aufgebaut werden ergeben sich daraus, dass DDS Nutzer Daten zur Verfügung stellen und andere Nutzer Interesse an diesen Daten anmelden. Die Kopplung der Produzenten und Nutzer ist dabei lose, d.h. Nutzer wissen nicht wer die Daten produziert hat und Produzenten nicht wer die Daten kommuniziert. Diese Trennung ermöglicht es, einfach neue Teilnehmer ins Netzwerk aufzunehmen und bietet auch eine gute Skalierbarkeit.
Im Gegensatz zu einem klassischen Client-Server Ansatz müssen von der DDS Middleware jedoch zusätzliche Aufgaben in Bezug auf das Monitoring der Teilnehmer übernommen werden. In einer Client-Server Architektur kann das Monitoring der Teilnehmer (sprich die Überwachung ob noch alle Teilnehmer erreichbar sind) leicht vom Server übernommen werden, weil dieser weiß wer alles an Daten interessiert ist. Der Ausfall des Servers wiederum wird von den Clients leicht entdeckt, da diese keine Verbindung zum Server bekommen können. Durch die lose Kopplung in DDS ist dies nicht mehr gegeben und die Middleware selbst muss die Überwachung der Netzteilnehmer übernehmen. Dies geschieht indem von der Middleware regelmäßig Heartbeats von den einzelnen Knoten aus gesendet werden, oder ähnliche Mechanismen .
Kombination MRP und DDS Ein als beispielsweise Soft-MRP System ausgebildetes Netzwerk 1, wie in Figur 2 dargestellt, kann beispielsweise realisiert werden, indem basierend auf dem Monitoring Mechanismus von einer als DDS ausgestalteten Middleware 16 auf einem der Ringteilnehmer 11 (Soft-MRP Manager) die Portunterbrechungs- funktion 25 wie in MRP implementiert wird. Analog zur Funktionsweise von auf einem Switch installierten MRP, wird gemäss bevorzugten Ausführungsbeispielen der Erfindung die Unterbrechung 15 aufgehoben, sobald der DDS Monitoring Service meldet dass Knoten/Verbindungen ausgefallen sind und wiederherge- stellt, sobald der Ausfall 21 behoben ist.
Vergleich der Lösungen MRP und Soft-MRP:
Ein herkömmliches auf MAC-Schicht implementiertes MRP garan- tiert deutlich schnellere Reaktionszeiten bei Ausfällen
(Monitoring in DDS nutzt architekturbedingt höhere Timeouts) .
Ein herkömmliches auf MAC-Schicht implementiertes MRP erfordert „intelligente" Netzwerkkomponenten, was höhere Kosten als Standardkomponenten zur Folge hat.
Ein herkömmliches auf MAC-Schicht implementiertes MRP arbeitet transparent und unabhängig von übergelagerte Netzwerkschichten. Bevorzugte auf Soft-MRP basierende Ausführungsbei- spiele der Erfindung setzen ein Vorhandensein von Middleware voraus . Bevorzugte auf Soft-MRP basierende Ausführungsbeispiele der Erfindung stellen also einen kostengünstigen Ersatz für herkömmliche auf MAC-Schicht implementierte MRP dar für alle Anwendungsgebiete in denen Middleware Lösungen wie DDS einge- setzt werden. In diesen Anwendungsgebieten ist die Reaktionszeit von Soft-MRP ausreichend, da Soft-MRP das Monitoring von DDS nutzt, skaliert die Reaktionszeit im Fehlerfall automatisch mit den Anforderungen eines konkreten Systems, da basierend auf diesen Anforderungen das Monitoring in DDS konfi- guriert wird.
Der Einsatz von Soft-MRP ist vorteilhaft für Anwendungsgebiete die kostensensitiv sind (SMART Produkte) und/oder nicht- echtzeit Anwendungen.
Bevorzugte Ausführungsbeispiele der Erfindung nutzen aus, dass Kommunikations-Middleware, wie z.B. DDS, andere Anforderungen an Kommunikationsnetze stellt wie z.B. eine mit heutiger Technologie realisierte Automatisierungsanwendung, aber zunehmend im gleichen Anwendungsgebiet (industrielle Anlagen) eingesetzt wird. Die bisherige Lösung (MRP auf Netzwerkebene) kann daher durch eine alternative, kostengünstigere Lösung (MRP auf Middleware-Ebene) für diese neuen Einsatzgebiete ersetzt werden.
Die Soft-MRP Lösung gemäss bevorzugten Ausführungsbeispielen der Erfindung stellt keinen allgemeingültigen Ersatz für die existierende Implementierung von MRP dar, da sie zum Einen nur für bestimmte Anwendungsfelder geeignet ist (bei denen DDS eingesetzt wird) und zum Anderen auch schlechtere Reaktionszeiten im Fehlerfall erreicht. Sind diese Reaktionszeiten tolerabel und ist das Anwendungsgebiet gegeben, können dafür jedoch deutliche Kosteneinsparungen bei den Netzwerkkomponenten erzielt werden.

Claims

Patentansprüche
1. Middleware (16), umfassend ein Redundanzprotokoll (17) welches auf Applikationsebene (18) in einem Netzwerkstack (19) implementiert ist.
2. Middleware (16) nach Anspruch 1, wobei das Redundanzprotokoll (17) eine Unterbrechungsfunktion (25) umfasst, welche ausgestaltet ist, eine logische Unterbrechung (15) einer Ringtopologie (12) eines Netzwerkes (1) zu veranlassen.
3. Middleware (16) nach Anspruch 2, wobei das Redundanzprotokoll (17) ausgestaltet ist, die logische Unterbrechung (15) aufzuheben, falls die Ringtopologie (12) zerstört wird.
4. Middleware (16) nach Anspruch 2 oder 3, wobei das Redundanzprotokoll (17) ausgestaltet ist, die logische Unterbrechung (15) der Ringtopologie (12) zu veranlassen, wenn eine Unterbrechung (15) im Ringnetzwerk (12) behoben wurde.
5. Middleware (16) nach einem der vorhergehenden Ansprüche, wobei das Redundanzprotokoll (17) ein Media Redundancy Proto- col (MRP) ist und/oder die Middleware (16) eine Implementierung des Data Distribution Standards umfasst.
6. Verfahren zum Sicherstellen einer Funktionsfähigkeit eines Netzwerkes (1), wobei das Netzwerk (1) eine Ringtopologie (12) umfasst, und wobei das Verfahren den Verfahrensschritt eines Überwachens der Ringtopologie (12) mittels eines Redundanzprotokolls (17) umfasst, wobei das Redundanzprotokoll (17) von einer Middleware (16) umfasst wird, und wobei das Redundanzprotokoll (17) auf Applikationsebene (18) in einem Netzwerkstack (19) implementiert wird.
7. Verfahren nach Anspruch 6, wobei die Middleware (16) von einem als Redundanzmanager (11) ausgestalteten Netzwerkknoten (11) der Ringtopologie (12) umfasst wird.
8. Verfahren nach einem der Ansprüche 6 oder 7, wobei das Redundanzprotokoll (17) eine Unterbrechungsfunktion (25) um- fasst, welche ausgestaltet ist, eine logische Unterbrechung (15) der Ringtopologie (12) zu veranlassen.
9. Verfahren nach Anspruch 8, wobei das Redundanzprotokoll (17) ausgestaltet ist, die logische Unterbrechung (15) aufzuheben, falls die Ringtopologie (12) zerstört wird.
10. Verfahren nach Anspruch 8 oder 9, wobei das Redundanzprotokoll (17) ausgestaltet ist, die logische Unterbrechung (15) der Ringtopologie (12) zu veranlassen, wenn eine Unterbrechung (21) der Ringtopologie (12) behoben wurde.
11. Verfahren nach einem der Ansprüche 6 bis 10, wobei das Redundanzprotokoll (17) ein Media Redundancy Protocol (MRP) ist und/oder die Middleware (16) eine Implementierung des Data Distribution Standards umfasst.
12. Verfahren nach einem der Ansprüche 6-11, wobei die Middleware in mindestens einem weiteren oder in mehreren oder in allen der Netzwerkknoten (11, IIa, IIb, 11c, lld) der Ringtopologie (12) mit dem Redundanzprotokoll (17) auf Applikati- onsebene (18) implementiert wird.
13. Netzwerk (1), umfassend mehrere Netzwerkknoten (11, IIa, IIb, 11c, lld) welche in einer Ringtopologie (12) angeordnet sind, wobei mindestens einer der Netzwerkknoten (11) eine Middleware (16) umfasst, und wobei die Middleware (16) ein Redundanzprotokoll (17) zum Sicherstellen einer Funktionsfähigkeit der Ringtopologie (12) umfasst, und wobei das Redundanzprotokoll (17) auf Applikationsebene (18) in einem Netz- werkstack (19) implementiert ist.
14. Netzwerk (1) nach Anspruch 13, wobei die Middleware (16) von einem als Redundanzmanager (11) ausgestalteten Netzwerkknoten (11) der Ringtopologie (12) umfasst ist.
15. Netzwerk (1) nach Anspruch 13 oder 14, wobei das Redundanzprotokoll (17) eine Unterbrechungsfunktion (25) umfasst, welche ausgestaltet ist, eine logische Unterbrechung (15) der Ringtopologie (12) zu veranlassen.
16. Netzwerk (1) nach Anspruch 15, wobei das Redundanzprotokoll (17) ausgestaltet ist, die logische Unterbrechung (15) aufzuheben, falls die Ringtopologie (12) zerstört wird.
17. Netzwerk (1) nach einem der Ansprüche 15 oder 16, wobei das Redundanzprotokoll (17) ausgestaltet ist, die logische Unterbrechung (15) der Ringtopologie (12) zu veranlassen, wenn eine Unterbrechung (21) der Ringtopologie (12) behoben wurde .
18. Netzwerk (1) nach einem der Ansprüche 13 bis 17, wobei das Redundanzprotokoll (17) ein Media Redundancy Protocol (MRP) ist und/oder die Middleware (16) eine Implementierung des Data Distribution Standards umfasst.
19. Netzwerk (1) nach einem der Ansprüche 13 bis 18, wobei mindestens ein weiterer der Netzwerkknoten (11, IIa, IIb, 11c, lld) der Ringtopologie (12) eine Implementation der Middleware (16) mit dem Redundanzprotokoll (17) auf Applikationsebene umfasst oder wobei mehrere oder alle der Netzwerk- knoten (11, IIa, IIb, 11c, lld) der Ringtopologie (12) jeweils eine Implementation der Middleware (16) mit dem Redundanzprotokoll (17) auf Applikationsebene umfassen.
EP14734779.3A 2013-07-31 2014-06-24 Soft-redundanzprotokoll Withdrawn EP2987280A1 (de)

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 (de) 2013-07-31 2014-06-24 Soft-redundanzprotokoll

Publications (1)

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

Family

ID=51062798

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14734779.3A Withdrawn EP2987280A1 (de) 2013-07-31 2014-06-24 Soft-redundanzprotokoll

Country Status (5)

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

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2849951T3 (es) 2015-06-18 2021-08-24 89Bio Ltd Derivados de piperidina 4-bencil y 4-benzoil sustituidos
PE20180572A1 (es) 2015-06-18 2018-04-04 Cephalon Inc Derivados de piperidina 1,4-sustituidos
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
AU2003228949A1 (en) * 2002-05-08 2003-11-11 Starrete Communications, Inc. System and method for providing video telephony over a cable access network infrastructure
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
EP2409458B1 (de) * 2009-03-18 2013-01-09 Hirschmann Automation and Control GmbH Parallelbetrieb von rstp (rapid spanning tree protocol) und mrp (media redundancy protocol) und segmentierung/kopplung
US8509618B2 (en) * 2009-05-06 2013-08-13 Ciena Corporation Photonic routing systems and methods for loop avoidance
WO2012100671A1 (zh) * 2011-01-30 2012-08-02 华为技术有限公司 一种绑定物理网口的方法、网卡及通信系统
DE102011004064A1 (de) * 2011-02-14 2012-08-16 Siemens Aktiengesellschaft Zwischennetzwerk in Ringtopologie und Verfahren zum Herstellen einer Netzwerkverbindung zwischen zwei Netzwerkdomänen
EP2536070A1 (de) * 2011-06-15 2012-12-19 BAE Systems Plc Datenübertragung
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 (de) * 2012-09-28 2017-08-02 Siemens Aktiengesellschaft Redundant betreibbares industrielles Kommunikationssystem, Kommunikationsgerät und Verfahren zum redundanten Betrieb eines industriellen Kommunikationssystems
EP2770760A1 (de) * 2013-02-25 2014-08-27 Sequans Communications S.A. eMBMS über LAN
US9264347B2 (en) * 2013-12-27 2016-02-16 Dell Products L.P. N-node virtual link trunking (VLT) systems control plane

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
US20160197766A1 (en) 2016-07-07
CN105432044A (zh) 2016-03-23
WO2015014543A1 (de) 2015-02-05

Similar Documents

Publication Publication Date Title
EP2343857B1 (de) Netzwerkknoten für ein Kommunikationsnetzwerk
DE60130285T2 (de) Reduntante Input/Output Management Einheit, insbesondere ein Wegewahlsystem
EP1297394B1 (de) Redundantes steuerungssystem sowie steuerrechner und peripherieeinheit für ein derartiges steuerungssystem
EP2838220A1 (de) Verfahren zur redundanten Nachrichtenübermittlung in einem industriellen Kommunikationsnetz und Kommunikationsgerät
WO2004021641A1 (de) Testverfahren für nachrichtenpfade in kommunikationsnetzen sowie netzelement
EP3753205B1 (de) Datenübertragung in zeitsensitiven datennetzen
WO2015014543A1 (de) Soft-redundanzprotokoll
DE102006004339A1 (de) Redundantes Kommunikationsnetzwerk
DE10305415B4 (de) Verfahren und Vorrichtung zum medienredundanten Betreiben eines Endgeräts in einem Netzwerk
DE102011086726A1 (de) Verfahren zur redundanten Kommunikation zwischen einem Nutzer-Terminal und einem Leitsystem-Server
DE60200692T2 (de) Wegeleitsystem zur Sicherstellung der Kontinuität der Interfacedienste zu den assoziierten Nachbarnetzen
EP1410577A1 (de) Netzwerkkomponente für ein optisches netzwerk mit notlauffunktion, insbesondere für ein optisches netzwerk in ringtopologie
DE102005003060A1 (de) Verfahren zur Handhabung von Unterbrechungen in einem Ethernet-Ring
EP1843929B1 (de) Leitsystem für die steuerung und/oder überwachung von objekten
EP1399818B1 (de) Verfahren und vorrichtung zur kommunikation in einem fehlertoleranten verteilten computersystem
EP3435179B1 (de) Verfahren zum gemäss einer sicherheitsnorm funktional sicheren austausch von informationen
EP2817923B1 (de) Rechnernetzwerk mit einer ringförmigen busverbindung
DE10131135B4 (de) Verfahren zum Betreiben eines Netzwerkknotens
DE10025283B4 (de) Vorrichtung zur dynamischen Verbindung von mindestens zwei Datenringzellen
EP1415452B1 (de) Kopplungsmittel für eine datenverarbeitungsvorrichtung
EP2290882B1 (de) Verfahren zur mehrfachen Fehlerredundanz in Netzwerken mit Ringtopologien
EP3739822A1 (de) Koppeln eines kommunikationsnetzwerks mit einem kommunikationsendgerät
WO1999018498A1 (de) Responsives system zur digitalen signalverarbeitung sowie verfahren zum betrieb eines responsiven systems
EP3236637B1 (de) Kommunikation über ein weitverkehrsnetz mittels eines applikationsspezifischen protokolls
WO1998045983A2 (de) Datenkommunikationsverbindung in hierarchischem kommunikationsnetz mit bus, mit einem abfrage/antwort-protokoll, dem sogenannten polling-protokoll, betrieben wird

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