Entwicklung einer Referenzarchitektur zur Realisierung von Methoden der Lean Production mittels digitaler Technologien

Doktorarbeit / Dissertation , 2018 , 200 Seiten , Note: summa cum laude

Ingenieurwissenschaften - Maschinenbau

Ziel der vorliegenden Arbeit ist die Erarbeitung einheitlicher informationstechnischer Schnittstellen für die Lean Production. Die erarbeitete Referenzarchitektur definiert technologieunabhängige Schnittstellen und schafft den notwendigen Rahmen für die Nutzung digitaler Technologien in bestehenden Lean-Methoden. Bestandteil der Referenzarchitektur ist eine Systemarchitektur, die Rollen und deren Verhältnisse beschreibt. Ergänzt wird sie durch ein Informationsmodell, das die je Rolle benötigten Funktionalitäten und die ausgetauschten Nachrichten spezifiziert, sowie durch eine Softwarearchitektur für die Umsetzung der Schnittstellen. Die Referenzarchitektur wurde auf einen bestehenden Forschungsdemonstrator der Technologie-Initiative SmartFactory KL e.V. exemplarisch übertragen.

Spätestens seit den 1990ern bildet die Lean Production den Status quo der Produktionssysteme in der diskreten Klein- und Großserienfertigung. Mittels der Umstellung auf eine nachfrageorientierte Produktion und Vermeidung jeglicher nicht-wertschöpfender Aktivitäten konnte die Lean Production bei geringen Investitionen hohe Effizienzsteigerungen erreichen. Heute stößt die Lean Production allerdings an ihre Grenzen, da sie nicht das Potenzial moderner Informations- und Kommunikationstechnologie berücksichtigt. Der Lean Production mangelt es u.a. an der notwendigen Wandelbarkeit der Fertigungslinien, um zukünftige Anforderungen wie z.B. eine kundenindividuelle Fertigung in Losgröße 1 zu ermöglichen.

Die stattfindende Digitalisierung der Produktion will diesen zukünftigen Produktionsanforderungen gerecht werden. Neue digitale Technologien sowie die gestiegene Leistung der Komponenten ermöglichen eine intelligente Produktion, die Mitarbeiter in komplexen Produktionsprozessen unterstützt. Der gleichzeitig stattfindende Preisverfall und die Miniaturisierung in der Informations- und Kommunikationstechnologie führen auch in der Produktion zu allgegenwärtigen, vernetzten Computern. Das Potenzial dieser technologischen Entwicklung ist unumstritten, dennoch mangelt es aktuell an einer übergreifenden und ganzheitlichen Betrachtung, die eine Integration der Digitalisierung und der neuen Anwendungen in bestehende Produktionsumgebungen miteinbezieht.

Inhalt

1. Einleitung

2. Stand der Technik
2.1 Digitalisierung in der Produktion
2.1.1 Begriffsabgrenzung und Paradigmen
2.1.2 Dezentrale Architekturen fur die Produktionssteuerung
2.1.3 Informationstechnische Schnittstellen und Kommunikation
2.1.4 Informationsmodelle und -modellierung
2.1.5 Bewertung des Status quo
2.2 Lean Production
2.2.1 Begriffsabgrenzung und historische Entwicklung
2.2.2 Gestaltungsprinzipien und Methoden
2.2.3 Lean Automation
2.2.4 Bewertung des Status quo

3. Problemstellung, Zielsetzung und Vorgehensweise
3.1 Problemstellung
3.2 Zielsetzung
3.3 Vorgehensweise

4. Referenzarchitektur zur Digitalisierung der Lean Production
4.1 Methodik zur Entwicklung der Referenzarchitektur
4.1.1 Prinzipien der Methodik
4.1.2 Schritt 1: Lean-Methoden sammeln und bewerten
4.1.3 Schritt 2: Anforderungen analysieren
4.1.4 Schritt 3: Systemarchitektur und Informationsmodell entwickeln
4.1.5 Schritt 4: Schnittstellenarchitektur entwickeln
4.2 Bewertung, Modellierung und Anforderungskatalog der Lean-Methoden
4.2.1 Bewertung und Auswahl von Lean-Methoden
4.2.2 Modellierung der ausgewahlten Lean-Methoden
4.2.3 Funktionale Anforderungen des Anforderungskataloges
4.2.4 Nicht-funktionale Anforderungen des Anforderungskataloges
4.3 Bestandteile der Referenzarchitektur
4.3.1 Systemarchitektur
4.3.2 Informationsmodell der Schnittstelle
4.3.3 Schnittstellenarchitektur

5. Prototypische Realisierung der Referenzarchitektur
5.1 Anwendungsszenarien und Rahmenbedingungen
5.2 Technische Realisierung

6. Bewertung und Ausblick
6.1 Zusammenfassende Bewertung
6.2 Ausblick auf weiteren Forschungs- und Entwicklungsbedarf

7. Zusammenfassung

8. Literaturverzeichnis

Anhang A-Anwendungsfalle der Lean-Methoden

Anhang B - Aktivitatsdiagramme der Lean-Methoden

Anhang C- Kommunikationsdiagramme der Lean-Methoden

Anhang D - Liste der funktionalen Anforderungen

Anhang E - Spezifikation der je Rolle anzubietenden Funktionalitaten

Anhang F - Spezifikation der Nachrichten

Liste der betreuten studentischen Arbeiten

Lebenslauf

Vorwort des Verfassers

Schon wahrend meines Studiums faszinierte mich nicht nur die Einfachheit und Effizienz der Lean Production, sondern auch die Vision und das Potential des Internets der Dinge bzw. spater Industrie 4.0. Die vorliegende Dissertation ist die Vertiefung und Umsetzung einer von mir jahrelang verfolgten Idee, beide Themen miteinander sinnvoll zu verbinden. Sie entstand wahrend meiner Tatigkeit als wissenschaftlicher Mitarbeiter im Forschungsbereich Innovative Fabriksysteme (IFS) am Deutschen Forschungszentrum fur Kunstliche Intelligenz (DFKI) sowie bei der Technologie-lnitiative SmartFactory KL e.V.

Fur die Betreuung der Arbeit mochte ich mich besonders bei Herrn Professor Zuhlke bedan- ken, der fruh das Potential erkannte, welches sich durch die Verbindung der im ersten Mo­ment nicht offensichtlich zusammengehorenden Bereiche ergibt. Er und Herr Professor Ruskowski, bei welchem ich mich ebenfalls besonders bedanken mochte, pragten durch die Ubertragung von Projekt- und Fuhrungsverantwortung maligeblich meine fachliche und per- sonliche Entwicklung wahrend der Zeit.

Bei Herrn Professor Thoben mochte ich mich fur die Anfertigung des Drittgutachtens und fur die Betreuung meiner Masterarbeit seinerzeit bedanken, durch welche ich die Grundidee fur diese Dissertation bekam. Selbstverstandlich gilt mein Dank auch Herrn Professor Teutsch fur die Ubernahme des Vorsitzes der Prufungskommission.

Bedanken mochte ich mich bei alien Freunden und Kollegen am IFS und in der SmartFacto- ry-KL fur die vorbildliche Zusammenarbeit und das positive Arbeitsklima auch in arbeitsinten- siven Phasen. Erwahnen mochte ich dabei insbesondere Max Birtel, Ellina Marseu, Dr. Mari­us Orfgen, Dr. Mathias Schmitt, Michael Wendling, Dr. Stephan Weyer und Dr. Fabian Quint, die mit Humor, Hilfsbereitschaft und Teamgeist den Arbeitsalltag und die Arbeit an der Pro­motion erleichterten. Auch gilt mein Dank den Studenten Joshua Knobloch und Eric Jeder- mann, die mich bei der Realisierung der Demonstration tatkraftig unterstutzten.

Zuletzt mochte ich meiner Familie und insbesondere meinen Eltern danken, die mich nicht nur in fruhen Jahren pragten, sondern in den letzten Jahren fur die Dissertation oft auf mich verzichten mussten. Mein allergro&ter Dank jedoch gilt meiner Ehefrau Ekaterina Kolberg, die fur meine Dissertation nicht nur personliche Interessen zuruckstellte, sondern mir taglich den Rucken freihielt und mich in schwierigen Zeiten motivierte. Ihre Unterstutzung trug mali- geblich zum Gelingen der Arbeit bei.

Hamburg, im Juni 2018

Kurzfassung

Spatestens seit den 1990ern bildet die Lean Production den Status quo der Produktionssys- teme in der diskreten Klein- und GroIJserienfertigung. Mittels der Umstellung auf eine nach- frageorientierte Produktion und Vermeidung jeglicher nicht-wertschopfender Aktivitaten konn- te die Lean Production bei geringen Investitionen hohe Effizienzsteigerungen erreichen. Heu- te stolit die Lean Production allerdings an ihre Grenzen, da sie nicht das Potenzial moderner Informations- und Kommunikationstechnologie berucksichtigt. Der Lean Production mangelt es u.a. an der notwendigen Wandelbarkeit der Fertigungslinien, um zukunftige Anforderun- gen wie z.B. eine kundenindividuelle Fertigung in LosgroRe 1 zu ermoglichen.

Die stattfindende Digitalisierung der Produktion will diesen zukunftigen Produktionsanforde- rungen gerecht werden. Neue digitale Technologien sowie die gestiegene Leistung der Komponenten ermoglichen eine intelligente Produktion, die Mitarbeiter in komplexen Produk- tionsprozessen unterstutzt. Der gleichzeitig stattfindende Preisverfall und die Miniaturisierung in der Informations- und Kommunikationstechnologie fuhren auch in der Produktion zu allge- genwartigen, vernetzten Computern. Das Potenzial dieser technologischen Entwicklung ist unumstritten, dennoch mangelt es aktuell an einer ubergreifenden und ganzheitlichen Be- trachtung, die eine Integration der Digitalisierung und der neuen Anwendungen in bestehen- de Produktionsumgebungen miteinbezieht.

Ziel der vorliegenden Arbeit ist die Erarbeitung einheitlicher informationstechnischer Schnitt- stellen fur die Lean Production. Die erarbeitete Referenzarchitektur definiert technologieun- abhangige Schnittstellen und schafft den notwendigen Rahmen fur die Nutzung digitaler Technologien in bestehenden Lean-Methoden. Bestandteil der Referenzarchitektur ist eine Systemarchitektur, die Rollen und deren Verhaltnisse beschreibt. Erganzt wird sie durch ein Informationsmodell, das die je Rolle benotigten Funktionalitaten und die ausgetauschten Nachrichten spezifiziert, sowie durch eine Softwarearchitektur fur die Umsetzung der Schnittstellen. Die Referenzarchitektur wurde auf einen bestehenden Forschungsdemonstra- tor der Technologie-lnitiative SmartFactory KL e.V. exemplarisch ubertragen.

Abstract

Since the 1990s there is no doubt that Lean Production is the state of the art production sys­tem in discrete parts manufacturing. With its pull-driven production and elimination of non­value-adding tasks, Lean Production is able to improve efficiency with little invest. Neverthe­less, Lean Production is reaching its limits nowadays. It does not take into account the poten­tial of modern information and communication technology and is not able to realize a lot-size one production of highly customized products. Furthermore, there is a lack of changeability in production lines to meet future production requirements.

Digitization in production tries to cope with these requirements. New digital technologies and the increased computing power are paving the way to intelligent machines and assistant sys­tems for complex manufacturing processes. In addition, decreasing prices and miniaturiza­tion of components lead to ubiquitous and connected computers. There is no doubt about the potential of this technological development in production. Nevertheless, a comprehensive and holistic approach which describes how digitization and digitized solutions can be imple­mented in existing production systems is missing.

The objective of this thesis is the development of uniform communication interfaces for the lean production. The developed reference-architecture defines in a technology-independent way how to realize such interfaces. Besides, it enables the usage of digital technologies in existing lean-methods. It consists of a system architecture which defines roles and their con­nections. Furthermore, necessary functionalities for each role as well as exchanged mes­sages are specified in an information model. In order to support the realization, the refer­ence-architecture proposes a software-architecture to realize the common and uniform communication interfaces. The reference-architecture has been implemented in an existing research demonstrator at the Technologie-lnitiative SmartFactory KL e.V.

1. Einleitung

