Automatisierungssysteme mit Web-Technologien

Transkript

1 HAUPTBEITRAG Automatisierungssysteme mit Web-Technologien Architektur und Schnittstellen Das Thema dieses Beitrags ist eine neue Architektur für Automatisierungssysteme auf Basis von Web-Technologien. Die Architektur wird in Anlehnung an den aus dem IT-Bereich bekannten Ansatz einer weborientierten Architektur (WOA) als weborientiertes Automatisierungssystem (WOAS) bezeichnet. Mit der WOAS-Architektur werden die Prinzipien und Methoden aus der standardisierten Welt der Internettechnologien systematisch in die Industrieautomation übertragen. Ein WOAS besteht aus einem WOAS-Kern und einer konfigurierbaren Anzahl weborientierter Automatisierungsdienste, die die erforderlichen Automatisierungsfunktionen realisieren. SCHLAGWÖRTER Automatisierungssystem / weborienterte Architektur / Automatisierungsdienst / CPS-Integrationsplattform Automation System in the Web Architecture and Interfaces The paper describes a new architecture for automation systems based on web technologies. The architecture is designated as a Web-Oriented Automation System (WOAS), following the approach involving a web-oriented architecture (WOA) familiar from information technology. The WOAS architecture allows the principles and methods from the standardized world of Internet technologies to be transferred into the world of industrial automation in a systematic and structured manner. A WOAS consists of a WOAS core as well as a configurable number of web-oriented automation services that implement the required automation functions. KEYWORDS Automation system / Web-oriented architecture / automation service / CPS integration platform 888

2 REINHARD LANGMANN, Fachhochschule Düsseldorf Die Prozess- und Fertigungsautomatisierung befindet sich durch die zunehmende Durchdringung mit IKT-Technologien im Umbruch. Der Einsatz von cyber-physischen Systemen (CPS) und dem darauf basierenden Industrie-4.0-Paradigma bietet hohe Potenziale, um den Herausforderungen der Zukunft in der Automatisierungstechnik gerecht zu werden. Dabei spielen unter anderem die Kommunikationsvernetzung der Systeme/Komponenten und die Bereitstellung und Nutzung von Diensten eine wesentliche Rolle (Internet der Dinge und Dienste). Die klassische Automatisierungshierarchie wandelt sich zu einer flachen Automatisierungswolke [1]. In dieser Automatisierungswolke werden nach einhelliger Auffassung serviceorientierte Architekturen (SOA) als neue Technologie eine besondere Rolle spielen. SOA bietet die Möglichkeit, einheitliche Schnittstellen zu erstellen und eine Kollaboration von der Feldebene bis in die Unternehmensleitebene zuzulassen. Damit lässt sich bei steigender Individualität, Komplexität und Qualität weiterhin ein hoher und kosteneffizienter Durchsatz generieren. Der Trend zur räumlichen und funktionalen Verteilung von Automatisierungsfunktionen ist nicht neu. Bisherige Lösungen setzten immer auf proprietäre und für die Automatisierungstechnik spezialisierte Lösungen, die sich aber aufgrund ihrer Kompliziertheit und nicht ausreichender Industrieunterstützung (zum Beispiel Corba) kaum durchsetzen konnten. Erst die neuen und standardisierten IT-Technologien mit Web/ Internet an der Spitze schufen die Voraussetzungen für eine räumlich unbegrenzte Verteilung von Funktionen/ Diensten und werden nun auch für die Automatisierungs-technik interessant. Auf die Prozessleittechnik, die sich mit übergeordneten und koordinierenden Automatisierungsfunktionen bereits mit den eher dispositiven und verteilenden Aufgaben beschäftigt, wird sich der zuvor erwähnte Trend zunehmend auswirken. Das verdeutlicht die Tatsache, dass bereits 2012 über 2000 Scada-Systeme über das Internet bedienbar waren [2]. 1. Ansatz Im Gegensatz zur klassischen Verwendung des Begriffs Automatisierungssystem wird für die folgenden Ausführungen das Gesamtsystem zur Automatisierung eines technischen Prozesses geteilt in das Automatisierungssystem (AS) und ein Feldsystem (FS). Das Automatisierungssystem (AS) besteht im wesentlichen aus Software-Komponenten, die auf Rechnern unterschiedlicher Ausprägung verteilt sein können. Es lässt sich in eine definierte Anzahl von Automatisierungsfunktionen () aufteilen. Gegenüber dem Automatisierungssystem präsentiert sich der technische Prozess ausschließlich über die vom Feldsystem bereitgestellten Prozessdaten. Diese Prozessdaten werden im Automatisierungssystem innerhalb verschiedener verarbeitet. Für das Automatisierungssystem ist ein weiches Echtzeitverhalten charakteristisch. Typische Beispiele für Automatisierungssysteme sind Prozessvisualisierungs-, HMI- und Leitsysteme (Scada)). Das Feldsystem (FS) arbeitet mit Prozesssignalen aus Automatisierungsgeräten und verarbeitet diese zu Prozessdaten. Es beinhaltet alle erforderlichen Sensoren und Aktoren und kann darüber hinaus Automatisierungsfunktionen beinhalten, wie zum Beispiel Steuerung und Regelung. Das Feldsystem muss üblicherweise ein hartes Echtzeitverhalten gewährleisten. Typische Feldsysteme sind SPS- und CNC-Steuerungssysteme. Im Sinne der im Beitrag verwendeten Begriffsdefinition könnte ein Automatisierungssystem auch alle erforderlichen Automatisierungsfunktionen beinhalten, sodass das Feldsystem dann nur noch aus Sensoren/Aktoren mit Signalaufbereitung besteht. Dies hängt von der jeweiligen maximalen Prozesszeit des zu automatisierenden technischen Prozesses ab. Wäre es möglich hier noch zwei Zeilen zu längen? 889

