Warum Industrie 4.0 keine modellbasierte

Transkript

1 Warum Industrie 4.0 keine modellbasierte Softwareentwicklung braucht Und warum es ohne Modelle nicht gehen wird... Oliver Niggemann, Fraunhofer Anwendungszentrum Industrial Automation (IOSB-INA) und Institut für industrielle Informationstechnik (init), Lemgo Abstrakt deutsch Industrie 4.0 versucht, die Handhabung von komplexen Produktionsanlagen zu verbessern und eine flexible und adaptive Produktion umzusetzen. Aktuell liegt die Hauptschwierigkeit dieser Szenarien bei der Automationssoftware, deren Erstellung ist zeitaufwändig und fehleranfällig. Zur Lösung dieses Problems werden dabei zumeist zwei Hauptansätze verfolgt: (i) die modellbasierte Softwareentwicklung und (ii) die intelligente Automation, d.h. die Verwendung wissensbasierte Lösungsansätze. Dieser Artikel vergleicht diese beiden Ansätze anhand dreier Phasen des Lebenszyklus, der Planungsphase, der Betriebsphase und der Anlagenumbauphase. Intelligente technische Systeme / Industrie 4.0 / Modellbasierte Softwarentwicklung für die Automation Abstract English The efficient handling of complex production systems and the implementation of a more flexible and adaptable production lies at the heart of Industrie 4.0. Currently these scenarios fight with one main bottleneck: the creation and configuration of the corresponding automation software is timeconsuming and error-prone. Two main solutions exist for this problem: (i) model-based software development and (ii) intelligent automation, i.e. the usage of new knowledge-based solution approaches. This article compares these different solutions by applying them to three phases of the life-cycle, the planning phase, the operation phase and the plant reconfiguration phase. Intelligent technical systems / Cyber-physical Systems / Model based software development for automation

2 1. Industrie 4.0, die modellbasierte Softwareentwicklung und intelligente Systeme Auf dem ersten Blick gibt es wenig Einigkeit über den Inhalt von Industrie 4.0 und Cyber-physischen Systemen: Je nach persönlicher Vergangenheit der Experten stehen mal die Informationen im Mittelpunkt (Internet der Dinge), mal die Methoden (Selbstdiagnose, Selbstkonfiguration, etc.) oder die Systemfähigkeiten (Intelligente Technische Systeme). Bewegen wir uns aber weg von der technischen Ebene hin zu den ursprünglichen Fragestellungen, so wird das Bild homogener: Der zentrale Begriff ist die Komplexitätsreduktion [3]. Offensichtlich nehmen immer mehr Menschen den Umgang mit der heutigen Produktions- und Automatisierungstechnik als zu komplex, zu fehleranfällig und zu unflexibel war. Beispiele sind der Automatisierer, der Anforderungen bzgl. Inbetriebnahmezeiten, Energieeinsparungen und Zuverlässigkeit nicht in angemessener Zeit vereinbaren kann, der Werksleiter, der die Anforderungen bzgl. hoher Variabilität bei kleinen Stückzahlen (Stichwort: Losgröße 1) nicht mehr erfüllt, oder der Wartungsingenieur, der komplexe Fehler auf Systemebene nicht mehr in angemessener Zeit repariert. In jedem Fall besteht das Ziel in der Reduktion der vom Menschen wahrgenommen Komplexität bei Beibehaltung der Komplexität der Produktions- und Automatisierungstechnik. Insofern steht, und dies ist ein weiteres Merkmal von Industrie 4.0, immer der Mensch im Mittelpunkt dieser Arbeiten. Die klassische Antwort der Informatik, auch für die Automation, auf diese Fragen besteht im Frontloading und speziell in der modellbasierten Softwareentwicklung [10,12,13,14,15,16]. Bei diesen Ansätzen erlauben Modellierungswerkzeuge dem Experten, sein Wissen bzgl. der zu entwickelnden Software auf einem für ihn angenehmen Niveau zu formalisieren, d.h. zu modellieren. Angenehm ist ein Niveau, wenn Modellierungsniveau und das Niveau des mentalen Modell des Menschen, also sein inneres Bild der Software, nahe beieinander liegen. Der Begriff Frontloading beschreibt dabei das dadurch erhoffte Tauschgeschäft: So verlangt die Modellbildung initial mehr Zeit und Aufwand, allerdings verringern sich später im Prozess durch die bessere Spezifikation, durch die Möglichkeit der frühen virtuellen Systemüberprüfung z.b. mittels Simulation und durch die Möglichkeit der Codegenerierung Aufwände und Probleme. In der Summe ergibt sich für viele Anwendungsszenarien unter dem Strich eine signifikante Verbesserung des Entwicklungsprozesses [12-16]. Bild 1 zeigt einen typischen Ablauf der modellbasierten Softwareentwicklung: Der Experte spezifiziert auf möglichst abstrakte, für ihn angenehme Weise die Software. Auf Basis dieser Modelle wird die Automatisierungssoftware und die entsprechenden Konfiguration der Automation generiert. Die modellbasierten Softwareentwicklung zielt aber, im Gegensatz zur Modellentwicklung im Allgemeinen, immer auf eine Beschreibung der Software ab. Dies gilt auch, falls die Softwaremodelle durch Ergänzung von Prozessteilen, von Hardwaretopologie und von Basissoftware zu Systemmodellen [33,34] erweitert werden, i.a. wird auch bei diesen Ansätzen die Software manuell modelliert. Abbildung 1: Ein typischer Ablauf der Modellbasierten Softwareentwicklung Je häufiger jedoch Anlagen und damit die Automation aber geändert werden, desto häufiger muss dieser Engineering-Zyklus durchlaufen werden. Des Weiteren verbleibt alles Wissen bzgl. der korrekten Automation, wie z.b. Systemwissen und Steuerungswissen, beim Experten. D.h. eine Zunahme der Systemkomplexität muss sich in einer Zunahme der Modellierungskomplexität niederschlagen. Neue Modellbasierte Ansätze können diese Zunahme abschwächen aber nicht grundsätzlich verhindern. Eine Alternative zur modellbasierten Softwareentwicklung ist die intelligente Automation: Hier beschreibt der Experte nicht mehr den Ablauf der Automation, sondern nur noch das Automationsziel. D.h. Ziel des Engineering ist nicht mehr die Definition des Wie, sondern des Was. Klassische Produktionsziele sind Produkt-

