Los geht´s!

Mammutprojekt integriertes Engineering

Anlagenbau
Chemie
Pharma
Ausrüster
Planer
Betreiber
Einkäufer
Manager

02.10.2013 Das wird kein Spaziergang, sondern ein steiniger Weg: Industrie 4.0 als Vision eines Internets der Dinge und Dienste und von Cyber-Physical Production zielt auf die Vernetzung von Prozessen, Produkten und Dienstleistungen. In einem solchen Umfeld werden jedoch Informationsflüsse notwendig, die weit über das heute Notwendige hinaus gehen.

Anzeige

Entscheider-Facts Für Planer, Betreiber und Manager

  • Integriertes Engineering bedeutet, dass die Planung und Betreuung aller Systeme und Gewerke des Unternehmens über ein einziges Engineering-Tool beziehungsweise ein zusammenhängendes Toolsystem erfolgt.
  • Zur Realisierung des integrierten Engineerings gibt es zwei grundsätzliche Wege. Der eine besteht darin, Schnittstellen zu vermeiden, indem mit verschiedenen Werkzeugen oder Modulen auf derselben Datenbank gearbeitet wird. Die Alternative besteht darin, standardisierte Schnittstellen zu schaffen, über die die verschiedenen Datenbanken der Werkzeuge Daten austauschen.

Das betrifft mithin nicht nur den Produktionsprozess, sondern alle damit verbundenen Prozesse im Lebenszyklus von Produktionsanlagen – auch das Engineering, also die Planungsphase. Im weiten Verständnis bezeichnet Engineering sämtliche Prozesse zur Dokumentation von Anlagen während ihres gesamten Lebenszyklus von der Planung über die Betriebsphase bis zur Demontage. Von diesem erweiterten Begriff ist hier die Rede: Es geht also um Werkzeuge für die Dokumentation für den gesamten Lebenszyklus von Anlagen. Während der Konstruktion, Planung und Errichtung von Anlagen wird eine große Menge an Daten generiert. Daraus entsteht schließlich ein erstes elektronisches Abbild der Anlage. Dieses wird dann während der Betriebsphase ständig fortgeschrieben und durch Projekte weiter entwickelt. Der Planungsaufwand macht dabei in der Prozessindustrie zehn bis fünfzehn Prozent des Anlagenwertes aus. Die Qualität der dabei erzeugten Daten hat großen Einfluss: nicht nur auf die Geschwindigkeit der Anlagenerrichtung, sondern auch auf Qualität und Kosten der späteren Betriebsbetreuung.
Zur Lösung der anstehenden Aufgabe sowohl in der Planungs-, als auch der Betriebsphase dient eine Vielzahl von unterschiedlichen Engineering-Systemen. Diese sind jeweils für Komponenten, Lebenszyklusphasen oder Gewerke spezialisiert, aber auch auf sie begrenzt. In den Planungs- und Betriebsphasen muss jedoch ein in Ort und Zeit weitgehend uneingeschränkter Informationsfluss zwischen diesen Systemen gewährleistet werden. In Anlehnung an einen Vortrag auf der Namur-Hauptsitzung 2012 wird dafür im Weiteren der Begriff der integrierten Engineering-Systeme verwendet.

Integriertes Engineering: Zusammenschluss
zu einem übergeordneten Ganzen

