Protokollumsetzer und Automatisierungssystem

Die Erfindung betrifft einen Protokollumsetzer und ein Automatisierungssystem mit einem solchen Protokollumsetzer.

Diese Patentanmeldung beansprucht die Priorität der deutschen Patentanmeldung 10 2020 113 572.6, deren Offenbarungsgehalt hiermit durch Rückbezug aufgenommen wird.

Moderne Konzepte der Industrieautomation, d. h. der Steuerung und Überwachung von technischen Prozessen mit Hilfe von Software, beruhen auf der Idee einer zentralen Steu erung bei gleichzeitig verteilter Sensor-/Aktorebene. Ein Bussystem, im Weiteren als Feld bussystem bezeichnet, verbindet dabei die Feldgeräte wie Messfühler (Sensoren) und Stellglieder (Aktoren) mit einem Automatisierungsgerät.

Damit die Teilnehmer am Feldbus ihre Nachrichten Über dieselbe Leitung senden können, wird für die Nachrichtenübertragung zwischen den Teilnehmern ein normiertes Protokoll, im Weiteren als Feldbus-Protokoll bezeichnet, verwendet, das festlegt, wer (Kennung) was (Messwert, Befehl) wann (Initiative) auf dem Feldbus ausgibt.

Feldbussysteme sind heute fester Bestandteil jeder Fertigungsanlage. Dabei werden je nach Hersteller verschiedene Feldbustechnologien favorisiert, die sich in Bezug auf die Verbindungsstruktur, den Buszugang und das normierte Feldbus-Protokoll unterscheiden. In vielen Fertigungsanlagen stellt sich deshalb die Anforderung, die verschiedenen einge setzten Feldbustechnologien zu einer gemeinsamen Feldbuslösung zu verbinden. Eine solche Integration wird mit Hilfe von Protokollumsetzern, im Weiteren auch als Gateways bezeichnet, realisiert.

Gateways können unterschiedliche, auch heterogene Netzwerke miteinander verbinden und ermöglichen ein Routing über Netzwerkgrenzen hinweg. Das Gateway stellt dabei ei nen gemeinsamen Knoten dar, der zu den zu verbindenden Netzwerken gehört und den netzübergreifenden Datenverkehr abwickelt. Gateways nehmen beim Übergang von ei nem Netzwerk zum anderen Netzwerk eine Protokollumsetzung vor und konvertieren ein- gehende Daten. Vom Zielnetzwerk nicht unterstützte Protokolldaten können dabei im Ga teway wegfallen, zusätzliche für den Weitertransport nötige Protokolldaten vom Gateway ergänzt werden.

Eine wesentliche Anforderung an ein Automatisierungssystem ist die Fehlersicherheit. Beim Steuern und Überwachen von technischen Prozessen muss sichergestellt sein, dass dann, wenn das Automatisierungssystem fehlerhaft arbeitet, daraus keine Gefahr für Mensch und Umwelt resultiert.

Für eine Übertragung von sicherheitsrelevanten Nachrichten zwischen sicherheitsrelevan ten Kommunikationsteilnehmern in einem Feldbussystem wird deshalb ein sicherheitszer tifiziertes Feldbus-Protokoll, im Weiteren als Sicherheits-Feldbus-Protokoll bezeichnet, eingesetzt. Ein solches Sicherheits-Feldbus-Protokoll, allgemein, dann, wenn kein Bezug auf einen Feldbus gegeben ist, auch als Sicherheitskommunikationsprotokoll bezeichnet, ermöglicht eine sichere Nachrichtenübertragung auf dem Feldbus, auch dann, wenn sich zwischen den beiden sicherheitsrelevanten Kommunikationsteilnehmern im Übertra gungsweg beliebig viele unsichere Feldbusgeräte befinden und der Übertragungsweg also einen sogenannten Black Channel bildet.

Die Normen EN ISO 13849-1 und IEC/EN 62061 spezifizieren die zur Risikoreduzierung erforderliche sicherheitstechnische Leistungsfähigkeit von Automatisierungssystemen.

Um die gewünschte sicherheitstechnische Leistungsfähigkeit zu erreichen, haben die si cherheitszertifizierte Feld- und Automatisierungsgeräte, die die sicherheitsrelevanten Teil nehmer im Netzwerk bilden und bei denen ein Sicherheits-Feldbus-Protokoll eingesetzt wird, in der Regel eine wenigstens zweikanalige Hardware. Alternativ kann auch einkana- lige Hardware verwendet werden, wenn die Software wenigstens zweikanalig aufgebaut ist.

Um eine Kommunikation zwischen sicherheitsrelevanten Teilnehmern in Netzwerken, die unterschiedliche Sicherheits-Feldbus-Protokolle unterstützen, zu ermöglichen, werden zu sätzlich zu den herkömmlichen Gateways dann auch Sicherheits-Gateways mit zweikana- liger Hardware oder Software realisiert.

Eine zweikanalige Hardware hat allerdings erhöhte Hardware- Kosten. Eine zweikanalige Software erfordert dagegen einen leistungsfähigen Mikroprozessor sowie ausreichend Speicher. Aufgabe der Erfindung ist es, einen Protokollumsetzer für einen netzwerkübergreifenden Datenverkehr von sicherheitsrelevanten Nachrichten und ein entsprechendes Automati sierungssystem bereitzustellen, die kostengünstig realisiert werden können.

Diese Aufgabe wird mit einem Protokollumsetzer nach Anspruch 1 und einem Automati sierungssystem nach Anspruch 8 gelöst. Bevorzugte Weiterbildungen sind in den abhän gigen Ansprüchen angegeben.

In einem Automatisierungssystem mit einem ersten Netzwerk und einem zweiten Netz werk, bei dem das erste und zweite Netzwerk (10, 20) unterschiedliche Netzwerkproto kolle zum Nachrichtenaustausch verwenden, und bei dem das erste Netzwerk wenigstens einen ersten Teilnehmer mit einer ersten Sicherheitskommunikationsschicht aufweist, die ein erstes Sicherheitskommunikationsprotokoll verarbeitet, und bei dem das zweite Netz werk wenigstens einen zweiten Teilnehmer mit einer zweiten Sicherheitskommunikations schicht aufweist, die ein zweites Sicherheitskommunikationsprotokoll verarbeitet, ist zwi schen dem ersten und dem zweiten Netzwerk ein Protokollumsetzer zum Umsetzen von sicherheitsrelevanten Nachrichten zwischen dem ersten und dem zweiten Netzwerk vor gesehen. Der Protokollumsetzer weist eine einkanalige Schnittsteilen-Einrichtung, die ei nen Nachrichtenaustausch mit dem ersten Netzwerk und/ oder mit dem zweiten Netzwerk ermöglicht, auf. Eine mit der Schnittsteilen-Einrichtung verbundene einkanalige Filter-Mo- dul-Einrichtung ermittelt aus von der Schnittsteilen-Einrichtung empfangenen Nachrichten Nachrichten mit dem ersten Sicherheitskommunikationsprotokoll und Nachrichten mit dem zweiten Sicherheitskommunikationsprotokoll. Ein mit der Filter-Modul-Einrichtung verbun denes wenigstens zweikanaliges Sicherheits-Modul setzt dann die von der Filter-Modul- Einrichtung ermittelten Nachrichten mit dem ersten Sicherheitskommunikationsprotokoll in Nachrichten mit dem zweiten Sicherheitskommunikationsprotokoll beziehungsweise die von der Filter-Modul-Einrichtung ermittelten Nachrichten mit dem zweiten Sicherheitskom munikationsprotokoll in Nachrichten mit dem ersten Sicherheitskommunikationsprotokoll um.

Der Protokollumsetzer für einen netzübergreifenden Datenverkehr von sicherheitsrelevan ten Nachrichten im Automatisierungssystem kann im Wesentlichen einkanalig realisiert werden. Nur die sicherheitsrelevanten Routinen sind wenigstens zweikanalig ausgelegt. Das hat den Vorteil, dass die Hardware- beziehungsweise Softwarekosten für einen zwei ten Kanal weitgehend eingespart werden können. Die einkanalige Schnittsteilen-Einrichtung weist eine einkanalige erste Schnittstelle, die einen Nachrichtenaustausch mit dem ersten Netzwerk ermöglicht, das den wenigstens ei nen ersten Teilnehmer mit der ersten Sicherheitskommunikationsschicht aufweist, die das erste Sicherheitskommunikationsprotokoll verarbeitet, und eine einkanalige zweite Schnittstelle, die einen Nachrichtenaustausch mit dem zweiten Netzwerk ermöglicht, das den wenigstens zweiten Teilnehmer mit der zweiten Sicherheitskommunikationsschicht aufweist, die das zweite Sicherheitskommunikationsprotokoll verarbeiten, auf. Ferner weist die Filter-Modul-Einrichtung ein einkanaliges erstes Filter-Modul, um aus von der ersten Schnittstelle empfangenen Nachrichten Nachrichten mit dem ersten Sicherheits kommunikationsprotokoll zu ermitteln, und ein einkanaliges zweites Filter-Modul, um aus von der zweiten Schnittstelle empfangenen Nachrichten Nachrichten mit dem zweiten Si cherheitskommunikationsprotokoll zu ermitteln, auf. Das wenigstens zweikanalige Sicher heits-Modul ist mit dem ersten und dem zweiten Filter-Modul verbunden, um vom ersten Filter-Modul ermittelte Nachrichten mit dem ersten Sicherheitskommunikationsprotokoll in Nachrichten mit dem zweiten Sicherheitskommunikationsprotokoll beziehungsweise um vom zweiten Filter-Modul ermittelte Nachrichten mit dem zweiten Sicherheitskommunikati onsprotokoll in Nachrichten mit dem ersten Sicherheitskommunikationsprotokoll umzuset zen.

Diese Auslegung ermöglicht eine integrierte Protokollumsetzung, bei der sowohl eine Pro tokollumwandlung von nicht-sicherheitsrelevanten Nachrichten als auch von sicherheitsre levanten Nachrichten in einem einzelnen Protokollumsetzer realisierbar ist.

Das zweikanalige Sicherheits-Modul kann wenigstens zwei parallele Software-Funktions kanäle aufweisen. Im Protokollumsetzer kann dann ein kostengünstiger Mikrocontroller, der vergleichsweise wenig Speicher benötigt, da nur wenige sicherheitsrelevante Soft ware-Funktionen zweikanalig realisiert werden müssen, eingesetzt werden.