3 HAUPTBEITRAG 2. Automatisierungssysteme im Web 2.1 Stand der Technik Unter dem Stichwort Webtechnologie für die Automatisierung werden seit einigen Jahren Standardtechniken aus der Welt der Informationstechnologie für Automatisierungssysteme verfügbar gemacht und eingesetzt. Verstärkt wird diese Entwicklung durch die in [3] dargelegten Empfehlungen zur Thematik Industrie 4.0 und Cyber-Physical Production Systems (CPPS), um den Produktionsstandort Deutschland auch in Zukunft zu sichern, sowie durch die Diskussion über das Internet der Dinge [4]. Zu den technischen Entwicklungsschwerpunkten gehören dabei die Nutzung des Webbrowsers als universelle Bedienschnittstelle für automatisierte Geräte, Maschinen und Anlagen, der Einsatz von Ethernet und TCP/IP beziehungsweise IP-Netzen als vertikale und horizontale Kommunikation zwischen den Ebenen in der klassischen Automatisierungspyramide, die Nutzung von XML als Beschreibungssprache für Protokolle, Dienste und Komponenten. Einige Entwicklungen beschäftigen sich damit, Automatisierungsfunktionen aus den prozessfernen Ebenen in das IP-Netz zu verlagern beziehungsweise Geräte der prozessnahen Ebene mit Dienstschnittstellen zu versehen, damit diese in einem IP-Netz zum Beispiel über eine Cloud genutzt werden können [5, 6]. Andere Arbeiten befassen sich mit der Entwicklung von Dienstestrukturen für Automatisierungssysteme auf Basis einer serviceorientierten Architektur (SOA). Ziel ist dabei vorrangig die Ausrüstung von Geräten mit embedded Diensten [7]. Auch die Nutzung von webbasierten Cloud-Technologien für den Betrieb von Automatisierungsdiensten wird zunehmend thematisiert [8]. Nach einer Studie in [9] sind für Geschäftsanwendungen SOA-Modelle sehr kompliziert, zentralisiert und schwergewichtig. In Zusammenhang mit neueren Entwicklungen für das Web 2.0 werden deshalb leichtgewichtige, hochflexible und dezentralisierte Strukturen wie die weborientierte Architektur (WOA) an Bedeutung gewinnen. Dies wird durch die Aussagen in [10] unterstrichen, nach denen WOA als Basis betrachtet wird, um zukünftige SOA-Systeme zu entwickeln. WOA-Strukturen ergänzen beziehungsweise erweitern SOA-Strukturen und verlagern erforderliche Informationsverarbeitungsprozesse in den Webbrowser, um beispielsweise die SOA-Server zu entlasten. Erste Ansätze zur Nutzung von WOA-Modellen für Automatisierungssysteme kommen aus der Gebäudeautomatisierung. Neue Systeme zum Betrieb und zur Datenerfassung/-auswertung von im Internet verteilter Sensorik/Aktorik setzen dazu Verfahren aus dem Web-2.0-Umfeld (zum Beispiel Ajax und Rest) sowie das Cloud-Computing ein [11,12]. 2.2 Herausforderungen Die Zielsetzung zur Weiterentwicklung von Automatisierungssystemen beinhaltet eine wesentliche Verbesserung der horizontalen und vertikalen Kommunikation und Datenintegration, eine Reduzierung der Schnittstellenprobleme durch Vereinheitlichung und Nutzung von informationstechnischen Standards sowie damit verbunden eine wesentliche Erhöhung von Flexibilität und Effizienz als Voraussetzung für die künftig erforderliche Fähigkeit zur Selbstanpassung und Autonomie. Die meisten bekannten Arbeiten setzen dazu die Webtechnologien partiell, herstellerspezifisch und/oder begrenzt offen ein. Selbst Systeme, die durchgängig Webtechnologien für die Funktionsrealisierung verwenden, verbleiben in der klassischen Server-Client-Struktur und lassen weder eine verteilte Strukturierung des AS noch die Nutzung verteilter Dienste zu (zum Beispiel WEBfactory, atvise). Web-2.0-Technologien werden bisher nur wenig berücksichtigt. Eine auf Basis von Webtechnologien mögliche Modellierung eines AS sowie eine entsprechende Engineering-Umgebung steht nicht zur Verfügung. Damit ergeben sich keine prinzipiellen Änderungen in der Struktur der Automatisierungssysteme und die erwähnte Zielsetzung ist unter den Bedingungen einer vollständigen Vernetzung nach Industrie 4.0 nur unvollständig realisierbar. Zusammengefasst ergeben sich deshalb Herausforderungen, um Automatisierungsssysteme für die Zukunft vorzubereiten: AS benötigen eine durchgängige, offene und konsistente Modellierung auf Basis von webbasierten Standardtechnologien. Webtechnologien werden zwar teilweise eingesetzt, erforderlich ist aber weiterhin die flexible Verteilung von Struktur und Funktion eines AS auf Basis dieser Technologien. Neue Web-2.0-Technologien wie MashUps (Erstellung neuer Webinhalte durch Kombination bereits bestehender Inhalte), Rest (Programmierparadigma für verteilte Webanwendungen), WebSockets (TCP- Netzwerkprotokoll für bidirektionale Verbindungen zwischen einer Webseite und einem Server) müssen auf ihre Einsatzfähigkeit für die Automatisierung geprüft und gegebenenfalls modifiziert werden. Für die Zukunft einer webbasierten Automatisierungsdiensteindustrie sind weborientierte Architekturen basierend auf dem SOA-Prinzip für AS erforderlich. Verfügbare Standardtechnologien aus der Welt der IP-Netze müssen verstärkt für ihren Einsatz in AS untersucht werden, um die Flexibilität und Effizienz zu erhöhen und eine durchgängige und konsistente Kommunikation zu ermöglichen. 890

