Forschungsthemen

Lösungen und Handlungsempfehlungen für die nationale Umsetzung der U-Space-Verordnung – LUV
bearbeitet durch: M.Sc. Tobias Grebner, M.Sc. Luca von Rönn

Modulare Produktionslogistik (MoProLog)
bearbeitet durch: M.Sc. Michelle Blumenstein

Analyse von GRAFCET-Spezifikationen zur Erkennung von Entwurfsfehlern (AGRAFE)
bearbeitet durch: M.Sc. Aron Schnakenbeck

Automatisierte Datenverknüpfung von der Auslegung bis zur Produktion (ADAPT)
bearbeitet durch: M.Sc. Maximilian Weigand

Smart & Stustainable RTM 4.0 (SAUBER 4.0)
bearbeitet durch: M.Sc. Tom Jeleniewski, M.Sc. Jonathan Reif

Entwicklung von Energiemanagementschnittstellen für IoT-Technologien (IoT_EnRG)
bearbeitet durch: M.Sc. Leif-Thore Reiche

Integrierte Plattform für Peer-to-Peer Energiehandel und Aktive Netzführung (PEAK)
bearbeitet durch: M.Sc. Alexandra Karmann, M.Sc. Jan-Philip Beck und M.Sc. Maximilian Kilthau.

Daten- und prozessbasierte Zustandsermittlung für eine wertorientierte Komponentenbewirtschaftung in imperfekter Umgebung (DaProKo)
bearbeitet durch: MBA B. Eng. Maximilian Rappl, M.Sc. David Winkler

TIME4CPS – Ein Software-Framework zur Analyse des zeitlichen Verhaltens von Produktions- und Logistikprozessen
bearbeitet durch: M.Sc. Tom Westermann und M.Sc. Maximilian Peters

Urbaner Drohnen-Verkehr effizient organisiert (UDVeo)
bearbeitet durch: M.Sc. Sebastian Törsleff, M.Sc. Evelyn Fischer, M.Sc. Tobias Grebner und M.Sc. Felix Stückrath

Agentenbasierte Steuerung der Produktionslogistik (Agent.Pro)
bearbeitet durch: M.Sc. Felix Gehlhoff

Modellexperimente in der operativen Energiesystemanalyse (MEO)
bearbeitet durch: M.Sc. Jan-Philip Beck

Automatisierung des Löschvorgangs bei einem Normbrandversuch
bearbeitet durch: M.Sc. Fabian Stoller

Mittelstand 4.0-Kompetenzzentrum Hamburg (M40HH)
bearbeitet durch: M.Sc. Timo Busert, M.Sc. Feras El Sakka, M.Sc. Alexander Hayward

xMODERN – Cross Platform MOdel Driven Engineering avataRs Network
bearbeitet durch: M.Sc. Claas Steffen Gundlach, M.Sc. Leif-Thore Reiche

Digitales Typenschild
bearbeitet durch: M.Sc., MBA Alaettin Dogan, M.Sc. Yuanheng Zhang

AeroCut 4.0: Digitaler (Prozess-) Zwilling als Grundlage der Prozessoptimierung in der Fräsbearbeitung
bearbeitet durch: M.Sc. Christian Corinth, M.Sc. Birte Caesar

Räumliche auf Bildverarbeitung basierende Echtzeit-Deflagrations-Detektion
bearbeitet durch: M.Sc. Jakob Krooß

Forever Young Production Automation with Active Components – FYPA²C (DFG-Projekt)
bearbeitet durch: Dr.–Ing. Jan Ladiges, M.Sc. Abhishek Chakraborty, M.Sc. Felix Gehlhoff

Engineering-Unterstützung durch Simulation / Virtuelle Inbetriebnahme
bearbeitet durch: Suthida Thongnuch, M.Sc, Dr.–Ing. Philipp Puntel Schmidt, M.Sc. Artan Markaj

Effiziente Herstellverfahren und Technologien für 1-Tank-Abwassersysteme (HUTAB)
bearbeitet durch: M.Sc. Jakob Krooß, M. Sc. Gian Mewes

Formale Methoden zur Spezifikation und Implementierung von Steuerungen
bearbeitet durch: Robert Julius, M.Eng., M.Sc. Sophia Cordes

Agentensystem zur dezentralen Steuerung der Energieverteilung
bearbeitet durch: Dr.–Ing. Tobias Linnenberg, Dipl.–Ing. Erik Wassermann, M.Sc. Sebastian Törsleff

Ontology Engineering for Collaborative Embedded Systems
bearbeitet durch: Dr.–Ing. Constantin Hildebrandt, M.Sc. Sebastian Törsleff

Flexibilisierung von Maschinen (DFG-Projekt FlexA)
bearbeitet durch: Dr.–Ing. Xuan-Luu Hoang

CrESt: Modellbasierte Entwicklung kollaborativer eingebetteter Systeme
bearbeitet durch: Dr.–Ing. Constantin Hildebrandt, M.Sc. Birte Caesar, M.Sc. Alexander Hayward, M.Sc. Sebastian Törsleff

Einordnung der Beispiele der Industrie-4.0-Landkarte in die Anwendungsszenarien (EiBILA)
bearbeitet durch M.Sc. Timo Busert, M.Sc. Marcus Lewin

Semantische Allianz für Industrie 4.0 (SemAnz40)
bearbeitet durch: Dr.–Ing. André Scholz und Dr.–Ing. Constantin Hildebrandt

Automatisierung komplexer Arbeitsprozesse der Bauteilbearbeitung mit Hilfe von Industrierobotern
bearbeitet durch: Dipl.–Ing. Tobias Ernst, Alaettin Dogan, M.Sc.

IT-Sicherheit von automatisierten Anlagen
bearbeitet durch:Dipl.–Ing. Matthias Glawe, Dr.–Ing. André Scholz, Dr.–Ing. Thomas Holm

Interdisziplinäre Wiederverwendung im Engineering automatisierter Anlagen
bearbeitet durch: Dr.–Ing. Sebastian Schröck

Gebäudeautomatisierung: Requirements Engineering und Engineering-Unterstützung
bearbeitet durch: Dr.–Ing. André Scholz

