IoT-Basics

OPC UA schafft Interoperabilität im I4.0-Umfeld

| Autor / Redakteur: Stefan Hoppe / Jürgen Schreier

Ohne OPC UA kein Industrie 4.0! Nur mit standardisierter Kommunikation werden Feldgeräte, Maschinen und die Cloud zum Team.
Ohne OPC UA kein Industrie 4.0! Nur mit standardisierter Kommunikation werden Feldgeräte, Maschinen und die Cloud zum Team. (Bild: Pixabay / CC0)

Semantische Interoperabilität gilt als Schlüssel für Industrie 4.0. Standardisierte und sichere Kommunikation vom Feldgerät bis in die Cloud ist keine Vision mehr, sondern mit OPC UA umsetzbare Realität. Der Artikel soll eine Einführung in den IEC-62541-Standard OPC Unified Architecture geben.

Eine zentrale Herausforderung von Industrie 4.0 und dem industriellen Internet der Dinge (IIoT) ist der sichere, standardisierte Daten- und Informationsaustausch zwischen Geräten,Maschinen und Diensten auch aus verschiedenen Branchen. Das «Reference Architecture Model for Industry 4.0» (RAMI 4.0) hat bereits im April 2015 den IEC-62541-Standard OPC Unified Architecture (OPC UA) [I.1] als einzige Empfehlung für die Umsetzung des Kommunikationslayers gelistet. Nun gibt die Plattform Industrie 4.0 mit einer Checkliste [I.2] Auskunft, ob man sein Produkt in den Kategorien Industrie 4.0 «Basic», «Ready» oder «Full» einstufen kann: Bereits die niedrigste Stufe listet als Kriterium «I4.0-Kommunikation» die Anforderung, dass das Produkt im Netzwerk online per TCP/UDP oder IP mit mindestens dem Informationsmodell von OPC UA ansprechbar sein muss (Bild 1).

Wer also mit dem Produktstempel «Industrie-4.0-fähig» werben will, muss OPC-UA-fähig sein (integriert oder per Gateway). Explizit wird die Eigenschaft der Informationsmodellierung von OPC UA hervorgehoben (Bild 2).

Service-orientierte Architektur OPC UA

Informationsmodellierung? Viele KMUs schalten hier bereits ab – schnell wird dann OPC UA mit anderen Protokollen verglichen und vermeintliche Einschränkungen in Einsatzszenarien werden festgestellt: «OPC UA direkt in die Cloud geht nicht – oder?» Zunächst: Unbewusst liefert jeder Geräte- und Maschinenbauer bereits heute ein Informationsmodell: Daten und Schnittstellen sind ja bereits (über diverse Protokolle) verfügbar. Wir Menschen haben uns an die Denkweise der Computer angepasst und haben in Bits & Bytes & Hexcodes basierenden – hoffentlich vollständigen – Beschreibungen festgehalten, welche Bedeutung sich dahinter verbirgt. Die neue Welt der Geräte unterstützt uns Menschen, schneller und einfacher die «Things» zu verstehen, da diese nun «Dienste», aber vor allem deren Bedeutung anbieten. Gar nicht neu ist das in der IT-Welt – nun wandert aber diese Service-orientierte Architektur (SoA) bis in die Things selber vor.

Und genau da hilft OPC UA dem Framework für industrielle Interoperabilität. Geräte- und Maschinenbauer beschreiben die objektorientieren Informationen ihres Systems und definieren auch die Zugriffsrechte mit integrierter IT-Security dazu. Das deutsche BSI hat die Ergebnisse der OPC-UA-Sicherheitsanalyse [I.3] auf seinem Web veröffentlicht. Der Maschinenbauer bleibt damit Herr seiner Daten bzw. er kann sie gezielt und kontrolliert verteilen und somit auch an Big Data und der Analyse monetär teilhaben.