Im Protokollumsetzer kann ein mit der Filter-Modul-Einrichtung und dem Sicherheits-Mo dul verbundenes einkanaliges Betriebsfunktions-Modul vorgesehen sein, um die Filter- Modul-Einrichtung und das Sicherheits-Modul zyklisch aufzurufen. Diese Auslegung sorgt für eine stabile Funktionsweise des Protokollumsetzers.

Nachfolgend wird die Erfindung anhand von Figuren näher erläutert. Fig. 1 zeigt ein Automatisierungssystem mit einem Sicherheits-Gateway zwischen einem EtherCAT-Netzwerk und einem PROFINET-Netzwerk, wobei das EtherCAT-Netzwerk ei nen Teilnehmer mit einer Sicherheitskommunikationsschicht aufweist, die ein FSoE-Kom- munikationsprotokoll verarbeitet, und das PROFINET-Netzwerk einen Teilnehmer mit ei ner Sicherheitskommunikationsschicht aufweist, die ein PROFIsafe-Kommunikationspro- tokoll verarbeitet.

Fig. 2 zeigt den schematischen Aufbau des Sicherheits-Gateways im Automatisierungs system aus Fig. 1 .

Fig. 3 zeigt einen Ablauf einer Übertragung einer sicherheitsrelevanten Nachricht im Auto matisierungssystem aus Fig. 1 vom FSoE-Safety-Teilnehmer im EtherCAT-Netzwerk zum PROFIsafe-Safety-Teilnehmer im PROFINET-Netzwerk.

Fig. 4 zeigt einen Ablauf einer Übertragung einer sicherheitsrelevanten Nachricht im Auto matisierungssystem aus

Fig. 1 vom PROFIsafe-Safety-Teilnehmer im PROFINET-Netzwerk zum FSoE- Safety- Teilnehmer im EtherCAT-Netzwerk.

Fig. 5 zeigt den schematischen Aufbau eines Sicherheits-Gateways mit einer EtherCAT- Schnittstelle und einer I/O-Link-Schnittstelle.

Fig. 6 zeigt den schematischen Aufbau eines Sicherheits-Gateways mit einer EtherCAT- Schnittstelle und einer allgemeinen Hardware-Schnittstelle.

Die Figuren sind lediglich schematischer Natur und nicht maßstabsgetreu. Ferner sind die Bezugszeichen in den Figuren unverändert gewählt, wenn es sich um gleich ausgebildete Elemente oder Komponenten handelt.

In der Industrieautomation werden Netzwerke eingesetzt, um verteilt angeordnete Feldge räte einer Sensor-/Aktorebene mit einer Steuerungsebene zu verbinden. Die Automatisie rungsnetzwerke, auch Feldbussysteme genannt, weisen in der Regel einen seriellen Bus auf, an dem die Netzwerkteilnehmer angeschlossen sind. Dabei werden von den Herstel lern verschiedene Feldbuskonzepte eingesetzt, die sich in Bezug auf die Verbindungs struktur, den Buszugang und das normierte Feldbusprotokoll, im Weiteren allgemein, dann, wenn kein Bezug auf einen Feldbus gegeben ist, auch als Netzwerkprotokoll be zeichnet, unterscheiden. Das Netzwerkprotokoll legt fest, wie der Datenaustausch zwischen den Teilnehmern am Netzwerk durchgeführt werden soll. Dabei bestimmt das Netzwerkprotokoll die Regeln und Formate für das Kommunikationsverhalten der Teilnehmer. Das Netzwerkprotokoll hat in der Regel eine Schichtenarchitektur, wobei die einzelnen Protokollschichten im OSI-Referenzmodell definiert sind.

Der vom Netzwerkprotokoll festgelegte Nachrichtenaufbau enthält alle für den Datenaus tausch wichtigen Informationen, wie Absender und Empfänger, Nachrichtentyp, Nachrich tengröße und Prüfsumme zum Nachvollziehen einer fehlerfreien Übertragung. Diese Infor mationen werden den Nutzdaten in der Nachricht als Header vorangestellt oder als Trailer angehängt.

Die möglichen Netzwerkprotokolle können sich an verschiedenen Punkten unterscheiden. So kann im Netzwerkprotokoll festgelegt sein, dass die Kommunikation nur in eine Rich tung stattfinden darf oder auch dass gleichzeitig eine Kommunikation in beide Richtungen möglich ist. Weiterhin kann das Netzwerkprotokoll bestimmen, dass die Kommunikation mit einem Taktsignal synchronisiert wird oder asynchron erfolgen soll. Das Netzwerkpro tokoll kann darüber hinaus die Anzahl der Teilnehmer, die an der Kommunikation teilneh men dürfen, festlegen. Auch kann das Netzwerkprotokoll bestimmen, dass eine Übermitt lung an nur einen Empfänger, eine Übertragung an mehrere Empfänger oder auch eine Nachrichtenübertragung an alle Teilnehmer erfolgen soll.

Weiterhin können sich die Netzwerkprotokolle in Bezug auf die Stellung der Teilnehmer unterscheiden. Wenn alle Teilnehmer gleichberechtigt sind, erfolgt eine symmetrische Kommunikation, andernfalls eine asymmetrische Kommunikation. Bei Netzwerkprotokol len wird auch zwischen einer synchronen Kommunikation, bei der nach einer Anfrage auf eine Antwort gewartet wird, und einer asynchronen Kommunikation, bei der keine Antwort erfolgen muss, unterschieden. Das Netzwerkprotokoll kann eine paketorientierte Kommu nikation ausführen oder auch verbindungsorientiert ausgelegt sein.

Als Kommunikationsstandard für Netzwerke mit kurzer Reichweite, insbesondere auch Automatisierungsnetzwerken hat sich das Ethernet-Protokoll etabliert. Im Rahmen des OSI-Schichtenmodells legt das Ethernet-Protokoll die beiden untersten Protokollschich ten, die Bitübertragungsschicht und die Sicherungsschicht fest. Für die Datenübertragung in den höheren Protokollschichten können beim Ethernet-Konzept dann Standard-Kom munikationsprotokolle wie das TCP/IP-Protokoll eingesetzt werden. Das Ethernet-Protokoll unterteilt die zu übertragenden Daten in Datenpakete, sogenannte Frames, deren Aufbau im Standard IEEE 802.3 festgelegt ist. Dem eigentlichen Ethernet- Frame sind eine Präambel und ein Startbit, das sogenannte Start Frame Delimiter SFD, vorgeschaltet. Daran schließt sich dann das eigentliche Ethernet-Datenpaket an. Das Ethernet-Datenpaket setzt sich aus einem Kopfabschnitt, dem Header, einem Nutzdaten block und einem Endabschnitt, dem Trailer, zusammen.

Der Header startet mit einem 6-Byte-Feld für die Zieladresse, an das sich ein weiteres 6- Byte-Feld mit der Quelladresse anschließt. Dann kann ein weiteres 4-Byte-Feld, das so genannte VLAN-Tag mit zusätzlichen Steuerdaten im Header folgen, das insbesondere Priorisierungsinformationen enthält. Der Header schließt mit einem 2-Byte-Feld, dem so genannte Type-Feld, ab, welche Auskunft gibt über das Protokoll, mit dem die Daten im Nutzdatenblock zu verarbeiten sind.

Der sich an den Header anschließende Nutzdatenblock kann eine Länge von 1500 Bytes aufweisen, wobei in verschiedenen Ethernet-Protokoll-Erweiterungen auch größere Da tenblöcke erlaubt sein können. Der Nutzdatenblock wird dabei von einem in der Länge va riablen Feld, dem sogenannten PAD-Feld abgeschlossen, das die festlegte Mindestlänge des Ethernet-Frames garantiert.

An den Nutzdatenblock schließt der Trailer an, der ein 4-Byte-Feld mit einer Prüfsumme aufweist. Wenn ein Ethernet-Frame erstellt wird, wird eine CRC-Berechnung über die Bit folge durchgeführt und die Prüfsumme an den Datenblock angehängt. Der Empfänger führt nach dem Empfang die gleiche Berechnung aus. Stimmt die empfangene Prüf summe nicht mit der selbst berechneten Prüfsumme überein, geht der Empfänger von ei ner fehlerhaften Übertragung aus. Der Ethernet-Frame wird dann verworfen.

Der Einsatz des Ethernet-Standards in der Industrieautomation ermöglicht es, Echtzeitlö sungen bereitzustellen. Echtzeitfähige Feldbussysteme, die auf dem Ethernet-Standard basieren, sind beispielsweise PROFINET, EtherCAT, Powerlink oder SERCOS III. Das je weils eingesetzte Feldbusprotokoll wird dabei Type-Feld im Header des Ethernet-Frames angezeigt.

Neben dem Ethernet-Standard können in Automatisierungssystemen jedoch auch andere Feldbus-Protokolle wie beispielsweise das CANopen, Interbus oder Profibus eingesetzt werden. Feldbussysteme werden oft als Master-Slave-Systeme betrieben. Der Master-Teilnehmer im Feldbussystem ist die Steuerung, die die Buszugriffsberechtigung besitzt und Daten auf den Feldbus ausgeben kann. Die Slave-Teilnehmer im Feldbussystem sind die Feld geräte, wie beispielsweise E/A-Geräte, Ventile, Antriebe, Sensoren, Messumformer etc. Sie besitzen keine Buszugriffsberechtigung und dürfen empfangene Daten nur quittieren und auf Anforderungen durch den Master-Teilnehmer Daten übermitteln.

Bei Master-Slave-Systemen erfolgt die Steuerung über ein Feldbussystem dann in der Regel so, dass der Master-Teilnehmer zyklisch Steuerungsprozesse durchführt, um auf der Grundlage von Eingangsdaten von Slave-Teilnehmern Ausgangsdaten für diese und/oder andere Slave-Teilnehmer zu erzeugen.