Automatische Auswertung von PDF-Engineering-Dokumenten
bearbeitet durch: Herrn Dr.–Ing. Xuan-Luu Hoang und Herrn Dr.–Ing. Esteban Arroyo

Unterstützung des Auswahlprozesses von Sensoren durch Nutzung von Methoden der künstlichen Intelligenz
bearbeitet durch: Dr.–Ing. Maik Riedel

Werkzeug und Methode zur Formalisierten Prozessbeschreibung entsprechend VDI-Richtlinie 3682
bearbeitet durch: Dr.–Ing. André Scholz und Dr.–Ing. Sebastian Schröck

Modellierung von Zusammenhängen mittels Struktur- und Prozessbeschreibungen automatisierungstechnischer Systeme
bearbeitet durch: Dr.–Ing. André Scholz

Funktionale Anlagenbeschreibung
bearbeitet durch: Dr.–Ing. André Scholz

Stabilitätsanalyse dezentral-autonomer Entscheidungssysteme
bearbeitet durch: Dipl.–Ing. Ireneus Wior

Nutzen von Information für dezentrale Steuerungen
bearbeitet durch: Dipl.–Ing. Stefan Jerenz

Funktionaler Anwendungsentwurf für verteilte Automatisierungssysteme – FAVA (DFG-Projekt)
bearbeitet durch Dr.–Ing.. Karin Eckert

Verlässlichkeits-Anforderungen in Anlagenbeschreibung und Prozessbeschreibung
bearbeitet durch Dr.–Ing. Lars Christiansen

Entwicklung von Mitteln zur Qualitätssicherung für den Ersatz analoger Rechentechnik durch rechnerbasierte Leittechnik in Kernkraftwerken
bearbeitet durch: Dr.–Ing. Markus Göring

Offenheitsmetrik für Engineering-Werkzeuge

Anwendung von Entwurfsmustern auf die Automatisierungstechnik
bearbeitet durch Dr.–Ing. Carsten Mahler

Modellassoziation und Abhängigkeitsmanagement im industriellen Lösungsgeschäft
bearbeitet durch: Dr.–Ing. Tobias Jäger

Bewertung des Nutzen von dezentralen Steuerungskonzepten
bearbeitet durch: Dr.–Ing. Sebastian Schreiber

Bus-ID: RFID-basierte akustische Unterstützung blinder und sehbehinderte Menschen für Orientierung und Information beim Zugang zum ÖPNV und an Ampeln
bearbeitet durch: Martin Hennig, M.Sc., Dipl.-Psych. Cornelia Vogel, Dipl.-Phys. Helmut Weber

Durchgängiges Beschreibungsmodell für den Feldgeräte-Lebenszyklus.
bearbeitet durch Dr.–Ing. Yaoying Lin

Analyse und Re-Implementierung von SPS-Programmen mit Hilfe von Automaten
bearbeitet von: Dr.–Ing. Mohammed Bani Younis

Wissensbasierte Dispositionsunterstützung im Schienenverkehr
bearbeitet durch Prof. Dr.–Ing. Alexander Fay

Robotergestützte minimalinvasive Endoprothetik (ROMEO).

Informationsmodelle sind die tragende Säule im Engineering von automatisierten Anlagen. An der Professur für Automatisierungstechnik an der Helmut-Schmidt-Universität Hamburg wird seit 15 Jahren an Methoden, Beschreibungsmitteln und Werkzeugen für die Erstellung und Nutzung solcher Informationsmodelle geforscht. In dieser Abhandlung werden diese Arbeiten mit dem Anlagen-Lebenszyklus in Bezug gesetzt.

Informationsmodelle im Lebenszyklus automatisierter Anlagen

1. Engineering: eine erste Annäherung

Auch wenn inzwischen 15 Jahre „Bologna-Prozess“ die europäische Bildungslandschaft verändert haben und der Abschluss Diplom-Ingenieur nun nicht mehr vergeben wird, besteht über das Berufsbild des Ingenieurs weiterhin großer Konsens: es ist gekennzeichnet durch „die systematische Aneignung, Beherrschung und Anwendung von wissenschaftlich-theoretisch fundierten und empirisch gesicherten technischen Erkenntnissen und Methoden“ – so formuliert von der Gliederung „Beruf und Gesellschaft“ des Vereins Deutscher Ingenieure (VDI) und einer breiten Öffentlichkeit zugänglich über [Wiki09].

Sucht man hingegen nach einer zusammenfassenden Bezeichnung für das Schaffen des Ingenieurs, so wird man in der deutschen Sprache nicht fündig: „entwerfen“, „entwickeln“, „erfinden“: all diese Tätigkeiten beschreiben es nicht richtig oder nicht vollständig (siehe unten). In den USA wurde hingegen schon früh der Begriff des „Engineering“ geprägt: das „Engineers‘ Council for Professional Development“, vergleichbar mit dem VDI definierte bereits 1941 Engineering als „[T]he creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property.“ [ECPD41]. An dieser Definition ist dreierlei bemerkenswert:

1. Die kompromisslose Bezugnahme auf wissenschaftliche Methoden zu einem Zeitpunkt, zu dem zum Beispiel die Automatisierungstechnik als Wissenschaftsgebiet noch gar nicht etabliert war.
2. Die umfassende – heute würde man sagen „lebenszyklus-übergreifende“ – Sicht auf Entwurf und Realisierung, aber auch Betrieb und Diagnose.
3. Die Orientierung an funktionaler Zielerreichung und am gesellschaftlichen Nutzen hinsichtlich Wirtschaftlichkeit und Sicherheit.

Mangels einer entsprechenden, gleichermaßen umfassenden Bezeichnung in der deutschen Sprache hat sich „Engineering“ sukzessive auch im deutschen Sprachraum durchgesetzt. So bezeichnet sich der VDI selbst als „engineering association“ [VDI09].

[ECPD41]	Science, Volume 94, Issue 2446, 11/1941, p. 456.
[VDI09]	N.N.: VDI – The Association of German Engineers. Quelle: http://www.vdi.de/index.php?id=2657&L=1 .
[Wiki09]	N.N.: Ingenieur. Quelle: http://de.wikipedia.org/wiki/Ingenieur .

2. Engineering als Charakteristikum des Projektgeschäfts

