In der Regel wird in industriellen Applikationen die SPS eines bestimmten Anbieters verwendet respektive werden lediglich kleine Anwendungsteile mit Steuerungen anderer Hersteller realisiert, um das entsprechende Know-how zu bündeln und die Wartbarkeit der Geräte zu erhöhen. Aufgrund der Liefersituation der vergangenen Jahre gestaltet sich die Beschaffung der Komponenten allerdings schwieriger, da diese oft nicht erhältlich sind. Deshalb werden Lieferketten überarbeitet und Konzepte zur zeitgerechten Umsetzung von Kundenaufträgen erstellt und angepasst. Ein bereits seit längerem in der Prozessautomation existierender Ansatz besteht in der Modularisierung von Anlagen. Die Anwender definieren ihre Anforderungen so, dass sich bestimmte Teilaufgaben in Module auslagern lassen, die später austauschbar und im besten Fall frei kombinierbar sind. Die Herausforderung in einem modularen System ergibt sich jedoch aus den Schnittstellen zwischen den Teilsystemen und einem meist übergeordneten Leitsystem. Sie müssen standardisiert werden und in die Realisierung der Teilmodule einfließen.

Festlegung der Anforderungen an eine dezentrale Anwendungsarchitektur

Beim Open Process Automation Forum (OPA-F) handelt es sich um einen Zusammenschluss zahlreicher Unternehmen aus verschiedenen Industriebereichen und der Informationstechnologie (IT). Sie haben sich zum Ziel gesetzt, eine dezentrale, verteilte sowie gleichzeitig sichere und effiziente Anwendungsarchitektur zu etablieren. Anhand dieser Architektur lassen sich industrielle Applikationen entwickeln, die aus kleinen Funktionseinheiten zusammengesetzt werden können und somit eine verteilte, dezentrale Anwendung darstellen. Sämtliche Anforderungen an eine solche Applikation sind im Open Process Automation Standard (O-PAS) festgelegt.

O-PAS legt großen Wert auf die Hersteller­unabhängigkeit der Architektur, deren Backbone der Industriestandard OPC UA bildet. OPC UA vereint alle Ansprüche hinsichtlich einer sicheren Verbindung und effizienten Datenübertragung, der Standardisierung von Informationsmodellen, moderner Publikations- und Subscriptions-Mechanismen, des Zertifikats- und Rechtemanagements sowie weiterer wichtigen Aufgaben in industriellen verteilten und modularen Systemen. Die Herstellerunabhängigkeit sorgt für hohe Flexibilität und Austauschbarkeit der verbauten Komponenten. Sämtliche dem Standard entsprechende und zertifizierte Teilnehmer lassen sich miteinander kombinieren und schaffen folglich ein Netzwerk von kommunizierenden Knoten.

Mehrere Ankopplungsoptionen von Anlagenteilen

Generell nutzt die O-PAS-Architektur das sogenannte OCF (O-PAS Connectivity Framework) als zentrales Kommunikationselement. Über das Framework tauschen alle Applikationsteile, die als Distributed Control Nodes (DCN) angeschlossen werden, Daten untereinander aus. Mit seiner Steuerungsplattform PLCnext Technology stellt Phoenix Contact hier mehrere mögliche DCN-Ausprägungen zur Verfügung. Dabei kann es sich um einen I/O-Knoten handeln, bei dem die angekoppelten Sensoren direkt auf den Kommunikationsbus (OCF) gelegt respektive Daten vom Kommunikationsbus gelesen und auf die angebundene Hardware geschrieben werden. Darüber hinaus lässt sich ein dedizierter Applikationsteil (App) auf die offene Steuerungsplattform aufspielen und an den Bus anschließen. Abhängig vom gesamten Applikationsdesign werden mehrere Ankopplungsoptionen von Applikationsteilen angeboten. Eine Kombination der beiden oben genannten Ausprägungen ist ebenfalls möglich.

Ein solch verteiltes Netzwerk hängt maßgeblich von der Selbstbeschreibung des Applikationsteils ab. In der O-PAS-Architektur sorgt dafür ein OPC-UA-Informationsmodell, das auf standardisierte Datentypen und -strukturen zurückgreift, die für sämtliche Hersteller bindend sind. Über das Informationsmodell werden Datenknoten bereitgestellt und durch Aliasnamen neutral beschrieben. Als Zentralregister innerhalb des Netzwerks registriert der Global Discovery Service (GDS) die Aliasnamen, die den jeweiligen OPC-UA-Namensraum, die eindeutige OPC-UA-NodeID sowie die OPC-UA-Serveradresse als Referenzdaten umfassen.

