Mobile Monitoring und smarte Datenanalyse basierend auf offenen Standards

Transkript

1 MoMo Mobile Monitoring und smarte Datenanalyse basierend auf offenen Standards Dr.-Ing. M. Schleipen, Dr.-Ing. C. Kühnert, Dr. M. Okon, R. Henßen, T. Bischoff, Fraunhofer IOSB, Karlsruhe Kurzfassung Heute existiert in der Produktion auf Grund heterogener Toollandschaften und verschiedenster Datenlieferanten meist keine einheitliche Komponente für die Verarbeitung der Prozessund Qualitätsdaten. Der Aufwand für die Erstellung eines geeigneten Systems zur Prozessdatenanalyse verursacht einen nicht unerheblichen Aufwand für die Anbindung an die Datenquellen, das Verständnis für die erfassten Daten und die Erstellung einer geeigneten Visualisierung. Eine einheitliche Architektur auf Basis bestehender industrieller Standards kann hier Abhilfe schaffen. Im vorliegenden Beitrag wird eine solche modulare Architektur (MobileMonitor MoMo) basierend auf verschiedenen Standards für die Produktionsanlagenmodellierung (AutomationML) und die Anbindung an den Produktionsprozess (OPC-UA) inklusive einer Beispiel-Umsetzung in der Wasserqualitätsanalyse vorgestellt, die die Möglichkeiten der Prozessoptimierung bzw. die vorausschauende Wartung für den Nutzer transparent macht. Abstract Today heterogeneous tool landscape and different data suppliers in the production environment complicate a universal component for the processing of process and quality data. The development effort of a suitable system for process data analysis comprises a serious effort for the connection to the data sources, the comprehension of the recorded data, and the development of a feasible visualization. To avoid this, an integrated architecture based on existing industrial standards can be used. The present paper discusses such a modular architecture (MobileMonitor MoMo) which makes the possibilities of process optimization and predictive maintenance transparent to the user. MoMo is based on standards für production plant modelling (AutomationML) and for the connection to the production process (OPC UA). It includes an example implementation of water quality analysis.

2 1. Einleitung und Motivation Heute existiert in der Produktion auf Grund heterogener Toollandschaften und verschiedenster Datenlieferanten meist keine einheitliche Komponente für die Verarbeitung der Prozessund Qualitätsdaten. Der Aufwand für die Erstellung eines geeigneten Systems verursacht einen nicht unerheblichen Aufwand für die Anbindung an die Datenquellen, das Verständnis für die erfassten Daten und deren Visualisierung. Eine einheitliche Architektur auf Basis bestehender industrieller Standards kann hier Abhilfe schaffen. Im vorliegenden Beitrag wird eine solche modulare Architektur (MobileMonitor MoMo, siehe Kapitel 2) inklusive Umsetzung vorgestellt. Damit können Daten aus verschiedenen Quellen flexibel zusammengeführt und dem Anwender in für ihn geeigneten Sichten visualisiert werden. Ziel ist die Bereitstellung einer mobilen und flexiblen Plattform (MoMo) für den Endanwender. Dabei bezieht sich die Mobilität nicht notwendigerweise auf den Einsatz mobiler Clients, sondern beschreibt die räumliche Unabhängigkeit der Komponenten, die verschiedene mobile Anwendungen ermöglichen. Die Plattform soll der Unterstützung multivariabler Datenanalyse (z.b. für Condition Monitoring, Berechnung KPIs) basierend auf Standards für die Produktionsanlagenmodellierung (AutomationML) und die Anbindung an den Produktionsprozess (OPC UA) dienen. AutomationML ist eine offene, XML-basierte Normenreihe (IEC 62714, siehe Kapitel 3) zur Beschreibung und Modellierung von Produktionsanlagen und komponenten. Die OPC UA (OPC Unified Architecture, siehe Kapitel 4) ist eine plattformunabhängige Normenreihe (IEC 62541) zur Kommunikation von industriellen Automatisierungsgeräten und systemen. Die entwickelte Plattform wird in Kapitel 5 beschrieben. Sie beinhaltet eine zentrale Komponente mit entsprechenden Modellverwaltungsmechanismen (basierend auf AutomationML) in Form eines aggregierenden OPC UA Servers. Außerdem werden verschiedene Kommunikationskanäle zur Prozess-/Maschinendatenakquisition (basierend auf z.b. OPC UA, ODBC, OPC DA) bereitgestellt. Die Auswertung der Daten kann von verschiedenen Quellen (Services) gekoppelt über OPC UA einfließen. Die Plattform ist für verschiedene Anwendungsbereiche geeignet (z.b. Wasserüberwachung, Gebäudeüberwachung, Verfahrenstechnik, ). Die domänenspezifischen Daten sind in der AutomationML-Modellierung integriert. Der Beitrag beschreibt eine erste praktische Anwendung der aktuell in Arbeit befindlichen Companion Spezifikation AutomationML für OPC UA, sowie die Beschreibung von OPC UA- Konfigurationsdaten in AutomationML. Die Umsetzung erfolgte prototypisch für einen Anwendungsfall in der Wasserqualitätsanalyse, dieser wird in Kapitel 6 beschrieben. Zukünftig soll die Plattform wie in Kapitel 7 zusammengefasst auch direkt in der Produktion zur Anwendung kommen.

