Die Hierarchie der klassischen Automatisierungspyramide wird sich in Zukunft durch die Integration von OPC UA in allen Ebenen in ein Netzwerk von Automatisierungsdiensten wandeln, das heißt Geräte und Dienste reden direkt miteinander.

Die Hierarchie der klassischen Automatisierungspyramide wird sich in Zukunft durch die Integration von OPC UA in allen Ebenen in ein Netzwerk von Automatisierungsdiensten wandeln, das heißt Geräte und Dienste reden direkt miteinander.Beckhoff

Bei einer schnellen, individualisierten Produktion (Industrie 4.0) müssen Geräte und Dienste wie Sensoren, Messgeräte, RFID-Chips, Steuerungen, HMI, MES- und ERP-Systeme direkt miteinander kommunizieren können: Sie liefern wichtige Produktionsdaten. In klassischen Steuerungsarchitekturen sind die einzelnen Datenanfragen entweder zyklisch oder ereignisgesteuert initiiert und erfolgen immer nur auf Anfrage von oben, das heißt von der Client-Ebene. Die untere Schicht fungiert immer als Server. Nach diesem Prinzip lässt sich beispielsweise eine Visualisierung (Client) von der SPS (Server) die Statusdaten übermitteln. Zunächst werden aus den Sensorsignalen digitale Informationen erstellt – diese bekommen in der SPS einen Zeitstempel und werden über weitere Dienste dann in die MES-IT-Ebene weitergeleitet. Das Kommunikationsmodell bei Industrie 4.0 wird diese strikte Trennung der Ebenen und den Top-Down-Ansatz des Informationsflusses aufweichen und vermischen. Denn jedes Gerät oder jeder Dienst muss eigenständig eine Kommunikation zu anderen Diensten initiieren können.

Aus den beiden Kontexten IT und Automation ergeben sich – unabhängig von harter oder weicher Echtzeit – insgesamt drei potenzielle Kommunikationsübergänge: B2B, B2M und M2M.

Aus den beiden Kontexten IT und Automation ergeben sich – unabhängig von harter oder weicher Echtzeit – insgesamt drei potenzielle Kommunikationsübergänge: B2B, B2M und M2M.Beckhoff

Harte oder weiche Echtzeit – der Kontext entscheidet

Generell können alle Kommunikationsszenarien und Use-Cases, die in den verschiedenen Industrie-4.0- und Internet-of-Things(IoT)-Gruppen definiert wurden, in zwei Kontexte der Kommunikationsarchitektur abstrahiert werden: in Dienste in harter Echtzeit (Automatisierungskontext), zum Beispiel die deterministische SPS zur Regelung, und in Dienste mit weichen Echtzeitanforderungen (IT-Kontext). Hieraus ergeben sich genau drei potenzielle Kommunikationsübergänge, die von der Arbeitsgruppe 2 (Referenzarchitektur, Standardisierung und Normung) der Plattform Industrie 4.0 definiert wurden: B2B-Kommunikation, B2M-Kommunikation und M2M-Kommunikation.

Bei B2B kommunizieren zwei Business-Prozesse miteinander. Beispiel: Eine ERP-Anwendung tauscht mit einer MES-Anwendung Informationen aus. In diese Kategorie fällt auch der Datenaustausch zwischen HMI und MES, von MES zu MES oder von Sensor und Cloud. Die Dauer kann wenige Millisekunden bis zum hohen Minutenbereich betragen.

B2M bedeutet, dass ein Prozess mit weicher Echtzeit mit einem Prozess der Kategorie harte Echtzeit kommuniziert. Beispiel: Eine Business-Anwendung tauscht mit einer Maschine Informationen aus. Die Übertragung, zum Beispiel von Livedaten zwischen HMI und SPS oder MES und SPS, kann von wenigen Millisekunden bis zu Minuten betragen.

M2M-Kommunikation: Zwei Prozesse der Kategorie Automation kommunizieren miteinander in harter oder weicher Echtzeit. Beispiel: Eine Roboter-Plattformsteuerung tauscht mit der Hand-Steuerung des Roboters Regelungsinformationen aus. Der Austausch muss im Mikrosekunden- oder niedrigen Millisekundenbereich in einem harten, deterministischen Echtzeittakt abgewickelt werden. Beispiel 2: Zwei Steuerungen tauschen horizontal Daten aus, schnell (weiche Echtzeit), zyklisch und feldbusunabhängig.