Der Master-Teilnehmer verschickt nach Abschluss eines Steuerprozesszyklus die Aus gangsdaten in Form von Nachrichten auf dem Feldbus, wobei die Slave-Teilnehmer die dem jeweiligen Slave-Teilnehmer zugeordneten Ausgangsdaten aus den Nachrichten ent nehmen und mit diesen Ausgangsdaten einen lokalen Teilnehmerprozess ausführen. Die von dem lokalen Teilnehmerprozess ermittelten Daten werden dann wiederum vom Slave- Teilnehmer an den Master-Teilnehmer übertragen und anschließend als Eingangsdaten für den nächsten Steuerprozesszyklus vom Master-Teilnehmer genutzt.

Zur direkten Anbindung von Sensoren und Aktoren in einem Automatisierungssystem können zusätzlich zu dem Feldbussystem vereinfachte Kommunikationsprotokolle für den Datenaustausch genutzt werden. Ein solches Feldbussystem mit vereinfachtem Kommu nikationsprotokoll ist das I/O-Link-System, das aus einem I/O-Link-Master-Teilnehmer und einem oder mehreren I/O-Link-Slave-Teilnehmern, den Sensoren und Aktoren besteht.

Der I/O-Link-Master-Teilnehmer stellt die Schnittstelle zur überlagerten Steuerung zur Verfügung und steuert die Kommunikation mit den angeschlossenen I/O-Link-Feldgerä- ten.

Eine zentrale Anforderung an Automatisierungssysteme ist die sichere und zuverlässige Datenübertragung. Zum Steuern und Überwachen von technischen Prozessen im Rah men der Industrieautomation muss sichergestellt sein, dass Fehler im Automatisierungs system zuverlässig erkannt werden. Im Automatisierungssystem sind deshalb oft zusätz lich Sicherungsmaßnahmen, sogenannte Safety-Maßnahmen implementiert, die gewähr leisten, dass Fehler mit hoher Wahrscheinlichkeit aufgedeckt werden, um so die Gefahr unerkannter Fehler zu minimieren. In den Normen EN ISO 13849-1 und IEC/EN 62061 sind die zur Risikoreduzierung in Au tomatisierungssystemen vorgesehenen Safety-Maßnahmen beschrieben. Die für die ein zelnen Teilnehmer erforderlichen Safety-Maßnahmen hängen dabei von den, dem jeweili gen Teilnehmer zugeordneten Sicherheitsfunktionen ab. Eine wesentliche Safety-Maß- nahme ist dabei die redundante Auslegung des Teilnehmers in Form einer zweikanaligen Hardware. Alternativ kann auch eine einkanalige Hardware verwendet werden, wenn die Software dann zweikanalig aufgebaut ist.

Für die Übertragung von sicherheitsrelevanten Nachrichten zwischen sicherheitsrelevan ten Teilnehmern am Feldbus ist weiterhin ein sicherheitszertifiziertes Kommunikationspro tokoll erforderlich.

Automatisierungssysteme werden oft im Mischbetrieb mit sicherheitsrelevanten Teilneh mern und nicht-sicherheitsrelevanten Teilnehmern verwendet, wobei sich dann zwischen den sicherheitsrelevanten Teilnehmern am Feldbus beliebig viele unsichere Feldbusge räte befinden. Die sicherheitszertifizierten Kommunikationsprotokolle sind in der Regel so ausgelegt, dass sicherheitsrelevante Nachrichten auch über einen Kommunikationskanal mit ungesicherten Eigenschaften, einen sogenannten Black Channel übertragen werden können. Zwischen den sicherheitsrelevanten Teilnehmern und dem „nichtsicheren“ Feld bus ist dann das Sicherheitsprotokoll integriert, das dem Sicherheitsniveau des sicher heitsgerichteten Automatisierungssystems entspricht und Übertragungsfehler auf dem Feldbus erkennt und beherrscht.

Für die verschiedenen Feldbus-Protokolle wurden Safety-Varianten zum Übertragen von sicherheitsrelevanten Nachrichten entwickelt. So gibt es für das Ethernet-basierte Feld busprotokoll EtherCAT die Safety-Variante Safety over EtherCAT, abgekürzt FSoE. Der Sicherheitsableger für PROFINET ist PROFIsafe. Auch für das vereinfachte Kommunikati onsprotokoll I/O-Link gibt es mit I/O-Link-Safety eine Sicherheitserweiterung.

Bei komplexen Fertigungsanlagen setzen sich die Automatisierungssysteme aus unter schiedlichen, auch heterogenen Netzwerken zusammen, bei denen in den einzelnen Netzwerkbereichen abhängig vom Hersteller unterschiedliche Kommunikationsprotokolle verwendet werden. Um eine Kommunikation zwischen den Teilnehmern über Netzwerk grenzen hinaus zu ermöglichen, werden zwischen den einzelnen Netzwerken Proto kollumsetzer, im Weiteren auch als Gateways bezeichnet, eingesetzt, die die Verbindung zwischen den Netzwerken hersteilen. Das Gateway ist dann jeweils Teilnehmer in den zu verbindenden Netzwerken und wickelt den netzwerkübergreifendenden Datenverkehr ab. Dabei bearbeitet das Gateway die wei tergeleiteten Nachrichten, indem es eine Protokollumsetzung zwischen den Netzwerken vornimmt. Das Gateway kann je nach Erfordernis Protokolldaten hinzufügen oder weg nehmen.

Wenn Gateways im Rahmen einer Übertragung von sicherheitsrelevanten Nachrichten eingesetzt werden, müssen die Gateways die entsprechenden sicherheitstechnischen An forderungen erfüllen. Um Sicherheits-Gateways kostengünstig zu realisieren, wird die er forderliche zweikanalige Hardware- beziehungsweise Softwareauslegung auf den Kern- Bereich reduziert.

Das Gateway weist dann eine Schnittsteilen-Einrichtung auf, die einen Nachrichtenaus tausch mit dem ersten Netzwerk und mit einem zweiten Netzwerk ermöglicht. Mit der Schnittsteilen-Einrichtung ist dann eine einkanalige Filter-Modul-Einrichtung verbunden, das aus den von der Schnittsteilen-Einrichtung empfangenen Nachrichten Nachrichten mit einem ersten Sicherheitskommunikationsprotokoll und Nachrichten mit einem zweiten Si cherheitskommunikationsprotokoll ermittelt.

Ein mit der Filter-Modul-Einrichtung verbundenes wenigstens zweikanaliges Sicherheits- Modul im Gateway setzt die von der Filter-Modul-Einrichtung ermittelten Nachrichten mit dem ersten Sicherheitskommunikationsprotokoll in Nachrichten mit dem zweiten Sicher heitskommunikationsprotokoll beziehungsweise Nachrichten mit dem zweiten Sicherheits kommunikationsprotokoll in Nachrichten mit dem ersten Sicherheitskommunikationsproto koll um.

Mit dieser Auslegung kann im Gateway ein netzwerkübergreifender Datenverkehr auch von sicherheitsrelevanten Nachrichten im Wesentlichen einkanalig realisiert werden. Nur die sicherheitsrelevanten Routinen bei der Protokollumsetzung sind zweikanalig ausge führt. Das zweikanalige Sicherheits-Modul kann durch wenigstens zwei parallele Soft ware-Funktionskanäle realisiert werden. Durch das Gateway kann dann ein kostengünsti ger Mikrocontroller, der vergleichsweise wenig Speicher benötigt, die sicherheitsrelevante Protokollumsetzung zweikanalig durchführen.

Die einkanalige Schnittsteilen-Einrichtung kann dabei eine einkanalige erste Schnittstelle, die einen Nachrichtenaustausch mit dem ersten Netzwerk ermöglicht, das den wenigstens einen ersten Teilnehmer mit der ersten Sicherheitskommunikationsschicht aufweist, die das erste Sicherheitskommunikationsprotokoll verarbeitet, und eine einkanalige zweite Schnittstelle, die einen Nachrichtenaustausch mit dem zweiten Netzwerk ermöglicht, das den wenigstens zweiten Teilnehmer mit der zweiten Sicherheitskommunikationsschicht aufweist, die das zweite Sicherheitskommunikationsprotokoll verarbeiten, aufweisen.

Ferner kann die Filter-Modul-Einrichtung ein einkanaliges erstes Filter-Modul, um aus von der ersten Schnittstelle empfangenen Nachrichten Nachrichten mit dem ersten Sicher heitskommunikationsprotokoll zu ermitteln, und ein einkanaliges zweites Filter-Modul, um aus von der zweiten Schnittstelle empfangenen Nachrichten Nachrichten mit dem zweiten Sicherheitskommunikationsprotokoll zu ermitteln, aufweisen.

Das wenigstens zweikanalige Sicherheits-Modul ist dann mit dem ersten und dem zweiten Filter-Modul verbunden, um vom ersten Filter-Modul ermittelte Nachrichten mit dem ersten Sicherheitskommunikationsprotokoll in Nachrichten mit dem zweiten Sicherheitskommuni kationsprotokoll beziehungsweise um vom zweiten Filter-Modul ermittelte Nachrichten mit dem zweiten Sicherheitskommunikationsprotokoll in Nachrichten mit dem ersten Sicher heitskommunikationsprotokoll umzusetzen. Ein einkanaliges Betriebsfunktions-Modul ist weiter mit dem ersten und dem zweiten Filter-Modul und dem Sicherheits-Modul verbun den, um das erste Filter-Modul, das zweite Filter-Modul und das Sicherheits-Modul zyk lisch aufzurufen.

Diese Auslegung ermöglicht eine integrierte Protokollumsetzung, bei der sowohl eine Pro tokollumwandlung von nicht-sicherheitsrelevanten Nachrichten als auch von sicherheitsre levanten Nachrichten in einem einzelnen Protokollumsetzer realisierbar ist.

Fig. 1 zeigt schematisch die Grundstruktur eines Automatisierungssystems mit einem ers ten Netzwerk 10 und einem zweiten Netzwerk 20, die über ein Gateway, im Weiteren auch als Protokollumsetzer 30 bezeichnet, miteinander verbunden sind, das eine inte grierte Protokollumsetzung ausführt. Jedes Netzwerk weist wenigstens einen Master-Teil nehmer, der die Steuerungsebene bildet, und wenigstens einen Slave-Teilnehmer, der die Sensor-/Aktorebene repräsentiert, auf.

In jedem Netzwerk sind der Master-Teilnehmer und der Slave-Teilnehmer über einen seri ellen Bus miteinander verbunden, über den der Nachrichtenaustausch zwischen dem Master-Teilnehmer und dem Slave-Teilnehmer stattfindet. Der serielle Bus des ersten Netzwerkes 10 ist mit dem seriellen Bus des zweiten Netzwerkes 20 über das Gateway gekoppelt.

