CHEManager: Herr Dr. Tauchnitz, Sie haben kürzlich auf dem Kongress „Automation 2016“ von Sehnsüchten gesprochen, die Sie im Rahmen von Industrie 4.0 haben – sind das Utopien, konkrete Anforderungen oder gar schon existierende Lösungen im Umfeld moderner Prozessautomation?

Dr. Thomas Tauchnitz: Was ich als „Sehnsucht“ bezeichnet habe, sind wichtige Use Cases für Industrie 4.0 und für die Digitale Transformation. Diese Use Cases sind keine Träumerei, sondern konzeptionell längst möglich. Gemeinsame Voraussetzung dafür sind Schnittstellen zwischen den beteiligten Systemen, die ja auch in anderen Vorträgen auf dem Kongress angesprochen wurden.

CHEManager: Welche Use Cases meinen Sie dabei?

Dr. Tauchnitz: Da ist zum ersten das „Plug and Play für Feldgeräte” …

CHEManager: … Was ja kein ganz neues Thema ist?

Dr. Tauchnitz: Nein, darüber wurde bereits auf der NAMUR-Hauptsitzung 2012 diskutiert. Grundidee ist, den Wechsel eines Feldgerätes mittels „sowieso“ vorhandenen Wissens quasi automatisiert durchzuführen. Dem neuen Gerät muss manuell der Einbauort zugewiesen werden, der Rest sollte automatisch ablaufen.

Meinen zweiten Use Case bezeichne ich mit „Konsistente und aktuelle Dokumentation“. Heute gibt es in jeder Anlage zwei wichtige Datenbanken mit PLT-Stellen-Know how:  Das CAE-Tool, das die R&I-Schemata und die Spezifikationsblätter enthält und die PLT-Stellen verwaltet, und das PLS-Engineering-Tool, das die gleichen PLT-Stellen verwendet. Der Transfer der Daten erfolgt bisher unidirektional über sogenannte Konfi-Listen vom CAE zum PLS-Engineering. Bei größeren Änderungen im CAE-Tool wird eine neue Konfi-Liste erstellt und an das PLS-Engineering gesandt, das dann die Änderungen herausfiltert und nachimplementiert.

Dieser Prozess mag in der Engineering-Phase trotz seiner Umständlichkeit akzeptabel sein – in der Betriebsphase ist er es definitiv nicht. Denn da werden Änderungen häufig direkt am PLS durchgeführt – sonst sind sie nicht wirksam. Aber wie wird sichergestellt, dass die Änderungen im CAE-System korrekt nachgeführt werden? Dies führt dazu, dass die beiden Datenbanken nach und nach auseinander driften. Damit ist die gesetzlich geforderte korrekte Anlagendokumentation nicht zu gewährleisten. Verstärkt wird dieser Effekt häufig noch, wenn Engineering und Betrieb organisatorisch getrennt sind und deshalb mit unterschiedlichen Werkzeugen arbeiten. Auch hier geht es „nur“ um den Transfer sowieso vorhandener Daten.

CHEManager: Spielt hierbei die Wahrung proprietärer Interessen der Anbieter von CAE und PLS eine Rolle?

Dr. Tauchnitz: Jeder Hersteller neigt natürlich dazu, sein eigenes Werkzeug als zentralen Punkt der Datenhaltung zu sehen Auf alle Fälle setzt die Lösung eine gemeinsame Syntax und Semantik voraus, damit sich beide Seiten „verstehen“ – eine Aufgabe, die der globalen Standardisierung bedarf.

