DE102009027168B4

DE102009027168B4 - Verfahren zum Ermitteln einer übermittelten Telegramm-Datenlänge

Info

Publication number: DE102009027168B4
Application number: DE102009027168.6A
Authority: DE
Inventors: Bert Von Stein; Markus Kilian; Andrea Seger; Christian Wandrei
Original assignee: Endress and Hauser SE and Co KG
Current assignee: Endress and Hauser SE and Co KG
Priority date: 2009-06-24
Filing date: 2009-06-24
Publication date: 2021-01-21
Anticipated expiration: 2029-06-25
Also published as: DE102009027168A1; US20120093024A1; WO2010149440A1

Abstract

Verfahren zum Ermitteln einer übermittelbaren Telegramm-Datenlänge in einem HART®-Feldbussystem, gekennzeichnet durch nachfolgende Schritte:A) Übersenden eines Test-Telegramms (4; 6; 12; 16; 30; 38; 46; 52; 62; 70; 78; 82) zwischen einem Master (M) und einem Slave (S) über das HART®-Feldbussystem, wobei das Test-Telegramm eine vorbestimmte Test-Datenlänge aufweist;B) Überprüfen durch den Empfänger (M; S) des Test-Telegramms, ob dieses vollständig erhalten wurde; undC) Feststellen anhand des Ergebnisses der Überprüfung, ob diese Test-Datenlänge übermittelbar ist, wobei das Test-Telegramm durch ein Test-Antworttelegramm (4; 12; 30; 38; 46; 78) gebildet wird, das von dem Slave (S) an den Master (M) über das HART®-Feldbussystem auf ein entsprechendes Anfragetelegramm (2; 10; 28; 36; 48; 76) des Masters hin übersendet wird, wobei das entsprechende Anfragetelegramm des Masters derart ausgebildet ist, dass durch dieses der Slave zur Übersendung des Test-Antworttelegramms aufgefordert wird, dadurch gekennzeichnet,dass das entsprechende Anfragetelegramm (2; 10; 28; 36; 48; 76) des Masters (M) Informationen bezüglich der in dem Nutzdatenanteil des Test-Antworttelegramms zu übersendenden Daten enthält.

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Ermitteln einer übermittelbaren Telegramm-Datenlänge in einem HART®-Feldbussystem.
In der Prozessautomatisierungstechnik werden vielfach Feldgeräte eingesetzt, die zur Erfassung und/oder Beeinflussung von Prozessvariablen dienen. Zur Erfassung von Prozessvariablen dienen Sensoren, wie beispielsweise Füllstandsmessgeräte, Durchflussmessgeräte, Druck- und Temperaturmessgeräte, pH-Redoxpotentialmessgeräte, Leitfähigkeitsmessgeräte, etc., welche die entsprechenden Prozessvariablen Füllstand, Durchfluss, Druck, Temperatur, pH-Wert bzw. Leitfähigkeit erfassen. Zur Beeinflussung von Prozessvariablen dienen Aktoren, wie zum Beispiel Ventile oder Pumpen, über die der Durchfluss einer Flüssigkeit in einem Rohrleitungsabschnitt bzw. der Füllstand in einem Behälter geändert werden kann. Als Feldgeräte werden im Prinzip alle Geräte bezeichnet, die prozessnah eingesetzt werden und die prozessrelevante Informationen liefern oder verarbeiten. Eine Vielzahl solcher Feldgeräte wird von der Firma Endress + Hauser hergestellt und vertrieben.
In modernen Industrieanlagen sind Feldgeräte in der Regel über Bussysteme (Profibus®, Foundation® Fieldbus, HART®, etc.) mit übergeordneten Einheiten verbunden. Normalerweise handelt es sich bei den übergeordneten Einheiten um Leitsysteme bzw. Steuereinheiten, wie beispielsweise SPS (speicherprogrammierbare Steuerung) oder PLC (Programmable Logic Controller). Die übergeordneten Einheiten dienen unter anderem zur Prozesssteuerung, Prozessvisualisierung, Prozess-überwachung sowie zur Inbetriebnahme der Feldgeräte.
In einem HART®-Feldbussystem ist ein Master vorgesehen, der in der Regel durch eine übergeordnete Einheit gebildet wird. Dieser Master steht über das HART®-Feldbussystem mit einem oder mehreren Slave(s) in Kommunikationsverbindung, wobei die Slaves in der Regel durch Feldgeräte gebildet werden.
Telegramme gemäß dem HART@-Protokoll sind dabei derart aufgebaut, dass diese Steuerinformationen, die einen Frame (deutsch: Rahmen) des Telegramms bilden, und Nutzdaten, die einen Nutzdatenanteil des Telegramms bilden, aufweisen. Bis zur Revision 5 des HART® Field Communication Protocol war die Datenlänge des Nutzdatenanteils von Telegrammen bei einem Anfrage-Telegramm, das von einem Master an einen Slave übersendet wird, auf 25 Byte und bei einem Antwort-Telegramm, das von einem Slave an einen Master übersendet wird, auf 27 Bytes begrenzt. Seit der Revision 6 des HART® Field Communication Protocol besteht die Möglichkeit, Telegramme mit einer Datenlänge des Nutzdatenanteils von bis zu 255 Bytes zu übertragen. Für die Ermittlung der gesamten Telegramm-Datenlänge muss jeweils noch die Datenlänge der Steuerinformationen hinzugerechnet werden, die je nach Anwendung variieren kann.
Grundsätzlich ist die Ausnutzung der maximalen Datenlänge des Nutzdatenanteils vorteilhaft, da hierdurch die Übertragung von großen Datenmengen schneller und effektiver durchgeführt werden kann. Problematisch ist jedoch, falls nicht alle, an der Kommunikation beteiligten Komponenten die Übermittlung von Telegrammen mit so großen Telegramm-Datenlängen unterstützen, da in diesem Fall Fehler auftreten können. Solche, an der Kommunikation beteiligte Komponenten sind insbesondere der jeweilige Master, der jeweilige Slave sowie eine oder mehrere Komponenten des HART®-Feldbussystems, die an der Übermittlung von Telegrammen beteiligt sind, wie beispielsweise ein Multiplexer. Dabei ist insbesondere die Ausbildung der Schicht 2 (Data Link Layer bzw. Sicherungsschicht) des OSl-Referenzmodells (OSI: Open System Interconnection) der jeweiligen Komponente entscheidend dafür, welche Telegramm-Datenlängen durch die betreffende Komponente übermittelbar sind.
Falls keine Sicherheit darüber besteht, ob sämtliche, an der Kommunikation beteiligten Komponenten zumindest gemäß Revision 6 des HART® Field Communication Protocol ausgebildet sind und damit die Übermittlung von Telegrammen mit so großen Datenlängen, insbesondere mit einem Nutzdatenanteil von bis zu 255 Bytes, unterstützen, können bisher Fehler bei der Übermittlung von Telegrammen dadurch vermieden werden, dass der Nutzdatenanteil für ein Anfrage-Telegramm auf 25 Bytes und für ein Antwort-Telegramm auf 27 Bytes begrenzt wird. Hierdurch wird insbesondere bei der Übertragung von großen Datenmengen die Kommunikation über das HART®-Feldbussystem erheblich verlangsamt.
Die EP 2 131 256 A1 offenbart ein Verfahren zum Ermitteln einer Telegrammlänge in einer Bedienvorrichtung zum Kommunizieren zwischen der Bedienvorrichtung und einem Feldgerät über ein Netzwerk.
Die US 2008/0232261 A1 offenbart ein Übertragungsgerät, welches Test-Frames sendet und/oder empfängt, um die Konnektivität zwischen dem Übertragungsgerät und einem anderen Übertragungsgerät zu, bzw. von dem anderen Übertragungsgerät in regelmäßigen Abständen zu testen.
Die DE 10 2007 052031 A1 offenbart ein Verfahren zum Betreiben eines Parametrier-Gerätes für ein Feldbussystem, welches eine Erhöhung der effektiven Übertragungsgeschwindigkeit bei der Übertragung von Parametern ermöglicht.
Demgemäß besteht die Aufgabe der vorliegenden Erfindung darin, ein Verfahren bereitzustellen, durch das eine effektive Datenübertragung über ein HART®-Feldbussystem ohne Auftreten von Fehlern bei der Übermittlung von Telegrammen ermöglicht wird.
Die Aufgabe wird durch ein Verfahren zum Ermitteln einer übermittelbaren Telegramm-Datenlänge in einem HART®-Feldbussystem gemäß Anspruch 1 gelöst. Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
Gemäß der vorliegenden Erfindung wird ein Verfahren bereitgestellt, durch das in einem HART®-Feldbussystem eine übermittelbare Telegramm-Datenlänge ermittelbar ist. Das erfindungsgemäße Verfahren weist dabei nachfolgende Schritte auf:

A) Übersenden eines Test-Telegramms zwischen einem Master und einem Slave über das HART®-Feldbussystem, wobei das Test-Telegramm eine vorbestimmte Test-Datenlänge aufweist;
B) Überprüfen durch den Empfänger des Test-Telegramms, ob dieses vollständig erhalten wurde; und
C) Feststellen anhand des Ergebnisses der Überprüfung, ob diese Test-Datenlänge übermittelbar ist.

Dementsprechend kann durch das erfindungsgemäße Verfahren auf einfache Weise festgestellt werden, ob ein Telegramm mit einer bestimmten Datenlänge zwischen einem Master und einem Slave über das HART®-Feldbussystem übermittelbar ist. Insbesondere kann durch das erfindungsgemäße Verfahren festgestellt werden, ob die an der Übermittlung des Test-Telegramms beteiligten Komponenten die Übermittlung von Telegrammen mit einer Telegramm-Datenlänge, die der Test-Datenlänge entspricht, unterstützen. Basierend auf diesem Ergebnis kann eine möglichst effektive Datenübertragung (mit entsprechend angepasster Telegramm-Datenlänge) über das HART®-Feldbussystem durchgeführt werden.
Insbesondere werden in dem Test-Telegramm keine „echten“ Daten, die beispielsweise für eine Prozesssteuerung in einer Anlage der Prozessautomatisierungstechnik relevant sind, übermittelt, sondern lediglich Test-Daten. Im Fall einer fehlerhaften Übermittlung entstehen folglich keine nachteiligen Auswirkungen, wie beispielsweise das Auftreten von Fehlern in einer durchgeführten Prozesssteuerung.
Insbesondere kann bei dem Schritt des Übersendens (Schritt A)) der Fall auftreten, dass der Absender des Test-Telegramms das Absenden von Telegrammen mit einer so großen Telegramm-Datenlänge nicht unterstützt und beispielsweise nur ein Teil des Test-Telegramms abgesendet wird. Ferner kann bei dem Schritt des Übersendens (Schritt A)) der Fall auftreten, dass eine oder mehrere Komponenten des HART®-Feldbussystems, die an der Übermittlung des Test-Telegramms beteiligt sind, wie beispielsweise ein Multiplexer, nicht die Übermittlung von Telegrammen mit einer so großen Telegramm-Datenlänge unterstützen. In diesem Fall kann insbesondere der Fall auftreten, dass nur ein Teil des Test-Telegramms durch die betreffende Komponente übermittelt wird und/oder das Test-Telegramm fehlerhaft übermittelt wird. Weiterhin kann bei dem Schritt des Übersendens (Schritt A)) der Fall auftreten, dass der Empfänger des Test-Telegramms das Empfangen von Telegrammen mit so großen Telegramm-Datenlängen nicht unterstützt und beispielsweise nur ein Teil des Test-Telegramms empfangen wird. Sämtliche dieser beispielhaften Konstellationen führen bei dem Schritt des Überprüfens (Schritt B)) zu dem Ergebnis, dass das Test-Telegramm nicht vollständig erhalten wurde.
Führt der Schritt des Überprüfens (Schritt B)) zu dem Ergebnis, dass das Test-Telegramm durch den Empfänger nicht vollständig erhalten wurde, so wird bei dem Schritt des Feststellens (Schritt C)) dann festgestellt, dass diese Test-Datenlänge nicht übermittelbar ist. Folglich müssen für die Übersendung von „tatsächlichen“ bzw. „echten“ Daten über den betreffenden Feldbus-Pfad (zwischen dem Master und dem Slave) Telegramme mit einer kürzeren Telegramm-Datenlänge eingesetzt werden. Führt hingegen der Schritt des Überprüfens (Schritt B)) zu dem Ergebnis, dass das Test-Telegramm vollständig erhalten wurde, so wird bei dem Schritt des Feststellens (Schritt C)) festgestellt, dass diese Test-Datenlänge übermittelbar ist. Folglich können für die Übersendung von „tatsächlichen“ bzw. „echten“ Daten über den betreffenden Feldbus-Pfad (zwischen dem Master und dem Slave) Telegramme mit einer Telegramm-Datenlänge eingesetzt werden, die zumindest der Test-Datenlänge entspricht.
Erfindungsgemäß wird das Test-Telegramm durch ein Test-Antworttelegramm gebildet, das von dem Slave an den Master über das HART®-Feldbussystem auf ein entsprechendes Anfragetelegramm des Masters hin übersendet wird, wobei das entsprechende Anfragetelegramm des Masters derart ausgebildet ist, dass durch dieses der Slave zur Übersendung des Test-Antworttelegramms aufgefordert wird. Dies hat den Vorteil, dass sowohl der Schritt des Überprüfens (Schritt B)) als auch der Schritt des Feststellens (Schritt C)) in dem Master durchgeführt werden können. Dadurch kann die Anzahl der zu übersendenden Telegramme niedrig gehalten werden. Insbesondere ist vorgesehen, dass das entsprechende Anfragetelegramm sowie das Test-Antworttelegramm ein herstellerspezifisches Kommando aufweisen. Ferner ist insbesondere vorgesehen, dass das Anfragetelegramm eine derart kurze Datenlänge (beispielsweise maximal 25 Bytes in dessen Nutzdatenanteil) aufweist, dass es in jedem Fall von dem Master an den Slave übermittelbar ist.
Gemäß einer Weiterbildung enthält das entsprechende Anfragetelegramm des Masters weitere Informationen bezüglich des von dem Slave zu übersendenden Test-Antworttelegramms, insbesondere Informationen bezüglich der in dem Nutzdatenanteil des Test-Antworttelegramms zu übersendenden Daten. Wird beispielsweise ein Ringspeicher eingesetzt, so kann in dem entsprechenden Anfragetelegramm auch der Startpunkt des Ringspeichers übermittelt werden.
Das erfindungsgemäße Verfahren eignet sich insbesondere für den Dienst „Block Data Transfer“. Dieser Dienst, der in HART® standardisiert ist, ermöglicht die Übertragung großer Datenmengen zwischen einem Master und einem Slave, wobei die zu übertragenden Daten in der Regel auf mehrere Telegramme aufgeteilt werden. Durch das erfindungsgemäße Verfahren kann folglich für den betreffenden Feldbus-Pfad eine übermittelbare Telegramm-Datenlänge, insbesondere eine maximale, übermittelbare Telegramm-Datenlänge, ermittelt werden und diese Telegramm-Datenlänge dann für die Übersendung von „tatsächlichen“ bzw. „echten“ Daten eingesetzt werden.
Wie nachfolgend unter Bezugnahme auf Weiterbildungen erläutert wird, kann das Test-Telegramm mit der Test-Datenlänge von einem Master an einen Slave und/oder von einem Slave an einen Master übersendet werden. Der Schritt des Überprüfens (Schritt B)) wird demzufolge in ersterem Fall durch den Slave und in letzterem Fall durch den Master durchgeführt. Der Schritt des Feststellens wird insbesondere durch den Master durchgeführt, wobei in ersterem Fall der Slave das Ergebnis der Überprüfung an den Master übersenden muss. Insbesondere wird der Master durch eine übergeordnete Einheit (teilweise auch als Host bezeichnet) und der Slave durch ein Feldgerät (Sensor und/oder Aktor) gebildet. Wie im einleitenden Teil erläutert wird, kann der Master insbesondere eine Prozesssteuerung in Bezug auf den Slave (Feldgerät) sowie gegebenenfalls auch weitere oder alternative Funktionen ausführen.
Ferner weist das Test-Telegramm insbesondere ein herstellerspezifisches Kommando auf. In HART® werden Kommandos eingesetzt, um den jeweils auszuführenden Befehl anzugeben. Diese bilden einen Teil des Frames (d.h. der Steuerzeichen) eines Telegramms. Neben standardisierten Kommandos können dabei in HART® auch herstellerspezifische Kommandos eingesetzt werden, die sowohl dem Absender als auch dem Empfänger des betreffenden Telegramms bekannt sein müssen.
Gemäß einer Weiterbildung ist das erfindungsgemäße Verfahren derart ausgebildet, dass durch dieses eine maximal übermittelbare Telegramm-Datenlänge oder eine Telegramm-Datenlänge, die noch übermittelbar ist und die möglichst nahe an der maximal übermittelbaren Telegramm-Datenlänge liegt, in einem HART®-Feldbussystem ermittelbar ist. Dies kann beispielsweise dadurch realisiert werden, dass das gemäß dem erfindungsgemäßen Verfahren übersendete Test-Telegramm eine Test-Datenlänge aufweist, die möglichst hoch gewählt wird, bei der aber zu erwarten ist, dass die Übermittlung solch einer Datenlänge von zumindest einer, an der Übermittlung beteiligten Komponenten unterstützt wird. Gemäß einer Weiterbildung weist das Test-Telegramm eine maximale, in der aktuellen Version des HART® Field Communication Protocol zugelassene Telegramm-Datenlänge auf. Aktuell entspricht dies einer Datenlänge des Nutzdatenanteils des Telegramms von 255 Bytes. Hinzu kommt noch die Datenlänge der Steuerzeichen des Telegramms.
Teilweise kann der Fall auftreten, dass in dem Telegramm enthaltene Daten von Komponenten, die an der Kommunikation beteiligt sind, falsch übermittelt werden. Gemäß einer Weiterbildung kann die korrekte Übermittlung dadurch getestet und gegebenenfalls der korrekt übermittelte Anteil bestimmt werden, dass das Test-Telegramm in dessen Nutzdatenanteil eine zufällige, dem Master und dem Slave bekannte Datenfolge aufweist. Der Empfänger des Test-Telegramms kann dann bei dem Schritt des Überprüfens (Schritt B)) überprüfen, ob sämtliche Daten des Nutzdatenanteils (und gegebenenfalls auch die Steuerinformationen) des Test-Telegramms korrekt übermittelt wurden. Solch eine Datenfolge für den Nutzdatenanteil kann beispielsweise dadurch generiert werden, dass in dem Master und dem Slave ein Ringspeicher (auch als Ringbuffer bezeichnet) mit jeweils identischen Daten vorgesehen ist und der Startpunkt für die in dem Nutzdatenanteil des Test-Telegramms zu übersendende Datenfolge jeweils frei (bzw. zufällig) gewählt wird. Der Startpunkt innerhalb des Ringspeichers kann beispielsweise in einem separaten Telegramm oder auch in dem Test-Telegramm selbst mitgeteilt werden.
Im einfachsten Fall kann durch den Empfänger bei dem Schritt des Überprüfens (Schritt B)) der bloße Erhalt des Test-Telegramms geprüft werden. Es besteht aber auch die Möglichkeit, dass das Test-Telegramm durch den Empfänger bei dem Schritt des Überprüfens (Schritt B)) auf weitere Kriterien im Hinblick darauf, ob es vollständig erhalten wurde, überprüft wird und das Ergebnis der Überprüfung somit mehrere Einzel-Ergebnisse aufweist. Insbesondere ist gemäß einer Weiterbildung vorgesehen, dass das Ergebnis der Überprüfung mindestens eines der nachfolgenden Einzel-Ergebnisse aufweist:

- Test-Telegramm wurde durch den Empfänger erhalten;
- Test-Telegramm wurde durch den Empfänger vollständig (insbesondere dessen vollständige Nutzdaten) erhalten;
- die Checksumme des Test-Telegramms wurde durch den Empfänger erhalten;
- die Checksumme des Test-Telegramms weist einen korrekten Wert auf; und/oder
- die in dem Nutzdatenanteil des Test-Telegramms enthaltenen Nutzdaten wurden korrekt empfangen.

Daneben kann das Ergebnis der Überprüfung auch noch weitere oder alternative Einzel-Ergebnisse aufweisen. Dabei ist gemäß einer Weiterbildung vorgesehen, dass bei dem Schritt des Feststellens (Schritt C)) nur dann festgestellt wird, dass die betreffende Test-Datenlänge übermittelbar ist, wenn sämtliche Einzel-Ergebnisse positiv sind (d.h. in Bezug auf alle überprüften Kriterien eine korrekte Übermittlung stattgefunden hat).
Der Erhalt des Test-Telegramms mit seinen vollständigen Nutzdaten durch den Empfänger kann beispielsweise dadurch überprüft werden, dass der Wert des Byte Count und die Datenlänge der tatsächlich empfangenen Nutzdaten übereinstimmen. Der Byte Count bildet dabei einen Teil der (standardisierten) Steuerinformationen von HART®-Telegrammen und gibt die Anzahl der Bytes zwischen dem Byte Count und der Checksumme, die sich am Ende des Telegramms befindet, an. Die Checksumme (bzw. das Check Byte) bildet in der Regel das letzte Byte eines HART®-Telegramms und dient der Fehlererkennung. Wie in HART® genauer definiert ist, wird der Wert der Checksumme durch ein exklusives ODER (XOR) aller Bytes eines Telegramms von dessen Start Byte bis zu dem letzten Byte des Nutzdatenanteils gebildet. Das Einzel-Ergebnis, dass die Checksumme des Test-Telegramms durch den Empfänger erhalten wurde, gibt folglich an, dass das Test-Telegramm in seiner gesamten Länge erhalten wurde und dass bei dem Empfänger kein Gap Timeout (deutsch: Lücken-Zeitablauf)aufgetreten ist. Das Einzel-Ergebnis, dass die Checksumme des Test-Telegramms einen korrekten Wert aufweist, gibt an, dass die in dem Test-Telegramm enthaltenen Daten mit hoher Wahrscheinlichkeit korrekt übermittelt wurden. Ferner können, wie oberhalb unter Bezugnahme auf eine Weiterbildung erläutert wurde, die empfangenen Daten des Nutzdatenanteils des Test-Telegramms auch noch auf ihre Richtigkeit (durch Vergleich) überprüft werden. In letzterem Fall kann insbesondere auch überprüft werden, welcher Anteil des Nutzdatenanteils, d.h. welche Nutzdatenlänge des Test-Telegramms durch den Empfänger (korrekt) empfangen wurde.
Gemäß einer Weiterbildung ist vorgesehen, dass basierend auf dem Ergebnis der Überprüfung, insbesondere basierend auf dem Einzel-Ergebnis, welche Nutzdatenlänge des Test-Telegramms durch den Empfänger empfangen wurde, die übermittelbare Telegramm-Datenlänge in dem HART®-Feldbussystem bestimmt wird. Dieser Schritt des Bestimmens wird insbesondere durch den Master durchgeführt. Wird dieser Schritt des Bestimmens basierend auf dem Einzel-Ergebnis, welche Nutzdatenlänge des Test-Telegramms durch den Empfänger (korrekt) empfangen wurde, durchgeführt, so kann beispielsweise auch in Fällen, in denen das Test-Telegramm nicht vollständig übermittelt wurde, anhand der (korrekt) übermittelten Nutzdatenlänge festgestellt werden, welcher Anteil des Test-Telegramms korrekt übermittelt wurde. Anhand dieser (korrekt) übermittelten Nutzdatenlänge kann dann (unter Berücksichtigung der Datenlänge der Steuerinformationen) eine maximal übermittelbare Telegramm-Datenlänge bestimmt werden. Die für die Übermittlung von „tatsächlichen“ bzw. „echten“ Daten eingesetzten Telegramme können dann eine Telegramm-Datenlänge aufweisen, die dieser maximal übermittelbaren Telegramm-Datenlänge entspricht oder etwas kleiner als diese ist.
Gemäß einer Weiterbildung wird dann, wenn der Schritt des Feststellens ergibt, dass eine Test-Datenlänge eines vorhergehend gesendeten Test-Telegramms nicht übermittelbar ist, zwischen dem Master und dem Slave über das HART®-Feldbussystem ein weiteres Test-Telegramm mit einer gegenüber dem vorhergehend gesendeten Test-Telegramm reduzierten Test-Datenlänge übersendet. Durch diese Weiterbildung wird ein „Herantasten“ an eine maximale, übermittelbare Telegramm-Datenlänge ermöglicht.
Gemäß einer Weiterbildung wird dann, wenn der Schritt des Feststellens ergibt, dass eine Test-Datenlänge eines vorhergehend gesendeten Test-Telegramms übermittelbar ist, zwischen dem Master und dem Slave über das HART®-Feldbussystem ein weiteres Test-Telegramm mit einer gegenüber dem vorhergehend gesendeten Test-Telegramm erhöhten Test-Datenlänge übersendet. Durch diese Weiterbildung wird ein „Herantasten“ an eine maximale, übermittelbare Telegramm-Datenlänge ermöglicht.
Gemäß einer Weiterbildung wird nach einem vorbestimmten Algorithmus und basierend auf dem Ergebnis des Schrittes des Feststellens (bei einem vorhergehend übersendeten Test-Telegramm) eine Erhöhung oder Reduzierung der Test-Datenlänge eines weiteren, zwischen dem Master und dem Slave über das HART®-Feldbussystem zu übersendenden Test-Telegramms gegenüber einem vorhergehend übersendeten Test-Telegramm bestimmt. Dabei kann insbesondere ein Algorithmus gewählt werden, durch den möglichst schnell ein Herantasten an eine maximal übermittelbare Telegramm-Datenlänge ermöglicht wird. Dabei ist nicht zwingend, dass die maximal übermittelbare Telegramm-Datenlänge genau ermittelt wird, sondern der Algorithmus kann auch abgebrochen werden, sobald eine übermittelbare Telegramm-Datenlänge ermittelt wurde, die nahe genug an der maximal übermittelbaren Telegramm-Datenlänge liegt.
Solch ein Algorithmus kann beispielsweise dadurch gebildet werden, dass mit einer hohen Test-Datenlänge (z.B. einer Datenlänge des Nutzdatenanteils von 255 Bytes) gestartet wird und die Test-Datenlänge (oder gegebenenfalls auch nur die Datenlänge des Nutzdatenanteils) jeweils halbiert wird, bis der Schritt des Feststellens (Schritt C)) ergibt, dass die Test-Datenlänge (des zuletzt übersendeten Test-Telegramms) übermittelbar ist. Anschließend kann ausgehend von dieser zuletzt übermittelten Test-Datenlänge wieder eine sukzessive Erhöhung der Test-Datenlänge (oder gegebenenfalls auch nur der Datenlänge des Nutzdatenanteils) durchgeführt werden, bis der Schritt des Feststellens (Schritt C) wiederum ergibt, dass die Test-Datenlänge (des zuletzt übersendeten Test-Telegramms) nicht mehr übermittelbar ist.
Gemäß einer vorteilhaften Weiterbildung ist in dem HART®-Feldbussystem zwischen dem Master und dem Slave mindestens ein Multiplexer, über welchen die jeweiligen Telegramme übermittelt werden, vorgesehen. Solche Multiplexer werden in HART®-Feldbussystemen oftmals zwischen einem Master und einem bzw. in der Regel mehreren Slave(s) eingesetzt. Durch einen Multiplexer werden die erhaltenen Telegramme hinsichtlich deren Steuerinformationen zumindest teilweise interpretiert und entsprechend weiter übersendet. Insbesondere bei Multiplexern besteht dabei bisher die Problematik, dass diese teilweise nicht für die Übermittlung von Telegramm-Datenlängen mit bis zu 255 Bytes Nutzdatenanteil (und zusätzlichen Steuerinformationen) ausgelegt sind. Dennoch sind diese oftmals dafür ausgelegt, längere Telegramm-Datenlängen als nur mit 27 Bytes Nutzdatenanteil (und zusätzlichen Steuerinformationen) zu übermitteln. Dementsprechend kann durch das erfindungsgemäße Verfahren auf einfache Weise ermittelt werden, welche Telegramm-Datenlänge (durch den Multiplexer) noch übermittelbar ist, insbesondere welche maximale Telegramm-Datenlänge übermittelbar ist.
Gemäß einer Weiterbildung wird das Verfahren zwischen dem Master und mehreren, an dem HART®-Feldbussystem angeschlossenen Slaves durchgeführt. Auf diese Weise kann die jeweils übermittelbare Telegramm-Datenlänge für verschiedene Pfade des HART®-Feldbussystems und auch für die verschiedenen Slaves ermittelt werden. In der Regel erfolgt die Übersendung von Test-Telegrammen zwischen dem Master und den jeweiligen Slaves nacheinander.
Gemäß einer Weiterbildung sind Informationen über die jeweiligen Verfahrensschritte in Informationen zur Geräteintegration des Slaves, insbesondere in einer Gerätebeschreibung und/oder in einem Gerätetreiber des Slaves, enthalten und der Master weist eine entsprechende Rahmenapplikation, insbesondere einen Interpreter zum Interpretieren einer Gerätebeschreibung und/oder eine FDT-Rahmenapplikation für einen Gerätetreiber in Form eines Device Type Managers (DTM), auf. Auf diese Weise können dem Master für die Kommunikation mit dem betreffenden Slave das jeweils einzusetzende, (in der Regel herstellerspezifische) Kommando, die für das erfindungsgemäße Verfahren erforderlichen Schritte, etc. bekannt gemacht werden. Wird in dem Nutzdatenanteil des Test-Telegramms eine zufällige, dem Master und dem Slave bekannte Datenfolge übermittelt, so kann diese Datenfolge (oder auch die in einem Ringspeicher gespeicherten Daten) auch in den Informationen zur Geräteintegration des Slaves enthalten sein.
„Informationen zur Geräteintegration“ werden allgemein eingesetzt, um die in einem Slave (in der Regel ein Feldgerät) vorgesehenen Funktionen und Daten einer übergeordneten Einheit bzw. einem Master bekannt zu machen. Solche Informationen zur Geräteintegration können beispielsweise durch eine Gerätebeschreibung (DD) (engl.: „Device Description“) des Slaves (in der Regel ein Feldgerät) gebildet werden. Die Gerätebeschreibung wird in der Regel in textbasierter Form erstellt (z.B. im ASCII-Textformat). Je nach verwendetem Feldbus-System werden verschiedene Gerätebeschreibungssprachen verwendet, bei HART® beispielsweise die HART® Device Description Language. Die in der Gerätebeschreibung bereitgestellten Informationen werden in der Regel durch einen Interpreter interpretiert bzw. übersetzt und an ein Bedienprogramm (z.B. „Application Designer“ von Endress + Hauser) des Masters (in der Regel eine übergeordnete Einheit) bereitgestellt. Ein Gerätetreiber, insbesondere ein DTM, ist eine gerätespezifische Software, die Daten und Funktionen des betreffenden Slaves (in der Regel ein Feldgerät) kapselt und gleichzeitig grafische Bedienelemente bereitstellt. Insbesondere stellt ein DTM Funktionen zum Zugang zu Variablen des Feldgerätes, zum Parametrieren und Betreiben des Feldgerätes und Diagnosefunktionen bereit. Ein DTM ist alleine nicht lauffähig. Als Laufzeitumgebung dient eine dem FDT-Standard entsprechende Rahmenapplikation, die in dem Master implementiert ist.
Weitere Vorteile und Zweckmäßigkeiten der Erfindung ergeben sich anhand der nachfolgenden Beschreibung von Ausführungsbeispielen unter Bezugnahme auf die beigefügten Figuren. Von den Figuren zeigen:

1: eine schematische Darstellung von zwei Kommunikationsabläufen zur Veranschaulichung von zwei Ausführungsbeispielen der vorliegenden Erfindung;
2: eine schematische Darstellung von zwei Kommunikationsabläufen zur Veranschaulichung von zwei weiteren Ausführungsbeispielen der vorliegenden Erfindung;
3A: eine schematische Darstellung eines Kommunikationsablaufes zur Veranschaulichung eines weiteren Ausführungsbeispiels der vorliegenden Erfindung;
3B: eine schematische Darstellung eines Kommunikationsablaufes zur Veranschaulichung eines weiteren Ausführungsbeispiels der vorliegenden Erfindung; und
4: eine schematische Darstellung von zwei Kommunikationsabläufen zur Veranschaulichung von zwei weiteren Ausführungsbeispielen der vorliegenden Erfindung;

In den 1 bis 4 sind jeweils ein Master M, ein Slave S und eine HART®-Feldbus-Topologie FB dargestellt. Die Kommunikationsebenen dieser drei, an der Kommunikation beteiligten Komponenten M, S und FB sind jeweils durch vertikale, gestrichelte Linien dargestellt. Der Master M wird dabei in den Ausführungsbeispielen durch eine übergeordnete Einheit und der Slave S durch ein Feldgerät gebildet.
Der Master M und der Slave S sind dabei an einem drahtgebundenen HART®-Feldbussystem angeschlossen, wobei die Übermittlung von Telegrammen zwischen dem Master M und dem Slave S über einen (nicht dargestellten) Multiplexer erfolgt. Das HART®-Feldbussystem zusammen mit dem Multiplexer wird in dem vorliegenden Zusammenhang als HART®-Feldbus-Topologie FB bezeichnet. Ferner sind in den 1 bis 4 Anfragetelegramme (von dem Master M an den Slave S) jeweils in durchgezogener Linie dargestellt und Antworttelegramme (von dem Slave S an den Master M) jeweils in gestrichelter Linie dargestellt. Handelt es sich bei dem betreffenden Telegramm um ein Test-Telegramm gemäß der vorliegenden Erfindung, so ist dieses in Fettdruck dargestellt.
In den 1 bis 4 weist das Test-Telegramm (bzw. das erste, gesendete Test-Telegramm) jeweils einen Nutzdatenanteil mit einer Datenlänge von 255 Bytes auf. Zu diesen 255 Bytes kommt dann noch die Datenlänge der Steuerinformationen des Test-Telegramms hinzu, so dass sich daraus die Test-Datenlänge ergibt. Auf diese Weise kann geprüft werden, ob sämtliche, an der Kommunikation beteiligten Komponenten (hier: Master M, Slave S, Feldbus-Topologie FB) eine Übertragung von Telegrammen mit einer so großen Test-Datenlänge unterstützen. Dies ist beispielsweise dann der Fall, wenn sämtliche, an der Kommunikation beteiligten Komponenten zumindest gemäß Revision 6 des HART® Field Communication Protocol ausgebildet sind.
In 1 ist der Fall dargestellt, dass sämtliche, an der Kommunikation beteiligten Komponenten (hier: Master M, Slave S, Feldbus-Topologie FB) die Übertragung einer solchen Test-Datenlänge unterstützen.
In der oberen Hälfte von 1 ist ein erstes Ausführungsbeispiel der vorliegenden Erfindung dargestellt. Der Master M übersendet zunächst ein entsprechendes Anfragetelegramm 2 über die Feldbus-Topologie FB an den Slave S. Das Anfragetelegramm 2 weist dabei ein herstellerspezifisches Kommando auf, durch das der Slave S aufgefordert wird, ein Test-Antworttelegramm an den Master M zu übersenden. Ferner enthält das Anfragetelegramm 2 in dem vorliegenden Ausführungsbeispiel noch weitere Informationen bezüglich des von dem Slave S zu übersendenden Test-Antworttelegramms. Insbesondere ist darin angegeben, welche Datenlänge der Nutzdatenanteil des Test-Antworttelegramms aufweisen soll (hier 255 Bytes). Ferner weist sowohl der Master M als auch der Slave S einen Ringspeicher auf, in dem jeweils identische Test-Daten gespeichert sind. In dem Anfragetelegramm 2 wird auch ein Startpunkt innerhalb des Ringspeichers für die in dem Nutzdatenanteil des Test-Antworttelegramms zu übersendenden Test-Daten mitgeteilt. Das Anfragetelegramm 2 kann, je nach Ausgestaltung des erfindungsgemäßen Verfahrens, auch keine oder alternative Informationen bezüglich des von dem Slave S zu übersendenden Test-Antworttelegramms aufweisen.
Das Anfragetelegramm 2 weist dabei eine derart kurze Datenlänge auf, dass es in jedem Fall von dem Master M an den Slave S übermittelbar ist. Im vorliegenden Fall weist der Nutzdatenanteil des Anfragetelegramms 2 eine Datenlänge von maximal 25 Bytes auf. Dadurch wird sichergestellt, dass das Anfragetelegramm 2 selbst dann, wenn eine oder mehrere, an der Kommunikation beteiligte(n) Komponente(n) nicht zumindest gemäß Revision 6 des HART® Field Communication Protocol ausgebildet sind, von dem Master M an den Slave S vollständig übermittelbar ist.
Nach Erhalt des Anfragetelegramms 2 übersendet der Slave S an den Master M ein Test-Antworttelegramm 4, das in dessen Nutzdatenanteil die oberhalb spezifizierten Test-Daten enthält. Das Test-Antworttelegramm 4 wird von allen, an der Kommunikation beteiligten Komponenten (hier: Master M, Slave S, Feldbus-Topologie, FB) fehlerfrei übermittelt. In dem Master M wird anschließend überprüft, ob es vollständig erhalten wurde. Insbesondere werden dabei die nachfolgenden Kriterien durch den Master M überprüft:

