Systematische Instanziierung der P&IDs von Referenzanlagen

Im verfahrenstechnischen Anlagenbau gibt es das Problem, dass ein hoher Engineering-Aufwand aufgrund notwendiger Neukonstruktionen besteht. Dies äußert sich in einem hohen Zeit- und Kostenaufwand im Engineering. Aus diesem Grund lohnt es sich in einem Großteil der Anlagenprojekte, diese ausgehend von einem kundenunabhängig vorentwickelten Modell aufzubauen. Solch ein, als Bezug dienendes, Projekt wird im Folgenden als Referenzprojekt bezeichnet. Diese kundenunabhängigen Vorentwicklungen können ohne jeden konkreten Projektbezug durchgeführt werden.

1 Modulares Datenmodell für Referenzanlagen und Referenz-P&IDs

Der Kern eines solchen Referenzprojektes ist die sogenannte Referenzanlage. Dabei handelt es sich nicht um eine physische Anlage, sondern um eine digital geplante Anlagenstruktur beispielsweise in einem Plant-LM-System. Bild 1 zeigt, wie sich eine Kundenabhängigkeit bei der Projektierung einer Referenzanlage auswirkt. Eine Referenzanlage enthält sämtliche Entitäten, die bereits als auswählbar vordefiniert sind. Diese Bezeichnung der Möglichkeit zur Auswahl aus den mehr als den mindestens notwendigen Entitäten wird symbolisch als „150 %“ festgelegt.

Der Referenzanlage zugehörig ist die sogenannte Basisanlage. Sie stellt die Anteile der Anlage dar, die projektunabhängig sind. Um den Engineering-Aufwand und die damit verbundenen Kosten während eines Projekts möglichst gering zu halten, gilt es den Anteil der Basisanlage an der finalen angepassten Anlage möglichst hochzuhalten. Aus diesem Grund wird für die Basisanlage der symbolische Wert „80 %“ gewählt.

Aufbauend auf der Basisanlage wird aus der zur Verfügung stehenden variablen Auswahl der Referenzanlage und den Kundenanforderungen ein „95 %“-Stand der finalen Anlage in Form einer instanziierten Anlage abgeleitet.

Unter dem Begriff „Instanziierung“ ist somit eine Konkretisierung eines schon bestehenden Modells und explizit keine spezifische Neuentwicklung, zum Beispiel im Sonderanlagenbau zu verstehen.

Um eine angepasste Anlage (100 %) zu erreichen, muss die instanziierte Anlage (95 %) um den Anteil des Customer-Order-Engineerings (COE) ergänzt werden. Dieses COE ist kein Bestandteil der Referenzanlage und muss aufgrund des hohen Engineering-Aufwands auf ein Mindestmaß beschränkt werden (siehe sichelförmiger „5 %“-Anteil in Bild 1).

Eine Referenzanlage kann so als modulares Element „Modulare Anlage“ (MP) nach VDI 2776 – Blatt 1 [1] und Blatt 2 [2] angesehen werden (siehe Bild 1). Die unveränderlichen Bestandteile einer solchen Referenzanlage sind der Basisanlage zugeordnet. In dieser wird ein möglichst hoher Anteil an vorentwickelten prozessbeschreibenden „Process Equipment Assemblies“ (PEAs) eingeordnet. Dadurch wird es möglich, den Engineering-Aufwand einer kundenspezifisch angepassten Anlage zu minimieren. In manchen Fällen kann eine PEA nicht komplett so gestaltet werden, dass all ihre Bestandteile Teil der Basisanlage sind. Dann müssen möglichst viele ihrer enthaltenen funktionalen „Functional Equipment Assemblies“ (FEAs) so gestaltet werden, dass nur eine geringe Anzahl an FEAs nicht zur Basisanlage gehört. Dasselbe gilt für einzelne Komponenten (COMPs), die in FEAs vorkommen und nicht Teil der Basisanlage sind. [1] [2]

Im Folgenden wird die Instanziierung betrachtet, bei der die Bestandteile einer Basisanlage um weitere Entitäten aus dem Pool der Funktionsbausteine einer Referenzanlage erweitert werden, sodass eine instanziierte Anlage mit einem symbolischen Anteil von 95 % erreicht wird. Innerhalb dieser Instanziierung werden notwendige Auswahlentscheidungen für FEAs und COMPs getroffen. Die Prozess- oder PEA-Struktur der Referenzanlage muss dabei unverändert bleiben, sonst kann das Ziel der Minimierung des COE-Aufwandes nicht erreicht werden. Innerhalb des spezifischen COE-Anteils einer Referenzanlage, muss dieser auf ein Minimum beschränkt werden. Dies wird dadurch sichergestellt, dass in der grundlegenden modularen Anlagenstruktur nur noch einzelne COMPs innerhalb von FEAs veränderlich oder anpassbar sind.