Die Datenübertragung im ersten Netzwerk 10 beziehungsweise im zweiten Netzwerk 20 werden jeweils vom Master-Teilnehmer in Form von Datenpaketen organisiert, wobei im ersten Netzwerk 10 beispielweise das Ethernet-Feldbusprotokoll EtherCAT und im zwei ten Netzwerk 20 beispielsweise das Ethernet-Feldbusprotokoll PROFINET eingesetzt wird. Das erste Netzwerk 10 wird deshalb im Weiteren als EtherCAT-Netzwerk 1 und das zweite Netzwerk 20 im Weiteren als PROFINET-Netzwerk 2 bezeichnet. Der Master-Teil nehmer im EtherCAT-Netzwerk 1 ist dann ein EtherCAT-Master 11 und der Master-Teil nehmer im zweiten PPROFINET-Netzwerk ein PPROFINET-Master 21.

Das Gateway, das den Datenaustausch zwischen dem EtherCAT-Netzwerk 1 und dem PPROFINET-Netzwerk 2 ausführt, ist ein EtherCAT/PPROFINET-Gateway 3, das eine Protokollumsetzung vom Feldbusprotokoll EtherCAT zum Feldbusprotokoll PROFINET und umgekehrt ausführt.

Die beiden im ersten und zweiten Netzwerk 10, 20 eingesetzten Feldbusprotokolle Ether CAT und PROFINET sind nur beispielhaft. Alternativ besteht auch die Möglichkeit, ein an deres Feldbusprotokoll auf der Grundlage des Ethernet-Standards, aber auch ein nicht- Ethernet-basiertes Feldbusprotokoll, einzusetzen.

Bei dem in Fig. 1 gezeigten Automatisierungssystem sind sowohl der Slave-Teilnehmer im EtherCAT-Netzwerk und als auch der Slave-Teilnehmer im PPROFINET-Netzwerk si cherheitsrelevant. Der Slave-Teilnehmer im EtherCAT-Netzwerk 1 , welcher auch als der erste Teilnehmer 13 bezeichnet wird, arbeitet mit der Safety-Variante Safety over Ether CAT, abgekürzt FSoE, von EtherCAT und ist ein FSoE-Safety-Teilnehmer 12. Der Ether CAT-Master 11 des EtherCAT-Netzwerk 1 steuert die Nachrichtübertragung, führt aber in der Regel keine eigenständige Prozessdatenverarbeitung aus, weshalb im EtherCAT- Master 11 dann auch das Sicherheits-Kommunikationsprotokoll FSoE nicht implementiert sein muss.

Der Slave-Teilnehmer im PROFINET-Netzwerk 1 , welcher auch als der zweite Teilnehmer 23 bezeichnet wird, arbeitet mit der Sicherheitsvariante von PROFINET namens PROFI- safe und ist ein PROFIsafe-Safety-Teilnehmer 22. Der PROFINET-Master 21 des PROFINET-Netzwerks 2 setzt dann auch das Sicherheits-Kommunikationsprotokoll PRO- Flsafe ein. Ferner ist auf dem EtherCAT/PPROFINET-Gateway 3 für eine Protokollumsetzung zwi schen dem EtherCAT-Netzwerk 1 und dem PROFINET-Netzwerk 2 sowohl das Sicher heitskommunikationsprotokoll FSoE als auch das Sicherheitskommunikationsprotokoll PROFIsafe installiert. Das EtherCAT/PPROFINET-Gateway 3 stellt deshalb ein Sicher heits-Gateway dar.

Statt einem einzelnen sicherheitsrelevanten Slave-Teilnehmer, wie in Fig. 1 gezeigt, kann auch eine beliebige Anzahl von sicherheitsrelevanten Slave-Teilnehmern am jeweiligen Feldbus vorgesehen sein. Ferner können in den einzelnen Netzwerken neben sicherheits relevanten Teilnehmern auch nicht-sicherheitsrelevante Teilnehmer eingebunden sein.

Die Steuerungsebene in den Netzwerken kann auch, je nachdem, welches Feldbusproto koll eingesetzt wird, auf mehrere Master-Teilnehmer aufgeteilt sein.

Der Nachrichtenaustausch zwischen dem EtherCAT-Netzwerk 1 und dem PROFINET- Netzwerk 2 bei dem in Fig. 1 gezeigten Automatisierungssystem erfolgt in folgender Weise:

Der FSoE-Safety-Teilnehmer 12 generiert eine FSoE-Nachricht, die vom EtherCAT-Mas- ter 11 abgeholt und an das EtherCAT/PPROFINET-Gateway 3 übertragen wird. Im Ether CAT/PPROFINET-Gateway 3 wird die FSoE-Nachricht in eine PROFIsafe-Nachricht um gewandelt. Das EtherCAT/PROFINET-Gateway 3 übergibt die PROFIsafe-Nachricht wei ter an den PROFINET -Master 21 , der die PROFIsafe-Nachricht an den PROFIsafe-Sa- fety-Teilnehmer 22 sendet, von dem die PROFIsafe-Nachricht interpretiert wird.

In der umgekehrten Richtung sendet der PROFIsafe-Safety-Teilnehmer 22 eine PROFI safe-Nachricht an den PROFINET -Master 21 , der die PROFIsafe-Nachricht an das Ether- CAT/PROFIsafe-Gateway 3 übergibt. Das EtherCAT/PPROFINET-Gateway 3 wandelt die PROFIsafe-Nachricht in eine FSoE-Nachricht um. Die FSoE-Nachricht wird dann vom EtherCAT-Master 11 abgeholt und an den FSoE-Safety-Teilnehmer 21 übertragen, von dem die FSoE-Nachricht interpretiert wird.

Die sicherheitsrelevanten Teilnehmer in den beiden Netzwerken, bei der in Fig. 1 gezeig ten Darstellung sowohl der PROFINET-Master 21 als auch die Slave-Teilnehmer FSoE- Safety-Teilnehmer 12 und PROFIsafe-Safety-Teilnehmer 22 weisen eine Sicherheitskom- munikationsschicht zum Verarbeiten von Sicherheitsdaten auf. Die Sicherheitskommuni kationsschicht ist entsprechend den Sicherheitsanforderungen in der Regel zweikanalig in Form von Hardware und/oder Software ausgelegt.

Fig. 2 zeigt im Detail den Aufbau des EtherCAT/PROFINET-Gateway 3, das als Sicher heits-Gateway arbeitet. Das EtherCAT/PROFINET-Gateway 3 weist dabei als zentrale Einheit einen Mikrocontroller 31 auf.

Zum Anschluss an das EtherCAT-Netzwerk 1 ist ein EtherCAT-Slave-Controller 32 als eine einkanalige erste Schnittstelle 42 vorgesehen, das einen Datenaustausch mit den Nachrichten auf dem EtherCAT-Feldbus 1 ermöglicht. Der EtherCAT-Slave-Controller 32 ist mit einem EtherCAT-Speicher 33 verbunden, der die Schnittstelle zwischen dem Ether CAT-Slave-Controller 32 und dem Mikrocontroller 31 bildet und in dem die zwischen dem EtherCAT-Slave-Controller 32 und dem EtherCAT-Feldbus 1 ausgetauschten Nachrichten abgelegt werden.

Zum Anschluss an den PROFINET-Feldbus 2 ist ein PROFINET-Slave-Controller 34 als eine einkanalige zweite Schnittstelle 44 vorgesehen, das einen Datenaustausch mit den Nachrichten auf dem PROFINET-Feldbus 2 durchführt. Der PROFINET-Slave-Controller

34 ist mit einem PROFINET-Speicher 35 verbunden, der die Schnittstelle zwischen dem PROFINET-Slave-Controller 34 und dem Mikrocontroller 31 bildet. Die zwischen dem PROFINET-Slave-Controller 34 und dem PROFINET-Feldbus ausgetauschten Nachrich ten werden im PROFINET-Speicher 35 abgelegt.

Auf dem Mikrocontroller 31 ist ein Software-Modul EtherCAT-Slave-Funktionen 311 vor gesehen, das mit dem EtherCAT-Speicher 33 verbunden ist und unter anderem als ein einkanaliges erstes Filter-Modul 321 arbeitet, um aus dem EtherCAT-Speicher 33 abge legten Nachrichten FSoE-Nachrichten zu ermitteln. Das Software-Modul EtherCAT-Slave- Funktionen 311 ist weiter mit einem FSoE-Speicher 312 verbunden, in dem die FSoE- Nachrichten abgelegt werden. Der FSoE-Speicher 312 hat wiederum eine Schnittstelle zu einem Software-Modul Safety-Funktionen 4, welches ein zweikanaliges Sicherheits-Modul bildet.

Auf dem Mikrocontroller 31 ist ferner ein Software-Modul PROFINET-Slave-Funktionen 313 vorgesehen, das mit dem PROFINET-Speicher 35 verbunden ist und unter anderem als ein einkanaliges zweites Filter-Modul 323 arbeitet, um aus den PROFINET-Speicher

35 abgelegten Nachrichten PROFIsafe-Nachrichten zu ermitteln. Das Software-Modul PROFINET-Slave-Funktionen 313 ist weiter mit einem PROFIsafe-Speicher 314 verbun den, in dem die PROFIsafe-Nachrichten abgelegt werden. Der PROFIsafe-Speicher 314 hat außerdem eine Schnittstelle zum zweikanaligen Software-Modul Safety-Funktionen 4.

Bis zum Software-Modul Safety-Funktionen 4 liegt im EtherCAT/PROFINET-Gateway 3 ein Black Channel vor. Das Safety-Modul Safety-Funktionen 4 kann dann Veränderungen an den FSoE-Nachrichten beziehungsweise den PROFIsafe-Nachrichten erkennen. Das Software-Modul Safety-Funktionen 4 ist weiter ausgelegt, FSoE-Nachrichten in PROFI safe-Nachrichten und PROFIsafe-Nachrichten in FSoE-Nachrichten umzuwandeln.

