{"id":164,"date":"2017-09-19T13:06:23","date_gmt":"2017-09-19T11:06:23","guid":{"rendered":"https:\/\/www.hsu-hh.de\/aut\/?page_id=164"},"modified":"2026-03-02T09:05:37","modified_gmt":"2026-03-02T08:05:37","slug":"forschungsthemen","status":"publish","type":"page","link":"https:\/\/www.hsu-hh.de\/aut\/forschung\/forschungsthemen","title":{"rendered":"Forschungsthemen"},"content":{"rendered":"\n

Ver\u00f6ffentlichungen<\/a> | Kooperationen<\/a> | Labore<\/a><\/p>\n\n\n\n

An der Professur werden verschiedene Forschungsprojekte zu den im \u00dcberblick genannten Forschungsgebieten bearbeitet. F\u00fcr n\u00e4here Informationen wenden Sie sich gerne an Herrn Dr.<\/abbr>–Ing.<\/abbr> Felix Gehlhoff<\/a> (operative Leitung der Professur).<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n
<\/div>\n\n\n\n

Aktuelle Forschungsthemen<\/h1>\n\n\n\n

<\/a>TrustME: Zertifizierbare KI-Anwendungen in Luftfahrt-Produktionssystemen<\/a>
bearbeitet durch: M.Sc.<\/abbr> Lasse Beers, M.Sc.<\/abbr> Lisa Gebauer, M.Sc.<\/abbr> Niklas Jobs, M.Sc.<\/abbr> Iman Talai<\/p>\n\n\n\n

Integrierte Plattform f\u00fcr Peer-to-Peer Energiehandel und marktbasiertes Netzengpassmanagement durch Sektorenkopplung (InterPhaSe)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Nane Zimmermann, Dr.<\/abbr>–Ing.<\/abbr> Lukas Wagner<\/p>\n\n\n\n

EKI \u2013 Engineering f\u00fcr die KI-basierte Automation in virtuellen und realen Produktionsumgebungen<\/a>
bearbeitet durch: M.Eng. Marvin Schieseck, M.Sc.<\/abbr> Philip Topalis<\/p>\n\n\n\n

Optimale Nutzung energetischer Flexibilit\u00e4t von Systemverb\u00fcnden in der Produktion auf Basis intelligenter Agenten (OptiFlex)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Lasse Matthias Reinpold, Dr.<\/abbr>–Ing.<\/abbr> Lukas Peter Wagner<\/p>\n\n\n\n

Computergesteuerte Bauteilaufarbeitung (COmputer-based REfurbishment, CORE)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Maximilian Mosig<\/p>\n\n\n\n

Labor f\u00fcr intelligente Leichtbauproduktion (LaiLa)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Raphael H\u00f6fer, M.Sc.<\/abbr> Tom Jeleniewski, M.Sc.<\/abbr> Pezhman Pourabdollah, M.Sc.<\/abbr> Jonathan Reif<\/p>\n\n\n\n

Intelligente modulare Robotik und integrierte Produktionsgestaltung im Flugzeugbau (iMOD)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Lasse Beers, M.Sc.<\/abbr> Hamied Nabizada, M.Sc.<\/abbr> Omar Ismail<\/p>\n\n\n\n

Produktionsnahe Modellwerkstatt zur Forschung an Digitalisierungsthemen im Bereich der Flugzeuginstandhaltung (ProMoDi)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Tom Westermann, M.Sc.<\/abbr> Manjinder Singh<\/p>\n\n\n\n

Critical Components for Distributed and Secure Grid Operation (DISEGO)<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Lukas Wagner, M.Sc.<\/abbr> Nane Zimmermann<\/p>\n\n\n\n

Rechtskonforme IT<\/abbr>-Konzepte und -L\u00f6sungen f\u00fcr Verb\u00fcnde autonomer Land-, Wasser- und Luftfahrzeuge (RIVA)<\/a>
bearbeitet durch: Dipl.<\/abbr>-Wi.-Ing.<\/abbr> Marvin Zager, M.Sc.<\/abbr> Miguel Vieira da Silva<\/p>\n\n\n\n

<\/div>\n\n\n\n

Weitere Forschungsthemen und abgeschlossene Projekte<\/h1>\n\n\n\n

Modellierung, Automatisierung, Integration und Optimierung von modular aufgebauten Elektrolyse-Anlagen (eModule)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Vincent Henkel, M.Sc.<\/abbr> Joshua Galys<\/p>\n\n\n\n

Entwicklung eines Frameworks zur f\u00e4higkeits- und skillbasierten Produktion auf Basis semantischer Modelle<\/a>
bearbeitet durch: M.Sc.<\/abbr> Aljosha K\u00f6cher, M.Sc.<\/abbr> Luis Miguel Vieira da Silva, M.Sc.<\/abbr> Tom Jeleniewski, M.Sc.<\/abbr> Lasse Beers<\/p>\n\n\n\n

Innovative luftgest\u00fctzte urbane Mobilit\u00e4t (i-LUM)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Tobias Grebner, M.Sc.<\/abbr> Luca von R\u00f6nn<\/p>\n\n\n\n

Automatisierung modularer Anlagen in der Prozessindustrie<\/a>
bearbeitet durch: M.Sc.<\/abbr> Artan Markaj<\/p>\n\n\n\n

VDI-Young Automation Challenge (VDI-YAC)
<\/a>bearbeitet durch: M.Sc.<\/abbr> Hamied Nabizada, M.Sc.<\/abbr> Jonathan Reif, M.Sc.<\/abbr> Lasse Matthias Reinpold, M.Eng. Marvin Schieseck, M.Sc.<\/abbr> Christoph Sieber<\/p>\n\n\n\n

Assistenzsystem aus Verbindung von Engineering-Dokumenten und Anlagenlivedaten zur Szenario- und Flusswegeanalyse (AVEDAS)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Malte Ramonat<\/p>\n\n\n\n

L\u00f6sungen und Handlungsempfehlungen f\u00fcr die nationale Umsetzung der U-Space-Verordnung – LUV<\/a>
bearbeitet durch: M.Sc.<\/abbr> Tobias Grebner, M.Sc.<\/abbr> Luca von R\u00f6nn<\/p>\n\n\n\n

Modulare Produktionslogistik (MoProLog)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Michelle Blumenstein<\/p>\n\n\n\n

Analyse von GRAFCET-Spezifikationen zur Erkennung von Entwurfsfehlern (AGRAFE)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Aron Schnakenbeck<\/p>\n\n\n\n

Automatisierte Datenverkn\u00fcpfung von der Auslegung bis zur Produktion (ADAPT)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Maximilian Weigand<\/p>\n\n\n\n

Smart & Stustainable RTM 4.0 (SAUBER 4.0)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Tom Jeleniewski, M.Sc.<\/abbr> Jonathan Reif<\/p>\n\n\n\n

Entwicklung von Energiemanagementschnittstellen f\u00fcr IoT-Technologien (IoT_EnRG)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Leif-Thore Reiche<\/p>\n\n\n\n

Integrierte Plattform f\u00fcr Peer-to-Peer Energiehandel und Aktive Netzf\u00fchrung (PEAK)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Alexandra Karmann, M.Sc.<\/abbr> Jan-Philip Beck und M.Sc.<\/abbr> Maximilian Kilthau.<\/p>\n\n\n\n

Daten- und prozessbasierte Zustandsermittlung f\u00fcr eine wertorientierte Komponentenbewirtschaftung in imperfekter Umgebung (DaProKo)<\/a>
bearbeitet durch: MBA B. Eng. Maximilian Rappl, M.Sc.<\/abbr> David Winkler<\/p>\n\n\n\n

TIME4CPS – Ein Software-Framework zur Analyse des zeitlichen Verhaltens von Produktions- und Logistikprozessen<\/a>
bearbeitet durch: M.Sc.<\/abbr> Tom Westermann und M.Sc.<\/abbr> Maximilian Peters<\/p>\n\n\n\n

Urbaner Drohnen-Verkehr effizient organisiert (UDVeo)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Sebastian T\u00f6rsleff, M.Sc.<\/abbr> Evelyn Fischer, M.Sc.<\/abbr> Tobias Grebner und M.Sc.<\/abbr> Felix St\u00fcckrath<\/p>\n\n\n\n

Agentenbasierte Steuerung der Produktionslogistik (Agent.Pro)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Felix Gehlhoff<\/p>\n\n\n\n

Modellexperimente in der operativen Energiesystemanalyse (MEO)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Jan-Philip Beck<\/p>\n\n\n\n

Automatisierung des L\u00f6schvorgangs bei einem Normbrandversuch<\/a>
bearbeitet durch: M.Sc.<\/abbr> Fabian Stoller<\/p>\n\n\n\n

Mittelstand 4.0-Kompetenzzentrum Hamburg (M40HH<\/abbr>)<\/a>
bearbeitet durch: M.Sc.<\/abbr> Timo Busert, M.Sc.<\/abbr> Feras El Sakka, M.Sc.<\/abbr> Alexander Hayward<\/p>\n\n\n\n

xMODERN \u2013 Cross Platform MOdel Driven Engineering avataRs Network<\/a>
bearbeitet durch: M.Sc.<\/abbr> Claas Steffen Gundlach, M.Sc.<\/abbr> Leif-Thore Reiche<\/p>\n\n\n\n

Digitales Typenschild<\/a>
bearbeitet durch: M.Sc.<\/abbr>, MBA Alaettin Dogan, M.Sc.<\/abbr> Yuanheng Zhang<\/p>\n\n\n\n

AeroCut 4.0: Digitaler (Prozess-) Zwilling als Grundlage der Prozessoptimierung in der Fr\u00e4sbearbeitung<\/a>
bearbeitet durch: M.Sc.<\/abbr> Christian Corinth, M.Sc.<\/abbr> Birte Caesar<\/p>\n\n\n\n

R\u00e4umliche auf Bildverarbeitung basierende Echtzeit-Deflagrations-Detektion<\/a>
bearbeitet durch: M.Sc.<\/abbr> Jakob Kroo\u00df<\/p>\n\n\n\n

Forever Young Production Automation with Active Components – FYPA\u00b2C (DFG-Projekt)<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Jan Ladiges, M.Sc.<\/abbr> Abhishek Chakraborty, M.Sc.<\/abbr> Felix Gehlhoff<\/p>\n\n\n\n

Engineering-Unterst\u00fctzung durch Simulation \/ Virtuelle Inbetriebnahme<\/a>
bearbeitet durch: Suthida Thongnuch, M.Sc, Dr.<\/abbr>–Ing.<\/abbr> Philipp Puntel Schmidt, M.Sc.<\/abbr> Artan Markaj<\/p>\n\n\n\n

Effiziente Herstellverfahren und Technologien f\u00fcr 1-Tank-Abwassersysteme (HUTAB)
bearbeitet durch: M.Sc.<\/abbr> Jakob Kroo\u00df, M. Sc. Gian Mewes<\/p>\n\n\n\n

Formale Methoden zur Spezifikation und Implementierung von Steuerungen<\/a>
bearbeitet durch: Robert Julius, M.Eng., M.Sc.<\/abbr> Sophia Cordes<\/p>\n\n\n\n

Agentensystem zur dezentralen Steuerung der Energieverteilung<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Tobias Linnenberg, Dipl.<\/abbr>–Ing.<\/abbr> Erik Wassermann, M.Sc.<\/abbr> Sebastian T\u00f6rsleff<\/p>\n\n\n\n

Ontology Engineering for Collaborative Embedded Systems<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Constantin Hildebrandt, M.Sc.<\/abbr> Sebastian T\u00f6rsleff<\/p>\n\n\n\n

Flexibilisierung von Maschinen (DFG-Projekt FlexA)<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Xuan-Luu Hoang<\/p>\n\n\n\n

CrESt: Modellbasierte Entwicklung kollaborativer eingebetteter Systeme<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Constantin Hildebrandt, M.Sc.<\/abbr> Birte Caesar, M.Sc.<\/abbr> Alexander Hayward, M.Sc.<\/abbr> Sebastian T\u00f6rsleff<\/p>\n\n\n\n

Einordnung der Beispiele der Industrie-4.0-Landkarte in die Anwendungsszenarien (EiBILA)<\/a>
bearbeitet durch M.Sc.<\/abbr> Timo Busert, M.Sc.<\/abbr> Marcus Lewin<\/p>\n\n\n\n

Semantische Allianz f\u00fcr Industrie 4.0 (SemAnz40)<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Andr\u00e9 Scholz und Dr.<\/abbr>–Ing.<\/abbr> Constantin Hildebrandt<\/p>\n\n\n\n

Automatisierung komplexer Arbeitsprozesse der Bauteilbearbeitung mit Hilfe von Industrierobotern<\/a>
bearbeitet durch: Dipl.<\/abbr>–Ing.<\/abbr> Tobias Ernst, Alaettin Dogan, M.Sc.<\/abbr><\/p>\n\n\n\n

IT<\/abbr>-Sicherheit von automatisierten Anlagen<\/a>
bearbeitet durch:Dipl.<\/abbr>–Ing.<\/abbr> Matthias Glawe, Dr.<\/abbr>–Ing.<\/abbr> Andr\u00e9 Scholz, Dr.<\/abbr>–Ing.<\/abbr> Thomas Holm<\/p>\n\n\n\n

Interdisziplin\u00e4re Wiederverwendung im Engineering automatisierter Anlagen<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Sebastian Schr\u00f6ck<\/p>\n\n\n\n

Geb\u00e4udeautomatisierung: Requirements Engineering und Engineering-Unterst\u00fctzung<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Andr\u00e9 Scholz<\/p>\n\n\n\n

Automatische Auswertung von PDF-Engineering-Dokumenten<\/a>
bearbeitet durch: Herrn Dr.<\/abbr>–Ing.<\/abbr> Xuan-Luu Hoang und Herrn Dr.<\/abbr>–Ing.<\/abbr> Esteban Arroyo<\/p>\n\n\n\n

Unterst\u00fctzung des Auswahlprozesses von Sensoren durch Nutzung von Methoden der k\u00fcnstlichen Intelligenz<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Maik Riedel<\/p>\n\n\n\n

Werkzeug und Methode zur Formalisierten Prozessbeschreibung entsprechend VDI-Richtlinie 3682<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Andr\u00e9 Scholz und Dr.<\/abbr>–Ing.<\/abbr> Sebastian Schr\u00f6ck<\/p>\n\n\n\n

Modellierung von Zusammenh\u00e4ngen mittels Struktur- und Prozessbeschreibungen automatisierungstechnischer Systeme<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Andr\u00e9 Scholz<\/p>\n\n\n\n

Funktionale Anlagenbeschreibung<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Andr\u00e9 Scholz<\/p>\n\n\n\n

Stabilit\u00e4tsanalyse dezentral-autonomer Entscheidungssysteme<\/a>
bearbeitet durch: Dipl.<\/abbr>–Ing.<\/abbr> Ireneus Wior<\/p>\n\n\n\n

Nutzen von Information f\u00fcr dezentrale Steuerungen<\/a>
bearbeitet durch: Dipl.<\/abbr>–Ing.<\/abbr> Stefan Jerenz<\/p>\n\n\n\n

Funktionaler Anwendungsentwurf f\u00fcr verteilte Automatisierungssysteme – FAVA (DFG-Projekt)<\/a>
bearbeitet durch Dr.<\/abbr>–Ing.<\/abbr>. Karin Eckert<\/p>\n\n\n\n

Verl\u00e4sslichkeits-Anforderungen in Anlagenbeschreibung und Prozessbeschreibung<\/a>
bearbeitet durch Dr.<\/abbr>–Ing.<\/abbr> Lars Christiansen<\/p>\n\n\n\n

Entwicklung von Mitteln zur Qualit\u00e4tssicherung f\u00fcr den Ersatz analoger Rechentechnik durch rechnerbasierte Leittechnik in Kernkraftwerken<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Markus G\u00f6ring<\/p>\n\n\n\n

Offenheitsmetrik f\u00fcr Engineering-Werkzeuge<\/a><\/p>\n\n\n\n

Anwendung von Entwurfsmustern auf die Automatisierungstechnik<\/a>
bearbeitet durch Dr.<\/abbr>–Ing.<\/abbr> Carsten Mahler<\/p>\n\n\n\n

Modellassoziation und Abh\u00e4ngigkeitsmanagement im industriellen L\u00f6sungsgesch\u00e4ft<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Tobias J\u00e4ger<\/p>\n\n\n\n

Bewertung des Nutzen von dezentralen Steuerungskonzepten<\/a>
bearbeitet durch: Dr.<\/abbr>–Ing.<\/abbr> Sebastian Schreiber<\/p>\n\n\n\n

Bus-ID: RFID-basierte akustische Unterst\u00fctzung blinder und sehbehinderte Menschen f\u00fcr Orientierung und Information beim Zugang zum \u00d6PNV und an Ampeln<\/a>
bearbeitet durch: Martin Hennig, M.Sc.<\/abbr>, Dipl.<\/abbr>-Psych. Cornelia Vogel, Dipl.<\/abbr>-Phys. Helmut Weber<\/p>\n\n\n\n

Durchg\u00e4ngiges Beschreibungsmodell f\u00fcr den Feldger\u00e4te-Lebenszyklus.<\/a>
bearbeitet durch Dr.<\/abbr>–Ing.<\/abbr> Yaoying Lin<\/p>\n\n\n\n

Analyse und Re-Implementierung von SPS-Programmen mit Hilfe von Automaten<\/a>
bearbeitet von: Dr.<\/abbr>–Ing.<\/abbr> Mohammed Bani Younis<\/p>\n\n\n\n

Wissensbasierte Dispositionsunterst\u00fctzung im Schienenverkehr<\/a>
bearbeitet durch Prof.<\/abbr> Dr.<\/abbr>–Ing.<\/abbr> Alexander Fay<\/p>\n\n\n\n

Robotergest\u00fctzte minimalinvasive Endoprothetik (ROMEO).<\/a><\/p>\n\n\n\n

<\/div>\n\n\n\n

Themen\u00fcberblick – Informationsmodelle von Anlagen<\/h1>\n\n\n\n

Informationsmodelle sind die tragende S\u00e4ule im Engineering von automatisierten Anlagen. An der Professur f\u00fcr Automatisierungstechnik an der Helmut-Schmidt-Universit\u00e4t Hamburg wird seit 15 Jahren an Methoden, Beschreibungsmitteln und Werkzeugen f\u00fcr die Erstellung und Nutzung solcher Informationsmodelle geforscht. In dieser Abhandlung werden diese Arbeiten mit dem Anlagen-Lebenszyklus in Bezug gesetzt.<\/p>\n\n\n\n

Informationsmodelle im Lebenszyklus automatisierter Anlagen<\/a><\/p>\n\n\n\n

<\/div>\n\n\n\n

Themen\u00fcberblick – Effizientes Engineering komplexer Automatisierungssysteme<\/h1>\n\n\n

1. Engineering: eine erste Ann\u00e4herung<\/h2>\n

Auch wenn inzwischen 15 Jahre \u201eBologna-Prozess\u201c die europ\u00e4ische Bildungslandschaft ver\u00e4ndert haben und der Abschluss Diplom-Ingenieur nun nicht mehr vergeben wird, besteht \u00fcber das Berufsbild des Ingenieurs weiterhin gro\u00dfer Konsens: es ist gekennzeichnet durch \u201edie systematische Aneignung, Beherrschung und Anwendung von wissenschaftlich-theoretisch fundierten und empirisch gesicherten technischen Erkenntnissen und Methoden\u201c \u2013 so formuliert von der Gliederung \u201eBeruf und Gesellschaft\u201c des Vereins Deutscher Ingenieure (VDI) und einer breiten \u00d6ffentlichkeit zug\u00e4nglich \u00fcber [Wiki09].<\/p>\n

Sucht man hingegen nach einer zusammenfassenden Bezeichnung f\u00fcr das Schaffen des Ingenieurs, so wird man in der deutschen Sprache nicht f\u00fcndig: \u201eentwerfen\u201c, \u201eentwickeln\u201c, \u201eerfinden\u201c: all diese T\u00e4tigkeiten beschreiben es nicht richtig oder nicht vollst\u00e4ndig (siehe unten). In den USA wurde hingegen schon fr\u00fch der Begriff des \u201eEngineering\u201c gepr\u00e4gt: das \u201eEngineers‘ Council for Professional Development\u201c, vergleichbar mit dem VDI definierte bereits 1941 Engineering als \u201e[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.\u201c [ECPD41]. An dieser Definition ist dreierlei bemerkenswert:<\/p>\n

    \n
  1. Die kompromisslose Bezugnahme auf wissenschaftliche Methoden zu einem Zeitpunkt, zu dem zum Beispiel die Automatisierungstechnik als Wissenschaftsgebiet noch gar nicht etabliert war.<\/li>\n
  2. Die umfassende \u2013 heute w\u00fcrde man sagen \u201elebenszyklus-\u00fcbergreifende\u201c \u2013 Sicht auf Entwurf und Realisierung, aber auch Betrieb und Diagnose.<\/li>\n
  3. Die Orientierung an funktionaler Zielerreichung und am gesellschaftlichen Nutzen hinsichtlich Wirtschaftlichkeit und Sicherheit.<\/li>\n<\/ol>\n

    Mangels einer entsprechenden, gleicherma\u00dfen umfassenden Bezeichnung in der deutschen Sprache hat sich \u201eEngineering\u201c sukzessive auch im deutschen Sprachraum durchgesetzt. So bezeichnet sich der VDI selbst als \u201eengineering association\u201c [VDI09].<\/p>\n\n\n\n\n\n
    [ECPD41]<\/td>\nScience, Volume 94, Issue 2446, 11\/1941, p. 456.<\/td>\n<\/tr>\n
    [VDI09]<\/td>\nN.N.: VDI – The Association of German Engineers. Quelle: http:\/\/www.vdi.de\/index.php?id=2657&L=1 <\/a> .<\/td>\n<\/tr>\n
    [Wiki09]<\/td>\nN.N.: Ingenieur. Quelle: http:\/\/de.wikipedia.org\/wiki\/Ingenieur <\/a> .<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    2. Engineering als Charakteristikum des Projektgesch\u00e4fts<\/h2>\n

    Der Begriff \u201eEngineering\u201c wird im deutschen Sprachraum insbesondere dort eingesetzt, wo der Begriff \u201eEntwicklung\u201c nicht zutreffend oder nicht ausreichend ist. Die T\u00e4tigkeiten der Konzeption, des Grobentwurfs, des Detailentwurfs, der (zun\u00e4chst prototypischen) Realisierung und des Tests eines technischen Produkts, z.B.<\/abbr> eines Kraftfahrzeugs oder einer Kamera, welches danach in Serie produziert wird, lassen sich unter \u201eEntwicklung\u201c subsumieren. Anders stellt sich die Situation im Entstehungsprozess von Anlagen dar, z.B.<\/abbr> bei Produktionsanlagen der fertigungs- oder verfahrenstechnischen Industrie, bei Kraftwerken, Ver- und Entsorgungsanlagen oder Transporteinrichtungen wie Flugh\u00e4fen. Derartige Anlagen sind im Allgemeinen sehr komplex, d.h.<\/abbr> sie enthalten Wirkbeziehungen zwischen Tausenden von Sensoren und Aktoren, und m\u00fcssen daher sorgf\u00e4ltig und systematisch, mit anderen Worten ingenieurwissenschaftlich, geplant und realisiert werden. Das \u201eEngineering\u201c umfasst dabei die Planung, Realisierung, und Inbetriebnahme der Anlage sowie sp\u00e4tere Ingenieurst\u00e4tigkeiten w\u00e4hrend des Betriebs wie die \u00dcberpr\u00fcfung, Optimierung, Erweiterung und Modernisierung.<\/p>\n

    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\u00fcr die Planung und Realisierung monet\u00e4r nicht auf eine Mehrzahl von Produkten verteilt werden kann, sondern durch den Erl\u00f6s f\u00fcr die Erstellung bzw.<\/abbr> 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\u00e4tigkeiten (Planung, Program\u00admierung, Inbetriebnahme) entfallen. Unter dem erheblichen Kostendruck im Anlagenbau sehen sich Engineering-Unternehmen inzwischen gezwungen, Engineering-Leistungen von Automatisierungs-Ingenieuren au\u00dferhalb Deutschlands erbringen zu lassen, welche hinsichtlich ihres Ausbildungsstands den Ingenieuren in Deutschland zunehmend ebenb\u00fcrtig sind, bei weiterhin deutlich niedrigeren Stundens\u00e4tzen und steigender Produktivit\u00e4t. Diese Verlagerung basiert auf technischen Anforderungen an die Engineering-Umgebungen und die Informationstechnik-Infrastruktur [FSZ01], insbesondere der Sicherstellung der Konsistenz paralleler Bearbeitungsvorg\u00e4nge; Anforderungen, die in zunehmendem Ma\u00dfe erf\u00fcllbar werden. Gesellschaftliches Ziel der deutschen wissenschaftlichen Automatisierungs-Gemeinschaft muss daher sein, Engineering durch Methoden zu unterst\u00fctzen, welche den Engineering-Aufwand senken, statt ihn zu erh\u00f6hen. Andererseits gew\u00e4hrleistet nur ein qualitativ hochwertiges Engineering eine z\u00fcgige Inbetriebnahme und einen weitestgehend st\u00f6rungsfreien Betrieb der automatisierten Anlage. Daher besteht schon seit l\u00e4ngerem gro\u00dfes Interesse daran, Methoden und Werkzeuge zu entwickeln, welche ein effizienteres und damit kosteng\u00fcnstigeres, gleichzeitig aber qualitativ hochwertiges Engineering erm\u00f6glichen.<\/p>\n\n\n\n\n
    [AIDA05]<\/td>\nN.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 <\/a> – Whitepaper_AutomationML_2007-11-20_v05.pdf.<\/td>\n<\/tr>\n
    [FSZ01]<\/td>\nA. Fay, B. Schilli, K. Zinser: Voraussetzungen f\u00fcr das In- und Outsourcing von Leittechnik-Engineering-Aufgaben. GMA-Kongress 2001, Baden-Baden, 21.-23.5.2001, VDI-Berichte Band 1608, D\u00fcsseldorf, S. 287-294.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    3. Vorgehensweisen im Engineering<\/h2>\n
    \n

    Um die Komplexit\u00e4t von Anlagen beherrschen zu k\u00f6nnen und einen zeitlich und finanziell kalkulierbares Engineering im Anlagenbauprojekt sicherstellen zu k\u00f6nnen, haben sich in der Praxis bestimmte Vorgehensweisen entwickelt, die sich wie folgt charakterisieren lassen:<\/p>\n

      \n
    1. Die Anlage wird in einem top-down-Vorgehen vom Grobentwurf sukzessive bis ins Detail geplant, bevor sie realisiert wird.<\/li>\n
    2. Die Ergebnisse der jeweiligen Planungsphasen werden dokumentiert; diese Dokumentation bildet die Basis f\u00fcr die Entscheidung, ob das Projekt fortgesetzt wird.<\/li>\n
    3. F\u00fchrendes \u201eGewerk\u201c, d.h.<\/abbr> f\u00fchrender Fachbereich im Projekt, ist das Gewerk, welches den zu realisierenden technischen Prozess entwirft und dimensioniert, also<\/li>\n
    4. \n
        \n
      1. die Mechanik bei Fertigungsanlagen (St\u00fcckprozessen),<\/li>\n
      2. die Verfahrenstechnik bei verfahrenstechnischen Anlagen (Batch- oder Konti-Prozessen),<\/li>\n
      3. die Materialflussplanung bei Transportprozessen.<\/li>\n<\/ol>\n<\/li>\n
      4. Alle anderen Gewerke \u2013 dazu z\u00e4hlen Ger\u00e4teherstellung, Verbindungstechnik, Elektrotechnik und Automatisierungstechnik \u2013 sind dem f\u00fchrenden Gewerk nachgeordnet. Sie verwenden die Planungsunterlagen des f\u00fchrenden Gewerks als Grundlage, um auf der Basis die gewerkespezifischen Planungen durchzuf\u00fchren. Sie arbeiten sequentiell, wo sie inhaltlich auf den Ergebnissen anderer Gewerke aufbauen, und ansonsten parallel, um die Projektdauer zu minimieren.<\/li>\n<\/ol>\n

        Dies wird zum Beispiel f\u00fcr die Prozessleittechnik (PLT) im NAMUR-Arbeitsblatt 35 \u201eAbwicklung von PLT-Projekten\u201c [NA35] idealtypisch in Form eines Ablaufs sequentieller und teilweise paralleler, dabei aber unabh\u00e4ngiger Einzelaktivit\u00e4ten beschrieben, ohne R\u00fcckspr\u00fcnge oder Iterationen.<\/p>\n

        Aus der Notwendigkeit, die Projektlaufzeiten zu reduzieren, ergibt sich jedoch die Anforderung an die Ingenieure, mit ihren jeweiligen Engineering-Aufgaben bereits zu beginnen, wenn noch nicht alle erforderlichen Informationen in endg\u00fcltiger Form vorliegen. Die Ingenieure sind darauf angewiesen, mit vorl\u00e4ufigen und l\u00fcckenhaften Informationen zu arbeiten und ihre eigenen Arbeiten bei Eintreffen erg\u00e4nzender oder korrigierender Information iterativ zu \u00fcberarbeiten [KABL02]. Dazu muss die vorliegende Information zun\u00e4chst auf Vollst\u00e4ndigkeit und Konsistenz gepr\u00fcft werden, und fehlende oder nicht stimmige Informationen m\u00fcssen \u2013 oft mehrfach \u2013 eingefordert und integriert werden [Fay05a]. Diese iterative \u00dcberarbeitung macht einen signifikanten Anteil der Engineering-Arbeitszeit aus, der von manchen Fachleuten auf bis zu 30{3728c0ddcf5026c65bc0b4e995c837d09025c3e7fa253cea254631dfe46bf841} der gesamten Engineering-Arbeitszeit gesch\u00e4tzt wird [Fay05b].<\/p>\n

        Was unterscheidet nun das Engineering einer Anlage von einer Erfindung oder einer Entwicklung eines neuartigen Produkts? Engineering ist ein Prozess, in dem schrittweise in interdisziplin\u00e4rer Zusammenarbeit eine L\u00f6sung f\u00fcr eine individuelle, aber nicht ungew\u00f6hnliche Aufgabe gefunden wird. Eine Anlage zur Herstellung von Ammoniak nach dem Haber-Bosch-Verfahren mag sich zum Beispiel durch Kapazit\u00e4t, Grundriss, chemische Zusammensetzung der Rohstoffe, geforderte Qualit\u00e4t des Produkts etc.<\/abbr> von einer vorhergehenden unterscheiden. Trotzdem k\u00f6nnen zahlreiche L\u00f6sungselemente aus der vorhergehenden Anlage f\u00fcr die neue Anlage \u00fcbernommen werden. In der Praxis gibt es zahlreiche Varianten der Wiederverwendung [AAF03].<\/p>\n

        Eine h\u00e4ufige Form der Wiederverwendung ist die Kopie der vorhandenen Implementierung mit nachfolgender Anpassung an die Anforderungen der neuen Anlage. Dies entspricht der Kopie von Software<\/span>-Quellcode mit anschlie\u00dfender Modifikation. Diese Form der Wiederverwendung erscheint zun\u00e4chst einfach, birgt aber verschiedene Nachteile:<\/p>\n

        –\u00a0\u00a0\u00a0\u00a0 Nicht vollst\u00e4ndig verstandene Vorlagen werden nicht korrekt angepasst.<\/p>\n

        –\u00a0\u00a0\u00a0\u00a0 Es ist un\u00fcbersichtlich, wie ge\u00e4nderten Anforderungen mit den Anpassungen Rechnung getragen wird.<\/p>\n

        –\u00a0\u00a0\u00a0\u00a0 Die Zahl der Varianten steigt mit jedem Projekt.<\/p>\n

        –\u00a0\u00a0\u00a0\u00a0 Fehler in der Vorlage werden dupliziert.<\/p>\n

        –\u00a0\u00a0\u00a0\u00a0 Nachtr\u00e4gliche Verbesserungen m\u00fcssen in allen Projekten von Hand individuell nachgepflegt werden.<\/p>\n<\/div>\n

        \n

        Um gezielt einzelne Elemente entsprechend ge\u00e4nderten funktionalen Anforderungen anpassen zu k\u00f6nnen, wird in Anlagenprojekten eine funktionale Strukturierung vorgenommen. Teilweise spiegelt diese sich in einem geeigneten Kennzeichnungssystem wider, welches aber oft noch von r\u00e4umlichen Aspekten (\u201eOrtsstruktur\u201c) \u00fcberlagert wird. Um den projektbezogenen Aufwand zu reduzieren, wird versucht, die Funktionalit\u00e4t der Gesamtanlage aufzuteilen in kleine, handhabbare Einzelfunktionen und f\u00fcr m\u00f6glichst viele von diesen L\u00f6sungen zu finden, die in sp\u00e4teren Projekten wieder verwendet werden k\u00f6nnen. F\u00fcr die Automatisierungstechnik bedeutete dies, die Regelungs- und Steuerungsfunktionen in Funktionen zu gliedern, die nur wenige Eingangs- und Ausgangsgr\u00f6\u00dfen miteinander verkn\u00fcpfen und diese Funktionen dann, unabh\u00e4ngig von der sp\u00e4teren Implementierung, zu charakterisieren und in gewissem Ma\u00dfe zu standardisieren. Durchgesetzt hat sich die Kennzeichnung und Charakterisierung der automatisierungstechnischen Funktionen im Rohrleitungs- und Instrumentierungs-Flie\u00dfbild [DIN EN ISO 10628]. Hingegen konnte sich aufgrund der Differenzierungsw\u00fcnsche der Hersteller nicht die Vereinheitlichung der leittechnischen Steuerungs- und Regelungs-Algorithmen nach [VDI\/VDE 3696] durchsetzen.<\/p>\n

        Auf der Basis funktional strukturierter Anlagenkonzepte ist eine weitergehende Wieder\u00adverwendung m\u00f6glich, siehe Abschnitt 4.2.4.<\/p>\n

        F\u00fcr die Erforschung und Entwicklung neuer Engineering-Methoden durch Hochschulen und Industrie muss im Vordergrund stehen, die Effizienz des Engineerings und damit die Produktivit\u00e4t der Ingenieure zu erh\u00f6hen. Dies kann geschehen durch [Fay05c]<\/p>\n

          \n
        1. Eliminierung nicht wertsch\u00f6pfender T\u00e4tigkeiten (manuelle Suche nach Informationen, Konsistenz\u00fcberpr\u00fcfung von Informationen, manuelle Eingabe in Werkzeug von bereits in anderen Werkzeugen vorhandener Information, manuelle Durchf\u00fchrung sich wiederholender Basisaufgaben, \u00c4nderungen aufgrund unvollst\u00e4ndiger oder missverst\u00e4ndlicher Spezifikation etc.<\/abbr>) und<\/li>\n
        2. Unterst\u00fctzung wertsch\u00f6pfender T\u00e4tigkeiten (durch geeignete rechnergest\u00fctzte Bereit\u00adstellung und Aufbereitung aller daf\u00fcr erforderlichen Informationen, durch Methoden und Werkzeuge f\u00fcr Simulation, Test, Validierung etc.<\/abbr>).<\/li>\n<\/ol>\n

          F\u00fcr die Software<\/span>-Werkzeuge des Computer-Aided Engineering (CAE) kann letzteres konkret zum Beispiel bedeuten, den kreativen, sch\u00f6pferischen Akt, f\u00fcr ein gegebenes Regelungs- oder Steuerungsproblem die geeignete Automatisierungsstruktur und geeignete Ger\u00e4te auszuw\u00e4hlen, durch Vorschlagssysteme und intelligente Produktkataloge zu unterst\u00fctzen. In Bezug auf I. wird von den CAE-Werkzeugen gefordert, den Leerlauf und die Mehrarbeit, die durch fehlende Kenntnis der prozesstechnischen Vorgaben begr\u00fcndet sind, durch entsprechende Werkzeug-Schnittstellen und Workflow-Unterst\u00fctzung zu reduzieren. Denn dabei geht nicht nur Zeit verloren, sondern es sinkt auch (durch die Nutzung veralteter oder fehlerhafter Information) die Qualit\u00e4t des Gesamt-Engineering-Ergebnisses. Die gr\u00f6\u00dferen Herausforderungen f\u00fcr die Engineering-Werkzeuge liegen insofern nicht so sehr in der spezifischen Funktionalit\u00e4t f\u00fcr das Engineering bestimmter Einzelaufgaben, sondern an den Schnittstellen zwischen den Gewerken und den Werkzeugen.<\/p>\n\n\n\n\n\n\n\n\n\n\n
          [AAF03]<\/td>\nR. Alznauer, K. Auer, A. Fay: Wiederverwendung von Automatisierungs-Informationen und -L\u00f6sungen. Automatisierungstechnische Praxis, Heft 3\/2003, S. 31-35.<\/td>\n<\/tr>\n
          [DIN EN ISO 10628]<\/td>\nDIN EN ISO<\/abbr> 10628:2001-03. Flie\u00dfschemata f\u00fcr verfahrenstechnische Anlagen – Allgemeine Regeln.<\/td>\n<\/tr>\n
          [Fay05a]<\/td>\nA. Fay: Engineering in vernetzten, offenen, durchg\u00e4ngigen Systemen. Automatisierungstechnik, Heft 4-5\/2005, S. 205-210.<\/td>\n<\/tr>\n
          [Fay05b]<\/td>\nA. Fay: Wie unterst\u00fctzen CAE-Werkzeuge Integration und zugrunde liegende Arbeitsabl\u00e4ufe? Vortrag und Diskussion der gemeinsamen Arbeiten des GMA-Fachausschusses 6.12 und des NAMUR-Arbeitskreises 1.3 auf der NAMUR-Hauptsitzung 2005, Lahnstein, 10. November 2005 (auf CD).<\/td>\n<\/tr>\n
          [Fay05c]<\/td>\nA. Fay, M. Schleipen, Mathias M\u00fchlhause: Wie kann man den Engineering-Prozess systematisch verbessern? – In: Automatisierungstechnische Praxis, Heft 1-2\/2009, S. 80-85.<\/td>\n<\/tr>\n
          [KABL02]<\/td>\nR.A. Klein, F. Anh\u00e4user, M. Burmeister, J. Lamers: Planungswerkzeuge aus Sicht eines Inhouse-Planers. \u2013 In: atp-Automatisierungstechnische Praxis 44 (2002) Nr. 1, S. 46-50.<\/td>\n<\/tr>\n
          [NA35]<\/td>\nNAMUR-Arbeitsblatt NA 35 \u201eAbwicklung von PLT-Projekten\u201c, Erstausgabe 01.02.1993.<\/td>\n<\/tr>\n
          [VDI\/VDE 3696]<\/td>\nVDI\/VDE 3696:1995-10. Herstellerneutrale Konfigurierung von Prozessleitsystemen. Blatt 1 bis 3.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

          4. Engineering als Wissenschaftsgebiet – Teil 1<\/h2>\n

          Zahlreiche wissenschaftlich fundierte Methoden, die in der Entwicklung von technischen Produkten zum Einsatz kommen, um die Erf\u00fcllung funktionaler und nicht-funktionaler Anforderungen sicherzustellen, k\u00f6nnen aufgrund des daf\u00fcr erforderlichen zus\u00e4tzlichen Arbeitsaufwands und der damit verbundenen Kosten in dieser Form im Engineering von Anlagen nicht eingesetzt werden. Es bleibt eine gro\u00dfe und lohnende Herausforderung f\u00fcr die Wissenschaft, Ans\u00e4tze zu entwickeln, welche das Engineering von Anlagen unter Ber\u00fccksichtigung dieser Randbedingung unterst\u00fctzen.<\/p>\n

          Mit dieser Zielrichtung hat Prof.<\/abbr> Dr.<\/abbr>–Ing.<\/abbr> Dr.<\/abbr> h.c. Eckehard Schnieder<\/em> bereits 1991 die Fachtagung \u201eEffizientes Engineering komplexer Automatisierungssysteme\u201c durchgef\u00fchrt, die den Auftakt der sp\u00e4ter als \u201eEKA\u201c bekannten Reihe von Tagungen unter seiner Leitung bildete. Im Vorwort des Tagungsbands dieser Tagung [Schn91a] weist Schnieder<\/em> auf darauf hin, dass im Rahmen des Engineerings die drei Hilfsmittel Beschreibungsmittel<\/em>, Methoden<\/em> und Werkzeuge<\/em> erforderlich sind und geeignet kombiniert werden m\u00fcssen, um ihre Wirkung zu entfalten. Diesen Dreiklang hat Schnieder<\/em> sp\u00e4ter auch griffig als \u201eBMW-Prinzip\u201c propagiert [Schn99].<\/p>\n

          Ohne Anspruch auf Vollst\u00e4ndigkeit sollen im folgenden Beschreibungsmittel und Methoden kurz behandelt werden, die in den letzten Jahren im Engineering Bedeutung erfahren haben.<\/p>\n

          4.1\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Beschreibungsmittel<\/h3>\n

          4.1.1\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/em> \u00dcbersicht<\/em><\/strong><\/p>\n

          Es existiert eine Vielzahl von Beschreibungsmitteln, welche erlauben, f\u00fcr die Automatisierungs\u00adtechnik relevante Systemaspekte qualitativ oder quantitativ zu beschreiben. Kein Beschreibungs\u00admittel kann alle Aspekte eines Systems allein beschreiben. Die VDI\/VDE-Richtlinie 3681 [VDI\/VDE3681] gibt eine \u00dcbersicht \u00fcber relevante Systemaspekte und die M\u00f6glichkeiten, diese mit verschiedenen Beschreibungsmitteln abzubilden. In dieser \u00dcbersicht f\u00e4llt auf, dass Petri-Netze besonders viele Systemaspekte abbilden k\u00f6nnen. Dies liegt einerseits an der universellen Einfachheit des Konzepts der Petri-Netze und andererseits an den vielf\u00e4ltigen M\u00f6glichkeiten, die Ausdrucksm\u00e4chtigkeit von Petri-Netzen durch geeignete Erweiterungen zu erh\u00f6hen. In [Schn99] sowie in zahlreichen Grundlagenarbeiten und Anwendungsaufs\u00e4tzen zeigt Schnieder<\/em> auf, wie Petri-Netze \u00fcber den gesamten Entwicklungsprozess eines technischen Systems (und damit auch f\u00fcr viele Phasen des Engineerings einer Anlage) vorteilhaft eingesetzt werden k\u00f6nnen.<\/p>\n

          4.1.2\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/em> Prozessbeschreibung<\/em><\/strong><\/p>\n

          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.<\/abbr> die physikalischen Gr\u00f6\u00dfen werden mit technischen Mitteln erfasst und beeinflusst [DIN19226]. Alle beim Engineering beteiligten Gewerke haben prim\u00e4r die Aufgabe, diesen Prozess zu erm\u00f6glichen bzw.<\/abbr> sicherzustellen. Daf\u00fcr ist ein gewerke\u00fcbergreifend einheitliches Verst\u00e4ndnis des Prozesses erforderlich. Mit diesem Ziel wurde auf der Basis der grundlegenden Arbeiten von Polke<\/em> [Pol85] unter ma\u00dfgeblicher Beteiligung von Schnieder<\/em> [AFSC00] die \u201eformalisierte Prozessbeschreibung\u201c konzipiert und in zur VDI\/VDE-Richtlinie 3682 [VDI\/VDE3682] entwickelt. In der formalisierten Prozessbeschreibung werden die M\u00f6glichkeiten der Petri-Netze zur Beschreibung von Abl\u00e4ufen mit einem umfassenden Informationsmodell kombiniert, welches alle relevanten Informationen \u00fcber die Prozessoperationen und die beteiligten Energien und Stoffe abzubilden vermag [PolSchn02]. In j\u00fcngster 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].<\/p>\n

          4.1.3\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/em> Anlagenbeschreibung<\/em><\/strong><\/p>\n

          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\u00e4tzlich aufgebaut sein sollten, hat CAEX [IEC62424] in den letzten Jahren gro\u00dfe Aufmerksamkeit erfahren. F\u00fcr verschiedene Branchen des Anlagenbaus wurde gezeigt, wie CAEX-Modelle unter Verwendung branchenspezifischer Rollen und Bibliothekselemente aufgebaut werden k\u00f6nnen, so f\u00fcr Anlagen der Prozessindustrie [FEDF02], der Fertigungsindustrie [G\u00fctFay08] und f\u00fcr die Geb\u00e4udetechnik [RunFay08]. \u00dcber den Bezug, den in der formalisierten Prozessbeschreibung die Prozessoperationen zu technischen Ressourcen herstellen, k\u00f6nnen Prozess- und Anlagen\u00adbeschreibung miteinander verbunden werden.<\/p>\n

          Das Wissen \u00fcber eine Anlage, d.h.<\/abbr> ihre Struktur, ihre Komponenten, deren Eigenschaften und Funktionen, l\u00e4sst 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<\/p>\n

          Zusammenh\u00e4nge zwischen einzelnen Begriffen um Inferenzregeln erg\u00e4nzt. Damit wird eine Verkn\u00fcpfung zwischen Aussagen innerhalb der Aussagenlogik m\u00f6glich. Daraus ergibt sich die M\u00f6glichkeit, das auf diese Art beschriebene Wissen f\u00fcr die Methoden der k\u00fcnstlichen Intelligenz, speziell wissensbasierte Methoden, verarbeitbar zu machen [Schn08].<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
          [AAFSC00]<\/td>\nW. Ahrens, M. Felleisen, M. Schnieder, E. Chouikha: Formale Prozessbeschreibungen- gestern, heute und morgen, In: Automatisierungstechnische Praxis \u2013 atp 42 (2000), Nr. 9, S. 24-33.<\/td>\n<\/tr>\n
          [DIN 19226]<\/td>\nDIN19226. Leittechnik – Regelungstechnik und Steuerungstechnik Allgemeine Grundbegriffe.<\/td>\n<\/tr>\n
          [FEDF02]<\/td>\nM. Fedai, U. Epple, R. Drath, A. Fay: Eine neutrale Beschreibungsform f\u00fcr die lebenszyklusbegleitende Spezifikation und Implementierung verfahrens\u00adtechnischer Anlagen auf der Basis von XML. \u2013 In: Tagungsband Engineering in der Prozessindustrie \u2013 Anforderungen und L\u00f6sungen. VDI-Bericht 1684, VDI-Verlag, D\u00fcsseldorf, 2002., S. 133-143.<\/td>\n<\/tr>\n
          [G\u00fctFay08]<\/td>\nK. G\u00fcttel, A. Fay: Beschreibung von fertigungstechnischen Anlagen mittels CAEX. Automatisierungstechnische Praxis, Heft 5\/2008, S. 34 – 39.<\/td>\n<\/tr>\n
          [Pol85]<\/td>\nM. Polke: Informationshaushalt technischer Prozesse, In: Automatisierungstechnische Praxis \u2013 atp 27 (1985), Nr. 4, S. 161-171.<\/td>\n<\/tr>\n
          [PolSchn02]<\/td>\nM. Polke, E. Schnieder et al.: Formale Prozessbeschreibungen \u2013 Entwurf der Richtlinie VDI\/VDE 3682 und deren Anwendung, GMA-Fachtagung „Engineering in der Prozessindustrie“ 2002, VDI-Bericht Nr. 1684, S. 187 \u2013 204. D\u00fcsseldorf: VDI Verlag.<\/td>\n<\/tr>\n
          [RunFay08]<\/td>\nS. 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.<\/td>\n<\/tr>\n
          [Schn91a]<\/td>\nE. Schnieder (Hrsg.<\/abbr>): Effizientes Engineering komplexer Automatisierungssysteme \u2013 Methoden, Anwendungen und Tools auf der Basis von Petri-Netzen. Fachtagung, Braunschweig, 11.-12.4.1991.<\/td>\n<\/tr>\n
          [Schn99]<\/td>\nE. Schnieder: Methoden der Automatisierung. Vieweg Verlagsgesellschaft, Braunschweig, 1999.<\/td>\n<\/tr>\n
          [Schn08]<\/td>\nE. Schnieder, L. Schnieder: Axiomatik der Begriffe f\u00fcr die Automatisierungstechnik. In: Automatisierungstechnische Praxis, Heft 10\/2008, S. 62 \u2013 73.<\/td>\n<\/tr>\n
          [UFFEP08]<\/td>\nA. 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<\/abbr> 978-3-940961-01-3 <\/a> <\/a> <\/a> <\/a> , Seiten 221-230.<\/td>\n<\/tr>\n
          [VDI\/VDE 3681]<\/td>\nVDI\/VDE 3681:2005-10. Einordnung und Bewertung von Beschreibungsmitteln aus der Automatisierungstechnik.<\/td>\n<\/tr>\n
          [VDI\/VDE 3682]<\/td>\nVDI\/VDE 3682:2005-09. Formalisierte Prozessbeschreibungen.<\/td>\n<\/tr>\n
          [W308]<\/td>\nN.N.: OWL Web Ontology Language \u2013 Use Cases and Requirements. Quelle: http:\/\/www.w3.org\/TR\/webont-req\/#onto-def <\/a> . 26.02.2008 [letzter Zugriff 30.07.2009].<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          4.2\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Methoden<\/h3>\n

          4.2.1\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/em> Objektorientierung<\/em><\/strong><\/p>\n

          Der Gedanke der Objektorientierung, die Attribute der Elemente eines Systems und die Funktionen dieser Elemente nicht getrennt voneinander, sondern zusammenh\u00e4ngend zu modellieren, wurde in den 90er Jahren auf das Engineering von Anlagen \u00fcbertragen. Auf der Tagung \u201eEKA 1997\u201c gab es erstmals eine eigene Sitzung zu diesem Thema. Im Jahr 1999 stellte Vahldieck<\/em> auf der \u201eEKA 1999\u201c vor, wie Engineering automatisierter Anlagen auf der Basis des objektorientierten Anlagenmodells von ABB, \u201eAspect Objects\u201c genannt, m\u00f6glich ist [Vah99]. Der objektorientierte Gedanke liegt auch CAEX [IEC62424], der objektorientierten Strukturierung von Simulationsmodellen wie z.B.<\/abbr> mit Modelica [Fri03] sowie inzwischen auch zahlreichen anderen Engineering-Werkzeugen zugrunde.<\/p>\n

          4.2.2\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/em> Objektorientierte Analyse und objektorientierter Entwurf von Steuerungssoftware<\/em><\/strong><\/p>\n

          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\u00fcfen ist, inwieweit auch die Entwicklung von automatisierungstechnischer Software, also Steuerungs- und Regelungs-Programmen (Leittechnik-Software), im Rahmen des Engineerings von Anlagen \u00a0daraus Nutzen ziehen kann.<\/p>\n

          Die objektorientierte Analyse und der objektorientierte Entwurf dienen in der allgemeinen Software-Entwicklung dazu, dass ein Software-Spezialist eine ihm zun\u00e4chst 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\u00f6sung erarbeitet.<\/p>\n

          Dies entspricht aus mehreren Gr\u00fcnden nicht der Erstellung von automatisierungstechnischer Software im Rahmen des Anlagen-Engineerings:<\/p>\n

            \n
          • Dem Projektierer der Leittechnik-Software sind die Aufgaben, die Leittechnik-Software \u00fcblicherweise ausf\u00fchrt ausf\u00fchren kann, bestens bekannt.<\/li>\n
          • Die dom\u00e4nenspezifischen Objekte, anhand derer Leittechnik-Software gegliedert werden kann, sind ihm ebenfalls bekannt und m\u00fcssen nicht erst identifiziert werden: es handelt sich dabei um die Elemente der jeweiligen Anlage, abgebildet im Anlagenmodell in eindeutiger Form in Flie\u00dfbildern oder technischen Zeichnungen.<\/li>\n
          • Bei der Zuordnung von SW-Funktionen zu Objekten hat sich die funktionale Strukturierung bew\u00e4hrt, 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\u00fcllt [Vah99].<\/li>\n
          • Die SW-Funktionen m\u00fcssen im Allgemeinen nicht neu erarbeitet werden, sondern sind allgemein bekannt (\u201eVentil \u00f6ffnen\u201c).<\/li>\n<\/ul>\n

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

            In technischen Anlagen ist die Software zwar heute funktionsgebendes Element, aber nicht, strukturbildend. Wenn also die Software nur ein „Anh\u00e4ngsel“ physikalisch vorhandener Objekte ist, d.h.<\/abbr> die Struktur schon durch physikalische Objekte und Zusammenh\u00e4nge vorgegeben ist (wie in einer verfahrenstechnischen Anlage mit Beh\u00e4ltern, Rohren und str\u00f6menden Medien oder in einer fertigungstechnischen Anlage mit Maschinen und Materialfluss), dann erscheint eine objektorientierte Analyse \u00fcberfl\u00fcssig. Dann steht im Vordergrund, die Software-Funktionen den richtigen Objekten geeignet zuzuordnen und die Software-Funktionen korrekt zu verbinden.<\/p>\n

            4.2.3\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/em> Modellbasiertes Vorgehen<\/em><\/strong><\/p>\n

            In der Regelungstechnik ist eine modellbasierte Vorgehensweise \u00fcblich, bei der zun\u00e4chst das Verhalten des zu regelnden (Teil-)systems mit Hilfe eines geeigneten Beschreibungsmittels (z.B.<\/abbr> Differentialgleichungen) formal beschrieben wird. Die Anforderungen an die L\u00f6sung, hier also an die Regelg\u00fcte und die Stellgr\u00f6\u00dfe, werden ebenfalls formal notiert, so dass auf der Modellebene der L\u00f6sungsentwurf durchgef\u00fchrt und die gefundene L\u00f6sung gegen die Anforderungen validiert bzw.<\/abbr> rechnerisch verifiziert werden kann.<\/p>\n

            F\u00fcr Steuerungsaufgaben in ereignisdiskreten Systemen ist eine \u00e4hnliche Vorgehensweise m\u00f6glich. Es war insbesondere auf den ersten \u201eEKA\u201c-Tagungen das zentrale Anliegen von Schnieder<\/em>, aufzuzeigen, wie auf der Basis der Petri-Netze als Beschreibungsmittel f\u00fcr ereignisdiskrete Systeme mit Hilfe von Analysemethoden formal abgesicherte Erkenntnisse \u00fcber die Qualit\u00e4t einer Steuerung gewonnen werden k\u00f6nnen, zum Beispiel in [Schn91b]. Inzwischen liegen zahlreiche Anwendungsberichte \u00fcber den erfolgreichen Einsatz eines solchen modellbasierten Vorgehens f\u00fcr 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\u00fchrt gelten kann.<\/p>\n

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

            Dar\u00fcber hinaus gibt es weitere Hindernisse f\u00fcr ein modellbasiertes Vorgehen im Engineering:<\/p>\n

              \n
            • Durch die individuelle Modellierung der Anlage, die auch von der Sichtweise desjenigen abh\u00e4ngt, der die Modellierung durchf\u00fchrt, entstehen individuelle L\u00f6sungen, die schwierig zu warten und weiterzuentwickeln sind.<\/li>\n
            • Die zahlreichen bereits existierenden Leittechnik-Software-L\u00f6sungen k\u00f6nnen nicht weiter verwendet werden, da bei der modellbasierten Vorgehensweise der L\u00f6sungs-Code generiert wird. Damit geht das in den bestehenden L\u00f6sungen implementierte Know-how verloren.<\/li>\n
            • F\u00fcr jede Anlage wird erneut ein Modell erstellt und erneut L\u00f6sungs-Code generiert, so dass die Zahl der Varianten st\u00e4ndig w\u00e4chst.<\/li>\n
            • Nachtr\u00e4gliche \u00c4nderungen, die bei der Inbetriebnahme oder im Betrieb erforderlich werden, m\u00fcssten, damit Modell und Implementierung nicht divergieren, \u00fcber das Modell realisiert werden, h. das Modell m\u00fcsste angepasst werden, die Analyse und\/oder Synthese m\u00fcsste erneut durchgef\u00fchrt werden, und Code m\u00fcsste erneut generiert werden. Dies ist in Anbetracht der Qualifikation des Personals, welches Inbetriebnahme und Betrieb durchf\u00fchrt, und in Anbetracht der Zeitknappheit bei der Inbetriebnahme nicht realistisch.<\/li>\n<\/ul>\n

              F\u00fcr ein durchg\u00e4ngig auf formaler Modellbildung, Analyse und Synthese aufbauendes Engineering von Anlagen m\u00fcssen L\u00f6sungen gefunden werden, die diese Hindernisse \u00fcberwinden.<\/p>\n

              4.2.4\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/em> Wiederverwendung<\/em><\/strong><\/p>\n

              Die wiederholte Erarbeitung einer L\u00f6sung f\u00fcr ein bereits zufrieden stellend gel\u00f6stes Problem ist eine T\u00e4tigkeit, die nach Abschnitt 3 als nicht wertsch\u00f6pfend bezeichnet werden muss. Daher besteht von Seiten der Verantwortlichen, also der Leiter von Engineering-Projekten, Engineering-Abteilungen oder Engineering-Unternehmen, Interesse an M\u00f6glichkeiten, das Engineering effizienter zu gestalten, d.h.<\/abbr> bei reduzierten Kosten gleichbleibend qualitativ hochwertige Engineering-Leistungen erbringen zu k\u00f6nnen, indem Wiederverwendung erm\u00f6glicht und unterst\u00fctzt wird.<\/p>\n

              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\u00fcrden verhindern eine st\u00e4rkere Wiederverwendung [JaGriJo97]. Griss unterscheidet [Gri03] vier M\u00f6glichkeiten, wie Wiederverwendung in Organisationen gestaltet werden kann:<\/p>\n

                \n
              • \u201eAd hoc Reuse\u201c, bei dem die Entwickler selbst eigene L\u00f6sungen suchen und finden oder L\u00f6sungen von Kollegen erfragen;<\/li>\n
              • \u201eFacilitated Reuse\u201c, bei der die Organisation zur Wiederverwendung ermutigt und diese in begrenztem Ma\u00dfe auch unterst\u00fctzt;<\/li>\n
              • \u201eManaged Reuse\u201c, bei dem die Organisation Wiederverwendung durch Richtlinien, Reviews und Metriken erwirkt;<\/li>\n
              • \u201eDesigned Reuse\u201c, bei dem die Organisation in die Erstellung von wieder verwendbaren L\u00f6sungen vorab investiert.<\/li>\n<\/ul>\n

                Vor diesem Hintergrund hat der GMA-Fachausschuss 6.12 \u201eDurchg\u00e4ngiges Engineering von Leitsystemen\u201c im Rahmen der Erarbeitung der VDI\/VDE-Richtlinie 3695 \u201eEngineering von Anlagen \u2013 evaluieren und optimieren\u201c auch den Aspekt der Wiederverwendung im Engineering von Anlagen untersucht, mit folgenden Ergebnissen [FaySchM\u00fc09], [VDI\/VDE3695]:<\/p>\n

                Der Aspekt „Wiederverwendung“ zielt darauf ab, ein Artefakt in m\u00f6glichst vielen Kundenprojekten einsetzen zu k\u00f6nnen. Wiederverwendung kann dabei sowohl auf materielle Artefakte, wie z. B. Motoren, Pumpen, Funktionsbausteine, angewandt werden, als auch auf immaterielle Artefakte, wie z. B. Pl\u00e4ne, Architekturen, Spezifikationen. Der Umfang eines Artefaktes kann dabei vom einzelnen Programmbaustein bis zur kompletten Anlage reichen.<\/p>\n

                Je fr\u00fcher Wiederverwendung im Projekt erfolgt, desto gr\u00f6\u00dfer sind die Potentiale, die dadurch erschlossen werden k\u00f6nnen.<\/p>\n

                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\u00e4hrter Artefakte das Risiko von Fehlfunktionen bzw.<\/abbr> der Aufwand f\u00fcr die Erstellung neuer L\u00f6sungen. (Dies entspricht \u201eAd Hoc Reuse\u201c nach [Gri03].)<\/p>\n

                Im Zielzustand B wird Wiederverwendung innerhalb eines Projektes koordiniert. Die abgelegten Artefakte k\u00f6nnen dabei auch von anderen Mitarbeitern genutzt werden. Dabei k\u00f6nnen allerdings auch Kompatibilit\u00e4tsprobleme auftreten. Den Mitarbeitern werden Zeit- und Archivierungsm\u00f6glichkeiten bereitgestellt. Ihnen muss die Angst genommen werden, dass ihnen durch die Preisgabe ihres Wissens Nachteile entstehen. W\u00e4hrend der Planungsphasen der Anlage werden die Artefakte so spezifiziert, dass sie m\u00f6glichst oft im Projekt wiederverwendet werden k\u00f6nnen. Dies bedingt eine gewisse Durchg\u00e4ngigkeit der Werkzeugkette sowie eventuelle Kompromisse hinsichtlich der Funktionalit\u00e4t eines Artefakts, um es f\u00fcr mehrere Einsatzzwecke zu nutzen. (Dies entspricht \u201eFacilitated Reuse\u201c nach [Gri03].)<\/p>\n

                Im Zielzustand C sollen wieder verwendbare Artefakte gezielt spezifiziert und entwickelt werden, so dass diese in mehreren Projekten eingesetzt werden k\u00f6nnen. Die Spezifikation und Entwicklung dieser Artefakte erfolgt von zentraler Stelle aus und bedingt das Vorhandensein eines projektunabh\u00e4ngigen Vorgehensmodells. Diese Spezifikation und Entwicklung sollte sowohl Marktanforderungen als auch Projekterfahrungen ber\u00fccksichtigen, indem zum Beispiel projektspezifische Artefakte so aufbereitet werden, dass sie projekt\u00fcbergreifend eingesetzt werden k\u00f6nnen. 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\u00dferdem freigestellt, auf Basis von Marktanforderungen und Projekterfahrungen wieder verwendbare Artefakte zu spezifizieren und zu erstellen. Zus\u00e4tzlich werden alle Mitarbeiter durch ideelle oder monet\u00e4re Anreize animiert, aktiv Feedback \u00fcber die Nutzbarkeit dieser Artefakte zu geben. Ein Anreiz kann die Pr\u00e4mierung von Verbesserungsvorschl\u00e4gen sein. (Dies entspricht \u201eDesigned Reuse\u201c nach [Gri03].)<\/p>\n

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

                Im Zielzustand E wird die Spezifikation wieder verwendbarer Artefakte auf Basis interner oder externer Standards durchgef\u00fchrt. Innerhalb der Engineering-Organisation gibt es firmeninterne Standards wie z. B. Programmierrichtlinien oder Schnittstellendefinitionen, die bei der Spezifikation von wieder verwendbaren Artefakten ber\u00fccksichtigt werden. Die erstellten Artefakte werden bzgl. der Nutzung relevanter Normen kontinuierlich analysiert und entsprechend aktualisiert. Dies erm\u00f6glicht ein Maximum an Interoperabilit\u00e4t und erleichtert nachhaltig die Durchg\u00e4ngigkeit von Daten in der eingesetzten Werkzeugkette. F\u00fcr die Umsetzung f\u00fchren Mitarbeiterteams, die \u00fcber das entsprechende Standardisierungs- und Normenwissen verf\u00fcgen, regelm\u00e4\u00dfig Analysen durch, welche Standards und Normen bei der Spezifikation der Artefakte einflie\u00dfen. F\u00fcr diese T\u00e4tigkeiten werden Mittel und Budget verkn\u00fcpft mit klar definierten Erfolgskriterien zur Verf\u00fcgung gestellt.<\/p>\n

                Die Erstellung wieder verwendbarer Artefakte auf der Basis einer Analyse des Marktes und des Anwendungsgebiets, wie sie in den Zielzust\u00e4nden C, D und E durchgef\u00fchrt wird, wird auch als \u201eDomain Engineering\u201c bezeichnet. Das \u201eDomain Engineering\u201c f\u00fcr die Automatisierungstechnik ist noch ein junges, viel versprechendes Forschungsgebiet [Maga08].<\/p>\n

                Die Modularisierung von Automatisierungsl\u00f6sungen entsprechend technologischer Teilfunktionen ist die Basis f\u00fcr eine Wiederverwendung von Teill\u00f6sungen 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\u00f6nnen, sowie in der Motivation der Projekteure, erfolgreiche eigene L\u00f6sungen so zu modularisieren und zu beschreiben, dass eine erfolgreiche Wiederverwendung durch andere m\u00f6glich ist.<\/p>\n

                Die Wiederverwendbarkeit von Artefakten erm\u00f6glicht damit letztendlich eine Optimierung des Engineering-Prozesses hinsichtlich Kosten, Zeitaufwand, Qualit\u00e4t der L\u00f6sung, sowie Wartungsaufwand.<\/p>\n

                4.2.5\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/em> Regelbasierte Ans\u00e4tze<\/em><\/strong><\/p>\n

                Zur Reduktion repetitiver und damit nicht-wertsch\u00f6pfender Engineering-T\u00e4tigkeiten wird zunehmend die \u201eAutomatisierung der Automatisierung\u201c in Betracht gezogen, korrekter: die Automatisierung von Engineering-Aufgaben der Automatisierungstechnik. Dies kann insbesondere auf der Basis wissensbasierter, z.B.<\/abbr> regelbasierter, Systeme erfolgen, welche das Wissen \u00fcber typische, vergleichsweise einfache und h\u00e4ufige 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\u00fctzt auswertbare Spezifikation der Automatisierungsaufgabe. Die zweite und dritte Voraussetzung k\u00f6nnen in Kombination erf\u00fcllt werden durch ein Anlagenmodell mit funktionaler Struktur und Beschreibung, welches z.B.<\/abbr> in Form von CAEX [IEC62424] vorliegt und aus einem Engineering-Werkzeug \u00fcber eine neutrale Schnittstelle generiert wurde. Diese Schnittstellen m\u00fcssen nicht nur syntaktisch, sondern auch semantisch eindeutig definiert sein, um die Konsistenz der Information zu gew\u00e4hrleisten. Semantische Konsistenz bedeutet jedoch, einheitliche Begriffe zu finden und zu vereinbaren [Schn08], ein m\u00fchsamer und zeitaufw\u00e4ndiger Prozess.<\/p>\n

                Sind diese Voraussetzungen gegeben, so kann auf diesem Weg z.B.<\/abbr> automatisch Steuerungscode zur L\u00f6sung 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\u00e4nde signifikant zu reduzieren.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
                [BSFWG09]<\/td>\nM. 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\u00f6ffentlichung in: Tagungsband der \u201eIEEE IECON 2009\u201c \u2013 35th Annual Conference of the IEEE Industrial Electronics Society, Porto, Portugal, 03.-05. November 2009.<\/td>\n<\/tr>\n
                [Fri03]<\/td>\nPeter Fritzson: Principles of Object-Oriented Modeling and Simulation with Modelica 2.1. Wiley-IEEE Press, 2003.<\/td>\n<\/tr>\n
                [Gri03]<\/td>\nM. Griss: Reuse Comes in Several Flavors. SDPC White paper, Flashline Inc., May 2003. Quelle: http:\/\/martin.griss.com\/pubs\/WPGRISS02.pdf <\/a> [letzter Zugriff 28.07.2009].<\/td>\n<\/tr>\n
                [IEC62424]<\/td>\nIEC 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.<\/td>\n<\/tr>\n
                [JaGriJo97]<\/td>\nI. Jacobson, M. Griss, P. Jonsson: Software Reuse. Addison Wesley, 1997.<\/td>\n<\/tr>\n
                [Maga08]<\/td>\nC. Maga: Domain-Engineering erschlie\u00dft ungenutzte Wiederverwendungspotenziale. ESE-Kongress, Sindelfingen, 2008.<\/td>\n<\/tr>\n
                [RSFPW09]<\/td>\nS. Runde, A. Scholz, A. Fay, J. Pollmeier, C. Wolff: Unterst\u00fctzungssoftware f\u00fcr das Automationsstations-Engineering in der Geb\u00e4udeautomation. In: Automatisierungstechnische Praxis, Heft 6\/2009, S. 42 \u2013 49.<\/td>\n<\/tr>\n
                [Schm08]<\/td>\nT. Schmidberger: Wissensbasierte Auswertung von Anlagenplanungsdaten f\u00fcr die Unterst\u00fctzung des Prozessleittechnikingenieurs – Anwendung einer rollenbasierten Mustersuche. Dissertation HSU<\/abbr>\/UniBW Hamburg. VDI-Fortschritt-Bericht Band 415. VDI-Verlag. D\u00fcsseldorf, 2008.<\/td>\n<\/tr>\n
                [Schn08]<\/td>\nE. Schnieder, L. Schnieder: Axiomatik der Begriffe f\u00fcr die Automatisierungstechnik. In: Automatisierungstechnische Praxis, Heft 10\/2008, S. 62 \u2013 73.<\/td>\n<\/tr>\n
                [Schn91b]<\/td>\nE. Schnieder: Methodischer Entwurf von Automatisierungssystemen mit Petri-Netzen. In: [Schn91a], S. 27 \u2013 42.<\/td>\n<\/tr>\n
                [Vah99]<\/td>\nR. Vahldieck : Engineering gro\u00dfer Leitsysteme. 6. Fachtagung Entwicklung und Betrieb komplexer Automatisierungssysteme (EKA), Braunschweig, 26. bis 28. Mai 1999.<\/td>\n<\/tr>\n
                [VDI\/VDE 3695]<\/td>\nVDI\/VDE 3695:2009-05. Engineering von Anlagen – Evaluieren und optimieren. Gr\u00fcndruck. Blatt 1 bis 4.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

                5. Handlungsbedarf<\/h2>\n

                Da die Engineering-Kosten nicht eindeutig dem Hersteller oder Betreiber zuzuordnen sind, sondern im Wesentlichen beim Anlagenbauer bzw.<\/abbr> Systemintegrator, h\u00e4ufig in einem Netzwerk von Projektbeteiligten anfallen, fehlen die \u201eschwergewichtigen Treiber\u201c, um gr\u00f6\u00dfere gemeinschaftliche Anstrengungen, z.B.<\/abbr> in Form gro\u00dfer, \u00f6ffentlich gef\u00f6rderter F&E-Projekte, zu initiieren. In Anbetracht der Bedeutung des Engineerings von Automatisierungssystemen f\u00fcr Wissenschaft, Wirtschaft und Gesellschaft sind hier gr\u00f6\u00dfere Anstrengungen n\u00f6tig.<\/p>","protected":false},"excerpt":{"rendered":"

                Ver\u00f6ffentlichungen | Kooperationen | Labore An der Professur werden verschiedene Forschungsprojekte zu den im \u00dcberblick genannten Forschungsgebieten bearbeitet. F\u00fcr n\u00e4here Informationen wenden Sie sich gerne an Herrn Dr.–Ing. Felix Gehlhoff […]<\/p>\n","protected":false},"author":78,"featured_media":0,"parent":132,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-164","page","type-page","status-publish","hentry","category-forschung"],"_links":{"self":[{"href":"https:\/\/www.hsu-hh.de\/aut\/wp-json\/wp\/v2\/pages\/164","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.hsu-hh.de\/aut\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.hsu-hh.de\/aut\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.hsu-hh.de\/aut\/wp-json\/wp\/v2\/users\/78"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hsu-hh.de\/aut\/wp-json\/wp\/v2\/comments?post=164"}],"version-history":[{"count":143,"href":"https:\/\/www.hsu-hh.de\/aut\/wp-json\/wp\/v2\/pages\/164\/revisions"}],"predecessor-version":[{"id":4753,"href":"https:\/\/www.hsu-hh.de\/aut\/wp-json\/wp\/v2\/pages\/164\/revisions\/4753"}],"up":[{"embeddable":true,"href":"https:\/\/www.hsu-hh.de\/aut\/wp-json\/wp\/v2\/pages\/132"}],"wp:attachment":[{"href":"https:\/\/www.hsu-hh.de\/aut\/wp-json\/wp\/v2\/media?parent=164"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hsu-hh.de\/aut\/wp-json\/wp\/v2\/categories?post=164"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hsu-hh.de\/aut\/wp-json\/wp\/v2\/tags?post=164"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}