Bei einer P&ID-Instanziierung bildet ein Referenz-P&ID eine 150 %-Ausprägung des finalen angepassten P&IDs (100 %). Der Begriff Referenz-P&ID hat einen abstrakten Charakter, weil unter ihm kein einzelnes Dokument zu verstehen ist. Vielmehr ist darunter das Zusammenwirken aus unveränderbaren Bestandteilen und weiteren vorhandenen und somit hinzuwählbaren Entitäten einer Referenzanlage zu verstehen. Diese unveränderlichen Bestandteile, die auf konkreten verschiedenen P&IDs des Referenz-Projektes verteilt sind, werden dem ebenfalls abstrakten Begriff des Basis-P&IDs (80 %) zugeordnet. Das Basis-P&ID ist, ebenso wie das Referenz-P&ID kein wirkliches Dokument, sondern umfasst die auf unterschiedliche P&IDs verteilten unveränderlichen Komponenten der gesamten Anlage.

Die konkret als digitale Dokumente vorliegenden P&IDs, die mit einer neuen Methode automatisiert erweitert werden, werden als Initial-P&IDs bezeichnet.

2 Datentechnische Umsetzung der Instanziierung mittels generalisierender Merkmale

Zur Berücksichtigung der unterschiedlich ausgeprägten Einflüsse verschiedener Gewerke (zum Beispiel Verfahrens- oder Automatisierungstechnik) auf die Entitäten einer Anlage während der Instanziierung eines P&IDs wird im Folgenden eine Lösung aufgezeigt.

Bild 2 zeigt, wie durch drei Grade die Einflüsse unterschiedlicher Gewerke auf den Engineering-Prozess berücksichtigt werden:

• Anpassungsgrad (APG): Der Anpassungsgrad wird genutzt, um anzugeben, wie wahrscheinlich es ist, ob eine einzelne Entität während des Engineering-Prozesses angepasst werden muss. Für die in Bild 1 dargestellte Instanziierungsmethodik wird der APG für Entitäten der Basisanlage mit dem Wert „0 %“ festgelegt, weil dort keine Änderungen vorgesehen sind.
• Customer-Order-Engineering-Grad (COEG): Unter dem COEG ist die Wahrscheinlichkeit zu verstehen, ob ein COE an einer Entität durchgeführt werden muss. Der Bezug zu Bild 1 ist in dem dort ersichtlichen sichelförmigen COE-Anteil (5 %) dargestellt.
• Einbauwahrscheinlichkeitsgrad (EWG): Der Einbauwahrscheinlichkeitsgrad beschreibt, wie wahrscheinlich es ist, dass bei Verfügbarkeit verschiedener einbaubarer Varianten einer Entität diese tatsächlich final in eine Anlage eingebaut wird.

In Bild 3 werden mit Hilfe von linguistischen Variablen Wenn-Dann-Beziehungen zwischen Einflussgrößen und den daraus resultierenden Graden APG, COEG und EWG aufgezeigt. Die Bedeutung der linguistischen Variablen ist in der zugehörigen Legende von Bild 3 festgelegt. Bei Einflussgrößen, die mit allen fünf möglichen linguistischen Variablen bewertet werden können, wird festgelegt, dass bei Bewertung mit einem der Grenzfälle [- -] oder [+ +], diese Einflussgröße als ausschlaggebend für eine Entscheidungsfindung gegenüber den anderen Einflussgrößen gilt.

Um, ausgehend von der Bewertung der festgelegten Einflussgrößen aus Bild 3 einen gesamten APG, EWG und COEG für eine Entität zu bestimmen, sind zwei Bewertungsschritte erforderlich.

Im ersten Schritt muss geprüft werden, ob die Auswertung der Bewertung einer der Einflussgrößen für einen Grad als ausschlaggebend betrachtet wird ([- -] oder [+ +]). Wenn das der Fall ist, gilt diese Einflussgröße als entscheidungsweisend.

Ansonsten muss in einem zweiten Schritt ein Vergleich der ausgewerteten linguistischen Variablen [+], [0] und [-] für die einzelnen Grade vorgenommen werden. Dies erfolgt, indem jeweils die Anzahl der linguistischen Variablen miteinander verglichen werden und die am häufigsten auftretende linguistische Variable als überwiegend angesehen wird. Im Fall einer gleichen Anzahl wird [0] als Mittelwert gewählt.