4 AUTOMATISIERUNGSSYSTEM WOAS Cloud Prozessdaten AS SK AS AS SK AS SK FELDSYSTEM Sensoren Aktoren Signale vom/zum technischen Prozess BILD 1: Trennung in Automatisierungsund Feldsystem BILD 2: Prinzipstruktur eines WOAS 3. Das WOAS-Projekt Bild 2 Basierend auf den beschriebenen Herausforderungen wurde 2011 das IGF-Forschungsprojekt Architektur und Schnittstellen für ein weborientiertes Automatisierungssystem (WOAS) unter Beteiligung von 10 Automatisierungsfirmen gestartet. Ziel des Forschungsvorhabens war es, eine Architektur für Automatisierungssysteme auf Basis von Webtechnologien zu erforschen. Diese Architektur wird in Anlehnung an den WOA-Ansatz [9] als weborientiertes Automatisierungssystem (WOAS) bezeichnet. Ein WOAS besteht dabei aus einem WOAS-Kern und einer konfigurierbaren Anzahl von weborientierten Automatisierungsdiensten (WOAD), die die erforderlichen Automatisierungsfunktionen realisieren. Mit der WOAS/WOAD-Methodik wurde ein konsistentes und pragmatisches Architekturmodell für weborientierte Automatisierungslösungen (Referenzmodell) geschaffen, das die Basis für die Generierung von verteilten nutzerspezifischen AS in einem IP-Netz bildet. Bild 2 zeigt die Prinzipstruktur eines WOAS. Das Automatisierungssystem wird erst zur Betriebszeit aus einer Bauvorschrift im Webbrowser eines Nutzers erzeugt und dort als Systemkern (SK) ausgeführt. Die erforderlichen Automatisierungsfunktionen werden als Automatisierungsservices über eine WOAS-Cloud genutzt. Der Anschluss der Feldsysteme (Geräte) erfolgt über Standardindustrieschnittstellen mit Webanbindung. Auf alle Elemente eines WOAS, einschließlich des Engineering-Systems (WOAS Creator), kann über das Web zugegriffen werden. 3.1 Systemkern Wichtigster Teil des WOAS-Architekturmodells ist der Systemkern (WOAS-Kern). Er schafft die Voraussetzungen, um herstellerunabhängig unterschiedliche Automatisierungsfunktionen als Dienste zusammen mit unterschiedlichen Automatisierungsgeräten (Feldsystem) verteilt im Netz in einheitlicher Art und Weise verbinden zu können. Bild 3 verdeutlicht dazu die Komponentenstruktur des WOAS-Kerns. Über Virtual Devices (VD), siehe Abschnitt 3.3, erfolgt die einheitliche Abbildung (Mapping) der jeweiligen Automatisierungsgeräte auf die WOAS-Webstruktur. Die WOAD-Stubs schaffen gegenüber dem Kern ein einheitliches Interface zu unterschiedlichen Diensten, und über den WOAS-Distributor erfolgt die Verbindung der Geräteprozessdaten mit den erforderlichen E/A- Daten der Dienste. Basierend auf einem Datenmodell eines WOAS gelten diese WOAD-Stubs sind an dieser Stelle noch nicht eingeführt. Eine auf Dienste bezogene Erklärung folgt in 3.2, gegebenenfalls vorziehen. 891