3 merkmale, Durchsatz oder der maximale Energieverbrauch, Dieses Vorgehen entspricht dem Übergang von der klassischen prozedualen Automation hin zu einer zukünftigen deskriptiven Automation. Da das Automationsziel sich, anders als der Automationsablauf, auch bei Anlagenumbauten wie z.b, dem Austausch einen Anlagenmoduls, zumeist nicht ändert, ist der Experte bei diesem Ansatz nicht mehr ständig beteiligt. Darüber hinaus ist es einfacher das Automationsziel, z.b. in Form einer Beschreibung des finalen Produktes, festzulegen als den kompletten Automationsablauf zu beschreiben. Hierdurch erfolgt eine Reduktion der vom Experten wahrgenommenen Komplexität. Abbildung 2 zeigt den Unterschied zwischen diesen beiden Ansätzen im Fall eines Anlagenumbaus, also bzgl. Anforderungen wie Adaptivität und Flexibilität. Während im Fall der modellbasierten Softwareentwicklung der Mensch bei jeder Änderung involviert ist, reagiert die deskriptive Automation zumeist automatisch ohne Mitwirkung des Experten auf Änderungen. Abbildung 2: Vergleich der modellbasierten Softwareentwicklung und der deskriptiven Automation In den letzten Jahren sind immer mehr solche Entwicklungsprozesse in den Vordergrund der Forschung gerückt, die Prozess- und Produkt-Modelle in den Vordergrund stellen, d.h. die deskriptiv arbeiten. Hierzu haben auch Bemühungen zur Standardisierung solcher Modelle beigetragen [26,27]. In verschiedenen Arbeiten wurden solche Modelle im Kontext von Industrie 4.0 zur Erhöhung der Adaptivität der Automation eingesetzt [8,28,29,30]. Ein verwandter Ansatz sind Agentensysteme [23-25], bei denen allerdings nicht nur die Beschreibung des Produktionszieles, sondern auch algorithmische Aspekte der Selbstorganisation betrachtet werden. Im Folgenden werden die modellbasierte Softwareentwicklung und die deskriptive Automation anhand dreier Anwendungsfälle verglichen. Kapitel 2 vergleicht modellbasierte und deskriptive Ansätze bei der Planung von Automatisierungssystemen. In Kapitel 3 werden beide Ansätze für den Fall der Anomalieerkennung und Diagnose verglichen. Der Fall des Anlagenumbaus wird in Kapitel 4 geschildert. Ein Fazit wird in Kapitel 5 gezogen. 2. Ein Vergleich für die Planungs- und Inbetriebnahmephase Im Folgenden sollen die in Kapitel 1 geschilderten gegensätzliche Ansätze anhand mehrerer Forschungsprojekte verglichen werden, und zwar für den Anwendungsfall der Planungs- und Inbetriebnahme. Das EFRE Projekt initial (Höhere Produktivität durch den modellbasierten Entwurf und Betrieb von komplexen Automatisierungssystemen, [19]) versuchte mittels modellbasierter Softwareentwicklungsmethoden und mittels Simulation die Inbetriebnahme zu verkürzen. Das BMBF Projekt EfA (Entwurfsmethoden für Automatisierungssysteme mit Modellintegration und automatischer Variantenbewertung, [20]) geht anders vor: Der Benutzer modelliert in

