DIMA im realen Einsatz Von der Idee zum Prototypen Thomas Holm, Wago Kontakttechnik, Minden; Jan Ladiges, Helmut-Schmidt Universität, Hamburg; Sachari Wassilew, Technische Universität Dresden; Paul Altmann, Technische Universität Dresden; Alexander Fay, Helmut-Schmidt Universität Hamburg; Leon Urbas, Technische Universität Dresden; Ulrich Hempen, Wago Kontakttechnik, Minden

Kurzfassung

Mit dem NAMUR-MTP wurde die Basis geschaffen, Module weitestgehend automatisiert in

eine Prozessführungsebene zu integrieren. Im MTP (Modul Type Package) werden dazu alle

Informationen abgebildet, die für eine effiziente und fehlerfreie Integration benötigt werden.

Der Arbeitsstand des NAMUR-MTP wurde von den Autoren auf Anwendbarkeit überprüft.

Dazu wurde ein Anlagendemonstrator aufgebaut, und die darin befindlichen Module wurden

mit Hilfe ihrer MTPs in ein Prozessleitsystem integriert. Der Beitrag schildert den

Engineering-Prozess und beschreibt die dabei zum Einsatz gekommenen Software-

Werkzeuge sowie die dabei gewonnenen Erfahrungen und schließt ab mit der Beschreibung

aktueller Herausforderungen als Roadmap für die nächsten Schritte.

1. Dezentrale Intelligenz für modulare Anlagen (DIMA)

In immer turbulenteren und kurzlebigeren Märkten, die überdies durch das

Individualisierungsbestreben der Endverbraucher geprägt sind, ist die Wandlungsfähigkeit

von Produktionsanlagen eine zunehmend wichtige Eigenschaft. Diese Eigenschaft, mit

einem Produkt schnell Marktreife zu erreichen und entsprechende Marktsegmente besetzen

zu können, wird zukünftig große Auswirkungen auf die Konkurrenzfähigkeit von

Unternehmen haben [1]. Die Modularisierung von Produktionsanalgen gilt als ein

entscheidender Befähiger für eine flexible und wandlungsfähige Produktion [2].

Modularisierung und die damit erwünschte Wandlungsfähigkeit innerhalb von

Produktionsstrukturen stellen allerdings erhebliche Anforderungen an das

Automatisierungssystem der Anlage [3]. Verändert sich das Funktionsspektrum einer

Produktionsanlage, zum Beispiel durch Hinzufügen, Entnahme oder Austausch von

Modulen, soll das Automatisierungssystem der Anlage schnell auf die neue physikalische

und funktionale Struktur anzupassen sein. In diesem Zusammenhang wird häufig von „Plug-

and-Play“ bzw. „Plug and Produce“ gesprochen. Ziel des „Plug and Produce“ ist, die

weitestgehend funktional unabhängigen Module über eine standardisierte Schnittstelle so zu

beschreiben, dass manuelle Eingriffe während oder nach einem Wandlungsprozess der

Produktionsanlage so gering wie möglich ausfallen [4]. Die bisher vorgeschlagenen

Beschreibungs- und Modellierungsansätze, die ein „Plug and Produce“ ermöglichen

könnten, entsprechen nicht ausreichend den Erfordernissen von Prozessanlagen und/oder

haben noch nicht den Weg in die Standardisierung gefunden.

Mit der DIMA-Methodik, die WAGO zur Namur-Hauptsitzung 2014 vorgestellt hat [5], könnte

sich dies ändern. DIMA ist eine herstellerunabhängige Methodik zur Befähigung modularer

Automatisierungsstrukturen. Zentrales Element ist das Modul Type Package (MTP) [6]. Das

MTP enthält alle Informationen eines Moduls, die für dessen Integration in eine

Prozessführungsebene (PFE), zum Beispiel in ein Prozessleitsystem, benötigt werden.

Diese Information umfasst neben den Bedienbildern auch die eigenen

verfahrenstechnischen Funktionen, die das Modul in Form von Diensten anbietet. Der

einzige verbleibende manuelle Aufwand während der Integration eines Moduls in die PFE

besteht im Import des MTP und der Orchestrierung der Dienste des Moduls zu einer