Auf dem Mikrocontroller 31 ist ferner ein mit dem Software-Modul EtherCAT-Slave-Funkti- onen 311 , dem Software-Modul PROFINET-Slave-Funktionen 313 und dem Software-Mo dul Safety-Funktionen 4 verbundenes einkanaliges Betriebsfunktions-Modul 315 vorgese hen, um das Software-Modul EtherCAT-Slave-Funktionen 311 , das Software-Modul PROFINET-Slave-Funktionen 313 und das Software-Modul Safety-Funktionen 4 zyklisch aufzurufen.

Das EtherCAT/PROFINET-Gateway 3 arbeitet bei der Umwandlung einer FSoE-Nachricht in eine PROFIsafe-Nachricht wie folgt:

Die in einem EtherCAT-Datenpaket enthaltene FSoE-Nachricht wird über das EtherCAT- Netzwerk 1 von dem EtherCAT-Slave-Controller 32 empfangen und in den EtherCAT Speicher 33 geschrieben. Vom EtherCAT Speicher 33 wird die FSoE-Nachricht von dem einkanaligen Software-Modul EtherCAT-Slave-Funktionen 311 zu dem FSoE-Speicher 312 übertragen.

Der Black Channel im EtherCAT/PROFINET-Gateway 3 reicht bis zum FSoE-Speicher 312. Das zweikanalige Safety-Modul Safety-Funktionen 4 kann Veränderungen an der FSoE-Nachricht, die im FSoE-Speicher 312 abgelegt ist, erkennen. Das zweikanalige Software-Modul Safety-Funktionen 4 wandelt die FSoE-Nachricht in die PROFIsafe-Nach richt um und legt diese im PROFIsafe-Speicher 314 ab.

Das einkanalige Software-Modul PROFINET-Slave-Funktionen 313 kopiert die PROFI safe-Nachricht von dem PROFIsafe-Speicher 313 in den PROFINET-Speicher 35. Wenn ein entsprechendes PROFINET-Datenpaket vom PROFINET-Slave-Controller 34 empfan gen wird, um den PROFINET-Speicher 35 zu lesen, wird die PROFIsafe-Nachricht in das PROFINET-Datenpaket vom PROFINET-Slave-Controller 34 eingefügt. Das EtherCAT/PROFINET-Gateway 3 arbeitet bei der Umwandlung einer PROFIsafe- Nachricht in eine FSoE-Nachricht wie folgt:

Die in einem PROFINET-Datenpaket enthaltene PROFIsafe-Nachricht wird vom PROFINET-Slave-Controller 34 empfangen und in den PROFINET-Speicher 35 geschrie ben. Vom PROFINET-Speicher 35 wird die PROFIsafe-Nachricht von dem einkanaligen Software-Modul PROFINET-Slave-Funktionen 313 zu dem PROFIsafe-Speicher 314 übertragen.

Der Black Channel des EtherCAT/PROFINET-Gateways 3 umfasst noch den PROFIsafe- Speicher 314. Das zweikanalige Safety-Modul Safety-Funktionen 4 kann dann Verände rungen an der PROFIsafe-Nachricht, die im PROFIsafe-Speicher 314 abgelegt ist, erken nen. Das zweikanalige Software-Modul Safety-Funktionen 4 wandelt die PROFIsafe- Nachricht in die FSoE-Nachricht um und legt die FSoE-Nachricht im FSoE-Speicher 312 ab.

Das einkanalige Software-Modul EtherCAT-Slave-Funktionen 311 kopiert die FSoE-Nach- richt von dem FSoE-Speicher 312 in den EtherCAT-Speicher 33. Wenn ein entsprechen des EtherCAT-Datenpaket vom EtherCAT-Controller 32 empfangen wird, um den Ether CAT-Speicher 33 zu lesen, wird die FSoE-Nachricht vom EtherCAT-Controller 32 in das EtherCAT-Datenpaket eingefügt.

Ein Software-Modul Betriebsfunktions-Modul 315 sorgt dafür, dass das zweikanalige Soft ware-Modul Safety-Funktionen 4 sowie das einkanalige Software-Modul EtherCAT-Slave- Funktionen 311 und das einkanalige Software-Modul PROFINET-Slave-Funktionen 313 zur Ausführung der vorstehend erläuterten Vorgänge zyklisch aufgerufen werden.

Das in Fig. 2 gezeigte EtherCAT/PROFINET-Gateway 3 ist so ausgelegt, dass sowohl eine Protokollumwandlung von EtherCAT-Nachrichten und PPROFINET-Nachrichten als auch von PROFIsafe-Nachrichten und FSoE-Nachrichten realisiert wird. Es besteht auch die Möglichkeit, statt einer integrierten Protokollumsetzung eine getrennte Protokollumset zung der sicherheitsrelevanten Nachrichten und der nicht-sicherheitsrelevante Nachrich ten vorzusehen. Die beiden Funktionen können dann statt in einem Gateway zusammen, auch getrennt in eigenständigen Gateways ausgeführt werden. Das Sicherheits-Gateway, das in Fig. 3 als kombinierter EtherCAT-Slave-Teilnehmer und PROFINET -Slave-Teilnehmer ausgebildet ist, kann dann auch nur ein EtherCAT-Slave- Teilnehmer oder ein PROFINET-Slave-Teilnehmer sein. Dann ist auch nur das Software Modul EtherCAT Slave Funktionen und der EtherCAT Slave Controller zum Anschluss an das EtherCAT -Netzwerk beziehungsweise das Software Modul PROFINET-Funktionen und der PROFINET-Slave-Controller zum Anschluss an das PROFINET-Netzwerk vorge sehen. Das Software-Modul Safety-Funktionen ist weiter so ausgelegt, FSoE-Nachrichten in PROFIsafe-Nachrichten und PROFIsafe-Nachrichten in FSoE-Nachrichten umzuwan deln.

Die Umsetzung vom EtherCAT- Datenpaket in das PROFINET-Datenpaket, dann wenn das Sicherheits-Gateway nur als EtherCAT-Slave-Teilnehmer ausgebildet ist, erfolgt in ei nem nachgeordneten EtherCAT/PROFINET-Gateway. Ein solches nachgeordneten Ether- CAT/PROFINET-Gateway führt auch die Umsetzung vom PROFINET-Datenpaket in das EtherCAT- Daten paket durch, wenn das Sicherheits-Gateway ausschließlich als PROFINET-Slave-Teilnehmer ausgebildet ist.

Das Sicherheits-Gateway kann grundsätzlich als ein Teilnehmer eines frei wählbaren Kommunikationssystems ausgestaltet sein, da sowohl das FSoE-Protokoll als auch das PROFIsafe-Protokoll auf einem beliebigen Kommunikationsweg übertragen kann. Dann muss das Software-Modul EtherCAT-Slave-Funktionen 311 beziehungsweise das Soft ware-Modul PROFINET-Slave-Funktionen 313 durch ein entsprechendes Software Modul, der EtherCAT-Slave-Controller 32 beziehungsweise der PROFINET-Slave-Controller 34 durch einen entsprechenden Controller, eine serielle Schnittstelle oder einen Dual-Port- RAM-Speicher und das EtherCAT-Netzwerk 1 beziehungsweise das PROFINET- Netzwerk 2 durch ein entsprechendes Netzwerk bzw. einen entsprechenden Feldbus, eine Punkt-zu-Punkt-Verbindung oder einen Datenbus ersetzt werden.

In Fig. 3 und Fig. 4 ist eine Datenübertragung zwischen dem FSoE-Safety-Teilnehmer 12 und dem PROFIsafe-Safety-Teilnehmer 22 im in Fig. 1 dargestellten Automatisierungs netzwerk gezeigt, wobei in Fig. 3 eine Übertragung von FSoE-Daten vom FSoE-Safety- Teilnehmer 12 zum PROFIsafe-Safety-Teilnehmer 22 und in Fig. 4 eine Übertragung von PROFIsafe-Daten vom PROFIsafe-Safety-Teilnehmer 22 zum FSoE-Safety-Teilnehmer 12 stattfindet. Die Datenübertragung erfolgt mit Hilfe von Ethernet-Datenpaketen, die sich, wie vorste hend erläutert, aus einem Header 700, einem Nutzdatenblock 710 und einem Trailer 720 mit der Datenpaket-Prüfsumme CRC zusammensetzen.

Im Header 700 der Ethernet-Datenpakete ist in einem Zieladressfeld 120 die Zieladresse DA, in einem Quelladressfeld 125 die Quelladresse SA und in einem Type-Feld 130 der EtherType enthalten. Im Type-Feld 130 ist dabei das Ethernet-Feldbus-Protokoll angege ben, mit dem die Daten im Nutzdatenblock zu verarbeiten sind. Beispielsweise hat das EtherCAT-Protokoll den Wert 0x88A4 und das PROFINET-Protokoll den Wert 0x8892.

Da beim EtherCAT-Protokoll die Ethernet-Datenpakete vom Master-Teilnehmer gesendet und nach der Verarbeitung von den Slave-Teilnehmern im Durchlauf auch wieder empfan gen werden, ist im Header sowohl für die Zieladresse DA, also im Zieladressfeld 120 und die Quelladresse SA, also im Quelladressfeld 125 kein für die Adressierung verwendeter Wert eingetragen. Beim PROFINET-Protokoll dagegen sind die Ethernet-Datenpakete, die zwischen dem Master-Teilnehmer und den Slave-Teilnehmern ausgetauscht werden, adressiert, weshalb im Header 700 jeweils ein Wert im Zieladressfeld 120 für die Zieladresse DA und im Quelladressfeld 130 für die Quelladresse SA eingetragen ist.

Der Nutzdatenblock 710 der Ethernet- Daten pakete weist dann ein eigenes Protokoll-Hea- der-Feld 140 mit Steuerdaten des jeweils verwendeten Feldbus-Protokolls, also entweder EtherCAT oder PROFINET auf. Daran schließt sich dann das eigentliche Nutzdaten-Be- reich an.

Da beim EtherCAT-Protokoll die Ethernet-Datenpakete von den Slave-Teilnehmern im Durchlauf verarbeitet werden, ist jedem Slave-Teilnehmer am Feldbus im Nutzdaten-Be- reich ein eigener Datenblock-Bereich, der Teil eines Datagramms ist. Dieser Datenblock- Bereich wird im Folgenden auch als Datagrammfeld bezeichnet. Beispielhaft sind in Fig. 3 und 4 ein erstes Datagrammfeld 150 und ein zweites Datagrammfeld 160 dargestellt.

