Moryx-Plattform zur Wiederverwendung von Software-Komponenten

Unabhängig davon, ob das letzte Digitalisierungsprojekt von eigenen Mitarbeitern oder einem externen Partner agil respektive starr vorausplanend durchgeführt worden ist: Am Ende machen viele Unternehmen die gleiche Erfahrung. Entweder müssen Abstriche bei den produktiv nutzbaren Funktionen hingenommen werden oder die ursprünglich geplante Dauer des Vorhabens verlängert sich erheblich. Aufgrund dieser Unkalkulierbarkeit zögern zahlreiche Betriebe, mit der notwendigen Digitalisierung von manuellen und automatisierten Prozessen in der Fabrik zu beginnen (Bild 1).

Bei der Software-Entwicklung für diesen Einsatzbereich gilt somit das Paradigma „jeder für sich und immer wieder neu“. Eine genauere Betrachtung der Ursachen dafür verdeutlicht den Unterschied zu anderen Domänen der Software-Entwicklung. Die wenig bis nicht verbreitete Wiederverwendung etablierter Software-Plattformen zur Digitalisierung, wie sie beispielsweise im Bereich der Web-, KI- oder App-Erstellung seit Jahren selbstverständlich ist, wird bislang durch die heterogen gewachsene IT- und OT-Systemlandschaft in den Fabriken verhindert. Sobald diese Herausforderung mit wirtschaftlich vertretbarem Aufwand gelöst ist, liegt folglich nichts näher, als diese Herangehensweise auf die digitalisierte Fabrik zu übertragen. Damit sind auch die beiden zentralen Designideen der Moryx-Plattform beschrieben: Abstrahieren und Integrieren von heterogenen IT- und OT-Systemen, um Logik und Algorithmen von Digitalisierungs-Applikationen zentralisieren und erneut nutzen zu können (Bild 2).

SPS-Ebene wird auf ihren Leistungskern zurückgeführt

Unter Operational Technology (OT) werden in der Fabrik heterogene Fertigungstechnologien vom einfachen Handscanner bis zur komplexen automatisierten Prozesszelle zusammengefasst. Jedes System arbeitet dabei mit unterschiedlichen Kommunikationsprotokollen und Datenmodellen zum Austausch von Informationen mit überlagerten Logiken und Algorithmen. An dieser Stelle wird die OPC-UA-Übertragung mit standardisierten Informationsmodellen möglicherweise Vereinheitlichungen nach sich ziehen, jedoch darf die aufwendige und daher schleppend verlaufende Verbreitung des Protokolls nicht der Bremsklotz der Digitalisierung sein. Neben den vielfältigen Datenschnittstellen sind stetig neue starr verkettete SPS-Applikationen geschaffen worden, in denen die Logiken für die Verwaltung von Stammdaten, Steuerung von Produktionsprozessen oder Anbindung von IT-Systemen monolithisch miteinander vermischt werden. Der mit Moryx eingeleitete Paradigmenwechsel zielt auf das Aufbrechen dieser Monolithen in kohärente Einzelkomponenten mit loser Kopplung ab. Auf diese Weise soll sich die hohe und zukünftig weiter steigende Komplexität der Digitalisierung beherrschen lassen.

Im ersten Schritt extrahiert Moryx dazu die Logik zur Synchronisation von IT-Systemen, Verwaltung von Stammdaten sowie zum Steuern der Fertigungsprozesse in der Fabrik aus der SPS-Ebene. So entstehen OT-Systeme mit minimaler Produktionsintelligenz, die weniger leistungsfähige Hardware und einen geringeren Koordinationsaufwand bei der Beauftragung und Abnahme von deren Lieferanten bedingen. Von den SPS-Systemen werden weiterhin Funktionen wie die Ankopplung von Sensoren und Aktoren oder Steuerung von Echtzeit- und Safety-Prozessen ausgeführt. Eine derart auf den Kern ihrer ursprünglichen Leistungsbeschreibung zurückgeführte SPS-Ebene eröffnet neue Freiheiten bei der Auswahl dieser Systeme für Neuanlagen und Anlagenerweiterungen (Bild 3).

