Home Technology Erweitertes Vorgehensmodell für intentionsbasiertes Engineering und Automatisierung modularer verfahrenstechnischer Anlagen
Article Open Access

Erweitertes Vorgehensmodell für intentionsbasiertes Engineering und Automatisierung modularer verfahrenstechnischer Anlagen

  • Artan Markaj

    Artan Markaj ist Forschungsgruppenleiter am Institut für Automatisierungstechnik in der Fakultät für Maschinenbau der Helmut-Schmidt-Universität/Universität der Bundeswehr Hamburg. Seine Forschungsschwerpunkte liegen in der modularen Automatisierung und dem Engineering verfahrenstechnischer Anlagen.

    EMAIL logo
    , Nicolai Schoch

    Nicolai Schoch ist Senior Scientist bei ABB Corporate Research in Ladenburg, Deutschland. Seine Forschungsinteressen liegen in der Semantik, Modellierung und Analytik in der Automatisierungstechnik.

    , Katharina Stark

    Katharina Stark ist Senior Scientist bei ABB Corporate Research in Ladenburg, Deutschland. Ihre Forschungsinteressen sind Methoden und Werkzeuge im Bereich der Automatisierungstechnik.

    , Mario Hoernicke

    Mario Hoernicke ist Senior Principal Scientist bei ABB Corporate Research in Ladenburg, Deutschland. Sein Forschungsinteresse liegt in der Entwicklung von neuen und innovativen Konzepten für die Automatisierungstechnik.

    and Alexander Fay

    Alexander Fay ist Professor für Automatisierungstechnik und Leiter des Instituts für Automatisierungstechnik in der Fakultät für Maschinenbau der Helmut-Schmidt-Universität/Universität der Bundeswehr Hamburg. Sein Hauptinteresse gilt Beschreibungsmitteln, Methoden und Werkzeugen für ein effizientes Engineering komplexer Automatisierungssysteme.

Published/Copyright: January 13, 2023

Abstract

The modularization of process plants and their modular automation represent innovative concepts to meet the increasing demands for flexibility in plant operation. However, existing approaches to support the engineering of such plants do not focus on the early phases of requirements elicitation and concept design, although these early phases are crucial for the economic efficiency of the later plant. This paper presents a process model for the formalized description of intentions in the early engineering phases of modular process plants. The plant operator creates a formalized model of his intentions and submits it to the module manufacturers in a suitably modularized form. Thus, in the engineering phases, a reduction of effort and an increase in support in the planning and development of the plants are achieved. Furthermore, purpose-specific, required automation functionalities can be defined at an early stage.

Zusammenfassung

Die Modularisierung verfahrenstechnischer Anlagen und deren modulare Automatisierung stellen innovative Konzepte dar, um den steigenden Anforderungen nach Flexibilität im Anlagenbetrieb gerecht zu werden. Bisherige Ansätze zur Unterstützung des Engineerings solcher Anlagen fokussieren aber nicht auf die frühen Phasen der Anforderungserhebung und Konzeptgestaltung, obgleich in diesen frühen Phasen wesentliche Weichen für die Wirtschaftlichkeit der späteren Anlage gestellt werden. In diesem Beitrag wird ein Vorgehensmodell zur formalisierten Beschreibung von Intentionen in den frühen Engineering-Phasen modularer verfahrenstechnischer Anlagen vorgestellt. Hierbei wird durch den Anlagenbetreiber ein formalisiertes Modell seiner Intentionen erstellt und geeignet modularisiert an die Modulhersteller übermittelt. Somit werden in den Engineering-Phasen eine Aufwandsreduzierung und verstärkte Unterstützung in der Planung und Entwicklung der Anlagen erreicht. Weiterhin können frühzeitig zweckgebundene, benötigte automatisierungstechnische Funktionalitäten definiert werden.

1 Einleitung

Die chemische und pharmazeutische Industrie sieht sich größeren Herausforderungen im globalen Wettbewerb ausgesetzt. Zu diesen gehören u.a. immer kürzere Produktlebenszyklen und immer individuellere Kundenanforderungen. In den letzten Jahren wurden Konzepte für modulare verfahrenstechnische Anlagen entwickelt, die als flexible Produktionssysteme einen Beitrag leisten, um diesen Herausforderungen zu begegnen [1, 2]. Die Entwicklung und Implementierung modularer verfahrenstechnischer Anlagen hat auch einen Paradigmenwechsel in der Automatisierung solcher Anlagen veranlasst. Die modulare Automatisierung baut auf einer servicebasierten Struktur auf, bei der die Module verschiedene Services (=Dienste) anbieten und diese vom übergeordneten Leitsystem zu einem Produktionsrezept orchestriert werden [3]. Diese Services werden innerhalb des Module Type Package (MTP) beschrieben [4]. Das MTP dient als Standard für die nahtlose Modulintegration und hat sich in mehreren Pilotprojekten etabliert [5].

Um das Engineering modularer verfahrenstechnischer Anlagen, insbesondere das automatisierungstechnische Engineering, zu unterstützen, wurden in den letzten Jahren verschiedene Beschreibungsmittel, Methoden und Werkzeuge entwickelt. Die Nutzung dieser Hilfsmittel fokussiert bisher jedoch auf einzelne, spätere Engineering-Phasen, wie z.B. Detail Engineering. Im NAMUR-Arbeitsblatt 35 werden verschiedene Input-und Output-Dokumente der Prozessleittechnik (PLT) aufgelistet. Für die Phasen ab dem Basic Engineering finden sich mehrere Richtlinien, Normen und Empfehlungen, wie z.B. die IEC 62881 für die Erstellung von Cause & Effect Matrizen, die DIN EN 62708 zur PLT-Stellenprüfung sowie die IEC 61511 zur Erstellung von Safety Requirements Specifications (SRS) [6]. Die darin vorgestellten Modelle und Vorgehensweisen unterstützen das automatisierungstechnische Engineering verfahrenstechnischer Anlagen, in dem zu nutzende Beschreibungsmittel und Methoden aufgezeigt werden. Die frühen Engineering-Phasen der Anforderungserhebung (Requirements Engineering) und Konzeptausgestaltung (Conceptual Engineering) werden bisher nur unzureichend unterstützt. Hierfür werden häufig informelle Spezifikationen, beispielsweise in Form von Lastenheften (siehe VDI 3694 [7]), genutzt. Diese Phasen spielen jedoch eine elementare Rolle, um die Anlagen den Anforderungen des Betreibers entsprechend zu konzipieren. In den frühen Engineering-Phasen monolithischer Anlagen hat die Automatisierungstechnik insbesondere die Aufgabe, Anforderungen und PLT-Konzepte zu erarbeiten [6]. Mit welchen Beschreibungsmitteln und unter Nutzung welcher Methoden das geschieht, wird nicht spezifiziert. Weiterhin ist unklar, wie die Anforderungen und PLT-Konzepte von den Anforderungen und Konzepten der Gesamtanlage abhängen. Sie sind gekennzeichnet durch verschiedene Designentscheidungen [8], an denen mehrere Disziplinen wie Verfahrenstechnik, Regelungstechnik, Elektrotechnik, Chemie und Betriebswirtschaft beteiligt sind [9]. Treten Fehler oder Unklarheiten in diesen frühen Engineering-Phasen auf, führt das zu häufigeren Iterationsschleifen zwischen den Disziplinen. Diese Iterationsschleifen verlängern das Engineering und führen zu Kostensteigerungen. Fehler, die erst in den späteren Engineering-Phasen entdeckt werden, kosten in der Fehlerbeseitigung ein Vielfaches im Vergleich zur Beseitigung in den früheren Phasen [6]. Dies liegt u.a. daran, dass in den frühen Engineering-Phasen bereits 80% der späteren Kosten auf Grundlage der getroffenen Entscheidungen festgelegt werden [10]. Durch eine frühzeitige Berücksichtigung der Automatisierungstechnik in den frühen Engineering-Phasen können häufige Iterationsschleifen vermieden und Fehler frühzeitig beseitig werden.

In dem vorliegenden Beitrag wird ein Konzept für ein Vorgehensmodell für die frühen Engineering-Phasen modularer verfahrenstechnischer Anlagen aufgezeigt. Dieses Vorgehensmodell basiert auf dem Ansatz des intentionsbasierten Engineerings verfahrenstechnischer Anlagen [11]. Es beinhaltet die Beschreibung und Modellierung von Zielen, Implementierungen und Anforderungen modularer verfahrenstechnischer Anlagen auf Basis von Ontologien. Diese formalisierten, wissensbasierten Beschreibungen werden durch den Anlagenbetreiber erstellt und an die jeweiligen Modulhersteller übermittelt. Der Nutzen des Vorgehensmodells ist hierbei vielseitig: (1) Unterstützung der frühen Engineering-Phasen durch ein systematisches Vorgehen, welches die für die Phasen charakteristischen Iterationen reduziert, (2) Aufwandsreduzierung in den späteren Engineering-Phasen durch die Berücksichtigung von Zielen und Anforderungen sowie der Modellierung der Modulspezifikationen, (3) Verhindern von “Over-Engineering” durch eine zweck- und intentionsbasierte Entwicklung benötigter automatisierungstechnischer Funktionalitäten der Module, (4) frühzeitige, formalisierte Beschreibung zukünftiger Ziele der modularen Anlagen. Durch das Ausschöpfen dieser Vorteile lässt sich das Ziel eines durchgängigen Engineerings modularer Anlagen von den frühen Phasen an erreichen. Im Vergleich zu anderen Ansätzen für das Engineering und die Automatisierung modularer Anlagen fokussiert dieser Beitrag auf die frühen Engineering-Phasen und versucht, die dortige Lücke mit einer systematischen Vorgehensweise zu schließen.

Der Beitrag ist folgendermaßen gegliedert: In Abschnitt 2 werden die Grundlagen modularer Anlagen, deren Engineering und Herausforderungen in den frühen Engineering-Phasen hervorgehoben. Abschnitt 3 fokussiert auf das hier eingeführte Vorgehensmodell für intentionsbasiertes Engineering modularer Anlagen. Hierzu werden zunächst die Grundlagen intentionsbasierter Ansätze im Engineering eingeführt. In Abschnitt 4 wird das Vorgehensmodell an einem Anwendungsbeispiel (Drei-Phasen Separationsanlage) angewendet. Abschnitt 5 befasst sich mit der Leistungsfähigkeit und den Limitationen des Ansatzes, bevor in Abschnitt 6 eine Zusammenfassung des Beitrags und ein Ausblick auf weitere Forschungsaktivitäten gegeben werden.

