Ein Blick auf die Automobilindustrie verdeutlicht, was in nicht allzu ferner Zeit auch in den Fabrikhallen einziehen könnte: Seit den späten 1970er-Jahren wurden Motorsteuergeräte in Autos eingebaut und bald darauf unterschiedliche elektronische Steuergeräte für weitere Funktionen. Innovationen in allen Bereichen von der Fahrzeugsteuerung und Sicherheit über Komfort bis hin zu Fahrerassistenz und automatisierten Fahrzeugfunktionen sorgen seither dafür, dass Computer stets mehr Aufgaben in Autos übernehmen. Für jede neue Funktion kam zuerst auch ein neuer Steuercomputer mit eigenen I/O-Elementen zum Einsatz. Die Hersteller der Steuergeräte erklärten, dies wäre die Voraussetzung für die Gewährleistung hoher Qualität und Betriebssicherheit.
In Folge stieg dadurch aber je nach Ausstattung des Fahrzeugs die Zahl von Steuergeräten und I/O-Elementen samt der dafür notwendigen Verkabelung an – und damit auch der Stromverbrauch, das Gesamtgewicht und der Platzbedarf für die Elektronik. 

In den 1990er-Jahren setzte sich im Rahmen einer ‚Architektur-Revolution‘ das Konzept von Domänensteuergeräten durch. Anstatt eines eigenen Steuergerätes für jede Funktion übernahm ein größerer und leistungsfähigerer Rechner eine Vielzahl von Aufgaben der gleichen Art – beispielsweise Motor- und Getriebesteuerung oder Komfortfunktionen. Durch diese Integration und Zentralisierung wurden Kosten gespart, weil weniger einzelne Steuergeräte verbaut werden mussten. Außerdem war die neue Architektur für die Wartung und die Zuverlässigkeit vorteilhaft, weil weniger einzelne elektronische Bauteile, Kabel und Stecker im System existierten. 

In der Industrieautomatisierung gibt es auch dedizierte Steuergeräte – SPSen – und zugehörige I/O-Elemente mit hohen Anforderungen an Zuverlässigkeit und Verfügbarkeit. Die Gesamtarchitektur umfasst oft eine Vielzahl einzelner Steuerungen, die miteinander in Verbindung stehen. Im Gegensatz zur Automobilindustrie sind die funktionalen Verbindungen zwischen den Steuerungen oft deutlich geringer und es ist genügend Raum für den Einbau und die Stromversorgung einer Vielzahl von SPSen verfügbar. Nun stellt sich die Frage, ob die Integration und Zentralisierung von Steuerungen in der Industrieautomatisierung ähnliche Vorteile bieten kann wie in der Automobilelektronik. Sicherlich liegt der Vergleich deutlich näher als mit einem Rechenzentrum, wo ja Virtualisierung und damit gemeinsamer Betrieb von Webservern, Datenbanken und anderen Applikationen unterschiedlicher Art auf leistungsfähigen Servern schon lange Stand der Technik sind. 

Die integrierte, zentralisierte Architektur

Folgende Situation ist durchaus vorstellbar: Die SPSen werden aus der Automatisierung entfernt und ihre Steuerungsfunktionen in Form von Soft-SPSen in einem ‚Edge Rechenzentrum‘ mit passender Ausstattung an Rechenkapazitäten und Netzwerk-Anbindung zum Automatisierungssystem auf ‚Industrial Edge Servern‘ gehostet. 
Server bieten heute bereits ausreichend Leistung, um Dutzende Soft-SPSen gleichzeitig zu verarbeiten, allerdings können gewöhnliche IT-Server mit Technologien wie Virtualisierung und geteilten Ressourcen für Netzwerk und Speicher die Anforderungen der Industrie nach Zuverlässigkeit und Echtzeit-Verhalten nicht ausreichend adressieren. Dafür sind ‚Industrial Edge Server‘ vonnöten. 

Netzwerktechnisch muss das Rechenzentrum eng an die Automatisierung angebunden sein, um die notwendigen kurzen Kommunikationszyklen und Latenzanforderungen zu erfüllen. Daher ist das Edge Rechenzentrum nicht irgendeine Cloud, sondern potenziell ein Serverrack vor Ort. Die Feldebene der Automatisierung bleibt weitgehend unverändert – allerdings müssen analoge und diskrete I/Os durch Ethernet-basierte ersetzt oder durch passende Gateways ergänzt werden, um für die über ein Netzwerk erreichbaren Steuerung nutzbar zu sein.

Vor- und Nachteile der integrierten Architektur

Die integrierte, zentralisierte Architektur mit Edge-Datacenter.

© TTTech