Um diese Daten nun auszutauschen, gibt es zwei Mechanismen:

  • ein Client-Server-Modell, in dem UA-Clients die dedizierten Dienste des UA-Servers nutzen;
  • ein Publisher-Subscriber-Modell, bei dem ein UA-Server konfigurierbare Untermengen von Informationen an eine beliebige Anzahl Zuhörer verfügbar macht.

Beide Mechanismen sind losgelöst vom eigentlichen Protokoll und daher stehen TCP und HTTPS für die Client-Server und UDP sowie AMQP und MQTT für das Subscriber-Modell zur Verfügung.

Definitiv benötigt man beide Varianten:

  • 1. den Peer-to-peer-Kontext für den sicheren, bestätigten Transport – aber mit Einschränkungen
  • in der Anzahl der Verbindungen;
  • 2. die Broadcast-Verteilung an alle unter dem Aspekt «Fire and forget».

OPC UA vereinigt Beides. Die Frage «OPC UA oder AMQP oder MQTT» stellt sich somit aus OPCFoundation-Sicht nicht – auch OPC UA kann das liefern. Ein Ressource-eingeschränktes Gerät mit «nur-MQTT» sollte aber seine Daten im «OPC UA viaMQTT»-Informationsmodell-Format abfeuern.

„Praxishandbuch OPC UA“ Mit diesem Fachbuch gibt das Autorenteam rund um Dr. Miriam Schleipen neben einem grundlegenden Überblick über den Kommunikationsstandard OPC UA auch eine Übersicht, welche Tools bei der Umsetzung helfen. Das "Praxishandbuch OPC UA. Grundlagen – Implementierung – Nachrüstung – Praxisbeispiele" bereitet Sie auf die zukunftsträchtige Technologie mit Uses Cases, Lessons leraned und Best Practises vor. Das Fachbuch „OPC UA“ kann hier versandkostenfrei oder als eBook bestellt werden.

Welche Daten und Dienste liefert ein Gerät oder eine Maschine?

Transport, Security, Zugriffsrechte

Von «außen» betrachtet soll aus der Kommunikationssicht der Zugriff auf Daten und Dienste der Maschine zunächst vollkommen sicher im Sinne der IT-Sicherheit definiert sein. OPC UA bietet hier nicht nur die gängigen IT-Mechanismen zur Authentifizierung, Signierung und Verschlüsselung im Zugriff. Zusätzlich bleibt der Maschinenbauer der «Herr seiner Daten», da er die Sichtbarkeit und Zugriffsrechte auf jedes einzelne Datum und jedem Dienst entsprechende Rollen konfigurieren kann.

Die eigentliche Transportschicht kann in Zukunft jederzeit durch weitere Protokolle erweitert werden. Die Unabhängigkeit vom physikalischen Transportmedium und dem Transportprotokoll ist ein ganz entscheidender Vorteil von OPC UA gegenüber anderen, reinen IoT-Datenprotokollen. Der Geräte- bzw. Maschinenbauer muss sich nicht darum kümmern, sondern nur die Daten und Dienste gesichert bereitstellen.

Modellierung

Maschinen müssen ihre Daten und Dienste maschinenlesbar anbieten, wenn Maschinen und Dienste miteinander sprechen sollen und auch das Engineering durch den Menschen möglichst einfach vonstattengehen soll: z.B. «Ich bin eine Verpackungsmaschine mit den Diensten xyz» oder «Ich bin ein RFID-Reader». Die semantische Festlegung der Schnittstellen kann von den entsprechenden Fachverbänden mit OPC UA modelliert werden. Als Beispiel haben die Unternehmen

Harting und Siemens dies für die AutoID-Industrie vorangetrieben und in kurzer Zeit die Spezifikation der Schnittstelle, aber auch die Umsetzung realisiert: RFID-Reader mit integriertem OPC UA mit Unterstützung der AutoID Companion Spec sind lieferbar ab Lager. OPC UA Clients, verfügbar als PLCopen-Bausteine in einer SPS-Steuerung oder einer Visualisierung oder aus der Cloud, können nun mit extrem einfachem Engineering den identischen Zugriff auf die Geräte beider Hersteller umsetzen.