3 2. MoMo-Architektur Die MoMo-Architektur zielt darauf ab, basierend auf industriellen Standards (AutomationML und OPC UA), eine generische und flexible Möglichkeit der Prozessdatenanalyse von verteilten Prozessen zu schaffen. Die Komponenten der Architektur sind in Bild 1 dargestellt. Die zentrale Komponente ist der aggregierende OPC UA Server (im Bild 1 grün dargestellt), der eine Art zentrales Repository darstellt. Bild 1: MoMo-Architektur Der Server enthält zentrale Komponenten zur Modellverwaltung und operiert auf einem AutomationML-Informationsmodell. Dieses Modell enthält Informationen über die zu betrachtenden Anlagenkomponenten in der Produktion, aber auch über die Konfigurationsparameter zum Aufbau der Kommunikationsverbindung zum Produktionsprozess. Durch verschiedene Kommunikationskanäle (mittig links im Bild 1, z.b. OPC UA, OPC DA, ODBC) ist der aggregierende OPC UA Server in der Lage, die Prozess- oder Maschinendaten für die Auswertung zu akquirieren. Darüber hinaus können in die Auswertung Daten von verschiedenen Quellen (Services, beispielsweise getriggert durch Methoden in OPC UA) einfließen (links unten im Bild 1 dargestellt). Hierdurch sind Datenakquisition und Verständnis der Daten von der eigentlichen Auswertung entkoppelt. Beispielsweise kann hierzu eine inkrementelle Echtzeitmodellierung für die Auswertung zum Einsatz kommen.

4 Gleichzeitig stellt der aggregierende OPC UA Server seine Daten für diverse Visualisierungskomponenten per OPC UA bereit. Dies beinhaltet ebenfalls die Informationsaufbereitung für die Anwender. Durch die Informationen über die Kommunikation mit dem Prozess ist hier nicht nur die Beobachtung des aktuellen Zustands des Produktionsprozesses wichtig, sondern auch die Bedienung entsprechender Prozessvariablen. In der MoMo-Architektur wird zwischen der Offline-/Konfigurations-Phase und der Online- /Betriebs-Phase unterschieden. In der Online-Phase kommt, wie bereits beschrieben, die Kommunikation mittels OPC zum Einsatz, um Online-Sensor- und Aktor-Werte zu propagieren. In der Offline-Phase können die in der nachfolgenden Online-Phase benötigten Modelle bereits aus vorliegenden Anlagenplanungsinformationen, wie z.b. der CAD-Planung oder der Steuerungsprogrammierung importiert und fusioniert werden. Diese fusionierten Daten können für verschiedene Zielsysteme, wie z.b. die Visualisierung, oder Informationen zum Engineering dieser Systeme genutzt werden. Dieser Schritt der automatischen Generierung der Visualisierung [1] ist im Bild 1 rechts oben sichtbar. Das hierfür benötigte AutomationML- Modell enthält für Online- und Offline-Phase gemeinsam benötigte Informationen, wie z.b. die Topologie oder Grafikinformationen zu den einzelnen Anlagenkomponenten. Nachfolgend werden nun die einzelnen Bausteine der Architektur im Detail betrachtet. 3. Produktionsanlagenmodellierung (AutomationML) AutomationML [2] ist eine offene, XML-basierte Normenreihe (IEC 62714, [3]) zur Beschreibung und Modellierung von Produktionsanlagen und komponenten. Die Pflege und Weiterentwicklung erfolgt durch den AutomationML e.v. [4] 3.1 Generierung von Prozessbildern auf Basis von AML Um die Daten aus möglicherweise verschiedenen Datenquellen (Planungsphase, Betriebsphase) sinnvoll zu nutzen, müssen diese in einem gemeinsamen Modell integriert werden. Dies geschieht mittels Importierung aus den verschiedenen Quellen und anschließender semantisch sinnvoller Fusionierung. Auf dieser Basis kann die weitere Verarbeitung für die Überwachung, Auswertung und Steuerung erfolgen. Als standardisiertes Format für dieses Modell wurde AutomationML gewählt. Das Modell der Komponenten setzt sich aus verschiedenen Teilmodellen zusammen. Im Rahmen von MoMo genügen Links für die Topologie, die zu einer hierarchisch verknüpften Prozessbildmenge führen. Fehlende Geometrie-Informationen werden durch Dummy- Objekte (standardisierte Rechtecke mit hinterlegten Foto-Informationen) und geeignete Platzierungen (standardisierte Layouts, z. B. in Tabellen-, Zeilen- oder Spalten-Anordnung) ersetzt.

