WO2013135279A1 - Verfahren und vorrichtung zum übertragen von informationspaketen teilweise unter echtzeitbedingungen - Google Patents

Verfahren und vorrichtung zum übertragen von informationspaketen teilweise unter echtzeitbedingungen Download PDF

Info

Publication number
WO2013135279A1
WO2013135279A1 PCT/EP2012/054423 EP2012054423W WO2013135279A1 WO 2013135279 A1 WO2013135279 A1 WO 2013135279A1 EP 2012054423 W EP2012054423 W EP 2012054423W WO 2013135279 A1 WO2013135279 A1 WO 2013135279A1
Authority
WO
WIPO (PCT)
Prior art keywords
transmission
time
information
nrt1
data packets
Prior art date
Application number
PCT/EP2012/054423
Other languages
English (en)
French (fr)
Inventor
Sven Kerschbaum
Thomas Talanis
Frank Volkmann
Original Assignee
Siemens Aktiengesellschaft
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 Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to PCT/EP2012/054423 priority Critical patent/WO2013135279A1/de
Publication of WO2013135279A1 publication Critical patent/WO2013135279A1/de

Links

Classifications

    • 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/40—Bus networks
    • H04L12/40143—Bus networks involving priority mechanisms
    • H04L12/4015—Bus networks involving priority mechanisms by scheduling the transmission of messages at the communication node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/245—Traffic characterised by specific attributes, e.g. priority or QoS using preemption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • H04L47/365—Dynamic adaptation of the packet size
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic

Definitions

  • Automation systems include the Informationsübertra ⁇ supply now often commercial communication networks, for example based on Ethernet technology, according to the IEEE 802.3 standard. This is also required because the office and automation networks grow together for the purpose of CONSULTANT ⁇ mens wide information processing.
  • Enhancements in these standards include in particular switching technology (full-duplex), the CSMA / CD used to ⁇ ago (Carrier Sense Multiple Ac ⁇ cess / Collision Detection) method of Ethernet eliminates the need, as well as support a prioritization ,
  • Automation networks must therefore be in a position today to carry both time-critical data of the process-oriented levels of the required quality and non-time-critical data (for example ⁇ play Parametri für, diagnostic data) system at a moderate quality. Automation networks are thus becoming increasingly complex and difficult to plan.
  • Ethernet standard currently has no mechanisms to guarantee end-to-end latency.
  • Non-real-time critical data is also referred to as non-real-time data.
  • packets are standard compliant Ethernet packages.
  • Real-time data includes z.
  • process data is diagnostic data that belongs to non-real-time data.
  • Real-time and non-real-time packages basically differ:
  • the data that must be sent in the automation network under real-time conditions as real-time packets are usually very short and are frequently sent cyclically. In addition, they put a heavy demand on the end-to-end latency, which means that it must be ensured that the information contained in the data packets is received by the addressed recipient at a specific time.
  • Non-realtime packages have no requirement for real-time capability. These packages can he testify ⁇ in the network components of the automation network considerable waiting times for real-time packets. Because when the transmission of a non-realtime packet is taking place, incoming real-time packets must wait until the transmission of the non-realtime packet in the queue of the network element is completed. The length of the non-realtime packets thus directly influences the waiting time of the realtime packets in the network component. The requirement of the real-time packet to its end-to-end latency can no longer be met in the worst case, which then lead in the worst case to failure of the automation system.
  • Solution 1 Stop the transfer of the non-realtime package
  • FIG. 2 illustrates a first solution of the described problem.
  • the starting point is again that sichzu- next one non-real-time packet NRTL ⁇ will be in the queue and then a real-time packet is transmitted RT1 should.
  • the currently active and still ongoing over ⁇ transmission of non-real-time packet NRT1 is canceled.
  • the real-time packet RT1 is sent immediately thereafter, RT1 ', with a short latency At.
  • the abort is reported to the sender of the packet as a collision, Abort, which will then resend the packet, Retry NRT1.
  • the queues of the considered network element are empty at time t n -i. Further ⁇ no packet is transmitted at this time.
  • a non-prioritized packet arrives. This package can thus be transferred immediately.
  • an RT packet arrives at the time t n + i.
  • the transmission of the NRT packet is now aborted in order to forward the RT packet without delay.
  • the method requires no special hardware and also no coordination of successive network components. The disadvantage of the method is that it is not efficient, and in the worst case, it can lead to the non-real-time package not being able to be transmitted.
  • the automation technology is strongly influenced by deterministic behavior. This deterministic behavior is achieved, inter alia, by repetitive cycles. Real-time packets are therefore often transmitted cyclically, with a period cycle between the events.
  • the approach described has the disadvantage that, for example, in the case of an unfavorable cycle with short periods between the data packets, the repetition of the non-realtime packet, Retry NRT1, would be aborted again. In this case, the NRT1 non-realtime packet (and any other NRT2) would never be transferable.
  • the real-time package would "starve" the NRT package. This is sketched by way of example in FIG. Solution 2: Stop the transmission of the NRT packet
  • Time t n + i is currently the transmission of a non-realtime packet NRT1 active. Now an RT packet RT1 arrives for transmission. This now leads to the interruption of the currently active NRT packet transmission. The RT packet RT1 'is transmitted immediately. Subsequently, the transmission of the non-realtime packet NRT1 "which has already begun is continued. The package will not be repeated, that is transmitted from scratch, but fragmented advantage ⁇ .
  • This method is more efficient than Variant 1, but requires that the next network component recognize and correctly reassemble the interruption of the transmission, ie fragments NRT1 "and NRT1"'. Thus, all network components must support the process, which in turn represents a major disadvantage. Furthermore, the method requires a modification of the standard protocol stack.
  • the process should be Ethernet standard compliant.
  • the method for transmitting first information in the first data packets whose transmission time critical within a specified maximum period of time (also end-to-end latency) to be completed needs and second Informatio ⁇ nen in second data packets whose transmission is not time critical, and wherein the transfer of the second information interrupted as soon as the first transmission information has been received.
  • the transmission of the second information is resumed as soon as the transmission of the first time-critical information is completed.
  • Erfindungsge- measure is predetermined optimum packet size for the second Since ⁇ tenwovene and the second data packets that exceed the opti ⁇ male package size are always fragmented before transmission into smaller data packets of the predetermined packet size, so divided.
  • the inventive apparatus includes means for determining an optimal packet size for the second data packets, means for determining the size of the second data packets and means for fragmentation of the data packets into smaller packets when they pass in front of the ermit ⁇ Telte optimum packet size, and means for further transmission the information.
  • the data packets resulting from the fragmentation are advantageously compatible with the Ethernet standards IEEE 802.3 and can thus be transmitted without problems in the same transport network. For the recipient it is irrelevant leased whether the data packet originally had this packet size or was fragmented into that size before it was sent by the packet switch.
  • the optimum packet size of the non-real time packets can be determined prior ⁇ geous enough, depending on the maximum time duration (end-to-end latency, At) which may be delays the transmission of the first information and of other information via the transmission network, in particular the network topology , Equipment.
  • the determination of the maximum packet size can be done either by empirical determination or by calculation using the formulas of the Network Calculus.
  • the fragmentation of the non-realtime data packets can either take place in a network element used specifically for this purpose or in the switches present in the network.
  • FIG. 5 shows a flowchart according to the method according to the invention.
  • Figure 6 is a representation of the network consisting of automation ⁇ s mecanicsnetz and conventional communication network.
  • the maximum packet size for non-realtime packets is highly dependent on the demands of real-time data on their end-to-end latencies.
  • Le Boudec's Network Calculus can calculate end-to-end latencies for networks whose topology and data flows are known in the network.
  • the maximum allowable jourö ⁇ SSE can now be calculated for non-real-time packets, so that the influence of non-real-time packets of all real-time packets are tolerated on the end-to-end latency can.
  • “Tolerated” here means that for all real-time packets their desired end-to-end latency can be guaranteed, provided that non-realtime packets do not exceed a maximum packet length.
  • non-realtime packets Dismembering non-realtime packets. All non-real-time packets that exceed the configured (calculated, or empirically determined) maximum packet length are now fragmented, ie, a non-realtime packet NRT1 is divided into n smaller packets NRT1 ", NRT1", as well as shown in FIG. All n packages remain stan ⁇ dardkonform Ethernet standard.
  • the functionality of the "Zer Nursingeins" can both in a dedicated network device as well as existing network devices such. B. a switch to be implemented.
  • n smaller NRT packets (n> 0), each having a maximum configured packet length, are generated in a dedicated network component FRAG, and all (new and old) packets are compliant with today's IEEE Ethernet standard.
  • the transmission in the network via the switches Switch l ... n and PLC1, PLC2 takes place as usual.
  • the calculation of the packet size can be made in an offline planning ⁇ tool, and are transmitted by means of configuration to the network component. Furthermore, diagnostics data DIAG can be evaluated by a PC.
  • the waiting time of real-time packets, z. B. in a switch can be reduced to a minimum.
  • Latency for real-time data can thus be reduced. Nevertheless, non-real-time data can be transmitted successfully, albeit under conditions that are worse for them.
  • a device with this functionality is enough to convert non-realtime packets into smaller, more standard-compliant Ethernet packets. All other network devices are not affected and therefore do not need to support any other functionality.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Automatisierungsnetzwerke müssen heute also in der Lage sein, sowohl zeitkritische Daten der prozessnahen Ebenen in der notwendigen Qualität als auch nicht-zeitkritische Daten (beispielsweise Parametrierungdaten, Diagnosedaten) in angemessener Qualität zu übertragen. Automatisierungs-Netzwerke werden somit immer komplexer und schwieriger zu planen. Es wird daher nach einem Verfahren und einer Vorrichtung vorgeschlagen, bei dem vorab eine optimale Paketgröße für die Datenpakete zur Übermittlung von nicht-zeitkritischen Daten bestimmt, und diejenigen Datenpakete, die die optimale Paketgröße überschreiten, werden vor der Übertragung immer in kleinere Datenpakete der vorbestimmten Paketgröße fragmentiert, also aufgeteilt. So wird sichergestellt, dass die zeitkritischen Daten innerhalb ihrer Zeitanforderungen übermittelt werden und gleichzeitig eine Übertragung von nicht-zeitkritischen Daten nicht unterbrochen wird.

Description