Framework bildet die Eigenschaften als digitalen Zwilling ab

Die OT-Vereinfachung ermöglicht die Umsetzung der in Moryx zentralisierten Logik und Algorithmen als funktional klar unterscheid- und somit wiederverwendbare Komponenten. Die Menge der so entstandenen Komponenten bildet den Baukasten, aus dem für jede individuelle Digitalisierungs-Applikation neu ausgewählt und orchestriert werden kann. Denn die erneute Nutzung von Software-Komponenten darf nicht mit übermäßigen Einschränkungen bei der Realisierung individueller Anforderungen einhergehen. Vielmehr erlaubt sie erst die Implementierung solcher Anforderungen, indem sie den Entwicklungsaufwand für den Boilerplate Code und allgemeine Funktionen – etwa die Auftrags- oder Benutzerverwaltung – deutlich reduziert, die ohnehin kein Alleinstellungsmerkmal bilden.

Welche Synergien ließen sich also erschließen, wenn die realisierten Software-Komponenten unternehmensübergreifend wiederverwendbar wären? Und das ohne Harmonisierung der zu integrierenden IT- und OT-Systeme. Mit Moryx Industry bietet Phoenix Contact einen solchen Kickstarter für die Digitalisierung.

Wie genau wird also mit der Moryx-Plattform die Wiederverwendung der genannten zentralisierten und hochintegrierten Logik und Algorithmen möglich? Als Antwort seien die vier Schichten in Moryx angeführt, die jeweils modulare Einzelkomponenten mit starker Kohäsion und loser Kopplung gruppieren (Bild 4). Das Moryx-Framework spannt das cyber-physische System auf, welches die Eigenschaften der herzustellenden Produkte, der durchzuführenden Fertigungsprozesse und der mechatronischen Einheiten in der Fabrik als digitaler Zwilling abbildet. Zu diesem Zweck bietet Moryx das Meta-Modell zum Modellieren der Zwillingstypen und ihrer Abhängigkeiten mit garantierter Konsistenz durch Typprüfungen zur Kompilierzeit. Die Typprüfung eliminiert erstmalig die Dateninkonsistenz als eine der häufigsten Fehlerquellen des Modellierens. Aus den modellierten Typen erzeugt die Moryx-Laufzeitumgebung die Instanzen der Zwillinge, die über den gesamten Lebenszyklus einer Applikation als Repräsentation der digitalen Istzustände der modellierten realen Gegenstände und Prozesse bestehen bleiben. Zur Laufzeit von Moryx-Applikationen fungieren die digitalen Zwillinge des Moryx-Frameworks als Datenquellen und -senken aller darauf aufbauenden Moryx-Schichten.

Module bündeln Logik und Algorithmen

Bei einer dieser Schichten handelt es sich um die Moryx-Module, welche die Logik und Algorithmen zum Ausführen und Steuern der Prozesse in der Fabrik bündeln. Als einzelne Module sind in dieser Schicht zum Beispiel die Ablaufsteuerung von Arbeitsplänen, Transportsteuerung von Werkstückträgern und AGVs (Automated Guided Vehicle) sowie die Bearbeitung und Überwachung von Produktionsaufträgen repräsentiert. Sämtliche Module stellen ihre Dienste über funktionsspezifisch separierte Schnittstellen zur Verfügung, über die sie zur Laufzeit in eine Applikation geladen und miteinander gekoppelt werden. Auf diese Weise lassen sich Module mit geringem Aufwand isoliert testen und separat aktualisieren, was ein Leerfahren von Fertigungslinien verhindert und in Stillständen von unter einer Minute resultiert. Unabhängig von den zum jeweiligen Zeitpunkt geladenen Modulen bleiben die von ihnen genutzten digitalen Zwillinge des Moryx-Frameworks konsistent verfügbar und durch eine Persistenzebene langfristig abgesichert.    

