TwinCAT 3 SOA-SPS

Die Hierarchie der klassischen Automatisierungspyramide wird sich in Zukunft durch die Integration von OPC-UA in allen Ebenen in ein Netzwerk von Automatisierungsdiensten wandeln, d. h. Geräte und Dienste „reden“ direkt miteinander durch Aufruf von SoA-Diensten.

Industrie-4.0-Konzepte für eine schnelle, individualisierte Produktion setzen entsprechende Vernetzung und Kommunikation von Geräten und Diensten voraus, die direkt miteinander kommunizieren können: Sensoren, Messgeräte, RFID-Chips, SPS-Steuerungen, HMI, MES und ERP-Systeme liefern in der Industrie wichtige Produktionsdaten. In klassischen Steuerungsarchitekturen sind die Datenanfragen entweder zyklisch oder ereignisgesteuert initiiert, und sie erfolgen immer nur auf Anfrage „von oben“, das heißt von der Client-Ebene. Dabei fungiert die untere Schicht immer als Server und reagiert: So lässt sich z. B. eine Visualisierung von der SPS die Statusdaten übermitteln oder gibt neue Produktionsrezepte in die SPS. Zunächst werden aus den elektrischen Sensorsignalen digitale Informationen erstellt – diese bekommen in der SPS einen Zeitstempel und werden über weitere Dienste dann in die MES-IT-Ebene weitergeleitet.

Mit Industrie 4.0 wird sich diese strikte Trennung der Ebenen und der Top-Down-Ansatz des Informationsflusses aufweichen und vermischen. In einer intelligenten Vernetzung kann jedes Gerät oder jeder Dienst eigenständig eine Kommunikation zu anderen Diensten initiieren.

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

B2B – B2M – M2M

Generell können alle Kommunikations-Szenarien und Use-Cases, welche auch in Industrie- 4.0- und IoT-Gruppen definiert wurden, aus abstrahierter Sicht in zwei Kontexte der Kommunikationsarchitektur unterschieden werden: in Dienste in harter Echtzeit (gemeint ist der Automatisierungskontext, z. B. die deterministische SPS zur Regelung) und in Dienste im weichen Echtzeitkontext (gemeint ist der IT-Kontext, d. h. die Reaktion erfolgt schnell, aber eine Überschreitung der Antwortzeit ist kein Versagen).

Hieraus ergeben sich genau drei potentielle Kommunikations-Übergänge welche auch im Industrie-4.0-AG2-Leitungsgremium definiert wurden:

Effiziente Kommunikation ohne Handshake: Die TwinCAT-SPS übergibt die RFID- Information per OPC-UA-Methodenaufruf an das MES-System und bekommt als Rückgabeparameter die Anweisung zum weiteren Vorgehen.

„B2B“-Kommunikation:

Zwei Business-Prozesse der „weichen Echtzeit“ kommunizieren miteinander. Beispiel: Eine ERP-Anwendung tauscht mit einer MES-Anwendung Informationen aus. Der Austausch z. B. zwischen HMI und MES, MES und MES, Sensor und Cloud, … kann vom kleinen ms- bis zum hohen Minutenbereich dauern.

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

„B2M“-Kommunikation:

Ein Prozess mit „weicher Echtzeit“ kommuniziert mit einem anderen Prozess der Kategorie „harte Echtzeit“. Beispiel: Eine Business-Anwendung tauscht mit einer Maschine Informationen aus. Der Austausch, z. B. von Livedaten zwischen HMI und SPS oder MES und SPS-Steuerung kann vom kleinen ms- bis zum Minutenbereich dauern.

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

„M2M“-Kommunikation:

Zwei Prozesse der Kategorie „harte Echtzeit“ kommunizieren miteinander. Beispiel: Eine Roboter-Plattformsteuerung tauscht horizontal mit einer Roboter-Handsteuerung Regelungsinformationen aus. Der Austausch muss im µs- bis zum kleinen ms-Bereich in einem harten, deterministischen Echtzeittakt abgewickelt werden.