Der vorliegende Beitrag stellt eine Erweiterung des Beitrags [12] dar. In diesem Beitrag wird das Vorgehensmodell um weitere Ausführungen in den einzelnen Schritten (Abschnitt 3.3) erweitert. Hierzu zählt auch die aktualisierte Version der Intention Ontology. Weiterhin wird das Anwendungsbeispiel in Abschnitt 4 ausgebaut und detaillierter beschrieben. Im neu hinzugefügten Abschnitt 5 werden die Vorteile und Limitationen des Ansatzes kritisch diskutiert.

2 Wissenschaftlicher Hintergrund

Im Kontext modularer verfahrenstechnischer Anlagen sind insbesondere die Richtlinien VDI 2776 Blatt 1 (Verfahrenstechnische Anlagen – Modulare Anlagen – Grundlagen und Planung modularer Anlagen) [13] und die VDI/VDE/NAMUR-Richtlinie 2658 Blatt 1 (Automatisierungstechnisches Engineering modularer Anlagen in der Prozessindustrie – Allgemeines Konzept und Schnittstellen) [4] relevant.

Eine modulare Anlage besteht aus mindestens einem Modul [13]. Ein Modul, eine sogenannte Prozessausrüstungsbaugruppe (PEA), stellt eine automatisierungs-und sicherheitstechnisch unabhängige Prozesseinheit dar [13]. Eine PEA führt einen Prozessschritt aus oder stellt Infrastruktur innerhalb der modularen Anlage zur Verfügung. Mit der Entwicklung modularer verfahrenstechnischer Anlagen wurden Konzepte für deren Automatisierung entwickelt und als neues Paradigma in der Automatisierung etabliert [14, 15]. Der wichtigste Unterschied zwischen der Automatisierung modularer Anlagen und monolithischer (d.h. konventioneller) Anlagen ist die Verwendung von servicebasierter Automatisierung. PEAs bieten Services an, die zu einem Gesamtrezept orchestriert werden [16]. Services kapseln die Prozessfunktionen der Anlagen. Die Anforderungen an die Services werden während des verfahrenstechnischen Engineerings von Prozessingenieuren definiert. Automatisierungsingenieure implementieren und beschreiben diese Services später mithilfe des MTP [4, 16]. Services werden vom Modulhersteller in der Phase des Modul-Engineerings entworfen und implementiert und sollten für ein breiteres Spektrum von Anwendungen geeignet sein [17]. Anschließend wird die Anlage in Betrieb genommen, indem die PEAs in die modulare Anlage integriert werden, sowie deren Dienste orchestriert und ausgeführt werden.

Das Engineering modularer Anlagen kann in zwei Teile unterteilt werden: das Modul-Engineering und das Anlagen-Engineering. Das unterscheidet das Engineering modularer Anlagen vom Engineering konventioneller Anlagen [18]. Im Modul-Engineering wird das Modul durch den Modulhersteller geplant und realisiert sowie das MTP erstellt. Im Anlagen-Engineering erfolgt die physische und informationstechnische Zusammensetzung der Anlage aus den PEAs [17]. Weiterhin kann zwischen dem Neubau von PEAs (z.B. Spezialmodulen) und der Auswahl von vorhandenen PEAs (z.B. Standardmodulen) unterschieden werden. Im späteren Verlauf des Anlagenbetriebs kann die Anlage rekonfiguriert werden und die bestehenden PEAs modifiziert. Die Autoren in [19] beschreiben ein mögliches Vorgehen für das Anlagen-Engineering modularer verfahrenstechnischer Anlagen. Hierbei liegt der Fokus auf einem modulbasierten Planungsansatz für das Basic und Detail Engineering. In [20] wird ein Ansatz vorgestellt, wie verschiedene Austauschformate und Schnittstellen im Engineering verfahrenstechnischer Anlagen ineinander transformiert werden können, um so ein durchgängiges Engineering modularer Anlagen zu erreichen. Im Kern steht hierbei die Anreicherung des MTP aus weiteren digitalen Engineering-Dokumenten. Es wird jedoch darauf verwiesen, dass es für die frühen Engineering-Phasen (z.B. Requirements Engineering) modularer Anlagen keine formalisierten Ansätze zur Unterstützung gibt. Die Autoren in [21] zeigen auf, wie die benötigten Funktionalitäten von PEAs tabellarisch durch den Anlagenbetreiber beschrieben werden können. Services werden hiernach auf Grundlage der Funktionalitäten aufgestellt. Unklar ist jedoch, wie die Funktionalitäten voneinander abhängen und welche Ziele damit verfolgt werden. Die Autoren selbst betonen, dass eine semantische Basis für die Beschreibung der Funktionalitäten fehlt [21]. Es zeigt sich, dass das MTP und die von den PEAs auszuführenden Services ein elementarer Teil des Engineerings modularer Anlagen sind. Während der Modulhersteller diese im Detail entwirft, muss sich der Anlagenbetreiber um eine Spezifikation ebendieser automatisierungstechnischen Services kümmern. Um die passenden PEAs mit den dazugehörigen Services zu spezifizieren und zu finden, bedarf es einer frühzeitigen Definition der benötigten Funktionalitäten. Hierzu muss die Automatisierungstechnik des Anlagenbetreibers bereits frühzeitig involviert werden, wie auch in [21] gefordert. So können bestimmte Abhängigkeiten zwischen den geplanten PEAs aufgedeckt und für die Spezifikation an die Modulhersteller berücksichtigt werden.

Zusammenfassend lässt sich sagen, dass es für die sehr frühen Engineering-Phasen noch keinen Ansatz für eine systematische und wissensbasierte Unterstützung des Engineerings modularer Anlagen gibt. Hier setzt der nachfolgende Ansatz an und bietet eine Erweiterung des aktuellen Stands der Technik. Hierdurch sollen die in Abschnitt 1 aufgezeigten Vorteile erreicht werden.

3 Vorgehen für intentionsbasiertes Engineering modularer Anlagen

Nachfolgend wird das Vorgehen für intentionsbasiertes Engineering modularer Anlagen beschrieben. Hierfür werden zunächst bisherige intentionsbasierte Ansätze im Engineering vorgestellt. Anschließend wird das Konzept für intentionsbasiertes Engineering verfahrenstechnischer Anlagen vorgestellt, welches die Grundlage für das intentionsbasierte Engineering modularer Anlagen im letzten Teil des Abschnitts bildet. Die Nutzung eines intentionsbasierten Ansatzes bringt mehrere Vorteile mit sich. Zum einen kann die Nachvollziehbarkeit von Entscheidungen in den frühen Engineering-Phasen durch (semi-)formale Beschreibung der Zielerreichung erreicht werden. Weiterhin kann geprüft werden, welche Ziele erfüllt, nicht erfüllt oder übererfüllt werden. So können die Intentionen verschiedener Disziplinen im Engineering frühzeitig berücksichtigt und kostenintensive Iterationen zur Fehlerbehebung vermieden werden.

Der Begriff Intention in diesem Beitrag geht auf die Arbeiten von Gollwitzer aus dem Bereich der Sozialpsychologie zurück [22, 23]. Intentionen können auf zwei Ebenen beschrieben werden: Ziel-und Implementierungsebene. Während Zielintentionen abstrakte Ziele darstellen, enthalten Implementierungsintentionen mögliche Lösungskonzepte, um diese Ziele zu erreichen [22].

3.1 Intentionsbasierte Ansätze im Engineering

Die Basis intentionsbasierter Ansätze bildet die Zielmodellierung, die vor allem im Bereich des Software Engineering verwendet wird und Schlussfolgerungen während der Anforderungsanalyse durch Definition und Modellierung von Zielen erlaubt [24]. Die Nachvollziehbarkeit einzelner Systementscheidungen kann hierdurch erhöht werden und weitere Entscheidungen können begründet abgeleitet werden [24]. Für die Modellierung und Analyse von Zielen und deren Abhängigkeiten wurden mehrere Zielmodellierungssprachen entwickelt. Die bekanntesten und am häufigsten verwendeten sind i*, KAOS und Tropos [25]. Durch die Erweiterung dieser Zielmodellierungssprachen haben mehrere Autoren diese im Entwurf kollaborativer cyber-physischer Systeme (CCPS) zur Beschreibung von Zielen ebensolcher CCPS verwendet [26] oder zur Beschreibung serviceorientierter Architekturen und dem Auffinden geeigneter Services [27] eingesetzt.

Im Bereich des Systems Engineering werden Intentionen in Form von Stakeholder-Zielen und Anforderungen in den frühen Phasen mittels geeigneter Diagrammtypen (z.B. SysML-Anforderungsdiagrammen) aufgestellt [28]. Auch im Bereich der Informationssysteme sind intentionsbasierte Ansätze zur Systementwicklung etabliert [29].

In der Automatisierungstechnik werden intentionsbasierte Ansätze insbesondere bei der agentenbasierten Steuerung mit Belief-Desire-Intention (BDI) Agenten verwendet. Sie werden zur Steuerung komplexer und dynamischer High-Level-Management-Systeme eingesetzt, durch Berücksichtigung von Zielen und Aktionen zur Erreichung dieser Ziele [30]. Darüber hinaus basieren Goal-Oriented Control Systems (GOCS) auf intentionsbasierten Ansätzen zur systematischen Entwicklung und Charakterisierung von automatisierungstechnischen Systemen und Verfahren [31, 32]. Ziele werden dabei für den Entwurf und die Charakterisierung von Steuerungssystemen und für die Definition von Steuerungsverfahren für bestimmte Prozesse verwendet.

Aktuelle intentionsbasierte Ansätze wie z.B. GOCS haben einen starken Fokus auf einen bestimmten Aspekt in der verfahrenstechnischen Anlage. Diese Ansätze sind daher auf bestimmte Ingenieursdisziplinen fokussiert und stoßen an ihre Grenzen, sobald sie von einer anderen Disziplin angewendet werden sollen. Der hier vorgestellte Ansatz ist allgemeiner und kann von verschiedenen Disziplinen genutzt werden. Ein weiterer wichtiger Aspekt ist die Integration von intentionsbasierten Ansätzen in die bestehenden verfahrenstechnischen Abläufe. Aktuelle Ansätze fokussieren nicht ausreichend ein durchgängiges Engineering. Außerdem erlauben nicht alle Ansätze, die Ziele genauer zu spezifizieren und Abhängigkeiten zwischen verschiedenen Zielen aufzustellen. Darüber hinaus gibt es keine Verknüpfung zwischen Zielen und den möglichen Implementierungen sowie Anforderungen. Dieser Ansatz kombiniert diese Elemente in einem Modell unter Verwendung verschiedener Abhängigkeitstypen.