4 diesem Ansatz nur die Anforderungen an die Automatisierungslösung, die Lösung selbst wird automatisch generiert. Das initial Projekt entwickelte einen typischen modellbasierten Ansatz zur Planung von Automatisierungssystemen. Dies beinhaltet zum einen ein Strukturmodell, d.h. ein Modell der Struktur der Produktionsanlage (z.b. Module und deren Verschaltung) und der Automatisierungstechnik (z.b. Steuerungen inkl. Software, Sensoren, Aktoren, Netzwerke). Abbildung 3 zeigt ein solches initial-strukturmodell. Dieses Strukturmodell kann als AutomationML Datei importiert und abgespeichert werden. Des Weiteren werden für Teile des Strukturmodells Verhaltensmodelle hinterlegt. Für die Anlagenmodule geschieht dies in der Modellierungssprache Modelica, für die Steuerungsanteile wird realer IEC61131-Code benutzt. Abbildung 3: Der modellbasierte Engineering-Ansatz im initial Projekt Im initial Projekt werden diese Modelle für verschiedene Aufgaben verwendet: Zum einen dienen die Modelle als Methode der Absprache und der Kommunikation zwischen den beteiligten Parteien. Zum anderen können die Modelle auf einem PC simuliert werden und so frühzeitig Automatisierungsfehler entdeckt werden. Letztendlich ist es auch möglich, in einer Hardware-in-the-Loop (HIL) Simulation eine reale Steuerung an eine simulierte Anlage anzuschließen und so die reale Steuerung vor Inbetriebnahme zu überprüfen. Weitere Details zum initial-projekt sind in [1,2] zu finden. Einen völlig anderen Ansatz verfolgt das EfA Projekt: In diesem Projekt spezifiziert der Experte nur die Anforderungen an das zu entwerfende Automatisierungssystem. Dies ist auch in Abbildung 4 zu sehen. Auf der linken Seite definiert der Experte auf Anforderungsniveau den zu automatisierenden Prozess, hier eine fliegende Säge. Das System generiert hieraus automatisch die Automationslösung inkl. Hardwaretopologie und Softwareblöcken. generieren Prozessbeschreibung, hier fliegende Säge Automationslösung für fliegende Säge Abbildung 4: Der Konfigurationsansatz im EfA Projekt In Abbildung 5 sind die beiden Ansätze noch einmal verglichen: Für den Automatisierer beim Systemintegrator