Mein dritter Use Case betrifft das seit dem 48. Tutzing-Symposion im Jahr 2009 viel diskutierte Thema “Modularisierung”; ich nenne ihn “Plug and Play für Package Units und Module”. Die Grundidee ist: Man könnte eine Halbierung der Planungs- und Errichtungszeit von Chemieanlagen erreichen, wenn man diese aus vorgefertigten Modulen zusammensetzt. Für die Automatisierungstechnik heißt das: Man bekommt eine große Anzahl von fertig instrumentierten und automatisierten Modulen in die Anlage und muss diese Module dann zu einer funktionsfähigen Gesamtanlage zusammensetzen. Das ist eine sehr aufwändige manuelle Programmieraufgabe, zumal wenn unterschiedliche Automatisierungssysteme eingesetzt werden.

CHEManager: Es werden aber auch in Zukunft nicht nur modulare Anlagen gebaut?

Dr. Tauchnitz: Nein, aber auch wer keine modularisierte Anlage baut, hat in aller Regel Module dabei, meist als Package Units bezeichnet: Kälteaggregate, Zentrifugen, Fermenter …, alle bringen ihre eigene Automatisierung mit. Die Integration geschieht heutzutage mehr oder weniger schlecht durch einzelne weitergeleitete Analog- oder Binärsignale – und zur detaillierten Bedienung oder Störungssuche muss man eben vor Ort gehen und sich in die jeweilige Steuerung „eindenken“. Optimal wäre es, wenn die Bedienung, die Beobachtung und die Störungsinformationen der modularen Steuerungen automatisch ausgelesen und in die überlagerte Steuerung übertragen werden. Dann könnte man das Modul bzw. die Package Unit vom überlagerten System aus so fahren wie vor Ort – ohne jeglichen zusätzlichen Programmieraufwand.

Mein vierter Use Case ist das “Controller Performance Management”, ein inzwischen bewährtes Software-Tool, das das Verhalten der Regelkreise erfasst, analysiert und daraus verbesserte Parametersätze vorschlägt.

Bisher muss ein solches Tool mit dem jeweiligen Leitsystem durch Engineering-Leistung verknüpft werden. Wenn die PLS-Engineering-Tools und auch die historischen Prozessdaten durch offene Schnittstellen zugreifbar sind, wird hier eine vollautomatische App denkbar. Sie wird an das Netz gehängt und sucht sich im Engineering-Tool alle PLT-Stellen mit dem „C“ für Control im PLT-Stellen-Namen heraus. Dort sieht sie auch den Aktor, der durch diese Messstelle angesprochen wird. So kann das Controller Performance Management Tool ohne jeden Engineering-Aufwand die Daten erfassen, auswerten und optimieren. CPM wird so aus der Nische, in der es jetzt seit 20 Jahren ist, zu einem allgemein eingesetzten, hoch wirtschaftlichen Tool.

CHEManager: Dann liegt es nahe, auch “Advanced Process Control” mit einzubinden!

Dr. Tauchnitz: Richtig. APC hat ein ähnliches Schicksal erlebt wie CPM: Eigentlich seit 30 Jahren bekannt, fristet es immer noch ein Nischen-Dasein. Es gibt erfolgreiche Anwendungen, aber sie sind von überschaubarer Zahl. Grund ist, dass hinter jedem gehobenen Regler ein erheblicher manueller Aufwand erforderlich ist. Die Daten müssen aus dem PLS ausgelesen werden, dann wird ein Modell erstellt, ein Regler entworfen und getestet und schließlich implementiert. Etwas lästerlich gesprochen: ein Ph.D.-Controller statt ein PID Controller, weil er den Einsatz engagierter junger Doktoranden erfordert.

Warum eigentlich dieser hohe manuelle und intellektuelle Aufwand? Wenn das CAE-Tool die Prozesszusammenhänge kennt wie Volumina oder Rohrverbindungen und das Leitsystem Jahrzehnte von Prozessdaten – sollte dann nicht vollautomatisch ein stochastisches Modell generiert werden können, das zum Reglerentwurf verwendbar ist? Darüber wurde bereits in den 1980-er Jahren promoviert – jetzt könnte es endlich zur breiten Anwendung kommen.

