dima im realen einsatz - gti-process ag · pdf filedima im realen einsatz von der idee zum...
TRANSCRIPT
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.