Determinismus ist lediglich eine Art Quality of Service (QoS), über den eine Kommunikationsart verfügen kann oder nicht; notwendig ist dazu die Angabe der zu garantierenden Zeitdauer, zum Beispiel 100 µs.

Die PLCopen/OPC-UA-Client-Bausteine ermöglichen eine feldbusunabhängige, schnelle Kommunikation. Die Twincat SPS mit integriertem OPC-UA-Client initiiert die Datenkommunikation.

Die PLCopen/OPC-UA-Client-Bausteine ermöglichen eine feldbusunabhängige, schnelle Kommunikation. Die Twincat SPS mit integriertem OPC-UA-Client initiiert die Datenkommunikation.Beckhoff

M2M – eine neue Definition

Den Begriff M2M haben Mobilfunkanbieter bereits geprägt: M2M steht für die Anbindung von Geräten per Mobilfunk an IT-Prozesse. Weit verbreitet ist die Auffassung, dass M2M immer dann gegeben ist, wenn eine SIM-Karte zum Einsatz kommt – bislang jedenfalls.

Wie auch immer die drei Kommunikationskategorien final mit Namen belegt werden: Die Kommunikation bei IoT und Industrie 4.0 basiert nicht mehr auf reinen Daten und der Interoperabilität der Datenkommunikation, sondern auf dem Austausch von Informationsmodellen und somit der semantischen Interoperabilität. Höchste Bedeutung wird auch die Übertragungssicherheit und die Sicherheit der Zugriffsrechte auf einzelne Daten oder Dienste haben.

Beide Aufgabenstellungen – Informationsmodelle und Security – sind Kernpunkte der OPC Unified Architecture (OPC UA). Sie enthält eine Beschreibungssprache und die Kommunikationsdienste für Informationsmodelle. Als IEC-Norm 62541 ist OPC UA dafür ausgelegt, die Informationsmodelle von anderen Organisationen abzubilden, beispielsweise von Bacnet, PLCopen, IEC 61850, AIM AutoID oder MES-Dach. Die in OPC UA integrierte Security ist laut dem Bundesamt für Sicherheit in der Informationstechnik (BSI) deutlich besser als bei anderen Protokollen und wird daher aufgrund der hohen Relevanz für Industrie 4.0 aktuell in einem Projekt evaluiert.

Durch die standardisierte Zusammenführung von Daten sowie deren Struktur und Bedeutung (Metadaten) eignet sich OPC UA insbesondere für verteilte, intelligente Anwendungen zwischen Maschinen. Der Grund: Eine übergeordnete Intelligenz mit einem zentralen Wissen über alle Teilnehmer entfällt. Die Funktionalität von OPC UA ist skalierbar und bereits heute in Komponenten auf der Sensorebene (beginnend bei 240 kB Flash und 35 kB RAM) bis zum SAP-System vorhanden.

Wandlungsfähig: Die SPS wird zum Client

Damit eine SPS eine Kommunikation initiieren kann, muss eine Client-Komponente in den Controllern vorhanden sein – idealerweise als standardisierte Schnittstelle. Auf die Initiative von Beckhoff, PLCopen-Kommunikationsbausteine auf Basis der OPC UA zu definieren, wurde eine gemeinsame Arbeitsgruppe gegründet, die zunächst das Mapping des IEC-61131-3-Informationsmodells in OPC UA (Server) als gemeinsame Spezifikation festlegte. Das bedeutet konkret: Ein einziges IEC-61131-3-konformes SPS-Programm kann unverändert mit den jeweils unterschiedlichen, proprietären Engineering-Tools verschiedener Hersteller auf deren SPS geladen werden. Die Steuerungen stellen ihre Daten und Informationen semantisch identisch per OPC UA zur Verfügung, zum Beispiel für Visualisierungs- und MES/ERP-Aufgaben. Dies erleichtert den Engineering-Aufwand ungemein: Anstatt für eine Instanz eines Funktionsbausteins jeden einzelnen Datenpunkt mit ihrer Entsprechung in einer Visualisierungsmaske oder einem MES-System zu verknüpfen, reicht es nun aus, ein einziges Instanz-Objekt zu verbinden – das zudem bei verschiedenen Herstellern identisch ist. Als nächster Schritt wurde die PLCopen-Spezifikation ‚OPC-UA-Client-Funktionsbausteine für IEC 61131-3‘ erarbeitet und im April 2014 freigegeben. Damit kann die Steuerung – zusätzlich oder alternativ zur bisherigen Rollenverteilung – auch den aktiven, führenden Part der Kommunikation übernehmen.