3.2 Konzept für intentionsbasiertes Engineering modularer Anlagen

Der von den Autoren entwickelte Ansatz des intentionsbasierten Engineerings verfahrenstechnischer Anlagen beruht darauf, Intentionen der Ingenieurinnen und Ingenieure, die in die Anlagenplanung involviert sind, als Grundlage für ebendiese Anlagenplanung zu nutzen. Hierbei liegt der Fokus auf den frühen Engineering-Phasen. Intentionen können aus mehreren intentionalen Elementen bestehen. Hierbei kann es sich um Ziele (Goals), Implementierungen (Implementations) oder Anforderungen (Requirements) handeln. Vergleichbare Untergliederungen finden sich auch in anderen gebräuchlichen Zielmodellierungssprachen (z.B. i* oder KAOS [25]). Abbildung 1 stellt die Intention Ontology dar, welche die Zusammenhänge zwischen den einzelnen Elementen einer Intention abbildet. Das Modell wurde aus [11] übernommen und erweitert. Aus der Rückmeldung von Experten aus Industrie und Academia wurden insbesondere die Beziehungen zwischen den Modellelementen erweitert.

Abbildung 1: 
Modell der Intention Ontology (basierend auf [11] und wie beschrieben erweitert).
Abbildung 1:

Modell der Intention Ontology (basierend auf [11] und wie beschrieben erweitert).

Eine Intention besteht aus mindestens einem intentionalen Element. Dies können entweder Ziele, Implementierungen oder Anforderungen sein. Einem Ziel können dabei mehrere Implementierungen und/oder Anforderungen zugeordnet werden. Die Zuordnung von Anforderungen zu den Zielen stellt eine Erweiterung des Modells dar, die dadurch begründet ist, dass Ziele durch Anforderungen präzisiert werden können, auch wenn keine generische Implementierung vorliegt (z.B. bei der Neuentwicklung von Prozessen). Implementierungen können wiederum auch mehrere Anforderungen haben. Die Zuordnung der intentionalen Elemente zueinander kann mittels Aggregationsbeziehungen modelliert werden. So ist die Existenz intentionaler Elemente unabhängig voneinander. Weiterhin können die intentionalen Elemente aus Subelementen der gleichen Klasse bestehen. Im erweiterten Modell liegt hier eine Kompositionsbeziehung vor. Wird das Elternelement gelöscht, so werden auch die Kindelemente gelöscht. Besonders im Conceptual Engineering können Ontologien zur Formalisierung der Ergebnisse und des Wissens genutzt werden. Zudem ergibt sich der Vorteil der Wiederverwendbarkeit für zukünftige Engineering-Projekte.

Intentionsbasiertes Engineering verfahrenstechnischer Anlagen basiert auf drei elementaren Schritten: 1. Formulierung von Intentionen unter Nutzung einer kontrollierten natürlichen Sprache [33]; 2. Modellierung von Abhängigkeiten und kausalen Beziehungen zwischen den Elementen; 3. Anlagendesign auf Basis des aufgestellten Intentionsmodells. Für die späteren Engineering-Phasen wie das Basic Engineering und Detail Engineering ist es von Vorteil, die Ergebnisse der früheren Phasen EDV-gestützt und formalisiert weiterverwerten zu können. Dies soll mit dem hier vorgestellten Konzept konsistent sichergestellt werden. Der Anspruch an das Vorgehensmodell ist, dass die verschiedenen Disziplinen in den frühen Engineering-Phasen ihre Intentionen innerhalb eines gemeinsamen Modells (in Form einer Ontologie) beschreiben. Für die Automatisierungstechnik ist es insbesondere relevant, auf Basis der aufgestellten Intentionen (der eigenen sowie der Intentionen anderer Disziplinen), die später zu realisierenden Funktionalitäten formalisiert zu beschreiben. Für die Automatisierungstechnik ergibt sich somit als Anforderung, dass die Funktionalitäten der PEAs so definiert werden, dass sie die Intentionen der Gesamtanlage möglichst vollständig erfüllen. Dies erfordert eine Nachvollziehbarkeit der Abhängigkeiten zwischen den Intentionen und zwischen Intentionen und Funktionalitäten. Weiterhin muss es möglich sein, dass die realisierten Funktionalitäten gegen die Intentionen geprüft werden können.

Während sich die Autoren in [11] auf konventionelle Anlagen konzentrieren, wird im Folgenden der intentionsbasierte Ansatz auf modulare Anlagen angewendet. Für die Anwendung sprechen mehrere Gründe: Erstens hilft die Standardisierung den frühen Engineering-Phasen, die Time-to-Market zu verkürzen, und ermöglicht geringere Kosten für Fehlerbehebung. Dies ist insbesondere relevant, da eines der Hauptziele der Modularisierung eine schnellere Time-to-Market ist und geeignete Ansätze für die frühen Engineering-Phasen fehlen. Weiterhin ist insbesondere für die Automatisierungstechnik die frühzeitige Definition der benötigten Funktionalitäten und Services von Relevanz. Die Funktionalitäten und Services können auf Basis der aufgestellten Intentionen abgestimmt und auf ihre Zielerreichung hin überprüft werden. Darüber hinaus kann eine Wiederverwendung auf Grundlage einer Entscheidungsdokumentation nützlich sein, da sie den Prozess der Wiederverwendung von Informationen, Komponenten usw. unterstützt. Modulare verfahrenstechnische Anlagen sind durch dynamische Anlagenkonfigurationen gekennzeichnet. Daher müssen neue Intentionen für neue Anlagenkonfigurationen mit aktuellen Anlagenkonfigurationen abgeglichen werden. Zum Abgleich gehört auch die Überprüfung der aktuellen Services der PEAs mit den neuen Intentionen. Intentionsbasiertes Engineering bietet einen erweiterbaren und wiederverwendbaren Ansatz, bei dem neue Intentionen in bestehende Intentionsmodelle integriert werden können.

3.3 Anwendung des intentionsbasierten Engineerings auf modulare Anlagen

Die zuvor genannten drei Schritte des intentionsbasierten Engineerings verfahrenstechnischer Anlagen werden aufgegriffen und an das Engineering modularer Anlagen angepasst. Abbildung 2 stellt das adaptierte und erweiterte Vorgehen für intentionsbasiertes Engineering modularer Anlagen dar.

Abbildung 2: 
Vorgehen für intentionsbasiertes Engineering modularer Anlagen (adaptiert von [11]).
Abbildung 2:

Vorgehen für intentionsbasiertes Engineering modularer Anlagen (adaptiert von [11]).

Das Vorgehensmodell wird in Abschnitt 4 anhand des nachfolgenden Anwendungsbeispiels angewendet Leerzeichen. Es wird ein beispielhafter Trennprozesses in der Öl- und Gasindustrie betrachtet, der aus mehreren 3-Phasen-Separatoren besteht. Eine vereinfachte Prozessbeschreibung ist in Abbildung 3 zu finden. Der Prozessschritt der Separation, der das Öl-Gas-Wasser-Gemisch in seine einzelnen Bestandteile auftrennen soll, könnte durch eine Kombination einzelner 3-Phasen Separatoren durchgeführt werden. Das abgetrennte Wasser und das Gas sollen weitere Aufbereitungsprozesse durchlaufen, um eine höhere Qualität zu erreichen. Im Engineering modularer Anlagen würde die Verfahrenstechnik den Prozess funktional modularisieren und zu den einzelnen Prozessschritten PEAs mit geeigneten automatisierungstechnischen Services suchen oder eigens vom Modulhersteller entwickeln lassen. Sowohl die Verfahrens- als auch Automatisierungstechnik haben jeweils andere Intentionen an die Anlage und PEAs, die jedoch von den Intentionen der jeweils anderen Disziplin abhängen. Häufig sind die Intentionen der anderen Disziplin unbekannt und es werden Annahmen hierzu getroffen. Bei modularen Anlagen basiert die Suche nach geeigneten PEAs auf informellen textuellen oder tabellarischen Spezifikationen. Hier ergibt sich die Herausforderung, modulübergreifende und anlagenweite Abhängigkeiten in den Anforderungen zu berücksichtigen. Beispielsweise hat die Verfahrenstechnik die Intention, das separierte Gas aufzubereiten und kontinuierlich abzuführen, was vom Separationsschritt abhängig ist. Die Automatisierungstechnik erhält jedoch nur die Verfahrensbeschreibung zur Gasaufbereitung, ohne die dahinterliegende Intention und Abhängigkeit zum Separationsschritt. Zudem ist schon im Vorhinein festgelegt, welche Prozessschritte von welchen PEAs durchgeführt werden sollen, obwohl andere Kombinationen denkbar wären, die die gleichen Intentionen erfüllen.

Abbildung 3: 
Vereinfachter Separationsprozess in Öl, Gas und Wasser.
Abbildung 3:

Vereinfachter Separationsprozess in Öl, Gas und Wasser.

3.3.1 Formulierung von Intentionen

Im ersten Schritt definiert der Anlagenbetreiber zunächst die Ziele der modularen Anlage, unabhängig von der späteren Realisierung (also unabhängig z.B. von der Art möglicher Module oder der Anzahl der Module). Beispielhaft formulierte Ziele für ein verfahrenstechnischen System können sein: ,,Ich will erreichen, dass das Eingangsprodukt separiert wird“ oder ,,Ich will erreichen, dass der Behälterdruck konstant gehalten wird“. In den gängigen Engineering-Workflows werden vom Anlagenbetreiber User Requirements Specifications (URS) erstellt. Diese sind jedoch eine Kombination aus sehr genauen und weniger genauen Anforderungen sowie bereits geforderten Lösungen. In dem hier vorgestellten Ansatz zeigen Ziele, welche Anwendungsfälle im kurz-, mittel-und langfristigen Bereich durch die modulare Anlage erreicht werden können. Darüber hinaus können sich die Ziele im Laufe des Lebenszyklus einer modularen Anlage ändern und müssen bei einer Neukonfiguration der Anlage angepasst und überprüft werden. Wie bereits erwähnt, werden die Ziele unabhängig von der späteren Implementierung formuliert. Dies liegt an der Möglichkeit unterschiedlicher Anlagenkonfigurationen zur Erfüllung des Ziels.