Integration bezeichnet den Zusammenschluss von unabhängigen Einheiten zu einem übergeordneten Ganzen. Dem entsprechend geht es hier also um den Zusammenschluss unabhängiger Engineering-Werkzeuge zu einem Gesamt-Werkzeug. Die angestrebte Integration reicht über Komponenten-, Lebenszyklus- und Gewerkgrenzen hinaus. Integriertes Engineering würde also beispielsweise bedeuten, dass die Planung und Betreuung aller Systeme und Gewerke des Unternehmens über ein einziges Engineering-Tool beziehungsweise ein zusammenhängendes Toolsystem erfolgt. In dieses werden die Daten der technischen Einrichtungen im gesamten Lebenszyklus nur einmalig eingegeben und während des gesamten Anlagen-Lebenszyklus konsistent gehalten. Umgekehrt gilt freilich auch: Je mehr unabhängige Systeme verwendet werden, in je mehr Systeme dieselben Daten manuell einzugeben und zu pflegen sind, je höher der organisatorische und personelle Aufwand für die Datenkonsistenz ist – desto weiter ist der noch bis zum integrierten Engineerings zurückzulegende Weg.
Warum ist das integrierte Engineering aber meist noch nicht umgesetzt – und  wie komplex ist diese Aufgabe eigentlich? Dazu ist zunächst der sinnvolle Umfang der Integration zu definieren: Welche Komponenten, welche Lebenszyklusphasen, welche Gewerke sollen mit dem integrierten Werkzeug geplant und in der Betriebsphase dokumentiert werden?
Schon die Planung lässt sich in verschiedene Phasen unterteilen: Konzeptplanung, Basic Engineering, Detail Engineering, Errichtung  und Inbetriebnahme. Jede Planungsphase verwendet Daten der vorherliegenden Phasen und detailliert sie weiter. Nur wenn die Daten der früheren Phasen in einem integrierten elektronischen System zur Verfügung stehen, können sie ohne zusätzlichen Aufwand für den Transfer und die Qualitätssicherung in späteren Phasen verwendet werden. Die Planungsphasen sind aber nur in der Theorie aufeinander folgend und einmalig. In aller Regel werden verschiedene Phasen parallel bearbeitet. Es gibt auch ständig Änderungen, die auf die vorhergehende Phase zurückwirken. Jede dieser Umplanungen erfordert wiederum Datentransfers.
Im Übergang von der Planungs- zur Betriebsphase werden dann Planungsdaten benötigt, beispielsweise für die Instandhaltung. Umgekehrt müssen die bei der Inbetriebnahme erzeugten Parametersätze und Betriebspunkte in die As-Built-Dokumentation eingepflegt werden. Während der eigentlichen Betriebsphase entstehen lediglich Daten zur Dokumentation von Instandhaltungsmaßnahmen. Das in der Planung erzeugte elektronische Anlagenabbild wird hier für Dokumentation und Fehlerbehebung benötigt. Es muss daher  immer aktuell und konsistent zur Verfügung stehen. Sobald  im Rahmen der Instandhaltung oder als separates Projekt Verbesserungen oder Erweiterungen erfolgen, wird es ebenfalls benötigt.

Schiffsverkehr auf Engineering-Polynesien
Am Ende des Anlagenlebens dienen schließlich die Unterlagen zur Demontageplanung und zur Dokumentation, die über die Anlagenlebensdauer hinaus aufbewahrt werden muss. Die Anforderung an ein integriertes Engineering gilt also für den gesamten Lebenszyklus von Anlagen. Einen eingängigen Ausdruck für die durch die verschiedenen Engineering-Werkzeuge für Komponenten, Lebenszyklus-Phasen und Gewerke entstehende Engineering-Landschaft hat Biffl geprägt: Er spricht vom Engineering-Polynesien. Im Folgenden werden Anforderungen an die Integration von solchen Engineering-Inseln diskutiert.  
Zwischen den Engineering-Systemen – bildlich: den Engineering-Inseln – ist ein Datenaustausch erforderlich. Dieser erfolgt nicht einmalig, sondern immer wieder und häufig sogar in beide Richtungen. Im Bild: Es müssen Boote zwischen den Inseln hin- und herfahren und Daten transportieren, und zwar nicht kleine Schnellboote, sondern große Fähren mit Tausenden von Daten.
In der realen Welt können die Daten per Telefon übertragen werden, etwa in dem Sinne: „An die PLT: Wir haben den Durchmesser der Rohrleitung xyz von DN50 auf DN80 geändert. Bitte ändert euren Durchflussmesser F1234″. Noch häufiger wird der Austausch per Tabellenkalkulationsblatt sein: „An die PLT: Anbei erhalten Sie Version 15 der nochmals überarbeiteten PLT-Stellen-Bezeichnungen.“ Der Empfänger dieser Tabelle muss dann aus den Hunderten Zeilen die Änderungen heraussuchen und in seine Systeme eingeben. Jeder manuelle Transfer und jeder manuelle Abgleich von Daten ist jedoch auch – wie jede menschliche Arbeit – eine Fehlerquelle. Diese Fehler können große Probleme bei der Inbetriebnahme bis hin zu Nachbesserungsprojekten schaffen. Um sie zu minimieren, müssen umfangreiche Qualitätssicherungsmaßnahmen wie beispielsweise das Vier-Augen-Prinzip eingesetzt werden. Eine weitere Anforderung ist, dass die Schnittstellen das Management des Workflows ermöglichen. Die klare Zuordnung der Daten zu Verantwortlichen (owner) ist unumgänglich. Änderungen müssen nachvollziehbar sein: Wer hat wann was geändert? Die Vergabe diverser Stati wie etwa „freigegeben zum Detail Engineering oder as built“ ist ebenfalls notwendig.