Mit ihrer 1992 veroffentlichten Studie uber Toyotas Produktionssystem pragten [Wom+92] nicht nur den Begriff „Lean Production", sondern sorgten insbesondere in der westlichen In­dustrie fur einen tief greifenden Wandel in der Produktion. Die Umstellung auf eine nachfra- georientierte Produktion, durchgangig standardisierte und transparente Prozesse sowie die Vermeidung jeglicher nicht-wertschopfender Aktivitaten waren im Vergleich zur klassischen, von Henry Ford gepragten Massenproduktion, Erfolgskonzepte, die den Automobilhersteller Toyota zum Weltmarktfuhrer machten. 30% kurzere Durchlaufzeiten, 20% geringere Lager- bestande und eine Effizienzsteigerung von 30% pro Mitarbeiter bei verhaltnismalJig geringen Investitionen sind Grunde, weshalb heute fast alle diskreten Klein- und GroIJserienfertigun- gen die Prinzipien und Methoden der Lean Production einsetzen. [Ger11; Kor+04; Neu07; Ger11; Dom+15] Der Begriff „Lean Production System" (LPS) fasst heute die unterschiedli- chen, individuellen Anpassungen der Lean Production zusammen, die alle auf dem in den 1950ern entstandenen Ansatz von Toyota basieren [Dom+15].

Auch wenn die Vorteile von LPS unumstritten sind, stolien die Prinzipien und Methoden der Lean Production heute an ihre Grenzen. Die steigende Volatilitat der Markte, immer kurzere Produktlebenszyklen sowie die kundenindividuelle Einzelfertigung sind Entwicklungen, die zur Zeit der Lean Production noch nicht abzusehen waren und somit keine Berucksichtigung fanden [Nyh08]. Konzepte wie eine gleichmaRige Auslastung und einheitliche Taktzeiten von Fertigungslinien werden diesen neuen Anforderungen nicht gerecht. Methoden wie das Kan­ban-System sind ferner nicht fur sich stetig andernde Fertigungslinien konzipiert. [Erl07; Dic07c] Die Ziele der Lean Production, die Verbesserung von Kosten, Qualitat und Durch- laufzeit, mussen heute urn das Ziel Wandelbarkeit erganzt werden [Mou+12], Wandelbarkeit ist die Fahigkeit, sich zukunftig schnell auf nicht bekannte Umstande einzustellen. Daruber hinaus bleiben die Potenziale moderner Informations- und Kommunikationstechnologie (IKT) wie z.B. verkurzte Informationsflusse und intelligente, sich selbst steuernde Systeme in der Lean Production ungenutzt.

Der technische Fortschritt, kleinere BaugroRen und ein gleichzeitiger Verfall der Beschaf- fungskosten fur IKT fuhrten in den letzten Jahren zu einer Verbreitung von Computern. Be- griffe wie ..Ubiquitous Computing" Oder ..Internet of Things" beschreiben allgegenwartige, nicht sichtbare IT-Systeme, die mit dem Internet vernetzt sind und uns im Alltag unterstutzen [Wei91]. Nach der Einfuhrung von Produktionsanlagen, der Elektrifizierung und dem Einsatz von Automatisierungstechnologie wird unter dem Begriff ..Industrie 4.0“ die nachste Revoluti­on in der Produktion prognostiziert. Industrie 4.0 beschreibt den vermehrten Einsatz von IKT, urn den zukunftigen Marktanforderungen und dem dadurch entstehenden Bedarf nach Wan­delbarkeit in der Produktion gerecht zu werden. Als Kerntechnologie wurden sogenannte Cyber-Physische Systeme (CPSe) identifiziert. [Bun; Kag+13] Aufgrund ihrer Leistungsfahig- keit und den Interaktionsmoglichkeiten mit der Umgebung ermoglichen CPSe in der Produk­tion autonom agierende, intelligente Systeme [Lee08; Bro10a], Aus der Fabrik wird eine Smart Factory [Zuh10]. Neben CPSen finden auch andere, neuartige digitale Technologien wie mobile Endgerate, Datenbrillen mit Augmented Reality und kunstliche Intelligenz Einzug in die Produktion. Das, was wie eine Fiktion klingt, wurde bereits in Forschungsprojekten demonstriert und ist teilweise am Markt als Produkt erhaltlich (siehe z.B. [Rei+15]).

Diese technologiegetriebene Entwicklung vernachlassigt allerdings die Integration in und die Migration von bestehenden Produktionsumgebungen. Existierende Referenzarchitekturen beschranken sich auf die tech nolog ische Sicht und berucksichtigen die organisatorischen Prozesse und die Rolle des Menschen nicht ausreichend. Das ist insofern uberraschend, da die Notwendigkeit einer ganzheitlichen Betrachtung spatestens seit der Ara der Computer Integrated Manufacturing (CIM) bekannt ist. [Deu+15; Zuh10; Deu+15] Daruber hinaus fallt heutzutage ein Grofcteil der Kosten fur die Automatisierung im Engineering und fur die spate- re Anpassung an neue Anforderungen an [Col+05; Lud+]. Ein Ansatz, dem entgegenzuwir- ken, ist die sinnvolle Modularisierung und Etablierung definierter Kommunikationsschnittstel- len. Modularisierung kann die Interoperabilitat insbesondere mit bestehenden Systemen her- stellen, die Komplexitat reduzieren und die Wandelbarkeit von Produktionsumgebungen ver- bessern [Deu+15; Col+05].

Aus den heutigen Defiziten der weitverbreiteten Lean Production sowie dem Potenzial der vermehrten Integration von IKT in der Produktion ergibt sich die Frage, wie digitale Techno- logien die Wandelbarkeit der Lean Production unterstutzen konnen. Ahnlich wie die von [Sch 13] bereits 1997 im Kontext der Architektur Integrierter Systeme (ARIS) veroffentlichten Referenzmodelle fur administrative Prozesse bedarf es eines formalisierten Modells, das die Prozesse und Interaktionen der Lean Production fur die Umsetzung mittels digitaler Techno- logien beschreibt. Die Wirkung eines solchen Referenzmodells mit seinen beschriebenen Prozessen und Akteuren hat sich in der Vergangenheit im Enterprise-Resource-Planning (ERP)-System SAP gezeigt, in das die Arbeiten von Scheer einflossen [Sch+15] (siehe Ab- bildung 1).

Die vorliegende Arbeit thematisiert einen ahnlichen Ansatz fur die Lean Production. Die erar- beitete, technologieunabhangige Referenzarchitektur legt in einer ubergeordneten Sys- temarchitektur die notwendigen, mit informationstechnischen Schnittstellen ausgestatteten Rollen und Ressourcen fest. In einem Informationsmodell spezifiziert sie die von jeder Rolle anzubietenden Dienste und vereinheitlicht die ausgetauschten Nachrichtentypen. Erganzt wird beides durch eine Softwarearchitektur fur die informationstechnischen Schnittstellen, die bestehende Systeme und die Verwendung von CPSen berucksichtigt. Die in der Referenzar­chitektur definierten einheitlichen Schnittstellen vereinfachen die Integration digitaler Techno-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 Beispiel fur ein Referenzmodell zur Abwicklung einer Kundenanfrage (links) und fur ein Informationsmodell (rechts) aus ARIS (Quelle: [Sch02], [Sch13a])

logien und unterstutzen die Modularisierung in der Lean Production. Hierdurch erreicht sie das angestrebte Ziel, die Wandelbarkeit der Lean Production zu verbessern.

Im Folgenden wird in Kapitel 2.1 der Status quo relevanter Themen der Produktionsdigitalisierung aufgearbeitet und fur diese Arbeit relevante Wissensgrundlagen beschrieben. Kapitel 2.2 widmet sich der Lean Production und aktuell vorhandenen, digitalisierten Anwendungen hierfur. Aufbauend auf diesen Erkenntnissen leitet Kapitel 3 das Ziel und die notwendigen (Teil-)Ergebnisse dieser Arbeit her. Die erarbeitete Referenzarchitektur wird anschlieliend in Kapitel 4 vorgestellt und in Kapitel 5 in einer prototypischen Realisierung verifiziert. Zuletzt widmet sich Kapitel 6 der kritischen Betrachtung der Ergebnisse und gibt einen Ausblick auf weitere, auf diese Arbeit aufbauende Forschungsthemen.

2. Stand der Technik

Das vorliegende Kapitel beschreibt die fur diese Arbeit relevanten Themen und gibt einen Uberblick Liber den aktuellen Stand der Forschung und Entwicklung. Wie in der Einleitung bereits hervorgehoben, verbindet die vorliegende Arbeit die aktuell stattfindende Digitalisie- rung in der Produktion (Kapitel 2.1) mit der bestehenden Lean Production (Kapitel 2.2).

2.1 Digitalisierung in der Produktion

lm Folgenden wird im Themenfeld Digitalisierung neben den der Digitalisierung zugrundelie- genden Paradigmen und vorhandenen Architekturen als Grundlage fur die Referenzarchitek- tur insbesondere auf die digitale Kommunikation eingegangen. Dies umfasst bestehende Schnittstellen, Kommunikationsmethoden sowie Informationsmodelle zur Standardisierung des Informationsaustausches. Das Kapitel schlielJet mit einer Bewertung des aktuellen Sta­tus Quo und den bestehenden Defiziten ab.

2.1.1 Begriffsabgrenzung und Paradigmen

In den vergangenen Jahren fand der Begriff ..Digitalisierung" im deutschsprachigen Raum grolie Verbreitung. Er beschrieb ursprunglich die digitale Darstellung von Informationen Oder die Umwandlung analoger Signale in digitale Signale [Bib]. Ein Beispiel hierfur ist ein Analog- Digital-Wandler, der analoge Messwerte aus einem Temperatursensor in digitale Werte um- wandelt. In den letzten Jahren veranderte sich das Verstandnis fur den Begriff. Digitalisie­rung beschreibt heute die zunehmende Einfuhrung von modernen digitalen Technologien in Wirtschaft, Gesellschaft und Produktion [Pla], Dies umfasst zum einen die vermehrte Nut- zung von IKT in bestehenden Anwendungen, zum anderen aber auch die Einfuhrung neuer, auf IKT basierender Geschaftsmodelle. Digitalisierung ist ein kontinuierlicher Prozess der Veranderung, der nicht nur technische, sondern auch organisatorische Aspekte betrifft. [Mer+16; Jun+16; Pau16] In dieser Arbeit wird Digitalisierung wie folgt verstanden:

Digitalisierung beschreibt die bewusste Integration von IKT in Prozesse und Strukturen in einem Betrachtungsbereich (in diesem Fall die innerbetriebliche Produktion), welcher zuvor nicht Oder nur untergeordnet diese Technologie nutzte.

Beispiele fur Digitalisierung in der Produktion sind die Einfuhrung mobiler Endgerate wie Tablets als Ersatz fur Papier, die kontextbezogene Informationsanreicherung mithilfe von Augmented Reality in Form von z.B. Datenbrillen (siehe Abbildung 2) Oder, im Rahmen der digitalen Vernetzung, das anlagenubergreifende Auslesen und Interpretieren von Sensor- und Aktorinformationen zur Statusuberwachung.

Im Zusammenhang mit der Digitalisierung ist Industrie 4.0 zu nennen. Die deutsche Bundes- regierung verkundete 2011 im Rahmen der digitalen Agenda den Begriff zusammen mit ei­nem dazugehorigen Forderprogramm. Andere Regionen wie z.B. die USA, China Oder Euro- pa adaptierten ihn kurze Zeit spater und legten ahnliche Programme fest (siehe z.B. [Xin15; The16; Bun]). Heutzutage ist der Begriff ..Industrie 4.0“ neben der Digitalisierung nicht nur im deutschsprachigen Raum allgegenwartig.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 Beispiel fur den Einsatz von Augmented Reality und Datenbnllen fur Wartungs- arbeiten in der Produktion (Quelle: Technologie-lnitiative SmartFactory KL e.V.)