Der Begriff „Engineering“ wird im deutschen Sprachraum insbesondere dort eingesetzt, wo der Begriff „Entwicklung“ nicht zutreffend oder nicht ausreichend ist. Die Tätigkeiten der Konzeption, des Grobentwurfs, des Detailentwurfs, der (zunächst prototypischen) Realisierung und des Tests eines technischen Produkts, z.B. eines Kraftfahrzeugs oder einer Kamera, welches danach in Serie produziert wird, lassen sich unter „Entwicklung“ subsumieren. Anders stellt sich die Situation im Entstehungsprozess von Anlagen dar, z.B. bei Produktionsanlagen der fertigungs- oder verfahrenstechnischen Industrie, bei Kraftwerken, Ver- und Entsorgungsanlagen oder Transporteinrichtungen wie Flughäfen. Derartige Anlagen sind im Allgemeinen sehr komplex, d.h. sie enthalten Wirkbeziehungen zwischen Tausenden von Sensoren und Aktoren, und müssen daher sorgfältig und systematisch, mit anderen Worten ingenieurwissenschaftlich, geplant und realisiert werden. Das „Engineering“ umfasst dabei die Planung, Realisierung, und Inbetriebnahme der Anlage sowie spätere Ingenieurstätigkeiten während des Betriebs wie die Überprüfung, Optimierung, Erweiterung und Modernisierung.

Derartige Anlagen sind im Gegensatz zu technischen Produkten aber immer Unikate, die einzeln beauftragt werden und dann im Rahmen eines Projekts geplant und realisiert werden. Das bedingt, dass der Aufwand für die Planung und Realisierung monetär nicht auf eine Mehrzahl von Produkten verteilt werden kann, sondern durch den Erlös für die Erstellung bzw. durch den Betrieb der jeweiligen einzelnen Anlage getragen werden muss. Der Engineering-Aufwand ist im Bezug auf die Gesamterstellungskosten der Anlage erheblich. So wird in einer Studie der Automatisierungsinitiative Deutscher Automobilhersteller (Aida) [AIDA05] aufgezeigt, dass mehr als 50{3728c0ddcf5026c65bc0b4e995c837d09025c3e7fa253cea254631dfe46bf841} der Kosten der Steuerungstechnik in einer Rohbau-Fertigungszelle in der Automobilindustrie auf Engineering-Tätigkeiten (Planung, Program­mierung, Inbetriebnahme) entfallen. Unter dem erheblichen Kostendruck im Anlagenbau sehen sich Engineering-Unternehmen inzwischen gezwungen, Engineering-Leistungen von Automatisierungs-Ingenieuren außerhalb Deutschlands erbringen zu lassen, welche hinsichtlich ihres Ausbildungsstands den Ingenieuren in Deutschland zunehmend ebenbürtig sind, bei weiterhin deutlich niedrigeren Stundensätzen und steigender Produktivität. Diese Verlagerung basiert auf technischen Anforderungen an die Engineering-Umgebungen und die Informationstechnik-Infrastruktur [FSZ01], insbesondere der Sicherstellung der Konsistenz paralleler Bearbeitungsvorgänge; Anforderungen, die in zunehmendem Maße erfüllbar werden. Gesellschaftliches Ziel der deutschen wissenschaftlichen Automatisierungs-Gemeinschaft muss daher sein, Engineering durch Methoden zu unterstützen, welche den Engineering-Aufwand senken, statt ihn zu erhöhen. Andererseits gewährleistet nur ein qualitativ hochwertiges Engineering eine zügige Inbetriebnahme und einen weitestgehend störungsfreien Betrieb der automatisierten Anlage. Daher besteht schon seit längerem großes Interesse daran, Methoden und Werkzeuge zu entwickeln, welche ein effizienteres und damit kostengünstigeres, gleichzeitig aber qualitativ hochwertiges Engineering ermöglichen.

[AIDA05]	N.N.: Automatisierungsinitiative Deutscher Automobilhersteller (Aida): Analyse Investitionskostenstruktur Steuerungstechnik und Robotik am Beispiel Rohbau, 2005. Zitiert nach: A. A. Garcia, R.Drath: AutomationML verbindet Werkzeuge der Fertigungsplanung. Quelle: http://www.automationml.org – Whitepaper_AutomationML_2007-11-20_v05.pdf.
[FSZ01]	A. Fay, B. Schilli, K. Zinser: Voraussetzungen für das In- und Outsourcing von Leittechnik-Engineering-Aufgaben. GMA-Kongress 2001, Baden-Baden, 21.-23.5.2001, VDI-Berichte Band 1608, Düsseldorf, S. 287-294.

3. Vorgehensweisen im Engineering

4. Engineering als Wissenschaftsgebiet – Teil 1

Zahlreiche wissenschaftlich fundierte Methoden, die in der Entwicklung von technischen Produkten zum Einsatz kommen, um die Erfüllung funktionaler und nicht-funktionaler Anforderungen sicherzustellen, können aufgrund des dafür erforderlichen zusätzlichen Arbeitsaufwands und der damit verbundenen Kosten in dieser Form im Engineering von Anlagen nicht eingesetzt werden. Es bleibt eine große und lohnende Herausforderung für die Wissenschaft, Ansätze zu entwickeln, welche das Engineering von Anlagen unter Berücksichtigung dieser Randbedingung unterstützen.

Mit dieser Zielrichtung hat Prof. Dr.–Ing. Dr. h.c. Eckehard Schnieder bereits 1991 die Fachtagung „Effizientes Engineering komplexer Automatisierungssysteme“ durchgeführt, die den Auftakt der später als „EKA“ bekannten Reihe von Tagungen unter seiner Leitung bildete. Im Vorwort des Tagungsbands dieser Tagung [Schn91a] weist Schnieder auf darauf hin, dass im Rahmen des Engineerings die drei Hilfsmittel Beschreibungsmittel, Methoden und Werkzeuge erforderlich sind und geeignet kombiniert werden müssen, um ihre Wirkung zu entfalten. Diesen Dreiklang hat Schnieder später auch griffig als „BMW-Prinzip“ propagiert [Schn99].

Ohne Anspruch auf Vollständigkeit sollen im folgenden Beschreibungsmittel und Methoden kurz behandelt werden, die in den letzten Jahren im Engineering Bedeutung erfahren haben.