Eine gemeinsame Datenbank oder standardisierte Schnittstellen?
Zur Realisierung des integrierten Engineerings gibt es zwei grundsätzliche Wege. Der eine besteht darin, Schnittstellen zu vermeiden, indem mit verschiedenen Werkzeugen oder Modulen auf derselben Datenbank gearbeitet wird. Die Alternative besteht darin, standardisierte Schnittstellen zu schaffen, über die die verschiedenen Datenbanken der Werkzeuge Daten austauschen. Vorteil des ersten Ansatzes besteht darin, dass Schnittstellen gar nicht erst erforderlich sind. Die Integration leistet der Anbieter der Datenbank sowie der Module, die auf diese Datenbank zugreifen. Nachteil ist, dass man mit der Wahl der Datenbank auf die zugehörige Werkzeugsuite festgelegt ist. Werden zusätzliche Werkzeuge benötigt, sind diese wieder Inseln oder müssen individuell per Schnittstelle angedockt werden.
Der Vorteil des zweiten Ansatzes ist, dass die standardisierten Schnittstellen eine grundsätzliche Offenheit ermöglichen. Damit lassen sich frei wählbare Engineering-Werkzeuge einsetzen – sofern sie nur den Schnittstellenstandard verwenden. Der Nachteil besteht darin, dass eine solche Standardisierung über alle Komponenten, Lebenszyklus-Phasen und Gewerke noch nicht vorhanden ist und einen hohen Aufwand erfordern wird. Außerdem müssen solche Standards über Jahrzehnte stabil oder aufwärtskompatibel sein, um die Anlagenlebensdauer abzudecken. Unmittelbarer Nutznießer eines integrierten Engineerings sind die Betreiber von Anlagen. So lassen sich Projekte billiger, schneller und besser umsetzen. Der Übergang von der Planungs- zur Betriebsphase erfordert dann keinen Dokumentationsaufwand. Obsoleszenzprobleme der Systeme lassen sich durch die geforderte Aufwärtskompatibilität beherrschen.
Bleibt die Frage: Wer von den Anlagenbetreibern kann und wird bei einem solchen Entwicklungsprojekt mitarbeiten? Die einzelnen Unternehmen sicher nicht. Die In-house-Engineering-Abteilungen würden wohl schon Interesse haben, aber nur dann, wenn dafür Entwicklungsgelder vom Konzern zur Verfügung gestellt werden. Einzelne Projekte dürften nicht in der Lage sein, den Entwicklungsaufwand zu tragen. Die Interessen von Engineering-Dienstleistern sind schon nicht mehr so eindeutig. Einerseits erlauben effiziente Entwicklungswerkzeuge eine günstige Projektabwicklung. Offene Standards stehen aber auch den Mitbewerbern zur Verfügung und könnten Know-how-Vorsprünge relativieren. Hinzu kommt: Zumindest kurzfristig gesehen, lässt sich auch mit dem Verkauf von Ingenieurstunden für Datentransfers gutes Geld verdienen. Die Anbieter von CAE-Werkzeugen wiederum versuchen traditionell, möglichst viele Anwendungen im eigenen Haus anzubieten. Sie tendieren also eher zu Systemen mit zentraler Datenbank. Offenheit ermöglicht zwar die  Ankopplung von spezialisierten Fremd-Engineering-Systemen, ist aber keine Einbahnstraße. Sie ermöglicht es auch anderen Anbietern, das eigene Werkzeug als Subsystem anzubinden.
Die Diskussion in den kommenden Jahren wird zeigen, welche Interessengruppen bereit sind, mit welchen Ressourcen das integrierte Engineering voranzubringen. Die Vorteile liegen auf der Hand, und die  technische Entwicklung zum Internet der Dinge schafft zwingende Rahmenbedingungen. Es gilt mithin: „Integriertes Engineering – wann, wenn nicht jetzt!“

Beitrag nach Material der atp 55 (1-2) 2013, zusammengefasst von Ingo Busch, Redaktion Instandhaltung

Den CT-Bericht über die Namur-Hauptsitzung 2012 finden Sie hier

Heftausgabe: Oktober 2013
Dr. Thomas Tauchnitz, Sanofi-Aventis, ist im Vorstand der Namur

Über den Autor

Dr. Thomas Tauchnitz, Sanofi-Aventis, ist im Vorstand der Namur

Dr. Thomas Tauchnitz, Sanofi-Aventis, ist im Vorstand der Namur

Loader-Icon