Beim PROFINET-Protokoll dagegen sind Daten im Nutzdaten-Bereich für den jeweils in der Zieladresse genannten Feldbus-Teilnehmer bestimmt. Somit ist beispielhaft in Fig. 3 und 4 jeweils nur ein Nutzdatenfeld 155 dargestellt.

Der Nutzdatenblock wird von einem Trailer-Bereich End-Feld 170 des jeweils verwende ten Feldbus-Protokolls, also entweder EtherCAT-End oder PROFINET-End abgeschlos- sen. Im Trailer 720 ist in einem Trailer-Feld 180 dann die jeweilige Datenpaket-Prüfsumme CRC enthalten.

Wie Fig. 3 zeigt, sendet der EtherCAT-Master 11 ein erstes EtherCAT- Datenpaket E1 mit zwei leeren Datagrammen im Nutzdatenbereich an die beiden EtherCAT-Slave-Teilneh- mer FSoE-Safety-Teilnehmer 12 und EtherCAT/PROFINET-Gateway 3. Aus Gründen der Übersichtlichkeit, wird bei einem leeren Datagramm das entsprechende erste und/oder zweite Datagrammfeld 150, 160 auch nicht dargestellt. Der FSoE-Safety-Teilnehmer 12 trägt beim Durchlauf des ersten EtherCAT-Datenpaketes E1 erste Daten „FSoE-Message mit FSoE-Data“ als Schreib-Daten in das zugeordnete erste Datagrammfeld 150 des ers ten EtherCAT-Datenpaketes E1 ein. Da im EtherCAT/PROFINET-Gateway 3 noch keine Schreib-Daten vorliegen, bleibt das zugeordnete zweite Datagrammfeld 160 des ersten EtherCAT-Datenpaketes E1 leer.

Der EtherCAT-Master 11 empfängt das erste EtherCAT-Datenpaket E1 dann wieder und kopiert die ersten Daten „FSoE-Message mit FSoE-Data“. Anschließend sendet der Ether CAT-Master 11 ein zweites EtherCAT-Datenpaket E2 mit den ersten Daten „FSoE-Mes sage mit FSoE-Data“ als Lese-Daten im zweiten Datagrammfeld 160 für den EtherCAT- Slave EtherCAT/PROFINET-Gateway 3.

Der EtherCAT -Slave-Controller 32 des EtherCAT/PROFINET-Gateways 3 liest beim Durchlauf des zweiten EtherCAT-Datenpaketes E2 die ersten Daten „FSoE-Message mit FSoE-Data“ aus dem zugeordneten zweiten Datagrammfeld 160 im zweiten EtherCAT- Datenpaket E2 aus. Das dem EtherCAT/PROFINET-Gateway 3 zugeordnete zweite Data grammfeld 160 des zweiten EtherCAT-Datenpaketes E2 wird dann nicht weiter beschrie ben und bleibt leer, da im EtherCAT/PROFINET-Gateway 3 weiterhin keine Schreib-Da ten vorliegen.

Der FSoE-Safety-Teilnehmer 12 dagegen trägt beim Durchlauf des zweiten EtherCAT-Da tenpaketes E2 zweite Daten „FSoE-Message mit FSoE-Data“ als Schreib-Daten in das zugeordnete erste Datagrammfeld 150 des zweiten EtherCAT-Datenpaketes E2 ein. Die zweiten Daten „FSoE-Message mit FSoE-Data“ entsprechen dabei den ersten Daten „FSoE-Message mit FSoE-Data“, solange der FSoE-Safety-Teilnehmer 12 noch keine Antwort erhalten hat und der FSoE-Safety-Teilnehmer 12 deshalb in Reaktion auf die Ant wort noch keinen neuen Daten erzeugt hat. Der EtherCAT-Master 11 empfängt das zweite EtherCAT-Datenpaket E2 dann mit den zweiten Daten „FSoE-Message mit FSoE-Data“. Die Verarbeitung der ersten Daten „FSoE-Message mit FSoE-Data“ im in Fig. 2 gezeigten EtherCAT/PROFINET Gateway 3 erfolgt in folgender Weise:

Im EtherCAT/PROFINET Gateway 3 kopiert das einkanalige Software-Modul EtherCAT- Slave Funktionen 311 die ersten Daten „FSoE-Message mit FSoE-Data“ aus dem Ether- CAT-Speicher 33 des EtherCAT-Slave-Controllers 32 in den FSoE-Speicher 312 des Mik rocontrollers 31. Vom FSoE-Speicher 312 liest das zweikanalige Software-Modul Safety- Funktionen 4 die ersten Daten „FSoE-Message mit FSoE-Data“ aus, wandelt dann die Daten in erste Daten „PROFIsafe-Message mit FSoE-Data“ um und speichert anschlie ßend die ersten Daten „PROFIsafe-Message mit FSoE-Data“ im PROFIsafe-Speicher 314 des Mikrocontrollers 31.

Das einkanalige Software-Modul PROFINET-Slave-Funktionen 313 liest die ersten Daten „PROFIsafe-Message mit FSoE-Data“ aus dem PROFIsafe-Speicher 313 des Mikrocon trollers 31 aus und legt die ersten Daten „PROFIsafe-Message mit FSoE-Data“ im PROFINET -Speicher 35 ab.

Wie Fig. 3 dann weiter zeigt, sendet der PROFINET-Slave-Controller 34 die im PROFINET-Speicher 35 abgelegten ersten Daten „PROFIsafe-Message mit FSoE-Data“ in einem dem Nutzdatenfeld 155 eines ersten PROFINET-Datenpakets P1 an den PROFINET-Master 21. Im ersten PROFINET-Datenpaket P1 ist dabei im Header 700 im Zieladressfeld 120 als die Zieladresse DA der PROFINET-Master 21 und im Quelladress- feld 125 als die Quelladresse SA das EtherCAT/PROFINET Gateway 3 angegeben.

Der PROFINET-Master 21 empfängt das erste PROFINET-Datenpaket P1 , kopiert die ersten Daten „PROFIsafe-Message mit FSoE-Data“ und sendet ein zweites PROFINET- Datenpaket P2 an den PROFINET -Slave-Teilnehmer PROFIsafe-Safety-Teilnehmer 22.

Im zweiten PROFINET-Datenpaket P2 ist dabei im Header 700 im Zieladressfeld 120 als die Zieladresse DA der PROFIsafe-Safety-Teilnehmer 22 und im Quelladressfeld 125 als die Quelladresse SA der PROFINET-Master 21 angegeben. Der PROFIsafe-Safety-Teil nehmer 22 liest dann nach Empfang des zweiten PROFINET-Datenpaketes P2 die ersten Daten „PROFIsafe-Message mit FSoE-Data“ aus dem Nutzdatenfeld 155 aus.

In Fig. 4 werden dann in Reaktion auf die empfangenen FSoE-Data PROFIsafe-Daten vom PROFIsafe-Safety-Teilnehmer 22 zum FSoE-Safety-Teilnehmer 12 übertragen. Der PROFINET -Slave-Teilnehmer PROFIsafe-Safety-Teilnehmer 22 sendet dazu ein drittes PROFINET-Datenpaket P3 mit den ersten Daten „PROFIsafe-Message mit PROFIsafe- Data“ im Nutzdatenfeld 155 an den PROFINET-Master 21 . Im dritten PROFINET- Datenpaket P3 ist dabei im Header 700 im Zieladressfeld 120 als die Zieladresse DA der PROFINET-Master 21 und im Quelladressfeld 125 als die Quelladresse SA der PROFI- safe-Safety-Teilnehmer 22 angegeben.

Der PROFINET-Master 21 empfängt das dritte PROFI NET- Datenpaket P3 und kopiert die Daten „PROFIsafe-Message mit PROFIsafe-Data“ in das Nutzdatenfeld 155 eines vierten PROFINET-Datenpakets P4. Der PROFINET-Master 21 sendet das vierte PROFINET- Datenpaket P4 dann an das EtherCAT/PROFINET-Gateway 3. Im vierten PROFINET- Datenpaket P4 ist dabei im Header 700 im Zieladressfeld 120 als die Zieladresse DA das EtherCAT/PROFINET-Gateway 3 und im Quelladressfeld 125 als die Quelladresse SA der PROFINET-Master 21 angegeben.

Die Verarbeitung der ersten Daten „PROFIsafe-Message mit PROFIsafe-Data“ im in Fig.

2 gezeigten EtherCAT/PROFINET Gateway 3 erfolgt in folgender Weise:

Der PROFINET-Slave-Controller 34 des EtherCAT/PROFINET-Gateways 3 legt die ersten Daten „PROFIsafe-Message mit PROFIsafe-Data“ aus dem vierten PROFINET- Datenpaket P4 im PROFINET -Speicher 35 ab. Das einkanalige Software-Modul PROFINET-Slave-Funktionen 313 des EtherCAT/PROFINET-Gateways 3 überträgt dann die ersten Daten „PROFIsafe-Message mit PROFIsafe-Data“ in den PROFIsafe-Speicher 314 des Mikrocontrollers 31 .

Das zweikanalige Software-Modul Safety-Funktionen 4 liest die ersten Daten „PROFIsafe- Message mit PROFIsafe-Data“ aus dem PROFIsafe-Speicher 314 aus, wandelt die ersten Daten „PROFIsafe-Message mit PROFIsafe-Data“ in erste Daten „FSoE-Message mit PROFIsafe-Data“ um und speichert anschließend die ersten Daten „FSoE-Message mit PROFIsafe-Data“ im FSoE-Speicher 312 des Mikrocontrollers 31. Von dort liest das ein kanalige Software-Modul EtherCAT-Slave Funktionen 311 die ersten Daten „FSoE-Mes sage mit PROFIsafe-Data“ aus und schreibt die ersten Daten „FSoE-Message mit PROFI safe-Data“ als Schreib-Daten in den EtherCAT-Speicher 33 des EtherCAT-Slave-Control- lers 32.