Wie auch immer die drei Kategorien final mit Namen belegt werden: Die Kommunikation bei IoT und Industrie 4.0 wird nicht mehr auf reinen Daten und der Interoperabilität der Datenkommunikation, sondern auf dem Austausch von Informationsmodellen und somit der semantischen Interoperabilität basieren. Höchste Bedeutung wird auch die Übertragungssicherheit und die Sicherheit der Zugriffsrechte auf einzelne Daten oder Dienste haben. Alle diese Aufgabenstellungen 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 darauf angelegt, die Informationsmodelle von anderen Organisationen, wie BACnet, PLCopen, IEC 61850, AIM AutoID etc., abzubilden. Die in OPC-UA integrierte „Security by Design“ ist, laut 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, ohne Erfordernis einer übergeordneten Intelligenz oder eines zentralen Wissens. Die Funktionalität von OPC-UA-Komponenten ist skalierbar und bereits heute in der Sensorebene bis zum SAP-System vorhanden.

PLCopen: OPC-UA-Client-Funktionalität in der SPS

Für die Anforderung „Kommunikation initiieren“ muss eine Client-Komponente in den SPS-Controllern vorhanden sein – idealerweise als standardisierte Schnittstelle. Auf den im Oktober 2006 von Beckhoff eingebrachten Vorschlag, PLCopen-Kommunikationsbausteine, basierend auf OPC-UA, zu definieren, hat sich drei Jahre später eine gemeinsame Arbeitsgruppe PLCopen und OPC-UA, unter Vorsitz von Beckhoff, begründet. Im Jahr 2010 wurde zunächst das Mapping des IEC61131-3-Informationsmodells in OPC-UA (Server) als gemeinsame Spezifikation verabschiedet: Das bedeutet konkret, dass ein einziges SPS-Programm als IEC61131-3-Norm unverändert, mit den jeweils unterschiedlichen, proprietären Engineering-Tools verschiedener Hersteller auf deren SPS geladen werden kann. Die Steuerungen stellen ihre Daten und Informationen, semantisch identisch, per OPC-UA, nach außen, z. B. für Visualisierungs- und MES/ERP-Aufgaben, zur Verfügung. Dies erleichtert den Engineering-Aufwand ungemein: Anstatt für eine Instanz eines Funktionsbausteines mit z. B. 20 Datenpunkten jeden einzelnen in eine Visualisierungsmaske oder ein MES-System zu verknüpfen, reicht es nun, ein einziges Instanz-Objekt zu verbinden – und das sogar identisch bei verschiedenen Herstellern.

Als nächster Schritt wurde im April 2014 die Spezifikation der PLCopen „OPC-UA-Client-Funktionsbausteine für IEC61131-3“ freigegeben. Damit kann die Steuerung – zusätzlich oder alternativ zur bisherigen Rollenverteilung – auch den aktiven, führenden Part der Kommunikation übernehmen. Die SPS kann somit komplexe Datenstrukturen horizontal mit anderen Controllern austauschen aber auch vertikal Methoden in einem OPC-UA-Server eines MES/ERP-Systems aufrufen, um sich z. B. neue Produktionsaufträge abzuholen oder Daten in die Cloud zu schreiben. Dies ermöglicht der Produktionslinie, selbständig aktiv zu werden.

Erste Kunden haben frühzeitig das Potenzial dieser Bausteine erkannt und von der Umsetzung von Beckhoff profitiert: Silvo Merz, vom Zweckverband Wasser und Abwasser Vogtland, hat für den Bereich der Wasserwirtschaft 300 dezentrale Anlagen mit kleinsten Embedded-CX9020-Steuerungen intelligent vernetzt. Das Ergebnis ist eine dezentrale Intelligenz, 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. „Der Ersatz einer vormals proprietären Lösung wurde mit dem CX9020 und dem integrierten OPC-UA-Client und -Server ersetzt und erbrachte uns z. B. eine Einsparung der Lizenz-Initialkosten von mehr als 90 % je Gerät“, ist Silvio Merz technologisch und kaufmännisch mehr als begeistert von der Lösung.