5 oder beim Betreiber ist der Aufwand für den deskriptiven Ansatz erheblich geringer, da nicht mehr die Lösung sondern nur noch das Ziel beschrieben werden muss. Hieraus folgt auch, dass der Automatisierer sich beim deskriptiven Ansatz auf Prozesswissen fokussieren kann, während er bei dem modellbasierten Ansatz auch erhebliches Wissen über die IT, die Software und die Automatisierungstechnik besitzen muss. Auf der anderen Seite muss zuvor ein Werkzeugentwickler das nötige Wissen über den Entwurfsprozess formalisieren und in Form eines Werkzeuges dem Automatisierer zur Verfügung stellen. Darüberhinaus ist Wissen über Produktionsmodule und Automatisierungsgeräte notwendig. Dieses Wissen muss entweder vom Anlagenoder Gerätehersteller bzw. vom Werkzeughersteller modelliert werden. Diese Aufwände für die deskriptive Automation fallen aber nur einmal an und nicht bei jedem Anlagenentwurf und Inbetriebnahme. Abbildung 5: Vergleich der beiden Ansätze für die Planung und die Inbetriebnahme Schönknecht: bitte austauschen) Ein erheblicher Unterschied ergibt sich für die Absicherung der Programmierung: Bei dem modellbasierten Ansatz läuft alles auf eine virtuelle Inbetriebnahme hinaus, die Steuerung wird, real oder als Code, gegen eine Simulation der Anlage getestet. Dies funktioniert allerdings nur unter der Annahme, dass ein gutes, mit der Realität abgeglichenes Anlagenmodell existiert. Genau an diesem Punkt liegt aber das Problem: Im Allgemeinen haben weder Systemintegrator noch Betreiber die Zeit und die Ressourcen, um solche Modelle zu entwickeln. Eine Alternative ist es, dass Maschinen- und Anlagenbauer Modelle ihrer Anlagen mitliefern und diese später über Austauschformate wie AutomationML [17] zu einem Gesamtmodell inetgrieren. Allerdings ergeben sich hierbei diverse Probleme: (i) Für verschiedene Zwecke wie SPS-Programmierung oder Erstellung der Leitsysteme sind unterschiedliche Modelle notwendig, d.h. es wird gar nicht nur ein Modell sondern diverse Modelle benötigt. (ii) Eine Modellparametrisierung ist nur mit Wissen über das Gesamtsystem möglich. Dies setzt aber voraus, dass der Systemintegrator oder der Betreiber über das notwendige Wissen verfügen und, zwecks Abgleich zwischen Modell und Realität, auch das Systemverhalten vermessen können. (iii) Aktuell ist der Business Case für die Maschinen- und Anlagenbauer unklar. Im Falle der deskriptiven Automation existieren keine simulationsfähigen Anlagenmodelle, d.h. ein Modellerstellungs- und Parametrisierungsprobleme gibt es in der Form nicht. Stattdessen muss einmalig das Wissen über die automatische Erzeugung der Steuerungssoftware aus der Beschreibung des Automationszieles modelliert werden. Diese Synthese-Frage ist bislang nicht vollständig erforscht und stellt die größte Herausforderung bei der Umsetzung des deskriptiven Ansatzes dar. Das EfA Projekt setzt hierzu z.b. die Steuerungssoftware kompositionell aus fertigen Bausteinen, also Software-Komponenten in Form von IEC61131-Funktionsblöcken, zusammen. Hierzu werden zum einen Methoden des Constraint-Solving zur Konsistenzsicherung der Anforderungen und zur Berechnung von unbekannten Systemgrößen verwendet. Regelsysteme wählen dann die passende Automationstopologie aus und bilden die Software auf die Hardware ab. Das Ergebnis sind mehrere Lösungsvarianten, welche nach Zielkriterien wie z.b. Preis bewertet werden Sollte dieses Software-Synthese aber gelöst werden, entfällt der Bedarf an Tests durch eine Simulation, da man nun statt der Software die Software-Generierung absichern kann. Dies ist analog zum Compilerbau, bei welchem

