Firmen im Artikel
Herr Dr. Mersch, Herr Wetzel, im Rahmen der Prozessindustrie 4.0 kommt man kaum um den Begriff des Module Type Package (MTP) herum. Was verbirgt sich dahinter?
Laurids Wetzel: Das MTP ist eine Beschreibung der Schnittstellen eines zugehörigen prozesstechnischen Moduls. Das bedeutet, dass mithilfe dieser Datei – also dem MTP – prozesstechnische Module in einen Gesamtkontext integriert werden können. Dabei werden die Module und deren Funktionalitäten in einem sogenannten Process Orchestration Layer (POL) zusammengeführt und von dort aus orchestriert. Die Funktionalität des POL kann beispielsweise in einem Prozessleitsystem (DCS) abgebildet werden.
Henning Mersch: Das MTP beschreibt also die Kommunikation zwischen POL und den Modulen. Die Module werden dabei als „intelligente“ Einheiten verstanden, die über eine eigene Steuerung verfügen und nur über diese Steuerung mit dem übergeordneten DCS kommunizieren. Das MTP-Konzept ist in der Richtlinie VDI/VDE/Namur 2658 beschrieben.
Prozesstechnische Anlagen werden schon heute häufig modular aufgebaut. Worin liegt der Mehrwert bei der Verwendung des MTP-Konzepts?
Wetzel: Einer der traditionellen Ansätze für modulare Prozessanlagen ist deren rein mechanische Modularisierung. Dies ermöglicht insbesondere einen einfachen Transport, indem die Anlage in ihre Module zerlegt werden kann und sich diese einzeln transportieren und anschließend wieder zusammenbauen lassen. Flexibilität hinsichtlich des Prozesses an sich wird dadurch jedoch nicht erreicht. Das bedeutet, dass man die Anlage zwar in einzelne Module aufteilen, sie jedoch nicht in einer abgeänderten Weise wieder zusammensetzen oder einfach erweitern kann. Dies wird jedoch zunehmend gefordert, da durch kürzere Produktlebenszyklen bestehende Anlagen bzw. Module für die Herstellung anderer Produkte wiederverwendet werden sollen.
Mersch: Heutzutage werden Sensorik und Aktorik teilweise noch direkt oder über einen Systembus an das DCS angeschlossen, wodurch bei einem Umbau der Anlage eine Einzelprojektierung der Prozessstellen in den Modulen erfolgen muss – das wird MTP ändern. Ein weiterer notwendiger Schritt ist daher die Modularisierung der Automatisierung und damit die Kapselung der Steuerungslogik in den einzelnen Modulen. Auch dies wird bereits häufig eingesetzt, allerdings sind dafür proprietäre Schnittstellen notwendig, die zur Steuerung der Module verwendet werden. Das MTP vollendet diese Entwicklung durch eine einheitliche und herstellerunabhängige Definition dieser Schnittstellen. Somit können modulare prozesstechnische Anlagen in kürzester Zeit aus bestehenden Modulen von verschiedenen Herstellern aufgebaut werden. Eine solche Rekombination hat keine größeren Auswirkungen, da lediglich die Orchestrierung und nicht die Steuerungslogik angepasst werden muss.
Mit der Einführung der ELX-Klemmenserie im Jahr 2018 hat Beckhoff sein Produktportfolio für die Prozessindustrie erweitert. Inwiefern trägt Twincat MTP dazu bei?
Wetzel: Bei Beckhoff verstehen wir uns besonders als Systemlieferant für die Modulhersteller. Durch die Einführung der ELX-Klemmenserie bieten wir dem Modulhersteller die Möglichkeit, Sensorik und Aktorik aus Zone 0/20 direkt anzuschließen. In Kombination mit unseren weiteren I/O-Schnittstellen, Steuerungen und Control Panels bieten wir dem Modulhersteller eine vollumfängliche Lösung für den Einsatz von Automatisierungstechnik in explosionsgefährdeten Bereichen. Darüber hinaus ist mit Twincat eine etablierte Engineeringumgebung zur Programmierung des Moduls vorhanden. Twincat MTP ergänzt diese Umgebung nun durch die Möglichkeit zur Moduldefinition, den MTP-Export sowie eine automatische Codegenerierung zur Unterstützung bei der Modulprogrammierung.
Worin sehen Sie die größten Herausforderungen bei der Modulentwicklung?
Mersch: Der Kernpunkt des MTP ist die Standardisierung der Schnittstellen, und damit die Möglichkeit der Interoperabilität. Um diese sicherzustellen, ist es notwendig, dass in der Richtlinie entsprechende Vorgaben zum Verhalten der einzelnen Elemente eines Moduls gemacht werden. Daraus resultiert wiederum, dass der Modulhersteller diese Vorgaben in seinem Modul berücksichtigen und implementieren muss. In der Praxis kann man jedoch nicht erwarten, dass sich jeder Modulentwickler detailliert mit der Richtlinie auskennt. Ziel bei der Entwicklung von Twincat MTP war es daher, dem Modulhersteller möglichst viele Richtlinienanforderungen abzunehmen und diese durch Automatismen zu implementieren. Umgesetzt wird dies vor allem durch die automatische Generierung einer PLC-Vorlage auf Basis der zuvor definierten Modulinformationen des MTP.
Wie kann ein Modulhersteller von Beckhoff mit Twincat MTP konforme Module entwickeln?
Wetzel: Der Workflow zur Entwicklung eines Moduls beginnt zunächst mit der Definition des Moduls im Twincat MTP Engineering. In diesem können alle Modulaspekte, wie z. B. die Dienste (Funktionalitäten) und deren Abhängigkeiten, definiert werden. Da diese Informationen die Schnittstellen des Moduls bereits hinreichend definieren, kann anschließend ein Export des MTP durchgeführt werden. Des Weiteren werden diese Informationen nun zur Generierung der PLC-Vorlage auf Basis der Twincat-MTP-Bibliothek genutzt. Durch das Twincat-XCAD-Interface lässt sich diese Codegenerierung bei Bedarf individuell anpassen. Der vorprojektierte Code wird anschließend durch die Zustandsprogrammierung der zuvor definierten Dienste vervollständigt. Abschließend sorgt Twincat beim Aktivieren der Konfiguration automatisch dafür, dass die Kommunikation vom POL wie im MTP beschrieben über OPC UA aufgebaut werden kann.
Wie kann der Modulhersteller sein P&ID und andere Planungsdaten in den Workflow einbringen?
Mersch: Das MTP bietet zusätzlich die Möglichkeit, einen Visualisierungsbauplan zu hinterlegen. Dies ermöglicht es der POL, eine Gesamtvisualisierung aller Module im gleichen Look-and-feel aus den MTP-Beschreibungen zu erzeugen. Es ergibt daher Sinn, die dafür notwendigen Informationen aus dem P&ID des Moduls zu extrahieren. Anstatt den P&ID-Editor ebenso in Twincat zu integrieren und den Modulhersteller folglich davon abhängig zu machen, haben wir uns für einen offenen Ansatz zum Einbringen der Planungsdaten in den Workflow entschieden. Mit Twincat MTP kann ein unvollständiges MTP, das zuvor von einem P&ID-Editor generiert wurde, importiert und anschließend vervollständigt werden. Alternativ lässt sich ebenso das Twincat-MTP-Automation-Interface nutzen, um proprietäre Datenquellen anzubinden. Das Interface stellt eine Programmierschnittstelle (API) für den Modulhersteller bereit, um den programmatischen Zugriff auf das MTP-Projekt zu ermöglichen. So können existierende Daten von P&ID-Editoren oder Datenquellen verwendet werden, auch wenn diese keinen MTP-Export anbieten. Dadurch kann der Modulhersteller bereits etablierte Tools und Datenbanken weiterhin nutzen.
Gibt es aus Ihrer Sicht noch Aspekte, die im MTP verbessert werden müssten?
Mersch: Die Richtlinie VDI/VDE/Namur 2658 umfasst nach aktuellem Stand die Blätter 1–4. In den kommenden Blättern werden weitere Themen behandelt und als Ergänzung für die bereits bestehenden veröffentlicht. Wichtige Aspekte werden dabei unter anderem die Modul-zu-Modul-Kommunikation, das Safety-MTP, Diagnose/Wartung und Validierung sein. Bereits jetzt ist das Konzept jedoch auf einem ausreichenden Stand, um praxistaugliche Module zu entwickeln und deren Flexibilität voll auszuschöpfen. Durch unsere Mitarbeit im VDI-GMA-Fachausschuss 5.16 kennen wir diese Weiterentwicklungen nicht nur frühzeitig, sondern gestalten sie auch aktiv mit. Das mündet natürlich auch in Weiterentwicklungen für Twincat MTP – ggf. auch in einer frühzeitigen Evaluation.
Beckhoff Automation GmbH & Co. KG, Verl
„Das MTP basiert auf einer einheitlichen und herstellerunabhängigen Definition der Schnittstellen.“