IoT-Basics: Selbstbeschreibung von Maschinen und Anlagen

Vernetzte Produktion

IoT-Basics: Selbstbeschreibung von Maschinen und Anlagen

30.01.18 - Parallel zur Fertigungswelt entstehen derzeit IIoT-Plattformen. Viele leiden aber daran, dass der Zugang zu Maschinendaten schwierig ist. Die Vernetzung in der Industrie 4.0 erfordert nämlich, dass Maschinen und ihre Komponenten als Datenquellen eine maschinenlesbare Selbstbeschreibung mitbringen. lesen

Keine Differenzierung mit OPC UA?

Wenn RFID-Reader unterschiedlicher Hersteller ein identisches Interface bieten – bleibt dann die Differenzierung der Geräte nicht auf der Strecke? Die Antwort lautet: Nein. Denn neben dem standardisierten Informationsmodell kann jeder Gerätehersteller seine eigenen Modelle quasi als «Extra» parallel anbieten. Diese Kombination aus genormtem «Geräte-Standard» und der «Geräte-Individualität» ist sinnvoll und ideal geeignet, um miteinander konkurrierenden Geräteherstellern

die Chance zu geben, sich zu einigen, aber trotzdem ihren Mehrwert nach außen abgreifbar zur Verfügung zu stellen. Wichtig bleibt aber: Auf alle Schnittstellen – die standardisierten und die herstellerspezifischen – greift ein OPC UA Client mit dem gleichen Mechanismus zu.

Diese Schicht der Modellierung der Daten und Dienste ist der eigentliche Schlüssel für Industrie 4.0 und der wesentliche Unterschied zum «Nur IoT-Daten pushen» in die Cloud: Erkannt haben das diverse Organisationen und haben so ihre marktspezifischen Informationsmodelle mit OPC UA modelliert – eine Übersicht findet man im Web der OPC Foundation [I.4].

Dienste

Unabhängig von der Bestimmung des Gerätes oder der Maschine sind bestimmte Dienste immer vorhanden; nur einige sollen hier vorgestellt werden:

  • Datendienste liefern heute an Visualisierungen die benötigen «Live-Daten» (die IT-Welt spricht hier von Realtime-Daten – nicht zu verwechseln mit deterministischen Daten aus der harten Echtzeit) der Maschine. Auch historische Daten aus der Vergangenheit oder Alarme, wenn bestimmte Wertlevel über- oder unterschritten werden, gehören in diese Kategorie der Dienste.
  • Administration-Dienste wirken eher auf die Funktionalität der Geräte: Eine SPS-Steuerung kann darüber definiert zwischen «Stopp»- und «Start»-Zustand geschaltet werden (dieser Dienst wurde z.B. von der PLCopen & OPCF-Arbeitsgruppe definiert), um z.B. neue Logik-Ablaufprogramme per OPC-UA-Filetransfer in die Steuerung zu transferieren. Eine Verteilung einer überarbeiteten SPS-Logik in viele weltweit verteilte Anwendungen wie Windturbinen ist damit einfach und vor allem sicher realisierbar. Das Senden und Laden von Dateien dient auch dezentralen SmartMeter-Anwendungen.
  • Monitoring-Dienste können zu jedem Zeitpunkt Informationen über das Gerät selber liefern, wie z.B. die Temperatur der CPU oder deren Auslastung, die Lüfterdrehzahl usw.
  • Applikationsdienste bzw. Maschinendienste: Der Geräte- bzw. Maschinenbauer kann hier einfach seine eigenen Dienste nach außen definieren – in verketteten Maschinen in der Holzbranche z.B. «Auslesen Vorschubgeschwindigkeit» oder «Betriebsbereitschaft» ebenso wie in ganz anderen Branchen wie einer intelligenten Kamera «Bild aufnehmen und auswerten».

Betriebssystem und Realtime