Nachfolgend können nun zu den Zielen (alternative) Implementierungen aufgestellt werden. Diese spiegeln allgemeines Wissen dar, welches für eine bestimmte Klasse von Problemen Anwendung findet (z.B. standardisierte Module für häufig vorkommende Prozessschritte). Eine Implementierung kann hierbei eine bestimmte Funktionalität, Technologie oder Entscheidung nach modularem versus monolithischem Anlagenteil sein. Für diesen Schritt kann auf allgemeines Wissen zurückgegriffen werden (z.B. PEA-Datenbanken, Prozessfließbilder [34, 35]).

Abschließend werden Anforderungen hinsichtlich der Parameter (für Produkte und Prozessschritte) und benötigter technischer Ressourcen aufgestellt. Die Anforderungen repräsentieren spezifisches Wissen, das für die Planung und Realisierung der spezifischen modularen Anlage vorliegt (z.B. spezifische geforderte Prozessparameter).

3.3.2 Modellierung von Intentionen

Die Intentionen der verschiedenen Disziplinen an die Anlage sind nun innerhalb eines Intentionsmodells zusammengefasst. Abhängigkeiten, wie z.B. zeitliche oder kausale Bedingungen zwischen den intentionalen Elementen, werden modelliert. In Abbildung 4 ist ein beispielhaftes Intentionsmodell dargestellt. Ziel: Achieve constant pressure at gas outlet wird durch die Implementierung: Module with pressure control at gas outlet erfüllt. Das Ziel enthält zudem die Anforderung einen bestimmten maximalen Druck (Anforderung: Max. pressure) zu ermöglichen. Die Implementierung benötigt einen bestimmten Druckregler (Anforderung: Pressure controller). Dieser ist abhängig vom maximal geforderten Druck. Bei der Implementierung könnte es sich auch um ein spezielles Druckregelungsmodul handeln, das den Betrieb mehrerer Abscheider unterstützt. Dieses allgemeine Wissen über Implementierungen kann in einer Domänen-Ontologie abgelegt werden.

Abbildung 4: 
Beispielhaftes Intentionsmodell.
Abbildung 4:

Beispielhaftes Intentionsmodell.

Die Intentionen können von den verschiedenen Disziplinen formuliert werden. So kann die Automatisierungstechnik die Intentionen der Verfahrenstechnik ergänzen, beispielsweise durch Hinzufügen geeigneter Implementierungen zu den Zielen.

3.3.3 Definition möglicher Funktionalitäten und Services

Um eine spezialisierte PEA nach den Intentionen der Anlagenbetreiber zu erstellen, benötigt der Modulhersteller eine Funktionsbeschreibung für die Leistungsentwicklung. Oftmals sind diese Informationen in einer Anforderungsspezifikation, in einem Prozessfließbild oder in textuellen Beschreibungen enthalten. In [36] beschreiben die Autoren, wie aus dem Intentionsmodell abstrakte Servicebeschreibungen abgeleitet werden können. Dies ist vorteilhaft, da der Modulhersteller effizient Services auf der Basis von vordefinierten abstrakten Servicestrukturen und nicht auf textuellen Beschreibungen programmieren kann. Zur Servicebeschreibung kann die die VDI/VDE/NAMUR-Richtlinie 2658 Blatt 4 (Automatisierungstechnisches Engineering modularer Anlagen in der Prozessindustrie – Modellierung von Moduldiensten) [37] herangezogen werden. Die Beschreibung der benötigten Funktionalitäten und Services kann in Zusammenarbeit zwischen Verfahrens- und Automatisierungstechnik vorgenommen werden. Die Implementierung der Services auf Seiten der Modulhersteller geschieht durch die Automatisierungstechnik des Modulherstellers.

Für das Service Design einer PEA können aus dem Gesamtmodell mehrere mögliche Implementierungen und damit verbundene Anforderungen extrahiert werden. Der Anlagenbetreiber kann aus dem Intentionsmodell gewünschte, abstrakte Leistungsbeschreibungen generieren und an den Modulhersteller weiterleiten. Diese Beschreibungen dienen als Grundlage für den Entwurf und die Entwicklung geeigneter Dienste und PEAs. Ein abstrakter Service hat eine Beschreibung seiner Funktionalität zur Erreichung einer bestimmten Intention, wie sie im Intentionsmodell beschrieben ist.

3.3.4 Modularisierung des Intentionsmodells

Ziele innerhalb des Intentionsmodells repräsentieren Anwendungsfälle, in denen ein Modul oder Service genutzt werden kann. Um nun die jeweiligen Anforderungen an die Modulhersteller stellen zu können, muss dieses Intentionsmodell modularisiert werden. Dies unterstützt die Forderung der Autoren von [38] nach einer durchgehenden, modularen Planung und damit auch einem modularisierten Requirements Engineering und Conceptual Engineering.

Für ein verfahrenstechnisches Modul können mehrere mögliche Implementierungen und zugehörige Anforderungen dem Gesamtmodell entnommen werden. Der Anlagenbetreiber kann aus dem Intentionsmodell gewünschte, abstrakte Servicebeschreibungen erzeugen und diese innerhalb eines implementierungsunabhängigen MTP an den Modulhersteller übermitteln. Es gibt Anforderungen, die von einzelnen PEAs erfüllt werden müssen, Anforderungen, die von allen PEAs erfüllt werden müssen, sowie Abhängigkeiten zwischen den Anforderungen der PEAs, die berücksichtigt werden müssen. Der Modulhersteller kann dem Anlagenbetreiber einen oder mehrere alternative Detailentwürfe für die PEA und das MTP zukommen lassen. Hierbei kann durch Mapping des MTP auf die Konzepte und Relationen einer Ontologie evaluiert werden, inwiefern einzelne Anforderungen erfüllt und die Ziele der Gesamtanlage erreicht werden können. Etwaige Konflikte in der Zielerreichung können identifiziert und beseitigt werden.

Die zugrundeliegende Theorie für die Modularisierung des Intentionsmodells basiert auf modularen Ontologien [39, 40]. Eine Ontologie und der zugehörige Wissensgraph können aus einer terminologischen Box (TBox) und einer assertionalen Box (ABox) bestehen. Die TBox beschreibt die Konzepte der Domänen-Ontologie, während die ABox die Individuen oder Fakten in Bezug auf die TBox beschreibt [41]. Der Begriff modulare Ontologie kann auf TBox und ABox angewendet werden. Bei einer modularen TBox wird die Ontologie aus mehreren anderen TBoxen kombiniert, wie z.B. in [42] mit Hilfe von Ontology Design Pattern (ODP) beschrieben. Im Falle einer modularen ABox wird die Ontologie nach ihrer Erstellung in Teilontologien modularisiert, wie in [40] beschrieben. Dieser Beitrag konzentriert sich auf die letztgenannte Definition.

Die ABox A kann als eine Menge von Individuen und Konzeptaussagen C(a) beschrieben werden, wobei a ein Individuum darstellt und C ein Konzept innerhalb der TBox T bezeichnet. Insbesondere bei ,,großen“ ABoxen, die Konzeptaussagen C(a) diverser Themenbereiche enthalten können, erscheint eine Aufteilung in ,,kleinere“ ABoxen und bei Bedarf eine spätere Zusammenführung zu einer ABox sinnvoll. Hierdurch kann Komplexität gekapselt werden und Reasoning-Techniken (zu Deutsch: Schlussfolgerungstechniken) können auf individuelle Teile der ABox angewendet werden [40]. Die Autoren von [40] führen die Möglichkeit des parallelen Reasoning als Vorteil auf. Diese Aufteilung soll im Weiteren als Modularisierung der ABoxen verstanden werden. Ein ABox-Modul A m bildet eine Teilmenge der ABox A ab:

A m A .

Die Autoren von [40] stellen für die Modularisierung einer ABox die Bedingung auf, dass nur Konzeptaussagen in ein ABox-Modul extrahiert werden sollten, wenn sie logische Konsequenzen zu anderen Konzeptaussagen haben. Angewendet auf das Intentionsmodell hätte diese Bedingung zur Folge, dass nur Elemente in das Teil-modell aufgenommen werden, die für das Design einer PEA relevant sind. Alle anderen Informationen (z.B. Ziele anderer PEAs) sollten nicht enthalten sein. Hierfür muss jedes Element innerhalb des Intentionsmodells überprüft werden. Mithilfe vorher festgelegter Regeln lässt sich diese Überprüfung jedoch beschleunigen. So kann beispielsweise nachfolgende Regel zur Zuordnung von Zielen (g – Goal) festgelegt werden:

W E N N g i A m U N D g i h a s S u b G o a l g j , j i

D A N N g j , j i A m .

Wenn ein Ziel g i einem ABox-Modul A m zugeordnet ist, dann sind auch alle weiteren Ziele g j,ji , die ein Sub-Ziel von g i sind (ausgedrückt durch die Object Property hasSubGoal), diesem ABox-Modul zugeordnet. Die resultierende ABox kann durch die Vereinigung der modularen ABoxen A m beschrieben werden, wobei A m mindestens ein Individuum enthält:

A = m ε M A m .

Die ABox-Module können zueinander in Beziehung stehen. Diese Beziehungen müssen bei der Modularisierung betrachtet werden. Dies kann innerhalb einer Alignment Ontologie für die spätere Rekombination der Module berücksichtigt werden. Eine Alignment Ontologie beschreibt, wie verschiedene Ontologien in Beziehung zueinanderstehen und zusammengesetzt werden können. In dem vorliegenden Beispiel liegt die Alignment Ontologie bereits vor. Sie stellt das Intentionsmodell dar, welches die Beziehungen der ABox-Module vor der Modularisierung dargestellt hat.

Wendet man dieses Konzept auf ein bestimmtes Intentionsmodell an, so erfolgt der Modularisierungsprozess durch Zerlegung des Intentionsmodells in kleinere Teilmodelle. Die modularisierte Ontologie kann den später realisierten PEAs innerhalb der modularen Anlage entsprechen. Darüber hinaus wird es Teile der Ontologie geben, die zwar modularisiert sind, aber nicht durch PEAs sondern durch monolithische Anlageninfrastruktur implementiert werden.

