-
Die vorliegende Erfindung bezieht sich auf eine Bedienoberfläche für eine Maschine und ein Verfahren zur Kommunikation zwischen einer Bedienoberfläche für eine 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 Bedienoberfläche für eine Maschine, eine Kommunikationseinrichtung für die Bedienoberfläche und ein Verfahren zur Kommunikation zwischen einer Bedienoberfläche für eine Maschine und einer Steuereinrichtung der Maschine bereitzustellen, mit welchen die zuvor genannten Probleme gelöst werden können. Insbesondere sollen eine Bedienoberfläche für eine Maschine, eine Kommunikationseinrichtung für die Bedienoberfläche und ein Verfahren zur Kommunikation zwischen einer Bedienoberfläche für eine 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 Bedienoberfläche für eine Maschine nach Patentanspruch 1 gelöst.
-
Vorteilhafte weitere Ausgestaltungen der Bedienoberfläche sind in den abhängigen Patentansprüchen angegeben.
-
Die Bedienoberfläche hat 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.
-
Somit ist 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 Bedienoberfläche eine vollständige Plattformunabhängigkeit durch Web-Technik ohne für die Plattform native Komponenten. Daher ist mit der Bedienoberfläche eine große Flexibilität realisiert.
-
Noch dazu ist 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 allen Bedienoberflächen, die auch als Clients bezeichnet werden können, identisch.
-
Die Bedienoberfläche ermöglicht das Erstellen von eingebetteten Web-Clients, beispielsweise Browser-Steuerungen, die auch als Browser-Controls bezeichnet werden können.
-
Als weiterer Vorteil ist ein Erstellen und anschließendes Fehlersuchen und -beseitigen, was auch als Debugging bezeichnet wird, von mobilen Applikationen (Apps) direkt im Browser eines Entwickler-PCs möglich.
-
Vorteilhaft ist auch, dass plattformunabhängige Multi-Client-Visualisierungen realisierbar sind.
-
Die Bedienoberfläche bietet zudem den Vorteil von identischem Client-Code für alle Bedienoberflächen bzw. Zielplattformen der Maschine.
-
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 Bedienoberfläche 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 gemäß einem ersten Ausführungsbeispiel; und
-
2 ein Flussdiagramm eines Verfahren zur Kommunikation zwischen einer Bedienoberfläche für eine Maschine und einer Steuereinrichtung der Maschine 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/r 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 JavaSkript-Code 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 JavaSkript-Code 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.
-
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 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. Demzufolge wird bei einem Schritt S1 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 geht der Fluss zu einem Schritt S2 weiter.
-
Bei dem Schritt S2 kommuniziert die Kommunikationseinheit 15 mit der Steuereinrichtung 30, indem die Kommunikationseinheit 15 die Kommunikationsanfrage 18 ü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 das Websocket-Protokoll. Danach geht der Fluss zu einem Schritt S3 weiter.
-
Bei dem Schritt S3 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. Danach geht der Fluss zu einem Schritt S4 weiter.
-
Bei dem Schritt S4 werden die Daten 35 in der Steuereinrichtung gemäß der Kommunikationsanfrage 18 von der Schnittstelle 231, 31 oder 251, 32 gelesen und anschließend ein entsprechendes Ergebnis über die Schnittstelle 231, 31 oder 251, 32 an die Kommunikationseinrichtung 20 zurückgegeben. Danach geht der Fluss zu einem Schritt S5 weiter.
-
Bei dem Schritt S5 setzt die Kommunikationseinrichtung 20 die beim Schritt S4 als Ergebnis zurückgegebenen Daten 35 mit ihren Einheiten 21, 22, 23 oder 21, 22, 24, 25 wieder zum Websocket-Protokoll um und gibt die Daten 35 so an die Kommunikationseinheit 15 weiter. Danach geht der Fluss zu einem Schritt S6 weiter.
-
Bei dem Schritt S6 wandelt die Kommunikationseinheit 15 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 anzeigt. Danach ist das Verfahren beendet.
-
Bei dem Verfahren können auch nur die Schritte S4 bis S6 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.
-
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 zwischen Anzeigeeinheit 115, 125 und Kommunikationseinheit 15 ausgetauscht wurden.
-
Gemäß einem vierten Ausführungsbeispiel wird die Kommunikationseinheit 15 statt als autarke Komponente im Netzwerk, als integrierte Komponente auf der Steuereinrichtung 30 implementiert. Um eine Beeinträchtigung der System-Performance zu verhindern, ist ein separater Prozessorkern für Webaufgabe (Webtask) auf Mehrkernsteuerungen (Multicore-Steuerungen) bei Ausführung des WebSocket-Servers direkt auf der Steuerung vorgesehen.
-
Alle zuvor beschriebenen Ausgestaltungen der Maschine 1, der Bedienoberfläche 10, der Bediengeräte 11, 12, der Kommunikationseinheit 15 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),BRWS (proprietäres Protokoll von BoschRexroth), oder SIP(SercoslP)-vorhanden sein. Die Kommunikationseinrichtung 20 als WebSocket Protokoll-Umsetzer muss dabei um die entsprechenden Eigenschaften erweitert werden.