Welches Betriebssystem in einer Maschine werkelt oder ob gegebenenfalls eine spezielle Echtzeitrealisierung implementiert ist, spielt keine Rolle aus Sicht einer externen Geräte- und Maschinenkommunikation: Nichts ist davon nach außen – in einem «Industrie-4.0-kompatiblen Gerät» – sichtbar. Die Auswahl eines Betriebssystems, z.B. eines Steuerungsherstellers, unterliegt anderen Kriterien und bietet die eigentliche Basis für die Differenzierung der Maschinenfunktionalität:

Lange Supportverfügbarkeit, Freistellung von IP-Policies, eine exzellente Software-Toolkette für einfaches Engineering, skalierbarer Einsatz vom kleinsten Embedded-System bis in Many-Multi-Core-Systeme sind z.B. Faktoren, die den einen Steuerungshersteller vom anderen unterscheiden.

Skalierbarkeit

OPC UA ist skalierbar von kleinen Geräten bis in die IT-Ebene. Bereits im Jahr 2012 hat das Fraunhofer-Institut Lemgo einen OPC-UA-Server auf einen 10-kB-Footprint abgespeckt, um ihn in kleinsten Sensoren auf Chips zu integrieren.

Die Firma Areva hat einen OPC-UA-Server in den Sensor von Überwachungsgeräten für Armaturen und deren elektrische Antriebe integriert (Bild 2.3). Diese Lösung wird in der Nuklearbranche zur Überwachung kritischer Systeme in entfernten Umgebungen eingesetzt. Neben der Zuverlässigkeit der Daten ist daher auch die integrierte Sicherheit ein wesentlicher Aspekt. Der OPC-UA-Server benötigt hier eine Speicherauslastung beginnend bei 240 kByte Flash und 35 kByte RAM.

Adaptierung

Als «Early Adapter» haben Beckhoff und Siemens den OPC-UA-Standard bereits im Jahr 2008 unterstützt, in Geräte integriert und ab Lager verkauft. Heute unterstützen nahezu alle SPS-, Visualisierungs- und MES-Hersteller diesen Standard. Die Anbindung einer neuen Produktionsmaschine dauert somit nicht mehr Tage – mit erheblichem Integrations- und Testaufwand –, sondern ist in weniger als einer Stunde umsetzbar. OPC UA wächst sowohl in kleinste Geräte, aber auch in die Cloud weiter.

Seit Mai 2015 sind die OPC-UA-Spezifikationen öffentlich verfügbar und die OPC-Foundation hat die Öffnung von Stacks als OpenSource für Evaluierungszwecke Im Jahr 2016 umgesetzt. Für die professionelle OPC-UA-Integration in industrielle Produkte bieten Firmen Toolkits und Beratung an.

Praktische Anwendungen von OPC UA

Anwendung vertikal: Energie-Monitoring und Big Data

Mit Energie-Monitoring in dezentralen Liegenschaften sind Betreiber in der Lage, sämtliche Anforderungen zur optimierten, energetischen Betriebsführung umzusetzen. Als Beispiel werden in Städten wie Aachen mit deren Gebäudemanagement bis zu 2000 Liegenschaften und mehr verwaltet. Das Energie-Monitoring-System e2watch der regio iT gesellschaft für informationstechnologie mbh wurde in Kooperation mit dem Gebäudemanagement der Stadt Aachen entwickelt [I.7].

Als dezentrales Gerät wurde eine Embedded-Kleinststeuerung verwendet, die die Messdaten sammelt, zunächst lokal puffert und zu frei konfigurierbaren Zeitpunkten mit der Cloud synchronisiert (Bild 6). Als Transportweg wird OPC UA als IT-Standard mit integrierter Security genutzt. Die Steuerung pusht dabei als OPC UA Client die Daten als «Historic Access»-Daten direkt in die «Big-Data-Managementlösung» in der Cloud. Dort findet eine weitere Analyse bzw. Auswertung der Daten statt, auf die Betreiber und Nutzer der Liegenschaften mit einer internetbasierten Visualisierung zugreifen können.