sinnvollen Abfolge, die dem Gesamtprozess entspricht. Durch die geringe Anzahl an

manuellen Tätigkeiten kann die DIMA-Methodik als ein wertvoller Schritt in Richtung „Plug-

and-Produce“ gesehen werden.

Bild 1: Anlagen-Projekt-unabhängiges (links) und Anlagen-Projekt-bezogenes (rechts) Engineering

Die Idee des DIMA-Ansatzes sieht unter anderem vor, dass das Modul-Engineering zeitlich

vor dem eigentlichen Planungsprozess der Anlage (Anlagen-Engineering) durchgeführt wird.

Das projektbezogene Anlagen-Engineering kann damit, durch Nutzung des MTP, signifikant

verkürzt werden. Bild 1 verdeutlicht den Workflow graphisch.

Nach Vorstellung des Ansatzes wurden die ersten Ergebnisse 2015 an die NAMUR und den

ZVEI übergeben. Dort wird zurzeit erfolgreich an der Weiterentwicklung und

Standardisierung gearbeitet [6].

2. Aktuelle Umsetzung am Anlagendemonstrator

2.1 Aufbau des Anlagendemonstrators und Wandlungs-Szenarien

Um die Anwendbarkeit des Ansatzes und der Arbeitsergebnisse des NAMUR-MTP als

Modulbeschreibung validieren zu können, wurde parallel zu den Arbeiten von NAMUR und

ZVEI weiter an der technischen Umsetzung von DIMA gearbeitet. Dazu wurde ein

Anlagendemonstrator erbaut, mithilfe dessen die in Bild 1 dargestellten Engineering-

Prozesse und die Modulintegration mittels MTP erstmalig getestet werden konnten. Im

Folgenden wird der Anlagendemonstrator im Detail beschrieben.

In einem Ausgangsszenario besteht die Produktion aus den Prozesschritten (1) Mischen, (2)

Destillieren, (3) Filtern und (4) Abfüllen. Jede dieser vier verfahrenstechnischen

Grundfunktionen wird durch ein eigenes Modul realisiert. Zunächst werden drei Edukte in

einem Mischer-Modul in einem beliebigen Verhältnis miteinander vermischt und zur Reaktion

gebracht. Hierfür stellt das Modul unter anderen den Dienst „Mischen“ zur Verfügung, in dem

das Mischverhältnis, die Rührerdrehzahl und der Durchfluss über eine Eingabe in der PFE

parametriert werden können. Die Möglichkeit zur Parametrierung einzelner Dienste aus der

PFE ermöglicht einen flexiblen Einsatz von Modulen, ohne dass zum Zeitpunkt des Modul-

Engineerings schon Kenntnisse über das zu produzierende Produkt vorliegen müssen. Das

entstandene Produkt wird anschließend in einem Destillations-Modul destilliert. Der durch

dieses Modul angebotene Dienst „Destillieren“ kann durch den Prozess- und

Produktverantwortlichen über die Parameter Kopftemperatur und Rührerdrehzahl spezifiziert

werden. Sollten die Parametriermöglichkeiten dieses Dienstes nicht ausreichen, kann der

Verantwortliche mithilfe kleinteiligerer Dienste, wie „Befüllen“, „Heizen“, „Mischen“ und

„Entleeren“ mit entsprechenden Parametern die Destillation betreiben.

Nachfolgend werden durch Ausführung des Dienstes „Filtern“ im Filter-Modul

Schwebekörper entnommen. Abschließend wird das Produkt in einem Abfüll-Modul in

kleinen Gefäßen vereinzelt.

Alle Module sind sternförmig an einen Backbone angeschlossen. Der Backbone versorgt die

Module mit elektrischer Energie und Druckluft und stellt die Netzwerkinfrastruktur zur

Kommunikation zwischen Modulen und Prozessführungsebene zur Verfügung.

Bild 2: Aufbau der Anlage auf der SPS/IPC/Drives 2015 (von links nach rechts: Misch-Modul, Destillations-Modul, Backbone, Filter-Modul, Abfüll-Modul)

Um die Wandlungsfähigkeit der Anlage zu untersuchen, wurde in einem Beispielszenario

das Filtermodul aus der Anlage entfernt.