6 auch nicht das Kompilat sondern der Compiler getestet wird. 3. Ein Vergleich für die Betriebsphase In der Betriebsphase stellen sich Fragen zur Erkennung von Anomalien, von suboptimalen Energieverbräuchen oder von Verschleiß [4-7]. Aktuell löst der Experte diese Fragen zumeist durch das manuelle Kodieren von festen Regeln im Automationscode (siehe linke Seite von Abbildung 6), diese Regeln schließen von Symptomen auf Anomalien oder Optimierungsbedarf [9]. Hierzu müssen aber alle Anomalien vorausgedacht werden. Im Kontext von Industrie 4.0 mit dem Anspruch auf Unterstützung für den häufigen Anlagenumbauten bedeutet dies auch, dass diese Regeln häufig manuell bearbeitet werden müssen Abbildung 6: Vergleich der beiden Ansätze für die Anomalieerkennung und Diagnose Ein anderer Nachteil von manuellen Diagnoseregeln ergibt sich aus der Komplexität auf Systemebene: Während es für einzelne Aggregate noch möglich ist, die Symptom à Anomalie Regeln manuell aufzustellen, ist dies aufgrund der Kombinatorik für Systeme mit vielen Abhängigkeiten nicht mehr möglich, im schlimmsten Fall muss die Software zwischen allen Kombinationen von Symptomen differenzieren. Modellbasierte Ansätze (siehe rechte Seite von Abbildung 6) gehen daher anders vor [4,5,6]: Sie vergleichen die Vorhersagen eines Verhaltensmodells mit den Beobachtungen des Systems, ergeben sich Diskrepanzen wie z.b. ein schlechter Energieverbrauch, so wird der Benutzer darüber informiert. Allerdings stellt sich sofort die Frage, woher das Verhaltensmodell kommt. Eine manuellen Modellierung führt zu allen im Kapitel 2 diskutierten Nachteile. Aus diesem Grund geht das BMBF Projekt AVA (Abstraktion von Verhaltensmodellen für Anlagen des Maschinenbaus aus Messungen in verteilten Automatisierungssystemen, [21]) anders vor: Die Modelle werden, in Form von zeitbehafteten hybriden Automaten, automatisch anhand von Systembeobachtungen gelernt. Abbildung 7 zeigt ein Beispiel, ein Verhaltensmodell für ein Modul der Lemgoer Modellfabrik (siehe Foto in Abbildung 7) wurde automatisch anhand von Systembeobachtungen erlernt. Solche Lernverfahren für Automaten sind ein aktuelles Forschungsgebiet: Interessant sind für die Automation dabei Verfahren, die nur Positivbeispiele verwenden. Für große Systeme existieren Verfahren, die die Anzahl der Zustände minimieren, z.b. ein Verfahren zum Lernen von zeitbehafteten Automaten [32] und aus dem AVA Projekt ein Verfahren für hybride Automaten [8]. Andere Verfahren arbeiten mit dem gegebenen Zustandsraum der IO-Signale [31].

7 Abbildung 7: Ein gelernter Automat mit einem unerwarteten Ereignis, z.b. verursacht durch einen SW-Fehler Das Anomalieerkennungssystem vergleicht nun gelerntes Modell und Systemverhalten: Während der Zustände 0 bis 4 in Abbildung 7 verhalten sich Modell und System identisch, im Zustand 4 tritt aber ein unbekanntes Signal auf. Dies wird als Anomalie dem Benutzer mitgeteilt, in diesem Beispiel liegt ein Programmierfehler vor. Der Benutzer gibt also nur noch deskriptiv vor, welche Art von Anomalie (z.b. Zeit-, Energie- oder Sensoranomalie) ihn interessiert und mit welcher Empfindlichkeit das System reagieren soll. Abbildung 8 zeigt den Vergleich: Da im Falle der deskriptiven Automation der Automatisierer nur noch die Analyseziele formuliert, schneidet die deskriptive Automation klar besser ab. Ein Wehmutstropfen bleibt aber, das Vorgehen fällt und steigt mit der Möglichkeit, Verhaltensmodelle automatisch zu erlernen. Erste Ergebnisse zeigen, dass dies für reale Anlagen möglich ist [8, 18, 31], das Thema bleibt aber ein Forschungsgegenstand und es ist noch ein weiter Weg hin zu einer kommerziellen Umsetzung in Werkzeugen. Abbildung 8: Vergleich für den Betriebsfall (@Fr. Schönknecht: bitte austauschen) 4. Ein Vergleich für die Umbauphase Die Umbauphase wurde schon kurz in Kapitel 1 angerissen. In der modellbasierten Softwareentwicklung (siehe linke Seite von Abbildung 2) läuft ein Anlagenumbau bislang zumeist wie folgt ab: Nachdem der mechanische Anlagenumbau abgeschlossen ist, werden neue Geräte wie Sensoren, Aktoren und Steuerungen im Netzwerk angeschlossen, dies beinhaltet zumeist eine Umkonfiguration des Netzwerkes. Nun müssen alle angeschlossenen Steuerungen ebenfalls geändert werden, um die neue Netzwerkkonfiguration zu berücksichtigen und um neue Kommunikationsbeziehungen, z.b. zu neuen Anlagenmodulen, aufzubauen. Oft werden auch Steuerungsalgorithmen angepasst und Parameter wie z.b. Zykluszeiten in den Steuerungen geändert. Des Weiteren erfolgt eine