5 HAUPTBEITRAG Jedes WOAS besteht aus einem Workspace mit Control Panels, denen Views zugeordnet sind. Ein Workspace entspricht dabei einem strukturierten Webobjekt, das im Webbrowser ausführbar ist. Die Views sind die im Browser sichtbaren Webseiten. Jedes Control Panel beinhaltet genau einen WOAS- Distributor sowie mehrere Virtual Devices und WOAD-Stubs. Jeder WOAS-Distributor kann mit mehreren Virtual Devices und mit mehreren WOAD-Stubs zusammenarbeiten. Ein Virtual Device und auch ein WOAD-Stub kann mit mehreren WOAS-Distributoren verbunden sein. Die Kommunikation innerhalb eines WOAS-Kerns erfolgt ausschließlich über ereignisbasierte Prozessdatenkanäle. Beim Laden des WOAS-Kerns erfolgt die dynamische Erzeugung des WOAS-Distributors, der die generische Verbindung zwischen den Virtual Devices und den Automatisierungsdiensten übernimmt. JavaScript-Entwicklungsumgebung bereitgestellt, die eine WOAS-Umgebung simuliert. Aus Sicht eines WOAS besteht ein Dienst immer aus zwei Beschreibungsteilen: WOAD general: Dieser Teil wird durch den Diensteanbieter (Publisher) festgelegt. Dazu gehören zum Beispiel Dienstname, Version, IP-Adresse, Beschreibung. WOAD specific: Diesen Teil legt ein Anwender während des Projektierungsprozesses eines WOAS fest. Dazu gehören beispielsweise Darstellungsparameter, Prozessdatenzuordnung. Damit Automatisierungsdienste kostenpflichtig abgerechnet werden können, ist in der WOAS-Architektur ein Clearing-Konzept vorgesehen, nach dem Dienste feingranular abgerechnet werden können. Damit lassen sich neue Geschäftsmodelle zum Vermieten von Automatisierungsfunktionen realisieren [13]. 3.2 Automatisierungsfunktionen als Dienste Weborientierte Automatisierungsdienste realisieren im WOAS die Automatisierungsfunktionen. Für eine strukturierte Nutzung müssen WOAD beschrieben und modelliert werden können (ähnlich Webservices). Für die Verwaltung, Publikation und Nutzung von Automatisierungsdiensten wird ein WOAD-Verzeichnis (Repository) benötigt, in dem die Dienste mit ihren Eigenschaften gesammelt sind. Ein WOAD-Stub realisiert eine definierte und offengelegte Aufrufschnittstelle, um Dienste in einer einheitlichen Form mit dem WOAS-Kern zu verbinden. Dabei gelten folgende Prinzipien: Dienste werden erst zur Runtime an den WOAS- Kern gebunden. Der WOAD-Stub realisiert nur die Übergabe der Prozessdaten an einen Dienst, die Automatisierungsfunktion ist interner Bestandteil des Dienstes und wird über diesen festgelegt. Über den WOAD-Stub werden die Dienste in die einzelnen Views eingebunden. Zur Nutzung von Automatisierungsfunktionen als Dienste werden diese in der WOAS-Architektur in Abhängigkeit von den jeweils erforderlichen Prozessdaten in fünf WOAD-Typen eingeteilt, siehe Tabelle 1. Im Unterschied zu klassischen Webservices lassen sich Dienste sowohl serverseitig als auch clientseitig oder gemischt zur Runtime nutzen. Es werden Clienttechnologien wie Mashups mit Servertechnologien (SOA) kombiniert. Die erforderliche Dienstschnittstelle zum WOAS ist über ein Datenmodell und die Aufrufschnittstelle wohlstrukturiert, damit ein Drittanbieter Dienste für WOAS bereitstellen kann. Zur Offline-Entwicklung und zum Test von Diensten wird eine spezielle HTML/ 3.3 Geräteintegration Nach dem WOAS-Ansatz, siehe Bild 1, befinden sich alle Automatisierungsgeräte im Feldsystem. Ein Automatisierungsgerät (AG) und damit im Prinzip auch das Feldssystem wird in WOAS als Virtual Device modelliert. Ein VD ist ein Software-Objekt, das die Eigenschaften eines Automatisierungsgerätes für ein nutzerspezifisches WOAS abbildet. Es kann direkt im WOAS-Kern oder als zulinkbare Dateien realisiert sein. Jedes VD besitzt zur Verbindung mit dem WOAS-Kern ein einheitliches und schlankes JavaScript-Objektinterface und zur Verbindung mit dem AG eine WOAS-Device-Protokollschnittstelle. Jedes Virtual Device wird, ähnlich einem Dienst (WOAD), durch allgemeine Daten (general data) sowie spezifische Daten (specific data) charakterisiert. Die allgemeinen Daten werden durch den Hersteller des VD vorgegeben und kennzeichnen unter anderem die VD- Klasse. Die spezifischen VD-Daten werden durch einen WOAS-Nutzer erzeugt und parametriert. Zur schnellen und zuverlässigen Übertragung von Prozessdaten wird für ein WOAS ein schlankes und flexibles Gerätemodell benötigt. Bekannte Gerätemodelle der Automatisierungstechnik (wie GSD, FDT/ DTM, EDS, FDI) sind für Engineering-Zwecke optimiert und für einen Runtime-Betrieb über IP-Netze aufgrund ihrer Komplexität und Schwergewichtigkeit wenig geeignet. Das WOAS-Gerätemodell nutzt deshalb ein einfaches Input/Output-Channel-Konzept (vergleichbar mit dem Portkonzept aus AutomationML), um Prozessdaten einheitlich für Automatisierungsdienste bereitzustellen. Jeder Channel besitzt festgelegte Parameter und ist über Options beliebig erweiterbar (zum Beispiel mit einer semantischen Beschreibung). Ein VD kann beliebig viele Channels besitzen. Mittels eines Virtual Device werden die Prozessdaten eines Automatisierungsgerätes über ereignisbasierte 892