- ob das Test-Antworttelegramm erhalten wurde;
- ob das Test-Antworttelegramm mit seinen vollständigen Nutzdaten erhalten wurde;
- ob die Checksumme des Test-Antworttelegramms erhalten wurde;
- ob die Checksumme des Test-Antworttelegramms einen korrekten Wert aufweist; sowie
- ob die in dem Nutzdatenanteil des Test-Antworttelegramms enthaltenen Nutzdaten (Test-Daten) korrekt empfangen wurden.

In dem vorliegenden Ausführungsbeispiel sind sämtliche Kriterien erfüllt, so dass sämtliche Einzel-Ergebnisse der Überprüfung positiv sind. Anschließend wird in dem Master M festgestellt, dass die betreffende Test-Datenlänge übermittelbar ist.
Im Folgenden wird unter Bezugnahme auf 1 ein zweites Ausführungsbeispiel der vorliegenden Erfindung erläutert, dessen Kommunikationsablauf in 1 unterhalb der strichpunktierten Linie dargestellt ist. Hierbei wird vorwiegend auf die Unterschiede gegenüber dem ersten Ausführungsbeispiel eingegangen.
Der Master M übersendet zunächst ein Test-Anfragetelegramm 6 über die Feldbus-Topologie FB an den Slave S. Das Test-Anfragetelegramm 6 weist dabei ein herstellerspezifisches Kommando auf, durch das der Slave S aufgefordert wird, in einem Antwort-Telegramm das Ergebnis der Überprüfung, ob das Test-Anfragetelegramm 6 vollständig erhalten wurde, an den Slave S zu übersenden. In dem Nutzdatenanteil des Test-Anfragetelegramms 6 werden wiederum Test-Daten übersendet, die sowohl in dem Master M als auch in dem Slave S in einem zugehörigen Ringspeicher gespeichert sind. Dabei wird bei dem vorliegenden Ausführungsbeispiel in dem Test-Anfragetelegramm 6 auch der Startpunkt innerhalb des Ringspeichers für die übersendeten Test-Daten mitgeteilt. Alternativ kann dieser Startpunkt aber auch in einem separaten Telegramm mitgeteilt werden.
Das Test-Anfragetelegramm 6 wird von allen, an der Kommunikation beteiligten Komponenten (hier: Master M, Slave S, Feldbus-Topologie FB) fehlerfrei übermittelt. In dem Slave S wird anschließend überprüft, ob das Test-Anfragetelegramm 6 vollständig erhalten wurde. Dabei werden durch den Slave S bei dem erhaltenen Test-Anfragetelegramm 6 in entsprechender Weise die oberhalb, in Bezug auf das erste Ausführungsbeispiel erläuterten Kriterien überprüft.
In dem vorliegenden Ausführungsbeispiel sind sämtliche Kriterien erfüllt, so dass sämtliche Einzel-Ergebnisse der Überprüfung positiv sind. Diese Einzel-Ergebnisse der Überprüfung werden anschließend in einem Antworttelegramm 8 von dem Slave S an den Master M übersendet. Das Antworttelegramm 8 weist wiederum eine derart kurze Datenlänge (Datenlänge des Nutzdatenanteils von maximal 27 Bytes) auf, so dass es in jedem Fall von dem Slave S an den Master M übermittelbar ist. Anschließend wird in dem Master M festgestellt, dass die betreffende Test-Datenlänge über-mittelbar ist.
Sowohl bei dem ersten als auch bei dem zweiten Ausführungsbeispiel können zur Übermittlung von „echten“ Daten Telegramme mit dieser maximalen Datenlänge eingesetzt werden. Gegebenenfalls kann die Telegramm-Datenlänge für die Übermittlung von „echten“ Daten auch auf eine etwas kürzere Datenlänge als die Test-Datenlänge begrenzt werden.
In 2 ist der Fall dargestellt, dass Telegramme mit der Test-Datenlänge (Datenlänge des Nutzdatenanteils von 255 Bytes) durch die HART®-Feldbus-Topologie FB, insbesondere durch den Multiplexer, abgeschnitten werden und nur der erste Teil des betreffenden Telegramms übermittelt wird.
In der oberen Hälfte von 2 ist ein drittes Ausführungsbeispiel der vorliegenden Erfindung dargestellt, wobei nachfolgend vorwiegend auf die Unterschiede gegenüber dem ersten Ausführungsbeispiel eingegangen wird. Der Master M übersendet wiederum ein entsprechendes Anfragetelegramm 10 über die Feldbus-Topologie FB an den Slave S. Das Anfragetelegramm 10 ist dabei entsprechend dem Anfragetelegramm 2 des ersten Ausführungsbeispiels aufgebaut. Nach Erhalt des Anfragetelegramms 10 übersendet der Slave S an den Master M ein Test-Antworttelegramm 12, das in dessen Nutzdatenanteil die angeforderten Test-Daten enthält. Das Test-Antworttelegramm 12 wird bei der Übermittlung von dem Multiplexer abgeschnitten und nur der erste Teil 12' des Test-Antworttelegramms 12 wird weiter übermittelt.
Der Master M führt das Empfangen solange aus, bis die Checksumme (die sich am Ende von HART®-Telegrammen befindet) erhalten wird oder bis ein Timeout (deutsch: Zeitablauf), der als Gap Timeout bezeichnet wird, auftritt. Vorliegend enthält der erste Teil 12' des Test-Antworttelegramms 12 keine Checksumme, so dass der Master M nach Auftreten eines Gap Timeout das Empfangen abbricht. Anschließend werden in dem Master M die oberhalb, in Bezug auf das erste Ausführungsbeispiel erläuterten Kriterien in Bezug auf einen vollständigen Erhalt des Test-Antworttelegramms 12 überprüft. Dieser Schritt des Überprüfens ergibt in dem vorliegenden Ausführungsbeispiel unter anderem, dass die Checksumme und auch ein Teil des Nutzdatenanteils des Test-Antworttelegramms 12 nicht erhalten wurde. Ferner prüft der Master M bei dem Schritt des Überprüfens, welche Nutzdatenlänge (bzw. welcher Anfangsteil der Nutzdaten) des Test-Antworttelegramms 12 korrekt empfangen wurde und bestimmt daraus (unter Berücksichtigung der Datenlänge der Steuerinformationen) die maximal übermittelbare Telegramm-Datenlänge. Die von dem Master M ab dem Empfangen des Test-Antworttelegramms 12 durchgeführten Schritte sind in 2 durch den rückführenden Pfeil 14 dargestellt.
Im Folgenden wird unter Bezugnahme auf 2 ein viertes Ausführungsbeispiel der vorliegenden Erfindung erläutert, dessen Kommunikationsablauf in 2 unterhalb der strichpunktierten Linie dargestellt ist. Hierbei wird vorwiegend auf die Unterschiede gegenüber dem zweiten Ausführungsbeispiel eingegangen.
Der Master M übersendet zunächst ein Test-Anfragetelegramm 16 über die Feldbus-Topologie FB an den Slave S. Das Test-Anfragetelegramm 16 ist dabei entsprechend dem Test-Anfragetelegramm 6, wie es unter Bezugnahme auf das zweite Ausführungsbeispiel erläutert wurde, aufgebaut. Das Test-Anfragetelegramm 16 wird bei der Übermittlung von dem Multiplexer abgeschnitten und nur der erste Teil 16' des Test-Anfragetelegramms 16 wird weiter übermittelt.
Wie bei dem dritten Ausführungsbeispiel in Bezug auf den Empfangvorgang durch den Master M erläutert wurde, bricht der Slave S, da die Checksumme in dem übermittelten ersten Teil 16' des Test-Anfragetelegramms 16 nicht enthalten ist, nach Auftreten eines Gap Timeout das Empfangen ab. Dies ist in 2 schematisch durch den rückführenden Pfeil 18 dargestellt. Anschließend werden in dem Slave S die oberhalb, in Bezug auf das erste Ausführungsbeispiel erläuterten Kriterien in Bezug auf einen vollständigen Erhalt des Test-Anfragetelegramms 16 überprüft. Dieser Schritt des Überprüfens ergibt in dem vorliegenden Ausführungsbeispiel unter anderem, dass die Checksumme und auch ein Teil des Nutzdatenanteils des Test-Anfragetelegramms 16 nicht erhalten wurde. Ferner prüft der Slave S bei dem Schritt des Überprüfens, welche Nutzdatenlänge (bzw. welcher Anfangsteil der Nutzdaten) des Test-Anfragetelegramms 16 korrekt empfangen wurde. Da von dem Master M kein Antworttelegramm auf das Test-Anfragetelegramm 16 erhalten wird, tritt in dem Master M ein Response Timeout (deutsch: Antwort-Zeitablauf) auf, was in 2 schematisch durch den rückführenden Pfeil 20 dargestellt ist.
Als nächster Schritt übersendet der Master M ein Analyse-Anfragetelegramm 22 an den Slave S. Das Analyse-Anfragetelegramm 22 weist ein herstellerspezifisches Kommando auf, durch das der Slave S aufgefordert wird, in einem Antwort-Telegramm das Ergebnis der Überprüfung, insbesondere die oberhalb genannten Einzel-Ergebnisse, zu übersenden. Anschließend übersendet der Slave S in einem Antworttelegramm 24 die Einzel-Ergebnisse, die bei dem Schritt des Überprüfens erhalten wurden. Sowohl das Analyse-Anfragetelegramm 22 als auch das zugehörige Antworttelegramm 24 weisen wiederum eine derart kurze Datenlänge (z.B. Datenlänge des Nutzdatenanteils des Analyse-Anfragetelegramms von maximal 25 Bytes; Datenlänge des Nutzdatenanteils des zugehörigen Antworttelegramms von maximal 27 Bytes) auf, so dass sie in jedem Fall zwischen dem Slave S und dem Master M übermittelbar sind.
Der Master M stellt anhand der empfangenen Einzel-Ergebnisse fest, dass die Test-Datenlänge nicht übermittelbar ist. Ferner bestimmt er aus den Einzel-Ergebnissen, insbesondere aus dem Einzelergebnis, welche Nutzdatenlänge (bzw. welcher Anfangsteil der Nutzdaten) des Test-Anfragetelegramms 16 korrekt empfangen wurde, (unter Berücksichtigung der Datenlänge der Steuerinformationen) die maximal übermittelbare Telegramm-Datenlänge. Diese Schritte des Masters M sind in 2 durch den rückführenden Pfeil 26 dargestellt.
Sowohl bei dem dritten als auch bei dem vierten Ausführungsbeispiel können zur Übermittlung von „echten“ Daten Telegramme mit der bestimmten, maximalen Datenlänge eingesetzt werden. Gegebenenfalls kann die Telegramm-Datenlänge für die Übermittlung von „echten“ Daten auch auf eine etwas kürzere Datenlänge als die bestimmte, maximale Datenlänge begrenzt werden. Ferner kann zusätzlich vorgesehen sein, dass vor der Übermittlung von „echten“ Daten mit einem weiteren Test-Telegramm getestet wird, ob die bestimmte, maximale Telegramm-Datenlänge tatsächlich fehlerfrei und vollständig übermittelt wird.
In den 3A und 3B ist der Fall dargestellt, dass Telegramme mit der Test-Datenlänge (Datenlänge des Nutzdatenanteils von 255 Bytes) durch die HART®-Feldbus-Topologie FB, insbesondere durch den Multiplexer, vollständig verworfen werden und damit nicht weiter übermittelt werden.
Im Folgenden wird unter Bezugnahme auf 3A ein fünftes Ausführungsbeispiel erläutert, wobei vorwiegend auf die Unterschiede gegenüber dem dritten Ausführungsbeispiel eingegangen wird. Der Master M übersendet wiederum ein entsprechendes Anfragetelegramm 28 über die Feldbus-Topologie FB an den Slave S. Das Anfragetelegramm 28 ist dabei entsprechend dem Anfragetelegramm 2 des ersten Ausführungsbeispiels aufgebaut. Nach Erhalt des Anfragetelegramms 28 übersendet der Slave S an den Master M ein Test-Antworttelegramm 30, das in dessen Nutzdatenanteil die angeforderten Test-Daten enthält. Das Test-Antworttelegramm 30 wird bei der Übermittlung von dem Multiplexer verworfen, was in 3A durch den rückführenden Pfeil 32 dargestellt ist. Da von dem Master M kein Test-Antworttelegramm erhalten wird, tritt in dem Master M ein Response Timeout (deutsch: Antwort-Zeitablauf) auf. Der Master M stellt dementsprechend fest, dass die Test-Datenlänge nicht übermittelbar ist. Diese Schritte des Masters M sind in 3A durch den rückführenden Pfeil 34 dargestellt.
Als nächster Schritt übersendet der Master M ein weiteres Anfragetelegramm 36 über die Feldbus-Topologie FB an den Slave S, wobei der Slave S in dem weiteren Anfragetelegramm 36 aufgefordert wird, ein Test-Antworttelegramm mit einer gegenüber dem vorhergehend gesendeten Test-Antworttelegramm 30 reduzierten Test-Datenlänge zu übersenden. Daraufhin übersendet der Slave S an den Master M das weitere Test-Antworttelegramm 38 mit einer entsprechend reduzierten Test-Datenlänge. Wiederum wird das weitere Test-Antworttelegramm 38 bei der Übermittlung von dem Multiplexer verworfen, was in 3A durch den rückführenden Pfeil 40 dargestellt ist. Da von dem Master M kein Test-Antworttelegramm erhalten wird, tritt in dem Master M ein Response Timeout auf, was in 3A durch den rückführenden Pfeil 42 dargestellt ist. Diese, in diesem Absatz beschriebene Schleife, die in 3A durch eine gestrichelte Box 44 gekennzeichnet ist, wird wiederholt, bis, wie nachfolgend erläutert wird, eine erfolgreiche Übermittlung eines Test-Antworttelegramms stattfindet.
Solch eine erfolgreiche Übermittlung eines Test-Antworttelegramms 46 mit einer entsprechend reduzierten Test-Datenlänge, das auf ein entsprechendes Anfragetelegramm 48 hin übersendet wird, ist in 3A unterhalb der gestrichelten Box 44 dargestellt. In dem Master M wird anschließend überprüft, ob das Test-Antworttelegramm 46 vollständig erhalten wurde, wobei insbesondere die unter Bezugnahme auf das erste Ausführungsbeispiel erläuterten Kriterien überprüft werden. In dem vorliegenden Ausführungsbeispiel sind sämtliche Kriterien erfüllt. Anschließend wird in dem Master M festgestellt, dass die betreffende (reduzierte) Test-Datenlänge übermittelbar ist. Folglich können zur Übermittlung von „echten“ Daten Telegramme mit dieser Datenlänge oder einer geringfügig reduzierten Datenlänge eingesetzt werden. Die von dem Master M durchgeführten Schritte sind in 3A durch den rückführenden Pfeil 50 dargestellt.
Im Folgenden wird unter Bezugnahme auf 3B ein sechstes Ausführungsbeispiel erläutert, wobei vorwiegend auf die Unterschiede gegenüber dem vierten Ausführungsbeispiel eingegangen wird.
Der Master M übersendet zunächst ein Test-Anfragetelegramm 52 über die Feldbus-Topologie FB an den Slave S. Das Test-Anfragetelegramm 52 ist dabei entsprechend dem Test-Anfragetelegramm 6, wie es unter Bezugnahme auf das zweite Ausführungsbeispiel erläutert wurde, aufgebaut. Das Test-Anfragetelegramm 52 wird bei der Übermittlung von dem Multiplexer verworfen, was in 3B durch den rückführenden Pfeil 54 dargestellt ist. Da von dem Master M kein Antworttelegramm auf das Test-Anfragetelegramm 52 erhalten wird, tritt in dem Master M ein Response Timeout auf, was in 3B durch den rückführenden Pfeil 56 dargestellt ist.
Als nächster Schritt übersendet der Master M ein Analyse-Anfragetelegramm 58, das entsprechend dem Analyse-Anfragetelegramm 22 der vierten Ausführungsform aufgebaut ist, an den Slave S. Anschließend übersendet der Slave S in einem Antwort-telegramm 60, das entsprechend dem Antworttelegramm 24 der vierten Ausführungsform aufgebaut ist, auf das Analyse-Anfragetelegramm 58 lediglich das Einzel-Ergebnis, dass kein Analyse-Anfragetelegramm durch den Slave S erhalten wurde. Eine weitergehende Überprüfung der verschiedenen Kriterien durch den Slave S erübrigt sich in der vorliegenden Konstellation. Anschließend stellt der Master M anhand des empfangenen Einzel-Ergebnisses fest, dass die Test-Datenlänge nicht übermittelbar ist.
Als nächster Schritt übersendet der Master M ein weiteres Test-Anfragetelegramm 62 über die Feldbus-Topologie FB an den Slave S. Das weitere Test-Anfragetelegramm 62 weist gegenüber dem vorhergehend gesendeten Test-Anfragetelegramm 52 eine reduzierte Test-Datenlänge auf. Wiederum wird das weitere Test-Anfragetelegramm 62 bei der Übermittlung von dem Multiplexer verworfen, was in 3B durch den rückführenden Pfeil 64 dargestellt ist. Da von dem Master M kein Antworttelegramm auf das weitere Test-Anfragetelegramm 62 erhalten wird, tritt in dem Master M ein Response Timeout auf. Anschließend stellt der Master M fest, dass die reduzierte Test-Datenlänge nicht übermittelbar ist. Diese Schritte des Masters M sind in 3B durch den rückführenden Pfeil 66 dargestellt. Diese, in diesem Absatz beschriebene Schleife, die in 3B durch eine gestrichelte Box 68 gekennzeichnet ist, wird wiederholt, bis, wie nachfolgend erläutert wird, eine erfolgreiche Übermittlung eines Test-Anfragetelegramms stattfindet.
Solch eine erfolgreiche Übermittlung eines Test-Anfragetelegramms 70 mit einer entsprechend reduzierten Test-Datenlänge, auf das hin ein Antwortgramm 72 übersendet wird, ist in 3B unterhalb der gestrichelten Box 68 dargestellt. Der Kommunikationsablauf entspricht dabei demjenigen, wie er zu dem zweiten Ausführungsbeispiel in Bezug auf das Test-Anfragetelegramm 6 und das Antworttelegramm 8 erläutert wurde. Anschließend wird in dem Master M festgestellt, dass die betreffende (reduzierte) Test-Datenlänge übermittelbar ist. Folglich können zur Übermittlung von „echten“ Daten Telegramme mit dieser Datenlänge oder einer geringfügig reduzierten Datenlänge eingesetzt werden. Die von dem Master M durchgeführten Schritte sind in 3B durch den rückführenden Pfeil 74 dargestellt.
Dabei ist nicht zwingend erforderlich, dass die in den 3A und 3B veranschaulichten Verfahren nach der ersten erfolgreichen Übermittlung eines Test-Telegramms abgebrochen werden. Vielmehr kann durch weitere Schritte, insbesondere durch das nachfolgende Erhöhen der Test-Datenlänge eines weiteren, zu übersendenden Test-Telegramms eine maximal übermittelbare Telegramm-Datenlänge noch genauer bestimmt werden. Hierzu kann insbesondere ein Algorithmus eingesetzt werden, wie im einleitenden Teil der Beschreibung erläutert wird.
In 4 ist der Fall dargestellt, dass Telegramme mit der Test-Datenlänge (Datenlänge des Nutzdatenanteils von 255 Bytes) durch die HART®-Feldbus-Topologie FB, insbesondere durch den Multiplexer, zwar nicht gekürzt, aber die zu übertragenden Bytes falsch übermittelt werden. Dieser Fall kann beispielsweise dann auftreten, wenn Daten eines Telegramms bei der Übermittlung in einem Pufferspeicher, beispielsweise in einem Pufferspeicher eines Multiplexers, zwischengespeichert werden, der Pufferspeicher nicht für die Speicherung von so großen Datenmengen ausgelegt ist und damit Daten teilweise überschrieben werden. Solch eine fehlerhafte Übermittlung kann insbesondere dadurch festgestellt und genauer analysiert werden, dass in dem jeweiligen Test-Telegramm in dessen Nutzdatenanteil eine zufällige, dem Master M und dem Slave S bekannte Datenfolge übermittelt wird. Solche Test-Daten werden in den nachfolgend erläuterten beiden Ausführungsbeispielen durch Test-Daten, die jeweils in einem Ringspeicher des Masters M und des Slaves S gespeichert sind, gebildet. Im Hinblick auf diese Test-Daten wird auf die Erläuterung zu dem ersten Ausführungsbeispiel verwiesen.
Im Folgenden wird unter Bezugnahme auf die obere Hälfte der 4 ein siebtes Ausführungsbeispiel erläutert, wobei vorwiegend auf die Unterschiede gegenüber dem ersten Ausführungsbeispiel eingegangen wird. Der Master M übersendet wiederum ein entsprechendes Anfragetelegramm 76 über die Feldbus-Topologie FB an den Slave S. Das Anfragetelegramm 76 ist dabei entsprechend dem Anfragetelegramm 2 des ersten Ausführungsbeispiels aufgebaut. Nach Erhalt des Anfragetelegramms 76 übersendet der Slave S an den Master M ein Test-Antworttelegramm 78, das in dessen Nutzdatenanteil die angeforderten Test-Daten enthält. Die zu übertragenden Bytes des Test-Antworttelegramms 78 werden von dem Multiplexer falsch übermittelt, so dass bei dem Master M ein verändertes Test-Antworttelegramm 78' ankommt.
Anschließend werden in dem Master M die oberhalb, in Bezug auf das erste Ausführungsbeispiel erläuterten Kriterien in Bezug auf einen vollständigen Erhalt des Test-Antworttelegramms 78 überprüft. Dieser Schritt des Überprüfens ergibt in dem vorliegenden Ausführungsbeispiel unter anderem, dass die Checksumme des erhaltenen Test-Antworttelegramms 78' keinen korrekten Wert aufweist und dass die in dem Nutzdatenanteil des erhaltenen Test-Antworttelegramms 78' enthaltenen Nutzdaten nicht korrekt empfangen wurden. Ferner prüft der Master M bei dem Schritt des Überprüfens, welche Nutzdatenlänge (bzw. welcher Anfangsteil der Nutzdaten) des Test-Antworttelegramms 78 korrekt empfangen wurde und bestimmt daraus (unter Berücksichtigung der Datenlänge der Steuerinformationen) die maximal übermittelbare Telegramm-Datenlänge. Die von dem Master M ab dem Empfangen des Test-Antworttelegramms 78' durchgeführten Schritte sind in 4 durch den rückführenden Pfeil 80 dargestellt.
Im Folgenden wird unter Bezugnahme auf 4 ein achtes Ausführungsbeispiel der vorliegenden Erfindung erläutert, dessen Kommunikationsablauf in 4 unterhalb der strichpunktierten Linie dargestellt ist. Hierbei wird vorwiegend auf die Unterschiede gegenüber dem zweiten Ausführungsbeispiel eingegangen.
Der Master M übersendet zunächst ein Test-Anfragetelegramm 82 über die Feldbus-Topologie FB an den Slave S. Das Test-Anfragetelegramm 82 ist dabei entsprechend dem Test-Anfragetelegramm 6, wie es unter Bezugnahme auf das zweite Ausführungsbeispiel erläutert wurde, aufgebaut. Die zu übertragenden Bytes des Test-Anfragetelegramms 82 werden von dem Multiplexer falsch übermittelt, so dass bei dem Slave S ein verändertes Test-Anfragetelegramm 82' ankommt.
Anschließend werden in dem Slave S die oberhalb, in Bezug auf das erste Ausführungsbeispiel erläuterten Kriterien in Bezug auf einen vollständigen Erhalt des Test-Anfragetelegramms 82 überprüft. Dieser Schritt des Überprüfens ergibt in dem vorliegenden Ausführungsbeispiel unter anderem, dass die Checksumme des erhaltenen Test-Anfragetelegramms 82' keinen korrekten Wert aufweist und dass die in dem Nutzdatenanteil des erhaltenen Test-Anfragetelegramms 82' enthaltenen Nutzdaten nicht korrekt empfangen wurden. Ferner prüft der Slave S bei dem Schritt des Überprüfens, welche Nutzdatenlänge (bzw. welcher Anfangsteil der Nutzdaten) des Test-Anfragetelegramms 82 korrekt empfangen wurde. Diese Schritte des Slaves S sind in 4 durch den rückführenden Pfeil 84 dargestellt.
Da in dem vorliegenden Fall die Checksumme keinen korrekten Wert aufweist, wird als Antworttelegramm 86 auf das Test-Anfragetelegramm 82 ein standardmäßig in HART® vorgesehenes Checksummen-Fehlertelegramm gesendet, in dem lediglich mitgeteilt wird, dass das Test-Anfragetelegramm 82 eine fehlerhafte Checksumme enthielt.
Da das Antworttelegramm 86 auf das Test-Anfragetelegramm 82 nicht das vollständige Ergebnis der Überprüfung enthält, übersendet der Master M ein Analyse-Anfragetelegramm 88 an den Slave S. Anschließend übersendet der Slave S in einem Antworttelegramm 90 auf das Analyse-Anfragetelegramm 88 die Einzel-Ergebnisse, die bei dem Schritt des Überprüfens erhalten wurden. Das Analyse-Anfragetelegramm 88 und das zugehörige Antworttelegramm 90 sind dabei entsprechend dem Analyse-Anfragetelegramm 22 und dem Antworttelegramm 24, die in Bezug auf das vierte Ausführungsbeispiel erläutert wurden, aufgebaut.
Der Master M stellt dann anhand der empfangenen Einzel-Ergebnisse fest, dass die Test-Datenlänge nicht übermittelbar ist. Ferner bestimmt er aus den Einzel-Ergebnissen, insbesondere aus dem Einzelergebnis, welche Nutzdatenlänge (bzw. welcher Anfangsteil der Nutzdaten) des Test-Anfragetelegramms 82 korrekt empfangen wurde, (unter Berücksichtigung der Datenlänge der Steuerinformationen) die maximal übermittelbare Telegramm-Datenlänge. Diese Schritte des Masters M sind in 4 durch den rückführenden Pfeil 92 dargestellt.
Auch bei dem siebten und achten Ausführungsbeispiel können, entsprechend wie es zu der dritten Ausführungsform erläutert wurde, zur Übermittlung von „echten“ Daten Telegramme mit dieser maximalen Datenlänge oder auch einer etwas kürzeren Datenlänge eingesetzt werden. Ferner kann in entsprechender Weise nochmals ein weiteres Test-Telegramm, das die bestimmte, maximal übermittelbare Telegramm-Datenlänge aufweist, übersendet werden, um dessen fehlerfreie Übermittlung zu testen.