Zur Entnahme des Filter-Moduls wird zunächst der Prozess gestoppt. Um das Filtermodul

entfernen und wiederverwenden zu können, muss es gereinigt und entleert werden. Hierfür

bietet das Filter-Modul die Dienste „Reinigen“ und „Abkoppeln“ an. Zur Ausführung dieser

Dienste wird ein entsprechendes Rezept im Batch-Werkzeug erstellt und ausgeführt. Nach

Abschluss des Reinigungsprozesses kann das Modul sowohl physikalisch als auch

informationstechnisch aus der PFE entfernt werden. Das informationstechnische Entfernen

des Moduls erfolgt durch Entnahme des MTP. Durch Ausführen des entsprechenden

Entnahmealgorithmus im Prozessleitsystem werden die Elemente wie Variablen,

Bedienbilder und Services in Form von Batch-Grundfunktionen entfernt, sofern sie nicht für

eine Archivierung vorgesehen sind. Dazu wurde die Information, welche Elemente aus

einem MTP während der Integration angelegt wurden, gespeichert.

Zur erneuten Aufnahme des Produktionsprozesses, nun ohne Filter-Modul, müssen

zunächst die Schnellkupplungen von Destillier- und Abfüllmodul verbunden werden. Der nun

veränderten Funktionalität der Produktionsanlage wird durch eine veränderte

Diensteauswahl im Batch-Werkzeug entsprochen. Zudem wurde die Parametrierung des

Prozesses durch Anpassung des Mischverhältnisses im Dienst „Mischen“ angepasst.

Für die Erstellung des Automatisierungssystems des Anlagendemonstrators wurden zwei

Software-Werkzeuge genutzt:

1. Das Modul-Engineering und die MTP-Generierung wurden mit Hilfe des Engineering-

Werkzeugs e!Cockpit der Firma WAGO durchgeführt.

2. Das Anlagen-Engineering, samt Einlesen und Verarbeiten der MTP, wurde im

Prozessleitsystem zenon der Firma COPA-DATA umgesetzt.

Die beiden durchgeführten Engineering-Prozesse und die dabei zur Anwendung

gekommenen Engineering-Werkzeuge werden im Folgenden beschrieben.

2.2 Modulautomatisierung mit e!Cockpit

Aufgabe des Modulanbieters ist es, das Modul zu planen, zu bauen und zu automatisieren.

Letzteres enthält neben der Auswahl der Sensorik und Aktorik auch die Erstellung des

Programmcodes der Modulsteuerung. Der Programmcode enthält zusätzlich zu dem

konventionellen Steuerungscode auch die Logik, die den Ablauf der Dienste ermöglicht,

welche durch das Modul angeboten werden. Dieser Teil muss nach DIMA so entworfen

werden, dass die Schnittstellen der Dienste und deren Zustände zur direkten

Kommunikation mit der Prozessführungsebene vorbereitet werden. Des Weiteren sind für

ein Modul ein oder mehrere Bedienbilder zur Visualisierung des Moduls auf einem lokalen

Panel und in der HMI-Funktionalität der Prozessführungsebene zu erzeugen.

Bild 3: Dienst des Filter-Moduls im Ordner Services und im AS-Editor in e!Cockpit

Die Erstellung des Programmcodes der Modul-Steuerung findet in e!Cockpit in den

bekannten Programmiersprachen der IEC 61131-3 statt. Dienste werden als Funktions-

bausteine in einem hierfür vorgesehenen Ordner „Services“ erstellt (vgl. Bild 3).

Der Funktionsbaustein eines Dienstes enthält dazu unter anderem die Kommunikationslogik,

mit dessen Hilfe die Zustände der Dienste zwischen Prozessführungsebene und Modul

ausgetauscht werden.

Die Erstellung der Bedienbilder (vgl. Bild 4) wird unter Nutzung von Bibliothekselementen

durchgeführt. Dazu werden die Bibliothekselemente genutzt, die aktuell in den

entsprechenden NAMUR Aktivitäten spezifiziert werden, vgl. [6]. Zum Modellieren der

Bedienbilder eines Moduls im MTP wird die Bedeutung der Bedienbildelemente, deren Lage,

Größe und angebundene Variablen ermittelt und beschrieben.