4.1         Beschreibungsmittel

4.1.1        Übersicht

Es existiert eine Vielzahl von Beschreibungsmitteln, welche erlauben, für die Automatisierungs­technik relevante Systemaspekte qualitativ oder quantitativ zu beschreiben. Kein Beschreibungs­mittel kann alle Aspekte eines Systems allein beschreiben. Die VDI/VDE-Richtlinie 3681 [VDI/VDE3681] gibt eine Übersicht über relevante Systemaspekte und die Möglichkeiten, diese mit verschiedenen Beschreibungsmitteln abzubilden. In dieser Übersicht fällt auf, dass Petri-Netze besonders viele Systemaspekte abbilden können. Dies liegt einerseits an der universellen Einfachheit des Konzepts der Petri-Netze und andererseits an den vielfältigen Möglichkeiten, die Ausdrucksmächtigkeit von Petri-Netzen durch geeignete Erweiterungen zu erhöhen. In [Schn99] sowie in zahlreichen Grundlagenarbeiten und Anwendungsaufsätzen zeigt Schnieder auf, wie Petri-Netze über den gesamten Entwicklungsprozess eines technischen Systems (und damit auch für viele Phasen des Engineerings einer Anlage) vorteilhaft eingesetzt werden können.

4.1.2        Prozessbeschreibung

Im Zentrum einer technischen Anlage steht immer ein Prozess, in dem Materie und/oder Energie umgeformt, transportiert und/oder gespeichert wird. Dieser Prozess wird mit technischen Mitteln bewerkstelligt, d.h. die physikalischen Größen werden mit technischen Mitteln erfasst und beeinflusst [DIN19226]. Alle beim Engineering beteiligten Gewerke haben primär die Aufgabe, diesen Prozess zu ermöglichen bzw. sicherzustellen. Dafür ist ein gewerkeübergreifend einheitliches Verständnis des Prozesses erforderlich. Mit diesem Ziel wurde auf der Basis der grundlegenden Arbeiten von Polke [Pol85] unter maßgeblicher Beteiligung von Schnieder [AFSC00] die „formalisierte Prozessbeschreibung“ konzipiert und in zur VDI/VDE-Richtlinie 3682 [VDI/VDE3682] entwickelt. In der formalisierten Prozessbeschreibung werden die Möglichkeiten der Petri-Netze zur Beschreibung von Abläufen mit einem umfassenden Informationsmodell kombiniert, welches alle relevanten Informationen über die Prozessoperationen und die beteiligten Energien und Stoffe abzubilden vermag [PolSchn02]. In jüngster Zeit wurde eine Methode im Detail entwickelt, wie die formalisierte Prozessbeschreibung vorteilhaft beim Engineering verfahrenstechnischer Anlagen eingesetzt werden kann. Dazu wurde ein Werkzeug konzipiert und prototypisch realisiert, welches erlaubt, formalisierte Prozessbeschreibungen grafisch zu erstellen und rechnerisch auszuwerten [UFFEP08].

4.1.3        Anlagenbeschreibung

Das Pendant zur Prozessbeschreibung, die die Dynamik des technischen Prozesses beschreibt, bildet beim Engineering von Anlagen die Anlagenbeschreibung, welche beschreibt, wie die Anlage hierarchisch aus Teilsystemen zusammengesetzt ist und wie diese Teilsysteme miteinander verbunden sind. Als Meta-Modell, welches definiert, wie solche Anlagenbeschreibungen grundsätzlich aufgebaut sein sollten, hat CAEX [IEC62424] in den letzten Jahren große Aufmerksamkeit erfahren. Für verschiedene Branchen des Anlagenbaus wurde gezeigt, wie CAEX-Modelle unter Verwendung branchenspezifischer Rollen und Bibliothekselemente aufgebaut werden können, so für Anlagen der Prozessindustrie [FEDF02], der Fertigungsindustrie [GütFay08] und für die Gebäudetechnik [RunFay08]. Über den Bezug, den in der formalisierten Prozessbeschreibung die Prozessoperationen zu technischen Ressourcen herstellen, können Prozess- und Anlagen­beschreibung miteinander verbunden werden.

Das Wissen über eine Anlage, d.h. ihre Struktur, ihre Komponenten, deren Eigenschaften und Funktionen, lässt sich auch in einer Ontologie abbilden. Eine Ontologie ist ein formal definiertes (und damit durch den Computer lesbares und verarbeitbares) System von Begriffen und den zwischen ihnen bestehenden Relationen [W308]. In einer Ontologie werden die semantischen

Zusammenhänge zwischen einzelnen Begriffen um Inferenzregeln ergänzt. Damit wird eine Verknüpfung zwischen Aussagen innerhalb der Aussagenlogik möglich. Daraus ergibt sich die Möglichkeit, das auf diese Art beschriebene Wissen für die Methoden der künstlichen Intelligenz, speziell wissensbasierte Methoden, verarbeitbar zu machen [Schn08].