Adapter integrieren in die IT-Systemlandschaft

Digitale Zwillinge sowie die mit ihnen interagierende Logik, Algorithmen und grafische Benutzerschnittstellen im Moryx-Framework und den Modulen stellen bereits einen großen Mehrwert hinsichtlich einer Kostensenkung und Qualitätsverbesserung durch Wiederverwendung dar. Um die Komplexität von Digitalisierungsvorhaben gänzlich zu beherrschen, werden sie durch die Adapter-Schicht zur Einbindung der IT und der Treiber-Schicht für die OT-Integration komplettiert. Die beiden Schichten sorgen für den automatisch synchronisierten Datenaustausch mit der umgebenden Systemlandschaft. Das eliminiert die aufwendige und fehleranfällige menschliche Datenweitergabe und erlaubt die Umsetzung von erneut einsetzbaren Protokollen und Modellen zur Kommunikation mit der Fertigungstechnologie.

Treiber sorgen für die Einbindung der OT-Systeme

Für jede einzelne dieser Technologien und ihren unter Umständen individuellen Kommunikationsmodellen und Datenprotokollen ist in der Moryx-Architektur eine Treiber-Komponenten vorgesehen. Durch die Kapselung in einem dedizierten Treiber kann die Applikationsentwicklung genau die Treiber orchestrieren, die für das jeweilige Szenario notwendig sind. Daraus ergibt sich ein entscheidender Vorteil unter den Gesichtspunkten Entwicklungskosten und Aufwand für die Wartung der Anwendung. Aufgrund der losen Kopplung und damit einem Binding der Treiber mit der Gesamtapplikation erst zur Laufzeit kann überdies das Update neuer Treiber ohne ein Neukompilieren sowie ohne eine neue Gesamtinbetriebnahme durchgeführt werden, weil die restlichen Komponenten unangetastet bleiben. Die beschriebenen Designentscheidungen und Vorteile gelten sowohl für die Adapter- als auch Treiber-Schicht. Einziger Unterschied ist, dass die modularen Adapter für die Einbindung der IT-Systemlandschaft entworfen werden. Sie bündeln hierzu das erforderliche Wissen über die aufzubauenden Kommunikationsprotokolle sowie die auszutauschenden Datenmodelle für jedes zu integrierende IT-System.

Adapter-Schicht zur Einbindung der IT und der Treiber-Schicht für die OT-Integration komplettiert. Die beiden Schichten sorgen für den automatisch synchronisierten Datenaustausch mit der umgebenden Systemlandschaft. Das eliminiert die aufwendige und fehleranfällige menschliche Datenweitergabe und erlaubt die Umsetzung von erneut einsetzbaren Protokollen und Modellen zur Kommunikation mit der Fertigungstechnologie.

Treiber sorgen für die Einbindung der OT-Systeme

Für jede einzelne dieser Technologien und ihren unter Umständen individuellen Kommunikationsmodellen und Datenprotokollen ist in der Moryx-Architektur eine Treiber-Komponenten vorgesehen. Durch die Kapselung in einem dedizierten Treiber kann die Applikationsentwicklung genau die Treiber orchestrieren, die für das jeweilige Szenario notwendig sind. Daraus ergibt sich ein entscheidender Vorteil unter den Gesichtspunkten Entwicklungskosten und Aufwand für die Wartung der Anwendung. Aufgrund der losen Kopplung und damit einem Binding der Treiber mit der Gesamtapplikation erst zur Laufzeit kann überdies das Update neuer Treiber ohne ein Neukompilieren sowie ohne eine neue Gesamtinbetriebnahme durchgeführt werden, weil die restlichen Komponenten unangetastet bleiben. Die beschriebenen Designentscheidungen und Vorteile gelten sowohl für die Adapter- als auch Treiber-Schicht. Einziger Unterschied ist, dass die modularen Adapter für die Einbindung der IT-Systemlandschaft entworfen werden. Sie bündeln hierzu das erforderliche Wissen über die aufzubauenden Kommunikationsprotokolle sowie die auszutauschenden Datenmodell für jedes zu integrierende IT-System.

