Unterstützung des Engineerings von fertigungstechnischen Produktionssystemen mit Hilfe von Maschinenfunktionen – Methode, Modell und Beschreibungsmittel für ein funktionsorientiertes Planen –

Von der Fakultät für Maschinenbau der Helmut-Schmidt-Universität / Universität der Bundeswehr Hamburg zur Erlangung des akademischen Grades eines Doktor-Ingenieurs (Dr.-Ing.) genehmigte

Dissertation

vorgelegt von Dipl.-Ing. André Scholz aus Radebeul

Hamburg 2018

Gutachter: Prof. Dr.-Ing. Alexander Fay Prof. Dr.-Ing. Christian Diedrich Vorsitzender: Prof. Dr.-Ing. habil. Thomas Klassen Tag der mündlichen Prüfung: 31.08.2018

Vorwort des Autors

Die vorliegende Arbeit entstand im Rahmen meiner Tätigkeit als Wissenschaftlicher Mitarbeiter an der Professur für Automatisierungstechnik der Helmut-Schmidt-Universität / Universität der Bundeswehr Hamburg in der Zeit von Juli 2013 bis Dezember 2017. Mein besonderer Dank gilt Herrn Professor Dr.-Ing. Alexander Fay für die Möglichkeit an seinem Lehrstuhl in unterschiedlichen Projekten forschen zu dürfen. Seine Förderung und Forderung, sowie die zahlreichen wissenschaftlichen Anregungen haben die Erstellung dieser Arbeit erst ermöglicht. Herrn Professor Dr.-Ing. Christian Diedrich danke ich für das Interesse an meiner Arbeit und die Übernahme des Zweitgutachtens. Herrn Professor Dr. Ing. habil. Thomas Klassen möchte ich meinen Dank für die Übernahme des Prüfungsvorsitzes aussprechen. Ich bedanke mich bei den Mitgliedern der Fachgremien und Ausschüsse, mit denen ich im Rahmen des GMA FA 6.16 und des NAMUR AK 1.10 viele spannende und konstruktive Sitzungen erleben konnte. Ebenso danke ich den Mitarbeitern im Forschungsprojekt SemAnz4.0 für das kreative und kollaborative Teamwork. Neben dem Forschungsteam von Professor Diedrich sind hier insbesondere die Mitarbeiter von eCl@ss, Herr Ralf Wiegand und Herr Christian Eck zu nennen, sowie Herr Martin Dubovy von Rösberg Engineering. Ein herzlicher Dank geht an alle Kollegen und Mitarbeiter der Professur für Automatisierungstechnik. Ohne dieses tolle Team von motivierten, aufmerksamen und geduldigen Kollegen wäre eine Forschung in so vielen Projekten in der Intensität nur schwer möglich gewesen. Besonders dankbar bin ich denen, die mir bei meiner Zeit an der Professur immer ein offenes Ohr schenkten: Herrn Henry Bloch, Herrn Constantin Hildebrandt und Frau Birte Caesar. Herrn Dr.-Ing. Maik Riedel und Herrn Dr.-Ing. Sebastian Schröck gilt zusätzlich mein besonderer Dank für ihre intensive Unterstützung, sei es durch ihre konstruktive Kritik an der Arbeit oder dem guten Zuspruch vor der Prüfung. Meinen Eltern danke ich für die immerwährende Unterstützung und den Rückhalt, der mir meinen beruflichen und wissenschaftlichen Weg möglich gemacht hat. Meiner Frau Silke danke ich für ihre bedingungslose Unterstützung und ihr geduldiges Verständnis. Ihre Liebe und Zuversicht gaben mir die notwendige Kraft, die vorliegende Arbeit fertig zu stellen.

Ansbach, September 2018 André Scholz

Inhaltsverzeichnis I

Inhaltsverzeichnis INHALTSVERZEICHNIS ...... I ABKÜRZUNGSVERZEICHNIS ...... V GLOSSAR ...... VII KURZFASSUNG ...... X ABSTRACT ...... XI 1 EINLEITUNG ...... 1 1.1 MOTIVATION ...... 1 1.2 ZIELSETZUNG UND WISSENSCHAFTLICHER BEITRAG DER ARBEIT ...... 2 1.3 AUFBAU DER ARBEIT...... 3 1.4 FORSCHUNGSFRAGEN ...... 4 2 ABLAUF DES ENGINEERINGS AUTOMATISIERTER SYSTEME ...... 6 2.1 BESCHREIBUNG ALLGEMEINER ENGINEERING-ANSÄTZE ...... 6 2.1.1 VDI-RICHTLINIE 3695 – ENGINEERING VON ANLAGEN ...... 6 2.1.2 VDI-RICHTLINIE 4499 – DIGITALE FABRIK ...... 7 2.1.3 VDI-RICHTLINIE 5200 – FABRIKPLANUNG ...... 8 2.1.4 PROJEKTBERICHT AQUIMO ...... 8 2.1.5 SCHNIEDER – METHODEN DER AUTOMATISIERUNG ...... 9 2.1.6 LÜDER – AGGREGATION OF ENGINEERING PROCESSES REGARDING THE MECHATRONIC APPROACH ...... 9 2.1.7 BERGHOLZ – OBJEKTORIENTIERTE FABRIKPLANUNG ...... 10 2.1.8 TAUCHNITZ – INTEGRIERTES ENGINEERING ...... 10 2.1.9 VDI/VDE-GMA – REFERENZ-ARCHITEKTUR MODELL INDUSTRIE 4.0 (RAMI4.0) ...... 10 2.1.10 CHRISTIANSEN – MODELLGESTÜTZTES ENGINEERING ...... 11 2.1.11 HÄMMERLE – AUTOMATIONML IM PRAXISEINSATZ ...... 11 2.1.12 ZUSAMMENFASSUNG ...... 12 2.2 ENGINEERING IN DER FERTIGUNGSTECHNIK ...... 13 2.2.1 VDI-RICHTLINIE 2206 – ENTWICKLUNGSMETHODIK FÜR MECHATRONISCHE SYSTEME ...... 13 2.2.2 VDI-RICHTLINIE 2223 – METHODISCHES ENTWERFEN TECHNISCHER PRODUKTE ...... 14 2.2.3 DRATH – DATENKONSISTENZ IM UMFELD HETEROGENER ENGINEERING-WERKZEUGE ...... 15 2.2.4 ANIS – CP³L: A CYBER-PHYSICAL PRODUCTION PLANNING LANGUAGE ...... 15 2.2.5 ZUSAMMENFASSUNG ...... 16 2.3 ENGINEERING IN DER PROZESSINDUSTRIE ...... 16 2.3.1 PAS 1059 – PLANUNG EINER VERFAHRENSTECHNISCHEN ANLAGE ...... 17 2.3.2 NAMUR-ARBEITSBLATT 35 – ABWICKLUNG VON PLT-PROJEKTEN...... 17 2.3.3 ZUSAMMENFASSUNG ...... 18 2.4 PARALLELISIERUNG DES ENGINEERINGS ...... 18 2.5 FOLGERUNGEN AUS DEN ANSÄTZEN DES ENGINEERINGS ...... 19 3 INFORMATIONSAUSTAUSCH IM ENGINEERING ...... 22 3.1 DIE BETEILIGTEN GEWERKE IM FERTIGUNGSTECHNISCHEN ENGINEERING ...... 22 3.2 VERWENDETE UND AUSGETAUSCHTE INFORMATIONEN IM ENGINEERING ...... 23 3.3 NORMEN UND STANDARDS ZUR OPTIMIERUNG DES ENGINEERINGS ...... 26 3.3.1 BEDEUTUNG DER STANDARDISIERUNG FÜR DAS ENGINEERING ...... 27 3.3.2 MERKMALE UND ECL@SS...... 27 3.3.3 VDI/VDE 3682 – FORMALISIERTE PROZESSBESCHREIBUNG ...... 29 3.3.4 NAMUR-EMPFEHLUNG 150 ...... 30 3.3.5 VDMA-SCHNITTSTELLE FÜR DEN MASCHINENBAU (ENTWURF) ...... 31 3.3.6 AUTOMATIONML ...... 32 3.3.7 ZUSAMMENFASSUNG DER BETRACHTETEN STANDARDS ...... 34 3.4 ZUSAMMENFASSUNG DES INFORMATIONSAUSTAUSCHES IM ENGINEERING ...... 34 Inhaltsverzeichnis II

4 ANSÄTZE DES FUNKTIONSORIENTIERTEN ENGINEERINGS ...... 36 4.1 DEFINITION DER FUNKTION ...... 36 4.2 DAS FUNKTIONSORIENTIERTE ENGINEERING IN VERSCHIEDENEN DOMÄNEN ...... 37 4.2.1 PROZESSINDUSTRIE ...... 37 4.2.2 GEBÄUDELEITTECHNIK ...... 38 4.3 ANSÄTZE ZUR FUNKTIONSORIENTIERTEN PLANUNG IN DER FERTIGUNGSTECHNIK ...... 39 4.3.1 ABGRENZUNG ZUM ANFORDERUNGSGETRIEBENEN ENGINEERING ...... 40 4.3.2 VDI-RICHTLINIE 2206 – ENTWICKLUNGSMETHODIK FÜR MECHATRONISCHE SYSTEME ...... 40 4.3.3 VDI RICHTLINIE 2222 – KONSTRUKTIONSMETHODIK ...... 42 4.3.4 AQUIMO ...... 43 4.3.5 MEPROMA – MECHATRONISCHES ENGINEERING ZUR EFFIZIENTEN PRODUKTENTWICKLUNG IM MASCHINEN- UND ANLAGENBAU ...... 45 4.3.6 KIEFER – MECHATRONIKORIENTIERTE PLANUNG AUTOMATISIERTER FERTIGUNGSZELLEN IM BEREICH KAROSSERIEROHBAU ...... 46 4.3.7 REUTER – DEFINITION EINES MECHATRONISCHEN INFORMATIONSMODELLS ZUR MODELLIERUNG VON AUTOMATISIERUNGSKOMPONENTEN UND MASCHINEN ...... 49 4.3.8 GEHRKE – ENTWURF MECHATRONISCHER SYSTEME AUS FUNKTIONSHIERARCHIEN ...... 50 4.3.9 HADLICH – VERWENDUNG VON MERKMALEN IM ENGINEERING VON SYSTEMEN ...... 51 4.3.10 FUSE – FUNCTION BASED SYSTEMS ENGINEERING ...... 53 4.3.11 HIMMLER – FUNCTION BASED ENGINEERING ...... 53 4.3.12 ZUSAMMENFASSUNG DER BETRACHTETEN ANSÄTZE ...... 54 4.4 BESCHREIBUNG VON ABLÄUFEN IM ENGINEERING-WORKFLOW ...... 56 4.4.1 AUSWIRKUNGEN DER FUNKTIONSORIENTIERUNG AUF DAS ENGINEERING ...... 56 4.4.2 BEDEUTUNG DER BESCHREIBUNG VON ABLÄUFEN FÜR DAS ENGINEERING ...... 57 4.4.3 BETRACHTUNG UNTERSCHIEDLICHER BESCHREIBUNGSMITTEL FÜR ABLÄUFE ...... 58 4.5 ABGRENZUNG VON WEITEREN INDUSTRIE-4.0-ANSÄTZEN ...... 64 4.5.1 ABGRENZUNG ZUR MODULARISIERUNG VON PRODUKTIONSSYSTEMEN ...... 64 4.5.2 ABGRENZUNG ZUM SERVICEORIENTIERTEN ENGINEERING ...... 65 4.6 SCHLUSSFOLGERUNGEN UND HANDLUNGSBEDARF...... 67 5 MODELLIERUNG DER MASCHINENFUNKTION ...... 69 5.1 AUFBAU DES SYSTEMMODELLS ...... 69 5.1.1 FUNKTIONSMODELL ...... 70 5.1.2 STRUKTURMODELL ...... 71 5.1.3 VERHALTENSMODELL ...... 72 5.1.4 MERKMALE IM SYSTEMMODELL ...... 73 5.2 VERWENDUNG DER MASCHINENFUNKTION IM ZUSAMMENSPIEL DER GEWERKE ...... 75 5.2.1 ABLAUF DER PLANUNG MIT DEM SYSTEMMODELL ...... 75 5.2.2 INFORMATIONEN IM FUNKTIONSMODELL...... 76 5.2.3 INFORMATIONEN IM STRUKTURMODELL ...... 81 5.2.4 INFORMATIONEN IM VERHALTENSMODELL ...... 84 5.2.5 VERWENDUNG VON MERKMALEN IM SYSTEMMODELL ...... 84 5.3 ZUSAMMENHÄNGE ZWISCHEN MASCHINENFUNKTIONEN ...... 86 5.3.1 VERBINDUNGEN ZWISCHEN ELEMENTEN INNERHALB DER TEILMODELLE ...... 86 5.3.2 VERBINDUNGEN ZWISCHEN DEN TEILMODELLEN DES SYSTEMMODELLS ...... 87 5.4 ZUSAMMENFASSUNG ...... 90 6 RECHNERINTERPRETIERBARE ABBILDUNG UND ÜBERTRAGUNG DER MASCHINENFUNKTION ...... 91 6.1 ABLAUF EINES DATENAUSTAUSCHES IM ENGINEERING ...... 91 6.1.1 DATENAUSTAUSCH ZWISCHEN ZWEI WERKZEUGEN ...... 91 6.1.2 DATENAUSTAUSCH IN EINEM WERKZEUGVERBUND ...... 92 6.2 DATENFORMATE ...... 93 6.2.1 UNIFIED MODELING LANGUAGE (UML) ...... 93 6.2.2 SYSTEMS MODELING LANGUAGE (SYSML) ...... 94 6.2.3 XML-BASIERTE DATENFORMATE ...... 94 Inhaltsverzeichnis III

6.2.4 TABELLEN UND DATENBANKEN ...... 95 6.2.5 WEB-TECHNOLOGIEN ...... 95 6.2.6 ZUSAMMENFASSUNG ...... 95 6.3 ABBILDUNG DES SYSTEMMODELLS IM DATENAUSTAUSCHFORMAT ...... 96 6.3.1 ABBILDUNG DES FUNKTIONSMODELLS ...... 96 6.3.2 ABBILDUNG DES STRUKTURMODELLS ...... 102 6.3.3 ABBILDUNG DES VERHALTENSMODELLS...... 103 6.3.4 ABBILDUNG DER VERBINDUNGEN ZWISCHEN DEN TEILMODELLEN ...... 103 6.4 ZUSAMMENFASSUNG ...... 104 7 VERWENDUNG DER MASCHINENFUNKTION IN DER PRAXIS ...... 106 7.1 BEISPIELPROJEKT 1: ANALYSE EINER BESTANDSANLAGE ...... 106 7.1.1 BESCHREIBUNG DES PRODUKTIONSSYSTEMS UND DES PRODUKTES ...... 106 7.1.2 VORGEHEN BEI DER DATENAUFNAHME ...... 106 7.1.3 SYSTEMMODELL DES PRODUKTIONSSYSTEMS...... 107 7.1.4 ABBILDUNG DES SYSTEMMODELLS IN AUTOMATIONML ...... 111 7.1.5 AUSWERTUNG DES SYSTEMMODELLS ...... 119 7.2 BEISPIELPROJEKT 2: FUNKTIONSANALYSE KOMPLEXER FERTIGUNGSSYSTEME ...... 121 7.2.1 BESCHREIBUNG DES PRODUKTIONSSYSTEMS ...... 121 7.2.2 FUNKTIONSMODELL DES PRODUKTIONSSYSTEMS ...... 121 7.2.3 AUSWERTUNG DES SYSTEMMODELLS ...... 124 8 DIE MASCHINENFUNKTIONEN ALS GEWERKE-ÜBERGREIFENDE DATENBASIS ...... 127 8.1 EINTEILUNG VON AUTOMATISIERTEN MASCHINENFUNKTIONEN ...... 127 8.1.1 LENZE – MASCHINENAUFGABEN ...... 127 8.1.2 PLCOPEN – MOTION CONTROL ...... 128 8.1.3 PATZAK – SYSTEMTECHNIK ...... 129 8.1.4 HIRTZ – A FUNCTIONAL BASIS FOR ENGINEERING DESIGN ...... 129 8.1.5 AKIYAMA – FUNKTIONENANALYSE ...... 130 8.1.6 ZUSAMMENFASSUNG DER ANSÄTZE ...... 131 8.2 KATEGORISIERUNG VON MASCHINENFUNKTIONEN ...... 131 8.2.1 DIN 8580 – FERTIGUNGSVERFAHREN ...... 131 8.2.2 VDI 2860 – MONTAGE- UND HANDHABUNGSTECHNIK ...... 132 8.2.3 IEC 62390 – LEITFADEN FÜR GERÄTEPROFILE ...... 132 8.2.4 DIN 19226-6 – REGELUNGS- UND STEUERUNGSTECHNIK: BEGRIFFE ZU FUNKTIONS- UND BAUEINHEITEN ...... 133 8.3 ZUSAMMENFASSUNG ...... 134 9 METHODE ZUR ERSTELLUNG VON INDIVIDUELLEN FUNKTIONSBIBLIOTHEKEN ...... 135 9.1 VORGEHENSWEISE ZUR ABLEITUNG VON MASCHINENFUNKTIONEN ...... 135 9.2 STRUKTURIERUNG DER BIBLIOTHEKEN IN MODULE UND VARIANTEN ...... 135 9.3 BIBLIOTHEKSERSTELLUNG UND -NUTZUNG IN EINEM BEISPIELUNTERNEHMEN ...... 137 9.3.1 ERSTELLUNG DER BIBLIOTHEKEN IN AUTOMATIONML...... 137 9.3.2 ANWENDUNG DER BIBLIOTHEKEN IM BETRACHTETEN UNTERNEHMEN ...... 139 9.4 ZUSAMMENFASSUNG ...... 141 10 ENGINEERING-WERKZEUG ZUR FUNKTIONSORIENTIERTEN PLANUNG ...... 142 10.1 GRAFISCHER EDITOR FÜR AUTOMATIONML-BASIERTE MODELLIERUNG ...... 142 10.1.1 BEDIENOBERFLÄCHE DES EDITORS ...... 142 10.1.2 FÄHIGKEIT: ÄNDERUNGEN UMSETZEN ...... 144 10.1.3 FÄHIGKEIT: DELTAVERGLEICH UNTERSCHIEDLICHER PLANUNGSSTÄNDE ...... 144 10.2 VISUALISIERUNG DER PROZESSBESCHREIBUNG ...... 145 10.3 ZUSAMMENFASSUNG ...... 146 11 ZUSAMMENFASSUNG UND AUSBLICK ...... 148 11.1 ZUSAMMENFASSUNG ...... 148 11.2 AUSBLICK ...... 151 Inhaltsverzeichnis IV

ANHANG A: ERGEBNISSE AUS DEM BEISPIELPROJEKT 1 ...... 152 ANHANG B: ERGEBNISSE AUS DEM BEISPIELPROJEKT 2 ...... 154 LITERATURVERZEICHNIS...... 157 LITERATUR ...... 157 NORMEN, RICHTLINIEN UND EMPFEHLUNGEN ...... 165 VERÖFFENTLICHUNGEN DES AUTORS ...... 167 STUDENTISCHE ARBEITEN ...... 168 REFERENZIERTE INTERNETQUELLEN ...... 169 LEBENSLAUF ...... 171

Abkürzungsverzeichnis V

Abkürzungsverzeichnis 3D 3 dimensional AK Arbeitskreis API Application programming interface ASB Automation Service Bus AT Automatisierungstechnik BMW Beschreibungsmittel, Methode, Werkzeug BPMN Business Process Model and Notation CAD Computer-aided design CAE Computer-aided engineering CAEX Computer-aided engineering exchange CDD Common Data Dictionary CPPS Cyber-physical production system ERP Enterprise-Resource-Planning FA Fachausschuss FPB Formalisierte Prozessbeschreibung GMA VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik HMI Human-Machine Interface HW Hardware ID Identifikator IT Informationstechnologie MTM Methods-Time Measurement MTP Module Type Package NC Numerical Control NE NAMUR-Empfehlung NIST National Institut of Standards and Technology OMG Object Management Group PERT Program Evaluation and Review Technique PLT Prozessleittechnik POE / POU Programmorganisationseinheit / Program organisation unit PPR Produkt, Prozess und Ressource RC Robot Control R&I-Fließschema Rohrleitungs- und Instrumentenfließschema SFC Sequential Function Chart Abkürzungsverzeichnis VI

SPS Speicherprogrammierbare Steuerung SW Software SysML Systems Modeling Language TMU Time Measurement Unit UML Unified Modeling Language VDMA Verband Deutscher Maschinen- und Anlagenbau XML Extensible Markup Language

Glossar VII

Glossar Beschreibungsmittel Dienen zur Beschreibung von Informationen in strukturierter Form. Im Zusammenhang mit der Steuerungstechnik wird darunter die Abbildungsform der unterschiedlichen Programmiersprachen der [IEC 61131-3] verstanden. Auch die formalisierte Prozessbeschreibung [VDI/VDE 3682-1] ist ein Beschreibungsmittel für Prozesse. Die unterschiedlichen Beschreibungsmittel können in verschiedenen Datenformaten abgebildet und ausgetauscht werden. Daten Daten stellen eine Folge von Zeichen dar, wobei ihre Bedeutung nicht eindeutig ist. Die Zeichen können z.B. aus Zahlen, Buchstaben oder @ Symbolen bestehen. [DAT18 ] Datenformat Das Datenformat definiert die Struktur von Daten zum Datenaustausch und zur Datensicherung. Es enthält Informationen über das Dateiformat, in dem die Daten transportiert werden. Effekt Mittels eines physikalischen Effektes werden verändernde Einwirkungen an einem Produkt vorgenommen. Effekte lassen sich nach ihrer Wirkung am Produkt kategorisieren. Funktionen lassen sich durch Effekte realisieren. [ROT14] Element Repräsentiert einen Bestandteil des Systemmodells oder seiner Teilmodelle. Engineering „Das Engineering ist die systematische Anwendung von Kenntnissen über physikalische Gesetzmäßigkeiten zur Konzeption, Erschaffung und Verbesserung von Anlagen. Das Engineering erfordert das Zusammenwirken verschiedener Gewerke, z. B. der Prozesstechnik, des Maschinenbaus, der Elektrotechnik und der Automatisierungstechnik.“ [VDI/VDE 3695-1, S. 5] Engineering-Ansatz Unterschiedliche Engineering-Ansätze beschreiben jeweils einen Engineering-Workflow, der aus unterschiedlichen Engineering-Phasen besteht. Engineering-Phase Repräsentiert einen Tätigkeitsabschnitt innerhalb eines Engineering- Workflow, der meist mit einem Meilenstein in Form eines Planungsdokumentes abgeschlossen wird. Engineering- Repräsentiert eine Aneinanderreihung von Tätigkeiten, gegliedert in Workflow Phasen, zur Durchführung des Engineerings eines Systems. Funktion Für die vorliegenden Arbeit wird die Definition der [VDI 2221] genutzt, in Verbindung mit der Erweiterung von [GCD15]: Eine Funktion ist eine lösungsneutral beschriebene Beziehung zwischen Eingangs-, Ausgangs- und Zustandsgrößen eines Systems mit dem Ziel, eine Aufgabe zu erfüllen. Funktionseinheit Eine Funktionseinheit (functional unit) ist ein Element des Strukturmodells. Es stellt ein nach Aufgabe oder Wirkung abgrenzbares Gebilde dar. Eine Funktionseinheit kann ein System, ein Segment, eine SW-Einheit/HW-Einheit, eine SW-Komponente, ein @ SW-Modul oder eine Datenbank sein [GRA17 ]. Funktionsmodell Repräsentiert den Teil des Systemmodells, der die Funktionen eines Systems abbildet.

Glossar VIII

Gewerk Als Gewerk bezeichnet man handwerkliche und bautechnische @ Arbeiten im Bauwesen [WIK17B ]. Im Zusammenhang mit dem Engineering wird auch von Disziplinen gesprochen [VDI 2206]. Diese können in der Domäne der Fertigungstechnik sein: Maschinenbau, Elektrotechnik, Informationstechnik (Automatisierungstechnik) Information Aus Daten können Informationen entstehen, wenn bekannt ist, in welchem Kontext die Daten stehen. Durch eine Kombination verschiedener Daten wird eine Beziehung hergestellt, die interpretiert @ werden kann. Die Daten werden zu einer Information. [DAT18 ] Kaufteil Ist eine Komponente, die nicht im eigenen Unternehmen gefertigt, sondern von anderen Unternehmen bezogen wird [VDI 2815-2]. Komponente Repräsentiert das kleinste Element des Strukturmodells. Komponenten sind die elementaren physischen Bestandteile, aus denen sich ein System aufbauen lässt. Eine Komponente kann ein Konstruktions- oder ein Kaufteil sein. Im Strukturmodell erfüllen die Komponenten zusammengesetzt zu Funktionseinheiten eine bestimmte Funktion. Konstruktionsteil Repräsentiert ein Teil, das im eigenen Unternehmen konstruiert und ggf. auch gefertigt wird. Merkmal „Ein Merkmal ist eine allgemein erkennbare Eigenschaft eines Betrachtungsgegenstandes, die zu einer Klassifizierung des Betrachtungsgegenstandes genutzt werden kann.“ [HAD15, S. 7] Metamodell „Ein Metamodell ist ein Modell, das die Konzepte einer Modellierungstechnik - damit sind deren verwendbaren Modellelemente und die diesbezüglichen Zusammenhänge @ angesprochen – modelliert.“ [ITW17 ] In der vorliegenden Arbeit dient es eben diesem Zweck: zur Beschreibung der entwickelten Modelle, deren Aufbau und den darin enthaltenen Verbindungen. Modul Ein Modul wird als eine räumlich abgegrenzte, komplexe Baugruppe betrachtet, mit definierten Schnittstellen für mechanische Verbindungen sowie für den Austausch von Energie und Informationen, vgl. [BLE11]. Norm „Eine Norm ist ein Dokument, das Anforderungen an Produkte, Dienstleistungen oder Verfahren festlegt.“ [DIN18@] Eine Norm ist eine anerkannte und durch ein Normungsverfahren beschlossene, allgemeingültige sowie veröffentlichte Regel. PLCopen XML Ist ein XML-basiertes Datenformat zur Übertragung von Beschreibungsmitteln der SPS-Programmierung, die in der [IEC 61131-3] beschrieben sind [PLC17@]. PPR-Konzept PPR = Produkt, Prozess und Ressource. Ein Ansatz zur Beschreibung von Abläufen. Er beruht auf der Betrachtung eines Systems und seinen Ein- und Ausgangsgrößen. Materie, Energie und Information können als diese Ein- und Ausgangsgrößen definiert [PAT82] und als Fluss innerhalb eines Systems oder Prozesses dargestellt werden. Betrachtet man die Flüsse in ein System als Produkte, das System als Prozess und die Ressource, die diesen Prozess ausführt, so hat man alle Elemente für das PPR-Konzept definiert [DBK+15]. Das PPR-Konzept wird auch als Drei-Sichtenkonzept bezeichnet [DRA10]. Glossar IX

Prinzipielle Lösung „Eine prinzipielle Lösung stellt eine grundsätzliche Lösung für eine abgegrenzte Konstruktionsaufgabe dar, die lediglich bestimmte grundlegende Festlegungen zur physikalischen – bei Software logischen – Wirkungsweise und zur Art und Anforderung von festen Körpern, Fluiden und Feldern oder bei Software zu Algorithmen und Datenstrukturen trifft, ohne diese bereits im Detail zu definieren.“ [VDI 2222-1] Produkt Repräsentiert das Ergebnis der Produktion oder des Produktionsprozesses. Produkte können Sachgüter, Dienstleistungen oder Energien sein. Sie bilden die Zusammenfassung der materiellen oder immateriellen @ Eigenschaften einer Ware oder Dienstleistung [WIR17 ]. In der vorliegenden Arbeit ist das Produkt Teil des Funktionsmodells. Es repräsentiert das durch das Produktionssystem zu fertigende Gut und seine Einzelteile. Produktfamilie Bezeichnet eine Gruppe von Produkten, deren Herstellung ähnliche Arbeitsabläufe, Verarbeitungsschritte und Betriebsmittel erfordert [FRA02]. Produktionssystem Ein System, das zur Erzeugung eines Produktes benötigt wird. Sicht Repräsentiert den Interessenbereich eines Planers auf ein Objekt. Durch die Gruppierung von Informationen zu einem Objekt in verschiedene Sichten ist es möglich, dem Planer nur die für ihn relevanten Informationen anzuzeigen. Standard „Im Gegensatz zu einer Norm wird der Inhalt eines Standards, einer sogenannten DIN SPEC, durch ein temporär zusammengestelltes Gremium erstellt. Konsens und die Einbeziehung aller interessierten Kreise sind nicht zwingend erforderlich.“ [DIN18@] Jedes, auch firmeninterne Regelwerk zur Regelung eines Sachverhaltes kann als Standard bezeichnet werden. Systemmodell Repräsentiert ein Modell zur Abbildung eines Produktionssystems, das während des Engineerings durch die unterschiedlichen Planer erstellt und zum Aufbau des Systems genutzt wird. Kann im vorliegenden Ansatz in bis zu drei Teilmodelle aufgegliedert werden: Funktions-, Struktur- und Verhaltensmodell. Technische Repräsentiert ein Element des Funktionsmodells, das die Prozesse Ressource und Prozessschritte ausführt. Die Technische Ressource stellt damit eine Funktion zur Verfügung. In der vorliegenden Arbeit wird die Technische Ressource im Laufe des Engineerings mit Anforderungen angereichert, die eine noch auszuwählende physikalische Komponente erfüllen muss. Template Projekt- und/oder anlagenspezifischer Standard für Funktionseinheiten. Templates können sowohl durch Software als auch durch Hardware realisiert werden [NA 35]. UML4SysML Repräsentiert ein Subset an Beschreibungsmitteln aus der Beschreibungssprache UML, welches um eigene Elemente erweitert wurde, um die Anforderungen der Beschreibungssprache SysML zu erfüllen, vgl. [OMG17@]. Kurzfassung X

Kurzfassung Industrie 4.0 birgt Chancen und Herausforderungen. Zum einen stehen durch die zunehmende Digitalisierung nahezu unbegrenzte Mengen an Daten über Prozesse, Geräte und Produkte zur Verfügung. Zum anderen müssen diese Daten strukturiert, verstanden, ausgetauscht und verarbeitet werden, um deren Mehrwert für das Engineering von Produktionssystemen oder für neue Geschäftskonzepte zu nutzen. Die vorliegende Arbeit stellt einen Ansatz vor, wie die Strukturierung der Daten von Produkten, Prozessen und Ressourcen mit Hilfe eines Systemmodells zur Herstellung eines Kontextes zu den Daten und deren Nutzung als Informationen gelingen kann. Dazu wird in der vorliegenden Arbeit das Engineering von Produktionssystemen und dessen Phasen untersucht, um daraus abzuleiten, welcher Stakeholder im Engineering-Workflow welche Daten erstellt und austauscht. Zudem wird eine Gewerke-übergreifende Kommunikationsgrundlage in der Maschinenfunktion gefunden. Diese Maschinenfunktion stellt den Kern des entworfenen Modells zur Beschreibung des Produktionssystems im Engineering dar. Dieses Funktionsmodell wird in der vorliegenden Arbeit um die Aspekte Struktur und Verhalten erweitert. Somit liegt ein dreiteiliges Systemmodell vor, dessen Teilmodelle sich mit definierten Schnittstellen miteinander verknüpfen lassen, um die im Engineering erzeugten Informationen zu strukturieren, zu interpretieren und sie zwischen den Gewerken auszutauschen. Für die Abbildung der Teilmodelle werden etablierte Standards genutzt, wie die Formalisierte Prozessbeschreibung, Beschreibungsmittel für die SPS-Programmierung und hierarchische Strukturen. Darüber hinaus wird ein Konzept vorgestellt, wie das Systemmodell im Engineering schrittweise aufgebaut und von den Gewerken genutzt werden kann. Für den Austausch werden unterschiedliche Datenformate untersucht und das geeignetste für den vorliegenden Ansatz ausgewählt. Das Systemmodell wird dementsprechend in AutomationML abgebildet. Dabei erfolgt eine detaillierte Abgrenzung zu bereits existierenden Ansätzen. Die Nutzung des Systemmodells wird an zwei Praxisbeispielen evaluiert, deren Nutzen beschrieben und mit den entstehenden Aufwänden verglichen. Für eine optimale Nutzung des vorgestellten Systemmodells wird ein Ansatz vorgestellt, wie firmeneigenen Bibliotheken erstellt werden, die das Engineering unterstützen können. Diese Bibliotheken enthalten Funktionen und Komponenten, die sich im Engineering bestehender Produktionssysteme bereits etabliert haben. Auch dieses Vorgehen wird an einem Praxisbeispiel erläutert. Zum Abschluss der vorliegenden Arbeit wird ein prototypisches Engineering-Werkzeug vorgestellt, welches die beiden Ansätze der Systemmodellierung und der Bibliothekserstellung umfassend unterstützt. Dieses Werkzeug stellt umfangreiche Funktionalitäten zur Verfügung, um große Datenmengen zu bearbeiten. Zudem werden Informationen aus dem Systemmodell mit dem entwickelten Werkzeug grafisch dargestellt. Das entwickelte Bibliothekskonzept wird durch die Abbildung von eigenen, hierarchisch gegliederten Bibliotheken unterstützt.

Abstract XI

Abstract Industry 4.0 holds opportunities and challenges. On the one hand, increasing digitization means that almost unlimited amounts of data are available on processes, devices and products. On the other hand, this data has to be structured, understood, exchanged and processed in order to use its added value for the engineering of production systems or for new business concepts. The present work presents an approach how to structure the data of products, processes and resources with the help of a system model. For this purpose, the engineering of production systems and the corresponding phases are examined in order to deduce which data is created and exchanged in the engineering workflow. In addition, the machine function has been identified as a trade-overlapping communication basis. This machine function represents the core of the designed model for the description of the production system in engineering. In the present work, this model is extended by the aspects of structure and behavior. Thus, there is a three-part system model, while the submodels can be linked together with defined interfaces in order to structure and interpret the information generated in engineering and to exchange it between the trades. For modeling the submodels, established standards are used, such as the formalized process description, description means for PLC programming and hierarchical structures. A concept is presented how the system model in engineering can be gradually built up and used by the trades. For the exchange, different exchange formats are examined and the most suitable one selected for the present approach. The system model is mapped accordingly to AutomationML. There is a detailed distinction from already existing approaches. The use of the system model is explained by two practical examples and their benefits are described and compared with the required expenses. For an optimal use of the presented system model, an approach is presented how to create proprietary libraries that can support the engineering. These libraries contain functions and components that have already become established in the engineering of existing systems. This procedure is also explained using a practical example. At the end of the present work, a prototypical engineering tool will be presented, which comprehensively supports the two approaches of sytem modelling and creation of libraries. This tool provides extensive functionality to handle large amounts of data. In addition, information from the system model is graphically displayed with the developed tool. The developed library concept is supported by the mapping of own hierarchically arranged libraries.

1 Einleitung 1

1 Einleitung In den folgenden Abschnitten wird die vorliegende Arbeit motiviert, indem eine Einordnung des Themas der Arbeit in den Zusammenhang von Digitalisierung, Industrie 4.0 und den daraus resultierenden Herausforderungen erfolgt. Anschließend wird die Zielsetzung und der wissenschaftliche Beitrag der vorliegenden Arbeit erklärt. Darauf aufbauend wird zur Orientierung der Aufbau der vorliegenden Arbeit beschrieben. Anschließend werden die Forschungsfragen erklärt, die im Laufe der vorliegenden Arbeit beantwortet werden.

1.1 Motivation „Derzeit überschreiten wir eine Schwelle, an der die Digitalisierung weite Teile des täglichen Lebens, der Wertschöpfungsprozesse und des Arbeitens durchdringt: Das Internet vernetzt nicht nur kommunizierende Menschen, sondern auch „kommunizierende“, d.h. Daten aussendende Dinge.“ [BUN17] Das hat zur Folge, dass die physische und die virtuelle Welt stetig zusammenwachsen. Die Zahl der Objekte mit intelligenter Sensor-, Aktor- und Kommunikationstechnologie nimmt immer mehr zu. Diese Objekte sind über das Internet der Dinge vernetzt, tauschen Informationen aus und stellen ihre Daten für neue Geschäftsprozesse zur Verfügung. Die Verfügbarkeit all dieser Daten in Echtzeit ermöglicht es, zu jedem Zeitpunkt den optimalen Wertschöpfungsfluss abzuleiten und zudem neue Geschäftsmodelle zu entwickeln. [VDI15@] Im Zusammenhang mit den aufgezeigten Chancen durch die Digitalisierung und der damit verbundenen Verfügbarkeit von riesigen Datenmengen stehen ebenfalls Herausforderungen. Einige der Herausforderungen, die vor allem produzierende Unternehmen betreffen, sind im Folgenden aufgeführt [ABRE11]:

• Globalisierung: Durch zunehmendes Wachstum des Welthandels, die steigende weltweite Kooperation und Verflechtung produzierender Unternehmen sowie die Auslagerung von Produktionsstätten in Niedriglohnländer kommt es zu einem stärker globalisierten Wettbewerb und einer erhöhten Notwendigkeit des elektronischen Datenaustausches. Aus der Globalisierung resultiert ein steigender Kostendruck auf die produzierenden Unternehmen, während ständig neue Innovationen von den internationalen Kunden verlangt werden. • Verkürzung der Produktlebenszyklen: Fortlaufende Weiterentwicklung von Kern- Technologien und häufiger werdende Innovationssprünge führen zu einer Reduzierung der Zeit, die zwischen zwei Produktgenerationen liegt. Hinzu kommt die zunehmende Nachfrage nach kundenindividuell gefertigten Produkten bis hin zu einer Fertigung in Losgröße „Eins“. Dadurch sind produzierende Unternehmen gezwungen, neue Produktvarianten in immer kürzerer Zeit zu entwickeln und zu produzieren und ihre Produktionsprozesse und -systeme entsprechend den veränderten Anforderungen anzupassen. • Ressourcenverknappung: Der weltweit steigende Bedarf an Energie und Rohstoffen kann auf Dauer nicht im bisherigen Umfang gedeckt werden. Es ist für produzierende Unternehmen zunehmend von Bedeutung, ressourcenschonende Technologien und Fertigungsverfahren zu nutzen und ihre Produktionssysteme entsprechend umzurüsten. • Durchdringung mit neuen Technologien: Die Verflechtung unterschiedlicher Disziplinen wie Mechanik, Elektronik und Informatik führt zur Generierung neuer Technologien, die zunehmend Einzug in den menschlichen Alltag, aber auch in die industrielle Produktion 1 Einleitung 2

finden [HDL10]. Dies erfordert neue Herstellungsverfahren in der Produktion und führt zu Anpassungen an den Produktionssystemen. Diese Aspekte stellen besonders das Engineering von Produktionssystemen vor Herausforderungen. Die sich stetig ändernden Anforderungen an die Produkte und die Produktionssysteme für deren Fertigung, verursacht durch Produktwechsel oder dessen Variation durch Kundenwünsche sowie die Anpassung der Produktionsprozesse an neue, innovative und ressourcenschonende Technologien, führt zu häufigeren Neuplanungen von zunehmend flexibleren Produktionssystemen sowie zu Umplanungen an bestehenden Systemen in immer kürzeren Zeiträumen. Dazu kommt die immer stärkere Verflechtung der verschiedenen Gewerke im Engineering, um neue Technologien in den Produktionssystemen effizient einzusetzen. Dies führt zusätzlich zu steigenden Aufwänden im Engineering. Zusammenfassend können die Herausforderungen für das Engineering von Produktionssystemen wie folgt benannt werden: In immer kürzeren Engineering-Phasen müssen immer flexiblere und komplexere Produktionssysteme entwickelt werden, unter Berücksichtigung einer zunehmenden Anzahl technischer Lösungen und unter gleichzeitiger Einbindung aller am Engineering beteiligten Gewerke. Daraus folgt die Kern- Herausforderung, dass immer mehr Informationen über die Produktionssysteme von unterschiedlichen Beteiligten erzeugt, bearbeitet und ausgetauscht werden müssen. Dies stellt besondere Herausforderungen an die im Engineering-Prozess verwendeten Modelle mit ihren Beschreibungsmitteln, die verwendeten Methoden und die eingesetzten Werkzeuge. Wenn möglich sollen die Modelle der Produktionssysteme alle Aspekte von Industrie 4.0 abdecken. Im Einzelnen sind das vertikale und horizontale Integration, sowie die Unterstützung des durchgängigen Engineerings [VDI15@]. Bei der Berücksichtigung der vertikalen Integration muss die Vernetzung der unterschiedlichen Ebenen eines Produktionssystems, von der einzelnen Komponente, den verbauten Feldgeräten bis zum Leitsystem beschrieben werden. Die horizontale Integration berücksichtigt die Nutzung der Informationen aus dem Engineering und dem Betrieb der Produktionssysteme über Wertschöpfungsnetzwerke hinweg. Bei der Unterstützung des durchgängigen Engineerings ist die durchgehende konsistente Nutzung der Informationen über das Produkt und das Produktionssystem im Engineering-Prozess von allen Beteiligten zu beachten. Ein solches Engineering-Vorgehen hat sich bisher nicht etabliert. Es existieren einige Ansätze, um einzelne der genannten Herausforderungen zu meistern. Daher wird in der vorliegenden Arbeit ein Versuch unternommen, geeignete Ansätze zu untersuchen und in geeigneter Weise so zu kombinieren, dass ein Beitrag zur Lösung der beschriebenen Herausforderungen geleistet werden kann.

1.2 Zielsetzung und wissenschaftlicher Beitrag der Arbeit Die vorliegende Arbeit bedient sich aus bereits etablierten Ansätzen des Engineerings und kombiniert diese in geeigneter Weise, um den veränderten Anforderungen aus den aufgezeigten Herausforderungen und dem Themenkomplex Industrie 4.0 zu begegnen. Durch die zunehmende Digitalisierung stehen im Engineering mehr Daten zu Geräten und Prozessen zur Verfügung, die strukturiert in einem Systemmodell abgelegt werden müssen, um sie als Informationen optimal im Engineering zu nutzen. Diese Daten müssen strukturiert, modelliert und in einem Datenformat abgebildet werden. Nur so können die Daten von den 1 Einleitung 3 entsprechenden Planern in den unterschiedlichen Engineering-Phasen erzeugt, ausgetauscht und verstanden werden. In Hinblick auf die Entwicklungen im Themenkomplex Industrie 4.0 kann das erstellte Systemmodell in der vorliegenden Arbeit einen Beitrag zur Strukturierung der Daten in der Verwaltungsschale [VDI16@] von Industrie 4.0-Komponenten liefern.

Eine Einordnung der vorliegenden Arbeit hinsichtlich des BWM-Prinzips [SCH99] stellt sich wie folgt dar: • Methode: es wird ein systematisches Vorgehen zur Modellerstellung eines fertigungstechnischen Produktionssystems beschrieben, • Beschreibungsmittel: dabei wird das Modell mit seinen unterschiedlichen Aspekten mit Hilfe von verschiedenen Beschreibungsmitteln dargestellt und in einem herstellerneutralen Datenformat abgebildet, • Werkzeug: zur Unterstützung der entwickelten Methode und der Nutzung der Beschreibungsmittel wurde ein prototypisches Werkzeug entworfen. Die vorliegende Arbeit hat das Engineering von fertigungstechnischen Produktionssystemen im Fokus. Da das funktionsorientierte Engineering in der Domäne der Fertigungstechnik nicht stark ausgeprägt ist, werden an einigen Stellen der vorliegenden Arbeit immer wieder Bezüge zu den Domänen der Prozessindustrie und der Gebäudeleittechnik hergestellt. In diesen Domänen ist die Funktionsorientierung in der Planung stark ausgeprägt. Daher werden an den notwendigen Stellen die Ansätze, Methoden und Modelle der Prozessindustrie und der Gebäudeleittechnik betrachtet, um daraus Ansätze für die Optimierung des Engineerings in der Fertigungstechnik abzuleiten.

1.3 Aufbau der Arbeit Der vorliegenden Einleitung folgend werden in Kapitel 2 allgemeine Engineering-Ansätze detailliert betrachtet. Daraus wird abgeleitet, wie ein Engineering-Workflow für die vorliegende Arbeit definiert werden kann. Darin wird zudem geklärt, welche Ergebnisse die einzelnen Phasen des Engineerings jeweils erzeugen. In dem daran anschließenden Kapitel 3 wird der Informationsaustausch im Engineering analysiert. Dabei spielen die unterschiedlichen Gewerke eine zentrale Rolle, und wie diese Informationen austauschen. Zudem erfolgt eine Betrachtung gängiger Normen und Standards zur Optimierung des Datenaustausches zwischen den Gewerken. Die betrachteten Standards finden teilweise im Laufe der vorliegenden Arbeit weitere Anwendung. Kapitel 4 fokussiert auf die Engineering-Ansätze, die mechatronisch oder funktionsorientiert sind. Dabei wird auch betrachtet, wie die Domänen der Prozessindustrie und der Gebäudeleittechnik die funktionsorientierte Planung durchführen. Ziel ist hier, die verwendeten Modelle und Funktionsbeschreibungen auf Eignung für den eigenen Ansatz der vorliegenden Arbeit zu prüfen. Das Kapitel 5 beschreibt in einem eigenen Ansatz den Aufbau eines funktionsorientierten Systemmodells und dessen Verwendung im Engineering-Workflow. Daran anschließend wird in Kapitel 6 das entwickelte Systemmodell in einem Datenformat abgebildet, das sich zum Austausch von Engineering-Daten eignet. In Kapitel 7 wird das beschriebene Systemmodell an zwei unterschiedlichen Praxisbeispielen angewendet und sein Nutzen sowie die damit verbundenen Aufwände beschrieben. 1 Einleitung 4

Aus der Praxis ergeben sich weitere Anforderungen an die Methode der vorliegenden Arbeit. Eine Unterstützung des vorgestellten Ansatzes durch ein Bibliothekskonzept erhöht die Wiederverwendung von Elementen der Funktions- und Lösungssammlungen. Daher wird in Kapitel 8 erneut der Stand der Technik in Bezug auf unterschiedliche Ansätze gängiger Funktionssammlungen hin untersucht, die für die Erstellung von Bibliotheken genutzt werden können. Die daraus gewonnenen Erkenntnisse werden in Kapitel 9 verwendet, um ein eigenes Vorgehen zum Aufbau firmeneigener Funktionsbibliotheken zu beschreiben. Dies wird ebenfalls an einem Praxisbeispiel erklärt. In Kapitel 10 wird abschließend ein prototypisch implementiertes Engineering-Werkzeug demonstriert, welches die gezeigte Methode und die gewählten Beschreibungsmittel unterstützt. Kapitel 11 fasst die Inhalte der Arbeit zusammen und gibt einen Ausblick auf sich anschließende Forschungsarbeiten für die mögliche Weiterentwicklung des vorgestellten Ansatzes.

1.4 Forschungsfragen In [MDL+14] werden Einflussfaktoren beschrieben, die sich auf den Engineering-Workflow auswirken: 1. die Zahl der Workflow-Schritte sowie die Zahl der vorgesehenen Schleifen, 2. die beteiligten Personen und Werkzeuge sowie ihre Schnittstellen, 3. die Komplexität des Workflows, 4. die verwendeten Modelle, 5. die Anpassbarkeit des Workflows an interne Geschäftsprozesse, 6. das Wissen über die Abhängigkeiten zwischen den Aktivitäten, 7. die Nutzerführung. Zur Optimierung des Engineering-Workflows müssen diese sieben Einflussfaktoren detailliert betrachtet werden. Die folgenden Forschungsfragen resultieren direkt aus den aufgeführten Einflussfaktoren. Durch die Beantwortung der jeweiligen Forschungsfrage in den einzelnen Kapiteln der vorliegenden Arbeit werden diese Einflussfaktoren zur Optimierung des Engineerings detailliert erläutert. Der entwickelte Ansatz der vorliegenden Arbeit soll einen Beitrag zu einer optimalen Ausrichtung der benannten Einflussfaktoren leisten. Ein Bezug zu den jeweiligen Fragen ist am Ende des Kapitels zu finden, welches eine der nachfolgend aufgeführten Fragestellungen beantwortet: 1. In welche Phasen ist das typische fertigungstechnische Engineering zur Errichtung von mechatronischen Produktionssystemen gegliedert und wie lassen sich diese Phasen ggf. parallelisieren? • Es sind allgemeine und fertigungstechnische Engineering-Ansätze zu untersuchen und miteinander zu vergleichen, um deren Ablauf im Detail zu verstehen. Die Phasen des jeweiligen Engineering-Workflows, die daran Beteiligten und die darin erzeugten Informationen sind dabei von besonderer Bedeutung.

2. Welche Informationen stehen im Mittelpunkt der Interessenbereiche der beteiligten Gewerke im fertigungstechnischen Engineering und dienen somit als Drehpunkt für eine Gewerke-übergreifende Kommunikation? 1 Einleitung 5

• Dies ist für die Modellbildung des Produktionssystems entscheidend. Das Modell, das im Engineering des Produktionssystems erstellt wird, sollte die gleichen Informationen im Mittelpunkt haben, die zur Gewerke-übergreifenden Kommunikation im Engineering genutzt werden. • Es sind daher die im Engineering erstellten und zwischen den Gewerken ausgetauschten Informationen zu analysieren. Dies umfasst sowohl die Informationen im Mittelpunkt der Kommunikation, als auch die Informationen, die zwischen den einzelnen Gewerken ausgetauscht werden. Die jeweiligen Informationen müssen durch das Modell übertragen werden, um das Engineering zu verbessern.

3. Wie ist das Modell des Systems aufzubauen und welche (möglichst genormten oder standardisierten) Beschreibungsmittel eignen sich für die Darstellung der unterschiedlichen Informationen im Modell des Produktionssystems? • Dazu sind unterschiedliche Engineering-Ansätze auf deren verwendete Modelle hin zu untersuchen und daraus das Optimum für die Beschreibung des Systems unter den Aspekten der unterschiedlichen Informationen aus den Gewerken auszuwählen. • Hierbei sind etablierte Normen und Standards zu verwenden, um die Strukturierung der Informationen des Modells des Produktionssystems zu unterstützen und die darin enthaltenen Informationen über das Produktionssystem für andere Beteiligte am Engineering des Systems nachvollziehbar zu machen.

4. Wie muss ein Modell eines Systems strukturiert sein, um die Gewerke-übergreifende Kommunikation optimal zu unterstützen? Und welche weiteren Informationen an den Schnittpunkten der Gewerke sind über das System abzubilden? • Aus den analysierten Informationen der unterschiedlichen Engineering-Vorgehen lassen sich die Informationen ableiten und eine geeignete Strukturierung des Modells des Produktionssystems entwickeln. • Zudem ist eine geeignete Methode für das Aufstellen des Modells aus den analysierten Vorgehen abzuleiten, die den Aufbau des Modells während des Engineerings des Produktionssystems unterstützt.

5. Wie lassen sich die Informationen/Beschreibungen aus dem Systemmodell zum Gewerke-übergreifenden Austausch in einem Datenformat abbilden? • Nach der Untersuchung unterschiedlicher Datenformate wird ein entsprechend geeignetes Datenformat für die Abbildung des Systemmodells ausgewählt. • Mit diesem Datenformat ist eine Abbildung des Systemmodells mit seinen Teilmodellen im Detail zu beschreiben.

6. Wie können diese Informationen in Bibliotheken abgelegt werden, um sie im Engineering von Neuanlagen wiederzuverwenden? • Eine Methode, wie Informationen in einem Bibliothekskonzept strukturiert abgelegt werden können, ist zu entwickeln. Die Nutzung der unterschiedlichen Bibliotheken wird an einem Beispiel aus der Praxis erklärt.

7. Wie können das Systemmodell und die Bibliotheken im gewählten Datenformat Werkzeug-gestützt dargestellt und bearbeitet werden? • Es ist ein Funktionsmuster zu erstellen, das die wesentlichen Funktionalitäten für die Bearbeitung des Systemmodells beinhaltet. Das erstellte Werkzeug ist an einem Beispiel anzuwenden. 2 Ablauf des Engineerings automatisierter Systeme 6

2 Ablauf des Engineerings automatisierter Systeme In diesem Kapitel wird der Begriff des „Engineerings“ für die vorliegende Arbeit definiert und detailliert beschrieben. Dazu werden aktuell gültige Normen zur Durchführung des Engineerings sowie Ansätze des Engineerings aus der Fachliteratur untersucht. Dabei spielen im Wesentlichen die Phasen eine Rolle, in die das Engineering eingeteilt wird. Von besonderem Interesse für die vorliegende Arbeit ist es, welche Beteiligten in den unterschiedlichen Phasen welche Ergebnisse erzeugen. Dabei wird auf die Besonderheiten des Engineerings in der Domäne der Fertigungstechnik in Abgrenzung zur Prozessindustrie eingegangen, da die Besonderheiten und Unterschiede den Planungsprozess der Systeme wesentlich beeinflussen und somit Auswirkungen auf die Optimierung des Engineerings haben. Während sich produzierende Unternehmen in der Vergangenheit auf den optimalen Ausgleich zwischen der Qualität der produzierten Produkte und den bei der Produktion anfallenden Kosten fokussierten, müssen zukünftig auch Leistungsgrößen wie Wandlungsfähigkeit und Ressourcenschonung adressiert werden [LOS13, S. 78]. Nicht nur im Rahmen von Industrie 4.0 [ASM+15] und den Versuchen, diesen Paradigmenwechsel in die Realität umzusetzen [WDF+14; FDT+15*; GWQ+16] - auch vorher waren Bemühungen vorhanden, das Engineering von Produktionssystemen schneller und effektiver zu gestalten. Zum einen wurden die Planungswerkzeuge selbst optimiert, zum anderen wurde versucht, die Planungsmethodik zu verbessern [WDH14]. Hier sind vor allem die mechatronischen und funktionalen Ansätze zu nennen, die in dieser Arbeit im besonderen Fokus stehen. Im vorliegenden Abschnitt werden unterschiedliche Engineering-Vorgehen untersucht, um Ansätze für deren Optimierung zu finden. Um die genannten Einflussfaktoren für die Optimierung des Engineerings einordnen zu können, werden im folgenden Kapitel allgemeine Engineering-Ansätze beschrieben. Dem schließt sich eine Betrachtung von spezifischen Engineering-Ansätzen aus der Fertigungs- und der Prozessindustrie an. In einem weiteren Abschnitt wird auf die Parallelisierung der einzelnen Phasen des Engineerings eingegangen. Aus den betrachteten Ansätzen werden im letzten Teil des vorliegenden Kapitels in einer Zusammenfassung die entscheidenden Phasen des Engineerings für die vorliegende Arbeit zusammengefasst und einige der vorgestellten Einflussfaktoren zur Optimierung hervorgehoben, die im Laufe der vorliegenden Arbeit weitere Beachtung finden.

2.1 Beschreibung allgemeiner Engineering-Ansätze Im folgenden Abschnitt werden unterschiedliche, allgemeine Engineering-Ansätze untersucht, um eine gültige Definition eines Engineering-Prozesses für die vorliegende Arbeit abzuleiten und aufzuzeigen, aus welchen Phasen das typische Engineering besteht.

2.1.1 VDI-Richtlinie 3695 – Engineering von Anlagen Die [VDI/VDE 3695-1] definiert das Engineering von Produktionssystemen als "...systematische Anwendung von Kenntnissen über physikalische Gesetzmäßigkeiten zur Konzeption, Erschaffung und Verbesserung von Anlagen." Dabei wird auch auf das Zusammenwirken unterschiedlicher Gewerke eingegangen und dass deren effektive Zusammenarbeit essentiell für die Qualität und die Zeit (-dauer) für die Durchführung des Engineerings ist. Das Engineering lässt sich in die folgenden Phasen gliedern, wie in Abbildung 2-1 in einem Workflow dargestellt. 2 Ablauf des Engineerings automatisierter Systeme 7

Abbildung 2-1: Engineering-Phasen der [VDI/VDE 3695-1] Es wird hervorgehoben, dass in der Akquisition alle Anforderungen an das System und alle Schnittstellen des Systems definiert werden müssen, damit die unterschiedlichen Gewerke in den darauf folgenden Phasen Planung und Realisierung unabhängig voneinander arbeiten können. Dafür ist ein einheitliches Modell des Systems zu erstellen, das die Anforderungen und deren Lösungen abbilden kann. Dieses Modell gewährleistet über alle Phasen hinweg eine Durchgängigkeit der Informationen.

2.1.2 VDI-Richtlinie 4499 – Digitale Fabrik Die Digitale Fabrik ist der Oberbegriff für ein umfassendes Netzwerk von digitalen Modellen, Methoden, Werkzeugen und Prozessen, die auf Basis eines integrierten Datenmanagements zur durchgängigen digitalen Planung, Simulation und Validierung von Produktionsprozessen und -systemen benötigt werden [VDI 4499-1]. Ihr Anwendungsbereich erstreckt sich dabei über alle Phasen des Produktionsentstehungsprozesses, wobei sämtliche Ebenen einer produzierenden Fabrik bzw. ihre individuellen Wechselwirkungen im Mittelpunkt der Betrachtung stehen [KIE07]. Die [VDI 4499-1] legt den Fokus auf die Produktionsplanung und Gestaltung der Fabrik. Zusätzlich beschreibt die [VDI 4499-1] auch Themen der Auftragsabwicklung. Somit liegt der Interessenbereich der Norm sowohl in den Produkt- und Produktionsentstehungsprozessen als auch in den Auftragsabwicklungsprozessen, wie in Abbildung 2-2 dargestellt.

Abbildung 2-2: Fokus der Digitalen Fabrik im Schnittpunkt der Prozesse nach [VDI 4499-1] Bezüglich ihres Anwendungsbereichs ist derzeit eine lebenszyklusbezogene Ausweitung der Digitalen Fabrik erkennbar. Wurde sie ursprünglich dazu entwickelt, die „Lücke“ bezogen auf die IT-Unterstützung zwischen Produktentwicklung (CAD) und Produktion (SPS/RC/NC) zu schließen, werden ihre Anwendungen in zunehmenden Maße auch zur Unterstützung des Produktionsanlaufs herangezogen. In diesem Zusammenhang halten die beiden Gewerke der Elektro- und Steuerungstechnik zunehmenden Einzug in die bis dato eher „Mechanik- orientierten“ Anwendungen der Digitalen Fabrik. [KIE07] Dies ist in Abbildung 2-2 zu erkennen, hier kommt es im Strahlenkreuz der Unternehmensprozesse zu einer Ausweitung des Interessenbereichs der Digitalen Fabrik von der Phase der Fabrikplanung hin zur Phase der Produktion [KIE07]. 2 Ablauf des Engineerings automatisierter Systeme 8

2.1.3 VDI-Richtlinie 5200 – Fabrikplanung Die [VDI 5200-1] beschreibt im Detail den Ablauf der Fabrikplanung. Der darin erklärte Planungsprozess besteht aus sieben Phasen, die in Abbildung 2-3 dargestellt sind.

Abbildung 2-3: Planungsphasen nach [VDI 5200-1] Die dargestellten Phasen werden weiter unterteilt. In der Detailplanung wird vom Engineering des einzelnen Produktionssystems einer Fabrik gesprochen, als Ergebnis liegt das Feinlayout des Produktionssystems der Fabrik vor. Die Phase der Detailplanung gliedert sich in die folgenden Unterphasen:

• Feinplanung, • Erstellung von Genehmigungsanträgen, • Erstellung der Leistungsbeschreibung. In der Feinplanung erfolgt die detaillierte Planung der Material-, der Informations- und der Kommunikationsflüsse in Form von Prozessdarstellungen und Prozessbeschreibungen [VDI 5200-1]. Dabei werden den Prozessen bestimmte Ressourcen zugeordnet. In einer weiteren Unterphase, der Leistungsbeschreibung, wird ein Lastenheft für diese Ressourcen und deren detaillierte Ausplanung erstellt, das zudem für die funktionale Leistungsbeschreibung benötigt wird. Hier hat der Lieferant des Produktionssystems die Planungsfreiheit, er kann die geforderten Funktionen frei ausgestalten. Im Gegensatz zur funktionalen Leistungsbeschreibung kann eine detaillierte Leistungsbeschreibung die Freiheitsgrade zur Lösungsfindung des Lieferanten einschränken. Die Prozessdarstellung und -beschreibung mit Hilfe von Flüssen sowie die daraus abgeleiteten Anforderungen an Ressourcen aus der Phase Detailplanung sind einige wesentliche Forderungen der Norm an einen effizienten Engineering-Workflow. Daher werden diese Punkte im Laufe der vorliegenden Arbeit weiter verfolgt.

2.1.4 Projektbericht AQUIMO Im Projekt AQUIMO (Adaptierbares Modellierungswerkzeug und Qualifizierungsprogramm für den Aufbau firmenspezifischer mechatronischer Engineering-Prozesse) wurde unter anderem untersucht, welche Phasen im Engineering eines Systems durchgeführt werden und welche verantwortlichen Personen es in diesen Schritten gibt. Daraus lassen sich die folgenden Phasen aus Abbildung 2-4 ableiten:

Abbildung 2-4: Planungsphasen nach [ABH+10, S. 44] In Abbildung 2-4 werden Phasen und Ergebnisse einzelner Phasen (Planungsartefakte) zusammen aufgeführt. Die Planungsartefakte Pflichtenheft und Prototyp können als Meilensteine des Engineering-Workflows verstanden werden. Die Phase Konzeption schließt somit mit der Erstellung des Pflichtenheftes ab, sowie die Konstruktion mit der Erstellung eines Prototyps abschließt [ABH+10]. Daran ist der Fokus des Projektes AQUIMO auf die Produktplanung zu erkennen. In der Planung eines Produktionssystems wird kaum ein 2 Ablauf des Engineerings automatisierter Systeme 9

(realer) Prototyp erstellt werden, da das zu aufwändig wäre. Hier wäre ein Prototyp in Form eines umfangreichen Systemmodells vorstellbar, das für die Simulation genutzt werden kann.

2.1.5 Schnieder – Methoden der Automatisierung [SCH99] teilt den Entwicklungsprozess eines Systems in die folgenden Phasen mit den jeweils dabei entstehenden Ergebnissen ein, siehe Abbildung 2-5.

Abbildung 2-5: Entwicklungsprozess nach [SCH99, S. 7] Dies ist die allgemeinste Darstellung des Planungsprozesses eines Systems. Dabei wird aus der Anforderungsdefinition eine Idee entwickelt, die dann im Entwurf in ein Modell des Systems umgesetzt wird. In der Phase der Realisierung entsteht dann das Produkt, in Form eines Produktionssystems oder eines Produktes. Wird dieses System in der letzten Phase in Betrieb genommen, dann entsteht daraus die geplante Leistung, um das anfangs gestellte Ziel zu erfüllen. Auch hier ist die Definition der Anforderungen eine wesentliche Forderung an den Engineering-Workflow. Zudem wird die Nutzung von Modellen angeregt, um die Realisierung zu gewährleisten.

2.1.6 Lüder – Aggregation of engineering processes regarding the mechatronic approach In [LFH+11] werden unterschiedliche Engineering-Ansätze miteinander verglichen, um daraus ein generelles Engineering-Vorgehen abzuleiten. In [SLS+14] wird dieses Engineering-Vorgehen nochmals dargestellt. Dabei wird detailliert auf die unterschiedlichen Tätigkeiten in den jeweiligen Phasen eingegangen, siehe Abbildung 2-6.

Abbildung 2-6: Allgemeines Engineering-Vorgehen nach [SLS+14] Hierbei wird ein allgemeines Engineering-Vorgehen mit branchenneutralen Phasenbezeichnungen aufgestellt. Im Detail wird auf die Phase des funktionalen Engineerings eingegangen, dass durch das Gewerke-übergreifende Planen und Konstruieren des Produktionssystems geprägt ist, vgl. [SLS+14]. Dies ist die Phase, in der die größte Möglichkeit der Parallelisierung der Tätigkeiten besteht, da hier unterschiedliche Gewerke teilweise unabhängig voneinander Planungsschritte ausführen [BMW+15]. 2 Ablauf des Engineerings automatisierter Systeme 10

2.1.7 Bergholz – Objektorientierte Fabrikplanung [BER05] analysiert einige Ansätze zur Fabrikplanung und kommt zusammenfassend zu den folgenden Phasen, in die sich das Engineering-Vorgehen einteilen lässt, siehe Abbildung 2-7:

Abbildung 2-7: Phasen des Planungsprozesses nach [BER05]

[BER05] nutzt zur Beschreibung der geplanten Fabrik im Kern ein Funktions- und ein Strukturmodell, die beide in einer Hierarchie mit unterschiedlichen Ebenen abgebildet werden.

2.1.8 Tauchnitz – Integriertes Engineering [TAU13] definiert das Engineering im engeren Sinne als die Planungsphase eines Produktionssystems. „Fasst man den Engineering-Prozess weiter auf, dann kommen zur Planungsphase alle anderen Prozesse zur Dokumentation während des gesamten Lebenszyklus einer Anlage…“ [TAU13] hinzu. Der Fokus liegt hier auf dem integrierten Engineering, in dem unterschiedliche Gewerke mit unterschiedlichen Werkzeugen dazu befähigt werden, miteinander Daten auszutauschen und auf gemeinsamen Modellen zu arbeiten.

2.1.9 VDI/VDE-GMA – Referenz-Architektur Modell Industrie 4.0 (RAMI4.0) In [VDI15@] wird das Engineering in die Lebenszyklen von Produkt, Maschine und Fabrik eingeordnet und in ein Referenz-Architektur Modell eingebunden, siehe Abbildung 2-8.

Abbildung 2-8: Relevante Lebenszyklen für Industrie 4.0-Komponenten [VDI15@] Hier findet die Betrachtung des Engineerings als Teil der Lebenszyklen der relevanten Industrie 4.0-Komponenten (Produkt, Auftrag, Fabrik, Maschine, Zulieferteil) auf unterschiedlichen Ebenen statt, die zeitlich versetzt zueinander betrachtet werden müssen. Die Produktentwicklung stellt hier die Anforderungen an die Maschine und somit auch an die Fabrik, welche die Maschinen beinhaltet. Dieser Ansatz wurde in [VDI16@] weiterentwickelt 2 Ablauf des Engineerings automatisierter Systeme 11 und um die Verwaltungsschale für jede der Industrie 4.0-Komponenten erweitert. Diese Verwaltungsschale bildet mit ihren Modellen des Objektes, das sie repräsentiert, somit einen digitalen Zwilling des realen Objektes, der beispielsweise alle Daten einer bestimmten Maschine über deren gesamten Lebenszyklus hinweg abbildet.

2.1.10 Christiansen – Modellgestütztes Engineering In [CHF14] wird auf die Verwendung von Modellen im Engineering fokussiert und die dabei auftretenden Herausforderungen, die durch die Vielfältigkeit der verwendeten Modelle in den jeweiligen Planungsphasen entstehen. Dabei wird ein Ansatz vorgestellt, der ein allgemeines, übergeordnetes Topologiemodell (top level topology model, TLT-Modell) im Fokus hat. Dieses TLT-Modell dient als Ausgangsbasis, um die spezifischen Gewerke- eigenen Teilmodelle zu erzeugen. Dieses Vorgehen basiert auf dem Ansatz, dass Teilmengen der spezifischen Modelle identisch sind, insbesondere hinsichtlich der Komponenten- und Strukturinformation, gegebenenfalls mit unterschiedlichem Detaillierungsgrad [CHF14]. Dieser Ansatz kann vor allem in späten Engineering-Phasen genutzt werden, in denen bereits konkrete Ressourcen ausgewählt sind, um eine bestimmte Funktion im System zu erfüllen. In frühen Phasen, wie der Anforderungsdefinition oder dem funktionalen Engineering, stehen die Strukturelemente zumeist noch nicht fest und somit kann eine bestimmte Komponente oder Struktur nicht als Schnittstelle für Teilmodelle verwendet werden. Für spätere Phasen, wie der virtuellen Inbetriebnahme, in der alle Komponenten ausgewählt und konfiguriert vorliegen, kann der vorgestellte Ansatz verwendet werden.

2.1.11 Hämmerle – AutomationML im Praxiseinsatz "Der klassische Anlagenentstehungsprozess ist herstellerübergreifend ähnlich und in typische Phasen aufgeteilt. Diese werden in der Praxis teilweise parallel, teilweise sequenziell durchlaufen…“ [HÄDR14].

In [HÄDR14] wird das Engineering mit Fokus auf die Fertigungstechnik in folgende Phasen gegliedert und mit den typischen Werkzeugen hinterlegt, die in der jeweiligen Phase zum Einsatz kommen können, siehe Tabelle 2-1.

Tabelle 2-1: Werkzeuge den Engineering-Phasen zugeordnet gem. [HÄDR14]

Phase Werkzeug Vorplanung SAP-Tools Konzeptplanung Office-Tools und Datenbanken Detailplanung CAD-Tools, wie: • Layout CATIA • Abläufe Siemens NX • Anlagenverhalten • Pneumatikplanung • Funktionsbeschreibung • Vorrichtungskonstruktion Geometriesimulation Delmia Process Simulate Offlineprogrammierungsphase RobCAD RobotStudio Hardwarekonstruktion ePlan • Elektroschaltplan Ruplan Softwarekonstruktion Native Systeme der Hersteller • SPS • HMI

Auch hier liegt der Fokus auf der Erstellung von integrierten Modellen mit Engineering- Ergebnissen aus den unterschiedlichen Gewerken, um diese für eine virtuelle 2 Ablauf des Engineerings automatisierter Systeme 12

Inbetriebnahme des Systems zu nutzen. Dadurch sollen Fehler in der Planung noch vor der Errichtung des Systems erkannt und verhindert, sowie die Inbetriebnahme beschleunigt werden.

2.1.12 Zusammenfassung Die im Abschnitt 2.1 dargestellten Ansätze für das Engineering von Systemen stellen allgemeine Vorgehensweisen dar, die sich in den Kernphasen nur wenig unterscheiden. Die [VDI 4499-1] beispielsweise fokussiert auf den Produkt- und Produktionsentstehungsprozess und die damit verbundenen Auftragsabwicklungsprozesse. Damit trifft sie die Kernprozesse des Engineering-Prozesses der [VDI/VDE 3695-1]: die Planung und Realisierung. Darunter sind sowohl die Planung der Prozesse der Produktion als auch die Planung der Produktionsressourcen zu verstehen. Abbildung 2-9 stellt die vorgestellten Phasen der unterschiedlichen Ansätze gegenüber und ordnet sie in einen zeitlichen Zusammenhang.

Abbildung 2-9: Gegenüberstellung der unterschiedlichen Phasen der betrachteten Ansätze Daraus kann der typische Engineering-Workflow eines Produktionssystems abgeleitet werden, siehe Abbildung 2-10. Er beginnt mit der Phase der Anforderungsdefinition. Die darin definierten Anforderungen ergeben sich aus dem Produkt, das durch das Produktionssystem hergestellt werden soll. In der darauf folgenden Entwurfsphase werden unterschiedliche Informationen und Beschreibungen genutzt, um ein Modell des Produktionssystems, das Systemmodell, zu erstellen. Dabei kommen unterschiedliche Planungswerkzeuge in den verschiedenen Gewerken zum Einsatz, die – wenn sinnvoll möglich – an deren Schnittstellen miteinander verbunden sein sollten, um ein integriertes, Gewerke-übergreifendes Engineering zu ermöglichen. In der darauf folgenden Phase der Realisierung wird das Systemmodell genutzt, um die Planungsdokumente für die Realisierung des Produktionssystems zu erstellen und für dessen Errichtung zu nutzen. Anschließend wird das Produktionssystem in Betrieb genommen. 2 Ablauf des Engineerings automatisierter Systeme 13

Abbildung 2-10: Abgeleiteter, allgemeiner Engineering-Workflow Es existieren neben den gezeigten allgemeinen Ansätzen des Engineerings weitere Ansätze, die sich auf die speziellen Besonderheiten der Fertigungstechnik und der Prozessindustrie fokussieren. Diese Ansätze werden in den folgenden beiden Abschnitten dargestellt.

2.2 Engineering in der Fertigungstechnik In diesem Abschnitt werden die Engineering-Ansätze betrachtet, welche die Fertigungstechnik und deren Besonderheiten im Fokus haben. Der wesentliche Unterschied der Fertigungstechnik im Vergleich mit der Prozessindustrie liegt in der Art der Herstellung der Produkte. In der Fertigungstechnik werden diskrete Stückgüter gefertigt, deren Produktionsablauf sich leichter unterbrechen lässt als bei der kontinuierlichen Fertigung der Produkte in der Prozessindustrie. Eine weitere wesentliche Besonderheit der Fertigungstechnik im Vergleich zur Produktion in der Prozessindustrie sind kurze Produktlebenszyklen und eine große Produktvarianz [SGK08]. In Folge dessen werden fertigungstechnische Produktionssysteme zunehmend wandlungsfähiger und in der Regel modularer im Aufbau [NHR+08]. Die Nutzungsdauer einer konkreten Konfiguration einer diskreten Fertigungsanlage variiert abhängig von der Branche und vom Geschäftsmodell zwischen Tagen bis hin zu Jahren [BMQ+10].

2.2.1 VDI-Richtlinie 2206 – Entwicklungsmethodik für mechatronische Systeme Die [VDI 2206] fokussiert auf die Unterstützung des domänenübergreifenden Entwickelns mechatronischer Systeme. Der Schwerpunkt wird auf den Systementwurf gelegt, der durch den Entwickler mit Hilfe von Vorgehensweise, Methode und Werkzeugen aus dieser Norm effektiver durchgeführt werden kann. Um ein mechatronisches System strukturiert zu entwerfen schlägt die [VDI 2206] das V- Modell als Methode vor. Das in Abbildung 2-11 dargestellte Vorgehen kann als Makrozyklus mehrfach durchlaufen werden, wobei die Ergebnisse immer weiter verfeinert werden.

Abbildung 2-11: Das V-Modell als Vorgehensmethode der [VDI 2206] Mit der Aufnahme der Anforderungen, die das spätere Produkt erfüllen soll, beginnt der Systementwurf. Ein komplexes mechatronisches Erzeugnis entsteht in der Regel nicht innerhalb eines Makrozyklus. Vielmehr sind mehrere Durchläufe erforderlich [VDI 2206]. 2 Ablauf des Engineerings automatisierter Systeme 14

Die Phase des Systementwurfes ist wesentlich durch die funktionale Betrachtung des Systems und dessen Zerlegung in Teilfunktionen geprägt. Im sich anschließenden domänenspezifischen Entwurf wird auf dem funktionalen Modell aufgebaut, das im Systementwurf erstellt wurde. Die einzelnen Gewerke (Maschinenbau, Elektrotechnik und Informationstechnik) entwickeln hier konkrete Lösungen für die Umsetzung der Funktionen. Durch die Gewerke werden dabei weitere Modelle erzeugt. In der Systemintegration werden die Ergebnisse zusammengeführt und ergeben somit ein Produkt. Durch die Eigenschaftsabsicherung als letzte Phase des Makrozyklus wird sichergestellt, dass die entworfenen Lösungen die gestellten Anforderungen erfüllen. Daraus lässt sich ableiten, dass ein funktionales Modell zur Abbildung der Anforderungen genutzt werden kann. Ein solches Modell, welches das System mittels Fluss-Beziehungen modelliert, unterstützt das lösungsneutrale Entwickeln eines Systems und dient am Ende zum Abgleich der Eigenschaften des Produktes mit den ursprünglichen Anforderungen.

2.2.2 VDI-Richtlinie 2223 – Methodisches Entwerfen technischer Produkte Die [VDI 2223] bezieht sich auf den Entwurf technischer Produkte und kann zudem als Leitfaden für das Engineering von Produktionssystemen verstanden werden, indem sie dazu beiträgt, dass der Entwurfsprozess als methodisch durchzuführender Arbeitsprozess begriffen wird [VDI 2223]. Es werden geeignete Methoden, Arbeitsmittel und Instrumente vorgestellt, die sich an der [VDI 2221] orientieren, welche die Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte beschreibt, siehe Abbildung 2-12.

Abbildung 2-12: Generelles Vorgehen des methodischen Entwickelns und Konstruierens [VDI 2221] Daraus lassen sich zusammengefasst folgende Forderungen an das Engineering von fertigungstechnischen Produktionssystemen ableiten, vgl. [VDI 2223, S. 4]: • Eine funktionale Denkweise wird gefordert; • Das Finden von Lösungen und prinzipiellen Lösungen folgt erst nach der funktionalen Modellierung, um einen größtmöglichen Lösungsraum offen zu halten; 2 Ablauf des Engineerings automatisierter Systeme 15

• Eine Modularisierung des Produktionssystems sollte vorgenommen werden; • Gefundene und getestete Lösungen sollten wiederverwendet werden.

2.2.3 Drath – Datenkonsistenz im Umfeld heterogener Engineering-Werkzeuge In [DSH11] werden die Hauptphasen des Engineerings in der Fertigungstechnik aufgezeigt. Im Detail wird die Phase „Construction/Manufacturing“ erläutert, deren Hauptteil durch das funktionale Engineering bestimmt wird, siehe Abbildung 2-13.

Abbildung 2-13: Workflow des Engineerings in der Fertigungstechnik Die Abbildung 2-13 zeigt eine deutliche Separierung des Engineering-Workflows in die Tätigkeiten der unterschiedlichen Gewerke, vor allem dem mechanischen, dem elektrischen und dem automatisierungstechnischen Engineering. Auf die Führungsrolle des mechanischen Engineerings, das Input für die anderen Gewerke produziert, sei besonders hingewiesen. Auf die unterschiedlichen, am Engineering beteiligten Gewerke wird in Kapitel 3 der vorliegenden Arbeit detaillierter eingegangen.

2.2.4 Anis – CP³L: A Cyber-Physical Production Planning Language Aus [ASP+15] lassen sich Anforderungen für die Planung von Produktionssystemen ableiten. Im Detail sind Anforderungen an die Beschreibungsmittel von cyber-physischen Produktionssystemen (CPPS) aufzuführen: • Abbildung von Zeit und Dauer von Produktionsprozessen, • Möglichkeit der Darstellung parallel ablaufender Produktionsprozesse, • Modellierung von Ausschlussbedingungen (zum Beispiel Verriegelungen), • Nutzbarkeit durch Engineering-Software, • verteilte Planung durch unterschiedliche Gewerke. Diese Anforderungen geben einen Hinweis auf die notwendigen Modelle, die im Laufe des Engineerings eines Produktionssystems von unterschiedlichen Beteiligten erzeugt und ausgetauscht werden müssen. Im Einzelnen sind hier detaillierte Prozessbeschreibungen (mit Zeitverhalten, sequentiellen und parallelen Prozessschritten) und Abbildung von Logik (im Sinne von Ausschlussbedingungen) zu nennen, die von unterschiedlichen Gewerken bearbeitet werden. 2 Ablauf des Engineerings automatisierter Systeme 16

2.2.5 Zusammenfassung Die fertigungstechnischen Engineering-Ansätze der [VDI 2206] und der [VDI 2223] lassen sich in die herausgearbeiteten Kernphasen des Engineerings aus Abschnitt 2.1.12 einordnen. Die [VDI 2223] legt dabei einen starken Fokus auf die Funktion (im Sinne einer prinzipiellen Lösung), auf die Modularisierung und auf die Wiederverwendung bereits gefundener Lösungen. Daher wird im Laufe der vorliegenden Arbeit untersucht, welche Ansätze einen mechatronischen (vorgestellt durch [DSH11]) oder funktionsorientierten Ansatz verfolgen, wie sich die Modularisierung und die Verwendung von Bibliotheken in diese Ansätze integrieren lassen. In [ASP+15] wird auf die benötigten Modelle im Engineering hingewiesen, auf die bei der folgenden Untersuchung der unterschiedlichen mechatronischen und funktionsorientierten Engineering-Ansätze besonders geachtet wird.

2.3 Engineering in der Prozessindustrie Im Gegensatz zu fertigungstechnischen Produktionssystemen sind verfahrenstechnische Produktionssysteme meist für einen Betrieb über Jahre bis Jahrzehnte ausgelegt [POEP94]. Dabei treten Änderungen selten als Umbaumaßnahmen existierender Produktionssysteme auf, sondern häufig als Ergänzungen durch parallele oder sequentielle neue Produktionsanlagen, um beispielsweise den Durchsatz zu verbessern oder weiterverarbeitete Produkte zu produzieren [BMQ+10]. Auch das Engineering von verfahrenstechnischen Produktionssystemen sieht sich aktuell und in der nahen Zukunft großen Herausforderungen gegenüber. Die Schwierigkeit besteht hierbei vor allem in der massiven Zunahme der Anzahl der eingesetzten Geräte (Sensoren und Aktoren) unterschiedlicher Hersteller inklusive ihrer Informationsverarbeitung und Energieversorgung, der individuellen Geräteparameter und der daraus resultierenden Menge an Informationen. Diese Geräte müssen verknüpft und im Leitsystem des Produktionssystems nutzbar gemacht werden, mit dem Ziel, die gewünschten Automatisierungsfunktionen zu realisieren [WDH14]. Während es in der diskreten Fertigung kein einheitliches Vorgehen zur Beschreibung von Strukturen eines Produktionssystems gibt, wird in der Prozesstechnik die [DIN EN 62424] als standardisierte und formalisierte Beschreibung genutzt [BMQ+10]. Darin wird unter anderem das Rohrleitungs- und Instrumentenfließschema (R&I-Fließschema) als ein zentrales Planungsdokument beschrieben. Doch auch diese Planungsgrundlage kann nicht uneingeschränkt verwendet werden. Wie in [SSE08] gezeigt wird, beschreibt das R&I-Fließschema zwar eine grafische Abbildung von Produktionssystemen und lässt sich mittels rechnerinterpretierbarer Repräsentation der darin enthaltenen Daten maschinell auswerten, jedoch sind viele, für Menschen implizit vorhandene Informationen nicht explizit formuliert und damit informationstechnisch nicht zugreifbar [BMQ+10]. Die [DIN EN 62424] versucht dieser Herausforderung zu begegnen, indem sie beim Engineering eine intelligente, maschinelle Unterstützung bietet. Hier zeigen sich die Unterschiede zur Fertigungstechnik, vor allem in den zu erstellenden Planungsdokumenten. Das R&I-Fließschema ist eine wichtige Planungsgrundlage im Engineering der Prozessindustrie, denn es enthält die grafische Repräsentation der Funktionen, die in dem Produktionssystem geplant sind. Ein Äquivalent mit einer ähnlich hohen Informationsdichte gibt es in der Fertigungstechnik nicht. Die verschiedenen Fließschemata der [DIN EN ISO 10628-1] (Grundfließschema, Verfahrensfließschema und R&I-Fließschema) dienen dem Informationsaustausch zwischen den an der Entwicklung, 2 Ablauf des Engineerings automatisierter Systeme 17 dem Bau, der Montage, dem Betrieb und der Wartung derartiger verfahrenstechnischer Produktionssysteme beteiligten Gewerken. Im folgenden Abschnitt wird auf einige wichtige Standards eingegangen, die das Engineering verfahrenstechnischer Produktionssysteme wesentlich beeinflussen. Es wird daraus abgeleitet, welche Phasen im Engineering eines verfahrenstechnischen Produktionssystems entscheidend sind und welche Planungsdokumente darin erstellt werden.

2.3.1 PAS 1059 – Planung einer verfahrenstechnischen Anlage Die [PAS 1059] geht detailliert auf die Planungsphasen innerhalb der Abwicklungsphase beim Bau eines Produktionssystems ein. Sie fokussiert dabei auf die Abbildung der einzelnen Teiltätigkeiten sowie der daraus resultierenden Ergebnisse innerhalb der genannten Engineering-Phasen. Diese Phasen sind in Abbildung 2-14 dargestellt.

Abbildung 2-14: Engineering-Phasen nach [PAS 1059] Die Anforderungsdefinition findet in der Phase Grundlagenermittlung statt, in der aus einer detaillierten Produktbeschreibung ein Verfahrenskonzept angefertigt wird. Dazu wird das Grundfließschema genutzt, das die einzelnen geplanten Prozesse in Form von Blöcken darstellt. In der Vorplanung wird das Grundfließschema erweitert. Das R&I-Fließschema wird in der Phase Entwurfsplanung erstellt und dient den Gewerken der Prozessleittechnik (PLT) und den Elektrotechnikern als Planungsgrundlage.

2.3.2 NAMUR-Arbeitsblatt 35 – Abwicklung von PLT-Projekten Das [NA 35] gliedert das Engineering eines Produktionssystems in unterschiedliche Phasen, die im Wesentlichen den Phasen der [VDI/VDE 3695-1] und der [VDI 5200-1] entsprechen. Zudem werden das Ziel jeder dieser Phasen benannt und die Einzeltätigkeiten den jeweiligen Engineering-Phasen zugeordnet, siehe dazu Abbildung 2-15.

Abbildung 2-15: Standardprojektstrukturplan der [NA 35] Der Fokus des [NA 35] liegt hier auf der Durchführung von PLT-Projekten, die nur eine Teilmenge der auszuführenden Tätigkeiten beinhaltet, die während der Errichtung eines verfahrenstechnischen Produktionssystems durchzuführen sind. Es deckt sich dabei mit den entsprechenden Tätigkeiten aus den Engineering-Phasen, wie sie in der [PAS 1059] beschrieben sind. 2 Ablauf des Engineerings automatisierter Systeme 18

2.3.3 Zusammenfassung Die Ansätze des Engineerings verfahrenstechnischer Produktionssysteme unterscheiden sich kaum von den allgemeinen Engineering-Ansätzen, wie sie in Abschnitt 2.1 dargestellt sind. Auch beim verfahrenstechnischen Engineering werden zuerst Anforderungen aufgenommen, die durch die verfahrenstechnischen Produktionssysteme erfüllt werden müssen. Einen Unterschied stellt die Funktionsorientierung durch die Verwendung der PLT- Stelle im R&I-Fließschema dar. Die PLT-Stelle beschreibt die prozessleittechnische Funktion, welche an einer definierten Stelle in dem Produktionssystem ausgeführt werden soll. Diese Funktion wird zunächst hersteller- und geräteneutral geplant (beispielweise: „Messen eines Durchflusses“). Erst in einer späteren Phase wird für diese Funktion das passende Gerät ausgewählt. Somit wird der Lösungsraum bei der Suche nach der passenden Realisierung der Funktion so lang wie möglich offen gehalten. Dies kann hilfreich sein, um beispielsweise möglichst viele Informationen über die Umgebungsbedingungen am Einbauort des Gerätes in Erfahrung zu bringen, die zu einem früheren Zeitpunkt im Engineering noch nicht zur Verfügung standen. Diese Orientierung an der Funktion als Planungsgegenstand wird im Weiteren in der vorliegenden Arbeit detaillierter betrachtet. Dabei spielen Normungsbestrebungen für den rechnerinterpretierbaren Austausch der PLT-Stelle im verfahrenstechnischen Engineering eine wichtige Rolle, da sie Anregungen für den vorliegenden Ansatz liefern können.

2.4 Parallelisierung des Engineerings Die beschriebenen sequentiellen Abläufe in den unterschiedlichen betrachteten Engineering- Abläufen sind jeder für sich schwierig weiter zu optimieren, da die meisten Verluste an den Übergängen zwischen den einzelnen Gewerken entstehen. „Die Sachbearbeiter in den Abteilungen sind demotiviert, haben den Sinn für das Ganze verloren.“ beschreibt [EHR07] kritisch ein Kernproblem in großen Engineering-Projekten. Durch dieses Verhalten entstehen „Mauern“, die den Datenfluss behindern. „[…] dieses Mauerndenken (ist) die Hauptursache für Zeit-, Qualitäts- und Kostenprobleme in unseren Unternehmen […]“ [EHR07, S. 186]. Die folgende Abbildung 2-16 verdeutlicht das Problem des Mauerdenkens bei sequentiellen Engineering-Prozessen.

Abbildung 2-16: Darstellung des Mauerdenkens im Engineering-Prozess nach [EHR07, S. 186] Dem entgegen steht ein integrierter Ansatz, aus dem das Concurrent Engineering oder auch Simultaneous Engineering hervor gegangen ist. „Bei der integrierten Produkterstellung arbeiten, im Gegensatz zu der konventionellen Produkterstellung, alle am Erstellungsprozess beteiligten Abteilungen und die betroffenen Spezialisten eng abgestimmt und unmittelbar zusammen. Dabei wird versucht, durch eine gemeinsame Zielrichtung Qualität, Zeiten und 2 Ablauf des Engineerings automatisierter Systeme 19

Kosten der Produkterstellung und des Produktes positiv zu beeinflussen. Zur Zeiteinsparung wird zusätzlich eine Parallelisierung von früher sequentiell bearbeiteten Tätigkeiten angestrebt, insbesondere die Parallelisierung von Produkt-, Produktions- und Vertriebsentwicklung […].“ [EHR07, S. 189] „Die Grundidee des Simultaneous Engineering ist, dass vormals streng sequentiell durchgeführte Ablaufe zeitlich parallel bzw. überlappt durchgeführt werden. Dies erfordert teamorientierte und bereichsübergreifende Arbeitsweisen, die durch einen intensiven Austausch von Informationen gekennzeichnet sind. Durch die Zusammenarbeit bereits in der Konzeptphase der Produktentstehung erfolgt der frühzeitige Abgleich von marktseitigen Zielen und Lösungskonzepten im Hinblick auf Produkt und Produktionsmittel.“ [EVE12, S. 2] Auch die [VDI 4499-1] hat zum Ziel, durch Verkürzen und Parallelisieren der in Abschnitt 2.1.2 aufgezeigten Planungsphasen das zu produzierende Produkt früher in den Markt zu bringen, siehe Abbildung 2-17.

Abbildung 2-17: Verkürzen der Planungsphasen [VDI 4499-1] Diese Verkürzung der „time to market“ ist durch die gemeinsame Verwendung von Daten, Modellen und Werkzeugen von den am Planungsprozess beteiligten Gewerken zu erreichen. Ein weiterer wesentlicher Erfolgsfaktor für die Parallelisierung der Abläufe ist die Digitalisierung der Schnittstellen zwischen den Gewerken. Unterschiedliche Software- Hersteller bieten hierfür bereits Teillösungen an, allerdings ist die Idee eines durchgängigen digitalen Workflows noch immer nicht wirtschaftlich in die Realität umgesetzt worden [HÄDR14].

2.5 Folgerungen aus den Ansätzen des Engineerings Bisher werden diskrete Fertigung und die Produktion in der Prozessindustrie wissenschaftlich weitestgehend getrennt voneinander betrachtet. Die Forschungsschwerpunkte innerhalb der beiden Disziplinen sind durch die jeweiligen, spezifischen Anforderungen getrieben. Als Gemeinsamkeit steht in der Regel die Wirtschaftlichkeit der Produktionssysteme unter verschiedenen Gesichtspunkten im Fokus [BMQ+10].

2 Ablauf des Engineerings automatisierter Systeme 20

Auch wenn sich Fertigungstechnik und Prozessindustrie in ihren technischen Lösungen unterscheiden, werden doch fachübergreifend folgende Gemeinsamkeiten im Engineering deutlich [DRA08]: • starke Phasenausprägung, • starke Toolunterstützung innerhalb der Phasen, • wachsender Engineering-Anteil bei zunehmender Zahl von Sublieferanten, • fehlende Datenaustauschlösungen zwischen den Phasen. Eine weitere Gemeinsamkeit im Engineering beider Disziplinen besteht in der Nutzung von Modellen. Diese unterstützen in beiden Fällen sowohl das Engineering als auch den Betrieb des Produktionssystems. Auf Grund der unterschiedlichen Anforderungen zum Beispiel an die Rekonfigurierbarkeit der Produktionssysteme und der unterschiedlichen Entwicklungs- und Produktionsprozesse haben sich aber unterschiedliche Modelle zur Beschreibung von Produktionssystemen etabliert [BMQ+10]. Diese Modelle werden in Werkzeugen zum Engineering, in Visualisierungs-, Steuerungs- und Simulationssystemen während des Betriebs und zur Qualitätssicherung eingesetzt [BMQ+10]. Forschungsfrage 1 lässt sich an dieser Stelle beantworten:

1. In welche Phasen ist das typische fertigungstechnische Engineering zur Errichtung von mechatronischen Produktionssystemen gegliedert und wie lassen sich diese Phasen ggf. parallelisieren?

Zusammenfassend ergeben sich somit folgende Erkenntnisse aus der Untersuchung der unterschiedlichen allgemeinen Engineering-Vorgehensmodelle und aus den speziellen Vorgehensmodellen der beiden Disziplinen: • Der Engineering-Prozess lässt sich in verschiedene Phasen einteilen, dabei spielen insbesondere die Definition der Anforderungen, die Planung in unterschiedlichen Gewerken und die Errichtung/Betrieb des Produktionssystems eine zentrale Rolle; • Jede Phase des Engineerings erzeugt unterschiedliche Planungsergebnisse; • Jede Phase des Engineerings wird von unterschiedlichen Beteiligten durchgeführt, die aus unterschiedlichen Gewerken entstammen; • Jeder Beteiligte am Engineering benutzt unterschiedliche Methoden, Modelle und Software-Werkzeuge zur Erstellung der Planungsergebnisse; • Im verfahrenstechnischen Engineering gibt es das R&I-Fließschema als zentrale, gemeinsame Planungsgrundlage. Im fertigungstechnischen Engineering gibt es dafür eine Vielzahl unterschiedlicher Lösungen [BMQ+10]; • Gemeinsam ist beiden Engineering-Prozessen, dass Modelle verwendet werden, um sowohl das Engineering als auch den Betrieb des Produktionssystems zu unterstützen [BMQ+10]; • Der Grundgedanke des Engineerings basiert auf den Funktionen, die noch vor den Geräten geplant werden, • Eine Parallelisierung der Phasen kann nur durch eine gemeinsame Verwendung der Daten, Modelle und Werkzeuge durch die beteiligten Gewerke geschehen. Ausgehend von den bereits genannten Einflussfaktoren für die Optimierung des Engineerings liefert der vorliegende Abschnitt Klarheit über die Komplexität des Workflows sowie über die darin enthaltenen Workflow-Schritte. Offen hingegen bleiben die verwendeten Prozessmodelle und Erkenntnisse über die beteiligten Personen und Werkzeuge, sowie ihre 2 Ablauf des Engineerings automatisierter Systeme 21

Schnittstellen. Diese Schnittstellen werden umso wichtiger, wenn die Prozesse im Engineering parallel ablaufen, da hierbei eine größere Anzahl an Iterationsschritten im Planungsprozess und damit ein intensiverer Datenaustausch notwendig wird. Folglich müssen zunächst die unterschiedlichen beteiligten Akteure im Engineering näher betrachtet werden, um deren Einfluss auf den Ablauf und die Qualität des Engineerings bewerten zu können. Daher wird im folgenden Kapitel detailliert auf die Gewerke eingegangen, die typischerweise bei der Planung eines fertigungstechnischen Produktionssystems beteiligt sind, sowie die Informationen, die zwischen den Beteiligten ausgetauscht werden. Im darauf folgenden Kapitel werden dann unterschiedliche Ansätze des funktionalen Engineerings untersucht, um die darin verwendeten Methoden und Modelle detailliert zu analysieren.

3 Informationsaustausch im Engineering 22

3 Informationsaustausch im Engineering Abgeleitet aus der detaillierten Analyse existierender Engineering-Ansätze des vorangegangenen Kapitels werden die Chancen und Risiken des daraus resultierenden Informationsaustausches dargestellt. Dazu wird das multidisziplinäre Vorgehen im Engineering erläutert und auf die Herausforderungen eingegangen, die sich daraus ergeben. Auf dieser Basis werden die zurzeit gängigen Standards und Konzepte für den Informationsaustausch erläutert und untersucht, welche Vor- und Nachteile sich durch die Standardisierung des Informationsaustausches ergeben. Dabei werden aktuelle Forschungsthemen und Gremienarbeiten vorgestellt.

3.1 Die beteiligten Gewerke im fertigungstechnischen Engineering „Das Engineering im fertigungstechnischen Maschinen- und Anlagenbau beinhaltet die Entwicklung und die Erstellung von Dokumenten durch Personen verschiedenster Domänen bzw. Disziplinen, d. h. Disziplin-/Gewerke-übergreifendes Engineering.“ [FFV13] Das reibungslose Zusammenwirken dieser Gewerke ist Voraussetzung dafür, dass Fehler in der Planung frühzeitig erkannt werden und das Produktionssystem termingerecht fertig gestellt wird [VDI/VDE 3695-1, S. 5]. Bei der Betrachtung der Gewerke, die an der Planung und Realisierung eines fertigungstechnischen Produktionssystems beteiligt sind, wird meist die folgende klassische Einteilung gemäß [VDI 2206, S. 22] vorgenommen: • Maschinenbau, • Elektrotechnik und • Informationstechnik. In manchen Engineering-Organisationen werden die mechanische und die elektrische Planung zusammengelegt und in einem „mechatronischen“ Gewerk gemeinsam ausgeführt. Dabei wird meist innerhalb des „mechatronischen“ Gewerkes erst die mechanische und im Anschluss die elektrische Planung durchgeführt, da der Maschinenbau als führendes Gewerk die Wissensdomäne dominiert [VDI 2206, S. 22]. Erst im Anschluss werden die Planungen der Informationstechnik ausgeführt, die als drittes Gewerk an der Erstellung eines mechatronischen Systems beteiligt ist. Werden pneumatische oder hydraulische Elemente in das System verbaut und gibt es in der Engineering-Organisation kein eigenes Gewerk dafür, so gliedert sich deren Planung häufig in den Verantwortungsbereich der Elektrotechnik, da für die Planung fluider Systeme ähnliche Regeln und Systematiken gelten wie in der Elektrotechnik. Die klassische Einteilung der Gewerke ist in Abbildung 3-1 dargestellt. An Hand deren gemeinsamer Schnittstellen werden gemeinsame Informationen der Gewerke erkennbar, die für das Gewerke-übergreifende Engineering eine entscheidende Rolle spielen. Diese Informationen werden im Folgenden näher betrachtet. 3 Informationsaustausch im Engineering 23

Abbildung 3-1: Darstellung der Gewerke nach [VDI 2206] Ziel der Gewerke-übergreifenden Planung ist mehr als das reine Zusammenfügen mechanischer, elektronischer und softwaretechnischer Komponenten, sondern „dass diese funktionell und technologisch in wohl definierter Weise zusammen wirken müssen“ [JAN10] und alle Elemente der geschlossenen Wirkkette aufeinander abgestimmt sind [HEL13]. Um diese Gewerke-übergreifende Planung zu verbessern, bestehen Bestrebungen, zum einen die existenten Engineering-Werkzeuge miteinander zu verknüpfen, zum anderen wird versucht, eine integrierte, disziplinübergreifende Modellierung zu realisieren [FFV13]. Im Folgenden werden die Informationen näher untersucht, die zwischen den Gewerken im Laufe des Planungsprozesses ausgetauscht werden, um abzuleiten, was bei einer disziplinübergreifenden Modellierung beachtet werden muss.

3.2 Verwendete und ausgetauschte Informationen im Engineering “The exchange of data between and within enterprises, between engineering tools and between departments can only run smoothly when both the information to be exchanged and the use of this information have been clearly defined.” [IEC 63832] Schon bei der sequentiellen Planung eines Systems müssen im Laufe des Planungsprozesses zahlreiche Informationen zwischen den Gewerken ausgetauscht werden. Vor allem durch die Parallelisierung der Planungsschritte müssen diese Informationen noch häufiger zwischen den Gewerken ausgetauscht werden, da hierbei eine modulare Betrachtung des Produktionssystems vorherrschend ist. Betrachtet man die Grenzen der Interessenbereiche der Gewerke und die Schnittmengen mit den anderen Gewerken, so kann man auf folgende Informationen schließen, die untereinander ausgetauscht werden: Zwischen den Gewerken Maschinenbau und Elektrotechnik wird im einfachsten Fall eine Stückliste elektronisch relevanter Bauteile ausgetauscht. Diese enthält im optimalen Fall Betriebsmittelkennzeichen, um eine Zuordnung der Komponenten in der Gewerke- übergreifenden Planung zu gewährleisten [HWH14]. Diese Bauteile werden in einem Elektro- CAD-Programm elektrisch und informationstechnisch miteinander verbunden. Gegebenenfalls werden durch den Elektroplaner Steuerungskomponenten ausgewählt und in der Stückliste ergänzt. Aus dem Gewerk der Elektrotechnik werden die Signale von Sensoren und Aktoren als Signalliste oder auch als Adressliste der Steuerung an die Informationstechnik übergeben [HWH14]. Daraus und aus einer detaillierten Ablaufbeschreibung, die vom Maschinenbau als führendes Gewerk entworfen wird, erstellt die Informationstechnik das Steuerungsprogramm 3 Informationsaustausch im Engineering 24 für das Produktionssystem. Zusammengefasst lassen sich die Informationen, die zwischen den beteiligten Gewerken ausgetauscht werden in Anlehnung an die Abbildung 3-1 in der folgenden Abbildung 3-2 darstellen.

Abbildung 3-2: Das 3-Kreise-Modell der Gewerke mit den Informationen an den Schnittstellen Nach der Betrachtung der Informationen, die an den Schnittstellen der Gewerke ausgetauscht werden, erfolgt eine kurze Betrachtung der benutzten Werkzeuge in den einzelnen Phasen des Engineerings und von den unterschiedlichen Gewerken. Die verwendeten Werkzeuge und deren Kompatibilität haben einen wesentlichen Einfluss auf den Informationsaustausch zwischen den Gewerken. Jede Phase des Engineerings hat ihre eigenen Werkzeuge und Modelle, wie in [SLS+14] detailliert gezeigt wird. In Abbildung 3-3 sind die für die Phase des funktionalen Engineerings häufig verwendeten Software-Werkzeuge unterschiedlicher Hersteller ohne bestimmte Systematik aufgeführt, um deren Vielfältigkeit zu verdeutlichen.

Abbildung 3-3: Werkzeuge der Phase des Funktionalen Engineerings nach [SLS+14] An dieser Stelle wird wieder ein Blick in die Domäne der Prozessindustrie geworfen. [AHSP09] gibt einen Überblick über die in den verschiedenen Phasen des verfahrenstechnischen Engineerings eingesetzte Software. In Tabelle 3-1 ist ein Auszug daraus aufgelistet. 3 Informationsaustausch im Engineering 25

Tabelle 3-1: Verwendete Software in den unterschiedlichen Phasen des verfahrenstechnischen Engineerings

Phase Software/Hersteller Verfahrensauslegung: Magma5 der Fa. Magma Fließbilderstellung: MicroStation der Fa. Bentley Aufstellungsplanung: Plant Builder/Autorouter der Fa. Design Power Vontage der Fa. Aveva L/ISO der Fy. LOGOS PLT-Engineering: PLANEDS der Fa. CIMWare COMOS/PT der Fa. Siemens PRODOK der Fa. Rösberg Engineering ELCAD der Fa. Aucotec WSCAD-P1 der Fa. WSCAD Software-Planung: CoDeSys der Fa. 3S-Smart Software Solution SFC, CFC, S7-Micro, S7-Graph der Fa. Siemens Leitsystem-Erstellung: 800xA der Fa. ABB PCS 7 der Fa. Siemens Control Drawing Builder der Fa. Yokogawa

Sowohl für das Engineering in der Prozessindustrie als auch in der Fertigungstechnik @ existiert eine Vielfalt an Werkzeugen unterschiedlicher Hersteller. In [GRÖ13 ] wird aufgezeigt, dass durch die Vielfalt an Software und deren häufig vorhandene Inkompatibilität ein Defizit im Engineering entsteht, das durch die folgenden Punkte charakterisiert wird: • Eine große Vielfalt an Software-Werkzeugen ist in den verschiedenen Fachbereichen vorhanden; • Die Auswahl am besten geeigneter Werkzeuge für den Fachbereich ist: o „historisch“ bedingt, o Getrieben durch die Kundenwünsche nach bestimmten Steuerungen, für die spezifische Programmierwerkzeuge benötigt werden; • Die verwendeten Werkzeuge sind nicht für eine übergreifende Zusammenarbeit entworfen; • Gemeinsame Konzepte auf Projektebene werden in Werkzeugen unterschiedlich repräsentiert; • Fehlender durchgängiger Standard, um Bauteile/Geräte Gewerke-übergreifend in allen Engineering-Werkzeugen zu identifizieren; • Fehlende Lösungsansätze eines Informationsaustausches zwischen den verwendeten Werkzeugen für die überwiegend klein- und mittelständisch geprägte Maschinenbau- Branche. In [ABH+10] wird dargestellt, dass die erzeugten Planungsdokumente der unterschiedlichen Gewerke auf Grund der hohen Komplexität und des hohen Detaillierungsgrads von den anderen Disziplinen nur bedingt lesbar sind. Aus diesem Grund werden als Übergabedokumente in der Regel einfache Listen verwendet (Sensor-/Aktorliste, Signalliste), die in der anschließenden Entwicklungsphase nicht optimal genutzt werden können, da sie manuell in andere Systeme übertragen werden müssen [ABH+10, S. 50]. Somit entsteht der überwiegende Anteil der Ingenieursleistung in Tabellenkalkulationssoftware (wie beispielsweise in Excel). „Das bedeutet dementsprechend auch, dass das Wissen einzelner Personen an eine Excelliste gebunden ist.“ [GEI13]

Dass die bloße Weitergabe von Listen nicht immer ausreichend ist, wird in [ULR09] gezeigt. „Die Speicherung und Weitergabe von Daten ist jedoch nicht ausreichend, um ein allgemeines Prozessverständnis über alle Fachdisziplinen hinweg zu ermöglichen.“ In @ [MEI13 ] wird gezeigt, dass der deutsche Maschinenbau größte Schwierigkeiten bei der Übergabe von Daten und Informationen zwischen den verschiedenen Gewerken hat. Viele 3 Informationsaustausch im Engineering 26 bisherige Lösungen sind teuer oder erfordern große Umstellungen in den Unternehmen. Dies ist für mittelständische Maschinenbauer kaum zu schaffen und das Risiko ist für sie damit zu @ hoch. Wie in [MEI13 ] weiterhin festgestellt wird, ist besonders der Informationsaustausch mit dem mechanischen Konstruktionssystem in der Breite des Maschinenbaus quasi nicht vorhanden.

In [HÄDR14] wird angeführt, dass für die Integration aller benötigten Daten und Informationen im Planungsprozess ein monolithisches Gesamtwerkzeug naheliegend wäre. Dies scheitert jedoch an einer Vielzahl von Hürden, wie der hohen Komplexität solcher Werkzeuge, der kostenintensiven Einführung in das Unternehmen, der großen Herstellervielfalt, dem hohen erforderlichen Ausbildungsgrad der Mitarbeiter, dem hohen Wartungsaufwand sowie einer eventuell notwendigen Änderung des Engineering-Workflows. Die alten Werkzeuge müssten durch das neue Werkzeug ersetzt werden, und mit ihnen gingen die historische Expertise, Bibliotheken, Musterlösungen und Experten verloren. Zudem erfolgt eine derartige Einführung typischerweise parallel zum laufenden Projektgeschäft. Dies würde den gesamten Workflow im Unternehmen verändern und führt daher aus ganz praktischen Erwägungen zu menschlichen Widerständen [HÄDR14]. Es ist festzustellen, dass, obwohl es von Firmen und Organisationen seit Jahren Anstrengungen und teilweise proprietäre @ Lösungen gibt, diese in der Fläche noch nicht angekommen sind [MEI13 ].

Doch weist [HÄDR14] auch auf einen anderen Ansatz hin, der erfolgversprechender erscheint, vor allem für kleine und mittelständige Unternehmen. Dieser Ansatz akzeptiert die heterogene Werkzeuglandschaft, belässt die Werkzeuge, Bibliotheken, Experten und gereiften Lösungen wie sie sind und verfolgt stattdessen den gezielten Informationsaustausch zwischen diesen. Genau zu diesem Zweck initiierte Daimler 2006 die Entwicklung des Datenformats AutomationML [HÄDR14], auf das in Abschnitt 3.3.6 näher eingegangen wird. Aus den aufgezeigten Herausforderungen und Lösungsvorschlägen lässt sich erkennen, dass zum einen ein abgestimmtes Datenmanagement innerhalb eines Unternehmens vorhanden sein und andererseits möglichst auf genormte Datenaustauschformate oder Vorschriften zurückgegriffen werden sollte, um den Informationsaustausch auch nach außen hin effizient zu gestalten. Daher wird im folgenden Abschnitt auf die gängigsten Normen und Normungsvorhaben in diesem Themenbereich eingegangen.

3.3 Normen und Standards zur Optimierung des Engineerings Im vorliegenden Abschnitt wird auf Normen und Standards eingegangen, die zur Optimierung des Engineerings beitragen. Daraus werden nutzbare Konzepte abgeleitet, welche für die vorliegende Arbeit verwendet werden. Die Autoren von [LMF15] sehen in den verfügbaren Standards im Engineering die Bausteine, die sicher wiederholbare Prozesse und die Kombination unterschiedlicher technologischer Lösungen bereitstellen, um ein optimales Ergebnis zu erreichen. Die [VDI 4499-1] hat unter anderem das Ziel, den Planungsprozess von Fertigungsanlagen zu standardisieren und damit die Wiederverwendbarkeit von Planungsergebnissen zu erhöhen. Damit verbunden sind folgende Teilziele: • Aufarbeitung und Wiederverwendung von Best-Practice Lösungen in Bezug auf Modelle und Ergebnisse, • Verwendung von Best-Practice Lösungen als verbindlicher Standard für zukünftige Planungen, 3 Informationsaustausch im Engineering 27

• Wiederverwendung von Teilmodellen der Planung im Sinn von Bausteinen der Fabrik (Wiederverwendung aus Bibliotheken). Ein damit verbundener zusätzlicher Nutzen liegt in der Archivierung von Daten, Informationen und Planungsständen, um sie unter anderem zur rechtlichen Absicherung sowie zur Dokumentation von Planungsfortschritt und Planungsergebnissen selbst nutzen zu können [VDI 4499-1, S. 13]. Doch auch diese unternehmensinterne Standardisierung muss in kleinen Schritten erfolgen. Denn [DRA13] erklärt anschaulich, dass ein Weltmodell für den Informationsaustausch nicht zu erzeugen ist, da dies zur Abstimmung unter allen Beteiligten sehr lang dauern würde. Daher ist es die effizienteste Methode, das Standardisieren in vielen kleinen Schritten zu praktizieren, um den Standard anzuwenden und im Laufe des praktischen Betriebs zu aktualisieren oder zu erweitern [DRA13].

3.3.1 Bedeutung der Standardisierung für das Engineering Unternehmen bedienen sich sowohl firmeninterner als auch allgemein gültiger Standards. Diese Standardisierung geht meist mit einer Modularisierung einher. Dies ist darin begründet, dass die Hersteller von Produktionssystemen ihren Kunden keine Einheitssysteme verkaufen wollen, die zu 100 % standardisiert sind, sondern ein auf den Kunden zugeschnittenes Produkt, das alle seine Anforderungen optimal erfüllt. Daher modularisieren die Hersteller von Produktionssystemen ihr Angebot und ihre Wertschöpfung. Sie standardisieren ihr Portfolio und ihre Prozesse intern, können dem Kunden aber durch Modularisierung individuelle Lösungen anbieten [VDMC14, S. 31]. Der Fokus der Standardisierung liegt dabei zuerst auf den internen Prozessen, bevor firmenübergreifende Aktivitäten zur Standardisierung und zur Optimierung des Informationsaustausches in Angriff genommen werden [GEI13]. Häufig findet die Standardisierung nur an einzelnen Pilotangeboten oder Prozessschritten statt. Konsequent umgesetzt entlang der gesamten Wertschöpfungskette entfaltet die Standardisierung und Modularisierung ihren vollen Kosteneffekt [VDMC14, S. 61]. Auf einige Standards und Standardisierungsvorhaben wird im folgenden Abschnitt eingegangen. Diese stellen nur eine Teilmenge aktueller Forschungs- und Gremienarbeiten dar, haben aber das Potential, eine entscheidende Rolle für die Umsetzung der Bestrebungen im Rahmen von Industrie 4.0 zu spielen [VDI15@]. Einige Inhalte werden im weiteren Verlauf der vorliegenden Arbeit zur Anwendung gebracht.

3.3.2 Merkmale und eCl@ss In den Fokus der Standardisierungsbemühungen gelangen häufig ähnliche Themengebiete, wie eine einheitliche Produkt- oder Produktionssystembeschreibung. Damit geht eine einheitliche Merkmalbeschreibung dieser Objekte einher. Für diese Forderungen der Hersteller gibt es aktuell zahlreiche Bestrebungen der Standardisierung, in denen für viele Elemente von Automatisierungssystemen Merkmalbeschreibungen erstellt werden (z.B. Merkmalleisten zur Gerätebeschreibung [DIN IEC 61987-11], das Common Data Dictionary (CDD) mit den Normen [DIN IEC 61987-11] und [DIN EN 61360-4]), und es wird an weiteren Standards und Normen für das merkmalbasierte Engineering gearbeitet (z. B. eCl@ss @ [ECL17 ] und [IEC 63832]) [HAD15, S. 2]. Auf einen dieser Standards wird exemplarisch eingegangen. eCl@ss ist ein branchenübergreifender Produktdatenstandard zur Klassifizierung und eindeutigen Beschreibung von Produkten und Dienstleistungen. Dies spielt für einen internen 3 Informationsaustausch im Engineering 28 oder firmenübergreifenden Informationsaustausch eine entscheidende Rolle, da mit der Klassifizierung eine eindeutige Beschreibung des jeweiligen Produktes gewährleistet ist. Dieser Standard kann in zahlreichen Anwendungen verwendet werden, wie zum Beispiel: Beschaffung, Controlling, Vertrieb und auch Prozessdatenmanagement und im Engineering @ [ECL17 ]. Als Beispiel sei hier das Produkt "Analoges Ein-/Ausgangs-Modul" als Teil einer Steuerung angenommen, das sich in der eCl@ss-Klassifikation mit der eindeutigen ID "27-24-22-01" beschreiben lässt, siehe Abbildung 3-4.

Abbildung 3-4: Auszug aus der eCl@ss-Klassifizierung Gruppe 27

Zudem benutzt der Standard die Merkmalleistentechnologie [BLFR15]. Damit können die kategorisierten Produkte mit Hilfe von Merkmalen beschrieben werden. eCl@ss stellt für jede Produktklassifikation eine Merkmalleiste zur Verfügung. Diese enthält eindeutige Merkmale und mögliche Ausprägungen dieser Merkmale, um das jeweilige Produkt näher zu beschreiben. Als Beispiel sei hier wieder auf das Produkt „Analoges Ein-/Ausgangs-Modul" verwiesen, das über das Merkmal: „Ausführung des elektrischen Anschlusses“ verfügt und zahlreiche Ausprägungen für dieses Merkmal zur Verfügung stellt, zum Beispiel: „Steckverbinder M12“ oder „Crimpanschluss“, siehe Abbildung 3-5. Sowohl das Merkmal als auch die Ausprägungen des Merkmals (Werte) sind mit einer eindeutigen ID versehen.

Abbildung 3-5: Werte für das Merkmal „Ausführung elektrischer Anschluss“ aus eCl@ss

3 Informationsaustausch im Engineering 29

Einige aktuelle wissenschaftliche Publikationen zeigen die Verwendungsmöglichkeiten von eCl@ss auf. So verwenden [GTS13] die Klassifikation von eCl@ss, um die Wissensinhalte ihres Ansatzes einzuordnen. [HAD15, S. 36] hingegen stellt fest, dass die Merkmalleisten- Technologie von eCl@ss nutzbar erscheint, um Elemente (wie Produkt, Prozess, Ressource, Energie, Information) der Formalisierten Prozessbeschreibung (FPB) [VDI/VDE 3682-1] näher und eindeutig zu beschreiben und sie so zu Merkmalträgern zu machen. Auf die FPB wird im folgenden Abschnitt eingegangen.

3.3.3 VDI/VDE 3682 – Formalisierte Prozessbeschreibung Die [VDI/VDE 3682-1] beschreibt die Verwendung der Formalisierten Prozessbeschreibung (FPB). Diese kann dazu eingesetzt werden, um auf einer abstrakten Ebene Prozesse und Prozessabläufe mit Hilfe einer neutralen, grafischen Darstellungsform zu beschreiben. Dabei werden Elemente verwendet, die auch schon vor Erstellung der Richtlinie zur abstrakten Beschreibung von Abläufen genutzt wurden. Das Konzept von Produkt, Prozess und Ressource (PPR) wird hier aufgegriffen und entsprechend erweitert. So erklären auch [PAT82] und [FEGR12], wie mit unterschiedlichen Flüssen ein System beschrieben werden kann. Sie verwenden dabei Stoff-, Informations- und Energiefluss und deren Änderung durch ein System. Sie verknüpfen mit diesen Flüssen ein Grundsystem mit Sensoren, Informationsverarbeitung und Aktoren [VDI 2206, S. 15]. Die Elemente der FPB werden mit ihren grafischen Entsprechungen in Abbildung 3-6 dargestellt.

Abbildung 3-6: Elemente der FPB Die grafische Komposition dieser Elemente kann Abbildung 3-7 beispielhaft entnommen werden.

Abbildung 3-7: Darstellung eines Prozesses mit den möglichen Flüssen Im Detail können mit Hilfe der Norm einzelne Prozesse eines Ablaufes durch Prozessoperatoren beschrieben werden. Diese können durch die angesprochenen Flüsse von Produkt, Energie und Information miteinander verbunden werden, um den 3 Informationsaustausch im Engineering 30 entsprechenden Ablauf und dessen Randbedingungen zu beschreiben. Jeder dieser Prozesse beschreibt eine Operation. Dies kann in verschiedenen Detailstufen erfolgen, ein Prozess lässt sich in Prozessschritte dekomponieren. Die im Prozess ausgeführte Operation hat einen Einfluss auf das Produkt, die Energie oder die Information, die in diesen Prozess hinein oder aus diesem hervor geht. Dabei kann eine Operation als eine Veränderung an einem Produkt (oder Energie/Information) definiert und somit als Funktion angesehen werden. Es tritt eine Eigenschaftsänderung des Produktes (oder Energie/Information) ein, die sich durch Attribute mit ihren Werten beschreiben lässt. Zudem können Verbindungen zwischen Produkten geändert werden, sie können dabei kombiniert oder getrennt werden. [HNO+14] Aktuelle wissenschaftliche Publikationen verwenden die FPB, um Modelle zu erzeugen. In [HADI14] wird damit ein Funktionsmodell beschrieben, das anschließend Ausgangspunkt für die Planung der Systemkomponenten und der Systemstruktur ist. Wurde nach diesem Ansatz die Systemstruktur definiert, kann mit Hilfe der FPB dargestellt werden, welche Komponente die jeweilige Funktion ausführt, indem dem Prozessoperator jeweils eine Technische Ressource zugeordnet wird. Dabei stellt ein Prozessoperator jeweils die Ausführung einer Funktion des Systems dar. Die dargestellten Eingangs- und Ausgangsgrößen (Material und Energie) beschreiben die Schnittstellen der Funktion [HADI14]. Die Information als Ein- und Ausgangsgröße findet in [HADI14] keine Verwendung, da diese erst in der Neufassung der Richtlinie im Jahr 2014 [VDI/VDE 3682-1] hinzugekommen ist. In [FAL+15] wird das Produkt-Prozess-Ressourcen-Konzept (PPR-Konzept) genutzt, das der FPB zu Grunde liegt, jedoch durch die Autoren in einer Ontologie umgesetzt. Dabei erweitert dieser Ansatz den Prozess noch um Tasks, die von dem Prozess ausgeführt werden. Dies ist vergleichbar mit den Funktionen aus [HADI14]. Zudem lassen sich in dem Konzept von [FAL+15] neben den Prozessen auch die Ressourcen dekomponieren. In [BMQ+10] werden die Nachteile der FPB dargestellt: „Die Anzahl der notwendigen Prozessschritte und der eingesetzten Fertigungsverfahren, wie etwa zur Herstellung eines Dreh/Frästeils, in Abhängigkeit von den Fähigkeiten der beteiligten Bearbeitungszentren kann variieren. Daher ist die Festlegung eines Prozesses bzw. einer Prozessfolge erst in Verbindung mit einer konkreten Produktionsanlage sinnvoll. In größeren Produktionsanlagen mit zusätzlichen, nebenläufigen um Ressourcen konkurrierenden Prozessen, wie beispielsweise flexiblen Fertigungssystemen, wird die genaue Abfolge von Prozessschritten und zugeordneten Ressourcen planerisch ggf. sogar erst zur Laufzeit bestimmt. Die in der [VDI/VDE 3682-1] beschriebene Reihenfolge ist damit erst bekannt, wenn alle parallelen Prozesse eingelastet wurden.“ [BMQ+10] Um diesen Nachteil der FPB auszugleichen wird im Verlauf vorliegender Arbeit ein Konzept vorgestellt, das die Anforderungen der Produkte von den Fertigungsprozessen und den Ressourcen entkoppelt. Damit sind auch in einem dynamischen Kontext die Beschreibung der vom Produkt geforderten Produktionsabläufe mittels FPB und eine Ressourcen- Zuweisung während der Laufzeit möglich.

3.3.4 NAMUR-Empfehlung 150 Ein Beispiel für einen entwickelten Standard, der den Informationsaustausch zwischen unterschiedlichen Engineering-Werkzeugen erleichtern soll, sind die Bemühungen um die [NE 150] und die damit verbundenen Entwicklungen aus den entsprechenden Arbeitskreisen: NAMUR-Arbeitskreis 1.10 und dem GMA-Fachausschuss 6.16. Im NAMUR-AK 1.10 wurden 3 Informationsaustausch im Engineering 31 die Inhalte erarbeitet, die zwischen einem CAE-Engineering-Werkzeug bei der Planung eines verfahrenstechnischen Produktionssystems und dem nachfolgenden PLS-Engineering- Werkzeug übertragen werden. Diese Inhalte wurden aus den bis dahin verwendeten Konfigurationslisten abgeleitet. Dazu wurden die Inhalte zahlreicher Excel-Tabellen unterschiedlicher Unternehmen ausgewertet, die Informationen kategorisiert und zusammengefasst [SCH12]. Die in der [NE 150] gesammelten Informationen wurden im GMA-FA 6.16 aufgenommen, um den Entwurf einer Datenschnittstelle zu realisieren. Die dafür notwendigen Anforderungen stammen ebenfalls aus dem NAMUR AK 1.10. Als Beispiel sei genannt, das die Schnittstelle bidirektional funktionieren und neben den genormten Informationen der NE 150 auch private Informationen der Werkzeuge übertragen können muss. Aus den Anforderungen wurde ein Informationsmodell für die zu übertragende PLT-Stelle erstellt. Dieses Informationsmodell ist in Abbildung 3-8 dargestellt.

Abbildung 3-8: Informationsmodell der PLT-Stelle gemäß [SST+15*] Die rot umrandeten Elemente enthalten zur näheren Beschreibung Attribute der PLT-Stelle, wie sie in der [NE 150] definiert sind. In einem demonstrierten Szenario [DTB+15*], sowie in einzelnen Anwendungsprojekten konnte die Wirksamkeit der Schnittstelle und die Vollständigkeit der Inhalte unter Beweis gestellt werden. Das agile Vorgehen bei der Umsetzung soll als Beispiel dienen, wie man die Normung und Standardisierung auch in anderen Bereichen effektiv voranbringen kann. Es wurde gezeigt, dass die Normung schrittweise, für einen abgeschlossenen Teil an Information und mit Experten auf dem Fachgebiet schnell umzusetzen ist. Der Normungsvorgang von der Idee, vgl. [TAU13], über das Konzept, vgl. [TAU14] und den Test bis zur Erstellung der Norm dauerte nur zwei Jahre, vgl. [SST+15*; DTB+15*]

3.3.5 VDMA-Schnittstelle für den Maschinenbau (Entwurf) Ein weiteres Beispiel für eine firmenübergreifende Standardisierung zur Optimierung des Engineerings im Maschinen- und Anlagenbau liefert der VDMA. Dazu wurde ein Arbeitskreis gegründet, der eine konkrete Lösung für das Thema erarbeitet. Es soll ein Datenaustausch- Format definiert werden, das ein Informationsmodell bereitstellt, um den standardisierten Austausch grundlegender, gemeinsamer Projektdaten zwischen Mechanik-CAD, Elektro- CAD und SPS-Programmiersoftware zu realisieren. Der Datenaustausch soll so gestaltet 3 Informationsaustausch im Engineering 32 sein, dass auch weitere Planungs- und Engineering-Systeme, wie zum Beispiel Visualisierungssoftware, ERP-Systeme oder die Fluidplanung, davon profitieren können @ [MEI13 ]. Auslöser für diese Aktivitäten war eine Umfrage des VDMA zur Zufriedenheit der deutschen @ Maschinenbauer mit ihren Datenschnittstellen, vgl. [GRÖ13 ]. Die Ergebnisse dazu sind in folgender Abbildung 3-9 zu sehen.

@ Abbildung 3-9: Auswertung einer VDMA-Umfrage [GRÖ13 ] Aus der Statistik ist zu erkennen, dass eine große Unzufriedenheit mit den vorliegenden Datenschnittstellen vorliegt. Diese ist unter anderem auf den Datenverlust an diesen Schnittstellen zwischen den Gewerken zurückzuführen. Dies ist den Mehrfacheingaben von Daten oder Datenverlust auf Grund nicht kompatibler Schnittstellen oder der Überführung in wenig geeignete Datenformate geschuldet.

3.3.6 AutomationML Eine weitere Standardisierungs-Aktivität beschäftigt sich mit der Etablierung eines neutralen Datenaustauschformates, vgl. [DIN EN 62714-1; DIN EN 62714-2; DIN EN 62714-3]. Dieser Ansatz akzeptiert die heterogene Werkzeuglandschaft und versucht den gezielten Datenaustausch zwischen den Werkzeugen zu optimieren [HÄDR14]. Auf Grund der hohen Flexibilität des standardisierten Datenformates verbreitet sich AutomationML schnell [BBM+15]. Das XML-basierte, offene Datenaustauschformat AutomationML nutzt im Kern das Metamodell CAEX (Computer-aided engineering exchange) entsprechend [DIN EN 62424] zur Abbildung hierarchischer Strukturen [DRA10]. CAEX unterteilt sich in die folgenden vier Teile:

INSTANCEHIERARCHY Die INSTANCEHIERARCHY bildet die Repräsentation eines existierenden oder geplanten Systems. Sie setzt sich aus INTERNALELEMENTS zusammen, die einzelne Komponenten des Systems repräsentieren.

SYSTEMUNITCLASSLIBRARY Die SYSTEMUNITCLASSLIBRARY beinhaltet als Bibliothek beliebig viele SYSTEMUNITCLASSES. Die SYSTEMUNITCLASSES beschreiben den physischen und logischen Aufbau von Objekten und setzen sich aus INTERFACES, Attributen und untergeordneten INTERNALELEMENTS 3 Informationsaustausch im Engineering 33 zusammen. Durch Instanziierung können von SYSTEMUNITCLASSES INTERNALELEMENTS in der INSTANCEHIERARCHY erzeugt werden.

ROLECLASSLIBRARY Die ROLECLASSLIBRARY beinhaltet eine Ansammlung von ROLECLASSES. ROLECLASSES dienen der abstrakten Beschreibung von Objektrollen, ohne die technische Realisierung zu definieren. Hierdurch können in einer frühen Planungsphase Anforderungen unabhängig von technischen Lösungen definiert werden. Durch den AutomationML e.V. sind standardisierte ROLECLASSLIBRARIES definiert worden, die bei Bedarf durch den Anwender erweitert werden können.

INTERFACECLASSLIBRARY Die INTERFACECLASSLIBRARY beinhaltet eine Sammlung von INTERFACECLASSES zur Darstellung von Schnittstellen eines Objektes. Diese Schnittstellen können durch Attribute weiter spezifiziert werden.

INTERNALLINKS Über INTERNALLINKS können INTERFACES von INTERNALELEMENTS oder SYSTEMUNITCLASSES miteinander verbunden werden, um Zusammenhänge zwischen den verbundenen Objekten darzustellen. Weiterhin verfügt das Datenaustauschformat AutomationML über die Möglichkeit, Verhaltensbeschreibungen in Form von PLCopen XML- und Bahnkurvenbeschreibungen in Form von COLLADA-Dateien zu integrieren. Über eine EXTERNALREFERENCE (eine bestimmte INTERFACECLASS) kann sowohl auf die Datei, als auch in diese @ Beschreibungsmittel hinein referenziert werden [SCLÜ15 ]. Der AutomationML e.V. ist bestrebt, auch andere Standards in das eigene Format zu integrieren. So ist es in AutomationML möglich, die eCl@ss-Klassifikationen und Merkmalsdefinitionen zur Festlegung von Semantiken einzufügen [LÜD14]. Auch die Abbildung der Formalisierten Prozessbeschreibung ist in AutomationML möglich, wie in [JCS+12] konzeptionell gezeigt wird.

Auch AutomationML hat seine Grenzen. So führt [HAD15] an, dass die Reichweite der Modellierung, insbesondere bei der Abbildung von unterschiedlichen Verbindungen mit Hilfe von INTERNALLINKS, begrenzt ist. Da ein INTERNALLINK nur innerhalb einer INSTANCEHIERARCHY (und nicht zwischen verschiedenen INSTANCEHIERARCHIES) verwendet werden kann, ist eine Hierarchie-übergreifende Verbindung nicht ohne Weiteres zu realisieren. Außerdem kann für ein INTERNALLINK keine weitere semantische Information (z. B. Verbindungstyp, Attribute der Verbindung) hinterlegt werden [HAD15, S. 52]. Dazu muss erklärt werden, dass InternalLinks als Objekte immer an das größte gemeinsame INTERNALELEMENT gehängt werden, in dem die beiden Verbindungspartner abgelegt sind. Hierarchieübergreifend gibt es also kein gemeinsames Element, in dem die INTERNALLINKS abgelegt werden können, da in diesem Fall das oberste Element die AutomationML-Datei an sich ist. Mittels Anwendungsvorschriften ist das Problem zu lösen, indem man immer ein INTERNALELEMENT als oberstes Element einer INSTANCEHIERARCHY definiert und alle betrachteten Hierarchien diesem Element unterordnet. Des Weiteren gibt es auch Möglichkeiten, komplexe Verbindungen an sich als INTERNALELEMENTS zu modellieren (im Sinne eines Rohres oder Kabels), um diesem Element bestimmte Eigenschaften zuzuweisen. 3 Informationsaustausch im Engineering 34

Wie beschrieben, sind in den unterschiedlichen Domänen zusätzliche Konkretisierungen und vor allem Anwendungsvorschriften notwendig, um AutomationML effektiv einzusetzen [BMQ+10]. Dies kann über firmeninterne Vorschriften oder domäneneigene Standardisierungsbemühungen erzielt werden.

3.3.7 Zusammenfassung der betrachteten Standards Im vorliegenden Abschnitt wurden einige Standards, teils aus unterschiedlichen Domänen, vorgestellt. Die normierten Merkmale aus eCl@ss können Domänen-übergreifend eingesetzt werden, um Produkte und Produktionsressourcen zu beschreiben. Diese können in der Formalisierten Prozessbeschreibung zusammengefasst werden, um detaillierte Abläufe von Prozessen zu modellieren. Die beiden Gremienarbeiten zur [NE 150] und der VDMA- Schnittstelle zeigen, wie mit Hilfe von Informationsmodellen eine standardisierte Informationsübertragung zwischen verschiedenen Gewerken optimiert werden kann. Sowohl die Merkmalbeschreibungen als auch die Prozessbeschreibung und die Schnittstellendaten lassen sich mit dem Datenaustauschformat AutomationML transportieren. Daher bilden die in den vorgestellten Standards verwendeten Formate, Modelle und Methoden einen idealen Baukasten, um das Engineering in geeigneter Weise zu optimieren. Die vorgestellten Normen und Standards werden im Laufe der vorliegenden Arbeit angewendet.

3.4 Zusammenfassung des Informationsaustausches im Engineering Aus den Kapiteln 2 und 3 der vorliegenden Arbeit können folgende Erkenntnisse aus den betrachteten Engineering-Ansätzen, den Gewerken und den Standards zusammengefasst und damit die Forschungsfrage 2 beantwortet werden:

2. Welche Informationen stehen im Mittelpunkt der Interessenbereiche der beteiligten Gewerke im fertigungstechnischen Engineering und dienen somit als Drehpunkt für eine Gewerke-übergreifende Kommunikation?

Das Engineering von Produktionssystemen läuft in unterschiedlichen Phasen ab. Es gibt in diesen Phasen verschiedene Beteiligte unterschiedlicher Gewerke, grundsätzlich sind dies in der Domäne der Fertigungstechnik: der Maschinenbau, die Elektrotechnik und die Informationstechnik. Zwischen diesen Gewerken werden unterschiedliche Informationen ausgetauscht: • Diese Informationen werden in unterschiedlichen, spezifischen Engineering-Werkzeugen erstellt; • Je mehr das Engineering parallelisiert wird, desto häufiger müssen diese Informationen zwischen den Gewerken ausgetauscht werden; • Die Informationen zur Erstellung eines Systems sollten funktionsorientiert strukturiert werden, da die Funktionen des Systems im Mittelpunkt der Interessenbereiche aller beteiligten Gewerke sind: o Der funktionsorientierte Ansatz ist unter anderem in der [VDI 2221] vorgesehen, um in der Lösungsfindung einen größtmöglichen Lösungsraum zu ermöglichen. o Ein funktionsorientierter Ansatz macht die Planung so lang wie möglich realisierungs- und geräteunabhängig und dadurch wettbewerbsneutral und flexibel, so wie es in der Domäne der Prozessindustrie mit der PLT-Stelle im R&I-Fließschema gezeigt wird; o Die Funktion dient in immer komplexeren Produktionssystemen der Gewerke- übergreifenden Kommunikation über die zu findende gemeinsame Lösung, die innerhalb des Systems realisiert werden soll. 3 Informationsaustausch im Engineering 35

Aus diesen Anforderungen lässt sich ableiten, dass die Informationen im Engineering funktionsorientiert strukturiert in einem Gewerke-übergreifenden Modell abgelegt werden müssen. Die Funktion bildet den Schnittpunkt aller drei Gewerke. Ihre Realisierung in dem Produktionssystem ist das gemeinsame Ziel des Gewerke-übergreifenden Engineerings. Denn die Entwickler sollten in den frühen Phasen der Planung lösungsneutral denken und das zu entwickelnde Produkt zunächst funktional beschreiben. Auf Basis dieser Funktionsbeschreibung erfolgt anschließend die Lösungssuche [GTS13, S. 17]. Daher lässt sich das 3-Kreise-Modell der Gewerke aus Abbildung 3-2 um die Funktion ergänzen, welche die zentrale Information im Datenaustausch zwischen den Gewerken darstellt, siehe Abbildung 3-10.

Abbildung 3-10: Erweiterung des 3-Kreise-Modells der Gewerke Wie ein solches funktionsorientiertes und Gewerke-übergreifendes Modell aufgebaut wird und wie sich die Informationen darin strukturieren lassen, wird im folgenden Kapitel der vorliegenden Arbeit untersucht.

4 Ansätze des funktionsorientierten Engineerings 36

4 Ansätze des funktionsorientierten Engineerings Im vorliegenden Kapitel werden aktuelle Ansätze des funktionsorientierten und des mechatronischen Engineerings von Produktionssystemen untersucht. Zuvor wird die Funktion im vorliegenden Kapitel in ihrer Verwendung allgemeingültig erklärt und für die vorliegende Arbeit definiert. Funktionsorientiertes Engineering bedeutet, in Funktionen zu denken und die konkrete technische Realisierung vorerst außer Acht zu lassen [WDH14]. Das funktionsorientierte Engineering zeichnet sich besonders dadurch aus, dass es in einem frühen Planungsschritt auf die zu realisierende Funktion fokussiert und nicht zu früh mittels technischer Umsetzung durch Hardware den möglichen Raum für die Findung einer Lösung beschränkt [VDI 2221]. Dabei spielt auch die Betrachtung der mechatronischen Ansätze eine Rolle, da es sich bei den betrachteten Systemen um mechatronische Systeme handelt, an deren Erstellung ein interdisziplinäres Planungsteam beteiligt ist. Daher lassen sich die Ansätze des funktionsorientierten und des mechatronischen Engineerings inhaltlich nicht losgelöst voneinander betrachten. Im Anschluss an die Betrachtung der Ansätze werden diese zusammengefasst und von weiteren, aktuellen Industrie-4.0-Ansätzen, ohne Fokus auf die Funktion, abgegrenzt. Letztendlich wird aus den Ergebnissen der Untersuchung abgeleitet, welche Modelle in einem funktionsorientierten Engineering-Workflow in der Fertigungstechnik bisher verwendet werden und welche Strukturierung der Informationen innerhalb der Modelle angewendet wird. Dazu wird untersucht, welche Modelle mit welchen Beschreibungsmitteln in den verschiedenen Ansätzen erstellt werden. In einer Zusammenfassung am Ende dieses Abschnittes werden diese Informationen einander gegenübergestellt, um daraus Anforderungen an ein funktionsorientiertes Engineering abzuleiten, das den gegebenen Herausforderungen der Digitalisierung mit seinen umfangreich vorliegenden Daten von Produkten und Maschinen durch die Erstellung eines Informationsmodells begegnen kann.

4.1 Definition der Funktion Um im weiteren Verlauf dieser Arbeit ein konsistentes Verständnis über die Funktion zu haben, wird an dieser Stelle eine allgemein gültige Definition der Funktion für die vorliegende Arbeit eingeführt.

[PAT82, S. 64] definiert die Funktion eines Systems wie folgt: „Die Funktion eines Systems ist das Vermögen, bestimmte Eingangsgrößen in bestimmte Ausgangsgrößen überzuführen.“ Die [VDI 2221] beschreibt die Funktion als: „… eine lösungsneutral beschriebene Beziehung zwischen Eingangs-, Ausgangs- und Zustandsgrößen eines Systems“. In [GCD15] wird eine Funktion als: „… der allgemeine und gewollte Zusammenhang zwischen Eingangs- und Ausgangsgrößen mit dem Ziel, eine Aufgabe zu erfüllen“ bezeichnet. Des Weiteren werden Funktionen durch Lösungsmuster bzw. deren Konkretisierungen realisiert. Eine Untergliederung in Subfunktionen erfolgt so lange, bis zu den Funktionen sinnvolle Lösungsmuster gefunden werden [GCD15]. Für die vorliegenden Arbeit wird die Definition der [VDI 2221] genutzt, in Verbindung mit der Erweiterung von [GCD15]: „Eine Funktion ist eine lösungsneutral beschriebene Beziehung zwischen Eingangs-, Ausgangs- und Zustandsgrößen eines Systems mit dem Ziel, eine Aufgabe zu erfüllen.“ 4 Ansätze des funktionsorientierten Engineerings 37

In den folgenden Abschnitten werden funktionsorientierte Ansätze des Engineerings, auch in unterschiedlichen Domänen, untersucht.

4.2 Das funktionsorientierte Engineering in verschiedenen Domänen In diesem Abschnitt wird der Aspekt der funktionsorientierten Planung in den Domänen der Prozessindustrie und der Gebäudeleittechnik betrachtet. Da diese Domänen bereits eine stark funktionsorientierte Planung nutzen, werden hier Anknüpfungspunkte für die fertigungstechnische Planung untersucht.

4.2.1 Prozessindustrie Beim Engineering verfahrenstechnischer Produktionssysteme wird in Funktionen gedacht. Dies äußert sich in den in der Planung verwendeten Planungsunterlagen, den Fließschemata. Diese Fließschemata zeigen den Aufbau und die Funktionen innerhalb verfahrenstechnischer Produktionssysteme. Im verfahrenstechnischen Engineering wird zuerst das Grundfließschema eingesetzt, welches die Verfahren und Grundoperationen, sowie die vorkommenden Stoffflüsse in dem zu planenden Produktionssystem beschreibt. Das Verfahrensfließschema detailliert die Informationen aus dem Grundfließschema, indem es auf die Art der für das Verfahren erforderlichen Apparate und Maschinen eingeht. Die Stoffflüsse werden dabei um Energieflüsse ergänzt. Zusammen mit dem Rohrleitungs- und Instrumentenfließschema (R&I-Fließschema) bilden diese Schemata einen wesentlichen Teil der vollständigen technischen Unterlagen, die für Planung, Bau, Montage, Verwaltung, Inbetriebnahme, Betrieb, Wartung und Außerbetriebnahme eines Produktionssystems benötigt werden [DIN EN ISO 10628-2]. Das eingesetzte R&I-Fließschema hat die Automatisierungsfunktionen, die in einem Produktionssystem umgesetzt werden sollen, als zentrales Planungselement [DIN EN 62424]. In diesem R&I-Fließschema werden unter anderem verfahrenstechnische Funktion und die Art der Apparate und Maschinen, sowie die Regel- und Steuerfunktionen durch graphische Symbole abgebildet [DIN EN ISO 10628-2]. Diese und weitere Angaben sind als eine gemeinsame Kommunikationsgrundlage zwischen den an der Planung der Prozessleittechnik (PLT) beteiligten Gewerken zu sehen. In Abbildung 4-1 ist dieser Zusammenhang grafisch dargestellt. Wie in der Abbildung zu erkennen ist, steht die Automatisierungsfunktion in Form der PLT-Stelle im Mittelpunkt der Interessenbereiche der beteiligten Gewerke. Gemäß [NA 35] beginnt die Planung eines Produktionssystems mit der Grundlagenermittlung und der Vorplanung durch das Gewerk der Verfahrenstechnik. Dabei werden das Konzept des Produktionssystems und die ersten PLT-Funktionen zur Herstellung des Produkts festgelegt und die verfahrenstechnischen Daten ermittelt. Später und teilweise parallel zur Verfahrenstechnik werden in der Basisplanung R&I-Fließschemata durch die R&I-Planung erstellt. Zwischen den CAE- Systemen der Gewerke werden die Planungsdaten ausgetauscht und abgeglichen. Das DEXPI-Datenmodell [DEX17@] definiert unter anderen die Instrumentierungsobjekte eines R&I-Fließschemas und kann zur Datenübertragung zwischen den Gewerken benutzt werden. In der Basisplanung werden die verfahrenstechnischen Daten für das weitere Engineering in CAE-Systeme der PLS-Planung übertragen. Das Datenmodell, welches in der [NE 159] vorgestellt wird, standardisiert diese verfahrenstechnischen Daten und ermöglicht so die Erstellung von Schnittstellen zwischen den CAE-Systemen der Verfahrensauslegung und der PLS-Planung. In der Phase der Ausführungsplanung werden Signaldaten für die PLS- Planung in die CAE-Systeme der PLS-Planung importiert. Dafür kann das Datenmodell aus der [NE 150] verwendet werden [SBL+17]. 4 Ansätze des funktionsorientierten Engineerings 38

Abbildung 4-1: Informationsschnittmengen in der Planung verfahrenstechnischer Produktionssysteme Die beschriebenen Zusammenhänge zwischen den drei Gewerken werden in unterschiedlichen Arbeitskreisen unter Beteiligung von Industriepartnern untersucht. Daraus folgend werden Bemühungen unternommen, diese Informationen zu standardisieren, um sie effizient zwischen den beteiligten Planern der unterschiedlichen Gewerke übertragen zu können, vgl. [DTB+15*; SBL+17].

4.2.2 Gebäudeleittechnik Aus der Domäne der Gebäudeleittechnik wird der untergeordnete Teilbereich der Raumautomation betrachtet. Auch hier wird ein Planungsansatz verwendet, bei dem die Funktion in einem bestimmten Bereich eines Gebäudes, beispielsweise in einem Raum, im Mittelpunkt steht. Diese Funktionen sind in der [VDI 3813-2] beschrieben. Durch diese Standardisierung stehen die Funktionen den Planern der Raum- und Gebäudeautomation lösungsneutral zur Verfügung. Die Funktionen sind als „Black-Boxes“ ausgeführt, nur ihre jeweiligen Ein- und Ausgänge sowie die Parameter zur Konfiguration der Funktion sind standardisiert und in der Norm detailliert beschrieben. Für den Inhalt der Funktion sind die Hersteller selbst verantwortlich. In der Planung können sich die unterschiedlichen Gewerke (Heizung/Lüftung/Klima, Elektrotechnik, Sicherheitstechnik) an den geplanten Funktionen orientieren und diese zur weiteren Planung verwenden, zum Beispiel um entsprechende Geräte auszuwählen, zu verkabeln und diese Geräte zu verbauen. In der Programmierung des Gebäudeautomations-Systems werden die geplanten Funktionen dann in Steuerungsfunktionen umgesetzt. Abbildung 4-2 zeigt ein einfaches Beispiel, in dem drei Funktionen zur Realisierung einer einfachen Lichtschaltung in einem Raumautomationsschema dargestellt sind. Diese Funktionen können mit Parametern hinterlegt werden, wie zum Beispiel Haltezeiten.

4 Ansätze des funktionsorientierten Engineerings 39

Abbildung 4-2: Funktionen zur Lichtschaltung in einem Raumautomationsschema Diese Darstellung der Funktionen eines Raumes oder Gebäudes ist auch in der Gebäudeautomation ein gemeinsames Kommunikationsmittel zwischen den beteiligten Planern der verschiedenen Fachdisziplinen. Die technische Realisierung der geplanten Funktionen obliegt den unterschiedlichen ausführenden Beteiligten der Elektroinstallation, der Klima- und Lüftungsinstallation sowie den Heizungsbauern. Mit einer gemeinsamen Planungsgrundlage ist hier eine effektive Kommunikation zwischen den beteiligten Planern der unterschiedlichen Fachdisziplinen möglich.

4.3 Ansätze zur funktionsorientierten Planung in der Fertigungstechnik In diesem Abschnitt werden aktuelle und etablierte Ansätze untersucht, die sich mit dem Engineering von fertigungstechnischen Produktionssystemen beschäftigen und dabei die funktionsorientierte Betrachtung eines Systems in den Fokus rücken. Das Denken in Funktionen und das schrittweise Konkretisieren technischer Lösungen ist nicht ohne Herausforderungen konsequent umzusetzen. Auf der einen Seite sind die Planer der unterschiedlichen Gewerke, die zunächst lösungsneutral und funktionsorientiert vorgehen sollen. Auf der anderen Seite sind die Anbieter von Lösungselementen, die einen lösungsspezifischen sowie bauteil- und komponentenorientierten Denkansatz verfolgen. Die Planer, die je nach Fachdisziplin die Produktspezifikation in ihrer eigenen Terminologie beschreiben, treffen bei der Suche nach Lösungen auf unterschiedliche Präsentationsformen der Anbieter – unternehmensspezifische Terminologien, unterschiedliche Detailtiefen, sowie differenzierte Aufbauten von Online-Katalogen. Eine funktionsorientierte, anbieterübergreifende Suche ist somit nicht möglich. In Folge dessen werden die Planer insbesondere in den frühen Entwurfsphasen dazu verleitet, ihre lösungsneutrale Vorgehensweise aufzugeben und sich an den ihnen bekannten Lösungen zu orientieren. [GTS13, S. 13] Um diesem Umstand entgegen zu wirken, werden im Folgenden mechatronische Ansätze, von den allgemeinen hin zu den speziellen Ansätzen betrachtet, um darzustellen, wie Planer ein funktionsorientiertes Engineering durchführen können. Im Engineering-Workflow sollte vor dem Engineering des Produktionssystems eine Aufnahme der Anforderungen durchgeführt werden, was durch die Betrachtung des zu produzierenden Produktes realisiert wird. In Abgrenzung zu den unterschiedlichen mechatronischen Ansätzen wird daher kurz auf das anforderungsgetriebene Engineering eingegangen. 4 Ansätze des funktionsorientierten Engineerings 40

4.3.1 Abgrenzung zum anforderungsgetriebenen Engineering Ziel des anforderungsgetriebenen Engineering ist es, bei der Planung eines Produktionssystems im Kern darauf zu fokussieren, was hergestellt werden soll, und nicht in den Fokus zu bringen, wie dies geschehen soll [HNO+14]. Daher sind für die anforderungsgetriebene Planung die Informationen über das Produkt, das produziert werden soll, der Orientierungspunkt zur Ausrichtung der gesamten Planung eines Produktionssystems. Um dies zu betonen, legen [GTS13] für die Anforderungen, die ein Produkt an das Produktionssystem stellt, ein eigenes Partialmodell als Teil der Produktbeschreibung an. Das Produkt kann sowohl durch seine Funktionen als auch durch seine Struktur beschrieben werden [GTS13, S. 38]. Aus der (Bau-) Struktur des Produktes kann auf die notwendigen Grundfunktionen des Produktionssystems für das Produkt geschlossen werden [BYA+15]. Eine Abgrenzung zur funktionsorientierten Planung kann in dem Sinne nicht getroffen werden, da die Analyse der Anforderungen an ein Produktionssystem als Vorbereitung der funktionsorientierten Planung eingeordnet werden kann. Im Engineering-Prozess ist dieses Planungsvorgehen somit zeitlich vor der funktionsorientierten Planung zu sehen und stellt eine wichtige Voraussetzung für die Durchführung der funktionsorientierten Planung zur Verfügung: die systematisch aufgenommenen Anforderungen an ein Produktionssystem abgeleitet aus dem herzustellenden Produkt.

4.3.2 VDI-Richtlinie 2206 – Entwicklungsmethodik für mechatronische Systeme Analog der VDI-Richtlinie 2221, die allgemeingültige, branchenunabhängige Grundlagen methodischen Entwickelns und Konstruierens behandelt, werden in der [VDI 2206] die Methoden zur Entwicklung mechatronischer Systeme beschrieben [VDI 2206, S. 14]. Die Mechatronik nutzt die Synergien aus dem Zusammenwirken der klassischen Gewerke Maschinenbau, Elektrotechnik und Informationstechnik [VDI 2206, S. 10] zur Entwicklung mechatronischer Systeme. Diese Domänen verfügen über eigene Begriffswelten, Erfahrungen und über Jahrzehnte gewachsene Methoden und Beschreibungsmittel (siehe dazu Abschnitt 3). In der Vergangenheit wurde die Produktentwicklung häufig von einer Wissensdomäne dominiert. Die mechanische Grundstruktur stellte die Basis dar, Elektrotechnik und Informationsverarbeitung wurden später ergänzt. Dieses sequentielle Vorgehen bei der Entwicklung führte zu teiloptimierten Produkten, die langwierige Iterationen mit kosten- und zeitintensiven Entwicklungsprozessen nach sich zogen. Die Herausforderungen und zugleich die Chancen mechatronischer Systeme bestehen darin, das Potential domänenübergreifender Zusammenarbeit zu nutzen und im Sinne eines Concurrent Engineering zu einem Gesamtoptimum zu führen (siehe dazu Abschnitt 2.4). Um das Engineering zu parallelisieren, müssen Systemkonzepte durch die beteiligten Fachleute integrativ erarbeitet werden. Die Komponenten des geplanten Systems können dann bei gegebener Kompatibilität durch Lösungsansätze der unterschiedlichen Domänen realisiert werden. Meist werden diese Lösungen erst durch die domänenübergreifende Zusammenarbeit möglich. Dieses Konzept erfordert neben organisatorischen Maßnahmen auch domänenübergreifende Vorgehensweisen und Beschreibungsmittel, um die Kommunikation und Kooperation zwischen den beteiligten Gewerken sicherzustellen. Domäneneigene Methoden sind häufig für sehr spezielle Aufgabenstellungen entwickelt worden und nicht ohne Weiteres auf eine domänenübergreifende Zusammenarbeit erweiterbar [VDI 2206, S. 22]. 4 Ansätze des funktionsorientierten Engineerings 41

Methodisch schlägt die Norm vor, eine Funktionsstruktur des geplanten Systems aufzustellen. Dazu wird aus der Problemspezifikation die Gesamtfunktion des Systems abgeleitet. Diese Gesamtfunktion stellt die Zielfunktion für das Verhalten des Systems unter seinen Einsatzbedingungen dar. Die Funktion und die Einsatzbedingungen bilden die Eingangsgrößen für die Planungsmethode eines mechatronischen Systems, die Ausgangsgrößen beschreiben das gewünschte Verhalten des Systems. Wird die Funktion eines Systems geplant, so ist erst einmal allgemein der Aufbau eines mechatronischen Systems zu klären: Ein Ziel der Mechatronik ist es, das Verhalten eines technischen Systems zu verbessern, indem mit Hilfe von Sensoren Informationen über die Umgebung, aber auch über das System selbst erfasst werden [VDI 2206, S. 10]. Ein mechatronisches System lässt sich dementsprechend als ein System beschreiben, das aus einem Grundsystem, Sensoren, Aktoren und einer Informationsverarbeitung besteht, siehe dazu Abbildung 4-3. Um das Grundsystem zu beschreiben, wird dessen Wirkung auf unterschiedliche Flüsse dargestellt. Grundsätzlich sind drei Arten von Flüssen zu unterscheiden: Stofffluss, Energiefluss und Informationsfluss [VDI 2206, S. 15].

Abbildung 4-3: Grundstruktur eines mechatronischen Systems nach [VDI 2206, S. 14] Mit Hilfe dieser allgemeinen Flussgrößen Stoff, Energie und Information und der Blockdarstellung der Funktionen, die ein System ausführen soll, kann der Zusammenhang zwischen Eingangs- und Ausgangsgrößen spezifiziert werden. In Abbildung 4-4 ist die Blockdarstellung für zwei Funktionselemente (FE) zu erkennen. In der Regel ist die zu lösende Aufgabe zu komplex, um unmittelbar aus der Gesamtfunktion die technische Realisierung ableiten zu können. Deshalb ist eine Aufgliederung der Gesamtfunktion in Teilfunktionen (Abbildung 4-4, FE1 und FE2) vorzunehmen. Teilfunktionen mechatronischer Systeme können beispielsweise Antreiben, Steuern/Regeln, Messen, Übertragen sein. Die Teilfunktionen werden wiederum über Stoff-, Energie- und Informationsflüsse zur Funktionsstruktur verknüpft, um das Verhalten zu beschreiben und frühzeitig Inkonsistenzen zu erkennen [VDI 2206, S. 32]. 4 Ansätze des funktionsorientierten Engineerings 42

Abbildung 4-4: Funktions- und Wirkstruktur der [VDI 2206] In einem nächsten Schritt werden für die gefundenen Teilfunktionen Wirkprinzipien in Form von Wirkelementen (WE) gesucht, die diese Teilfunktionen erfüllen können, siehe Abbildung 4-4. Sind für alle Teilfunktionen entsprechende Wirkprinzipien und für diese die entsprechenden Lösungselemente gefunden, so werden diese in einer Wirkstruktur zusammengefasst und über die entsprechenden Flüsse (Stoff-, Energie- und Informationsfluss) miteinander verbunden, vgl. mit Wirkstruktur in Abbildung 4-4. Ergebnis des Systementwurfs ist ein domänenübergreifendes Lösungskonzept, das die wesentlichen physikalischen und logischen Wirkungsweisen des zukünftigen Systems und die Art und Anordnung seiner Komponenten beschreibt [VDI 2206, S. 35].

4.3.3 VDI Richtlinie 2222 – Konstruktionsmethodik Die [VDI 2222-2] gibt Anleitungen, wie der Prozess für das Finden der "Prinzipiellen Lösung" eines technischen Systems methodisch vollzogen und dokumentiert werden kann. In der Norm wird der Übergang von gefundenen Funktionen und Funktionsstrukturen zur Erfüllung der Systemanforderungen hin zu "Prinzipiellen Lösungen" vollzogen. Dazu ist es notwendig, dass man sich mit der funktionalen Gestaltung des Systems intensiv befasst hat und deren Auswirkung auf die "Prinzipiellen Lösungen" kennt. Auch diese Richtlinie verwendet wie die [VDI 2206] die drei verschiedenen Flüsse (Stoff-, Energie- und Informationsfluss), um die Funktion aller Maschinen, Geräte und Apparate zu beschreiben, vgl. [VDI 2222-2]. Dazu teilt die Richtlinie die Funktionen in die notwendigen Zustandsänderungen ein: Speichern, Leiten, Umformen, Wandeln und Verknüpfen. Die drei Flussarten kombiniert mit den Zustandsänderungen ergeben die allgemeinen Funktionen eines Systems. Eine Übersicht über diese allgemeinen Funktionen ist der folgenden Abbildung 4-5 zu entnehmen. 4 Ansätze des funktionsorientierten Engineerings 43

Abbildung 4-5: Allgemeine Funktionen und ihre symbolische Darstellung [VDI 2206, S. 32] Ein methodisches Vorgehen im Engineering eines Systems findet statt, wenn durch die Kombination der allgemeinen Funktionen eine Lösung für eine Anforderung gefunden wird. Diese Kombination von Funktionen kann dann durch „Prinzipielle Lösungen“ realisiert werden. Dabei können verschiedene Lösungswege entstehen, um die Anforderungen des Systems zu erfüllen. Im weiteren Engineering-Prozess werden diese dann gegeneinander abgewogen und bewertet, um die beste Lösung auszuwählen. Die [VDI 2206] und die [VDI 2222-2] haben gemeinsam, das während des Engineerings eine Trennung zwischen der Funktion und der Umsetzung der Funktion als Grundlage für die Vergrößerung des möglichen Lösungsraumes gesehen wird. Eine zu frühe Festlegung auf eine prinzipielle Lösung oder ein entsprechendes Bauteil/Gerät, das die Funktion erfüllt, wird damit verhindert. Die durch diese systematische Vorgehensweise gefundenen Lösungen dienen dann als Planungsgrundlage für das Engineering in den unterschiedlichen Gewerken.

4.3.4 AQUIMO Das Projekt AQUIMO (Adaptierbares Modellierungswerkzeug und Qualifizierungsprogramm für den Aufbau firmenspezifischer mechatronischer Engineeringprozesse) hatte zum Ziel, eine mechatronische Modellierungsmethode und ein Werkzeug hierfür zu erarbeiten [ABH+10]. Damit soll es möglich sein, in einem durchgehenden reproduzierbaren Engineering-Prozess zuverlässige mechatronische Komponenten zu entwickeln. Als ein Ergebnis des Projektes entstand ein firmenspezifisch adaptierbares Modellierungswerkzeug. Im Projektbericht wird erklärt, wie sich durch die durchgängige mechatronische Entwicklungsmethode des Systems und durch die Verwendung des entsprechenden Engineering-Werkzeuges für Anwenderfirmen große Potentiale ergeben. Laut Projektbericht wird die Reduzierung der Entwicklungszeiten und -kosten bei gleichzeitiger Steigerung der Zuverlässigkeit erreicht [ABH+10, S. 51]. Auf die Kernpunkte der Methode wird im Folgenden eingegangen. 4 Ansätze des funktionsorientierten Engineerings 44

Um bei der Systementwicklung den mechatronischen Entwurf vollständig zu beschreiben, müssen folgende Beschreibungsmittel vorhanden sein [ABH+10, S. 51]: • eine schematische Darstellung des Systems zur Visualisierung, • eine Ablaufspezifikation zur Festlegung von Bewegungsabläufen und der Abschätzung von benötigten Zykluszeiten, • optional: vereinfachter Installationsentwurf zur Dokumentation der Rohre und Leitungen für die Installationsplanung. Daraus ergeben sich folgende Werkzeuge/Darstellungsformen zur Beschreibung, vgl. [ABH+10, S. 64]: • 3D-Editor für die Anordnung und den Zusammenbau von Komponenten zu Systemen, • Gantt- oder Funktionsdiagramme für die Festlegung von Bewegungsabläufen, • Installationsprogramm zum Anschließen von Aktoren und Sensoren an Steuerungskomponenten und zur Zuweisung von Komponenten zu verschiedenen Örtlichkeiten. Dabei stellt jedes dieser Ergebnisse/Diagramme eine Sicht auf ein und dasselbe mechatronische Modell dar [ABH+10, S. 64]. Interessant für die vorliegende Arbeit ist die hierarchische Strukturierung der Komponenten. Diese werden (von groß nach klein) in folgende Teile gegliedert: 1. Stationen 2. Funktionsgruppen 3. Funktionseinheiten 4. Basiskomponenten (Zylinder, Sensoren, Ventile) Die Basiskomponenten werden detailliert und nach ihren Funktionen eingeteilt [ABH+10, S. 61]. Nachfolgende Abbildung 4-6 illustriert die Basisstruktur der Komponenten.

Abbildung 4-6: Basiskomponenten nach [ABH+10, S. 66] Aus dem Projektbericht geht nicht hervor, wie ein konkretes mechatronisches Modell aufgestellt wird. Die Vermischung von Funktionen und Komponenten in einer hierarchischen Strukturierung scheint für einen systematischen Lösungsentwurf nicht zielführend. Die beschriebenen Darstellungsmittel geben einen Hinweis darauf, wie ein Modell eines 4 Ansätze des funktionsorientierten Engineerings 45 mechatronischen Systems unterteilt werden kann. Das Teilmodell einer Komponentenhierarchie lässt sich aus der hierarchischen Strukturierung der Basiskomponenten ableiten. Die weiteren Anforderungen nach einer Verhaltensbeschreibung in Form eines Gantt-Diagramms lassen ein Verhaltensmodell sinnvoll erscheinen. Für die Funktionsbeschreibung des Systems sollte zusätzlich ein Funktionsmodell vorhanden sein, welches die Funktionen aus dem geforderten Funktionsdiagramm abbildet. Die aufgeführten Basiskomponenten und ihre Unterteilung können zudem einen Beitrag für die Erstellung von firmeneigenen Funktionsbibliotheken bilden.

4.3.5 MEPROMA – Mechatronisches Engineering zur effizienten Produktentwicklung im Maschinen- und Anlagenbau Das Projekt MEPROMA verfolgt das Ziel, Anforderungen an Methoden und Werkzeuge für ein effizientes Engineering anhand von Anwendungsszenarien zu formulieren und darauf aufbauend Lösungsansätze, Schulungskonzepte und Einführungsstrategien zu entwickeln [MEP15]. Für die vorliegende Arbeit ist die Betrachtung der Beschreibung eines vollständigen mechatronischen Entwicklungsprozesses relevant, der im Folgenden kurz dargestellt wird. Für den mechatronischen Systementwurf sind Modelle, die eine Funktionsstruktur (inkl. Funktionsbeschreibung) sowie eine Systemstruktur (Komponenten, Maschinenlayout, disziplinübergreifende Stückliste) beinhalten und die auf Grundlage der Anforderungen erstellt werden, von besonderer Bedeutung [MEP15]. In einem ersten Schritt wird das System nach Funktionen strukturiert. Dazu ist die Erstellung eines Baukastens für benötigte Funktionsbausteine des zu entwickelnden Systems notwendig. Die Funktionsbausteine verknüpfen Anforderungen, Dokumente und Teillösungen einzelner Disziplinen. Eine Ablage in einer zentralen Datenbank unterstützt eine einfachere Wiederverwendung bestehender Lösungen in Form von Funktionen und die Erstellung eines übergreifenden, modularen Funktionsbaukastens [MEP15]. In der sich anschließenden Phase der Systemrealisation werden von jedem Gewerk die geforderten Unterlagen erstellt, die für die Errichtung des Systems erforderlich sind. Begleitet werden diese Aktivitäten der einzelnen Gewerke von einer Gewerke-übergreifenden Phase der gemeinsamen Systemrealisierung, in der die Ergebnisse der Gewerke zusammengeführt und auf Fehler hin untersucht werden. Als ein mögliches Beschreibungsmittel für die Bestandteile eines Systems werden im Projekt MEPROMA die mechatronischen Objekte genannt. Um diese zu strukturieren, sind zwei Modelle notwendig. Eines der Modelle repräsentiert einen komponentenbasierten Strukturbaum, der die erforderlichen Baugruppen des zu entwickelnden Systems beschreibt. Diese Baugruppen werden klassifiziert in Mechanik, Elektrik und zugehörige Software. Ein zweites Modell enthält einen funktionsbasierten Strukturbaum, der die zukünftig zu realisierenden Aufgaben des Systems angibt [MEP15]. Beide Strukturbäume können nun in einer Verknüpfungsmatrix (Domain Mapping Matrix) miteinander über Cross-Referenzen in Beziehung gebracht werden. Hierzu werden die jeweiligen Elemente der Strukturbäume zeilen- bzw. spaltenweise aufgetragen und etwaige Wechselwirkungen zwischen diesen Elementen markiert. Dies erlaubt dem Entwickler ein frühes Verständnis davon, welche System-Funktionalitäten durch welche Komponenten umgesetzt werden. Weiterhin ergibt sich durch Summation der Zeilen- bzw. Spalteneinträge 4 Ansätze des funktionsorientierten Engineerings 46 eine Verifikation, ob für eine umzusetzende Funktionalität dessen realisierende Komponenten fehlen und umgekehrt [MEP15]. Die mechatronischen Objekte stellen die abschließende und detaillierteste Stufe des Systementwurfs dar. Sie beschreiben das System als funktionale Module (im Sinne eines Planungsobjektes) und korrelieren mit den ermittelten Systemfunktionen. Ein mechatronisches Objekt enthält alle notwendigen Informationen, die für eine Realisierung der beschriebenen Systemfunktion und dessen Anforderungen benötigt werden [MEP15]. Die mechatronischen Objekte werden in einer Art Steckbrief detailliert in Fließtext beschrieben. Darin sind Informationen über die Hardware, die Schnittstellen und die Anforderungen, unterteilt nach Gewerken, enthalten. Relevant für die vorliegende Arbeit erscheint der Ansatz, die Anforderungen strukturiert aufzunehmen und in ein funktionsorientiertes Strukturmodell einfließen zu lassen. Zudem erscheint die Trennung zwischen Funktionsstruktur und Aufbaustruktur des Systems zielführend, da somit die Lösungsfindung strukturiert möglich ist. Die Verbindung dieser beiden Modelle ist dabei entscheidend, um Beziehungen zwischen den Funktionen und den diese Funktionen realisierenden Komponenten abzubilden.

4.3.6 Kiefer – Mechatronikorientierte Planung automatisierter Fertigungszellen im Bereich Karosserierohbau In [KIE07] wird gezeigt, wie mit Hilfe einer Mechatronik-orientierten digitalen Planungsprozesskette das Engineering von Produktionssystemen beschleunigt werden kann. Grundlage dieser Mechatronik-orientierten Planungsprozesskette stellt die frühzeitige und integrierte Betrachtung von mechanischen, elektrischen, pneumatischen/hydraulischen und steuerungstechnischen Ressourcendaten dar. Hierzu werden standardisierte domänenübergreifende Ressourcenkomponenten benötigt, die alle zur Projektierung von Produktionssystemen benötigten Ressourcendaten zentral bündeln und die den jeweiligen Fachbereichen durchgängig und transparent zur Verfügung gestellt werden [KIE07]. Für die Umsetzung dieses Ansatzes sind unterschiedliche Modelle notwendig. Kiefer verwendet ein mechatronisches Ressourcenmodell und ein Prozessmodell [KIE07]. Das Ressourcenmodell enthält die Elemente des Systems. Diese sind in Hierarchieebenen eingeteilt und beinhalten in und oberhalb der Ebene „Funktionsgruppe“ Planungsinformationen aller drei beteiligten Gewerke (Mechanik, Elektrik und Steuerungstechnik). Dies ist in folgender Abbildung 4-7 dargestellt. 4 Ansätze des funktionsorientierten Engineerings 47

Abbildung 4-7: Aufbau und Strukturierung des Ressourcenmodells [KIE07] Wie der Abbildung 4-7 zu entnehmen ist, können die Funktionsgruppen in einer mechatronischen Ressourcenbibliothek abgelegt werden. Der Aufbau und die Inhalte einer solchen Funktionsgruppe, allgemein als mechatronischen Ressourcenkomponente bezeichnet, sind in Abbildung 4-8 dargestellt.

Abbildung 4-8: Inhalte mechatronischer Ressourcenkomponenten [KIE07] Eine mechatronische Ressourcenkomponente enthält neben allgemeinen Informationen im Wesentlichen die gesammelten Planungsdaten der drei Gewerke, sowie eine funktionsorientierte Beschreibung. Parallel zur Entwicklung des mechatronischen Ressourcenmodells im Engineering-Prozess findet die Prozessplanung statt. Auf Grund von Praxisanforderungen soll das Prozessmodell (siehe Abbildung 4-9) sowohl als interdisziplinäres Dokumentations- und Kommunikationsmedium, als auch als Basis zur automatisierten Generierung von SPS- Programmen dienen [KIE07]. 4 Ansätze des funktionsorientierten Engineerings 48

Abbildung 4-9: Prozessmodell [KIE07] Daher ist die Abbildung der Prozesse sehr nah an der SPS-Programmiersprache Ablaufsprache orientiert, wie man an der Verwendung von Aktivitäten und Transitionen erkennen kann. Wie in Abbildung 4-10 dargestellt, wird ein PPR-Datenmodell (PPR: Produkt, Prozess, Ressource) als „Planungsmaster“ für die beiden dargestellten Modelle genutzt. Bezogen auf den gesamten Lebenszyklus automatisierter Produktionssysteme nimmt dieses integrierte Datenmodell eine vielfältige Rolle ein. Während des Produktionsplanungsprozesses dient es als interdisziplinäre Kommunikationsplattform und bildet zudem die informationstechnische Basis zur automatisierten Generierung standardisierter Arbeitsunterlagen und zellenspezifischer SPS-Programme [KIE07].

Abbildung 4-10: Planungsvorgehen [KIE07] In der Arbeit von Kiefer wird das PPR-Datenmodell an sich nicht weiter dargestellt, es ist als Datenbasis vorhanden und stellt Informationen zur Verfügung. Das Ressourcenmodell gliedert die Hierarchie eines Produktionssystems und beschreibt die Komposition mechatronischer Komponenten. Diese können Merkmalsträger sein, für unterschiedliche Merkmale von verschiedenen Domänen der Konstruktion und der Beschaffung. Das Prozessmodell ist sehr stark an einem SPS-Programm orientiert, um automatisch den Steuerungscode daraus generieren zu können. Das hat zur Folge, dass es wenig generisch ist und für eine frühe Phase der Planung wenig geeignet erscheint. Es hilft dem SPS- Programmierer, seine Programme schnell umzusetzen, ist jedoch erst einsetzbar, wenn konkrete Komponenten ausgewählt sind.

4 Ansätze des funktionsorientierten Engineerings 49

4.3.7 Reuter – Definition eines mechatronischen Informationsmodells zur Modellierung von Automatisierungskomponenten und Maschinen [REU13] definiert Grundfunktionen von Automatisierungskomponenten durch die Analyse und Abstraktion bestehender disziplinspezifischer Informationen. Diese Grundfunktionen treten in Automatisierungskomponenten sowohl einzeln als Hauptfunktion, als auch miteinander kombiniert als jeweils eine Hauptfunktion mit zusätzlichen Nebenfunktionen auf. Die Hauptfunktionen werden wie folgt definiert [REU13, S. 73]: • Steuerung bzw. Regelung realisieren durch Verarbeitung bzw. Rückkopplung vorgegebener Soll-Zustände, • Visualisierung bereitstellen dient der Darstellung von Messgrößen und Zuständen der Maschine für den Maschinenbediener, • Eingabeschnittstelle bereitstellen ermöglicht dem Maschinenbediener die Beeinflussung aktueller Maschinenabläufe und Prozesszustände, • Kommunikationsschnittstelle bereitstellen zur Kommunikation der Automatisierungskomponenten untereinander. Jede Automatisierungskomponente stellt als Nebenfunktion mindestens eine Kommunikationsschnittstelle bereit. Es gibt aber Automatisierungskomponenten, deren Hauptfunktionalität das Bereitstellen von Kommunikationsschnittstellen ist (z. B. Feldbuskoppler), • Eingang bereitstellen dient dem Einlesen und der Übertragung elektrischer Messsignale, • Ausgang bereitstellen dient zur Ausgabe von Soll-Zustandsinformationen und damit elektrischer Steuersignale in physikalische Stellgrößen der Maschine, • Energie wandeln als Grundfunktion realisiert den notwendigen Eintrag einer Energieform zur gezielten Beeinflussung einer Maschine sowie deren Zustände. Dies geschieht entsprechend der vorgegebenen Stellgrößen, • Messgröße aufnehmen sorgt für die notwendige Wandlung von veränderlichen, physikalischen Messgrößen der Maschine in analoge bzw. digitale Messsignale. Das Informationsmodell (siehe dazu Abbildung 4-11) zur Beschreibung von Automatisierungskomponenten besteht nach Reuter aus einem hierarchischen Teil, der den Aufbau der Automatisierungskomponenten beschreibt, indem diese in Aktor-, Sensor-, und Informationsverarbeitungskomponenten unterteilt werden. Als zweiten Teil setzt sich das Informationsmodell aus den genannten Grundfunktionen zusammen, die durch die beschriebenen Automatisierungskomponenten realisiert werden. 4 Ansätze des funktionsorientierten Engineerings 50

Abbildung 4-11: Funktionsorientierte Klassenstruktur zur Modellierung von AT-Komponenten [REU13, S. 79] Diese Gliederung erscheint für die Strukturierung von Funktionen und Komponenten nutzbar und kann für die Erstellung von Funktionsbibliotheken mit darin hinterlegten Komponenten eingesetzt werden.

4.3.8 Gehrke – Entwurf mechatronischer Systeme aus Funktionshierarchien Ziele der Arbeit von [GEH05] sind die Formalisierung der Funktionshierarchie und der Systemstruktur sowie das Mapping der beiden Modelle miteinander. Hierzu wurden in der Arbeit zwei weitere Schwerpunkte festgelegt: Die Entwicklung eines Algorithmus zur automatischen Suche nach Systemelementen und die Definition und Sicherstellung von Konsistenzbedingungen zwischen den beiden Modellen der beiden Spezifikationstechniken [GEH05].

Die Analyse des Stands der Technik von [GEH05] zeigt, dass es keinen Ansatz gibt, der einen rechnerunterstützten Übergang von der Funktionshierarchie zur Systemstruktur ermöglicht. Der Übergang von den lösungsneutralen Funktionen zu den konkreten Elementen des mechatronischen Systems wird bisher durch den Menschen vorgenommen. Dies wird jedoch zunehmend schwerer, da durch die Kombination der Elemente der verschiedenen Disziplinen ein riesiger Lösungsraum entsteht, der nur sehr schwer von einzelnen Entwicklern überschaut werden kann [GEH05, S. 55]. Aus diesem Defizit wird ein Planungsvorgehen abgeleitet. Im ersten Schritt ist ein Funktionsmodell zu entwerfen und daraus das Strukturmodell abzuleiten. Auf Seiten der Funktionsmodellierung wird von Gehrke ausschließlich die Funktionshierarchie betrachtet. Für die Gliederung der Funktionshierarchie wird folgende Einteilung genutzt: Vernetzte Mechatronische Systeme, die sich aus Autonomen Mechatronischen Systemen und diese wiederum aus Mechatronischen Funktionsmodulen zusammensetzen, siehe dazu Abbildung 4-12. Die Mechatronischen Funktionsmodule enthalten wiederum eine Betrachtung der Flussgrößen und deren Änderung durch die mechanische Struktur. 4 Ansätze des funktionsorientierten Engineerings 51

Abbildung 4-12: Funktionshierarchie [GEH05, S. 21] Ist das Funktionsmodell aufgestellt, so können Systemelemente ausgewählt werden, die die geforderte Funktion erfüllen. Die Auswahl eines Systemelements kann in einigen Fällen bedeuten, dass noch andere Systemelemente zur Verfügung stehen müssen, damit das gewählte Systemelement seine Aufgabe überhaupt erfüllen kann. So benötigt z. B. ein Radar oder eine Pumpe elektrischen Strom, damit sie funktionieren. Diese Art der Abhängigkeit wird durch Hilfsfunktionen ausgedrückt, wobei sich deren Aufbau nicht von den übrigen Funktionen (Hauptfunktion bzw. Teilfunktionen) unterscheidet [GEH05, S. 59]. Die Trennung nach Funktions- und Strukturhierarchie erscheint für die vorliegende Arbeit nutzbar. [GEH05] betrachtet flussverkettete Funktionsstrukturen nicht, da sie seiner Meinung nach, auf Grund der darin modellierten Reihenfolgen, nicht als lösungsneutral angesehen werden. Trotz der Tatsache, dass eine Funktion selbst zwar noch lösungsneutral ist, werden durch die Reihenfolge bereits andere Lösungen ausgeschlossen bzw. impliziert.

4.3.9 Hadlich – Verwendung von Merkmalen im Engineering von Systemen In [HAD15] wird der Engineering-Prozess umfassend betrachtet und abgeleitet, welche Datenobjekte als Träger von Merkmalen von Interesse für das Engineering und die daran Beteiligten sind. Dabei stehen die Merkmale, deren Verbindung untereinander und deren Abbildung in CAEX im Vordergrund. Auf Produkte, die in den Funktionen des Systems bearbeitet werden, wird nicht eingegangen. Auch die Beschreibung von Funktionen durch Merkmale wird nicht detailliert erklärt. In [HAD15] wird dargestellt, welche Standardisierungsbemühungen aktuell unternommen werden, um Merkmale einheitlich zu verwenden. Dabei werden zwei Modelle verwendet, um ein System zu beschreiben: • Kompositionelle Struktur, in der die Elemente durch Bestandsbeziehungen (besteht aus) verbunden sind, • Funktionale Struktur, in der die Elemente durch funktionale Verbindungen verbunden sind. [HAD15, S. 10] Dabei wird die funktionale Verbindung zwischen Elementen eines Systems wie folgt definiert: „Über die funktionalen Verbindungen zwischen Systemelementen erfolgen die Interaktionen zwischen den Systemelementen. Diese Interaktion kann sich auf Material, Energie oder Information beziehen, wobei diese jeweils als Ausgangsgrößen von Systemelementen über 4 Ansätze des funktionsorientierten Engineerings 52 die funktionalen Verbindungen anderen Systemelementen als Eingangsgrößen zugeführt werden. Quellen der Eingangsgrößen von Systemelementen können Eingangsgrößen des Systems, Zustandsgrößen des Systems oder Ausgangsgrößen von anderen Systemelementen sein. Ausgangsgrößen von Systemelementen können auch Zustandsgrößen des Systems oder Ausgangsgrößen des Systems sein.“ [HAD15, S. 13] Der Autor erklärt weiterhin, dass eine Beschreibung der Interaktionen oft mit Mitteln der Verhaltensbeschreibung erfolgt [HAD15, S. 13]. In diesem Zusammenhang wird eine Funktion als eine lösungsneutral beschriebene Beziehung zwischen Eingangsgrößen und Ausgangsgrößen eines Systems definiert [HAD15, S. 15]. Zudem lassen sich die Funktionen klassifizieren [HAD15, S. 16]: • Nach Zuordnung zu einem System, das diese Funktion bereitstellt (z. B. Anlagenfunktion, Steuerungsfunktion), • Nach Typ der Eingangs- bzw. Ausgangsgrößen (z. B. Material, Energie, Information), • Nach dem zeitlichen Verhalten der Funktion (z. B. zustandsbehaftet/zustandsfrei, kontinuierlich/diskret). Zur vollständigen Beschreibung einer Funktion werden die Eingangs- und Ausgangsgrößen der Funktion beschrieben. Material, Energie und Information werden somit als Merkmalträger dargestellt [HAD15, S. 94]. Die Ausführung von Funktionen eines Systems wird durch Prozesse beschrieben: „Ein Prozess beschreibt die Ausführung von einer oder mehreren Funktionen eines Systems mit zeitlichem und räumlichem Bezug, mit Anfangs- und Endzustand der Systemumgebung.“ [HAD15, S. 16] Hadlich beschreibt die Verbindung der von ihm genutzten Modelle durch die Zuweisung einer Technischen Ressource zu einem Prozessoperator (beides Elemente der Formalisierten Prozessbeschreibung zur Darstellung der funktionalen Struktur). Der Prozess, der durch den Prozessoperator repräsentiert wird, wird dann auf dieser Technischen Ressource ausgeführt. Diese Zuordnung kann gemäß Hadlich erst erfolgen, nachdem ein Strukturmodell des Systems existiert und die verwendeten Technischen Ressourcen definiert wurden. Durch die Zuordnung wird eine Beziehung zwischen Elementen des Funktionsmodells und Elementen des Strukturmodells definiert [HAD15, S. 34]. Bei der Verwendung von unterschiedlichen Modellen im Engineering adressiert Hadlich ein Problem, das dabei auftreten kann. Durch unterschiedliche Sichten der beteiligten Gewerke auf die verschiedenen Modelle können diese Modelle sowohl die gleichen Systemelemente als auch unterschiedliche Systemelemente beinhalten. Daraus ergibt sich das Problem, dass der Zusammenhang zwischen den verschiedenen Sichten als wichtige Information dokumentiert werden muss. Diese Dokumentation erfolgt sowohl in den jeweiligen Modellen (z. B. in der formalisierten Prozessbeschreibung durch Referenz auf die Technische Ressource), durch Namenskonventionen für die verschiedenen Beschreibungsmittel (z. B. Bezeichnungen von Verhaltensdarstellungen referenzieren das jeweilige Systemelement) als auch durch Dokumentation außerhalb der Beschreibungsmittel [HAD15, S. 41].

4 Ansätze des funktionsorientierten Engineerings 53

4.3.10 FuSE – Function Based Systems Engineering In [HMS+07] wird ein Vorgehen beschrieben, das die Systemfunktion in den Fokus der Entwicklung eines Systems stellt. Dabei wird ein Funktionsmodell verwendet, das als grafische Darstellung der Flüsse von Energie, Material und Information verstanden werden kann und die an diesen Flüssen vorgenommenen Beeinflussungen näher beschreibt [HMS+07]. Im Unterschied zur [VDI 2206] wird in [HMS+07] ein standardisierte Sammlung von Funktions- und Flussbezeichnungen vorgeschlagen. Die Verwendung einer solchen Taxonomie ist notwendig, um den Prozess der Funktionsmodellierung zu formalisieren. Die Autoren stellen fest, dass durch die Verwendung von Schaltplänen und Flussdiagrammen (im Sinne von Fluid-Plänen oder R&I-Fließschemata) in einer frühen Phase des Engineerings die technische Lösung einer Funktion teilweise vorweg genommen wird. Dies ist nur möglich, wenn (teils unzutreffende) Annahmen getroffen werden, wie die technische Lösung aussehen kann [HMS+07]. Daher wird die Verwendung einer weniger lösungsnahen Beschreibungsform in der Entwurfsphase gefordert. Die Autoren erstellen dazu eine Art Verfahrensfließschema, in dem die Flüsse und Funktionen in Beziehung gesetzt werden. Dieses Funktionsmodell wird im Weiteren dazu genutzt, den Modellierungsprozess des Systemverhaltens zu unterstützen. Dafür wird ein Verhaltens- Modell erstellt, welches auf dem Funktionsmodell aufbaut. Das Verhaltensmodell beschreibt die Flüsse zwischen den Funktionen im Detail und ordnet diesen Flüssen Zustände zu. Das Verhalten wird zudem als mathematische Gleichung in der Funktion abgebildet und setzt Ein- und Ausgangsgrößen zueinander in Beziehung. Für jedes so beschriebene Funktionselement wird anschließend systematisch ein Lösungselement gesucht, welches die definierten Bedingungen des Verhaltensmodells erfüllt. Zusammenfassend wird in [HMS+07] ein Vorgehen gezeigt, wie im „Function-Based Systems Engineering“ die beschriebenen Modelle systematisch entwickelt werden können. Für die vorliegende Arbeit sind das Aufstellen des Funktionsmodells und das Ableiten eines Verhaltensmodells aus dem Funktionsmodell von Interesse. Auch die Verwendung einer standardisierten Taxonomie zur Beschreibung der Funktionen und der Flüsse scheint zielführend, da somit eine standardisierte Funktionsbibliothek aufgebaut werden kann. Das Modellierungsvorgehen aus [HMS+07] beschränkt sich bisher auf eine rein mathematische Modellierung, eine Integration in ein Werkzeug wird angestrebt.

4.3.11 Himmler – Function Based Engineering In [HLO+14] wird ein funktionsorientierter Ansatz für das Engineering von Produktionssystemen vorgestellt. Dabei wird ein Vergleich zwischen dem komponentenbasierten Engineering und dem funktionsorientierten Engineering mit den damit verbundenen mechatronischen Objekten angestellt. Der Schwerpunkt der Betrachtungen liegt dabei auf einer möglichen Wiederverwendung der mechatronischen Objekte im Engineering eines neuen Produktionssystems. Es wird ein dreistufiges Verfahren vorgeschlagen, mit den folgenden Phasen: • Definition: die funktionale Struktur eines Produktionssystems wird entworfen. Es resultiert daraus eine Liste von Funktionen, die potentiell von dem zu entwickelnden System ausgeführt werden können. Funktionen können dabei als optional markiert werden.

4 Ansätze des funktionsorientierten Engineerings 54

• Standardisierung: für jede Funktion aus der funktionalen Struktur werden Standardobjekte definiert. Diese Standardobjekte können in der Realisierung verwendet und mehrfach genutzt werden. • Realisierung: die ausgewählten Standardobjekte werden durch Komponenten realisiert. Dazu muss jeder Funktion, repräsentiert durch Standardobjekte, genau eine Komponente zugeordnet werden. Diese Komponente muss die Funktion exakt erfüllen. Zudem wird ein Objektmodell für diese funktionsorientierte Beschreibung vorgestellt und an einem Beispiel angewendet. Dieses Objektmodell unterstützt das beschriebene funktionsorientierte Vorgehen, indem es alle notwendigen Informationen über die Funktionen und die Komponenten, die diese Funktionen ausführen, aufnehmen kann. Zudem werden verschieden Sichten (Funktionale Sicht, Komponentensicht und Produktionssicht) auf das Produktionssystem für die unterschiedlichen Beteiligten am Engineering ermöglicht. Die Unterteilung in Funktionen und mechatronische Objekte erscheint zielführend, um die gestellten Anforderungen an das Konzept zu erfüllen. Lediglich die eins zu eins Zuordnung von Funktionen und Komponenten schränkt den Lösungsraum erheblich ein, erleichtert aber die Erstellung der Algorithmen der Lösungsfindung. Die beschriebenen Modelle aus [HLO+14] sind auch für die vorliegende Arbeit nutzbar.

4.3.12 Zusammenfassung der betrachteten Ansätze In Tabelle 4-1 werden die betrachteten Ansätze aus dem vorliegenden Abschnitt zusammengefasst, um Gemeinsamkeiten und Unterschiede in der Modellierung und der verwendeten Modellierungselemente darzustellen. Daraus werden im Anschluss Forderungen abgeleitet, wie eine optimale Modellierung im Engineering von Produktionssystemen unterstützt werden kann. In der Tabelle 4-1 wird dazu aufgezeigt, welche Modelle in den unterschiedlichen Ansätzen verwendet wurden. Dabei wird zwischen Funktions-, Struktur- und Verhaltensmodell differenziert. Im Sinne der vorliegenden Arbeit beschreibt ein Funktionsmodell die Funktionen eines Produktionssystems mit den dazu gehörigen Ein- und Ausgangsflüssen von Stoff, Energie und Information. Ein Strukturmodell beschreibt eine Aufbaustruktur eines Produktionssystems mit seinen Komponenten. Das Verhaltensmodell beschreibt das gesteuerte Verhalten eines Systems. Die drei Modelle können hierarchisch gegliedert sein und eine Bildung von Modulen unterstützen. In Tabelle 4-1 werden neben den verwendeten Modellen der unterschiedlichen Ansätze auch das Modellierungsvorgehen betrachtet. Im Sinne der vorliegenden Arbeit ist hier entscheidend, ob dieses Vorgehen die Funktion im Mittelpunkt der Modellierung sieht, siehe Spalte Funktionszentrierung in Tabelle 4-1. In der Spalte PPR-Konzept wird angegeben, ob der betrachtete Ansatz das Produkt-Prozess-Ressourcen-Konzept berücksichtigt. Die Spalte Funktionsbibliothek gibt Auskunft darüber, ob im betrachteten Ansatz eine Funktionsbibliothek genutzt wird und ob standardisierte Elemente dafür vorgegeben werden. Zudem wird betrachtet, welche Komponenten im Fokus des betrachteten Ansatzes stehen, dies ist in der Spalte Komponentenabbildung aufgeführt.

4 Ansätze des funktionsorientierten Engineerings 55

Tabelle 4-1: Zusammenfassung der untersuchten Ansätze

Funktions- PPR- Funktions- Komponenten- Ansätze Modelle zentrierung Konzept bibliothek abbildung VDI 2206 • Funktionsmodell ja ja keine nein Definition VDI 2222 • Funktionsmodell ja nein allgemeiner nein Funktionen Unterteilung der 6 • Strukturmodell AQUIMO nein nein keine Basiskomponenten • Verhaltensmodell nach Funktionen • Funktionsmodell Funktionsbaukasten mechatronische MEPROMA ja nein • Strukturmodell vorgesehen Objekte • Strukturmodell PPR-Datenbasis mechatronische Kiefer nein ja • Verhaltensmodell vorgesehen Funktionsgruppen • Funktionsmodell Automatisierungs- Reuter nein nein 8 Grundfunktionen komponenten mit • Strukturmodell Grundfunktionen Unterteilung in • Funktionsmodell mechatronische Gehrke ja ja Hauptfunktionen • Funktionsmodule Strukturmodell und Hilfsfunktionen • Funktionsmodell Hadlich • Strukturmodell nein ja keine ja • Verhaltensmodell • Funktionsmodell Taxonomie FuSE ja nein nein • Verhaltensmodell vorgesehen Kundenspezifische Funktionen • Funktionsmodell mechatronische Himmler ja nein unterteilt in • Strukturmodell Objekte Funktionen und Unterfunktionen

Aus den Forderungen aus Abschnitt 3.4 nach einem funktionsorientierten und Gewerke- übergreifenden Modell, welches die Informationen an den Schnittstellen der Gewerke abbilden kann und die Funktion des Produktionssystems im Mittelpunkt der Modellierung stellt, lassen sich folgende Anforderungen an den Aufbau eines solchen Modells stellen, die sich auch durch die Betrachtung der Gemeinsamkeiten und Unterschiede der vorgestellten Ansätze stützen lassen. Keiner der vorgestellten Ansätze erfüllt diese Forderungen vollständig, aber jeder betrachtete Ansatz kann einen Teil dazu beitragen: • Ein Gewerke-übergreifendes Modell muss die Funktion im Zentrum haben, um den wachsenden Anforderungen durch den intensiven Datenaustausch der Gewerke durch die steigende Parallelisierung im Engineering der immer komplexeren Produktionssysteme begegnen zu können: o Die Funktion dient im Datenaustausch zwischen den Gewerken als durchgängiges gemeinsamen Kommunikationselement, über die Phasen des Engineerings hinweg, o Auch in anderen Domänen, wie Prozesstechnik und Gebäudeleittechnik, ist dieses funktionsorientierte Prinzip etabliert und wird im Engineering angewendet, o Das PPR-Konzept ist dabei anzuwenden, da sich die Funktion umfassend betrachtet aus dem Prozess, den Ein- und Ausgangsprodukten, sowie der ausführenden Ressource zusammensetzen lässt, o Eine Nutzung von Funktionsbibliotheken ist in der Modellierung vorzusehen, um eine standardisierte Abbildung der Funktionen zu gewährleisten und den Datenaustausch zwischen den Beteiligten weiter zu erleichtern.

4 Ansätze des funktionsorientierten Engineerings 56

• Für ein integriertes Modell aller Gewerke ist mehr als ein Funktionsmodell notwendig: o Wie in Abschnitt 3.4 gezeigt, muss ein Gewerke-übergreifendes Modell mindestens die Informationen an den Schnittstellen der Gewerke übertragen können, welche sich in die folgenden Teile aufteilen lassen: . Stückliste (Komponenten des Produktionssystems und deren Aufbaustruktur) . Signalliste (elektrotechnische/logische Daten der Komponenten) . Ablaufbeschreibung (beabsichtigtes Verhalten des Produktionssystems) o Diese Informationen an den Schnittstellen der Gewerke lassen sich in einem Modell abbilden, das aus den folgenden Teilemodellen zusammengesetzt wird: . Funktionsmodell (Abbildung der Funktionshierarchie), . Strukturmodell (Abbildung der Aufbaustruktur der Komponenten), . Verhalten (Abbildung des gesteuerten Verhaltens in Form von Abläufen mit Verwendung der Signalinformationen der Komponenten) Diese Forderungen an ein Konzept werden im Kapitel 5 genutzt, um das Modell für ein Produktionssystem aufzustellen, das ein integriertes, Gewerke-übergreifendes funktionsorientiertes Engineering ermöglicht. In Abschnitt 4.5 werden weitere, aktuelle Engineering-Ansätze betrachtet, die nicht den funktionsorientierten oder mechatronischen Ansatz verfolgen, um sich gegen diese abzugrenzen oder mit ihnen Gemeinsamkeiten zu finden. In Abschnitt 4.4 wird zunächst auf die Auswirkungen des funktionsorientierten Engineerings auf den Engineering-Workflow eingegangen und anschließend untersucht, wie Abläufe innerhalb eines Produktionssystems beschrieben werden können, um daraus abzuleiten, wie das Funktionsmodell eines Produktionssystems in einem geeigneten Beschreibungsmittel abgebildet werden kann.

4.4 Beschreibung von Abläufen im Engineering-Workflow Im vorliegenden Abschnitt werden unterschiedliche Beschreibungsmittel untersucht, mit denen es möglich ist Abläufe innerhalb eines Produktionssystems zu beschreiben. Zunächst wird auf die Auswirkungen der Funktionsorientierung auf den Engineering-Workflow eingegangen, um zu klären, welche Anforderungen bei der Modellierung beachtet werden müssen.

4.4.1 Auswirkungen der Funktionsorientierung auf das Engineering Aus den Domänen der Prozessindustrie und der Gebäudeleittechnik sind die Vorteile der funktionsorientierten Planung bereits bekannt. Auf Grund der starken Fokussierung des Maschinenbaus als führendes Gewerk der Fertigungstechnik auf die CAD-Zeichnung werden diese Vorteile hier selten genutzt. Verzichtet man in der Planung auf das systematische Betrachten der Anforderungen und die daraus entstehenden Funktionen [VDI 2221] und fokussiert sich zu stark auf eine Komponenten- oder Geräte-orientierte Lösung, so schränkt man schon in einer frühen Phase der Planung den Lösungsraum zur Erfüllung der gestellten Anforderungen ein. „Die Darstellung in einem lösungsneutralen Beschreibungsmittel verhindert implizite Annahmen und Kommunikationsprobleme, die bei der Zusammenarbeit verschiedener Gewerke auftreten.“ [FUF+09] Wird in der Planung auf die Nutzung oder die Dokumentation eines Funktionsmodells verzichtet, so bringt das einen weiteren Nachteil mit sich. Es existiert kein Beschreibungsmittel, in dem die ursprünglichen Anforderungen und die daraus abgeleiteten Funktionen dokumentiert werden. Folglich ist dieses Modell während des Betriebes, der Wartung oder der Umplanung eines solchen Produktionssystems nicht verfügbar. Die daraus ableitbaren Informationen könnten bei der Neubeschaffung von Geräten eine wichtige Rolle 4 Ansätze des funktionsorientierten Engineerings 57 spielen, da darin enthalten ist, welche Anforderungen an das Gerät ursprünglich gefordert wurden. Daher wird in manchen Fällen nach der Inbetriebnahme eines Produktionssystems ein solches Funktionsmodell aufwändig erstellt, um diese Informationen zu dokumentieren. Wäre das Modell in einer frühen Phase des Engineerings entstanden und sukzessive mit dem Fortschritt der Planung mit aufgewachsen, so wäre der Aufwand für dessen Erstellung geringer, da alle notwendigen Informationen im Engineering-Prozess erzeugt und somit vorhanden wären. Im Gegensatz dazu müssten diese im Nachhinein neu erstellt oder nachgefordert werden.

4.4.2 Bedeutung der Beschreibung von Abläufen für das Engineering Die Verwendung von Ablaufbeschreibungen in der Planung von Produktionssystemen ist eine essentielle Anforderung an das Engineering. Dabei wird die Funktionen eines Produktionssystems in ihre Teilfunktionen zerlegt und in eine Abfolge gebracht. Wird eine Funktion innerhalb eines Produktionssystems umgesetzt, indem ihr Komponenten zugewiesen werden, die diese Funktion erfüllen, so spricht man von einem Prozess, der durch die Komponente ausgeführt wird. Im Unterschied zur Funktion lassen sich einem Prozess beispielsweise eine Zeitdauer zuweisen. Dies ist bei der Funktion noch unbekannt, da der Funktion als abstraktem Planungselement keine reale Komponente zur Umsetzung zugeordnet ist, welche einen wesentlichen Einfluss auf die Dauer eines solchen Prozesses und die darin enthaltenen Prozessschritte hat. Durch die Beschreibung von Funktionen und deren Ablaufreihenfolge kann in der Entwurfsphase des Systems konzeptionell und lösungsneutral geplant werden, welche Prozesse das zukünftige System in welcher Reihenfolge durchführen soll. Diese Beschreibung dient im weiteren Engineering-Prozess der Gewerke-übergreifenden Verständigung über die Funktionen und kann im weiteren Verlauf des Engineerings dem SPS-Programmierer zur detaillierten Ausgestaltung des Steuerungsprogramms dienen. Ein Ansatz zur Beschreibung von Abläufen im Engineering ist das PPR-Konzept (Produkt, Prozess und Ressource). Das PPR-Konzept wird unter anderem in [SPS+14] aufgenommen und um Skills (Fähigkeiten) erweitert. Abbildung 4-13 zeigt unter anderem den Zusammenhang zwischen Prozess und Ressource.

Abbildung 4-13: PPR und Skills nach [SPS+14] Mit dieser Form der Modellierung ist es möglich, auch komplexe Abläufe der Umwandlung von Produkten durch Prozesse darzustellen. Die Ressourcen lassen sich über ihre Fähigkeiten den Prozessen zuordnen. Eine mögliche Form der Darstellung dieser Modelle % mit Hilfe der Formalisierten Prozessbeschreibung wurde in Abschnitt 3.3.3 erklärt. In [HIL15 ] wird ausführlich aufgezeigt, welche Vorteile mit der Nutzung von Ablaufbeschreibungen im Engineering einhergehen.

4 Ansätze des funktionsorientierten Engineerings 58

Die Wichtigsten sind hier aufgeführt: • prozessorientierte Sichtweise im Entwurfsprozess des Produktionssystems (z. B. zur lösungsneutralen Darstellung der Prozesse), • gemeinsames Informationsmodell unter den Gewerken (z. B. um Bezeichnungen der Ressourcen abzustimmen), • strukturierte, teils formale Beschreibung der Abläufe innerhalb des Produktionssystems (z. B. ersetzt die Beschreibung in Fließtext), • PPR-Elemente können als Träger von Merkmalen fungieren (z. B. Ressourcen durch Anforderungen näher beschreiben), • bewährte Abläufe können wiederverwendet werden. Wie aus der Aufzählung zu entnehmen ist, dient neben den Funktionen die Beschreibung von Abläufen im Engineering-Prozess der gemeinsamen interdisziplinären Kommunikation und kann zum besseren Datenaustausch zwischen den Gewerken beitragen.

4.4.3 Betrachtung unterschiedlicher Beschreibungsmittel für Abläufe Im Engineering-Prozess können in unterschiedlichen Phasen verschiedene Beschreibungsmittel zur Abbildung von Abläufen zum Einsatz kommen. Einige typische Beschreibungsmittel sind in Abbildung 4-14 dargestellt und den Phasen des Engineerings zugeordnet.

Abbildung 4-14: Beschreibungsmittel für Abläufe in der Planung von Produktionssystemen [DRA10] Auf ausgewählte Beschreibungsmittel, auch aus der Abbildung 4-14, wird im Folgenden kurz eingegangen.

4.4.3.1 Gantt- und PERT Charts Im Gantt-Diagramm werden Aktivitäten in Form von Balken in einer Sequenz dargestellt, siehe Abbildung 4-15. Das Gantt-Diagramm kann in frühen Phasen des Engineerings zur Beschreibung von Reihenfolgen und Ausführungszeiten einer Abfolge von Aktivitäten genutzt werden, beispielsweise für Fertigungsschritte in einer Produktionsanlage. Parallel ablaufende Prozesse können dargestellt werden, diese entsprechen einer logischen UND-Verknüpfung. 4 Ansätze des funktionsorientierten Engineerings 59

Alternativ-Verzweigungen (logisches ODER) lassen sich mit diesem Beschreibungsmittel nicht darstellen.

@ Abbildung 4-15: Beispiel eines Gantt-Diagramms [VIS10 ] Ähnlich dem Gantt-Diagramm lässt sich das PERT-Diagramm (PERT = Program Evaluation and Review Technique) einsetzen. Das PERT-Diagramm ist eine Form der Netzplantechnik [SCH99]. In der Modellierung mit diesem Beschreibungsmittel werden die Aktivitäten in Blöcken abgebildet, die mit Kanten verbunden sind. Die einzelnen Blöcke enthalten detaillierte Angaben über die zeitlichen Bedingungen und die kausalen Zusammenhänge der abgebildeten Prozessschritte, siehe Abbildung 4-16.

@ Abbildung 4-16: Elemente des Beschreibungsmittels PERT-Diagramm [VIS10 ] Auch hier lassen sich parallele Abläufe modellieren. Alternative Abläufe können nicht abgebildet werden, da keine Bedingungen für das Nutzen eines Pfades angegeben werden können. Beide Beschreibungsmittel haben keinen Bezug zum Produkt oder der den beschriebenen Prozess ausführenden Ressource.

4.4.3.2 Sequential Function Charts Sequential Function Charts (SFC) sind als eine Programmiersprache in der [IEC 61131-3] beschrieben und auch als Ablaufsprache bekannt [SCH99]. Die Ablaufsprache wird genutzt, um sequentielle Abläufe zu beschreiben, in denen Schritte mit dazugehörigen Aktionen als Folge ablaufen. Die einzelnen Schritte sind durch Bedingungen (Transitionen) getrennt. Es lassen sich sowohl parallel ablaufende als auch alternative Schrittfolgen damit abbilden. In Abbildung 4-17 sind die einzelnen Elemente der Ablaufsprache zu erkennen.

Abbildung 4-17: Elemente des Sequential Function Charts [DRA10]

4 Ansätze des funktionsorientierten Engineerings 60

SFC eignen sich zur Beschreibung von gesteuertem Verhalten von Systemen. Ein Bezug zum Produkt, das in dem System gefertigt wird, ist nur indirekt über die Sensorinformationen herzustellen, die in den Transitionsbedingungen verarbeitet werden. Über die Transitionsbedingungen und die Aktionen der einzelnen Schritte lässt sich ein Bezug zu den Technischen Ressourcen des Systems herstellen, die als Sensoren und Aktoren die notwendigen Signale liefern und empfangen. Ein rechnerinterpretierbarer Austausch der @ Daten ist XML-basiert über das Format PLCopen XML möglich, vgl. [PLC17 ; DRA10; @ AUT17B ].

4.4.3.3 UML-Aktivitätsdiagramme Das Aktivitätsdiagramm ist ein Diagrammtyp der Unified Modeling Language (UML), der sich mit der Modellierung der dynamischen Sichtweise auf ein System befasst. Der Fokus wird dabei auf das Verhalten des Systems gelegt [CZU10, S. 117]. Aktivitätsdiagramme sind aus folgenden Elementen (siehe dazu Abbildung 4-18) aufgebaut: Aktionen, Aktivitätsknoten, Flüsse, Objektknoten, Kontrollknoten. Innerhalb einer Aktion werden Werte eines Flusses transformiert. Die Elemente des Flusses können Informationen oder Objekte sein. Die Aktionen lassen sich zu Aktivitäten zusammenfassen. Objektknoten geben an, welche Objekte in den Aktionen oder Aktivitäten erzeugt oder verarbeitet werden. Kontrollknoten werden verwendet, um zu kennzeichnen, wo eine Aktivität beginnt (Abbildung 4-18, schwarzer Kreis) und wo diese endet (Abbildung 4-18, grüner Kreis mit schwarzem Punkt).

@ Abbildung 4-18: Elemente des UML-Aktivitätsdiagramms [VIS10 ] Als weiteres Element ist ein Entscheidungsknoten in Abbildung 4-18 aufgeführt. Die Bedingungen für die Entscheidung können auf den Pfeilen notiert werden. Die Anwendung und damit auch die rechnergestützte Austauschbarkeit der Modelle in UML ist beispielsweise in der Systems Modeling Language (SysML) möglich [BBL+16]. Dafür wurden unter anderem die vorgestellten UML-Aktivitätsdiagramme auf die Verwendung in verschiedenen Domänen zur Modellierung komplexer Systeme und deren Engineering angepasst und ein entsprechendes Metamodell für deren Erstellung entwickelt [BBL+16].

4.4.3.4 BPMN – Business Process Model and Notation Die BPMN ist ein grafisches Beschreibungsmittel, das sich für die Modellierung und Dokumentation von Geschäftsprozessen und Arbeitsabläufen einsetzen lässt [OMG16@]. Abläufe werden in der BPMN als eine Folge von Aktivitäten beschrieben. In Abbildung 4-19 ist eine solche Folge zu erkennen, die aus einem Event (Start-Event) heraus gestartet wird und wieder in einem Event endet (End-Event). Eine solche Folge wird innerhalb eines Pools 4 Ansätze des funktionsorientierten Engineerings 61 zusammengefasst. Dieser Pool kann einem System (zum Beispiel: einer Person oder einer Organisation) zugeordnet werden.

@ Abbildung 4-19: Darstellung von Aktivitäten und Events in BPMN [WIK17A ] Es ist zudem möglich, Artefakte zu beschreiben und in die Folge der Abläufe zu integrieren. Abbildung 4-20 zeigt ein Beispiel für diese Objekte.

@ Abbildung 4-20: Darstellung von Artefakten in BPMN [WIK17A ] Die Darstellungen der BPMN sind semantisch nicht eindeutig, da diese nicht genormt sind. Je nach Anwendungsfall unterscheiden sich die verwendeten Symbole und deren Bedeutung. Es existieren zahlreiche Werkzeuge, wie beispielsweise das „Free BPMN 2.0 @ @ Tool“ [CAM17 ] oder das „BPMN 2.0 rendering toolkit“ [BPM17 ], die die Erstellung von BPMN-Diagrammen unterstützen und einen XML-basierten Austausch der Daten zur Verfügung stellen.

4.4.3.5 Formalisierte Prozessbeschreibung Die Formalisierte Prozessbeschreibung (FPB) gemäß [VDI/VDE 3682-1] und ihre Symbolik wurden bereits in Abschnitt 3.3.3 detailliert vorgestellt. An dieser Stelle wird ergänzend dazu auf die Eignung der FPB zur Abbildung von Abläufen eingegangen. Die FPB bietet die Möglichkeit, ohne eine Erweiterung des Zeichensatzes, parallele und alternative Verzweigungen innerhalb von Prozessen zu modellieren. Dies wird durch die Vorgabe einer eindeutigen Modellierungsweise erreicht, die im Folgenden kurz vorgestellt wird. Parallele Abläufe Durch die Verwendung eines teilweise gemeinsamen Flusses in der Darstellung des Prozesses wird ein paralleler Prozessablauf modelliert. Dadurch kann die parallele Zuführung von zwei Produkten in einen Prozessschritt, sowie eine Entstehung von zwei Produkten aus einem Prozessschritt (Abbildung 4-21) abgebildet werden. Ebenso ist die parallele Ausführung von zwei Prozessschritten darstellbar (Abbildung 4-22). 4 Ansätze des funktionsorientierten Engineerings 62

Abbildung 4-21: Parallele Zuführung von Abbildung 4-22: Parallele Prozessschritte mit Produkten in einen Prozessschritt und Entstehung zugeführtem und entstehendem Produkt von zwei Produkten

Alternative Abläufe Alternative Abläufe werden grafisch durch voneinander getrennte Flüsse dargestellt. Hier ist zu beachten, dass die Systemgrenze in diesem Fall nicht immer als Bilanzgrenze verwendet werden kann. Eine Darstellung von alternativen Prozessschritten mit Ein- und Ausgangsprodukten ist möglich (Abbildung 4-23). Ebenso kann auf diese Weise ein Prozessschritt mit alternativen Ein- und Ausgangsprodukten abgebildet werden (Abbildung 4-24).

Abbildung 4-23: Alternative Prozessschritte Abbildung 4-24: Alternative Ein- und Ausgangsprodukte eines Prozessschrittes

4.4.3.6 Zusammenfassung der betrachteten Beschreibungsmittel In Tabelle 4-2 werden die Kriterien für die vorgestellten Ablaufbeschreibungen im vorliegenden Anwendungsfall aufgeführt und für das jeweilige Beschreibungsmittel bewertet. Als Bewertungskriterien werden die Komplexität der Sprache und der Beschreibungselemente, die Darstellungsform, der Normungsgrad, die Abdeckung des PPR- Konzepts und die Bewertung der Austauschbarkeit des erstellten Modells benutzt, welche sich aus den Einflussfaktoren zur Effizienz des Engineerings ableiten lassen, vgl. Abschnitt 1.4. Damit sich ein Beschreibungsmittel in der Praxis durchsetzen kann, darf die Komplexität des Beschreibungsmittels nicht zu hoch sein, da ansonsten separate Schulungen der Mitarbeiter notwendig werden. Es sollte schnell und intuitiv erlernbar sein und über einen begrenzten und fest definierten Satz an Symbolen verfügen, um den Raum für Interpretationen klein zu halten. Eine grafische Darstellung ist in Anbetracht der großen Datenmengen unverzichtbar, um die Informationen zu visualisieren und somit für den Betrachter erfassbar zu machen. Eine Normung des Beschreibungsmittels ist von Vorteil, da 4 Ansätze des funktionsorientierten Engineerings 63 somit der Satz der Symbole fest definiert und nur in Ausnahmefällen erweitert werden kann. Somit ist eine verlässliche Kommunikation gewährleistet. Eine hohe Abdeckung des PPR- Konzeptes ist anzustreben, vgl. Abschnitt 4.3.12 und 4.4.2, damit die Forderungen aus dem Engineering im vollen Maße umgesetzt werden können. Zudem ist entscheidend, dass die Ablaufbeschreibung rechnergestützt ausgetauscht und ausgewertet werden kann.

Tabelle 4-2: Zusammenfassung der Beschreibungsmittel für Abläufe

Komplexität Darstellung Normung PPR-Konzept Austauschbarkeit über Gantt/PERT Chart niedrig grafisch nicht genormt Prozesse PLCopen XML über SFC mittel grafisch genormt Prozesse PLCopen XML UML- Produkte und hoch grafisch genormt UML Aktivitätsdiagramm Prozesse hoch - durch Produkte und die große Prozesse lassen nicht genormt, Anzahl an sich abbilden, der Basissatz XML-basierte BPMN Zeichen und grafisch Ressourcen an Zeichen ist Austauschdatei deren können über häufig gleich differenzierter Pools abgebildet Bedeutung werden. XML-basierte volle FPB mittel grafisch genormt Ansätze Unterstützung vorhanden

In Anbetracht der gestellten Forderungen erfüllt die Formalisierte Prozessbeschreibung die genannten Punkte besser als die verglichenen Beschreibungsmittel. Die Komplexität des Beschreibungsmittels FPB wird als mittel bewertet. Es verfügt, verglichen mit den anderen Beschreibungsmitteln wie BPMN und UML- Aktivitätsdiagrammen, mit einem Umfang von acht Symbolen über einen kleinen Satz an verwendbaren Zeichen. Dennoch sind damit auch komplexe Zusammenstellungen von Abläufen mit alternativen und parallelen Verzweigungen abbildbar. Für die Umsetzung existiert ein begrenzter Satz an Anwendungsregeln, die in der dazugehörigen Norm zu finden sind. Die grafische Darstellung ist durch die geringe Zahl an verwendeten Symbolen als einfach zu verstehende, grafische Prozessdarstellung anzusehen [VDI/VDE 3682-1]. Durch die vorhandene Normung der Symbole und deren Anwendung ist sichergestellt, dass der Interpretationsspielraum bei der Erstellung und der Auswertung der Abgebildeten Abläufe möglichst gering ist. Die vollständige Unterstützung des PPR-Konzeptes ist der wesentliche Vorteil gegenüber den anderen Beschreibungsmitteln. Damit wird ein funktionsorientiertes Engineering vollständig unterstützt, wie in Abschnitt 4.4.2 hergeleitet ist. Für den rechnergestützten Austausch existieren bereits XML-basierte Ansätze, vgl. [JCS+12; STR14]. Daher wird im Folgenden die Nutzung der FPB als Mittel zur Beschreibung von Abläufen im Funktionsmodell genutzt.

4 Ansätze des funktionsorientierten Engineerings 64

4.5 Abgrenzung von weiteren Industrie-4.0-Ansätzen Im vorliegenden Abschnitt wird das funktionsorientierte Engineering von weiteren aktuellen, Industrie-4.0-relevanten Ansätzen abgegrenzt, vgl. [VDI15@]. Es werden dabei Gemeinsamkeiten und Unterschiede bei Methoden und Modellen aufgezeigt. Dazu werden in den folgenden Abschnitten die Ansätze der Modularisierung und Service-orientierte Ansätze betrachtet.

4.5.1 Abgrenzung zur Modularisierung von Produktionssystemen Die Bildung von Modulen im Engineering ist ein effizientes Vorgehen zur Reduzierung von Aufwänden. Die damit verbundene Modularisierung der Produktionssysteme ist eine Thematik mit stetig wachsender Bedeutung, wie unterschiedliche Forschungsprojekte zeigen. Um Systeme flexibler zu gestalten, das Engineering zu vereinfachen und die Wiederverwendbarkeit von Lösungen zu steigern, werden vermehrt modulare Ansätze @ genutzt [CHSC15 ]. Auf einige ausgewählte Ansätze der Modularisierung wird im Folgenden eingegangen.

4.5.1.1 Mahler – Automatisierungsmodule für ein funktionsorientiertes Automatisierungsengineering [MAH14] verwendet zur Optimierung des Engineerings Automatisierungstechnische Module. In denen werden die Funktionen der Automatisierungstechnik (AT) modular gekapselt, um AT-Probleme zu lösen. Ein solches Modul enthält eine Eingabe- und eine Ausgabeeinheit sowie die AT-Funktion, die die Berechnungen durchführt und diese Informationen mit Hilfe der Übergabeeinheit an die SPS weitergibt. Zudem können Informationen über die Verkabelung der einzelnen Elemente enthalten sein. AT-Module können mit anderen Modulen gemeinsam eingesetzt werden und in Bibliotheken als Vorlage zur Planung abgelegt werden. Der Schwerpunkt in der Arbeit von Mahler liegt nicht in der Modellierung der dafür notwendigen Informationen oder in der Integration in den bestehenden Engineering-Workflow für unterschiedliche Engineering-Werkzeuge. Für den vorgestellten Ansatz von Mahler ist es zudem notwendig zu wissen, welche Hardware explizit verwendet wird, um die geplanten Funktionen auszuführen, da es für die Planung der Verkabelung in einem AT-Modul abhängig ist, wie viele Anschlüsse auf der Eingabe- oder Ausgabeeinheit geplant werden müssen (z. B. Sensor mit 2- oder 3-Leiter-Anschluss). Daher eignet sich die Verwendung der vorgestellten AT-Module besonders in einer Phase des Engineerings, in der die für die Lösung des AT-Problems notwendige Hardware bereits ausgewählt wurde, wie dem Detail-Engineering. Die gezeigte Methodik ist besonders effektiv bei der Erstellung des Steuerungscodes, da dieser in dem AT-Modul zur geplanten Funktion enthalten ist und somit schnell und fehlerfrei durch den Planer zusammengestellt werden kann.

4.5.1.2 Holm – Aufwandsbewertung im Engineering modularer Prozessanlagen [HOL16] beschreibt in seiner Arbeit, wie mit Hilfe des Ansatzes DIMA (Dezentrale Intelligenz für modulare Anlagen) und durch eine modulare Planung von Produktionssystemen die Engineering-Aufwände in eine frühere Phase der Planung verschoben werden können. Dadurch kann der Engineering-Prozess der Produktionssysteme wesentlich effizienter ausgeführt werden. Dies wird durch die Verlagerung des Detail-Engineerings der einzelnen Module auf die Modulhersteller möglich. Beim Engineering des eigentlichen Produktionssystems werden lediglich die benötigten Module entsprechend den Anforderungen an den Prozess miteinander kombiniert und parametrisiert. Dafür liegt jedem Modul eine Selbstbeschreibung in Form eines Module Type Package (MTP) bei. Darin 4 Ansätze des funktionsorientierten Engineerings 65 enthalten sind Informationen zum Modul und über die ausführbaren Prozesse, die das Modul realisieren kann.

4.5.1.3 Schröck – Interdisziplinäre Wiederverwendung im Engineering automatisierter Anlagen [SCH16] definiert wiederverwendbare Einheiten, die im Rahmen seines Wiederverwendungskonzeptes entwickelt werden. Schröck grenzt seine wiederverwendbaren Einheiten von autonom funktionsfähigen Modulen ab. Doch auch die beschriebenen wiederverwendbaren Einheiten müssen gekapselt und voneinander unabhängig sein. Sie erfüllen eine bestimmte Funktion und lassen sich durch Merkmale beschreiben. Einen hohen Stellenwert nimmt die Variabilität der wiederverwendbaren Einheiten in dem vorgestellten Konzept ein. Teilweise wird in den wiederverwendbaren Einheiten die automatisierungstechnische Hardware bei deren Planung integriert.

4.5.1.4 Zusammenfassung der Modularisierung Zusammenfassend kann festgestellt werden, dass im modularen Engineering in Funktionen geplant wird und diese Funktionen beschrieben werden müssen. Es werden dabei unterschiedliche Ansätze verfolgt. Im Kern ist erkennbar, dass es in der Modularisierung und dem funktionsorientierten Engineering um die Kapselung von Funktionseinheiten für eine bestimmte Aufgabe geht und diese möglichst wiederverwendbar zu gestalten ist. Dabei wird im Engineering-Prozess der Module so lange wie möglich auf die Auswahl der Hardware verzichtet, um den Lösungsraum so lange wie möglich uneingeschränkt nutzen zu können. Dies ist beim funktionsorientierten Engineering ähnlich. Die Ansätze der Modularisierung sind sehr stark durch die Auswahl von Hardware und deren Schnittstellen geprägt. Die Herausforderungen der Modularisierung liegen in der optimalen Kapselung eines Moduls. Für die Kapselung der Funktionen gilt daher: je unabhängiger Funktionen voneinander sind, desto eigenständiger können die Module sein, die diese Funktion erfüllen sollen [ERI98; KÜH10]. Die Abgrenzung eines Moduls zu einem anderen sollte so geschehen, dass ein Minimum an Schnittstellen entsteht. Zudem ist die Granularität der Funktionen eines Moduls ein weiteres, intensives Forschungsthema, um zu untersuchen wie feingranular ein Modul Funktionen anbieten muss, um die Anforderungen aus dem Engineering zu erfüllen. Gleichzeitig soll diese Modellierung eine möglichst geringe Variabilität in den Modulen verursachen (viele feingranulare Module versus wenige Module mit großem Funktionsumfang, die in sehr vielen Varianten vorliegen müssen). In Abgrenzung zum vorliegenden Ansatz ist die Modularisierung eines Produktionssystems ein kleiner, aber sehr wichtiger Teilschritt im gesamten Engineering-Prozess, welcher durch den Ansatz der vorliegenden Arbeit umfassend unterstütz wird.

4.5.2 Abgrenzung zum serviceorientierten Engineering Die Kapselung mechatronischer Funktionen von Feldgeräten zu Services kann als Kern der Übertragung serviceorientierter Ansätze auf die Automatisierung von Produktionssystemen angesehen werden. Diese Services können über standardisierte Schnittstellen zur Verfügung gestellt werden. Eine Kombination von sogenannten Basis-Services kann zu höherwertigen Services und Prozessabläufen führen [LOS13, S. 27].

In [JASM05] werden einige Eigenschaften der Services in der Fertigungsautomatisierung genannt. Dazu zählt unter anderem, dass Services üblicherweise einen Geschäftsprozess repräsentieren und dass deren Kommunikation mit anderen Services über Dokumente realisiert wird. Hier ist ein Unterschied zu objektorientierten Ansätzen zu finden, bei denen 4 Ansätze des funktionsorientierten Engineerings 66 die Kommunikation über Interaktionsmuster im Konversationsstil stattfindet, wobei einzelne Objektattribute adressiert werden. Für die Umsetzung der Services im Umfeld der Automatisierungstechnik werden häufig Webservices benutzt. Methoden, Werkzeuge und Frameworks zur Realisierung dieser Services auf Feldgeräteebene wurden im Projekt SOCRADES erarbeitet [SSG+08]. Dieses Projekt hatte die Entwicklung einer servicebasierten Middleware zur vertikalen Integration von Feld- und Unternehmensebene (z. B. ERP-Systemen) zum Ziel [LOS13, S. 27]. Hier ist bei der Nutzung der Services die Fokussierung auf Geschäftsprozesse unter Nutzung von Informationen aus der Feldebene zu erkennen. Im Rahmen der Aktivitäten zum Themenfeld Industrie 4.0 wird der Begriff Dienste synonym zum Begriff Services verwendet. Dienste lassen sich in unterschiedliche Klassen einteilen [SCGO16]: • Kommunikationsdienste (zur Kommunikation zwischen den Beteiligten), • Informationsdienste (zum Datenaustausch), • Anwendungsdienste (zur Organisation der Handhabung und Produktion der Produkte), • Plattformdienste (zur Selbstverwaltung der Ressourcen). Die Anwendungsdienste werden auch als funktionale Dienste bezeichnet und können dafür genutzt werden, um zu beschreiben, welche Funktion ausgeführt wird, wenn der entsprechende Dienst aufgerufen wird. Einen differenzierten Ansatz verfolgen die Projekte um den Automation Service Bus (ASB), der durch das Bereitstellen einer offenen Plattform zur Integration von heterogenen Software-Werkzeugen für die Entwicklung von Automatisierungssystemen das Engineering verbessern soll [BMM12]. Der ASB stellt an seinen Schnittstellen Software-Services zur Verfügung, die den Aufruf von Funktionen der unterschiedlichen Software-Werkzeuge erlauben und Daten für den bidirektionalen Austausch bereitstellen. Die unterschiedlichen Projekte zeigen, dass die Nutzung von Webservices in der Automatisierungstechnik Einzug hält. Dabei lassen sich zwei unterschiedliche Richtungen erkennen. Zum einen werden Services in Produktionssystemen zur Kommunikation zwischen Komponenten oder Modulen eingesetzt, zum anderen werden Services genutzt, um im Engineering Informationen zwischen Software-Werkzeugen auszutauschen, die sonst nicht miteinander im Informationsaustausch stehen würden. Im Fokus der vorliegenden Arbeit stehen die Services, die für die Kommunikation in einem Produktionssystem genutzt werden können. Es ist möglich diese Services in Verbindung mit der funktionsorientierten Planung zu sehen, da die hier betrachteten Services die Funktionen von mechatronischen Komponenten nach außen hin beschreiben und Anderen zur Nutzung anbieten können [DME+14]. Eine vollständige Modellierung eines Produktionssystems mit seinen Funktionen, dem Verhalten und den darin geplanten und verbauten Komponenten ist mit den serviceorientierten Ansätzen nicht möglich. Diese Ansätze können einen Beitrag für den Aufbau der Kommunikationsstruktur innerhalb eines Produktionssystems geben, welches nur ein kleiner Teilbereich des gesamten Engineering-Prozesses ist, welcher durch den Ansatz der vorliegenden Arbeit abgedeckt wird.

4 Ansätze des funktionsorientierten Engineerings 67

4.6 Schlussfolgerungen und Handlungsbedarf Fasst man die Erkenntnisse aus den Untersuchungen der funktionsorientierten Ansätze zusammen und lässt dabei die Informationen zur Abgrenzung und Einordnung in die Themen der Modularisierung, der Anforderungsanalyse und der Services einfließen, so können folgende Kernforderungen an ein funktionsorientiertes Planungsvorgehen aufgestellt und die Forschungsfrage 3 beantwortet werden:

3. Wie ist das Modell des Systems aufzubauen und welche (möglichst genormten) Beschreibungsmittel eignen sich für die Darstellung der unterschiedlichen Informationen im Modell des Produktionssystems?

Mit einer funktionsorientierten Planung können sowohl Anforderungen an das System dokumentiert, als auch systematisch nach dessen Lösung gesucht werden, ohne eine Einschränkung durch zu frühe Festlegung auf bestimmte Geräte vorzunehmen. Für eine funktionsorientierte Planung ist das Beschreiben von Abläufen als einer der ersten Planungsschritte essentiell. Dafür ist die Formalisierte Prozessbeschreibung zu nutzen, wie in Abschnitt 4.4.3.5 dargestellt ist. Das im Engineering entstehende Modell des Systems ist aus mehreren Teilen (Funktion, Struktur und Verhalten) aufzubauen, um alle Aspekte der Gewerke im Engineering abzudecken. Dabei spielt jedes dieser Teilmodelle eine wichtige Rolle in der Zusammenarbeit der Gewerke: Funktionsmodell Das Funktionsmodell bildet die zu realisierenden Funktionen des Produktionssystems ab. Diese können in einer hierarchischen Struktur abgebildet werden, um unterschiedliche Detaillierungsebenen der Funktionen und ihrer Teilfunktionen abzubilden. Der entscheidende Vorteil der funktionalen Planung ist folgender: Wird ein Produktionssystem in seine Teilfunktionen zerlegt und diese einzeln geplant, so weiß jedes Gewerk im Engineering über was gesprochen wird, da die Funktion und die darin enthaltenen Teilfunktionen als erstes geplant werden. Komponentenorientierte Vorgehen haben diesen Vorteil nicht. Sie legen entweder zu früh bestimmte Komponenten als Lösung für eine Anforderung fest, was den Lösungsraum zu früh einschränkt. Oder sie lassen die Komponentenauswahl vorerst offen, was dann ein Planungselement im Mittelpunkt hat, welches auf Grund seiner nicht erfolgten Auswahl nicht klar beschrieben ist. Die beschriebenen Vorteile lassen sich in den beschriebenen Planungsvorgehen der Prozessindustrie mit der PLT-Planung, in der Gebäudeleittechnik mit den Raumautomatisierungsfunktionen und den funktionsorientierten Planungsvorgehen aus Abschnitt 4.3 beobachten, die eine Funktionsorientierung aufweisen. Den beschriebenen Vorteilen steht der Nachteil gegenüber, dass eine solche funktionsorientierte Planung scheinbar mit zusätzlichem Mehraufwand in der Planung verbunden ist. Daher wird diese teilweise nicht eingesetzt, sondern gleich mit der Konstruktion von Systemkomponenten begonnen. Dieser scheinbare Nachteil wird jedoch aufgehoben, wenn eine detaillierte Anforderungserhebung für das Produktionssystem oder eine funktionale Beschreibung des Produktionssystems erstellt werden muss, um die daraus resultierenden Modelle später im Betrieb des Systems einsetzen zu können. Dies kann notwendig sein, wenn eine Änderung des Produkts, das auf dem Produktionssystem gefertigt werden soll, vorgenommen wird. Mit Hilfe der detaillierten Anforderungen eines Produktes an das Produktionssystem, die in einem Funktionsmodell durch Berücksichtigung des PPR- Konzeptes abgebildet sind, kann von einer Eigenschaftsänderung eines Produktes auf die Änderungen innerhalb des Produktionssystems geschlossen werden. Das PPR-Konzept 4 Ansätze des funktionsorientierten Engineerings 68 stellt weiterhin sicher, dass auch das zu produzierende Produkt beschrieben wird. Nur über die Funktion und den zu realisierenden Produktionsprozessen besteht eine Verbindung zu diesem Produkt mit seinen Zwischenprodukten. Im Falle einer Komponentenorientierung im Engineering ist dieser Zusammenhang nicht ohne Mehraufwand über zusätzliche Modellierungsschritte zu erreichen. Eine detaillierte funktionale Beschreibung des Produktionssystems wird dann notwendig, wenn das Produktionssystem flexibel erweitert werden soll. Zusätzliche Funktionen müssen sich in die bestehende Funktionshierarchie einordnen lassen. Aus dem vorliegenden Kapitel lässt sich weiterhin ableiten, dass bei der Modellierung eines Produktionssystems die Funktionseinheiten als Module zu planen und zu kapseln sind, um standardisierte Schnittstellen an den Modulgrenzen zu gewährleisten. Eine Verwendung von Funktionsbibliotheken ist anzustreben, damit ein gemeinsames standardisiertes Verständnis über die Funktionen in den unterschiedlichen Gewerken vorliegt. Strukturmodell Neben dem Funktionsmodell muss in einem Strukturmodell beschrieben werden, aus welchen Komponenten das Produktionssystem aufgebaut werden soll. Das Strukturmodell kann dabei eine hierarchische Aufbaustruktur enthalten, welche das Produktionssystem in Teilanlagen, Module und Funktionseinheiten unterteilt. Zwischen den Komponenten des Strukturmodells und den Technischen Ressourcen des Funktionsmodells sollte eine Verbindung bestehen, da die Komponenten die Anforderungen der Technischen Ressourcen erfüllen sollten. Verhaltensmodell Das Verhaltensmodell muss gemäß den Anforderungen aus Abschnitt 3.4 mindestens dazu geeignet sein eine Signalliste abzubilden und rechnerinterpretierbar zu übertragen. Für eine umfassende Systembeschreibung ist neben dem Ablauf der Funktionen und deren Teilfunktionen eine Beschreibung der Prozessschritte notwendig, die detaillierte Angaben über Zeit und Dauer der Schritte, sowie der beteiligten Sensoren und Aktoren enthält. Diese kann in einem ersten Schritt aus dem Funktionsmodell abgeleitet werden und durch das Gewerk der Automatisierungstechnik weiter detailliert werden. Sicherheitsfunktionen und Verriegelungslogiken lassen sich in einem Funktionsmodell nicht darstellen und sollten daher in einem gesonderten Modell abgelegt werden, dass mittels geeigneter Beschreibungsmittel dafür ausgelegt ist. Aus diesen Punkten lässt sich der Handlungsbedarf für eine einfach einzuführende, intuitive Funktionsmodellierung ableiten, deren Systemmodell in Kapitel 5 näher erklärt wird.

5 Modellierung der Maschinenfunktion 69

5 Modellierung der Maschinenfunktion Die Funktion, deren unterschiedliche Ansätze in den vorangegangenen Kapiteln betrachtet wurden, wird im vorliegenden Kapitel gemäß den Anforderungen aus den vorangehenden Kapiteln abgebildet. Dazu wird ein Informationsmodell vorgestellt, das die Erzeugung eines Systemmodells mit der Funktion im Mittelpunkt ermöglicht. Das Systemmodell bildet das zu konstruierende und später auch zu errichtende Produktionssystem ab. Es wird im Engineering durch die unterschiedlichen Gewerke mit Informationen befüllt. Die Nutzung des beschriebenen Informationsmodells zum Aufbau des Systemmodells wird im Engineering-Workflow für fertigungstechnische Produktionssysteme dargestellt. Zudem wird im nachfolgenden Kapitel erklärt, wie das erzeugte Systemmodell in einem Datenformat abgebildet wird, damit es zwischen den Gewerken rechnerinterpretierbar ausgetauscht werden kann. Um die Funktion im Folgenden abzubilden, wird eine objektorientierte Sichtweise gewählt. Die Funktion wird dementsprechend als ein Objekt abgebildet, das sich durch Merkmale näher beschreiben lässt. Die Strukturierung und der Aufbau dieses objektorientierten Modells zur funktionsorientierten Beschreibung eines fertigungstechnischen Produktionssystems werden im folgenden Abschnitt grundlegend betrachtet.

5.1 Aufbau des Systemmodells In diesem Abschnitt wird auf das Systemmodell eingegangen, mit dessen Hilfe es möglich ist, ein umfassendes Modell des Produktionssystems zu erstellen. Um das Gewerke-übergreifende Engineering zu unterstützen, muss das Modell in der Lage sein, alle Interessenbereiche, die zwischen den beteiligten Gewerken im Engineering vorhanden sind, abzudecken. Abbildung 3-10 stellt diese Interessenbereiche bildhaft dar. Im Kern wird zwischen allen Gewerken die Funktion des Systems als gemeinsamer Verbindungspunkt genutzt. Des Weiteren sind an den Schnittflächen der Gewerke die Informationen eingetragen, die als Mindestmaß zwischen den jeweiligen Gewerken ausgetauscht werden sollten: die Verhaltensbeschreibung des Systems, die Stückliste mit mechanischen/elektrischen Komponenten und die Signalliste. Um diese Informationen abzubilden und sie im Engineering zwischen den Gewerken auszutauschen, werden die folgenden drei Teilmodelle benötigt: • Funktionsmodell, • Strukturmodell und • Verhaltensmodell. In den folgenden Abschnitten wird auf das jeweilige Teilmodell eingegangen und wie es im Engineering genutzt wird. Dazu wird jedem Teilmodell ein Metamodell zugeordnet, das dessen Aufbau beschreibt. Die im vorliegenden Abschnitt vorgestellten Metamodelle wurden durch den Autor der vorliegenden Arbeit in das Verbundprojekt „SemAnz4.0 – Semantische Allianz für Industrie 4.0“ eingebracht, vgl. [HHS+16*; SHF+17A*; SHF17B*; HSF+17A*; HSF+17B*; SHW+17*; FDD+18*]. Ziel der Modellierung und des Projektes war es, möglichst genormte Elemente für die Abbildung der Elemente eines Produktionssystems zu verwenden. Ein weiteres Ziel des Projektes war es, aus den untersuchten und genutzten Normen und Standards abzuleiten, welche Lücken in der nationalen und internationalen Normungslandschaft noch vorhanden sind und wie man diese gegebenenfalls schließen könnte. 5 Modellierung der Maschinenfunktion 70

5.1.1 Funktionsmodell Das Funktionsmodell enthält im Kern den Prozess eines Systems zur Fertigung eines Produktes. Dieses Modell kann somit auch als Anforderungsmodell für ein System angesehen werden, da es durch seine abstrakte Betrachtung des Prozesses und der darin ausgeführten Funktionen eine lösungsoffene Darstellung ermöglicht. Ein solcher Prozess kann durch Dekomposition weiter detailliert und durch feiner granulierte Prozessschritte beschrieben werden. In diesen Prozessschritten werden wiederum Funktionen ausgeführt. Die Abbildung der Prozessschritte erfolgt in dieser Arbeit mit der Formalisierten Prozessbeschreibung (FPB) nach [VDI/VDE 3682-1], da damit eine formalisierte Form der Prozessbeschreibung mit einem überschaubaren Umfang an genormten Symbolen zur Verfügung steht. In den Eigenschaftsänderungen des Produktes innerhalb eines Prozessschrittes lassen sich die Fertigungsbedürfnisse der Produkte darstellen. Diese Bedürfnisse stellen Anforderungen an den Prozessschritt und somit auch an dessen Funktion dar und sollen durch die Technischen Ressourcen erfüllt werden, die den Prozessschritten zugeordnet sind. Diese Technischen Ressourcen definieren somit auch Anforderungen an die dafür eingesetzten Geräte/Komponenten. Es lassen sich im Funktionsmodell folgende Verbindungen zwischen den Elementen abbilden: • Flussverbindungen von Material, Energie und Informationen, • Nutzungsbeziehungen zwischen Prozess und der zugeordneten Technischen Ressource. Das in Abbildung 5-1 dargestellte Metamodell zur Abbildung der Maschinenfunktion in einem Funktionsmodell enthält die Funktion im Kern und die Flussgrößen Produkt, Energie und Informationen, die der Funktion als In-/Output dienen. Zudem ist der Funktion eine Technische Ressource zugeordnet. Durch diese Zuordnung wird aus der abstrakten Funktion ein ausführbarer Prozess.

Abbildung 5-1: Metamodell des Funktionsmodells Um die Anforderungen aus Abschnitt 4.6 zu erfüllen, muss das Funktionsmodell mit den anderen Teilmodellen des Systemmodells verbunden werden, um die Funktionszentrierung zu realisieren. Das Funktionsmodell muss daher über Schnittstellen zum Struktur- und Verhaltensmodell verfügen. Auf diese Verbindungen wird in Abschnitt 5.3 eingegangen.

5 Modellierung der Maschinenfunktion 71

5.1.2 Strukturmodell Das Strukturmodell muss in der Lage sein, unterschiedliche Detaillierungsebenen eines Systems mit seinen Komponenten abzubilden. In [ZHR+16] werden neun Hierarchieebenen identifiziert und an branchenspezifischen Ausprägungen erklärt. Die Gliederung der Ebenen sollte sich dabei an etablierten Standards orientieren. In [DIN SPEC 91345] werden dazu mehrere Konzepte ([DIN EN 62264-1] und [DIN EN 61512-1]) betrachtet und in einer Hierarchie zusammengeführt. In den aufgeführten Normen wird die Hierarchie oberhalb der Feldgeräte betrachtet. Um die darunter liegenden Ebenen zu modellieren, welche die Funktionen in einem System realisieren, wurden Funktionseinheiten in der Hierarchie ergänzt. Die Funktionseinheiten wurden aus der [IEC 61499-1] übernommen und gliedern sich in der Hierarchie zwischen den Teilanlagen und den Feldgeräten ein. Die Funktionseinheiten werden aus Komponenten zusammengesetzt, welches eine allgemeine Bezeichnung für die angesprochenen Feldgeräte und sonstige Elemente ist. Unter den Feldgeräten werden im Zusammenhang mit Industrie 4.0 intelligente, selbst kommunizierende Elemente verstanden. Für die Modellierung komplexer Produktionssysteme sind zudem passive, selbst konstruierte oder gekaufte Elemente notwendig. Zwischen den einzelnen Elementen der Struktur können Verbindungen angelegt werden. Diese sind: • strukturelle Verbindung, im Sinne von Montageverbindung (z. B. Sensor ist mit Greifer durch Schraubverbindung verbunden), • Informationstechnische/logische Verbindung (z. B. Sensor liefert Signal an SPS und SPS an Greifer), • Energetische Verbindung (z. B. Motor bekommt Strom von zentraler Versorgung im Schaltschrank), • Materialtechnische Verbindung (z. B. Werkstück wird von Band 1 zu Band 2 gefördert). Somit erfüllt das Strukturmodell die Anforderung aus Abbildung 3-10 und Abschnitt 4.6, mindestens eine strukturierte Stückliste zwischen Maschinenbau und Elektrotechnik abzubilden. Das Strukturmodell besteht im Kern aus Funktionseinheiten, die aus Komponenten aufgebaut sind. Komponenten sind nicht weiter zerlegbar. Hierzu zählen Kaufteile oder selbst gefertigte Elemente wie beispielsweise Halterungen für andere Komponenten. Funktionseinheiten können als kleinste Systemeinheit betrachtet werden. Diese bestehen aus einem Sensor/Aktor und dazu gehöriger Steuerung und führen Funktionen aus. Abbildung 5-2 stellt das Metamodell des Strukturmodells dar. 5 Modellierung der Maschinenfunktion 72

Abbildung 5-2: Metamodell des Strukturmodells Die Objekte oberhalb der Funktionseinheit können beliebig tief hierarchisiert werden. Beispielsweise lassen sich Produktionssysteme in Abschnitte/Unterabschnitte und diese wiederum in Module zerlegen. Auch die Funktionseinheiten können ineinander verschachtelt werden, da auch hier unterschiedliche Detaillierungstiefen vorstellbar sind. Die Komponenten als elementare Bestandteile des Systems werden über Schnittstellen miteinander verbunden. Diese Schnittstellen können konstruktive Verbindungen beschreiben oder auch Verbindungen von Energie-, Informations- oder Produktflüssen.

5.1.3 Verhaltensmodell Das Verhaltensmodel enthält im einfachsten Fall Informationen über Sensor- und/oder Aktorsignale und ggf. Zustände des Systems. Dabei wird der Fokus der vorliegenden Arbeit auf das gesteuerte Verhalten gelegt, um das dynamische Verhalten des Systems zu beschreiben. Hier wird klar gegen das ungesteuerte Verhalten zur Beschreibung der Reaktion des Systems auf die eingehenden Steuerbefehle abgegrenzt, da sich die Modellerstellung des ungesteuerten Verhaltens eines Systems in einer späteren Phase des Engineerings eingliedert. Der Themenschwerpunkt der virtuellen Inbetriebnahme beschäftigt sich eingehend mit der Verhaltensmodellierung des ungesteuerten Verhaltens, vgl. [PUN17; HUM11] und ist daher nicht im Fokus der vorliegenden Arbeit. Es ist möglich, das in der vorliegenden Arbeit entwickelte Systemmodell um die Anteile des ungesteuerten Systemverhaltens zu ergänzen. Eine detaillierte Betrachtung des umfangreichen Themenschwerpunktes der Verhaltensmodellierung des ungesteuerten Verhaltens ist auf Grund des Umfanges in dieser Arbeit nicht möglich. Auf Grund der Vielzahl an verwendeten Beschreibungsmitteln für das Verhalten wird dieses für das Verhaltensmodell offen gehalten. Das Verhaltensmodell selbst stellt abstrakte Objekte zur Verfügung, die Referenzen auf externe Dokumente enthalten können. Diese Objekte sind im einfachsten Fall Variablen, die als Liste dargestellt werden. Dies kann als Signalliste verstanden werden, die zwischen der Elektrotechnik und der Automatisierungstechnik ausgetauscht wird. Die jeweiligen Objekte, die eine Variable bzw. 5 Modellierung der Maschinenfunktion 73 ein Signal repräsentieren, enthalten eine Beschreibung in Form von Merkmalen. Hier sind beispielsweise der Name, der Datentyp und die Bedeutung des Signals zu dessen näherer Beschreibung anzugeben. Vorstellbar ist hier weiterhin, dass Abläufe als Ablaufbeschreibung gemäß [IEC 61131-3] darstellt werden können. Dazu wird eine Programmorganisationseinheit (POE) innerhalb des Verhaltensmodells erstellt. Diese kann neben den Variablen auch Programmcode und Hardwarekonfigurationen enthalten. Für die Darstellung des Verhaltens eines Systems sind somit die Beschreibungsmittel der [IEC 61131-3] verfügbar. Eine Darstellung von Abläufen mit der Ablaufsprache, Strukturiertem Text oder Anweisungsliste kann realisiert werden. Zudem sind Verriegelungslogiken mit der Funktionsbausteinsprache abbildbar. Ein Zusammenhang zwischen der Darstellung von Abläufen im Funktionsmodell und den Abläufen im Verhaltensmodell wird im Abschnitt 5.3 dargestellt. Das Metamodell zum Aufbau des Verhaltensmodells ist in Abbildung 5-3 dargestellt.

Abbildung 5-3: Metamodell des Verhaltensmodells Das im vorliegenden Abschnitt beschriebene Verhaltensmodell erfüllt somit zwei Forderungen aus Abbildung 3-10. Zum einen kann mindestens eine Signalliste zwischen den Gewerken Elektrotechnik und Automatisierungstechnik übertragen werden. Zum anderen ist es möglich, über das Verhaltensmodell eine detaillierte Ablaufbeschreibung zwischen dem Maschinenbau und der Automatisierungstechnik auszutauschen.

5.1.4 Merkmale im Systemmodell Funktionen lassen sich durch die Verwendung von Merkmalen näher beschreiben [HAD15, S. 2]. Neben den Funktionen fungieren hier auch die anderen Elemente aus den beschriebenen Teilmodellen als Merkmalträger, vgl. [HADI14; EPP11]. Abbildung 5-4 zeigt schematisch den Zusammenhang zwischen dem Merkmalträger und den Merkmalen, die die Funktion (in Abbildung 5-4 als Platzhalter der Planung bezeichnet) als Merkmalträger näher beschreiben. Merkmale sind klassifizierte Eigenschaften eines Systems, die sich zunächst dadurch auszeichnen, dass sich ihre Ausprägung durch einen einfachen Wert ausdrücken lässt [HEE05]. 5 Modellierung der Maschinenfunktion 74

Merkmal- charakterisiert Merkmal spezifiziert Ausprägung träger

Ausprägungs- aussage Platzhalter sichert zu Technische der Planung fordert an Ressource

Aussageziel Aussage

Anforderung Zusicherung .11 . .

Abbildung 5-4: Darstellung der Merkmalsausprägungen [RIE17] Dabei kann ein solches Merkmal über unterschiedliche Ausprägungen verfügen, die über das Aussageziel interpretierbar wird. Es sind unterschiedliche Typen von Aussagezielen möglich, vgl. [MER11]. Die am häufigsten verwendeten Aussageziele werden im vorliegenden Ansatz zur Anwendung kommen [HEE05; EPP11]: • Zusicherung: Der Aussagende sichert zu, dass die Merkmalinstanz die dargestellte Bedingung erfüllt. • Anforderung: Der Aussagende fordert, dass die Merkmalinstanz die dargestellte Bedingung erfüllt. Die Festlegung eines frei zu konfigurierenden Einstellwertes ist ebenfalls eine Anforderung. • Istwert: Der Aussagende macht eine Aussage zu seiner Erkenntnis über den tatsächlichen Wert der Ausprägung.

[HADI14] merken an, dass sich die Arbeiten zur Merkmalsdefinition gegenwärtig auf Systemkomponenten konzentrieren. Die Definition von Merkmalen für Systemfunktionen ist jedoch wichtig, wenn es möglich sein soll, Entwurfsergebnisse mit Entwurfszielen zu vergleichen. Dementsprechend muss ein Systemmodell über ein Merkmalmodell verfügen, dass sowohl die Funktion als auch die Komponente zu deren Realisierung detailliert beschreibt. Dabei können sowohl die Funktionen als auch die Komponenten zu deren Erfüllung Anforderungen stellen und Zusicherungen geben. Für ein erfolgreiches Engineering müssen sich die Aussageziele der jeweiligen Merkmale gegenseitig erfüllen. Auf eine weitere, detaillierte Betrachtung von Merkmalmodellen wird an dieser Stelle für die vorliegende Arbeit verzichtet, da die Komplexität des Themas der Merkmalmodellierung eigene Standards, vgl. [DIN EN 61360-1], und Forschungsarbeiten hervorbringt, vgl. [DHT17], die im Zusammenhang mit der vorliegenden Arbeit genutzt werden können.

5 Modellierung der Maschinenfunktion 75

5.2 Verwendung der Maschinenfunktion im Zusammenspiel der Gewerke In diesem Abschnitt wird beschrieben, wie die Gewerke im Engineering-Workflow die vorgestellten Teilmodelle nutzen, um ihre Informationen in das Systemmodell zu überführen. Im Weiteren werden die drei Teilmodelle des Systemmodells detailliert erklärt und anhand eines durchgängigen Beispiels einer Fertigungsanlage dargestellt, welches Gewerk mit welchem Werkzeug Informationen erzeugt und wie diese in das Systemmodell eingefügt werden.

5.2.1 Ablauf der Planung mit dem Systemmodell In Abbildung 5-5 ist der in der vorliegenden Arbeit definierte allgemeine Engineering- Workflow mit den darin verwendeten Teilmodellen zum Aufbau des Systemmodells exemplarisch dargestellt, vgl. dazu Abschnitt 2.1.12. Die hier dargestellten Engineering- Tätigkeiten lassen sich in die Phase des Entwurfs einordnen, in dem die drei Gewerke das Systemmodell des zu planenden Produktionssystems aufstellen, das die Anforderungen aus der Anforderungserhebung erfüllen soll. Eventuelle Iterationsschritte durch Rücksprünge oder Datenänderungen sind der Übersichtlichkeit halber nicht aufgeführt, können aber durch die Datenhaltung im Systemmodell abgedeckt werden.

Abbildung 5-5: Beteiligte Gewerke und deren Einfluss auf die Teilmodelle des Systemmodells [SHF17B*] Zu Beginn des Engineering-Workflows wird mit dem Funktionsmodell geplant. Dieses Vorgehen ist ähnlich der Planung mit dem Grundfließschema in der Prozessindustrie [DIN EN ISO 10628-1] oder dem Blackbox-Prinzip des Systems-Engineering [HMS+07]. Daher steht auch im vorliegenden Systemmodell die Funktion im Mittelpunkt. Die Funktion ist zudem die Gemeinsamkeit der beteiligten Gewerke. Über die Funktionen sind eine Gewerke- übergreifende Kommunikation und der Informationsaustausch zwischen den Planern der einzelnen Gewerke möglich. 5 Modellierung der Maschinenfunktion 76

Als Beispiel zur Erklärung der Inhalte des Systemmodells wird ein Produkt betrachtet, für welches ein automatisiertes Produktionssystem zu entwickeln ist. Das Produkt Pneumatik- Zylinder und seine Komponenten (Zylinder, Deckel, Schieber, Feder, Dichtung) sind in Abbildung 5-6 dargestellt.

Abbildung 5-6: Stückliste und Darstellung des Produktes Pneumatik-Zylinder In den folgenden drei Abschnitten wird auf den Aufbau und die Erstellung der drei Teilmodelle des Systemmodells eingegangen.

5.2.2 Informationen im Funktionsmodell Im beschriebenen Engineering-Workflow beginnt der Maschinenbau als führendes Gewerk mit dem mechatronischen Engineering, in Abbildung 5-5 als conceptual modeling dargestellt. Dabei wird als ein erster Schritt das zu fertigende Produkt näher betrachtet. Das Produkt, im vorliegenden Fall der Pneumatik-Zylinder, lässt sich durch ein eigenes Strukturmodell beschreiben. Dies besteht aus der hierarchischen Anordnung der einzelnen Komponenten des Produktes, dem Zylinder, dem Deckel, dem Schieber, der Feder und der Dichtung. Aus diesem Strukturmodell des Produktes, welches die Anforderungen an das zu planende Produktionssystem definiert, lässt sich ein grundlegendes Funktionsmodell des Produktionssystems ableiten: das Funktionsmodell zur Herstellung des Produktes, siehe Abbildung 5-7. Wie beschrieben, definiert es die Randbedingungen (im Sinne von Anforderungen) für das Produktionssystem. Damit wird die Funktionsanalyse gemäß [VDI 2221] unterstützt, die für eine korrekte Lösungsfindung im Engineering Voraussetzung ist. Die Funktion eines Systems ist eine lösungsneutral beschriebene Beziehung zwischen Eingangs-, Ausgangs- und Zustandsgrößen eines Systems mit dem Ziel, eine Aufgabe zu erfüllen. Diese Ein- und Ausgangsgrößen können neben den Produkten auch Energie und Information sein. [VDI 2222-1] Die Funktionen des Produktionssystems werden innerhalb von Prozessen ausgeführt. Dazu werden Technische Ressourcen genutzt. Die Modellierung nach dem Produkt-Prozess-Ressource-Ansatz (PPR) wird angewendet. Das Funktionsmodell des Produktionssystems lässt sich mit der Formalisierten Prozessbeschreibung darstellen. Dieses funktionsorientierte Teilmodell wird während des gesamten Engineering-Workflows zwischen den beteiligten Gewerken als neutrales gemeinsames Kommunikationsformat verwendet. Es zeigt unabhängig von CAD- Abbildungen oder Layout-Darstellungen des Systems die Funktionen, die realisiert werden. 5 Modellierung der Maschinenfunktion 77

Durch eine Verbindung mit dem Strukturmodell und dem Verhaltensmodell entsteht ein integriertes Systemmodell für den gesamten Engineering-Workflow. Das Funktionsmodell des Produktionssystems beschreibt auf einer sehr abstrakten Ebene die Gesamtfunktion des Produktionssystems: das Herstellen eines Pneumatik-Zylinders, vgl. Abbildung 5-7. Als Eingangsprodukte dienen die Komponenten des Pneumatik-Zylinders, welche aus dem Strukturmodell des Produktes entnommen werden. Das Ausgangsprodukt des Prozesses ist das Endprodukt, der Pneumatik-Zylinder.

P_Cylinder P_Lid P_Spring P_Piston B_System_Boundary

O_Manufacture_Cylinder T_Production_System

P_Pneumatic_cylinder

Abbildung 5-7: Funktionsmodell des Produktionssystems Das Funktionsmodell des Produktionssystems kann nun im Laufe des Engineering- Workflows weiter detailliert werden. Dazu wird der Prozess „Herstellen eines Pneumatik- Zylinders“ dekomponiert. Eine detaillierte Beschreibung der für die Produktion notwendigen Prozessschritte ist damit möglich. Diesen Prozessschritten werden Technische Ressourcen zugeordnet. Diese definieren Anforderungen an die physischen Komponenten, die diesen Prozessschritt später ausführen sollen. Für die Dekomposition der Prozesse hat sich für das vorliegende Beispiel die Einteilung in vier Ebenen der Modellierungstiefe bewährt. Diese Einteilung orientiert sich an der generellen Vorgehensweise beim Entwickeln und Konstruieren der [VDI 2221]. Dabei steht jede dargestellte Ebene für eine Planungsphase und die darin erstellten Funktionen des Funktionsmodells in ihrem jeweiligen Detaillierungsgrad. Dadurch wird das Funktionsmodell schrittweise weiter detailliert. Diese Ebenen (Level) sind in Tabelle 5-1 dargestellt.

Tabelle 5-1: Ebenen der Detaillierung des Funktionsmodells

Level Beschreibung Lösungsneutrale Darstellung der Gesamtfunktion Level 0 Übernahme des funktionsorientierten Anforderungsmodell aus dem Strukturmodell des Produktes Lösungsneutrale Darstellung der Funktionen und Teilfunktionen Level 1 Funktionsanalyse Effekt-gebundene Darstellung der Funktionen Level 2 Suche nach Lösungseffekten Prinzip-gebundene Darstellung der Funktionen Level 3 Gestaltung der prinzipiellen Lösungen

Das gezeigte Funktionsmodell des Produktionssystems (Abbildung 5-7) lässt sich in Level 0 gemäß der Einteilung in Tabelle 5-1 einordnen. Aus diesem Funktionsmodell wird durch Dekomposition eine detailliertere Beschreibung der darin enthaltenen Prozessschritte abgeleitet. Die Prozessschritte können sich dabei an der Aufbaustruktur des Produktes orientieren. Die Unterteilung des Produktes in Module oder Teilkomponenten ist an dieser Stelle hilfreich für die lösungsneutrale Modellierung der Prozessschrittkette. Ein Beispiel für eine solche Dekomposition eines Fertigungsprozesses ist in Abbildung 5-8 verdeutlicht. Die Abbildung 5-8 zeigt den Prozess aus Abbildung 5-7 und stellt ihn in Level 1 detaillierter dar. 5 Modellierung der Maschinenfunktion 78

Abbildung 5-8: Detaillierung des Fertigungsprozesses eines Pneumatik-Zylinders auf Level 1 Zu erkennen ist, dass die Ein- und Ausgangsprodukte auf der Bilanzgrenze des Prozesses die gleichen sind wie im vorher dargestellten Gesamtprozess. Diese Produkte und auch die aus den Prozessschritten resultierenden Zwischenprodukte können detaillierte Informationen enthalten, vgl. [VDI/VDE 3682-2]. Zur Beschreibung dieser Informationen werden Merkmale benutzt. Weiterhin ist der Abbildung 5-8 zu entnehmen, dass die Prozessschritte und auch die dazu gehörigen Technischen Ressourcen lösungsneutral beschrieben sind. Als Beispiel sei hier der Prozess „Create hole“ aufgeführt, der die Herstellung eines Loches in den Grundkörper repräsentiert. Eine Lösung, wie Bohren oder Fräsen ist an dieser Stelle noch nicht gewählt, um alle Freiheiten in der Lösungssuche im Engineering-Workflow offen zu halten. Auf dieser Detailebene steht die Funktion im Mittelpunkt, die durch den Prozessschritt ausgeführt wird. 5 Modellierung der Maschinenfunktion 79

Abbildung 5-9: Detaillierung des Fertigungsprozessschrittes „Create hole“ auf Level 2 Abbildung 5-9 beschreibt den Prozess „Create hole“ aus Abbildung 5-8 im Detail. Es zeigt das Ergebnis der Modellierung der Funktionen auf Level 2 der vorgestellten Detailtiefe. Hierbei kann bei der Modellierung auf diesem Level im Engineering-Prozess auf die Effekte eingegangen werden, die dann im nächsten Detaillierungslevel auf die prinzipiellen Lösungen führen. Diese prinzipiellen Lösungen werden methodisch gefunden, wenn die vorgegebenen Funktionen oder Prozessschritte durch physikalische, chemische, biologische, usw. Effekte realisiert werden können. 5 Modellierung der Maschinenfunktion 80

Als Beispiel sei hier auf den Kernprozess aus dem dargestellten Beispiel in Abbildung 5-9 verwiesen. Im Prozess „Machining“ wird der Effekt Zerspanen gewählt und als Merkmal im Prozessschritt hinterlegt. Es kommen somit die prinzipiellen Lösungen wie Bohren oder Fräsen in Frage. Prinzipielle Lösungen wie Laserschneiden oder Stanzen entfallen auf Grund des gewählten Effektes, vgl. [DIN 8580]. Da auf Grund der Lösungsneutralität der Darstellung auf Level 2 noch keine konkreten Technischen Ressourcen ausgewählt werden (das erfolgt in Level 3 der Modellierung), sind einige Typen von Technischen Ressourcen mehrfach vorhanden. Am Beispiel der Technischen Ressourcen „Positioning Unit 1“ und der „Positioning Unit 2“ zum Bewegen des Grundkörpers des Zylinders aus Abbildung 5-9 wird das näher erklärt: Ist das angesprochene Modul, welches den Prozessschritt „Create hole“ ausführt, linear (alle Fertigungsschritte werden nacheinander entlang eines Transportbandes ausgeführt) aufgebaut, dann werden die beiden Prozessschritte des Positionierens durch zwei unterschiedliche Technische Ressourcen realisiert. Im Strukturmodell des Produktionssystems werden dafür zwei unterschiedliche Geräte eingeplant. Diese konkreten Geräte erfüllen dann jeweils die Anforderungen der Technischen Ressourcen „Positioning Unit 1“ und „Positioning Unit 2“. Ist das Layout aber als Rundschalttisch ausgeführt, dann können die beiden Prozessschritte des Positionierens des Werkstücks durch den gleichen Aktor (Antrieb des Rundschalttisches) realisiert werden. Im untersten Detaillierungslevel (Level 3) des Funktionsmodells werden die prinzipiellen Lösungen in den Prozessschritten realisiert. Für das Beispiel bedeutet dies, dass der Prozessschritt „Machining“ durch Dekomposition detailliert wird und im Kern den Prozessschritt „Drill_hole“ (Loch bohren) enthält, siehe Abbildung 5-10.

I_Is_Fixed P_Cylinder E_Electical Energy B_Machining

O_Move down T_Linear drive

P_Cylinder

O_Drill_hole T_Drilling_Unit

P_Cylinder_intermediate

O_Move up

P_Cylinder_intermediate E_Thermal_Energy I_Machining_done

Abbildung 5-10: Detaillierung des Fertigungsprozessschrittes „Machining“ auf Level 3 Diese Dekomposition wird für alle Prozessschritte der Herstellung des Pneumatik-Zylinders vorgenommen. Dadurch ergibt sich eine Folge von Detailprozessen, deren ausführende Technische Ressourcen sich während des Engineerings in Module zusammenfassen lassen (siehe Strukturmodell im folgenden Abschnitt). Hierbei ist eine Betrachtung der Technischen Ressourcen im Detail sinnvoll. Je nach geplantem Layout des Produktionssystems können 5 Modellierung der Maschinenfunktion 81 unterschiedliche Prozessschritte von unterschiedlichen oder gleichen Technischen Ressourcen ausgeführt werden. Im nächsten Schritt des Engineerings wird aus dem erstellten Funktionsmodell über die Technischen Ressourcen das Strukturmodell abgeleitet.

5.2.3 Informationen im Strukturmodell Aus dem erstellten Funktionsmodell werden die Struktur des Produktionssystems und auch Teile der Inhalte des Strukturmodells abgeleitet. Das Strukturmodell repräsentiert die Aufbaustruktur des Produktionssystems. Dies ist eine statische Darstellung der Gliederung der Komponenten des Systems [PAT82]. Die Technischen Ressourcen aus dem Funktionsmodell definieren die Anforderungen an konkrete Geräte, die im Strukturmodell abgebildet werden. Schon im Funktionsmodell kann die Modulbildung des zu planenden Systems an Hand der Dekomposition der Prozesse vorgeplant werden. Diese Module lassen sich im Strukturmodell durch die Bildung von Funktionseinheiten (Zusammensetzung von mehreren Geräten/Komponenten) weiter ausführen. Grundsätzlich werden die Inhalte des Strukturmodells des Maschinenbaus in einem CAD- Werkzeug geplant [VDI 4499-1]. Die Modellierung erfolgt durch Konstruktion von Komponenten und Hinzufügen von importierten Kaufteilen. Durch die strukturierte Anordnung von Komponenten und Kaufteilen und ihre Unterteilung in Funktionseinheiten entsteht eine hierarchische Struktur. In Abbildung 5-11 ist das Kaufteil „Bohrmaschine“ als ein Teil der zusammengesetzten Funktionseinheit „Bausatz Bohrmaschine“ abgebildet. Das Kaufteil „Bohrmaschine“ wird durch den Hersteller als 3D-CAD-Zeichnung zur Verfügung gestellt und in das CAD-Werkzeug importiert.

Abbildung 5-11: Kaufteil Bohrmaschine mit Halterung und Darstellung der Stückliste Dieses Kaufteil erfüllt die Anforderungen der Technischen Ressource „Drilling Unit“ aus dem Funktionsmodell, so dass es die Funktion des Prozessschrittes „Drill_hole“ durchführen kann, siehe Abbildung 5-10. Es ist in der Lage, in einem Prozessschritt ein Eingangsprodukt ohne Loch in ein Ausgangsprodukt mit Loch umzuwandeln. 5 Modellierung der Maschinenfunktion 82

Für die weiteren Prozessschritte aus dem Prozess „Machining“ wird die Technische Ressource „Linear_Drive“ benötigt, die die Prozessschritte „Move_up“ und „Move_down“ realisiert. Das Strukturmodell wird um eine Funktionseinheit „Linearachse“ ergänzt, die weitere Kaufteile wie Sensoren als Endlagenschalter für die Auf- und Ab-Bewegung enthält. Zusätzlich konstruierte Halterungen für Kaufteile werden als Komponenten im Laufe des Engineering-Prozesses des Maschinenbaus hinzugefügt.

Abbildung 5-12: Funktionseinheit „Bohren“ mit Stückliste Die fertig konstruierte Funktionseinheit „Bohren“ ist mit der dazugehörigen Stückliste aus dem CAD-Programm in Abbildung 5-12 dargestellt. Zu erkennen ist beispielsweise der Bausatz Endschalter, welcher zwei Microschalter des Typs S-3-BE enthält. Die Funktionseinheit „Bohren“ erfüllt die Anforderungen der Technischen Ressource „Machining_Unit“. Diese Technische Ressource ist zur Ausführung des Prozessschrittes „Machining“ im Funktionsmodell (siehe Abbildung 5-9) vorgeplant. Auch im Elektro-Engineering werden Daten im Strukturmodell eingefügt, siehe Abbildung 5-5. Im gezeigten Beispiel (Abbildung 5-12) sind in dem Strukturmodell bereits elektrische Komponenten enthalten. Der Getriebemotor der Linearachse wird durch den Maschinenbauer eingefügt. Genauso verhält es sich mit den Endlagenschaltern der Linearachse. Sind alle Sensoren und Aktoren im Strukturmodell enthalten, so kann der Elektrotechnik-Planer die dafür notwendige Steuerung auswählen und im Strukturmodell ergänzen. Für das gegebene Beispiel wird eine SPS vom Typ FESTO CECC-S ausgewählt und im Strukturmodell angelegt. Die ausgewählte SPS verfügt über ausreichend Anschlüsse für alle Aktoren und Sensoren und die entsprechenden Schnittstellen für die Anbindung an übergeordnete Systeme. Ist die SPS vom Elektrotechnik-Planer ausgewählt, werden die notwendigen Informationen dazu in das E-CAD-Werkzeug importiert. Der Hersteller der SPS stellt dafür ein Makro für z. B. die E-CAD-Werkzeuge EPLAN [EPL17@] oder WSCAD [WSC17@] zur Verfügung. Der Elektrotechnik-Planer hat somit Informationen über die entsprechende elektrische Komponente und ihre Anschlüsse im E-CAD-Werkzeug vorliegen. Dabei kann es von einer Komponente auch unterschiedliche Sichten geben, je nachdem wie komplex die Anschlüsse 5 Modellierung der Maschinenfunktion 83 an der Komponente sind. Bei der vorliegenden SPS werden im Folgenden zwei Sichten betrachtet. Als erstes wird die SPS mit der Stromversorgung verbunden. Dafür wird sie im E- CAD-Werkzeug über Leitungen mit einem Netzteil verbunden. Abbildung 5-13 stellt dies schematisch dar.

Abbildung 5-13: Makro einer SPS und ihre elektrischen Anschlüsse Eine weitere Verkabelung erfolgt zwischen der SPS und den Sensoren und Aktoren. Dabei werden die Endlagenschalter des Linearantriebes mit den digitalen Eingängen der SPS verbunden, siehe Abbildung 5-14.

Abbildung 5-14: Ausschnitt eines Makros einer SPS und ihre informationstechnischen Anschlüsse Die Informationen über die SPS und deren Anschlüsse sowie die dazu gehörigen Verbindungen werden im Strukturmodell abgelegt. Eine detaillierte Darstellung der beschriebenen Informationen wird in Abschnitt 6.3.2 im ausgewählten Datenformat gezeigt. 5 Modellierung der Maschinenfunktion 84

5.2.4 Informationen im Verhaltensmodell Zum gemeinsamen Verständnis über das zu errichtende Produktionssystem ist es notwendig, nicht nur dessen Funktionen zu kennen, sondern auch sein gesteuertes Verhalten. Dazu wird eine Prozessbeschreibung in Form eines Verhaltensmodells genutzt, die darstellt, welche Systemfunktionen in welcher Reihenfolge ausgeführt werden müssen, um von einem definierten Anfangszustand zu einem definierten Endzustand zu gelangen. In einer frühen Phase des Engineerings können damit durch den Maschinenbau bereits Verhaltensrestriktionen oder grobe Abläufe geplant werden, siehe behavior constraints in Abbildung 5-5. Die Verhaltensrestriktionen können den im Struktur- und Funktionsmodell implizit vorgesehenen (aber nicht explizit) modellierten Ablauf beschreiben. Ergänzend zur FPB und zum CAD-Modell wird im Verhaltensmodell dargestellt, welche Information eine Bedingung für die Ausführung welcher Aktion ist und welche parallelen oder alternativen Vorgänge vorgesehen sind. Dies wird in der Ablaufbeschreibung des Funktionsmodells nicht abgebildet. Die [IEC 61131-3] sieht für die formale Beschreibung der detaillierten Abläufe unterschiedliche Beschreibungsmittel vor. Für das vorliegende Beispiel wurde die Ablaufsprache ausgewählt. Abbildung 5-15 zeigt einen Teil eines Programms in Ablaufsprache an einem Beispiel des Bohrens. Es wird durch einzelne Schritte mit zugeordneten Aktionen dargestellt, dass die Rotation des Bohrers vor dem Absenken stattfinden muss und auch erst nach dem Erreichen der oberen Position des Linearantriebes abgeschaltet werden darf.

Abbildung 5-15: Verhaltensdarstellung in Ablaufsprache Dieses Programm wird in einer Programmorganisationseinheit (POE) abgelegt, in der neben der Liste der verwendeten Variablen (Signalliste) auch noch Informationen zur Hardware- Konfiguration der Steuerung abgelegt werden können. Das erstellte Programm dient dann als Grundgerüst für die Steuerungsprogrammierung durch den Automatisierungstechniker.

5.2.5 Verwendung von Merkmalen im Systemmodell An einem Beispiel wird im vorliegenden Abschnitt die Verwendung von Merkmalen im Systemmodell erklärt. Dazu wird der Prozessschritt „Drill_hole“ aus Abbildung 5-10 betrachtet. Mit den verbundenen Produkten und der zugeordneten Technischen Ressource wird die Funktion „Bohrung herstellen“ dargestellt. Zur Beschreibung der einzelnen Elemente 5 Modellierung der Maschinenfunktion 85 werden Merkmale verwendet, die über ein Aussageziel (ASZ) in Form einer Zusicherung, einer Anforderung oder einem Ist-Wert verfügen. Zusätzlich wird im folgenden Beispiel die Komponente aus dem Strukturmodell betrachtet, welche die Funktion der Technischen Ressource ausführen wird. Der Übersicht halber wird hier eine vereinfachte Darstellung der Merkmale ohne Trennung von Wert und Einheit verwendet. Abbildung 5-16 zeigt als erstes Element das Eingangsprodukt in dem beschriebenen Prozessschritt. Es besitzt das Element Loch als Anforderung mit dem Merkmal Durchmesser sowie das Merkmal Material, welches den Wert PLA besitzt. Dabei handelt es sich um einen Ist-Wert. Der Prozessschritt hat das Merkmal Funktion mit dem Wert Loch herstellen und dem Aussageziel Anforderung. Der Prozessschritt stellt damit eine Anforderung nach einer bestimmten Funktion an eine Technische Ressource, wie durch die Pfeile in der Abbildung 5-16 verdeutlicht wird. Zudem wird das Merkmal Durchmesser verwendet, um den Prozessschritt weiter zu beschreiben. Die Technische Ressource sichert die geforderte Funktion des Prozessschrittes zu. Zugleich fordert die Technische Ressource eine detailliertere Funktion von einer physischen Komponente. Dies ist durch die beschriebene stufenweise Lösungsfindung beim funktionsorientierten Engineering bedingt. Hier wurde dementsprechend die Funktion Bohren ausgewählt, um die Funktion Loch herstellen zu realisieren.

Abbildung 5-16: Beispiel für Merkmale der Elemente des Systemmodells Das Merkmal des Durchmessers wird als Anforderung durch die Technische Ressource weitergegeben. Zusätzliche Merkmale, wie die Leistung der Bohrmaschine, sind in der Technischen Ressource abgelegt. Die geforderte Leistung ergibt sich in diesem Beispiel aus einer Berechnung im Engineering-Werkzeug aus der Kombination der Merkmale Material des Produktes und dem Durchmesser der Bohrung. Die physische Komponente aus dem Strukturmodell muss nun die gestellten Anforderungen der Technischen Ressource erfüllen. Im Gegenzug stellt die Komponente selbst Anforderungen an die Technische Ressource und somit auch an den Prozessschritt. Im dargestellten Fall ist das die Energieversorgung mit 12 Volt Gleichstrom. Im Engineering hat das zur Folge, dass gegebenenfalls die Energie für diesen Prozessschritt im Funktionsmodell ergänzt werden muss.

5 Modellierung der Maschinenfunktion 86

5.3 Zusammenhänge zwischen Maschinenfunktionen Das Systemmodell kann in seiner Entstehung ohne die vollständigen Teilmodelle existieren und ausgetauscht werden. Wird in einem ersten Planungsschritt mit dem Funktionsmodell geplant, kann zu einem späteren Zeitpunkt im Engineering-Prozess das Strukturmodell daraus abgeleitet werden, indem eine Modulbildung schon durch die Strukturierung der Funktionen vorgenommen wird. Diese Module können als grobe Strukturierung des Strukturmodells dienen. In einem ausgeplanten Produktionssystem ist das Systemmodell vollständig vorhanden und beschreibt alle relevanten Aspekte des Systems. Zusätzliche Informationen können jederzeit in das Systemmodell integriert werden, indem neue Teilmodelle erstellt und in das Systemmodell eingepflegt werden. Die drei beschriebenen Teilmodelle des Systemmodells werden miteinander verbunden. Dadurch werden Zusammenhänge zwischen den Teilmodellen und den darin enthaltenen Elementen dargestellt. Die folgende Tabelle 5-2 gibt einen Überblick über die Verbindungstypen, die für den vorliegenden Ansatz definiert sind. Im Weiteren wird detailliert auf ausgewählte Verbindungstypen eingegangen.

Tabelle 5-2: Verbindungstypen zur Verbindung der Elemente und der Teilmodelle

Modellüber- Struktur- Funktions- Verhaltens- Modellinterne greifende Nr. Bezeichnung model model model Verbindung Verbindung A1 StructuralFlowMaterial X X A2 StructuralFlowInformation X X A3 StructuralFlowEnergy X X A4 StructuralConnection X X B1 FunctionalFlow X X B2 FunctionalUse X X C1 COLLADAInterface X X X X C2 PLCopenXMLInterface X X D1 InterfaceBetween_ FunctionStructure X X X D2 InterfaceBetween_ FunctionBehavior X X X D3 InterfaceBetween_ BehaviorStructure X X X

5.3.1 Verbindungen zwischen Elementen innerhalb der Teilmodelle Im Folgenden werden die durch den vorgestellten Ansatz definierten Verbindungen zwischen den Elementen innerhalb der einzelnen Teilmodelle beschrieben und an Hand eines Beispiels erklärt. Innerhalb des Strukturmodells sind vier Verbindungen (Tabelle 5-2, A1-A4) zwischen den Elementen vorgesehen. Die ersten drei Verbindungen beschreiben Flüsse innerhalb des Strukturmodells, die in Material-, Informations- und Energiefluss unterschieden werden. Eine Materialfluss-Verbindung (Tabelle 5-2, A1) liegt zwischen zwei Elementen vor, wenn zwischen diesen ein Produkt oder Material ausgetauscht wird. Dies ist beispielsweise bei einer Verbindung von zwei Förderbändern der Fall, an deren Schnittstelle Produkte oder Material von dem einen auf das andere Förderband übergeben wird. Ebenso ist diese Verbindung zwischen einem Rohr und einem Flansch einsetzbar, da zwischen diesen beiden Elementen in einem verfahrenstechnischen Produktionssystem Material übergeben wird. Innerhalb des Strukturmodells lassen sich mit Hilfe dieser Verbindungen Materialflüsse abbilden und mit Eigenschaften, die den Verbindungen zugewiesen werden, detailliert beschreiben. 5 Modellierung der Maschinenfunktion 87

Informationsflüsse (Tabelle 5-2, A2) beschreiben den Fluss von Daten, die zwischen Elementen des Strukturmodells ausgetauscht werden. Dies kann zwischen einem Sensor/Aktor und einer Steuerung oder zwischen Steuerungen und übergeordneten Systemen (Prozessleitsystem) geschehen. Über Merkmale, die diesen Verbindungen zugeordnet werden, lassen sich Details, wie die verwendete Übertragungstechnik und Signalarten (analog, digital) im Strukturmodell abbilden. Hier kann zudem die Verkabelung der einzelnen Elemente eines Systems modelliert werden. Dies gilt analog zu den Energieflüssen und deren Verbindungen im Strukturmodell. Ein Energiefluss (Tabelle 5-2, A3) beschreibt die energietechnische Verbindung zweier Elemente. Für die Modellierung von Energieverbindungen kann die Modellierung als Quelle/Senke-Modellierung ausgeführt werden. Als Energieträger werden in Systemen häufig elektrischer Strom, pneumatische und hydraulische Systeme eingesetzt. Als Beispiel ist hier die elektrische Verbindung eines Motors in einem System zu nennen oder die pneumatische Versorgung eines Ventils. Auch diese Verbindungen im Strukturmodell lassen sich durch Merkmale näher beschreiben. Die letzte Verbindung im Strukturmodell ist die Montageverbindung (Tabelle 5-2, A4). Sie beschreibt die Verbindung zwischen Elementen aus dem Strukturmodell, die bei der Montage ausgeführt werden. Beispielsweise, dass Rohr und Flansch über zehn M12- Schrauben miteinander verbunden sind und diese mit 150 Nm festgezogen werden müssen. Im Funktionsmodell sind zwei Verbindungstypen (Tabelle 5-2, B1 und B2) definiert. Zum einen die Flussverbindungen, die wie im Strukturmodell zur Darstellung von Stoff- Informations- und Energieflüssen genutzt werden. Im Funktionsmodell erfolgt dies auf abstrakterer Ebene, beispielsweise ohne die Modellierung der Kabel oder Schlauchverbindungen und deren Schnittstellen. Zum anderen die Nutzungsbeziehung, die zwischen dem Prozessschritt und der zugeordneten Technischen Ressource modelliert wird und ausdrückt, dass eine bestimmte Funktion in einem Prozess durch eine zugeordnete Technische Ressource ausgeführt wird. Das Verhaltensmodell verfügt über zwei Schnittstellen (Tabelle 5-2, C1 und C2), die Verbindungen mit externen Daten in PLCopen XML- oder COLLADA-Dateien realisieren. Diese Schnittstellen sind von dem AutomationML-Interface ExternalInterface abgeleitet, siehe Abschnitt 3.3.6.

5.3.2 Verbindungen zwischen den Teilmodellen des Systemmodells Es existieren Verbindungen zwischen den Teilmodellen des Systemmodells, die durch die Verbindungen im Metamodell des Systemmodells nachzuvollziehen sind, siehe Abbildung 5-17. Das dargestellte Metamodell enthält die drei Teilmodelle zur Abbildung der Funktionen (grün), der Struktur (gelb) und des Verhaltens (grau) eines Systems. 5 Modellierung der Maschinenfunktion 88

Abbildung 5-17: Metamodell des Systemmodells Im Folgenden wird auf die jeweiligen Verbindungen zwischen den Teilmodellen eingegangen. Funktion – Struktur Eine solche Verbindung wird zwischen dem Funktionsmodell und dem Strukturmodell (Tabelle 5-2, D1) angelegt. Hier wird eine Technische Ressource, die in der funktionsorientierten Beschreibung einen Prozessschritt ausführt, mit der entsprechenden tatsächlich geplanten physischen Komponente in der Strukturbeschreibung verbunden. Somit werden Ortsinformationen (wo ist die Komponente im System verbaut?) für die Prozesse im Funktionsmodell bekannt und die Funktionen der Komponente werden im Strukturmodell ersichtlich. Dadurch werden beide Teil-Modelle mit Informationen angereichert. Ein weiterer Vorteil dieser Verbindung zwischen Funktions- und Strukturmodell ist, das sowohl Technische Ressourcen als auch konkrete Komponenten (Konstruktions-/Kaufteile) getrennt voneinander in einem eigenen Modell geplant werden. Daraus folgt, dass die Planung von Funktionen und Komponenten nacheinander und getrennt voneinander stattfinden kann. Somit wird während der Planung eines Systems ein möglichst großer Lösungsraum offen gehalten, um eine Funktion in einem Prozess ausführen zu lassen, da die Auswahl der Komponente erst später erfolgt. Die Technische Ressource beschreibt die Anforderungen, die erfüllt werden müssen, um den mit ihr verbundenen Prozess ausführen zu können. Dies können beispielsweise Umgebungsbedingungen sein, welche die physische Komponente (System) aushalten muss. Das System hingegen besteht aus physischen Komponenten mit bestimmten Merkmalen. Diese Komponenten sollten die Anforderungen der Technischen Ressource erfüllen. Es kann mit dem vorliegenden Ansatz so geplant werden, dass eine Komponente mehrere Funktionen erfüllen und somit zur Ausführung von mehreren Prozessschritten genutzt werden kann. Denkbar ist ebenfalls, dass mehrere Komponenten benötigt werden, um die Anforderungen einer Technischen Ressource zu erfüllen. Dies wird durch die Verbindung von Funktionsmodell und Strukturmodell realisiert.

5 Modellierung der Maschinenfunktion 89

Werden im betrachteten System Produkte hergestellt und sind diese im Engineering-Prozess zu modellieren (weil sie die Anforderungen an das Produktionssystem stellen), so kann eine weitere Verbindung zwischen den Teilmodellen angelegt werden. Dazu werden die Produktobjekte des Funktionsmodells mit den Strukturdaten der Produkte verbunden, wenn diese ebenfalls in einem Strukturmodell vorliegen. Diese Modellierung der Produkte dient dann zur Repräsentation der Fertigungsbedürfnisse, da mit dem Strukturmodell des Produktes auch ein Funktionsmodell des Produktes verbunden sein kann. Diese Fertigungsbedürfnisse des Produktes beinhalten die stofflichen oder geometrischen Eigenschaftsänderungen des Produktes und sind als einzelne Funktionen hinterlegt. Diese Funktionen werden in den entsprechenden Prozessen des Systems ausgeführt und in den Prozessoperatoren des Funktionsmodells abgebildet. Funktion – Verhalten Eine weitere Verbindung zwischen den Teilmodellen (Tabelle 5-2, D2) kann zwischen den Informationsobjekten des Funktionsmodells (dargestellt durch ein blaues Sechseck in der Formalisierten Prozessbeschreibung) und den Signalen im Verhaltensmodell gezogen werden. In der Entwurfsphase dienen die Signallisten zum Datenaustausch zwischen den Gewerken. Dabei kann der Elektrotechnik-Planer dem SPS-Programmierer die bereits geplanten Signallisten der Steuerungen übertragen. Für diesen wird somit nachvollziehbar, welche Variable der Verhaltensbeschreibung in welcher Funktion benutzt wird. Dies fördert das Verständnis über den Ablauf im Produktionssystem. Eine weitere Verbindung ist zwischen der Verhaltensbeschreibung und der Technischen Ressource zu finden. In der Verhaltensbeschreibung können sich Ablaufbeschreibungen oder Logiken befinden, die mit der angesprochenen Verbindung einer konkreten Technischen Ressource zugewiesen werden. Diese Verhaltensbeschreibungen sind für den SPS-Programmierer hilfreich, um die Funktionen des Produktionssystems zu verstehen und in Programm-Code umzusetzen. Struktur – Verhalten Eine weitere Verbindung ist zwischen Struktur- und Verhaltensmodell (Tabelle 5-2, D3) zu finden. Hier können den bereits geplanten Komponenten im Strukturmodell die Variablen des Verhaltensmodells zugewiesen werden. Damit können die Variablen den einzelnen Anschlüssen der SPS oder den entsprechenden Sensoren/Aktoren zugeordnet werden. Zudem ist über die Verbindung zum Funktionsmodell erkennbar, welche Funktion diese Variable im System übernimmt. Über die gleiche Verbindung ist eine Zuordnung des gesamten Verhaltens in Form einer Programmorganisationseinheit (POE) zu einer Funktionseinheit im Strukturmodell möglich.

5 Modellierung der Maschinenfunktion 90

5.4 Zusammenfassung Das vorliegende Kapitel 5 stellt den Aufbau, die Verwendung und die Inhalte eines Systemmodells dar, das im Engineering eines fertigungstechnischen Produktionssystems erstellt und für dessen Errichtung und Betrieb genutzt werden kann. Forschungsfrage 4 kann an dieser Stelle beantwortet werden:

4. Wie muss ein Modell eines Systems strukturiert sein, um die Gewerke-übergreifende Kommunikation optimal zu unterstützen? Und welche weiteren Informationen an den Schnittpunkten der Gewerke sind über das System abzubilden?

Aus den untersuchten Ansätzen und den betrachteten Engineering-Workflows ist abzuleiten, dass sich das Systemmodell an den Funktionen des Systems orientieren muss, um eine optimale Kommunikation zwischen den Gewerken zu ermöglichen. Daher ist ein Funktionsmodell im Engineering zu entwerfen, welches die Anforderungen an das Produktionssystem aufnimmt und lösungsneutral als Funktionen abbildet. Die weiteren Informationen, die zwischen den beteiligten Gewerken ausgetauscht werden, lassen sich in einem Struktur- und in einem Verhaltensmodell unterbringen. Die drei beschriebenen Teilmodelle bilden zusammen das Systemmodell des Produktionssystems. Sie sind stark miteinander vernetzt, aber können dennoch unabhängig voneinander ausgetauscht und genutzt werden. Zudem verfügen die im Systemmodell enthaltenen Elemente über eine detaillierte Beschreibung, die über Merkmale realisiert wird. Es ist an einem Beispiel dargestellt, wie dieses Systemmodell in einem systematischen Engineering-Workflow durch die unterschiedlichen Gewerken mit Informationen befüllt wird. Damit das Systemmodell genutzt werden kann, ist es in einem rechnerinterpretierbaren Datenformat abzubilden und auszutauschen. Dies wird im nachfolgenden Kapitel 6 dargestellt. Es schließt mit einer detaillierten Zusammenfassung des vorgestellten Ansatzes und einer direkten Abgrenzung zu ähnlichen Ansätzen ab.

6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion 91

6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion Um das erstellte Systemmodell im Engineering verlustfrei zwischen den Gewerken rechnerinterpretierbar auszutauschen, ist es in einem geeigneten Datenformat abzubilden. Um eine Bewertung der Eignung eines Datenformates für den Austausch der Daten aus dem Systemmodell durchführen zu können, ist zuerst die Ausgangslage bei einem solchen Datenaustausch zu untersuchen. Dazu wird im folgenden Abschnitt der Ablauf eines typischen Datenaustausches im Engineering beschrieben und die Möglichkeiten der Erstellung von Schnittstellen zwischen den beteiligten Werkzeugen diskutiert. Darauf folgend werden unterschiedliche Datenformate betrachtet, die sich für den beschriebenen Einsatzzweck eignen. Letztendlich wird das am besten geeignete Datenformat ausgewählt und für die Umsetzung der beschriebenen Modellierungsmethode genutzt.

6.1 Ablauf eines Datenaustausches im Engineering Wie in Abschnitt 3.2 bereits erklärt, existieren für den Datenaustausch im Engineering zwei grundsätzliche Möglichkeiten [FDB+12]: 1. Die Verwendung einer monolithischen Werkzeuglandschaft eines Herstellers (Tool- Suite), bei der die Daten aller Werkzeuge in einem zentralen Daten-Backbone gespeichert werden und von allen Werkzeugen aus abgerufen und verändert werden können. Die Vor- und Nachteile wurden bereits in Abschnitt 3.2 diskutiert. 2. Die Nutzung von spezifischen Werkzeugen unterschiedlicher Hersteller mit Import- und Exportfunktionalitäten und einer jeweils eigenen Datenablage. Für diese ist der nachfolgend betrachtete Datenaustausch von Bedeutung. Je nach Offenheit der Werkzeuge stehen hier unterschiedliche Technologien des Datenzugriffs dem Nutzer der Werkzeuge zur Verfügung. Neben der API (application programming interface, wörtlich „Anwendungsprogrammierschnittstelle“) ist der Datei-Export die verbreitetste Methode des Datenaustausches. Im Datenaustausch zwischen den beteiligten Gewerken und ihren Werkzeugen werden Bestrebungen unternommen, die in den Unternehmen existenten Engineering-Werkzeuge über Schnittstellen miteinander zu verknüpfen. Zusätzlich wird dabei versucht, eine integrierte, disziplinübergreifende Modellierung zu realisieren [FFV13]. Auf die Besonderheiten des Datenaustausches zwischen zwei Werkzeugen und innerhalb eines Werkzeugverbundes wird in den folgenden beiden Abschnitten eingegangen.

6.1.1 Datenaustausch zwischen zwei Werkzeugen Abbildung 6-1 zeigt den detaillierten Ablauf eines Datenaustausches zwischen zwei Engineering-Werkzeugen mit Hilfe eines dateibasierten Datenaustausches auf, der im Folgenden kurz beschrieben wird (von links nach rechts). Dieser Datenaustausch kann über die vorhandenen Export-/Import-Funktionalitäten der Werkzeuge geschehen oder über eine API eigens dafür implementiert werden. Als erster Schritt beim Export von Daten aus einem Werkzeug muss ein Mapping zwischen dem internen Informationsmodell des Werkzeuges auf das Informationsmodell des Datenformates erfolgen. Dies kann innerhalb (über den Zugriff über eine API auf die Werkzeug-Inhalte) oder außerhalb (über das Werkzeug-eigene Exportformat und einen Konverter) des Werkzeuges erfolgen. Die Austauschdatei wird entsprechend gespeichert und rechnerinterpretierbar ausgetauscht. Im Ziel-Werkzeug wird die Datei eingelesen und mit Hilfe eines Mappings und eines Deltavergleiches in das Zielformat übertragen. Das Mapping 6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion 92

überführt die Daten aus dem Informationsmodell des Datenformates in das Informationsmodell des Zielwerkzeuges. Vor oder auch nach diesem Schritt sollte ein Deltavergleich stattfinden, der den Werkzeug-internen Datenstand und den neuen Datenstand aus dem Datenaustausch miteinander vergleicht. Hier ist die Verwendung von eindeutigen Identifikatoren (ID‘s) unerlässlich, um auch Namensänderungen von gleichbleibenden Objekten zu erkennen. Die aufgetretenen Differenzen zwischen den beiden Datenständen sollten dem Nutzer zur Information oder zur Entscheidung angezeigt werden.

Abbildung 6-1: Schematischer Ablauf des Datenaustausches zwischen unterschiedlichen Engineering- Werkzeugen Um die Durchgängigkeit der Informationen innerhalb des Engineering-Workflows zu gewährleisten, sollte das dem gesamten Workflow zugrunde liegende Systemmodell hinsichtlich Struktur, Semantik und Darstellung möglichst einheitlich sein, um den Aufwand für die Überführung in andere Informationsmodelle und den Datenverlust an dieser Stelle so gering wie möglich zu halten [VDI/VDE 3695-3]. Aus dem beschriebenen Ablauf des Datenaustausches abgeleitet, kann eine Schnittstelle in einer Werkzeugkette implementiert werden, wenn die folgenden Schritte durchgeführt werden: 1. Untersuchung der Datenstruktur der Schnittstellen beider Werkzeuge (Offenheit, ID's, Attribute/Merkmale), 2. Untersuchung der auszutauschenden Informationen zwischen den beiden Werkzeugen, 3. Erstellung eines Informationsmodells für das Datenformat, 4. Umsetzung in den Werkzeugen: Anpassen der Export-/Import-Funktionen (über API) oder Programmieren eines externen Werkzeuges (Konverter) zwischen den Werkzeugen, 5. Validierung des Informationsmodells und der Schnittstellen durch Tests.

6.1.2 Datenaustausch in einem Werkzeugverbund Ähnlich gestaltet sich das Vorgehen für die Implementierung in einem Werkzeugverbund. Abbildung 6-2 stellt den Ablauf des Datenaustausches in einem Verbund von Werkzeugen dar. Dabei ist das Informationsmodell des Datenformates von besonderer Bedeutung, da es zwischen mehr als zwei beteiligten Interessengruppen (vertreten durch die unterschiedlichen Werkzeuge) abgestimmt werden muss. 6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion 93

Abbildung 6-2: Schematischer Ablauf des Datenaustausches in einem Werkzeugverbund Durch die Arbeiten im GMA-Fachausschuss 6.16 „Integriertes Engineering in der Prozessleittechnik“ konnte ein methodisches Vorgehen entwickelt werden, dass sich aus dem beschrieben Vorgehen für den Datenaustausch zwischen zwei Werkzeugen aus Abschnitt 6.1.1 ableitet und für die Definition einer Schnittstelle für mehrere Engineering- Werkzeuge in einem Verbund erweitert wurde. Folgende Punkte sind dabei im Kern durchzuführen: 1. Untersuchung der auszutauschenden Daten zwischen den Werkzeugen (Sammeln von Austauschdateien, Bilden einer Schnittmenge der Daten aus den Dateien), 2. Aufstellen eines Informationsmodells (kleine Inhaltspakete, anstatt allumfassendes Modell), 3. Festlegen von Regeln zum Datenaustausch, 4. Anpassen der Werkzeuge an das Informationsmodell, 5. Normung durch Feedback aus der Praxis, schrittweise Erweiterung des Informationsmodells. Dabei sind die verwendeten Beschreibungsmittel bedeutsam, da sie die Grundlage für die Schnittstellen-Definition bilden. Diese Beschreibungsmittel dienen zum einen dem neutralen Austausch von Informationen und zum anderen zur Definition, in welcher Struktur die Daten ausgetauscht werden. Eine wesentliche Anforderung an die Beschreibungsmittel ist dabei, dass sie Werkzeug- und Gewerke-neutral sind, um die Akzeptanz der unterschiedlichen Interessengruppen sicherzustellen. Zudem sollten die Beschreibungsmittel einfach zu verstehen, möglichst genormt und vielfach anwendbar sein. Dies sichert die Durchsetzung in den Unternehmen und die schrittweise Erweiterung der Schnittstelle. Daher wird im folgenden Abschnitt eine kurze Betrachtung unterschiedlicher Beschreibungsmittel und Datenformate durchgeführt.

6.2 Datenformate Die folgende Auswahl an Datenformaten und Beschreibungsmitteln beschränkt sich auf einige etablierte sowie in der Entwicklung befindliche Formate, die in der Domäne der Automatisierungstechnik bekannt sind.

6.2.1 Unified Modeling Language (UML) Im Gegensatz zu den im Abschnitt 4.4.3.3 bereits beschriebenen UML- Aktivitätsdiagrammen, die für die Verwendung zur Ablaufbeschreibungen genutzt werden, wird hier auf die UML-Klassendiagramme eingegangen. 6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion 94

Diese eignen sich zur Strukturierung der Daten, die im Datenformat abgebildet und transportiert werden. Damit dienen die Klassendiagramme als Metamodell und somit als Strukturierungsvorschrift und Hilfe für die Erstellung der notwendigen Schnittstellen [KEC11]. Die Erfahrungen aus den unterschiedlichen Arbeitskreisen zeigen, dass die UML- Klassendiagramme Gewerke-übergreifend verstanden und genutzt werden.

6.2.2 Systems Modeling Language (SysML) SysML [OMG17@] ist eine grafische Modellierungssprache, die von der Object Management Group (OMG) für die Entwicklung von großen, komplexen und multi-disziplinären Systemen mit Hilfe eines Modell-basierten Ansatzes standardisiert wurde. Diese Modellierungssprache hält Modellierungskonzepte bereit, die die Anforderungen an ein System, seine Struktur und sein Verhalten abbilden können. Gemeinsam bilden diese ein kohärentes Model des Systems als Basis für dessen Entwurf, seine Implementierung und die Analyse des Systems. Während SysML schon in den Domänen der Luftfahrt- und Verteidigungsindustrie genutzt wurde, um komplexe, multi-disziplinäre Systeme zu entwickeln, wird es nun auch in der Automatisierungsdomäne genutzt [BBL+16]. Eine vollständige Systembeschreibung mittels SysML lässt sich durch vier Säulen repräsentieren, die durch unterschiedliche Diagramme abgebildet werden: • Struktur (Block definition diagram, Internal block diagram), • Verhalten (Sequence diagramm, State machine, Activity diagram), • Anforderungen (Requirement diagram), • Parameter (Parametric diagram = für Gleichungen). Die Diagramme können zu einem komplexen Model verbunden werden. Dafür können Allokationen genutzt werden. Dadurch wird beispielsweise ersichtlich, welche Aktivitäten durch welche Objekte ausgeführt werden. Oder es wird eine Verbindung zwischen Anforderungen und Objekten gezogen, um zu zeigen, dass durch das Objekt die Anforderungen erfüllt werden. SysML wurde als UML-Profil entworfen und erweitert UML um Elemente zur Abbildung des Systems Engineering. Dabei wird das UML4SysML Subset genutzt, das die Elemente enthält, die SysML mit UML gemeinsam hat. Die von SysML verwendeten Diagramme sind mit denen aus UML vergleichbar: das UML-Klassendiagramm und das Strukturdiagramm wurden entsprechend angepasst und in das Block definition diagram und Internal block diagram umbenannt, um die Struktur eines Systems zu beschreiben [BBL+16].

6.2.3 XML-basierte Datenformate AutomationML ist ein standardisiertes, neutrales, XML-basiertes Datenaustauschformat, das in der Forschung, vgl. [JCS+12; BBM+15; BAKU16], seit längerem in verschiedenen Domänen (Prozessindustrie, vgl. [SST+15*], Fertigungstechnik, vgl. [BMW+15], Gebäudeautomation, vgl. [GDS+16*]) für unterschiedliche Aspekte verwendet und in der Industrie, vgl. [HÄDR14; DTB+15*] zunehmend eingesetzt wird. Eine detaillierte Beschreibung der Grundelemente von AutomationML ist in Abschnitt 3.3.6 zu finden. Neben AutomationML gibt es noch einige andere XML-basierte Datenformate, die im Einsatz sind oder in der Forschung [HMS+07; BBL+16] untersucht werden. Häufig werden diese für einen sehr speziellen Einsatzraum geschaffen und können eine gute Ergänzung zu AutomationML darstellen, um sehr spezifische Daten abzubilden (MathML, vgl. [W3C17@], @ @ RuleML, vgl. [RUL17 ], PetriNetML, vgl. [PNM17 ]). 6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion 95

6.2.4 Tabellen und Datenbanken Tabellenbasierte Austauschformate sind die am häufigsten verwendeten Export- und Importformate für Daten der gängigen Engineering-Werkzeuge in den unterschiedlichen Domänen, siehe dazu Abschnitt 3.2. Gründe für diese große Verbreitung dieses Formates sind die einfache Handhabung, die schnelle Bearbeitung großer Datenmengen und der flexible Einsatz. Nachteilig daran sind die folgenden Punkte: Bei jedem Datenaustausch mit tabellenbasierten Dateien muss vorher mit den beteiligten Interessengruppen aufwändig abgestimmt werden, wie die Austauschdatei aufgebaut sein soll, damit jeder die Daten in den jeweiligen Zeilen und Spalten interpretieren kann. Auch die Formate und Inhalte der Zellen müssen abgestimmt sein. Beispielsweise muss festgelegt werden, ob Wert und dazugehörige Einheit in einer Zelle stehen oder in zwei Zellen. Zudem muss definiert werden, welche Einheit in welcher Schreibweise angewendet wird. Dies ist mit einem hohen Abstimmungsaufwand und einer großen Fehleranfälligkeit verbunden. Aber nur mit diesen Aufwänden kann ein automatisiertes Auslesen großer Datenmengen realisiert werden.

6.2.5 Web-Technologien [BMS+17] beschreibt das Konzept der Integrationsplattform „AutomationML Hub“. Dieses stellt eine herstellerneutrale Online-Plattform zur Verfügung, die basierend auf AutomationML zur Integration heterogener Werkzeuge und Informationsmodelle beiträgt. Dabei wird ein integriertes Modell des Produktionssystems erzeugt, das über Schnittstellen zu den unterschiedlichen verwendeten Engineering-Werkzeugen der Beteiligten angereichert wird. Dadurch können beispielsweise Daten der Gewerke Konstruktion, Elektrotechnik und Steuerungsprogrammierung zusammengeführt werden. Die Durchsetzung des Konzeptes hängt entscheidend von der Offenheit der Engineering- Werkzeuge bezüglich ihrer Daten und Modelle ab, sowie von der Adaptierbarkeit des Systems an den Engineering-Workflow der Nutzer.

6.2.6 Zusammenfassung Für den vorliegenden Anwendungsfall wird das XML-basierte Datenaustauschformat AutomationML ausgewählt. Durch seine objektbasierte Datenhaltung und den bereits erreichten Standardisierungsgrad eignet es sich für die vorliegenden Anforderungen von den dargestellten Formaten am besten. Zudem ist es in der Domäne der Automatisierungstechnik durch die zahlreichen aufgeführten Forschungs- und Standardisierungsaktivitäten bekannt und etabliert. Wie gezeigt, existieren zu verschiedenen Informationen aus dem Engineering Ansätze, dies in AutomationML abzubilden und zu übertragen. An diesen kann sich für den vorliegenden Ansatz orientiert werden. Mit der @ AutomationML-Engine [AUT17A ] steht zudem eine umfangreiche Methodensammlung für die Implementierung der benötigten Funktionalitäten des Schreibens und Lesens einer AutomationML-Datei zur Verfügung. Das Entwickeln der Struktur der Austauschdatei kann @ durch den bereits vorhandenen AutomationML-Editor [AUT17C ] unterstützt werden. Damit ist das händische Erzeugen und Befüllen einer AutomationML-Datei möglich, um die entwickelten Strukturierungs-Ansätze für die Engineering-Informationen innerhalb der Datei zu testen. Diese Strukturierung wird durch Metamodelle vorgegeben. Für die Darstellung der Metamodelle wird auf UML-Klassendiagramm zurückgegriffen.

6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion 96

6.3 Abbildung des Systemmodells im Datenaustauschformat Das beschriebene Systemmodell wird in den folgenden Abschnitten im ausgewählten Datenaustauschformat AutomationML abgebildet. Dabei wird im Einzelnen auf die Modellierung der drei Teilmodelle und der Verbindungen innerhalb und zwischen den Teilmodellen eingegangen.

6.3.1 Abbildung des Funktionsmodells Zur Nutzung des Funktionsmodells als Gewerke-übergreifendes Kommunikationsmittel muss dieses in einem rechnerinterpretierbaren Datenformat vorliegen. Dazu wird in der vorliegenden Arbeit das Datenaustauschformat AutomationML genutzt. Im Folgenden wird die Abbildung des Funktionsmodells in AutomationML dargestellt. Der hier vorliegende Ansatz erweitert die Abbildung der Formalisierten Prozessbeschreibung von [JCS+12] um weitere Details. Im Gegensatz zu dem Ansatz aus [JCS+12] wird die Technische Ressource nicht direkt in einer Baustruktur abgelegt, da sie somit nicht Bestandteil der Prozessbeschreibung und des Funktionsmodells wäre. Im vorliegenden Ansatz herrscht eine Trennung zwischen dem Funktionsmodell mit seinen abstrakten Technischen Ressourcen und dem Strukturmodell mit seinen Komponenten. Es ist möglich, die beiden Modelle zu verbinden, wie im Folgenden aufgezeigt wird. Zudem wird die Dekomposition von Prozessschritten und deren Umsetzung in AutomationML detaillierter beschrieben. Für die Umsetzung in AutomationML ist das in Abbildung 5-1 dargestellte Metamodell bindend. Die folgende Tabelle 6-1 stellt eine gemischte Darstellung zwischen der FPB und der gängigen AutomationML-Symbolik dar und dient zum besseren Verständnis für die Modellierung der Verbindungen.

Tabelle 6-1: Übersicht über die Elemente der FPB mit ihren Schnittstellen

Die unterschiedlichen Flüsse (von Produkt, Energie, Information) verfügen über gerichtete Schnittstellen zur Abbildung dieses Flusses.

Der Prozessoperator verfügt auch über gerichtete Schnittstellen zu Abbildung des Flusses. Eine weitere Schnittstelle ist die „Use“-Schnittstelle, die den Prozess über diese Nutzungsbeziehung mit der Technischen Ressource verbindet.

Die Technische Ressource ist mit der „Use“- Schnittstelle mit dem dazu gehörigen Prozess verbunden. Über die „Represents“-Schnittstelle ist eine Verbindung zu einer Komponente im Strukturmodell möglich. Die Schnittstellen im Überblick. Sie können mit Attributen näher spezifiziert werden, wie in Klammern dargestellt.

Die Modellierung mittels gerichteter Schnittstellen ist notwendig, um eine automatisierte Auswertung der Flussrichtung vornehmen zu können. Dies ist notwendig, da in AutomationML der INTERNALLINK als Verbinder von zwei Schnittstellen keine Richtung hat 6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion 97 und auch nicht mit Attributen näher beschrieben werden kann. Durch dieses Vorgehen sind Software-Werkzeuge einfacher in der Lage, die Verbindungen zwischen den Elementen zu interpretieren und die Flussrichtung korrekt von oben nach unten darzustellen.

Zur Abbildung in AutomationML wird in der INSTANCEHIERARCHY ein INTERNALELEMENT erzeugt, welches das Funktionsmodell des abzubildenden Systems repräsentiert. In Abbildung 6-3 ist dies für eine Produktionslinie „Testanlage“ mit der Produktionseinheit „Testmodul“ dargestellt. Darunter befinden sich drei Container für die Produkt-, Prozess- und Ressourcenstruktur. Diese sind als INTERNALELEMENTS mit der jeweiligen Rolle Product- /Process-/ResourceHierarchy definiert und bilden die höchste Ebene der jeweiligen Elemente.

Abbildung 6-3: Gruppierung der Elemente der FPB des Funktionsmodells in AutomationML Innerhalb dieser Container lassen sich die entsprechenden Elemente beliebig tief hierarchisch gliedern. Das entspricht der Dekomposition in der FPB. Beispielhaft ist dies für das „Produkt_A“ mit seinen, ihm zugeordneten Zwischenprodukten „Produkt_B“ und „Produkt_C“ dargestellt. Ebenso kann ein „Prozess_13“ in die Prozessschritte „Prozess_1“, „Prozess_2“ und „Prozess_3“ unterteilt werden.

Die Darstellung der Schnittstellen in AutomationML erfolgt mit Hilfe der INTERFACES. Diese sind für einen Prozess in Abbildung 6-4 dargestellt. Zu erkennen sind sowohl die Flüsse („Flow_In“, „Flow_Out“) des Prozesses, als auch die Nutzungsbeziehung („Process_Use“) zur Technischen Ressource. 6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion 98

Abbildung 6-4: Darstellung eines Prozesses im Funktionsmodell mit seinen Schnittstellen in AutomationML Die angesprochene Dekomposition eines Prozesses und speziell deren Abbildung in AutomationML wurde bisher in der Literatur nicht beschrieben und wird deshalb hier ausführlich dargestellt. Grundsätzlich gibt es unterschiedliche Möglichkeiten, eine solche Dekompositionsbeziehung darzustellen. Drei Möglichkeiten werden hier betrachtet und kurz diskutiert. Im Fokus stehen bei dieser Betrachtung die zusätzlichen Aufwände, die die getroffenen Festlegungen verursachen. Dies gilt sowohl für die mögliche Visualisierung der FPB aus AutomationML heraus als auch für den Im- und Export der FPB-Elemente des Funktionsmodells in ein oder aus einem Engineering-Werkzeug. 1. Möglichkeit: Alle Verbindungen werden nur auf der untersten Detaillierungsebene ausgeführt Im Laufe des Engineering-Prozesses werden die Prozessschritte dekomponiert, je mehr Details zu den Funktionen und den Technischen Ressourcen geplant werden. Hier könnten bei jeder Dekomposition eines Prozessschrittes die Verbindungen mit den davor und dahinter liegenden Produkten/Energien/Informationen getrennt und eine Detaillierungsebene tiefer erneut verbunden werden. Der Nachteil dieser Abbildungsform in AutomationML besteht darin, dass die Prozessschritte auf einer höheren Abstraktionsebene nicht mehr mit den Produkten/Energien/Informationen verbunden sind. Dies führt bei der Visualisierung zu aufwändigen Auswertefunktionen, in denen geprüft werden muss, in welcher der unterlagerten Ebenen die Prozessschritte mit den Produkten/Energien/Informationen verbunden sind. Diese Verbindungen müssen gefunden, ausgewertet und für den ausgewählten Abstraktionsgrad und den gewählten Prozessschritt dargestellt werden. Zudem kommt ein erhöhter Aufwand beim Abbilden der FPB in AutomationML, beispielsweise beim Export, hinzu. Da in dieser Schnittstelle die Festlegung umgesetzt werden muss, dass Verbindungen nur auf der untersten Ebene realisiert werden und alle darüber liegenden Verbindungen getrennt werden. Dies führt zu erheblichen Mehraufwand in der Schnittstellenprogrammierung.

6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion 99

2. Möglichkeit: Über die Attributierung der Schnittstellen zwischen Produkt und Prozessschritt wird die Verbindung einer Detaillierungsebene zugewiesen Bei dieser Möglichkeit werden bei der Dekomposition einzelner Prozessschritte zusätzliche Verbindungen zwischen den Produkten/Energien/Informationen und dem neuen, detaillierteren Prozessschritt angelegt. Dafür werden an den vor- und nachgelagerten Produkten/Energien/Informationen der betroffenen Prozessschritte zusätzliche Schnittstellen angelegt. Diese Schnittstellen, INTERFACES in AutomationML, enthalten ein Attribut Level, das die Detaillierungsebene des nachfolgenden Prozessschrittes angibt. Ähnliches würde bei der Komposition mehrerer Prozessschritte zu einem übergeordneten Prozessschritt erfolgen. Dabei bleiben alle Verbindungen enthalten. Es werden an den davor und danach liegenden Produkten/Energien/Informationen zusätzliche Schnittstellen angelegt und deren Wert des Attributs Level um eins verringert. Auch hier entstehen zusätzliche Aufwände in der Programmierung der Schnittstellen. Jedoch lassen sich in der Visualisierung der Inhalte der AutomationML-Datei alle Detaillierungsebenen der FPB ohne großen Aufwand in der Auswertung der Datei darstellen, da für jeden Prozessschritt alle Verbindungen erhalten sind und für jede Dekomposition ausgewählt werden kann, in welcher Detailstufe diese dargestellt werden soll. 3. Möglichkeit: Gruppierungen bilden, die die Sichten auf den unterschiedlichen Detaillierungsebenen darstellen

Zum Bilden von Gruppen ist in AutomationML das Gruppen-Konzept [DRA10] vorgesehen. Es erlaubt die Anordnung identischer Objekte in unterschiedlichen Hierarchien. Dabei existiert ein Master-Objekt, von dem Kopien als Mirror-Objekte angefertigt werden. Dies erfolgt durch Referenzierung auf das Master-Objekt. Eine Gruppierung mit diesem Master- Mirror-Konzept von AutomationML wurde verworfen, da die Mirror-Objekte keine Schnittstellen aufweisen. Eine strukturierte Darstellung einer Reihenfolge ist somit nur schwer (nicht über die Verbindungen sondern nur über Attribute) möglich. Einen zweiten Ansatz zur Gruppierung von Informationen in AutomationML bietet das Facetten-Konzept [DRA10], bei dem von einem Facetten-Objekt nur die für die jeweilige Sicht auf das Objekt relevanten Attribute und Schnittstellen in dieses Objekt übernommen werden. Auch das Facetten-Konzept von AutomationML ist zur Lösung der Dekompositionsbeziehung nicht hilfreich, da sich dieses nur auf Schnittstellen und Attribute von Objekten und nicht auf die Objekte selbst bezieht. Entscheidung: 2. Möglichkeit Daher wird für das weitere Vorgehen die zweite der hier vorgestellten Möglichkeiten gewählt. An einem abstrakten Beispiel wird das Vorgehen der Dekomposition kurz erläutert, siehe Abbildung 6-5. Es wird dargestellt, dass das „Produkt A“ über zwei Schnittstellen verfügt, die eine Flussbeziehung repräsentieren. Beide Schnittstellen verfügen über ein Attribut Level, welches die Ebene der Dekomposition angibt, in die die Flussbeziehung führt. Im vorliegenden Beispiel ist der Level 0 für die Verbindung zu „Prozess 13“ und Level 1 für die Verbindung zu „Prozess 1“. 6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion 100

Abbildung 6-5: Detaillierte Darstellung der Dekomposition eines Prozessschrittes Zusätzlich zur beschriebenen Attributierung der Schnittstellen von Prozessschritten und Produkten/Energien/Informationen zur Unterscheidung der verschiedenen Detailstufen werden weitere Attribute an den Schnittstellen benötigt. Diese Attribute bilden die Merkmale der jeweiligen Elemente des Systemmodells ab. Diese Merkmale lassen sich in AutomationML jeweils durch die Unterattribute Name, Wert, Einheit, Standardwert, Datentyp, Beschreibung und Einschränkungen beschreiben. Abbildung 6-6 stellt die Merkmale der Schnittstelle eines eingehenden Produktflusses eines Prozessschrittes dar. Darin werden die Merkmale Richtung, Verzweigungstyp und Level durch Attribute und ihre Unterattribute beschrieben. 6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion 101

Abbildung 6-6: Merkmale einer Schnittstelle modelliert als Attribute in AutomationML Zum einen wird die Flussrichtung als Attribut an der Schnittstelle festgelegt, an der die betreffende Flussverbindung verbunden wird. So lässt sich für die Visualisierung der FPB einfacher darstellen, in welche Richtung die Pfeile der Flüsse gerichtet sind. Eine Benennung der Schnittstelle oder die Bildung von zwei unterschiedlichen Schnittstellenklassen für Ein- und Ausgang ist eine alternative Möglichkeit dazu. Zum anderen wird an der Schnittstelle der Typ der eventuell vorhandenen Verzweigung angegeben. In der FPB sind alternative und parallele Verzweigungen möglich. Es wird daher innerhalb der Schnittstelle ein weiteres Attribut verwendet, der Verzweigungstyp. Somit kann in AutomationML abgebildet werden, dass die an der Schnittstelle befindlichen Verbindungen eine alternative oder parallele Beziehung aufweisen. Sollte der Fall auftreten, dass beispielsweise in einen Prozess drei Produkte eingehen, zwei davon sind alternativ, das dritte Produkt parallel zu den beiden anderen, so müssen dafür pro Prozessschritt zwei separate Schnittstellen angelegt werden. Eine Schnittstelle bildet die alternative Verzweigung ab, die zweite Schnittstelle dann die parallele Verbindung. Sollte dieser Prozessschritt dekomponiert werden, so verdoppelt sich die Anzahl der Schnittstellen, da für die zweite Detailebene die gleiche Anordnung der Schnittstellen gewählt werden muss. Um für die Attribute der Schnittstellen konkrete Ausprägungen vorzugeben, können in der Schnittstellenklasse Einschränkungen, sogenannte Constraints, definiert werden, die eine @ Auswahl von Ausprägungen der Werte (wie eine Werteliste) vorgeben, vgl. [AUT14 ].

@ In Abbildung 6-7 ist dies sowohl im AutomationML-Editor [AUT17C ] als auch in der XML- Darstellung abgebildet. 6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion 102

Abbildung 6-7: Darstellung von Einschränkungen im AutomationML-Editor und in XML-Darstellung Als Beispiel kann bei dem Attribut Verzweigungstyp nur einer der folgenden Werte gewählt werden: • none (keine Verzweigung), • parallel (parallele Verzweigung), • alternative (alternative Verzweigung), wie in Abbildung 6-7 zu erkennen ist.

6.3.2 Abbildung des Strukturmodells Das in Abschnitt 5.1.2 eingeführte und in Abschnitt 5.2.3 detailliert beschriebene Strukturmodell wird als eigene Hierarchie in der INSTANCEHIERARCHY angelegt. Dazu wird ein INTERNALELEMENT mit der Rolle StructuralHierachy als oberstes Element in die INSTANCEHIERARCHY des Projektes integriert. Unter diesem Element wird die Struktur des Systems angelegt, siehe Abbildung 6-8.

Abbildung 6-8: Darstellung des Strukturmodells in AutomationML Die Detaillierung der Struktur ist sowohl von der Domäne als auch vom Einsatzzweck des Modells abhängig. Einen Überblick über mögliche Gliederungsebenen eines Systems wird in [ZHR+16] vorgestellt. Das in der vorliegenden Arbeit vorgestellte Strukturmodell unterstützt diese Strukturierung vollständig. Die Komponenten als elementare Bestandteile des Systems werden über Schnittstellen miteinander verbunden. Diese Schnittstellen können konstruktive Verbindungen beschreiben oder auch Verbindungen von Energie-, Informations- oder Produktflüssen, wie sie in Abbildung 6-8 unterhalb des Objektes „TestElement 1“ als INTERFACES zu sehen sind.

6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion 103

6.3.3 Abbildung des Verhaltensmodells Die Abbildung des Verhaltensmodells in AutomationML erfolgt ebenso wie beim Strukturmodell und dem Funktionsmodell in einer eigenen Hierarchie. Diese enthält die Objekte, die durch das Metamodell des Verhaltensmodells beschrieben werden. In Abbildung 6-9 ist beispielhaft das Objekt eines „TestProgramm1“ und einer „TestVariable1“ zu sehen.

Abbildung 6-9: Darstellung des Verhaltensmodells in AutomationML

Diese Objekte verfügen jeweils über ein INTERFACE. Über dieses können externe PLCopen XML-Dateien verlinkt werden, in denen sich das Steuerungsprogramm oder auch die Variablenliste befindet. Eine Liste an Variablen kann gemäß dem Metamodell auch als Liste von INTERNALELEMENTS direkt in der Verhaltenshierarchie abgebildet werden.

6.3.4 Abbildung der Verbindungen zwischen den Teilmodellen Wie in Abschnitt 5.3 beschrieben lassen sich die drei vorgestellten Teilmodelle untereinander verbinden. Die Verbindungen werden in AutomationML als INTERNALLINKS realisiert, welche die Schnittstellen der betroffenen Elemente miteinander verbinden. Die Schnittstellen der Elemente werden als INTERFACES ausgeführt. Folgende Abbildung 6-10 gibt einen Überblick über die verwendeten INTERFACE-Typen. 6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion 104

Abbildung 6-10: INTERFACECLASSLIBRARY für das Systemmodell

Die zur Realisierung der angesprochenen INTERFACES benötigten INTERFACE-Typen sind in einer eigenen Bibliothek, der INTERFACECLASSLIBRARY, gespeichert. Diese Bibliothek stellt somit alle Verbindungstypen aus Tabelle 5-2 bereit. Damit sind alle notwendigen Elemente in AutomationML beschrieben und an einem Beispiel erklärt, die zur Abbildung des vorliegenden Systemmodells mit seinen drei Teilmodellen und den darin enthaltenen Verbindungen in AutomationML benötigt werden.

6.4 Zusammenfassung Forschungsfrage 5 ist an dieser Stelle beantwortet:

5. Wie lassen sich die Informationen/Beschreibungen aus dem Systemmodell zum Gewerke-übergreifenden Austausch in einem Datenformat abbilden?

In den beiden vorliegenden Kapiteln 5 und 6 wird gezeigt, wie ein Systemmodell aus drei Teilmodellen aufgestellt wird, um eine Gewerke-übergreifende Kommunikations- und Planungsgrundlage über die Engineering-Phasen hinweg sicherzustellen. Dazu ist detailliert beschrieben, wie sich das erstellte Systemmodell rechnerinterpretierbar austauschen lässt, indem es im Datenformat AutomationML abgebildet wird. Der Ansatz der vorliegenden Arbeit wird hier von zwei ausgewählten Ansätzen abgegrenzt. Die Ansätze, beschrieben in [SBV17] und [HAD15] befinden sich thematisch am nächsten am vorliegenden Ansatz und werden herangezogen, um die Neuheit des vorliegenden Ansatzes hervorzuheben. In [SBV17] wird die FPB zur Anforderungsmodellierung für technische Systeme genutzt. Dabei dient das darin entwickelte Vorgehen der Definition von Anforderungen für die Lieferanten, deren Produkte die Anforderungen der Technischen Ressourcen erfüllen sollen. Gemeinsam mit dem Vorgehen der vorliegenden Arbeit ist, dass das Funktionsmodell des Systems zur Formalisierung der Anforderungen genutzt wird, die in späteren Phasen des Engineerings durch Komponenten erfüllt werden sollen. 6 Rechnerinterpretierbare Abbildung und Übertragung der Maschinenfunktion 105

Im Unterschied zum vorliegenden Ansatz wird dabei kaum auf die Prozesse und deren Beschreibung eingegangen. Diese Prozesse repräsentieren die Funktionen, die das System ausführen kann. Diese funktionsorientierte Beschreibung kann im vorliegenden Ansatz für eine Fähigkeitsbeschreibung genutzt werden und ist daher auch in den Betriebsphasen des Systems verwendbar. Weiterhin wird in [SBV17] erklärt, dass AutomationML nicht direkt zum Transport des Funktionsmodells genutzt wird, sondern in erster Linie für die kontinuierliche Anreicherung der Planungsdaten des Produktionssystems. Aus Sicht der Autoren von [SBV17] ist das Datenaustauschformat somit nur bedingt geeignet für die direkte Speicherung von Anforderungen, die sich ab der Übergabe an den Lieferanten möglichst nicht mehr ändern sollten und stetig gegengeprüft werden müssen. Beim vorliegenden Ansatz wird dies durch die Nutzung von getrennten Teilmodellen verhindert. Dabei kann das funktionsorientierte Teilmodell mit den Technischen Ressourcen die Anforderungen zu jeder Phase des Engineerings repräsentieren, da es vom Strukturmodell getrennt ist.

[HAD15] beschreibt die Nutzung von Funktions- und Strukturmodell zur Beschreibung von Systemen. Dabei geht Hadlich intensiv auf die Verwendung von Merkmalen zur Beschreibung der Elemente der beiden Modelle ein. Er nutzt das Funktionsmodell ähnlich wie im vorliegenden Ansatz: „In frühen Phasen des Lebenszyklus (Basic und Detail Engineering) dienen Funktionsbeschreibungen zur Darstellung des Entwurfsziels. In der Betriebsphase eines Systems werden Funktionsbeschreibungen zur Darstellung der Fähigkeiten eines Systems genutzt.“ [HAD15, S. 95] Im Unterschied zum vorliegenden Ansatz werden die unterschiedlichen Modellaspekte Funktion und Struktur gemäß [HAD15] in einem Systemmodell abgelegt. Dies wird unter anderem dadurch begründet, dass die Verwendung von INTERNALLINKS INSTANCEHIERARCHY-übergreifend in AutomationML nicht möglich ist. Im vorliegenden Ansatz werden die Teilmodelle daher in einer INSTANCEHIERARCHY abgelegt. Weiterhin werden die Elemente des Funktionsmodells bei [HAD15] nicht in Produkte, Prozesse und Ressourcen unterteilt und getrennt voneinander abgelegt. Im vorliegenden Ansatz dient diese Trennung der hierarchischen Gliederung von Produkten, Funktionen und Technischen Ressourcen. Eine weitere Differenz zum vorliegenden Ansatz besteht darin, dass bei [HAD15] die Technische Ressource und das Strukturelement gleich gesetzt werden. Dies erschwert es, die Anforderungen der Technischen Ressource und die Zusicherungen des Strukturelements getrennt voneinander und dauerhaft in einem Modell abzulegen. Im vorliegenden Ansatz ist das durch die Trennung der Teilmodelle ohne weiteres möglich. Zudem können die Teilmodelle auch einzeln verwendet werden, beispielsweise nur das Funktionsmodell zur Fähigkeitsbeschreibung des Systems. Zudem bestehen diverse Unterschiede in der Modellierung mit AutomationML. Während der vorliegende Ansatz darauf fokussiert, vorhandene Elemente in AutomationML zweckmäßig einzusetzen, werden bei [HAD15] diverse Anpassungen von AutomationML gefordert. Beispielsweise wird ein Verbindungselement (ähnlich einem INTERNALLINK) gefordert, das auch durch ein INTERNALELEMENT mit den entsprechenden INTERFACES realisiert werden könnte.

7 Verwendung der Maschinenfunktion in der Praxis 106

7 Verwendung der Maschinenfunktion in der Praxis Das vorliegende Kapitel beschreibt die Nutzung des aufgestellten Systemmodells in der Praxis. Dafür wird das Systemmodell auf bestehende Produktionssysteme angewendet. Das dadurch entstehende Systemmodell wird für die umfassende Analyse der Produktionssysteme genutzt. Zudem dient das Systemmodell als Ablage für die unterschiedlichen Daten, die im Laufe des Engineerings erstellt wurden und während des Betriebes erstellt werden.

7.1 Beispielprojekt 1: Analyse einer Bestandsanlage Der vorliegende Abschnitt beschreibt die Analyse einer Bestandsanlage eines Sensorherstellers. Die dabei aufgenommenen Daten wurden dabei in das vorgestellte Systemmodell überführt, um dieses detailliert auszuwerten zu können. Ein Ziel der Auswertung war es, Potential für eine mögliche Automatisierung bisher händisch ausgeführter Tätigkeiten an dem betrachteten Produktionssystem aufzudecken [SHW+17*; % WEN17 ].

7.1.1 Beschreibung des Produktionssystems und des Produktes Das betrachtete Produktionssystem fertigt optische Sensoren einer Baureihe mit unterschiedlichen Varianten. Der Aufbau des Produktionssystems ist modular mit 12 unterschiedlichen Modulen. Einige dieser Module sind reine Handarbeitsplätze, andere Module beinhalten Maschinen, in denen Fügevorgänge unterschiedlicher Art durchgeführt werden. Ebenso sind Module für Parametrierung, Test, Beschriftung und Verpackung in dem Produktionssystem aufgebaut. Der Aufbau der Module ist dabei firmenintern standardisiert. Es gibt definierte Übergabepunkte zwischen den einzelnen Modulen, die mit Sensorik ausgestattet sind. Die Fertigungsschritte auf den Modulen sind ebenfalls streng vorgegeben. Die einzelnen Bauteile werden für jeden Fertigungsschritt in gesonderte Vorrichtungen eingelegt, um fest definierte Positionen für die Bauteile für jede Wiederholung des Fertigungsschrittes einzuhalten. Beispielhaft sei hier der erste Fügevorgang aufgeführt, bei dem zwei Platinen im rechten Winkel an drei definierten Stellen miteinander verlötet werden. Dazu werden beide Bauteile in eine eigens dafür konstruierte Halterung eingelegt und fixiert. Das kleinere Bauteil wird auf einer definierten Bahn auf das größere Bauteil zubewegt, bis die durch die Vorrichtung definierte Endposition erreicht ist. Diese Position wird ebenfalls fixiert. Danach lötet der Montagemitarbeiter die beiden Bauteile an den Lötpunkten zusammen.

7.1.2 Vorgehen bei der Datenaufnahme In einem ersten Schritt wurde das Produkt detailliert betrachtet, das in unterschiedlichen Varianten in dem Produktionssystem gefertigt wird. Hierbei waren insbesondere die Einzelteile des Endproduktes von Interesse sowie die Fügefolge dieser Komponenten. Die Komponenten sowie das zusammengesetzte Produkt definieren die Eingangs- sowie Ausgangszustände für das Produktionssystem. Die Fügefolge spiegelt sich direkt im Aufbau der Module wieder. Jedes Modul realisiert mindestens einen Prozessschritt in der Fügefolge. Daher bilden diese Daten die ersten Anforderungen an das Produktionssystem. Die restliche Datenaufnahme orientierte sich an dem Engineering-Workflow für Neuanlagen, wie er in Abschnitt 5.2 dargestellt ist. Auch hier wurde zuerst das Funktionsmodell des Produktionssystems erstellt. Dies geschah durch die Beobachtung des Produktionssystems und der durchgeführten Prozessschritte. Bei der Analyse der Prozessschritte wurde 7 Verwendung der Maschinenfunktion in der Praxis 107 aufgenommen, welche Änderungen an dem Produkt durch das Produktionssystem und den Montagemitarbeiter vorgenommen werden. Nach der funktionsorientierten Betrachtung wurden die Baustruktur des Produktionssystems untersucht und alle notwendigen Informationen über mechanische, mechatronische und elektrische Geräte aufgenommen. Daran angeschlossen hat sich die Analyse des Verhaltens des Produktionssystems, in der Verhaltensrestriktionen und Reihenfolgen unterstützt durch Zeitmessungen aufgenommen wurden. Abschließend konnten die aufgenommenen Daten entsprechend dem Systemmodel abgebildet und miteinander in Beziehung gesetzt werden. Auch hier waren die Schnittstellendaten zwischen den unterschiedlichen Gewerken des Engineerings von besonderer Bedeutung. Signallisten und Ablaufbeschreibungen sowie Stücklisten vervollständigten die Abbildung des Produktionssystems im Systemmodell und stellten die notwendigen Schnittpunkte zwischen den Teilmodellen her. Im Folgenden wird dies an dem Beispiel eines Moduls des beschriebenen Produktionssystems exemplarisch dargestellt.

7.1.3 Systemmodell des Produktionssystems Das erstellte Systemmodell des Produktionssystems gliedert sich in die drei Teilmodelle, die in der vorliegenden Arbeit definiert wurden, um ein Produktionssystem vollständig zu beschreiben. Auf diese Teilmodelle wird im Folgenden eingegangen. Im Fokus steht hierbei insbesondere die detaillierte Betrachtung des Funktionsmodells.

7.1.3.1 Funktionsmodell Die Komponenten des zu fertigenden Produkts bilden die Eingangsprodukte des gesamten Produktionsprozesses des Produktionssystems, also hier die Komponenten des zu fertigenden Sensors. Dieser Fertigungsprozess kann auf unterschiedlichen Abstraktionsebenen dargestellt werden. Für das vorliegende Produktionssystem wurde eine vierstufige Detaillierung vorgenommen, siehe Tabelle 7-1. Für jede Detaillierungsstufe (Level) im Funktionsmodell unterhalb des Levels 0 wurde eine andere standardisierte Funktionsbeschreibung zu Grunde gelegt, entsprechend passend zum Abstraktionsgrad der jeweiligen Detailstufe.

Tabelle 7-1:Übersicht über die Detaillierungsstufen des Funktionsmodells

Detaillierungs- Inhalt grad Gesamtprozess des Produktionssystems, mit Komponenten des Produktes als Input und Level 0 Endprodukt als Output Prozesse auf Modulebene nach [DIN 8580], mit Zwischenprodukten, die zwischen den Level 1 Modulen übergeben werden Detaillierung der Prozesse der Module auf Basis der MTM-Handhabungsklassen, vgl. Level 2 [BOLA12] Detaillierung der Prozessschritte von Level 2 auf Basis der Handhabungsfunktionen der Level 3 [VDI 2860]

Wird das gesamte Produktionssystem zu Herstellung der Sensoren als ein Gesamtsystem (Level 0) betrachtet, lässt sich der im Produktionssystem durchgeführte Fertigungsprozess als ein Gesamtprozess mit den Komponenten des Produktes als Eingang des Materialflusses und dem Sensor als Ausgang dieses Flusses darstellen, siehe Abbildung 7-1. 7 Verwendung der Maschinenfunktion in der Praxis 108

Abbildung 7-1: Produktionsprozess der Sensorfertigung, Level 0 In einem weiteren Analyseschritt wurden die einzelnen Module des Produktionssystems näher untersucht und ihre Prozessschritte sowie die darin ablaufenden Funktionen detailliert betrachtet. Dazu wurden Fertigungsanweisungen und Stücklisten mit Fügefolge als Planungsdokumente analysiert. Daraus wurde die funktionale Abfolge innerhalb des Produktionssystems dargestellt. Diese Abfolge wurde im Funktionsmodell weiter detailliert. Es beschreibt die Funktionen der 12 Module (Level 1) mit Hilfe der Funktionseinteilung nach [DIN 8580]. Abbildung 7-2 enthält den entsprechenden Ausschnitt für das Modul 1. Hier werden zwei Komponenten durch den Prozessschritt „Fügen M1 11“ (Fügen in Modul 1, Level 1, Schritt Nummer 1) miteinander verbunden.

Abbildung 7-2: Detaillierung der Fertigungsschritte, Ausschnitt Modul 1, Level 1 Diese Prozessschritte, welche die einzelnen Fertigungsmodule darstellen, sind dabei noch weiter zu dekomponieren. Dazu werden die Handhabungsschritte der Mitarbeiter und die genutzten Vorrichtungen detailliert betrachtet (Level 2) und mit Hilfe der Funktionseinteilung der MTM-Handhabungsklassen nach [BOLA12] beschrieben. Abbildung 7-3 zeigt einen Auszug aus dem ersten Modul mit den Funktionen als Prozessschritte abgebildet. Diese Abbildung stellt den Prozessschritt „Fügen M1 11“ der Abbildung 7-2 auf der nächsten Detaillierungsebene (Level 2) dar. Dabei handelt es sich um einen Auszug, die vollständige Darstellung des Prozessschrittes „Fügen M1 11“ ist im Anhang A in Abbildung A-1 zu finden. 7 Verwendung der Maschinenfunktion in der Praxis 109

Abbildung 7-3: Detaillierung der Prozessschritte des Modul 1, Level 2 Die in Abbildung 7-3 beschriebenen Prozessschritte sind in Level 2 nach den MTM- Handhabungsfunktionen klassifiziert. Diese lassen sich noch weiter detaillieren, siehe dazu Abbildung 7-4. Die gesamte Darstellung des Prozesses in Level 3 ist im Anhang A der Abbildung A-2 zu entnehmen.

Abbildung 7-4: weitere Detaillierung der Prozessschritte, Modul 1, Level 3 Die beschriebenen Prozessschritte sind in der Detaillierungsebene 3 gemäß [VDI 2860] klassifiziert. Dabei ist erkennbar, dass sich die MTM-Handhabungsfunktion „Aufnehmen und Platzieren M1 24“ aus Abbildung 7-3 in die Montage- und Handhabungsfunktionen der 7 Verwendung der Maschinenfunktion in der Praxis 110

[VDI 2860] dekomponieren lässt. „Aufnehmen und Platzieren M1 24“ lässt sich dementsprechend in die Prozessschritte „Halten M1 38“, „Positionieren M1 39“ und „Lösen M1 310“ zerlegen. Dies ist an den gleichen Ein- und Ausgangsprodukten der Prozessschritte zu erkennen. Eine tiefergehende Modellierung der Funktionen würde an dieser Stelle den Informationsgehalt nicht mehr steigern. Eine weitere Dekomposition der Prozessschritte ist hier nur noch an wenigen Stellen sinnvoll möglich. Daher ist Level 3 hier die am feinsten granulierte Funktionsbeschreibung des Produktionssystems.

7.1.3.2 Strukturmodell Das Strukturmodell beinhaltet die einzelnen Module des Produktionssystems und die darin verwendete technische Ausrüstung, wie Lötkolben oder speziell konstruierte Halterungen für die Produkte, dargestellt als hierarchische Anordnung dieser Objekte. Als Beispiel ist in Abbildung 7-5 ein Teil des Modul 1 des Produktionssystems dargestellt.

Abbildung 7-5: Ausschnitt aus der Struktur des Modul 1 Abbildung 7-6: Darstellung der Verbindung des Produktionssystems zwischen zwei Elementen der Struktur In der Strukturdarstellung des Modul 1 ist die Unterteilung in die Bauteile „Tisch“ und „Pick- by-light Regal“ zu erkennen. Das Bauteil „Tisch“ enthält ein weiteres Bauteil „Vorrichtung Löten“, das aus den Komponenten „Niederhalter 1“, „Niederhalter 2“ und „Schieber 1“ besteht. In der Abbildung 7-6 ist die Verbindung zwischen den beiden Komponenten „Niederhalter 2“ und „Schieber 1“ zu entnehmen. Diese Verbindung ist verschiebbar ausgeführt. Dies bedeutet, dass der „Niederhalter 2“ gegenüber dem „Schieber 1“ verschiebbar ist.

7 Verwendung der Maschinenfunktion in der Praxis 111

7.1.3.3 Verhaltensmodell Im Verhaltensmodell wurden einige Abläufe hinterlegt, die in dieser detaillierten Form nicht im Funktionsmodell abgebildet werden konnten. Die Vorgänge aus diesem Verhaltensmodell können zur Erstellung von Handlungsanweisungen der Mitarbeiter an der Fertigungslinie dienen. Zudem kann ein Bezug zu den Technischen Ressourcen aus dem Funktionsmodell und auch den entsprechenden Geräten aus dem Strukturmodell hergestellt werden, indem die genutzten Ressourcen (im Sinne von Sensoren und Aktoren) im Verhaltensmodell und die Technischen Ressourcen aus dem Funktionsmodell verbunden werden. Ebenso ist ein Verweis auf die Elemente im Strukturmodell möglich. Abbildung 7-7 zeigt einen Ausschnitt aus dem Verhaltensmodell für das Modul 1.

Abbildung 7-7: Ausschnitt aus dem Verhaltensmodell des Modul 1 Darin werden einige Vorgänge dargestellt, ebenso eine zugeordnete Ressource. Im vierten Vorgang wird beispielhaft die Ressource „Printaufnahme Grundprint“ verwendet. Das dargestellte Gantt-Diagramm kann in einer PLCopen XML-Datei gespeichert werden.

7.1.4 Abbildung des Systemmodells in AutomationML Um das Systemmodell des Produktionssystems automatisiert auszuwerten und es rechnerinterpretierbar zwischen den unterschiedlichen Planern auszutauschen, wurde es im Datenaustauschformat AutomationML abgebildet. Im Folgenden wird dies am Beispiel des Funktionsmodells detailliert dargestellt. Zudem wird auf einige Verbindungen zwischen den Teilmodellen und den verwendeten Bibliotheken für die Prozessschritte eingegangen.

7.1.4.1 Abbildung des Funktionsmodells Wie in Abschnitt 5.1 beschrieben, wird das Systemmodell des Produktionssystems in drei unterschiedliche Teilmodelle unterteilt. Im Fokus steht hier das Funktionsmodell, das sich in die drei verschiedenen Strukturen der Produkt-, Prozess- und Ressourcenstruktur unterteilt, siehe Abbildung 7-8.

Abbildung 7-8: Aufbau des Funktionsmodells der Beispielanlage Die Produktstruktur enthält die Flüsse der Produkte und deren Zwischenprodukte, sowie weiterhin die Flüsse der Informationen und der Energien. In der Prozessstruktur werden die Prozesse und ihre untergeordneten Prozessschritte abgelegt. Die Ressourcenstruktur enthält die Technischen Ressourcen und ihre Unterelemente. Das erste Modul des Produktionssystems wird im Folgenden im Detail betrachtet. Das Modul 1 stellt eine Funktion bereit, durch dessen Ausführung zwei Platinen miteinander verlötet werden. Im Funktionsmodell stellen diese beiden Platinen als Produkte die Eingänge für den Prozess „Fügen M1 11“ (Fügen in Modul 1, Level 1, Schritt Nummer 1) dar. Als Ausgangsprodukt des Prozesses entsteht die „Print-Baugruppe“, zusammengesetzt aus den 7 Verwendung der Maschinenfunktion in der Praxis 112 beiden Komponenten „Grundprint“ und „HMI-Print“. Abbildung 7-9 zeigt den beschriebenen Prozess und die entsprechende Abbildung des Funktionsmodells in AutomationML.

Abbildung 7-9: Fügeprozess mit Entsprechung in AutomationML, Level 1 Die drei Produkte sind in der Produktstruktur eingeordnet. Sie verfügen jeweils über drei unterschiedliche INTERFACES. Jedes davon stellt eine Verbindung in einen anderen Level dar, wie in Abschnitt 5.3 beschrieben. Hierzu wurde den INTERFACES ein Attribut Level zugeordnet, siehe Abbildung 7-10.

Abbildung 7-10: Attribute des INTERFACES „out_1“ des INTERNALELEMENTS „Grundprint“ Dieses Attribut gibt an, in welche Detaillierungsebene (Level) die angehängte Verbindung über den INTERNALLINK führt, wenn der Prozess dekomponiert wird. Im gezeigten Beispiel hat jedes Produkt drei INTERFACES, die Verbindungen in drei unterschiedliche Detaillierungsebenen realisieren. In Abbildung 7-9 sind die Verbindungen auf Level 1 abgebildet. Die Verbindungen der INTERNALLINKS zu dem Prozess „Fügen M1 11“ sind zu erkennen, ebenso die Verbindung des Prozesses mit der ihm zugeordneten Technischen Ressource „Modul 1“. Ein weiteres Beispiel zeigt einen Ausschnitt aus der Dekomposition des Prozesses „Fügen M1 11“. Die gesamte Dekomposition ist Abbildung 7-3 zu entnehmen. In Abbildung 7 Verwendung der Maschinenfunktion in der Praxis 113

7-11 ist ein Ausschnitt aus dem oberen Teil von Abbildung 7-3 abgebildet, mit der entsprechenden Darstellung in AutomationML.

Abbildung 7-11: Handhabungsprozess mit Entsprechung in AutomationML, Level 2 Auf dieser Detaillierungsebene ist der Prozessschritt „Hilfsmittel Handhaben M1 21“ dem Prozess „Fügen M1 11“ untergeordnet, was die Kompositionsbeziehung dieser zwei Objekte darstellt. Auch bei den Technischen Ressourcen ist der „Montagemitarbeiter“ dem „Modul 1“ untergeordnet.

7.1.4.2 Abbildung der Verbindungen zwischen den Teilmodellen Nachfolgend wird die Ausführung der unterschiedlichen Verbindungen in und zwischen den Teilmodellen in AutomationML erklärt. Dabei wird zudem auf einige Details der Umsetzung des Struktur- und des Verhaltensmodells des Produktionssystems eingegangen. Funktion – Struktur Ein möglicher Verbindungstyp, der hier näher erklärt wird, ist zwischen dem Funktions- und dem Strukturmodell zu finden. Dabei wird einer Technischen Ressource aus dem Funktionsmodell eine Komponente oder eine Funktionseinheit aus dem Strukturmodell über eine Verbindung zugeordnet. Die Technische Ressource ist ein abstraktes Objekt, das Anforderungen an Komponenten definiert. Hingegen ist die Komponente eine Abbildung eines physischen Objektes. Dieses Objekt kann eine Komponente oder eine Kombination mehrerer Komponenten sein, das die Anforderungen der Technischen Ressource erfüllt. Die Trennung zwischen Technischer Ressource und Komponente ist hierbei wichtig, da damit beide Teilmodelle auch unabhängig voneinander austauschbar bleiben und die Anforderungen für spätere Analysen weiterhin vorhanden sind und nicht durch die realen Werte der ausgewählten Komponente ersetzt werden, wie es bei den integrativen Ansätzen [HAD15] der Fall ist, in denen die Technische Ressource gleichgesetzt wird mit einer Komponente aus dem Strukturmodell. 7 Verwendung der Maschinenfunktion in der Praxis 114

Abbildung 7-12 zeigt die Technische Ressource „Modul 1“, welche die Funktion des Fügens zweier Platinen durch Löten realisiert. Diese Technische Ressource ist der Funktionseinheit „Modul 1“ aus dem Strukturmodell über ein INTERFACE (vom Typ „Represents_HW“) zugeordnet. Damit erfüllt dieses Element mit der Rolle „ProductionUnit“ die Anforderungen der Technischen Ressource „Modul 1“ aus dem Funktionsmodel. Ebenso ist aus Sicht der Funktion erkennbar, wie diese ausgeführt werden soll, da eine Verbindung zu den Geräten und deren technischer Realisierung vorhanden ist.

Abbildung 7-12: Verbindung von Funktions- und Strukturmodell

Weiterhin ist der Abbildung zu entnehmen, dass diesem Strukturobjekt über ein INTERFACE (vom Typ „COLLADAInterface“) eine externe Referenz zugeordnet ist, die auf ein 3D-CAD- Modell im COLLADA-Format verweist. Somit besteht über die Verbindung der beiden Teilmodelle eine semantische Verbindung zwischen dem CAD-Modell des Moduls und seiner Funktion. Funktion – Verhalten Ein weiterer Verbindungstyp kann zwischen dem Funktions- und dem Verhaltensmodell angelegt werden. Dies ist an zwei Stellen innerhalb des Funktionsmodells möglich. Zum einen kann ein Informationszustand (in der FPB als blaues Sechseck repräsentiert) mit einer Variable aus dem Verhaltensmodell verbunden werden. Dies ist vor allem bei Statusinformationen sinnvoll, die im Funktionsmodell schon vorgedacht werden. Diese bekommen mit der Verbindung eine Entsprechung im Verhaltensmodell, wo sie durch eine Variable näher definiert werden können. Dies ist in Abbildung 7-13 beispielhaft abgebildet. Hier ist dem Informationsobjekt „Baugruppe korrekt übergeben“ aus dem Funktionsmodell über ein INTERFACE vom Typ „Represents_SW“ einer Variable „Übergabe_1_to_2ok“ im Verhaltensmodell zugeordnet. Weiterhin ist zu erkennen, dass im Verhaltensmodell dem Modul 1 ein SPS-Programm in Form einer PLCopen XML-Datei zugeordnet ist. Die Variable „Übergabe_1_to_2ok“ ist auch in diesem Programmcode vorhanden und mit einer externen Referenz mit diesem Programm verbunden. Somit ist aus Sicht der Funktion eine Verbindung zum SPS-Code der Technischen Ressource realisiert. 7 Verwendung der Maschinenfunktion in der Praxis 115

Abbildung 7-13: Verbindung von Funktions- und Verhaltensmodell Zum anderen kann einer Technischen Ressource aus dem Funktionsmodell eine Variable oder eine Programmorganisationseinheit (POE) über eine Verbindung zugewiesen werden. Handelt es sich beispielweise bei der Technischen Ressource um einen Sensor, dann kann diese Technischen Ressource mit dem entsprechenden Sensorsignal im Verhaltensmodell verbunden werden, das dort durch eine Variable repräsentiert wird. Somit ist aus Sicht des Verhaltensmodells erkennbar, an welcher Funktion dieses Signal beteiligt ist. Es ist somit semantisch interpretierbar. Einer komplexeren Technischen Ressource, wie einem Modul, kann eine POE zugewiesen werden, die neben Variablen auch Programmcode enthält. Damit sind detaillierte Abläufe beschreibbar, feingranularer als es mit der FPB möglich ist. Zudem werden einem Programm damit eine bestimmte Funktion und auch deren Auswirkung auf die Produkte zugeordnet. Struktur – Verhalten Zwischen dem Struktur- und dem Verhaltensmodell können Verbindungen realisiert werden. Ein Beispiel dafür ist in Abbildung 7-14 dargestellt. Darin wird das Gerät „Sensor 1“ aus dem Strukturmodell des Modul 1 über eine Verbindung in Form eines INTERNALLINK mit einer Variable aus dem Verhaltensmodell des Modul 1 verbunden. Diese Verbindung stellt dar, durch welches physische Gerät die jeweilige Variable genutzt wird. 7 Verwendung der Maschinenfunktion in der Praxis 116

Abbildung 7-14: Verbindung von Struktur- und Verhaltensmodell In dem vorliegenden Beispiel ist es der Sensor 1, der in der Übergabeeinheit verbaut ist. Dieser registriert, ob sich ein Produkt in der Übergabeeinheit befindet. Ist dies der Fall, so wird die Variable „Übergabe_1_to_2_ok“ auf eins gesetzt. Dies kann über die gezeigte Verbindung abgebildet werden. Die binäre Logik liegt dabei im Verhaltensmodell. Die beschriebenen Verbindungen zwischen den Elementen der unterschiedlichen Teilmodelle sind in AutomationML als INTERFACES, verbunden durch INTERNALLINKS ausgeführt und können an den jeweiligen Elementen auch mehrfach vorhanden sein, um unterschiedliche Verbindungen eines Typs zu beschreiben.

7.1.4.3 Verwendete Bibliotheken in AutomationML Zur Erstellung des Funktionsmodells sind in AutomationML unterschiedliche Bibliotheken angelegt wurden, die im Folgenden kurz erklärt werden. Zur Abbildung der unterschiedlichen Detaillierungsebenen im Funktionsmodell wurden die Funktionen entsprechend der unterschiedlichen Normen und Standards erstellt. Wie in Abschnitt 7.1.3 detailliert beschrieben, wurden die Fertigungsverfahren nach DIN 8580, die MTM-Handhabungsfunktionen und die Montage- und Handhabungsfunktionen der VDI 2860 für die jeweiligen Detaillierungsebene verwendet. Abbildung 7-15 stellt einen Auszug aus den erstellten SYSTEMUNITCLASSES dar, die zur Instanziierung der jeweiligen INTERNALELEMENTS der Funktion verwendet werden. 7 Verwendung der Maschinenfunktion in der Praxis 117

Abbildung 7-15: Verwendete SYSTEMUNITCLASSLIBRARY für das Beispielprojekt

Diese SYSTEMUNITCLASSES werden durch verschiedene Attribute näher beschrieben. Beispielhaft sei hier die Zeitdauer der MTM-Funktionen genannt.

Weiterhin wurde eine Rollenbibliothek erstellt, die dazu dient, die INTERNALELEMENTS der INSTANCEHIERARCHY zu strukturieren und diese über Vererbung mit den unterschiedlichen Schnittstellen auszustatten. Abbildung 7-16 stellt die ROLECLASSES dar, unterteilt in Rollen für das Funktions-, das Struktur- und das Verhaltensmodell. Zudem sind die unterschiedlichen INTERFACES zu erkennen, die den Rollen zugeordnet sind. Diese werden durch Vererbung an die erzeugten Instanzen, die INTERNALELEMENTS, vererbt. 7 Verwendung der Maschinenfunktion in der Praxis 118

Abbildung 7-16: Verwendete ROLECLASSLIBRARY

Die genutzten INTERFACES werden einer separaten Bibliothek entnommen, der INTERFACECLASSLIBRARY, die für die Modellierung des Beispiels erstellt wurde. Sie enthält die unterschiedlichen Schnittstellen, um die Elemente innerhalb der Modelle und auch Modell-übergreifend zu verbinden. Auch diese Schnittstellen werden durch Attribute näher beschrieben, wie etwa die Richtung des Flusses (von Produkten, Energien oder Informationen) oder der Art der Verzweigung eines Flusses (alternativ oder parallel). Abbildung 7-17 stellt die verwendete INTERFACECLASSLIBRARY dar.

Abbildung 7-17: Verwendete INTERFACECLASSLIBRARY für das Beispielprojekt

7 Verwendung der Maschinenfunktion in der Praxis 119

7.1.5 Auswertung des Systemmodells Die durch die Abbildung in AutomationML digital vorliegenden und somit auch automatisiert auswertbaren Informationen der Prozessschritte des betrachteten Produktionssystems wurden genutzt, um eine Analyse der einzelnen Module durchzuführen. Ein Ziel der Analyse war es, herauszufinden, welche Prozessschritte innerhalb des Produktionssystems automatisiert werden können, um einerseits die Qualität in der Produktion zu erhöhen und andererseits die Taktzeit der einzelnen Prozessschritte zu optimieren. Auf den unterschiedlichen Detailstufen des Funktionsmodells wurden die Prozessschritte sowohl in die Klassen der Handhabungsfunktionen der [VDI 2860] eingeteilt, als auch in die Klassen der Bewegungen der MTM-Analyse. Mit Hilfe der MTM-Handhabungsklassen und den dahinterliegenden Zeit-Werten (TMU = Time Measurement Unit, 1 TMU = 0,0006 Minuten) für die Bewegungsausführung kann eine automatisierte Wirkungsgradberechnung über die Primär- und Sekundär-Aufwände durchgeführt werden. Dabei bilden die Primäraufwände Tätigkeiten ab, die als wertschöpfend bezüglich des Produktes gelten. Die restlichen Tätigkeiten, durchgeführt in Prozessschritten, werden in die Sekundäraufwände eingeteilt. Beispielhaft ist dies für ein Modul des Produktionssystems in Tabelle 7-2 abgebildet. Darin werden die Prozessschritte des Moduls 1 aufgeführt, mit Zeitwerten hinterlegt und in Primär- und Sekundäraufwände eingeteilt. Anschließend kann der Wirkungsgrad des Moduls berechnet werden [SHW+17*].

Tabelle 7-2: MTM-Analyse des Modul 1

MTM & Primär-Sekundär-Analyse Modul 1 Kurzbeschreibung: zwei Platinen miteinander verlöten, die zusammen eine Baugruppe bilden rechte Hand Nr. Bezeichnung Code TMU Primär- Sekundär-Aufwände 1 Hilfsmittel handhaben HC2 70 X 2 Platzieren PC1 30 X 3 Betätigen BA1 10 X 4 Aufnehmen & Platzieren AF2 65 X 5 Betätigen BA1 10 X 6 Betätigen BA1 10 X 7 Hilfsmittel handhaben HB2 60 X 8 Bewegungszyklus: 6x Lötpads 612 X 9 Betätigen BA1 10 X 10 Aufnehmen & Platzieren AE2 55 X

Summe TMU's gesamt: 932 TMU's gesamt in s: 34 Summe Primär-Aufwände in TMU: 762 Summe Sekundär-Aufwände in TMU: 170

Wirkungsgrad: 81,76%

Prozessschritte mit einem unterdurchschnittlichen Wirkungsgrad wurden weitergehenden Betrachtungen unterzogen. Als Analyseergebnis konnten mit Hilfe der MTM-Analyse einige Prozessschritte identifiziert werden, deren Automatisierung Vorteile bezüglich Qualität und konstanter Ausführungsdauer bringen kann. Diese wurden dem Betreiber des Produktionssystems als Vorschlag vorgestellt und mit Hilfe des Systemmodells umfassend diskutiert. Während des Aufstellens des Systemmodells und der anschließenden Analyse des Produktionssystems wurden weitere Anwendungsfälle für das Systemmodell mit dem Betreiber des Produktionssystems diskutiert. Eine weitere Analyse der Prozessschritte, die 7 Verwendung der Maschinenfunktion in der Praxis 120 durch das Systemmodell in Kategorien eingeteilt vorliegen, wurde hinsichtlich der Vergleichbarkeit einzelner Prozessschritte der gleichen Handhabungs- oder Montageklasse vorgenommen. Somit könnten beispielsweise alle Füge-Vorgänge in dem gesamten Produktionssystem miteinander verglichen und besser auf die einzelnen Mitarbeiter abgestimmt werden. Dies führte durch organisatorische Umplanung zu einer Optimierung der Taktzeiten an zwei Modulen. Das vorliegende Systemmodell kann durch den Betreiber des Produktionssystems zudem dazu genutzt werden, um die Fähigkeiten des Produktionssystems zu beschreiben. Diese Fähigkeiten, repräsentiert durch die Prozessschritte im Funktionsmodell und die Eigenschaften der Komponenten im Strukturmodell, können für einen automatisierten Abgleich mit den Anforderungen eines Produktes genutzt werden, um herauszufinden, ob das beschriebene Produktionssystem das Produkt fertigen kann. Ein zusätzlicher Nutzen des gesamten Systemmodells wurde in der Realisierung einer zentralen Datensammlung für das modellierte Produktionssystem gesehen. Im Laufe des Engineerings des Produktionssystems werden alle Daten in der AutomationML-Datei gespeichert oder mit ihr verknüpft. Dies beginnt mit dem Strukturmodell des Produktes, das als CAD-Datei vorliegt. Nach der Erstellung des Funktionsmodells und der Ableitung des Strukturmodells der einzelnen Module werden auch die CAD-Dateien der Module und der konstruierten Vorrichtungen an die AutomationML-Datei gebunden. Es ergibt sich somit für jedes Projekt eine umfassende Sammlung von Informationen, die über die AutomationML- Datei mit dem Systemmodell des Produktionssystems in einen gemeinsamen Kontext gebracht werden. Im Sinn der Wiederverwendung kann aus dem Systemmodell des Produktionssystems zusätzlich eine Bibliothek für die wichtigsten Funktionen des Produktionssystems aufgebaut werden. Diese lassen sich in Untermodule einteilen und gekapselt mit ihrem Funktions-, Struktur- und Verhaltensmodell abspeichern. Diese können dann als Kopiervorlage beim Engineering eines neuen Produktionssystems dienen. Beispielsweise können so die Funktionen des Fügens abgebildet werden. Als Unterfunktionen können das Löten und das Ultraschallschweißen betrachtet werden, da diese Funktionen durch zugekaufte Maschinen durchgeführt werden und in einem Produktionssystem in mehreren Modulen eingesetzt werden. Somit sind in der Bibliothek Elemente vorhanden, die von der Anforderung über die Funktion bis zur technischen Lösung, in der explizite Geräte ausgewählt sind, einen Systemteil in den drei Facetten (Funktion, Struktur, Verhalten) und den aufgeführten Lebenszyklusphasen repräsentieren. Neben der Nutzung im Engineering kann das Systemmodell zur Dokumentation des Produktionssystems eingesetzt werden. Beispielsweise wurde durch den Betreiber des Produktionssystems angeregt, aus dem Systemmodell eines Produktionssystems (teil-) automatisiert die Montageanweisungen für die Montagemitarbeiter zu erstellen. Alle notwendigen Informationen liegen dazu in den drei Teilmodellen des Systemmodells vor.

7 Verwendung der Maschinenfunktion in der Praxis 121

7.2 Beispielprojekt 2: Funktionsanalyse komplexer Fertigungssysteme Der vorliegende Abschnitt stellt an einem weiteren Beispiel die praktische Anwendung des Systemmodells eines Produktionssystems dar. Dazu wurde im Rahmen der vorliegenden Arbeit bei einem weiteren Hersteller von Automatisierungskomponenten die Anwendbarkeit des Systemmodells überprüft. Dabei wurden zunächst die Anforderungen des Herstellers an % die Modellierung aufgenommen [HIL15 ] und diese dann mit dem, in der vorliegenden Arbeit entwickelten Ansatz umgesetzt. Im folgenden Abschnitt wird der Schwerpunkt auf die Darstellung der Funktionen des untersuchten Systems gelegt, die im Funktionsmodell % abgebildet werden, vgl. [HIL16 ; HHS+16*].

7.2.1 Beschreibung des Produktionssystems Das untersuchte vollautomatisierte Produktionssystem dient zur Herstellung von Leiterplatten-Steckern. Diese Stecker können auf dem betrachteten Produktionssystem in verschiedenen Varianten gefertigt werden. Sie unterscheiden sich dabei durch die Anzahl der Steckplätze, die sie besitzen. Je nach Anzahl der Steckplätze ist ein anderes Gehäuse notwendig, welches die entsprechende Anzahl an Stiften für die Steckplätze aufnehmen kann. Das Produkt wird aus den beiden Bestandteilen Gehäuse und Stift gefertigt. Diese beiden Ausgangsprodukte liegen als lose Schüttung in den jeweiligen Lagerbehältern des Produktionssystems vor. Im folgenden Abschnitt wird der Herstellungsprozess detailliert an Hand des erstellten Funktionsmodells erklärt.

7.2.2 Funktionsmodell des Produktionssystems Ein erster schematischer Entwurf des im Produktionssystem ablaufenden Fertigungsprozesses ist in Abbildung 7-18 zu erkennen und wird nachfolgend beschrieben. Aus Gründen der Übersichtlichkeit sind die Namen der Objekte in den jeweiligen Abbildungen stets in abgekürzter Form eingezeichnet. Die Abkürzungen werden dazu im Text erläutert. Eine größere Darstellung der Abbildung ist in Anhang B der vorliegenden Arbeit zu finden. Dem Produktionssystem (abgegrenzt durch die Bilanzgrenze „B_Gesamtsystem“) werden wie oben beschrieben zwei Produkte zugeführt: „P_St_lose“ als lose vorliegende Stifte und „P_G_lose“ als lose vorliegende Gehäuse. Da die Gehäuse als lose Schüttware vorliegen, müssen sie vor der Montage dem System zunächst ordnungsgemäß zugeführt werden. Dies beschreibt der Prozess „O_Gehaeu_zu“. Dieser Prozess nutzt die Technische Ressource „T_F&M G“, die an dieser Stelle noch sehr abstrakt und lösungsneutral die Fördertechnik (F) und Montagetechnik (M) für das Gehäuse (G) bezeichnet. An dieser Stelle ist die Technische Ressource noch sehr abstrakt gehalten, da zunächst der gesamte gewünschte Ablauf dargestellt wird und seine konkrete technische Realisierung in der Entwurfsphase nicht im Mittelpunkt der Betrachtung steht. Sofern sich im Schüttgut der Gehäuse nicht nur sortenreine Ware befindet, sind die nicht den Vorgaben entsprechenden Gehäuse in diesem Prozess auszusortieren. Fixiert wird das Gehäuse auf einem sogenannten Nest, das den Werkstückhalter während der Bearbeitung darstellt. Den Prozess verlässt nun ein fixiertes Gehäuse „P_G_fix“, das zusammen mit einer entsprechend der Variante definierten Anzahl von Stiften den Prozess „O_Stift_ein“ erreicht. Dieser Prozess realisiert das Einsetzen der Stifte in das Gehäuse. Durchgeführt wird dies mit Hilfe der Technischen Ressource „T_F&M St“, was erneut Förder- und Montagetechnik, hier jedoch für die Stifte (St), bedeutet. Den Prozess verlässt der fertig montierte Leiterplattenstecker „P_LPS“, der noch im Prozess „O_GS“ einer Qualitätskontrolle unterzogen wird, wofür mit „T_P_LPS“ diverse Technische Ressourcen zur Qualitätsprüfung (P) zur Verfügung stehen. 7 Verwendung der Maschinenfunktion in der Praxis 122

E_G_zu P_St_lose P_G_lose I_Variante B_Gesamtsystem

O_Gehaeu_zu T_F&M G

E_St_zu P_G_fix

P_Nest

O_Stift_ein T_F&M St

E_P_LPS P_LPS

O_QS T_P_LPS

P_LPS_Ausschuss P_LPS_gut P_G_fehlerhaft

Abbildung 7-18: Prozesse des Gesamtsystems zur Herstellung der Leiterplattenstecker, Level 1 Im Qualitätskontrollprozess werden Gutteile von Ausschuss getrennt, weshalb den Prozess Leiterplattenstecker entweder als Gutteile „P_LPS_gut“ oder als Ausschuss „P_LPS_Ausschuss“ verlassen. In jedem Prozess des darstellten Systems fließen Informationen über die Variante des Produktes ein, woraus sich die Anzahl der Stifte und die Form des Gehäuses ableiten lassen. Dies geschieht durch das sechseckige Informationssymbol mit der Bezeichnung „I_Variante“. Zudem sind im vorliegenden System die genutzten Energien für die einzelnen Prozesse skizziert, eine weitere Detaillierung erfolgt aus Gründen der Übersichtlichkeit der Abbildungen nicht. Nachfolgend wird der erste Teilprozess aus Abbildung 7-18 („O_Gehaeu_zu“) weiter untersucht. Innerhalb des Zuführens des Gehäuses in das automatisierte System sind einige Teilprozesse zu beobachten, wie Abbildung 7-18 darstellt. Abbildung 7-19 ist eine Dekomposition des Prozesses „O_Gehaeu_zu“, somit entspricht die Bilanzgrenze der Abbildung der Bilanzgrenze des entsprechenden Prozesses „O_Gehaeu_zu“. Der erste erkennbare Prozessschritt ist das Fördern der Gehäuse („O_G_foerdern“), wobei diese aus einem losen Zustand in einen aufgereihten, geordneten Zustand mit Hilfe der mechatronischen Komponenten (MK) eines Fördertopfes versetzt werden. Die aufgereihten Gehäuse werden anschließend mit Hilfe der mechatronischen Komponenten einer linearen Zuführung durch den Prozessschritt „O_G_zufuehren“ genau positioniert. Hierbei ist die Information, um welche Variante es sich handelt, von entscheidender Bedeutung. Auch soll während dieses Prozessschrittes die Breite des Gehäuses (beziehungsweise des Blocks) gemessen werden, um bei eventuell falschen Gehäusen im Schüttgut keine Schäden an der Maschine hervorzurufen. Sofern es sich um ein der Vorgabe entsprechendes Gehäuse handelt, kann mit Hilfe einer mechatronischen „Pick&Place“-Komponente durch den Prozessschritt „O_G_einsetzen“ das Gehäuse auf dem Nest fixiert werden. Sofern es sich 7 Verwendung der Maschinenfunktion in der Praxis 123 um ein fehlerhaftes Gehäuse handelt, soll die Maschine durch den Prozessschritt „O_Fehler_Block“ angehalten werden und das fehlerhafte Gehäuse ist manuell zu entnehmen.

Abbildung 7-19: Detaillierung des Prozessschrittes „O_Gehaeu_zu“ (Gehäuse zuführen), Level 2 Für eine detailliertere Betrachtung der Prozessschritte wird der Teilprozess „O_G_zufuehren“ aus Abbildung 7-19 dekomponiert. Die entsprechende Dekomposition ist in Abbildung 7-20 gegeben. Hier ist der Prozessschritt „O_F_R max/min“ zu erkennen, der lediglich mit Hilfe von zwei Sensoren (S) den Füllstand (F) des Linearförderers (hier Rinne (R)) bestimmt. Der Prozessschritt „O_G_foerdern“ nutzt diese Informationen, um zu entscheiden, ob die aufgereihten Gehäuse weiter gefördert werden können oder ob der genutzte Aktor (Linearförderer) ausgestellt werden muss, um Schäden an der Maschine zu verhindern. Parallel zum Prozess des Beförderns der Gehäuse wird eine Messung der Breite der aufgereihten Gehäuse durchgeführt, wobei mit Hilfe der Varianteninformation und einem Messgerät (Potentiometer) eine binäre Information erzeugt wird, ob das Gehäuse zu den eingestellten Maschinenparametern passt und verarbeitet werden kann oder nicht. Der bereits besprochene Prozessschritt des Beförderns der Gehäuse transportiert die Gehäuse dann bis zum Prozessschritt der Positionierung 7 Verwendung der Maschinenfunktion in der Praxis 124

(„O_G_position“), der auf die mechatronischen Komponenten einer Positionierungseinrichtung zurückgreift und die Gehäuse so positioniert, dass sie im nächsten Schritt fixiert werden können.

Abbildung 7-20: Detaillierung des Prozessschrittes „O_G_zufuehren“ (Gehäuse zuführen), Level 3 Wie in Abbildung 7-20 erkennbar, ist die Beschreibung bereits jetzt auf einer sehr hohen Detailebene angekommen, welche die Nutzung einzelner Sensoren und Aktoren beinhaltet. Es wird daher an dieser Stelle auf eine detailliertere Beschreibung der einzelnen Prozessschritte verzichtet.

7.2.3 Auswertung des Systemmodells Mit Hilfe des dargestellten Funktionsmodells ist es dem Maschinenbau als führendes Gewerk möglich, den Ablauf innerhalb des automatisierten Produktionssystems übersichtlich und strukturiert zu erarbeiten. Andererseits ist es auch der Elektrotechnik möglich, die erarbeiteten Informationen zu nutzen und weiter zu entwickeln, indem beispielsweise grob spezifizierte Technische Ressourcen explizit definiert werden oder weitere nötige Technische Ressourcen zu einem mechatronischen System hinzugefügt werden. Letztendlich ist es auch der Programmierung möglich, die für die Erstellung der Programme notwendigen 7 Verwendung der Maschinenfunktion in der Praxis 125

Informationen über den Ablauf aus dem Funktionsmodell zu entnehmen und bei Unstimmigkeiten im Ablauf auch die direkten Auswirkungen auf andere Prozesse zu erkennen. Das gemeinsame Arbeiten in einem gemeinsam entwickelten Funktionsmodell führt zu einem besseren Prozessverständnis bei allen Gewerken und somit zu einer besseren Zusammenarbeit der drei Gewerke. Im betrachteten Unternehmen wurden insbesondere in frühen Phasen der Entwicklung viele informelle Beschreibungsmittel wie textuelle Spezifikationen, 3D-CAD-Modelle und eine Baugruppenliste (Excel-Liste) genutzt, um ein Prozessverständnis zu erzeugen und Wissen von einem zum anderen Gewerk zu übertragen. Dies ist einerseits sehr aufwändig, da diese Beschreibungen extra für Projektsitzungen beziehungsweise den Workflow aufbereitet (CAD- Zeichnungen) oder erstellt (Baugruppenliste) werden müssen. Des Weiteren sind die angesprochenen Beschreibungsmittel informal, was auf Grund der vielfältigen Interpretationsmöglichkeiten für Missverständnisse bezüglich der ablaufenden Prozesse und somit für Ineffizienz sorgte. Daher wurde das Funktionsmodell entsprechend den ermittelten Anforderungen im Unternehmen (vgl. [HHS+16*]) entworfen. In einem weiteren Workshop im Unternehmen wurde festgestellt: Wird das Funktionsmodell nun so in den betrieblichen Engineering- Workflow integriert, dass es einen Großteil der informellen Darstellungen ersetzt, so steigt die Effizienz im Engineering einerseits durch Zeitersparnis des Erstellens informeller Beschreibungen und durch ein besseres Prozessverständnis. Diese Effizienzsteigerung ist umso höher, je stärker auf die Nutzung von Bibliotheken geachtet wird, da auch diese zur Vermeidung von Missverständnissen beitragen und die Zeit der Erstellung weiter verkürzen. Ein weiterer wichtiger Vorteil für das Engineering im betrachteten Unternehmen ist das Arbeiten in verschiedenen Detaillierungsstufen. Mit Hilfe des vorgestellten Funktionsmodells ist es möglich, in verschiedenen Detaillierungsstufen zu arbeiten und somit auch bei umfassenden Änderungen am Produktionssystem den Überblick zu behalten. Dies gilt insbesondere dann, wenn Änderungen an einem Prozessschritt auch Änderungen an anderen Prozessschritten hervorrufen. Die Verbindungen innerhalb des Funktionsmodells sorgen dafür, dass Auswirkungen von Änderungen in jeglicher Stufe der Hierarchie der Funktionen klar erkennbar sind. Beispielsweise, wenn während der Bearbeitung einer hohen Detailstufe auffällt, dass in einem Prozessschritt eine bestimmte Information nicht erzeugt werden kann. Mit Hilfe des Strukturmodells, das innerhalb des Systemmodells mit dem Funktionsmodell verbunden ist, ist es auf sehr effiziente Weise möglich, die gesamte Struktur des automatisierten Systems nach den Orten der Verwendung der Information zu suchen und somit zu erkennen, welche Auswirkung diese Änderung im Produktionssystem nach sich zieht. Der größte Nutzen für das Engineering durch die Nutzung des Systemmodells entsteht bei einer rechnerinterpretierbaren Einbindung in den betrieblichen Workflow. Analysiert man die bisherige Vorgehensweise im betrachteten Unternehmen, so werden bei neuen Projekten viele Prozessschritte eines Produktionssystems neu entwickelt, die bereits in anderen Systemen in leicht abgewandelter Form vorliegen. Der Grund für diese Vorgehensweise ist, dass es den Mitarbeitern bisher einfacher erscheint, den Prozessschritt erneut zu entwickeln, anstatt sich in die diversen Dokumentationen des bereits vorhandenen Produktionssystems einzuarbeiten. Dies ist insbesondere in der Tatsache begründet, dass Dokumentationen nicht in einem einheitlichen Beschreibungsmittel vorliegen, sondern in einer Vielzahl unterschiedlicher, teils voneinander abhängiger Beschreibungsmittel. Das entwickelte Systemmodell bietet hier die Möglichkeit zu einer effizienten Gestaltung der Reaktivierung 7 Verwendung der Maschinenfunktion in der Praxis 126 vorhandenen Wissens und die Anpassung dieses Wissens auf neue Sachverhalte. Ist ein Produktionssystem mit Hilfe des Systemmodells vollständig geplant und mit Hilfe einer Bibliothek für Prozesse und Technische Ressourcen beschrieben worden, so muss bei einer neuen Entwicklung lediglich nach genau eingrenzbaren Lösungsmöglichkeiten gesucht werden, anstatt eine Lösung neu zu entwickeln. Es ist dem Mitarbeiter somit möglich, mit Hilfe einer automatisierten Suche eine einzige Beschreibung auf die Möglichkeit der Anwendung auf den Fall hin zu untersuchen, anstatt erst eine Kombination aus teilweise mangelhaft dokumentierten 3D-CAD Zeichnungen und textuellen Beschreibungen analysieren zu müssen. Das Systemmodell bietet somit den Vorteil einer wesentlich effizienteren Wiederverwendung von bereits erzielten Ergebnissen. Dies gilt insbesondere dann, wenn das Systemmodell mit Produktdaten und Daten der Technischen Ressourcen, sowie Verweisen auf andere CAx-Daten gepflegt wurde. Zusammenfassend lässt sich in Tabelle 7-3 festhalten, dass durch die Nutzung des Systemmodells mit dem Fokus auf das Funktionsmodell eine Reihe von effizienzsteigernden Faktoren entstehen, die im vorliegenden Abschnitt ausgeführt wurden. Diesen Faktoren gegenüber steht eine Reihe von Aufwänden, die ebenfalls identifiziert wurden.

Tabelle 7-3: Gegenüberstellung der Aufwände und der effizienzsteigernden Faktoren

Aufwände Effizienzsteigernde Faktoren • Entwurf von Richtlinien für Detailtiefen der • Zeitersparnis Modellierung • Funktions- und prozessorientierte Sichtweise • Entwurf von Bibliotheken • Projektübersicht • Integration in bestehende betriebliche Prozesse • Wiederverwendung

Langfristig überwiegen die Faktoren der Effizienzsteigerung im Engineering den Aufwänden, welches in den Workshops mit dem Unternehmen bestätigt wurde. Hierbei ist eine Nutzung von Bibliotheken für die unterschiedlichen Elemente die im Engineering erzeugt werden von entscheidender Bedeutung. Hierbei tauchte immer wieder die Forderung nach standardisierten oder genormten Funktions- und Komponentenbibliotheken auf, deren Nutzung die Kommunikation im Engineering verbessern und den Grad der Wiederverwendung erheblich steigern kann, da auf Basis des Standards jedes Gewerk auf standardisierte Funktionen und Komponenten verweisen kann und somit Fehlinterpretationen minimiert werden. Daher soll im folgenden Kapitel 8 eine Untersuchung des Standes der Technik in Bezug auf die Funktions- und Komponentenbibliotheken erfolgen, um daraus ein Vorgehen zur Erstellung eigener Funktionsbibliotheken zur Nutzung im Engineering abzuleiten.

8 Die Maschinenfunktionen als Gewerke-übergreifende Datenbasis 127

8 Die Maschinenfunktionen als Gewerke-übergreifende Datenbasis Im vorliegenden Kapitel werden Standards und Ansätze untersucht, die sich mit der Definition und Kategorisierung von Maschinenfunktionen beschäftigen. Die Systematisierung der Funktionen ist notwendig, da sie im modernen, systematischen und funktionsorientierten Engineering-Prozess benötigt und als möglichst konsistentes Vokabular zur Beschreibung auch auf unterschiedlichen Detailstufen eingesetzt werden sollen [HSM+01]. Aus den zu betrachtenden Funktionssammlungen werden allgemeine Strukturierungsprinzipien und Unterscheidungsmerkmale von Maschinenfunktionen abgeleitet. Diese werden benötigt, um ein Vorgehen zur Erstellung eigener Funktions- und Komponentenbibliotheken zu entwerfen.

8.1 Einteilung von automatisierten Maschinenfunktionen Die folgenden Abschnitte analysieren Funktionssammlungen, die genutzt werden können, um die Funktionen von Produktionssystemen zu beschreiben oder mit diesen Funktionen im Engineering eines Systems zu planen. In der [VDI 2221] wird eine Klassifizierung der Funktionen in Gesamtfunktion, Teilfunktion und Elementarfunktion vorgenommen. Weiterhin lassen sich Funktionen allgemein nach unterschiedlichen Gesichtspunkten klassifizieren [HAD15, S. 16]: • Nach Zuordnung zu einem System, das diese Funktion bereitstellt. (z. B. Anlagenfunktion, Steuerungsfunktion) • Nach Typ der Eingangs- bzw. Ausgangsgrößen (z. B. Material, Energie, Information) • Nach dem zeitlichen Verhalten der Funktion (z. B. zustandsbehaftet/zustandsfrei, kontinuierlich/diskret) Auf einige dieser Einteilungen wird in den folgenden Abschnitten eingegangen.

8.1.1 Lenze – Maschinenaufgaben Es erscheint naheliegend für die Untersuchung der Funktionen für Fertigungssysteme, einen Blick zu den Herstellern der Antriebstechnik oder der Sensorik zu werfen. Denn diese müssen die geplanten Funktionen mit ihren Lösungen realisieren. Lenze, als Hersteller von Antriebs- und Automatisierungslösungen, hat eine Sammlung von zwölf typischen Maschinenaufgaben veröffentlicht, die durch ihre Produkte realisiert werden können. Die Nutzung dieser Standardfunktionen ermöglicht es, vorhandenes Know-how zur Verfügung zu stellen, die Komplexität zu verringern und Informationen wiederzuverwenden. Diesem Anforderungsprofil wird mit der Modularisierung von Maschinen und der damit verbundenen Bildung von mechatronischen Einheiten begegnet [LEN13]. Abbildung 8-1 zeigt die zwölf Antriebslösungen, die verwendet werden können, um die geforderte Funktion in den mechatronischen Einheiten zu erfüllen. 8 Die Maschinenfunktionen als Gewerke-übergreifende Datenbasis 128

@ Abbildung 8-1: Zwölf typische Maschinenaufgaben von Lenze [LEN16 ] @ Die Maschinenaufgaben werden in [LEN16 ] genauer beschrieben und technische Lösungen in Form einer Produktempfehlung vorgeschlagen, die diese Funktionen erfüllen können. Allgemein gesehen ist diese Sammlung an Funktionen sehr lösungsnah, da hier schon elektrische Antriebe eingesetzt werden und andere Effekte (hydraulische oder pneumatische Aktoren) durch die Begrenzung des Produktportfolios von Lenze keine Beachtung finden.

8.1.2 PLCopen – Motion Control In [PLC16@] werden Funktionen beschrieben, die Bewegungen realisieren können. Dazu werden standardisierte Funktionsbausteine eingesetzt, die administrative Aufgaben und Bewegungen im Zusammenhang mit Linearantrieben realisieren können. Durch die Benutzung dieser Funktionsbausteine zur Planung und Beschreibung von Bewegungen kann in einer frühen Phase des Engineerings plattformunabhängig geplant werden. Somit entfallen aufwändige Anpassungen an diverse Plattformen oder Architekturen bei der Umsetzung der Bewegungsprogramme zu einem späteren Zeitpunkt, da die Bausteine mit dem neutralen Datenaustauschformat PLCopen XML übertragen werden können. Zudem verbessert sich durch die Benutzung der standardisierten Bausteine in der Bewegungssteuerung die Wartbarkeit der Programme. Dem Programmierer stehen zahlreiche administrative und bewegungssteuernde Bausteine zur Verfügung, siehe Tabelle 8-1. Beispielsweise kann mit dem Funktionsbaustein MC_MoveAbsolute eine kontrollierte Bewegung einer Achse zu einer absoluten Position gesteuert werden. Die dafür notwendigen Parameter werden dem standardisierten Funktionsblock übergeben. Statusinformationen sind als Ausgaben des Funktionsblockes ebenfalls standardisiert. Ein Beispiel für eine administrative Funktion stellt der Funktionsbaustein MC_Power dar, der den Power-Zustand des Antriebes an- und ausschaltet.

Tabelle 8-1: Auszug aus den definierten Funktionsblöcken nach [PLC16@]

Administrativ Motion Single Axis Multiple Axis Single Axis Multiple Axis MC_Power MC_CamTableSelect MC_Home MC_CamIn MC_ReadStatus MC_Stop MC_CamOut MC_ReadAxisError MC_Halt MC_GearIn MC_ReadParameter MC_MoveAbsolute MC_ReadBoolParameter MC_MoveRelative

8 Die Maschinenfunktionen als Gewerke-übergreifende Datenbasis 129

Die gezeigte Funktionssammlung umfasst sehr spezifische Funktionsbausteine für die Koordination von Bewegungen mit Hilfe von Linearantrieben. Für ein sehr kleines Anwendungsfeld stellt das die standardisierte Nutzung einer gemeinsamen Bibliothek sicher. Diese Funktionsbausteine können dabei eine Orientierung für die Strukturierung der Funktionsbibliothek geben.

8.1.3 Patzak – Systemtechnik In [PAT82, S. 74] werden die Grundfunktionen hergeleitet, indem Überlegungen angestellt werden, welchen prinzipiellen Einwirkungen die drei Flussgrößen (Materie, Energie, Information) unterliegen können, wenn sie vom Input in den Output eines Systems übertragen werden. Er definiert die folgenden Funktionen als Elementarfunktion und leistet damit eine Grundlage für weitere, darauf aufbauende Arbeiten: • Transportieren • Bewahren • Wandeln • Kombinieren / Trennen • Kreieren / Vernichten • Umformen • Aufnehmen / Aufgeben Werden diese Grundfunktionen den drei Flussgrößen zugeordnet, so ergeben sich die Grundfunktionen konkreter Systeme, siehe Tabelle 8-2.

Tabelle 8-2: Grundfunktionen konkreter Systeme nach [PAT82, S. 77]

transpor- kreieren bewahren wandeln trennen kombinieren tieren vernichten Materie Materie Materie Materie Materie mit speichern Materie Materie und mit Materie transpor- Information isolieren wandeln zerlegen Materie Energie tieren versehen konservieren verbinden laden Energie Energie Energie Energie Energie mit Energie Energie auf und Energie transpor- speichern Information wandeln zerlegen Materie Energie tieren isolieren versehen laden vereinigen Infor- Daten Daten Daten Daten auf Daten mit mationen Infor- Daten Daten durch speichern umfor- Materie Daten kreieren mation übertragen sortieren Energie konservieren men codieren verknüpfen oder codieren zerstören

Für eine Kategorisierung einer Funktionsbibliothek nach der Betrachtung der Ein- und Ausgangsgrößen und deren Grundfunktionen bildet der vorgestellte Ansatz eine solide Basis.

8.1.4 Hirtz – A functional basis for engineering design Basierend auf den Entwicklungen des NIST (National Institut of Standards and Technology, USA) wird in [HSM+01] eine umfangreiche Taxonomie von Funktionen und von Flüssen (Energie-, Stoff- und Informationsfluss) vorgestellt. Dazu werden die Hauptfunktionen aus [SRS99] verwendet: • Nutzungsfunktionen (Quelle, Senke, Speicher) • Kombinations- und Verteilungsfunktionen • Umwandlungsfunktionen • Förderfunktionen 8 Die Maschinenfunktionen als Gewerke-übergreifende Datenbasis 130

• Signal- und Regelungsfunktionen • Montagefunktionen Diese Hauptfunktionen werden weiter detailliert und um zwei weitere Hierarchieebenen ergänzt. Als Beispiel sei in Tabelle 8-3 ein Ausschnitt der Funktionssammlung aufgeführt, der sich in die Förderfunktionen der vorher genannten Unterteilung eingliedern lässt:

Tabelle 8-3: Beispiel für Funktionen und deren Unterteilung nach [HSM+01]

Primär Sekundär Tertiär Bewegen Importieren Exportieren Verlagern Transportieren (Stoff) Übermitteln (Energie/Information) Führen Translatorische Bewegung Rotatorische Bewegung Freiheitsgrade zulassen

Die Untergliederung der Hauptfunktionen erscheint sehr zweckmäßig, da somit eine schrittweise Verfeinerung der Funktionen möglich ist. Dies unterstützt die schrittweise Lösungsfindung im Engineering.

8.1.5 Akiyama – Funktionenanalyse „In der Funktionenanalyse kann die Bedeutung von Funktion entweder auf eine Substantiv- Verb-Benennung beschränkt sein oder (zusätzlich) Kriterien enthalten. Funktion im engeren Sinne ist Thema und (Assoziationen auslösendes) Stichwort im Prozess der Ideenfindung. Funktion im weiteren Sinne beinhaltet zusätzlich Kriterien zum Bestimmen des Erfüllungsgrads zwecks Bewertung von Ideen oder Lösungsalternativen.“ [AKI94]

Nach [AKI94] werden dabei die Funktionen gemäß Abbildung 8-2 in folgende Funktionstypen eingeteilt:

Abbildung 8-2: Funktionentypen nach [AKI94]

Die gezeigten Funktionstypen werden in [AKI94] im Weiteren noch näher erklärt. Im Fokus dieser Arbeit stehen vorrangig die Gebrauchsfunktionen vor den Geltungsfunktionen, da diese sich auf die inneren Mechanismen beziehen, um den Zweck oder das Ziel des Produktes zu erfüllen. Als Geltungsfunktionen zählen diejenigen Funktionen, welche Gestalt oder Farbe eines Produktes bestimmen, um die Anforderungen der Kunden zufriedenzustellen. Die weitere Einteilung der Funktionen nach Grundfunktionen und Sekundärfunktionen wird wie folgt begründet: „Grundfunktionen geben dem Objekt seine Daseinsberechtigung. […] Sekundärfunktionen sind alle anderen Funktionen, die bei der Verwirklichung der Grundfunktion helfen.“ [AKI94] Die dargestellte Funktionsunterteilung stellt eine sehr allgemeine Kategorisierung dar, welche die Funktionen nach ihrer Wirkung am Produkt unterscheidet. 8 Die Maschinenfunktionen als Gewerke-übergreifende Datenbasis 131

8.1.6 Zusammenfassung der Ansätze Zusammenfassend werden die wichtigsten Punkte zur Einteilung der Funktionen der unterschiedlichen Ansätze in folgender Tabelle 8-4 gegenüber gestellt. Wie im vorliegenden Abschnitt erklärt, fokussiert Lenze sehr stark auf die Lösungen, die eine Funktion erfüllen können. Durch das begrenzte Produktportfolio ist diese Sicht auf die Funktionen sehr eingeschränkt, da hier eine sehr detaillierte Lösung mit Komponentenvorschlägen vorliegt. Lösungsoffener sind die Funktionsbausteine von PLCopen, die zur Bewegungssteuerung von Linearantrieben dienen. Auch hierbei wird eine sehr kleine Domäne betrachtet. Jedoch sind die Bausteine neutral ausgeführt und können durch jeden Hersteller / Programmierer der Antriebe individuell gefüllt werden. Der Typ und die Schnittstellen des Bausteins sind dabei standardisiert. Dadurch sind ein verlässlicher Austausch und eine aufwandsarme Wartung der Bausteine möglich.

Tabelle 8-4: Zusammenfassung der Ansätze der Funktionsbeschreibung

Ansatz Domäne Einteilung Lenze Elektrische Antriebe 12 Funktionen zur Lösung von Bewegungsaufgaben PLCopen Bewegungssteuerung Administrative und Bewegungs-Funktionsbausteine Patzak Grundlagen 6 Grundfunktionsarten Hirtz Grundlagen 6 Grundfunktionsarten mit dreistufiger Hierarchie Akiyama Grundlagen Grobe Unterteilung der Funktionen nach Wirkung am Produkt

Es lässt sich erkennen, dass lediglich Patzak und Hirtz eine Einteilung der Funktionen in unterschiedliche Arten von Funktionen vornehmen. Diese Unterteilung, auch mit der hierarchischen Gliederung, erscheint für die vorliegende Arbeit am wirkungsvollsten und wird daher in Abschnitt 9 verwendet, um eine firmeneigene Funktionsbibliothek aufzubauen. Die Einteilung nach Akiyama erscheint für eine Produktklassifizierung am ehesten nutzbar, da die Unterteilung in die genannten Grundfunktionen sehr grob und allgemein gehalten ist.

8.2 Kategorisierung von Maschinenfunktionen In diesem Abschnitt werden unterschiedliche Definitionen der automatisierten Maschinenfunktion untersucht. Dazu werden Normen aus verschiedenen Domänen daraufhin analysiert, wie die jeweiligen domänentypischen Funktionen beschrieben werden.

8.2.1 DIN 8580 – Fertigungsverfahren Die [DIN 8580] definiert Fertigungsverfahren und gibt somit eine Orientierung, wie man die Funktionen, die diese Verfahren nutzen, einteilen kann. Die Einteilung erfolgt in dieser Norm in drei Hierarchieebenen als Hauptgruppen, Gruppen und Untergruppen. Abbildung 8-3 zeigt die sechs Hauptgruppen der Fertigungsverfahren.

Abbildung 8-3: Hauptgruppen der Fertigungsverfahren Die beschriebenen Gruppen der Fertigungsverfahren sind auch hier lösungsneutral formuliert und eignen sich somit als grobe Gliederung der Funktionen in der funktionsorientierten Planung eines Systems. 8 Die Maschinenfunktionen als Gewerke-übergreifende Datenbasis 132

8.2.2 VDI 2860 – Montage- und Handhabungstechnik Die [VDI 2860] beschreibt detailliert Funktionen der Handhabungstechnik. Dabei werden diese Funktionen in folgende Teilfunktionen eingeteilt: • Speichern (Halten von Mengen) • Mengen verändern • Bewegen (Schaffen und Verändern einer definierten räumlichen Anordnung) • Sichern (Aufrechterhalten einer definierten räumlichen Anordnung) • Kontrollieren Für jede dieser Teilfunktionen werden unterschiedliche Elementarfunktionen abgebildet, die sich dann wieder zu komplexeren Funktionen zusammensetzen lassen. Zudem wird jede dieser Elementarfunktionen durch ein Symbol repräsentiert. Ein Beispiel sei in Abbildung 8-4 gezeigt, wo die beiden Elementarfunktionen „Drehen“ und „Verschieben“ zur Funktion „Schwenken“ kombiniert werden.

Abbildung 8-4: Funktion „Schwenken“ als Überlagerung der Elementarfunktionen „Drehen“ und „Verschieben“ [VDI 2860] In aktuellen Forschungsarbeiten werden die Normen [DIN 8580] und [VDI 2860] genutzt, um die verwendeten Funktionen zu kategorisieren, siehe [HHH15] und [LOS13]. Die genormten Funktionen eignen sich für eine sehr detaillierte, aber lösungsneutrale Darstellung der Montage- und Handhabungsfunktionen eines Systems.

8.2.3 IEC 62390 – Leitfaden für Geräteprofile Die [IEC 62390] hat das Ziel, eine gemeinsame und allgemein gültige Methode anzubieten, um Informationen und das Verhalten von vernetzten Geräten darzustellen. Für die Unterscheidung einzelner Geräteklassen werden Profile verwendet. Diese Profile definieren eine gemeinsame Menge von Funktionen, um unter anderem eine konsistente Strukturierung und Semantik der Funktionen der Geräte zu ermöglichen. Der Informationsfluss zwischen Geräten eines Systems verläuft von der Informationserkennung des Prozesses (Geber, Eingabegerät) über die Informationsverarbeitung (Steuerung) zur Informationsverwendung im Prozess (Aktor, Antrieb, Ausgabegerät). Der Informationsfluss erfolgt zudem durch einen Signalfluss entlang einer Funktionskette [IEC 62390]. Die Norm zeigt eine Funktionsgruppierung in drei Hierarchieebenen, die im Folgenden auszugsweise dargestellt wird, siehe Tabelle 8-5. Dabei bilden die ersten beiden Hierarchieebenen des Gebietes und der Teilgebiete die Funktion lösungsneutral ab. Die Ebene der Grundgeräte repräsentiert dazu passende Lösungen, die nicht mehr als lösungsneutral gelten.

8 Die Maschinenfunktionen als Gewerke-übergreifende Datenbasis 133

Tabelle 8-5: Gerätegruppen, Auszug aus [IEC 62390]

Gebiet/Gruppe Teilgebiet (Familie) Grundgerät (Familienmitglied) Messgerät, Geber Durchfluss (F) Differenzdruck (Sensor, diskret oder analog) Schwimmkörper Ultraschall Magnetisch-induktiv…. Füllstand (L) Hydrostatisch Verdrängung Schwimmschalter Ultraschall…. Temperatur (T) Widerstand Pyrometer Ausdehnung Heiß-/Kaltleiter Bewegungssteuerung Schütz Sanftstarter Achsensteuerung Motorsteuerung….

Da die Norm Geräteklassen kategorisiert, eignet sie sich dazu, eine funktionsorientierte Einteilung dieser Geräte auf Grund ihrer Funktionen vorzunehmen. Somit kann auch eine Funktionsbibliothek aufgebaut werden, indem die vorliegenden Gerätegruppen genutzt und in geeigneter Weise kombiniert werden, um die notwendigen Funktionen in einem System zu realisieren.

8.2.4 DIN 19226-6 – Regelungs- und Steuerungstechnik: Begriffe zu Funktions- und Baueinheiten In der [DIN 19226-6] wird unter anderem die Funktionseinheit definiert, die den Wirkzusammenhang zwischen Eingangs- und Ausgangsgrößen herstellt und die nach Aufgabe oder Wirkung unterschieden wird. Die Norm definiert zudem einige Funktionseinheiten und kategorisiert diese entsprechend ihren Eigenschaften in drei Detaillierungsebenen. Ein Auszug ist in Tabelle 8-6 aufgeführt.

Tabelle 8-6: Funktionseinheiten, Auszug aus [DIN 19226-6]

Funktionseinheit Ebene 1 Ebene 2 Ebene 3 Bildung von Größen und Signalen aus der Strecke Meßeinrichtung und deren Umgebung Aufnehmer Signalgeber Abtaster Haltglied Impulsformer Grenzsignalgeber Trigger Anpassung und Weitergabe von Größen und Umformer Wandler Signalen Barriere Verstärker Umsetzer Analog-digital-Umsetzer Seriell-parallel-Umsetzer Parallel-seriell-Umsetzer Filter Schalttor

Auch hier ist eine Geräte-nahe Kategorisierung wie nach der [IEC 62390] zu finden, die sich für die Einordnung von Geräten in eine bestimmte Klasse eignen. Aus den so gegliederten Gerätebibliotheken können dann entsprechende Funktionen zusammengestellt werden. 8 Die Maschinenfunktionen als Gewerke-übergreifende Datenbasis 134

8.3 Zusammenfassung Aus den untersuchten Ansätzen des vorliegenden Kapitels lassen sich folgenden Punkte ableiten, die eine Bibliothekserstellung beeinflussen: Die Funktionen eines Produktionssystems sollten nach ihrer Wirkung am Produkt klassifiziert werden. Eine mehrstufige Einteilung der Funktionen erleichtert das Finden von Lösungen auf unterschiedlichen Detailstufen. Die Lösungen im Sinne von detaillierteren Funktionen können so im Laufe des Engineerings von grob nach fein, entsprechend ihrer Ebene in der Bibliothek angewendet werden. Eine Kombination von unterschiedlichen Standards, die verschiedene Ebenen der Lösungen beschreiben, erscheint hier sehr vorteilhaft. In der Domäne der Fertigungstechnik lassen sich mit den Funktionen der [DIN 8580] und [VDI 2860] ein Großteil der Funktionen in Fertigungsanlagen beschreiben. Die [DIN 8580] kann für eine sehr grobe Einteilung verwendet werden, während die [VDI 2860] eine sehr feingranulare Beschreibung der Funktionen auf einer tieferen Ebene der Bibliothek erlaubt. Die [IEC 62390] ist sehr auf die gerätetechnische Umsetzung ausgerichtet, hier müsste eine abstraktere Sichtweise auf die Funktionen gewählt werden, damit eine lösungsneutrale Darstellung der Funktionen gewährleistet ist. Ähnlich verhält es sich mit der [DIN 19226-6]. Auch hier wird das Gerät in den Fokus der Betrachtung gerückt. Die Komponenten, welche die geplanten Funktionen des Produktionssystems ausführen, sollten ebenfalls hierarchisch gegliedert in Bibliotheken angelegt werden. Diese Einteilung in Gruppen und Untergruppen ermöglicht es, im Laufe des Engineerings zu der jeweiligen Detaillierungsebene der Funktion eine entsprechende Komponente auszuwählen. Für eine grobe Detaillierung der Funktion kann dementsprechend eine grob kategorisierte Komponente zugeordnet werden. Zudem erscheint es sinnvoll, in einer solchen Bibliothek bereits etablierte Lösungen im Sinne von Kombinationen von Funktionen und den ausführenden Komponenten in Templates abzulegen. Das Bilden dieser komplexen Kopiervorlagen aus den genannten Basiselementen Funktionen und Geräten mit ihren Verbindungen wird in dem Ansatz zur Bildung von firmeneigenen Funktionsbibliotheken berücksichtigt.

9 Methode zur Erstellung von individuellen Funktionsbibliotheken 135

9 Methode zur Erstellung von individuellen Funktionsbibliotheken Im vorliegenden Kapitel wird eine Methode vorgestellt, die es ermöglicht, aus vorliegenden Engineering-Daten eigene Bibliotheken für häufig verwendete Funktionen von Produktionssystemen zu erstellen. Diese Bibliothekselemente können als Kopiervorlagen von komplexen Funktionen und deren Realisierung für neue Engineering-Projekte verwendet werden. Zudem ist es möglich, mit Hilfe der Bibliothekselemente die vorhandenen Engineering-Daten zu strukturieren und für alle Gewerke geordnet zur Verfügung zu stellen. Die dafür notwendigen Schritte sind in den folgenden Abschnitten erklärt und wurden an einem Beispielprojekt exemplarisch angewendet.

9.1 Vorgehensweise zur Ableitung von Maschinenfunktionen Der Aufbau einer Funktionsbibliothek mit Elementen, die beim Engineering von neuen Systemen wiederverwendet werden können, erfolgt an Hand der Engineering-Artefakte eines bereits geplanten Produktionssystems. Denn bei diesen fertig geplanten und erfolgreich errichteten Lösungen ist sichergestellt, dass sie die Ziele innerhalb des Produktionssystems den Anforderungen entsprechend erfüllen. Der Aufbau einer firmeneigenen Funktionsbibliothek erfolgt dabei entsprechend den Schritten innerhalb des Engineering-Workflow: 1. Funktionen aus dem Funktionsmodell extrahieren und kategorisieren, 2. Strukturmodell auswerten, Analyse aller Lösungen, die die zugeordnete Funktion erfüllen und diese in der Bibliothek ablegen, 3. Verhaltensmodell auswerten und die zur Funktion passenden Elemente in der Bibliothek ablegen. Aus diesen drei Schritten ergibt sich der erste Teil der Funktionsbibliothek, der einer strukturierten Sammlung von Funktionen und den dazu gehörigen Lösungselementen in Form von Gerätedaten und Verhaltensbeschreibungen entspricht. Zudem können darin auch Produkte, Energien und Informationen abgelegt werden, die in Kombination mit den Funktionen häufig verwendet werden. Der zweite Teil der Funktionsbibliothek besteht aus Templates (im Sinne von Kopiervorlagen), die eine Zusammenstellung von Elementen der Funktions- (mit Produkt/Energie/Information), Struktur- und Verhaltensbeschreibungen darstellt. Sowohl in den Elementen der Funktionsbibliothek als auch in den Templates, die im Engineering wiederverwendet werden können, werden notwendige Daten zu deren Beschreibung abgelegt. Diese Daten können Komponentenbeschreibungen in Form von Datenblättern, CAD-Zeichnungen und weitere Dokumentationen sein. Das beschriebene zweistufige Vorgehen zum Aufstellen einer Funktionsbibliothek mit seinen Elementen und den Templates zum Abbilden von teils komplexen Funktionen wird im folgenden Abschnitt beschrieben. Mit dessen technischer Umsetzung lassen sich die Anforderungen (Funktionsmodell) und die dazu passenden und etablierten Lösungen (Struktur- und Verhaltensmodell) in einer nach dem Systemmodell strukturierten Bibliothek abbilden.

9.2 Strukturierung der Bibliotheken in Module und Varianten Im vorliegenden Abschnitt wird auf die Strukturierung der Bibliotheken eingegangen. Für die Nutzung der Bibliotheken und der darin enthaltenen Elemente ist es von entscheidender Wichtigkeit, dass die Struktur für jeden Nutzer verständlich und dadurch die gesuchten Elemente schnell wiedergefunden werden können. Es wird daher nachfolgend betrachtet, 9 Methode zur Erstellung von individuellen Funktionsbibliotheken 136 wie Funktionen und Komponentendaten in der Bibliothek eingebracht und durch eine geeignete Strukturierung effizient abgelegt werden können. Da auch komplexe Templates aus mehreren Elementen, wie Funktionen, Struktur- und Verhaltensbeschreibungen, in den Bibliotheken abgelegt werden sollen, bietet sich hierfür die Bildung von Modulen an. Für Module gibt es auf Grund der weiten Verbreitung in unterschiedlichen Domänen keine einheitliche Definition, allerdings ist eine aus der Montagesicht geprägte Definition von Modularität vorherrschend: Darin wird ein Modul als eine räumlich abgegrenzte, komplexe Baugruppe betrachtet, mit definierten Schnittstellen für mechanische Verbindungen sowie für den Austausch von Leistungen und Informationen [BLE11]. Sowohl für die Funktionen, die Struktur- und die Verhaltensbeschreibungen, als auch für die komplexeren Templates in Form von Modulen muss eine Betrachtung der Varianten durchgeführt werden, da zur Erfüllung einer Anforderung durchaus mehr als eine passende Lösung gefunden werden kann. Daher ist es möglich, Varianten von Funktionen, Komponenten und auch von Modulen in den Bibliotheken abzubilden und diese nach ihrer Varianz zu unterscheiden.

[BLE11] definiert Varianten eines Produktes, welche im vorliegenden Fall Funktionen, Komponenten- und Verhaltensbeschreibungen sowie Module sein können, wie folgt: „Die einzelnen Vertreter einer Produktfamilie werden als Varianten bezeichnet. Varianten von Produkten können als andere Produkte des gleichen Zwecks bezeichnet werden, die sich in mindestens einem Merkmal unterscheiden. Diese Merkmale werden als Unterscheidungsmerkmale einer Produktfamilie bezeichnet, die unterschiedlich ausgeprägt sein können.“ [BLE11] Für die Anwendung der Bibliotheken ist es wichtig, dass deren Nutzung einen Vorteil im Engineering bringt. Daher müssen die Struktur, die Dokumentation und auch die Anpassung der Bibliothekselemente an veränderte Anforderungen geeignet sein, diese Vorteile anzubieten. Ist das Auffinden oder Anpassen eines Bibliothekselementes aufwändiger als es neu anzulegen, so ist die Nutzung der Bibliothek nicht sinnvoll, da hier weder eine Zeitersparnis noch ein Vorteil durch die Nutzung bereits etablierter Lösungen entsteht. In der vorliegenden Arbeit liegt der Fokus auf automatisierten fertigungstechnischen Produktionsanlagen. Die Gestaltung der Bibliotheken orientiert sich durch die vorliegenden Fertigungs- und Handhabungsfunktionen innerhalb dieser Produktionssysteme an den vorgestellten Elementarfunktionen ausgewählter Funktionssammlungen aus Abschnitt 8. Die genaue Strukturierung und Detailtiefe der Funktionen und Module richtet sich dabei stets an den individuellen Bedürfnissen des Engineerings des jeweiligen Herstellers aus. Bei der Strukturierung der Bibliothekselemente wird die mehrstufige Lösungsfindung unterstützt. Das bedeutet, dass bei der Strukturierung der Bibliothek auf oberster Ebene allgemeine Lösungen und mit zunehmender Detailtiefe konkretere Lösungen abgelegt werden. Eine Strukturierung, in der Funktionen in drei Ebenen wie in Abschnitt 8.1.4 beschrieben eingeteilt werden, ist hier vorstellbar. Das gleiche gilt für die Strukturierung der physischen Komponenten, die eine konkrete Lösung bereitstellen. Auch diese lassen sich in unterschiedliche Ebenen der Detaillierung, beispielsweise den Fertigungsverfahren, vgl. Abschnitt 8.2.1, gliedern. An einem Beispiel wird die Strukturierung einer Bibliothek im nachfolgenden Abschnitt erläutert. 9 Methode zur Erstellung von individuellen Funktionsbibliotheken 137

9.3 Bibliothekserstellung und -nutzung in einem Beispielunternehmen Nach der umfassenden Analyse des betrachteten Produktionssystems des Sensorherstellers aus Abschnitt 7.1 wird im vorliegenden Abschnitt auf die Erstellung und anschließende Nutzung einer firmeneigenen Bibliothek erläutert, die im Rahmen unterschiedlicher Workshops zusammen mit dem Unternehmen erstellt wurde. Zur Erstellung der Bibliothek wurde die vollständige Systembeschreibung des bereits analysierten Produktionssystems genutzt. Diese liegt bereits als AutomationML-Datei vor. Daher ist auch die Erstellung der Bibliothek für Funktionen, Struktur- und Verhaltensbeschreibungen beispielhaft in AutomationML ausgeführt. An dieser Stelle kann aus Gründen der Verschwiegenheit nur auf die prinzipielle Struktur der Bibliotheken eingegangen, diese aber nicht an konkreten Beispielen des untersuchten Herstellers erklärt werden.

9.3.1 Erstellung der Bibliotheken in AutomationML In AutomationML werden die elementaren Bestandteile für die Bibliothekserstellung, die Funktionen, Struktur- und Verhaltensbeschreibungen in SYSTEMUNITCLASSLIBRARIES abgelegt. In Abbildung 9-1 ist der Strukturteil der Bibliothek dargestellt. Sie beinhaltet zum einen die Produkte mit ihren Komponenten. In dem vorliegenden Anwendungsbeispiel wird ein mechatronisches Produkt betrachtet, dessen Bibliothekselement sich in die Teile Hardware und Software unterteilen lässt. Unter dem Hardware-Element des Produktes A1 finden sich alle Komponenten, die zur Erstellung des Endproduktes benötigt werden. Im Hardware-Element selbst kann über eine Referenz auf externe Dokumente, beispielsweise eine Materialliste, verwiesen werden, die im Einkauf genutzt werden kann. Das Software- Element des Produktes A1 enthält die Parametrisierung, die bei der Herstellung des Produktes A1 auf das Produkt selbst aufgespielt wird. Auch hier ist es möglich, innerhalb des Software-Elements des betrachteten Produktes weitere Dokumente und Daten abzulegen. Das sorgt dafür, dass stets die aktuellste Version des Produktes im Engineering verwendet wird.

Abbildung 9-1: Bibliothek der Strukturelemente Zum anderen sind in der Strukturbibliothek die einzelnen Komponenten des Produktionssystems abgelegt. Sie sind als SYSTEMUNITCLASS Equipment in Abbildung 9-1 zu finden und beinhaltet die Bestandteile (hier als Ressourcen bezeichnet) für ein Produktionssystem. 9 Methode zur Erstellung von individuellen Funktionsbibliotheken 138

Aus den beschriebenen elementaren Bestandteilen der Bibliothek lassen sich Templates für häufig vorkommende Funktionen mit den entsprechend zugeordneten Geräten erstellen. Diese Templates liegen in einer separaten SYSTEMUNITCLASSLIBRARY und beinhaltet SYSTEMUNITCLASSES und INTERNALELEMENTS mit den entsprechenden INTERFACES und INTERNALLINKS. Die Struktur für den Aufbau der Templates orientiert sich an dem in der vorliegenden Arbeit eingeführten Systemmodell mit seinen drei Teilmodellen, da sich diese Struktur auch im Engineering bewährt hat und die Templates sich somit einfach im Engineering-Workflow nutzen lassen. In Abbildung 9-2 ist beispielhaft ein Template für eine Funktion abgebildet. Funktionstemplates sind, wie auch das Funktionsmodell des Systemmodells, gemäß dem PPR-Konzept in Produkt-, Prozess- und Ressourcenstruktur untergliedert. Diese Strukturierung ermöglicht auch bei komplexen Strukturen mit dekomponierten Funktionen einen Überblick über die darin abgelegten Daten.

Abbildung 9-2: Beispiel eines Funktionstemplates In den Funktionstemplates können bereits Verbindungen zwischen den Elementen angelegt werden, die beim Instanziieren des Templates übernommen werden. Im vorliegenden Beispiel ist der Prozess „Funktion 1“ mit einem Eingangsprodukt „Produkt 1“ über eine Flussbeziehung und mit der ausführenden Technischen Ressource „Ressource 1“ über eine Nutzungsbeziehung verbunden. Für das Instanziieren dieser stark verknüpften Templates sind spezielle Funktionalitäten in den ausführenden Engineering-Werkzeugen notwendig, die im Detail im nachfolgenden Kapitel 10 beschrieben werden. Die entscheidende Stärke des Bibliothekskonzepts ist die Nutzung von kombinierten Templates, in denen Anteile von Funktion, Struktur und Verhalten enthalten sind. Diese Templates lassen sich aus den beschriebenen elementaren Bibliotheksbestandteilen aufbauen und bilden somit die in Abschnitt 9.2 beschriebenen Module ab. Abbildung 9-3 zeigt beispielhaft den Aufbau eines solchen kombinierten Templates. 9 Methode zur Erstellung von individuellen Funktionsbibliotheken 139

Abbildung 9-3: Beispiel eines kombinierten Templates Das vorliegende Beispiel enthält sowohl einen Funktionsanteil, als auch einen Strukturanteil eines Moduls. Die beiden Anteile sind an den entsprechenden Schnittstellen (vom Typ „Represents_HW“) über einen INTERNALLINK miteinander verbunden. Im vorliegenden Beispiel wird der Technischen Ressource „Ressource 2“ (der Klasse „Ressource A“) das Gerät „Ressource 2“ (der Klasse „Ressource A1“) zugeordnet. Damit wird zum Ausdruck gebracht, dass das konkrete Gerät im Strukturanteil die Anforderungen der Technischen Ressource im Funktionsanteil erfüllen kann.

9.3.2 Anwendung der Bibliotheken im betrachteten Unternehmen Die Bibliotheken des untersuchten Sensor-Herstellers wurden nach dem vorgestellten Aufbau angelegt. Die Funktionsbibliothek wurde beispielhaft für die unterschiedlichen Fügefunktionen angelegt, die an unterschiedlichen Stellen und mit verschiedenen Verfahren in den Produktionssystemen des Sensor-Herstellers eingesetzt werden. Ausgehend von der Beschreibung des Produktionssystems, die in der AutomationML-Datei vorliegt, wurden die einzelnen Funktionen wie beschrieben in projektübergreifend nutzbare Bibliothekselemente abgebildet. Dabei wird die AutomationML-Datei als zentrale Datenablage für das Projekt der Errichtung des geplanten Produktionssystems benutzt, indem alle verfügbaren Daten über Funktionen, Komponenten und über geplante Abläufe in der Datei, zusätzlich zu den schon vorhandenen Engineering-Daten, ergänzt wurden. Die dadurch entstehenden Bibliothekselemente sind durch diese Daten umfassend dokumentiert und für eine erneute Verwendung in weiteren Engineering-Projekten geeignet. Wird ein Bibliothekselement im Engineering instanziiert, so können die abgelegten Dokumente mit vererbt werden. Oder sie verbleiben im Bibliothekselement, und das instanziierte Element verweist nur darauf. Dies ist beispielsweise mit Handbüchern zu bestimmten Komponenten vorstellbar. Dadurch soll sichergestellt werden, dass alle Beteiligten am Engineering mit dem aktuellen Planungsstand arbeiten, da stets die aktuellste Version eines Dokumentes in der AutomationML-Datei verlinkt ist. Hier ist auch eine 9 Methode zur Erstellung von individuellen Funktionsbibliotheken 140

Versionierung möglich, indem ein neues Bibliothekselement für die neue Version aus dem alten Bibliothekselement erstellt wird. An einem Beispiel wird exemplarisch auf die unterschiedlichen Daten in den Bibliothekselementen eingegangen werden. Abbildung 9-4 zeigt ein kombiniertes Template, das sowohl Funktions- als auch Struktur- und Verhaltenselemente enthält. Den jeweiligen Elementen sind einige Merkmale und Dokumente exemplarisch zugewiesen, die durch den Sensorhersteller an der entsprechenden Stelle in der AutomationML-Datei abgelegt werden oder auf die referenziert wird.

Abbildung 9-4: Template im betrachteten Unternehmen mit Zuordnung der Daten Unterhalb der Prozessbeschreibung des Gesamtprozesses und seinen Prozessschritten werden Dokumente zur Fertigungsfolge und Arbeitsbeschreibungen für die Montage- Mitarbeiter abgelegt. Da dem Prozess eindeutige Ein- und Ausgangsprodukte zugeordnet sind, ist dieser Verweis auch in den Dokumenten nutzbar und eine eindeutige Identifikation der zu nutzenden Produkte für den jeweiligen Prozess/Prozessschritt gegeben. Innerhalb der Elemente der Produkte können weiter Informationen zu deren Beschaffenheit angegeben werden. Wie aufgeführt, sind das im vorliegenden Beispiel minimale und maximale Ausdehnungen der zu verarbeitenden Produkte in dem dazugehörigen Prozessschritt oder geforderte Materialeigenschaften. Weiterhin ist dem Prozess eine Technische Ressource zugeordnet, die mit einer Komponente im Strukturmodell verbunden ist. Dies stellt einen eindeutigen Bezug zu einem Equipment des Produktionssystems, wie beispielsweise einem bestimmten Werkzeug, einer Maschine oder Vorrichtung dar. Innerhalb der Technischen Ressource sind Informationen zu deren technischen Anforderungen, wie Versorgung mit Druckluft und elektrischer Energie, hinterlegt, die für eine Gesamtbilanz des Produktionssystems zur Auslegung der Druckluftversorgung und der Energieverteilung herangezogen werden. 9 Methode zur Erstellung von individuellen Funktionsbibliotheken 141

Im Strukturmodell ist zum einen das physische Produkt hinterlegt, das auf dem Produktionssystem gefertigt werden soll. Wie in Abschnitt 5.2.2 beschrieben, kann auch das Produkt über ein Strukturmodell verfügen, welches den Aufbau des Produktes aus seinen Komponenten beschreibt. Im Funktionsmodell stellt das Produkt lediglich einen Platzhalter zur Definition von Anforderungen an den Prozess dar. Im Strukturmodell hingegen kann es in seine Hardware- und Softwareanteile zerlegt und somit viel detaillierter dargestellt werden. Darin werden Informationen über die Einzelteile (BoM = Bill of Material) und auch über die Hardware-Struktur in Form von 3D-CAD-Zeichnungen hinterlegt. Im Softwareanteil werden im vorliegenden Anwendungsbeispiel die Parameter abgelegt, die im Laufe der Produktion des Produktes auf das Produkt aufgespielt werden. Zum anderen sind die Komponenten des Produktionssystems ebenfalls im Strukturmodell abgelegt. In deren Elementen werden das Fertigungslayout des Produktionssystems und Informationen über die genutzten Maschinen, Werkzeuge und Halterungen abgelegt. Insgesamt bietet die vorgestellte firmeneigene Bibliothek, aufgestellt nach dem dargestellten Vorgehen, die Möglichkeit, aus den erstellten Bibliothekselementen das Engineering von neuen Produktionssystemen umfassend zu unterstützen. Dies wurde durch den Sensorhersteller in den Workshops bestätigt. Durch die umfangreiche Dokumentation des Produktionssystems an einer zentralen Stelle und durch die Möglichkeit des Datenaustausches zwischen den Beteiligten ist hier eine zentrale Planungsgrundlage erstellt worden.

9.4 Zusammenfassung Das vorliegende Kapitel 9 beantwortet die Forschungsfrage 6 an dieser Stelle:

6. Wie können diese Informationen in Bibliotheken abgelegt werden, um sie im Engineering von Neuanlagen wiederzuverwenden?

Wie im vorliegenden Kapitel beschrieben, ist die Erstellung von Bibliotheken möglich, die sich in der Struktur an dem vorgestellten Systemmodell orientieren. Dabei können die dafür notwendigen Bibliothekselemente aus bereits geplanten Produktionssystemen abgeleitet werden. Die Strukturierung der Bibliothekselemente richtet sich nach den individuellen Gegebenheiten der jeweiligen Unternehmen und deren Engineering-Abläufen, kann sich aber an den vorgestellten Strukturierungsansätzen aus Kapitel 8 orientieren. Diese Elemente der Funktions-, Struktur- und Verhaltensbibliothek werden genutzt, um Module aufzubauen, die als zusammengesetzte Templates eingesetzt werden können. Zusätzlich können weitere Informationen in diesen Templates abgelegt und im Engineering genutzt werden, wie das an einem Beispiel gezeigt wurde. Dadurch ergibt sich ein hoher Grad an Wiederverwendung bereits geplanter Elemente und etablierter Lösungen. Dies erfüllt somit die Anforderungen des untersuchten Sensorherstellers nach einer umfassenden Nutzung bereits in existierenden Produktionssystemen geplanter Lösungen für das Engineering zukünftiger Produktionssysteme. Zudem bildet die Bibliothek eine zentrale Datengrundlage im Engineering, da alle Beteiligten auf die gleichen aktuellen Daten zugreifen können.

10 Engineering-Werkzeug zur funktionsorientierten Planung 142

10 Engineering-Werkzeug zur funktionsorientierten Planung Bisher existieren nur wenige Werkzeuge, mit denen eine funktionsorientierte Planung auf abstrakter Ebene durchgeführt werden kann. Auch die softwaretechnische Unterstützung der Formalisierten Prozessbeschreibung ist bisher kaum vorhanden. Ein wesentlicher Nachteil der bisher eingesetzten Werkzeuge ist ihre mangelnde Offenheit [FDB+12] und die kaum vorhandenen Möglichkeiten, die erzeugten Daten in ein neutrales Austauchformat zu übertragen.

10.1 Grafischer Editor für AutomationML-basierte Modellierung Aus den genannten Anforderungen abgeleitet, wurde im Rahmen der vorliegenden Arbeit ein prototypisches Werkzeug basierend auf [GSP+16*] implementiert, das die Möglichkeit bietet, ein Funktionsmodell eines Systems zusammen mit weiteren Teilmodellen, wie Struktur und Verhalten, in einem Editor zu erstellen und sich die Funktionsstruktur grafisch anzeigen zu lassen. Für diese Visualisierung wurde die Darstellung gemäß der FPB gewählt. Im Folgenden werden die unterschiedlichen Fähigkeiten des Werkzeuges kurz vorgestellt und an jeweils einem Beispiel erklärt.

10.1.1 Bedienoberfläche des Editors Der erstellte Editor dient dazu, eigene AutomationML-Dateien zu erstellen, um nicht vorhandene Engineering-Schnittstellen in einem ersten Schritt zu umgehen. Das Systemmodell, das in den unterschiedlichen Engineering-Werkzeugen mit Informationen angereichert werden soll, kann so händisch durch den Entwickler angelegt werden. Mit der entstandenen Datei können sowohl Modellierungsansätze getestet als auch selbst implementierte oder vorhandene Schnittstellen getestet werden. Abbildung 10-1 zeigt die Bedienoberfläche des Editors. 10 Engineering-Werkzeug zur funktionsorientierten Planung 143

Abbildung 10-1: Bedienoberfläche des entwickelten Engineering-Werkzeuges Einige Grundfunktionalitäten werden im Folgenden beschrieben. Hauptsächlich wird dabei @ auf die Unterschiede zum AutomationML-Editor des AutomationML e.V. [AUT17C ] eingegangen. Wie aus Abbildung 10-1 entnommen werden kann, ist die Bedienoberfläche in fünf Bereiche aufgeteilt.

A. Im Hierarchy-Bereich werden die Daten des Systemmodells in der INSTANCEHIERARCHY abgelegt. Dabei findet eine Unterteilung in die drei Teilmodelle (Funktion, Struktur, Verhalten) statt. Die einzelnen Elemente sind mit Namen, Rolle und Klasse angegeben. B. Im Bereich der Rollen-Bibliothek werden die ROLECLASSES der AutomationML-Datei aufgeführt. Diese können durch drag&drop einem Systemelement aus der INSTANCEHIERARCHY zugewiesen werden, oder in der INSTANCEHIERARCHY instanziiert werden. C. Ein Teil der SYSTEMUNITCLASSES wird im Bereich der Funktionsbibliotheken abgelegt. D. Der andere Teil, die Templates, werden im Bereich der Templates abgelegt. Diese Templates können unterschiedliche Kopiervorlagen, auch für komplexe Zusammenstellungen, enthalten. Diese können, wie die Elemente aus Bereich C, durch drag&drop in die INSTANCEHIERARCHY instanziiert werden. Die Besonderheit dabei ist, das Elemente, die mit INTERNALLINKS verbunden sind, auch nach dem Instanziieren noch diese Verbindung aufweisen. Somit sind stark miteinander verknüpfte Kopiervorlagen erstellbar und uneingeschränkt nutzbar. E. Im Bereich der Eigenschaften werden die Attribute der Elemente sowie deren Schnittstellen angezeigt. Ebenso die Anzahl der Verbindungen über INTERNALLINKS ist an den Schnittstellen ablesbar. 10 Engineering-Werkzeug zur funktionsorientierten Planung 144

Auf zwei Fähigkeiten des Editors wird detailliert eingegangen: „Änderungen umsetzen“ und „Delta-Vergleich“.

10.1.2 Fähigkeit: Änderungen umsetzen Mit Hilfe dieser Fähigkeit ist es möglich, Änderungen, die man an einem Template vorgenommen hat, auf alle Instanzen zu übertragen, die von diesem Template abgeleitet wurden. Dabei hat der Nutzer die Auswahl, auf welche Instanzen er diese Änderungen übertragen möchte. Dies kann beispielsweise genutzt werden, wenn ein Fehler in einem Template erkannt wird. Dieser kann korrigiert werden und über die beschriebene Funktion auf alle Instanzen übertragen werden, ohne dies händisch an jeder Instanz ändern zu müssen.

10.1.3 Fähigkeit: Deltavergleich unterschiedlicher Planungsstände Der Deltavergleich ermöglicht es, zwei Dateien mit unterschiedlichen Planungsständen miteinander zu vergleichen. Dabei werden gelöschte, neu hinzugefügte, bewegte und veränderte Objekte erkannt. Abbildung 10-2 gibt einen Überblick über die Bedienoberfläche der Vergleichsfähigkeit.

Abbildung 10-2: Delta-Vergleich von zwei Planungsständen Die einzelnen Änderungen, die durch diese Fähigkeit erkannt werden, werden kurz dargestellt:

1. Gelöschte Objekte können INTERNALELEMENTS, ROLECLASSES oder SYSTEMUNITCLASSES sein. 2. Neue Objekte können INTERNALELEMENTS, ROLECLASSES, SYSTEMUNITCLASSES, INTERFACES und INTERNALLINKS sein. 3. Werden INTERNALELEMENTS innerhalb der INSTANCEHIERARCHY verschoben, so wird das durch den Delta-Vergleich erkannt. Dies geschieht über die Auswertung der Eltern- Elemente des jeweiligen INTERNALELEMENTS. 4. Änderungen können an Namen, Attributen und Attribut-Werten der INTERNALELEMENTS und der SYSTEMUNITCLASSES und deren INTERFACES erkannt werden. Ebenso werden Änderungen an INTERNALLINKS erkannt. Für jede erkannte Änderung hat der Nutzer die Möglichkeit, eine Auswahl zu treffen, ob diese erkannte Änderung im Planungsdokument übernommen werden soll. Dazu kann er die Check-Box vor der angezeigten Änderung in dem Programmfenster des Delta-Vergleiches anwählen, siehe dazu Abbildung 10-2.

10 Engineering-Werkzeug zur funktionsorientierten Planung 145

10.2 Visualisierung der Prozessbeschreibung Zur bildlichen Darstellung der Inhalte aus der AutomationML-Datei, die das Systemmodell enthält, wurde eine prototypische Anwendung erstellt. Diese ist in der Lage, vor allem das Funktionsmodell grafisch darzustellen. Dies ist notwendig, um die teilweise sehr komplexen Strukturen innerhalb des Funktionsmodells mit seinen zahlreichen Verbindungen für den Nutzer handhabbar zu machen. Abbildung 10-3 zeigt ein Beispiel einer einfachen Darstellung eines Prozessschrittes mit den zugeordneten Produkten und der dazu gehörenden Technischen Ressource.

Abbildung 10-3: Programm zur Visualisierung der Inhalte einer AutomationML-Datei Zur Ausführung der Visualisierung werden in diesem Fall den unterschiedlichen Rollen der Elemente aus dem Funktionsmodell entsprechende Symbole zugewiesen. In dem gezeigten Beispiel wurden den jeweiligen Rollen folgende Symbole, konform zur [VDI/VDE 3682-1], zugewiesen: • Ressource: graues Langrund, • Produkt: roter Kreis, • Prozess: grünes Rechteck. Das Programm ist so konzipiert, dass die Zuweisung der Symbole sowohl über Klassen als auch über Rollen möglich ist. Auch eine gemischte Darstellung ist möglich, wobei der Nutzer hier entscheiden kann, ob Rollen vor Klassen oder Klassen vor Rollen ausgewählt werden sollen. Dies ist beispielsweise nutzbar, wenn es für Produkte einer bestimmten Rolle eine Detaillierung in Form von Klassen gibt. Dann kann der Nutzer die Visualisierungsmethode „Klassen vor Rollen“ auswählen und bekommt für Produkte, für deren Klasse ein Symbol zugeordnet wurde, dieses Symbol angezeigt. Für Produkte ohne Klassenzuordnung oder ohne Symbol für die Klasse wird das Symbol der Rolle ausgewählt und angezeigt. 10 Engineering-Werkzeug zur funktionsorientierten Planung 146

Einmal zugeordnete Symbole zu Klassen oder Rollen können in einem Visualisierungsschema gespeichert und entsprechend wieder verwendet werden. In Abbildung 10-4 ist ein Beispiel zu sehen, wie die Inhalte eines Funktionsmodells nach Ihren Klassen visualisiert werden können. Neben der allgemeinen Darstellung der FPB, wie in Abbildung 10-3 nach den Rollen, ist eine Darstellung auch nach den Klassen der Elemente möglich. Dazu wurde den Elementen ein spezifisches Symbol der entsprechenden Klasse zugeordnet.

Abbildung 10-4: Visualisierung nach Klassen Beispielsweise wurde der Ressource A ein Symbol der Klasse Ressource A zugeordnet. Mit den hier dargestellten Fähigkeiten des Visualisierungsprogramms können aus der Funktionsbeschreibung direkt bebilderte Handhabungsanweisungen für die Montagemitarbeiter oder Fügefolgen erstellt werden. Voraussetzung dafür ist das Vorhandensein einer Bibliothek mit Rollen und Klassen und entsprechenden Symbolen für diese.

10.3 Zusammenfassung Das vorgestellte Werkzeug stellt Funktionalitäten für eine funktionsorientierte Bearbeitung von Engineering-Daten bereit. Damit lässt sich an dieser Stelle die Forschungsfrage 7 beantworten:

7. Wie können das Systemmodell und die Bibliotheken im gewählten Datenformat Werkzeug-gestützt dargestellt und bearbeitet werden?

Das im vorliegenden Kapitel beschriebene Engineering-Werkzeug unterstützt das vorgestellte Systemmodell und ermöglicht eine grafische Bearbeitung der darin enthaltenen Informationen. Dabei wird das Datenaustauschformat AutomationML unterstützt. Das 10 Engineering-Werkzeug zur funktionsorientierten Planung 147

Werkzeug soll als prototypische Anwendung verstanden werden, die aufzeigt, welche Funktionalitäten im Zusammenhang mit der funktionsorientierten Planung sinnvoll und realisierbar sind. Für eine Schnittstellenprogrammierung an den entsprechenden im funktionsorientierten Engineering beteiligten Werkzeugen kann das vorgestellte Werkzeug als Anhalt genutzt werden.

11 Zusammenfassung und Ausblick 148

11 Zusammenfassung und Ausblick Die vorliegende Arbeit stellt ein funktionsorientiertes Modellierungskonzept in der fertigungstechnischen Planung vor, das Ansätze verschiedener Domänen kombiniert, um die Herausforderungen des Engineerings in Hinblick auf die zunehmende Digitalisierung zu adressieren. Dieses Konzept wurde im Rahmen der vorliegenden Arbeit evaluiert und auf unterschiedlichen Konferenzen und Workshops diskutiert. Das vorliegende Kapitel schließt die Arbeit mit einer Zusammenfassung des Erreichten und dem Aufzeigen möglicher zukünftiger Forschungsfragen ab.

11.1 Zusammenfassung Die in der Einleitung der vorliegenden Arbeit genannten Einflussfaktoren zur Optimierung des Engineerings fertigungstechnischer Produktionssysteme wurden detailliert analysiert. Aus den einzelnen Ansätzen, die zur Optimierung eines jeden Einflussfaktors existieren, wurden die erfolgversprechendsten durch eigene Entwicklungen ergänzt und in einem Ansatz kombiniert. Durch dieses Vorgehen konnten die aus den Einflussfaktoren abgeleiteten Forschungsfragen in den jeweiligen Kapiteln beantwortet werden. Der in der vorliegenden Arbeit vorgestellte Ansatz kann einen Beitrag zur Lösung der Herausforderungen im Engineering leisten. Bei der Analyse bestehender Ansätze fand eine Betrachtung über die Domänengrenzen hinweg statt, indem die Themen des funktionsorientierten Engineerings in der Prozessindustrie und der Gebäudeautomation untersucht wurden. Dazu wurde in der vorliegenden Arbeit das Engineering von Produktionssystemen und dessen Phasen detailliert betrachtet, um abzuleiten, wer im Engineering-Workflow welche Daten erstellt und austauscht. Die betrachteten Engineering-Workflows wurden verglichen und ein allgemeiner, für diese Arbeit gültiger Engineering-Workflow definiert. Bei der Analyse der Kommunikation in und zwischen den beteiligten Planern der unterschiedlichen Gewerke wurde eine Gewerke-übergreifende Kommunikationsgrundlage in der Maschinenfunktion gefunden. Eine detailliertere Betrachtung von funktionsorientierten Ansätzen im Engineering war daher notwendig, um den Stand der Forschung darzulegen und bereits etablierte Modellierungsansätze für die eigene Modellierung zu finden. Dabei wurden auch andere Ansätze untersucht, die aktuell im Fokus bei der Entwicklung von Industrie 4.0- Anwendungen stehen, wie die Modularisierung und die Serviceorientierung. Den Kern des anschließend entworfenen Modells zur Beschreibung des Produktionssystems stellt die Maschinenfunktion dar. Dieses Modell wurde um die Aspekte Struktur und Verhalten erweitert. Somit liegt ein dreiteiliges Systemmodell vor, dessen Teilmodelle sich stark miteinander verknüpfen lassen, um die im Engineering erzeugten Informationen zu strukturieren, zu interpretieren und sie zwischen den Gewerken auszutauschen. Für die Abbildung der Teilmodelle wurden etablierte Standards genutzt, wie die Formalisierte Prozessbeschreibung, Beschreibungsmittel für die SPS-Programmierung und hierarchische Strukturen. Es wurde ein Konzept vorgestellt, wie das Systemmodell im Engineering schrittweise aufgebaut und von den Gewerken genutzt werden kann. Für den Austausch wurden unterschiedliche Datenformate untersucht und das geeignetste für den vorliegenden Ansatz ausgewählt. Das Systemmodell wurde dementsprechend in AutomationML abgebildet. Dabei erfolgte eine detaillierte Abgrenzung zu bereits existierenden Ansätzen. Die Nutzung des Systemmodells wurde anschließend an zwei Praxisbeispielen erklärt und deren Nutzen beschrieben und mit den entstehenden Aufwänden verglichen. Für eine optimale Nutzung des vorgestellten Systemmodells wurde zudem ein Ansatz vorgestellt, wie firmeneigene Bibliotheken erstellt werden, die das Engineering unterstützen können. Diese 11 Zusammenfassung und Ausblick 149

Bibliotheken enthalten Funktionen und Komponenten, die sich im Engineering bestehender Produktionssysteme bereits etabliert haben. Auch dieses Vorgehen wurde an einem Praxisbeispiel erläutert. Zum Abschluss der vorliegenden Arbeit wurde ein prototypisches Engineering-Werkzeug vorgestellt, welches die beiden vorgestellten Ansätze umfassend unterstützt. Dieses stellt umfangreiche Funktionalitäten zur Verfügung, um die ausgewählten Beschreibungsmittel dazustellen und im gewählten Datenformat abzubilden. Die erzeugten Ergebnisse werden entsprechend der Einleitung in Kapitel 1 nach dem BMW-Prinzip [SCH99] gruppiert und zusammengefasst. Methode: Es wurde in der vorliegenden Arbeit ein systematisches Vorgehen zur Modellerstellung eines fertigungstechnischen Produktionssystems beschrieben. Der damit verbundene Engineering-Workflow orientiert sich dabei an Standards und bereits etablierten Ansätzen. Das im Mittelpunkt der Modellierung stehende Systemmodell wurde systematisch entwickelt. Es stellt mit seiner funktionsorientierten Sichtweise ein Kommunikationsmittel für alle Gewerke dar. Der Aufbau des Modells bedient sich unterschiedlicher Teilmodelle, die neben der Funktion die Struktur und das Verhalten des Produktionssystems abbilden. Eine intensive Verbindung zwischen den Teilmodellen sorgt im Engineering-Workflow für einen Zugewinn an Informationen. Für eine Integration des Modells in bestehende Workflows wurde zudem ein Ansatz entwickelt, der Bibliotheken für das Engineering erzeugt. Dazu werden die bestehenden Daten aus dem Systemmodell genutzt. Der Aufbau der Bibliotheken orientiert sich ebenso an dem Systemmodell und seinen Teilmodellen. Dadurch können Lösungen aus den Kategorien Funktion, Struktur und Verhalten bereitgestellt werden. Auch eine Kombination innerhalb eines Templates ist möglich. Beschreibungsmittel: Das entwickelte Systemmodell mit seinen drei Teilmodellen wurde durch unterschiedliche Beschreibungsmittel abgebildet. Das Funktionsmodell wurde mit Hilfe der Formalisierten Prozessbeschreibung dargestellt, da die FPB eine neutrale, formalisierte und standardisierte Prozessdarstellung mit einem übersichtlichen Satz an Symbolen ermöglicht. Für die Abbildung des Strukturmodells wurden unterschiedliche Ansätze kombiniert, um hierarchische Anordnungen von Elementen eines Systems abzubilden. Dabei wurde eine Unterteilung der Strukturelemente in Funktionseinheiten vorgenommen. Diese lassen sich gemäß dem entwickelten Strukturmodell in Komponenten zerlegen. Sie repräsentieren die elementaren Bestandteile des Systems und können als Kauf- oder Konstruktionsteile auftreten. Für die Abbildung des Verhaltensmodells wurde auf PLCopen XML zurückgegriffen, da es damit möglich ist, sowohl einfache Variablenlisten als auch komplexe Programmcodes herstellerneutral und rechnerinterpretierbar abzubilden. Für den rechnergestützten Austausch des Systemmodells wurde das Datenformat AutomationML gewählt. Durch sein Bibliothekskonzept unterstützt es den entworfenen Ansatz optimal. An insgesamt drei Praxisbeispielen konnte die Nutzung des Systemmodells und die Bibliothekserstellung vorgestellt und erprobt werden. Werkzeug: Zur Unterstützung der entwickelten Methoden und der Nutzung der Beschreibungsmittel wurde ein prototypisches Werkzeug entworfen. Dieses stellt als prototypische Anwendung die Nutzungsmöglichkeiten des Modells anschaulich dar und kann den Programmierern von Schnittstellen in Engineering-Werkzeugen ein Anhalt sein. Das Funktionsmodell wird in der Anwendung grafisch dargestellt. Weitere Funktionalitäten zur Unterstützung des Engineering-Workflows beim Arbeiten mit dem Systemmodell, wie der Delta-Vergleich zum Abgleich zweier unterschiedlicher Versionsstände eines Projektes, wurden integriert. Zudem sind Funktionalitäten zur Unterstützung der Bibliothekserstellung 11 Zusammenfassung und Ausblick 150 und zur Instanziierung der Bibliothekselemente integriert, wie beispielsweise das Durchführen von Änderungen an allen Instanzen einer bestimmten Klasse. Das Engineering- Werkzeug arbeitet dabei vollständig auf einem AutomationML-Datenmodell. Das Systemmodell mit seinen Teilmodellen und den damit verknüpften Dateien liegt somit im rechnerinterpretierbaren Datenaustauschformat AutomationML vor und kann von anderen Beteiligten im Engineering gelesen und weiter bearbeitet werden. Die Ergebnisse der vorliegenden Arbeit wurden durch den Autor in das Verbundprojekt „SemAnz4.0 – Semantische Allianz für Industrie 4.0“ eingebracht. In diesem Zusammenhang wurden Teile der Ergebnisse national und international veröffentlicht, begutachtet und diskutiert vgl. [HHS+16*; SHF+17A*; SHF17B*; HSF+17A*; HSF+17B*; SHW+17*; FDD+18*]. Das in der vorliegenden Arbeit entwickelte Modellierungsvorgehen ist an zwei Praxisbeispielen unterschiedlicher industrieller Partner angewandt und evaluiert worden. Dabei wurde das Verfahren der Modellerstellung auf bestehende Systeme angewandt. Es konnten somit erfolgreich digitale Modelle der unterschiedlichen Produktionssysteme erstellt werden, ein wesentlicher Schritt, um Industrie 4.0 auch in Bestandssysteme zu etablieren. Eine begleitende Anwendung im Engineering von neu geplanten Systemen konnte aus unterschiedlichen, zeitlichen wie organisatorischen Gründen nicht durchgeführt werden. Da das Vorgehen zur Modellerstellung aus den unterschiedlichen Engineering-Vorgehen für neu zu errichtende Produktionssysteme abgeleitet wurde, ist von einer erfolgreichen Anwendung des beschriebenen Verfahrens auszugehen. Durch den vorgestellten Ansatz der Bibliothekserstellung aus bestehenden Produktionssystemen finden die erstellten Bibliothekselemente Einzug auch in neue Produktionssysteme und deren Engineering. Damit sich ein neues Vorgehen im Engineering etablieren kann, müssen die Vorteile den Mehraufwand aufwiegen. Dies gilt sowohl für den vorgestellten Ansatz der Modellerstellung als auch für die Erstellung und Nutzung der Bibliothekselemente. Um den Aufwand für die Bearbeiter der Modelle so gering wie möglich zu halten, muss sich die Modellerstellung in den bisherigen Workflow integrieren lassen. Im Falle des Funktionsmodells heißt das, die Erstellung sollte sich aus vorhandenen Daten automatisiert oder zumindest teilautomatisiert mit Unterstützung des Planers ableiten lassen. An dieser Stelle wäre es notwendig, die vorhandenen Daten aus der Anforderungserhebung rechnerinterpretierbar vorliegen zu haben. Eine Integration des vorgestellten Systemmodells wäre so in der Schnittstelle des dafür genutzten Werkzeuges notwendig. Die dafür erforderlichen Funktionalitäten wurden in der vorliegenden Arbeit an Hand des Engineering-Werkzeuges vorgestellt. Existiert ein solches Werkzeug bisher in der Engineering-Organisation nicht, so ist dessen Einführung mit Mehraufwand in Form von Zeit und Kosten verbunden. Dieser Mehraufwand muss im Laufe des Engineerings zurückgewonnen werden, entweder durch eine schnellere Durchführung des Engineerings oder durch eine Reduzierung der Kosten durch weniger Werkzeuge oder Mitarbeiter. Das sich die Modellierung des Systems im Engineering lohnt, zeigen die vielseitigen Einsatzmöglichkeiten eines solchen Produkt- und Systemmodells, die in den @ Industrie 4.0-Anwendungszenarien, vgl. [PLA16 ], detailliert beschrieben sind.

11 Zusammenfassung und Ausblick 151

11.2 Ausblick In der vorliegenden Arbeit wurde ein Konzept zur Modellierung von Produktionssystemen vorgestellt, um das Engineering an seinen Einflussfaktoren zu optimieren und den Herausforderungen der Modellerstellung von Industrie 4.0 zu begegnen. Dies stellt nur einen kleinen Teil der Lösung für die genannten Herausforderungen dar. Unterteilt nach dem BMW-Prinzip werden im vorliegenden Ausblick die möglichen weiteren Forschungsthemen zur Erweiterung des vorliegenden Ansatzes angesprochen. Methode: Die vorliegende Methode zur Modellerstellung orientiert sich vollständig an dem Engineering von neu geplanten Produktionssystemen. Ihre Wirksamkeit wurde am Re- Engineering von bestehenden Systemen untersucht. Daraus ließen sich zudem Bibliothekselemente für das Engineering von neuen Systemen erstellen. Für eine Etablierung der Methode im Engineering von Neuanlagen sind Erweiterungen der Modelle hinsichtlich firmenspezifischer Inhalte notwendig. Das vorgestellte Modell kann das durch seine unabhängigen, aber stark verknüpften Teilmodelle leisten. Eine Integration des ungesteuerten Verhaltens eines Produktionssystems ist an dieser Stelle als weiteres Teilmodell neben dem gesteuerten Verhalten vorstellbar. Dieses weitere Teilmodell zur Abbildung des Verhaltens kann im Engineering schrittweise aufgebaut und durch Bibliothekselemente unterstützt werden. Das dadurch entstehende Systemmodell kann dann für die virtuelle Inbetriebnahme genutzt werden. Beschreibungsmittel: Das vorgestellte Systemmodell wurde zum Einsatz in der Praxis im Datenaustauschformat AutomationML abgebildet. Für die Abbildung des Systemmodells ist eine Normung in AutomationML anzustreben, um die gemeinsame Nutzung auch firmenübergreifend sicherzustellen. Dazu kann als erster Schritt die Abbildung des Funktionsmodells in Form einer „Best Practice Recommendations“ für AutomationML erstellt @ werden, vgl. [AUT14 ]. Das Vorgehen der Modellerstellung ist jedoch unabhängig vom eingesetzten Datenformat. Hier wären auch andere Formate vorstellbar, wenn sich diese in den bestehenden Engineering-Workflow der jeweiligen Engineering-Organisation integrieren lassen. Werkzeug: Allgemein ist für die vorgestellten Methoden eine umfassende Werkzeugunterstützung notwendig. Die Daten für das Systemmodell und seine Teilmodelle müssen rechnerinterpretierbar vorliegen, um sie effizient im Engineering-Workflow nutzen zu können. Hier können zahlreiche weitere Forschungen ansetzen, um die Verfügbarkeit digitaler Abbilder von Produkten, Komponenten und der Integration der Daten in die entsprechenden Engineering-Werkzeuge sicher zu stellen. Eine Nutzung von neutralen Darstellungsformen der Daten, wie UML, zu deren Beschreibung und eine Verwendung von neutralen XML-basierten Austauschformaten scheint hier erfolgsversprechend. Die Offenheit der Engineering-Werkzeuge sollte zu diesem Zweck verbessert werden, um Schnittstellen zwischen den unterschiedlichen Werkzeugen nutzen zu können. Für das vorgestellte Engineering-Werkzeug sind weitere Funktionalitäten zur Optimierung der Darstellung der FPB, verschiedene hierarchische Ansichten, auch in Kombination mit dem Struktur- und Verhaltensmodell denkbar.

Anhang A: Ergebnisse aus dem Beispielprojekt 1 152

Anhang A: Ergebnisse aus dem Beispielprojekt 1

Grundprint HMI-Print

Hilfsmittel Handhaben M1 21

Aus Tray gelöster Grundprint

Platzieren M1 22

In Vorrichtung eingelegter Grundprint

Aufnehmen & Platzieren Betätigen M1 23 M1 24

In Vorrichtung In Vorrichtung gesicherter eingelegter Grundprint HMI-Print Vorrichtung Modul 1

Betätigen M1 25 Betätigen M1 26

Grundprint zum In Vorrichtung HMI-Print gesicherter geführt HMI-Print

Bewegungs- zyklus Lötkolben Verlöten M1 27

Verlötete Print-BG In Vorrichtung

Betätigen M1 28

Print-BG in gelöster Vorrichtung

Aufnehmen & Übergabeplatz Platzieren Modul 1 &Modul 2 M1 29

Print-BG

Abbildung A-1: Detaillierung der Prozessschritte des Modul 1 , Level 2 Anhang A: Ergebnisse aus dem Beispielprojekt 1 153

Grundprint HMI-Print

Teilen M1 31 Halten M1 38

Aus Tray HMI-Print gelöster Grundprint gegriffen

Positionieren Halten M1 32 M1 39

Grundprint Positionierter In Hand HMI-Print

Drehen um Längsachse M1 33 Lösen M1 310

In Vorrichtung Gedrehter eingelegter Grundprint HMI-Print

Positionieren M1 34 Führen M1 311

In Vorrichtung Positionierter gesicherter Grundprint HMI-Print

Lösen M1 35

In Vorrichtung eingelegter Grundprint

Niederhalter Führen M1 36

In Vorrichtung gesicherter Grundprint Printaufnahme HMI-Print

Printaufnahme Grundprint Führen M1 37

Grundprint zum HMI-Print geführt Hebel HMI-Halterung

Lötkolben Fügen M1 312

Verlötete Print-BG In Vorrichtung

Führen M1 313

Print-BG in gelöster Vorrichtung

Halten M1 314

entnommene Print-BG

Übergabeplatz Positionieren Modul 1 & Modul 2 M1 315

Print-BG BG korrekt übergeben positioniert (LED leuchtet)

Lösen M1 316

Übergebene Print-BG an Modul 2

Abbildung A-2: weitere Detaillierung der Prozessschritte, Level 3 Anhang B: Ergebnisse aus dem Beispielprojekt 2 154

Anhang B: Ergebnisse aus dem Beispielprojekt 2

E_G_zu P_St_lose P_G_lose I_Variante B_Gesamtsystem

O_Gehaeu_zu T_F&M G

E_St_zu P_G_fix

P_Nest

O_Stift_ein T_F&M St

E_P_LPS P_LPS

O_QS T_P_LPS

P_LPS_Ausschuss P_LPS_gut P_G_fehlerhaft

Abbildung B-1: Detaillierung des Prozesses „Gehäuse zuführen“, Level 2

Anhang B: Ergebnisse aus dem Beispielprojekt 2 155

E_G_zu P_G_lose P_Nest I_Variante B_Gehaeu_zu

O_G_foerdern T_MK_Foerdertopf

P_G_aufgereiht

O_G_zufuehren T_MK_Zufuehrung

P_G_positioniert

I_Blockbreite

O_G_einsetzen T_MK_Pick&Place

O_Fehler_Block T_MK_Funkt_Sich

P_G_fehlerhaft P_G_fix

Abbildung B-2: Detaillierung des Prozesses „Gehäuse zuführen“, Level 2 Anhang B: Ergebnisse aus dem Beispielprojekt 2 156

P_G_positioniert I_Blockbreite I_Variante P_Nest B_G_einsetzen

O_G greifen T_A_Festo Picker

O_N oeffnen T_MK_Nestoeffner

P_G in Greifer P_N offen

O_G in N setzen T_A_Festo Picker

P_G lose in N

O_N schließen T_MK_Nestoeffner

P_G_fix

Abbildung B-3: Detaillierung des Prozesses „Gehäuse einsetzen“, Level 3

Literaturverzeichnis 157

Literaturverzeichnis

Literatur Dieses Verzeichnis enthält eine Liste der referenzierten Quellen, die nicht vom Autor stammen. Die Quellen sind mittels [] gekennzeichnet. [ABH+10] R. Angerbauer, Buck, Raphael, Doll, Ulrich, M. Hackel, K.-H. Kayser: Aquimo: Adaptierbares Modellierungswerkzeug und Qualifizierungsprogramm für den Aufbau firmenspezifischer mechatronischer Engineeringprozesse. Frankfurt: VDMA-Verlag, 2010.

[ABRE11] E. Abele, G. Reinhart: Zukunft der Produktion: Herausforderungen, Forschungsfelder, Chancen. München: Carl Hanser Fachbuchverlag, 2011.

[AHSP09] W. Ahrens, G.-U. Spohr: CAE-Systeme für die Planung verfahrenstechnischer und leittechnischer Anlagen. In: Handbuch der Prozessautomatisierung: Prozessleittechnik für verfahrenstechnische Anlagen. 4., überarb. Aufl. München: Oldenbourg Verlag, 2009.

[AKI94] K. Akiyama: Funktionenanalyse: Der Schlüssel zu erfolgreichen Produkten und Dienstleistungen. Landsberg/Lech: Verlag Moderne Industrie, 1994. [ASM+15] Aurich, Steimer, Meissner, Menck: Einfluss von Industrie 4.0 auf die Fabrikplanung: Auswirkungen der besonderen Charakteristika cybertronischer Produktionssysteme auf die Fabrikplanung. wt Werkstattstechnik online, Vol. 105 (4), 2015, S. 190–194. [ASP+15] A. Anis, W. Schäfer, A. Pines, O. Niggemann: CP³L: A Cyber-Physical Production Planning Language. In: International Conference on Emerging Technologies and Factory Automation (ETFA). Luxembourg, 2015.

[BAKU16] M. Bartelt, B. Kuhlenkötter (Hrsg.): Conexing Abschlussbericht: Werkzeug zur interdisziplinären Planung und produktbezogenen virtuellen Optimierung von automatisierten Produktionssystemen. Bochum: Bochumer Universitätsverlag Westdeutscher Universitätsverlag (Maschinenbau, 10), 2016. [BBL+16] L. Berardinelli, S. Biffl, A. Lüder, E. Mätzler, T. Mayerhofer, M. Wimmer, S. Wolny: Cross-disciplinary engineering with AutomationML and SysML. at - Automatisierungstechnik, Vol. 64 (4), 2016, S. 253–269. [BBM+15] L. Berardinelli, S. Biffl, M. Maetzler, T. Mayerhofer, M. Wimmer: Model-Based Co-Evolution of Production Systems and their Libraries with AutomationML. In: International Conference on Emerging Technologies and Factory Automation (ETFA). Luxembourg, 2015.

[BER05] M. Bergholz: Objektorientierte Fabrikplanung. Aachen, RWTH Aachen. Dissertation, 2005.

[BLE11] C. Blees: Eine Methode zur Entwicklung modularer Produktfamilien. Hamburg, Technische Universität Hamburg-Harburg. Dissertation, 2011.

[BLFR15] R. Bleich, K.F. Früh: Handbuch der Prozessautomatisierung: Prozessleittechnik für verfahrenstechnische Anlagen. 5., komplett überarb. Aufl. München: DIV, 2015. Literaturverzeichnis 158

[BMM12] S. Biffl, R. Mordinyi, T. Moser: Integriertes Engineering mit Automation Service Bus: Paralleles Engineering mit heterogenen Werkzeugen. atp-edition: Automatisierungstechnische Praxis (12), 2012, S. 888–895. [BMQ+10] D. Behnen, H. Mersch, C. Quix, D. Schmitz, M. Zhang, K. Fayzullin, C. Brecher, U. Epple, M. Jarke: Gemeinsamkeiten und Unterschiede in der Modellierung von prozesstechnischen und diskreten Produktionsanlagen. In: Entwurf komplexer Automatisierungssysteme (EKA). Magdeburg, 2010. [BMS+17] S. Biffl, R. Mordinyi, H. Steininger, D. Winkler: Integrationsplattform für anlagenmodellorientiertes Engineering - Bedarfe und Lösungsansätze. In: Handbuch Industrie 4.0. 2., erweiterte und bearbeitete Auflage. Berlin: Springer, 2017. [BMW+15] S. Biffl, M. Maetzler, M. Wimmer, A. Lüder, N. Schmidt: Linking and Versioning Support for AutomationML: A Model-Driven Engineering Perspective. In: International Conference on Emerging Technologies and Factory Automation (ETFA). Luxembourg, 2015.

[BOLA12] R. Bokranz, K. Landau: Handbuch Industrial Engineering: Produktivitätsmanagement mit MTM. 2., überarb. und erw. Aufl. Stuttgart: Schäffer-Poeschel, 2012.

[BUN17] Bundesministerium für Arbeit und Soziales: Weißbuch Arbeiten 4.0, 2017. [BYA+15] T. Beyer, R. Yousefifar, S. Abele, M. Bordasch, P. Göhner, K.-H. Wehking: Flexible Agent-based Planning and Adaption of Material Handling Systems. In: 11th IEEE Conference on Automation Science and Engineering. Gothenburg, 2015. [CHF14] L. Christiansen, M. Hoernicke, A. Fay: Modellgestütztes Engineering: Basis für die Automatisierung der Automatisierung. atp-edition: Automatisierungstechnische Praxis, Vol. 56 (3), 2014, S. 18–27.

[CZU10] W. Czuchra: UML in logistischen Prozessen: Graphische Sprache zur Modellierung der Systeme. 1. Aufl. Wiesbaden: Vieweg + Teubner, 2010. [DBK+15] R. Dumitrescu, C. Bremer, A. Kühn, A. Trächtler, T. Frieben: Model-based development of products, processes and production resources: A state- oriented approach for an integrated system model of objects, processes and systems. at - Automatisierungstechnik, Vol. 63 (10), 2015. [DHT17] C. Diedrich, T. Hadlich, M. Thron: Semantik durch Merkmale in Industrie 4.0. In: Handbuch Industrie 4.0. 2., erweiterte und bearbeitete Auflage. Berlin: Springer, S. 417–432, 2017. [DME+14] C. Diedrich, M. Meyer, L. Evertz, W. Schäfer: Dienste in der Automatisierungstechnik. atp-edition: Automatisierungstechnische Praxis, Vol. 56 (12), 2014, S. 24–35.

[DRA08] R. Drath: Die Zukunft des Engineering: Herausforderungen an das Engineering von fertigungs- und verfahrenstechnischen Anlagen. In: Karlsruher leittechnisches Kolloquium. Karlsruhe, 2008. Literaturverzeichnis 159

[DRA10] R. Drath: Datenaustausch in der Anlagenplanung mit AutomationML: Integration von CAEX, PLCopen XML und COLLADA. Heidelberg, New York: Springer Verlag, 2010 (VDI-Buch).

[DRA13] R. Drath: Warum ein Engineering-Weltmodell bisher nicht gelang: Serie AutomationML Teil 19: Austausch von Daten zwischen unterschiedlichen Datenmodellen im heterogenen Werkzeugumfeld. SPS-Magazin (10), 2013, S. 55–57. [DSH11] R. Drath, B. Schröter, M. Hoernicke: Datenkonsistenz im Umfeld heterogener Engineering-Werkzeuge. In: Automationskongress. Baden-Baden, 2011.

[EHR07] K. Ehrlenspiel: Integrierte Produktentwicklung: Denkabläufe, Methodeneinsatz, Zusammenarbeit. 3., aktualis. Aufl. München [u.a.]: Hanser Verlag, 2007.

[EPP11] U. Epple: Merkmale als Grundlage der Interoperabilität technischer Systeme. at - Automatisierungstechnik (7), 2011.

[ERI98] G. Erixon: Modular function deployment: A method for product modularisation. Stockholm, 1998 (TRITA-MSM, 98,1).

[EVE12] W. Eversheim: Simultaneous Engineering: Erfahrungen aus der Industrie für die Industrie: Springer Verlag, 2012. [FAL+15] B. Ferrer, B. Ahmad, A. Lobov, D. Vera, J. Lastra, R. Harrison: An approach for knowledge-driven product, process and resource mappings for assembly automation. In: 11th IEEE Conference on Automation Science and Engineering. Gothenburg, 2015. [FDB+12] A. Fay, R. Drath, M. Barth, F. Zimmer, K. Eckert: Bewertung der Fähigkeit von Engineering-Werkzeugen zur Interoperabilität mit Hilfe einer Offenheitsmetrik. In: Automationskongress. Baden-Baden, 2012.

[FEGR12] Feldhusen, Grote (Hrsg.): Pahl/Beitz Konstruktionslehre: Methoden und Anwendung erfolgreicher Produktentwicklung: Springer Verlag, 2012. [FFV13] D. Friedrich, S. Feldmann, B. Vogel-Heuser: Modularisierung und Wiederverwendung in der Elektroplanung. In: Engineering von der Anforderung bis zum Betrieb. Kassel: Kassel Univ. Press (Embedded systems 1, Tagungen und Berichte, 3), 2013.

[FRA02] H.-J. Franke: Variantenmanagement in der Einzel- und Kleinserienfertigung: Mit 33 Tabellen. München [u.a.]: Hanser Verlag, 2002. [FUF+09] M. Felleisen, A. Ulrich, A. Fay, U. Enste, B. Polke: Formalisierte Prozessbeschreibung in der praktischen Anwendung: 2. Teil: Nutzen der Prozessbeschreibung nach VDI/VDE-Richtlinie 3682. atp-edition: Automatisierungstechnische Praxis, Vol. 51 (10/11), 2009, S. 52–57. [GCD15] J. Gausemeier, A.M. Czaja, C. Dülme: Innovationspotentiale auf dem Weg zu Industrie 4.0. In: Wissenschafts- und Industrieforum Intelligente Technische Systeme, Vol. 343, 2015.

[GEH05] M. Gehrke: Entwurf mechatronischer Systeme auf Basis von Funktionshierarchien und Systemstrukturen. Paderborn, Universität Paderborn, Institut für Informatik. Univ., Dissertation, 2005. Literaturverzeichnis 160

[GEI13] A. Geipel-Kern: Interview mit Prof. Dr. Leon Urbas: Standards im Engineering - Wann kommt der Durchbruch? PROCESS, 2013. [GTS13] J. Gausemeier, A. Trächtler, W. Schäfer: Semantische Technologien im Entwurf mechatronischer Systeme: Effektiver Austausch von Lösungswissen in Branchenwertschöpfungsketten. München: Hanser Verlag, 2013 (Hanser eLibrary). [GWQ+16] D. Gorecky, S. Weyer, F. Quint, M. Köster: Definition einer Systemarchitektur für Industrie 4.0-Produktionsanlagen. In: Automationskongress. Baden-Baden, 2016.

[HAD15] T. Hadlich: Verwendung von Merkmalen im Engineering von Systemen. Magdeburg, Otto von Guericke Universität. Dissertation, 2015.

[HADI14] T. Hadlich, C. Diedrich: Verwendung von Merkmalen für die funktionale Modellierung: Merkmale in frühen Phasen des Systems-Engineering. In: Automationskongress. Baden-Baden, 2014.

[HÄDR14] H. Hämmerle, R. Drath: AutomationML im Praxiseinsatz: Erfahrungen bei der virtuellen Inbetriebnahme. In: AutomationML Anwenderkonferenz: Tagungsband der 3. Tagung. Blomberg, 2014. [HDL10] D. Hellenbrand, C. Daniilidis, U. Lindemann: Integrierte funktionsorientierte Produkt- und Prozessmodellierung mechatronischer Produkte. In: 7. Paderborner Workshop - Entwurf mechatronischer Systeme. Paderborn, 2010.

[HEE05] M. Heeg: Ein Beitrag zur Modellierung von Merkmalen im Umfeld der Prozessleittechnik. Aachen, Techn. Hochsch., Dissertation, 2005.

[HEL13] D. Hellenbrand: Transdisziplinäre Planung und Synchronisation mechatronischer Produktentwicklungsprozesse. München, Dissertation, 2013. [HHH15] T. Helbig, S. Henning, J. Hoos: Efficient engineering in special purpose machinery through automated control code sythesis based on a functional categorisation. In: Machine Learning for cyber physical Systems: ML4CPS. Lemgo, 2015. [HLO+14] F. Himmler, H. Loy, V. Ostapovski, M. Amberg: Function Based Engineering - A Standardization Framework for the Plant Engineering Domain. In: Multikonferenz Wirtschaftsinformatik. Paderborn, 2014. [HNO+14] S. Henning, O. Niggemann, J. Otto, S. Schriegel: A Describtive Engineering Approach for Cyber-Physical Systems. In: International Conference on Emerging Technologies and Factory Automation (ETFA). Barcelona (Spain), 2014.

[HOL16] T. Holm: Aufwandsbewertung im Engineering modularer Prozessanlagen. Hamburg, Helmut-Schmidt Universität / Universität der Bundeswehr Hamburg. Dissertation, 2016. [HSM+01] J. Hirtz, R.B. Stone, D.A. Mcadams, S. Szykman, K.L. Wood: A functional basis for engineering design: Reconciling and evolving previous efforts. Research in engineering design: theory, applications, and concurrent engineering, Vol. 13 (2), 2001, S. 65–82. Literaturverzeichnis 161

[HUM11] B. Hummel: Integrated behavior modeling of space-intensive mechatronic systems. München, Technische Universität München. Dissertation, 2011. [HWH14] T. Helbig, E. Westkamper, J. Hoos: Identifying automation components in modular manufacturing systems: A method for modeling dependencies of manufacturing systems. In: International Conference on Emerging Technologies and Factory Automation (ETFA). Barcelona (Spain), S. 1–8, 2014.

[JAN10] K. Janschek: Systementwurf mechatronischer Systeme: Methoden - Modelle - Konzepte. Berlin, Heidelberg: Springer Verlag, 2010.

[JASM05] F. Jammes, H. Smit: Service-Oriented Paradigms in Industrial Automation. IEEE Transactions on Industrial Informatics, Vol. 1 (1), 2005. [JCS+12] T. Jäger, L. Christiansen, M. Strube, A. Fay: Durchgängige Werkzeugunterstützung von der Anforderungserhebung mittels formalisierter Prozessbeschreibung und AutomationML. In: Entwurf komplexer Automatisierungssysteme (EKA). Magdeburg, 2012.

[KEC11] C. Kecher: UML 2.3: Das umfassende Handbuch. 4., erw. Ausg. Bonn: Galileo Press, 2011 (Galileo Computing).

[KIE07] J. Kiefer: Mechatronikorientierte Planung automatisierter Fertigungszellen im Bereich Karosserierohbau. Saarbrücken. Dissertation, 2007.

[KÜH10] C. Kühnl: Einfach wettbewerbsfähiger durch mechatronische Konzepte. etz elektrotechnik & automation, Vol. 2010 (7), 2010, S. 2–4.

[LEN13] Lenze Antriebstechnik: Engineering-Effizienz für Antriebs- und Automatisierungslösungen. automation.at (Sonderausgabe 2013/2014), 2013, S. 17–21. [LFH+11] A. Lüder, M. Foehr, L. Hundt, M. Hoffmann, Y. Langer, S. Frank: Aggregation of engineering processes regarding the mechatronic approach. In: International Conference on Emerging Technologies and Factory Automation (ETFA). Toulouse, France, S. 1–8, 2011. [LMF15] Y. Lu, K.C. Morris, S. Frechette: Standards Landscape and Directions for Smart Manufacturing Systems. In: 11th IEEE Conference on Automation Science and Engineering. Gothenburg, 2015.

[LOS13] M. Loskyll: Entwicklung einer Methodik zur dynamischen kontextbasierten Orchestrierung semantischer Feldgerätefunktionalitäten. Kaiserslautern: Techn. Univ, Dissertation, 2013 (Fortschritt-Berichte pak Kontextadaptive Automatisierung, 25).

[LÜD14] A. Lüder: Semantikdefinition durch die Integration von Klassifikationssystemen in Entwurfsdaten zum verlustfreien Datenaustausch in Werkzeugketten: Vortrag im VDI Wissensforum 2014. In: Automationskongress. Baden-Baden, 2014.

[MAH14] C. Mahler: Automatisierungsmodule für ein funktionsorientiertes Automatisierungsengineering. Hamburg, Helmut-Schmidt Universität / Universität der Bundeswehr Hamburg. Dissertation, 2014. Literaturverzeichnis 162

[MDL+14] C. Messinger, R. Drath, N. Li, B. Schröter, G. Gutermuth: Ansatz zur Messung von Engineering-Effizienz in der Automatisierungsplanung. In: Automationskongress. Baden-Baden, 2014. [MEP15] MEPROMA: MEPROMA: Anforderungen und Methoden im mechatronischen Engineering. Frankfurt am Main: VDMA-Verlag, 2015.

[MER11] M. Mertens: Verwaltung und Verarbeitung merkmalbasierter Informationen: vom Metamodell zur technologischen Realisierung. Aachen, Rheinisch- Westfälische Technische Hochschule. Dissertation, 2011. [NHR+08] P. Nyhuis, T. Heinen, G. Reinhart, C. Rimpau, E. Abele, A. Wörn: Wandlungsfähige Produktionssysteme: Theoretischer Hintergrund zur Wandlungsfähigkeit von Produktionssystemen. wt Werkstattstechnik online, Vol. 98 (1/2), 2008, S. 85–90.

[PAT82] G. Patzak: Systemtechnik - Planung komplexer innovativer Systeme: Grundlagen, Methoden, Techniken. Berlin, Heidelberg: Springer Verlag, 1982.

[POEP94] M. Polke, U. Epple: Prozessleittechnik: Mit 8 Tabellen. 2., völlig überarb. und stark erw. Aufl. München, Wien: Oldenbourg, 1994.

[PUN17] P. Puntel Schmidt: Methode zur simulationsbasierten Absicherung von Steuerungscode fertigungstechnischer Anlagen. Hamburg, Helmut-Schmidt Universität / Universität der Bundeswehr Hamburg. Dissertation, 2017.

[REU13] A. Reuter: Definition eines mechatronischen Informationsmodells zur Modellierung von Automatisierungskomponenten und Maschinen. Stuttgart, Universität Stuttgart. Dissertation, 2013.

[RIE17] M. Riedel: Ein Beitrag zur wissensbasierten Unterstützung bei der Auswahl technischer Ressourcen: Repräsentation und Auswertung von Prinziplösungen auf Basis multidimensionaler, heterogener, vernetzter Merkmalräume. Hamburg, Helmut-Schmidt Universität / Universität der Bundeswehr Hamburg. Dissertation, 2017.

[ROT14] K. Roth: Konstruieren mit Konstruktionskatalogen: Band 1: Konstruktionslehre. 3., Aufl. 2000. Softcover reprint of the original 3rd ed. 2000. Berlin: Springer Berlin, 2014. [SBL+17] A. Schüller, M. Brendelberger, F. Li, C. Temmen, P. Zgorzelski: Durchgängiges PLT-Engineering: Die Interaktion von Datenmodellen im PLT- Engineering. atp-edition: Automatisierungstechnische Praxis, Vol. 59 (10), 2017. [SBV17] A. Schlag, T. Bär, M. Vielhaber: Generische Anforderungserstellung für automatisierte Fertigungs- und Montageanlagen mittels formalisierter Prozessbeschreibung für einen höheren Reifegrad im Anlagenentwicklungsprozess. In: Automationskongress. Baden-Baden, 2017.

[SCGO16] D. Schulz, T. Goldschmidt: Industrie 4.0 Dienstearchitektur: Semantische Interoperabilität in Industrie 4.0 Dienstesystemen. In: Automationskongress. Baden-Baden, 2016.

[SCH12] T. Scherwietes: Neues CAE/PLS-Interface vereinfacht den Austausch von Automatisierungsdaten: Namur-Arbeitskreis entwickelt Standard-Schnittstelle Literaturverzeichnis 163

für den bidirektionalen Datentransfer. atp-edition: Automatisierungstechnische Praxis (1-2), 2012, S. 24–26.

[SCH16] S. Schröck: Interdisziplinäre Wiederverwendung im Engineering automatisierter Anlagen: Anforderungen, Konzept und Umsetzung für die Prozessindustrie. Hamburg, Helmut-Schmidt Universität / Universität der Bundeswehr Hamburg. Dissertation, 2016.

[SCH99] E. Schnieder: Methoden der Automatisierung: Beschreibungsmittel, Modellkonzepte und Werkzeuge für Automatisierungssysteme. Braunschweig, Wiesbaden: Vieweg, 1999 (Studium Technik). [SGK08] G. Schuh, S. Gottschalk, D. Kupke: Individualisierte Produktion: Flexible Konfigurationslogik zur Gestaltung von integrativen Produktionssystemen. wt Werkstattstechnik online, Vol. 98 (4), 2008, S. 286–290. [SLS+14] N. Schmidt, A. Lüder, H. Steininger, S. Biffl: Analyzing requirements on software tools according to the functional engineering phase in the technical systems engineering process. In: International Conference on Emerging Technologies and Factory Automation (ETFA). Barcelona (Spain), S. 1–8, 2014. [SPS+14] M. Schleipen, J. Pfrommer, D. Stogl, B. Hein, K. Aleksandrov, S.E. Navarro, J. Beyerer: AutomationML to describe skills of production plants based on the PPR concept. In: AutomationML Anwenderkonferenz: Tagungsband der 3. Tagung. Blomberg, 2014. [SRS99] S. Szykman, J. Racz, R. Sriram: The Representation of Function in computer- based Design. In: ASME Design Engineering Technical Conference. Las Vegas, USA, 1999. [SSE08] St. Schmitz, M. Schlütter, U. Epple: R&I – Grundlage durchgängigen Engineerings. In: Automationskongress. Baden-Baden, 2008. [SSG+08] L. Sá de Souza, P. Spiess, D. Guinard, M. Köhler, S. Karnouskos, D. Savio: SOCRADES: A Web Service based Shop Floor Integration Infrastructure. In: The Internet of Things: First International Conference. Zurich, Switzerland, 2008.

[STR14] M. Strube: Modellgestützte Modernisierungsplanung industrieller Automatisierungslösungen. Hamburg, Helmut-Schmidt Universität / Universität der Bundeswehr Hamburg. Dissertation, 2014.

[TAU13] T. Tauchnitz: Integriertes Engineering - wann, wenn nicht jetzt!: Notwendigkeit, Anforderungen und Ansätze. atp-edition: Automatisierungstechnische Praxis (1-2), 2013, S. 46–53.

[TAU14] T. Tauchnitz: Schnittstellen für das integrierte Engineering: Wege zu einer schnellen Realisierung. atp-edition: Automatisierungstechnische Praxis, Vol. 56 (1), 2014, S. 30–36.

[ULR09] A. Ulrich: Entwicklungsmethodik für die Planung verfahrenstechnischer Anlagen. Hamburg, Helmut-Schmidt Universität / Universität der Bundeswehr Hamburg. Dissertation, 2009. Literaturverzeichnis 164

[VDMC14] VDMA, McKinsey: Zukunftsperspektive deutscher Maschinenbau: Erfolgreich in einem dynamischen Umfeld agieren, 2014. [WDF+14] M. Weyrich, C. Diedrich, A. Fay, M. Wollschlaeger, S. Kowalewski, P. Göhner, B. Vogel-Heuser: Industrie 4.0 am Beispiel einer Verbundanlage. atp-edition: Automatisierungstechnische Praxis, Vol. 56 (7), 2014, S. 52–61. [WDH14] A. Wallnöfer, R. Drath, F. Hüning: Was ist Funktionales Engineering?: Einordnung, Definition, Randbedingungen. In: Automationskongress. Baden- Baden, 2014. [ZHR+16] Zawisza, Hell, Röpke, A. Lüder, Schmidt: Generische Strukturierung von Produktionssystemen der Fertigungsindustrie. In: Automationskongress. Baden-Baden, 2016.

Literaturverzeichnis 165

Normen, Richtlinien und Empfehlungen Dieses Verzeichnis enthält eine Liste der referenzierten Normen, Richtlinien und Empfehlungen. Die Quellen sind mittels [ ] gekennzeichnet. [DIN 19226-6] DIN 19226-6. Regelungstechnik und Steuerungstechnik - Teil 6: Begriffe zu Funktions- und Baueinheiten, 1997. [DIN 8580] DIN 8580. Fertigungsverfahren, 2003.

[DIN EN 61360-1] DIN EN 61360-1. Genormte Datenelementtypen mit Klassifikationsschema für elektrische Bauteile - Teil 1: Definitionen – Regeln und Methoden, 2008. [DIN EN 61360-4] DIN EN 61360-4. Genormte Datenelementtypen mit Klassifikationsschema für elektrische Bauteile - Teil 4: IEC Nachschlagewerk für genormte Datenelementtypen, Bauteilklassen und Terme, 2005.

[DIN EN 61512-1] DIN EN 61512-1. Chargenorientierte Fahrweise - Teil 1: Modelle und Terminologie, 2000. [DIN EN 62264-1] DIN EN 62264-1. Integration von Unternehmensführungs- und Leitsystemen - Teil 1: Modelle und Terminologie, 2008. [DIN EN 62424] DIN EN 62424. Festlegung für die Darstellung von Aufgaben der Prozessleittechnik in Fließbildern und für den Datenaustausch zwischen EDV-Werkzeugen zur Fließbilderstellung und CAE- Systemen, 2008. [DIN EN 62714-1] DIN EN 62714-1. Datenaustauschformate für Planungsdaten industrieller Automatisierungssysteme - Automation markup language - Teil 1: Architektur und allgemeine Festlegungen, 2015. [DIN EN 62714-2] DIN EN 62714-2. Datenaustauschformate für Planungsdaten industrieller Automatisierungssysteme - Automation markup language - Teil 2: Rollenbibliotheken, 2015. [DIN EN 62714-3] DIN EN 62714-3. Datenaustauschformate für Planungsdaten industrieller Automatisierungssysteme - Automation markup language - Teil 3: Geometrie und Kinematik, 2016.

[DIN EN ISO 10628-1] DIN EN ISO 10628-1. Schemata für die chemische und petrochemische Industrie - Teil 1: Spezifikation der Schemata, 2015.

[DIN EN ISO 10628-2] DIN EN ISO 10628-2. Schemata für die chemische und petrochemische Industrie - Teil 2: Graphische Symbole, 2015. [DIN IEC 61987-11] DIN IEC 61987-11. Industrielle Leittechnik – Datenstrukturen und - elemente in Katalogen der Prozessleittechnik – Teil 11: Merkmalleisten für Messgeräte für elektronischen Datenaustausch – Allgemeine Strukturen, 2010. [DIN SPEC 91345] DIN SPEC 91345. Referenzarchitekturmodell Industrie 4.0 (RAMI4.0), 2016. Literaturverzeichnis 166

[IEC 61131-3] IEC 61131-3. Programmable controllers – Part 3: Programming languages, 2013. [IEC 61499-1] IEC 61499-1. Funktionsbausteine für industrielle Leitsysteme - Teil 1: Architektur, 2003. [IEC 62390] IEC 62390. Leitfaden für Geräteprofile in der Automatisierungstechnik, 2006. [IEC 63832] IEC 63832. Digital Factory, 2014. [NA 35] NA 35. Abwicklung von PLT-Projekten, 2003. [NE 150] NE 150. Standardisierte NAMUR-Schnittstelle zum Austausch von Engineering-Daten zwischen CAE-System und PCS-Engineering- Werkzeugen, 2014. [NE 159] NE 159. Standardisierte NAMUR-Schnittstelle für den Datenaustausch zwischen CAE-Systemen der Verfahrensauslegung und der PLT-Hardware-Planung, 2018. [PAS 1059] PAS 1059. Planung einer verfahrenstechnischen Anlage, 2006. [VDI 2206] VDI 2206. Entwicklungsmethodik für mechatronische Systeme, 2004. [VDI 2221] VDI 2221. Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte, 1993. [VDI 2222-1] VDI 2222-1. Konstruktionsmethodik - Blatt 1: Methodisches Entwickeln von Lösungsprinzipien, 1997. [VDI 2222-2] VDI 2222-2. Konstruktionsmethodik - Blatt 2: Erstellung und Anwendung von Konstruktionskatalogen, 1982. [VDI 2223] VDI 2223. Methodisches Entwerfen technischer Produkte, 2004. [VDI 2815-2] VDI 2815-2. Begriffe für die Produktionsplanung und -steuerung - Material, Erzeugnis, Handelsware, 1978. [VDI 2860] VDI 2860. Montage- und Handhabungstechniken, 1990. [VDI 3813-2] VDI 3813-2. Gebäudeautomation (GA) Grundlagen der Raumautomation - Blatt 2: Raumautomationsfunktionen, 2011. [VDI 4499-1] VDI 4499-1. Digitale Fabrik - Blatt 1: Grundlagen, 2008. [VDI 5200-1] VDI 5200-1. Fabrikplanung -Blatt 1: Planungsvorgehen, 2011. [VDI/VDE 3682-1] VDI/VDE 3682-1. Formalisierte Prozessbeschreibung - Blatt 1: Konzept und grafische Darstellung, 2015. [VDI/VDE 3682-2] VDI/VDE 3682-2. Formalisierte Prozessbeschreibung - Blatt 2: Informationsmodell, 2015. [VDI/VDE 3695-1] VDI/VDE 3695-1. Engineering von Anlagen - Evaluieren und optimieren des Engineerings - Blatt 1: Grundlagen und Vorgehensweise, 2010. [VDI/VDE 3695-3] VDI/VDE 3695-3. Engineering von Anlagen - Evaluieren und optimieren des Engineerings - Blatt 3: Methoden, 2010. Literaturverzeichnis 167

Veröffentlichungen des Autors Dieses Verzeichnis enthält eine Liste der Veröffentlichungen des Verfassers, die mittels [*] gekennzeichnet sind. [DTB+15*] R. Drath, T. Tauchnitz, P. Bigvand, A. Schüller, A. Scholz: Datenaustausch mit dem Namur-Container: Ein neuer Weg der agilen Standardisierung am Beispiel der PLT-Stelle. In: Automationskongress. Baden-Baden, 2015. [FDD+18*] A. Fay, C. Diedrich, M. Dubovy, C. Eck, C. Hildebrandt, A. Scholz, T. Schröder, R. Wiegand: Abschlussbericht - SemAnz40: Vorhandene Standards als semantische Basis für die Anwendung von Industrie 4.0, Hamburg. 2018. [FDT+15*] A. Fay, C. Diedrich, M. Thron, A. Scholz, P. Puntel Schmidt, J. Ladiges, T. Holm: Wie bekommt Industrie 4.0 Bedeutung?: Normen und Standards als semantische Basis. atp-edition: Automatisierungstechnische Praxis (07-08), 2015. [GDS+16*] M. Günther, P. Diekhake, A. Scholz, P. Puntel Schmidt, U. Becker, A. Fay: Durchgängiges modellbasiertes Engineering von Gebäudeautomations- systemen. at - Automatisierungstechnik, Vol. 64 (6), 2016, S. 490–499. [GSP+16*] M. Günther, A. Scholz, P. Puntel Schmidt, A. Fay, P. Diekhake, D. Diaz, U. Becker: Anforderungserhebung und-modellierung in der Gebäudeautomation. In: Entwurf komplexer Automatisierungssysteme (EKA). Magdeburg, 2016. [HHS+16*] C. Hildebrandt, X.-L. Hoang, A. Scholz, A. Fay, A. Schreiber, O. Graeser: Modellierung von Aufträgen und Produktionsressourcen in flexibilisierten Produktionsumgebungen. In: Automationskongress. Baden-Baden, 2016.

[HSF+17A*] C. Hildebrandt, A. Scholz, A. Fay, M. Dubovy, T. Schröder, T. Hadlich, C. Diedrich, C. Eck, R. Wiegand: Semantic Modeling for Collaboration and Cooperation of Systems in the production domain. In: International Conference on Emerging Technologies and Factory Automation (ETFA). Limassol, 2017.

[HSF+17B*] C. Hildebrandt, A. Scholz, A. Fay, T. Hadlich, C. Diedrich, M. Dubovy, C. Eck, R. Wiegand: Semantische Allianz 4.0: Semantische Inhalte für Industrie 4.0. In: Automationskongress. Baden-Baden, 2017.

[SHF+17A*] A. Scholz, C. Hildebrandt, A. Fay, T. Schröder, C. Diedrich, M. Dubovy, C. Eck, R. Wiegand, R. Heidel: Semantische Inhalte für Industrie 4.0: Modellierung technischer Systeme in kollaborativen Umgebungen. atp-edition: Automatisierungstechnische Praxis, Vol. 59 (7/8), 2017, S. 34–43.

[SHF17B*] A. Scholz, C. Hildebrandt, A. Fay: Functional Modelling in Production Engineering Workflows. In: 13th IEEE Conference on Automation Science and Engineering. Xi‘an, China, 2017. [SHW+17*] A. Scholz, C. Hildebrandt, C. Wentzien, T. Mathes, A. Fay: Modellierung von Fertigungsfunktionen bringt Industrie 4.0 in Bestandsanlagen. In: Automationskongress. Baden-Baden, 2017. [SST+15*] A. Schüller, A. Scholz, T. Tauchnitz, R. Drath, T. Scherwietes: Speed- Standardisierung am Beispiel der PLT-Stelle: Datenaustausch mit dem Namur- Datencontainer. atp-edition: Automatisierungstechnische Praxis (1-2), 2015, S. 36–46. Literaturverzeichnis 168

Studentische Arbeiten Dieses Verzeichnis enthält eine Liste der studentischen Arbeiten, die vom Autor betreut wurden. Die Quellen sind mittels [%] gekennzeichnet.

% [HIL15 ] C. Hildebrandt: Modellierung von fertigungstechnische Produktionsprozessen. Hamburg, Helmut-Schmidt Universität / Universität der Bundeswehr Hamburg. Projektseminararbeit, 2015.

% [HIL16 ] C. Hildebrandt: Modellierung des dynamischen Kontexts flexibler Produktionsressourcen: Anforderungen und Bewertung bestehender Lösungen. Hamburg, HWI Hamburg. Masterarbeit, 2016.

% [WEN17 ] C. Wentzien: Analyse und Modellierung von Fertigungsfunktionen einer modularen fertigungstechnischen Anlage. Hamburg, HWI Hamburg. Masterarbeit, 2017.

Literaturverzeichnis 169

Referenzierte Internetquellen Dieses Verzeichnis enthält eine Liste der referenzierten Internetquellen. Die Quellen sind mittels [@] gekennzeichnet.

@ [AUT14 ] AutomationML e.V.: Best Practice Recommendations: Constraints with regular expressions in AutomationML. https://www.automationml.org/o.red/uploads/dateien/1417688745- BPR_001E_Constraint_RegEx_Oct2014.pdf [Abruf: 2018-04-30].

@ [AUT17A ] AutomationML e.V.: AutomationML Engine. https://www.automationml.org/o.red.c/dateien.html [Abruf: 2018-04-30].

@ [AUT17B ] AutomationML e.V.: Whitepaper AutomationNML: Part 4: AutomationML Logic. https://www.automationml.org/o.red.c/dateien.html [Abruf: 2018-04-30].

@ [AUT17C ] AutomationML e.V.: AutomationML Editor. https://www.automationml.org/o.red.c/dateien.html [Abruf: 2018-04-30]. [BPM17@] BPMN: Web-based tooling for BPMN, DMN and CMMN.: bpmn-js. http://bpmn.io/toolkit/bpmn-js/ [Abruf: 2018-04-30].

@ [CAM17 ] Camunda: Free BPMN 2.0 Tool. https://camunda.org/bpmn/tool/ [Abruf: 2018-04-30].

@ [CHSC15 ] A. Christ; R. Schäfer: Mechatronischer Ansatz für die Automatisierung. http://www.maschinenmarkt.vogel.de/mechatronischer-ansatz-fuer-die- automatisierung-a-476282/ [Abruf: 2018-04-30].

@ [DAT18 ] Datenschutzbeauftragter-info.de: Definition und Unterscheidung der Begriffe Daten, Informationen & Wissen. https://www.datenschutzbeauftragter- info.de/definition-und-unterscheidung-der-begriffe-daten-informationen-wissen/ [Abruf: 2018-05-05]. [DEX17@] DEXPI: Data Exchange in Process Industry. http://www.dexpi.org [Abruf: 2018-04-30].

@ [ECL17 ] eCl@ss e.V.: eCl@ss. http://www.eclass.eu/eclasscontent/index.html.de [Abruf: 2018-04-30]. [DIN18@] DIN: über Normen und Standards. https://www.din.de/de/ueber-normen-und- standards/basiswissen [Abruf: 2018-05-05]. [EPL17@] EPLAN Software & Service GmbH & Co. KG: EPLAN - efficent engineering. https://www.eplan.de [Abruf: 2018-04-30].

@ [GRA17 ] Graphical Development Process assistent: Funktionseinheit. http://www.informatik.uni-bremen.de/gdpa/def-d/def_f/Funktionseinheit.htm [Abruf: 2018-04-30].

@ [GRÖ13 ] M. Gröpper: Engineering: Datenaustausch Mechanik - Elektrik - Software. http://www.3ds.com/fileadmin/EVENTS/3DEXPERIENCE-Customer- FORUMS/Germany/Presentation/2013-3DEXPERIENCE-VDMA- Gr%C3%B6pper.pdf [Abruf: 2018-04-30].

@ [ITW17 ] ITwissen: Metamodell. http://www.itwissen.info/Metamodell-meta-model.html [Abruf: 2018-04-30]. Literaturverzeichnis 170

@ [LEN16 ] Lenze Antriebstechnik: Lösungen erarbeiten. http://www.lenze.com/fileadmin/lenze/documents/de/flyer/13510720_Broschuer e_Loesungen_erarbeiten_de-DE.pdf [Abruf: 2018-04-30].

@ [MEI13 ] Meinrad Happacher: Nachgehakt bei Claus Kühnl: Die Lage ist niederschmetternd! http://www.computer-automation.de/unternehmensebene/ produktionssoftware/artikel/104077/ [Abruf: 2018-04-30]. [OMG16@] OMG: Objekt Management Group. http://www.omg.org/spec/BPMN/ [Abruf: 2018-04-30]. [OMG17@] OMG: SysML. http://www.omgsysml.org [Abruf: 2018-04-30].

@ [PLA16 ] Plattform Industrie 4.0: Ergebnispapier: Fortschreibung der Anwendungsszenarien der Plattform Industrie 4.0. http://www.plattform- i40.de/I40/Redaktion/DE/Downloads/Publikation/fortschreibung- anwendungsszenarien.pdf?__blob=publicationFile&v=5 [Abruf: 2018-04-30]. [PLC16@] PLCopen: PLCOpen - motion control: Part 1 - Basics. http://www.plcopen.org/pages/tc2_motion_control/part_1_2/index.htm [Abruf: 2018-04-30]. [PLC17@] PLCopen: PLCopen XML. http://www.plcopen.org/pages/tc6_xml/ [Abruf: 2018-04-30]. [PNM17@] PNML: PetrinetML. http://www.pnml.org [Abruf: 2018-04-30].

@ [RUL17 ] RuleML: RuleML. http://wiki.ruleml.org/index.php/RuleML_Home [Abruf: 2018-04-30].

@ [SCLÜ15 ] N. Schmidt; A. Lüder: AutomationML in a Nutshell. www.automationml.org [Abruf: 2018-04-30]. [VDI15@] VDI/VDE: Statusreport: Referenzarchitekturmodell Industrie 4.0 (RAMI4.0). https://www.vdi.de/fileadmin/user_upload/VDI-GMA_Statusreport_ Referenzarchitekturmodell-Industrie40.pdf [Abruf: 2018-04-30]. [VDI16@] VDI/VDE: Statusreport: Fortentwicklung des Referenzmodells für die Industrie 4.0-Komponente: Struktur der Verwaltungsschale. https://www.vdi.de/fileadmin/vdi_de/redakteur_dateien/gma_dateien/6146_PUB _GMA_ZVEI_Statusreport_-_RAMI_4-0_Struktur_der_Verwaltungsschale_ Internet.pdf [Abruf: 2018-04-30].

@ [VIS10 ] Visio: Microsoft Visio. https://products.office.com/de-de/visio/flowchart-software [Abruf: 2018-05-06]. [W3C17@] W3C: W3C Math Home - MathML. https://www.w3.org/Math/ [Abruf: 2018-04-30].

@ [WIK17A ] Wikipedia: Business Process Model and Notation. https://de.wikipedia.org/wiki/ Business_Process_Model_and_Notation [Abruf: 2018-04-30].

@ [WIK17B ] Wikipedia: Gewerk. https://de.wikipedia.org/wiki/Gewerk [Abruf: 2018-04-30].

@ [WIR17 ] Wirtschaftslexikon: Produkt. http://www.wirtschaftslexikon24.com/d/produkt/produkt.htm [Abruf: 2018-04-30]. [WSC17@] WSCAD GmbH: WSCAD - Electrical Engineering. http://www.wscad.com/electrical-engineering/ [Abruf: 2018-04-30]. Lebenslauf 171

Lebenslauf

Persönliche Daten Name: André Scholz Geburtsdaten: 25. September 1982 in Radebeul

Berufserfahrung 04/2018 – jetzt Siemens AG, Nürnberg Entwicklungsingenieur

07/2013 – 12/2017 Helmut-Schmidt-Universität / Universität der Bundeswehr, Hamburg Wissenschaftlicher Mitarbeiter

07/2001 – 06/2013 Bundeswehr, Deutschland Offizier in der Logistiktruppe des Heeres

Ausbildung 10/2004 – 03/2008 Helmut-Schmidt-Universität / Universität der Bundeswehr, Hamburg Studium des Maschinenbaus Abschluss: Diplom-Ingenieur Thema der Diplomarbeit: Ein wissensbasiertes System zur automatischen Auswahl von SPS-Funktions-Makros der Gebäudeautomation anhand von R&I-Fließbildern

09/1989 – 06/2001 Bergstadt-Gymnasium Altenberg, Altenberg Abschluss: Abitur