[AAFSC00]	W. Ahrens, M. Felleisen, M. Schnieder, E. Chouikha: Formale Prozessbeschreibungen- gestern, heute und morgen, In: Automatisierungstechnische Praxis – atp 42 (2000), Nr. 9, S. 24-33.
[DIN 19226]	DIN19226. Leittechnik – Regelungstechnik und Steuerungstechnik Allgemeine Grundbegriffe.
[FEDF02]	M. Fedai, U. Epple, R. Drath, A. Fay: Eine neutrale Beschreibungsform für die lebenszyklusbegleitende Spezifikation und Implementierung verfahrens­technischer Anlagen auf der Basis von XML. – In: Tagungsband Engineering in der Prozessindustrie – Anforderungen und Lösungen. VDI-Bericht 1684, VDI-Verlag, Düsseldorf, 2002., S. 133-143.
[GütFay08]	K. Güttel, A. Fay: Beschreibung von fertigungstechnischen Anlagen mittels CAEX. Automatisierungstechnische Praxis, Heft 5/2008, S. 34 – 39.
[Pol85]	M. Polke: Informationshaushalt technischer Prozesse, In: Automatisierungstechnische Praxis – atp 27 (1985), Nr. 4, S. 161-171.
[PolSchn02]	M. Polke, E. Schnieder et al.: Formale Prozessbeschreibungen – Entwurf der Richtlinie VDI/VDE 3682 und deren Anwendung, GMA-Fachtagung „Engineering in der Prozessindustrie“ 2002, VDI-Bericht Nr. 1684, S. 187 – 204. Düsseldorf: VDI Verlag.
[RunFay08]	S. Runde, A. Fay: A Data Exchange Format for the Engineering of Building Automation Systems. In: Tagungsband der 13. Tagung „IEEE International Conference on Emerging Technologies and Factory Automation“ (ETFA), Hamburg, 15.-18. September 2008.
[Schn91a]	E. Schnieder (Hrsg.): Effizientes Engineering komplexer Automatisierungssysteme – Methoden, Anwendungen und Tools auf der Basis von Petri-Netzen. Fachtagung, Braunschweig, 11.-12.4.1991.
[Schn99]	E. Schnieder: Methoden der Automatisierung. Vieweg Verlagsgesellschaft, Braunschweig, 1999.
[Schn08]	E. Schnieder, L. Schnieder: Axiomatik der Begriffe für die Automatisierungstechnik. In: Automatisierungstechnische Praxis, Heft 10/2008, S. 62 – 73.
[UFFEP08]	A. Ulrich, A. Fay, M. Felleisen, U. Enste, B. Polke: VDI/VDE-Richtlinie 3682 Formalisierte Prozessbeschreibung – CAE-Werkzeug und Workflow. In: Tagungsband der 10. Tagung „Entwurf komplexer Automatisierungssysteme“ (EKA), Magdeburg, 16.-17. April 2008. ISBN 978-3-940961-01-3 , Seiten 221-230.
[VDI/VDE 3681]	VDI/VDE 3681:2005-10. Einordnung und Bewertung von Beschreibungsmitteln aus der Automatisierungstechnik.
[VDI/VDE 3682]	VDI/VDE 3682:2005-09. Formalisierte Prozessbeschreibungen.
[W308]	N.N.: OWL Web Ontology Language – Use Cases and Requirements. Quelle: http://www.w3.org/TR/webont-req/#onto-def . 26.02.2008 [letzter Zugriff 30.07.2009].

4.2         Methoden

4.2.1        Objektorientierung

Der Gedanke der Objektorientierung, die Attribute der Elemente eines Systems und die Funktionen dieser Elemente nicht getrennt voneinander, sondern zusammenhängend zu modellieren, wurde in den 90er Jahren auf das Engineering von Anlagen übertragen. Auf der Tagung „EKA 1997“ gab es erstmals eine eigene Sitzung zu diesem Thema. Im Jahr 1999 stellte Vahldieck auf der „EKA 1999“ vor, wie Engineering automatisierter Anlagen auf der Basis des objektorientierten Anlagenmodells von ABB, „Aspect Objects“ genannt, möglich ist [Vah99]. Der objektorientierte Gedanke liegt auch CAEX [IEC62424], der objektorientierten Strukturierung von Simulationsmodellen wie z.B. mit Modelica [Fri03] sowie inzwischen auch zahlreichen anderen Engineering-Werkzeugen zugrunde.

4.2.2        Objektorientierte Analyse und objektorientierter Entwurf von Steuerungssoftware

Objektorientierte Analyse und Design (OOAD) sind objektorientierte Varianten der zwei allgemeinen Phasen Definition und Entwurf im Entwicklungsprozess eines Softwaresystems. Die objektorientierte Vorgehensweise ist die derzeit am weitesten verbreitete Methode in der allgemeinen Softwareentwicklung, so dass zu prüfen ist, inwieweit auch die Entwicklung von automatisierungstechnischer Software, also Steuerungs- und Regelungs-Programmen (Leittechnik-Software), im Rahmen des Engineerings von Anlagen  daraus Nutzen ziehen kann.

Die objektorientierte Analyse und der objektorientierte Entwurf dienen in der allgemeinen Software-Entwicklung dazu, dass ein Software-Spezialist eine ihm zunächst unvertraute Aufgabe eines rechnerbasierten Systems besser versteht, die Anforderungen auflistet, wesentliche Objekte identifiziert und auf diese Weise schrittweise die Software-Aufgabe gliedert und eine Lösung erarbeitet.

Dies entspricht aus mehreren Gründen nicht der Erstellung von automatisierungstechnischer Software im Rahmen des Anlagen-Engineerings:

• Dem Projektierer der Leittechnik-Software sind die Aufgaben, die Leittechnik-Software üblicherweise ausführt ausführen kann, bestens bekannt.
• Die domänenspezifischen Objekte, anhand derer Leittechnik-Software gegliedert werden kann, sind ihm ebenfalls bekannt und müssen nicht erst identifiziert werden: es handelt sich dabei um die Elemente der jeweiligen Anlage, abgebildet im Anlagenmodell in eindeutiger Form in Fließbildern oder technischen Zeichnungen.
• Bei der Zuordnung von SW-Funktionen zu Objekten hat sich die funktionale Strukturierung bewährt, h. die Software zur Steuerung eines Ventils ist dem Ventilantrieb zugeordnet, dieser dem Ventil, und dieses wiederum der Teilanlage, in der das Ventil eine Funktion erfüllt [Vah99].
• Die SW-Funktionen müssen im Allgemeinen nicht neu erarbeitet werden, sondern sind allgemein bekannt („Ventil öffnen“).

Mit anderen Worten: Objektorientierte Analyse und objektorientierter Entwurf sind dann sinnvoll, wenn die Software das strukturbildende Element einer Anwendung ist. Dies gilt insbesondere für Software, die nicht oder nur lose mit einem technischen System gekoppelt ist.

In technischen Anlagen ist die Software zwar heute funktionsgebendes Element, aber nicht, strukturbildend. Wenn also die Software nur ein „Anhängsel“ physikalisch vorhandener Objekte ist, d.h. die Struktur schon durch physikalische Objekte und Zusammenhänge vorgegeben ist (wie in einer verfahrenstechnischen Anlage mit Behältern, Rohren und strömenden Medien oder in einer fertigungstechnischen Anlage mit Maschinen und Materialfluss), dann erscheint eine objektorientierte Analyse überflüssig. Dann steht im Vordergrund, die Software-Funktionen den richtigen Objekten geeignet zuzuordnen und die Software-Funktionen korrekt zu verbinden.