Claims

Verfahren zum Ermitteln einer übermittelbaren Telegramm-Datenlänge in einem HART®-Feldbussystem, gekennzeichnet durch nachfolgende Schritte: A) Übersenden eines Test-Telegramms (4; 6; 12; 16; 30; 38; 46; 52; 62; 70; 78; 82) zwischen einem Master (M) und einem Slave (S) über das HART®-Feldbussystem, wobei das Test-Telegramm eine vorbestimmte Test-Datenlänge aufweist; B) Überprüfen durch den Empfänger (M; S) des Test-Telegramms, ob dieses vollständig erhalten wurde; und C) Feststellen anhand des Ergebnisses der Überprüfung, ob diese Test-Datenlänge übermittelbar ist, wobei das Test-Telegramm durch ein Test-Antworttelegramm (4; 12; 30; 38; 46; 78) gebildet wird, das von dem Slave (S) an den Master (M) über das HART®-Feldbussystem auf ein entsprechendes Anfragetelegramm (2; 10; 28; 36; 48; 76) des Masters hin übersendet wird, wobei das entsprechende Anfragetelegramm des Masters derart ausgebildet ist, dass durch dieses der Slave zur Übersendung des Test-Antworttelegramms aufgefordert wird, dadurch gekennzeichnet, dass das entsprechende Anfragetelegramm (2; 10; 28; 36; 48; 76) des Masters (M) Informationen bezüglich der in dem Nutzdatenanteil des Test-Antworttelegramms zu übersendenden Daten enthält.
Verfahren gemäß Anspruch 1, dadurch gekennzeichnet, dass das Test-Telegramm (4; 6; 12; 16; 30; 52; 78; 82) eine maximale, in der aktuellen Version des HART® Field Communication Protocol zugelassene Telegramm-Datenlänge aufweist.
Verfahren gemäß Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Test-Telegramm (4; 6; 12; 16; 30; 38; 46; 52; 62; 70; 78; 82) in dessen Nutzdatenanteil eine zufällige, dem Master (M) und dem Slave (S) bekannte Datenfolge aufweist.
Verfahren gemäß einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Ergebnis der Überprüfung mindestens eines der nachfolgenden Einzel-Ergebnisse aufweist: - Test-Telegramm (4; 6; 12; 16; 30; 38; 46; 52; 62; 70; 78; 82) wurde durch den Empfänger (M; S) erhalten; - Test-Telegramm wurde durch den Empfänger vollständig erhalten; - die Checksumme des Test-Telegramms wurde durch den Empfänger erhalten; - die Checksumme des Test-Telegramms weist einen korrekten Wert auf; und/oder - die in dem Nutzdatenanteil des Test-Telegramms enthaltenen Nutzdaten wurden korrekt empfangen.
Verfahren gemäß einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass basierend auf dem Ergebnis der Überprüfung, insbesondere basierend auf dem Einzel-Ergebnis, welche Nutzdatenlänge des Test-Telegramms (4; 6; 12; 16; 78; 82) durch den Empfänger empfangen wurde, die übermittelbare Telegramm-Datenlänge in dem HART®-Feldbussystem bestimmt wird.
Verfahren gemäß einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass dann, wenn der Schritt des Feststellens ergibt, dass eine Test-Datenlänge eines vorhergehend gesendeten Test-Telegramms (30; 38; 52; 62) nicht übermittelbar ist, zwischen dem Master (M) und dem Slave (S) über das HART®-Feldbussystem ein weiteres Test-Telegramm (38; 46; 62; 70) mit einer gegenüber dem vorhergehend gesendeten Test-Telegramm reduzierten Test-Datenlänge übersendet wird.
Verfahren gemäß einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass dann, wenn der Schritt des Feststellens ergibt, dass eine Test-Datenlänge eines vorhergehend gesendeten Test-Telegramms übermittelbar ist, zwischen dem Master (M) und dem Slave (S) über das HART®-Feldbussystem ein weiteres Test-Telegramm mit einer gegenüber dem vorhergehend gesendeten Test-Telegramm erhöhten Test-Datenlänge übersendet wird.
Verfahren gemäß einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass nach einem vorbestimmten Algorithmus und basierend auf dem Ergebnis des Schrittes des Feststellens bei einem vorhergehend übersendeten Test-Telegramm (30; 38; 52; 62) eine Erhöhung oder Reduzierung der Test-Datenlänge eines weiteren, zwischen dem Master (M) und dem Slave (S) über das HART®-Feldbussystem zu übersendenden Test-Telegramms (38; 46; 62; 70) gegenüber einem vorhergehend übersendeten Test-Telegramm (30; 38; 52; 62) bestimmt wird.
Verfahren gemäß einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass in dem HART®-Feldbussystem zwischen dem Master (M) und dem Slave (S) mindestens ein Multiplexer, über welchen die jeweiligen Telegramme übermittelt werden, vorgesehen ist.
Verfahren gemäß einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren zwischen dem Master (M) und mehreren, an dem HART®-Feldbussystem angeschlossenen Slaves (S) durchgeführt wird.
Verfahren gemäß einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass Informationen über die jeweiligen Verfahrensschritte in Informationen zur Geräteintegration des Slaves (S), insbesondere in einer Gerätebeschreibung und/oder in einem Gerätetreiber des Slaves, enthalten sind und dass der Master (M) eine entsprechende Rahmenapplikation, insbesondere einen Interpreter zum Interpretieren einer Gerätebeschreibung und/oder eine FDT-Rahmenapplikation für einen Gerätetreiber in Form eines Device Type Managers (DTM), aufweist.