Um eine Entscheidung darüber treffen zu können, ob eine Entität innerhalb einer Anlage anpassbar ist, lässt sich neben dieser morphologischen Entscheidungsfindung (Bild 3) eine weitere Möglichkeit aufzeigen.

Diese Möglichkeit basiert darauf, dass ein kundenunabhängiges Modell in der Modellierungssprache SysML [3] erstellt wird. Auf systemtechnischer Ebene lassen sich in SysML einem einzelnen Merkmal einer Entität die Formen „public“ und „private“ zuweisen.

Dabei lässt sich die konkrete Unterscheidung, ob ein Merkmal „public“ und somit generell veränderbar ist, oder ob es als „private“ vorliegt, also nicht verändert werden darf, in das Systemmodell integrieren. Durch Vergleich der jeweiligen Anzahl der mit „private“ oder „public“ bewerteten Merkmale lässt sich eine Aussage über die Anpassbarkeit einer Entität ableiten. Die folgende Gleichung (1) dient zur Berechnung dieses Vergleichswertes:

Das Ergebnis aus Gleichung (1) lässt sich unter Verwendung des Bewertungsschemas entsprechend der Legende von Bild 3 in eine linguistische Variable umwandeln. Dieses Vorgehen zur Bestimmung eines prozentualen Anpassungsgrad (APG_%) nach Gleichung (1) gilt insbesondere für physikalische Merkmale (zum Beispiel Durchmesser, Druck, Temperatur, …). Der Bewertung aus technischer Sicht werden die Auswirkungen der festgelegten allgemeinen Einflussgrößen (Bild 3) gegenübergestellt.

Die einzelnen Merkmale der Grade sowie die Einflussgrößen aus Bild 3 entsprechen sogenannten „generalisierenden Merkmalen“. Diese Merkmale haben den Zweck, dass durch ihr datentechnisches Zusammenwirken die gesamte Instanziierung möglichst automatisiert abläuft. Bild 4 zeigt eine Eingabemaske eines Plant-Engineering-Systems, in der alle entwickelten generalisierenden Merkmale dargestellt sind.

3 Erweiterung von P&IDs durch eine erweiterte Nutzung des Proteus-XML-Standards

Im Folgenden wird aufgezeigt, wie eine Erweiterung vorentwickelter Initial-P&IDs um weitere P&ID-Blöcke (zum Beispiel FEAs oder einzelne COMPS) ermöglicht wird. Dies wird durch die Erweiterung des XML-Files nach Proteus-Standard [4] eines Initial-P&IDs umgesetzt. Die Grundlage dafür besteht in einem datentechnischen Zugriff auf die XML-Daten (insbesondere auf die IDs und Symbol-Koordinaten) des P&IDs. Außerdem muss sowohl im Initial-P&ID als auch in den anzuknüpfenden P&ID-Blöcken festgelegt werden, welche Komponenten eine Schnittstellenfunktion zur Anbindung von zusätzlichen Entitäten haben. Diese Festlegung erfolgt über das generalisierende Merkmal „Schnittstellenkomponente“ (Bild 4).

Durch Zugriff auf die X- und Y-Koordinaten eines Anschlusspunktes einer Schnittstellenkomponente des Initial-P&IDs, ist es möglich, diesen fixen Koordinaten-Punkt als Referenzpunkt zum Einfügen von weiteren Entitäten zu definieren. Ausgehend von diesem Referenzpunkt muss dann zunächst ein Mindestabstand (X-, Y-Inkrement) festgelegt werden, an dem die Schnittstellen-Komponente der einzufügenden Entität platziert werden kann. Diese beiden Schnittstellen-Komponenten werden dann beispielsweise mit einer Rohrleitung miteinander verbunden.

Die anzubindende Entität muss außerdem auf einem separaten P&ID definiert sein. Somit kann für diese Schnittstellen-Komponente des anzufügenden P&ID-Blockes, als auch für die weiteren an diese Schnittstellen-Komponente geknüpften Entitäten, die Positionsangabe zum Anfügen geändert werden. Dazu wird zunächst für die einzufügende Schnittstellen-Komponente die Differenz (Gleichung (2), ΔKoord) zwischen den Koordinaten des Einfüge-Punktes auf dem Initial-P&ID (Koord_neu) und den Koordinaten des Punktes der ursprünglichen Position auf dem separaten P&ID (Koord_alt) gebildet (Gleichung (2)).

Dieser Koordinatendifferenz-Wert wird genutzt, um diesen zu allen im anzuhängenden P&ID-XML-Block enthaltenen Positionsangaben (X- und Y-Koordinaten) zu addieren. Dadurch wird jeder einzufügenden Entität eine neue eindeutige Position auf dem zu erweiternden Initial-P&ID zugewiesen.