5 3.2 Übergang in Online-Modell mit UA Die OPC UA [5] ist eine plattformunabhängige Normenreihe (IEC 62541, [6]) zur Kommunikation von industriellen Automatisierungsgeräten und systemen. Die Pflege und Weiterentwicklung erfolgt durch die OPCFoundation [7]. Informationsmodelle für OPC UA Server von Hand zu erstellen ist mit großem Aufwand verbunden. Zur Integration von AutomationML als Companion Specification (spezifisches Informationsmodell) der OPC UA existiert eine gemeinsame Arbeitsgruppe der OPCFoundation und des AutomationML e.v. unter Leitung des Fraunhofer IOSB. Ziel ist es, eine Vorgehensweise zu definieren, wie aus vorhandenen AutomationML Modellen OPC UA Informationsmodelle abgeleitet werden können (siehe dazu auch [8] und [9]). Dadurch wird das Engineering-Format AutomationML operationalisiert und der Anwendungsbereich von OPC UA vergrößert. Bild 2 zeigt die Abbildung der Hauptelemente von AutomationML und die Relationen zwischen diesen.zu erwähnen sind die verschiedenen ObjectType-Hierarchien, welche aus den SystemUnitClasses und den RoleClasses entstehen. Ein Unterschied zwischen beiden Standards ist, dass in AutomationML einer Instanz mehrere Rollen zugewiesen werden können, während in OPC UA einem Object nur ein ObjectType zugewiesen werden kann. Gelöst wird dies, indem ein neuer ReferenceType HasAMLRoleReference im OPC UA Informationsmodell eingeführt wird. Bild 2: Mapping der Hauptelemente Das OPC UA Informationsmodell des aggregierenden Servers wird um einige organisatorische Knoten erweitert. Es gibt organisierende Knoten, die einen schnellen Zugang für Auto-