Industrie 4.0 beschreibt die Vision der durchgangig digital vernetzten, weitestgehend auto- nom agierenden Produktion, in der Komponenten miteinander Informationen austauschen und sich selbst koordinieren. Die Ubertragung der Ideen des Internets-der-Dinge auf die Produktion soil diese befahigen, den zukunftigen Bedarf an hochindividualisierten Produkten zu erfullen. Moglich ist dies dank des technologischen Fortschrittes, der Miniaturisierung in der IKT und des gleichzeitig stattfindenden Preisverfalles dieser Komponenten. Im Gegen- satz zur CIM-Ara in den 1980ern strebt Industrie 4.0 nicht die Substitution des Menschen an, sondern dessen Unterstutzung. [aca14; Pla; Kag+13]

Kernparadigmen von Industrie 4.0 sind neben der Digitalisierung der Produktion die Modula- risierung zur Verbesserung der Wandelbarkeit von Anlagen und Fertigungslinien. AulJerdem gehoren die dadurch bedingte Dezentralisierung der Steuerung in der Produktion hin zu au- tonom agierenden Systemen, die durchgangige digitale Vernetzung und die digitale Kommu- nikation aller in der Produktion beteiligten Entitaten dazu. [Kag+13]

Modularisierung beschreibt die Unterteilung eines Systems in kleinere Einheiten mit definier- ten Schnittstellen, die eigenstandige Funktionalitaten anbieten. Sie ist ein Ansatz, der den Widerspruch zwischen hoher Variantenvielfalt bzw. kundenindividueller Fertigung und kos- tengunstiger, effizienter Nutzung der Produktionsressourcen mindert. Sie verbessert die Wandelbarkeit durch wiederverwendbare und einfach austauschbare Module. AulJerdem reduziert die Modularisierung die Komplexitat technischer Systeme, da mit steigender Abs- traktionsebene die Detailfunktionalitat von Modulen aufgrund der klaren Schnittstellen und Interaktionen aulier Acht gelassen werden kann (vgl. „Black-Box-Ansatz“). Die Objektorien- tierung und damit einhergehende Modularisierung ermoglichte in der Softwareentwicklung z.B. die Entwicklung komplexer Systeme mit vielen Beteiligten. [Mil+98; Kra+07; Mou+12] Modularisierung im Kontext der Produktion bezieht sich sowohl auf den physischen Aufbau als auch auf die funktionale Unterteilung eines technischen Systems. Im Gegensatz zu ei- nem Baustein muss ein Modul eine signifikante Aufgabe erfullen. Die Interaktionen mit der Umgebung, d.h. Ein- und Ausgabewerte, sowie die Beschreibung von Schnittstellen, d.h. Verbindungs- und Austauschpunkte, stehen bei der Modulbeschreibung im Mittelpunkt. Die Umgebung beeinflusst hierbei immer die Modularisierung. Je nach Bezugssystem kann bei- spielsweise eine Entitat entweder ein eigenstandiges System Oder ein Modul in einem ande- ren System sein. [Mil+98]

Urn die signifikanten Aufgaben selbststandig ubernehmen zu konnen, benotigen die Module eine eigenstandige Steuerungskomponente, welche interne Prozesse ausfuhrt und kontrol- liert. Dies verlagert zwangslaufig die Steuerungslogik von einer zentralen Komponente hin zu mehreren, verteilten Steuerungen. Diese bereits in der Praxis beobachtbare Entwicklung lasst sich als Dezentralisierung bezeichnen. Dezentrale Architekturen beschreiben hierfur den strukturellen Aufbau. Forschung und Praxis konnten in der Vergangenheit bereits den Vorteil dezentral gesteuerter Produktionen insbesondere hinsichtlich der Flexibilitat, der Adaptivitat und der Robustheit nachweisen. [Mou+12; Lei09]

Durch die Dezentralisierung und Modularisierung steigt die Relevanz der Kommunikation zwischen den Entitaten. Fur den digitalen Informationsaustausch einer Steuerung mit seiner Umgebung muss ein gemeinsames Kommunikationsnetzwerk bestehen, uber welches alle involvierten Teilnehmer erreichbar sind. Das beschrankt sich nicht nur auf die Produktion, sondern umfasst auch die relevanten ubergeordneten IT-Systeme wie z.B. das Manufac­turing Execution System (MES) Oder das ERP-System. Die seit Industrie 4.0 verstarkt ange- strebte gemeinsame Kommunikationsmdglichkeit zwischen alien Entitaten lasst sich als durchgangige digitale Vernetzung bezeichnen. Hierfur benotigen Steuerungen bzw. Module allerdings einheitliche informationstechnische Schnittstellen.

Im Gegensatz zu starren, sich uber die Zeit nicht andernden Konfigurationen ermoglicht eine dezentral gesteuerte und modulare Produktion zur Fertigung von kundenindividuellen Kleinstlosen eine stetige Anpassung an neue Anforderungen. Die im gemeinsamen Kommu­nikationsnetzwerk ausgetauschten Daten mussen fur alle interpretierbar sein. Neben einer gemeinsamen Syntax, welche die Struktur regelt, muss es eine gemeinsame Semantik ge- ben, welche die Bedeutung der Daten beschreibt. [Den12; Gra+16] In der Informatik sind unterschiedliche Modellarten zur Wissensreprasentation entstanden, die sich hinsichtlich Komplexitat und Ausdrucksstarke unterscheiden. In der einfachsten Form lassen sich Daten in einem Nachschlagewerk in Form eines Glossars darstellen, in der ausdrucksstarksten, komplexesten Version wird eine Ontologie verwendet, die zusatzlich logische Relationen zwischen Entitatstypen beschreiben kann (siehe auch [Den12; Dac+03]).

Zusammenfassend sind die Digitalisierung und die Modularisierung wichtige Paradigmen, urn die Wandelbarkeit zu verbessern und den zukunftigen Anforderungen an die Produktion gerecht zu werden. Die durchgangige digitale Vernetzung erfordert eine einheitliche, ma- schinenlesbare Kommunikation und bedingt durch die Modularisierung steigt die Dezentrali- tat und Relevanz der Schnittstellendefinition. Im Folgenden werden daher diese Themen vertiefend betrachtet.

2.1.2 Dezentrale Architekturen fur die Produktionssteuerung

2.1.2.1 Definition und Eigenschaften von Architekturen

Der Architektur-Begriff ist zuruckzufuhren auf den lateinischen Begriff ..architecture", der Baukunst bedeutet. Aufgrund der vielfachen Anwendung in der Stadtplanung, im Bauwesen und in der Informatik ist der Begriff heute nicht einheitlich definiert. Grundsatzlich beschreibt eine Architektur in alien Domanen eine Struktur zur Realisierung von Funktionalitaten, d.h. sie vereint zwei Sichten auf ein System: Zum einen beschreibt sie die fur das Schaffen eines Mehrwerts, also eine Funktion, notwendigen Komponenten, zum anderen beschreibt sie de- ren Form, im Besonderen die Zusammenstellung der Komponenten. Die Architektur stellt im Wesentlichen die nicht-funktionale Qualitat eines Systems dar. [Wik16a; Gol14; Kra+07; Hab+12]

Als eigener Typ von Architekturen beschreibt eine Referenzarchitektur eine Schablone, die in einer bestimmten Domane ahnlich geartete Probleme lost und die Komplexitat reduziert. Ei­ne Referenzarchitektur beschreibt u.a. Systembestandteile, Beziehungen der Entitaten un- tereinander, Nomenklaturen sowie typische Entwicklungs- und Losungsmuster. Die Be- schreibung bleibt grundsatzlich abstrakt und technologieunabhangig. Sie sollte allerdings neben technischen Aspekten auch die betrachteten Anwendungsfalle und deren Einbettung in die Domane adressieren. Sofern sich eine Referenzarchitektur nicht aus existierenden Architekturen und Implementierungen ableiten lasst, kann sie auch durch eine Referenzim- plementierung Oder einen Prototypen verifiziert werden. Obwohl in der Informatik ein einheit- licheres Verstandnis fur eine Referenzarchitektur besteht, ist der Begriff ahnlich wie der der Architektur in anderen Domanen nicht einheitlich definiert. [Gol14; Bro+12; Lin+15; Clo+09; Rat01]

(Referenz-)Architekturen lassen sich in zwei Typen unterteilen: Zum einen in Architekturen, die ein System beschreiben, und zum anderen in Architekturen, die eine Methode beschrei- ben. Erstere entsprechen der in der Praxis verbreiteteren Auffassung von Architekturen im Sinne einer Struktur. Letztere entsprechen eher Vorgehensmodellen zur Realisierung der erstgenannten Architekturen. [Kra+07] Eine gute Architektur ist u.a. dadurch gekennzeichnet, dass sie gegebene Rahmenbedingungen einhalt, ein strategisches Ziel Oder eine domanen- spezifische Aufgabenstellung wirtschaftlich erreicht und mit wenig Aufwand erweiterbar bzw. anpassbar ist. Zusatzlich sollte sie fur Dritte schnell erfassbar und in sich stimmig sein. [Hab+12] Im Rahmen dieser Arbeit ist eine Referenzarchitektur zu verstehen als:

Eine Referenzarchitektur ist eine technologieunabhangige Beschreibung, welche ein Problem in einer Domane zielorientiert und mdglichst allgemeingultig lost. Die Bestandteile einer Referenzarchitektur sind hierbei von der Domane und Pro- blemstellung abhangig und umfassen Strukturen Oder Vorgehensweisen.

Auch wenn (Referenz-)Architekturen nur ein theoretisches Konstrukt sind, ist ihr Mehrwert unumstritten. Sie besitzen fur die Entwicklung komplexer Systeme und die Digitalisierung der Produktion einen hohen Stellenwert. [Sen13; Rei+13; Pir+13] Architekturen helfen Entwick- lern, relevante Aspekte des betrachteten Systems von nicht relevanten Dingen abzugrenzen, wodurch Architekturen die Komplexitat reduzieren. Auch schafft eine Architektur ein gemein- sames Verstandnis fur eine Domane und reduziert Risiken bei der Entwicklung durch das Vermitteln von Wissen und Erfahrung. Sie ist teils sogar zwingend notwendig, da sie den Kontext eines Systems beschreibt. Ein Beispiel hierfur ist die Definition von Modulen, welche ohne die Kenntnisse des Kontexts nicht moglich ist. [Lin+15; Mil+98]

2.1.2.2 Relevanz von dezentralen Architekturen

Die Automatisierungspyramide ist eine fur die Beschreibung von automatisierten Fertigungs- linien und Anlagen in der Produktion weitverbreitete Architektur. Sie beschreibt die Arten und Abhangigkeiten unterschiedlicher Komponenten in der Produktion und ordnet sie in eine Hie- rarchie ein. Auch wenn heute unterschiedliche Darstellungen hinsichtlich Anzahl und Ab- grenzung der Ebenen in der Automatisierungspyramide existieren (siehe z.B. [Col+13; Zuh+11; Reu+08]), ist der grundsatzliche Aufbau stets ahnlich und in Abbildung 3 dargestellt. Auf der untersten Ebene der Pyramide befindet sich eine hohe Anzahl von Aktoren und Sen- soren. In der daruber liegenden Steuerungsebene befinden sich Steuerungskomponenten wie z.B. Speicherprogrammierbare Steuerungen (SPSen), welche mehrere Aktoren steuern Oder mehrere Sensoren auslesen. Sie kontrollieren ganze Anlagen Oder Anlagenabschnitte. Jedes Feldgerat ist in der Regel test einer Steuerung zugeordnet. In den Ebenen daruber befindet sich eine geringe Anzahl unterschiedlicher Systeme, die anlagenubergreifend die Produktion Oder das ganze Unternehmen verwalten. Beispiele hierfur sind MES zur Detail- planung und -steuerung von vorliegenden Auftragen Oder ERP-Systeme, die neben der Pro­duktion auch Dienste fur die Buchhaltung Oder das Personalwesen bereitstellen und mitei- nander vernetzen.

Fur die vorliegende Arbeit ist insbesondere die Steuerungsebene der Automatisierungspy­ramide mit ihren Schnittstellen zu ubergeordneten Software-Systemen relevant, weshalb im Folgenden speziell Architekturen hierfur betrachtet werden. Eine Steuerungsarchitektur ist eine Architektur, die fur die Domane der Produktion den Zusammenhang zwischen kontrollie- renden und ausfuhrenden Instanzen beschreibt. Sie bezieht sich speziell auf den Zu­sammenhang zwischen Steuerungen, den Ablauf von Entscheidungen sowie die Verteilung

