-
Die vorliegende Erfindung bezieht sich auf eine Kommunikationseinrichtung und ein Verfahren zur Kommunikation zwischen einer Bedienoberfläche einer Maschine und einer Steuereinrichtung der Maschine.
-
Eine Maschine, wie beispielsweise eine Druckmaschine, eine NC- oder CNC-Maschine (CNC = Computerized Numerical Control = computerunterstützte numerische Steuerung), eine Automatisierungsanlage mit insbesondere einem Schweißwerkzeug und einer Transporteinrichtung, usw. findet bei der Fertigung und/oder Bearbeitung von Produkten in vielen Bereichen Verwendung. Damit Bedienpersonal den Zustand der Maschine überwachen und bestimmen kann, hat die Maschine meist eine Bedienoberfläche, welche auch als Mensch-Maschine-Schnittstelle oder kurz HMI (Human Machine Interface) bezeichnet wird.
-
Bedienoberflächen sind in verschiedene Bedienoberflächentypen unterteilt, wie eine an der Maschine festinstallierte Maschinen-Bedienoberfläche, eine mobile Smart-Bedienoberfläche, eine mit dem Internet verbundene Web-Bedienoberfläche. Noch dazu sind die Bedienoberflächen derzeit auf verschiedenen Plattformen, wie beispielsweise einem Personalcomputer, einem Tablet-PC, einem Smartphone, usw., aufgebaut. Alle diese verschiedenen Bedienoberflächen haben unterschiedliche Betriebssysteme, wie beispielsweise Windows, Linux, VxWorks, MacOS, usw. Dadurch sind auch die Kommunikationsanforderungen für einen Datenaustausch mit der Maschine, die beispielsweise eine allen Bedienoberflächen übergeordnete Steuereinrichtung aufweist, sehr unterschiedlich.
-
Derzeit ist nur eine native Kommunikationsanbindung zwischen einer Bedienoberfläche und einer Steuereinrichtung der Maschine vorgesehen, wobei die Steuereinrichtung allen Bedienoberflächen übergeordnet ist. Die native Kommunikationsanbindung kann auf der Grundlage eines MLP-Protokolls mit Hilfe der proprietären MLPI-Schnittstelle (MLPI = Motion Logic Programming Interface) und/oder eines industriellen M2M-Kommunikationsprotokolls realisiert sein. Hierbei kann das industrielle M2M-Kommunikationsprotokoll OPC Unified Architecture sein, das auch kurz OPC UA genannt wird.
-
Problematisch ist jedoch, dass für jede unterstützte Plattform, wie beispielsweise ein Personalcomputer, ein Tablet-PC, ein Smartphone, usw., ein nativer Kommunikations-Client in der jeweiligen plattformspezifischen Programmiersprache notwendig ist. Beispielsweise gilt folgendes: Bei IOS ist ObjectiveC, bei Android ist Java, bei Windows ist .Net, bei Linux ist C++ als nativer Kommunikations-Client erforderlich. Dieser native Kommunikations-Client muss für die Kommunikation zwischen Bedienoberfläche und Steuereinrichtung der Maschine entweder zugekauft werden, wie beispielsweise ein UPC-UA JavaClient, oder aufwändig entwickelt werden. Ein weiterer Nachteil besteht darin, dass die Pflege nativer Clients bei möglichen Anpassungen der Schnittstelle sehr zeitaufwändig ist.
-
Daher ist es Aufgabe der vorliegenden Erfindung, eine Kommunikationseinrichtung und ein Verfahren zur Kommunikation zwischen einer Bedienoberfläche einer Maschine und einer Steuereinrichtung der Maschine bereitzustellen, mit welchen die zuvor genannten Probleme gelöst werden können. Insbesondere sollen eine Kommunikationseinrichtung und ein Verfahren zur Kommunikation zwischen einer Bedienoberfläche einer Maschine und einer Steuereinrichtung der Maschine bereitgestellt werden, bei welchen einfach und kostengünstig eine universelle Datenanbindung für alle Bedienoberflächentypen, wie Maschinen-Bedienoberfläche, Smart-Bedienoberfläche, Web-Bedienoberfläche, auf allen Plattformen, wie Personalcomputer (PC), Tablet-PC, SmartPhone, und unterschiedlichen Betriebssystemen, wie Windows, Linux, VxWorks, MacOS, bereitgestellt wird.
-
Diese Aufgabe wird durch eine Kommunikationseinrichtung zur Kommunikation zwischen einer Bedienoberfläche einer Maschine und einer Steuereinrichtung der Maschine nach Patentanspruch 1 gelöst.
-
Vorteilhafte weitere Ausgestaltungen der Kommunikationseinrichtung sind in den abhängigen Patentansprüchen angegeben.
-
Die Kommunikationseinrichtung hat zur Bedienoberfläche eine Schnittstelle, welche auf allen zu unterstützenden Plattformen einheitlich ohne weitere Anpassungen verwendet werden kann. Die Schnittstelle setzt dabei auf offenen Standards auf, wodurch die Zukunftssicherheit der Schnittstelle gewährleistet wird.
-
Die Kommunikationseinrichtung ermöglicht eine Kapselung einer proprietären Schnittstelle innerhalb eines offenen Standards.
-
Somit ist über die Kommunikationseinrichtung nur eine Kommunikationsanbindung der Bedienoberfläche an die Steuereinrichtung für alle Clients oder Bedienoberflächen vorhanden, was den Aufwand und damit die Kosten für Installation und Wartung der Maschine deutlich senkt.
-
Darüber hinaus besteht mit der Kommunikationseinrichtung für die Bedienoberfläche eine vollständige Plattformunabhängigkeit durch Web-Technik ohne für die Plattform native Komponenten. Daher ist mit der Kommunikationseinrichtung eine große Flexibilität für die Bedienoberfläche realisiert.
-
Noch dazu ist mit der Kommunikationseinrichtung eine agnostische Kommunikationsanbindung zur Steuereinrichtung der Maschine ermöglicht, gemäß welcher die Bedienoberfläche und die Steuereinrichtung der Maschine auf beliebige Weise ausgestaltet sein können, solange sie über einen WebSocket-Client miteinander kommunizieren können.
-
Ferner ist der JavaScript Code in der Kommunikationseinrichtung und in allen Bedienoberflächen, die auch als Clients bezeichnet werden können, identisch.
-
Die Kommunikationseinrichtung führt eine WebSocket-Protokolltransformation aus, mittels welcher wenigstens zwei völlig unterschiedliche Kommunikationsprotokolle unterstützt werden, deren Schnittstelle aus Sicht des Benutzers absolut identisch ist.
-
Die Aufgabe wird zudem durch ein Verfahren zur Kommunikation zwischen einer Bedienoberfläche für eine Maschine und einer Steuereinrichtung der Maschine nach Patentanspruch 10 gelöst.
-
Das Verfahren erzielt die gleichen Vorteile, wie sie zuvor in Bezug auf die Kommunikationseinrichtung genannt sind.
-
Weitere mögliche Implementierungen der Erfindung umfassen auch nicht explizit genannte Kombinationen von zuvor oder im Folgenden bezüglich der Ausführungsbeispiele beschriebenen Merkmale oder Ausführungsformen. Dabei wird der Fachmann auch Einzelaspekte als Verbesserungen oder Ergänzungen zu der jeweiligen Grundform der Erfindung hinzufügen.
-
Nachfolgend ist die Erfindung unter Bezugnahme auf die beiliegende Zeichnung und anhand von Ausführungsbeispielen näher beschrieben. Es zeigen:
-
1 ein Blockschaltbild einer Maschine mit einer Kommunikationseinrichtung gemäß einem ersten Ausführungsbeispiel; und
-
2 ein schematisches Zeitverlaufsdiagramm zur Darstellung einer Kommunikation zwischen einer Bedienoberfläche und einer Steuereinrichtung der Maschine mit der Kommunikationseinrichtung gemäß dem ersten Ausführungsbeispiel.
-
In den Figuren sind gleiche oder funktionsgleiche Elemente, sofern nichts anderes angegeben ist, mit denselben Bezugszeichen versehen.
-
1 zeigt eine Maschine 1 mit einer Bedienoberfläche 10, einer Kommunikationseinrichtung 20 und einer Steuereinrichtung 30, welche Daten 35 der Maschine 1 speichert. Die Bedienoberfläche 10 hat wiederum ein erstes Bediengerät 11, ein zweites Bediengerät 12 und eine Kommunikationseinheit 15 mit einer Schnittstelle 151 für einen Kommunikationskanal 151, 212. Die Kommunikationseinrichtung 20 hat Einheiten 21 bis 25. Die Einheit 21 hat eine Schnittstelle 211 zur Kommunikation gemäß HTTP (Hypertext Transfer Protocol) und eine Schnittstelle 212 zu der Schnittstelle 151 der Bedienoberfläche 10. Die Einheiten 23, 25 haben jeweils eine Schnittstelle 231, 251 zu Schnittstellen 31, 32 der Steuereinrichtung 30.
-
Die Maschine 1 kann beispielsweise eine Druckmaschine, eine NC-Maschine, eine CNC-Maschine, usw. sein. Die Maschine 1 kann jedoch auch ganz allgemein eine Automatisierungsanlage sein, in welcher Produkte bearbeitet und/oder gefertigt werden.
-
Die Steuereinrichtung 30 steuert die Maschine 1 für Steuerungs- und Antriebszwecke und speichert hierfür die Daten 35. Die Daten 35 können Sollwerte sein, welche bei der Steuerung der Maschine 1 mit der Steuereinrichtung 30 zu erreichen sind. Zudem können die Daten 35 Istwerte sein, welche bei der Steuerung der Maschine 1 mit der Steuereinrichtung 30 auftreten. Beispielsweise kann die Maschine 1 einen oder mehrere Antriebe, insbesondere für einen Greifer oder für ein Transportband, usw. aufweisen. Hierbei kann ein Sollwert für die Geschwindigkeit des Antriebs, insbesondere zu einer vorgegebenen Zeit, ein Sollwert für den Ansteuerstrom des Antriebs, ein Sollwert für das vom Antrieb ausgeübte Drehmoment usw. als Daten 35 in der Steuereinrichtung 30 gespeichert sein. Die Steuereinrichtung 30 kann jedoch auch zugehörige Istwerte als Daten 35 speichern.
-
Um die Daten 35 zu überwachen, können die Daten 35 mit der Bedienoberfläche 10, genauer gesagt einem ihrer Bediengeräte 11, 12, angezeigt werden. Die Steuereinrichtung 30 gibt hierfür auf Anfrage von der Bedienoberfläche 10 Daten 35 über die Kommunikationseinrichtung 20 an die Bedienoberfläche 10, genauer gesagt eines ihrer Bediengeräte 11, 12, weiter. Aufgrund dessen kann ein Benutzer die Daten 35, insbesondere die Sollwerte, bei Bedarf ändern und so Einfluss auf die Steuerung der Maschine 1 mit der Steuereinrichtung 30 nehmen.
-
Das erste Bediengerät 11 ist ein Desktop-Bediengerät 11, also ein festinstalliertes Bediengerät 11 eines Personalcomputers (PC). Das erste Bediengerät 11 hat Einheiten 111, 112, 113 und eine Anzeigeeinheit 115. Die Einheit 111 ist eine native Anwendung des zugrundeliegenden Betriebssystems (z. B. Windows, MacOS, Linux) (111). Die Einheit 112 ist eine native Anwendung (z. B. .Net) auf Basis eines zugrundeliegenden Betriebssystems mit einem eingebetteten Web-Control bzw. Websteuerung 112. Die Einheit 113 ist eine reine Web-Browser Anwendung ohne nativen Anteil des zugrundeliegenden Betriebssystems auf der Plattform des festinstallierten Bediengeräts 11. Mit der Anzeigeeinheit 115 können die Daten 35 für einen Benutzer optisch und/oder akustisch angezeigt werden.
-
Im Unterschied dazu ist das zweite Bediengerät 12 ein mobiles Bediengerät 12, also ein tragbares, nicht festinstalliertes Bediengerät 12. Das zweite Bediengerät 12 kann beispielsweise ein Smartphone, ein Tablet-PC, ein Laptop, usw., sein. Demzufolge ist das zweite Bediengerät 12 auf der Plattform eines Tablet, SmartPhone, usw. realisiert. Das zweite Bediengerät 12 hat Einheiten 121, 122 und eine Anzeigeeinheit 125. Die Einheit 121 ist eine Web-Anwendung (Web-App) der Plattform des mobilen Bediengeräts 12. Eine mobile Web-App verhält sich im Idealfall genauso wie eine native App, wird also vom Nutzer nicht wie eine Webseite wahrgenommen, sondern bietet stattdessen eine Benutzeroberfläche, die sich in das mobile Endgerät optisch und ergonomisch integriert. Die Einheit 122 ist eine mobile Webseite, die einen Standard-Web-Browser des mobilen Bediengeräts 12 als Ausführungsplattform nutzt. Auch mit der Anzeigeeinheit 125 können die Daten 35 für einen Benutzer optisch und/oder akustisch angezeigt werden.
-
Die Kommunikationseinheit 15 lenkt Anfragen 18 der Einheiten 111, 112, 113, 121, 122 über den Kommunikationskanal 151, 212 weiter an die Kommunikationseinrichtung 20. Der auf dem WebSocket-Protokoll basierende Kommunikationskanal 151, 212 ist durch JavaSkript-Code implementiert. Der JavaSkriptCode ist sowohl in Webanwendungen als auch in nativen Implementierungen der Einheiten 111, 112, 113, 121, 122, z. B. in .Net der Einheit 111, Code-identisch verwendbar. Der JavaSkriptCode leitet alle Kommunikationsanfragen der Einheiten 111, 112, 113, 121, 122 auf den Kommunikationskanal 151, 212. Somit stellt der Kommunikationskanal 151, 212 eine universelle Datenanbindung für alle Bediengeräte-Typen, wie Maschinen-Bediengerät bzw. -Visu, Smart-Bediengerät bzw. -Visu, Web-Bediengerät bzw. -Visu, usw., auf allen Plattformen, wie PC, Tablet, SmartPhone, usw., und unterschiedlichen Betriebssystemen, wie Windows, Linux, VxWorks, MacOS, usw., bereit. In der Maschine 1 ist somit ein plattformunabhängiger Kommunikationskanal 151, 212 zwischen der Bedienoberfläche 10 als Client und der Steuereinrichtung 30 als Server auf Basis von HTML5-WebSockets (HTML5 = Hypertext Markup Language Version 5 = Hypertext-Auszeichnungssprache der Version 5) realisiert. Das WebSocket Protokoll ist Teil der HTML5 Spezifikation und wird von allen HTML5-fähigen Web-Browsern unterstützt. Merkmale von WebSockets liegen in der konstanten Verbindung zwischen dem Client, beispielsweise der Bedienoberfläche 10, und dem Server, beispielsweise der Kommunikationseinrichtung 20, während des gesamten Ablaufs oder Sitzung (Session) der Kommunikation. Das WebSocket-Protokoll ermöglicht eine bidirektionale Kommunikation, sodass das ineffiziente Anfrage/Antwort-Verfahren (Request/Response-Verfahren (Polling)), wie es beim HTTP-Protokoll nötig ist, entfällt.
-
Die mit dem Kommunikationskanal 151, 212 realisierte WebSocket-Schnittstelle dient bei der Maschine 1 als hoch effizienter und plattformunabhängiger Kommunikationskanal zum Versenden der Anfragen 18 und deren Ergebnisse zwischen der Bedienoberfläche 10 als Visu-Client und der Kommunikationseinrichtung 20 als Kommunikationsserver.
-
Die Kommunikationseinrichtung 20 setzt die Anfragen 18 über den Kommunikationskanal 151, 212 mit Hilfe der Einheiten 21 bis 25 weiter in Anfragen für die Steuereinrichtung 30 um. Hierbei ist die Einheit 21 ein JavaWebServer, der neben der WebSocket-Schnittstelle über die HTTP-Schnittstelle 211 (Hypertext Transfer Protocol) verfügt, über welche weitere Clients (WebSeiten) mit der Einheit 21, dem Java WebServer, kommunizieren können. Es ist vorstellbar, einen Teil der über den Kommunikationskanal 151, 212 realisierten WebSocket-Schnittstelle auch über das HTTP-Protokoll anzubieten, um auch nicht HTML5-fähigen Clients (ältere WebBrowser) den Datenaustausch über die Einheit 21 (Java Webserver) zu ermöglichen. Die Einheit 22 ist ein OpenCore-Comfort Java SDK. Dies ist eine zentrale Komponente, welche die Protokolle von OPC-UA und MLPI nach oben (in Richtung der Clients), also der Bedienoberfläche 10, vereinheitlicht. Dies hat den großen Vorteil, dass die gleiche Anfrage-Syntax für beide Protokolle in den Clients verwendet werden kann und dadurch der Implementierungsaufwand verringert wird. Die Einheit 23 ist ein MLPI Java-SDK, welche die native Java Implementierung der MLPI-Schnittstelle darstellt. Somit kann eine Anfrage 18 über den Kommunikationskanal 151, 212 bei Bedarf in eine Anfrage für die MLPI-Schnittstelle 231, 31 umgesetzt werden. Demgegenüber ist die Einheit 24 ein UA-Client-SDK (Java basierter OPC-UA Client,), welche auf den durch die Einheit 25 gebildeten nativen UA-Stack 25 der OPC-Foundation aufsetzt. Der UA-Stack bildet die unterste Ebene der Client-seitigen OPC-UA Schnittstelle. Somit kann eine Anfrage 18 über den Kommunikationskanal 151, 212 bei Bedarf in eine Anfrage für die OPC-UA-Schnittstelle 251, 32 umgesetzt werden.
-
Auf diese Weise werden die Anfragen von der Kommunikationseinrichtung 20 an die Steuereinrichtung 30 über die Schnittstellen 231, 31 oder 251, 32 weitergeleitet. Die Schnittstellen 231, 31 oder 251, 32 sind native Kommunikationsanbindungen über die OpenCoreEngineering Interface MLPI oder über OPC-UA. Die Schnittstelle 231, 31 ist also bei dem vorliegenden Ausführungsbeispiel eine proprietäre MLPI-Schnittstelle. Die Schnittstelle 251, 32 ermöglicht bei dem vorliegenden Ausführungsbeispiel eine Kommunikation gemäß einem industriellen M2M-Kommunikationsprotokoll der Steuereinrichtung. Das industrielle M2M-Kommunikationsprotokoll ist beispielsweise OPC Unified Architecture, das auch kurz OPC UA genannt wird. Als derzeit neueste aller OPC-Spezifikationen der OPC Foundation unterscheidet sich OPC UA erheblich von seinen Vorgängern, insbesondere durch die Fähigkeit, Maschinendaten (Prozesswerte, Messwerte, Parameter usw.) nicht nur zu transportieren, sondern auch maschinenlesbar semantisch zu beschreiben.
-
2 zeigt das von der Maschine 1 ausgeführte Verfahren zur Kommunikation zwischen der Bedienoberfläche 10 und der Steuereinrichtung 30, das von einem Benutzer 5 gestartet werden kann. Demzufolge wird zunächst, beispielsweise von der Einheit 111 eine Kommunikationsanfrage 18 an die Steuereinrichtung 30 gesandt, um Daten 35 von der Steuereinrichtung 30 mit der Anzeigeeinheit 115 anzuzeigen. Die Einheit 111 sendet hierbei die Kommunikationsanfrage 18 an die Kommunikationseinheit 15 der Bedienoberfläche 10. Danach kommuniziert die Kommunikationseinheit 15 mit der Steuereinrichtung 30, indem die Kommunikationseinheit 15 die Kommunikationsanfrage 18 als Anfrage 40 über den auf dem WebSocket-Protokoll basierenden Kommunikationskanal 151, 212 an die Kommunikationseinrichtung 20 leitet. Demzufolge überführt die Kommunikationseinheit 15 die Kommunikationsanfrage 18 in eine Anfrage 40 im WebSocket-Protokoll.
-
Danach setzt die Kommunikationseinrichtung 20 die Kommunikationsanfrage 18 im WebSocket-Protokoll mit ihren Einheiten 21, 22, 23 in das Protokoll für die Schnittstelle 231, 31 oder mit ihren Einheiten 21, 22, 24, 25 in das Protokoll für die Schnittstellen 251, 32 um. Hierfür werden Routinen 27, wie Anfrage 40 empfangen (ReceiveRequest), Anfrage 40 umwandeln (TransformRequest) und an nativen Client senden (SendToNativeClient) ausgeführt, so dass sich zunächst die Anfrage 41 und dann die Anfrage 42 ergibt.
-
Die Anfrage 42 wird über die Schnittstellen 231, 31 oder 251, 32 an die Steuereinrichtung 30, genauer gesagt ihren Steuerdatenserver (Conrol DataServer) als Anfrage 43 weitergeleitet. Demzufolge werden die Daten 35 gemäß der Kommunikationsanfrage 18, 40 bis 43 in der Steuereinrichtung 30 gelesen und anschließend ein entsprechendes Ergebnis über die Schnittstelle 231, 31 oder 251, 32 mit der Antwort 44 an die Kommunikationseinrichtung 20 zurückgegeben.
-
Danach setzt die Kommunikationseinrichtung 20 die Antwort 44 im Protokoll der Schnittstellen 231, 31 mit den Einheiten 21, 22, 23 in das WebSocket-Protokoll um. Liegt die Antwort 44 jedoch im Protokoll der Schnittstellen 251, 32 vor, setzt die Kommunikationseinrichtung 20 die Antwort 44 mit ihren Einheiten 21, 22, 23 in das WebSocket-Protokoll um. Hierfür werden Routinen 28, wie Antwort 44 empfangen (ReceiveResponse), Antwort 45 umwandeln (Transform Response) und an WebSocket bzw. an Kommunikationskanal 151, 212 senden (SendToWebSocket) ausgeführt, so dass sich zunächst die Antwort 45 und dann die Antwort 46 ergibt.
-
Die Antwort 46 wird über den auf dem WebSocket-Protokoll basierenden Kommunikationskanal 151, 212 an die Bedienoberfläche 10 als Antwort 47 weitergegeben (Send Response). Die Kommunikationseinheit 15 wandelt die Daten 35 aus dem WebSocket-Protokoll wieder in das Format der Einheit 111 zurück, so dass die Einheit 111 die Daten 35 an die Anzeigeeinheit 115 geben kann, welche die Daten 35 als Antwort 48 anzeigt. Danach ist das Verfahren beendet.
-
Bei dem Verfahren können auch nur die Schritte gemäß den Antworten 44 bis 48 ausgeführt werden, so dass die Daten 35 auf Initiative der Steuereinrichtung 30 an die Anzeigeeinheit 115 gesendet werden. Alternativ kann auch die Steuereinrichtung 30 aufgrund einer Kommunikationsanfrage 18 von einer Einheit der Einheiten 111, 112, 113, 121, 122 Daten 35 an eine andere Einheit der Einheiten 111, 112, 113, 121, 122 oder an alle Einheiten 111, 112, 113, 121, 122 weitergeben.
-
Somit bildet die Kommunikationseinrichtung 20 eine Implementierung einer Protokoll-Transformation (Umsetzung) innerhalb des auf Java basierten Webservers, der Einheit 21. Der Webserver bzw. die Einheit 21 nimmt die per WebSocket über den Kommunikationskanal 151, 212 empfangenen Anfragen der Clients entgegen und leitet diese an die proprietäre Funktionen der Einheit 22, der OpenCore Comfort Java SDK, weiter. Der Webserver bzw. die Einheit 21 verwaltet dabei alle verbundenen Clients, also bei dem vorliegenden Ausführungsbeispiel der Bedienoberfläche 10 und ihrer Bediengeräte 11, 12 über eine eindeutige Sitzungs-Identifikation (Session-ID) und leitet eine Rückantwort der nativen Schnittstelle, also bei dem vorliegenden Ausführungsbeispiel der Schnittstellen 231, 31 oder 251, 32 wieder an den entsprechenden Client per WebSocket über den Kommunikationskanal 151, 212 weiter.
-
Demzufolge ist mit der Kommunikationseinrichtung 20 eine Komponente bereitgestellt, welche es ermöglicht, das WebSocket Protokoll in eine native (proprietäre) Kommunikationsschnittstelle, die Schnittstellen 231, 31 oder 251, 32, für die Steuereinrichtung 30 (OCI) umzusetzen. Insbesondere werden dabei spezielle Kommunikationsmechanismen, wie Anfragen (Subscriptions) und Ereignisse (Events) unterstützt. Hierbei weist eine auf HTML5 WebSocket Basis implementierte Visualisierung keine Einschränkung bei der Kommunikation gegenüber nativ implementierten Anbindungen auf.
-
Der Benutzer 5 ist in der Regel ein Programmierer der Bedienoberfläche 10 bzw. HMI, z. B. ein Steuerungsbetreiber oder Steuerungshersteller. Bei einer HMI-Implementierung unter Verwendung der Kommunikationseinrichtung 20 als WebSocket-Protokoll-Umsetzer ergeben sich folgende Vorteile:
- • Einfacher Wechsel zwischen verschiedenen Kommunikationskanälen ohne Änderungen an der Schnittstelle, nämlich dem Kommunikationskanal 151, 212,
- • Parallele Kommunikation über verschiedene Kommunikations-Kanäle hinweg mit nur einer Schnittstelle, nämlich dem Kommunikationskanal 151, 212, und
- • Verfügbarkeit von Push-Services (Subscriptions) für Kommunikations-Kanäle, die Push-Services selbst nicht bereitstellen. Dadurch ergibt sich eine Entlastung der Bedienoberfläche 10 als Client und eine Verringerung des Implementierungsaufwands.
-
Gemäß einem zweiten Ausführungsbeispiel ist eine verschlüsselte Übertragung zwischen Client und Server durch Secure WebSockets möglich.
-
Gemäß einem dritten Ausführungsbeispiel wird eine Querkommunikation zu einem OPC-UA Client/Server einer anderen Steuereinrichtung ermöglicht. Die zentrale Kommunikationseinrichtung 20 ermöglicht die Verbindung zu 1 – n Steuereinrichtung(en) 30, ohne dass eine weitere Instanz der Kommunikationseinheit 15 benötigt wird. Die Kommunikationseinheit 15 verteilt die Anfragen 18 dabei entsprechend den Verbindungsdaten, die beim Verbinden (Connect) zwischen Anzeigeeinheit 115, 125 und Kommunikationseinheit 15 ausgetauscht wurden.
-
Gemäß einem vierten Ausführungsbeispiel ist eine extern konfigurierbare (JSON- oder XML-Datei) Schnittstellenbeschreibung zur vereinfachten Pflege des WebServers bei Protokollanpassungen möglich. Dabei werden die verfügbaren Funktionen und Attribute einer Schnittstelle mittels einer externen Beschreibungsdatei bereitgestellt. Die somit verfügbare generische Schnittstelle verwendet bei ihrer Ausführung die Beschreibungsdatei, um die entsprechenden Kommunikations-Objekte zu generieren.
-
Alle zuvor beschriebenen Ausgestaltungen der Maschine 1 und des Verfahrens können einzeln oder in allen möglichen Kombinationen Verwendung finden. Insbesondere können alle Merkmale und/oder Funktionen der zuvor beschriebenen Ausführungsbeispiele beliebig kombiniert werden. Zusätzlich sind insbesondere folgende Modifikationen denkbar.
-
Die in den Figuren dargestellten Teile sind schematisch dargestellt und können in der genauen Ausgestaltung von den in den Figuren gezeigten Formen abweichen, solange deren zuvor beschriebenen Funktionen gewährleistet sind.
-
Die Bedienoberfläche 10 kann ganz allgemein eine grafische Bedienoberfläche für Maschinenanwendungen (Maschinen HMI), Web-Visualisierungen, Mobile-Apps (mobile Anwendungen bzw. Applikationen) sein. Hierbei können die Eingaben an der grafischen Bedienoberfläche grafisch erfolgen. Zudem können die Ausgaben an der grafischen Bedienoberfläche grafisch erfolgen
-
Die Anzahl der Bediengeräte 11, 12 der Maschine 1 ist beliebig wählbar.
-
Die Anzahl der Einheiten 111, 112, 113, 121, 122 der Bedienoberfläche 10 bzw. der Bediengeräte 11, 12 ist beliebig wählbar. Das erste Bediengerät 11 kann auch beispielsweise nur die Einheit 112 aufweisen. Das zweite Bediengerät 12 kann auch beispielsweise nur die Einheit 121 aufweisen.
-
Zumindest eines der Bediengeräte 11, 12 kann auch gleich einem der anderen Bediengeräte 11, 12 ausgestaltet sein.
-
Alternativ oder zusätzlich können die Kommunikationsanfragen 18 auch über die Schnittstelle 211 der Kommunikationseinrichtung 20 an einen Webserver zum Erlangen von Daten von einer Webseite weitergeleitet werden.
-
Anstelle einer OPC-UA-Schnittstelle 251. 32 bei der Steuereinrichtung 30 können auch andere Kommunikationsprotokolle wie OPC-DA (Vorgänger von OPC-UA) oder BRWS (proprietäres Protokoll von BoschRexroth), oder SIP (SercosIP) vorhanden sein. Die Kommunikationseinrichtung 20 als WebSocket Protokoll-Umsetzer muss dabei um die entsprechenden Eigenschaften erweitert werden.