Ein weiterer Nutzen besteht darin, dass Kennwertvergleiche und Benchmarking zwischen gleichwertigen Liegenschaften vorgenommen werden können, um ein Energie-Verbrauchscontrolling durchzuführen. Durch den Zugang zu den ausgewerteten Daten wird auch eine positive Beeinflussung des Nutzerverhaltens erwartet.

Das adressierbare Kundenpotenzial dieser Lösung ist auf viele Branchen übertragbar: Daten sammeln, puffern und weiterleiten sind verbreitete Aufgaben.

Anwendung horizontal: M2M in der Wasserwirtschaft

Der Zweckverband Wasser und Abwasser Vogtland bestätigt die finanziellen Einsparpotenziale als wesentliches Resultat einer kompletten Kommunikationsarchitektur, basierend auf OPC UA. Für die wasser- und abwassertechnische Versorgung (Wasserversorgung von 40 Städten und Gemeinden, Abwasserentsorgung in 37 Städten und Gemeinden mit zusammen 240 000 Einwohnern) sind mehr als 550 Anlagen auf einer Fläche von 1400 km² verteilt.

Die Zahl der Anlagen umfasst Wasserwerke, Pumpanlagen, Hochbehälter, Kläranlagen und Kanal-Entlastungsbauwerke. In der Vergangenheit wurden Informationen nur zentral in der Leitwarte gesammelt, um dort teilweise kostenintensive Serviceeinsätze zu koordinieren. Spezielle Anforderungen, wie die Pufferung von Prozessdaten bei Ausfall des Kommunikationstransportes und der Einsatz vieler verschiedener Protokolle mit unterschiedlichen Konfigurationen, haben über Jahre zu einem hohen Pflegeaufwand und entsprechenden Kosten geführt.

Durch die Abschaffung der proprietären Kommunikationsprotokolle und die Installation einer dezentralen, vernetzten Intelligenz wurden der Engineering- und Serviceaufwand reduziert und damit die Kosten gesenkt – und dies bei gleichzeitiger Erhöhung der IT-Sicherheit und Verfügbarkeit der Daten. Unter Nutzung von

OPC UA für die direkte M2M-Kommunikation sollten alle Geräte der dezentralen Liegenschaften autark agieren, die kleinsten Embedded-Steuerungen untereinander intelligent vernetzt sein und direkt miteinander kommunizieren. Damit stellt diese Anwendung eine erste reale Umsetzung der Ergebnisse der Zusammenarbeit der PLCopen- und der OPC-Arbeitsgruppe dar: Reale Objekte (z.B. eine Pumpe) wurden in der IEC-61131-3-SPS-Steuerung als komplexes Objekt mit Interaktionsmöglichkeiten modelliert. Durch den in die Steuerung integrierten OPC-UA-Server standen diese Objekte automatisch für semantische Interoperabilität als komplexe Datenstruktur der Außenwelt zur Verfügung.

Das Ergebnis ist eine dezentrale Intelligenz (Bild 7), die eigenständig Entscheidungen trifft und Informationen an ihre Nachbarn übermittelt bzw. Stati und Prozesswerte für den eigenen Prozess abfragt, um einen ungestörten Prozessablauf zu gewährleisten. Die Geräte «reden» hier direkt miteinander: Z.B. meldet das Wasserwerk 1 eine abnehmende Wasserqualität (verursacht z.B. durch das Düngen von Feldern) an die eigene Pumpe. Diese kann nun den Job «Hochbehälter füllen» an ein anderes Pumpwerk delegieren. Mit den standardisierten FUNCTIONBLOCKS der PLCopen initiieren die Geräte, als UA Clients, eigenständig die Kommunikation aus der SPS heraus zu anderen Prozessteilnehmern.