Wie Fig. 4 weiter zeigt, sendet der EtherCAT-Master 11 ein drittes EtherCAT- Datenpaket E3 an die EtherCAT -Slave-Teilnehmer FSoE-Safety-Teilnehmer 12 und Ether CAT/PROFINET-Gateway 3. Das dem FSoE-Safety-Teilnehmer 12 zugeordnete Data- gramm ist dabei leer, da im EtherCAT-Master 11 keine Daten für den FSoE-Safety-Teil- nehmer 12 vorliegen. In das Datagramm für das EtherCAT/PROFINET-Gateway 3 hat der EtherCAT-Master 11 dagegen im zweiten Datagrammfeld 160 die zweiten Daten „FSoE- Message mit FSoE-Data“ aus dem zweiten EtherCAT-Datenpaket E2 als Lese-Daten ein getragen. Die zweiten Daten „FSoE-Message mit FSoE-Data“ entsprechen dabei den ers ten Daten „FSoE-Message mit FSoE-Data“, solange der FSoE-Safety-Teilnehmer 12 noch keine Antwort erhalten hat und der FSoE-Safety-Teilnehmer 12 deshalb in Reaktion auf die Antwort noch keinen neuen Daten erzeugt hat.

Der EtherCAT-Slave-Controller 32 des EtherCAT/PROFINET-Gateways 3 liest beim Durchlauf des dritten EtherCAT-Datenpaketes E3 die zweiten Daten „FSoE-Message mit FSoE-Data“ aus dem zugeordneten zweiten Datagrammfeld 160 im dritten EtherCAT-Da tenpaket E3 aus. Anschließend trägt der EtherCAT-Slave-Controller 32 des Ether CAT/PROFINET-Gateways 3 dann die ersten Daten „FSoE-Message mit PROFIsafe- Data“ in das zugeordnete zweite Datagrammfeld 160 des dritten EtherCAT-Datenpaketes E3 ein.

Die Verarbeitung der zweiten Daten „FSoE-Message mit FSoE-Data“ erfolgt im Ether- CAT/PROFINET Gateway 3 auf dieselbe Weise wie bei den ersten Daten „FSoE-Mes sage mit FSoE-Data“, um zweite Daten „PROFISafe-Message mit FSoE-Data“ zu erzeu gen, die dann für den PROFINET-Slave-Teilnehmer PROFIsafe-Safety-Teilnehmer 22 be stimmt sind.

Beim Durchlauf des dritten EtherCAT-Datenpaketes E3 trägt der FSoE-Safety-Teilnehmer 12 ferner dritte Daten „FSoE-Message mit FSoE-Data“ in das zugeordnete erste Data grammfeld 150 des dritten EtherCAT-Datenpaketes E3 ein. Die dritten Daten „FSoE-Mes sage mit FSoE-Data“ entsprechen dabei den ersten beziehungsweise zweiten Daten „FSoE-Message mit FSoE-Data“, solange der FSoE-Safety-Teilnehmer 12 noch keine Antwort erhalten hat und der FSoE-Safety-Teilnehmer 12 deshalb in Reaktion auf die Ant wort noch keinen neuen Daten erzeugt hat. Der EtherCAT-Master 11 empfängt dann das dritte EtherCAT-Datenpaket E3 im Rücklauf.

Aus dem dritten EtherCAT-Datenpaket E3 kopiert der EtherCAT-Master 11 die ersten Da ten „FSoE-Message mit PROF Isafe- Data“ als Lese-Daten für den EtherCAT-Slave-Teil- nehmer FSoE-Safety-Teilnehmer 12 in das zugeordnete erste Datagrammfeld 150 eines vierten EtherCAT-Datenpaketes E4. Ferner überträgt der EtherCAT-Master 11 die dritten Daten „FSoE-Message mit FSoE-Data“ aus dem dritten EtherCAT-Datenpaket E3 als Lese-Daten in das zweite Datagrammfeld 160 für den EtherCAT-Slave-Teilnehmer Ether- CAT/PROFINET-Gateway 3 im vierten EtherCAT- Daten paket E4.

Der EtherCAT -Master 11 sendet das vierte EtherCAT-Datenpaket E4 an die EtherCAT- Slave-Teilnehmer FSoE-Safety-Teilnehmer 12 und EtherCAT/PROFINET-Gateway 3. Beim Durchlauf des vierten EtherCAT- Datenpaketes E4 liest der EtherCAT-Slave-Teilneh mer FSoE-Safety-Teilnehmer 12 die ersten Daten „FSoE-Message mit PROF Isafe- Data“ aus dem zugeordneten ersten Datagrammfeld 150 des vierten EtherCAT-Datenpaketes E4 aus. Anschließend trägt der FSoE-Safety-Teilnehmer 12 dann vierte Daten „FSoE- Message mit FSoE-Data“ in das zugeordnete erste Datagrammfeld 150 des vierten Ether CAT-Datenpaketes E4 ein. Die vierten Daten „FSoE-Message mit FSoE-Data“ entspre chen dabei den ersten beziehungsweise zweiten beziehungsweise dritten Daten „FSoE- Message mit FSoE-Data“, solange der FSoE-Safety-Teilnehmer 12 noch keine Antwort erhalten hat und der FSoE-Safety-Teilnehmer 12 deshalb in Reaktion auf die Antwort noch keinen neuen Daten erzeugt hat.

Weiterhin liest der EtherCAT-Slave-Controller 32 des EtherCAT/PROFINET-Gateways 3 beim Durchlauf des vierten EtherCAT-Datenpaketes E4 die dritten Daten „FSoE-Message mit FSoE-Data“ aus dem zugeordneten zweiten Datagrammfeld 160 im vierten EtherCAT- Datenpaket E4 aus. Die Verarbeitung der dritten Daten „FSoE-Message mit FSoE-Data“ erfolgt im EtherCAT/PROFINET Gateway 3 auf dieselbe Weise wie bei den ersten Daten „FSoE-Message mit FSoE-Data“, um dritte Daten „PROFISafe-Message mit FSoE-Data“ zu erzeugen, die dann für den PROFINET-Slave-Teilnehmer PROFIsafe-Safety-Teilneh- mer 22 bestimmt sind.

Nach dem Auslesen der dritten Daten „FSoE-Message mit FSoE-Data“ aus dem zugeord neten zweiten Datagrammfeld 160 im vierten EtherCAT-Datenpaket E4 trägt der Ether CAT-Slave-Controller 32 des EtherCAT/PROFINET-Gateways 3 zweite Daten „FSoE- Message mit PROFIsafe-Data“ in das zugeordnete zweite Datagrammfeld 160 des vierten EtherCAT-Datenpaketes E4 ein. Das EtherCAT/PROFINET Gateway 3 hat die zweiten Daten „FSoE-Message mit PROFIsafe-Data“ aus zweiten Daten „PROFIsafe-Message mit PROFIsafe-Data“ erzeugt, die mit zwei weiteren PROFINET-Datenpaketen (nicht gezeigt) auf dieselbe Weise wie die ersten Daten „PROFIsafe-Message mit PROFIsafe-Data“ vom PROFIsafe-Safety-Teilnehmer 22 über den PROFINET-Master 21 zum Ether CAT/PROFINET-Gateway 3 übertragen wurden. Der EtherCAT-Master 11 empfängt das vierte EtherCAT- Datenpaket E4 dann mit den vierten Daten „FSoE-Message mit FSoE-Data“ und den zweiten Daten „FSoE-Message mit PRO Fl säte- Data“. Die Datenübertragung zwischen dem FSoE-Safety-Teilnehmer 12 und dem PROFIsafe-Safety-Teilnehmer 22 wird dann in der anhand Fig. 3 und Fig. 4 er läuterten Weise fortgesetzt.

Fig. 5 zeigt eine Realisierung eines EtherCAT/IO-Link-Gateways 300 mit einer FSoE/IO- Link-Safety-Protokollumsetzung. Dabei sind die Komponenten des EtherCAT/IO-Link- Gateways 300, die Komponenten des in Fig. 2 gezeigten EtherCAT/PROFINET-Gateways 3 entsprechen, mit denselben Bezugszeichen versehen und werden im Folgenden nicht nochmals beschrieben.

Das EtherCAT/IO-Link-Gateway 300 ist mit einem auf dem Mikrocontroller 31 angeordne ten einkanaligen Software-Modul IO-Link-Master-Funktionen 513 als Schnittstelle direkt an einen IO-Link-Netzwerk 200 angebunden, um Nachrichten mit einem IO-Link-Safety- Slave-Teilnehmer (nicht gezeigt) auszutauschen. Das einkanalige Software-Modul IO- Link-Master-Funktionen 513 arbeitet unter anderem als ein einkanaliges zweites Filter- Modul 323, um aus den vom IO-Link-Slave-Teilnehmer empfangenen Nachrichten IO- Link-Safety-Nachrichten zu ermitteln.

Das Software-Modul IO-Link-Master-Funktionen 513 ist weiter mit einem IO-Link-Safety- Speicher 514 verbunden, in dem die IO-Link-Safety-Nachrichten abgelegt werden. Der IO- Link-Safety-Speicher 514 hat außerdem eine Schnittstelle zum zweikanaligen Software- Modul Safety-Funktionen 4.

Bis zum Software-Modul Safety-Funktionen 4 liegt im EtherCAT/IO-Link-Gateway 300 ein Black Channel vor. Das Software-Modul Safety-Funktionen 4 kann dann Veränderungen an den IO-Link-Safety-Nachrichten erkennen. Das Software-Modul Safety-Funktionen 4 ist ferner ausgelegt, FSoE-Nachrichten in IO-Link-Safety-Nachrichten und IO-Link-Safety- Nachrichten in FSoE-Nachrichten umzuwandeln.

Das EtherCAT/IO-Link-Gateway 300 arbeitet bei der Umwandlung einer FSoE-Nachricht in eine IO-Link-Safety-Nachricht wie folgt: Eine FSoE-Nachricht in einem EtherCAT-Da- tenpaket wird vom EtherCAT-Slave-Controller 32 in den EtherCAT-Speicher 33 geschrie ben, der die Schnittstelle zwischen dem EtherCAT-Slave-Controller 32 und dem Mikro controller 31 bildet. Aus dem EtherCAT-Speicher 33 wird die FSoE-Nachricht von dem einkanaligen Software-Modul EtherCAT-Slave-Funktionen 311 in den FSoE-Speicher 312 übertragen, der die Schnittstelle zum zweikanaligen Software-Modul Safety-Funktionen 4 bildet.