Diese werden zur automatischen Generierung des MTP aus dem in e!Cockpit erstellten

Programmcode herausgefiltert.

Bild 4: Bedienbild des Filter-Moduls in e!Cockpit

Bild 5: Auswahldialog für die Inhalte des MTP im e!Cockpit

Welche Dienste und Bedienbilder letztendlich im MTP abgebildet werden, entscheidet der

Modulhersteller. In e!Cockpit wird dies über einen zusätzlichen Dialog realisiert (vgl. Bild 5).

Damit wird ermöglicht, dass nur die Dienste und Bedienbilder durch den MTP veröffentlicht

werden, die auch von einem spezifischen Kunden gewünscht werden. Das MTP nimmt

hierbei zusätzlich die Rolle einer Lizenzdatei ein.

2.3 Integrations-Engineering in der Prozessführungsebene mit dem PLS zenon

Das PFE-Engineering wird durch den Anlagenbauer/-betreiber durchgeführt. Er wählt die zu

seinem Produktionsprozess passenden Module aus und erhält für jedes der Module im

Vorfeld ein MTP. Damit wird dem Anlagenbetreiber ein frühzeitiger Beginn des Integrations-

Engineering ermöglicht. Das Integrations-Engineering beginnt mit dem Einlesen der MTP in

das PLS. Im Rahmen des Anlagendemonstrators wurde das Prozessleitsystem zenon der

Firma COPA-DATA eingesetzt. Die Integration der Module konnte dabei vollständig über die

in den MTP modellierten Informationen realisiert werden. Dazu wurde im PLS ein MTP-

Handling-System erstellt, über das die MTPs eingelesen und gelöscht werden können. Im

Zuge des Einlesens eines MTP werden durch die systemspezifischen Algorithmen alle

benötigten Variablen, Bedienbilder, Grundoperationen einer Unit (also Dienste eines

Moduls) sowie deren Verknüpfungen untereinander angelegt. Auch der passende

Kommunikationstreiber im Prozessleitsystem wird angelegt und muss lediglich um die

Netzwerk-Adresse des jeweiligen Moduls ergänzt werden. Damit kann sofort eine direkte

Kommunikation zwischen Leitsystem und Modul-Steuerung aufgebaut werden - das

Produktionssystem ist innerhalb von Minuten einsatzbereit.

Bild 6: Bedienbild des Mischer-Moduls nach MTP-Import

Bild 6 zeigt die Runtime-Oberfläche des PLS des Demonstrators. Die Bildobjekte wurden

aus einer vorab erstellten Template-Bibliothek des PLS entnommen. Die Informationen bzgl.

Namen, Größe, Position und Variablenanbindung entstammen dem MTP. Somit ist

gewährleistet, dass Bedienbilder von Modulen unterschiedlicher Hersteller im Leitsystem

einheitlich dem kundenspezifischen „Look and Feel“ entsprechen. Bild 6 stellt die

Generierung des Bedienbildes für das Mischer-Modul dar, welches aus den Informationen

des Bedienbildes aus Bild 4 generiert wurde. Die aus den Diensten generierten

Grundfunktionen im Batch-Werkzeug können wie gewünscht durch den

Prozessverantwortlichen parametrisiert und in Form von Rezepten miteinander verknüpft

werden (vgl. Bild 7). Nach diesem Schritt ist der Produktionsprozess der Anlage ablauffähig.

Bild 7: Orchestrieren der Dienste im Batch-Werkzeug

2.4 Erprobung der Wandlungsfähigkeit

Zur Entnahme eines Moduls (entsprechend dem in Abschnitt 2.1 beschriebenen Szenario)

musste der Produktionsprozess gestoppt und in einem neuen Rezept die Grundfunktion

Reinigen des Filter-Moduls ausgeführt werden. Das Modul spülte daraufhin den

Kartuschenfilter und entleerte sich komplett. Das Modul konnte nun auch physikalisch

entnommen werden. Zur erneuten Aufnahme des Produktionsprozesses ohne Filter-Modul

mussten aus dem zuvor genutzten Rezept lediglich die Rezeptschritte des Filter-Moduls

entfernt werden. Die komplette Entfernung des Filter-Moduls und anschließende