Ein reales Szenario zum Aufruf einer OPC-UA-Methode wurde bereits im Jahr 2013 auf der Hannover Messe gezeigt: Die Beckhoff-SPS hat – als OPC-UA-Client agierend – eine Methode im MES-System der Firma iTAC aufgerufen: Als Inputparameter wurden ein RFID-Code und Prozessdaten übergeben, welche vom MES-System verbucht, geprüft und mit der Rückantwort der Qualität „OK“ oder „Failure“ versehen wurden. Vor allem die Performance und die Datenkonsistenz konnten durch den Methodenaufruf garantiert werden.

Die SoA (Service oriented Architecture)-SPS

Die SPS-Hersteller haben mit dem Mapping der IEC 61131-3 in den OPC-UA-Server und mit den PLCopen-Bausteinen bereits ein wichtiges Fundament gelegt. Aus der SPS heraus OPC-UA-Dienste in anderen Geräten aufzurufen, bietet die Möglichkeit für „B2M“-Szenarien: Die SPS kann z. B. einen Dienst in einer Vision/Kamera-Applikation oder einem RFID-Reader aufrufen, direkt mit der SPS kommunizieren oder die Daten einer Big-Data-Applikation in die Cloud melden. Die SPS kann diese Methoden aufrufen; wie aber kann sie selber Dienste anbieten – vor allem einfach handhabbar?

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. Die Grundlage hierzu ist die TwinCAT-Modulsprache, welche die Eigenschaften der Module, u. a. bezüglich der Prozessparameter oder der Methoden, beschreibt. Die Realisierung ist für SPS-Programmierer sehr einfach: Eine Methode in der SPS (mit beliebigen Ein-/Ausgangsparametern) steht durch das Hinzufügen einer simplen Pragma-Anweisungszeile einfach als Serviceaufruf im OPC-UA-Server zur Verfügung, welcher in die SPS-Steuerung integriert ist. Jeder OPC-UA-Client kann, mit der im OPC-UA integrierten IT-Security und Berechtigung, den TwinCAT OPC UA Server durchbrowsen und den entsprechenden Dienst aufrufen, und zwar unabhängig vom Betriebssystem, der Programmiersprache und unter Wahrung der Datenkonsistenz.

Vorteile: Effektive, datenkonsistente Dienste aus der SoA-SPS

Der Datenaustausch zwischen MES-Ebene und SPS erfolgt heute in der Regel über ein zeitaufwändiges Handshake-Verfahren. Die SoA-SPS ermöglicht es nun, mit einer einzigen Kommunikation Daten an die Steuerung zu übermitteln: Hier werden nicht vielfach Datenwerte ausgetauscht, sondern ein einziger Dienst mit Eingangsparametern (dem Rezept) und Ausgangsparametern (der 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 wird die Kommunikations-Roundtrip-Zeiten zwischen SPS- und MES-Systemen deutlich verkürzen und kann zu einem höheren Produktionsdurchsatz führen. Definitiv wird es aber die Engineering-Kosten für die Datenkopplung vom Shop-Floor zum Top-Floor drastisch reduzieren.

Status – Ausblick

Eine „SoA-SPS“ bedeutet mehr als nur einen 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 – verknüpft mit der notwendigen Security bis in die Dienste- und Datenebene, dazu die Modellierungsmöglichkeiten von Informationsmodellen – und all das auf einer internationalen 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. In Zukunft wird der Austausch von Informationsmodellen zunehmend wichtiger werden: Eine SPS sollte sich dann z. B. als Strommessgerät, gemäß einer Vorgabe der Organisation der Messgerätehersteller, melden. Das in einer Embedded-Steuerung eingesetzte Betriebssystem wird künftig von außen nicht mehr sichtbar sein: Aus Security-Gründen sind alle Ports geschlossen – das Gerät bietet 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. Beckhoff hat das Potenzial von OPC-UA 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 TwinCAT-Steuerungsarchitektur stellt, in Kombination mit der großen Signalvielfalt der IO-Klemmen, die ideale, leistungsmäßig skalierbare Plattform für alle zukünftigen Anforderungen zur Verfügung.