Als sechsten Use Case sehe ich das “Plant Asset Management”. Auch Plant Asset Management Systeme sind schon lange beschrieben, so stammt z.B. die entsprechende NAMUR-Empfehlung 129 aus dem Jahr 2009. Plant Asset Management ist aber fern davon, ein Standard zu sein. Warum? Der Grund ist ähnlich wie bei APC: Man benötigt Modellkenntnisse, um beispielsweise über die Wärmeübergangskoeffizienten die Beläge eines Wärmetauschers berechnen zu können. Und auch hier wird Industrie 4.0 endlich die Lösung bringen: Eine App kann beispielsweise die typische Wärmebilanzrechnung eines Wärmetauscher generisch kennen. Dann braucht sie nur noch in den jeweiligen R&I-Schemata des CAE-Systems und im PLS zu recherchieren und schon hat man die gesuchten Wärmeübergangskoeffizienten, deren Trend aus den historischen Daten berechnet werden kann. Und wieder hätte man das Wissen über die Anlagen praktisch ohne Aufwand erhöht!

CHEManager: Und was ist der siebte Use Case in Ihrer Liste?

Dr. Tauchnitz: Ich nenne ihn “Site-to-Site Transfer für PLS-Engineering”. Überspitzt gesagt, liegt das meiste Wissen über die Prozesse und die Prozessdynamik in den Prozessleitsystemen versteckt. Hier sind die Regelkreise, die Prozessabläufe. Hier wird während des Anlagenbetriebs immer weiter optimiert. Und besonders wichtig: Hier zumindest ist die Dokumentation stets aktuell, denn eine Prozessänderung wird erst wirksam, wenn sie im PLS implementiert ist.

Doch wie kann eine Firma dieses Wissen, das in den Prozessleitsystemen versteckt ist, nutzen? Solange diese Firma in allen Anlagen gleichen Typs das gleiche Prozessleitsystem verwendet, kann man Softwareblöcke austauschen und vergleichen. Sobald aber verschiedene PLS eingesetzt werden, lässt sich das Prozesswissen der Firma nicht zentral nutzen und weiterentwickeln. Verbesserungen müssen jeweils parallel in den Systemen implementiert werden. Gute Ideen eines Standorts sind nicht übertragbar. Und wenn ein neuer Standort errichtet wird, muss wieder die Software für das Zielsystem geschrieben werden.

Diese Verschwendung von Synergiepotential kann beendet werden, wenn die PLS Engineering-Datenbank mit der CAE-Datenbank gekoppelt ist. Dann kann das Unternehmenswissen in der zentralen CAE-Datenbank gepflegt werden und wird dann in das jeweilige Zielsystem heruntergeladen. Technisch gesehen ist das dieselbe Schnittstelle wie beim Use Case „Konsistente und aktuelle Dokumentation“, aber der Nutzen ist viel größer und strategisch wichtig für die Betreiber-Unternehmen.

CHEManager: Was muss passieren, damit aus Ihren „Sehnsüchten“ Wirklichkeit wird?

Dr. Tauchnitz: Der Weg zur Realisierung führt über standardisierte Schnittstellen zwischen Engineering-Werkzeugen, die übrigens von der NAMUR schon lange gefordert werden, und über Modulare Automatisierung, wobei die Herausforderungen an die Automatisierungstechnik hierbei beträchtlich sind. Generell erfordert Industrie 4.0 ein stärkeres Denken in Modulen, als wir es bisher gewohnt waren. In der Prozessindustrie konnte man sich individuell entworfene Anlagen leisten. Keine Frage: manchmal sind diese Anlagen auch besser als das, was man aus Modulen zusammenbaut. Der verstärkte Kostendruck und steigende Zeit- und Qualitätsanforderungen erlauben es aber immer weniger, das Rad jedes Mal neu zu erfinden. Prinzipiell geht es bei den von mir skizzierten Entwicklungen um das „Zusammenwachsen“ bisher unabhängiger Daten, andererseits um das „zusammen Wachsen“ der Branche.