WO2012000813A1 - Automatisierte adaption an verschiedene industrial ethernet protokolle - Google Patents
Automatisierte adaption an verschiedene industrial ethernet protokolle Download PDFInfo
- Publication number
- WO2012000813A1 WO2012000813A1 PCT/EP2011/060185 EP2011060185W WO2012000813A1 WO 2012000813 A1 WO2012000813 A1 WO 2012000813A1 EP 2011060185 W EP2011060185 W EP 2011060185W WO 2012000813 A1 WO2012000813 A1 WO 2012000813A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- protocol
- data packet
- industrial ethernet
- ethernet
- header
- Prior art date
Links
- 230000006978 adaptation Effects 0.000 title description 3
- 238000000034 method Methods 0.000 claims abstract description 22
- 230000015654 memory Effects 0.000 claims description 12
- 230000003213 activating effect Effects 0.000 claims description 2
- 230000004913 activation Effects 0.000 claims description 2
- 230000003936 working memory Effects 0.000 claims 1
- 230000005540 biological transmission Effects 0.000 description 33
- 238000011156 evaluation Methods 0.000 description 4
- 238000009434 installation Methods 0.000 description 3
- 101710117064 Trimethylamine corrinoid protein 1 Proteins 0.000 description 2
- 241000746998 Tragus Species 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 239000007788 liquid Substances 0.000 description 1
- 238000004801 process automation Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40169—Flexible bus arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/403—Bus networks with centralised control, e.g. polling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/407—Bus networks with decentralised control
- H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection (CSMA-CD)
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
- H04L41/0816—Configuration setting characterised by the conditions triggering a change of settings the condition being an adaptation, e.g. in response to network events
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/40208—Bus networks characterized by the use of a particular bus standard
- H04L2012/40228—Modbus
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/4026—Bus for use in automation systems
Definitions
- the type field in the Ethernet header of a data packet is next evaluated to distinguish the various I ndustrial Ethernet protocols. If it follows from the type information that it is If the data packet is an Internet Protocol packet, then the port numbers used by the packet are evaluated. The evaluation results in the Industrial Ethernet protocol used. According to an advantageous embodiment, the Industrial Ethernet protocol is one of the following: EtherNet / IP, Modbus TCP, EtherCAT, PROFI NET, Powerlink.
- FIG. 1 shows an overview of a fieldbus system according to the invention
- 4A shows a first Ethernet frame for transmitting EtherCAT data, the EtherCAT data being transmitted directly via Ethernet;
- step 89 the protocol stack associated with the determined Industrial Ethernet protocol is then activated on the side of the field device.
- byte 9 of the IP header is read out in the next step 90, in order to determine the subsequent protocol, that is to say the protocol following at the next higher level on the Internet Protocol. If the value 6 is in byte No. 9 of the IP header, then the follow-up protocol is TCP, if there is the value 17, then it is UDP.
- the Industrial Ethernet protocol used is determined on the basis of the thus determined port numbers.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Communication Control (AREA)
Abstract
Ein Verfahren zum Konfigurieren eines Feldgeräts, das mit einem Feldbus verbunden ist, wobei der Feldbus für Industrial Ethernet Protokolle ausgelegt ist, wobei das Verfahren die folgenden Schritte umfasst: Analysieren eines auf dem Feldbus übertragenen Datenpakets; Ermitteln eines in dem Datenpaket verwendeten Industrial Ethernet Protokolls; selbsttätiges Aktivieren eines für das ermittelte Industrial Ethernet Protokoll geeigneten Protokollstacks.
Description
Automatisierte Adaption an verschiedene Industrial Ethernet Protokolle
Die Erfindung betrifft ein Verfahren zum Konfigurieren eines Feldgeräts gemäß dem Oberbegriff des Anspruchs 1 sowie ein Feldgerät zum Anschluß an einen Feldbus gemäß dem Oberbegriff des Anspruch 9.
In der Prozessautomatisierungstechnik werden vielfach Feldgeräte eingesetzt, die zur Erfassung und/oder Beeinflussung von Prozessvariablen dienen. Beispiele für derartige Feldgeräte sind Füllstandsmessgeräte, Massedurchflussmessgeräte, Druck- und Temperaturmessgeräte etc., die als Sensoren die entsprechenden Prozessvariablen Füllstand, Durchfluss, Druck bzw. Temperatur erfassen.
Zur Beeinflussung von Prozessvariablen dienen Aktoren, z. B. 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.
Zunehmend werden etablierte Feldbusprotokolle wie Profibus oder Fieldbus Foundation durch Industrial Ethernet Protokolle ersetzt, welche höhere Datenübertragungsraten ermöglichen. Allerdings gibt es eine Vielzahl verschiedener Industrial Ethernet Protokolle wie beispielsweise EtherNet/IP, Modbus TCP, EtherCAT, PROFINET oder Powerlink, die jeweils von unterschiedlichen Herstellern unterstützt werden. Derzeit ist nicht erkennbar, dass eines dieser Industrial Ethernet Protokolle die anderen verdrängen kann. Ein Anbieter von Feldgeräten ist daher gezwungen, für jedes der marktüblichen Industrial Ethernet Protokolle eine gesonderte Geräteversion vorzusehen, die dieses Industrial Ethernet Protokoll unterstützt.
Aufgabe der Erfindung ist es, eine Anpassung eines Feldgeräten an unterschiedliche Industrial Ethernet Protokolle zu ermöglichen.
Gelöst wird diese Aufgabe durch d ie i n den An sprü chen 1 u n d 9 angegebenen Merkmale.
Vorteilhafte Weiterentwicklungen der Erfindung sind in den Unteransprüchen angegeben.
Ein erfindungsgemäßes Verfahren ist dazu ausgelegt, ein Feldgerät zu konfigurieren, das mit einem Feldbus verbunden ist, wobei der Feld bus fü r I nd ustrial Ethernet Protokolle ausgelegt ist. Das Verfahren umfasst die Schritte des Analysierens eines auf dem Feldbus übertragenen Datenpakets; des Ermitteins eines in dem Datenpaket verwendeten Industrial Ethernet Protokolls; und des selbsttätigen Aktivierens eines für das ermittelte Industrial Ethernet Protokoll geeigneten Protokollstacks.
Durch das erfindungsgemäße Verfahren zum Konfigurieren des Feldgeräts wird es dem Feldgerät ermöglicht, das jeweils verwendete Industrial Ethernet Protokoll zu erkennen und sich selbsttätig darauf einzustellen, indem ein für das jeweilige Industrial Ethernet Protokoll geeigneter Protokollstack aktiviert wird. Dadurch wird der Umgang mit der momentan am Markt befindlichen Vielfalt von Industrial Ethernet Derivaten wesentlich vereinfacht. Da die Adaption des Feldgeräts an das jeweilige Protokoll vom Feldgerät automatisch durchgeführt wird , werden Fehler beim Einstellen eines geeigneten Industrial Ethernet Protokolls vermieden, und das Bedienpersonal wird entlastet.
Ein weiterer Vorteil ist, dass durch eine einzige Version eines bestimmten Feldgeräts sämtliche wesentlichen Industrial Ethernet Protokolle abgedeckt werden können. Es ist daher nicht mehr erforderlich, für jedes I ndustrial Ethernet Protokoll ein auf dieses Protokoll abgestimmtes Feldgerät mit einer passenden Softwareversion anzubieten. Da es nur mehr eine Geräteversion und eine Softwareversion gibt, welche für sämtliche wesentlichen Industrial Ethernet Protokolle eingesetzt werden kann, wird der Vertrieb der Feldgeräte, aber auch die Lagerhaltung und die Softwareaktualisierung deutlich vereinfacht.
Gemäß einer vorteilhaften Ausführungsform wird zur Unterscheidung der verschiedenen I ndustrial Ethernet Protokolle zu nächst das Typ-Feld im Ethernet-Header eines Datenpakets ausgewertet. Wenn sich anhand der Typinformation ergibt, dass es sich bei
dem Datenpaket um ein Internet-Protocol-Paket handelt, dann werden die von dem Paket verwendeten Portnummern ausgewertet. Als Ergebnis der Auswertung erhält man das verwendete Industrial Ethernet Protokoll. Gemäß einer vorteilhaften Ausführungsform handelt es sich bei dem Industrial Ethernet Protokoll um eines der folgenden: EtherNet/I P, Modbus TCP, EtherCAT, PROFI NET, Powerlink.
Sobald das auf dem Feldbus verwendete Protokoll erkannt ist, kann entsprechend einer vorteilhaften Ausführungsform ein für dieses Industrial Ethernet Protokoll geeigneter Protokollstack aus verschiedenen gespeicherten Protokollstack-Komponenten auf Seiten des Feldgeräts zusammengestellt und anschließend aktiviert werden. Dabei macht man sich die Tatsache zunutze, dass einige Protokollschichten bei vielen gängigen Industrial Ethernet Protokolle übereinstimmen, und dass die benötigten Protokollstacks zumindest zu m Tei l m od u l a r a u s ei n igen wi ed erkeh ren d en P rotokol lstack-Komponenten zusammengestellt werden können. Dadurch wird der Aufwand für das Bereitstellen einer Vielzahl unterschiedlicher Protokollstacks deutlich verringert.
Nachfolgend ist die Erfindung anhand von in der Zeichnung dargestellten Ausführungsbeispielen näher erläutert.
Es zeigen:
Fig. 1 einen Überblick über ein erfindungsgemäßes Feldbussystem;
Fig. 2 die Datenstruktur eines Ethernet Frame;
Fig. 3A eine erste Variante der Übertragung von Daten eines Industrial-Ethernet- Protokolls, bei der die Daten unmittelbar über Ethernet übertragen werden;
Fig. 3B eine zweite Variante der Übertragung von Daten eines Industrial-Ethernet- Protokolls, bei der die Daten über TCP/IP oder UDP/IP übertragen werden;
Fig. 4A einen ersten Ethernet Frame zur Übertragung von EtherCAT-Daten, wobei die EtherCAT-Daten unmittelbar über Ethernet übertragen werden;
Fig. 4B einen zweiten Ethernet Frame zur Übertragung von EtherCAT-Daten, wobei die EtherCAT-Daten über UDP/IP übertragen werden;
Fig. 5 einen Überblick über die verschiedenen Ebenen des OSl-Schichtenmodells;
Fig. 6 die Datenstruktur eines IP-Headers;
Fig. 7A die Datenstruktur eines UDP-Datagramms;
Fig. 7B die Datenstruktur eines TCP-Headers;
Fig. 8A, 8B Ablaufdiagramme zur erfindungsgemäßen Erkennung von I ndustrial- Ethernet-Protokollen; und
Fig. 9 den Aufbau eines erfindungsgemäßen Feldgeräts.
Fig. 1 zeigt einen Überblick über ein Feldbussystem mit drei Feldgeräten 1 , 2, 3, die über einen Feldbus 4 mit einem Hostrechner 5 verbunden sind. Der Datenaustausch zwischen den Feldgeräten 1 , 2, 3 und dem Hostrechner 5 erfolgt über ein Feldbusprotokoll. Während bei bisherigen Feldbussystemen in erster Linie klassische Feldbusprotokolle wie beispielsweise Profibus, Fieldbus (FF) oder HART verwendet wurden , werden bei modernen I mplementierungen zunehmend Industrial-Ethernet- Protokolle eingesetzt. Zum aktuellen Zeitpunkt sind im industriellen Umfeld eine Vielzahl von verschiedenen Industrial-Ethernet-Derivaten im Einsatz, beispielsweise PROFINET, EtherNet/IP, Modbus TCP, EtherCAT, Powerlink etc. Es zeichnet sich nicht ab, dass sich eines der vielen Industrial-Ethernet-Protokolle auf dem Markt besonders stark etablieren kann. Mit der vorliegenden Erfindung wird ein Feldgerät zur Verfügung gestellt, welches verschiedene Industrial-Ethernet-Protokolle unterstützt und welches in der Lage ist, den Feldbus abzuhören, das auf dem Feldbus verwendete Industrial-Ethernet-Protokoll selbsttätig zu analysieren und dementsprechend einen geeigneten Protokoll-Stack für das betreffende Industrial-Ethernet-Protokoll zu aktivieren.
Hierzu soll im Folgenden zunächst ein Überblick über die verschiedenen Industrial- Ethernet-Protokolle gegeben werden.
Bei sämtlichen Industrial-Ethernet-Protokollen erfolgt die Datenübertragung auf dem Feldbus mit Hilfe von Ethernet Frames. Die Struktur eines Ethernet Frame ist in Fig. 2 gezeigt. Diese Struktur ist im Standard IEEE 802.3 festgelegt. Im Header des Ethernet Frame 6 wird zunächst die Ziel-MAC-Adresse 7 spezifiziert, anschließend wird die Quell- MAC-Adresse 8 angegeben. Bei den MAC-Adressen handelt es sich um Kennungen, die einer bestimmten Gerätehardware zugeordnet sind und eine ein-eindeutige
Identifizierung der betreffenden Gerätehardware ermöglichen . Optional kann im Ethernet-Header ein VLAN-Tag 9 spezifiziert sein, welches angibt, zu welchem virtuellen LAN (Local Area Network) das Ethernet Frame 6 gehört. Wenn im System keine verschiedenen virtuellen LANs definiert sind, erübrigt sich die Übertragung eines VLAN- Tags. Im Typ-Feld 10 wird der Typ des Ethernet Frame 6 angegeben, der sogenannte „Ethertype". Beispielsweise werden Ethernet Frames, in denen Daten gemäß dem Internet Protocol (IP) übertragen werden, mit dem Ethertype 0x0800 gekennzeichnet. Im Anschluss an den Ethernet-Header werden die eigentlichen Nutzdaten 1 1 übertragen. Dabei ist die Länge der in einem Ethernet Frame 6 übertragenen Nutzdaten 1 1 variabel; der gesamte Ethernet Frame 6 kann eine Länge zwischen 64 Byte und 1518 Byte aufweisen. Im Anschluss an die Nutzdaten 1 1 wird ein PAD-Füllfeld 12 übertragen, gefolgt von einer CRC (Cyclic Redundancy Check)-Prüfsumme 13. Das PAD-Füllfeld 12 umfasst sogenannte„Padding Bytes", also Füllbytes, die zum Auffüllen des Datenfeldes auf eine erforderliche Mindestgröße dienen.
Der in Fig. 2 gezeigte Ethernet Frame 6 dient in sämtlichen Industrial-Ethernet- Protokollen als Grundeinheit für die Datenübertragung auf dem Feldbus.
Allerdings gibt es zwei grundlegend verschiedene Varianten, wie die von den Ethernet Frames zur Verfügung gestellte Übertragungskapazität zur Übertragung der Daten des jeweiligen Industrial-Ethernet-Protokolls genutzt werden kann. Diese beiden Varianten werden im Folgenden anhand der Fig. 3A und 3B erläutert.
Bei der in Fig. 3A gezeigten ersten Variante wird zunächst der Ethernet-Header 14 übertragen , und auf den Ethernet-Header 14 folgen unmittelbar die Daten 1 5 des jeweiligen Industrial-Ethernet-Protokolls. Die Daten 15 des jeweiligen Industrial-Ethernet- Protokolls werden im Nutzdatenfeld des Ethernet Frame übermittelt. Da die Ethernet- Schicht die Ebenen 1 und 2 des OSl-Schichtenmodells bildet, bedeutet dies, dass die Daten 15 des Industrial-Ethernet-Protokolls auf der Ebene 3 (Vermittlungsschicht) des OSl-Schichtenmodells übertragen werden. Zum Abschluss des Ethernet Frame werden die PÄD- und CRC-Felder 16 übermittelt.
Die in Fig. 3A gezeigte erste Variante, bei der die Daten des jeweiligen Industrial- Ethernet-Protokolls auf der OSl-Ebene 3 übermittelt werden, wird beispielsweise bei dem Industrial-Ethernet-Protokoll„Powerlink" eingesetzt. Die Übertragung der Daten des jeweiligen Industrial-Ethernet-Protokolls kann auch entsprechend der in Fig. 3B gezeigten zweiten Variante erfolgen. Bei dieser zweiten Variante wird zunächst ein Ethernet-Header 17 übertragen. Auf den Ethernet-Header 17 folgen nicht unmittelbar die Nutzdaten des jeweiligen Industrial-Ethernet-Protokolls, sondern es werden zusätzliche Protokollschichten eingeführt. Dazu wird im Anschluss an den Ethernet-Header 17 ein I P-Header 18, also ein Header des Internet Protocol, übertragen, auf den dann ein TCP (Transmission Control Protocol)- oder UDP (User Datagram Protocol)-Header 19 folgt, je nachdem, ob die Datenübertragung über TCP/IP oder UDP/IP erfolgen soll. Im Anschluss an die beiden Header 18 und 19 beginnt dann die Übertragu ng der Daten 20 des jeweil igen I ndustrial-Ethernet-Protokolls. Zum Abschluss des Ethernet Frame werden die PÄD- und CRC-Felder 21 übertragen.
Die Entscheidung, ob TCP/IP oder UDP/IP zur Datenübertragung verwendet werden soll, hängt in erster Linie von den Anforderungen an die Zuverlässigkeit der Datenübertragung ab. Bei TCP handelt es sich um ein verbindungsorientiert.es Protokoll, das heißt, es wird eine Datenverbindung zwischen Sender und Empfänger aufgesetzt. Dies ermöglicht eine zuverlässige Datenübertragung, bei der Übertragungsfehler erkannt u n d korri g i ert werd e n kö n n en . Be i U D P d a g eg en h a n d e lt es s i ch u m e i n verbindungsloses Protokoll mit einem im Vergleich zu TCP geringeren Verwaltungsaufwand. Dadurch ist die Netzwerkbelastung bei UDP geringer als bei TCP, und es kann ein höherer Datendurchsatz erreicht werden. Die Verwendung von TCP/IP oder UDP/IP für die Datenübertragung hat den Vorteil, dass zum Routen und Switchen der Datenpakete gängige Hardwarekomponenten verwendet werden können, die auch in der Infrastruktur des Internet eingesetzt werden. Im Unterschied zu der in Fig. 3A gezeigten ersten Variante, bei der die Übertragung der Daten zum Industrial-Ethernet-Protokoll auf der Ebene 3 des OSl-Schichtenmodells erfolgt, wird bei der in Fig. 3B gezeigten zweiten Variante die Ebene 3 des OSl-Modells durch das Internet Protocol (I P) gebildet, und die Ebene 4 des OSl-Modells wird durch
TCP oder UDP gebildet. Die Übertragung der Daten des jeweiligen Industrial-Ethernet- Protokolls erfolgt dann erst auf der Ebene 5 des OSl-Schichtenmodells.
Die in Fig. 3B gezeigte zweite Variante der Datenübertragung über TCP/IP oder UDP/IP wird beispielsweise in den Industrial-Ethernet-Protokollen EtherNet/IP und Modbus TCP verwendet. Diese beiden Industrial-Ethernet-Protokolle verwenden das Internet Protocol (IP) als Basis. Bei EtherNet/IP kann die Datenübertragung sowohl über TCP/IP als auch über UDP/IP erfolgen. Bei Modbus TCP erfolgt die Datenübertragung ausschließlich über TCP/IP.
Daneben gibt es auch Industrial-Ethernet-Protokolle, die sowohl Ethernet Frames der in Fig. 3A gezeigten Art als auch Ethernet Frames der in Fig. 3B gezeigten Art verwenden. Zu diesen Industrial-Ethernet-Protokollen gehören beispielsweise die Industrial-Ethernet- Protokolle EtherCAT und PROFINET. Bei diesen beiden Industrial-Ethernet-Protokollen werden sowohl Ethernet Frames entsprechend der ersten Variante eingesetzt, bei denen die Daten des jeweiligen Industrial-Ethernet-Protokolls unmittelbar im Nutzdatenfeld des Ethernet Frame übermittelt werden, als auch Ethernet Frames entsprechend der zweiten Variante, bei denen die Übermittlung der Daten des jeweiligen Industrial Ethernet Protokolls über die Zwischenschichten TCP/IP oder UDP/IP erfolgt.
Für das Beispiel EtherCAT sind in den Fig. 4A und 4B für beide Varianten der Datenübertragung die entsprechenden Ethernet Frames gezeigt. Beide Varianten kommen bei EtherCAT zum Einsatz. Bei dem in Fig. 4A gezeigten Ethernet Frame 22 werden die EtherCAT-Daten unmittelbar als Nutzdaten des Ethernet Frame 22 übertragen. Insofern entspricht der in Fig. 4A gezeigte Ethernet Frame 22 der in Fig. 3A gezeigten ersten Variante. Der Ethernet Frame 22 besteht aus einem Ethernet-Header 23, der die Ziel-MAC-Adresse 24, die Quell-MAC-Adresse 25 sowie den Ethertype 26 umfasst. Nach dem Ethernet-Header 23 werden die Nutzdaten 27 übertragen. Als Teil der Nutzdaten 27 wird zuerst ein EtherCAT-spezifischer Header 28 übertragen, der die Länge 29, ein reserviertes Bit 30 sowie eine Typinformation 31 umfasst. Anschließend werden die eigentlichen EtherCAT-Befehle und -Daten 32 übertragen. Zum Abschluss des Ethernet Frame 22 wird ein PAD-Füllfeld sowie eine CRC-Prüfsumme 33 übertragen.
Bei dem in Fig. 4A gezeigten Ethernet Frame 22 werden im Nutzdatenfeld unmittelbar EtherCAT-Befehle und -Daten übertragen. Insofern handelt es sich um einen Ethernet Frame mit einem eigens hierfür vorgesehenen Ethertype, nämlich 0x88A4. Durch den Wert 0x88A4 im Typ-Feld 10 des Ethernet Frame (vgl. Fig. 2) wird klargestellt, dass im Nutzdatenfeld des Ethernet Frame EtherCAT-Daten und -Befehle übertragen werden.
Daneben werden im Industrial-Ethernet-Protokoll EtherCAT die Nutzdaten auch über UDP/IP übertragen. In Fig. 4B ist ein hierfür verwendeter Ethernet Frame 34 gezeigt. Der Ethernet Frame 34 umfasst einen Ethernet-Header 35 mit einer Ziel-MAC-Adresse 36, einer Quell-MAC-Adresse 37 sowie einem Ethertype 38. I m Anschluss an den Ethernet-Header 35 wird ein IP-Header 39 sowie ein UDP-Header 40 übertragen, insofern entspricht der Ethernet Frame 34 der in Fig. 3B gezeigten zweiten Übertragungsvariante. Erst nach der Übertragung der beiden Header 39, 40 beginnt die Übertragung der eigentlichen Nutzdaten 41 des Industrial-Ethernet-Protokolls EtherCAT. Die Nutzdaten 41 umfassen einen EtherCAT-spezifischen Header 42, in dem die Länge und der Typ der folgenden EtherCAT-Befehle und -Daten angegeben sind, und anschließend die EtherCAT-Befehle und -Daten 43. Zum Abschluss des Ethernet Frame 34 wird ein PAD-Füllfeld sowie eine CRC-Prüfsumme 44 übertragen.
Bei dem in Fig. 4B gezeigten Ethernet Frame 34 erfolgt die Übertragung der EtherCAT- Befehle und -Daten über UDP/IP, also über das Internet Protocol. Insofern handelt es sich bei dem Ethernet Frame 34 um ein IP-Paket. Dies wird durch den Wert 0x0800 im Typ-Feld 10 des Ethernet Frame (vgl. Fig. 2) angezeigt.
In Fig. 5 ist nochmals im Überblick dargestellt, auf welchen Ebenen des OSI- Schichtenmodells bei den verschiedenen Industrial-Ethernet-Protokollen die Datenübertragung stattfindet. Bei sämtlichen Industrial-Ethernet-Protokollen dient eine Ethernet-Schicht 46 als Basis für die Datenübertragung. Die Ethernet-Schicht 46 bildet die Ebenen 1 und 2 (Physikalische Schicht sowie Sicherungsschicht) des OSI- Schichtenmodells. Das Powerlink-Protokoll 47 setzt unmittelbar auf der Ethernet-Schicht 46 auf. Dies entspricht der in Fig. 3A gezeigten ersten Übertragungsvariante. Auch im EtherCAT-Protokoll 48 und im PROFINET-Protokoll 49 gibt es Frames, die unmittelbar aufsetzend auf die Ethernet-Schicht 46 übertragen werden. Im Powerlink-Protokoll 47 erfolgt die Datenübertragung vollständig auf der Ebene 3 (Vermittlungsschicht) des OSI-
Schichtenmodells. Im EtherCAT-Protokoll 48 und im PROFINET-Protokoll 49 erfolgt die Datenübertragung zumindest zum Teil auf der Ebene 3.
Alternativ dazu kann auf die Ethernet-Schicht 46 als Ebene 3 eine Internet-Protocol- Schicht 50 aufgesetzt werden, auf die dann als Ebene 4 (Transportschicht) eine TCP- oder eine UDP-Schicht 51 aufgesetzt wird. Dies entspricht der in Fig. 3B gezeigten zweiten Übertragungsvariante. Das jeweilige Industrial-Ethernet-Protokoll wird dann auf der Ebene 5 des OSl-Schichtenmodells übertragen, und zwar über TCP/I P oder über UDP/IP.
Beispielsweise werden die beiden Protokolle EtherNet/IP 52 und Modbus TCP 53, wie in Fig. 5 gezeigt, auf der Ebene 5 des OSl-Modells übertragen. Dabei kann das Protokoll EtherNet/IP 52 sowohl über TCP/IP als auch über UDP/IP übertragen werden. Das Protokoll Modbus TCP 53 dagegen wird ausschließlich über TCP/IP übertragen.
Darüber hinaus können die Protokolle PROFINET 48 und EtherCAT 49 nicht nur auf der Ebene 3, sondern darüber hinaus auch auf der Ebene 5 des OSl-Modells übertragen werden, wie dies in Fig. 5 veranschaulicht ist. Das Protokoll PROFINET 48 kann sowohl über TCP/IP als auch über UDP/IP übertragen werden. Dagegen wird das Protokoll EtherCAT 49 lediglich über UDP/IP übertragen.
Ein Feldgerät gemäß Ausführungsformen der vorliegenden Erfindung ist dazu ausgelegt, den auf dem Feldbus übertragenen Datenverkehr auszuwerten und das dort verwendete Industrial-Ethernet-Protokoll zu bestimmen. Anschließend kann das Feldgerät das eigene Industrial-Ethernet-Protokoll entsprechend dem auf dem Feldbus verwendete Industrial-Ethernet-Protokoll einstellen. Hierzu kann das Feldgerät beispielsweise einen geeigneten Protokoll-Stack aktivieren.
Im Folgenden soll der erfindungsgemäße Ablauf zur Bestimmung des auf dem Feldbus verwendeten Industrial-Ethernet-Protokolls dargestellt werden.
Hierzu greift das Feldgerät zunächst auf den Ethernet-Header eines auf dem Feldbus übertragenen Ethernet Frame zu. Die Struktur des Ethernet Frame ist bereits in Fig. 2 dargestellt worden. Der Ethernet Frame 6 umfasst ein Typ-Feld 10, in dem der Typ des
Ethernet Frame, der sogenannte„Ethertype", angegeben ist. Dieser Ethertype wird nun vom Feldgerät analysiert. Anhand des Ethertype kann unterschieden werden, ob der aktuell auf dem Feldbus übertragene Ethernet Frame das Internet Protocol (IP) zur Datenübertragung verwendet, oder ob irgendein anderes Protokoll auf die Ethernet- Schicht aufgesetzt ist. Falls der Ethernet Frame das Internet Protocol verwendet, dann ist dies im Typ-Feld 10 des Ethernet-Headers durch den Wert 0x0800 gekennzeichnet.
Wenn im Typ-Feld 10 dagegen ein anderer Wert als 0x0800 steht, dann handelt es sich nicht um ein I P-Paket. In diesem Fall kann anhand des im Typ-Feld 10 gespeicherten Werts unmittelbar erkannt werden, welches Protokoll auf der Ebene 3 des OSI- Schichtenmodells verwendet wird. Wenn beispielsweise im Typ-Feld 10 des Ethernet- Headers der Wert 0x88AB steht, dann wird auf Ebene 3 das Powerlin k-Protokoll verwendet, es handelt sich dann also um ein Powerlink-Paket. Wenn das Typ-Feld 10 dagegen den Wert 0x88A4 hat, dann handelt es sich um ein Paket, bei dem das EtherCAT-Protokoll auf der Ebene 3 verwendet wird. Wenn dagegen im Typ-Feld 10 der Wert 0x8892 steht, dann handelt es sich um ein PROFINET-Paket, bei dem das PROFINET-Protokoll auf der Ebene 3 verwendet wird.
Insofern kann für den Fall, das es sich bei dem Ethernet Frame nicht um ein IP-Paket handelt, an hand des Typ-Felds 10 ermittelt werden, welches Industrial-Ethernet- Protokoll verwendet wird. Bei dem Wert 0x88AB handelt es sich um ein Powerlink-Paket, bei 0x88A4 handelt es sich um ein EtherCAT-Paket, und bei dem Wert 0x8892 handelt es sich um ein PROFINET-Paket. Dagegen kann für den Fall, dass es sich bei dem Ethernet Frame um ein I P-Paket handelt, noch kei ne Aussage über das verwendete I ndustrial-Ethernet-Protokoll getroffen werden. In diesem Fall wird die Analyse des Ethernet Frame fortgesetzt. Dazu wird der auf den Ethernet-Header folgende IP-Header analysiert. Für die Version 4 des I nternet Protocol (I Pv4) ist ein derartiger I P-Header in Fig. 6 gezeigt. Die Bedeutung der einzelnen Felder ist hinlänglich dokumentiert, beispielsweise in der Protokollspezifikation RFC791 , so dass die einzelnen Felder des IP-Headers hier nur im Überblick beschrieben werden. Der I P-Header umfasst ein Versionsfeld 57, ein IHL-(I P Header Length)-Feld 58, ein TOS-(Type of Service)-Feld 59, ein Total-Length-
Feld 60, ein Identification-Feld 61 , verschiedene Flags 62, einen Fragment-Offset 63, ein TTL-(Time-To-Live)-Feld 64, ein Protocol-Feld 65 sowie eine Header-Checksum 66. Darüber hinaus umfasst der IP-Header eine Quelladresse 67, eine Zieladresse 68 sowie Zusatzinformationen 69 („Options and Padding").
Für die weitere Analyse relevant ist das Protocol-Feld 65, das als Byte 9 des IP-Headers übertragen wird (wobei die Nummerierung der Bytes mit Byte 0 startet). Das Protocol- Feld 65 bezeichnet das Folgeprotokoll , also das auf das I nternet Protocol auf der nächsthöheren Ebene folgende Protokoll, zu dem die in dem IP-Paket transportierten Nutzdaten gehören. Wenn das IP-Paket beispielsweise ein TCP-Paket enthält, dann steht im Protocol-Feld 65 des IP-Headers der Wert 6 für das Protokoll TCP. Enthält das IP-Paket dagegen ein UDP-Paket, so enthält das Protocol-Feld 65 des I P-Headers den Wert 17 für das Protokoll UDP. Diese Werte werden seit RFC3232 von der IANA (Internet Assigned Numbers Authority) in einer Online-Datenbank für Protokoll-Nummern festgelegt. Im IP-Header der Version 6 des Internetprotokolls (IPv6) gibt es ebenfalls ein Feld, welches das auf der nächsthöheren Ebene folgende Protokoll spezifiziert und insoweit dem Protocol-Feld 65 entspricht, allerdings heißt es dort„Next Header". Die zulässigen Werte sind in der Version IPv6 die gleichen wie in der Version IPv4. Durch Auslesen und Analysieren des Protocol-Felds 65 des IP-Headers kann daher auf einfache Weise ermittelt werden, welches der Folgeprotokolle U DP oder TCP auf der OSl-E bene 4 a uf d as I P-Protokoll folgt. Die Information, ob TCP oder UDP als Folgeprotokoll verwendet wird, kann dann zum geeigneten Auslesen des UDP- Datagramms bzw. des TCP-Headers verwendet werden. Die Information, ob UDP oder TCP als Folgeprotokoll verwendet wird, kann insbesondere dazu verwendet werden, den Quell-Port und den Ziel-Port des I P-Pakets zu ermitteln, wie im folgenden anhand von Fig. 7A und Fig. 7B dargestellt ist. Die Portnummern von Quell-Port und Ziel-Port ermöglichen dann die Bestimmung des verwendeten Industrial-Ethernet-Protokolls. In Fig. 7A ist die Struktur eines UDP-Datagramms dargestellt. Das UDP-Datagramm umfasst ein Feld 70 für den Quell-Port, in dem die Portnummer auf der Senderseite angegeben ist. Außerdem umfasst das UDP-Datagramm ein Feld 71 für den Ziel-Port, in dem die Portnummer auf der Empfängerseite angegeben ist. In Feld 72 ist die Länge
des UDP-Datagramms angegeben, und im Feld 73 wird eine Prüfsumme übertragen. Anschließend werden die Nutzdaten 74 übertragen.
Die Portnummern auf der Sender- und Empfängerseite können daher durch Auslesen der Felder 70 und 71 des UDP-Datagramms erhalten werden.
Alternativ zu UDP kann beispielsweise TCP als Übertragungsprotokoll auf der Ebene 4 des OSl-Schichtenmodells verwendet werden. In Fig. 7B ist die Struktur eines TCP- Headers gezeigt. Der TCP-Header umfasst ein Feld 75 für den Quell-Port, ein Feld 76 für den Ziel-Port, ein Feld 77 für die „Sequence Number" sowie ein Feld 78 für die „Acknowledgement Number". Darüber hinaus umfasst der TCP-Header ein Feld„Data Offset" 79, ein Reserve-Feld 80, eine Reihe von Flags 81 , ein Feld„Window" 82, ein Prüfsummenfeld 83, einen„Urgent Pointer" 84 sowie ein Optionsfeld 85. Im Anschluss an das Optionsfeld 85 beginnt die Übertragung der Nutzdaten 86.
Durch Auslesen der Felder 75 und 76 des TCP-Headers können der Quell-Port sowie der Ziel-Port des IP-Pakets ermittelt werden. Dabei bezeichnet der Quell-Port die Portnummer auf der Senderseite, während der Ziel-Port die Portnummer auf der Empfängerseite bezeichnet. Diese Portnummern sind charakteristisch für das verwendete Industrial Ethernet Protokoll. Daher ermöglicht eine Auswertung dieser Portnummern sowohl bei dem in Fig. 7A gezeigten Beispiel eines UDP-Datagramms als auch bei dem in Fig. 7B gezeigten Beispiel eines TCP-Headers die Bestimmung des verwendeten Industrial-Ethernet-Protokolls. Die Auswertung der so erhaltenen Portnummern kann beispielsweise anhand der folgenden Übersicht erfolgen:
EtherNet/IP:
Ports:
2222/TCP
2222/UDP
44818/TCP
44818/UDP
PROFINET:
Ports:
34962/TCP (PROFINET RT Unicast)
34962/UDP (PROFINET RT Unicast)
34963/TCP (PROFINET RT Multicast)
34963/UDP (PROFINET RT Multicast)
34964/TCP (PROFINET Context Manager)
34964/UDP (PROFINET Context Manager)
EtherCAT:
Port:
0x88A4/UDP
Modbus TCP:
Port:
502/TCP Anhand der obigen Aufstellung ist ersichtlich, dass die verwendeten Portnummern für das jeweils eingesetzte Industrial-Ethernet-Protokoll spezifisch sind. Für den Fall, dass ein IP-Paket vorliegt (was durch den Ethertype 0x0800 angezeigt wird), kann daher durch Auswerten der Portnummern von Quell-Port und Ziel-Port ermittelt werden, welches Industrial-Ethernet-Protokoll fü r die Datenü bertragu ng auf dem Feld bus verwendet wird. Dabei kann die Zuordnung der Portnummern zum entsprechenden Industrial-Ethernet-P rotokol l bei spi elswei se m it H i lfe ei n er Zuord n u n gsta bel l e durchgeführt werden.
Zusammenfassend kann festgestellt werden, dass durch eine Analyse des Typ-Felds im Ethernet-Header sowie eine Auswertung der Portnummern von Quell-Port und Ziel-Port eine eindeutige Bestimmung des verwendeten Industrial-Ethernet-Protokolls ermöglicht wird.
In Fig. 8A ist das erfindungsgemäße Verfahren zur automatischen Auswahl eines geeigneten Industrial-Ethernet-Protokolls in Form eines Ablaufdiagramms dargestellt.
Im Schritt 87 wird anhand des Typ-Felds im Ethernet-Header der Ethertype des Ethernet-Frame ausgewertet. Wenn der Ethertype nicht gleich 0x0800 ist, dann handelt es sich um einen Ethernet Frame mit einem eigens hierfür vorgesehenen Ethertype. In
diesem Fall ermöglicht der Ethertype einen Rückschluss auf das verwendete Industrial Ethernet Protokoll.
Wenn der Ethertype nicht gleich 0x0800 ist, kann daher im Schritt 88 anhand des Ethertype das verwendete Industrial Ethernet Protokoll bestimmt werden.
Im Schritt 89 wird dann der zu dem ermittelten Industrial Ethernet Protokoll gehörige Protokollstack auf Seiten des Feldgeräts aktiviert.
Wenn der Ethertype dagegen gleich 0x0800 ist, dann handelt es sich bei dem Ethernet Frame um ein IP-Paket.
In diesem Fall wird im nächsten Schritt 90 das Byte Nr. 9 des IP-Headers ausgelesen, um auf diese Weise das Folgeprotokoll zu bestimmen, also das auf der nächsthöheren Ebene auf das Internet Protocol folgende Protokoll. Wenn im Byte Nr. 9 des IP-Headers der Wert 6 steht, dann handelt es sich bei dem Folgeprotokoll um TCP, wenn dort der Wert 17 steht, dann handelt es sich um UDP.
I m darauffolgenden Schritt 91 wird auf den jeweiligen Header des Folgeprotokolls zugegriffen, also beispielsweise auf den TCP-Header oder den UDP-Header, um die Portn u m mern von Qu el lport u nd Ziel port des I P-Pakets zu bestimmen. Diese Portnummern sind spezifisch für das verwendete Industrial Ethernet Protokoll.
Insofern kann im nächsten Schritt 92 anhand der Portnummern das verwendete Industrial Ethernet Protokoll bestimmt werden. Beispielsweise kann das zu den Portnummern gehörige Industrial Ethernet Protokoll mittels einer Zuordnungstabelle ermittelt werden.
Im Schritt 93 wird dann der zu dem ermittelten Industrial Ethernet Protokoll gehörige Protokollstack auf Seiten des Feldgeräts aktiviert.
Ergänzend oder alternativ zu den bisher beschriebenen Schritten können zur Ermittlung des verwendeten Industrial Ethernet Protokolls auch die in dem Datenpaket übertragenen Nutzdaten analysiert werden. Bei dieser Analyse werden die Nutzdaten auf darin enthaltene protokollspezifische Strukturen überprüft, insbesondere auf
mindestens eines von: Befehlen, Objekten, Diensten, Adressen, Blöcken, etc., die für das verwendete Industrial Ethernet Protokoll typisch sind.
Bei der bisherigen Darstellung war davon ausgegangen worden, dass auf dem Feldbus ein bestimmtes Industrial Ethernet Protokoll eingesetzt wird. Es gibt aber auch Feldbussysteme, in denen auf dem Feldbus zwei oder mehr unterschiedliche Industrial Ethernet Protokolle parallel verwendet werden. Bei einer derartigen „hybriden" Installation muss ein erfindungsgemäßes Feldgerät erkennen, welche der unterschiedlichen Ethernet Frames an es selbst adressiert sind, dann das Industrial Ethernet Protokoll dieser Ethernet Frames analysieren, und dann einen für dieses Protokoll geeigneten Protokollstack aktivieren.
In Fig. 8B ist ein modifizierter Ablauf für derartige„hybride" Installationen gezeigt, bei denen zwei oder mehr unterschiedliche Industrial Ethernet Protokolle nebeneinander verwendet werden.
Bei einer derartigen Installation wird in einem ersten Schritt 94 die Ziel-MAC-Adresse des Ethernet Frame mit der eigenen MAC-Adresse des Feldgeräts verglichen, um herauszufinden, ob der Ethernet Frame an das Feldgerät adressiert ist.
Wenn die Ziel-MAC-Adresse des Ethernet Frames nicht mit der eigenen MAC-Adresse des Feldgeräts übereinstimmt, wird entsprechend Schritt 95 auf den nächsten Ethernet Frame gewartet. Wenn dagegen die Ziel-MAC-Adresse des Ethernet Frames mit der eigenen MAC- Adresse des Feldgeräts übereinstimmt, dann steht fest, dass der betrachtete Ethernet Frame an das Feldgerät adressiert ist. Nur in diesem Fall wird das in dem Ethernet Frame verwendete Industrial Ethernet Protokoll ermittelt. Sobald feststeht, dass der betrachtete Ethernet Frame an das eigene Feldgerät adressiert ist, wird das verwendete I ndustrial Ethernet Protokoll bestimmt. Dabei entspricht der Ablauf den in Fig. 8A gezeigten Schritten.
I m Schritt 96 wi rd anhand des Typ-Felds im Ethernet-Header der Ethertype des Ethernet-Frame ausgewertet.
Wenn der Ethertype nicht gleich 0x0800 ist, wird in Schritt 97 anhand des Ethertype das verwendete Industrial Ethernet Protokoll bestimmt.
Im Schritt 98 wird dann auf Seiten des Feldgeräts der Protokollstack zu dem ermittelten Industrial Ethernet Protokoll aktiviert.
Wenn der Ethertype dagegen gleich 0x0800 ist, dann handelt es sich bei dem Ethernet Frame um ein IP-Paket. In diesem Fall wird im Schritt 99 das Byte Nr. 9 des IP-Headers ausgelesen, um so das auf das Internet Protocol folgende Protokoll (zum Beispiel UDP oder TCP) zu bestimmen.
Im folgenden Schritt 100 werden die Portnummern von Quell-Port und Ziel-Port des IP- Pakets ausgelesen . H ierzu wird auf den jeweiligen H eader des Folgeprotokolls zugegriffen, also beispielsweise auf den TCP-Header oder den UDP-Header.
Im nächsten Schritt 101 wird anhand der so ermittelten Portnummern das verwendete Industrial Ethernet Protokoll bestimmt.
Im Schritt 102 wird dann auf Seiten des Feldgeräts der passende Protokollstack aktiviert.
In Fig. 9 ist gezeigt, wie der passende Protokollstack auf Seiten des Feldgeräts 103 zusammengestellt und aktiviert werden kann. Vorzugsweise kann dies mit Hilfe eines Baukastensystems aus verschiedenen Protokollstack-Komponenten geschehen, die geeignet zusammengestellt werden.
Das Feldgerät 103 umfasst eine Prozessoreinheit 104, einen flüchtigen Arbeitsspeicher 105 sowie einen nichtflüchtigen Speicher 106, beispielsweise einen Flash-Speicher. Im nichtflüchtigen Speicher 106 sind neben der Betriebssoftware 107 auch verschiedene Protokollstack-Komponenten abgespeichert. Insbesondere sind im nichtflüchtigen Speicher 106 eine Ethernet-Schicht 108, ein UDP/IP-Stack 109, ein TCP/IP-Stack 1 10 sowie die Industrial Ethernet Protokollebenen zu EtherNet/IP 1 1 1 , Modbus TCP 1 12, EtherCAT 1 13, PROFINET 1 14, Powerlink 1 15 etc. gespeichert.
Nach dem Hochstarten des Feldgeräts analysiert eine Konfigurationseinheit 1 16, die im Arbeitsspeicher 105 läuft, die auf dem Feldbus übertragenen Ethernet Frames. Dabei ermittelt die Konfigurationseinheit 1 16 mit Hilfe der in den Fig. 8A und 8B gezeigten Verfahren das in den Ethernet Frames verwendete Industrial Ethernet Protokoll. Anschließend wird ein für das ermittelte Protokoll passender Protokollstack zusammengestellt. Hierzu werden die verschiedenen benötigten Protokolstack- Komponenten aus dem nichtflüchtigen Speicher 1 06 in den Arbeitsspeicher 1 05 g e l a d e n . An sch l i e ße n d wi rd d e r i m Arbeitsspeicher 105 zusammengestellte Protokollstack aktiviert.
Dies soll im Folgenden anhand eines Beispiels veranschaulicht werden . Es soll angenommen werden, dass die Konfigurationseinheit 1 16 ermittelt, dass die Ethernet Frames das Protokoll Modbus TCP verwenden. Um im Arbeitsspeicher 105 einen Modbus TCP-Stack 1 17 zu erzeugen, lädt die Konfigurationseinheit 1 16 aus dem nichtflüchtigen Speicher 106 die Ethernet-Schicht 108, den TCP/IP-Stack 1 10 sowie die Protokollebene zu Modbus TCP 1 12. Aus diesen Komponenten kann der benötigte Modbus TCP-Stack 1 17 modular zusammengestellt werden. Anschließend wird der so zusammengestellte Modbus TCP-Stack 1 17 aktiviert, und das Feldgerät kann über Modbus TCP auf dem Feldbus kommunizieren.
Dabei bietet die modulare Zusammenstellung der benötigten Protokollstacks den Vorteil, dass der Speicherbedarf für die Stackkomponenten, die für die Zusammenstellung der Protokolstacks für eine Vielzahl verschiedener Industrial Ethernet Protokolle benötigt werden, in einem vernünftigen Rahmen gehalten werden kann. Dadurch wird es ermöglicht, mit vertretbarem Aufwand ein Feldgerät zu realisieren, das sich selbsttätig auf eine Vielzahl verschiedener Industrial Ethernet Protokolle einstellen kann.
Claims
Patentansprüche
1 . Verfahren zum Konfigurieren eines Feldgeräts (103), das mit einem Feldbus verbunden ist, wobei der Feldbus für Industrial Ethernet Protokolle ausgelegt ist, gekennzeichnet durch folgende Schritte:
Analysieren eines auf dem Feldbus übertragenen Datenpakets;
Ermitteln (88, 92) eines in dem Datenpaket verwendeten Industrial Ethernet
Protokolls;
selbsttätiges Aktivieren (89, 93) eines für das ermittelte Industrial Ethernet Protokoll geeigneten Protokollstacks (1 17).
2. Verfahren nach Anspruch 1 , gekennzeichnet durch folgenden Schritt:
Kommunizieren über den Feldbus entsprechend dem ermittelten Industrial Ethernet Protokoll.
3. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, dass das in dem Datenpaket verwendete Industrial Ethernet Protokoll ermittelt wird durch mindestens eines von:
Auswerten von Typ-Information zum Typ des Datenpakets, die aus einem Typ-Feld eines Ethernet-Headers des Datenpakets ausgelesen wird, und
Auswerten von mindestens einer Portnummer von mindestens einem Port des Datenpakets, welche aus einem H eader einer höheren Protokollebene des Datenpakets ausgelesen wird.
4. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, dass das in dem Datenpaket verwendete Industrial Ethernet Protokoll ermittelt wird durch:
Auswerten von Typ-Information zum Typ des Datenpakets, die aus einem Typ-Feld eines Ethernet-Headers des Datenpakets ausgelesen wird, und
Auswerten von mindestens einer Portnummer von mindestens einem Port des Datenpakets, welche aus einem Header einer höheren Protokollebene des Datenpakets ausgelesen wird.
Verfahren nach Anspruch 3 oder Anspruch 4, dadurch gekennzeichnet, dass das Ermitteln des in dem Datenpaket verwendeten I ndustrial Ethernet Protokolls zusätzlich folgenden Schritt umfasst:
Überprüfen von in dem Datenpaket enthaltenen Nutzdaten auf darin enthaltene protokollspezifische Datenstrukturen.
Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass das in dem Datenpaket verwendete Industrial Ethernet Protokoll ermittelt wird durch:
Auswerten von Typ-Information zum Typ des Datenpakets, die aus einem Typ-Feld eines Ethernet-Headers des Datenpakets ausgelesen wird,
Bestimmen, anhand der ausgelesenen Typ-Information, ob es sich bei dem Datenpaket um ein Internet-Protocol-Datenpaket handelt oder nicht, und
falls die Typ-Information ergibt, dass es sich bei dem Datenpaket um ein Internet- Protocol-Paket handelt, Auswerten von mindestens einer Portnummer von min d esten s ei n em P ort d es Date n pa kets , d i e a u s ei n em H ead er ei n es Folgeprotokolls zum Internet Protocol ausgelesen wird.
Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass das Ermitteln des in dem Datenpaket verwendeten Industrial Ethernet Protokolls einen oder mehrere der folgenden Schritte umfasst:
Auslesen von Typ-Information zum Typ des Datenpakets aus einem Typ-Feld eines Ethernet-Headers des Datenpakets, und Bestimmen, anhand der ausgelesenen Typ-Information, ob es sich bei dem Datenpaket um ein Internet-Protocol-Paket handelt oder nicht;
falls es sich nicht um ein Internet-Protocol-Paket handelt, Ermitteln des verwendeten Industrial Ethernet Protokolls anhand der ausgelesenen Typ-Information; und falls es sich um ein Internet-Protocol-Paket handelt, Auslesen von mindestens einer Portnummer von mindestens einem Port des Datenpakets aus einem Header eines Folgeprotokolls zum Internet Protocol, und Ermitteln des in dem Datenpaket verwendeten Industrial Ethernet Protokolls anhand der mindestens einen ausgelesenen Portnummer.
Verfahren nach einem der Ansprüche 1 bis 7, gekennzeichnet durch folgenden Schritt:
Zusammenstellen eines für das ermittelte Industrial Ethernet Protokoll geeigneten Protokollstacks aus verschiedenen Protokollstack-Komponenten und Aktivieren des so gebildeten Protokollstacks.
9. Ein Feldgerät (103) zum Anschluss an einen Feldbus, wobei der Feldbus für Industrial Ethernet Protokolle ausgelegt ist,
gekennzeichnet durch
eine Konfigurationseinheit (116), die dazu ausgelegt ist,
ein auf dem Feldbus übertragenes Datenpaket zu analysieren;
ein in dem Datenpaket verwendetes Industrial Ethernet Protokoll zu ermitteln; und selbsttätig einen für das ermittelte Industrial Ethernet Protokoll geeigneten
Protokollstack (117) zu aktivieren.
10. Feldgerät nach Anspruch 9, dadurch gekennzeichnet, dass das Feldgerät dazu ausgelegt ist, über den Feldbus entsprechend dem ermittelten Industrial Ethernet Protokoll zu kommunizieren.
11. Feldgerät nach Anspruch 9 oder Anspruch 10, dadurch gekennzeichnet, dass die Konfigurationseinheit dazu ausgelegt ist,
Typ-Information zum Typ des Datenpakets, die aus einem Typ-Feld eines Ethernet-
Headers des Datenpakets ausgelesen wird, auszuwerten, und
mindestens einer Portnummer von mindestens einem Port des Datenpakets, welche aus einem Header einer höheren Protokollebene des Datenpaktes ausgelesen wird, auszuwerten.
12. Feldgerät nach Anspruch 11 , dadurch gekennzeichnet, dass die Konfigurationseinheit zusätzlich dazu ausgelegt ist, in dem Datenpaket enthaltene Nutzdaten auf darin enthaltene protokollspezifische Datenstrukturen zu überprüfen.
13. Feldgerät nach einem der Ansprüche 9 bis 12, dadurch gekennzeichnet, dass die Konfigurationseinheit dazu ausgelegt ist,
Typ-Information zum Typ des Datenpakets, die aus einem Typ-Feld eines Ethernet- Headers des Datenpakets ausgelesen wird, auszuwerten,
anhand der ausgelesenen Typ-Information zu bestimmen, ob es sich bei dem Datenpaket um ein Internet-Protocol-Paket handelt oder nicht, und
falls die Typ-Information ergibt, dass es sich bei dem Datenpaket um ein Internet- Protocol-Paket handelt, mindestens eine Portnummer von mindestens einem Port des Datenpakets, die aus einem Header eines Folgeprotokolls zum Internet Protocol ausgelesen wird, auszuwerten.
14. Feldgerät nach einem der Ansprüche 9 bis 13, dadurch gekennzeichnet, dass die Konfigurationseinheit dazu ausgelegt ist, mindestens eine Protokollstack- Komponente aus einem nichtflüchtigen Speicher in einen Arbeitsspeicher zu laden, und aus den geladenen Protokollstack-Komponenten einen für das ermittelte Industrial Ethernet Protokoll geeigneten Protokollstack zusammenzusetzen.
15. Feldgerät nach einem der Ansprüche 9 bis 14, dadurch gekennzeichnet, dass die Konfigurationseinheit dazu ausgelegt ist, aus verschiedenen Protokollstack-
Komponenten einen für das ermittelte Industrial Ethernet Protokoll geeigneten Protokollstack zusammenzustellen und den so gebildeten Protokollstack zu aktivieren.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP11735608.9A EP2589187A1 (de) | 2010-07-01 | 2011-06-20 | Automatisierte adaption an verschiedene industrial ethernet protokolle |
| US13/805,881 US20130208724A1 (en) | 2010-07-01 | 2011-06-20 | Automated Adaption to Various Industrial Ethernet Protocols |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE102010030811.0 | 2010-06-30 | ||
| DE102010030811A DE102010030811A1 (de) | 2010-07-01 | 2010-07-01 | Automatisierte Adaption an verschiedene Industrial Ethernet Protokolle |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2012000813A1 true WO2012000813A1 (de) | 2012-01-05 |
Family
ID=44484119
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/EP2011/060185 WO2012000813A1 (de) | 2010-06-30 | 2011-06-20 | Automatisierte adaption an verschiedene industrial ethernet protokolle |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20130208724A1 (de) |
| EP (1) | EP2589187A1 (de) |
| DE (1) | DE102010030811A1 (de) |
| WO (1) | WO2012000813A1 (de) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE102009027168B4 (de) * | 2009-06-24 | 2021-01-21 | Endress+Hauser SE+Co. KG | Verfahren zum Ermitteln einer übermittelten Telegramm-Datenlänge |
| DE102011117083A1 (de) * | 2011-10-27 | 2013-05-02 | Volkswagen Aktiengesellschaft | Slave-Steuergerät und Verfahren zur Programmierung eines Slave-Steuergeräts |
| EP2713563B1 (de) * | 2012-09-28 | 2017-08-02 | Siemens Aktiengesellschaft | Redundant betreibbares industrielles Kommunikationssystem, Kommunikationsgerät und Verfahren zum redundanten Betrieb eines industriellen Kommunikationssystems |
| DE102013103242B4 (de) * | 2013-03-28 | 2021-06-24 | Phoenix Contact Gmbh & Co. Kg | Feldgerät, Kommunikations-Chip und Verfahren zum Zugreifen auf ein Feldgerät |
| CN103780427A (zh) * | 2014-01-17 | 2014-05-07 | 加弘科技咨询(上海)有限公司 | 基于fpga生成多协议错误管理报文的方法及系统 |
| DE102014108455A1 (de) * | 2014-06-16 | 2015-12-17 | Beckhoff Automation Gmbh | Verfahren zum Betreiben eines Netzwerks |
| EP3056953A1 (de) * | 2015-02-11 | 2016-08-17 | Siemens Aktiengesellschaft | Autarkes Feldgerät der Automatisierungstechnik zur Fernüberwachung |
| KR101632835B1 (ko) * | 2015-04-14 | 2016-06-23 | 엘에스산전 주식회사 | Plc 시스템의 프로토콜 자동 설정 방법 |
| CN105978896A (zh) * | 2016-06-24 | 2016-09-28 | 天津瑞能电气有限公司 | 一种工业以太网从站转Modbus主站的通信装置 |
| DE102016221690A1 (de) * | 2016-11-04 | 2018-05-09 | Audi Ag | Verfahren zum Übertragen von Datenpaketen zwischen einem Ethernet und einem Bussystem in einem Kraftfahrzeug sowie Gatewayvorrichtung und Kraftfahrzeug |
| CN107070589A (zh) * | 2016-12-30 | 2017-08-18 | 国网浙江省电力公司电力科学研究院 | 一种基于面向对象协议与传统协议的电能表自适应方法、装置及电能表 |
| DE102017208831A1 (de) | 2017-05-24 | 2018-11-29 | Wago Verwaltungsgesellschaft Mbh | Verarbeitung von Prozessdaten |
| CN109426302B (zh) * | 2017-08-30 | 2022-05-20 | 西门子（中国）有限公司 | 一种数据分析设备和方法 |
| EP3462256A1 (de) * | 2017-09-29 | 2019-04-03 | Wachendorff Automation GmbH & Co. KG | Konfiguration eines an einem bussystem angeschlossenen messsystems |
| EP3620877A1 (de) * | 2018-09-06 | 2020-03-11 | Siemens Aktiengesellschaft | Verfahren zur simulation einer technischen anlage, gerät, system, computerprogramm und computerprogrammprodukt |
| DE102019114305A1 (de) * | 2019-05-28 | 2020-12-03 | Beckhoff Automation Gmbh | Datenübertragungsverfahren, Datenstruktur, Automatisierungsnetzwerk und Entsperrer |
| CN112448924A (zh) * | 2019-08-30 | 2021-03-05 | 北京东土科技股份有限公司 | 一种兼容多种协议的报文处理方法、系统及交换设备 |
| DE102020203732B4 (de) | 2020-03-23 | 2022-01-05 | Lenze Se | Elektrisches Steuergerät |
| CN111970230B (zh) * | 2020-06-24 | 2023-03-31 | 格创东智(深圳)科技有限公司 | 基于云端识别的工业现场协议自动解析的方法及系统 |
| KR102347881B1 (ko) * | 2020-08-21 | 2022-01-05 | 장진욱 | 자동 프로토콜 설정을 지원하는 태양광 발전을 위한 모니터링 장치 및 이의 자동 프로토콜 설정 방법 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050228509A1 (en) * | 2004-04-07 | 2005-10-13 | Robert James | System, device, and method for adaptively providing a fieldbus link |
| WO2007014905A1 (de) * | 2005-07-30 | 2007-02-08 | Weidmüller Interface GmbH & Co. KG | Verteilersystem als teil eines ethernet-netzwerks |
| EP2053802A1 (de) * | 2007-10-23 | 2009-04-29 | Phoenix Contact GmbH & Co. KG | Verfahren zum übertragen von modifizierten Datenrahmen in einem Kommunikationsnetz, Sende- und Empfangsvorrichtung für ein Kommunikationsnetz |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5613096A (en) * | 1994-11-04 | 1997-03-18 | Canon Information Systems, Inc. | Network protocol sensor |
| CN1293502C (zh) * | 1999-06-30 | 2007-01-03 | 倾向探测公司 | 用于监控网络流量的方法和设备 |
| US7274706B1 (en) * | 2001-04-24 | 2007-09-25 | Syrus Ziai | Methods and systems for processing network data |
| AU2003204296A1 (en) * | 2002-06-25 | 2003-05-12 | Pr Electronics A/S | Method and adapter for protocol detection in a field bus network |
| US7502323B2 (en) * | 2003-05-28 | 2009-03-10 | Schneider Electric Industries Sas | Access control system for automation equipment |
| JP4530806B2 (ja) * | 2004-11-05 | 2010-08-25 | 富士通株式会社 | パケット伝送装置 |
| DE102004055308A1 (de) * | 2004-11-16 | 2006-05-18 | Endress + Hauser Flowtec Ag | Funkeinheit für ein Feldgerät der Automatisierungstechnik |
| DE102006057133B4 (de) * | 2006-12-01 | 2008-08-07 | Phoenix Contact Gmbh & Co. Kg | Verfahren zum Betreiben eines ethernetfähigen Feldbusgerätes |
-
2010
- 2010-07-01 DE DE102010030811A patent/DE102010030811A1/de not_active Withdrawn
-
2011
- 2011-06-20 EP EP11735608.9A patent/EP2589187A1/de not_active Withdrawn
- 2011-06-20 US US13/805,881 patent/US20130208724A1/en not_active Abandoned
- 2011-06-20 WO PCT/EP2011/060185 patent/WO2012000813A1/de active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050228509A1 (en) * | 2004-04-07 | 2005-10-13 | Robert James | System, device, and method for adaptively providing a fieldbus link |
| WO2007014905A1 (de) * | 2005-07-30 | 2007-02-08 | Weidmüller Interface GmbH & Co. KG | Verteilersystem als teil eines ethernet-netzwerks |
| EP2053802A1 (de) * | 2007-10-23 | 2009-04-29 | Phoenix Contact GmbH & Co. KG | Verfahren zum übertragen von modifizierten Datenrahmen in einem Kommunikationsnetz, Sende- und Empfangsvorrichtung für ein Kommunikationsnetz |
Non-Patent Citations (1)
| Title |
|---|
| See also references of EP2589187A1 * |
Also Published As
| Publication number | Publication date |
|---|---|
| US20130208724A1 (en) | 2013-08-15 |
| EP2589187A1 (de) | 2013-05-08 |
| DE102010030811A1 (de) | 2012-01-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2012000813A1 (de) | Automatisierte adaption an verschiedene industrial ethernet protokolle | |
| EP2625822B1 (de) | Verfahren zur konfiguration eines oder mehrerer geräte in einem ethernet-basierten kommunikationsnetz | |
| EP2676409B1 (de) | Schleifen von mpls pfaden auf weiterleitungsebene für verbindungslose mpls netze | |
| EP3251302B1 (de) | Gerätezugriff mittels eines generischen kommunikationstreibers | |
| DE102004052075A1 (de) | Knoten für ein Bus-Netzwerk, Bus-Netzwerk und Verfahren zum Konfigurieren des Netzwerks | |
| EP3932020A1 (de) | Verfahren zum routen von telegrammen in einem automatisierungsnetzwerk, datenstruktur, automatisierungsnetzwerk und netzwerkverteiler | |
| WO2015117749A1 (de) | Feldbusmodul, maschinensteuerung und verfahren zur parametrierung eines, insbesondere sicherheitsgerichteten, feldbusmoduls | |
| DE102019114303B3 (de) | Verfahren zum Erfassen von Netzwerkteilnehmer in einem Automatisierungsnetzwerk und Automatisierungsnetzwerk | |
| EP3092748B1 (de) | Verfahren und system zur diagnose von übertragungs-störungen in einem netzwerk gemäss opc ua standard | |
| EP3051779A1 (de) | Verfahren zur funktional sicheren Verbindungsidentifizierung und Kommunikationssystem | |
| DE102005037376B3 (de) | Verfahren zur Stempelung beliebiger Ethernet-Frames in Verbindung mit Standard-Ethernet | |
| EP1649328A1 (de) | Verfahren zur automatischen anpassung eines busfähigen feldgerätes der prozessautomatisierungstechnik an das auf dem feldbus verwendete busprotokoll | |
| DE102018129813A1 (de) | Datenübertragungsverfahren und Automatisierungskommunikationsnetzwerk | |
| WO2021104897A1 (de) | Automatisierungsnetzwerk und verfahren zur datenübertragung in einem automatisierungsnetzwerk | |
| DE102007043707B4 (de) | Kommunikationssystem | |
| EP2506503A1 (de) | Automatisierungsnetzwerk mit Leitsystemkomponente | |
| WO2020048868A1 (de) | Verfahren zur simulation einer technischen anlage, gerät, system, computerprogramm und computerprogrammprodukt | |
| DE102013215029B4 (de) | Verfahren zur Datenkommunikation in einem Netzwerk sowie Netzwerk | |
| EP4070530B1 (de) | Verfahren zum zyklischen übertragen von daten zwischen kommunikationsteilnehmern auf einem datenübertragungskanal und datenübertragungssystem | |
| WO2009118289A1 (de) | Verfahren zum betreiben eines kommunikationsgerätes und kommunikationsgerät hierfür | |
| DE102019217626A1 (de) | Maschine und Verfahren zum Schutz von Geräten in einem Feldbusnetzwerk | |
| EP3963839A1 (de) | Netzwerkverteiler, automatisierungsnetzwerk und verfahren zur datenübertragung in einem automatisierungsnetzwerk | |
| DE102011084364A1 (de) | Verfahren zur telegrammweisen Datenübertragung | |
| DE102022122048A1 (de) | Ethernet-Frame, Ethernet-basiertes Netzwerk und Verfahren zur Datenkommunikation in einem auf Ethernet basierenden Netzwerk | |
| DE102004020880A1 (de) | Schnittstelle zur Kommunikation zwischen Fahrzeug-Applikationen und Fahrzeug-Bussystemen |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 11735608 Country of ref document: EP Kind code of ref document: A1 |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 2011735608 Country of ref document: EP |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 13805881 Country of ref document: US |