4.2.3        Modellbasiertes Vorgehen

In der Regelungstechnik ist eine modellbasierte Vorgehensweise üblich, bei der zunächst das Verhalten des zu regelnden (Teil-)systems mit Hilfe eines geeigneten Beschreibungsmittels (z.B. Differentialgleichungen) formal beschrieben wird. Die Anforderungen an die Lösung, hier also an die Regelgüte und die Stellgröße, werden ebenfalls formal notiert, so dass auf der Modellebene der Lösungsentwurf durchgeführt und die gefundene Lösung gegen die Anforderungen validiert bzw. rechnerisch verifiziert werden kann.

Für Steuerungsaufgaben in ereignisdiskreten Systemen ist eine ähnliche Vorgehensweise möglich. Es war insbesondere auf den ersten „EKA“-Tagungen das zentrale Anliegen von Schnieder, aufzuzeigen, wie auf der Basis der Petri-Netze als Beschreibungsmittel für ereignisdiskrete Systeme mit Hilfe von Analysemethoden formal abgesicherte Erkenntnisse über die Qualität einer Steuerung gewonnen werden können, zum Beispiel in [Schn91b]. Inzwischen liegen zahlreiche Anwendungsberichte über den erfolgreichen Einsatz eines solchen modellbasierten Vorgehens für den Entwurf von Steuerungen ereignisdiskreter Systeme vor, zum Beispiel bei der Entwicklung von Steuerungen im Kraftfahrzeug, im Flugzeug und in Eisenbahnsicherungseinrichtungen, so dass die modellbasierte Vorgehensweise in diesen Anwendungsgebieten als erfolgreich eingeführt gelten kann.

Dies gilt jedoch nicht für das Engineering von Anlagen. Zwar wurden Ausschnitte von Fertigungs- und Förderanlagen ereignisdiskret modelliert und die dafür entworfenen Steuerungen anhand dieser Modelle verifiziert, oder alternativ die Steuerungen modellbasiert synthetisiert, jedoch immer nur für unrealistisch simplifizierte Beispiele oder kleine Ausschnitte aus dem Gesamtsystem. Trotz der funktionalen Strukturierung der Anlagen sind im Allgemeinen alle Funktionen über Signale zumindest unidirektional miteinander verbunden und müssen korrekterweise im Verbund modelliert werden. Die algorithmische Komplexität der Analyse- und Synthesemethoden verhindert dann deren Anwendung auf das Gesamtsystem. Die derzeitige Forschung zielt insbesondere darauf ab, das Analyse- bzw. Synthese-Problem ähnlich der Anlage zu gliedern und dadurch sequentiell abarbeitbar zu gestalten, um die Komplexität handhabbar zu machen.

Darüber hinaus gibt es weitere Hindernisse für ein modellbasiertes Vorgehen im Engineering:

• Durch die individuelle Modellierung der Anlage, die auch von der Sichtweise desjenigen abhängt, der die Modellierung durchführt, entstehen individuelle Lösungen, die schwierig zu warten und weiterzuentwickeln sind.
• Die zahlreichen bereits existierenden Leittechnik-Software-Lösungen können nicht weiter verwendet werden, da bei der modellbasierten Vorgehensweise der Lösungs-Code generiert wird. Damit geht das in den bestehenden Lösungen implementierte Know-how verloren.
• Für jede Anlage wird erneut ein Modell erstellt und erneut Lösungs-Code generiert, so dass die Zahl der Varianten ständig wächst.
• Nachträgliche Änderungen, die bei der Inbetriebnahme oder im Betrieb erforderlich werden, müssten, damit Modell und Implementierung nicht divergieren, über das Modell realisiert werden, h. das Modell müsste angepasst werden, die Analyse und/oder Synthese müsste erneut durchgeführt werden, und Code müsste erneut generiert werden. Dies ist in Anbetracht der Qualifikation des Personals, welches Inbetriebnahme und Betrieb durchführt, und in Anbetracht der Zeitknappheit bei der Inbetriebnahme nicht realistisch.

Für ein durchgängig auf formaler Modellbildung, Analyse und Synthese aufbauendes Engineering von Anlagen müssen Lösungen gefunden werden, die diese Hindernisse überwinden.

4.2.4        Wiederverwendung

Die wiederholte Erarbeitung einer Lösung für ein bereits zufrieden stellend gelöstes Problem ist eine Tätigkeit, die nach Abschnitt 3 als nicht wertschöpfend bezeichnet werden muss. Daher besteht von Seiten der Verantwortlichen, also der Leiter von Engineering-Projekten, Engineering-Abteilungen oder Engineering-Unternehmen, Interesse an Möglichkeiten, das Engineering effizienter zu gestalten, d.h. bei reduzierten Kosten gleichbleibend qualitativ hochwertige Engineering-Leistungen erbringen zu können, indem Wiederverwendung ermöglicht und unterstützt wird.

Im Bereich des Software Engineering besteht ebenfalls der Wunsch nach Wiederverwendung. Obwohl insbesondere die objektorientierte Softwareentwicklung eine bessere Wiederverwendung versprach, ist diese in der Praxis nicht zu beobachten [Schm99]. Nicht nur technische, sondern vor allem mentale und organisatorische Hürden verhindern eine stärkere Wiederverwendung [JaGriJo97]. Griss unterscheidet [Gri03] vier Möglichkeiten, wie Wiederverwendung in Organisationen gestaltet werden kann:

• „Ad hoc Reuse“, bei dem die Entwickler selbst eigene Lösungen suchen und finden oder Lösungen von Kollegen erfragen;
• „Facilitated Reuse“, bei der die Organisation zur Wiederverwendung ermutigt und diese in begrenztem Maße auch unterstützt;
• „Managed Reuse“, bei dem die Organisation Wiederverwendung durch Richtlinien, Reviews und Metriken erwirkt;
• „Designed Reuse“, bei dem die Organisation in die Erstellung von wieder verwendbaren Lösungen vorab investiert.