Wiederaufnahme des Produktionsprozesses konnte so in 2:30 min reproduzierbar auf der

Messe SPS/IPC/Drives im November 2015 in Nürnberg demonstriert werden.

3. Aktuelle Herausforderungen

Die vorgestellte Umsetzung hat gezeigt, dass der DIMA-Ansatz geeignet ist,

Produktionsanlagen modular aufzubauen und Module mithilfe des MTPs schnell in einen

anlagenweiten Modulverbund zu integrieren. Die Kapselung verfahrenstechnischer

Funktionen als parametrierbare Dienste erwies sich hierbei als sinnvoll, um erhebliche

Einsparungen im Anlagen-Engineering zu erzielen. Um die Prozessführung noch autarker

von den Mechanismen eines übergeordneten Automatisierungssystems zu gestalten, sind

weitere technologische Fortschritte erforderlich. Die technologischen und Standardisierungs-

Herausforderungen sollen daher im Folgenden diskutiert werden.

3.1 Zustandsbasierte Prozessführung und Betriebsartenkonzept

Um eine herstellerübergreifende Integration von Modulen zu ermöglichen, muss auch die

Ausführung der Dienste vereinheitlicht ablaufen. Das heißt, der Prozessführungsebene

muss im Vorfeld bekannt sein, welche Zustände ein Dienst einnehmen kann und welche

Zustandsübergänge möglich sind. Des Weiteren muss bekannt sein, welche

Zustandsübergänge die PFE herbeiführen kann, und es muss festgelegt werden, wie ein

Modul-Dienst seinen aktuellen Zustand der PFE mitteilt und Befehle zum Zustandswechsel

entgegen nimmt. D.h. es muss neben der Zustandsmodellierung der Dienste auch die

Kommunikationsmethodik zwischen Modul und PFE vereinheitlicht werden. Zusätzlich muss

ein Modul oder einzelne Dienste eines Moduls eine Betriebsartenumschaltung ermöglichen.

Die Betriebsarten eines Moduls und der Moduldienste müssen der PFE bekannt sein.

Bild 8: PackML-Zustandsautomat aus [8]

In der bisherigen Umsetzung wurde für Dienste eine Zustandsbeschreibung gem. IEC 61512

[7] verwendet. Diese beschreibt die zustandsbasierte Steuerung für Prozedurelemente einer

Rezeptsteuerung und definiert beispielhaft Zustände, deren Zustandsübergänge und einige

Betriebsarten. Darauf aufbauend wurde durch die OMAC PackML definiert [8]. PackML

definiert eine Obermenge von Zuständen und ihren Übergängen für Maschinen und Units,

vgl. Bild 8. Eine beliebige Untermenge dieser Zustände kann daraus für jede Betriebsart

instanziiert werden. Des Weiteren kann definiert werden, in welchen Zuständen zwischen

diesen Betriebsarten gewechselt werden kann. Da in PackML die Festlegung der

Betriebsarten, der darin enthaltenen Zustandsbeschreibungen und der Übergänge zwischen

den Betriebsarten nicht festgelegt ist, ist hier allerdings noch die erforderliche

Vereinheitlichung zur Kommunikation zwischen Modulen und PFE notwendig.

Ein weiterer offener Punkt ist die Interaktion der Service- und Modulzustände mit der PFE,

welche einer definierten Kommunikationsstruktur entsprechen sollte. Grundsätzlich stehen

unterschiedliche Kommunikationsmethoden wie Discovery, Request-Response oder Publish-

Subscribe [9] und weitere Handshake-Verfahren zur Verfügung. Für die dienstbasierte

Modulorchestrierung muss neben der zu verwendenden Kommunikationsmethode auch der

konkrete Nachrichtenaustausch standardisiert sein.

Als weiteren Punkt, der die zustandsbasierte Prozessführung betrifft, fordert die NE 148 [3],

den Betriebszustand eines Moduls gem. NE 107 [10] zu beschreiben. Die NE107 umfasst

die Status Ausfall, Funktionskontrolle, Außerhalb der Spezifikation und Wartungsbedarf. Da

die NE 107 für Feldgeräte spezifiziert wurde, bleibt zu klären, wie diese Zustände für Module

und/oder Dienste zu interpretieren sind. Außerdem muss eine mögliche Interaktion zwischen