6 mationml-affine Anwender den Zugang zum Modell zu ermöglichen, ebenso kann über die klassischen OPC UA Einstiegspunkte Zugang zum Modell erlangt werden. 4. Anbindung an den Produktionsprozess (OPC UA) Steht ein Prozesswert über einen OPC UA Server zur Verfügung, wird diese Informationen über die OPC UA Variable in der AutomationML zur Verfügung gestellt. Diese Konfigurationsinformationen nutzt der OPC UA Server, um sich auf die entsprechenden Prozessinformationen zu verbinden und die Online-Daten in seinem Adressraum zu spiegeln. Hierzu verwendet MoMo bei den entsprechenden Variablen im AutomationML-Modell ein Unterattribut mit dem Namen aml-opcua-variable. In Bild 3 ist die AutomationML Struktur dieses Elementes dargestellt. Das oberste Attribut Value entspricht logisch der Prozessinformation (OPC UA Variable des unterlagerten Servers). Bild 3: AutomationML Struktur der AML-UA-Variable Aus AutomationML Sicht bedeutet das aml-opcua-variable Unterattribut, dass sich der Wert des Attributs zur Laufzeit ändern und der aktuelle Wert im Adresshaushalt des angegebenen OPC UA Servers abgerufen werden kann. Das Unterattribut ServerAddress enthält die URL zum OPC UA Server (z.b. opc.tcp://momo.iosb.fraunhofer.de), die VariableNodeId enthält die UA NodeId der Variable (z.b. ns=1;i=123). Diese beiden Angaben sind zwingend erforderlich. Für das Projekt war es zusätzlich nötig, einen Alias des Servers und den Variablennamen bereit zu stellen. 5. MoMo-Plattform Die MoMo-Plattform basiert auf dem aggregierenden OPC UA Server als Kernkomponente (siehe grüner Kasten in Bild 1). Das Informationsmodell wird aus einer OPC UA XML-Datei mit standardisiertem Format geladen, das aus der beschriebenen AutomationML-Datei generiert wird. Er enthält einen integrierten OPC UA Client, um mittels oben angegebener Konfigurations-Informationen auf unterlagerte OPC UA Server zugreifen zu können.

7 Der Prozess muss nicht immer aktuell vorhanden sein, sonder kann wie im Anwendungsbeispiel (Abschnitt 6) durch einen Simulations-Server und in einer Datenbank gespeicherten Werten repliziert werden. Der Simulations-Server wird mittels einer XML-Datei konfiguriert, greift per ODBC auf diese Datenbank zu und simuliert die jeweiligen Werte anhand des enthaltenen Zeitstempels. Die XML-Datei enthält allgemeine Informationen, wie z.b. der ODBC Datenquellen-Name, weitere Informationen für die ODBC-Verbindung, sowie die Konfiguration der einzelnen Simulations-Items. Für jedes Item werden Name und Datentyp, sowie Informationen zur Datenbank-Anbindung, wie z.b. der Name der Datenbank, der Tabellen- Name unddie Spalten-Namen der einzelnen Spalten festgelegt. Hier kann für jedes Item auch ein Zeitraffer-Faktor festgelegt werden, um die Simulation zu beschleunigen. Da der Simulations-Server als Schnittstelle OPC DA verwendet, der aggregierende Server aber ausschließlich OPC UA unterstützt, war hier der Einsatz eines entsprechenden Wrappers erforderlich. Diese Aufgabe erledigt der OPCUARouter, welcher zum einen OPC UA Server, und zum anderen OPC DA Client ist. 5.1 Bildgenerierung Neben der Online-Nutzung der Daten, werden diese auch benötigt, um dem Benutzer eine grafische Übersicht über die zu überwachenden Anlagenkomponenten zu liefern. Die Verarbeitung des bereitgestellten AutomationML-Modells erfolgt so weit wie möglich zielsystemunabhängig, es muss aber in ein entsprechendes in der Regel proprietäres Ziel- System-Format exportiert werden. Der hierfür in IDA [1] und PCFF [10], [11] entwickelte Exporter ist mit einer PlugIn-Schnittstelle ausgestattet, welche die konkrete Umsetzung in das gewünschte Zielformat übernimmt. Dabei werden nur die Variablen aus dem Modell berücksichtigt, die explizit als sog. VisuFacets gekennzeichnet sind. Es können also im Modell umfassendere Informationen abgelegt werden, die aber in der Visualisierung nicht alle erscheinen sollen. Aktuell stehen PlugIns für die Systeme ProVis.Visu und Siemens WinCC zur Verfügung. Die Überführung der fusionierten Rohdaten in das jeweilige Zielsystem ist dabei natürlich unterschiedlich implementiert und richtet sich nach den Möglichkeiten und Anforderungen des jeweiligen Zielsystems. So bedient sich das PlugIn für den WinCC-Export zum Beispiel des Siemens Optionspaketes WinCC ODK (Open Development Kit), welches entsprechende Funktionen zur automatisierten Erstellung eines WinCC-Projektes zur Verfügung stellt. Das Plugin für ProVis.Visu erzeugt ein XML-basiertes internes Beschreibungsformat, das alle benötigten Informationen enthält. Nach dem Export ist die Anlage im Prozessleitsystem abgebildet und kann damit über das Leitsystem überwacht und gesteuert werden. Die Anbindung erfolgt dabei über den in Abschnitt 4 beschriebenen OPC-UA Server.

8 5.2 Datengetriebene Prozessüberwachung Mittels des OPC-UA-Servers ist es möglich eine große Anzahl an Sensordaten zur Verfügung zu stellen. Diese Sensordaten können,dazu verwendet werden, den aktuellen Zustand der Produktionsanlagen zu überwachen. Allerdings ist es bei einer großen Sensoranzahl nur unter großem Aufwand möglich, eine manuelle Parametrierung (z.b. das Setzen von Schwellwerten zur Alarmgenerierung) für die einzelnen Sensoren durchzuführen. Eine Möglichkeit, dieses Problem zu lösen, ist, ein datengetriebenes Modell der Anlage zu erlernen, welches den Normalzustand der Anlage darstellt. Das gelernte Modell wird mit aktuellen Prozessdaten abgeglichen. Bei einer starken Abweichung vom erlernten Normalzustand wird ein Alarm ausgelöst. Hierdurch wird die Anzahl der einzustellenden Parameter erheblich reduziert, da diese sich auf das zu lernende Modell beschränken. Zum Erlernen des Modells sind prinzipiell mehrere Ansätze möglich (für einen Überblick siehe z.b. [12]). Ein häufig verwendeter Ansatz zur datengetriebenen Modellierung bietet hierbei die Hauptkomponentenanalyse (PCA = Princial Component Analysis). Im Wesentlichen handelt es sich bei diesem Verfahren um eine lineare Transformation, welche den hochdimensionalen Originaldatensatz repräsentiert durch die Sensordaten unter Verlust eines Minimums an Information auf einen niedriger dimensionalen Datensatz transformiert. Informationen zur PCA und der Prozessüberwachung, speziell im Trink- und Abwasserbereich, finden sich z.b. [13] oder [14]. Da die PCA in der Regel zur Auswertung unterschiedlicher Sensortypen (z.b. Temperaturund Drucksensoren) verwendet wird, erfolgt in einem Vorverarbeitungsschritt zunächst eine z-score Normalisierung (Erwartungswert 0 und Varianz 1) der Messdaten [15]. Aus dem Datensatz der vorverarbeiteten Zeitreihen wird die Kovarianzmatrix bestimmt und in ihre Eigenwerte und Eigenvektoren zerlegt. Anhand der Eigenwerte und Eigenvektoren lässt sich im nächsten Schritt die so genannte Hotelling T 2 Statistik [16] berechnen. Bei der T 2 Statistik handelt es sich um ein univariates Maß, mit dem ungewöhnliche Schwankungen in den Sensordaten erfasst werden können. Es erfolgt hierbei also eine sehr starke Dimensionsreduktion und es müssen nicht die gesamten Sensordaten im Blick behalten werden, sondern es reicht, den jeweiligen Wert der T 2 Statistik zu überwachen. Zudem ist es möglich zu rekonstruieren, welcher Sensor welchen Einfluss auf den jeweiligen Wert der T 2 Statistik hat. Man hat hier also die Möglichkeit bei einem ausgelösten Alarm, trotz der durchgeführten Dimensionsreduktion, den auslösenden Sensor weiterhin zu lokalisieren.

9 6. Anwendungsbeispiel Wasserqualitätsanalyse Die allgemeingültige Methodik und umgesetzte Plattform soll an einem Anwendungsfall mit einer überschaubaren Anzahl von zu visualisierenden Daten evaluiert werden. Bei der Überwachung der Trinkwasserqualität handelt es sich um Daten verschiedener Messstationen, sowie unterschiedlicher Wasserwerke. Trinkwasserversorgungsnetze wurden und werden in letzter Zeit betreiberseitig mit einer großen Anzahl an Multiparametersonden ausgestattet. Multiparametersonden bestehen aus mehrere Sensoren, welche die Wasserqualitätsparameter Temperatur, Chlor, Leitfähigkeit und den ph-wert sowie die hydraulischen Parameter Druck und Durchfluss messen. Eine wichtige Aufgabe der Sonden ist es hierbei, die Betreiber des Wassernetzes über mögliche Kontaminierungen (z.b. durch einen Unfall, aber auch durch einen Terroranschlag) zu informieren. Im Folgenden wird erläutert, wie die entwickelte MoMo-Plattform zur Trinkwasserüberwachung eingesetzt werden kann. Mittels AutomationML wird ein Modell des Trinkwassernetzes sowie der Hauptstation des Wasserwerks erstellt Daraufhin wird das AutomationMl Modell dazu verwendet das User Interface zu generieren (Abschnitt 5.1), sowie die Anlage mit der in Abschnitt 4 beschriebenen Prozessanbindung zu simulieren.mittels des in Abschnitt 5.2 beschriebenen Verfahrens wird die Anlagenüberwachung durchgeführt. 6.1 AutomationML-Modell Bild 4 (links) zeigt die InstanceHierarchy des AutomationML Modells. Es gibt ein Wasserwerk mit einer Hauptmessstelle inklusive mehrerer Chlormesswerte und ein Wassernetz mit mehreren Messstellen. Alle Messwerte haben die gleiche Struktur, welche als SystemUnitClass vordefiniert und in Bild 4 (rechts) zu sehen ist. Die Auswertungs-InternalElements haben auch jeweils diese Struktur; der einzige Unterschied ist, dass die Value Attribute keinem Sensor zugeordnet, sondern für die Ergebnisse der Auswertungssoftware gedacht sind. Über das Unterattribut Note können von der Auswertungssoftware textuelle Informationen, z.b. Warnmeldungen zu dem Messwert propagiert werden. Das Value Attribut besitzt zwei opcua-variable Unterattribute. Die aml-opcua-variable bezeichnet die UA Variable des aggregierenden Servers, während die aml-opcua-sourcevariable die UA Variable beschreibt, von der der aggregierende Server die aktuellen Prozessdaten abholt. Die zweite ist also nur für aggregierenden Server interessant. Die für die Visualisierung relevanten Attribute werden in VisuFacets bereitgestellt. Die Facette ist im Wesentlichen eine Liste von Referenzen auf Attribute. Über die RefSemantic werden manchen Attributen noch besondere Bedeutungen zugewiesen. Eine StateVariable reprä-

10 sentiert den Gesamtzustand des Wasserwerks, während die mit SignificantVariable die wichtigen Attribute markiert wurden. 6.2 Prozessbild-Generierung In Bild 5 sind die Generierungs-Ergebnisse des Modells in das Zielsystem ProVis.Visu mit der hierarchischen Ausprägung zu sehen. Die Hierarchieebenen sind dabei gemäß des Ausgangsmodells verlinkt. Die Prozess- und Auswertungs-Daten erscheinen ebenfalls gemäß der Darstellung im Modell und sind hierarchisch gefiltert. Die grafische Darstellung in einem anderen Zielformat ist weitgehend identisch, zusätzliche Steuerelemente (Bildumschaltung, Exit, etc.) können aber durchaus systemspezifisch angelegt sein. Bild 4: AutomationML Struktur des Anwendungsbeispiels (links) und AutomationML Struktur der SystemUnitClass SensorValue (rechts) Bild 5: MoMo in ProVis.Visu (Hierarchieebene: Wasserüberwachung. Wassernetz, Messstelle S104, von links nach rechts)

11 6.2 Auswertung Die Überwachung des Trinkwasserversorgungsnetzes erfolgt mittels der in der Momo- Plattform enthaltenen datengetriebenen Prozessüberwachung. Insgesamt werden zur Überwachung des Trinkwassers vier Überwachungsmodule parallel trainiert und eingesetzt. Im Detail handelt es sich hier um die Überwachung für Chlor, Temperatur und ph-wert im Trinkwassernetz, sowie der Überwachung von Chlor im Wasserwerk. Die einzelnen gelernten Module, welche den Normalzustand des Versorgungsnetzes repräsentieren, werden hierzu mit den replizierten Prozessdaten des OPC UA Servers abgeglichen. Bei einer starken Abweichung zwischen trainiertem Modell und Messwert, wird von dem jeweiligen Modul ein Alarm ausgelöst. Im Zusammenspiel mit dem generierten User Interface, wird der ausgelöste Alarm über mehrere Ebenen hinweg visualisiert. Tritt ein Alarm an einem Sensor auf, werden hierzu zunächst der Sensor sowie die betroffene Sonde markiert. Des Weiteren wird angezeigt ob sich der Alarm im Wassernetz oder Wasserwerk ereignet hat. Dies bietet die Möglichkeit sehr schnell bei einem Alarm den betroffenen Sensor lokalisieren zu können, mit dem Vorteil durch die verwendete Hauptkomponentenanalyse nicht jeden Sensor manuell parametrieren zu müssen. Die einzelnen Sensor-Ids werden hierzu aus dem erstellten AutomationML Modell heraus ausgelesen. 7. Zusammenfassung und Ausblick Die einheitliche Akquisition von Prozess- und Qualitätsdaten auf Basis von offenen Standards spielt bei Industrie 4.0 eine große Rolle. Dabei geht es um eine Steigerung der Effektivität und Effizienz in der Produktion. In Zukunft soll der MoMo-Ansatz auf einen Anwendungsfall in der Produktion (bisher wurde nur die Wasserqualitätsanalyse) übertragen werden, die Grundelemente und komponenten bleiben dabei gleich, lediglich das AutomationML-Modell verändert sich. 8. Literatur [1] Miriam Schleipen, Michael Okon, Tanja Enzmann, Jiaqiu Wei: IDA Interoperable, semantische Datenfusion zur automatisierten Bereitstellung von sichtenbasierten Prozessführungsbildern. Tagungsband zum Kongress Automation 2011, , Baden- Baden, [2] Rainer Drath, Miriam Schleipen: Grundarchitektur: das Objektmodell. Datenaustausch in der Anlagenplanung mit AutomationML. Rainer Drath (Hrsg.), S , ISBN , Springer-Verlag Heidelberg Dordrecht London New York,

12 [3] IEC 62714, Engineering data exchange format for use in industrial automation systems engineering - Automation markup language, IEC standard series. [4] AutomationML e.v., [5] Miriam Schleipen: OPC UA supporting the automated engineering of production monitoring and control systems. Proceedings of 13th IEEE International Conference on Emerging Technologies and Factory Automation ETFA, , Hamburg, Germany, S , [6] IEC 62541, OPC Unified architecture, IEC standard series. [7] OPC Foundation, [8] Robert Henßen, Miriam Schleipen: Online-Kommunikation mittels OPC-UA vs. Engineering-Daten (offline) in AutomationML - Eine Möglichkeit der Integration und Kombination. VDI/VDE-Gesellschaft Meß- und Automatisierungstechnik -GMA-, Düsseldorf: Automation Branchentreff der Mess- und Automatisierungstechnik. Vol.1 : Smart X - powered by automation; Kongresshaus Baden-Baden, 01. und 02. Juli 2014, Düsseldorf: VDI-Verlag, 2014 (VDI-Berichte 2231), ISBN: , pp.59-74, [9] Companion Specification AutomationML for OPC UA - Draft; AutomationML e.v. and OPC Foundation; Mai 2015 [10] PCFF Plug and Control für flexible Fördertechnik, [11] Miriam Schleipen, Michael Okon, Thomas Hövelmeyer, Andreas Wagner, Gerhard Wolff, Halit Demir, Matthias Jentsch, Kai Furmans, Dennis Asi: PCFF - Plug&Control für flexible Fördertechnik. KommA Kommunikation in der Automation, Lemgo, November, [12] Shen Yin et. al.: A comparison study of basic data-driven fault diagnosis and process monitoring methods on the benchmark tennessee eastman process. Journal of Process Control, 22: , [13] Christian Kühnert, et. al.: Water quality supervision of distribution networks based on machine learning algorithms and operator feedback. Procedia Engineering, 89(0): , th Water Distribution System Analysis Conference. [14] R Murray, et al.: Water quality event detection systems for drinking water contamination warning systems. Development, testing, and application of canary. US Environmental Protections Agency, Office of Research and Development, National Homeland Security Research Center, [15] D.T. Larose. Data Mining Methods and Models. Wiley, [16] Evan Russell, Leo H Chiang, and Richard D Braatz. Data-driven methods or fault detection and diagnosis in chemical processes. Springer, 2000.