Bei der Modularisierung der ABox liegen eine oder mehrere der folgenden Randbedingungen vor:

  1. Die Elemente innerhalb der ABox A können scharf voneinander in verschiedene ABox-Module A m getrennt werden, sodass eine disjunkte Vereinigung vorliegt. Die Elemente lassen sich genau einem ABox-Modul A m zuordnen. Somit sind zwei ABox-Module A 1 und A 2 disjunkt. Im Fall einer ABox des Intentionsmodells werden also intentionale Elemente (Ziele, Implementierungen und Anforderungen) sowie deren Beziehungen zueinander eindeutigen ABox-Modulen zugewiesen.

  2. Die Elemente überlappen sich bei der Modularisierung und werden mindestens zwei ABox-Modulen A m zugeordnet. Es existiert also eine Schnittmenge zwischen zwei ABox-Modulen A 1 und A 2 . Bezogen auf das Intentionsmodell existieren beispielsweise intentionale Elemente, die mehreren ABox-Modulen zugewiesen werden. Das können beispielsweise Anforderungen sein, die für mehrere PEAs relevant sind.

  3. Es existieren Elemente, die keinem ABox-Modul zugeordnet werden. Im Fall des Intentionsmodells entspricht das beispielsweise übergeordneten Zielen, die sich erst durch die Kombination der erreichten Sub-Ziele (durch die PEAs) erreichen lassen. Diese Elemente lassen sich in einem ABox-Modul bündeln und bilden den “Rest”. Gegen diese Bündelung spricht jedoch, dass die darin enthaltenen Elemente wenige bis keine Beziehungen zu einander haben könnten. Aus diesem Grund sehen wir in unserem Ansatz von einer Bündelung ab und ordnen die übrigen Elemente keinem ABox-Modul zu.

Ein Algorithmus zur Modularisierung des Intentionsmodells soll in einem zukünftigen Beitrag detaillierter spezifiziert werden.

Nach der Modellierung von Zielen, Implementierungen und Anforderungen einer PEA innerhalb einer Teilontologie müssen diese Informationen an den Modulhersteller weitergeleitet werden. Derzeit stellen Anlagenbetreiber den Modulherstellern eine URS zur Verfügung. In dem vorgestellten Ansatz werden Informationen über Ziele, Implementierungen und Anforderungen in einer Ontologie (z.B. im .owl-Format) gespeichert. Anforderungsspezifikationen können durch Abfragen an diese Ontologie und den ggfs. darauf aufbauenden Wissensgraphen (z.B. mittels SPARQL-Queries) automatisch abgeleitet und gegengeprüft werden. Durch die Modularisierung des Intentionsmodells kann formal spezifiziert werden, welche Intentionen von welchen PEAs oder PEA-Kombinationen erfüllt werden müssen, um die Ziele der Gesamtanlage zu erreichen. Die Automatisierungstechnik des Modulherstellers erhält keine informelle Verfahrensbeschreibung, sondern kann die automatisierungstechnischen Services auf Basis einer formalisierten Beschreibung und ggf. eines vordefinierten implementierungsunabhängigen MTPs zweckbestimmt realisieren. Abbildung 5 stellt die Modularisierung anhand eines kleinen Beispiels der Separationsanlage schematisch dar. Bestimmte intentionale Elemente werden den zwei potenziellen PEAs (zur Wasser-und Gasaufbereitung) zugeordnet.

Abbildung 5: 
Beispielhafte Modularisierung des Intentionsmodells.
Abbildung 5:

Beispielhafte Modularisierung des Intentionsmodells.

3.3.5 PEA und MTP Design basierend auf Intentionen

Dieser Schritt wird vom Modulhersteller durchgeführt. Der Modulhersteller kann nun damit beginnen, die erforderlichen PEAs und MTPs zu entwerfen. Die Entwicklung der MTPs durch die Automatisierungstechnik des Modulherstellers kann durch die abstrakten Services des Anlagenbetreibers beschleunigt werden. Der Anlagenbetreiber stellt hierbei dem Modulhersteller die in Schritt III. angeforderten abstrakten Services (als funktionale Anforderungen) zur Verfügung.

3.3.6 Konsistenzprüfung

Nach der Erstellung des Detailentwurfs für die PEA und das MTP nach den Vorstellungen des Anlagenbetreibers kann der Modulhersteller einen oder mehrere alternative Entwurfsvorschläge für das Modul und das MTP versenden. Durch die Abbildung des MTP auf die Konzepte und Relationen einer Ontologie kann bewertet werden, inwieweit die individuellen Anforderungen an das Automatisierungskonzept erfüllt und die Ziele des Gesamtsystems erreicht werden können.

Es gibt Intentionen, die von einzelnen PEAs erfüllt werden müssen, Intentionen, die von allen PEAs erfüllt werden müssen, und Abhängigkeiten zwischen den PEA-Intentionen, die berücksichtigt werden müssen. Unter der Annahme, dass verschiedene Modulhersteller (z.B. für die Herstellung der Gasaufbereitungs-PEA und der Separations-PEA) jeweils ihre PEA und MTP an den Anlagenbetreiber liefern, sollten mögliche Zielkonflikte erkannt und beseitigt werden. Werden Inkonsistenzen festgestellt, müssen entweder zusätzliche Änderungen an der PEA oder dem MTP vorgenommen werden, oder, wenn eine PEA oder ein MTP nicht den Intentionen des Anlagenbetreibers entspricht, müssen diese Intentionen neuen PEAs zugeordnet werden.

3.3.7 Anlagendesign basierend auf Intentionen und PEAs

Ein Teil des Anlagenentwurfs erfolgte durch die Unterstützung des Anlagenbetreibers bei der automatischen Ableitung von Teil-oder Gesamtspezifikationen sowie der Definition von Funktionalitäten und abstrakten Services für die PEAs und MTP. Es muss ein Infrastrukturkonzept für die PEAs entworfen und das Gesamtautomatisierungskonzept entwickelt werden. Zu diesem Gesamtautomatisierungskonzept zählt beispielsweise die Automatisierung der Hilfssysteme oder die Spezifikation des Prozessleitsystems. Die jeweiligen Intentionen dafür könnten schon frühzeitig im Intentionsmodell formuliert werden und anschließend unter Berücksichtigung von Abhängigkeiten in späteren Engineering-Phasen ausspezifiziert werden.

Der letzte Schritt aus Abbildung 2 beschreibt den Übergang von den frühen Phasen in das Anlagen-Engineering von modularen Prozessanlagen. Während die frühen Phasen durch das beschriebene Vorgehensmodell für intentionsbasiertes Engineering unterstützt werden, unterstützt das Anlagen-Engineering nicht notwendigerweise die Verwendung von Intentionen, was jedoch von Vorteil sein könnte. Zwei Anwendungsfälle kommen in Frage:

  1. Das Anlagen-Engineering von modularen Prozessanlagen nutzt die vom Modulhersteller erstellten MTPs und orchestriert sie, während die PEAs physisch konfiguriert werden. Dabei können virtuelle und reale Inbetriebnahme-Techniken vor dem Anlagenbetrieb eingesetzt werden. Das Intentionsmodell wird ausschließlich für die frühen Phasen verwendet.

  2. Im Lebenszyklus von modularen verfahrenstechnischen Anlagen wird das Intentionsmodell verstärkt eingesetzt. Hier ist es besonders wichtig, dass das Intentionsmodell für spätere Verifikationen während der Rekonfiguration der modularen Prozessanlagen verwendet wird. Das Intentionsmodell wird als Single Source of Truth im Hinblick auf die dynamischen Anforderungen einer solchen Anlage betrachtet und in diesem Zusammenhang ständig erweitert und modifiziert. Darüber hinaus kann es im Rahmen des ontologiebasierten Engineerings mit anderen Ontologien verknüpft werden, um das Wissen auch in späteren Engineering-Phasen formalisiert darzustellen. Diese Ideen werden in zukünftigen Publikationen weiter vertieft.

4 Anwendungsbeispiel und Ergebnisse

Die einzelnen Schritte des Vorgehensmodells werden angewendet auf das Anwendungsbeispiel aus Abschnitt 3.3, dem Separationsprozess für das Öl-Gas-Wasser-Gemisch. Für den Gesamtprozess und die zukünftige Anlage wird ein Intentionsmodell erstellt und die Anlage in mehrere PEAs aufgeteilt. Für die einzelnen Intentionen werden die MTPs der jeweiligen PEAs erstellt.

In den ersten beiden Schritten (Schritt I. und II.) des Vorgehens (siehe Abbildung 2) formuliert und modelliert der Anlagenbetreiber Intentionen für die gewünschte Anlage. Hierbei werden die Elemente formell in einer Ontologie repräsentiert und beispielsweise durch den Anlagenbetreiber spezifiziert. Ein exemplarischer Ausschnitt des Intentionsmodells ist in Abbildung 6 zu sehen. Das Intentionsmodell wird durch die Verfahrenstechnik erstellt und von weiteren Disziplinen, wie z.B. der Automatisierungstechnik erweitert.

Abbildung 6: 
Ausschnitt aus dem Intentionsmodell.
Abbildung 6:

Ausschnitt aus dem Intentionsmodell.