Funktional ändert sich an der Steuerung nichts. Die Investitionsausgaben (CAPEX) für integrierte und zentralisierte Lösungen unterscheiden sich je nach Anwendungsfall. Beispielsweise ist relevant, ob schon eine Edge-Infrastruktur vorhanden ist oder nicht. Der Vergleich mehrerer Hardware-SPSen mit einer kleinen Zahl von Edge-Servern zeigt, dass erst bei einer großen Zahl von Hardware-SPSen ein deutlicher CAPEX-Vorteil für Edge-Server auszumachen ist. Auch im laufenden Betrieb unterscheiden sich beide Lösungen nur geringfügig.
Einen deutlichen Unterschied zwischen den Lösungen lässt sich hingegen in der Flexibilität und Erweiterbarkeit ausmachen: Durch die Möglichkeit, im Edge-Rechenzentrum auf die Daten aus der Feldebene zuzugreifen, lassen sich hier nicht nur Steuerungen, sondern auch Analysen von Prozessdaten in Echtzeit durchführen, was für Diagnose, Wartung, Optimierung und intelligente Reaktionen auf Veränderungen im Automatisierungssystem essenziell sein kann. Diese Analysen laufen nicht ‚auf‘, sondern ‚parallel zu‘ den Steuerungen auf den gleichen Edge Servern. Da die Steuerungsfunktionen auf der gleichen Edge-Infrastruktur zu hosten sind, lassen sich Feedback-Schleifen von der Analyse in die Steuerung ebenfalls hier realisieren und damit neue Optimierungsmöglichkeiten auch im Hinblick auf Industrie-4.0-Tauglichkeit erschließen.

Die Implementierung zentralisierter ­Architekturen

Warum ist die erläuterte Architektur derzeit (noch) nicht in relevantem Umfang im Einsatz? Drei Klassen von Argumenten lassen sich hierfür bei Befragungen ausmachen:

1. Die aktuelle Architektur ist bewährt: Gründe, die für die integrierte Architektur sprechen, wie Kostenvorteile, Flexibilität, Optimierung, sind generell wünschenswert, aber das derzeitige Modell wird diesbezüglich nicht als mangelhaft oder unzureichend bewertet.

2. Technologische Risiken: Zuverlässigkeit und Determinismus von integrierten Serverplattformen gelten als nicht vertrauenswürdig genug, um betriebskritische Steuerfunktionen dorthin auszulagern. Die Reaktionszeit von Steuerungen in einem Edge-Rechenzentrum gilt netzwerkbedingt als unzuverlässig.

3. Organisatorische Hürden: Zur Umsetzung einer integrierten Plattform dieser Art sind neue Kompetenzen bei den Steuerungs-Spezialisten notwendig. Die Kompetenzverteilung im Unternehmen ist oftmals mit einer integrierten Architektur nicht kompatibel.

Wie relevant die Vorteile von Zentralisierung der Steuerung an der ‚Industrial Edge‘ sind, lässt sich eher für den konkreten Einsatzfall beurteilen. Im Bereich Echtzeit-Datenerfassung und Edge Analytics lassen sich relevante Vorteile besonders bei jenen Anwendungen finden, die im Zug einer Industrie-4.0-Strategie stärker auf flexible Produktionsabläufe und reaktive Prozessveränderungen setzen. Somit lohnt sich eine Edge-Infrastruktur durch ihre Flexibilität vor allem für Anwendungen, die hohe Anforderungen an dynamische Veränderungen der Automatisierung stellen.

Die technologischen Risiken sind durchaus herausfordernd, aber einige Entwicklungen der jüngeren Zeit zeigen, was hier bereits möglich ist:

• Hypervisor-Lösungen bieten für aktuelle Multicore-CPUs bereits Mechanismen zur garantierten robusten Partitionierung von Ressourcen wie CPU-Cores und Cache, sodass anstelle von Virtualisierung und den damit verbundenen Laufzeit-Schwankungen Echtzeit-Performance wie auf ‚bare metal‘ erreichbar ist. Je mehr Cores, desto mehr Echtzeit-Anwendungen lassen sich gleichzeitig und unabhängig voneinander ausführen. 

• Hardware-unterstützte Netzwerk-Virtualisierung der lokalen Ethernet-Schnittstelle(n) ermöglicht, dass mehrere Anwendungen die Netzwerk-Ressourcen auf dem gleichen Server unabhängig voneinander nutzen können und die jeweils benötigte Bandbreite im Netzwerk in Echtzeit verfügbar ist. Time Sensitive Networking (TSN) wiederum bietet im Netzwerk die Mechanismen, um die Echtzeit-Daten unterschiedlicher Applikationen unabhängig und störungsfrei mit garantierter Latenz durch ein Ethernet-Netzwerk zu transportieren.