8 Anpassung in höheren Schichten wie OPC-Server, Leittechnik und MES-Systeme. All diese Schritte sind mit einem hohen Entwicklungsaufwand und einem hohen Testaufwand verbunden. Selbst bei Verwendung höherwertiger Modelle [14, 16], aus denen viele dieser Einstellungen generiert werden können, verbleibt ein manueller Engineeringaufwand in jedem Umbauzyklus. Die deskriptive Automation (rechte Seite Abbildung 2) geht hier anders vor, sie beschriebt nur das gewünschte Endprodukt. Bei vielen Anlagenumbauten wie z.b. einem Austausch eines Produktionsmoduls bleibt dieses Ziel konstant, d.h. eine manuelle Änderung der Automation ist gar nicht notwendig. In anderen Fällen wie z.b. der Variation des Produktes muss nur die Produktbeschreibung angepasst werden. In jedem Fall verringert sich der Aufwand massiv. Solche Ansätze erforscht aktuell das vom BMBF geförderten Spitzenclusterprojekt itsowl-iv (Querschnittsprojekt Intelligente Vernetzung, [22]). Abbildung 9 zeigt das Vorgehen in diesem Projekt: Der Experte modelliert nicht mehr die Automationssoftware. Stattdessen modelliert er das Endprodukt und den Prozess, der Prozess besteht dabei aus typisierten Prozessschritten wobei jeder Prozessschritt als Ein- und Ausgaben Zwischenprodukte und Ressourcen aufweist. Aus dieser Beschreibung wird die Automationssoftware automatisch generiert, z.b. in Form einer Verschaltung und Parametrisierung von vorgegebenen Softwarekomponenten. Abbildung 9: Generierung von Automatisierungssoftware anhand einer Produkt- und Prozessbeschreibung Abbildung 10 vergleicht die beiden Ansätze für diesen Fall: Anstatt die Softwareänderungen in allen Modellen wie z.b. IEC61131 einzupflegen, formalisiert der Experte im Fall des deskriptiven Ansatzes nur das Produkt und, wie im Fall des Projektes itsowl-iv, auch den Prozess. Hierdurch entfallen auch die Testaufwände. Die Vorteile des deskriptiven Ansatzes basieren aber auf der abgesicherten und getesteten Generierung der Software auf Basis der Produkt- und Prozessmodelle. Hierzu müssen entsprechende Modelle entweder von den Maschinen- und Anlagenbauer oder von den Werkzeugherstellern kommen. Des Weiteren müssen die Werkzeug- und Gerätehersteller die neuen Verfahren umsetzen. Genau hier liegen die aktuellen Forschungsfragestellungen. Aktuell werden im Projekt itsowl-iv als Lösung Planungsalgorithmen und Fallbasierte Ansätze untersucht.