Im dargestellten Intentionsmodell bildet die Intention0 den Wurzelknoten. Darunter findet sich das Hauptziel der Anlage: Die Produktion der drei Endprodukte Öl, Gas und Wasser (Ziel: Achieve endproducts oil, gas and water). Die drei Endprodukte müssen aus einem Öl-Gas-Wasser-Gemisch durch Separation aufgetrennt werden (Ziel: Achieve well fluid separation into oil, gas and water). Hier besteht die Anforderung, dass der Prozess kontinuierlich ablaufen soll (Anforderung: Conti). Das Ziel lässt sich über zwei Implementierungen erreichen, die beide in der späteren Anlage realisiert werden müssen. Hierzu zählt das Trennen von Öl und Gas (Implemenierung: Oil and gas separation) sowie das Trennen von Öl und Wasser (Implementierung: Oil and water separation). Das Trennen von Öl und Gas kann über mehrere Implementierungsalternativen erfolgen, z.B. über Wärme-, Rühr-oder Schwerkraftseparation. Dieses Wissen (insbesondere über verschiedene Technologien) sollte auch modelliert und konsistent repräsentiert werden, um Reasoning innerhalb der Ontologie zu erlauben. Je nach aufgestelltem Ziel könnten so teilautomatisiert diese Implementierungen hinzugefügt werden. Weiterhin könnten, basierend auf Abhängigkeiten zwischen den intentionalen Elementen, spezifische Implementierungen ausgewählt oder auch ausgeschlossen werden. Die Implementierung Heat hat die Anforderung hinsichtlich der Temperatur, die einen Mindestwert erreichen muss. Neben der Implementierung sind dem Hauptziel auch mehrere Subziele zugeordnet, die ebenfalls erfüllt werden müssen. Intentionen für die Wasser- und Gasaufbereitung werden dem Intentionsmodell hinzugefügt und durch den Anlagenbetreiber weiter spezifiziert. Bei der Wasseraufbereitung sind die Hauptziele die Verbesserung der Wasserqualität (Ziel Optimize water quality) und die Einhaltung der Regularien zur Wasserqualität (Ziel Maintain compliance with water quality laws). Ähnlich wie bei der Wasseraufbereitung sind die Hauptziele bei der Gasaufbereitung das Erreichen einer hohen Gasqualität (Ziel Optimize gas quality) und die Einhaltung der Regularien zur Gasqualität (Ziel 5: Maintain compliance with gas quality laws). Die Ziele zur Einhaltung der Regularien werden von einer anderen Disziplin hinzugefügt (bspw. Experten für Umweltrecht), die ihre Intentionen möglichst frühzeitig in die Planung mitgeben. Sowohl für die Wasseraufbereitung als auch die Gasaufbereitung gibt es jeweils mindestens eine Implementierung (Implementierung: Water purification; Implementierung: Gas purification). Ein weiteres Subziel des Hauptziels ist die kontinuierliche Produktion und Einspeisung von Gas. Dieses Ziel wird von der Verfahrenstechnik vorgegeben und durch Implementierungsmöglichkeiten der Automatisierungstechnik angereichert. Hierbei ergeben sich zwei Regelungsmechanismen, die für die Zielerreichung eingesetzt werden können: Regelung über die Temperatur oder über den Druck (Implementierung: Pressure control; Implementierung: Temperature control). Somit kann eine kontinuierliche Einspeisung mit konstantem Wert (Anforderung: Rate) des Gases in die Gasaufbereitung garantiert werden.

Im nächsten Schritt modelliert der Anlagenbetreiber die Abhängigkeiten zwischen den beabsichtigten Elementen innerhalb des Intentionsmodells. Ein Großteil der Abhängigkeiten ergibt sich durch die Zuordnung von intentionalen Elementen untereinander (z.B. hasImplementation), die Dekomposition von intentionalen Elementen (z.B. hasSubGoal) oder die logische Verknüpfung zwischen intentionalen Elementen (z.B. or). Weiterhin gibt es Abhängigkeiten, die das Erreichen bestimmter Ziele bedingen. So hängt die Zielerreichung der kontinuierlichen Produktion mit bestimmter Rate und die Gasqualität von der Auswahl der Separationstechnologie ab.

Nach der Erstellung des Intentionsmodells müssen Entscheidungen über die bevorzugten Implementierungen getroffen werden. Dazu gehört z.B. die Umsetzung zur Erreichung des Hauptziels unter Nutzung thermischer Energie. Wird diese Implementierung ausgewählt, dann sollte eine Temperatur-basierte Regelung ausgewählt werden. Für die Wasser- und Gasaufbereitung werden auch die jeweiligen Implementierungen ausgewählt. Jede dieser Implementierungen muss später über einen oder mehrere Services realisiert werden. Hierbei wird noch keine Festlegung der PEAs getroffen. Zunächst werden die benötigten Funktionalitäten (Schritt III.) aus dem Intentionsmodell abgeleitet und aufgestellt (hierbei werden die Ontologien, wie in [36] beschrieben, genutzt). Es gilt, dass so viele Funktionalitäten aufgestellt werden müssen, dass alle (funktional erreichbaren) Ziele erreicht werden können. Hierbei müssen etwaige Konflikte (in Form von Abhängigkeiten) zwischen intentionalen Elementen beachtet werden. Fünf Funktionalitäten werden aufgestellt (Oil_and_gas_separation, Oil_and_water_separation, Temperature_control, Gas_purification, Water_purification) und sind den jeweiligen Implementierungen zugeordnet (über die Objectproperty requestsFunctionality). Die Funktionalitäten werden durch die Verfahrenstechnik unter Nutzung der Formalisierten Prozessbeschreibung (FPB) beschrieben. Sie stellen abstrakte Beschreibungen der automatisierungstechnischen Services dar. Die späteren, vom Modulhersteller und der Automatisierungstechnik umzusetzenden Services können hierbei eine n:m Beziehung zu den Funktionalitäten haben.

Nach der Erstellung des Intentionsmodells und der Ableitung der Funktionalitäten sowie der benötigten Services wird das Intentionsmodell entsprechend dem bevorzugten Modulschnitt des Anlagenbetreibers modularisiert (Schritt IV.). Mit anderen Worten, die benötigten Funktionalitäten sind bisher noch nicht PEAs zugeordnet. Sie sind abstrakt in Form eines MTP-Service-“Skeletts”. In diesem Fall wird der bevorzugte Modulschnitt manuell durchgeführt. Es werden fünf PEAs definiert, davon drei PEAs für die Separation, eine PEA für die Gasaufbereitung und eine für die Wasseraufbereitung. Die drei Separations-PEAs sollen identisch aufgebaut werden und somit die modulare Anlage durch Numbering-Up skaliert werden. Hierdurch ergeben sich für die drei Separations-PEAs identische Intentionen, während die Intentionen für die Wasseraufbereitungs-PEA und Gasaufbereitungs-PEA andere sind. Abbildung 7 stellt die Zuordnung des Ziels Achieve continuous gas production and feed zu der Separations-PEA dar. Zudem ist der Implementierung Temperature control die dazugehörige Funktionalität zugeordnet. Die Funktionalität wird im späteren Engineering durch einen oder mehrere Services der Separations-PEA implementiert. In der beispielhaften Darstellung wird die Funktionalität von einem Service implementiert.

Abbildung 7: 
Beispielhafte Zuordnung von intentionalen Elementen zu einer PEA und deren Service.
Abbildung 7:

Beispielhafte Zuordnung von intentionalen Elementen zu einer PEA und deren Service.

Anschließend werden die Intentionen an den Modulhersteller weitergeleitet, wo ein Detailentwurf der PEAs und MTPs erstellt, und an den Anlagenbetreiber geliefert werden (Schritt V.). Hierbei kann der Modulhersteller auch schon fertige Standard-PEAs auf Lager haben, sodass der Detailentwurf nur kleinere Anpassungen enthält. Der Anlagenbetreiber führt eine Konsistenzprüfung durch, um die PEAs mit dem Intentionsmodell zu vergleichen (Schritt VI.). So kann der MTP-Entwurf des Modulherstellers automatisiert gegen das Intentionsmodell geprüft werden. Weiterhin geprüft werden, ob automatisierungstechnische Services den Intentionen und geforderten Funktionalitäten entsprechen. In einem zukünftigen Beitrag soll eine solche automatisierte Konsistenzprüfung vorgestellt werden. Hierbei müssen etwaige Abhängigkeiten zwischen den Intentionen beachtet werden. Im Ausschnitt des Intentionsmodells in Abbildung 6 ist eine Abhängigkeit zwischen dem Ziel der kontinuierlichen Produktion und der Implementierung der Öl-Gas-Separation mittels dependsOn modelliert. Diese Abhängigkeit muss auch in den automatisierungstechnischen Services berücksichtigt werden. Beispielsweise besteht zwischen der Leistung der Gasaufbereitungs-PEA zur Fraktionierung von Gas und den Separations-Services eine Abhängigkeit. Der Service zur Gasaufbereitung und der Service zur Separation müssen aufeinander abgestimmt werden, um die Erreichung des Ziels für die kontinuierliche Produktion und Einspeisung von Gas sicherzustellen.

5 Diskussion

Die Erkenntnisse des Beitrags werden nachfolgend hinsichtlich ihrer Interpretationen, Implikationen und Limitationen bewertet.

Die Ergebnisse des Anwendungsbeispiels zeigen, dass eine systematische und implementierungsunabhängige Entwicklung von benötigten Services eines Separators möglich ist. Es kann gezeigt werden, dass jede später auszuführende automatisierungstechnische Funktion eines Separators einer Intention zugeordnet werden kann. Dies erhöht die Nachvollziehbarkeit der unterschiedlichen Disziplinen im Engineering. So kann nachvollzogen werden, WAS die Services innerhalb der Separatoren leisten sollen und WARUM die Services diese Funktionalität erbringen müssen und WELCHE übergeordneten Anlagenziele dadurch erreicht werden sollen. Zudem kann geprüft werden, ob jede Intention überhaupt erfüllt wird oder “übererfüllt” wird durch die späteren PEAs und deren Services. Letzteres kann vorkommen, wenn mehrere PEAs die gleiche Funktionalität haben (z.B., wenn der Separator schon eine Gasaufbereitung enthält und damit die gleiche Funktionalität anbietet wie die Gasaufbereitungs-PEA). Von den Modulherstellern wird nur das gefordert, was auch zur Zielerreichung beiträgt.

Die in Abschnitt 2 vorgestellten Ansätze für das Engineering und die Automatisierung modularer Anlagen werden in diesem Beitrag ergänzt um eine Vorgehensweise für die frühen Engineering-Phasen. Die Idee eines Typ-basierten Engineerings für MTPs, wie in [43, 44] beschrieben, kann durch den vorgelegten Beitrag gestützt und erweitert werden. So werden nicht erst die MTPs Typ-basiert aufgebaut, sondern es können auch schon die zuvor benötigten Funktionalitäten implementierungsunabhängig, also lösungsneutral, beschrieben werden. Die Funktionalitäten können frühzeitig aufgestellt werden, sodass im Vergleich zu den bisherigen Entwicklungsprozessen die Disziplin der Automatisierungstechnik nicht erst auf die detaillierte Ausarbeitung eines PEA-Entwurfs durch die Verfahrenstechnik warten muss, sondern schon im Vorhinein wiederverwendbare, lösungsneutrale Services aufstellen kann. Das hier vorgestellte Vorgehensmodell berücksichtigt die Design Rationale hinter der Entwicklung von PEAs und der MTPs, sodass nachvollzogen werden kann, was die Services zu leisten haben und warum sie die Funktionalität leisten müssen. Weiterhin zeigt der Beitrag neue Einblicke in die Zusammenarbeit zwischen den unterschiedlichen Disziplinen. In [21] wird das Zusammenspiel der Verfahrens- und Automatisierungstechnik aufgezeigt. Unter Nutzung des intentionsbasierten Engineerings können die geforderten Funktionalitäten in den Gesamtzusammenhang der Intentionen der modularen Anlagen gesetzt werden.