Vor diesem Hintergrund hat der GMA-Fachausschuss 6.12 „Durchgängiges Engineering von Leitsystemen“ im Rahmen der Erarbeitung der VDI/VDE-Richtlinie 3695 „Engineering von Anlagen – evaluieren und optimieren“ auch den Aspekt der Wiederverwendung im Engineering von Anlagen untersucht, mit folgenden Ergebnissen [FaySchMü09], [VDI/VDE3695]:

Der Aspekt „Wiederverwendung“ zielt darauf ab, ein Artefakt in möglichst vielen Kundenprojekten einsetzen zu können. Wiederverwendung kann dabei sowohl auf materielle Artefakte, wie z. B. Motoren, Pumpen, Funktionsbausteine, angewandt werden, als auch auf immaterielle Artefakte, wie z. B. Pläne, Architekturen, Spezifikationen. Der Umfang eines Artefaktes kann dabei vom einzelnen Programmbaustein bis zur kompletten Anlage reichen.

Je früher Wiederverwendung im Projekt erfolgt, desto größer sind die Potentiale, die dadurch erschlossen werden können.

Zielzustand A dieses Aspekts bedeutet, dass die Mitarbeiter individuell die Wiederverwendung ihrer selbst erstellten Artefakte betreiben. Dies reduziert den individuell erforderlichen Aufwand, und damit verringert sich durch den Einsatz bereits bewährter Artefakte das Risiko von Fehlfunktionen bzw. der Aufwand für die Erstellung neuer Lösungen. (Dies entspricht „Ad Hoc Reuse“ nach [Gri03].)

Im Zielzustand B wird Wiederverwendung innerhalb eines Projektes koordiniert. Die abgelegten Artefakte können dabei auch von anderen Mitarbeitern genutzt werden. Dabei können allerdings auch Kompatibilitätsprobleme auftreten. Den Mitarbeitern werden Zeit- und Archivierungsmöglichkeiten bereitgestellt. Ihnen muss die Angst genommen werden, dass ihnen durch die Preisgabe ihres Wissens Nachteile entstehen. Während der Planungsphasen der Anlage werden die Artefakte so spezifiziert, dass sie möglichst oft im Projekt wiederverwendet werden können. Dies bedingt eine gewisse Durchgängigkeit der Werkzeugkette sowie eventuelle Kompromisse hinsichtlich der Funktionalität eines Artefakts, um es für mehrere Einsatzzwecke zu nutzen. (Dies entspricht „Facilitated Reuse“ nach [Gri03].)

Im Zielzustand C sollen wieder verwendbare Artefakte gezielt spezifiziert und entwickelt werden, so dass diese in mehreren Projekten eingesetzt werden können. Die Spezifikation und Entwicklung dieser Artefakte erfolgt von zentraler Stelle aus und bedingt das Vorhandensein eines projektunabhängigen Vorgehensmodells. Diese Spezifikation und Entwicklung sollte sowohl Marktanforderungen als auch Projekterfahrungen berücksichtigen, indem zum Beispiel projektspezifische Artefakte so aufbereitet werden, dass sie projektübergreifend eingesetzt werden können. Alle wiederverwendbaren Artefakte werden in einer zentralen Bibliothek abgelegt, dokumentiert und gepflegt, von wo aus sie von den Mitarbeitern in Kundenprojekten verwendet werden. Ein Mitarbeiterteam wird außerdem freigestellt, auf Basis von Marktanforderungen und Projekterfahrungen wieder verwendbare Artefakte zu spezifizieren und zu erstellen. Zusätzlich werden alle Mitarbeiter durch ideelle oder monetäre Anreize animiert, aktiv Feedback über die Nutzbarkeit dieser Artefakte zu geben. Ein Anreiz kann die Prämierung von Verbesserungsvorschlägen sein. (Dies entspricht „Designed Reuse“ nach [Gri03].)

Hierauf aufbauend werden für die Umsetzung des Zielzustands D Referenzmodelle spezifiziert. Ein Referenzmodell ist eine formale Beschreibung von Wissen, wie zum Beispiel Geschäftsprozessen, Informationsstrukturen, Schnittstellen etc., und schafft damit eine gemeinsame Kommunikationsbasis. Es ist folglich Ausgangsbasis für Standardisierung und systematische Wiederverwendung eines kompletten Engineering-Angebots über mehrere Kundenprojekte hinweg. Der Einsatz eines Referenzmodells ist für solche Engineering-Organisationen sinnvoll, die wiederkehrend dieselben Strukturen einer Lösung anbieten. Somit verringert sich deutlich der Aufwand für projektbedingte Neuentwicklungen bzw. die Kombination von Artefakten und damit die Fehlerwahrscheinlichkeit der Anlage. Abzuwägen bleibt allerdings der Aufwand, der mit der Erstellung verbunden ist, und die Wirtschaftlichkeit, da solche Modelle über eine gewisse Anzahl von Projekten erfolgreich eingesetzt werden sollten.

Im Zielzustand E wird die Spezifikation wieder verwendbarer Artefakte auf Basis interner oder externer Standards durchgeführt. Innerhalb der Engineering-Organisation gibt es firmeninterne Standards wie z. B. Programmierrichtlinien oder Schnittstellendefinitionen, die bei der Spezifikation von wieder verwendbaren Artefakten berücksichtigt werden. Die erstellten Artefakte werden bzgl. der Nutzung relevanter Normen kontinuierlich analysiert und entsprechend aktualisiert. Dies ermöglicht ein Maximum an Interoperabilität und erleichtert nachhaltig die Durchgängigkeit von Daten in der eingesetzten Werkzeugkette. Für die Umsetzung führen Mitarbeiterteams, die über das entsprechende Standardisierungs- und Normenwissen verfügen, regelmäßig Analysen durch, welche Standards und Normen bei der Spezifikation der Artefakte einfließen. Für diese Tätigkeiten werden Mittel und Budget verknüpft mit klar definierten Erfolgskriterien zur Verfügung gestellt.

Die Erstellung wieder verwendbarer Artefakte auf der Basis einer Analyse des Marktes und des Anwendungsgebiets, wie sie in den Zielzuständen C, D und E durchgeführt wird, wird auch als „Domain Engineering“ bezeichnet. Das „Domain Engineering“ für die Automatisierungstechnik ist noch ein junges, viel versprechendes Forschungsgebiet [Maga08].

