Eine auf digitaler Vernetzung beruhende Industrieform kann nur dann wirklich erfolgreich funktionieren, wenn auch ein gemeinsamer Kommunikationsraum existiert. Wenn also sämtliche Teilnehmer ein gemeinsames Verständnis von den für sie relevanten „Dingen“ teilen. Etwas, das auf den ersten Blick selbstverständlich erscheint, es aber keineswegs ist. Die mühsame Arbeit von Organisationen wie der Industrial Digital Twin Association oder der OPC UA Foundation sind Ausdruck für das wachsende Problembewusstsein in Sachen einer einheitlichen Semantik, dennoch kommen viele solcher Vorhaben meist nur schleppend voran. In der Prozessautomation könnte sich das jetzt allerdings ändern. Da momentan nicht nur in Sachen Semantik, sondern auch in puncto herstellerunabhängiger Automatisierung ein Umdenken stattfindet, erhält ein seit Jahren bekanntes Konzept frischen Aufwind: MTP.
MTP funktioniert wie ein Personalausweis für Module
Die Grundidee für das Module-Type-Package-Konzept stammt aus dem Jahr 2014. Sie sieht vor, Anlagenmodule dazu zu befähigen, gegenüber einem übergeordneten Leitsystem selbstständig und maschinenlesbar Auskunft über sich selbst geben zu können. Damit das funktioniert, muss der Modulhersteller, zusätzlich zum physischen Anlagenmodul, eine Beschreibungsdatei (Package) mitliefern, die als eine Art Personalausweis des Moduls verstanden werden kann. Ein MTP-fähiges Prozessleitsystem registriert diese Selbstbeschreibung und steuert das Modul dann mit den genau dafür geeigneten Befehlen an. Da die Kommunikationsbeziehung zwischen Leitsystem und Modul automatisch konfiguriert wird, müssen keine Schnittstellen programmiert oder eingerichtet werden. Herstellerspezifische Abhängigkeiten von Leitsystemen und Modulen oder von Modulen untereinander sind mit dem MTP-Konzept gelöst. Egal, welche Hardware in einem Skid verbaut ist, dank der mitgelieferten Beschreibungsdatei ist ein MTP-fähiges Leitsystem dazu in der Lage, jedes beliebige Modul problemlos und automatisch in die Orchestrierungsebene zu integrieren.
Funktionieren kann dieser Ansatz für eine herstellerunabhängige Interoperabilität von Modulen aber nur dann, wenn für die Selbstbeschreibung der einzelnen Module eine gemeinsame Semantik gefunden wird. Die Art und Weise, wie sich ein Modul mit all seinen Funktionen, Abhängigkeiten, Zuständen, Parametern und Verhaltensweisen dem Leitsystem vorstellt, muss für sämtliche Module herstellerübergreifend einheitlich sein. Das jedoch setzt voraus, dass es einen Konsens darüber gibt, welche physischen oder konzeptionellen Dinge mit bestimmten Benennungen gemeint sind und wie man über diese Dinge zu sprechen hat. Diese Konsensfindung wird von den MTP-Arbeitskreisen in der Namur, ZVEI, VDI und PNO, in denen Vertreter von Modulanbietern, Systemherstellern und Endanwendern versammelt sind, aktiv vorangetrieben.
Die Anlage als Dienstleister
Zugegeben, Semantik ist ein trockenes Thema. Deutlich spannender wird es, wenn man sich die Folgen einer anbieterübergreifend vereinheitlichten Kommunikation von Modulen und Leitsystemen vergegenwärtigt. Denn die Herstellung bestimmter Produkte muss dann nicht länger einseitig von der Apparatur abhängig sein, sondern kann vom Rezept und den von einer Anlage zur Verfügung gestellten Diensten vorgegeben werden. Möglich wird dies, da in der Selbstbeschreibungsdatei eines MTP-Moduls nicht nur Informationen zu Schnittstellen, sondern auch zu den einzelnen Funktionen eines Skids enthalten sind. Im Fall eines Bioreaktors beispielsweise für Befüllen, Vermischen, Temperieren und Entleeren. Da die Selbstbeschreibung des Moduls Bioreaktor dem übergeordneten Leitsystem zu verstehen gibt, dass es die genannten Funktionen für einen Produktionsprozess zur Verfügung stellt (und eben nicht nur die Apparatur Bioreaktor), kann das Leitsystem diese Funktionen auch individuell und unabhängig voneinander aktivieren. Ein MTP-Modul ist damit gleichsam ein Ensemble verschiedener Funktionen oder Dienste, die für veränderbare Produktionsprozesse bedarfsgerecht genutzt werden können. Verriegelungen in der Modulsteuerung verhindern dabei die wahllose und möglicherweise gefährliche Kombination von nicht miteinander kombinierbaren Diensten.
Wird nun also beispielsweise ein Rezept für die Herstellung eines Medikaments formuliert, lassen sich darin bereits Spezifikationen zu Losgrößen oder einzusetzenden Ressourcen festlegen. Entsprechend dieser Angaben können die benötigten Dienste dann so ausgewählt und parametriert werden, dass die erforderliche Produktmenge mit einem möglichst geringen Einsatz von Rohstoffen und Energie herstellbar ist. Für die Herstellung eines anderen Medikaments, also die Abarbeitung eines anderen Rezepts, ist es dann wiederum vergleichsweise einfach, Anlagenmodule in eine neue Reihenfolge zu bringen und die generell verfügbaren Dienste dementsprechend zu nutzen. Diese Art der Flexibilität und Wandelbarkeit ist nur deshalb möglich, da Module und Prozessleitsysteme im Fall von MTP dieselbe Sprache sprechen. Andernfalls wären Umbauten oder Umrüstungen jedes Mal mit enormem Aufwand und kleinteiliger Schnittstellenkonfiguration verbunden.
Unabhängige Middleware für die Orchestrierung von MTP-Modulen
Bleibt ein Problem: Prozessleitsysteme sind keine Programmierumgebungen. Zwar ist ein MTP-fähiges Leitsystem aufgrund der vereinheitlichten Kommunikationsweise in der Lage, das jeweilige MTP-Modul mit all seinen Eigenschaften zu erkennen und korrekt anzusteuern. Die Querkommunikation zwischen den Modulen ist damit aber längst nicht zufriedenstellend geklärt. Während innerhalb der einzelnen Module Steuerungen verbaut sind, die zum Beispiel sicherheitsrelevante Verriegelungen ermöglichen, steht auf der übergeordneten Prozessleitebene lediglich das Leitsystem für die Orchestrierung der verschiedenen Module zur Verfügung. Und dessen Bordmittel für die Etablierung logischer Verknüpfungen sind in der Regel stark limitiert. Will man also die Vorteile von MTP wirklich nutzen, muss sich die Logik zwischen den Modulen unabhängig von den darin verbauten SPS-Steuerungen einrichten lassen.
Wie MTP und IEC 61499 in der Praxis zusammenspielen
Ein Lösungsansatz für dieses Problem kommt beispielsweise von Schneider Electric. Das französische Unternehmen setzt sich seit Jahren für einen herstellerunabhängigen und softwarezentrierten Automatisierungsansatz ein und ist Gründungsmitglied der Universalautomation.org. Die Non-Profit-Organisation ist eine Kooperation aus Unternehmen, Herstellern, OEMs, Start-ups und Universitäten und möchte mit der von ihr verwalteten Technologie die Nutzung eines offenen Automatisierungskonzepts ermöglichen. Der Schlüssel zu dieser herstellerunabhängigen Welt ist die Norm IEC 61499. Sie kann als wesentlicher Baustein für die Entwicklung einer offenen industriellen Automatisierungsumgebung dienen, in der Softwareanwendungen über Hardwareplattformen verschiedener Hersteller hinweg portabel sind.
Schneider Electric hat mit Ecostruxure Automation Expert bereits ein IEC-61499-fähiges Engineering-Tool auf dem Markt. Im Fall des Prozessleitsystems Plant iT von Schneider-Electric-Partner Proleit ist es nun möglich, diese hardwareunabhängige Programmierumgebung Ecostruxure Automation Expert sozusagen als Middleware zwischen MTP-Modulen und Proleit-Leitsystem einzusetzen. Innerhalb dieser Middleware können die MTP-Module in Form grafischer Funktionsblöcke zum gewünschten Verfahren angeordnet werden und die Querkommunikation zwischen den Modulen wird automatisch generiert. Auch Logiken zur Fehlerbehandlung lassen sich in Ecostruxure Automation Expert vergleichsweise einfach hinzufügen.
Herstellerunabhängige Software auf Basis von Universalautomation.org
Das Besondere an dieser Lösung ist nun, dass die prinzipielle Herstellerunabhängigkeit des MTP-Systemaufbaus beibehalten bleibt. Denn da Ecostruxure Automation Expert nicht wie eine gewöhnliche, herstellerspezifisch an eine SPS geknüpfte Programmierumgebung funktioniert, sondern im Sinne von IEC 61499 eine hardware- und herstellerunabhängige Softwareschicht bildet, kann auch die Orchestrierung der MTP-Module mithilfe einer anbieterneutralen Sprache auf der Basis von Universalautomation.org erfolgen. Das Tool von Schneider Electric legt in keiner Weise fest, welche Module von welchem Hersteller stammen müssen oder welches Prozessleitsystem für das Management von Rezepten und Batches zu verwenden ist. Die Middleware ist in puncto Programmierung, Kommunikation und Beziehung zu anderen Anlagenebenen völlig herstellerunabhängig. Insofern stammen die einzelnen Module, Middleware und Prozessleitsystem zwar von verschiedenen Herstellern – der Systemaufbau bleibt jedoch grundlegend offen und ist im Sinne einer herstellerübergreifenden Semantik strukturiert.
Schneider Electric GmbH, Ratingen
Autor: Leif Jürgensen
Global Business Development Manager,
Schneider Electric