Der vorgestellte Ansatz fördert zwar ein systematisches und wissensbasiertes Vorgehen in den frühen Engineering-Phasen, was zu einer Reduzierung der Iterationsschleifen zwischen den Disziplinen führt, erfordert jedoch einen höheren Aufwand in der Durchführung. Die Autoren verfolgen den Ansatz des Front-End Engineering Design (FEED) bzw. Front-End Loading, bei dem Aufwände späterer Engineering-Phasen in die früheren Phasen verlagert werden. So können der Gesamtaufwand und die damit verbundenen Kosten über das gesamte Engineering hinweg verringert werden. Weiterhin benötigt die Durchführung der Schritte im Vorgehensmodell Modellierungsexpertise, insbesondere im Erstellen und Modularisieren des Intentionsmodells. Die Ingenieure/innen sollen in Zukunft durch geeigneten Tool-Support in der Erstellung der Intentionsmodelle unterstützt werden. Für die Erstellung der Intentionsmodelle wären Wissensdatenbanken, beispielsweise für die Zuordnung von Implementierungen, vorteilhaft. Im Beitrag von [45] werden beispielhafte Implementierungen für verschiedene verfahrenstechnische Equipments vorgestellt. Neben solchen Datenbanken können Domänenontologien in der Intentionsmodellierung zur Verringerung der Ambiguität beitragen. Derzeit können die Intentionen jegliche Bezeichnungen annehmen (z.B. Product separation). Eine einheitliche Semantik in den Zielen, Implementierungen und Anforderungen fördert ein disziplin- und unternehmensübergreifendes Verständnis der Intentionen. Die Anwendbarkeit, Skalierbarkeit und Generalisierbarkeit des Ansatzes muss zukünftig anhand eines komplexeren Anwendungsbeispiels aufgezeigt werden. Zudem müssen die Vorteile der Wiederverwendung und Integration in bestehende Konzepte illustriert werden.

6 Zusammenfassung und Ausblick

Durch die Anwendung des intentionsbasierten Engineering-Ansatzes auf modulare verfahrenstechnische Anlagen können in den frühen Phasen des Engineerings Intentionen formalisiert aufgestellt und an die jeweiligen Fachdisziplinen und Lieferanten (z.B. Modulhersteller) übermittelt werden. Zudem können erste Strukturen für die spätere modulare Automatisierung in Form von abstrakten Servicestrukturen aus dem Intentionsmodell erzeugt werden. Hierdurch können die Planung und Entwicklung modularer verfahrenstechnischer Anlagen und deren Automatisierung formalisiert von den frühen Phasen an unterstützt werden.

Das in [11] beschriebene intentionsbasierte Engineering für verfahrenstechnische Anlagen wurde als Grundlage für die frühen Phasen des Engineerings von modularen verfahrenstechnischen Anlagen herangezogen. Der in [11] beschriebene Ansatz wurde an die Rahmenbedingungen von modularen Anlagen angepasst. Der Ansatz wurde an einer aus fünf PEAs bestehenden Drei-Phasen Separationsanlage angewendet. Das Anwendungsbeispiel zeigte, dass eine systematische und implementierungsunabhängige Gestaltung der erforderlichen Services eines Separators möglich ist. Dies geschieht durch die ontologiebasierte Modellierung von Intentionen und die Ableitung von Funktionalitäten für jede PEA. Der intentionsbasierte Ansatz unterstützt verschiedene Situationen im Engineering modularer Anlagen. Beim Neubau von Modulen (z.B. Spezialmodulen) kann der Anlagenbetreiber spezifisch formulieren und modellieren, welche Intentionen durch die zu entwickelnden PEAs realisiert werden sollen. Bei der Auswahl bereits vorhandener PEAs (z.B. Standardmodule) kann ein Abgleich des MTP mit den geforderten Funktionalitäten zur Erfüllung der Intentionen des Anlagenbetreibers vorgenommen werden. Kommen neue Intentionen hinzu (z.B. durch neue Produktionskampagnen), kann das Intentionsmodell erweitert werden. Vorhandene PEAs können gegen das neue Intentionsmodell geprüft werden, um so zu ermitteln, ob Änderungen vorgenommen werden müssen.

Der Ansatz des intentionsbasierten Engineering soll an verschiedenen Anlagentypen, wie den in [46] beschriebenen hybriden Anlagen, angewendet werden. Dies erscheint vorteilhaft, da der intentionsbasierte Ansatz von einem implementierungsunabhängigen Punkt ausgeht, an dem die Modularität eines Systems noch nicht festgelegt ist. Die abstrakten, formalisierten Service-und Modulrepräsentationen sollen unter anderem als Spezifikationen dienen, die wiederum für die Modulauswahl und die Modul-zu-Modul-Pipeline-Generierung verwendet werden, wie in [47] beschrieben. Weiterhin kann Reasoning verwendet werden, um mögliche PEAs gegen die Intentionen zu prüfen. Zudem wird zur automatischen Modularisierung einer Ontologie ein Algorithmus entwickelt.


Corresponding author: Artan Markaj, Helmut-Schmidt-Universität/Universität der Bundeswehr Hamburg, Institut für Automatisierungstechnik, Holstenhofweg 85, 22043 Hamburg, Deutschland, E-mail:

Über die Autoren

Artan Markaj

Artan Markaj ist Forschungsgruppenleiter am Institut für Automatisierungstechnik in der Fakultät für Maschinenbau der Helmut-Schmidt-Universität/Universität der Bundeswehr Hamburg. Seine Forschungsschwerpunkte liegen in der modularen Automatisierung und dem Engineering verfahrenstechnischer Anlagen.

Nicolai Schoch

Nicolai Schoch ist Senior Scientist bei ABB Corporate Research in Ladenburg, Deutschland. Seine Forschungsinteressen liegen in der Semantik, Modellierung und Analytik in der Automatisierungstechnik.

Katharina Stark

Katharina Stark ist Senior Scientist bei ABB Corporate Research in Ladenburg, Deutschland. Ihre Forschungsinteressen sind Methoden und Werkzeuge im Bereich der Automatisierungstechnik.

Mario Hoernicke

Mario Hoernicke ist Senior Principal Scientist bei ABB Corporate Research in Ladenburg, Deutschland. Sein Forschungsinteresse liegt in der Entwicklung von neuen und innovativen Konzepten für die Automatisierungstechnik.

Alexander Fay

Alexander Fay ist Professor für Automatisierungstechnik und Leiter des Instituts für Automatisierungstechnik in der Fakultät für Maschinenbau der Helmut-Schmidt-Universität/Universität der Bundeswehr Hamburg. Sein Hauptinteresse gilt Beschreibungsmitteln, Methoden und Werkzeugen für ein effizientes Engineering komplexer Automatisierungssysteme.

  1. Author contributions: All the authors have accepted responsibility for the entire content of this submitted manuscript and approved submission.

  2. Research funding: None declared.

  3. Conflict of interest statement: The authors declare no conflicts of interest regarding this article.

Literaturverzeichnis

[1] T. Bieringer, S. Buchholz, and N. Kockmann, “Future production concepts in the chemical industry: modular – small-scale – continuous,” Chem. Eng. Technol., vol. 36, no. 6, pp. 900–910, 2013. https://doi.org/10.1002/ceat.201200631.Search in Google Scholar

[2] M. Eilermann, C. Post, H. Radatz, C. Bramsiepe, and G. Schembecker, “A general approach to module-based plant design,” Chem. Eng. Res. Des., vol. 137, pp. 125–140, 2018. https://doi.org/10.1016/j.cherd.2018.06.039.Search in Google Scholar

[3] H. Bloch, T. Grebner, A. Fay, et al.., “Orchestration of services in modular process plants,” in IECON 2018 – 44th Annual Conference of the IEEE Industrial Electronics Society, 2018, pp. 2935–2940.10.1109/IECON.2018.8591300Search in Google Scholar

[4] VDI/VDE/NAMUR 2658-1: Automatisierungstechnisches Engineering modularer Anlagen in der Prozessindustrie: Allgemeines Konzept und Schnittstellen. VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik (GMA), 2017.Search in Google Scholar

[5] J. Bernshausen, A. Haller, H. Bloch, et al.., “Plug & Produce auf dem Sprung in den Markt,” ATP, vol. 61, nos. 1–2, pp. 56–69, 2019. https://doi.org/10.17560/atp.v61i1-2.2400.Search in Google Scholar

[6] NAMUR-Arbeitsblatt 35: PLT-Planung und -Abwicklung in der Prozessindustrie. NAMUR-ad hoc Arbeitskreis zur NA 35 im Arbeitsfeld AF1, 2019.Search in Google Scholar

[7] VDI/VDE 3694: Lastenheft/Pflichtenheft für den Einsatz von Automatisierungssystemen. VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik (GMA), 2014.Search in Google Scholar

[8] M. M. Martín, Industrial Chemical Process Analysis and Design, Amsterdam, Elsevier, 2016.10.1016/B978-0-08-101093-8.00002-1Search in Google Scholar

[9] F. P. Helmus and C. Ahner, Process Plant Design: Project Management from Inquiry to Acceptance, Weinheim, Wiley VCH, 2008.10.1002/9783527621569Search in Google Scholar

[10] K. G. Topole, Grundlagen der Anlagenplanung: Einstieg in den Anlagenbau mit zahlreichen Praxisbeispielen, Berlin, Springer, 2018.10.1007/978-3-662-57418-8Search in Google Scholar

[11] A. Markaj, N. Schoch, K. Stark, M. Hoernicke, and A. Fay, “Intention-based engineering for process plants,” in 2022 IEEE International Systems Conference (SysCon), 2022, pp. 1–8.10.1109/SysCon53536.2022.9773910Search in Google Scholar

[12] A. Markaj, N. Schoch, K. Stark, M. Hoernicke, and A. Fay, “Intentionsbasiertes Engineering für die frühen Planungsphasen modularer verfahrenstechnischer Anlagen und deren Automatisierung,” in EKA 2022 – Entwurf komplexer Automatisierungssysteme, Institut für Automation und Kommunikation e.V., An-Institut der Otto-von-Guericke-Universität Magdeburg, Magdeburg, 2022.10.1515/auto-2022-0101Search in Google Scholar

[13] VDI 2776-1: Verfahrenstechnische Anlagen - Modulare Anlagen: Grundlagen und Planung modularer Anlagen. VDI-Gesellschaft Verfahrenstechnik und Chemieingenieurwesen (GVC), 2019.Search in Google Scholar