Bis zum zweikanaligen Software-Modul Safety-Funktionen 4 erstreckt sich der Black Channel, wobei das zweikanalige Safety-Modul Safety-Funktionen 4 Veränderungen an der FSoE-Nachricht erkennt. Das zweikanalige Software-Modul Safety-Funktionen 4 wan delt die FSoE-Nachricht in eine IO-Link-Safety Nachricht um und legt die IO-Link-Safety Nachricht in dem IO-Link-Safety-Speicher 514 ab, der die Schnittstelle zwischen dem zweikanaligen Software-Modul Safety-Funktionen 4 und dem einkanaligen Software-Mo dul IO-Link-Master Funktionen 513 bildet. Das einkanalige Software-Modul IO-Link- Master-Funktionen 513 liest die IO-Link-Safety-Nachricht aus dem IO-Link-Safety- Speicher 514 aus und sendet die IO-Link-Safety-Nachricht dann an den IO-Link-Safety- Slave-Teilnehmer.

Umgekehrt wird eine vom IO-Link-Safety-Slave-Teilnehmer gesendete IO-Link-Safety- Nachricht von dem einkanaligen Software-Modul IO-Link-Master-Funktionen 513 empfan gen und in den IO-Link-Safety-Speicher 514 kopiert, der die Schnittstelle zum zweikanali gen Software-Modul Safety-Funktionen 4 bildet. Bis hierhin erstreckt sich der Black Chan nel, wobei das zweikanaligen Safety-Modul Safety-Funktionen 4 Veränderungen an der IO-Link-Safety-Nachricht erkennt.

Das zweikanalige Software-Modul Safety-Funktionen 4 wandelt die IO-Link-Safety- Nachricht in eine FSoE-Nachricht um und legt die FSoE-Nachricht in dem FSoE-Speicher 312 ab, der die Schnittstelle zwischen dem zweikanaligen Software-Modul Safety-Funktio nen 4 und dem einkanaligen Software-Modul EtherCAT Slave Funktionen 311 bildet. Das einkanalige Software-Modul EtherCAT -Slave-Funktionen 311 kopiert die FSoE-Nachricht aus dem FSoE-Speicher 312 in den EtherCAT-Speicher 33, der die Schnittstelle zwischen EtherCAT-Slave-Controller 32 und dem einkanaligen Software-Modul EtherCAT Slave Funktionen 311 bildet.

Wenn ein EtherCAT-Datenpaket vom EtherCAT-Slave-Controller 32 empfangen wird, um den EtherCAT-Speicher 33 des EtherCAT/IO-Link-Gateway 300 zu lesen, wird die FSoE- Nachricht in das EtherCAT-Datenpaket vom EtherCAT-Slave-Controller 32 im Durchlauf eingefügt. Das auf dem Mikroprozessor 31 vorgesehene Software-Modul Betriebsfunktions-Modul 315 sorgt dafür, dass das zweikanalige Software-Modul Safety Funktionen 4, das einka- nalige Software-Modul IO-Link-Master Funktionen 513 sowie das einkanalige Modul EtherCAT Slave Funktionen 311 zyklisch aufgerufen werden.

Das EtherCAT/IO-Link-Gateway 300 ist als EtherCAT -Slave-Teilnehmer dargestellt. Das Sicherheits-Gateway könnte aber auch ein Teilnehmer eines anderen Feldbussystems sein, da das FSoE-Protokoll nicht auf die Übertragung auf dem EtherCAT-Feldbus einge schränkt ist.

Fig. 6 den Aufbau eines Sicherheits-Gateways, das eine Umsetzung zwischen dem FSoE-Protokoll und einem Safety-Hardware-Protokoll ausführt. Dabei sind Komponenten, die Komponenten des in Fig. 2 gezeigten EtherCAT/PROFINET-Gateways 3 entsprechen, mit denselben Bezugszeichen versehen und werden im Folgenden nicht nochmals be schrieben.

Das im Weiteren als EtherCAT/Hardware-Gateway 301 bezeichneten Sicherheits-Gate way ist mit einem auf dem Mikrocontroller 31 angeordneten einkanaligen Software-Modul Standard-Funktionen 613 an eine Hardware 201 angeschlossen, um Nachrichten mit ei nem Hardware-Teilnehmer (nicht gezeigt) auszutauschen. Die Schnittstelle des Software- Moduls Standard Funktionen 613 zur Hardware 201 kann beispielsweise ein IO-Port, eine serielle Schnittstelle, ein Datenbus oder ein Feldbus sein.

Das einkanalige Software-Modul Standard-Funktionen 613 arbeitet unter anderem als ein einkanaliges zweites Filter-Modul 323, um aus den von dem Hardware-Teilnehmer emp fangenen Nachrichten Safety-Nachrichten zu ermitteln. Das Software-Modul Standard Funktionen 613 kann ferner beliebige weitere nicht-sicherheitsrelevante Funktionen ent halten.

Das Software-Modul Standard Funktionen 613 ist weiter mit einem Safety-Speicher 614 verbunden, in dem die Safety-Nachrichten abgelegt werden. Der Safety-Speicher 614 hat außerdem eine Schnittstelle zum zweikanaligen Software-Modul Safety-Funktionen 4.

Bis zum Software-Modul Safety-Funktionen 4 erstreckt sich im EtherCAT/Hardware-Gate way 301 ein Black Channel. Das Software-Modul Safety-Funktionen 4 kann dann Verän derungen an den Safety-Nachrichten erkennen. Das Software-Modul Safety-Funktionen 4 ist ausgelegt, FSoE-Nachrichten in Safety-Nachrichten und Safety-Nachrichten in FSoE- Nachrichten umzuwandeln.

Es besteht die Möglichkeit, dass das Software-Modul Safety-Funktionen 4 zusätzlich eine Flardware-Schnittstelle (nicht gezeigt) besitzen. Auch kann vorgesehen sein, dass das Software-Modul Safety-Funktionen 4 beliebige Software-Funktionen ausführt. Die Soft ware-Funktionen können dabei ähnlich bespielweise zu einer Safety-Logik auch konfigu rierbar sein. Das Software-Modul Safety-Funktionen 4 kann dann Daten verarbeiten, die über die Flardware-Schnittstelle, von den anderen Software Modulen im Gateway oder über die FSoE-Nachricht empfangen beziehungsweise gesendet werden. Eine solche Ausgestaltung des Software-Modul Safety-Funktionen 4 ist auch bei den in Fig. 2 und Fig. 5 gezeigten Gateways möglich.

Das EtherCAT/Flardware-Gateway 301 arbeitet bei der Umwandlung einer FSoE-Nach- richt in eine Safety-Nachricht wie folgt: Eine FSoE-Nachricht in einem EtherCAT- Datenpa ket wird vom EtherCAT-Slave-Controller 32 in den EtherCAT-Speicher 33 geschrieben, der die Schnittstelle zwischen dem EtherCAT-Slave-Controller 32 und dem Mikrocontroller 31 bildet. Aus dem EtherCAT-Speicher 33 wird die FSoE-Nachricht von dem einkanaligen Software-Modul EtherCAT -Slave-Funktionen 311 in den FSoE-Speicher 312 übertragen, der die Schnittstelle zum zweikanaligen Software-Modul Safety-Funktionen 4 bildet.

Bis zum zweikanaligen Software-Modul Safety-Funktionen 4 erstreckt sich der Black Channel, wobei das zweikanalige Safety-Modul Safety-Funktionen 4 Veränderungen an der FSoE-Nachricht erkennt. Das zweikanalige Software-Modul Safety-Funktionen 4 wan delt die FSoE-Nachricht in eine Safety-Nachricht um und legt die Safety-Nachricht in dem Safety-Speicher 614 ab, der die Schnittstelle zwischen dem zweikanaligen Software-Mo dul Safety-Funktionen 4 und dem einkanaligen Software-Modul Standard Funktionen 613 bildet. Das einkanalige Software-Modul Standard Funktionen 613 liest die Safety-Nach richt aus dem Safety-Speicher 614 aus und sendet die Safety-Nachricht dann an den Flardware-T eilnehmer.

Umgekehrt wird eine vom Flardware-Teilnehmer gesendete Safety-Nachricht von dem einkanaligen Software-Modul Standard Funktionen 613 empfangen und in den Safety- Speicher 614 kopiert, der die Schnittstelle zum zweikanaligen Software-Modul Safety- Funktionen 4 bildet. Bis hierhin erstreckt sich der Black Channel, wobei das zweikanaligen Safety-Modul Safety-Funktionen 4 Veränderungen an der Safety-Nachricht erkennt. Das zweikanalige Software-Modul Safety-Funktionen 4 wandelt die Safety-Nachricht in eine FSoE-Nachricht um und legt die FSoE-Nachricht in dem FSoE-Speicher 312 ab, der die Schnittstelle zwischen dem zweikanaligen Software-Modul Safety-Funktionen 4 und dem einkanaligen Software-Modul EtherCAT Slave Funktionen 311 bildet. Das einkana- lige Software-Modul EtherCAT -Slave-Funktionen 311 kopiert die FSoE-Nachricht aus dem FSoE-Speicher 312 in den EtherCAT-Speicher 33, der die Schnittstelle zwischen Ether- CAT-Slave-Controller 32 und dem einkanaligen Software-Modul EtherCAT Slave Funktio nen 311 bildet.

Wenn ein EtherCAT-Datenpaket vom EtherCAT-Slave-Controller 32 empfangen wird, um den EtherCAT-Speicher 33 des EtherCAT/Flardware-Gateway 301 zu lesen, wird die FSoE-Nachricht in das EtherCAT-Datenpaket vom EtherCAT-Slave-Controller 32 im Durchlauf eingefügt.

Das auf dem Mikroprozessor 31 vorgesehene Software-Modul Betriebsfunktions-Modul 315 sorgt dafür, dass das zweikanalige Software-Modul Safety Funktionen 4, das einka- nalige Software-Modul Standard Funktionen 613 sowie das einkanalige Modul EtherCAT Slave Funktionen 311 zyklisch aufgerufen werden.

Das EtherCAT/Flardware-Gateway 301 ist als EtherCAT-Slave-Teilnehmer dargestellt.

Das Sicherheits-Gateway könnte aber auch ein Teilnehmer eines anderen Feldbussys tems sein, da das FSoE-Protokoll nicht auf die Übertragung auf dem EtherCAT-Feldbus eingeschränkt ist.