DE102020202226A1 - Verfahren sowie Übertragungssystem zur Übermittlung von Messdaten - Google Patents

Abstract

Das Verfahren und das Übertragungssystem (2) dienen zur weitgehenden Sicherstellung der vollständigen Übermittlung von Messdaten (S) von zumindest einem Sender (4) zu einem Empfänger (8), insbesondere in einer industriellen, synchronen Prozessdatenerfassung, wobei- von dem Sender (4) wiederholt Telegramme (6) an den Empfänger (8) übermittelt werden,- im Falle eines Ausbleibens eines auf Seiten des Empfängers (8) erwarteten Telegramms (6), der Empfänger (8) nach einer vorbestimmten Wartezeit (W) einen Anfragezyklus (Z) startet- der Empfänger (8) zur Durchführung des Anfragezyklus (Z) eine Wiederholungsanfrage (RR) an den Sender (4) übermittelt und einen vorgegebenen Anfragezeitraum (A) auf das erwartete Telegramm (6) wartet,- bei einem weiterem Ausbleiben des erwarteten Telegramms (6) nach Ablauf eines oder mehrerer Anfragezyklen (Z) über einen vorgegebenen Timeout (T) hinweg dies als ein Verlust des Telegramms (6) vermerkt wird.

Description

• Die Erfindung betrifft ein Verfahren sowie ein Übertragungssystem zur Übermittlung von Messdaten, von einem Sender zu einem Empfänger. Die Erfindung betrifft speziell ein derartiges Verfahren sowie Übertragungssystem im Rahmen einer industriellen, synchronen Prozessdatenerfassung. Das Übertragungssystem ist dabei insbesondere Teil eines Datenerfassungssystems, speziell eines industriellen Prozessdaten-Erfassungssystems.
• Bei industriellen Prozessdaten-Erfassungssystemen ist häufig eine zeitgleiche, synchrone Erfassung von Messdaten an verschiedenen Orten einer industriellen Anlage erforderlich. Eine derartige zeitgleiche, synchrone Messdatenerfassung erlaubt eine besonders genaue Überwachung des industriellen Prozesses. Durch eine entsprechende Messdatenauswertung der zeitlich synchron an unterschiedlichen charakteristischen Stellen der Anlage erfassten Daten lassen sich kausale Zusammenhänge zwischen verschiedenen Produktionsstufen ableiten und damit geeignete Maßnahmen beispielsweise zur Steigerung der Prozessqualität oder Prozessverfügbarkeit ableiten.
• Häufig kommt es dabei auf die zeitgleiche Erfassung und auch Übertragung von großen Datenmengen bei hohen Abtastraten an. Die Abtastrate, also die Zeitdauer zwischen zwei Messungen, liegt dabei beispielsweise zwischen 1 µs und 50ms. Die Datenerfassung, Datenaufbereitung und Datenübermittlung beispielsweise an eine zentrale Auswerteeinheit, muss daher innerhalb kürzester Zeit zuverlässig erfolgen.
• Die Übermittlung der Messdaten über ein Datennetz erfolgt mittels Datenübertragungsprotokollen in sogenannten Telegrammen, die auch als „Frame“ bezeichnet. Sofern vorliegend von „Protokollen“ gesprochen wird, so wird hierunter allgemein eine Vereinbarung oder ein Regelwerk verstanden, welches Regeln und Anforderungen / Formate für die Kommunikation zwischen den Teilnehmern in einem Netzwerk festlegt. Über das Protokoll ist daher insbesondere ein Regelwerk für den Aufbau der Telegramme vorgegeben. Solche Telegramme stellen insofern Datenpakete dar mit einer definierten Struktur und einem definierten Aufbau. Typischerweise enthalten derartige Telegramme einen Header mit Informationen z.B. über Absender, Empfänger sowie zumindest einen Datensatz, in dem Nutzdaten (speziell die Messdaten) enthalten sind.
• Die Übermittlung der Messdaten und damit der Telegramme erfolgt dabei typischerweise fortlaufend und kontinuierlich im Rahmen der vorgegebenen Abtastrate zwischen einem Sender und einem Empfänger. Bei dem Sender handelt es sich dabei typischerweise um eine Erfassungseinheit, über die die einzelnen Messdaten erfasst und für die Übermittlung an den Empfänger, beispielsweise eine Auswerteeinheit, aufbereitet werden.
• Für die Auswertung auf Seiten des Empfängers wird eine vollständige Übermittlung der Daten angestrebt. Zum Teil können Datenverluste z.B. aufgrund einer kurzzeitigen Unterbrechung der Datenverbindung auftreten. Zur Überprüfung, ob die vom Sender zum Empfänger gesendeten Telegramme auch tatsächlich angekommen sind, besteht die Möglichkeit, dass der Empfänger nach Empfang eines entsprechenden Telegramms eine Bestätigung an den Sender zurücksendet. Hierdurch wird jedoch der Datenverkehr innerhalb des Datennetzes weiter erhöht.
• Ausgehend hiervon liegt der Erfindung die Aufgabe zugrunde, ein Verfahren sowie ein Übertragungssystem zur Übermittlung von Messdaten, insbesondere im Rahmen eines industriellen synchronen Prozessdaten- Erfassungssystems vorzusehen, bei dem mit geringem Aufwand eine vollständige Übertragung zumindest weitgehend sichergestellt ist.
• Die Aufgabe wird gemäß der Erfindung gelöst durch ein Verfahren mit den Merkmalen des Anspruchs 1 sowie durch ein Übertragungssystem mit den Merkmalen des Anspruchs 16. Das Übertragungssystem dient zur Durchführung des Verfahrens. Die im Hinblick auf das Verfahren angeführten Vorteile und bevorzugten Ausgestaltungen sind insofern auf das Übertragungssystem zu übertragen.
• Das Verfahren dient zur Übermittlung von Messdaten von zumindest einem Sender zu einem Empfänger. Bei dem Sender handelt es sich speziell um eine Erfassungseinheit zur Erfassung und Übermittlung der Messdaten. Die Erfassungseinheit erhält dabei üblicherweise über entsprechende Eingänge die Messdaten von einem unmittelbar angeschlossenen Messgerät oder sonstigem Gerät. Alternativ handelt es sich bei der Erfassungseinheit um ein Messgerät. Bei dem Empfänger handelt es sich insbesondere um eine Auswerteeinheit zur zentralen (Prozess- )Datenerfassung zur Verarbeitung der verteilt über verschiedene Erfassungseinheiten zeitgleich erfassten Messdaten. Von dem Sender wird dabei wiederholt, speziell im Rahmen einer vorgegebenen Abtastrate von beispielsweise 1ms oder darunter jeweils ein Telegramm an den Empfänger übermittelt. Durch die Abtastrate sind insofern auch unterschiedliche, aufeinanderfolgende Messzeitpunkte für die Messdaten vorgegeben. Die Abtastrate liegt vorzugsweise deutlich unter 1ms und beispielsweise unter 100µs oder unter 10µs und beispielsweise bei 1µs.
• Typischerweise ist das hier interessierende Prozessdaten-Erfassungssystem zur synchronen Erfassung von mehreren tausend Messdaten, z.B. bis zu 10.000 Messdaten über mehrere örtlich verteilt angeordnete Erfassungseinheiten sowie zu deren Übermittlung an eine zentrale Auswerteeinheit ausgebildet.
• Die Telegramme erhalten jeweils zumindest einen Datensatz sowie einen Header. Der Header enthält Informationen über den Datensatz, speziell Informationen über den Sender, den Empfänger, einen Zeitstempel, welcher den Zeitpunkt der Datenerfassung, also den Messzeitpunkt charakterisiert und weitere Informationen. In dem zumindest einen Datensatz des Telegramms sind insbesondere auch die Messdaten enthalten. Je nach Telegrammtyp können ein oder mehrere Datensätze enthalten sein, die jeweils auch als „Image“ bezeichnet werden. Enthält ein Telegramm mehrere Datensätze, so weisen diese unterschiedlichen Datensätze unterschiedliche Messdaten auf, die zu unterschiedlichen Messzeitpunkten erfasst sind. Der letzte Messzeitpunkt bestimmt dabei den Zeitpunkt, zu dem das Telegramm abgesendet wird. Die Anzahl der im Telegramm enthaltenen Datensätze ist konfigurierbar oder zumindest durch eine Konfiguration des Systems dem Sender sowie dem Empfänger bekannt. Durch die (bekannte) Anzahl der Datensätze und der (bekannten) Abtastrate ist daher eine typische Zeitspanne zwischen zwei Sendevorgängen bekannt.
• Im Falle eines Ausbleibens eines auf Seiten des Empfängers erwarteten Telegramms, welches Messdaten zu einem definierten Messzeitpunkt enthält, startet der Empfänger nach einer vorbestimmten, definierten Wartezeit einen Anfragezyklus. Hierzu sendet der Empfänger eine Wiederholungsanfrage („request for repeat“) an den Sender und wartet erneut für einen vorgegebenen Anfragezeitraum („wait for frame“) auf das erwartete Telegramm, welches nicht empfangen wurde. Wird auch nach Ablauf zumindest des einen Anfragezyklusses und vorzugsweise von mehreren Anfragezyklen, und zwar über einen definierten als „Timeout“ bezeichneten Zeitintervall hinweg, das erwartete Telegramm nicht erhalten, so wird dies als ein Verlust des Telegramms vermerkt. Der Empfänger wird in diesem Fall bei der Datenauswertung berücksichtigen, dass ein Telegramm und damit Datensätze fehlen.
• Diese Ausgestaltung beruht dabei auf der Überlegung, dass aufgrund der kontinuierlichen Messdatenerfassung und dem kontinuierlichen Übermitteln von individuell unterscheidbaren Datensätzen und damit auch individuell unterscheidbaren Telegrammen der Empfänger von sich aus in der Lage ist, zu identifizieren, ob die Übertragung vollständig ist oder ob ein Telegramm nicht übermittelt wurde.
• Durch die vom Empfänger aus initiierten Abfragezyklen wird dabei zumindest weitgehen sichergestellt, dass ein jeweiliges, beispielsweise durch eine kurzzeitige Unterbrechung der Datenübermittlung nicht übermittelte Telegramm, doch noch übermittelt wird. Lediglich im Falle, dass selbst nach Durchlauf von mehreren, beispielsweise 2 bis 20 und vorzugsweise 3, 4 oder 5 Abfragezyklen kein Telegramm angekommen ist, wird ein Datenverlust identifiziert.
• Weiterhin beruht diese Ausgestaltung auf der Überlegung, dass durch diese Maßnahme das Abgeben einer Empfangsbestätigung beispielsweise im Rahmen eines Bestätigungs-Telegramms oder einer sonstigen Antwort vom Empfänger an den Sender nicht erforderlich ist. Entsprechend wird vorzugsweise auch auf eine Empfangsbestätigung durch den Empfänger verzichtet. Dadurch wird die Belastung des Datennetzes und der Datenverkehr reduziert.
• Die Wartezeit ist dabei zweckdienlicherweise bestimmt durch die Summe aus einem typischen Zeitbedarf für das Senden der Messdaten, einer zu erwartenden Signallaufzeit für die Übertragung des Telegramms vom Sender zum Empfänger sowie optional einer Toleranzzeit. Der typische Zeitbedarf für das Senden bestimmt sich üblicherweise aus der erforderlichen Zeitdauer für die Aufbereitung der erhaltenen Messdaten für das Senden inkl. der Erstellung des Telegramms beispielsweise mit Header-Informationen. Die zu erwartende Signallaufzeit ergibt sich aus den gewählten Übertragungsmitteln (optisch, elektrisch) und den entsprechenden Signalwegen. Ergänzend beinhaltet diese zu erwartende Signalzeit vorzugsweise noch einen Puffer, der einer üblichen Varianz der Laufzeit, dem sogenannten „Jitter“ entspricht. Die Toleranzzeit berücksichtigt insbesondere noch eine gewisse Verarbeitungszeit auf Seiten des Empfängers. Die Toleranzzeit liegt vorzugsweise maximal in der Größe des typischen Zeitbedarfs für das Senden zuzüglich der zu erwartenden Signallaufzeit.
• Die Wartezeit liegt bei den hier betrachteten Systemen vorzugsweise im einstelligen Millisekundenbereich und speziell unter fünf oder unter zwei Millisekunden, und vorzugsweise unterhalb einer Millisekunde und insbesondere kleiner 0,5ms bis beispielsweise 100µs.
• Der Startzeitpunkt für die Wartezeit bestimmt sich insbesondere durch den Messzeitpunkt, welcher beispielsweise durch einen Zeitstempel, beispielsweise durch den im Header enthaltenen Zeitstempel definiert ist. Enthält das Telegramm mehrere Datensätze, so wird bestimmt sich der Startzeitpunkt durch den Messzeitpunkt des letzten Datensatzes (letzte Messung).
• Der Sender und der Empfänger sind allgemein zeitsynchron. Da die Zeitspanne zwischen zwei Telegrammen und damit zwischen zwei Sendezeitpunkten dem Empfänger bekannt ist, ist der Empfänger in der Lage, einen Soll-Empfangszeitpunkt für jedes Telegramm zu bestimmen und auszurechnen. Hierbei werden insbesondere relevante Einflussfaktoren, wie z.B. Laufzeit des Signals, Jitter etc. berücksichtigt.
• Zur Bestimmung des Empfangszeitpunktes und damit auch der Wartezeit ist weiterhin vorzugsweise eine Referenz zwischen einem Zeitstempel und einem Identifikator des Telegramms, z.B. eine laufende Telegrammnummer (laufender Zählwert des Telegramms) festgelegt. Die Referenz ist beispielsweise ein definiertes Telegramm, beispielsweise das zuerst oder auch das zuletzt erhaltene Telegramm. Der Zeitstempel ist dabei insbesondere der im Header hinterlegte Zeitstempel, welcher im Wesentlichen den Sendezeitpunkt definiert. Alternativ wird ein Empfangszeitstempel verwendet.
• Als Startzeitpunkt für die Bemessung der Wartezeit wird also beispielsweise ein Messzeitpunkt (Zeitstempel) eines zuletzt erhaltenen Telegrams zuzüglich der typischen Zeitspanne zwischen zwei Telegrammen gewählt. Diese Zeitspanne wird durch die Anzahl der Datensätze sowie durch die vorgegebene Abtastrate bestimmt.
• Der Anfragezeitraum (wait for repeat) bestimmt sich vorzugsweise wiederum aus der zu erwartenden Signallaufzeit der Wiederholungsanfrage, inkl. Jitter, der zu erwartenden Signallaufzeit für die Übertragung des Telegramms vom Sender zum Empfänger, insbesondere inkl. des Jitters und aus einer zu erwartenden Bearbeitungszeit für die Wiederholungsanfrage und Senden des Telegramms auf Seiten des Senders sowie wiederum optional der zuvor bereits erwähnten Toleranzzeit.
• Bei dem hier betrachteten System liegt der Anfragezeitraum typischerweise ebenfalls im einstelligen Millisekundenbereich und <5 ms. Speziell liegt der Anfragezeitraum bei unter 1ms. Der Anfragezeitraum ist dabei typischerweise größer als die anfängliche Wartezeit, beispielsweise zumindest um den Faktor 1,5 oder um den Faktor 2 größer.
• Die Wartezeit zuzüglich des mit der Anzahl der vorgegebenen Anfragezyklen multiplizierten Anfragezeitraums definiert den vorgegebenen Timeout, also die maximal zulässige Zeit, die verstreichen darf. Auslösendes Zeitmoment ist dabei wie zuvor beschrieben insbesondere der (vom Empfänger ermittelte, erwartete) Messzeitpunkt, zu dem die Messdaten des erwarteten Telegramms vom Sender erfasst wurden.
• Wie bereits erwähnt, weist der Header eines jeweiligen Telegramms insbesondere einen Identifikator, vorzugsweise einen Zähler auf und die Telegramme, zumindest die Datensätze sind mit einem laufenden Zählwert, beispielsweise einer laufenden Nummer gekennzeichnet. Der Empfänger stellt dabei anhand eines fehlenden Zählwerts das Ausbleiben eines Telegramms fest.
• Aufeinanderfolgende Telegramme und vorzugsweise auch die Datensätze (Messdaten) innerhalb der Telegramme werden mit einem laufenden Zählwert versehen, sodass bei Ausbleiben eines Telegramms mit einem vorgegebenen Zählwert der Empfänger sofort erkennt, dass ein Telegramm nicht übermittelt wurde. Hat der Empfänger beispielsweise die Telegramme mit den Zählwerten 1, 3, 4, 5, 6 erhalten, so erkennt er, dass das Telegramm mit dem Zählwert 2 fehlt und wird eine entsprechende Wiederholungsanfrage an den Sender abgeben.
• Für diesen Zählwert ist innerhalb des Headers eine definierte Datengröße beispielsweise von 8, 16 und insbesondere von 24 Bit reserviert. Die dadurch definierte Anzahl von unterscheidbaren Zählwerten ist daher begrenzt und wird zyklisch wiederholt. Bei dem Zählwert handelt es sich insbesondere um einen Nummerierungswert. Der für den Zählwert verwendete Zahlenraum ist durch die Bit-Größe des (Daten-)Zählers von beispielsweise 24 Bit begrenzt.
• In bevorzugter Weiterbildung speichert der Sender ein jeweiliges Telegramm nach dem Senden für einen vorgegebenen Zeitraum in einem dafür ausgebildeten Zwischenspeicher ab. Grundsätzlich wird jedoch nur eine begrenzte Anzahl von Telegrammen gespeichert. Durch diese Zwischenspeicherung wird sichergestellt, dass der Sender auf eine Wiederholungsanfrage das entsprechende Telegramm nochmals übermitteln kann.
• Innerhalb des Zwischenspeichers wird vorzugsweise eine dem Timeout entsprechende Anzahl an Telegrammen gespeichert. Durch den Timeout ist insgesamt eine vorgegebene maximale Wartezeit definiert, innerhalb derer der Empfänger den Empfang eines jeweiligen Telegramms erwartet. Sämtliche Telegramme, die also während der durch den Timeout definierten Zeitdauer erfasst werden (können), sind im Speicher zwischengespeichert. Die Anzahl ergibt sich insbesondere durch den Timeout dividiert durch die Zeitspanne zwischen zwei Messzeitpunkten, welche durch die Abtastrate Vorliegend liegt die Anzahl der zwischengespeicherten Telegramme im Bereich von 2 bis 8000 Der Timeout liegt dabei insbesondere in einem Bereich bis 2s. Die typische Zeitspanne zwischen zwei Messzeitpunkten und damit auch zwischen dem Versenden zweier aufeinander folgender Telegramme liegt im Bereich von 10µs bis 50ms
• In zweckdienlicher Ausgestaltung enthält die Wiederholungsanfrage Angaben zur Identifizierung des erwarteten Telegramms, insbesondere enthält die Wiederholungsanfrage den Zählwert des erwarteten Telegramms. Auf diese Weise kann der Sender zielgerichtet das erwartete Telegramm erneut aus dem Zwischenspeicher auslesen und versenden.
• In bevorzugter Ausgestaltung bezieht sich die Wiederholungsanfrage entweder auf das erwartete Telegramm, also lediglich auf das erwartete Telegramm oder alternativ auf eine Gruppe von Telegrammen. Speziell umfasst die Gruppe das erwartete Telegramm und hierzu mehrere (z.B. 2-32) beispielsweise benachbarte Telegramme, die also einen zum Zählwert des erwarteten Telegramms angrenzenden Zählwert aufweisen. In der Wiederholungsanfrage werden alternativ auch mehrere Telegramme mit unterschiedlichen, nicht fortlaufenden Zählwerten aufgenommen.
• In zweckdienlicher Weiterbildung weist der Empfänger weiterhin einen Filter auf, welcher anhand des Zählers solche Telegramme ausfiltert, die bereits empfangen wurden und/oder die zeitlich nicht erwartet werden. Speziell werden dabei Telegramme ausgefiltert, die außerhalb eines durch den Timeout bestimmten (dem Timeout entsprechenden) Zeitfensters liegen. Aufgrund des Timeouts ist daher jeweils nur ein begrenzter Zählwertbereich überhaupt für den Empfang durch den Filter zugelassen. Allgemein ist dabei der Timeout vorzugsweise geringer, insbesondere deutlich geringer als die Zeitdauer, die für einen Zählwert-Zyklus benötigt wird, d.h. also die Zeitdauer, die benötigt wird für die Telegramme vom minimalen Zählwert bis zum maximalen Zählwert des sich periodisch wiederholenden Zählwerbereichs. Damit ist immer ein eindeutiger Zählwertbereich vorgegeben, innerhalb dessen ein jeder Zählwert nur einmal vorkommen kann. Da sich der Timeout bestimmt von einem laufenden Messzeitpunkt, verschiebt sich daher der zulässige Zählwertbereich dynamisch. Es handelt sich insofern um einen fließenden Zählwertbereich, anhand dessen der Empfänger die Telegramme zulässt bzw. ausfiltert.
• Wie bereits eingangs erläutert, bestehen für die hier im Vordergrund stehende synchrone Prozessdatenerfassung über örtlich verteilte Erfassungseinheiten hohe Anforderungen sowohl im Hinblick auf die eingesetzte Hardware als auch im Hinblick auf die eingesetzte Software. Eine hohe Leistung (high performance, HP), insbesondere eine hohe Datenübertragungsrate insbesondere von größer 0,5 Gbit oder 1 GBit kann dabei nur mit qualitativ hochwertigen Komponenten erreicht werden. Häufig ist daher eine Kenntnis über die innerhalb des Übertragungssystems eingesetzten Komponenten erforderlich, um deren Güte und Qualität abschätzen zu können, um beispielsweise entsprechende Einstellungen für die Datenübermittlung oder auch Datenerfassung, wie beispielsweise maximal mögliche Abtastraten oder Datenraten einstellen zu können.
• Hierzu ist es grundsätzlich eine sogenannten Nachbarschaftserkennung bekannt. Eine solche wird herkömmlich im Rahmen eines sogenannten „discovery protocols“ durchgeführt. Bekannte Standard-Protokolle zur Identifizierung von Komponenten, auch als Nachbarn bezeichnet, sind speziell das LLDP-Protokoll („Link-Layer-Discovery-Protocoll). Daneben sind auch proprietäre Protokolle, wie beispielsweise das Cisco-Discovery Protocoll, CDP, bekannt.
• Derartige Standard-Protokolle dienen dazu, dass eine jeweilige Komponente in periodischen Abständen Informationen über sich selbst versendet und parallele Informationen von Nachbargeräten empfängt und diese Informationen speichert, die dann beispielsweise über ein entsprechendes Verwaltungsprotokoll ausgelesen werden können, sodass insgesamt Informationen über die im Netzwerk enthaltenen Komponenten zusammengestellt werden können.
• Allerdings eignet sich das LLDP-Protokoll nur bedingt, um eine vollständig verlässliche Aussage über die verwendeten Komponenten zu erhalten. Dies ist beispielsweise darin begründet, dass ältere Komponenten, beispielsweise Switches oder Hubs, welche für geringere Datenübertragung ausgebildet sind, das LLDP-Protokoll nicht unterstützen und es daher an alle Ports durchreichen. Hierdurch können mehrere Antworten auf eine Anfrage auftreten, sodass keine eindeutige Zuordnung möglich ist. Zudem wird die Belastung der Netzwerke durch derartige sogenannte Multicast-Telegramme erhöht.
• Ausgehend hiervon liegt einem weiteren Aspekt der Erfindung die Aufgabe zugrunde, innerhalb eines (Daten-)Übertragungssystems mit mehreren an der Übermittlung beteiligten Komponenten eine Überprüfung, speziell eine Nachbarschaftserkennung durchzuführen, ob es sich bei den beteiligten Komponenten um spezielle, nachfolgend als proprietäre bezeichnete Komponenten handelt, die insbesondere einen vordefinierten Qualitätsstandard, beispielsweise im Hinblick auf Übertragungsraten und insbesondere auch im Hinblick auf eine Priorisierung von zu übertragenden oder weiterzuleitenden Telegrammen sicherstellen.
• Diese Aufgabe wird gelöst durch ein Verfahren mit dem Merkmal des Anspruchs 12, welches vorzugsweise ergänzend zu dem zuvor beschriebenen Verfahren oder auch alternativ hierzu, also unabhängig von dem zuvor beschriebenen Verfahren eingesetzt wird. Das Verfahren dient wiederum zur Übermittlung von Messdaten speziell in einem Prozessdaten-Erfassungssystem mit synchroner Messdatenerfassung. Es baut auf einem Datennetz auf, in dem mehrere Netzwerkkomponenten, wie beispielsweise Sender, Empfänger, Switches usw. enthalten sind. Zur Überprüfung, ob es sich bei diesen beteiligten Komponenten um proprietäre Komponenten mit dem gewünschten High Performance-Standard handelt, ist erfindungsgemäß ein Erkennungs-Telegramm, vorgesehen, welches zwischen den Komponenten versendet wird. Das Erkennungs-Telegramm ist dabei jedoch - gemäß einem für die Datenübertragung verwendeten/vereinbarten Standard-Übertragungsprotokoll, vorliegend insbesondere ein Ethernet-Protokoll - bewusst als ein ungültiges Telegramm ausgebildet, welches lediglich von proprietären Komponenten akzeptiert und verarbeitet wird.
• Unter ungültiges Protokoll wird hierbei insbesondere ein Protokoll verstanden, welches nicht den allgemein vereinbarten Regeln (z.B. im Rahmen eines Ethernet-Protokolls) entspricht und von einem solchen Ethernet-Protokoll definiert abweicht. Hierdurch wird erreicht, dass das Telegramm von herkömmlichen Komponenten, die ein Telegramm gemäß dem Ethernet Protokolle ausgelegt sind, als nicht gültig verworfen wird.
• Bei dem Erkennungs-Telegramm handelt es sich insofern insbesondere um ein modifiziertes Telegramm gemäß einem Standard-Protokoll, insbesondere Ethernet-Protokoll. Bei dem für die Datenübertragung zu Grunde liegenden Protokoll handelt es sich daher um ein modifiziertes Standard-Protokoll, speziell ein Ethernet-Protokell. Das Telegramm wird daher für die nicht proprietären Komponenten vorzugsweise lediglich durch eine Modifikation, also eine zusätzliche, lediglich den proprietären Komponenten bekannte Maßnahme „ungültig“ gemacht. Hierunter wird insbesondere eine definierte Abwandlung der Datenstruktur oder einzelner Datenbestandteile gemäß dem Standard-Protokoll verstanden, also speziell eine definierte Abwandlung des Aufbaus oder der Protokoll-Regeln für das Telegramms (Frame). Die proprietären Komponenten erkennen dieses modifizierte Standard-Telegramm, so dass durch diese proprietären Komponenten eine übliche Nachbarschafts-Erkennungsroutine durchgeführt wird.
• Durch das „ungültige“ Telegramm wird erreicht, dass dieses von herkömmlichen, nicht proprietären Komponenten nicht erkannt, zumindest nicht als zulässig erkannt wird und daher auch nicht weiter verarbeitet wird. Hierdurch wird also insbesondere vermieden, dass ein derartiges Telegramm beispielsweise von dem zuvor erwähnten älteren Switches/Hubs an alle Ports durchgereicht wird.
• Allgemein ist im Rahmen der Nachbarschaftserkennung vorgesehen, dass eine jeweilige Komponente derartige Erkennungs-Telegramme wiederkehrend versenden. Empfängt eine benachbarte Komponente ein solches Erkennungs-Telegramm, so sendet diese benachbarte Komponente ein Antworttelegramm zurück. Eine jeweilige Komponente erhält dadurch also Informationen, ob es sich bei seinen Nachbarn um proprietäre Komponenten handelt. Ein Ausbleiben eines Antworttelegramms auf ein Erkennungstelegramm ist ein Indiz dafür, dass die benachbarte Komponente keine proprietäre HP-Komponente ist.
• In bevorzugter Ausgestaltung verwendet das Erkennungs-Protokoll eine modifizierte Prüfsumme, die dazu führt, dass das Protokoll von den nicht-proprietären Komponenten als ungültig angesehen wird. D.h. das Erkennungs-Protokoll weicht vorzugsweise nur im Hinblick auf die Regeln zur Erstellung der Prüfsumme von dem zu Grunde liegenden Standard-Protokoll ab. Der Ermittlung der Prüfsumme liegt jeweils ein allgemein vorgegebener Algorithmus zugrunde. Dieser Algorithmus ist daher modifiziert.
• Zur Erstellung der modifizierten Prüfsumme wird in bevorzugter Ausgestaltung zunächst eine Standard-Prüfsumme gemäß einem vorgegebenen Standard, beispielsweise gemäß dem Ethernet Protokoll ermittelt. Anschließend wird diese Standard-Prüfsumme zur Ausbildung der modifizierten Prüfsumme modifiziert. Hierzu wird insbesondere die Standard-Prüfsumme invertiert oder es wird eine andere eindeutige mathematische Operation (z.B. Multiplikation, Addition, etc.) durchgeführt. Diese eindeutige mathematische Operation ist auf Seiten der proprietären Komponenten bekannt und wird insofern ebenfalls angewandt, d.h. der Empfänger kann in gleicher Weise die modifizierte Prüfsumme ermitteln und somit mit der mit dem Protokoll übertragenen modifizierten Prüfsumme vergleichen.
• Bei dem hier vorgesehenen Übertragungssystem zur Übermittlung der Messdaten wird allgemein in bevorzugter Ausgestaltung eine Datenübertragungsrate mit ≥1 GBit/s eingesetzt.
• Im Rahmen der Prüfung der Komponenten wird beispielsweise eine derartige hohe Übertragungsrate z.B. in einem Testzyklus oder auch für die normale Übertragung eingestellt. Sind Komponenten enthalten, die nicht für derartige Übertragungsraten ausgelegt sind, so wird dies durch Übertragungsfehler z.B. über fehlende Antworttelegramme auf Erkennungstelegramme festgestellt. Dies ist eine erste Maßnahme zur Prüfung, ob es sich bei den Komponenten um proprietäre Komponenten handelt.
• Alternativ wird die Übertragungsrate bevorzugt mit einem sogenannten Autonegotioation-Verfahren im Rahmen des Ethernet-Standards geprüft. Dieses bekannte Verfahren kann eingesetzt werden, da als Basis für die Datenkommunikation eine Standard-Ethernet- Variante benutzt wird.
• Durch die Einstellung oder das Aushandeln (mit Autonegotiation) von hohen Übertragungsraten wird vermieden, dass ältere Komponenten, die lediglich für kleine Übertragungsraten ausgebildet sind und/oder keine Prüfung der Prüfsumme durchführen (Hubs), die Erkennungs-Telegramme bearbeiten. Die zuvor beschriebene Maßnahme mit dem ungültigen Telegramm, speziell durch die modifizierte Prüfsumme, schließt demgegenüber auch Komponenten aus, die für hohe Übertragungsraten ausgebildet, jedoch nicht proprietär sind.
• In zweckdienlicher Ausgestaltung ist das zu übertragende Erkennungs-Telegramm in seiner Datengröße begrenzt auf kleiner 64Byte, insbesondere kleiner 32 Byte. Das Erkennungs-Telegramm basiert auf einem Ethernet -Standard. Gemäß Ethernet wird für ein Telegramm eine Mindestgröße von 64Byte vorgesehen. Bei kleineren zu übertragenden Datenmengen wird zum Auffüllen ein sogenanntes „PAD“-Feld in das Telegramm eingefügt. Vorliegend wird bewusst auf ein solches PAD-Feld verzichtet. Die Größe des gesamten Erkennungs-Telegramms inkl. Header und Datensatz (Nutzdaten) weist also lediglich eine Datengröße von <64 Byte auf.
• Diese Ausgestaltung beruht auf der Überlegung, dass es sogenannte „Cut-Through-Switches“ gibt, welche eingehende Telegramme bereits weiterleiten, bevor diese überprüft wurden. D.h. ein ankommendes Telegramm wird bereits weitergeleitet, auch wenn es noch nicht vollständig angekommen ist. Die Prüfsumme befindet sich typischerweise am Ende des Telegramms. Diese wird regelmäßig ausgewertet. Bei einem Cut-Through Switch wird daher - sobald das „fehlerhafte“ Telegramm anhand der Prüfsumme erkannt wird - die Übertragung / Weiterleitung abgebrochen. Damit wird das bereits teilweise weitergeleitete Telegramm quasi gekürzt und in einem nachfolgenden Switch wird es früher als nicht zulässiges Telegramm identifiziert.
• Durch die geringe Datengröße (Datenlänge) wird daher ermöglicht, dass solche Cut-Through-Switche ein fehlerhaftes Telegramm frühzeitig erkennen, bzw. dass zumindest die Netzbelastung durch diesen Datenverkehr gering gehalten ist, da diese Erkennung-Telegramme nach kurzer Zeit „verschwinden“.
• Eine Nachbarschafts-Erkennung und damit das Versenden von Erkennungstelegrammen wird allgemein vorzugsweise nach einer Änderung des sogenannten „Link-Status“ geändert. Alternativ und insbesondere ergänzend werden die Erkennungstelegramme vorzugsweise periodisch wiederholend insbesondere mit einem Abstand von mindestens 3 Sekunden versendet. Der Link-Status definiert dabei insbesondere, ob an der jeweiligen Komponente ein Kabel gesteckt, nicht gesteckt oder defekt ist. Die Erkennungs-Telegramme werden vorzugsweise im Laufe des normalen Betriebes, also parallel zur eigentlichen Messdatenerfassung und der Weiterleitung der Messdaten über die eingangs beschriebenen Telegramme versendet.
• Ausführungsbeispiele der Erfindung werden nachfolgend anhand der Figuren näher erläutert. Diese zeigen jeweils in vereinfachten Darstellungen:
• 1 eine schematische Darstellung eines Prozessdatenerfassungssystems,
• 2 eine vereinfachte Darstellung eines Telegramms zur Datenübertragung,
• 3 ein Ablaufschema zur Illustration der Durchführung von mehreren Anfrage-Zyklen im Falle eines Ausbleibens eines erwarteten Telegramms,
• 4 eine vereinfachte Darstellung des Aufbaus eines Senders und zur Erläuterung seiner Antwort auf eine Wiederholungsanfrage vom Empfänger,
• 5 eine stark reduzierte Darstellung eines Empfängers, speziell eines Filters eines Empfängers anhand dessen Telegramme ausgefiltert werden.
• In den Figuren sind gleich wirkende Teile mit den gleichen Bezugszeichen versehen.
• Ein in der 1 dargestelltes Übertragungssystem 2 ist Teil eines Prozessdaten-erfassungssystems für einen industriellen Herstellungsprozess. Das Übertragungssystem 2 weist mehrere Sender 4 auf, die Empfangseinheiten für Messsignale S bilden. Die Sender 4 übermitteln die Messsignale im Rahmen von Daten-Telegrammen 6 an einen im Ausführungsbeispiel zentralen Empfänger 8. Dieser ist insbesondere als eine Auswerteeinheit für eine gemeinsame Auswertung der dezentral erfassten Messdaten S ausgebildet.
• Das Übertragungssystem 2 und das insgesamt als Prozessdatenerfassungssystems ausgebildete System ist zur kontinuierlichen Erfassung der Messdaten S an unterschiedlichen Orten über die einzelnen Sender (Erfassungseinheiten) ausgebildet. Dabei werden pro Erfassungseinheit Messdaten S mit einer hohen Abtastrate, beispielsweise alle 100µs, erfasst und unmittelbar an den Empfänger 8 weitergeleitet. Eine Speicherung der Messdaten S innerhalb des Senders 4 ist vorzugsweise nur im Rahmen einer kurzzeitigen Zwischenspeicherung vorgesehen, wie sie insbesondere im Zusammenhang mit der 4 erläutert wird.
• 2 zeigt beispielhaft und stark vereinfacht den typischen Aufbau eines jeweiligen Telegramms 6. Dieses weist jeweils einen Header 10 sowie zumindest einen Datensatz 12 auf. Letzteres enthält die von der Erfassungseinheit erfassten Messdaten S. Im Header 10 sind Informationen über den Datensatz 12 sowie ergänzende Informationen beispielsweise auch über den Sender 4, Empfänger 8 etc. enthalten. Insbesondere ist im Header 10 auch ein Zähler 14 enthalten, welcher jedem Telegramm 6 einen Zählwert, beispielsweise eine Ziffer oder Nummer zuweist. Der Zählwert erstreckt sich von einem minimalen bis zu einem maximalen Wert und wird dann wieder zyklisch wiederholt. Der Zähler 14 weist beispielsweise eine Datengröße von 24 Bit auf.
• Weiterhin weist das Telegramm 6, speziell der Header 10, einen Zeitstempel 17 auf. Das Telegramm 6 weist weiterhin eine Prüfsumme 16 auf.
• Der Zählwert erhöht sich bei jedem aufeinander folgenden Telegramm 6 jeweils um eine Einheit, sodass die unterschiedlichen Telegramme 6 unterscheidbar sind.
• Der Empfänger 8 wertet die Telegramme 6 anhand des Zählwerts aus. Stellt der Empfänger 8 fest, dass ein Telegramm 6 fehlt, so stellt er im Rahmen eines Abfragezyklusses Z eine Wiederholungsanfrage RR (Request Repeat). Erhält der Empfänger 8 nach einer als Timeout T bezeichneten maximalen Wartezeit (und mehreren Abfragezyklen Z) nicht das fehlende, erwartete Telegramm 6, so wertet der Empfänger 8 dies als einen Verlust dieses erwarteten Telegramms 6.
• Dieser Prozess und die einzelnen Zeitabläufe werden insbesondere im Zusammenhang mit der 3 näher erläutert. In vertikaler Richtung sind hierbei jeweils Zeitachsen eingezeichnet. Auf der rechten Zeitachse sind die Maßnahmen des Senders 4 und auf der mittleren Zeitachse die Maßnahmen des Empfängers 8 angedeutet. Ergänzend sind ganz links zwei Zeitachsen dargestellt, die einzelne Zeitbereiche anzeigen.
• Zu einem Messzeitpunkt t1 werden vom Sender 4 Messdaten erfasst. Diese werden dann zum Senden 4 und zur Erstellung des Telegramms 6 aufbereitet Hierfür ist ein Zeitbedarf z1 erforderlich. Sobald die Messdaten und das Telegramm 6 aufbereitet sind, wird das Telegramm 6 an den Empfänger 8 abgesendet. Die Daten benötigen rechnerisch eine Signallaufzeit z2, bis sie den Empfänger erreichen. Die Signallaufzeit z2 enthält dabei bereits auch eine Varianz, die Laufzeitvarianzen berücksichtigt und allgemein als Jitter bezeichnet wird. Auf Seiten des Empfängers 8 wird das Telegramm 6 im Normalfall empfangen und ausgewertet. Hierzu vergeht eine Toleranzzeit z3. Die Summe dieser drei Zeitbereiche z1, z2, z3 definiert eine Wartezeit W. Diese liegt in den hier betrachteten High-Performance-Systemen bei typischerweise unter 1 Millisekunde.
• Bei dem gesamten Prozessdaten-Erfassungssystem handelt es sich um ein synchron arbeitendes System, d.h. die einzelnen Komponenten 4, 8 sind zeitlich miteinander synchronisiert, bzw. arbeiten mit einer gleichen Systemzeit. Ein jedes Telegramm 6 enthält hierzu den Zeitstempel 17. Auf Basis dieses Zeitstempels 17, z.B. eines zuletzt erhaltenen Telegrams mit einem Zählwert x, ermittelt der Empfänger 8 durch Vergleich mit seiner eigenen Systemzeit, ob die Wartezeit W für ein zu erwartendes Telegramm 6 mit dem Zählwert x+1 abgelaufen ist. D.h. der Empfänger 8 ermittelt auf Basis des zuletzt erhaltenen Telegramms unter Berücksichtigung der definierten Abtastrate zumindest indirekt den Messzeitpunkt t1.
• Hat der Empfänger 8 nach Ablauf der Wartezeit W (zu einem Zeitpunkt t2=t1+W) das erwartete Telegramm 6, nicht erhalten, so sendet er die bereits erwähnte Wiederholungsanfrage RR im Rahmen des Abfragezyklusses Z an den Sender 4. Dieser verarbeitet diese Wiederholungsanfrage RR und sendet das erwartete Telegramm 6 im Schritt „erneutes Senden R“ („Repeat“) erneut.
• Auf der Empfängerseite wird nach der Abgabe der Wiederholungsanfrage RR das wiederholt gesendete Telegramm 6 (Schritt R) spätestens nach Ablauf eines definierten Anfragezeitraums A erwartet. Dieses setzt sich zusammen aus der Summe der Zeiträume 2 x Signallaufzeiten z2 sowie einmal Bearbeitungszeit z4, die der Sender 4 zur Bearbeitung der Wiederholungsanfrage RR und zum wiederholten Senden des Telegramms 6 im Schritt R benötigt. Ergänzend ist auch in diesem Fall noch eine Toleranzzeit z3 vorgesehen, welche eine Bearbeitungszeit auf Seiten des Empfängers 8 berücksichtigt.
• Hat der Empfänger 8 nach Ablauf des Anfragezeitraums A (zu einem Zeitpunkt t3=t1+W+A) wiederum nicht das erwartete Telegramm 6 erhalten, so startet der Empfänger 8 erneut den Abfragezyklus Z und sendet eine weitere Wiederholungsanfrage RR.
• Der Abfragezyklus Z wird mehrfach über eine definierte Anzahl n von Abfragezyklen Z hinweg wiederholt, so lange bis das erwartete Telegramm 6 empfangen wird oder die maximale durch den Timeout T definierte Gesamt-Wartezeit zum Zeitpunkt t_y(t_y=t1+W+n*A) abgelaufen ist.
• In der 3 ist eine Situation dargestellt, bei der aufgrund von Übertragungsfehlern das erwartete und ggf. mehrfach in den Schritten R gesendete Telegramme 6 jeweils nicht auf der Empfängerseite ankommt. Das erwartete Telegramm 6 wird daher als Telegrammverlust gewertet (Telegrammverlust ist symbolisch durch die gezackten Pfeile dargestellt).
• Der Ablauf auf Seiten des Senders 4 bei Erhalt einer Wiederholungsanfrage RR wird nachfolgend anhand der 4 näher erläutert:
• Der Sender 4 weist allgemein einen Prozessor 18 auf, der die Datenverarbeitung innerhalb des Senders 4 steuert. Weiterhin ist im Ausführungsbeispiel ein programmierbare Logik 20 ergänzend zum Prozessor 18 angeordnet, welcher insbesondere als ein sogenanntes „Field Programmable Gate Array“ (FPGA) ausgebildet ist. Weiterhin enthält der Sender einen Zwischenspeicher 22, welcher zur Zwischenspeicherung einer Anzahl der bereits gesendeten Telegramme 6 vorgesehen ist. In der 4 sind beispielhaft fünf Telegramme 6 im Speicher 22 dargestellt.
• Die programmierbare Logik 20 weist weiterhin noch einen Pufferspeicher 24 auf, in dem die zum Senden aufbereiteten Telegramme 6 hinterlegt sind. Im Ausführungsbeispiel der 4 sind die einzelnen Telegramme 6 durchnummeriert mit den Zählwerten F1 bis F5. Dargestellt ist eine Situation, bei der der Sender 4 aktuell das Telegramm 6 mit dem Zählwert F5 über eine Ethernet-Verbindung 26 absendet. Gleichzeitig wird dieses Telegramm F5 in den Speicher 22 geschoben.
• Weiterhin erhält der Sender 4 eine Wiederholungsanfrage RR für das Telegramm mit dem Zählwert F2. Daraufhin veranlasst der Sender 4, speziell der programmierbare Speicher 20, dass das Telegramm 6 mit dem Zählwert F2 aus dem Speicher 22 in den Pufferspeicher 24 übermittelt und nachfolgend gesendet wird.
• In der 5 ist der Empfänger 8, und insbesondere ein Filter 28 des Empfängers 8 und dessen Funktionsweise dargestellt. Durch einen Kreis ist zunächst beispielhaft ein Zählkreis für die Zählwerte der Telegramme 6 dargestellt. Der Zählkreis wiederholt sich periodisch, startet beispielsweise bei einem minimalen Zählwert von null und endet bei einem maximalen Zählwert. Der Zählkreis richtet sich nach der Speichergröße des Zählers 14 innerhalb des Headers 10. Bei einer Datengröße von xBit weist der Zählkreis 2^x unterschiedliche Zählwerte auf. Der Filter 28 definiert ein Zeitfenster 30, welches durch eine vorgegebene Anzahl von Zählwerten definiert ist. Im Ausführungsbeispiel betrifft dies die Zählwerte von 256 bis 512. Das Zeitfenster 30 wird dabei auf Basis des Timeouts T berechnet und entspricht im Wesentlichen der Anzahl der Telegramme 6, die während eines dem Timeout T entsprechenden Zeitbereichs (bei vorgegebener Abtastrate) erstellt werden, ggf. zuzüglich einer Varianz (Jitter). Dies bedeutet, dass der Empfänger 8 zum aktuellen Zeitpunkt lediglich Telegramme 6 mit den Zählwerten 256 bis 512 als zulässig ansieht und empfängt. Weiterhin ist der Filter 28 derart ausgebildet, dass er den Zählwert des eingehenden Telegramms 6 mit den Zählwerten der bereits empfangenen Telegramme 6 abgleicht. Liegt ein Telegramm 6 mit vorgegebenem Zählwert erneut an, so wird auch dies nicht aufgenommen und verarbeitet.
• Im Ausführungsbeispiel der 5 sind drei Telegramme 6 mit den Zählwerten 1402, 284 und nochmals 284 dargestellt. Während das Telegramm 6 mit dem Zählwert 1402 außerhalb des zulässigen, dem Zeitfenster 30 entsprechenden Zählwert-Bereichs liegt und daher nicht empfangen wird, wird das erste Telegramm 6 mit dem Zählwert 284 empfangen und weiter verarbeitet, wohingegen das nachfolgende Telegramm 6 mit dem gleichen Zählwert 284 abgelehnt wird.
• Ein weiterer, unabhängiger oder insbesondere auch ergänzender Aspekt wird beispielhaft anhand der 1 und 2 näher erläutert. Die Qualität des Übertragungssystems 2, beispielsweise die möglichen Datenübertragungsraten, Abtastraten etc., hängen entscheidend von der Qualität der eingesetzten Komponenten, speziell Sender 4, Empfänger 8 und weitere hier nicht näher dargestellte Netzwerkkomponenten, wie beispielsweise Switche, ab. Werden beispielsweise ausschließlich High-Performance-Komponenten 4,8 eingesetzt, so werden beispielsweise für das Übertragungssystem 2 insgesamt höhere Abtastraten bzw. höhere Datenübertragungsraten z.B. durch eine geeignete Parametrierung eingestellt.
• Um zu überprüfen, ob lediglich derartige High-Performance-Komponenten 4,8, nachfolgend auch als proprietäre Komponenten bezeichnet, eingesetzt sind, wird eine Identifizierung der Nachbarn vorgenommen. Die einzelnen Komponenten 4,8 senden hierzu ein definiertes Erkennungs-Telegramm 36 ab, welches von der benachbarten Komponente empfangen wird. Die jeweiligen Komponenten 4,8 fügen dabei in das Erkennungs-Protokoll 36 Informationen über sich selbst ein, sodass Informationen über die jeweilige Komponente bekanntgemacht werden.
• Um zuverlässige Informationen über sämtliche Komponenten 4,8 innerhalb des Übertragungssystems zu erhalten, speziell zu erfahren, ob sämtliche Komponenten 4,8 High-Performance-Komponenten sind, wird speziell eine modifizierte Prüfsumme 16' vom Sender 4 in das Erkennungs-Protokoll 36 eingefügt. Hierdurch wird aus dem Erkennungs-Protokoll 36 für normale, nicht-proprietäre Komponenten ein „unzulässiges“ Protokoll, da die modifizierte Prüfsumme 16' nicht mit einer normal berechneten Prüfsumme 16 übereinstimmt. Demgegenüber berechnen die proprietären Komponenten 4,8 ebenfalls aufgrund eines ihnen bekannten Algorithmusses die Prüfsumme, sodass die dann von dem Empfänger 8 errechnete modifizierte Prüfsumme 16' mit der im Erkennungs-Protokoll 36 enthaltenen modifizierten Prüfsumme 16' übereinstimmt. Für die modifizierte Prüfsumme 16' wird daher allgemein eine proprietäre Prüfsumme verwendet, deren Ermittlung lediglich den proprietären Komponenten 4,8 bekannt ist. Bevorzugt wird für die Erstellung der modifizierte Prüfsumme 16' ein Standard-Algorithmus herangezogen, wie er beispielsweise gemäß dem Ethernet-Protokoll vorgesehen ist, und die damit ermittelte Standard-Prüfsumme 16 wird lediglich in einem Modifizierungsschritt zur Ausbildung der modifizierten Prüfsumme 16' modifiziert. Bei diesem Modifizierungsschritt handelt es sich beispielsweise um eine Multiplikation, eine Addition, eine Invertierung etc. Durch diese Maßnahme wird zuverlässig erkannt, ob sämtliche Komponenten 4,8 proprietäre High-Performance-Komponenten sind. Da die nicht proprietäre Komponente das Telegramm als unzulässig verwerfen wird, wird sie insbesondere keine erwartete Antwort senden, so dass die sendende Komponente erkennt, dass es sich bei der Nachbarkomponente - aufgrund der fehlenden Antwort - nicht um eine proprietäre Komponente handelt. Speziell ändert sich beispielsweise bei Ausbleiben einer erwarteten Rückantwort über einen definierten Zeitraum von z.B. 30s ein Nachbarschafts-Status in „unbekannt“ Diese Info kann dann z. B. über ein Diagnose / Konfigurations -Tool ermittelt und abgerufen werden.
• Bezugszeichenliste

