: Wie man die Automatisierungspyramide mit dem Metals Service Bus durchbricht

Wie ermöglicht PSIbus ein reibungsloses Zusammenspiel zwischen verschiedenen Systemkomponenten? Diese Frage wird in diesen 10 Fragen und Antworten beantwortet.

Internationale Automatisierungsnormen wie ANSI/ISA-95 gliedern die Metallproduktion hierarchisch in mehrere Ebenen: beginnend mit der Prozesssteuerung (L1) an der Basis, gefolgt von der Prozessautomatisierung (L2), dann der Betriebsleitung (L3) und schließlich der Unternehmensführung (L4). Die Schichten bilden zusammen die so genannte „Automatisierungspyramide”.

Jedes System, das sich auf einer Schicht der Pyramide befindet, hat sich in den letzten Jahren weiterentwickelt, wobei der Schwerpunkt auf der Optimierung der jeweiligen Prozesse innerhalb jeder Schicht lag. Die Systeme können nur dann miteinander interagieren, wenn Daten- und Kontrollflüsse zwischen benachbarten Schichten ausgetauscht werden. Die Beschreibungen, wie Teile der verschiedenen Schichten miteinander interagieren, werden als „Schnittstellen” bezeichnet, und jede Schnittstelle verwendet ihre eigene Sprache. Die Sprache einiger Schnittstellen ist standardisiert, während andere eine völlig eigene Sprache verwenden, die nur von zwei interagierenden Teilen der Automatisierungspyramide gesprochen und verstanden wird.

Bei der Suche nach Beispielen für die Anpassung von KI- und ML-Themen an die etablierte Automatisierungspyramide wird das inhärente Problem deutlich. KI und insbesondere Anwendungen im Beriech maschinellen Lernens (ML) erfordern eine hochintegrierte Sicht auf die erfassten Daten und die sie verarbeitenden Prozesse. Die Daten, die als Input für diese Techniken verwendet werden können, stammen aus verschiedenen Quellen, z. B. aus hochentwickelten Systemen, aber auch aus Sensoren, die hauptsächlich Rohdaten mit einem hohen Detaillierungsgrad liefern. Die Kombination von Daten aus all diesen Quellen bildet die Grundlage für das, was heute als „Big Data” bezeichnet wird.

Dies umfasst die Daten und ihre Quellen auf allen Ebenen der Automatisierungspyramide, von Ebene 1 bis Ebene 4. Die Anwendung dieser Mechanismen mit der derzeitigen Infrastruktur der Automatisierungspyramide ist schwierig oder sogar unmöglich zu bewerkstelligen. 

Der Ansatz der Automatisierungspyramide mit seiner Hierarchie, der starken Trennung der Verantwortlichkeiten der einzelnen Ebenen und den hochspezialisierten Produkten, die jede Ebene bedienen, hat sich über viele Jahre bewährt. Mehrere Veränderungen in der IT-Industrie mit neuen Forschungsfeldern, neuen Möglichkeiten und serienreifen Softwarekomponenten setzen diesen Ansatz jedoch unter Druck. Die Infrastruktur der automatisierten Pyramide behindert bis zu einem gewissen Grad die angemessene Nutzung dieser neuen Technologien.

Ein Grund dafür ist die zwischen den Schichten eingeführte versteckte Abstraktion. Da sich jede Schicht hauptsächlich auf ihre eigene Sicht der Daten und Prozesse konzentriert, die auf ihrer Ebene erforderlich sind, kommt es an den Schnittstellen zwischen den verschiedenen Schichten unweigerlich zu Informationsverlust. 

Während IoT, Big Data, maschinelles Lernen usw. uns zeigen, wie wir von unverfälschten Daten profitieren können, stößt die bestehende Schichtung der Automatisierungspyramide an ihre Grenzen. Die den Schnittstellen inhärente Abstraktion zwischen den Schichten verbirgt Daten aus den über- und unterliegenden Ebenen - dieser Effekt vervielfacht sich sogar, wenn mehr als eine Schicht durchlaufen wird. Informationen der Ebene 1 werden aufgrund der Abstraktion der Schnittstellen und der dazwischenliegenden Ebene 2 höchstwahrscheinlich nie die gleiche Bedeutung und Vollständigkeit haben, wenn sie die Ebene 3 erreichen. Es kann sogar sein, dass diese Informationen von Ebene 3 gar nicht wahrgenommen werden, weil Ebene 2 „entscheidet”, dass es nicht sinnvoll ist, sie an Ebene 3 weiterzugeben. Dasselbe gilt in umgekehrter Richtung.