Global Discovery Server als Certificate Authority

Über die Abfrage eines Aliasnamens beim GDS erhält jeder O-PAS-Teilnehmer seine Information bezüglich der Lage der zu verarbeitenden Daten und kann so eine Verbindung zum entsprechenden Zielserver aufbauen. Ab diesem Zeitpunkt liegt eine Direktkommunikation der Teilnehmer vor. Welche Aliasnamen auf einem DCN ausgeführt werden sollen, ergibt ich aus der Applikationskonfiguration. Als Format für deren mögliche Beschreibung hat sich die Automation Markup Language (AML) eta­bliert. Die Aspekte der Selbstbeschreibung der Applikation für andere Teilnehmer sowie der individuellen Konfiguration der zu verarbeitenden Daten auf lokaler Ebene bilden das Grundgerüst jedes Distributed Control Nodes.

In dezentralen Netzwerken kommt dem Thema Sicherheit eine große Bedeutung zu. Der Global Discovery Server übernimmt in diesem Zusammenhang die Rolle der Certificate Authority. Nach der Registrierung eines Applikationsteils wird die Erzeugung und Zuweisung eines Zertifikats zur Autorisierung der Komponenten untereinander angestoßen. Somit ist sichergestellt, dass lediglich registrierte Netzwerkteilnehmer Daten miteinander austauschen dürfen. Rollenbasierte Zugriffsmechanismen erweitern das Sicherheitskonzept. Sie ermöglichen eine zusätzliche feingranulare Verteilung von Rechten. Dieser grobe Überblick zeigt, dass verteilte dezentrale Anwendungen keine Utopie im industriellen Umfeld darstellen, sondern aktiv in das Design von Industrie­anwendungen einfließen können.

Entwicklung offener O-PAS-basierter Steuerungssysteme

Die Abkürzung COPA steht für Coalition for Open Process Automation. Das von den amerikanischen Unternehmen CSI und Cplane aufgesetzte Partnerprogramm dient der Zusammenarbeit von Anbietern aus den Sektoren Operational Technology (OT) und Information Technology (IT). COPA zielt darauf ab, die Entwicklung kommerzieller und offener Steuerungssysteme auf der Grundlage des O-PAS-Standards zu fördern und zu etablieren. Phoenix Contact ist der Coalition ebenfalls beigetreten, nimmt an zahlreichen Test- und Schulungsveranstaltungen teil und entwickelt das COPA-QuickStart-System gemeinsam mit Cplane stetig weiter. Als Hardwarelieferant kontribuiert das Blomberger Unternehmen mit Teilen seines Produktportfolios am QuickStart-System. Auch im Bereich von Engineering-Leistungen besteht eine enge Kooperation zwischen COPA und Phoenix Contact. Die Coalition strebt die Einführung und Verbreitung von O-PAS-basierten Steuerungssystemen in den Branchen Öl und Gas, Stromerzeugung, Chemie sowie weiteren Industriezweigen an.    

Autor: Peer Michael Gaus, Application Engineer im Industry Management Process, Phoenix Contact Electronics

Offenes Ecosystem PLCnext Technology

PLCnext Technology ist das Ökosystem für die industrielle Automatisierung bestehend aus offener Hardware, modularer Engineer­ing-Software sowie einer globalen Community und einem digitalen Software-Marktplatz. Digitalisierung und Globalisierung stellen neue Anforderungen an die industrielle Automatisierung. Ein passgenaues Design des offenen Automatisierungssystems erweist sich dabei als genauso wichtig wie eine flexible, modulare Erweiterung.
Neben der SPS-Standardprogrammierung nach IEC 61131-3 erlaubt PLCnext Technology auch die parallele Programmierung sowie die Kombination von Programmiersprachen wie C/C++, C# oder Matlab Simulink in Echtzeit. Durch die einfache Cloud-Integration, die Möglichkeit der Nutzung von Open Source Software und dem ständig wachsenden Know-how der PLCnext Community profitieren Anwender von neuen Formen der Zusammenarbeit. Die daraus resultierenden Solutions-Apps, Software-Bausteine, Run­time-Systems und Funktionserweiterungen sind im PLCnext Store verfügbar und sorgen für eine deutliche Zeit- und Kostenersparnis bei der Applikationserstellung. Damit erweist sich PLCnext Technology als das optimale Ökosystem für die Herausforderung der modernen Automatisierung.