Abbildung in dieser Leseprobe nicht enthalten

Abbıldung 3 Aulomatısierungspyramıde (Quelle [Züh+11])

von Entscheidungskompetenzen. Steuerungsarchitekturen liefern den grundsatzlichen Rah- men fur die spatere Implementierung der Hard- und Software. [Sch13b]

Hinsichtlich der Verteilung der Steuerungslogik in einem Netzwerk mit mehreren Steuerun- gen lassen sich drei Paradigmen unterscheiden. Je nach Sichtweise, ob aus Sicht der Sys- temstruktur Oder der Steuerungsverteilung, sind unterschiedliche Bezeichnungen fur die Ar- chitekturen entstanden. In hierarchischen Architekturen ubernimmt die ubergeordnete In- stanz die Kontrolle der ihr untergebenen Einheiten. Durch die vertikale Zusammenfassung von Aufgaben und Verantwortlichkeiten mit steigender Ebene existiert in der Regel eine zent- rale Instanz auf hochster Ebene, welche alle anderen ihr untergeordneten Komponenten direkt Oder indirekt kontrolliert. Diese Architektur entspricht dem klassischen Ansatz zur Steuerung in der Produktion. Die Pyramidenform der Automatisierungspyramide visualisiert dies. Der Begriff „zentrale Steuerung" ist ein Synonym zur hierarchischen Architektur. Das Gegenteil zu einer hierarchischen Architektur ist eine heterarchische Architektur. Hier ent- scheiden Steuerungen selbststandig und sind nicht weisungsgebunden an ubergeordnete Systeme. Alle Steuerungen kontrollieren eigene Feldgerate und bieten Funktionalitaten an. Durch die Kommunikation mit den gleichwertigen anderen Teilnehmern koordinieren sie Pro- zesse und handeln die Ubernahme von Aufgaben aus. Aus Steuerungssicht wird diese Ar­chitektur auch als „autonome Steuerung" bezeichnet. Beispiele fur eine solche Architektur finden sich im nachsten Kapitel in den agentenbasierten Ansatzen. Zwischen diesen beiden Extremen finden sich semi-heterarchische Architekturen, welche auch als dezentrale Steue­rungen bekannt sind. Sie kombinieren die Ansatze aus beiden Bereichen in unterschiedlicher Auspragung miteinander. Abbildung 4 visualisiert die vorgestellten Paradigmen und Syno- nyme. [Sch13b; Sch+07; Sch16; Wel+11]

In Abhangigkeit vom Grad der Heterarchie ist bei dezentralen Steuerungen eine zentrale Fertigungsplanung und -optimierung mangels global verfugbarer Informationen nur bedingt moglich und das Verhalten einzelner Steuerungen sowie die Gesamtleistung der Produktion nur schwer prognostizierbar. Auch sind die Investitionskosten aufgrund der Redundanz von Steuerungen hoher. U.a. mangels in der Produktion akzeptierter Standards und geringer

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 Vergleich von Paradigmen bei der Architekturgestaltung (Quelle: [Sch13b])

Interoperability zwischen den Herstellern konnten sich autonome Steuerungen bisher nicht etablieren. [Van+98; Col+05; Lei09]

Nichtsdestotrotz erfreuen sich autonome und dezentrale Steuerungen in Forschung und Pra­xis wachsender Beliebtheit. Grunde dafur sind die sinkenden Kosten, die damit verbundene bessere Rentability heterarchischer Architekturen, eine hohere Wandelbarkeit im Vergleich zu starren, zentralen Steuerungen und die lokale Rechenleistung fur die Datenvorverarbei- tung, um Eng passe in der Datenubertragung zu vermeiden. Sowohl die Wissenschaft als auch die Praxis konnten fur autonome Systeme nachweisen, dass sie hinsichtlich Produktivi- tat, Flexibility, Robustheit und Implementierungsaufwand zentralen Systemen uberlegen sind. [Van+98; Mou+12; Lei09; van96; Weg98; Val+94; Lei+08]

Mit der aktuell stattfindenden Industrie 4.0-Entwicklung und der angestrebten Modularisie- rung der Produktion verlagert sich zwangslaufig die Steuerungslogik von einer zentralen, ubergeordneten Instanz auf mehrere Module. Die in den Modulen jeweils vorhandenen Steuerungskomponenten steuern nicht nur die internen Komponenten, sondern kapseln auch die Kommunikation nach extern. Ein lose gekoppeltes Netzwerk mit sich selbst organi- sierenden Entitaten lost langfristig die klassische Automatisierungspyramide ab. [Her17a; Gor+17; Vog+14] Die im nachsten Kapitel vorgestellten CPSe bieten einen mit Industrie 4.0 aufgekommenen, vielversprechenden Ansatz zur Realisierung dezentraler Steuerungsarchi- tekturen.

2.1.2.3 Cyber-Physische Systeme zur dezentralen Steuerung der Produktion

CPSe sind kostengunstige und leistungsstarke Systeme, welche mit ihrer physischen Um- welt interagieren und digital mit anderen Systemen kommunizieren. Sie wurden im Rahmen der Industrie 4.0-Entwicklung als Kerntechnologie fur die dezentrale Steuerung proklamiert, da sie kostengunstig lokale Rechenleistung in die Produktion bringen. CPSe sollen nicht nur autonom handeln und sich selbst optimieren, sondern durch die Interaktion miteinander den Wandel von einer zentralen zu einer dezentralen Steuerung der Produktion unterstutzen. [Bau14; Bun]

Nach [Lee08], welcher den Begriff CPSe pragte, und [Bro10b], welcher sich mit den Potenzi- alen von CPSe in der Produktion befasste, besteht ein CPS aus einem eingebetteten, leis- tungsstarken Kleinstrechner zur Datenverarbeitung. Mittels daran angeschlossener Aktoren und Sensoren kann es mit seiner physischen Umwelt interagieren. liber eine integrierte Kommunikationsschnittstelle tauscht es digital Informationen mit anderen Entitaten aus (vgl. Abbildung 5)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 Schematische Darstellung eines CPSs (Quelle: [Kol13])

Als Weiterentwicklung von eingebetteten Systemen steht bei einem CPS der Austausch mit seiner physischen und digitalen Umgebung im Fokus. Dieser umfasst sowohl dem CPS be- reits bekannte als auch neue Entitaten. Im Kontext der Produktion zahlen zu den Entitaten andere CPSe, Anlagen und Menschen. Durch die leistungsstarke Recheneinheit kann es aufgenommene Informationen selbststandig interpretieren und Aktionen auslosen. Ein CPS wird aufgrund dieser Autonomie im allgemeinen Sprachgebrauch auch als ..intelligent" be- zeichnet.

Bezogen auf die vorgenannte Automatisierungspyramide ist das primare Einsatzgebiet von CPS die Steuerungsebene. Mit CPSen ausgestattete Anlagen werden auch als ..intelligente Anlagen" Oder ..Cyber-Physische Produktionssysteme" betitelt (siehe z.B. [Pro]). Auch wenn klassische Speicherprogrammierbare Steuerungen (SPS) die Produktion heute noch domi- nieren, existieren bereits erste kommerzielle Produkte im Sinne eines CPSs. Beispiele sind in Abbildung 6 dargestellt und z.B. in [Rot16] beschrieben. Sie basieren auf offenen Be- triebssystemen mit offenen Programmierschnittstellen, auf welchen auch moderne, objekt- orientierte Hoch-Programmiersprachen wie z.B. Java eingesetzt werden konnen, urn Feldge- rate anzusprechen. Moderne SPSen verfolgen ebenfalls den Ansatz von CPSen, wodurch eine eindeutige Abgrenzung nicht immer moglich ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 Beispiele fur kommerzielle Produkte im Sinne von CPSen (links: KUNBUS Re­volution Pi; rechts: Harting MICA; Quelle: [Han 16; Klo15])

CPSe sind zusammenfassend eine vielversprechende Technologie, um flexibel program- mierbare Rechenleistung in der Produktion zu ermoglichen. Aufgrund der Vielzahl der Schnittstellen konnen sie auch bestehende Betriebsmittel und Anlagen nachtraglich an das durch die Digitalisierung angestrebte durchgangige Netzwerk anbinden.

2.1.2.4 Bestehende dezentrale Architekturen zur Produktionssteuerung

Wie zuvor erwahnt, erfreuen sich dezentrale Architekturen in der Produktion u.a. aufgrund ihres Vorteils in komplexen und dynamischen Umgebungen wachsender Beliebtheit. Sie werden nicht erst seit dem Aufkommen von CPSen und Industrie 4.0 erforscht. Erste Ansat- ze finden sich bereits in den 1980er-Jahren, wobei in der Zeit vor und nach der Jahrtau- sendwende intensiv an dem Thema geforscht wurde. Eine Auswahl fur den Kontext dieser Arbeit relevanter Architekturen und Begrifflichkeiten wird im Folgenden vorgestellt. Der Fo- kus liegt auf der fur diese Arbeit relevanten Rollenverteilung von Steuerungen und Schnitt­stellen. Weitere Informationen zur historischen Entwicklung dezentraler Architekturen in der Produktion finden sich u.a. in [van96], [Lei09], [Sch+07] und [Sch13b],

Im Bereich der kunstlichen Intelligenz entstand der Ansatz der Multiagentensysteme (MAS). Autonome physische und logische Entitaten, sogenannte Agenten, interagieren in MAS mit- einander, um parallel ein gemeinsames Ziel zu erreichen, das die Agenten alleine nicht er- reichen konnen. Diese softwaregetriebenen Agenten ermoglichen die Realisierung von hete- rarchischen Steuerungsarchitekturen in der Produktion. Sie fordern die Komplexitatsreduzie- rung durch Funktionskapselung und unterstutzen eine hohe Wiederverwendbarkeit von Softwarecode. [Goh13; Lei09] Im Fokus von Architekturuberlegungen bei MAS stehen weni- ger feste Strukturen und Abhangigkeiten, sondern vielmehr die Definition von Agentenrollen, deren Verantwortlichkeiten, Verhaltensarten und -weisen. Analyse- und Entwurfsmethoden wie beispielsweise das Multiagent Systems Engineering (MaSE) leiten aus einem uberge- ordneten Ziel Anwendungsfalle ab, aus denen sich wiederum Agentenklassen und Nachrich- tenaustausche ergeben. Erst im letzten Schritt einer jeden Iteration werden Rahmenbedin- gungen wie der physische Ort des Agenten und die maximal zulassige Anzahl bestimmter Agenten je Klasse definiert. Agenten werden dabei beispielsweise durch die Wahrneh- mungsinhalte, Aktionen, Ziele und die Umwelt (engl. percepts, action, goals, environments; PAGE) Oder Wissen uber die Umwelt, Zielzustande und Absichten (engl. beliefs, desires, intentions; BDI) beschrieben. Grundsatzlich lassen sich drei Arten von Verhaltensweisen unterscheiden: Reaktive Agenten reagieren anhand fester Regeln auf Eingangswerte; logik- basierte Agenten treffen auf Basis eines Modells der Umwelt logische Schlussfolgerungen fur ihr Handeln zur Zielerreichung; BDI-Agenten verfugen uber ein Modell ihrer Umwelt und die Fahigkeit, selbst Ziele festzulegen und zu verfolgen. [Wei+06; Lei09; Los13] Beispiele fur bestehende Projekte und Frameworks fur MAS in der Produktion sind in [She+06] aufgelistet. Ein weiterer Ansatz zur Dezentralisierung der Produktion sind holonische Fertigungssysteme (engl. Holonic Manufacturing Systems; HMS). Der Begriff „Holon“, griechisch fur „Teil eines Ganzen“, ist zuruckzufuhren auf [Koe89] und beschreibt das kleinste Modellierungselement eines Systems mit festgelegten Rollen und Aufgaben. HMS wurden insbesondere im Produk- tionsumfeld wahrend der CIM-Ara erforscht. [Sch13b] Auch wenn in einem HMS die autono­men Holonen miteinander kooperieren und zur Zielerreichung aufeinander angewiesen sind, sind HMS im Gegensatz zu MAS nicht vollstandig dezentral, sondern hierarchisch struktu- riert. Die Holonen konnen im Gegensatz zu klassischen Hierarchien allerdings unterschiedli- chen HMS angehoren. [Lei09] Bekannte Referenzarchitekturen wie z.B. PROSA, ADACOR Oder GRACE basieren immer auf mindestens drei Grundtypen von Holonen, die in der Pro- duktion miteinander interagieren (siehe z.B. Abbildung 7): Der Produkt-Holon enthalt das Prozess- und Produktwissen und beschreibt das zu fertigende Produkt; der Auftrags-Holon reprasentiert die Arbeitsschritte zur Fertigung eines konkreten Produktes; der Ressourcen- Holon hingegen reprasentiert vorhandene Fertigungsressourcen. Teilweise ist ein Unterstut- zungs-Holon vorhanden, der ubergreifende Hintergrundaktivitaten ubernimmt. Ein Holon kann sowohl eine physische Entitat als auch Software sein. Durch die Verwendung von Ho- lon-Typen besteht trotz einer inneren Heterogenitat eine Ahnlichkeit nach aufien. [Van+98; Goh13]