Blockdiagramm für den Methoden-Aufruf

Blockdiagramm für den Methoden-AufrufBeckhoff

Die SPS kann somit komplexe Datenstrukturen mit anderen Controllern (horizontal) austauschen. Ebenso kann die Steuerung vertikal Methoden im OPC-UA-Server eines MES/ERP-Systems aufrufen, um sich zum Beispiel neue Produktionsaufträge abzuholen oder Daten in die Cloud zu schreiben. Kurzum: Diese Spezifikation ermöglicht es der Produktionslinie, selbständig aktiv zu werden.

SOA-SPS in der Praxis

Erste Anwender haben frühzeitig das Potenzial dieser Bausteine erkannt und von der Implementierung durch Beckhoff profitiert: Der Zweckverband Wasser und Abwasser Vogtland hat für den Bereich Wasserwirtschaft 300 dezentrale Anlagen mit Embedded-Steuerungen (CX9020) intelligent vernetzt: Reale Objekte, wie eine Pumpe, wurden in der IEC-61131-3-Steuerung als komplexes Objekt mit Interaktionsmöglichkeiten modelliert. Durch den in die Steuerung integrierten OPC-UA-Server stehen diese Objekte automatisch der Außenwelt zur Verfügung und ermöglichen eine semantische Interoperabilität – trotz der komplexen Datenstruktur. Das Ergebnis ist eine dezentrale Intelligenz, die eigenständig Entscheidungen trifft, Informationen an ihre Nachbarn übermittelt und Stati und Prozesswerte für den eigenen Prozess abfragt. Mit den standardisierten Funktionsbausteinen der PLCopen initiieren die Geräte als OPC-UA-Client eigenständig die Kommunikation aus der SPS heraus zu anderen Prozessteilnehmern, während sie gleichzeitig als OPC-UA-Server auf deren Anfragen oder auf Anfragen übergeordneter Systeme (Scada, MES, ERP) reagieren können. (siehe auch Artikel „OPC Unified Architecture im Einsatz“).

SPS-Hersteller haben mit dem Mapping der IEC 61131-3 in den OPC-UA-Server und den PLCopen-Bausteinen bereits ein wichtiges Fundament gelegt: Aus der SPS heraus OPC-UA-Dienste in anderen Geräten aufzurufen, ermöglicht B2M-Szenarien. So kann die Steuerung etwa einen Dienst in einer Vision/Kamera-Applikation oder einem RFID-Reader aufrufen oder die Daten einer Big-Data-Applikation in einer Cloud melden.

Methoden in der IEC-61131-3-SPS können einfach nach außen freigegeben werden.

Methoden in der IEC-61131-3-SPS können einfach nach außen freigegeben werden.
Beckhoff

Die SPS kann zwar Methoden aufrufen; wie aber kann sie selbst Dienste anbieten – und das vor allem einfach anwendbar? Twincat 3 bietet die Möglichkeit, IEC 61131-3-, C++- und Matlab/Simulink-Module zu implementieren, diese auf verschiedene CPU-Cores zu laden, in unterschiedlicher Echtzeit ablaufen und trotzdem sicher miteinander interagieren zu lassen. Grundlage hierfür ist die Twincat-Modulsprache, welche die Eigenschaften der Module, unter anderem bezüglich ihrer Prozessparameter oder Methoden, beschreibt.

Die Realisierung ist daher für SPS-Programmierer denkbar einfach: Durch das Hinzufügen einer simplen ‚Pragma‘-Anweisungszeile steht eine Methode der SPS (mit beliebigen Ein-/Ausgangsparametern) zusätzlich auch als Serviceaufruf im OPC-UA-Server der SPS zur Verfügung. Jeder OPC-UA-Client kann mit der im OPC UA integrierten IT-Security und Zugriffsberechtigung den Twincat-OPC-UA-Server browsen und den entsprechenden Dienst aufrufen – und zwar unabhängig vom Betriebssystem, der Programmiersprache und unter Wahrung der Datenkonsistenz.