• Für verschiedene Feldbus-Protokolle wie Ethercat und Profinet sind bereits Spezifikationen vorhanden, die ein ‚Tunneln‘ über TSN definieren. Damit können die I/Os der Feldebene durch ein konvergentes Netzwerk mit den Soft-SPSen im Edge-Rechenzentrum kommunizieren, als wären sie direkt über den Feldbus verbunden.

• Es gibt einen starken Trend zu herstellerunabhängigen Schnittstellen für Applikation und Management. Die laufenden Spezifikationsarbeiten in der Motion Working Group der OPC Foundation zielen darauf ab, in der Echtzeit-Steuerung herstellerunabhängige Interoperabilität zwischen Steuerungen und Motion-Control-Geräten (Drives, I/Os) auf Basis von OPC UA PubSub sicherzustellen. Ähnliche Standards für herstellerunabhängige Interoperabilität auf Basis von OPC UA und TSN haben auch andere Industriekonsortien zum Beispiel in der Euromap und der OPAF bereits verabschiedet. Auch herstellerunabhängige Management-Schnittstellen wie DMTF Redfish spielen hier eine wichtige Rolle.

Umsetzung der zentralisierten Architektur

Der Edge-Server mit Edge-Plattform, auf der mehrere Workloads laufen.

© TTTech

Mit den genannten Mechanismen, Technologien und Standards lässt sich die integrierte und zentralisierte Architektur nicht nur hypothetisch beschreiben, sondern auch umsetzen, wie es bereits in verschiedenen Testbeds und Demonstratoren der Fall ist.
Die organisatorischen Herausforderungen schließlich sind keinesfalls zu vernachlässigen, aber auch hier gibt es Ansätze, um eine Lösungsperspektive zu entwickeln. Einerseits ändert sich am Modell der Steuerung betreffend Programmierung und Laufzeit-Verhalten nichts: Unverändert wird das Programmiermodell nach IEC 61131 eingesetzt, auch wenn die resultierende Steuerungsapplikation als Soft-SPS aus-geführt wird und ausschließlich über Feldbus-Schnittstellen mit der Feldebene kommuniziert. Einzelne Entwicklungen zielen auch bereits in Richtung Erweiterung der zentralisierten Architektur nach den Maßgaben der IEC/EN 61499 für verteilte Steuerungen. Doch auch dies ändert nichts am grundsätzlichen Modell. 

Andererseits ist die Konfiguration, Inbetriebnahme und Wartung einer zentralisierten Edge-Plattform für das Hosting von Steuerungen doch ein ganz anderes Aufgabengebiet als die Programmierung und Nutzung einer SPS. Wenig erfolgversprechend wäre daher ein Ansatz, der die beiden Systemaspekte – SPS und Edge-Plattform – untrennbar integriert und gemeinsam verwalten möchte. Stattdessen scheint es zweckmäßig, wenn der Lifecycle der Steuerungsanwendungen wie bisher die Domäne der Experten für diese Anwendungen bleibt, während sich die IT-Abteilung um die Installation und Wartung der Edge-Server und der darauf laufenden Hosting-Infrastruktur kümmert. Die essenziellen Schnittstellen, die für Robustheit und Determinismus gemäß den Anforderungen der Automatisierung sorgen, müssen in einem entsprechend zertifizierten ‚Edge-Computing-Plattform‘-Produkt enthalten sein, denn diese Kompetenz ist für gewöhnlich weder bei den Experten für Steuerungen noch in einer IT-Abteilung zu finden. 

Blick in die Zukunft

Georg Stöger ist Director Technical Presales und Training Industrial bei TTTech Industrial Automation

© TTTech Computertechnik

Eine konsequent zentralisierte Architektur für Steuerungen in der Automatisierung ist momentan nicht Stand der Technik. Die aktuelle Architektur, in der nahezu jede Steuerung direkt bei ihrer Applikation als Hardware-SPS realisiert wird, ist bestens etabliert. Wenn aber die Notwendigkeit für mehr Flexibilität und dynamische Änderungen an einem stark vernetzten Automatisierungssystem es nahelegt, können die Methoden und Technologien für eine Integration und Zentralisierung von Steu-erungen in einer Edge-Computing-Architektur mit Edge-Servern und Edge-Rechenzentren eine gute Alternative bieten.

Solche Lösungen sind bereits vorhanden: So integriert die industrielle Edge-Computing-Plattform Nerve von ‚TTTech Industrial Hypervisor‘ Soft-SPS und zentrales Applikationsmanagement in einer offenen Lösung. Damit ist sichergestellt, dass bei einer Migration in eine solche zentralisierte Architektur die Offenheit und Herstellerunabhängigkeit so gut wie derzeit oder noch besser gewährleistet wird.