[14] J. Ladiges, A. Fay, T. Holm, et al.., “Integration of modular process units into process control systems,” IEEE Trans. Ind. Appl., vol. 54, no. 2, pp. 1870–1880, 2018. https://doi.org/10.1109/tia.2017.2782679.Search in Google Scholar

[15] H. Bloch, A. Fay, and M. Hoernicke, “Analysis of service-oriented architecture approaches suitable for modular process automation,” in 2016 IEEE 21st International Conference on Emerging Technologies & Factory Automation (ETFA), 2016, pp. 1–8.10.1109/ETFA.2016.7733651Search in Google Scholar

[16] H. Bloch, S. Hensel, M. Hoernicke, et al.., “State-based control of process services within modular process plants,” in 51st CIRP Conference on Manufacturing Systems, 2018, pp. 1088–1093.10.1016/j.procir.2018.03.037Search in Google Scholar

[17] T. Holm, M. Obst, A. Fay, et al.., “Engineering method for the integration of modules into fast evolving production systems in the process industry,” in 2015 IEEE International Conference on Automation Science and Engineering (CASE), Gothenburg, Sweden, 2015, pp. 1042–1047.10.1109/CoASE.2015.7294236Search in Google Scholar

[18] M. Obst, T. Holm, L. Urbas, et al.., “Semantic description of process modules,” in 2015 IEEE 20th Conference on Emerging Technologies & Factory Automation (ETFA), 2015, pp. 1–8.10.1109/ETFA.2015.7301440Search in Google Scholar

[19] C. Fleischer-Trebes, N. Krasberg, C. Bramsiepe, and N. Kockmann, “Planungsansatz für modulare Anlagen in der chemischen Industrie,” Chem. Ing. Tech., vol. 89, no. 6, pp. 785–799, 2017. https://doi.org/10.1002/cite.201600083.Search in Google Scholar

[20] J. Rahm, M. Theißen, A. Klose, et al.., “Efficient automation engineering of modular process equipment assemblies using the digital twin,” Chem. Ing. Tech., vol. 93, no. 12, pp. 2081–2091, 2021. https://doi.org/10.1002/cite.202100100.Search in Google Scholar

[21] VDI-Gesellschaft Verfahrenstechnik Chemieingenieurwesen (GVC) und VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik (GMA), “Modulare Anlagen – Paradigmenwechsel im Anlagenbau: Zusammenspiel von Prozesstechnik und Automatisierungstechnik: VDI-Handlungsempfehlung,” pp. 1–36, 2022.Search in Google Scholar

[22] P. M. Gollwitzer, “Goal achievement: the role of intentions,” Eur. Rev. Soc. Psychol., vol. 4, no. 1, pp. 141–185, 1993.10.1080/14792779343000059Search in Google Scholar

[23] P. M. Gollwitzer and P. Sheeran, “Implementation intentions and goal achievement: a meta-analysis of effects and processes,” Adv. Exp. Soc. Psychol., vol. 38, pp. 69–119, 2006. https://doi.org/10.1016/s0065-2601(06)38002-1.Search in Google Scholar

[24] A. van Lamsweerde, “Goal-Oriented requirements engineering: a guided tour,” In Proceedings Fifth IEEE International Symposium on Requirements Engineering, August 27-31, 2001, pp. 249–262.10.1109/ISRE.2001.948567Search in Google Scholar

[25] J. Horkoff, T. Li, F. L. Li, et al.., “Using goal models downstream,” Int. J. Inf. Syst. Model. Des., vol. 6, no. 2, pp. 1–42, 2015. https://doi.org/10.4018/ijismd.2015040101.Search in Google Scholar

[26] M. Daun, J. Brings, L. Krajinski, V. Stenkova, and T. Bandyszak, “A GRL-compliant iStar extension for collaborative cyber-physical systems,” Requir. Eng., vol. 26, pp. 325–370, 2021, https://doi.org/10.1007/s00766-021-00347-3.Search in Google Scholar

[27] C. Becerra, X. Franch, and H. Astudillo, “From i* models to service oriented architecture models,” in Proceedings of the 4th International Workshop on Architectures, Concepts and Technologies for Service Oriented Computing, 2010, pp. 52–63.Search in Google Scholar

[28] D. Dori, Model-Based Systems Engineering With OPM and SysML, 1st ed. New York, NY, Springer, 2016, s.l.10.1007/978-1-4939-3295-5Search in Google Scholar

[29] P. Johannesson and P. Jayaweera, “Value and intention based information systems engineering,” in Information Systems Engineering: From Data Analysis to Process Networks, P. Johannesson and E. Söderström, Eds., Hershey, PA, London, IGI Publ; Eurospan, 2008, pp. 66–96.10.4018/978-1-59904-567-2.ch004Search in Google Scholar

[30] A. S. Rao and M. P. Georgeff, “BDI agents: from theory to practice,” in Proceedings of the First International Conference on Multiagent Systems, 1995, pp. 312–319.Search in Google Scholar

[31] M. Lind, “Modeling goals and functions of complex plants,” Appl. Artif. Intell., vol. 8, no. 2, pp. 259–283, 1994. https://doi.org/10.1080/08839519408945442.Search in Google Scholar

[32] C. Son, S. C. Peres, N. Ade, and T. J. Neville, “Reflecting abstraction hierarchy of a chemical processing System on standard operating procedures,” Proc. Hum. Factors Ergon. Soc. Annu. Meet., vol. 63, no. 1, pp. 1806–1810, 2019.10.1177/1071181319631400Search in Google Scholar

[33] T. Kuhn, “A survey and classification of controlled natural languages,” Comput. Linguist., vol. 40, no. 1, pp. 121–170, 2014. https://doi.org/10.1162/coli_a_00168.Search in Google Scholar

[34] H. Uzuner and G. Schembecker, “Wissensbasierte Erstellung von R&I-Fließbildern,” Chem. Ing. Tech., vol. 84, no. 5, pp. 747–761, 2012. https://doi.org/10.1002/cite.201100230.Search in Google Scholar

[35] M. Eilermann, C. Schach, P. Sander, C. Bramsiepe, and G. Schembecker, “Generation of an equipment module database — a maximum coverage problem,” Chem. Eng. Res. Des., vol. 148, pp. 164–168, 2019. https://doi.org/10.1016/j.cherd.2019.05.055.Search in Google Scholar

[36] A. Markaj, A. Fay, K. Stark, N. Schoch, and M. Hoernicke, “From intentions to services in modular process plants,” in ICPS 2022 – the 5th IEEE International Conference on Industrial Cyber-Physical Systems (ICPS), 2022, pp. 1–8.10.1109/ICPS51978.2022.9816935Search in Google Scholar

[37] VDI/VDE/NAMUR 2658-4: Automatisierungstechnisches Engineering modularer Anlagen in der Prozessindustrie: Modellierung von Moduldiensten. VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik (GMA), 2022.Search in Google Scholar

[38] Temporärer ProcessNet-Arbeitskreis “Modulare Anlagen”, Modulare Anlagen: Flexible chemische Produktion durch Modularisierung und Standardisierung – Status quo und zukünftige Trends, Frankfurt am Main, DECHEMA e.V., 2017.Search in Google Scholar

[39] H. Stuckenschmidt, C. Parent, and S. Spaccapietra, Modular Ontologies: Concepts, Theories and Techniques for Knowledge Modularization, Berlin, New York NY, Springer, 2009.10.1007/978-3-642-01907-4Search in Google Scholar

[40] J. Xu, P. Shironoshita, U. Visser, N. John, and M. Kabuka, “Module extraction for efficient Object queries over ontologies with large ABoxes,” Artif. Intell. Appl., vol. 2, no. 1, pp. 8–31, 2015. https://doi.org/10.15764/aia.2015.01002.Search in Google Scholar

[41] S. Rudolph, “Foundations of description logics,” in Tutorial, vol. 6848, Reasoning Web: Semantic Technologies for the Web of Data; 7th International Summer School 2011, Galway, Ireland, August 23–27, 2011; Tutorial Lectures, A. Polleres, Ed. Berlin, Heidelberg, Springer, 2011, pp. 76–136.10.1007/978-3-642-23032-5_2Search in Google Scholar

[42] C. Hildebrandt, S. Torsleff, B. Caesar, and A. Fay, “Ontology building for cyber-physical systems: a domain expert-centric approach,” in 2018 IEEE 14th International Conference on Automation Science and Engineering (CASE): 20–24 Aug. 2018, Munich, Germany, 2018, pp. 1079–1086.10.1109/COASE.2018.8560465Search in Google Scholar

[43] M. Hoernicke, K. Stark, N. Schoch, R. Jeske, A. Markaj, and A. Fay, “Modular engineering of conventional plants,” ATP, vol. 63, no. 4, pp. 62–68, 2022. https://doi.org/10.17560/atp.v63i4.2587.Search in Google Scholar

[44] A. Klose, J. Lorenz, L. Bittorf, et al.., “Orchestration of modular plants,” ATP, vol. 63, no. 9, pp. 68–77, 2022. https://doi.org/10.17560/atp.v63i9.2599.Search in Google Scholar

[45] H. Uzuner, “Ein wissensbasiertes System zur Unterstützung von R&I-Fließbild Designprozessen auf der Grundlage eines modulbasierten Ansatzes,” Zugl.: dissertation, 2012, 1st ed. Verl. Dr. Hut, Dortmund, Techn. Univ., München, 2013.Search in Google Scholar

[46] A. Markaj, A. Fay, M. Hoernicke, N. Schoch, and K. Stark, “Requirements and conceptual design for hybrid process plants,” in 2021 26th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), Vasteras, Sweden, 2021, pp. 1–4.10.1109/ETFA45728.2021.9613714Search in Google Scholar

[47] N. Schoch, M. Hoernicke, and K. Stark, “Semantic function module pipeline generation,” AT-AUTOM, vol. 69, no. 12, pp. 1040–1050, 2021. https://doi.org/10.1515/auto-2021-0090.Search in Google Scholar

Erhalten: 2022-08-29
Angenommen: 2022-10-24
Online erschienen: 2023-01-13
Erschienen im Druck: 2023-01-27

© 2022 the author(s), published by De Gruyter, Berlin/Boston

This work is licensed under the Creative Commons Attribution 4.0 International License.

Downloaded on 5.3.2026 from https://www.degruyterbrill.com/document/doi/10.1515/auto-2022-0101/html
Scroll to top button