Als UA-Server antworten sie gleichzeitig auf deren Anfragen bzw. auf Anfragen übergeordneter Systeme (SCADA, MES, ERP). Die Geräte sind per Mobilfunkrouter verbunden. Eine physikalische Verbindungsunterbrechung führt dabei nicht zu einem Informationsverlust, da Informationen automatisch im UA-Server für eine Zeit gepuffert werden und abrufbar sind, sobald die Verbindung wiederhergestellt wurde. Dies ist eine sehr wichtige Eigenschaft, für die früher ein hoher, proprietärer Engineering-Aufwand betrieben werden musste.

Für die Integrität dieser zum Teil sensiblen Kommunikation wurden, neben einer geschlossenen Mobilfunkgruppe, auch die in OPC UA integrierten Sicherheitsmechanismen, wie Authentifizierung, Signierung und Verschlüsselung, genutzt. Der herstellerunabhängige Interoperabilitätsstandard OPC UA eröffnete dem Endanwender die Möglichkeit, die Auswahl einer Zielplattform der geforderten Technologie unterzuordnen, um so den Einsatz proprietärer bzw. nicht anforderungsgerechter Produkte zu umgehen. Der Ersatz einer proprietären Lösung durch eine kombinierte OPC-UA-Client/Server-Lösung erbrachte hier eine Einsparung der Lizenz-Initialkosten von mehr als 90 Prozent je Gerät.

Anwendung vertikal: IoT-Plattform

Microsoft hat die Bedeutung von OPC UA im Kontext von Industrie 4.0 frühzeitig erkannt und OPC UA in die Azure Cloud integriert (Bild 9). Neue OPC-UA-Server (1), die die Pub/Sub-Funktionalität unterstützen, können bereits direkt Telemetrie-Daten per JSON/AMQP in die Azure Cloud spielen. Für die OPC-UA-Server mit Client-Server(TCP)-Kanal steht ein Gateway (2) zur Verfügung – hier werden die UA-Daten als UA via AMQP gewandelt weitergeleitet. Auch der Rückkanal «Control & Command» (3) ist konfigurierbar.

Roadmap und Ausblick auf Weiterentwicklungen

OPC UA entwickelt sich weiter. Aktuell lassen sich die im Folgenden beschriebenen Trends vorhersehen.

Trend: Informationsmodelle

Andere Verbände wie die AutoID-Industrie (RFID Reader, Scanner, …), VDMA-Fachgruppen wie Spritzgussmaschinen, Robotik oder Machine Vision (und 35 weitere Automatisierungsbranchen) definieren bereits ihre Informationen in OPC-UA-Servern – einer sogenannten OPC UA Companion Specification. Als Anbieter einen solchen Branchenstandard zu erfüllen bedeutet nicht gleich austauschbar zu sein: Jeder kann seine eigenen Hersteller-speziellen Dienste weiterhin parallel anbieten.

Intelligente Geräte sollten unbedingt parallel mehrere Informationsmodelle unterstützen können: neben der dedizierten Funktionalität eben auch die für Energiedaten oder MES-Schnittstellen usw. Zur Reduzierung des Engineerings wird die Bedeutung dieser Branchen- und Cross-Branchen- Informationsmodelle in Zukunft stark steigen: Hersteller, die hier nicht den Standard unterstützen, werden bald nicht mehr verkaufen können.

Trend: Service-orientierte Architektur (SoA)

Die Informationsmodelle der Branchen basieren meistens nicht mehr auf dem Bit/Byte-Property-Austausch, sondern auf den Diensten mit komplexen Parametern. Ein UA Client, der keine Methoden oder komplexen Parameter unterstützt, wird mit UA-Servern zunehmend wenig kommunizieren können. Die DKE-Organisation listet OPC UA als einzige SoA-Lösung. Unabhängig von SoA: Die Automatisierungspyramide zur Organisation einer Fabrik bleibt sicherlich weiterhin bestehen – die Kommunikationspyramide ist mit OPC UA aber aufgehoben: Geräte können Daten direkt oder parallel an das MES (Manufacturing Execution System) oder die ERP-Ebene (ERP = Enterprise Resource Planning) liefern – auch die Logik muss nicht immer in der SPS vor Ort laufen, sondern kann (heute für unkritische Abläufe) in der Cloud laufen.

