-
Die Erfindung betrifft ein Verfahren und eine Vorrichtung nach dem Oberbegriff des Patentanspruches 1.
-
Bei der Programmierung einer bestimmten Hardware, insbesondere bei Hardware betreffenden Maschinensteuerungen kommt es darauf an, dass man mit einer grafischen Benutzeroberfläche möglichst einfach und wiederholbar die Hardware programmieren kann.
-
Eine solche Hardware besteht aus einer Vielzahl von Steuerungskomponenten einer Maschinensteuerung, wie z. B. einer Windkraftanlage oder dergleichen und können beispielsweise aus programmierbaren Ein- und Ausgängen, Betätigungsmodulen, Temperaturmodulen und dergleichen mehr bestehen.
-
Ein Programmgenerator mit einer grafischen Entwicklungsoberfläche und automatischer Code-Generierung ist aus der
DE 10 2004 043 788 A1 bekannt geworden. Der dort gezeigte Programmgenerator sieht eine grafische Entwicklungsoberfläche vor, wobei einzelne grafische Entwicklungsmodule auf eine Benutzeroberfläche gezogen werden, um ein bestimmtes ablauffähiges Programm zu erzeugen. Das Programm wird hierbei als Modell mit einzelnen Modulen vorgegeben.
-
Das Modell besteht hierbei aus einzelnen grafischen Symbolen, die auf der Benutzeroberfläche so angeordnet werden, damit sich ein ablauffähiges Programm mit einer bestimmten gewünschten Ablaufstruktur ergibt.
-
Ein weiteres Verfahren und eine Vorrichtung nach dem Oberbegriff ist beispielsweise mit dem Gegenstand der eigenen
DE 10 2007 014 271 A1 bekannt, bei der eine grafische Entwicklungsoberfläche mit einer automatischen Code-Generierung beschrieben wurde, bei der ein Programmgenerator vorhanden war, mit dem einzelne grafische Entwicklungsmodule auf eine Benutzeroberfläche gezogen werden konnten, um ein bestimmtes ablauffähiges Programm zu erzeugen.
-
Gegenstand dieser Druckschrift war die zur Verfügungsstellung eines benutzerseitigen Bedienungsterminals, um einen Konfigurator mit einer Java-Visualisierung weiter zu entwickeln und einen verbesserten Konfigurator zu erhalten.
-
Dabei war auf einem Bildschirm eines beliebigen Eingabegerätes eine grafische Oberfläche angeordnet, die im Wesentlichen aus einem Maschinenmodell bestand, welches auf einem zunächst leeren Blatt errichtet wurde, wobei durch Ziehen von einzelnen Komponenten einer oder mehrerer Paletten auf das (zunächst als leeres Blatt vorhandene) Maschinenmodell eine ablauffähige Steuerung erzeugt werden konnte, wobei den Hardware-Komponenten maschinenbezogene Prozessparameter (wie zum Beispiel Zustandsüberwachungspunkte, Alarmpunkte, Temperaturangabepunkte und andere Steuerungsparameter) zugeordnet werden konnten.
-
Dieses System stieß jedoch an die technischen Grenzen, weil die Möglichkeit fehlte, einzelne, benutzerseitige Komponenten mit hinzuzunehmen, weil es sich um ein abgeschlossenes System handelte, bei dem eine Einwirkung von außen mit zusätzlichen benutzereigenen Modulen nicht möglich war.
-
Weiterer Nachteil war die fehlende Kompatibilität zu außen liegenden Anwendungen, wie z. B. Mobilfon-Anwendungen und dergleichen mehr.
-
Im Übrigen war die Verwendung einer java-basierten Oberfläche nicht mehr dem letzten Stand der Technik entsprechend und daher waren die Modulpflege und die Wartung der Entwicklungsumgebung aufwendig.
-
Der Erfindung liegt deshalb die Aufgabe zugrunde, ausgehend von der
DE 10 2007 014 271 A1 ein Verfahren und eine Vorrichtung zur Bedienung und Steuerung einer maschinentechnischen Anlage so weiterzubilden, dass eine grafische Konfigurations- und Entwicklungsumgebung geschaffen werden kann, die geeignet ist, die Hardware-Komponenten einer Hardwarestation betriebssicher zu programmieren und die leichter zu bedienen ist.
-
Sie sollte auch mit geringeren Datenmengen und deshalb auch schneller arbeiten und bei der es möglich ist, von außerhalb der Entwicklungsumgebung liegende WWW-Anwendungen, z. B. Web-Komponenten hinzuzufügen, wie es vorher nicht möglich war.
-
Insbesondere bestand bei dem Gegenstand der
DE 10 2007 014 271 A der Nachteil, dass es sich um eine zweifache Entwicklungsumgebung handelte, nämlich um eine erste grafische Oberfläche, die ein sogenanntes Solutionscenter (SC) darstellte, in der ein grafisch basierter Konfigurator enthalten war, der schließlich einen automatischen Code generierte, mit dem ein User-Interface programmiert wurde, und dieses User-Interface schließlich seinerseits dann die Programmierung der Hardware-Komponenten übernahm.
-
Es handelte sich also um eine relativ umständliche, zeitaufwendige und auch anfällige Programmierung, die erfindungsgemäß vermieden werden soll.
-
Zur Lösung der gestellten Aufgabe zeichnet sich das bevorzugte Verfahren nach der Erfindung dadurch aus, dass in einer grafischen Konfigurator- und Entwicklungsumgebung (SC) ein embedded Webserver und ein über eine HTML-Schnittstelle mit diesem kommunizierender embedded Browser integriert sind und dass die in der Konfigurator- und Entwicklungsumgebung erzeugte Programmiersequenz über eine Ethernet-Verbindung dem in einem Feldbus-Master angeordneten Konfigurationsmodul zuführbar ist, welches die Programmiersequenz über einen Feldbus dem Stationskopf einer Hardwarestation zuführt, in welcher die mit der Programmiersequenz programmierbaren Hardwarekomponenten angeordnet sind und mit dem Stationskopf kommunizieren.
-
Als bevorzugtes Ausführungsbeispiel besteht die Entwicklungsumgebung vorzugsweise aus Eclipse-Konfigurator-Komponenten, in denen nun erfindungsgemäß ein embedded Webserver und ein embedded Browser integriert sind.
-
Ein Webserver ist ein Server, der Dokumente an Clients wie z. B. Webbrowser überträgt. Als Webserver bezeichnet man den Computer mit Webserver-Software oder nur die Webserver-Software selbst. Webserver werden lokal, in Firmennetzwerken und überwiegend als WWW-Dienst im Internet eingesetzt. Dokumente können somit dem geforderten Zweck lokal, firmenintern und weltweit zur Verfügung gestellt werden.
-
Die Hauptaufgabe eines Webservers ist die Auslieferung von statischen Dateien, z. B. unveränderlichen HTML- oder Bild-Dateien, oder dynamisch erzeugten Dateien, z. B. Seiten, deren Inhalte stets individuell gemäß dem Profil eines eingeloggten Benutzers erstellt werden.
-
Für eine komplette Webseite werden in der Regel die HTML-Seite inklusive verknüpfter Designbeschreibungen (CSS) und Bilddateien (JPG, PNG, GIF, SVG) jeweils als einzelne Dateien übertragen. Für jede benötigte Datei muss der Webbrowser eine eigene Anfrage an den Webserver senden, d. h. zur Darstellung einer komplexen Webseite sind manchmal hunderte Anfragen und Serverantworten nötig. Ein Webserver ist in der Lage, die Inhalte einer Webseite gleichzeitig auf viele verschiedene Rechner auszuliefern. Wie schnell Nutzeranfragen bearbeitet werden können, hängt nicht zuletzt von der Komplexität der Webinhalte ab: Beispielsweise benötigen dynamische mehr Ressourcen als statische Webinhalte.
-
Als Übertragungsmethoden dienen standardisierte Übertragungsprotokolle (HTTP, HTTPS) und Netzwerkprotokolle wie IP und TCP, üblicherweise über Port 80 (HTTP) und Port 443 (HTTPS). HTTP ist dabei das meist eingesetzte Protokoll.
-
Webbrowser sind spezielle Computerprogramme zur Darstellung von Webseiten im World Wide Web oder allgemein von Dokumenten und Daten. Neben HTML-Seiten können Webbrowser verschiedene andere Arten von Dokumenten wie zum Beispiel Bilder und PDF-Dokumente anzeigen. Webbrowser stellen die Benutzeroberfläche für Webanwendungen dar.
-
Eclipse ist ein quelloffenes Programmierwerkzeug zur Entwicklung von Software, welche die Grundlage der vorliegenden Konfigurator- und Entwicklungsumgebung bildet.
-
Aktuell besteht die Entwicklungsumgebung aus native Eclipse-Komponenten in den Programmiersprachen Java und XTend implementiert, und sind somit nahtlos in die Konfigurator- und Entwicklungsumgebung integriert, die nachfolgend auch als SolutionCenter (SC) bezeichnet wird.
-
Zur Darstellung von Webinhalten (HTML, CSS, ...) stellt das Eclipse-Ul-Framework eine Browser-Komponente (SWT.Browser Widget) zur Verfügung. Dieser Mechanismus wird vom Hilfe-System von Eclipse genutzt. Ein integrierter Webserver liefert die Hilfe in Form von statischen HTML Seiten aus, die in der Eclipse Browser Komponente angezeigt werden.
-
Insbesondere für Hardware Konfiguratoren bietet der Einsatz moderner Web-Technologien Vorteile, da Inhalte reichhaltiger und interaktiver gestaltet werden können. Das ist besonders bei komplexeren Hardware Modulen mit komplexen Abhängigkeiten zwischen Konfigurationswerten und in der Konfiguration verwendeten grafischen Elementen wertvoll.
-
Moderne Web Ul Frameworks sind leichter zu handhaben und moderner, als die z.T. in die Jahre gekommene Eclipse Code-Basis. Dadurch ergeben sich Vorteile bei der Umsetzung von möglichen Features wie Animationen im Konfigurationsvorgang, wie auch eine effiziente Entwicklung auf dem neuesten Stand der Technik.
-
Über das simple Anzeigen von statischen Web-Inhalten hinaus ist eine deutlich stärkere Verknüpfung zwischen den Web-Konfiguratoren und Eclipse Mechanismen notwendig. Insbesondere folgende Eclipse Funktionalitäten müssen in Web-Konfiguratoren für eine nahtlose bzw. benutzerfreundliche Integration nutzbar sein:
- • Änderungserkennung (Dirty-State Editor Verhalten): Wenn Änderungen im Konfigurator über den Browser vorgenommen werden, soll sich der Editor als geändert markiert melden. In Eclipse wird das über eine *-Dekoration im Label des Editors erzielt. Technisch gesehen muss es also möglich sein, Browsereingaben an das SC zu kommunizieren um den Editor-State zu verwalten.
- • Undo/Redo-Verhalten: Änderungen die im Browser vorgenommen werden sollen über den Eclipse Undo/Redo Stack rückgängig bzw. wieder-hergestellt werden können. Eclipse bietet hierfür eine Edit Menü und shortcuts an.
- • Drag&Drop-Support: Es soll möglich sein Inhalte von SC in den Konfigurator mittels D&D zu übertragen. Dies kann sinnvoll für das Setzen von Konfigurationswerten sein.
- • Lebenszyklus von Ul Komponenten: Wenn ein neues Modul erstellt wird, soll automatisch der Editor geöffnet werden und die Web-Applikation für die Konfiguration soll gestartet werden.
- • Einbindung Nativer SC-Widgets in Web-Konfiguratoren: Für manche Aktionen ist es sinnvoll native SolutionCenter (SC)-Widgets zu verwenden. Ein Anwendungsfall hierfür wäre ein SC-spezifischer Auswahldialog um Dateien oder andere Elemente zu selektieren.
-
Der im SolutionCenter integrierte Web-Konfigurator stellt auch die Basis für eine rein Web-basierte Konfiguration dar. Bei der erfindungsgemäßen Lösung kommuniziert ein üblicher Web-Browser mit einem Web-Server auf einer Steuerung, um die Konfiguration (Hardware-Programmierung) der Steuerung mit ihren Hard- und Software-Modulen zu durchzuführen.
-
Die hier beschriebene Implementierung ist ein Zwischenschritt für einen rein Webbasierten Konfigurationsmechanismus.
-
Im folgenden Abschnitt wird die Lösungsarchitektur vorgestellt, die es ermöglicht Web-Technologien integriert im Solution Center zu verwenden.
-
Im Ergebnis wird bei der vorliegenden Erfindung auf eine java-implementierte Konfiguration verzichtet, und stattdessen wird es nun erstmals möglich, bestimmte Web-Technologien einzusetzen, wie es bisher in dem älteren Stand der Technik nicht bekannt war.
-
Der Web-Server ist im SolutionCenter (SC) integriert, der vorzugsweise eine REST API zur Verfügung stellt.
-
Der Begriff REST-API ist eine Abkürzung der Bezeichnung „Representational State Transfer“ (abgekürzt REST, seltener auch ReST) und bezeichnet ein Programmierparadigma für verteilte Systeme, insbesondere für Webservices. REST ist eine Abstraktion der Struktur und des Verhaltens des World Wide Web. REST hat das Ziel, einen Architekturstil zu schaffen, der die Anforderungen des modernen Web besser darstellt. Dabei unterscheidet sich REST vor allem in der Forderung nach einer einheitlichen Schnittstelle von anderen Architekturstilen.
-
Der Zweck von REST liegt schwerpunktmäßig auf der Maschine-zu-Maschine-Kommunikation. REST stellt eine einfache Alternative zu ähnlichen Verfahren wie SOAP und WSDL und dem verwandten Verfahren RPC dar. Anders als bei vielen verwandten Architekturen kodiert REST keine Methodeninformation in den URI, da der URI Ort und Namen der Ressource angibt, nicht aber die Funktionalität, die der Web-Dienst zu der Ressource anbietet. Der Vorteil von REST liegt darin, dass im WWW bereits ein Großteil der für REST nötigen Infrastruktur (z. B. Web- und Application-Server, HTTP-fähige Clients, HTML- und XML-Parser, Sicherheitsmechanismen) vorhanden ist, und viele Web-Dienste per se RESTkonform sind. Eine Ressource kann dabei über verschiedene Medientypen dargestellt werden, auch Repräsentation der Ressource genannt.
-
Diese REST API ermöglicht die Kommunikation zwischen dem Web-Frontend und dem SolutionCenter (SC). Der Web-Server steht als SC-Plugin zur Verfügung und kann somit auf alle Funktionen im SC zugreifen. Speziell für die Kommunikation und das Schreiben der Konfiguration wird die „Controller Communication API“ des Solution Centers verwendet. Es kann aber auch auf die komplette Benutzeroberfläche zugegriffen werden, was es ermöglicht Dialoge oder andere Ul-Komponenten anzusteuern. Die REST API registriert Java basierte Endpunkte auf vordefinierte URLS. Diese Endpunkte dienen als Schnittstelle zur SC-Funktionalität.
-
Als Browser-Komponente wird das Eclipse SWT.Browser Widget verwendet und in einen SC-Editor integriert. Der Datenaustausch zwischen Browser und Web Server erfolgt über JSON.
-
Die JavaScript Object Notation, kurz JSON ist ein kompaktes Datenformat in einer einfach lesbaren Textform zum Zweck des Datenaustauschs zwischen Anwendungen. Jedes gültige JSON-Dokument soll ein gültiges JavaScript sein und per eval() interpretiert werden können. Aufgrund kleiner Abweichungen in der Menge der erlaubten Unicode-Zeichen ist es jedoch möglich, JSON-Objekte zu erzeugen, die von einem normkonformen JavaScript-Interpreter nicht akzeptiert werden. Davon abgesehen ist JSON aber unabhängig von der Programmiersprache. Parser existieren in praktisch allen verbreiteten Sprachen.
-
Das Backend interpretiert die Daten und führt die entsprechende SC-Funktionalität aus. Die Kommunikation basiert auf http Kommandos (GET, PUT, PATCH, ...), somit können Informationen in beide Richtungen ausgetauscht werden.
-
SWT wurde im Jahr 2001 von IBM für die Entwicklungsumgebung Eclipse entwickelt und wird kontinuierlich gepflegt. SWT nutzt dabei im Gegensatz zu Swing die nativen grafischen Elemente des Betriebssystems - wie das AWT von Sun - und ermöglicht somit die Erstellung von Programmen, die eine Optik vergleichbar mit „nativen“ Programmen aufweisen.
-
Bei SWT werden native Widgets durch dünne Wrapper eingebunden, anstatt Teile der Funktionalität in native Peer-Klassen auszulagern. Wegen der Verwendung dieser Ressourcen werden die SWT-Elemente „schwergewichtig“ genannt, im Gegensatz zu den „leichtgewichtigen“ Komponenten der Swing-Technik, die alle grafischen Elemente selbst erzeugt.
-
SWT kommt in einer ganzen Reihe von Anwendungen zum Einsatz, beispielsweise Eclipse selbst, Vuze und RSSOwl.
-
Das Anlegen eines neuen Hardware-Moduls passiert in der Entwicklungsumgebung Wird das Hardware-Modul aus dem SC geöffnet wird der Webserver gestartet und stellt den Konfigurator als Web-Applikation zur Verfügung. Das SWT-Browser Widget öffnet über eine modulspezifische URL den Konfigurator und ruft die Konfigurationsdaten über die REST API ab.
-
Der Begriff Solutions-Center kann übersetzt werden als eine Entwicklungsumgebung, die sich nun dadurch auszeichnet, dass in dieser Entwicklungsumgebung sowohl ein Embedded-Webserver als auch ein mit diesem allein kommunizierender Embedded-Browser vorhanden sind.
-
Es gibt deshalb zwischen dem Embedded-Webserver in der Entwicklungsumgebung eine Schnittstelle, z. B. die Schnittstelle http://127.0.0.1, und über diese Schnittstelle findet ein bidirektionaler Datenaustausch zwischen dem Embedded-Webserver und dem Embedded-Browser statt.
-
Damit besteht der Vorteil, dass es nun erstmals möglich ist, dass verschiedene Komponenten in die Entwicklungsumgebung mit eingeschrieben werden können, und zwar von der Herstellerseite aus, und diese Entwicklungskomponenten können z. B. java-script-basiert sein oder css (cascaded-style-sheets) und html5-Anwendungen.
-
Damit werden der Anwendungsbereich und die Anwendungsbreite einer solchen Entwicklungsumgebung wesentlich gegenüber dem Stand der Technik erweitert, denn der damalige Stand der Technik nahm nur auf eine java-basierte Programmierumgebung Rücksicht.
-
Nach einem weiteren bevorzugten Merkmal der Erfindung ist vorgesehen, dass die Programmierung des Feldbusses erfolgt, und der Feldbus seinerseits die entsprechenden Hardware-Komponenten programmiert.
-
Ein Feldbus ist ein Bussystem, das in einer Anlage Feldgeräte wie Messfühler (Sensoren) und Stellglieder (Aktoren) zwecks Kommunikation mit einem Automatisierungsgerät verbindet. Wenn mehrere Kommunikationsteilnehmer ihre Nachrichten über dieselbe Leitung senden, dann muss festgelegt sein, wer (Kennung) was (Messwert, Befehl) wann (Initiative) sagt. Hierfür gibt es normierte Protokolle.
-
Damit wird eine einheitliche Programmiersprache für den Feldbus zur Verfügung gestellt, weil der Feldbus eine standardisierte Anwendung ist, die deshalb mit standardisierten Daten die einzelnen zu programmierenden Hardware-Komponenten programmiert.
-
Nachdem es unterschiedliche Feldbus-Anwendungen gibt, die möglicherweise auch unterschiedlich programmiert werden, ist der weitere Vorteil der Erfindung darin zu sehen, dass der erfindungsgemäße Konfigurator nun für verschiedene Feldbus-Anwendungen auch die Daten zur Verfügung stellt, ohne dass für jede verschiedene Feldbus-Anwendung eine unterschiedliche Programmierung erfolgen muss.
-
Der Feldbus ersetzt die parallelen Leitungsbündel durch ein einziges Buskabel und verbindet alle Ebenen, von der Feld- bis zur Leitebene. Unabhängig von der Art des Automatisierungsgeräts, z. B. speicherprogrammierbare Steuerungen (SPS) unterschiedlicher Hersteller oder PC-basierte Steuerungen, vernetzt das Übertragungsmedium des Feldbusses die Komponenten im Feld und macht diese für eine Programmierung zugänglich.
-
Anstelle mehrerer I/O-Karten wird eine Bus-Interface-Karte mit einem Feldbus-Master eingesetzt. Hierdurch wird der Platzbedarf im Schaltschrank verringert.
-
Vorteil dieser Maßnahme ist, dass in der Regel die Hardware-Komponenten beim Kunden liegen und die Programmierung über einen kundenseitigen Feldbus erfolgt, wobei verschiedene Kunden durchaus unterschiedliche Feldbus-Konfigurationen aufweisen können.
-
Daher besteht der Wert der Erfindung darin, dass nun mit der neuartigen Entwicklungsumgebung unterschiedliche Feldbus-Konfigurationen jeweils auf der Kundenseite leicht beeinflusst werden können und unterschiedliche Feldbus-Anwendungen zur Programmierung von Hardware-Komponenten verwendet werden können.
-
Es handelt sich also um ein feldbuszentriertes System der Hardware-Konfiguration und der Vorteil ist, dass der Webserver zu einem späteren Zeitpunkt auch auf der kundenseitigen CPU betrieben werden kann, also auf der kundenseitigen Steuerung. Deshalb ist es möglich, dass der in der Entwicklungsumgebung vorhandene Webserver auch kundenseitig auf der Steuerung laufen kann, was mit dem Vorteil verbunden ist, dass der Kunde mit portablen Geräten die Module konfigurieren kann.
-
Es bedarf dazu keines aufwendigen Notebooks und der dazugehörenden Computersteuerung mehr, sondern die Programmierung kann einfach über eine Ethernet-Schnittstelle, z. B. über ein Mobiltelefon erfolgen.
-
Bei der Verwendung eines Mobiltelefons wird vorausgesetzt, dass dieses eine WLAN-Anbindung hat, um eine Datenübertragung zu ermöglichen.
-
Damit besteht der Vorteil, dass eine besonders leichte Servicezugänglichkeit für die kundenseitig angeordneten möglicherweise umzuprogrammierenden Hardware-Komponenten gegeben ist, was vorher nicht bekannt war.
-
Bei der Inbetriebnahme können deshalb sehr gut die Daten überwacht werden und die Funktionsfähigkeit der vorher programmierten Hardwaremodule, ohne dass es einer aufwendigen Rückübersetzung oder aufwendiger Kontrollen bedarf.
-
Weiterer Vorteil ist, dass man nur noch einen aktuell auf dem Markt erhältlichen Browser benötigt und den Browser mit einer entsprechenden URL-Adresse anspricht, um auf alle Möglichkeiten dieses Browsers zurückgreifen zu können, ohne speziell programmierte Software verwenden zu müssen.
-
Damit kann die kundenseitige Programmierung der Hardwaremodule mit Standardanwendungen erfolgen.
-
In den folgenden Abbildungen wird schematisiert ein Ablauf für das Speichern eines Konfigurationswertes in der Entwicklungsumgebung beschrieben, was in Bezug auf die Zeichnungen noch später näher ausgeführt wird.
- 1. Der Benutzer gibt einen neuen Wert in die Entwicklungsumgebung ein.
- 2. Das Web-Frontend sendet einen HTTP-PATCH Request mit der URL „/api/config/devices/DEVICE_NAME/modules/1001/slots/1/configobjects/0x001“ ab. Der Patch sendet als Payload den geänderten Wert der Konfiguration. Das Backend ruft den entsprechenden API-Endpunkt „Update Value“ auf.
- 3. Der Endpunkt teilt über ein Databinding dem Editor mit, dass sich Werte geändert haben, somit kann der Editor seinen „Dirty State“ aktualisieren
- 4. Der Endpunkt schreibt den Konfigurationswert über die „Controller Communication API“ auf die aus Hardware-Modulen gebildete Steuerung
-
Dieser Ablauf kann für die meisten Problemstellungen verwendet werden. Es wird eine Kommunikation mit der Steuerung sowie mit der Benutzeroberfläche der Entwicklungsumgebung SC ermöglicht, die dem Benutzer das Gefühl einer nativen Integration vermittelt.
-
Für Undo/Redo ist eine bidirektionale Kommunikation Voraussetzung. Dies wird durch eine Verwendung des Websockets Protokoll ermöglicht, über die auch vom Server aus Kommunikation an die Web-Applikation initiiert werden kann.
Wird also über das Edit-Menü im SC eine Undo/Redo Aktion getriggert bekommt das Web-Frontend die Information dass sich im SC etwas geändert hat.
-
Der Erfindungsgegenstand der vorliegenden Erfindung ergibt sich nicht nur aus dem Gegenstand der einzelnen Patentansprüche, sondern auch aus der Kombination der einzelnen Patentansprüche untereinander.
-
Alle in den Unterlagen, einschließlich der Zusammenfassung offenbarten Angaben und Merkmale, insbesondere die in den Zeichnungen dargestellte räumliche Ausbildung, könnten als erfindungswesentlich beansprucht werden, soweit sie einzeln oder in Kombination gegenüber dem Stand der Technik neu sind. Die Verwendung der Begriffe „wesentlich“ oder „erfindungsgemäß“ oder „erfindungswesentlich“ ist subjektiv und impliziert nicht, dass die so benannten Merkmale zwangsläufig Bestandteil eines oder mehrerer Patentansprüche sein müssen.
-
Im Folgenden wird die Erfindung anhand von mehreren Ausführungswegen darstellenden Zeichnungen näher erläutert. Hierbei gehen aus den Zeichnungen und ihrer Beschreibung weitere erfindungswesentliche Merkmale und Vorteile der Erfindung hervor.
-
Es zeigen:
- 1: vereinfachtes Blockschaltbild einer Entwicklungsumgebung (Solutionscenter)
- 2: die Darstellung der Programmierung einer von Hardware-Komponenten mit Hilfe der in 1 dargestellten Entwicklungsumgebung
- 3: die schematisierte Darstellung eines Konfigurators, der in die Entwicklungsumgebung integriert ist
- 4: eine gegenüber 3 abgewandelte Darstellung mit der Anbindung an einzelne Hardware-Module eines Stationskopfes einer Steuerung
-
Die 1 zeigt allgemein eine Entwicklungsumgebung 1, die bevorzugt in Eclipse-Java programmiert ist und die dem Benutzer eine grafische Anzeige zur Zusammenstellung seiner Konfiguration zur Verfügung stellt.
-
Es wird bevorzugt, wenn in dieser grafischen Entwicklungsumgebung 1 nun erfindungsgemäß ein Embedded-Webserver 2 implementiert ist. Er stellt eine http-Schnittstelle auf einem lokalen Port der Entwicklungsumgebung 1 zur Verfügung. Dabei ist bevorzugt, dass der Embedded-Webserver 2 keine Verbindung zu außen liegenden Komponenten hat, sondern als lokale Anwendung läuft, die daher besonders störungsfrei und betriebssicher arbeitet.
-
Der Embedded-Webserver 2 erzeugt über eine auf eine REST-basierte HTTPbasierte Schnittstelle 3, die entsprechend den eingezeichneten Pfeilen 5 einen bidirektionalen Datenverkehr zwischen dem Embedded-Webserver 2 und einem mit diesem verbundenen Embedded-Browser 4.
-
Der Embedded-Browser 4 erhält vom Embedded-Webserver 2 die Informationen über die jeweils gesteckten Hardware-Module 13, 14 in der Hardwarestation 11 und stellt eine grafischer Benutzeroberfläche zur Verfügung, um die Möglichkeit der Programmierung und damit eine Erzeugung oder Änderung einer Konfiguration der Hardware-Module 13, 14 zu ermöglichen.
-
Dabei überprüft er insbesondere, dass nur gültige Konfigurationen durchgeführt werden.
-
Somit bilden der Embedded-Webserver 2 und der Embedded-Browser 4 zusammen einen Konfigurator 6 bilden, der in der vorher genannten Entwicklungsumgebung 1 integriert ist.
-
In 2 sind weitere Einzelheiten der Entwicklungsoberfläche mit einer Code-Generierung für einen Feldbus 10 zu entnehmen.
-
Die gleiche Entwicklungsumgebung 1 ist in 2 schematisiert dargestellt, wobei als weitere Merkmale angegeben sind, dass am Ausgang der Entwicklungsumgebung 1 eine Ethernet-Verbindung 7 vorhanden ist, die auf einen Feldbus-Master 8 einwirkt.
-
Im Feldbus-Master ist ein Konfigurationsmodul 9 vorhanden, welches erfindungsgemäß durch die Entwicklungsumgebung 1, nämlich den Konfigurator 6 programmierbar ist.
-
Am Ausgang des Feldbus-Masters 8 ist ein Feldbus 10 üblicher Art angeschlossen, der z. B. als Can-Bus, als Ethercat-Bus, als Profinet-Bus oder als ähnlicher Feldbus ausgebildet sein kann.
-
Wichtig ist, dass verschiedene Bus-Konfigurationen für den Feldbus 10 möglich sind und dass die Entwicklungsumgebung 1 mit dem Konfigurator 6 alle bekannten Feldbusarten beherrscht.
-
Der Feldbus 10 wirkt auf einen hardwareseitig angeordneten Stationskopf 12 in der Hardwarestation 11, der den Kopf für eine Reihe von über einzelne Busverbindungen miteinander verbundenen Hardware-Modulen 13, 14 ausbildet.
-
Der gesamte Hardwareteil wird als Hardware-Station 11 bezeichnet, und die einzelnen Hardware-Module können z. B. auf einzelnen Platinen angeordnete und in einem Schaltschrank gesteckte Ein- und Ausgangsmodule sein, die jeweils über den Feldbus 10 und den Stationskopf 12 individuell programmierbar sind.
-
Statt der Ein- und Ausgangsmodule können auch andere Module verwendet werden, wie z. B. Alarmmodule, Grenzwertmodule, Temperatur- und Feuchtemodule und dergleichen mehr.
-
Wichtig ist, dass die Hardware-Station 11 alle Hardware-Komponenten für eine Anlage enthalten, wie sie z. B. für Windkraftsteueranlagen oder für Maschinensteuerungen notwendig sind.
-
Insbesondere können auch Kraftwerkssteuerungen im Sinne der vorstehend erläuterten Hardware-Station 11 ausgebildet sein.
-
Damit ergibt sich bei der Erfindung der Vorteil, dass mit einer relativ einfach aufgebauten Entwicklungsumgebung 1 und einem darin integrierten Konfigurator 6 der aus Modulen besteht, nämlich einem Embedded-Webserver 2, der nur lokal in der Entwicklungsumgebung 1 arbeitet und einen über eine Schnittstelle daran angeschlossenen Embedded-Browser 4 eine einfach zu bedienende Entwicklungsumgebung 1 geschaffen wird, die auf verschiedene Anwendungsfälle anwendbar ist.
-
Es wird dabei bevorzugt, wenn die Entwicklungsumgebung 1 mit Eclipse-Komponenten arbeitet und damit eine Entwicklungsumgebung 1 vorgegeben wird, die gemäß der technischen Lehre der Erfindung nun durch einen besonderen Konfigurator 6 weitergebildet wird.
-
In 3 ist ein solcher Konfigurator 6 in einem schematisierten Aufbau dargestellt, wo erkennbar ist, dass der Embedded-Browser 4 über die vorher genannte Schnittstelle 3 mit dem Embedded-Webserver 2 zusammen arbeitet.
-
Im Embedded-Browser ist ein konkretes Entwicklungsmodul als „Modul 1“ bezeichnet, dem bestimmte Werte (values) und bestimmte Eingangs- und Ausgangssignale (Sig1) zugeordnet sind.
-
Die vorgegebenen Werte werden nun über die bidirektionale Schnittstelle 3 dem Embedded-Webserver 2 eingegeben, der seine bereits gespeicherten Werte damit erneuert und eine Meldung ausgibt, wenn er feststellt, dass die von dem Embedded-Browser 4 erzeugten Werte neu sind. Es wird dann über den Datenpfad 21 ein User-Interface 16 angesprochen, in dem eine grafische Meldung 18 generiert wird, so dass der Benutzer aufgrund seiner Benutzereingabe 17 erkennen kann, dass eine neue Konfiguration von ihm veranlasst wurde.
-
Die Programmierung der bidirektionalen Schnittstelle 3 ist beispielhaft mit dem Informationspfeil 19 dargestellt, der zeigt, welcher Datenverkehr über die programmierbare Schnittstelle 3 erfolgt.
-
Am Ausgang des Interfaces 15, welches direkt mit dem Embedded-Webserver 2 über den Signalpfad 23 zusammenhängt, ist eine Ethernet-Verbindung 7 vorgesehen, die gemäß der 2 auf den Feldbus-Master 8 und einem dort angeordneten Konfigurationsmodul 9 einwirkt.
-
Aus 4 gehen weitere Einzelheiten der Verbindung der Entwicklungsumgebung mit den Hardware-Komponenten hervor.
-
In weiterer Erläuterung der Funktion des Embedded-Browsers 4 ist aus 4 zu erkennen, dass dieser Browser eine Editing-Funktion hat, eine Verifizierungsfunktion (Validation) und eine Anzeigefunktion (Display) für den Benutzer, um die eingegebenen Werte anzuzeigen.
-
Mit dem Bezugszeichen 24 ist die nach dem REST-API bezeichnet, die in dem Embedded-Webserver 2 integriert ist, welche die Erneuerung oder Veränderung von eingegebenen Werten feststellt und eine bestimmte Meldung über den Pfad 21 ausgibt, wenn eine Veränderung der Werte festgestellt wird.
-
Über den Datenpfad 21 erfolgt auch eine grafische Ausgabe auf das User-Interface 16.
-
Es wird bevorzugt, wenn nun über die Ethernet-Verbindung 7 ein Konfigurationsmodul 9 im Feldbus-Master 8 angesprochen wird, der somit eine Steuerungssequenz zur Verfügung stellt, die zur Programmierung der Hardware-Komponenten in der Hardware-Station 11 dient. Diese Steuerungsinformationen oder Programmierinformationen werden dem Stationskopf 12 der Hardware-Station 11 eingespeist, der hieraus die entsprechenden Konfigurationssignale oder Programmiersignale auf dem internen Bus 22 erzeugt und damit direkt die Hardware-Module 13, 14 programmiert. Somit werden auf den hardwareseitigen EEPROMS Werte eingeschrieben, die zu einer Funktionsänderung der programmierbaren Hardware-Module 13, 14 führen. Dies führt zu einer Funktionsänderung der Hardware-Module 13, 14.
-
Damit können z. B. die Ein- und Ausgänge, die Schwellwerte, die Signalwerte oder andere Parameter in den Hardware-Modulen 13, 14 verändert werden, und zwar entsprechend den eingegebenen Werten in der Entwicklungsumgebung 1.
-
Es wird bevorzugt, wenn die Schnittstellenarchitektur 20 gemäß 4 des Embedded-Webservers 2 als REST-API ausgebildet ist, weil dies eine besonders einfache und betriebssichere Datenumgebung ist.
-
Das aktive Element ist demzufolge immer der Embedded-Browser 4, in den die Daten über eine Benutzereingabe 17 eingegeben werden und der dann über den Embedded-Webserver 2 die Daten entsprechend der geforderten Entwicklungsumgebung 1 umformt, um damit über das Controller-Interface 15 die Ethernet-Verbindung 7 zum Feldbus-Master 8 und dem dort angeordneten Konfigurationsmodul 9 zu steuern.
-
Es handelt sich deshalb um eine feldbus-unabhängige Konfiguration von Hardwaremodulen, die zur Steuerung von Maschinen und Anlagen geeignet sind. Dementsprechend erfolgt die Programmierung über einen Standard-WEB-Browser 4. der in der Entwicklungsumgebung 1 integriert ist.
-
Es wird bevorzugt, wenn der Web-Browser 4 in einer Java-Umgebung eingebettet ist, was eine besonders einfache Bedienbarkeit gewährleistet.
-
Im Endausbau wäre dann ein Standard-WEB-Browser 4 auf einem kundenseitigen Endgerät (z.B. einem Tablet oder Mobiltelefon) vorhanden, der mit der erfindungsgemäßen anbieterseitigen Entwicklungsumgebung 1 einfach zu konfigurieren ist.
-
Damit ergibt sich ein Wettbewerbsvorteil gegenüber bekannten Lösungen, denn bekannte Lösungen verwenden keine Standard-Browser auf den kundenseitigen Endgeräten selbst, sondern müssen für die Kundenseite eine komplizierte Entwicklungsumgebung zur Verfügung stellen.
-
Daher sind die Umprogrammierung und die Veränderung der Konfiguration von kundenseitigen Hardware-Modulen besonders einfach.
-
Bezugszeichenliste
-
- 1
- Entwicklungsumgebung
- 2
- Embedded-Webserver
- 3
- Schnittstelle
- 4
- Embedded-Browser
- 5
- Datenverkehr
- 6
- Konfiguration
- 7
- Ethernet-Verbindung
- 8
- Feldbus-Master
- 9
- Konfigurationsmodul
- 10
- Feldbus
- 11
- Hardwarestation
- 12
- Stationskopf
- 13
- Hardware-Module
- 14
- Hardware-Module
- 15
- Interface
- 16
- User-Interface
- 17
- Benutzer-Eingabe
- 18
- Grafische Meldung
- 19
- Informationspfeil
- 20
- Schnittstellenarchitektur (REST)
- 21
- Datenpfad
- 22
- Bus
- 23
- Signalpfad
- 24
- Programmiersequenz
-
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 102004043788 A1 [0004]
- DE 102007014271 A1 [0006, 0012]
- DE 102007014271 A [0014]