Beschreibung / Description
Verfahren und Vorrichtung zum Übertragen von Informationspaketen teilweise unter EchtZeitbedingungen
Automatisierungssysteme beinhalten zur Informationsübertra¬ gung inzwischen häufig handelsübliche Kommunikationsnetze, beispielsweise basierend auf Ethernet Technologie, gemäß Standard IEEE 802.3. Dies wird auch dadurch gefordert, da die Büro- und Automatisierungsnetzwerke zum Zwecke der unterneh¬ mensweiten Informationsverarbeitung immer weiter zusammen wachsen .
Basis dieser Entwicklung bilden zum einen die fortschreitenden Möglichkeiten der Mikroelektronik (insbesondere die steigender Leistungsfähigkeit der zugrundeliegenden Hardware) , und zum anderen eine Reihe von Erweiterungen der relevanten IEEE 802 Standards rund um Ethernet, die den Einsatz zeitkritischer Datenübertragungen ermöglichen. Dies macht die Verwendung der genannten Technologie für den Einsatz in der Automatisierungstechnik erst möglich, da es hier etliche Anwendungsfälle gibt, die eine sogenannte Echtzeit-Kommunikation erforderlich machen.
Zu den Erweiterungen in den genannten Standards zählen insbesondere die Switching-Technologie ( Full-Duplex) , das das bis¬ her verwendete CSMA/CD (Carrier Sense Multiple Ac¬ cess/Collision Detection) Verfahren von Ethernet überflüssig macht, sowie die Unterstützung einer Priorisierung .
Dies bestätigt auch die Entwicklung und Verwendung zahlrei¬ cher industrieller Ethernet-Standards in den letzten Jahren, wie z. B. ProfiNET (Process Field Network), EtherNet/IP und EtherCAT (ein auf Ethernet basierender Feldbus), welche die Übertragung zeitkritischer, prozessnaher Daten als auch Daten in Standard TCP/IP und UDP/ IP-Datenformaten insbesondere auch in Echtzeit ermöglichen. Das für Automatisierungsnetzwerke wichtigste Dienstgütekrite¬ rium ist vor allem die Ende-zu-Ende-Latenzzeit , also die Zeit, die vergeht, von dem Versenden der Information an der Daten-Quelle bis zum Eintreffen der Daten an der Datensenke.
Automatisierungsnetzwerke müssen heute also in der Lage sein, sowohl zeitkritische Daten der prozessnahen Ebenen in der notwendigen Qualität als auch nicht-zeitkritische Daten (bei¬ spielsweise Parametrierungdaten, Diagnosedaten) in angemesse- ner Qualität zu übertragen. Automatisierungs-Netzwerke werden somit immer komplexer und schwieriger zu planen.
Der Ethernet-Standard kennt derzeit keine Mechanismen, um En- de-zu-Ende Latenzzeiten garantieren zu können.
Im Folgenden werden zeitkritische bzw. echtzeitkritische Da¬ ten auch als Realtime-Daten bezeichnet. Nichtechtzeitkritische Daten werden auch als Non-Real-Time Daten bezeichnet. Analog gilt diese Notation für Pakete. Non-Real- Time -Pakete sind standardkonforme Ethernet-Pakete . Zu den
Realtime -Daten zählen z. B. Prozessdaten, während Diagnosedaten zu den Non-Real-Time-Daten gehören.
Realtime- und Non-Realtime-Pakete unterscheiden sich prinzi- piell:
Die Daten, die im Automatisierungsnetz unter Echtzeitbedin- gungen als Realtime-Pakete verschickt werden müssen, sind meistens sehr kurz und werden häufig zyklisch versandt. Sie stellen darüber hinaus harte Anforderung an die Ende-zu-Ende Latenzzeit, das heisst, es muss sichergestellt sein, dass die in den Datenpaketen enthaltene Information zu einem bestimmten Zeitpunkt beim adressierten Empfänger eingeht.
Alle anderen Daten, die im Automatisierungsnetz als Non- Realtime-Pakete versendet werden, weisen hingegen meist kei¬ nen Zyklus auf, häufig handelt es sich auch um sehr große Da¬ tenpakete. Non-Realtime-Pakete haben also keine Anforderung an Echtzeitfähigkeit . Diese Pakete können in den Netzwerkkomponenten des Automatisierungsnetzes erhebliche Wartezeiten für Realtime-Pakete er¬ zeugen. Denn wenn gerade die Übertragung eines Non-Realtime- Pakets stattfindet, müssen eintreffende Realtime-Pakete bis zum Abschluss der Übertragung des Non-Realtime-Pakets in der Warteschlage des Netzelements warten. Die Länge der Non- Realtime-Pakete beeinflusst somit direkt die Wartezeit der Realtime-Pakete in der Netzkomponente. Die Anforderung des Realtime-Pakets an seine Ende-zu-Ende Latenzzeit kann im schlimmsten Fall nicht mehr eingehalten werden, was dann im schlimmsten Fall bis zum Ausfall der Automatisierungsanlage führen .
Das Problem besteht in jeder Netzkomponente, in dem Pakete weitergeleitet werden, wie z. B. in einem Switch und ist vereinfacht in der Figur 1 dargestellt.
Über einen Zeitraum (dargestellt durch den Zeitstrahl t) kommen verschiedene Datenpakete an einer Netzkomponente zur Übertragung an, Input. Das zuerst eingehende Non-Realtime Pa¬ ket NRT 1 wird auch zuerst übertragen, NRT" . Da es sich um eine größere Datenmenge handelt ist der Switch erst mal be¬ schäftigt. Das nächste Realtime-Datenpaket RT1 wartet in der Warteschlange der Netzkomponente und wird erst mit deutlicher Verzögerung At übertragen, so dass die geforderte Echtzeit Übertragung nicht eingehalten werden kann.
Stand der Technik
Verschiedene Lösungsansätze für das oben genannte Problem sind bereits bekannt, welche im Folgenden kurz beschrieben werden .
Lösung 1 : Abbruch der Übertragung des Non-Realtime-Pakets
Die Figur 2 illustriert eine erste Lösung des geschilderten Problems. Die Ausgangssituation ist wiederum, dass sichzu- nächst ein Non-Realtime-Paket NRtl in der Warteschlange be¬ findet und danach ein Realtime-Paket RT1 übertragen werden soll. Die gerade aktive und noch nicht abgeschlossene Über¬ tragung des Non-Realtime-Pakets NRT1 wird abgebrochen. Das Realtime-Paket RT1 wird unmittelbar danach versandt, RT1', mit kurzer Latenzzeit At. Der Abbruch wird dem Sender des Pa- kets als Kollision gemeldet, Abort, der das Paket daraufhin erneut senden wird, Retry NRT1. Die Warteschlagen des betrachteten Netzelements sind zum Zeitpunkt tn-i leer. Weiter¬ hin wird auch kein Paket zu diesem Zeitpunkt übertragen. Zum Zeitpunkt tn kommt ein nicht priorisiertes Paket an. Dieses Paket kann somit sofort übertragen werden. Während der Übertragung des NRT-Pakets trifft zum Zeitpunkt tn+i ein RT-Paket ein. Die Übertragung des NRT-Paketes wird nun abgebrochen, um das RT-Paket ohne Verzögerung weiterleiten zu können. Das Verfahren bedarf keiner speziellen Hardware und auch keiner Abstimmung aufeinander folgender Netzkomponenten. Der Nachteil der Methode ist, dass es nicht effizient ist, und es im schlimmsten Fall dazu führen kann dass das Non-Realtime- Paket gar nicht übertragen werden kann.
Die Automatisierungstechnik ist sehr stark von deterministischen Verhalten geprägt. Dieses deterministische Verhalten wird unter anderem durch Wiederholungs-Zyklen erreicht. Realtime-Pakete werden daher häufig zyklisch übertragen, mit ei- nem Zeitraum Zyklus zwischen den Ereignissen. Der beschriebene Lösungsansatz hat den Nachteil, dass beispielsweise bei einem ungünstigen Zyklus mit kurzen Zeiträumen zwischen den Datenpaketen die Wiederholung des Non-Realtime-Pakets, Retry NRT1, wieder abgebrochen werden würde. In diesem Fall würde das Non-Realtime-Paket NRT1 (und jedes weitere NRT2) nie übertragen werden können. Das Realtime-Paket würde das NRT- Paket "aushungern". Dies ist exemplarisch in Figur 3 skizziert . Lösung 2 : Unterbrechung der Übertragung des NRT-Paketes
Ein anderes Verfahren zur Umgehung des Problems besteht nun darin, dass die Übertragung des Non-Realtime Pakets NRT1 nicht mehr abgebrochen, sondern lediglich unterbrochen wird. Dies schließt das Risiko des gerade beschriebenen "Aushun- gerns" von Non-Realtime-Paketen wie im vorherigen Stand der Technik (Abbruch und vollständigen Wiederholung) aus. In Fi- gur 4 ist die Unterbrechung beispielhaft dargestellt. Zum
Zeitpunkt tn+i ist gerade die Übertragung eines Non-Realtime- Pakets NRT1 aktiv. Nun kommt ein RT-Paket RT1 zur Übertragung an. Dies führt nun zur Unterbrechung der gerade aktiven NRT- Paketübertragung . Das RT-Paket RT1' wird unmittelbar übertra- gen. Anschließend wird die bereits begonnene Übertragung des Non-realtime-Pakets NRT1'' fortgesetzt. Das Paket wird nicht wiederholt, also komplett neu übertragen, sondern fragmen¬ tiert . Dieses Verfahren ist effizienter als die Variante 1, erfordert aber, dass die nächste Netzkomponente die Unterbrechung der Übertragung, also die Fragmente NRT1'' und NRT1''', erkennt und wieder korrekt zusammensetzt. Somit müssen alle Netzkomponenten das Verfahren unterstützen, was wiederum ei- nen großen Nachteil darstellt. Weiterhin erfordert das Ver¬ fahren eine Modifikation des Standard-Protokollstacks.
Es ist nun Aufgabe der Erfindung, ein Verfahren und eine Vorrichtung bereit zu stellen, welche die beschriebenen Probleme löst. Das Verfahren soll dabei Ethernet Standard konform sein .
Beschreibung der Erfindung Die Aufgabe wird nun gelöst durch ein Verfahren gemäß den Merkmalen des Patentanspruchs 1.
Das Verfahren zur Übertragung von ersten Informationen in ersten Datenpaketen, deren Übertragung zeitkritisch innerhalb einer bestimmten maximalen Zeitdauer (auch Ende-zu-Ende Latenzzeit) abgeschlossen sein muss und von zweiten Informatio¬ nen in zweiten Datenpaketen, deren Übertragung nicht zeitkritisch ist, und bei dem die Übertragung der zweiten Informati- onen unterbrochen wird, sobald erste Informationen zur Übertragung vorliegen. Die Übertragung der zweiten Informationen wird wieder aufgenommen, sobald die Übertragung der ersten zeitkritischen Informationen abgeschlossen ist. Erfindungsge- maß wird vorab eine optimale Paketgröße für die zweiten Da¬ tenpakete bestimmt und die zweiten Datenpakete, die die opti¬ male Paketgröße überschreiten, werden vor der Übertragung immer in kleinere Datenpakete der vorbestimmten Paketgröße fragmentiert, also aufgeteilt.
Die Aufgabe wird weiterhin gelöst durch eine Vorrichtung ge¬ mäß den Merkmalen des Patentanspruchs 9.
Vorrichtung zur Übertragung von Informationen in einem Kommu- nikationsnetz , wobei die Informationen aus ersten Datenpaketen, deren Übertragung zeitkritisch innerhalb einer bestimmten maximalen Zeitdauer (Ende-zu-Ende Latenzzeit) abgeschlos¬ sen sein muss und aus zweiten Informationen in zweiten Datenpaketen, deren Übertragung nicht zeitkritisch ist, bestehen. Die Übertragung der zweiten Informationen wird unterbrochen, sobald erste Informationen zur Übertragung vorliegen, und die Übertragung der zweiten Informationen wird wieder aufgenommen, sobald die Übertragung der ersten zeitkritischen Informationen abgeschlossen ist. Die erfindungsgemäße Vorrichtung weist Mittel zur Bestimmung einer optimalen Paketgröße für die zweiten Datenpakete auf, Mittel zur Bestimmung der Größe der zweiten Datenpakete und Mittel zur Fragmentierung der Datenpakete in kleinere Datenpakete, wenn diese vor die ermit¬ telte optimale Paketgröße überschreiten, sowie Mittel zur weiteren Übermittlung der Informationen.
Vorteilhafte Aus führungs formen sind in den Unteransprüchen angegeben .
Die durch die Fragmentierung entstandenen Datenpakete sind vorteilhafterweise kompatibel zu den Ethernet-Standards IEEE 802.3 und können so problemlos im selben Transportnetz weiter übertragen werden. Für den Empfänger ist es dabei unerheb- lieh, ob das Datenpaket ursprünglich diese Paketgröße hatte oder erst vor dem Übermitteln vom Paket-Switch in diese Größe fragmentiert wurde.
Die optimale Paketgröße der Nicht-Echtzeit Pakete kann vor¬ teilhafterweise bestimmt werden abhängig von der maximalen Zeitdauer (Ende-zu-Ende Latenzzeit, At) , die die Übertragung der ersten Informationen verzögert werden darf und von weiteren Informationen über das Übertragungsnetz, insbesondere die Netztopologie, Geräte.
Die Bestimmung der maximalen Paketgröße kann dabei entweder durch empirische Ermittlung oder auch durch Berechnung mit Hilfe der Formeln des Network Calculus erfolgen.
Wichtig bei der Berechnung kann auch die Erkenntnis sein, dass die Übertragung der Realtime Datenpakete zyklisch in vorbekannten regelmäßigen Zeitabständen geschieht.
Die Fragmentierung der Non-Realtime Datenpakete kann entweder in einem eigens zu diesem Zweck eingesetzten Netzelement erfolgen oder in den im Netz vorhandenen Switches.
Ausführungsbeispiele
Im Weiteren werden Ausführungsbeispiele der Erfindung beschrieben. Dabei zeigen die Figuren:
Figuren 1 bis 4 verschiedene Formen des Standes der Technik, wie bereits in der Beschreibungseinleitung erläutert,
Figur 5 ein Ablaufdiagramm gemäß dem erfindungsgemäßen Verfahren und
Figur 6 eine Darstellung des Netzes bestehend aus Automati¬ sierungsnetz und herkömmlichem Kommunikationsnetz.
Unterschieden wird im Folgenden zwischen einer sogenannten „Engineering-Phase" und einer „Runtime-Phase" . Zunächst wer¬ den im Automatisierungssystem die Funktionalitäten der Anlage programmiert. Dies geschieht über ein sogenanntes Enginee- ring-System und offline. Es werden die Anforderungen identi¬ fiziert und die Schnittstellen definiert. Es wird auch fest¬ gelegt, welche Informationen über die Kommunikationsnetze verteilt werden müssen und welche Daten in Echtzeit zur Verfügung stehen müssen. Während der Laufzeit („Runtime") des Systems ist die (Automatisierungs- ) Anlage dann im Wirkbe¬ trieb. In der Runtime-Phase werden Non-Realtime Pakete „zer¬ stückelt", welche vorteilhafterweise konform zum IEEE Ether¬ net Standard sind. Die maximale Paketlänge von Non-Realtime- Paketen kann durch das Netzgerät, das die Erfindung implementiert, empirisch während der Laufzeit ermittelt werden. Eine Optimierung des Verfahrens kann dadurch erzielt werden, dass die maximale Paketlänge für Non-Realtime-Pakete bereits in der Engineering-Phase berechnet wird. Nachfolgend werden der mögliche Runtime- und Engineering-Anteil beschrieben:
In der Engineering-Phase: Berechnung der maximalen Paketlänge für Non-Realtime-Pakete
Die maximale Paketgröße für Non-Realtime-Pakete ist stark von den Anforderungen der Realtime-Daten an ihre Ende-zu-Ende- Latenzzeiten abhängig. Mit Hilfe eines Berechnungsverfahrens z. B. dem Network Calculus von Le Boudec können Ende-zu-Ende Latenzzeiten für Netze, deren Topologie und Datenflüsse im Netz bekannt sind, berechnet werden. Mit Hilfe des Berech¬ nungsverfahrens kann nun auch die maximal zulässige Paketgrö¬ ße für Non-Realtime-Pakete berechnet werden, so dass der Ein- fluss von Non-Realtime-Paketen auf die Ende-zu-Ende Latenzzeit aller Realtime-Pakete toleriert werden kann. "Toleriert" bedeutet hier, dass für alle Realtime-Pakete deren gewünschte Ende-zu-Ende Latenzzeit garantiert werden kann, sofern Non- Realtime-Pakete eine maximale Paketlänge nicht überschreiten. Die berechnete maximale Paketlänge für Non-Realtime-Pakete wird in dem Gerät, welches die Fragmentierung umsetzt, wäh¬ rend der Inbetriebnahme der Anlage konfiguriert.
In der Runtime (Laufzeit ) -Phase : Zerstückeln von Non- Realtime-Pakete . Alle Non-Realtime-Pakete, die die konfigurierte (berechnete, oder empirisch ermittelte) maximale Paketlänge überschreiten, werden nun fragmentiert, d. h. ein Non-Realtime-Paket NRT1 wird auf n kleinere Pakete NRT1 ' ' , NRT1 ' ' ' aufgeteilt, so wie in Figur 5 dargestellt. Alle n Pakete sind weiterhin stan¬ dardkonform zum Ethernet-Standard .
Die Funktionalität des "Zerstückeins" kann dabei sowohl in einem dedizierten Netzwerkgerät als auch vorhanden Netzwerkgeräten wie z. B. einem Switch umgesetzt werden.
Alle weiteren Netzwerkgeräte sowie die Endgeräte und die dar¬ auf laufenden Applikationen sind nicht betroffen und bekommen von dem Prozess des "Zerstückeins" einzelner Non- Realtime-Pakete nichts mit. Das Verfahren läuft also für die Empfängerseite transparent ab.
In Figur 6 ist das Verfahren der Erfindungsmeldung beispielhaft für den Übergang vom Office- ON in das Automatisierungs¬ netzwerk AN dargestellt.
Aus einem Non-Realtime-Paket werden n kleinere NRT-Pakete (n >0), welche jeweils eine maximale konfigurierte Paketlänge haben, in einer dedizierten Netzkomponente FRAG erzeugt und alle (neuen und alten) Pakete sind konform zu dem heute etab- Herten IEEE Ethernet Standard. Die Übermittlung im Netz über die Switche Switch l...n und PLC1, PLC2 erfolgt wie gehabt.
Die Berechnung der Paketgröße kann in einem Offline Planungs¬ tool erfolgen, und werden mittels Konfiguration an die Netz- komponente übermittelt werden. Weiterhin können Diagnosedaten DIAG durch einen PC ausgewertet.
Die Vorteile dieser Lösung ergeben sich dabei wie folgt:
Die Wartezeit von Realtime-Paketen, z. B. in einem Switch kann auf ein Minimum reduziert werden. Die Ende-zu-Ende-
Latenzzeit für Realtime-Daten kann somit reduziert werden. Non-Realtime-Daten können dennoch - wenn auch unter für sie verschlechterten Bedingungen - erfolgreich übertragen werden.
Es reicht ein Gerät mit dieser Funktionalität, um Non- Realtime-Pakete in n kleinere, weiterhin standardkonforme Ethernet-Pakete umzuwandeln. Alle anderen Netzwerkgeräte sind nicht betroffen und müssen somit keine weitere Funktionalität unterstützen .
Dies gilt insbesondere für die Endgeräte, die nicht verändert werden müssen. Die beschriebene Variante erzeugt auch keinen (markanten) Overhead, das Problem des "Aushungerns " kann hierbei nicht auftreten.
Es ergibt sich insgesamt eine bessere Ende-zu-Ende Latenzzeit für Non-Realtime-Daten.
Ein erhöhter Aufwand durch das Zerkleinern von Non-Realtime- Paketen (mehr Pakete, insgesamt mehr Daten durch Paketheader und Paketfooter) findet ausschließlich im Gerät, das die Erfindung implementiert, statt.

Claims

Verfahren zur Übertragung von ersten Informationen in ersten Datenpaketen (RT1), deren Übertragung zeitkritisch innerhalb einer bestimmten maximalen Zeitdauer (At) abgeschlossen sein muss und von zweiten Informationen in zweiten Datenpaketen (NRT1), deren Übertragung nicht zeitkritisch ist, und
bei dem die Übertragung der zweiten Informationen (NRT1) unterbrochen wird, sobald erste Informationen (RT1) zur Übertragung vorliegen, und
bei dem die Übertragung der zweiten Informationen (NRT1) wieder aufgenommen wird, sobald die Übertragung der ersten zeitkritischen Informationen abgeschlossen ist, dadurch gekennzeichnet, dass
vorab eine optimale Paketgröße für die zweiten Datenpake¬ te bestimmt wird und
die zweiten Datenpakete (NRT1), die die optimale Paket¬ größe überschreiten, vor der Übertragung immer in kleinere Datenpakete (NRT1 ' ' , NRT1 ' ' ' ) der vorbestimmten Paketgröße fragmentiert werden.
Verfahren zur Übertragung gemäß Patentanspruch 1, dadurch gekennzeichnet, dass
die Datenpakete (NRT1 ' ' , NRT1 ' ' ' ) kompatibel zu den Stan¬ dards IEEE 802.3 sind.
Verfahren zur Übertragung gemäß einem der vorherigen Patentansprüche,
dadurch gekennzeichnet, dass
die Paketgröße bestimmt wird abhängig von
- der maximalen Zeitdauer (At) , die die Übertragung der ersten Informationen verzögert werden darf und
- von weiteren Informationen über das Übertragungsnetz, insbesondere die Netztopologie .
Verfahren zur Übertragung gemäß Patentanspruch 4, dadurch gekennzeichnet, dass die Bestimmung der maximalen Paketgröße durch empirische Ermittlung erfolgt.
Verfahren zur Übertragung gemäß Patentanspruch 4, dadurch gekennzeichnet, dass
die Bestimmung der maximalen Paketgröße durch Berechnung mit Hilfe der Formeln des Network Calculus durchgeführt wird .
Verfahren zur Übertragung gemäß einem der vorherigen Patentansprüche,
dadurch gekennzeichnet, dass
die Übertragung der ersten Datenpakete zyklisch in bekannten regelmäßigen Zeitabständen geschieht.
Verfahren zur Übertragung gemäß einem der vorherigen Patentansprüche,
dadurch gekennzeichnet, dass
die Fragmentierung in einem eigens zu diesem Zweck eingesetzten Netzelement erfolgt.
Verfahren zur Übertragung gemäß einem der vorherigen Patentansprüche 1 bis 6,
dadurch gekennzeichnet, dass
die Fragmentierung in den im Netz vorhandenen Switches erfolgt .
Vorrichtung zur Übertragung von Informationen in einem Kommunikationsnetz, wobei die Informationen bestehen aus ersten Datenpaketen (RT1), deren Übertragung zeitkritisch innerhalb einer bestimmten maximalen Zeitdauer (At) abgeschlossen sein muss und aus zweiten Informationen in zweiten Datenpaketen (NRT1), deren Übertragung nicht zeitkritisch ist, und
wobei die Übertragung der zweiten Informationen (NRT1) unterbrochen wird, sobald erste Informationen (RT1) zur Übertragung vorliegen, und wobei die Übertragung der zweiten Informationen (NRT1) wieder aufgenommen wird, sobald die Übertragung der ersten zeitkritischen Informationen abgeschlossen ist, dadurch gekennzeichnet, dass
die Vorrichtung Mittel aufweist, zur Bestimmung einer optimalen Paketgröße für die zweiten Datenpakete (NRT1), und
die Vorrichtung Mittel aufweist, zur Bestimmung der Größe der zweiten Datenpakete (NRT1) und
Mittel zur Fragmentierung der Datenpakete, wenn diese vor die ermittelte optimale Paketgröße überschreiten, in kleinere Datenpakete (NRT1 ' ' , NRT1 ' ' ' )
und Mittel zur weiteren Übermittlung der Informationen.
10. Vorrichtung zur Übertragung gemäß Patentanspruch 9,
dadurch gekennzeichnet, dass
die Datenpakete (NRT1 ' ' , NRT1 ' ' ' ) kompatibel zu den Stan¬ dards IEEE 802.3. sind.
11. Vorrichtung zur Übertragung gemäß Patentanspruch 9 oder 10, dadurch gekennzeichnet, dass
zur Bestimmung der Paketgröße folgende Informationen berücksichtigt werden:
- der maximalen Zeitdauer (At) , die die Übertragung der ersten Informationen verzögert werden darf und
- von weiteren Informationen über das Übertragungsnetz, insbesondere die Netztopologie .
12. Vorrichtung zur Übertragung gemäß einem der Patentanspruch 9 bis 11, dadurch gekennzeichnet, dass
die Bestimmung der maximalen Paketgröße durch empirische Ermittlung erfolgt.
13. Vorrichtung zur Übertragung gemäß einem der Patentanspruch 9 bis 11, dadurch gekennzeichnet, dass
die Bestimmung der maximalen Paketgröße durch Berechnung mit Hilfe der Formeln des Network Calculus durchgeführt wird .
14. Vorrichtung zur Übertragung gemäß einem der Patentanspruch 9 bis 13, dadurch gekennzeichnet, dass
die Übertragung der ersten Datenpakete zyklisch in be- kannten regelmäßigen Zeitabständen erfolgt.
15. Vorrichtung zur Übertragung gemäß einem der Patentanspruch 9 bis 14, dadurch gekennzeichnet, dass
die Vorrichtung in einem Switch integriert ist.
PCT/EP2012/054423 2012-03-14 2012-03-14 Verfahren und vorrichtung zum übertragen von informationspaketen teilweise unter echtzeitbedingungen WO2013135279A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2012/054423 WO2013135279A1 (de) 2012-03-14 2012-03-14 Verfahren und vorrichtung zum übertragen von informationspaketen teilweise unter echtzeitbedingungen

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2012/054423 WO2013135279A1 (de) 2012-03-14 2012-03-14 Verfahren und vorrichtung zum übertragen von informationspaketen teilweise unter echtzeitbedingungen

Publications (1)

Publication Number Publication Date
WO2013135279A1 true WO2013135279A1 (de) 2013-09-19

Family

ID=45922665

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2012/054423 WO2013135279A1 (de) 2012-03-14 2012-03-14 Verfahren und vorrichtung zum übertragen von informationspaketen teilweise unter echtzeitbedingungen

Country Status (1)

Country Link
WO (1) WO2013135279A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995012265A1 (en) * 1993-10-26 1995-05-04 Northern Telecom Limited Digital telecommunication link for efficiently transporting mixed classes of packets
EP1734700A1 (de) * 2005-06-16 2006-12-20 Siemens Aktiengesellschaft Verfahren und Vorrichtung zur Echtzeit-Übertragung von Daten in einem Ethernet-Datennetz
WO2009089850A1 (de) * 2008-01-15 2009-07-23 Siemens Aktiengesellschaft Verfahren zum betreiben eines kommunikationsnetzes, switch und kommunikationsnetz

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995012265A1 (en) * 1993-10-26 1995-05-04 Northern Telecom Limited Digital telecommunication link for efficiently transporting mixed classes of packets
EP1734700A1 (de) * 2005-06-16 2006-12-20 Siemens Aktiengesellschaft Verfahren und Vorrichtung zur Echtzeit-Übertragung von Daten in einem Ethernet-Datennetz
WO2009089850A1 (de) * 2008-01-15 2009-07-23 Siemens Aktiengesellschaft Verfahren zum betreiben eines kommunikationsnetzes, switch und kommunikationsnetz

Similar Documents

Publication Publication Date Title
EP1554839B1 (de) Verfahren und knoten zur parallelen nutzung eines kommunikationsnetzwerkes für echtzeitanwendungen und nicht-echtzeitanwendungen
EP2466803B1 (de) Verfahren zur Datenübertragung in einem Automatisierungssystem unter Verwendung von Dynamic Frame Packing
EP1388238B1 (de) System und verfahren zur parallelen übertragung von echtzeitkritischen und nicht echtzeitkritischen daten über schaltbare datennetze, insbesondere ethernet
WO2016026783A1 (de) Verteilerknoten, automatisierungsnetz und verfahren zum übertragen von echtzeitrelevanten und nicht-echtzeitrelevanten datenpaketen
EP2538619B1 (de) Verfahren zur Übertragung von Datenpaketen
WO2019007516A1 (de) Verfahren zur performanten datenübertragung in einem datennetz mit teilweise echtzeit-anforderungen und vorrichtung zur durchführung des verfahrens
EP2137893B1 (de) Paketvermittlungsvorrichtung und lokales kommunikationsnetz mit einer solchen paketvermittlungsvorrichtung
EP3679691A1 (de) Datenübertragungsverfahren und kommunikationsnetzwerk
WO2011160696A1 (de) Priorisierte übertragung von datentelegrammen
DE102011015966B4 (de) Automatisierungssystem
EP4005163A1 (de) Übertragung von datenpaketen
EP1826646B1 (de) Verfahren, Knoten und Netzwerk zum zyklischen Versenden von Ethernet-Telegrammen
EP3632050A1 (de) Busumsetzer
DE102006021930B4 (de) Verfahren zur exklusiven Bevorzugung von Nachrichtentelegrammen
WO2013135279A1 (de) Verfahren und vorrichtung zum übertragen von informationspaketen teilweise unter echtzeitbedingungen
DE102017130167A1 (de) Verfahren zur Optimierung der Ausfallerkennung von Redundanz-Protokollen mit Testdatenpaketen
WO2021058254A1 (de) Datenübertragungsverfahren, segment-telegramm und automatisierungskommunikationsnetzwerk
EP1453252B1 (de) Übertragung von Daten in einem schaltbaren Datennetz
EP4070530B1 (de) Verfahren zum zyklischen übertragen von daten zwischen kommunikationsteilnehmern auf einem datenübertragungskanal und datenübertragungssystem
EP1371193B1 (de) Electronical switch and method for a communication interface with cut through buffer memory
DE102009021908B4 (de) Verfahren zur Übertragung von Daten
EP3518480A1 (de) Verfahren zur daten-kommunikation in einem ethernet-basierten, insbesondere industriellen netzwerk vorrichtung zur durchführung des verfahrens sowie computerprogramm und computerlesbares medium
WO2020020579A1 (de) Verfahren zur übermittlung zeitkritischer daten innerhalb eines kommunikationssystems für ein industrielles automatisierungssystem und kommunikationssystem

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12711373

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12711373

Country of ref document: EP

Kind code of ref document: A1