Beide Ansatze, MAS und HMS, sind nicht gegensatzlich. Bei MAS handelt es sich um ein Konzept und eine Technologie, bei HMS nur um ein Konzept. So konnen z.B. Agenten ein HMS realisieren. [Lei09] Neben diesen beiden in der Forschung recht bekannten Ansatzen finden sich unter Begriffen wie ..Flexible Manufacturing Systems" (FMS), „Reconfigurable Manufacturing Systems" (RMS), ..Biological Manufacturing Systems" (BMS), ..Fraktale Fabrik" Oder ..Agile Manufacturing Systems" (AMS) weitere Ansatze. Sie ubertragen unterschiedliche Paradigmen aus anderen Domanen auf verteilte Steuerungsarchitekturen, um die Wandel- barkeit der Fertigung zu erhohen. Eine klare Abgrenzung ist hierbei nicht immer moglich. Einen Uberblick und Vergleich dieser Ansatze findet sich z.B. in [Sch13b], [Lei09] Oder [Sch+07], MAS, HMS und ahnliche Ansatze beschreiben zusammenfassend aus der Struk- tursicht einen Sachverhalt. Sie geben keine unmittelbare Aussage uber ablaufende Prozesse bzw. wie sich bestehende Produktionsprozesse in Agenten abbilden lassen.

Fur den Einsatz von CPSen in der Produktion existieren in der Wissenschaft ebenfalls erste Architekturen. Speziell die Verteilung von Funktionalitaten auf unterschiedliche CPSe, die Ad-hoc-Vernetzung mit anderen Geraten, die Verbindung der physischen mit der Cyber-Welt und sich stetig andernde Umgebungen sind Herausforderungen, die ein CPS bewaltigen muss. Bestehende Referenzarchitekturen aus anderen Bereichen berucksichtigen das bisher nicht ausreichend. [Lee08; Rei+13; Kag+13] Nachstehende Beschreibung stellt eine Auswahl

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7 Holon-Typen und Zusammenhange in PROSA (Quelle: [Van+98])

bestehender CPS-Architekturen fur die Produktion vor. U.a. [Kol13] Oder [Hu+12] beschrei- ben und vergleichen daruber hinaus weitere Ansatze.

[Lew+13] erarbeiteten eine auf MAS basierende Architektur fur CPSe in der Intralogistik, welche sie in einem Demonstrator der Handhabungstechnik evaluierten. Ihr Ansatz unterteilt drei Ebenen in Abhangigkeit von der Rolle des Agenten: Im User-Interaction-Layer befinden sich die Agenten zur Administration des Systems und Interaktion mit dem Menschen via ei- ner Benutzungsoberflache; Agenten des Transport-Agent-Layer verfolgen das Ziel, Waren zu einem Zielort zu bewegen; und alle Agenten zur Kontrolle von Hardware-Komponenten sind im Hardware-Agent-Layer zusammengefasst. Neben diesen Agentenarten existieren noch zwei ubergreifende Agenten, welche Aktivitaten protokollieren und Standorte von Entitaten uberwachen. Abbildung 8 gibt einen Uberblick uber die Aufteilung.

[Vog+15] stellen einen ahnlichen Ansatz fur den Aufbau cyber-physischer Produktionssyste- me vor. Die auf MAS basierende Architektur unterteilt vier Ebenen: Die Management-Ebene stellt die Vernetzung sicher, die Planning-Ebene verwaltet die Auftrage, die Scheduling- Ebene reprasentiert Agenten mit Produkten und in der Execution-Ebene sind Agenten der Produktionsressourcen gesammelt. Des Weiteren verantworten globale Agenten die Kom- munikation.

Im Rahmen des Forschungsprojektes Cyber-Physische Produktionssysteme (CyProS) ent- stand ein Rahmenkonzept zur Integration von CPSen in bestehende Produktionsumgebun- gen. Das Rahmenkonzept umfasst ein Vorgehensmodell fur das Engineering von CPS- basierten Losungen, Bausteine zur Beschreibung des Aufbaus von CPSen sowie unter- schiedliche CPS-Rollen und deren Eigenschaften. Die CPS-basierte Fabrik besteht aus ei­nem Cyber-Physischen Produktionssystem (CPPS) zur Herstellung von Produkten, einem Cyber-Physischen Transportsystem (CPTS) fur deren Transport, einer Cyber-Physischen Infrastruktur (CPI) zur Versorgung und Bereitstellung der Umgebung, einem Cyber- Physischen Produkt (CPP) als Resultat der Produktion sowie dem Produktionsplanungssys- tem (PPL). Abgesehen vom PPL, welches ausschliefilich ein Softwaresystem ist, sind alle Rollen vom Typ eines CPSs. Abbildung 9 gibt einen Uberblick uber die Beziehungen zwi- schen den Rollen. Die aufeinander abgestimmten Rollen, Bausteine und das Vorgehensmo­dell im Rahmenkonzept unterstutzen Entwickler bei der Losung von Problemen mittels CPS- basierterTechnologien. [Kol+17]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8 MAS-basierte CPS-Architektur fur die Intralogistik (Quelle: [Lew+13])

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9 Rollen und Beziehungen von CPSen in der Produktion (Quelle: [Kol+17])

Neben diesen zwei Beispielen existieren weitere CPS-Architekturen, welche nicht speziell fur die Produktion entworfen wurden. Ahnlich wie der Ansatz von [Lew+13] basiert [San+12] auf MAS. Die Ansatze von [Hu+12], [La+10] und [Lin+10] hingegen verwenden das Paradigma einer serviceorientierten Architektur (SoA). Eine SoA verfolgt das Ziel, durch definierte Schnittstellen und der Kapselung von Funktionalitaten die Austauschbarkeit, Wiederver- wendbarkeit und Vernetzbarkeit von Anwendungen herzustellen. Softwareanwendungen, sogenannte Dienste, konnen zur Realisierung von Geschaftsprozessen lose miteinander gekoppelt werden. Eine SoA besitzt zur Verwaltung und Identifikation vorhandener Dienste einen Verzeichnisdienst, in dem sich alle Dienste mit ihrer Adresse und einer Beschreibung registrieren. Dienste konnen sich gegenseitig uber diesen Verzeichnisdienst finden und ge- meinsam Prozesse realisieren. [Mel10] Im Gegensatz zu MAS sind die vorgestellten CPS- Architekturen konkreter, da sie die Integration mittels CPS beschreiben. Allerdings gehen die bestehenden Architekturen ebenfalls nicht auf die Prozesssicht fur Produktionsablaufe ein und geben keinen Hinweis, wie bestehende Produktionsumgebungen zu migrieren sind.

Eine neuere Architektur zur Realisierung von dezentralen Fertigungslinien ist die in der Technologie-lnitiative SmartFactory KL e.V. entstandene SmartFactoryKL Systemarchitektur. Sie verfolgt das Ziel, die mechatronische Wandelbarkeit zu verbessern, eine individualisierte Massenproduktion zu ermoglichen und eine durchgangige Vernetzung der beteiligten Kom- ponenten herzustellen. Hierzu unterteilt sie die im Kontext einer vollautomatischen Ferti- gungslinie vorhandenen Komponenten in funf Ebenen (siehe Abbildung 10). Auf der Produkt- Schicht befindet sich das zu fertigende Produkt, welches mittels eines integrierten Produkt- gedachtnisses den Prozess steuert und kurzfristige Anderungen an der Produktkonfiguration in den Fertigungsprozess ubermitteln kann. Die Produktionsschicht fasst alle Fertigungsmo- dule zusammen. Fur die angestrebte Wandelbarkeit mussen diese kurzfristig austauschbar sein und dedizierte Aufgaben ubernehmen. Die daruber liegende Versorgungsschicht ver- sorgt die Module mit alien notwendigen Medien und muss ebenfalls modular sein. Die Inte- grationsschicht bildet die Schnittstelle zwischen den Fertigungsmodulen und den IT- Systemen. Sie soil einen Echtzeit-Datenaustausch und die durchgangige Verfugbarkeit von Informationen sicherstellen. Hierzu verfugt sie uber offene Schnittstellen zur losen Kopplung der Systeme. Die Schnittstellen bieten einheitlich die relevanten Parameter aus den Ferti­gungsmodulen an und ermoglichen sowohl lesenden als auch schreibenden Zugriff darauf. Die IT-Systemschicht bildet schlussendlich ubergeordnete Systeme wie das ERP-System ab.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10 Die SmartFactoryKL Systemarchitektur (Quelle: [Gor+16a])

Kennzeichnend fur diese Softwaresysteme sind eine schnelle Anbindung mit geringem Auf- wand sowie eine Kapselung der Funktionalitaten. Fur den Betrieb muss der IT- Systemschicht ein digitales Abbild der physisch stattfindenden Prozesse vorliegen. [Gor+16a; Wey+17; Gor+16b] Die SmartFactoryKL Systemarchitektur beschreibt nicht nur die Struktursicht, sondern spezifiziert auch Schnittstellen fur die mechanische, elektrotechni- sche und informationstechnische Integration. Sie ist dadurch praxisnah fur die Implementie- rung, berucksichtigt aber nicht die Rolle des Menschen und der Logistik. Ferner erfordert sie ein Produktgedachtnis, was nicht immer gegeben ist.

Die Plattform Industrie 4.0 ist eine Vereinigung von u.a. Unternehmen, Verbanden, Wissen- schaft und Politik und strebt an, Deutschland als fuhrenden Ausruster fur und Nutzer von neuartigen digitalen Technologien zu positionieren. Eines der Arbeitsergebnisse zur Stan- dardisierung der Technologien ist das Referenzarchitekturmodell fur Industrie 4.0 (RAMI 4.0). Das darin beschriebene Klassifizierungssystem bietet die Moglichkeit, eine Technologie bzw. Problemstellung in die Dimensionen Hierarchielevel (in Anlehnung an IEC 61512/ 62264), Lebenszyklus (in Anlehnung an IEC 62890) und Abstraktionsebene ein- zuordnen. Daruber hinaus beschreibt RAMI 4.0 mit der Industrie 4.0-Komponente und der dazugehorigen Verwaltungsschale eine Architektur zur Einbindung von physischen Entitaten in eine gemeinsame Kommunikationsumgebung (siehe Abbildung 11). Jede Entitat wie z.B. ein Produkt, eine Anlage Oder ein Feldgerat, besitzt eine virtuelle Beschreibung. Die soge- nannte Verwaltungsschale fasst die Beschreibung in einer standardisierten Notation zusam-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11 RAMI 4.0-Architektur mit I4.0-Komponente und Verwaltungsschale [Ado+15]