2

Übertragungssystem

4

Sender

6

Telegramm

8

Empfänger

10

Header

12

Datensatz

14

Zähler

16

Prüfsumme

16'

modifizierte Prüfsumme

17

Zeitstempel

18

Prozessor

20

programmierbarer Speicher

22

Speicher

24

Pufferspeicher

26

Ethernet-Verbindung

28

Filter

30

Zeitfenster

36

Erkennungs-Protokoll

S

Messignale

Z

Abfragezyklus

RR

Wiederholungsanfrage

R

erneutes Senden

T

Timeout

t1

Messzeitpunkt

z1

Zeitbedarf

z2

Signallaufzeit

z3

Toleranzzeit

z4

Bearbeitungszeit

W

Wartezeit

R

erneutes Senden

A

Anfragezeitraum

F1 ...F8

Telegramme

Claims (16)

1. Verfahren zur Übermittlung von Messdaten (S) von zumindest einem Sender (4) zu einem Empfänger (8), insbesondere in einer industriellen, synchronen Prozessdatenerfassung, wobei - von dem Sender (4) wiederholt Telegramme (6) an den Empfänger (8) übermittelt werden, - die Telegramme (6) jeweils zumindest einen Datensatz (12) mit zu einem Messzeitpunkt (t1) erfassten Messdaten (S) sowie einen Header (10) mit Informationen über den Datensatz (12) enthalten, - im Falle eines Ausbleibens eines auf Seiten des Empfängers (8) erwarteten Telegramms (6), der Empfänger (8) nach einer vorbestimmten Wartezeit (W) einen Anfragezyklus (Z) startet - der Empfänger (8) zur Durchführung des Anfragezyklus (Z) eine Wiederholungsanfrage (RR) an den Sender (4) übermittelt und einen vorgegebenen Anfragezeitraum (A) auf das erwartete Telegramm (6) wartet, - bei einem weiterem Ausbleiben des erwarteten Telegramms (6) nach Ablauf eines oder mehrerer Anfragezyklen (Z) über einen vorgegebenen Timeout (T) hinweg dies als ein Verlust des Telegramms (6) vermerkt wird.
2. Verfahren nach Anspruch 1, wobei auf eine Empfangsbestätigung für ein jeweiliges Telegramm (6) durch den Empfänger (8) verzichtet wird.
3. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Wartezeit (w) bestimmt ist durch die Summe aus - einem typischen Zeitbedarf (z1) für das Senden, - einer zu erwartenden Signallaufzeit (z2) für die Übertragung des Telegramms (6) vom Sender (4) zum Empfänger (8) sowie optional - einer Toleranzzeit (z3).
4. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Anfragezeitraum (A) bestimmt ist durch die Summe aus - der zu erwartenden Signallaufzeit (z2) der Wiederholungsanfrage (RR) - der zu erwartenden Signallaufzeit (z2) für die Übertragung des Telegramms (6) vom Sender (4) zum Empfänger (8) und - einer zu erwartenden Bearbeitungszeit (z4) für die Wiederholungsanfrage (RR) und dem Senden des Telegramms (6) auf Seiten des Senders (4) sowie optional - einer Toleranzzeit (z3).
5. Verfahren nach einem der vorhergehenden Ansprüche, bei der ein jeweiliger Header (10) einen Zähler (14) aufweist, und die Telegramme (6) mit einem laufenden Zählwert gekennzeichnet sind und der Empfänger (8) anhand eines fehlenden Zählwertes das Ausbleiben eines Telegramms (6) feststellt.
6. Verfahren nach einem der vorhergehenden Ansprüche, bei der im Sender (4) ein jeweiliges Telegramm (6) nach dem Senden für einen vorgegebenen Zeitraum gespeichert wird.
7. Verfahren nach dem vorhergehenden Anspruch, bei dem eine dem Timeout (T) entsprechende Anzahl an Telegrammen (6) gespeichert wird.
8. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Wiederholungsanfrage (RR) Angaben zur Identifizierung des erwarteten Telegramms (6) enthält, insbesondere dessen Zählwert.
9. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Wiederholungsanfrage (RR) sich bezieht - auf das erwartete Telegramm (6), - einen Bereich des erwarteten Telegramms (6) oder - auf eine Gruppe von Telegrammen (6).
10. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Empfänger (8) einen Filter (28) aufweist, welcher anhand des Zählers (14) Telegramme (6) ausfiltert, die bereits empfangen wurden und/oder die zeitlich nicht erwartet werden.
11. Verfahren nach dem vorhergehenden Anspruch, bei dem der Empfänger (8) Telegramme (6) ausfiltert, die außerhalb eines durch den Timeout (T) bestimmten Zeitfensters (30) liegen.
12. Verfahren insbesondere nach einem der vorhergehenden Ansprüche zur Übermittlung von Messdaten (S) in einem Übertragungssystem (2) mit mehreren an der Übermittlung beteiligten Komponenten (4,6), wobei zur Überprüfung, ob es sich bei den beteiligten Komponenten (4,6) um proprietäre Komponenten handelt ein Erkennungs-Telegramm (36) insbesondere auf Basis eines Standard-Telegramms, versendet wird, welches als ein ungültiges Telegramm ausgebildet ist, welches lediglich von proprietären Komponenten (4,6) akzeptiert und verarbeitet wird.
13. Verfahren nach Anspruch 12, bei dem das Erkennungs-Telegramm ein modifiziertes Telegramm gemäß einem Standard-Protokoll ist.
14. Verfahren nach Anspruch 12 oder 13, bei dem das Erkennungs-Telegramm (36) eine modifizierte Prüfsumme (16') aufweist, welche insbesondere dadurch erstellt wird, indem zunächst eine Standard-Prüfsumme (16) gemäß einem vorgegebenen Standard berechnet wird und die Standard-Prüfsumme (16) anschießend zur Ausbildung der modifizierten Prüfsumme (16') modifiziert wird.
15. Verfahren nach einem der Ansprüche 12 bis 14, bei dem das Erkennungs-Telegramm (36) eine begrenzte Größe von kleiner 64Byte aufweist
16. Übertragungssystem (2) zur Übermittlung von Messdaten (S) mit zumindest einem Sender (4) und einem Empfänger (8), welches zur Durchführung des Verfahrens nach einem der vorhergehenden Ansprüche ausgebildet ist.

Images