Plattform fungiert als Datenquelle und Steuerungsschnittstelle

Das dargelegte Paradigma der Wiederverwendung durch die klare Trennung der Zuständigkeiten der lose miteinander gekoppelten Software-Komponenten wird in der Moryx-Plattform durch das zweite Paradigma der Offenheit zu einer nachhaltigen Gesamtlösung vervollständigt. Bestehende heterogene IT- und OT-Systemlandschaften insbesondere in Brownfield-Vorhaben unverändert einbinden zu können, stellt die augenfälligste Ausprägung der Offenheit dar. Separate SaaS-Szenarien (Software as a Service) profitieren ebenfalls davon, indem sie als Cloud- oder On-Premise-Services Moryx als einheitliche Datenschnittstelle zur Fabrik nutzen. Auf diese Weise lässt sich der erneute Aufwand zur individuellen Anbindung der Linien, Maschinen oder Geräte einsparen.

Doch die Moryx-Plattform dient den Services nicht nur als Datenquelle, sondern ebenso als Schnittstelle zum Steuern der Prozesse und Entitäten in der Fabrik. Die Basis dafür bilden die Erkenntnisse und Analysen beispielsweise von KI-Algorithmen oder Analytics-Services. Services also, bei denen hohe Latenzen zwischen Anfrage und Ergebnis keine Auswirkungen auf die Produktivität und Effizienz der Fabrik haben. Um solche Latenzen in der zeitkritischen Prozesssteuerung im Bereich von Hundertstelsekunden zu halten, kann die Moryx-Plattform auf Edge-Devices in der Fabrik oder auf Servern ausgeführt werden. Von der Abarbeitung auf Edge-Devices zieht die Produktivität der Fertigungsanlage einen zusätzlichen Vorteil, da alle für einen Produktionsauftrag relevanten Daten offline in Moryx zur Verfügung stehen – selbst bei stark schwankender Erreichbarkeit und Latenz der sie umgebenden IT-Landschaft.

Offenheit erlaubt den Einsatz .NET-basierter Entwicklungs- und Testumgebungen …

Schließlich ermöglichen die lose Kopplung und die Entwicklung der Moryx-Komponenten auf .Net-Grundlage die Offenheit für den Einsatz etablierter Werkzeuge und Maßnahmen zur Sicherung der Software-Qualität. So kann mit bewährten .NET-basierten Entwicklungs- und Testumgebungen gearbeitet werden, welche die in anderen Software-Domänen seit Jahrzehnten anerkannten Werkzeuge zur Code-Analyse sowie automatisierten und regressionsfähigen Testausführung integrieren. Hierdurch sind die parallele und verteilte Entwicklung und Inbetriebnahme der Moryx-Applikationen durch sämtliche an einem Vorhaben beteiligte Partner technisch und wirtschaftlich darstellbar.

… sowie die Integration von Drittanbieter-Komponenten

Offenheit beschränkt sich nicht nur auf die Moryx-Plattform, sie beschreibt auch die Möglichkeit zur Teilhabe weiterer Partner am Moryx-Ökosystem. So ist das Moryx-Framework seit 2020 als Open Source auf GitHub zur Verwendung und Weiterentwicklung durch die Entwickler-Community veröffentlicht worden. Die unter kommerzieller Lizenz stehenden Moryx-Komponenten der Adapter-, Modul- und Treiberschicht sind ebenfalls auf den gemeinsamen Betrieb mit Moryx-Komponenten anderer Software-Hersteller ausgelegt. Die frei zugänglichen Schnittstellen dieser Komponenten bieten Unternehmen erstmalig die Chance, bei ihren Digitalisierungsvorhaben in der Fabrik mit Moryx auf den nachhaltigen Ansatz der Kombination verschiedener Software-Lieferanten mit jeweils hoher Fachspezialisierung zu setzen. (neu)