Methoden-Aufrufe aus dem MES/ERP in die SPS erhöhen die Performance der bisherigen zeitaufwendigen Daten-Handshake-Mechanismen.

Methoden-Aufrufe aus dem MES/ERP in die SPS erhöhen die Performance der bisherigen zeitaufwendigen Daten-Handshake-Mechanismen.Beckhoff

Datenkonsistente Dienste aus der SOA-SPS

Der Datenaustausch zwischen MES-Ebene und SPS erfolgt heute in der Regel über zeitaufwendige Handshakes: Das MES-System signalisiert der Steuerung, dass sie ein Rezept übergeben will. Die SPS quittiert die Bereitschaft. Dann beginnt die Übertragung. Nach der Übergabe der Rezeptdaten erfolgt die Quittierung über den erfolgreichen Abschluss der Übertragung.

Bei einer SOA-SPS lässt sich der Austausch dagegen mit einer einzigen Kommunikation erledigen: Es werden nicht vielfach Datenwerte ausgetauscht, sondern ein einziger Dienst mit Eingangsparametern (dem Rezept) und Ausgangsparametern (Quittierung der SPS) abgewickelt. Das heißt, via OPC UA wird der Remote Procedure Call (RPC) bis in den programmierten SPS-Funktionsbaustein zur Verfügung gestellt. Dies verkürzt die Kommunikations-Roundtrip-Zeiten zwischen SPS- und MES-Systemen deutlich und kann somit den Produktionsdurchsatz erhöhen. Definitiv wird es aber die Engineering-Kosten für die Datenkopplung vom Shop-Floor zum Top-Floor drastisch reduzieren.

Kommunikation ohne Grenzen

Eine SOA-SPS bedeutet mehr als nur einen per VPN gesicherten Webservice bis in die SPS anzubieten: Sie umfasst objekt-orientierte Datenkommunikation für Live- und historische Daten, Alarme, aber auch Dienste (Methoden), inklusive der zugehörigen Metadaten und der notwendigen Security bis in die Dienste- und Datenebene. Hinzu kommen die Modellierungsmöglichkeiten von Informationsmodellen. All das auf Basis einer IEC-Norm.

Die Integration von OPC-UA-Server und -Client in die Steuerung ermöglicht bereits heute die Realisierung intelligenter Netzwerke, basierend auf einem hohen Security-Standard mit Zugriffsrechten bis auf Dienste-Ebene. Das in einer Embedded-Steuerung eingesetzte Betriebssystem wird in Zukunft von außen nicht mehr sichtbar sein: Aus Security-Gründen sind alle Ports geschlossen. Stattdessen bietet das Gerät seine SOA-Dienste ausschließlich über OPC UA mit Security bis in die Dienste- und Datenebene an. Neben Daten und Methodenaufrufen bietet der Filetransfer via OPC UA eine interessante Variante nicht nur für dezentrale Offline-Messdatenaufzeichnungen, sondern auch für andere Aufgaben wie Device-Management.

In Zukunft wird der Austausch von Informationsmodellen wichtiger: Eine SPS sollte sich dann nicht mehr nur als IEC 61131-3 Controller per OPC UA mit Prozessdaten bei Anfragen melden, sondern – gemäß einer Vorgabe der Organisation der Messgerätehersteller – als Strommessgerät.

Als einzige SOA-Architektur auf der Normungs-Roadmap Industrie 4.0 der Deutschen Kommission Elektrotechnik Elektronik Informationstechnik stehend, hat OPC UA das Potenzial, sich als De-facto-Standard für den Daten- und Informationsaustausch für Anwendungen gemäß Industrie 4.0 und IoT zu etablieren. Eine sichere, horizontale und vertikale Kommunikation vom Sensor bis in die IT-Systeme ist damit bereits umsetzbar. Beckhoff hat das Potenzial früh erkannt und bietet die SOA-SPS mit integriertem OPC-UA-Client und -Server bis in kleinste CX-Embedded-Systeme. Die auf vielfältigen Geräteklassen lauffähige, PC-basierende Steuerungsarchitektur Twincat stellt, in Kombination mit der Vielfalt an I/O-Klemmen sowie der Performance von Ethercat mit Safety, eine skalierbare Plattform für alle künftigen Anforderungen zur Verfügung.