-
Die Erfindung betrifft ein Verfahren und eine Steuereinrichtung zum Betrieb eines IO-Link-Kommunikationssystems nach der Gattung der unabhängigen Ansprüche.
-
Stand der Technik
-
Im Maschinen- und Anlagenbau sowie in der Automatisierungstechnik haben sich zahlreiche genormte Feldbussysteme als Alternative zur parallelen Einzelverkabelung bewährt. Dabei werden an eine zentrale Steuereinrichtung eine Mehrzahl von sog. Feldbusmodulen über den Feldbus angeschlossen. An die Feldbusmodule werden wiederum Endgeräte angeschlossen.
-
Zur Feldbusebene zählen die meisten der standardisierten Feldbusse, wie sie im Maschinen- und Anlagenbau durchgängig zum Einsatz kommen. Gebräuchliche Feldbusse sind beispielsweise PROFIBUS-DP, Interbus, DeviceNet, CC-Link und CANopen. Darüber hinaus werden neuerdings auch auf dem im Bereich von Local Area Networks (LANs) bekannten Ethernet-Protokoll basierende Feldbusstandards wie PROFINET, EtherNet/IP, EtherCAT sowie Ethernet POWERLINK eingesetzt. Feldbusse sind besonders vorteilhaft bei der Überbrückung großer Entfernungen zwischen einzelnen Teilnehmern, die von mehreren 100 Metern bis zu teilweise über 10 km betragen können. Problematisch und nachteilig ist es jedoch, dass diese leistungsfähigen Bussysteme auf der Sensor-/Aktor-Ebene praktisch wirtschaftlich nicht einsetzbar sind.
-
Zur Verbindung der Endgeräte an die Feldbusmodule werden in jüngerer Zeit daher sogenannte „IO-Link“-Verbindungen verwendet. Ein solcher IO-Link sowie ein Verfahren und eine Steuereinrichtung zum Betrieb eines solchen IO-Links gehen aus der
DE 10 2012 009 494 A1 hervor. Wie dort beschrieben, übernehmen die Feldbusmodule die Rolle eines IO-Link-Masters. Als Endgeräte bzw. IO-Link-Devices (im Folgenden „IO-Link-Geräte“) kommen beispielsweise Sensoren, Aktoren, Anzeigegeräte, Bediengeräte, bis hin zu kleineren Antrieben an Maschinen in Betracht.
-
Um diese anschließen zu können, hat ein Konsortium betroffener Hersteller für den genannten IO-Link einen gleichnamigen Standard für eine intelligente Sensor-/Aktor-Schnittstelle spezifiziert, der als internationaler offener Standard in der Norm IEC 61131-9 genormt wurde. Genannte IO-Link-Geräte werden danach über Beschreibungsdateien IODD, IO-Link Device Description, beschrieben.
-
Ein solcher IO-Link stellt eine serielle Punkt-zu-Punkt-Verbindung für die Signalübertragung zwischen Sensoren und Aktoren (d.h. zwischen genannten IO-Link-Geräten) und der Steuerungsebene einer Maschine zur Verfügung. Grundsätzlich überträgt ein IO-Link Daten zwischen einem genannten IO-Link-Master und einem angeschlossenen IO-Link-Gerät (Device) als Slave. Als IO-Link-Master stehen sowohl Feldbusmodule als auch an sich bekannte SPS-Schnittstellenbaugruppen (SPS = „speicherprogrammierbare Steuerung“) zur Verfügung.
-
Ein solcher IO-Link stellt auch einen Informationstransport zum Feldbusmodul zur Verfügung, welches als TCP/IP-fähiges Gateway ausgebildet sein kann, allerdings handelt es sich bei den genannten Endgeräten bzw. IO-Link-Geräten um nicht TCP/IP-fähige Geräte. Die Datenhaltung erfolgt dabei dezentral im jeweiligen IO-Link-Gerät.
-
Ein solcher IO-Link ist zudem abwärtskompatibel zu binären Standardsensoren und verwendet durchgängig nicht abgeschirmte drei- oder fünfadrige Standardleitungen. Während die Feldbusebene für die Verknüpfung einzelner Maschinen oder deren Bestandteile mit der Steuerung der Anlage verantwortlich ist, ist der IO-Link der Maschinen- oder der Sensor-Aktor-Ebene zuzuordnen.
-
Beim Betrieb von Industrieanlagen erfolgt die Identifizierung und/oder Lokalisierung bzw. topologische Einordnung von vernetzten Geräten manuell, d.h. nicht automatisiert bzw. automatisierbar, anhand von manuell erstellten Datenbanken oder Listen, ggf. unter Berücksichtigung von Standort-Koordinaten der einzelnen Geräte.
-
Offenbarung der Erfindung
-
Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren sowie eine Steuereinrichtung zum Betrieb eines genannten IO-Link-Kommunikationssystems bereitzustellen, welche die genannten Nachteile des Standes der Technik ausräumen, und insbesondere ein Netzwerkmanagement von nicht IP-fähigen Endgeräten (insbesondere von genannten IO-Link-Geräten) aus einem TCP/IP-Netzwerk heraus zu ermöglichen bzw. solche Endgeräte in ein bestehendes Netzwerkmanagement zu integrieren gestatten.
-
Zur Lösung der genannten Aufgabe liegt dabei der Gedanke zugrunde, dass im Bereich der Büro- und Telekommunikation existente Dienste meist auf dem für die Kommunikation über das Internet bekannten TCP/IP-Protokoll (TCP/IP = „Transmission Control Protocol / Internet Protocol“) basieren bzw. auf TCP/IP-Fähigkeiten der vernetzten Geräte. Wie bereits erwähnt, sind die in industriellen Netzwerken auf der Feldebene angeordneten Geräte, z.B. Sensoren und Aktuatoren, meist nicht TCP/IP-fähig.
-
Bei einem hier betroffenen Verfahren zum Betreiben eines IO-Link-Kommunikationssystems mit wenigstens einem über einen IO-Link verbundenen IO-Link-Gerät in einem von einem SNMP(= „Simple Network Management Protocol“)-basierten Netzwerkmanagementsystem (NMS) betriebenen Kommunikationsnetzwerk wird daher erfindungsgemäß vorgeschlagen, dass SNMP-Anfragen mittels eines in einem SNMP-Gerät angeordneten Agenten in ein IO-Link-Format umgewandelt werden.
-
Bei einem hier betroffenen Verfahren zum Betreiben eines IO-Link-Kommunikationssystems mit wenigstens einem über einen IO-Link verbundenen IO-Link-Gerät in einem von einem SNMP(= „Simple Network Management Protocol“)-basierten Netzwerkmanagementsystem (NMS) betriebenen Kommunikationsnetzwerk wird erfindungsgemäß alternativ oder zusätzlich vorgeschlagen, dass das wenigstens eine IO-Link-Gerät über wenigstens eine SNMP-Anfrage mittels eines in einem SNMP-Gerät angeordneten Proxy-Agenten erkannt und/oder bedient wird, was einer zuvor genannten Umwandlung im Ergebnis gleichkommt.
-
Aus den nachfolgend beschriebenen Gründen ist zudem eine Erfassung und Verwaltung der vernetzten Geräte, insbesondere der genannten IO-Link-Geräte erforderlich. In diesem Zusammenhang müssen auf der Feldebene angeordnete, nicht TCP/IP-fähige Geräte, in ein TCP/IP Netzwerk-Management integriert werden.
-
Die Erfindung macht sich insbesondere bestimmte Eigenschaften an sich bekannter Netzwerkmanagement-Protokolle, wie bevorzugt SNMP und/oder LLDP (= „Link Layer Discovery Protocol“), zunutze. Das LLDP-Protokoll sowie das auf sogenannte „Media Endpoint Devices“ (MED) erweiterte LLDP-MED-Protokoll definiert Topologie- sowie Ortsinformationen und andere Management-Informationen für Endgeräte. Die dezentral von den Endgeräten bereitgestellten Gerätedaten sendet LLDP zu direkten Nachbarn im Netzwerk, z.B. Netzwerkschalter („network switches“). Die Netzwerkschalter speichern diese Daten in sogenannten MIB-Tabellen (MIB = „Management Information Base“), welche über das SNMP-Protokoll zu einem zentralen Netzwerkmanagementsystem (NMS) übertragen werden können, in dem die von mehreren MIBs stammenden Daten zusammengeführt werden können und daraus eine physikalische Netzwerktopologie berechnet werden kann.
-
Aus der Sicht eines Netzwerkmanagements können IO-Link-Geräte durch Implementierung von in den jeweiligen Gateway-Geräten angeordneten Proxy-Agenten („proxy agents“) von einem TCP/IP-basierten System aus betrieben werden. So können mit den folgenden beiden Ausgestaltungen des erfindungsgemäßen Verfahrens nicht TCP/IP-fähige Geräte in einem hier betroffenen Netzwerk sichtbar gemacht werden oder sogar für ein SNMP-basiertes Netzwerkmanagement geeignet bzw. zugänglich gemacht werden.
-
Gemäß einer ersten Ausgestaltung werden IO-Link-Geräte auf jeweiligen TCP/IP-Gateways anhand korrespondierender, in lokalen oder nicht-lokalen („remote“) LLDP-MIB-Tabellen erzeugter Einträge berücksichtigt. Die dabei betroffenen Informationen werden, wie nachfolgend in größerem Detail beschrieben, von der IO-Link-Umgebung auf eine SNMP- und/oder LLDP-Umgebung abgebildet.
-
Gemäß einer zweiten Ausgestaltung werden sich bei den IO-Link-Geräten vorhandene sogenannte IODD-Dateien (IODD = „IO-Link Device Description“) zunutze gemacht. Eine genannte IODD beschreibt Sensoren und Aktoren im XML-Format und enthält unter anderem Informationen zu Identifikation, Geräteparametern, Prozess- und Diagnosedaten, Kommunikationseigenschaften. Sie besteht aus einer Hauptdatei und optionalen Sprachdateien sowie optionalen Bilddateien. Um einem genannten Netzwerkmanagementsystem (NMS) oder dergleichen mittels SNMP den Zugriff auf die genannten IO-Link-Informationen zu ermöglichen, wird eine generische Gateway-MIB erzeugt, die den Zugriff zu den rohen IO-Link-Parametern bzw. -Daten anhand von in tabellarisch angeordneten „Typ-Länge-Wert“-ähnlichen Datenstrukturen erzeugten generischen MIB-Objekten ermöglicht.
-
Das erfindungsgemäße Verfahren kann so ausgestaltet sein, dass eine generische SNMP-MIB für die IO-Link-Geräte definiert wird, welche die zugreifbaren Daten des jeweiligen IO-Link-Gerätes über einen Gateway-SNMP-Agenten bevorzugt in tabellarischer Form in einem nicht-interpretierten bzw. nicht-interpretierbaren Rohformat bereitstellt. Die Interpretation der so übermittelten Rohdaten kann dann in einem genannten NMS und/oder in einem an sich bekannten MES-System (= „Manufacturing Execution System“) und/oder in einem an sich bekannten ERP-System (= „Enterprise Resource Planning“) mittels von zum jeweiligen IO-Link-Gerät zugehörigen, an sich bekannten IO-Link-IODDs (IODD = „IO Device Description“) automatisiert erfolgen. Ein genanntes MES stellt eine prozessnah operierende Ebene eines mehrschichtigen Fertigungsmanagementsystems dar.
-
Das erfindungsgemäße Verfahren kann zudem vorsehen, nicht TCP/IP-fähige IO-Link-Geräte in der Feldebene mittels einer im IO-Link-TCP/IP-Gateway vorgesehenen, bevorzugt standardmäßigen LLDP-MIB, sichtbar zu machen. Dabei kann das IO-Link-TCP/IP-Gateway eine IO-Link-Master-Instanz beinhalten. Mit den Informationen, die dieser IO-Link-Master über die angeschlossenen IO-Link-Geräte bzw. IO-Link-Devices hat, kann eine genannte in einem Gateway angeordnete, von dem LLDP bereitgestellte LLDP-Nachbar-Tabelle mit Daten befüllt werden. Dadurch werden die IO-Link-Geräte in einem vorhandenen NMS mittels des genannten SNMP sichtbar. Im Anschluss daran kann mit den IO-Link-Geräten mit über TCP/IP getunneltem IO-Link-Protokoll direkt kommuniziert werden.
-
Ein für die genannte direkte Kommunikation mit IO-Link-Geräten erforderliches IO-Link-Device-Tool kann mittels des an sich bekannten Tool Calling Interface (TCI) aus dem genannten NMS aufgerufen oder in dem NMS selbst integriert werden.
-
Ein genannter IO-Link eignet sich bevorzugt zur Implementierung des erfindungsgemäßen Verfahrens, da dieser bereits SNMP-ähnliche Mechanismen für nicht TCP/IP-fähige Geräte beinhaltet und unter anderem auch eine besondere Information mit der Bezeichnung „Location Tag“ aufweist, welche die Speicherung und Verarbeitung genannter Ortsdaten ermöglicht. Das erfindungsgemäße Verfahren kann daher so ausgestaltet sein, dass es sich einen solchen beim IO-Link-Kommunikationssystem verfügbaren „Location Tag“ zunutze macht, um genaue Positionsangaben eines IO-Link-Gerätes in dem IO-Link-Gerät, wie genannt dezentral, zu hinterlegen. Das erfindungsgemäße Netzwerkmanagement wird mit dieser Maßnahme um einen wichtigen Schritt in Richtung der an sich bekannten Ansätze „Internet der Dinge“ und „Industrie 4.0“ erweitert.
-
Die Erfindung ermöglicht demnach einen Realisierungsansatz zur vertikalen Integration der Feldebene im Sinne des Konzepts „Industrie 4.0“. Bei dem genannten Konzept verschmelzen die unterschiedlichen drei Gebiete Informationstechnik, Telekommunikation und Fertigungsindustrie miteinander.
-
Die Erfindung ist bevorzugt mittels des an sich bekannten Netzwerkmanagementprotokolls SNMP realisierbar, wobei andere ebenfalls an sich bekannte Protokolle wie CMIP (= „Common Management Information Protocol“) oder die an sich bekannte OPC-UA Spezifikation (= „OPC-Unified Architecture“) ebenfalls in Betracht kommen, diese aber derzeit nicht über eine etablierte Werkzeugbasis in Form von Netzwerkmanagementapplikationen verfügen. Das genannte CMIP entspricht dem im bekannten OSI-Standard spezifizierten Netzwerkmanagement-Protokoll, wohingegen das genannte OPC-UA dem Nachfolger von OLE im Bereich der Prozesskontrolle entspricht und Daten zwischen Systemen innerhalb eines Kommunikationsnetzwerks verfügbar macht.
-
Das erfindungsgemäße Verfahren ermöglicht eine kommunikationstechnische vertikale Integration von Automatisierungskomponenten eines in der Feldebene angeordneten Kommunikationssystems, insbesondere eines IO-Links, in übergeordnete digitale Netzwerke. Zudem wird die Integration von IO-Link Topologien in ein SNMP-basiertes Netzwerkmanagement ermöglicht.
-
Das erfindungsgemäße Verfahren ermöglicht ferner eine komfortable Verwaltung größerer Netzwerke mit einer großen Anzahl von räumlich (lokal oder global) verteilten IO-Link-Geräten, einschließlich von IO-Link-Geräten, die schwer auffindbar sind und an unzugänglichen Installationsorten angeordnet sind.
-
Im Bereich der Prozess- und Anlagenautomation ermöglicht das erfindungsgemäße Verfahren die Kenntnis bzw. Verarbeitung genauer topologischer und geografischer Daten von industriellen Anlagen bzw. deren Geräten, insbesondere bis hin zur Feldebene. Dadurch wird insbesondere ein physischer Zugang zu diesen Geräten bereitgestellt, um z.B. die nachfolgend beschriebenen Anwendungen zu ermöglichen.
-
Bei den erfindungsgemäß ermöglichten Anwendungen handelt es sich um die Fernkonfiguration von Geräten und Anlagen (einschließlich einer Multi-Gerätekonfiguration), um die Fernüberwachung (einschließlich der Bearbeitung von Störungsmeldungen) und die Ferndiagnose (einschließlich einer statischen und/oder dynamischen Anlagendiagnose) von IO-Link-Geräten über digitale (IT-)Netzwerke sowie um das Aufspielen von Software-Updates (insbesondere Firmware) an jeweiligen Endgeräten. Darüber hinaus stellt das erfindungsgemäße Verfahren ein Transportprotokoll für die automatisierte Übertragung von Produktionsdaten zu einem genannten MES- und/oder ERP-System bereit.
-
Die Erfindung betrifft auch eine Steuereinrichtung zum Betrieb eines IO-Link-Kommunikationssystems nach dem erfindungsgemäßen Verfahren.
-
Der erfindungsgemäße Verfahren und die Steuereinrichtung eignen sich insbesondere zum Betrieb eines genannten IO-Links in einer genannten SNMP-basierten Netzwerkmanagement-Umgebung, können jedoch auch in ähnlichen Netzwerkumgebungen entsprechend angewendet werden.
-
Kurze Beschreibung der Zeichnungen
-
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert.
-
Es zeigen:
-
1 zeigt eine im Stand der Technik bekannte IO-Link Sensor-Topologie eines hier betroffenen IO-Link-Übertragungssystems mit einem Ethernet-Anschluss.
-
2 zeigt eine typische Automatisierungspyramide zur Veranschaulichung des Betriebs von über Feldbus-Gateways gesteuerten Endgeräten (Sensoren und Aktoren) gemäß dem Stand der Technik.
-
3 zeigt ein Ausführungsbeispiel einer erfindungsgemäßen IO-Link-Integration mittels eines LLDP/IO-Link-Gateways.
-
4 zeigt eine beispielhafte Tabelle zur Abbildung („mapping“) von IO-Link-Ports auf MIB-Objekte gemäß der Erfindung.
-
5 zeigt eine beispielhafte Tabelle zur Abbildung („mapping“) von IO-Link-Geräten auf MIB-Objekte gemäß der Erfindung.
-
6a, b zeigen weitere Ausführungsbeispiele einer erfindungsgemäßen IO-Link-Integration mittels eines SNMP/IO-Link-Gateways.
-
7 zeigt eine beispielhafte erfindungsgemäße Übersetzung zwischen einem IODD-Objekt und einem MIB-Objekt.
-
8 zeigt schematisch eine erfindungsgemäße XSD/ASN.1-Übersetzung.
-
Ausführungsformen der Erfindung
-
Das in 1 gezeigte Übertragungssystem umfasst einen IO-Link-Master 100 und ein mit dem IO-Link-Master 100 über einen IO-Link 105 kommunizierendes IO-Link-Gerät („IO-Link Device“) 110, welches analoge Anschlüsse 112 sowie digitale Anschlüsse 114 bereitstellt. Der IO-Link-Master 100 weist eine nach dem entsprechenden Industrie-Standard ausgebildete Ethernet-Schnittstelle 115 zur Verbindung mit einer Ethernet-Leitung 117 auf. Zusätzlich zum gezeigten IO-Link-Gerät 110 ist mit dem IO-Link-Master 100 ein nur schematisch dargestelltes, weiteres IO-Link-Gerät 120 über einen weiteren IO-Link 125 verbunden. Mit dem IO-Link-Master 100 nur digital verbunden sind ferner zwei weitere Endgeräte 130, 135. Mit den genannten analogen Anschlüssen 112 bzw. digitalen Anschlüssen 114 des IO-Link-Gerätes 110 sind in dem vorliegenden Ausführungsbeispiel zwei analoge Sensoren 140, 145 sowie zwei digitale (binäre) Sensoren 150, 155 analog bzw. digital verbunden.
-
2 zeigt eine an sich bekannte Automatisierungspyramide, welche die Bereiche Management 200, Steuerung 205 und Feld 210 unterscheidet. An der Pyramidenspitze genannte Anwendungen 215 sind über Infrastrukturgeräte 220 mit Endgeräten 225 (Sensoren, Aktoren, Server, etc.) über diverse Kommunikationsleitungen 230–239 kommunikationstechnisch verbunden. Bei den Anwendungen kann es sich auch um ein gezeigtes Netzwerkmanagementsystem (NMS) handeln. Am Fuße der Pyramide befinden sich die genannten, über Feldbus-Gateways 240 mit dem Netzwerk verbundenen Endgeräte 225.
-
Die nachfolgenden Ausführungsbeispiele beruhen auf einer genannten SNMP-und genannten LLDP- bzw. genannten erweiterten LLDP-Funktionalität. Das an sich bekannte, eingangs beschriebene PROFINET-Gateway stellt bereits die nachfolgend im Detail beschriebene SNMP- und LLDP-Funktionalität zur Verfügung. Standardmäßig werden nur zwei Ethernet-Ports verwaltet, so dass dieses bei der Implementierung der Erfindung auf IO-Link-Ports erweitert werden muss.
-
Das „Simple Network Management Protocol“ (SNMP) erlaubt ein zentrales Netzwerkmanagement für viele Netzwerkkomponenten. Die primären Ziele des SNMP-Protokolls sind die Verringerung der Komplexität der Management-Funktionen, die Erweiterbarkeit des Protokolls und die Unabhängigkeit von irgendwelchen Netzwerkkomponenten. SNMP ermöglicht insbesondere die Überwachung von Netzwerkkomponenten, die Fernsteuerung und die Fernkonfiguration von Netzwerkkomponenten sowie die Fehlererkennung und die Fehlerbenachrichtigung.
-
SNMP basiert auf dem genannten TCP/IP-Protokoll und stellt einen Informationstransport zwischen NMS (= „Netzwerkmanagementsystem“) und Geräten bzw. Endgeräten zur Verfügung. Die Datenhaltung erfolgt dezentral mittels genannter MIB-Tabellen.
-
Nach dem Architekturmodell von SNMP teilt sich ein Netzwerk auf in die Stationen für das Netzwerkmanagement, die „Network Management Stations“ (NMS), die Netzwerkkomponenten und die „Network Management Agents“ (NMA). Die NMS-Stationen führen in 2 gezeigte Anwendungen zur Überwachung und Steuerung der NMAs aus. Die Netzwerkkomponenten Router, Host, Bridge oder Terminalserver haben Netzwerk-Management-Agenten, die die Management-Funktionen ausführen. Mittels SNMP findet zwischen der Managementstation (NMS) und den Netzwerkkomponenten (NMA) eine Kommunikation statt. Diese Kommunikation umfasst die Übertragung relevanter Management-Daten, die von den Netzwerkkomponenten gesammelt wurden und in der MIB abgelegt sind und zur Managementstation übertragen werden, ebenso wie die Steuerungsdaten für die Netzwerkkomponenten.
-
Beispiele solcher Informationen sind Netzwerkadressen, physikalische Adressen, Timer, Zähler und Protokollparameter. Der Agent reagiert auf SNMP-Anfragen des Managers durch die MIB-Werte abgefragt oder auch gesetzt werden. Letzteres bewirkt das Steuern des Netzwerkknoten. Zusätzlich kann der Agent von sich aus aufgrund bestimmter Ereignisse eine sogenannte „Trap Message“ (Ereignismeldung) senden.
-
SNMP verwendet „Abstract Syntax Notation One“ (ASN.1) als Sprache. Dank der Flexibilität von ASN.1 können Netzwerkobjekte je nach Bedarf zu der Management Information Base (MIB) hinzugefügt werden.
-
Das sogenannte “Link Layer Discovery Protocol” (LLDP) ermöglicht eine genaue Bestimmung der Netzwerktopologie von lokalen Kommunikationsnetzen. Die Kenntnis der Topologie sowie der physikalischen Verbindungen zwischen den Netzwerkkomponenten bietet die Voraussetzung für das Management von lokalen Netzen.
-
Das LLDP-Protokoll arbeitet mit einer eigenen „Management Information Base“ (MIB), in der die Daten über den lokalen Agenten und die erkannten Nachbar-Agenten gespeichert und für die Konfiguration des LLDP-Protokolls benutzt werden. Zu diesem Zweck versendet LLDP Datenpakete, die sogenannten LLDP-DUs (Data Units), an alle physikalischen Schnittstellen eines Gerätes. Jeder Verbindungspunkt innerhalb einer Topologie ist einmalig und wird als „Media Service Access Point“ (MSAP) eindeutig identifiziert. Über diese eindeutige Zuordnung der MSAPs kann das Netzwerkmanagement-System die Netzwerktopologie bestimmen. Ein MSAP setzt sich zusammen aus der Gerätekennung („Chassis-ID“) und einer für dieses Gerät eindeutigen Portkennung („Port-ID“).
-
Im Gegensatz zu SNMP basiert LLDP auf dem bekannten „Ethernet“-Standard und stellt einen entsprechenden Informationsaustausch bzw. Informationstransport zwischen Endgeräten und Netzwerkknoten zur Verfügung. Die mittels LLDP ermittelten Topologie-Informationen über vernetzte Geräte sind abrufbar und auch nicht IP-fähige Geräte können bei Implementierung eines entsprechenden Proxy-Agenten (= „Proxy-Agent“) abgebildet werden.
-
3 zeigt ein Ausführungsbeispiel der Erfindung, bei dem ein LLDP Proxy-Agent verwendet wird. Das gezeigte Kommunikationsnetzwerk umfasst eine genannte Management Station 700 sowie nur exemplarisch zwei mit der Management Station 700 über Ethernet-Leitungen 705, 710 verbundene Geräte 715, 720. Jedes dieser Geräte 715, 720 weist einen SNMP-Agenten 725, 730, einen LLDP-Agenten 735, 740 sowie eine genannte MIB 745, 750 auf. Die gezeigten beiden SNMP-Agenten 725, 730 sind über ein Kommunikationsleitungsnetz 755 untereinander und mit der Management Station 700 verbunden. Die beiden gezeigten, wie beschrieben dezentral arbeitenden LLDP-Agenten 735, 740 sind miteinander über eine weitere Kommunikationsleitung 760 verbunden.
-
In einem der mit dem Netzwerk verbundenen Geräte 720 ist ein Proxy-Agent 765 angeordnet, der wiederum mit einem IO-Link 770 kommunikationstechnisch verbunden ist, an den in der in 1 gezeigten Weise eine Reihe von IO-Link-Geräten 775, 780, 785, 790 angeschlossen sind.
-
Auf der Grundlage des auf dem Ethernet betriebenen TCP/IP Protokolls bzw. entsprechender TCP/IP-Gateways, werden die IO-Link-Geräte 775, 780, 785, 790 mittels in entsprechenden (hier nicht gezeigten) lokalen und nicht-lokalen (remote) LLDP-MIB-Tabellen künstlich erzeugter Einträge in das gesamte Netzwerk einbezogen. In dem vorliegenden Ausführungsbeispiel erfolgt eine Abbildung bzw. Zuordnung (mapping) von IO-Link zu SNMP und LLDP.
-
Die im Folgenden beschriebene systematische Abbildung von IO-Link Parametern auf SNMP-MIB-Objekte ist dadurch möglich, dass die grundsätzlichen Konzepte des Zugriffs und Speicherns von Daten in beiden Protokollen ähnlich erfolgt. Sowohl SNMP als auch IO-Link basieren auf strukturierten Daten. In SNMP ist die Struktur in an sich bekannter Weise in der sogenannten „Structure of Management Information“ (SMI) definiert, welches eine Untermenge des genannten ASN.1-Protokolls darstellt. Beim IO-Link basiert die Struktur auf XML-basierten Dokumenten und entsprechenden, IODD genannten XML-Definitionen. So umfasst IO-Link ‚Read’- und ‚Write’-Befehle für Objekte, welche den SET- und GET-Befehlen in SNMP entsprechen.
-
In Fällen, in denen eine genannte Abbildung von IO-Link Parametern auf bestehende SNMP-MIB-Objekte nicht möglich ist, kann ein entsprechendes MIB-Objekt in einer neu generierten IO-Link-MIB definiert werden, welche gemäß den beiden in den 4 und 5 gezeigten Tabellen enthaltenen, IO-Link gerätespezifischen LLDP Erweiterungs-MIB („lldpXIOL“) erfolgt. Wie aus 4 zu ersehen, enthalten die lokalen Tabellen in lldp, nämlich lldpXMED sowie die genannten erweiterten MIBs („lldpXIOL“), Konfigurationsinformationen für jeden Port. Da IO-Link einem Punkt-zu-Punkt Protokoll entspricht, kann für jeden Master Port maximal nur eine IO-Link-Geräteinstanz unterstützt werden. Daher kann jede Schnittstelle von mit dem Netzwerk verbundenen IO-Link-Geräten direkt über den IO-Link-Master adressiert werden. Da jedoch sogenannte „IO-Link-Hubs“ Schnittstellen für eine Anzahl einfacher binärer Sensoren und Aktuatoren bereitstellen, sollten diese Schnittstellen in den nicht-lokalen MIB-Tabellen über einen einzelnen Eintrag für jeden binären Endpunkt repräsentiert sein. Das IO-Link Adressierungsschema basiert bekanntlich auf Indizes („indices“) und Unter-Indizes („sub-indices“).
-
Die Tabellen der erweiterten MIB („lldpXIOL“) umfassen insbesondere IO-Link gerätespezifische Parameter, welche ein IO-Link-Gerät unterstützen aber nicht auf existierende lldp- oder lldpXMED-Objekte abgebildet werden können. Wie aus 5 zu ersehen, werden auch Informationen über mit dem Netzwerk verbundene Geräte bereitgestellt.
-
6a zeigt ein weiteres Ausführungsbeispiel der Erfindung, bei dem ein in einem NMS 1000 implementiertes SNMP-Gateway 1005 verwendet wird. Das SNMP-Gateway 1005 ist über einen SNMP-Proxy 1015 mit einem IO-Link-Master 1010 verbunden, und zwar über einen „IO-Link over SNMP“ 1008. Der IO-Link-Master 1010 ist in üblicher Weise mittels eines jeweiligen IO-Links 1020, 1022 mit vorliegend einem IO-Link Hub 1025 und einem Sensor 1030 verbunden.
-
Dieses Ausführungsbeispiel beruht auf den bei IO-Link-Geräten bereits vorliegenden, genannten IODDs, welche über XML-Definitionen eine formalisierte und strukturierte Geräte- und Schnittstellenbeschreibung bereitstellen. Da SNMP einen in ASN.1 kodierten, dem IO-Link ähnlichen Ansatz mit gerätespezifischen MIBs aufweist, können SNMP und IO-Link durch Abbildung der IODD-Systematik auf die rohen Gerätedaten, welche von einer geeigneten neu anzulegenden MIB bereitgestellt werden, miteinander verbunden werden.
-
Um einem genannten NMS oder dergleichen einen Zugriff auf IO-Link-Informationen mittels SNMP zu ermöglichen, wird in dem vorliegenden Ausführungsbeispiel eine generische Gateway-MIB erzeugt, welche einen Zugriff auf rohe IO-Link Parameterdaten mittels generischer MIB-Objekte gemäß der Datenstruktur „Typ-Länge-Wert“ ermöglicht. Damit das NMS diese rohen Parameterdaten richtig interpretieren kann, muss eine gerätespezifische Interpretation angewendet werden, welche anhand einer entsprechenden IODD-Datei erfolgen kann. Die IODD-Datei wird bevorzugt auf dem IO-Link-Gerät 1025, 1030 abgespeichert und mittels des genannten, generischen IO-Link-Gateway-MIB an das NMS 1000 übertragen.
-
Wie aus der 6b zu ersehen, in der ein weiteres Ausführungsbeispiel der Erfindung dargestellt ist, kann eine genannte IO-Link spezifische MIB auch auf einem IO-Link-Master 1115 in einen dortigen SNMP-Agenten 1110 („SNMP agent“) implementiert werden, anstatt die rohen IO-Link Parameterdaten and das NMS zu übertragen und dort zu übersetzen. Der SNMP-Agent 1110 bildet dabei von einem NMS 1100 generierte und im SNMP-Format bzw. entsprechend dem SNMP-Protokoll 1105 an den IO-Link-Master 1115 übertragene SNMP-Anfragen („SNMP requests“) auf entsprechende IO-Link Anfragen oder entsprechende interne Funktionen ab, um hier betroffene Daten zuzugreifen und ggf. abzuändern. Da der ursprüngliche Name eines IO-Link Parameters in einen MIB-Objektnamen kodiert ist, kann dieses interne Abbilden („mapping“) dadurch automatisiert werden, dass die entsprechenden Parameterbezeichnungen („parameter names“) bei der Suche („parsing“) verwendet werden und diese Parameternamen für den internen Zugriff verwendet werden. Es versteht sich, dass diese Vorgehensweise von der herstellerabhängigen internen Schnittstellen-Implementierung abhängt.
-
Mittels der in 7 gezeigten, beispielhaften Programmroutinen wird eine beschriebene Abbildung bzw. Übersetzung (= „mapping“) durchgeführt. Dabei werden insbesondere die folgenden Größen aus einer XSD-Notation in eine SMI-Notation übertragen bzw. übersetzt: Name, Index, Zugriffslevel, Syntax, Länge.
-
Die 8 zeigt ein Ausführungsbeispiel einer Werkzeugkette („tool chain“) zur Implementierung einer genannten Übersetzung, bei dem der an sich bekannte, von der Internationalen Fernmeldeunion herausgegebene „ITU-Standard X.694“ (ITU = „International Telecommunication Union“) angewendet wird, welcher die erforderlichen Definitionen für die Abbildung von Definitionen eines XML-Schemas in ASN.1 bereitstellt. Der gezeigte Übersetzer 1200 („XSD->ASN.1 Translator“) führt die in 7 gezeigten beiden Programmroutinen aus, um hier betroffene im XSD Format 1205 vorliegende Daten in ein mit ASN.1 kompatibles Format 1210 umzurechnen.
-
Der beschriebene Gateway-MIB Ansatz bietet in vorteilhafter Weise eine uneingeschränkte, in gewohnter Weise durchzuführende Konfigurierbarkeit von an ein hier betroffenes Kommunikationsnetzwerk angeschlossenen IO-Link-Geräten, und zwar auf der Grundlage der von einem IO-Link-System selbst bereitgestellten Mechanismen.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- DE 102012009494 A1 [0004]
-
Zitierte Nicht-Patentliteratur
-