6 Kanäle auf web- beziehungsweise internetgeeignete Objekte abbildet und in einem Webbrowser verfügbar gemacht. Über integrierte Device beziehungsweise Protocol Gateways können beliebige Industrieschnittstellen (wie OPC DA, OPC UA, Modbus TCP) damit im IP- Netz verfügbar gemacht werden. Zur Datenübertragung zwischen einem VD und einem Automatisierungsgerät wurde ein einfaches und pragmatisches WOAS Device Protocol (WOAS-DP) entwickelt, das als Datenformat JSON für die Prozessdatenübertragung über das HTTP-Protokoll und Websockets nutzt. Die Device Gateways und die Protocol Gateways lassen sich wie folgt charakterisieren: Ein WOAS Protocol Gateway (WPG) realisiert die Umsetzung des WOAS-DP in das erforderliche Industrieprotokoll zur Kommunikation mit dem realen AG. Das WPG kann direkt als JavaScript-Protokollumsetzer Bestandteil des Virtual Device sein oder es ist auf einer externen Hardware (IPC, embedded Server) realisiert. Als WOAS Device Gateway (WDG) wird die externe Hardware bezeichnet, die ein oder mehrere WOAS Protocol Gateways realisiert. Kommt dabei ein IPC zum Einsatz, können weitere erforderliche Geräte-/Protokolltreiber (zum Beispiel OPC-DA-Server) auf dem WOAS Device Gateway installiert sein. Zur Anpassung an unterschiedliche Gegebenheiten und Industrieprotokolle werden drei VD-Klassen unterschieden, die sich vor allem durch die Art und Weise ihrer Integration in ein WOAS-System unterscheiden: VD Class 1: Diese Virtual Devices sind bereits als Plug-in im WOAS-Server realisiert (internal VD) und setzen die Kernaufrufe direkt in die erforderlichen Geräteprotokollinformation um. Dies ist dann vorteilhaft, wenn das Automatisierungsgerät bereits eine geeigneten IP-Schnittstelle (zum Beispiel OPC UA) oder ein internes Protocol Gateway besitzt. WOAD stub 1 WOAD stub 2 WOAD stub M... WOAS distributor DB Connection matrix WOAD VD Virtual Device 1 (VD 1) Virtual Device 2 (VD 2)... Virtual Device N (VD N) BILD 3: Komponentenstruktur des WOAS-Kerns Typ Sichtbarkeit im WOAS-Client Prozessdaten Input/Output Funktionalität Beispiel Bild 3 Typ 1 Nein Input ODER (Input & Output) Realisierung eines Algorithmus Messwertverarbeitung, Datenarchivierung, Ablaufsteuerung Typ 2 Ja Input Visualisierung von Prozessdaten Echtzeit-Trend Typ 3 Ja Output ODER (Output & Input) Bedienung von Prozessdaten Schieberegler, Schalter, Tastenfeld Typ 4 Ja Input & Output Beeinflussung und Visualisierung von Prozessdaten HMI, Alarmbehandlung Typ 5 Ja - Auswertung von historischen Daten Trendanalyse, Alarmanalyse TABELLE 1: WOAD-Typen 893