den Status der NE 107 und den Zuständen der Services bzw. Module spezifiziert werden,

z.B. ob das Erreichen eines bestimmten Status der NE 107 die Änderung eines Dienste-

Zustandes oder einer Modul-Betriebsart zur Folge haben kann bzw. muss.

3.2 Beschreibungen von Diensten und deren Abhängigkeiten

Die Kommunikation in einem Modulverbund entspricht einer Service-orientierte Architektur

(SOA). Meist aufbauend auf dem OASIS Referenzmodell [11], der wohl der am weitesten

verbreitete und anerkannteste Standard zu SOA ist, haben sich verschiedene Arbeiten

bereits mit der Kommunikation in Automatisierungssystemen befasst, z.B. [12-14]. Die

bisherige Forschung beschäftigte sich damit, welche Anforderungen an eine SOA in der

Automatisierung gestellt werden und welche Informationen in einer Dienstbeschreibung

enthalten sein sollte (z.B. [15]), wie das Engineering von SOA-basierter Produktion

vorgenommen werden kann [17] sowie den Möglichkeiten zur Implementierung von Diensten

(z.B. [16]). Insbesondere die Arbeiten [12,13,15,17] sind sehr generisch gehalten, betrachten

Dienste durch die gesamten Automatisierungspyramide hindurch und bilden ein sehr gutes

Fundament zur Einführung der Dienste-Orchestrierung in die Automatisierungstechnik.

Zur Anwendung auf den konkreten hier beschriebenen DIMA-Ansatz und auch für die

Standardisierung des NAMUR-MTPs ist es jedoch notwendig, eine konkrete Modellierung in

einem geeigneten Beschreibungsmittel zu finden, dass den Anforderungen zur

Beschreibung von Diensten als prozesstechnische Funktionen genügt. Dies beinhaltet

insbesondere, dass ein Modul garantieren muss, dass es funktional sicher ist und keine

Dienstaufrufe erlaubt, die einen nicht-sicheren Zustand zur Folge haben. Des Weiteren ist es

erforderlich, dass Dienste oder Dienstzustände sich gegenseitig ausschließen können.

Andererseits können Dienste sich aber auch gegenseitig bedingen. Im Gegensatz zu Web-

Services ist der Aufruf eines verfahrenstechnischen Dienstes also nicht nur auf

Rechenkapazitäten beschränkt, sondern kann eine Vielzahl von Abhängigkeiten beinhalten.

Diese umfassen mindestens folgende Szenarien:

1. Die Ausführung eines Dienstes kann den Aufruf eines weiteren Dienstes beinhalten.

Hierbei ist zu berücksichtigen, dass die Zustandsübergänge des einen Dienstes vom

Zustand des anderen abhängig sind. Z.B. kann ein Reaktordienst einen Kühl-Dienst

aufrufen, wobei der Reaktordienst nur in den „Execute“-Zustand wechseln darf, wenn

der Kühl-Dienst bereits ausgeführt wird.

2. Dienste können sich gegenseitig ausschließen, z.B. ist es nicht sinnvoll, einen Tank

gleichzeitig zu heizen und zu kühlen.

3. Dienste können von Parametern anderer Dienste abhängen. Zum Beispiel muss ein

Kühl-Dienst blockiert werden, wenn ein Misch-Dienst mit einer entsprechend hohen

Solltemperatur aufgerufen wurde.

4. Bestimmte Dienste können nur in bestimmten Betriebsarten aufgerufen werden, und

Betriebsarten können nur bei bestimmten Dienstzuständen gewechselt werden.

Diese Abhängigkeiten zwischen den Diensten müssen im Programmcode des Moduls

hinterlegt sein. Da diese Abhängigkeiten jedoch schnell eine hohe Komplexität annehmen

können, sollte eine geeignete Komplexitäts-reduzierende Modellierung. Das

Beschreibungsmittel sollte entsprechend formal sein, um die Verifikation bestimmter

Eigenschaften des resultierenden Programmes automatisiert vornehmen zu können.

Beispiele solcher Eigenschaften ist die Freiheit von Deadlocks und Erreichbarkeit aller

Zustände. Zudem muss es möglich sein, die Abhängigkeiten geeignet im MTP abzulegen.