Die Modularisierung von Automatisierungslösungen entsprechend technologischer Teilfunktionen ist die Basis für eine Wiederverwendung von Teillösungen in verschiedenen Automatisierungsprojekten. Die Herausforderungen liegen hierbei im Wesentlichen darin, geeignete Modulgrenzen zu finden, so dass die steuerungstechnischen Module auch den von der Prozesstechnik vorgegebenen Modulen entsprechen und gemeinsam mit diesen ausgetauscht oder wiederverwendet werden können, sowie in der Motivation der Projekteure, erfolgreiche eigene Lösungen so zu modularisieren und zu beschreiben, dass eine erfolgreiche Wiederverwendung durch andere möglich ist.

Die Wiederverwendbarkeit von Artefakten ermöglicht damit letztendlich eine Optimierung des Engineering-Prozesses hinsichtlich Kosten, Zeitaufwand, Qualität der Lösung, sowie Wartungsaufwand.

4.2.5        Regelbasierte Ansätze

Zur Reduktion repetitiver und damit nicht-wertschöpfender Engineering-Tätigkeiten wird zunehmend die „Automatisierung der Automatisierung“ in Betracht gezogen, korrekter: die Automatisierung von Engineering-Aufgaben der Automatisierungstechnik. Dies kann insbesondere auf der Basis wissensbasierter, z.B. regelbasierter, Systeme erfolgen, welche das Wissen über typische, vergleichsweise einfache und häufige Engineering-Aufgaben enthalten. Neben der Wissensbasis ist als zweite Voraussetzung ein durch Rechner auswertbares Modell der zu automatisierenden Anlage erforderlich und als dritte Voraussetzung eine ebenfalls rechnergestützt auswertbare Spezifikation der Automatisierungsaufgabe. Die zweite und dritte Voraussetzung können in Kombination erfüllt werden durch ein Anlagenmodell mit funktionaler Struktur und Beschreibung, welches z.B. in Form von CAEX [IEC62424] vorliegt und aus einem Engineering-Werkzeug über eine neutrale Schnittstelle generiert wurde. Diese Schnittstellen müssen nicht nur syntaktisch, sondern auch semantisch eindeutig definiert sein, um die Konsistenz der Information zu gewährleisten. Semantische Konsistenz bedeutet jedoch, einheitliche Begriffe zu finden und zu vereinbaren [Schn08], ein mühsamer und zeitaufwändiger Prozess.

Sind diese Voraussetzungen gegeben, so kann auf diesem Weg z.B. automatisch Steuerungscode zur Lösung der Automatisierungsaufgabe erzeugt werden, siehe [Schm08], [RSFPW09], oder ein Simulationsmodell zum Test von Steuerungscode erstellt werden, siehe [BSFWG09]. Auch wenn diese Konzepte noch am Anfang ihrer Entwicklung stehen, so offenbart sich hier Potential, Engineering-Aufwände signifikant zu reduzieren.

[BSFWG09]	M. Barth, M. Strube, A. Fay, P.Weber, J. Greifeneder: Object-oriented engineering data exchange as a base for automatic generation of simulation models. Angenommen zur Veröffentlichung in: Tagungsband der „IEEE IECON 2009“ – 35th Annual Conference of the IEEE Industrial Electronics Society, Porto, Portugal, 03.-05. November 2009.
[Fri03]	Peter Fritzson: Principles of Object-Oriented Modeling and Simulation with Modelica 2.1. Wiley-IEEE Press, 2003.
[Gri03]	M. Griss: Reuse Comes in Several Flavors. SDPC White paper, Flashline Inc., May 2003. Quelle: http://martin.griss.com/pubs/WPGRISS02.pdf [letzter Zugriff 28.07.2009].
[IEC62424]	IEC 62424 Ed. 1.0 Representation of process control engineering – Requests in P&I diagrams and data exchange between P&ID tools and PCE-CAE tools. Publication date 2008-08-12.
[JaGriJo97]	I. Jacobson, M. Griss, P. Jonsson: Software Reuse. Addison Wesley, 1997.
[Maga08]	C. Maga: Domain-Engineering erschließt ungenutzte Wiederverwendungspotenziale. ESE-Kongress, Sindelfingen, 2008.
[RSFPW09]	S. Runde, A. Scholz, A. Fay, J. Pollmeier, C. Wolff: Unterstützungssoftware für das Automationsstations-Engineering in der Gebäudeautomation. In: Automatisierungstechnische Praxis, Heft 6/2009, S. 42 – 49.
[Schm08]	T. Schmidberger: Wissensbasierte Auswertung von Anlagenplanungsdaten für die Unterstützung des Prozessleittechnikingenieurs – Anwendung einer rollenbasierten Mustersuche. Dissertation HSU/UniBW Hamburg. VDI-Fortschritt-Bericht Band 415. VDI-Verlag. Düsseldorf, 2008.
[Schn08]	E. Schnieder, L. Schnieder: Axiomatik der Begriffe für die Automatisierungstechnik. In: Automatisierungstechnische Praxis, Heft 10/2008, S. 62 – 73.
[Schn91b]	E. Schnieder: Methodischer Entwurf von Automatisierungssystemen mit Petri-Netzen. In: [Schn91a], S. 27 – 42.
[Vah99]	R. Vahldieck : Engineering großer Leitsysteme. 6. Fachtagung Entwicklung und Betrieb komplexer Automatisierungssysteme (EKA), Braunschweig, 26. bis 28. Mai 1999.
[VDI/VDE 3695]	VDI/VDE 3695:2009-05. Engineering von Anlagen – Evaluieren und optimieren. Gründruck. Blatt 1 bis 4.

5. Handlungsbedarf

Da die Engineering-Kosten nicht eindeutig dem Hersteller oder Betreiber zuzuordnen sind, sondern im Wesentlichen beim Anlagenbauer bzw. Systemintegrator, häufig in einem Netzwerk von Projektbeteiligten anfallen, fehlen die „schwergewichtigen Treiber“, um größere gemeinschaftliche Anstrengungen, z.B. in Form großer, öffentlich geförderter F&E-Projekte, zu initiieren. In Anbetracht der Bedeutung des Engineerings von Automatisierungssystemen für Wissenschaft, Wirtschaft und Gesellschaft sind hier größere Anstrengungen nötig.