Ein weiteres Problem, das sich nicht speziell auf neue IT-Bereiche bezieht, sondern auf die fortgesetzte Nutzung einer Schichtenarchitektur, ist die mangelnde Fähigkeit zur schnellen Anpassung an Veränderungen.

Die Verwendung eines strengen Automatisierungspyramiden-Ansatzes tendiert dazu, unnötige Änderungen an laufenden Systemen zu fordern, schafft Abhängigkeiten von externen Anbietern, bindet deren Ressourcen und erschwert die Fähigkeit, den Wandel zu vollziehen.

In verschiedenen Bereichen unseres täglichen Lebens sind unterschiedliche Organisationsformen anzutreffen. Einige Unternehmen haben ihre Organisationsstruktur von einer streng hierarchischen Struktur zu einer Matrixstruktur geändert, in der jeder Teil des Unternehmens mit jedem anderen Teil interagieren kann. Die Architekturen von Softwareanwendungen entwickeln sich von Schichtenarchitekturen zu hexagonalen Architekturen oder sogar zu vollständigen Microservice-Architekturen.

Das Aufbrechen der Schichten der Automatisierungspyramide in kleinere Teile, bei denen jeder Teil direkt mit dem anderen kommuniziert, kann daher neue Anwendungsbereiche erschließen. Dies bedeutet nicht nur die Beseitigung der Schichten selbst, sondern auch die Möglichkeit, die einzelnen Teile geschäftsprozessorientiert zu integrieren. Zusammengefasst bedeutet dies die Beseitigung der horizontalen Aggregationsschicht und die Schaffung einer vertikalen Integration entlang der Geschäftsprozesse.

Durch die Änderung der Organisation der Systemteilnehmer ist es notwendig, die Art der Kommunikation und ihre Semantik zu harmonisieren, um die Interaktion der verschiedenen „schichtenfreien” Teile zu ermöglichen. Ohne einen solchen Standardisierungsansatz führt die Kombination von zwei unterschiedlichen Teilen der neuen Organisationsstruktur zu einer spezifischen Implementierung. Kommt ein weiterer Teil hinzu, der mit den bereits vorhandenen Teilen interagieren muss, verdoppelt sich die Anzahl der Kommunikationsschnittstellen und damit der Implementierungsaufwand. Kommen immer mehr Teile hinzu, die miteinander interagieren müssen, führt dies zu einer Explosion der benötigten Kommunikationsschnittstellen.

Der Begriff „Bus” wird in der IT-Branche seit fast Jahrzehnten verwendet, erreichte Anfang der 2000er Jahre seinen Höhepunkt und erlebte um 2010 ein Revival. Diese Systeme wurden in der Regel als einfache, leichtgewichtige Kommunikationsframeworks entwickelt, aber im Laufe der Zeit wurden sie immer intelligenter - bis zur Entwicklung eines vollständigen Enterprise Service Bus (ESB). Beispielsweise wurde die Auswahl, welcher Teil des Systems zur Ausführung einer bestimmten Systemfunktion verwendet werden soll, als Aufgabe in den Bus verlagert. Dadurch wurde immer mehr Domänenwissen von den beteiligten Komponenten in den Bus selbst verlagert.

Ein weiterer Schritt in Richtung Komplexität bestand darin, die Geschäftsinfrastruktur selbst in die Lage zu versetzen, zwischen den verschiedenen Sprachen der Beteiligten zu übersetzen. Auch dies führte zu Abstraktion und Informationsverlust durch Transformation. Es stellte sich heraus, dass diese Ansätze, Intelligenz in die frühen Bussysteme einzubauen, diese zu überladen und zu komplex für den Betrieb machten. Schließlich war der „Bus” selbst keine Kommunikationstechnik mehr, sondern wurde zur Anwendung selbst.

PSI Metals führt den PSIbus für die Metallindustrie als einen Oberbegriff ein, der vereinigt:

• ein Konzept über das Zusammenwirken verschiedener Teile des gesamten IT-Systems eines Stahlherstellers
• ein Protokoll für den Austausch von Daten und Abläufen zwischen den verschiedenen Beteiligten
• eine gebrauchsfertige Software-Infrastruktur, die es den Beteiligten ermöglicht, zu kommunizieren und zusammenzuarbeiten

Fasst man diese Aspekte des PSIbus mit ihrer metallspezifischen Anwendung zusammen, kann man diese Kombination „The Metals Service Bus“ nennen.

Digitalization Jorney mit PSIbus steht für die Transformationsreise der Metallindustrie.

Der erste Schritt zum Abbau der Automatisierungspyramide besteht darin, über eine andere Art der Zusammenarbeit zwischen den Beteiligten nachzudenken. Durch das Aufbrechen der Ebenen wird die direkte Kommunikation zwischen allen Beteiligten gefördert - die Zusammenarbeit wird von einer hierarchischen zu einer kollegialen Zusammenarbeit. So werden alle Beteiligten gleichbehandelt und haben Zugriff auf den gleichen Datenschatz. PSImetals als Produktions-Management-Software PMS ist der erste metallspezifische Anwender des Metals Service Bus. Durch die Nutzung des PSIbus als Grundgerüst für das Zusammenspiel der einzelnen Komponenten werden die „internen” Komponenten des PMS nach außen sichtbar. Die internen Komponenten des PMS  können somit auch leicht mit anderen PSIbus Beteiligten integriert werden. Dies eröffnet die Möglichkeit der Zusammenarbeit und ermöglicht eine wertvolle Business-to-Business-Kommunikation.

Neben der Fähigkeit, verschiedene Systeme und Komponenten miteinander zu verbinden, ist die zu verwendende „Sprache” ein Schlüsselfaktor für die erfolgreiche Integration dieser verschiedenen Teile. Um die „babylonische Sprachverwirrung” zu vermeiden, ist eine Vereinheitlichung der zu sprechenden Sprache - in der Informationstechnik „Protokoll” genannt - unbedingt erforderlich. Der PSIbus bietet neben einer technischen Plattform für den Austausch von Daten und Datenströmen auch ein einheitliches Protokoll als Standardisierungsvorschlag. Das Protokoll basiert auf einer textuellen Darstellung der Daten, die für Mensch und Maschine lesbar ist und dem IT-weiten Standard JavaScript Object Notation (JSON) folgt. 

Neben dem Standardprotokoll und dem Interaktionskonzept benötigt der PSIbus auch eine Software-Infrastruktur. Eine solche Software-Infrastrukturkomponente wird als Teil des PSI Java Frameworks der PSI Software SE bereitgestellt. Die Komponenten werden in vielen Branchen eingesetzt, z.B. in Überwachungssystemen für den Gas- und Öltransport, im Lagermanagement und in anderen Produktionssystemen. PSI Metals nutzt diese Komponenten, indem es diesen Bus um spezifische Konfigurationen erweitert, die auf die Bedürfnisse der Stahlerzeugung und -verarbeitung zugeschnitten sind. Um auch anderen, nicht-PSI Systemen die Integration mit dem PSIbus zu ermöglichen, basiert die Kommunikation auf Standards wie REpresentational State Transfer (REST) und Java Message Service (JMS). In Kombination mit dem offenen Protokoll ermöglicht dies die Anbindung nahezu aller Systeme an den Bus mit allen möglichen Programmiersprachen, Umgebungen und Frameworks.

Um sich von diesen frühen Bussystemen zu unterscheiden, verfolgt der PSIbus mit seinen metallspezifischen Erweiterungen eine strikte Trennung der Belange. Der PSIbus selbst ist ein architektonischer Ansatz, um verschiedene Teile unterschiedlicher Systeme über einen einheitlichen Transportmechanismus und ein einheitliches Protokoll zu verbinden - er bringt nicht selbst die Intelligenz aus den Bereichen der Stahlproduktion in diese Infrastruktur ein. Vielmehr zwingt er die Akteure des Systems, als intelligente Endpunkte zu agieren und die Geschäftslogik auf ihrer Seite zu behalten.