9 Abbildung 10: Vergleich der beiden Ansätze für den Fall des Anlagenumbaus Schönknecht: bitte austauschen) 5. Ein Fazit Die modellbasierte Softwareentwicklung und die deskriptive Automation sind zwei grundverschiedene Ansätze zur Umsetzung von Industrie 4.0. Während der erste Ansatz Methoden entwickelt, damit ein Experte die Software möglichst bequem und sicher modellieren kann, setzt der deskriptive Ansatz auf eine Beschreibung des Produktziels, die Software wird dabei aber nicht modelliert sondern generiert. Aber auch beim deskriptiven Ansatz spielen Modelle eine zentrale Rolle, sie beschreiben nun aber das Produkt, z.t. den Prozess und sie spezifizieren Optimierungsziele wie Durchsatz und Energieverbrauch. Da sie aber die Software nicht statisch modellieren, kann der dadurch gewonnen Freiraum zur Umsetzung von Adaptivität (Kapitel 2 und 3), von Qualitätsverbesserung (Kapitel 3) und von Aufwandsoptimierung beim Engineering (Kapitel 2 und 4) genutzt werden. Denn genau in diesem Freiraum zwischen deskriptiv beschriebenen Produktionsziel ( Was ) und fixer Ablaufsteuerung in der Automation ( Wie ) arbeiten wissensbasierte Methoden wie Selbstkonfiguration, Selbstdiagnose und Selbstoptimierung. Die dargestellten Beispiele zeigen aber auch deutlich, dass die modellbasierte Softwareentwicklung reifer und weiter entwickelt ist. Zur Umsetzung der deskriptiven Automation muss die Forschung noch diverse offene Forschungsfragen lösen: (i) Die Formalismen für Produkte, Prozesse und Optimierungsziele sind noch Forschungsgegenstand und noch nicht standardisiert. (ii) Es fehlen Methoden zum automatischen Modelllernen. (iii) Auf Basis der deskriptiven Beschreibung muss die Automationssoftware automatisch generiert werden. Hier fehlen abgesicherte Methoden der Softwaregenerierung. (iv) Es ist unklar, wie eine Migration von der klassischen Engineeringkette hin zu einer Werkzeugkette der deskriptiven Automation gelingen kann. Dies liegt u.a. auch daran, dass eine Verlagerung von Aufwänden weg vom Automatisierer und hin zu den Maschinen- und Anlagenbauer, den Geräteherstellern und den Werkzeugherstellern geschehen muss. Dieser Aufwand lohnt aber, da dadurch der Aufwand nur noch einmalig an zentralen Stellen entsteht und nicht mehr bei jedem Betreiber neu. Referenzen [1] Faltinski, Sebastian ; Niggemann, Oliver; Moriz, Natalia; Mankowski, Andre: AutomationML: From Data Exchange to System Planning and Simulation IEEE International Conference on Industrial Technology (ICIT). Mar [2] Graeser, Olaf; Kumar, Barath; Moriz, Natalia; Maier, Alexander; Niggemann, Oliver: AutomationML as a Basis for Offlineand Realtime-Simulation. 8th International Conference on Informatics in Control, Automation and Robotics (ICIN- CO)(Noordwijkerhout, The Netherlands, July, 2011) Jul [3] VDMA: Management summary importance of information and automation technology in the products of manufacturing systems, engineering and plant engineering, [4] Isermann, R.: Model-based fault detection and diagnosis - status and applications. 16th IFAC Symposium on Automatic Control in Aerospace, St. Petersbug, Russia, [5] Struss, P.; Ertl, B.: Diagnosis of bottling plants - first success and challenges. 20th International Workshop on Principles of Diagnosis, [6] Christiansen, L.; Fay, A.;Opgenoorth, B.; Neidig, J.: Improved Diagnosis by Combining Structural and Process Knowledge. IEEE ETFA 2011 [7] Windmann, S.; Jiao, S.; Niggemann, O.; Borcherding, H., A Stochastic Method for the Detection of Anomalous Energy Consumption in Hybrid Industrial Systems, IEEE 11th International Conference on Industrial Informatics - INDIN, 2013.