men und ist die Schnittstelle zu einem gemeinsamen Kommunikationsnetzwerk. Dritte kon- nen die Informationen ohne aufwendige Konfiguration und Programmierung auslesen und interpretieren. Hierfur stellt die Verwaltungsschale sogenannte Sichten zur Verfugung, wel- che fur unterschiedliche Anwendungsfalle die hinterlegten Merkmale bundeln. Die physische Entitat und die Verwaltungsschale bilden zusammen die Industrie 4.0-Komponente. [Bun16; Ado+15] Sowohl RAMI 4.0 als auch die Verwaltungsschale befinden sich aktuell noch in der Entwicklung und Evaluierung und lassen keine Aussagen zur Integration in Prozesse zu. Auch das Industrial Internet Consortium, das amerikanische Pendant zur Plattform Indus­trie 4.0, erarbeitete eine Referenzarchitektur. Die Industrial Internet Reference Architecture (IIRA) ist ein offener, auf Standards basierender Ansatz, welcher generisch auf hoher Abs- traktionsebene branchenubergreifende Gemeinsamkeiten und Anwendungsfalle beschreibt. Sie definiert Sichtweisen fur unterschiedliche Anwender und deren Informationsbedurfnisse, gibt daruber hinaus allerdings keine Hinweise zu Rollen, strukturellen Zusammenhangen Oder Schnittstellen zwischen Entitaten der Produktion. [Lin+15] Obwohl IIRA disziplinuber- greifende Themen adressiert, ist die Prozesssicht nur auf einem abstrakten Niveau beruck- sichtigt.

Als abschlieliende Bewertung ist festzuhalten, dass sich die aus der Forschung kommenden agentenbasierten und holonischen Ansatze mangels Reproduzierbarkeit der Prozesse, Echt- zeitfahigkeit und fur die industrielle Praxis verfugbarer Entwicklungswerkzeuge nicht durch- setzen konnten [Lei09]. Dezentrale Architekturen wie die des Forschungsprojektes CyProS hingegen fokussieren die Struktursicht und lassen die Prozesssicht weitestgehend auften vor. Sie beschreiben Abhangigkeiten zwischen den in der Produktion Beteiligten, geben aber keine Auskunft uber z.B. die Ablaufe zur Auftragsabwicklung Oder Fehlerbehandlung. Trotz des hohen Stellenwerts von Schnittstellen in modularen und dezentralen Umgebungen defi- nieren sie nicht, welche Informationen zwischen den Entitaten auszutauschen sind. Praxis- getriebene Ansatze wie die SmartFactoryKL Systemarchitektur, RAMI 4.0 Oder IIRA befas- sen sich mit der Schnittstellendefinition. Sie befinden sich allerdings noch in der Entwicklung Oder erfordern in der Produktion nicht immer vorhandene Voraussetzungen wie ein Produkt- gedachtnis. Fast alle Architekturen liefern daruber hinaus keine Beschreibung, wie beste- hende Umgebungen zu migrieren sind.

2.1.3 Informationstechnische Schnittstellen und Kommunikation

2.1.3.1 Definition informationstechnischer Schnittstellen und Kommunikation

Fur die Realisierung dezentraler Architekturen bedarf es einheitlicher informationstechni­scher Schnittstellen zur Kommunikation zwischen den Entitaten. Eine Schnittstelle beschreibt den Beruhrungspunkt einer Entitat mit seiner Umwelt. Schnittstellen lassen sich nach der Art der Interaktion unterscheiden, z.B. kann eine mechanische Schnittstelle die physische Ver- bindung zwischen zwei Anlagen herstellen, eine funktionale Schnittstelle von einer Software bei einer anderen Software aufrufbare Funktionen beschreiben und eine elektrische Schnitt­stelle elektrische Signale austauschen. Die Beschreibung von Schnittstellen ist eine wichtige Voraussetzung fur die Umsetzung von Modularisierung. [Mil+98; Bib16; Lac+] Im Kontext dieser Arbeit ist eine informationstechnische Schnittstelle definiert als:

Eine informationstechnische Schnittstelle ist ein Interaktionspunkt der Informa- tions- und Datenverarbeitung einer Entitat (z.B. einer Arbeitsstation) mit seiner Umwelt (z.B. andere Arbeitsstationen Oder Softwaresysteme). Die informations- technische Schnittstelle ermdglicht den Austausch von Informationen und den Aufrufvon Diensten durch Dritte an der anbietenden Entitat.

Eine Schnittstelle nimmt die Rolle eines Vermittlers zwischen Ablaufen bei Dritten und Ablau- fen innerhalb der Entitat ein. Solange die Schnittstelle unverandert bleibt, konnen Ablaufe innerhalb der Entitat ohne Auswirkung auf Dritte beliebig geandert werden. Sie kapselt die internen Funktionalitaten und besteht sowohl aus Hardware als auch aus Software. Bezug- lich der internen Architektur einer Entitat werden informationstechnische Schnittstellen ubli- cherweise einer eigenen Ebene bzw. einem eigenen Bereich in der Entitat zugeordnet. Auf der untersten Schicht steuern das Betriebssystem und die internen Applikationen die Hard­ware der Entitat an. Eine optionale Middleware verbirgt die Heterogenitat der untersten Ebe­ne, bildet Bausteine fur die interne Wiederverwendbarkeit und bzw. Oder ermoglicht durch beispielsweise intuitivere Programmiermodelle eine einfachere Entwicklung. An diese Ebene setzt die Schnittstellen-Ebene an, die die erwahnte Verbindung interner Funktionalitaten mit der Umwelt herstellt. [Cou+05] Abbildung 12 zeigt ein Beispiel einer Kommunikationsschnitt- stelle aus einer holonischen Architektur.

Grundlage der Kommunikation zwischen informationstechnischen Schnittstellen und der Umwelt ist ein Kommunikationsprotokoll, das den Austausch von Nachrichten standardisiert und den digitalen Nachrichtenaustausch zwischen Mensch und Maschine sowie insbesonde- re Maschine und Maschine ermoglicht. Die International Telecommunication Union (ITU),

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12 Beispiel fur die Umsetzung einer informationstechnischen Schnittstelle in agen- tenbasierten bzw. holonischen Architekturen (Quelle: [Lei09])

welche den internationalen Betrieb von Telekommunikationsnetzen und -diensten koordi- niert, definiert ein Kommunikationsprotokoll als eine Sammlung von Regeln und syntakti- schen sowie semantischen Formaten, welche das Kommunikationsverhalten von Entitaten untereinanderfur die Ausfuhrung von Aufgaben regelt [ITU14].

Die syntaktischen Formate beschreiben, wie einzelne Symbole bzw. Zeichen zu Gruppen zusammenzufassen sind. Erst durch die Syntax werden aus ubertragenen Signalen Daten. Die semantischen Formate dienen dazu, Daten eine Bedeutung zu geben. Hierdurch ist es den bei der Kommunikation beteiligten Partnern moglich, die empfangenen Signale als In- formationen zu interpretieren. [Den12] Im Kontext der zuvor beschriebenen dezentral ge- steuerten Produktionen, in denen sich nicht nur die Art und Menge an Teilnehmern andern kann, sondern auch unbekannte Teilnehmer hinzukommen konnen, ist eine eindeutige und einheitliche Kommunikation zwingend notwendig.

Die bei der digitalen Interaktion zwischen Entitaten eingesetzten Protokolle lassen sich in unterschiedliche Ebenen einteilen, welche aufeinander aufbauen. Das international standar- disierte Open Systems Interconnection Modell (ISO/OSI-Modell) beschreibt auf sieben Ebe­nen - ausgehend von der Bitubertragung uber die Absicherung und Vermittlung bis hin zur Anwendung - die Zusammenhange und einsetzbaren Protokolle. Eine Ubersicht ist in Abbil­dung 13 dargestellt, wobei fur Details auf [Sch06], [Cou+05] Oder [Wik16c] verwiesen sei. Im Rahmen dieser Arbeit sind hierbei ausschliefilich die Protokolle der sechsten und siebten Schicht relevant, welche sich mit der Syntax und Semantik der ubertragenen Daten befas- sen. Kapitel 2.1.3.3 stellt einen Ausschnitt der Vielzahl an im industriellen Kontext vorhande- nen Kommunikationsprotokollen vor.

2.1.3.2 Methoden der Interprozesskommunikation

Die digitale Kommunikation lasst sich hinsichtlich der Netzwerktopologie und der Interpro­zesskommunikation unterscheiden. Da die Netzwerktopologie fur diese Arbeit eine unterge- ordnete Rolle spielt und die Sterntopologie fur die Anbindung von IT-Systemen und Anlagen- steuerung der Status quo ist, wird hier nicht weiter auf sie eingegangen. Eine vollstandigere Beschreibung von Topologien im Kontext der Produktion findet sich beispielsweise in [Wel+11] Oder [Sch06],

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13 Die sieben Schichten des ISO/OS-Modells (Quelle: [Sel10])

Neben der Topologie und den Protokollen ist bei der dezentralen Steuerung insbesondere die Interprozesskommunikation relevant. Sie beschreibt auf den hoheren Schichten des ISO/ OSI-Modells den Ablaut des Informationsaustausches zwischen Prozessen und Systemen. Beim Informationsaustausch zwischen zwei Systemen lassen sich die drei nachstehend be- schriebenen Methoden unterscheiden [Jed 16].

Bei der Request-Reply-Methode geht die Initiative fur den Informationsaustausch vom Nach- richtenempfanger aus. Dieser greift auf einen Dienst des Nachrichtensenders zu und fuhrt ihn aus. Hierzu muss der Empfanger vom Sender wissen, unter welcher Adresse er erreich- bar ist und welche Informationen er dem Dienst ubergeben kann bzw. von ihm zuruckbe- kommt. Anderungen nur an dem Sender Oder nur am Empfanger sowie kurzfristiges Hinzu- fugen neuer Empfanger sind nicht moglich bzw. erfordern groftere Anpassungen. Es handelt sich somit urn eine starke Kopplung zwischen Sender und Empfanger. Beispiele fur diese Art der Kommunikation sind das zyklische Abrufen von Informationen eines MES von SPSen einer Fertigungslinie Oder die Remote Method Invocation (RMI) in der Programmiersprache Java, die den Aufruf von Java-Methoden auf anderen Rechnern ermoglicht. Auch Webser- vices, die unter einem festen Identifikator (engl. Unified Resource Identifier; URI) alien Teil- nehmern eine Information bereitstellen, funktionieren nach diesem Prinzip. Moderne Inter- netplattformen wie z.B. Facebook Oder Twitter verwenden sogenannte Application Program­ming Interfaces (dt. Programmierschnittstellen; API), die Drittanwendungen einen Zugang zu internen Daten bereitstellen (siehe [Fac; Twi17]).

Die Callback-Methode ist auch als Publish-Subscribe-Methode bekannt. Der Nachrichten- empfanger registriert sich beim Nachrichtensender und abonniert dort ausgewahlte Nach- richten. Will der Sender eine Nachricht versenden, sendet er diese nur an die ihm bekannte Liste von Abonnenten. Die Initiative geht vom Sender aus. Zum Abonnieren von Nachrichten muss dem Empfanger sowohl der Sender als auch die zu abonnierende Nachricht bekannt sein, weshalb ebenfalls eine enge Kopplung vorliegt. Beispiele fur diese Form der Kommuni­kation sind Enterprise Service Busse. Ein Enterprise Service Bus empfangt als zentraler Vermittler-Dienst im Netzwerk alle Nachrichten und verteilt sie anhand eines vorliegenden Regelwerks an die relevanten Clients. Die Verwendung von Event Handlern in Java, mit wel- chen Klassen die Nachrichten anderer Klassen abonnieren konnen, ist ein weiteres Beispiel. Bei der ereignisbasierten Methode sendet der Nachrichtensender beim Eintreten eines Er- eignisses eine Nachricht an das Netzwerk. Der Sender hat keine Information, wer diese Nachricht empfangt bzw. ob sie von einem Teilnehmer verarbeitet wird. Die Nachrichtenemp- fanger entscheiden selbststandig, ob sie diese Nachricht verwerten Oder ignorieren. Die Initi­ative geht vom Sender aus, und es herrscht eine lose Kopplung zwischen den Teilnehmern, da diese sich nicht gegenseitig kennen mussen. Die Kommunikation zwischen Sender und dem zuvor erwahnten Enterprise Service Bus ist ein Beispiel hierfur. Der Sender sendet sei­ne Nachricht an den Vermittler ohne Kenntnis daruber, an wen sie weitergeleitet wird. Die Java-Swing-Bibliothek zur Gestaltung von Benutzungsoberflachen nutzt ebenfalls einen eventgetriebenen Ansatz, mit dem sie Benutzereingaben weiterleitet.