Trend: OPC UA im Chip

OPC UA wird in immer kleinere Geräte und Sensoren «wachsen». Kleinste OPC-UA-Softwarelösungen benötigen heute mit limitierter (aber auslesbarer) Funktionalität 35 kB RAM und 240 kB Flash. Die ersten Chips mit integriertem OPC UA sind am Markt verfügbar, und so wächst OPC UA weiter in die Sensorwelt hinein. Schon jetzt wachsen die Anwendungen von OPC UA aus dem Kernbereich der Automatisierung in andere Branchen wie industrielle Großküchengeräte.

Trend: OPC UA mit TSN

Der Roboterhersteller KUKA ist 2015 der OPC-Foundation beigetreten, um diesen Standard aktiv mitgestalten zu können: Aus Sicht von KUKA muss auch eine schnellere, echtzeitfähige Kommunikation per OPC UA machbar sein, um mit einer einzigen Kommunikationslösung komplett zu skalieren: von der horizontalen Robotersteuerung zur Roboterhandsteuerung, aber auch bis in die MES- und IT-Ebene. Hier zeigt sich ein weiterer wesentlicher Vorteil: OPC UA ist eben nicht «nur Protokoll», sondern eine Architektur, die sich auf die Anforderungen des Marktes erweitern lässt: Die Anforderung nach harter Echtzeit mit der Kombination Time Sensitive Network (TSN) und OPC UA ist in einer Arbeitsgruppe bereits gestartet, die Umsetzung und Markteinführung wird allerdings noch Zeit benötigen.

Literatur

[I.1] Normenreihe: IEC 62 541 OPC unified architecture. Genf: International Electrotechnical Commission (IEC), 2015-2016

[I.2] Leitfaden: Welche Kriterien müssen Industrie-4.0-Produkte erfüllen? Frankfurt am Main: ZVEI e.V., November 2016

[I.3] Sicherheitsanalyse OPC UA. Bonn: Bundesamt für Sicherheit in der Informationstechnik (BSI), April 2016

[I.4] OPC Unified Architecture: Interoperabilität für Industrie 4.0 und das Internet der Dinge. OPC Foundation Europe 2015

[I.5] Products and Services. Erlangen: AREVA GmbH

[I.6] Hoppe, Stefan: OPC Unified Architecture as a Standard Integration Platform for the (Real-Time) Enterprise. August 2015

[I.7] e2watch: Energiekosten und Umwelt – alles im grünen Bereich. Aachen: regio iT gesellschaft für Informationstechnologie mbh

[I.8] Merz, Silvio: Intelligente Wasserwirtschaft – Interaktion von Geräten. Plauen: Zweckverband Wasser und Abwasser Vogtland 2015

Über den Autor

Dipl.-Ing. Stefan Hoppe studierte Elektrotechnik an der Technischen Universität Dortmund. 1995 startete er bei Beckhoff Automation GmbH zunächst als Softwareentwickler und später als Senior-Produkt-Manager für die Automatisierungssoftware TwinCAT. Seit 2009 wurde er von Microsoft jährlich neu mit dem MVP (Most Valuable Professional) Award für Embedded Software ausgezeichnet. Seit 2010 war er als Präsident von OPC Europe innerhalb der OPC Foundation tätig. Im Jahr 2014 wurde er zum Vorstandsmitglied und 2017 zum Vizepräsidenten der OPC Foundation berufen.

Dieser Beitrag stammt aus den dem Fachbuch „Industrie 4.0: Potenziale erkennen und umsetzen“ von Thomas Schulz (Hrsg.) Das Buch bietet dem Professional einen praxisorientierten und umfassenden Einblick in die Digitalisierung der Fertigung und der Produktion. Das Buch „Industrie 4.0“ kann hier versandkostenfrei oder als eBook bestellt werden.

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45368314 / Technologie)