Eine besondere Funktion nimmt die Rohrleitung zum Verbinden der Schnittstellenkomponente eines Initial-P&IDs mit einem anzufügenden P&ID-Block ein. Diese Funktion wird über das XML-Element <PipingNetworkSystem> im XML-File dargestellt (Bild 6). Konkret geschieht dies über das Kindelement <PipingNetworkSegment>. Dieses XML-Element bietet nach Proteus-Standard die Möglichkeit, durch das XML-Element <Connection> festzulegen, zwischen welchen beiden Entitäten (beispielsweise <Equipment>-XML-Elementen) sich die Rohrleitung befinden soll. [4]

Diese Verbindungsmöglichkeit ist im oberen Bereich von Bild 5 dargestellt (siehe auch XML-Code in Bild 6). Die Zuweisung, welche Entitäten durch die Rohrleitung miteinander verbunden werden sollen, wird durch die Einbindung der eindeutigen IDs dieser Entitäten umgesetzt. Über den Attributwert des XML-Attributes „FromID“ wird die ID der Schnittstellen-Entität des Initial-P&IDs angegeben und über eine „ToID“ die ID der Schnittstellen-Entität des zu ergänzenden P&ID-Blocks (Bild 5).

Eine weitere Möglichkeit, um eine datentechnische Verknüpfung zwischen Schnittstellen unterschiedlicher P&ID-Zeichnungen herzustellen, bieten Blattverweise. In einem Proteus-XML-File ist dies mittels des XML-Elementes <CrossPageConnection> möglich (siehe unterer Bereich in Bild 5). Dabei wird mittels „FromID“ und „ToID“ eine Verknüpfung zwischen zwei IDs hergestellt. An dieser Stelle allerdings zwischen den IDs zweier <PipeConnectorSymbol>-Elemente.

Es ergibt sich somit ein datentechnisch nutzbares Grundkonstrukt für die Verknüpfung von P&ID-Entitäten durch Nutzung und Anpassung der P&ID-XML-Files nach Proteus-Standard.

Bild 6 zeigt das Resultat der beschriebenen notwendigen Anpassungen eines Initial-P&IDs. Stellvertretend für alle hinzuzufügenden Entitäten eines P&ID-Blocks ist eine Schnittstellen-Komponente, zum Beispiel „Plattenwärmetauscher“ als <Equipment>-Element, mit angepassten Positionsangaben enthalten. Außerdem sind zwei <PipingNetworkSystem>-Elemente zur Anbindung des Wärmetauschers und somit des gesamten, an diesen gekoppelten P&ID-Blocks dargestellt. Bei diesen Rohrleitungssystemen wurden die <Connection>-Elemente so angepasst, dass die ID-Bezüge, die bisher zu blattverweisenden <PipeConnectorSymbol>-Elementen bestehen, durch die ID der anzubindenden Entität „Plattenwärmetauscher“ ersetzt werden.

4 Fazit und Ausblick

Durch die erweiterte Nutzung des Proteus-XML-Standards der DEXPI-Initiative wird eine standardisierte Möglichkeit zur automatischen Erweiterung von P&IDs geschaffen.

Die somit sichergestellte Durchgängigkeit der Daten hat eine direkte Reduzierung des Aufwands und der Kosten im Engineering innerhalb aller Anlagenprojekte zur Folge, die basierend auf einer Referenzanlage abgewickelt werden.

Weiteres Forschungspotenzial bietet die Vollendung der datentechnischen Durchgängigkeit durch eine auf den entwickelten Methoden basierenden Programmierung entsprechender Schnittstellen, beispielsweise durch Nutzung des Standards AutomationML [5] im Rahmen der datenverwaltenden „Asset Administration Shell“ (AAS). 

 

 

Literatur

1. [1] VDI 2776 – Blatt 1: 2020–11: Verfahrenstechnische Anlagen – Modulare Anlagen – Grundlagen und Planung modularer Anlagen
2. [2] VDI 2776 – Blatt 2 (Entwurf): 2022–04: Verfahrenstechnische Anlagen – Modulare Anlagen – Design modularer Anlagen
3. [3] Object Management Group: OMG System Modeling Language Version 1.6. URL: https://www.omg.org/spec/SysML/. 2019–11.
4. [4] POSC Caesar Association; Fiatech: P&ID File Specification 3.3.3. URL: https://github.com/ProteusXML/proteusxml/tree/master/additional_documents. 2018–10
5. [5] AutomationML e.V.: What is AutomationML? URL: https://www.automationml.org/about-automationml/automationml/. Abrufdatum 20.09.2022.