Die Request-Reply-Methode hat sich in der Vergangenheit insbesondere durch das Auf- kommen von SoA etabliert. Der Ansatz ist fur die Realisierung von Geschaftsprozessen mit- tels orchestrierter Softwaredienste geeignet. Die Callback- und ereignisbasierte Methode sind jungere Ansatze, welche mit der Internet-of-Things-Entwicklung Bekanntheit erlangten. Die Methoden sind insbesondere fur komplexe Prozesse und bei sich andernden Netzwerk- teilnehmern geeignet. Beide sind Weiterentwicklungen der SoA und wurden zwischenzeitlich in der Praxis als SoA 2.0 proklamiert (siehe z.B. [Bru+10; Com06; The+17]).

2.1.3.3 Bestehende Protokolle und Standards

Im Kontext der Industrie-4.0-Entwicklung sind eine Vielzahl an Kommunikationsprotokollen und Losungen aufgekommen, die die vorgenannten Methoden der Interprozesskommunika- tion verwenden. Im Folgenden wird eine Auswahl fur die Produktion relevanter Protokolle und Standards vorgestellt. Fur diese Arbeit ist dabei ausschlielJlich die Kommunikation zwi­schen Anlagensteuerungen wie z.B. SPS und ubergeordneten IT-Systemen wie z.B. MES und ERP-Systemen relevant. Betrachtet werden deshalb und u.a. aufgrund des vergangenen Erfolges und De-facto-Standards fur die Netzwerkkommunikation im Internet der Dinge Pro­tokolle, welche auf TCP/IP und Ethernet basieren. Ein Vergleich sowie weitere Protokolle finden sich beispielweise in [Her17b],

Die Open Platform Communications Unified Architecture (OPC UA), auch bekannt als IEC 62541, existiert seit 2008 und ist der Nachfolger von OPC Classic, zu welchem es abwarts- kompatibel ist. Wie in Abbildung 15 dargestellt, beschreibt OPC UA ein Informationsmodell, das in Kapitel 2.1.4.3 vorgestellt wird, und ein Protokoll fur den maschinenlesbaren Informa- tionsaustausch zwischen unterschiedlichen Geraten.