7 Sind der WOAS Portal Creator und der WOAS Creator das gleiche Stück Software? VD Class 2: Das Virtual Device beinhaltet ein separates WOAS Protocol Gateway in JavaScript, das die WOAS-Aufrufe in das erforderliche Industrieprotokoll/Geräteschnittstelle umsetzt. Das WOAS-DP kann hierbei zur internen Kommunikation auf Softwareebene genutzt werden. VD Class 3: Das Virtual Device kommuniziert mit einem externen WOAS Device Gateway, das in der Regel über Websockets WS/TCP mit dem VD verbunden ist und über das WOAS-DP Nachrichten austauscht. Für die Kommunikation können auch andere Protokolle genutzt werden. Bild 4 veranschaulicht die unterschiedliche Anbindung von Automatisierungsgeräten über verschiedene VD-Klassen in einem WOAS. Anmerkung zu OPC UA: Ein Virtual Device in WOAS nutzt üblicherweise JavaScript und Websockets für die bidirektionale und ereignisbasierte Kommunikation zum Automatisierungsgerät. Auch wenn OPC UA direkt über ein IP-Netzwerk zugreifbar ist, so wird dafür ein Gateway benötigt, um für das OPC UA-Gerät eine Websocket-Schnittstelle zu erzeugen. Zukünftig wäre es sicher sehr hilfreich, wenn OPC UA einen direkten Websocket-Zugang ermöglicht. 4. Implementierung und Evaluierung Test und Evaluierung der WOAS-Architektur erfolgten an einem Demonstrator, bestehend aus einer Anlage zur Montage von Modellautos mit fünf Montage- beziehungsweise Demontagestationen, siehe Bild 5. Die Montageteile befinden sich auf einem Werkstückträger, der mittels eines Transportbandes zwischen den einzelnen Stationen bewegt wird. Durch den gewählten Montage/Demontageprozess, der keine Teilezu- und -abführung benötigt, lässt sich die Anlage für den Testbetrieb über das Internet ohne Aufsicht dauerhaft nutzen. Bezogen auf Bild 1 bilden jeweils die Steuerung und der IPC in Bild 5 das Feldsystem, in dem die SPS-Programme sowie ein WOAS Protocol Gateway für den Zugriff auf OPC-Daten laufen. Als WOAD sind verschiedene Bedien-, Visualisierungs- und Auswertefunktionen für die Stationen realisiert. 4.1 WOAS-Portal Ein WOAS wird in einem Projektierungsprozess mittels eines Werkzeuges (WOAS Portal Creator) erzeugt. Die Implementierung des Prototyps eines solchen WOAS- Portals wurde mittels HTML5, Java, JavaScript, PHP und einer mysql-datenbank realisiert. Die Datenübertragung zwischen den Kern-Komponenten erfolgt über Websockets und JSON. Dazu wird der freiverfügbare jwebsocket-server mit zusätzlich entwickelten Plug-ins genutzt. Bild 6 zeigt den WOAS-Creator (= WOAS-Portal im Projektierungsmode) im Webbrowser. Im linken Teil in Bild 6 befindet sich der Navigator für die nutzerspezifischen Control Panels/Views, im mittleren Teil ist die Arbeitsfläche des Creators zu sehen, und der rechte Teil beinhaltet das Parametrierungsmenü für die Dienste. Im unteren Teil stehen Registerkarten für die Parametrierung der Dienste und Virtual Devices zur Verfügung. Das WOAS-Portal ist öffentlich zugängig und kann unter getestet werden. Ein Admin- Zugang für den EDIT-Modus eines WOAS findet sich in den Nutzerhinweisen zum Portal [14]. 4.2 Dienste und Geräte Zur Evaluierung der Architektur und Schnittstellen wurden bisher 18 Dienste unterschiedlichen Typs sowie sechs verschiedene Gerätezugänge entwickelt und erprobt. Eine vollständige Übersicht der im Prototyp des WOAS-Portals verfügbaren Dienste (WOAD) mit Beschreibung der Parameter enthält [14]. Zu den Diensten gehören zum Beispiel verschiedene HMI-Elemente, ein Echzeit-Plotter und Visualisierungsdienste einschließlich eines Webcam-Dienstes. Tabelle 2 gibt eine Übersicht über die verfügbaren WOAS-Protokoll- beziehungsweise Device-Gateways als Gerätezugänge. Über die Protocol Gateways beziehungsweise Device Gateways können Dritte ihre Automatisierungsgeräte unproblematisch in das WOAS-Portal einbinden. Hinweise zur Installation der Gateways finden sich im Düsseldorfer Telelabor ( Ausführliche Information zum gemessenen Zeitverhalten der Gerätezugänge nach Tabelle 2 ist in [15] veröffentlicht. 4.3 Betriebserfahrungen und Probleme Das WOAS-Portal wird seit Mai 2014 für verschiedene Aufgaben im Competence Center Automation Düsseldorf (CCAD) der FH Düsseldorf genutzt: Bedienung und Visualisierung von zwei öffentlich zugänglichen WOAS-Demonstratoren (Montagestation und Bearbeitungsstation), Nutzung als einfaches Scada/HMI-System für die Forschungs- und Trainingsfabrik Fab21 ( im Intranet, Entwicklungsumgebung für neue Automatisierungsdienste im Rahmen von studentischen Projektarbeiten. In Arbeit ist weiterhin der Einsatz des WOAS-Portals als Entwicklungs- und Runtime-Umgebung für neue Smart Remote Labs zur Ausbildung in der Automatisierungstechnik. Der besondere Vorteil von WOAS liegt in der schnellen und einfachen Erweiterung des Systems mit weiteren Automatisierungsfunktionen als Dienste. Alle mit Webtechnologien verfügbaren Funktionalitäten können 894

8 BILD 4: IP-Anbindung von Automatisierungsgeräten über Virtual Devices VD -Typ 1 Virtual Device Automatisierungsgerät Protocol Gateway AG mit integriertem Protocol Gateway VD -Typ 2 Virtual Device Protocol Gateway Automatisierungsgerät AG mit interner IP-Schnittstelle VD -Typ 3 Virtual Device Device Gateway Protocol Converter Automatisierungsgerät AG mit externem Protokoll-Gateway Station 5 IPC Steuerung IPC Steuerung Bild 4 Station 4 IPC Steuerung Station 1 Station 2 Station 3 Steuerung IPC Steuerung IPC BILD 5: WOAS- Demonstrator (Montagestation) BILD 6: Prototyp des WOAS-Portals (EDIT-Modus Beispiel: Demo Panel) d 5 Industrie- Interface Webtechnologie Kommunikation Reaktionszeit (gemessener Richtwert für die Übertragung eines Prozessdatums) OPC DA Applet/Java TCP 50 ms 3 VD- Klasse OPC DA JS/Java WS 40 ms 3 Modbus TCP JS/PHP WS 100 ms 3 OPC DA Ajax/PHP HTTP 150 ms 2 IEC JS/FBS WS 20 ms 2 Vathauer Frequenzumrichter JS/Java WS 150 ms 1 OPC UA JS/Java WS/OPC noch in Entwicklung 1 TABELLE 2: Verfügbare Gerätezugänge für WOAS (ws Websocket, JS JavaScript, FBS -Funktionsbausteinsprache) 895

9 HAUPTBEITRAG dank der schlanken und pragmatischen Schnittstellen in kurzer Zeit in WOAS integriert werden. Dies trifft gleichfalls auf neue Gerätezugänge über das Prinzip der Virtual Devices zu. Das WOAS-Portal ist ein Prototyp und damit noch mit einer Reihe von implementierungstechnischen Problemen behaftet, die zwar einen Testbetrieb, aber noch keinen Produktionsbetrieb ermöglichen. Für 2014/2015 ist dazu eine Überarbeitung vorgesehen. Bisher konnten aus Ressourcengründen folgende Funktionen noch nicht realisiert werden: Client-Rechner Auslastung CPU [%] Intel Core i ,4GHz, vier Kerne, 64Bit Windows 7, 8 GB RAM (PC) Intel Core i5-4300u 1,9 GHz, zwei Kerne, 64-Bit-Windows 8, 4 GB RAM, (Surface Tablet) TABELLE 3: Client-Performance für ein Beispiel-WOAS SERVICE DEVICE Das Clearing-System zur Abrechnung von WOAD ist als Rahmen in das System integriert, aber noch nicht funktionsfähig. Die rollenbasierte Nutzerverwaltung ist noch nicht vollständig implementiert. Neue Nutzer bezie- User 1 SERVICE WOAS-Portal User 2 DEVICE User n SERVICE BILD 7: WOAS-Portal als multi-user- und multi-rollen-basierte Integrationsplattform DEVICE hungsweise Zugänge müssen zur Zeit noch händisch über die Datenbank angelegt werden. Für Testzwecke stehen 10 Zugänge mit den Rollen Admin und User zur Verfügung. Neue Dienste und Gerätezugänge können durch die Nutzer noch nicht über das Portal hinzugefügt werden. Dazu ist derzeit noch ein separater FTP-Zugang erforderlich. Ein WOAS ist eine Rich-Client-Anwendung und benötigt, abhängig von der Anzahl der dynamischen Prozessdaten und der Komplexität der Dienste, die genutzt werden sollen, eine entsprechende Rechenleistung im Client- Rechner. Dynamische Visualisierungen mit Taktzeiten < 200 ms im Webbrowser führen zu hohen CPU-Belastungen. Die CPU-Auslastung für ein Beispiel (siehe Demo Panel unter woas.ccad.eu) zur Visualisierung von 18 Prozessdaten mit einer Aktualisierungsrate von etwa 100 ms zeigt Tabelle 3 (Webbrowser = Google Chrome). Aus Tabelle 3 wird auch sichtbar, dass moderne Tablet-Rechner in der Lage sind ein WOAS im Webbrowser mit ausreichender Performance zu betreiben. 5. WOAS als CPS-Integrationssystem Ursprünglich wurde WOAS für Automatisierungssysteme der nicht-zeitkritischen Ebenen entwickelt, vergleiche Bild 1. Unter dem Blickwinkel von Industrie 4.0 und CPS-basierter Automation zeigt sich aber, dass das WOAS-Portal generell als CPS-Integrationsplattform fungieren kann. Nach [1] kommunizieren CPS-basierte Automatisierungssysteme über offene, globale Informationsplattformen (Internet). Ihre Teilsysteme und Komponenten nutzen beziehungsweise stellen über diese Netze offen verfügbare, relevante Daten und Dienste zur Verfügung. Aus dieser Definition lässt sich eine wesentliche Herausforderung ableiten, die für CPS-basierte Automatisierungssysteme umgesetzt werden muss: CPS-Komponenten müssen im Gegensatz zu klassischen Automatisierungsgeräten geeignete Schnittstellen zu einem IP-Netz besitzen. Diese Schnittstellen sollen standardisiert beziehungsweise weit verbreitet, sicher und zuverlässig sein, sowie möglichst zeitdeterministisch arbeiten. In WOAS entsprechen die in Bild 4 dargestellten VD- Typen den CPS-Komponenten. Mit dem gleichzeitig verfügbaren Konzept der Dienste (WOAD) bildet das WOAS-Portal eine Integrationsplattform mit der beliebig in einem IP-Netz (lokal oder weltweit) verteilte Dienste mit beliebigen im IP-Netz verteilten CPS-Komponenten zu Funktionalsystemen verbunden werden können. Damit ergibt sich eine flache Automatisierungsstruktur mit verteilten Diensten, wie sie nach [1] für künftige Produktionssysteme erwartet wird. Hauptaufgabe des WOAS-Portal als CPS-Integrationsplattform ist die nutzerspezifische Verknüpfung der 896

10 Dienste mit den CPS-Komponenten, und dies in der Projektierungs- und Runtime-Phase. Erforderlich dazu ist eine multi-user und multi-rollen-basierte Integrationsplattform, die für einen bestimmten Anwendungskontext Lösungen bereitstellen kann. Dabei spielt es keine Rolle, ob der Anwendungskontext die Produktionsautomatisierung, Medizintechnik oder beispielsweise Verkehrstechnik ist, siehe Bild 7. Zusammenfassung Mit dem Prototyp des WOAS-Portals steht eine Konfigurations- und Runtime-Umgebung online und webbasiert zur Verfügung, mit der weltweit verteilte Geräte (Automatisierungsgeräte) mit beliebigen verteilten Diensten (Automatisierungsdiensten) zu nutzerspezifischen Funktionalsystemen integriert und für einen Testbetrieb genutzt werden können. Als Alleinstellungsmerkmal gegenüber allen anderen cloud-basierten Integrationssystemen für die Automatisierung kann das WOAS-Portal durch beliebige Dienste Dritter und weitere Gerätezugänge über konsistente und offengelegte Schnittstellen erweitert werden. Manuskripteingang Im Peer-Review-Verfahren begutachtet Autor Prof. Dr.-Ing. REINHARD LANGMANN (geb. 1950) ist seit 1993 als Professor an der Fachhochschule Düsseldorf in der Automatisierungstechnik tätig. Er ist Sprecher des Competence-Center Automation Düsseldorf (CCAD) sowie Leiter der Forschungs- und Trainingsfabrik Fab21 und des Düsseldorfer Telelabors. Sein Interessensschwerpunkt liegt auf dem Gebiet der Internettechnologie für die Industrieautomation. Seit 2008 ist er 1. Vorsitzender des Vereins für Angewandte Automatisierungstechnik in Lehre und Entwicklung an Hochschulen VFAALE e.v. Fachhochschule Düsseldorf, Fachbereich Elektrotechnik, Competence Center Automation Düsseldorf (CCAD), Josef-Gockeln-Str. 9, D Düsseldorf, Tel. +49 (0) , Referenzen [1] VDI/VDE-GMA: Cyber-Physical Systems:Chancen und Nutzen aus Sicht der Automation. Thesen und Handlungsfelder, April 2013 [2] Gritsai, G., Timorin, A., Goltsev, Y., Ilin, R., Goirdeychik, S., Karpin, A.: SCADA Safety in Numbers v Survey of Positive Technologies, 2012, S. 17, [3] Kagermann, H., Wahlster, W., Helbig, J.: Umsetzungsempfehlungen für das Zukunftsprojekt Industrie 4.0. Abschlussbericht des Arbeitskreises Industrie 4.0, Forschungsunion Wirtschaft Wissenschaft, 2013 [4] Chase, J.: Die Zukunft des Internet der Dinge : Ein Ausblick. Whitepaper Texas Instruments, 2013, [5] SOCRADES: EU-Project, [6] IMC-AESOP: EU-Project, [7] Mathes, M., Stoidner, C., Heinzl, S., Freisleben, B.: SOAP4PLC: Web Services for Programmable Logic Controller. - 17th Euromicro International Conference on Parallel, Distributed and Network-based Processing, S , IEEE Computer Society Press, 2009 [8] Honeywell Int Inc.: Cloud computing for an industrial automation and manufacturing system. - Patent, US B2, [9] Thies, G., Vossen, G.: Web-Oriented Architectures: On the Impact of Web 2.0 on Service-Oriented Architectures. In: Tagungsband Asia-Pacific Services Computing Conference APSCC 08, S IEEE Conference Publications, 2008 [10] Hinchcliffe, D: What Is WOA? It s The Future of Service- Oriented Architecture (SOA). 2008, archive/2008/02/27/16617.aspx [11] Etherios: Device Cloud. 2014, products/devicecloud/ [12] System LineMetrics: Die LineMetrics Plattform. 2014, [13] Langmann, R.: Rent an Automation Service - Smarte Geschäftsmodelle für Industrie 4.0 In: Tagungsband GMA-Kongress AUTOMATION 2014, [CD] VDI 2014 [14] CCAD: WOAS-Integrationsportal Nutzerhinweise. Düsseldorf, 2014, [15] Langmann, R.: Ein Interface für CPS-basierte Automatisierungsgeräte. In: Tagungsband Konferenz für Angewandte Automatisierungstechnik in Lehre und Entwicklung (AALE 2014), S DIV Deutscher Industrieverlag,