10 [8] Niggemann, O.; Stein, B., Vodencarevic, A.; und Maier, A.: Learning behavior models for hybrid timed systems, Twenty-Sixth Conference on Artificial Intelligence (AAAI-12), [9] Li, H.; Yin, B.; Li, N.; Guo, J.: Research of fault diagnosis method of analog circuit based on improved support vector machines. volume 1, pages , may [10] Stahl, T.; Völter, M.; Efftinge, S.: Modellgetriebene Softwareentwicklung. Techniken, Engineering, Management. DPunkt- Verlag, Heidelberg [11] Cannata, A.: Energy efficient driven process analysis and optimization, Discrete Manufacturing, Conference of Industrial Electronics, [12] Maurmaier, M.: Leveraging model-driven development for automation systems development, Emerging Technologies and Factory Automation, ETFA IEEE International Conference on, vol., no., pp.733,737, Sept [13] Streitferdt, D.; Wendt, G.; Nenninger, P.; Nyssen, A.; Lichter, H.: Model Driven Development Challenges in the Automation Domain, Computer Software and Applications, COMPSAC '08. 32nd Annual IEEE International, July Aug [14] Papakonstantinou, N.; Sierla, S.; Koskinen, K.: Object oriented extensions of IEC as an enabling technology of software product lines, 2011 IEEE 16th Conference on Emerging Technologies & Factory Automation (ETFA), 5-9 Sept [15] Thramboulidis, K.; Frey, G.: An MDD process for IEC based industrial automation systems, 2011 IEEE 16th Conference on Emerging Technologies & Factory Automation (ETFA), 5-9 Sept [16] Witsch, D.; Vogel-Heuser, B.: Close integration between UML and IEC : New possibilities through object-oriented extensions, IEEE Conference on Emerging Technologies & Factory Automation, 2009 (ETFA), Sept [17] Drath, R.; Weidemann, D.; Lips, S.; Hundt, L, Lüder, A.; Schleipen, M.: Datenaustausch in der Anlagenplanung mit AutomationML, R. Drath, Ed. Springer, [18] Niggemann, Oliver; Vodenčarević, Asmir; Maier, Alexander; Windmann, Stefan; Kleine Büning, Hans: A Learning Anomaly Detection Algorithm for Hybrid Manufacturing Systems. The 24th International Workshop on Principles of Diagnosis (DX- 2013) Jerusalem, Israel, Oct [19] [20] [21] [22] [23] Pech, Stephan, Software Agents in Industrial Automation Systems, IEEE Software, May/June 2013 [24] Mubarak, Hisham; Göhner, Peter: Einsatz von Agenten für das Selbstmanagement von Automatisierungssystemen, MKWI 2010 [25] Schraufstetter, Markus; Vogel-Heuser, Birgit: Konzept zur Erhöhung der Flexibilität von Produktionsanlagen durch den Einsatz rekonfigurierbarer Anlagenkomponenten und echtzeitfähiger Softwareagenten, Informatik aktuell: Echtzeit Herausforderungen durch Echtzeitbetrieb, Fachtagung des GI/GMA - Fachausschusses Echtzeitsysteme, Boppard, [26] Felleisen, M.;, Ulrich, A.; Fay, A.; Enste, U.;Polke, B.: Formalisierte Prozessbeschreibung in der praktischen Anwendung. 1. Teil: Erstellen einer Prozessbeschreibung nach VDI/VDE-Richtlinie 3682, Automatisierungstechnische Praxis, Heft 9/2009 [27] Döbrich, Udo; Heidel, Roland: Modell zur Beschreibung cyber-physischer Systeme - Modellierung mit Merkmalen unterstützt Industrie 4.0, atp edition, 12/2013 [28] Pfrommer, J.; Schleipen, M.; Beyerer, J.: Fähigkeiten adaptiver Produktionsanlagen, atp Edition, 11/2013 [29] Angelsmark, O.; Malec, J.; Nilsson, K.; Nowaczyk, S.; Prosperi, L.: Knowledge Representation for Reconfigurable Automation Systems, International Conference on Robotics and Automation (ICRA-07) Workshop on Semantic Information in Robotics, Rome, Italy, 2007 [30] Kainz, G.; Keddis, N.; Pensky, D.; Buckl, C.; Zoitl, A.; Pittschellis, R.; Kärcher, B.: AutoPnP Plug-and-produce in der Automation: Wandelbare Fabrik als cyberphysisches System. atp edition, April 2013 [31] Schneider, S.; Litz, L.: Automatische Fehlerdiagnose SPS-gesteuerter Anlagen - Von der Beobachtung zu den Fehlerkandidaten, atp edition, 07-08/2013 [32] Verwer, S.: Efficient Identification of Timed Automata: Theory and Practice. PhD thesis, Delft University of Technology, 2010 [33] Kleiner, S.; Kramer, C.: Model based Design with System Engineering Based on RFLP V6, In: Smart Product Engineering, Springer Verlag, 2013 [34] Niggemann, Oliver; Stroop, Joachim: Models for Model's Sake. Proceedings of the 30th International Conference on Software Engineering (ICSE) - Experience Track on Automotive Systems, Leipzig, Germany, May 2008, May Anhang Prof. Dr. Oliver Niggemann (geb. 1971) ist seit 2008 Professor der Informatik am Institut Industrial IT (init) der Hochschule OWL. Er studierte Informatik in Paderborn, wo er 2001 auch promovierte. Er ist auch stellvertretende Leiter des Fraunhofer Anwendungszentrum Industrial Automation (IOSB-INA) in Lemgo. Seine aktuellen Forschungsschwerpunkte liegen im Einsatz von Methoden des Künstlichen Intelligenz und des maschinelles Lernens im Gebiet der industriellen Automation.

11 Fraunhofer-Anwendungszentrum Industrial Automation (IOSB-INA) Langenbruch Lemgo Tel.: +049 (0) Oliver.niggemann@iosb-ina.fraunhofer.de