[go: up one dir, main page]

DE60319704T2 - Methode und adapter zur protokoll-ermittlung in einem feldbusnetzwerk - Google Patents

Methode und adapter zur protokoll-ermittlung in einem feldbusnetzwerk Download PDF

Info

Publication number
DE60319704T2
DE60319704T2 DE60319704T DE60319704T DE60319704T2 DE 60319704 T2 DE60319704 T2 DE 60319704T2 DE 60319704 T DE60319704 T DE 60319704T DE 60319704 T DE60319704 T DE 60319704T DE 60319704 T2 DE60319704 T2 DE 60319704T2
Authority
DE
Germany
Prior art keywords
fieldbus
protocol
data
predefined
adapter
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60319704T
Other languages
English (en)
Other versions
DE60319704D1 (de
Inventor
Stig Lindemann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
P R ELECTRONICS AS
PR Electronics AS
Original Assignee
P R ELECTRONICS AS
PR Electronics AS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by P R ELECTRONICS AS, PR Electronics AS filed Critical P R ELECTRONICS AS
Application granted granted Critical
Publication of DE60319704D1 publication Critical patent/DE60319704D1/de
Publication of DE60319704T2 publication Critical patent/DE60319704T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/20Pc systems
    • G05B2219/25Pc structure of the system
    • G05B2219/25217Configure communication protocol, select between several

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Small-Scale Networks (AREA)
  • Radio Relay Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

  • GEBIET DER ERFINDUNG
  • Die Erfindung bezieht sich auf einen Adapter für einen Feldbus zum Übertragen und Empfangen von Steuerdaten aus einem Feldbusnetzwerk, in welchem Daten entsprechend einem spezifischen Feldbusprotokoll ausgetauscht werden. Der Adapter weist einen Sender zum Übertragen von Daten zu dem Feldbusnetzwerk und einen Empfänger zum Empfangen von Daten aus dem Feldbusnetzwerk auf. Die Erfindung bezieht sich ferner auf ein Verfahren zum Übertragen und Empfangen von Steuerdaten von einem Feldbusnetzwerk, wobei Daten gemäß einem spezifischen Feldbusprotokoll ausgetauscht werden. Das Verfahren umfasst den Schritt eines Übertragens von Daten zu dem Feldbusnetzwerk und den Schritt eines Empfangens von Daten von dem Feldbusnetzwerk. Die Erfindung bezieht sich auch auf ein Speichermedium, auf dem Befehle gespeichert sind zum Durchführen des Verfahrens zum Übertragen und Empfangen von Steuerdaten von einem Feldbusnetzwerk, in welchem Daten entsprechend einem spezifischen Feldbusprotokoll ausgetauscht werden. Das Verfahren umfasst den Schritt eines Übertragens von Daten zu dem Feldbusnetzwerk und den Schritt eines Empfangens von Daten von dem Feldbusnetzwerk.
  • HINTERGRUND DER ERFINDUNG
  • Kommunikationsnetzwerke, die Eingabe- und Ausgabevorrichtungen koppeln, werden zunehmend bei vielen verschiedenen Steuersystemen angewendet. Diese Eingabevorrichtungen und Ausgabevorrichtungen ermöglichen, dass die Steuerungen lokale Eingabe-/Ausgabe-(E/A-)Funktionen empfangen und verarbeiten, wie z. B. einen gemessenen physikalischen Wert, z. B. eine Temperatur. Die Vorrichtungen kommunizieren unter Verwendung einer Buskommunikation, die auch als Feldbusnetzwerkkommunikation bezeichnet wird.
  • Bei Steuersystemen ist es von großer Bedeutung, dass die Kommunikation zuverlässig und innerhalb kurzer Zeitintervalle erfolgt. Dies ist z. B. wichtig, weil schnelle und zuverlässige Daten oft ein Muss sind, um eine zufriedenstellende Steuerung zu erhalten. Deshalb werden an Ansprechzeiten bei der Feldbusnetzwerkkommunikation sehr strenge Anforderungen gestellt, die normalerweise viel strenger sind als die Anforderungen für die Kommunikation bei Standard-IT-Systemen.
  • In einem Feldbuskommunikationsnetzwerk kann eine Vielzahl unterschiedlicher Feldbuskommunikationsprotokolle verwendet werden, wobei die am häufigsten verwendeten Feldbustypen Profibus PA (PB) und Foundation Fieldbus (FF) sind. Normalerweise ist einem ge gebenen Steuersystem oder einem Netzwerk von Steuersystemen, die die gleiche Steuerungsart aufweisen, ein Protokoll zugeordnet.
  • Ein Adapter für einen Feldbus ist einem spezifischen Netzwerkprotokoll zugeordnet, so dass die Einheit nicht in Netzwerken verwendet werden kann, in denen ein anderes Kommunikationsprotokoll verwendet wird. Dadurch sind unterschiedliche Netzwerkschnittstelleneinheiten für jedes unterschiedliche Kommunikationsprotokoll erforderlich.
  • Die US 6151640 beschreibt ein Feldbusnetzwerk von Eingabe- und Ausgabevorrichtungen, die durch ein E/A-Schnittstellenmodul mit einem Steuersystem gekoppelt sind, unabhängig von ihren Datenstrukturen. Das E/A-Schnittstellenmodul ist durch einen seriellen Kommunikationsport mit dem Steuersystem gekoppelt. Lokale Eingabe- und Ausgabevorrichtungen sind durch eine lokale E/A-Schnittstelle mit dem Schnittstellen-E/A-Modul gekoppelt, und vernetzte Eingabe- und Ausgabevorrichtungen sind durch einen Feldbuskommunikationsadapter mit dem Schnittstellen-E/A-Modul gekoppelt. Bei diesem Beispiel ist ein anderer Adapter für jede Art von Feldbusprotokoll erforderlich, was das Problem nicht löst, dass spezifische Einheiten für spezifische Netzwerkprotokolle erforderlich sind.
  • Die EP 0906595 beschreibt eine Schaltung für die Kommunikation zwischen externen Feldvorrichtungen und einem Feldbus. Die Schaltung ist aufgebaut zum Erkennen des Protokolls und der Versorgungsspannungen der externen Feldvorrichtungen, die mit der Schaltung verbunden sind und über die Schaltung über den Feldbus kommunizieren. In der EP 0906595 wird nicht beschrieben, wie diese Protokollerkennung erfolgen könnte.
  • Um die strengen Anforderungen an Ansprechzeiten bei der Feldbusnetzwerkkommunikation zu erfüllen, ist es sehr wichtig, dass der Erkennungsprozess sehr schnell durchgeführt werden kann. Ferner sollte der Erkennungsprozess sehr geringe Anforderungen bezüglich der benötigten Ressourcen stellen, wodurch sowohl die Größe des Speichers in der Schaltung als auch die Anforderungen an die zentrale Verarbeitungseinheit (CPU) geringer sein können.
  • AUFGABE DER ERFINDUNG
  • Es ist Aufgabe der vorliegenden Erfindung, eine schnelle automatische Auswahl zwischen Feldbusprotokollen zu liefern und eine Kommunikation über den ausgewählten Feldbus durchzuführen. Dies wird gelöst durch einen Adapter für einen Feldbus zum Übertragen und Empfangen von Steuerdaten aus einem Feldbusnetzwerk, in welchem die Daten entsprechend einem spezifischen Feldbusprotokoll ausgetauscht werden, wobei der Adapter einen Sender zum Übertragen von Daten zu dem Feldbusnetzwerk und einen Empfänger zum Empfangen von Daten aus dem Feldbusnetzwerk aufweist, dadurch gekennzeichnet, dass der Adapter außerdem ein Erkennungsmittel für das Protokoll aufweist, welches zum Erkennen eines Feldbusprotokolls zwischen einer Anzahl von vordefinierten Feldbusprotokollen und für ein Konfigurieren des Empfängers und des Senders zum Kommunizieren entsprechend dem erkannten Feldbusprotokoll aufgebaut ist, wobei das Erkennungsmittel für das Protokoll aufweist:
    • – eine Einrichtung zum Empfangen von Daten von dem Feldbus,
    • – eine Einrichtung zum Feststellen, ob die empfangenen Daten in einer Datenbank gespeicherte vordefinierte Eigenschaften erfüllen, wobei diese Eigenschaften Daten lediglich eines einzigen aus der Anzahl der vordefinierten Feldbusprotokolle eindeutig identifizieren,
    • – eine Einrichtung für das Konfigurieren des Empfängers und des Senders zum Kommunizieren entsprechend dem besagten einen Protokoll, falls die empfangenen Daten die Eigenschaften erfüllen.
  • Durch das Vorliegen von Eigenschaften, die ein Protokoll aus einer Anzahl von vordefinierten Protokollen eindeutig identifizieren, kann das Protokoll ohne Weiteres identifiziert werden. Da die Eigenschaften nur ein Protokoll aus einer begrenzten Anzahl von vordefinierten Protokollen eindeutig identifizieren müssen, ist es einfacher, diese Eigenschaften zu erhalten, und dadurch wird das Feststellen, ob die empfangenen Daten die Eigenschaften erfüllen, einfach, und folglich erfordert der Erkennungsprozess wenige Ressourcen.
  • Ein weiterer Vorteil besteht darin, dass der gleiche Feldbusadapter mit einer Anzahl von unterschiedlichen Kommunikationsprotokollen kompatibel ist. Adapter, die unter Verwendung eines ersten Protokolls in einem Feldbusnetzwerk kommunizieren, können dann verwendet werden, um in einem anderen Feldbusnetzwerk unter Verwendung eines anderen Protokolls zu kommunizieren, oder das Protokoll, das in einem Feldbusnetzwerk verwendet wird, kann geändert werden, ohne die Adapter wechseln zu müssen. Dies macht den Adapter attraktiver für die potentiellen Käufer. Außerdem ist es für den Hersteller der Adapter von Vorteil, dass nur eine Fertigungslinie erforderlich ist statt mehrerer Fertigungslinien, die Adapter herstellen, die für jedes Feldbusprotokoll spezifisch sind. Der Adapter der vorliegenden Erfindung stellt auch eine Erleichterung für den Benutzer dar, da es nicht nötig ist, genau zu wissen, welches Feldbusprotokoll verwendet wird; vielmehr kann der Adapter angeschlossen werden, und dann wird das Feldbusprotokoll automatisch erkannt und verwendet.
  • Bei einem spezifischen Ausführungsbeispiel ist das Erkennungsmittel für das Protokoll für das Erkennen von zwei vordefinierten Feldbusprotokollen aufgebaut, die ein erstes und ein zweites vordefiniertes Feldbusprotokoll sind, wobei das Erkennungsmittel für das Protokoll aufweist:
    • – eine Einrichtung zum Empfangen von Daten von dem Feldbus,
    • – eine Einrichtung zum Feststellen, ob die empfangenen Daten die in einer Datenbank gespeicherten vordefinierten Eigenschaften erfüllen, wobei die Eigenschaften eindeutig Daten aus dem ersten Feldbusprotokoll identifizieren,
    • – eine Einrichtung zum Konfigurieren des Empfängers und des Senders zum Kommunizieren entsprechend dem ersten vordefinierten Protokoll, falls die empfangenen Daten die besagten Eigenschaften erfüllen,
    • – eine Einrichtung zum Konfigurieren des Empfängers und des Senders zum Kommunizieren entsprechend dem zweiten vordefinierten Protokoll, falls die empfangenen Daten die Eigenschaften nicht erfüllen.
  • Wenn das Erkennungsmittel nur feststellen muss, welches von zwei vordefinierten Protokollen in einem Feldbusnetzwerk verwendet wird, wird der Erkennungsprozess sehr einfach, da eine Erkennung nur gestützt auf ein Protokoll durchgeführt werden muss. Falls es sich nicht um das eine Protokoll handelt, dann ist es das andere Protokoll. Dieses Verfahren ist sehr einfach und erfordert wenige Ressourcen.
  • Bei einem Ausführungsbeispiel werden die Daten in Datenübertragungsblöcken empfangen, welche eine Anzahl von Feldern aufweisen, und wobei die Eigenschaften eindeutig Datenübertragungsblöcke von einem aus der Anzahl der vordefinierten Feldbusprotokolle identifizieren. Ein Protokoll wird normalerweise durch seine Datenübertragungsblockstruktur charakterisiert; deshalb kann durch Betrachten dieser Struktur der Protokolltyp auf eine einfache und schnelle Weise festgestellt werden.
  • Bei einem spezifischen Ausführungsbeispiel weisen die Eigenschaften, die eindeutig einen Datenübertragungsblock identifizieren, Eigenschaften des Inhalts von spezifischen Feldern in dem Datenübertragungsblock auf. Indem spezifische Felder betrachtet werden, können Eigenschaften, die mit dem Protokoll in Beziehung stehen, auf eine einfache Weise identifiziert werden.
  • Bei einem spezifischen Ausführungsbeispiel weisen die Eigenschaften, die eindeutig einen Datenübertragungsblock identifizieren, die Länge eines Datenübertragungsblocks auf. Die Eigenschaften, die mit einem spezifischen Protokoll in Beziehung stehen, könnten auch durch die Länge identifiziert werden. Dies könnte z. B. eine Ergänzung zu der Inhaltserkennung sein.
  • Bei einem Ausführungsbeispiel wird das vordefinierte Protokoll gestützt auf mehr als einen Datenübertragungsblock erkannt. Dies dient dazu, den Erkennungsprozess zu verbessern und dadurch die Möglichkeit einer fehlerhaften Erkennung zu verringern. Weiteres Wissen über übereinstimmende Datenübertragungsblöcke, die mit dem Protokoll in Beziehung stehen, könnten es auch erforderlich machen, Datenübertragungsblöcke zu prüfen, um ein Protokoll eindeutig zu identifizieren.
  • Bei einem weiteren Ausführungsbeispiel ist das erste Feldbusprotokoll ein Profibus PA, und das zweite Feldbusprotokoll ist ein Foundation Fieldbus. Diese beiden Protokolle werden sehr häufig in Feldbusnetzwerken verwendet.
  • Bei einem spezifischen Ausführungsbeispiel weisen die Eigenschaften, die eindeutig einen Profibus PA identifizieren, Eigenschaften des Inhalts des ersten Feldes in dem Datenübertragungsblock und der Länge des Datenübertragungsblocks auf. Es hat sich gezeigt, dass dies eine sehr effiziente Weise darstellt, einen Profibus-PA-Datenübertragungsblock eindeutig von einem Foundation-Fieldbus-Datenübertragungsblock zu unterscheiden.
  • Bei einem Ausführungsbeispiel stellen die zu übertragenden Steuerdaten einen Wert dar, der einen gemessenen physikalischen Wert repräsentiert. Bei dem physikalischen Wert könnte es sich um Temperatur, Geschwindigkeit und/oder Strecke handeln, und der physikalische Wert wird dann zum Steuern eines Prozesses verwendet, der durch eine Steuereinheit durchgeführt wird, die mit dem Feldbusnetzwerk verbunden ist.
  • Bei einem spezifischen Ausführungsbeispiel weist der Adapter eine Einrichtung zum Messen des physikalischen Wertes auf. Dadurch weist der Adapter die Messeinrichtung oder den Wandler auf, und der Adapter ist einem spezifischen Zweck zugeordnet, was es einfach macht, den Adapter zu installieren, und was es vereinfacht, den Adapter für den spezifischen Zweck zu optimieren.
  • Die Aufgabe der vorliegenden Erfindung wird auch durch ein Verfahren gelöst, das den Schritt eines Erkennens des Feldbusprotokolls und eines Konfigurierens des Empfängers und des Senders zum Kommunizieren entsprechend dem erkannten Feldbusprotokoll aufweist.
  • Bei einem spezifischen Ausführungsbeispiel wird der Schritt des Erkennens des Feldbusprotokolls und des Konfigurierens des Empfängers und des Senders zum Kommunizieren entsprechend dem erkannten Feldbusprotokoll nur in einer Initialisierungsphase vor dem Senden und Empfangen von Steuerdaten über das Feldbusnetzwerk durchgeführt. Dadurch können die Erkennungsdaten schneller verarbeitet werden, da kein Erkennungsprozess durchgeführt werden muss.
  • Bei einem weiteren Ausführungsbeispiel wird der Schritt des Erkennens des Feldbusprotokolls periodisch in vordefinierten Intervallen durchgeführt. Dadurch kann das verwendete Protokoll in einem Feldbusnetzwerk geändert werden, und das Verfahren passt das Übertragungs- und Empfangsformat an das neue Protokoll an.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Im Folgenden werden bevorzugte Ausführungsbeispiele der Erfindung unter Bezugnahme auf die Figuren beschrieben. Es zeigen:
  • 1 eine Anzahl von Adapter für einen Feldbus, die mit einem Feldbusnetzwerk verbunden sind;
  • 2 ein Flussdiagramm, das den Schritt des Kommunizierens über ein Feldbussystem unter Verwendung unterschiedlicher Feldbusprotokolle und eines Erkennungsmittels für das Protokoll veranschaulicht;
  • 3 ein Flussdiagramm, das den Schritt des Erkennens eines Protokolls veranschaulicht;
  • 4 ein Flussdiagramm, das den Schritt des Erkennens der Feldbusprotokolle Foundation Fieldbus und Profibus PA veranschaulicht;
  • 5 eine Tabelle der Sicherungsschicht-Nachrichtenstruktur bei Foundation Fieldbus;
  • 68 einen Vergleich von spezifischen Datenübertragungsblöcken bei Profibus PA bzw. Foundation Fieldbus; und
  • 9 die unterschiedlichen Elemente bei einem Ausführungsbeispiel eines Adapters für einen Feldbus.
  • BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSBEISPIELE
  • 1 zeigt ein Beispiel für ein Steuersystem. Das Steuersystem weist eine Anzahl von Adaptern 101 für einen Feldbus auf, die über ein Feldbusnetzwerk 103 kommunizieren. Die Feldbusadapter könnten mit einer Anzahl von unterschiedlichen Arten von Wandlern zum Messen physikalischer Werte, wie z. B. Temperatur, Geschwindigkeit und/oder Strecke, verbunden sein. Diese Messwerte werden über einen Übertragungskanal 107 über das Feldbusnetzwerk z. B. zu einem Steuercomputer übertragen, wobei der Steuercomputer die empfangenen Werte z. B. zum Steuern eines Prozesses verwenden könnte. Die Adapter 101 können auch (über einen Kanal 105) Informationen empfangen, z. B. ein Steuersignal, das anzeigt, dass der physikalische Wert gemessen und übertragen werden soll.
  • Wenn über ein Feldbusnetzwerk kommuniziert wird, können unterschiedliche Kommunikationsprotokolle verwendet werden, und Beispiele für Feldbuskommunikationsprotokolle sind Profibus PA and Foundation Fieldbus. Normalerweise wird ein Protokoll ausgewählt, wenn das Steuersystem konfiguriert wird, und dann verwenden alle Vorrichtungen, die über das Feldbusnetzwerk kommunizieren, das ausgewählte Protokoll. Alternativ dazu könnte die Protokollerkennung in einem Feldbusnetzwerk verwendet werden, in dem verschiedene Protokolle in dem gleichen Netzwerk verwendet werden. In diesem Fall erkennt das Erkennungsmittel für das Protokoll das Protokoll jedes Mal, wenn Daten empfangen werden, und verarbeitet die Daten entsprechend dem erkannten Protokoll.
  • 2 ist ein Flussdiagramm, das den Schritt des automatischen Erkennens eines Protokolls veranschaulicht. Der Adapter für einen Feldbus ist mit einem Feldbusnetzwerk verbunden, und bei 201 empfangt der Adapter über das Feldbusnetzwerk ein Datenpaket. Das Datenpaket könnte entweder ein Paket sein, das für den spezifischen Feldbusadapter bestimmt ist, oder es könnte sich um ein beliebiges Paket handeln, das über das Feldbusnetzwerk übertragen wird. Bei 203 prüft der Adapter das Paket und erkennt das Protokoll. Das Protokoll könnte z. B. durch ein Prüfen des Datenübertragungsblocks des empfangenen Datenpakets bestimmt werden, der das Protokoll eindeutig identifiziert; wenn z. B. entsprechend dem Protokoll Profibus PA kommuniziert wird, unterscheidet sich ein Block von dem Block, der verwendet wird, wenn entsprechend dem Foundation-Fieldbus-Protokoll kommuniziert wird. Informationen über jedes Protokoll könnten in dem Feldbusadapter gespeichert sein, und diese Informatio nen können dann mit den Informationen verglichen werden, die durch das Prüfen des Blocks des empfangenen Datenpakets erhalten werden, wodurch das Protokoll identifiziert werden kann.
  • Bei 205 wird das Ergebnis der Prüfung bei 203 verwendet, um den nächsten Schritt im Algorithmus zu bestimmen, und falls das Protokoll als ein Protokoll erkannt wurde, das als T1 bezeichnet wird, dann werden bei 207 die Befehle aus dem Paket entsprechend Regeln extrahiert, die durch das Protokoll T1 definiert sind. Bei 209 werden Aktionen entsprechend den extrahierten Befehlen durchgeführt, und bei 211 wird die gesamte weitere Kommunikation über das Feldbusnetzwerk entsprechend dem erkannten Protokoll T1 durchgeführt. Die weitere Kommunikation könnte durchgeführt werden durch ein Empfangen eines Datenpakets über das Feldbusnetzwerk, ein Extrahieren von Informationen entsprechend T1 und ein Durchführen einer Aktion entsprechend den extrahierten Informationen. Bei der weiteren Kommunikation könnte es sich auch um ein Codieren von zu übertragenden Befehlen unter Verwendung des Protokolls T1 und dann ein Übertragen der codierten Befehle handeln. Falls das Protokoll als ein Protokoll erkannt wurde, das als T2 bezeichnet wird, dann werden bei 215 die Befehle aus dem Paket entsprechend Regeln extrahiert, die durch das Protokoll T2 definiert sind. Bei 217 werden Aktionen entsprechend den extrahierten Befehlen durchgeführt, und bei 219 wird die gesamte weitere Kommunikation über das Feldbusnetzwerk entsprechend dem erkannten Protokoll T2 durchgeführt. Die weitere Kommunikation könnte in diesem Fall auch durch ein Empfangen eines Datenpakets über das Feldbusnetzwerk, ein Extrahieren von Informationen entsprechend T2 und ein Durchführen einer Aktion entsprechend den extrahierten Informationen durchgeführt werden. Bei der weiteren Kommunikation könnte es sich auch um ein Codieren von zu übertragenden Befehlen unter Verwendung des Protokolls T2 und dann ein Übertragen der codierten Befehle handeln. T2 und T1 könnten z. B. Profibus PA bzw. Foundation Fieldbus sein.
  • Eine weitere Möglichkeit besteht darin, dass es bei 203 nicht möglich ist, das Protokoll zu erkennen, was an einem Fehler bei dem empfangenen Datenpaket liegen könnte, und somit wird der Erkennungsprozess unter Verwendung eines neuen Datenpakets für die Protokollerkennung neu begonnen.
  • In 3 veranschaulicht ein Flussdiagramm den Schritt des Erkennens eines Protokolls gemäß der vorliegenden Erfindung. Zuerst wird bei 301 ein empfangener Datenübertragungsblock DF geprüft, um festzustellen, ob die empfangenen Daten einen gültigen Datenübertragungsblock darstellen; dies könnte z. B. entsprechend einer Prüfsumme erfolgen. Wenn festgestellt wird, dass die empfangenen Daten keinen gültigen Datenübertragungsblock darstel len, dann wird der Erkennungsprozess gestoppt 303. Nach 303 wurde festgestellt, dass der empfangene Datenübertragungsblock ein gültiger Datenübertragungsblock ist, und der Prozess des Erkennens des Protokolltyps oder -formats kann beginnen. Eigenschaften IDP eines Datenübertragungsblocks, die nur für ein Protokoll, das als T1 bezeichnet wird, eindeutig sind, wurden vorab in einer Datenbank gespeichert, und diese Eigenschaften werden bei 305 mit dem empfangenen Datenübertragungsblock DF verglichen. Wie es bei 307 dargestellt ist, wird, wenn der Datenübertragungsblock DF die gleichen Eigenschaften aufweist wie die Eigenschaften IDPT1, die T1 eindeutig identifizieren, der empfangene Datenübertragungsblock entsprechend dem T1-Protokoll übertragen, ansonsten wird derselbe nicht entsprechend dem T1-Protokoll übertragen.
  • Wenn festgestellt wurde, dass der empfangene Datenübertragungsblock nicht entsprechend dem Protokoll T1 übertragen wurde, dann wird bei 309 der empfangene Datenübertragungsblock DF mit Eigenschaften IDPT2 verglichen, die einen Datenübertragungsblock eindeutig identifizieren, der entsprechend einem zweiten Protokoll T2 übertragen wird. Wieder wird, wie bei 311 gezeigt, falls der Datenübertragungsblock DF die gleichen Eigenschaften aufweist wie die Eigenschaften IDPT2, die T2 eindeutig identifizieren, der empfangene Datenübertragungsblock entsprechend dem T2-Protokoll übertragen, ansonsten wird derselbe nicht entsprechend dem T2-Protokoll übertragen.
  • Wenn festgestellt wurde, dass der empfangene Datenübertragungsblock nicht entsprechend dem Protokoll T1 oder T2 übertragen wurde, dann wird bei 313 der empfangene Datenübertragungsblock DF mit Eigenschaften IDPT3 verglichen, die einen Datenübertragungsblock eindeutig identifizieren, der entsprechend einem dritten Protokoll T3 übertragen wird. Wieder wird, wenn der Datenübertragungsblock DF die gleichen Eigenschaften aufweist wie die Eigenschaften IDPT3, die T3 eindeutig identifizieren, der empfangene Datenübertragungsblock entsprechend dem T3-Protokoll übertragen, ansonsten wird derselbe nicht entsprechend dem T3-Protokoll übertragen.
  • Der Prozess kann dann für eine Anzahl von Protokollen wiederholt werden, solange es Eigenschaften gibt, die ein Protokoll T4 bzgl. einer verbleibenden Anzahl von vordefinierten Protokollen T5 -> eindeutig identifizieren. Wenn z. B. 5 Protokolle (T1, T2, T3, T4, T5) zu erkennen sind, dann muss das erste zu erkennende Protokoll T1 gestützt auf Eigenschaften IDPT1 erkannt werden, die T1 bezüglich der Protokolle (T2, T3, T4, T5) eindeutig identifizieren; das zweite zu erkennende Protokoll T2 muss gestützt auf Eigenschaften IDPT2 erkannt werden, die T2 bezüglich der Protokolle (T3, T4, T5) eindeutig identifizieren; das dritte zu erkennende Protokoll T3 muss gestützt auf Eigenschaften IDPT3 erkannt werden, die T3 bezüglich der Protokolle (T4, T5) eindeutig identifizieren; das vierte zu erkennende Protokoll T4 muss gestützt auf Eigenschaften IDPT4 erkannt werden, die T4 bezüglich des Protokolls T5 eindeutig identifizieren. Da die Gültigkeit des Datenübertragungsblocks bereits bei 301 geprüft wurde, kann schließlich, falls bekannt ist, dass nur die fünf Protokolle (T1, T2, T3, T4, T5) in dem Netzwerk verwendet werden, automatisch festgestellt werden, dass, wenn das Protokoll als keines von (T1, T2, T3, T4) erkannt werden kann, es sich um ein T5-Protokoll handeln muss, und dadurch ist das T5-Protokoll erkannt.
  • Die Reihenfolge, in der die Erkennung durchgeführt wird, könnte darauf basieren, ob es möglich ist, ein Protokoll eindeutig von anderen Protokollen zu unterscheiden, oder auf der Menge an Ressourcen, die benötigt wird, um ein Protokoll eindeutig zu identifizieren, und wenn ein Protokoll z. B. starke Eigenschaften aufweist, die ohne Weiteres aus der Gruppe von möglichen Protokollen eindeutig identifiziert werden können, dann könnte es von Interesse sein, dieses Protokoll anfangs zu erkennen. Ferner könnte, wenn ein Protokoll schwache Eigenschaften aufweist, die Identifikation in einem späten Schritt erfolgen, um sicherzustellen, dass das Protokoll nur aus einer kleinen Gruppe von Protokollen eindeutig identifiziert werden muss.
  • Andere Kriterien, die für die Erkennungsreihenfolge zu verwenden sind, könnten sich auf das Wissen stützen, welches Protokoll am häufigsten in dem Feldbusnetzwerk verwendet wird. Es ist von Interesse, dieses Protokoll anfangs zu erkennen, wodurch eine Menge Erkennungsschritte eingespart werden können und die Erkennung auf eine Weise durchgeführt wird, die den Bedarf an Zeit und Ressourcen minimiert, wobei es sich bei Feldbussystemen um entscheidende Faktoren handeln kann.
  • In 4 veranschaulicht ein Flussdiagramm ein spezifisches Beispiel für das Erkennen der Feldbusprotokolle Foundation Fieldbus und Profibus PA. Zuerst wird bei 401 ein empfangener Datenübertragungsblock DF geprüft, um festzustellen, ob die empfangenen Daten einen gültigen Datenübertragungsblock darstellen; dies erfolgt gemäß einer Prüfsumme, die sich sowohl für Profibus PA als auch für Foundation Fieldbus auf ein ähnliches Prinzip stützt. Wenn festgestellt wird, dass es sich bei den empfangenen Daten nicht um einen gültigen Datenübertragungsblock handelt, dann wird der Erkennungsprozess gestoppt 403. Nach 401 wurde festgestellt, dass der empfangene Datenübertragungsblock ein gültiger Datenübertragungsblock ist, und der Prozess des Erkennens des Protokolltyps oder -formats kann beginnen. Eigenschaften IDPPB eines Datenübertragungsblocks, die nur für das Profibus-PA-Protokoll eindeutig sind, wurden vorab in einer Datenbank gespeichert, und diese Eigenschaften werden bei 405 mit dem empfangenen Datenübertragungsblock DF verglichen. Wie es bei 407 gezeigt ist, wird, wenn der Datenübertragungsblock DF die gleichen Eigenschaften aufweist wie die Eigenschaften IDPPB, die den Profibus PA eindeutig identifizieren, der empfangene Datenübertragungsblock entsprechend dem Profibus-PA-Protokoll übertragen, ansonsten wird derselbe entsprechend dem Foundation-Fieldbus-Protokoll übertragen.
  • Bei den Eigenschaften könnte es sich z. B. um einen Satz von Erkennungsregeln handeln, und wenn diese Regeln erfüllt sind, dann ist ein Protokoll eindeutig identifiziert. Im Folgenden wird ein Beispiel für Regeln präsentiert, die verwendet werden, um ein Profibus-PA-Protokoll zu identifizieren.
  • Um Eigenschaften der zu verwendenden Regeln zu definieren, ist es nötig, die Datenübertragungsblöcke zu betrachten, die sowohl bei Profibus PA als auch bei Foundation Fieldbus verwendet werden.
  • Das Profibus-PA-Datenübertragungsblockformat, das in der Profibus-DLL(Sicherungsschicht)-Spezifikation spezifiziert ist, ist gültig, wenn das physische Medium RS-485 ist. Für MBP-(Manchester Bus Powered)Medien-Anfangsblöcke, SD, FCS und ED werden Oktette im Segmentkoppler hinzugefügt. Die ursprünglichen FCS und ED werden entfernt, da sie nicht mehr benötigt werden. Der ursprüngliche SD wird nicht entfernt, da derselbe eine Informationsfunktion bezüglich der Länge des Blocks hat. Die vier gültigen SDs sind:
    • – SD1 (10H) Blöcke fester Länge ohne Datenfeld, auf einen SD1 folgen immer 3 Oktette: DA = Zieladresse, SA = Ursprungsadresse, FC = Funktionssteuerung.
    • – SD2 (68H) Blöcke variabler Datenfeldlänge, auf einen SD2 folgen immer: LE, LEr, SD2, DA, SA, FC und einige Dateneinheiten, wobei: LE = Oktettlänge, zulässige Werte: 4 bis 249 LEr = Oktettlänge, wiederholt
    • – SD3 (A2H) Blöcke fester Länge mit Datenfeld, auf einen SD3 folgen immer: DA, SA, FC und 8 Daten_Einheiten (Oktette).
    • – SD4 (DCH) Token-Block, auf einen SD4 folgen immer 2 Oktette: DA, SA.
  • Wenn der Block nur ein Oktett enthält, handelt es sich um „E5H", bezeichnet als SC (= Einzelzeichen).
  • Das Foundation-Fieldbus-(FF)Datenübertragungsblockformat ist in der Fieldbus-DLL-Spezifikation (die sich auf IEC 61158-4 bezieht) spezifiziert als Kommunikation über die MBP-Medien (H1-Netzwerk). Ein FF-Datenübertragungsblock beginnt immer mit einem Blocksteuerung-FC-Feld. Die gültigen FC-Werte sind in der Tabelle mit der Sicherungsschicht-Nachrichtenstruktur in 5 spezifiziert. Die Parameter der Tabelle sind im Folgenden erläutert:
    • L – gibt die Länge der Adressen an, die in der Nachricht verwendet werden (0 = kurz, 1 = lang).
    • F – gibt an, dass das Token nicht mehr verwendet wird. Die Vorrichtung gibt das Token an den LAS zurück.
    • PP – gibt die Priorität der Nachricht an (dringend, normal, verfügbare Zeit).
    • _ – gibt an, dass das Feld nicht verwendet wird.
    • [HL.]N.S – Die Adressbytes. Falls L gleich 1 ist, liegen lange Adressen vor, deren Länge 4 Byte beträgt (HLNS), aber falls L gleich 0 ist, liegen kurze Adressen vor, deren Länge 2 Byte beträgt (NS).
    • N – gibt an, dass die Adresse 1 Byte beträgt, nur mit der Knoteninformation (Knotenadresse).
    • N.0 – zeigt die kurze Adresse an, wenn das erste Byte den Knoten enthält (Knotenadresse) und das zweite Byte Null ist.
    • [PDA] – Die Ursprungsadresse. Falls die Nachricht keine Zieladresse hat. Diese Adressierweise wird normalerweise bei der Informationsberichtnachricht verwendet.
    • [PSA] – die Zieladresse.
    • o- – zeigt an, dass das Feld optional ist.
    • xx-p – gibt die Parameterklasse der DLL an (z. B. Zeitverteilung, Sondenknoten usw.) DLSDU – Parameter der DL-Dienstdateneinheit.
    • SPDU – Parameter der Unterstützungsprotokolldateneinheit. Es handelt sich dabei um die Parameter von den anderen Schichten des Protokolls (FMS, SM und FAS).
  • Es ist interessant, das erste Feld jedes Protokolldatenübertragungsblocks zu vergleichen, um zu sehen, ob ein Protokoll eindeutig identifiziert werden könnte, indem nur dieses erste Feld betrachtet wird. Durch ein Vergleichen der Datenübertragungsblöcke von Profibus und Foundation Fieldbus wird deutlich, dass das FF-Blocksteuerungsfeld unter den folgenden Bedingungen mit dem Profibus-SD-Feld in Konflikt gerät:
    • – SD1 (10H)/CT – Falls die FC eine CT ohne Rückgabe des Tokens ist, ist der Oktettwert 10H. Der Konflikt kann gelöst werden, indem auch die Blocklänge geprüft wird, da die Länge einer CT immer nur ein Oktett beträgt, siehe 7.
    • – SD2 (68H)/DC2, falls die FC eine DC2 mit langen Adressen und ohne Token-Rückgabe ist, ist der Wert 68H. Dieser Konflikt kann nicht mit 100%iger Sicherheit gelöst werden, aber das Risiko einer Fehlinterpretation kann minimiert werden, indem so viele bekannte Werte wie möglich geprüft werden: • Die beiden LE-Oktette müssen den gleichen Wert (im Bereich von 4–249) aufweisen, und das Knotenoktett 68H. Die Länge des Blocks muss auch mit dem LE-Wert zusammenpassen. Theoretisch stimmt ein FF-Block bei einer von 16 Millionen DC2-Blockkombinationen mit diesem Format überein, siehe 8.
    • – SD4 (DCH)/DT1, falls die FC eine DT1 mit einer langen Adresse, Token-Rückgabe und PP = 00 (Priorität) ist, ist der Wert DCH. Der Konflikt kann gelöst werden, indem die Blocklänge geprüft wird, da die FF-DT1 mit einer langen Adresse immer mehr als die 3 Oktette in dem Profibus-SD4-Block enthält, siehe 9.
  • Entsprechend den obigen Ausführungen können die folgenden Erkennungsregeln verwendet werden, um das Profibus-PA-Protokollformat, das das erkennbarere der beiden ist, eindeutig zu identifizieren.
  • Es kann mittels 5 Regeln erkannt werden. Diese 5 Regeln sollten dann alle möglichen Profibus-PA-Blöcke repräsentieren und keinen der möglichen FF-Blöcke akzeptieren. Da dies nicht 100%ig möglich ist (wegen SD2/DC2), muss der Test an mehr als einem Datenübertragungsblock wiederholt werden, und die Mehrzahl der Ergebnisse bestimmt dann den Protokolltyp. Dies sollte ein 100%ig sicheres Ergebnis liefern, da der FF-DC2-Block kein Blocktyp ist, der vom Publisher wiederholt werden soll. Regel Nr. 1
    Oktettposition Oktettdaten Kommentare
    1 10H SD1
    2 XX Zieladresse
    3 XX Ursprungsadresse
    4 XX FC (Blocksteuerung)
    Anzahl von Oktetten 4 immer die genannten 4 Oktette
    Regel Nr. 2
    Oktettposition Oktettdaten Kommentare
    1 68H SD2
    2 4–249D LE (Blocklänge)
    3 wie Pos. 2 LEr (Blocklänge, wiederholt)
    4 68H SD2 wiederholt
    Anzahl von Oktetten LE + 4
    Regel Nr. 3
    Oktettposition Oktettdaten Kommentare
    1 A2H SD3
    2 XX Zieladresse
    3 XX Ursprungsadresse
    4 XX FC (Blocksteuerung)
    Anzahl von Oktetten 12 immer genannte 4 Oktette + 8 Daten_Einheiten
    Regel Nr. 4
    Oktettposition Oktettdaten Kommentare
    1 DCH SD4
    2 XX Zieladresse
    3 XX Ursprungsadresse
    Anzahl von Oktetten 3 immer die genannten 3 Oktette
    Regel Nr. 5
    Oktettposition Oktettdaten Kommentare
    1 E5H SC (Einzelzeichen)
    Anzahl von Oktetten 1 immer das genannte 1 Oktett
  • Durch Prüfen der ersten Oktetts des empfangenen Blocks ist es möglich festzustellen, welche (falls überhaupt eine) der 5 Regeln relevant für die Prüfung ist. Falls keine der Regeln komplett eingehalten wird, wird der Block als ein FF-Datenübertragungsblock definiert.
  • In 9 ist ein Ausführungsbeispiel eines Adapters für einen Feldbus veranschaulicht, das die verschiedenen Elemente bei einem Adapter für einen Feldbus zeigt. Der Adapter für einen Feldbus ist über einen Empfänger 903 und einen Sender 911 mit dem Feldbusnetzwerk 901 verbunden. Der Empfänger könnte dann mit einer Analogfiltereinheit 905 zum Filtern und Wiederherstellen des empfangenen Datenpakets verbunden sein. Die empfangenen Daten sind dann bereit zur Verarbeitung gemäß dem Algorithmus, der in 2 gezeigt ist, wobei ein Mikrocomputer 907 die Schritte des Erkennens des Protokolls gemäß 203 und 205, die in 2 gezeigt sind, durchführen könnte. Der Mikrocomputer könnte einen Mikroprozessor 913 und einen Speicher 915 aufweisen, die über einen Kommunikationsbus 917 kommunizieren. Der Adapter für einen Feldbus könnte auch aufgebaut sein zum Empfangen von Daten von unterschiedlichen Arten von Wandlern zum Messen physikalischer Werte, wie z. B. Temperatur, Geschwindigkeit und/oder Strecke, und die empfangenen Daten sind dann der gemessene physikalische Wert. Bei einem Ausführungsbeispiel ist der Wandler mit dem Mikrocomputer 907 in dem Feldbusadapter über eine Analogfiltereinheit zum Filtern und Wiederherstellen der Daten, die von dem Wandler empfangen werden, verbunden.

Claims (15)

  1. Adapter (101) für einen Feldbus zum Übertragen und Empfangen von Steuerdaten aus einem Feldbusnetzwerk (103, 901), in welchem die Daten entsprechend einem spezifischen Feldbusprotokoll ausgetauscht werden, wobei der Adapter einen Sender (911) zum Übertragen von Daten zu dem Feldbusnetzwerk und einen Empfänger (903) zum Empfangen von Daten aus dem Feldbusnetzwerk aufweist, dadurch gekennzeichnet, dass der Adapter außerdem ein Erkennungsmittel für das Protokoll aufweist, welches zum Erkennen eines Feldbusprotokolls zwischen einer Anzahl von vordefinierten Feldbusprotokollen und für ein Konfigurieren des Empfängers und des Senders zum Kommunizieren entsprechend dem erkannten Feldbusprotokoll aufgebaut ist, wobei das Erkennungsmittel für das Protokoll aufweist: – eine Einrichtung zum Empfangen von Daten von dem Feldbus, – eine Einrichtung zum Feststellen, ob die empfangenen Daten in einer Datenbank gespeicherte vordefinierte Eigenschaften erfüllen, wobei diese Eigenschaften Daten lediglich eines einzigen aus der Anzahl der vordefinierten Feldbusprotokolle eindeutig identifizieren, eine Einrichtung für das Konfigurieren des Empfängers und des Senders zum Kommunizieren entsprechend dem besagten einen Protokoll, falls die empfangenen Daten die Eigenschaften erfüllen.
  2. Adapter nach Anspruch 1 für einen Feldbus, in welchem das Erkennungsmittel für das Protokoll für das Erkennen von zwei vordefinierten Feldbusprotokollen aufgebaut ist, die ein erstes und ein zweites vordefiniertes Feldbusprotokoll sind, wobei das Erkennungsmittel für das Protokoll aufweist: – eine Einrichtung zum Empfangen von Daten von dem Feldbus, – eine Einrichtung zum Festhalten, ob die empfangenen Daten die in einer Datenbank gespeicherten vordefinierten Eigenschaften erfüllen, wobei die Eigenschaften eindeutig Daten aus dem ersten Feldbusprotokoll identifizieren, – eine Einrichtung zum Konfigurieren des Empfängers und des Senders zum Kommunizieren entsprechend dem ersten vordefinierten Protokoll, falls die empfangenen Daten die besagten Eigenschaften erfüllen, eine Einrichtung zum Konfigurieren des Empfängers und des Senders zum Kommunizieren entsprechend dem zweiten vordefinierten Protokoll, falls die empfangenen Daten die Eigenschaften nicht erfüllen.
  3. Adapter entsprechend Anspruch 1 oder 2 für einen Feldbus, in welchem die Daten in Datenübertragungsblöcken empfangen werden, welche eine Anzahl von Feldern aufweisen, und in welchem die Eigenschaften eindeutig Datenübertragungsblöcke von einem aus der Anzahl der vordefinierten Feldbusprotokolle identifizieren.
  4. Adapter nach Anspruch 3 für einen Feldbus, in welchem die Eigenschaften, die eindeutig einen Datenübertragungsblock identifizieren, Eigenschaften des Inhalts von spezifischen Feldern in dem Datenübertragungsblock aufweisen.
  5. Adapter nach Anspruch 3 oder 4 für einen Feldbus, in welchem die Eigenschaften, die eindeutig einen Datenübertragungsblock identifizieren, Eigenschaften der Länge eines Datenübertragungsblocks aufweisen.
  6. Adapter nach einem der Ansprüche 3 bis 5 für einen Feldbus, in welchem das vordefinierte Protokoll gestützt auf mehr als einen Datenübertragungsblock erkannt wird.
  7. Adapter nach einem der Ansprüche 2 bis 5 für einen Feldbus, in welchem das erste Feldbusprotokoll ein Profibus und das zweite Feldbusprotokoll ein Foundation Fieldbus ist.
  8. Adapter nach Anspruch 7 für einen Feldbus, in welchem die Eigenschaften, die eindeutig einen Foundation Fieldbus identifizieren, Eigenschaften des Inhalts des ersten Feldes in dem Datenübertragungsblock und der Länge des Datenübertragungsblocks aufweisen.
  9. Adapter nach einem der Ansprüche 1 bis 8 für einen Feldbus, in welchem die zu übertragenden Steuerdaten einen Wert darstellen, der einen gemessenen physikalischen Wert repräsentiert.
  10. Adapter nach Anspruch 1 bis 9 für einen Feldbus, in welchem der Adapter eine Einrichtung zum Messen des physikalischen Wertes aufweist.
  11. Verfahren zum Übertragen und Empfangen von Steuerdaten durch einen Adapter (101) für einen Feldbus von einem Feldbusnetzwerk (103, 901), wobei Daten gemäß einem spezifischen Feldbusprotokoll ausgetauscht werden, wobei der Adapter einen Sender (911) zum Übertragen der Daten an das Feldbusnetzwerk und einen Empfänger (911) zum Empfangen von Daten aus dem Feldbusnetzwerk aufweist, dadurch gekennzeichnet, dass der Adapter außerdem ein Erkennungsmittel für ein Protokoll aufweist, welches zum Erkennen eines Feldbusprotokolls zwischen einer Anzahl von vordefinierten Feldbusprotokollen und für das Konfigurieren des Empfängers und des Senders, zum Kommunizieren entsprechend dem erkannten Feldbusprotokoll aufgebaut ist, wobei das Verfahren aufweist: – das Empfangen von Daten von dem Feldbus, – das Feststellen, ob die empfangenen Daten in einer Datenbank gespeicherte vordefinierte Eigenschaften erfüllen, wobei diese Eigenschaften Daten lediglich eines einzigen aus der Anzahl von vordefinierten Feldbusprotokollen eindeutig identifizieren, – das Konfigurieren des Empfängers und des Senders zum Kommunizieren entsprechend dem besagten einen Protokoll, falls die empfangenen Daten die Eigenschaften erfüllen.
  12. Verfahren nach Anspruch 11 zum Erkennen von zwei vordefinierten Feldbusprotokollen, die ein erstes und ein zweites vordefiniertes Feldbusprotokoll sind, aufweisend: – das Empfangen von Daten von dem Feldbus, – das Feststellen, ob die empfangenen Daten in einer Datenbank gespeicherte vordefinierte Eigenschaften erfüllen, wobei die Eigenschaften eindeutig Daten aus dem ersten Feldbusprotokoll identifizieren, – das Konfigurieren des Empfängers und des Senders zum Kommunizieren entsprechend dem ersten vordefinierten Protokoll, falls die empfangenen Daten die besagten Eigenschaften erfüllen, – das Konfigurieren des Empfängers und des Senders zum Kommunizieren entsprechend dem zweiten vordefinierten Protokoll, falls die empfangen Daten die besagten Eigenschaften nicht erfüllen.
  13. Verfahren nach Anspruch 11 oder 12, in welchem der Schritt des Erkennens des Feldbusprotokolls und des Konfigurierens des Empfängers und des Senders zum Kommunizieren entsprechend zu dem erkannten Feldbusprotokoll nur in einer Initialisierungsphase vor dem Senden und Empfangen von Steuerdaten über das Feldbusnetzwerk durchgeführt wird.
  14. Verfahren nach Anspruch 11 oder 12, in welchem der Schritt des Erkennens des Feldbusprotokolls periodisch in vordefinierten Intervallen durchgeführt wird.
  15. Speichermedium mit einem auf diesem gespeicherten Computerprogramm, welches Befehle zum Durchführen des Verfahrens nach den Ansprüchen 11 bis 14 aufweist, wenn es auf einem Computer lauft.
DE60319704T 2002-06-25 2003-01-20 Methode und adapter zur protokoll-ermittlung in einem feldbusnetzwerk Expired - Lifetime DE60319704T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DK200200978 2002-06-25
DKPA200200978 2002-06-25
PCT/DK2003/000034 WO2003039098A2 (en) 2002-06-25 2003-01-20 Method and adapter for protocol detection in a field bus network

Publications (2)

Publication Number Publication Date
DE60319704D1 DE60319704D1 (de) 2008-04-24
DE60319704T2 true DE60319704T2 (de) 2009-03-26

Family

ID=8161245

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60319704T Expired - Lifetime DE60319704T2 (de) 2002-06-25 2003-01-20 Methode und adapter zur protokoll-ermittlung in einem feldbusnetzwerk

Country Status (7)

Country Link
US (1) US20050232305A1 (de)
EP (1) EP1522178B1 (de)
AT (1) ATE389290T1 (de)
AU (1) AU2003204296A1 (de)
DE (1) DE60319704T2 (de)
DK (1) DK1522178T3 (de)
WO (1) WO2003039098A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102010030811A1 (de) * 2010-07-01 2012-01-05 Endress + Hauser Flowtec Ag Automatisierte Adaption an verschiedene Industrial Ethernet Protokolle

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7032045B2 (en) 2001-09-18 2006-04-18 Invensys Systems, Inc. Multi-protocol bus device
GB0329726D0 (en) * 2003-12-22 2004-01-28 Qinetiq Ltd Communication data analysis system
CN100426165C (zh) * 2004-05-20 2008-10-15 章近达 设备管理网络监控系统
DE502005001819D1 (de) * 2005-01-28 2007-12-13 Siemens Ag Verfahren und System zur Übertragung von Telegrammen
JP5115101B2 (ja) * 2007-08-30 2013-01-09 横河電機株式会社 フィールド装置及びフィールドバスコントローラ
DE102007054810A1 (de) * 2007-11-16 2009-05-20 Robert Bosch Gmbh Verfahren zum Erkennen unterschiedlicher Kommunikationsprotokolle in einem Steuergerät
EP2187571B1 (de) * 2008-11-12 2011-06-15 VEGA Grieshaber KG Generieren einer Gerätebeschreibung für ein Messgerät
JP4766349B2 (ja) * 2008-12-05 2011-09-07 横河電機株式会社 フィールド機器
US20100306232A1 (en) * 2009-05-28 2010-12-02 Harris Corporation Multimedia system providing database of shared text comment data indexed to video source data and related methods
CN102158882B (zh) * 2011-05-27 2014-07-09 重庆邮电大学 一种基于6LowPAN的两信道数据检测与协议分析仪及方法
DE102011117083A1 (de) * 2011-10-27 2013-05-02 Volkswagen Aktiengesellschaft Slave-Steuergerät und Verfahren zur Programmierung eines Slave-Steuergeräts
US9430429B2 (en) * 2012-05-07 2016-08-30 Bristol, Inc. Methods and apparatus to identify a communication protocol being used in a process control system
US9167382B2 (en) * 2014-03-10 2015-10-20 Interlite Aktiebolag Method and system for wireless communication

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0596648A1 (de) * 1992-11-02 1994-05-11 National Semiconductor Corporation Erkennung du Fähigkeiten eines Netzendpunkts
US5613096A (en) * 1994-11-04 1997-03-18 Canon Information Systems, Inc. Network protocol sensor
US5546211A (en) * 1995-06-13 1996-08-13 Apple Computer, Inc. Method and apparatus for multi-protocol infrared data transmission
US5742602A (en) * 1995-07-12 1998-04-21 Compaq Computer Corporation Adaptive repeater system
US6122287A (en) * 1996-02-09 2000-09-19 Microcom Systems, Inc. Method and apparatus for detecting switched network protocols
US5923557A (en) * 1997-08-01 1999-07-13 Hewlett-Packard Company Method and apparatus for providing a standard interface to process control devices that are adapted to differing field-bus protocols
US6285659B1 (en) * 1997-09-10 2001-09-04 Level One Communications, Inc. Automatic protocol selection mechanism
US6151640A (en) * 1998-01-23 2000-11-21 Schneider Automation Inc. Control I/O module having the ability to interchange bus protocols for bus networks independent of the control I/O module
US6049577A (en) * 1998-05-28 2000-04-11 Glenayre Electronics, Inc. Header synchronization detector
US7032045B2 (en) * 2001-09-18 2006-04-18 Invensys Systems, Inc. Multi-protocol bus device

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102010030811A1 (de) * 2010-07-01 2012-01-05 Endress + Hauser Flowtec Ag Automatisierte Adaption an verschiedene Industrial Ethernet Protokolle

Also Published As

Publication number Publication date
US20050232305A1 (en) 2005-10-20
WO2003039098A3 (en) 2004-02-26
DE60319704D1 (de) 2008-04-24
EP1522178B1 (de) 2008-03-12
EP1522178A2 (de) 2005-04-13
AU2003204296A1 (en) 2003-05-12
ATE389290T1 (de) 2008-03-15
WO2003039098A2 (en) 2003-05-08
DK1522178T3 (da) 2008-07-14

Similar Documents

Publication Publication Date Title
DE60319704T2 (de) Methode und adapter zur protokoll-ermittlung in einem feldbusnetzwerk
DE69123663T2 (de) Kanäle in einem Rechnerein-Ausgabesystem
DE102013201106B4 (de) Busknoten und Bussystem sowie Verfahren zur Identifikation der Busknoten des Bussystems
DE10392421B4 (de) Handdiagnose- und kommunikationsgerät mit automatischer Buserkennung
EP3251302B1 (de) Gerätezugriff mittels eines generischen kommunikationstreibers
DE69112315T2 (de) Feststellen von doppelten Aliasadressen.
DE69433232T2 (de) Digitales Nachrichtennetz mit Auswahlprozess einer Moderatorstation
EP3977682B1 (de) Fehlererkennung-testeinrichtung für eine teilnehmerstation eines seriellen bussystems und verfahren zum testen von mechanismen zur fehlererkennung bei einer kommunikation in einem seriellen bussystem
DE102004052075A1 (de) Knoten für ein Bus-Netzwerk, Bus-Netzwerk und Verfahren zum Konfigurieren des Netzwerks
EP3886372B1 (de) Verfahren und vorrichtung zur ansteuerung elektrischer und/oder elektronischer komponenten eines kfz-moduls
DE102008019053A1 (de) Verfahren zum Betreiben einer Anlage der Prozessautomatisierungstechnik
DE69122013T2 (de) Adressenerfassung in einem Ein-/Ausgabesystem
WO2019016265A1 (de) Sende-/empfangseinrichtung für ein can bussystem und verfahren zur erkennung eines kurzschlusses mit einer can sende-/empfangseinrichtung
EP2000866A2 (de) Überwachungseinrichtung zur Erkennung des Zustandes eines Busses
DE102019114309A1 (de) Verfahren zum Routen von Telegrammen in einem Automatisierungsnetzwerk, Datenstruktur, Automatisierungsnetzwerk und Netzwerkverteiler
DE69610874T2 (de) Vorrichtung zur Datenübertragung zwischen einer Mehrzahl von Funktionsmodulen in einer lokalen Buseinheit und einem externen ARINC-629-Bus
DE102016224961A1 (de) Teilnehmerstation für ein Bussystem und Verfahren zur Datenübertragung in einem Bussystem
DE69637013T2 (de) Verfahren zum automatischen Anpassen von Parametern einer Schnittstelle
WO2017036508A1 (de) Kommunikationsgerät für ein redundant betreibbares industrielles kommunikationsnetz und verfahren zum betrieb eines kommunikationsgeräts
DE102010003448A1 (de) Adressierungsverfahren und Kommunikationsnetzwerk mit einem solchen Adressierungsverfahren
DE102010028485B4 (de) Verfahren und Vorrichtung zur Absicherung von über eine Schnittstelle zu übertragenden Datenpaketen
DE102019116657B4 (de) System und Verfahren zur kombinierten Energieübertragung und Datenübertragung in einem Automatisierungssystem
DE102019200907A1 (de) Teilnehmerstation für ein Bussystem und Verfahren zur Datenübertragung in einem Bussystem
DE102007039427A1 (de) Steuerknoten für ein Netzwerk aus Steuerknoten
EP2854345B1 (de) Verfahren und Koppel-Kommunikationsgerät zur Nachrichtenübermittlung in einem redundant betreibbaren industriellen Kommunikationsnetz

Legal Events

Date Code Title Description
8364 No opposition during term of opposition