Kommentar Zentrale versus dezentrale Automation

Dieter Hess war mit diesem Beitrag im A&D-Kompendium 2019/2020 als einer von 100 Machern der Automation vertreten.

Wer über die letzten 25 Jahre die Automatisierungstechnik beobachtet hat, konnte erleben, dass das Thema zentrale versus dezentrale Automation immer wieder engagiert, manchmal auch emotional, diskutiert wurde. Momentan wird die Frage „zentral“ versus „dezentral“ zu einer Systementscheidung hochstilisiert. Denn oft werden ohne Not verschiedene Aspekte vermischt: die verwendete Kommunikationstechnologie, die verwendete Steuerungsarchitektur und das Zerlegen der Applikation in unabhängige Teile, die möglichst kleine Schnittstellen zueinander haben.

Letzteres ist generell eine gute Idee. Egal ob zentral oder dezentral: Man erreicht dadurch eine wesentlich bessere Wartbarkeit und versetzt sich überhaupt erst in die Lage, zwischen zentral und dezentral entscheiden zu können. Dieser Aspekt spielt in der Diskussion leider eine untergeordnete Rolle, da er von den Anwendern, nicht von den Anbietern, gelöst werden muss.

Kommunikation in Echtzeit

Bei der Kommunikationstechnologie gab es in der näheren Vergangenheit Entwicklungen, die viele Bewertungen in einem neuen Licht erscheinen lassen. Zum einen gibt es inzwischen Feldbussysteme, die große Mengen verteilter I/Os in Echtzeit zu einer Zentralsteuerung transportieren.

Auf der anderen Seite ist mit OPC UA in Kombination mit TSN erstmals eine Technologie in Sicht, die standardisierte, herstellerübergreifende Echtzeitkommunikation zwischen Steuerungen ermöglicht. Dabei werden alle Arten der Kommunikation bereitgestellt, die für eine moderne Applikation benötigt werden: Synchrone Kommunikation (OPC UA Pub/Sub) zum Prozessdatenaustausch, der Methodenaufruf (Remote procedure call) zum Auslösen von Funktionen auf anderen Steuerungen sowie die asynchrone Kommunikation (OPC UA DA Client/Server) zum Parameteraustausch und für größere Datenmengen.

Methoden des Datenaustauschs

Für den herstellerübergreifenden Einsatz ist jedoch neben dem Protokoll auch ein Austausch von Engineering-Daten erforderlich. Dieser kann bei OPC UA über das sogenannte Nodeset erfolgen, eine XML-Datei, die das Informationsmodell – also die angebotenen Daten – einer Steuerung beschreibt.

Eine weitere Möglichkeit ist das Auslesen des Informationsmodells, wenn man über eine Onlineverbindung zur Steuerung verfügt. Im Rahmen der OPC Foundation wurden darüber hinaus für verschiedene Branchen sogenannte „Companion Specs“ als Standards festgelegt. Dies sind Informationsmodelle, die nicht nur die Form, sondern auch die Interpretation bereitgestellter Daten definieren.

Companion Specs gibt es beispielsweise für Roboter oder Verpackungsmaschinen. Durch diese Kommunikationstechnologien wird der Aufbau herstellerübergreifender, dezentraler Steuerungssysteme möglich, wobei im Falle von Companion Specs nicht einmal zwingend ein Austausch zwischen den Tools stattfinden muss.

Die richtige Steuerung auswählen

Die Frage der Steuerungsarchitektur ist demgegenüber von immer geringerer Bedeutung. Steuerungen unterscheiden sich immer weniger voneinander. Ein Laufzeitsystem macht aus jeder Standardhardware (IPC mit x86, ARM-Prozessoren) eine Steuerung. In der Praxis entscheiden oft I/O-Ausstattung und Schutzklasse der Geräte. Zentrale oder dezentrale Steuerung?

Wichtig ist zunächst einmal, eine Steuerungsapplikation modular aufzubauen. Sobald echtzeitfähiges OPC UA verfügbar ist, kann für jede Anlage separat festgelegt werden, ob sie zentral oder dezentral gesteuert werden soll. Vorteile in Bezug auf Kosten oder Wartbarkeit können dann den Ausschlag geben.