Dritte konnen mit OPC UA nicht nur Informationen aus Anlagensteuerungen auslesen, son- dern durch Methodenaufrufe (vgl. Callback-Methode) auch Aktivitaten in der Steuerung aus- losen. Es lasst sich eine ereignisorientierte Kommunikation umsetzen, welche Netzwerkver- kehr durch das zyklische Abfragen von Geraten (engl. Polling) vermeidet. Bei der Verwen­dung von OPC-UA kann fur die Datenubertragung zwischen zwei verschiedenen Protokollen gewahlt werden. Der Webservice-Ansatz basiert auf HTTP und dem Simple Object Access Protocol (SOAP) und bietet eine hohe Flexibilitat. Das Binarprotokoll hingegen ist auf Durch- satz und Ubertragungsgeschwindigkeit optimiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 15 Die OPC Unified Architecture (Quelle: [0PC15]

Ublicherweise wird bei der Realisierung einer OPC UA-basierten Kommunikation zwischen einem Client als lesende Anwendung und einem Server als informationsanbietende Anwen- dung unterschieden. Ein Gerat, welches sowohl Informationen anbietet als auch liest, imple- mentiert somit zwei unabhangig voneinander laufende Anwendungen. Abbildung 14 zeigt die Kommunikationsmoglichkeiten zwischen Client, Server und Client und Server unter Verwen- dung der Callback- und der ereignisbasierten Methode.

Weitere Eigenschaften von OPC UA sind u.a. die Plattformunabhangigkeit, die Serviceorien- tierung, Skalierbarkeit, Sicherheit und Interoperability. [OPC15; Dam+09] Aufgrund dieser Vorteile, der Abwartskompatibilitat und dem Ursprung in der industriellen Produktion wird OPC UA als De-facto-Standard fur die digitale Vernetzung der Produktion angesehen. [Spi16; Rot16]

Das Message Queue Telemetry Transport (MQTT) ist ein offenes, von der Organization for the Advancement of Structure Information Standards (OASIS) seit 2013 standardisiertes Pro- tokoll, das eine schlanke und domanenunabhangige Maschine-zur-Maschine (M2M)- Kommunikation ermoglicht. MQTT wurde von IBM mitentwickelt und war in der Vergangen- heit u.a. unter dem Namen „SCADA Protokoll“ zur Anbindung von Uberwachungssystemen in der Verfahrenstechnik bekannt. [MQT]

MQTT verwendet fur die Kommunikation die Publish-Subscribe-Methode. Clients veroffentli- chen Oder abonnieren Nachrichten von einem gemeinsamen Bus, dem Broker. Eine MQTT- Nachricht besteht aus einer Uberschrift (engl. Topic), einem Hinweis zur notwendigen Uber- tragungsqualitat (Qualitat des Dienstes; engl. Quality of Service) und einem frei beschreibba- ren Inhalt (engl. Payload). Das Abonnieren von Nachrichten beschrankt sich nicht auf feste Topics. Platzhalter und Hierarchien gruppieren Topics und ermoglichen den Empfang vorab unbekannter Nachrichten. [OAS14]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14 MOglichkeiten der Kommunikation in OPC UA (Quelle: [OPC12c])

TCP/IP ist das Standard-Protokoll von MQTT fur den Nachrichtenaustausch. Allerdings sind unter Einhaltung bestimmter Bedingungen auch andere Protokolle wie z.B. Zigbee geeignet. Fur die Datensicherheit bietet MQTT eine verschlusselte Verbindung sowie Authentifizierung von Clients am MQTT-Broker. Die Verwendung von Websockets ermoglicht es, lokal instal- lierte Browser ohne zusatzliche Software als MQTT-Clients zu nutzen. [OAS14; dc-17] MQTT-basierte Anwendungen finden sich nicht nur im Bereich des Auslesens von Sensoren, sondern auch bekannte Internetplattformen wie Facebook verwenden es. Neben der Ein- fachheit und Offenheit ist ein weiterer Vorteil von MQTT die Vielzahl an Werkzeugen zur Re- alisierung von MQTT-Losungen. Bekannte Beispiele sind der Enterprise Integration Bus von IBM Oder die graphische Oberflache Node-RED zur Realisierung von ereignisbasierten Ab- laufen zwischen Internet-der-Dinge-Geraten (siehe [IBM; JS 17] und Abbildung 16). Durch die Anwendungsvielfalt und den geringen Umsetzungsaufwand fur Prototypen erfreut sich MQTT einer hohen Beliebtheit. [Spi16]

Das Data Distributed Services (DDS) ist ein von der Object Management Group (OMG) ent- wickeltes und standardisiertes Datenaustauschformat fur die M2M-Kommunikation. Ziel von DDS ist es, eine effiziente, stabile und rechtzeitige Kommunikation in verteilten Systemen herzustellen. Ursprunglich wurde DDS 2004 fur Domanen wie der Finanzwirtschaft, der Flugverkehrskontrolle Oder fur Smart Grids geschaffen. [Obj15; Cor+]

DDS verwendet wie MQTT die Publish-Subscribe-Methode. Als Middleware zwischen dem Betriebssystem und der Anwendung ermoglicht es die technologieunabhangige Kommunika­tion mit Drittsystemen und ist unabhangig von bestimmten Programmiersprachen. DDS- Gerate konnen andere Netzwerkteilnehmer erkennen, sodass keine zentrale Registrierung Oder ein gemeinsamer Bus notwendig ist. Die Kommunikation erfolgt direkt zwischen den betroffenen Geraten. Durch ein komplexes Regelwerk fur die Qualitat der ubertragenen Da- ten lassen sich Bedingungen wie die Lebensdauer, gultige Latenzen und Transportprioritaten definieren. Die Beschreibung der Daten kann in gangigen Beschreibungssprachen wie XML erfolgen. [Cor+; Obj15]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 16 Beispiel fur die Kommunikation mittels MQTT unter Verwendung von IBM Bluemix als MQTT-Broker (Quelle: [Bin 15])

DDS wurde ursprunglich nicht fur die Produktion entwickelt, verfugt uber keine Sicherheits- mechanismen und ist nicht fur die Realisierung von Webservices geeignet. Dennoch wird es teilweise aufgrund von Eigenschaften wie der Interoperabilitat, der losen Kopplung von Gera- ten, der Erweiterbarkeit und der Skalierbarkeit im amerikanischen Raum als das Kommuni- kationsprotokoll der zukunftigen Produktion angesehen. [Cor+; Spi16]

Weitere Ansatze fur die Implementierung informationstechnischer Schnittstellen sind Web­services, die den Nachrichtenaustausch zwischen Diensten auf Basis der Request-Reply- Methode und der Extensible Markup Language (XML) realisieren. Bekannte Standards zur Datenbeschreibung sind SOAP und Web Service Description Language (WSDL) [Aus+04; Mel10]. Aus dem Bereich der agentenbasierten Systeme gibt es ferner noch die Agent Communication Language (FIPA-ACL), welche die Kommunikation und die Schnittstellen zwischen Agenten spezifiziert [Pos07],

2.1.4 Informationsmodelle und -modellierung

2.1.4.1 Eigenschaften, Arten und Abstraktionsklassen von Modellen

Die vorgenannten Standards und Protokolle beschreiben, wie Informationen beschrieben werden. Welche Inhalte zu beschreiben sind, definieren Informationsmodelle. Informations­modelle gehoren zur Gattung der Modelle und besitzen somit weitestgehend die gleichen Eigenschaften. Ziel eines Modells ist es, die in der Realitat gegebene Komplexitat zu redu- zieren, indem es nur die fur einen Sachverhalt relevanten Dinge abbildet. Modelle unterlie- gen dabei dem bewussten und unbewussten Wissen und den Praferenzen des Modellierers. AulJerdem sind Modelle ein Mittel zum Zweck und somit pragmatisch. Aufgrund dessen sind Modelle niemals vollstandig. [Kra+07; Sta73]

Modelle konnen graphisch Oder semantisch die Realitat abbilden. Graphische Modelle die- nen primar zur Visualisierung von Zusammenhangen und sind oftmals formalisiert. Beispiele hierfur sind CAD-Modelle aus der Konstruktion, Flussdiagramme aus der Informatik Oder Organigramme aus der Organisationslehre. Semantische Modelle wie beispielsweise Onto- logien sind weniger zur Representation materieller Gegenstande geeignet, sondern eher zur Darstellung des Denkens und der Wahrnehmung. Daruber hinaus bilden dynamische Model­le wie z.B. Vorgehensmodelle Oder Prozessmodelle Ablaufe ab. Statische Modelle hingegen reprasentieren Strukturen und Zusammenhange. Organigramme und UML Klassendiagram- me sind Beispiele hierfur. Ferner lassen sich stark formalisierte Darstellungsweisen wie z.B. die Modellierungssprachen UML Oder BPMN, und wenig formalisierte Modelle wie z.B. Skiz- zen unterscheiden. Eine weitere Dimension zur Unterscheidung von Modellen ist der Zweck. Beschreibungsmodelle dokumentieren einen vorliegenden Sachverhalt. Simulationsmodelle wie z.B. Wettersimulationen werden fur die Vorhersage verwendet, und Erklarungsmodelle versuchen, Zustande durch Hypothesen zu erklaren. [Kra+07; WH13]

Neben der Art unterscheiden sich Modelle auch im Abstraktionsgrad. Sie lassen sich nach [Sch02] in vier Abstraktionsklassen einteilen, welche in ahnlicher Form bereits in [Str96] identifiziert wurden. Die erste Klasse ist, ahnlich wie ein Foto, ein Abbild eines realen und zu einem bestimmten Betrachtungszeitpunkt vorliegenden Sachverhaltes, d.h. sie bildet Entita- ten ab und stellt sie in einen Zusammenhang. Sie ist eine der wichtigsten Abstraktionsklas-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 17 Abstraktionsebenen der Modellierung (Quelle: [Sch02])

sen bei der Ist-Analyse, da sie die fur die Betrachtung relevanten Entitaten identifiziert. Die zweite Abstraktionsklasse abstrahiert die Entitaten und ordnet sie Entitatstypen mit Attributen zu. Diese Klasse beschreibt somit fur einen Anwendungsfall bzw. eine Domane allgemein- gultig vorkommende Objekte. Die dritte Abstraktionsklasse abstrahiert die Entitatstypen, in- dem sie diese den fur die Anwendung relevanten Gruppen zuordnet. Diese Abstraktionsklas­se wird auch als Meta-Modell bezeichnet. Die vierte Klasse, die Meta2-Klasse, definiert fur die Gruppen ubergeordnete, elementare Grundtypen. Der Ubergang zwischen den Klassen ist flie&end und teilweise nicht eindeutig moglich. Der Begriff „Objekt“ wird je nach Domane und Darstellung als Synonym fur Entitat verwendet. Abbildung 17 zeigt den Zusammenhang der Abstraktionsklassen anhand eines Beispiels.

2.1.4.2 Definition und Relevanz von Informationsmodellen

Der Begriff „lnformationsmodell“ ist in der Wirtschaftsinformatik weit verbreitet und wurde mit der Einfuhrung von IT-Systemen fur den administrativen Bereich in Unternehmen vermehrt verwendet. Auch wenn sich die Bedeutung des Begriffs uber die Zeit veranderte und weiter gefasst wurde, besteht bis zu einem gewissen Detaillierungsgrad eine Gemeinsamkeit bei den Definitionen. [Will3]

Eine der altesten Definitionen fur ein Informationsmodell stammt von [Pic+94], Sie definieren Informationsmodelle als eine strukturierte Beschreibung informationsbezogener Aspekte ei- nes betrieblichen Sachverhalts auf konzeptioneller Ebene. Im gleichen Jahr betonte [Sch93] in ihrer Definition, dass Informationsmodelle nie die gesamte Umgebung abbilden, sondern nur die fur den Sachverhalt relevanten Dinge. [Teu99] beschrankt sich bei einem Informati­onsmodell nicht nur auf die informationsbezogenen Aspekte, sondern beschreibt Informati­onsmodelle auch als ein Abbild des Unternehmens zur Unterstutzung der Softwareintegrati- on. Seine Definition ist abstrakter und deutlich weiter gefasst als die im gleichen Jahr publi- zierte Definition von [Lee99]. Eine oft zitierte Definition ist die von [Wes+01]. Ahnlich wie [Lee99] ist ihrer Ansicht nach ein Informationsmodell eine technologieunabhangige Abstrak- tion von Entitatstypen, Eigenschaften, Attributen und Operationen in einer organisierten Um­gebung. [Pra+03] befassen sich speziell mit der Abgrenzung eines Informationsmodells von einem Datenmodell. Im Gegensatz zu einem Datenmodell, das z.B. die konkrete Datenstruk- tur einer Datenbank beschreibt, ist ein Informationsmodell immer technologieunabhangig und sein Detaillierungsgrad abhangig von den Bedurfnissen des Modellierers. [Bec+04] sehen Informationsmodelle nicht nur als Werkzeug fur die Software-, sondern auch fur die Organi- sationsentwicklung. In Anlehnung an die Eigenschaften von Modellen allgemein betonen sie, dass ein Informationsmodell immer durch die subjektive Sicht des Modellierers gepragt ist. Basierend auf den vorgestellten Definitionen wird im Rahmen dieser Arbeit unter einem In­formationsmodell folgendes verstanden:

Ein Informationsmodell ist eine technologieunabhangige Beschreibung von Funk- tionen, Beziehungen und Attributen von Entitatstypen, urn Anwendungsfaile zu realisieren. Zweck des Informationsmodells ist die Unterstutzung bei der Integra- tion von IKT in vorgegebene Strukturen und Prozesse.

Abbildung 18 stellt den Zusammenhang zwischen einem Informationsmodell, der Realitat und einem Datenmodell im Kontext eines Softwareentwicklungsprojektes exemplarisch dar. Das Informationsmodell bildet die Realitat in einer eigenen Sprache ab, was die Bildung von Modellen fur die Entwicklung und Integration erleichtert.

Die Relevanz von Informationsmodellen ist in der Praxis unumstritten [Loo+07]. Insbesonde- re bei der Kommunikation zwischen Fachabteilungen, die den Anwendungsfall kennen, und IT-Abteilungen, die das technische Fachwissen fur die Implementierung besitzen, helfen In­formationsmodelle, den Sachverhalt fur die Entwickler zu verdeutlichen und ihn zielgerichte- ter durch IT-Systeme abzubilden bzw. zu unterstutzen. [Sch93; Pic+94] Informationsmodelle finden insbesondere im Rahmen der Anforderungsdefinition und Konzeption Anwendung (siehe Abbildung 19 und Abbildung 20).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 18 Informationsmodelle im Kontext des Softwareentv/icklungsprozesses

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 19 Konzepte zur Abstraktion der Wirklichkeit durch ein Informationsmodell (Quelle: [Dell 13])

Bestehende Studien stellten dabei test, dass die Informationsmodellierung in der Praxis bei der Software- und Datenbankentwicklung sowie der Optimierung und Dokumentation von Geschaftsprozessen besondere Aufmerksamkeit bekommt. Insbesondere bei der Konfigura- tion und Integration in bestehende Umgebungen sind Informationsmodelle nutzlich. Grenzen sehen die Befragten u.a. bei der Handhabung komplexer Systeme. [Loo+07]

Durch die technologieunabhangige Betrachtung schranken Informationsmodelle die techni- sche Realisierung in einem Entwicklungsprojekt nicht ein. Daruber hinaus ermoglichen sie in einem gewissen Rahmen die spatere Ubertragung auf ahnliche Problemstellungen Oder die Realisierung des Projektes mittels anderer Tech nolog ien. In der Produktion sind deshalb mit der Zeit diverse, teilweise standardisierte Informationsmodelle entstanden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 20 Rolle des Informationsmodells im Vorgehen zur Entwicklung von Informations- systemen(Quelle: [De(l13])

2.1.4.3 Bestehende Standards und Informationsmodelle

Das folgende Unterkapitel stellt eine Auswahl bestehender Informationsmodelle vor. Hierbei wird nicht nur auf die fur diese Arbeit relevanten Modelle eingegangen, sondern auch auf die Vielfalt der modellierbaren Sachverhalte und Darstellungsformen. Wie zuvor in Kapi- tel 2.1.3.3 beschrieben, enthalt OPC UA ein Kommunikationsprotokoll fur den einheitlichen Datenaustausch zwischen unterschiedlichen Geraten. Daneben definiert es im Address Space Model zusatzlich ein Informationsmodell. Bei dem Address Space Model handelt es sich urn ein Meta-Modell mit vordefinierten Typen zur Definition eigener, semantisch be- schriebener Informationsmodelle. Zu diesen Grundtypen zahlen Nodes (dt. Knoten) und Re­ferences (dt. Beziehungen). Attribute dienen dazu, Nodes naher zu beschreiben. Nodes un- terscheiden sich in Nodes, welche Instanzen reprasentieren, und Nodes, welche Typen be­schreiben, die dann wiederum instanziiert werden konnen. Die wichtigsten Grundtypen von Nodes sind Objects, Variables und Methods. Objects dienen der Ordnung und Bildung von Gruppen. Variables reprasentieren Werte, die z.B. Dritte auslesen und andern konnen. Me­thods sind Funktionen, die von aulien angesprochen intern eine Aktion auslosen. Refe­rences beschreiben Beziehungen zwischen Nodes und verweisen immer von einem Quell- knoten auf einen Zielknoten. Durch unterschiedliche Typen von References lassen sich Ab- hangigkeiten zwischen Nodes wie z.B. „X ist Abstraktion von Y“ Oder „X organisiert Y“ be­schreiben. Auf Basis dieses Grundgerustes leitet [OPC12], der funfte Teil der OPC UA Spe- zifikation, die unterschiedlichen Subtypen von Nodes und References ab und definiert zwin- gend notwendige sowie optionale Attribute. Hierdurch konnen Entwickler domanenspezifi- sche Einschrankungen vornehmen und das zu instanziierende Informationsmodell definie- ren. Abbildung 21 zeigt, wie sich die einzelnen Typen des Meta-Modells zur Informationsmo- dellierung nutzen lassen. [Dam+09; OPC12a]

Neben dem in OPC UA beschriebenen Informationsmodell existieren ferner sogenannte Companion Specifications, welche beschreiben, wie existierende Informationsmodelle mithil- fe des in OPC UA beschriebenen Metamodells zu konvertieren sind. Beispiele hierfur sind Companion Specifications fur Standards und Spezifikationen wie FDI, PLCopen, ISA95 und MTConnect (siehe z.B. [OPC+10; OPC13; OPC+12b]).

MTConnect ist ein ebenfalls seit 2008 existierender, offener, herstellerubergreifender und erweiterbarer Standard zur XML-basierten Beschreibung von Werkzeugmaschinen von der Unternehmensebene bis zur Feldgerateebene. Ziel von MTConnect ist es, die Datenakquisi- tion von Geraten und Anwendungen zu verbessern und eine Plug’n’Play-Fahigkeit zu ermog- lichen, d.h. MTConnect ersetzt Oder erweitert nicht bestehende Funktionen eines Gerates, sondern ermoglicht Dritten einen lesenden Zugriff darauf. [MTC14a; OPC+12b]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 22 MTConnect zugrundeliegende Architektur (Quelle: [OPC+12b])

vice-Entitatstypen gruppieren. Jedes Device unterteilt sich wiederum in Components. Com­ponents sind ebenfalls Container fur Component- und Subcomponent-Entitatstypen, welche physische Oder logische Teile einer Anlage reprasentieren. Unterschiedliche Typen von Components ermoglichen die Klassifizierung und einheitliche Beschreibungen von Eigen- schaften je Typ. Eine Component vom Typ Axes reprasentiert beispielsweise ein Feldgerat in einer Anlage, das rotierende Oder lineare Bewegungen ausfuhrt, und der Typ Sensor ist spe- zialisiert auf das Beschreiben von Messwerten eines Sensors. Abbildung 23 zeigt ein Bei- spiel fur eine mogliche Hierarchie zur Representation einer Anlage. Neben diesen Entitatsty- pen zur Beschreibung der Struktur, der Zusammenhange und der Art von physischen Oder logischen Komponenten existiert das Objekt Dataltem, das die fur Dritte lesbaren Informatio- nen vereint. Neben zwingend erforderlichen Attributen konnen optionale Attribute im Datal­tem definiert werden. Ein Dataltem enthalt zum einen administrative Angaben wie die Identi- fikationsnummer, den Namen, die Kategorie, den Typ der gemessenen Daten, die Wiederho- lungsrate und die Art des angebotenen Wertes (z.B. aktueller Wert, Durchschnittswert). Zum anderen enthalt es technische Parameter wie z.B. die Position einer Linearachse Oder die vorliegende Temperatur. Die Informationen lassen sich durch Angabe von Eigenschaften eines Wertes semantisch beschreiben. Eine Zuordnung von angebotenen Informationen zu Unternehmensprozessen ist allerdings nicht gegeben. Abbildung 24 zeigt die Struktur eines Data Items und Beispiele fur diese Attribute. [MTC14b]

Der US-Standard ISA 88 fur Steuerungssysteme von Batch-Produktionsprozessen sowie das lEC-aquivalent 61512-01 beschreiben die mit am altesten und bekanntesten Informations- modelle im Produktionsumfeld. Sie definieren eine Terminologie, Daten und Strukturen zur Beschreibung von Komponenten und Prozessen fur die Anbindung von Prozesssteuerungs- systemen an Batch-Produktionsprozesse, wie sie z.B. die Chemie- und Pharmabranche nutzt. Ziel ist es, durch die Modularisierung von Funktionalitaten und Strukturen mit definier-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 23 Beispiel fur ein Informationsmodell zur Representation einer Anlage

(Quelle: [MTC14b])

[...]

• Hochschule: Rheinland-Pfälzische Technische Universität Kaiserslautern-Landau (Fachbereich Maschinenbau und Verfahrenstechnik)
• Note: summa cum laude
• Autor: Dennis Kolberg (Autor:in)
• Erscheinungsjahr: 2018
• Seiten: 200
• Katalognummer: V462672
• ISBN (eBook): 9783668926899
• ISBN (Buch): 9783668926905
• Sprache: Deutsch
• Schlagworte: Industrie 4.0, Digitalisierung, Lean Production, Informationsmodellierung, Lean Management, Systems Engineering