3.3 Dienste-Orchestrierung in der Prozessführungsebene

Nicht zuletzt sind geeignete Methoden zur Dienste-Orchestrierung und -parametrierung zu

entwickeln. Dabei ist zu berücksichtigen, dass der entstandene Gesamtprozess die

Diensteabhängigkeiten eines Moduls nicht verletzen darf. Hieraus ergibt sich die

Anforderung, dass die im MTP enthaltenen Abhängigkeiten ausgelesen werden müssen und

die Orchestrierung gegen diese verifiziert werden muss. Des Weiteren können durch die

Modulkonfiguration und aufgrund prozessspezifischer Anforderungen neue Dienst- und/oder

Modulabhängigkeiten resultieren. Diese müssen ebenfalls verifizierbar sein. Eine Möglichkeit

hierzu wäre die Erstellung eines Modells, welches mittels formaler Methoden überprüft

werden kann.

Literatur

[1] PAAT Team Tutzing, ProcessNet: Die 50% Idee: Vom Produkt zur Produktionsanlage in der halben Zeit.

– Thesen Tutzing, 2009.

[2] H.P. Wiendahl: Wandlungsfähigkeit. In: Werkstatttechnik WT-Online, 92 (2002) Nr. 4, S. 122-127.

[3] NE 148: Anforderungen an die Automatisierungstechnik durch die Modularisierung

verfahrenstechnischer Anlagen. Namur 2013.

[4] J. Jasperneite, S. Hinrichsen, O. Niggemann: "Plug-and-Produce“ für Fertigungssysteme. Informatik-

Spektrum, Vol. 38 (3), 2015, S. 183–190.

[5] T. Holm, M. Obst, A. Fay, L. Urbas, T. Albers, S. Kreft, U. Hempen: Dezentrale Intelligenz für modulare

Automation. atp edition – Automatisierungstechnische Praxis 56(11), S.34-43, 2014.

[6] J. Bernshausen, A. Haller, T. Holm, M. Hörnicke, M. Obst, L. Ladiges: Namur-Module Type Package –

Definition. atp edition - Automatisierungstechnische Praxis 58(1-2), S.72–81, 2016.

[7] DIN EN 61512-1. Chargenorientierte Fahrweise - Teil 1: Modelle und Terminologie, 2000.

[8] ANSI/ISA-TR88.00.02-2015, Machine and Unit States: An implementation example of ANSI/ISA-

88.00.01, ISA 2015.

[9] D. Henneke, M. Elattar, J. Jasperneite: Communication patterns for Cyber-Physical Systems. In: IEEE

Conference on Emerging Technologies Factory Automation (ETFA), 2015.

[10] NE 107. Selbstüberwachung und Diagnose von Feldgeräten, Namur 2005.

[11] C. M. MacKenzie, K. Laskey, F. McCabe, P. F. Brown, und R. Metz: Reference Model for Service Oriented

Architecture 1.0. OASIS standard, OASIS, 12. Oktober 2006, http://docs.oasis-open.org/soa-

rm/v1.0/soa-rm.html.

[12] C. Diedrich, M. Meyer, L. Evertz, W. Schäfer: Dienste in der Automatisierungstechnik. atp edition -

Automatisierungstechnische Praxis, 2014, S. 24–35.

[13] H. Mersch, U. Epple: Concepts of service-orientation for process control engineering. In: International

Multi-Conference on Systems, Signals and Devices (SSD), 2012.

[14] M. Taisch, A.C. Colombo, S. Karnouskos, A. Cannata: SOCRADES Roadmap: The Future of SOA-based

Factory Automation. – Project Report SOCRADES.EU, 2006.

[15] L. Evertz, U. Epple: Laying a basis for service systems in process control. In: IEEE Conference on

Emerging Technologies Factory Automation (ETFA), 2013.

[16] W.W. Dai, J.H. Christensen, V. Vyatkin, V. Dubinin: Function block implementation of service oriented

architecture: Case study. In: IEEE International Conference on Industrial Informatics (INDIN), 2014.

[17] A. Giret, E. Garcia, V. Botti: An engineering framework for Service-Oriented Intelligent Manufacturing

Systems. Computers in Industry, 2016.