Entwicklung datenbasierter Produkt-Service Systeme: Ein Ansatz zur Realisierung verfügbarkeitsorientierter Geschäftsmodelle [1. Aufl. 2019] 978-3-662-59642-5, 978-3-662-59643-2

Table of contents :
Front Matter ....Pages I-XIII
Innovative Serviceprodukte für individualisierte, verfügbarkeitsorientierte Geschäftsmodelle (Patrick Kölsch, Jan C. Aurich)....Pages 1-3
Grundlagen zu Produkt-Service Systemen (Patrick Kölsch, Jan C. Aurich, Christoph F. Herder)....Pages 5-15
Konzeption verfügbarkeitsorientierter Geschäftsmodelle (Patrick Kölsch, Jan C. Aurich, Christoph F. Herder, Viviane Zimmermann)....Pages 17-30
Entwicklung intelligenter, kommunikationsfähiger Komponenten (Paaranan Sivasothy, Dani Bechev, Horst Brehm, Georgis Bulun, Claudia Glenske, Julian Imwalle et al.)....Pages 31-44
Intelligentes Informationsmanagement für verfügbarkeitsorientierte Geschäftsmodelle (Thomas Eickhoff, Hristo Apostolov, Christian Donges, Matthias Fischer, Jens C. Göbel, Michael Grethler et al.)....Pages 45-108
Anwendungsfall GRIMME (Paaranan Sivasothy, Jan C. Aurich, Dani Bechev, Horst Brehm, Georgis Bulun, Claudia Glenske et al.)....Pages 109-168
Anwendungsfall John Deere (Thomas Eickhoff, Hristo Apostolov, Jan C. Aurich, Christian Donges, Matthias Fischer, Jens C. Göbel et al.)....Pages 169-184
Anwendungsfall BHN/Lenze/Schaeffler (Daniel Olivotti, Hristo Apostolov, Dani Bechev, Horst Brehm, Georgis Bulun, Christian Donges et al.)....Pages 185-230
Generische Ergebnisse der Geschäftsmodellentwicklung (Viviane Zimmermann, Jan C. Aurich, Christoph F. Herder, Lars Holländer, Patrick Kölsch)....Pages 231-239
Zusammenfassung und Fazit (Patrick Kölsch, Jan C. Aurich)....Pages 241-246
Back Matter ....Pages 247-255

Citation preview

Jan C. Aurich Walter Koch Patrick Kölsch Christoph Herder Hrsg.

Entwicklung datenbasierter Produkt-Service Systeme Ein Ansatz zur Realisierung verfügbarkeitsorientierter Geschäftsmodelle

Entwicklung datenbasierter Produkt-Service Systeme

Jan C. Aurich  •  Walter Koch Patrick Kölsch  •  Christoph Herder Hrsg.

Entwicklung datenbasierter Produkt-Service Systeme Ein Ansatz zur Realisierung verfügbarkeitsorientierter Geschäftsmodelle

Hrsg. Jan C. Aurich Lehrstuhl für Fertigungstechnik und Betriebsorganisation (FBK) Technische Universität Kaiserslautern Kaiserslautern, Deutschland Patrick Kölsch Lehrstuhl für Fertigungstechnik und Betriebsorganisation (FBK) Technische Universität Kaiserslautern Kaiserslautern, Deutschland

Walter Koch Advanced R&D Engineering Schaeffler AG Herzogenaurach, Deutschland Christoph Herder Lehrstuhl für Fertigungstechnik und Betriebsorganisation (FBK) Technische Universität Kaiserslautern Kaiserslautern, Deutschland

ISBN 978-3-662-59642-5    ISBN 978-3-662-59643-2  (eBook) https://doi.org/10.1007/978-3-662-59643-2 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Springer Vieweg © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen etc. in diesem Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die Berechtigung zur Benutzung unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des Markenrechts. Die Rechte des jeweiligen Zeicheninhabers sind zu beachten. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag, noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Springer Vieweg ist ein Imprint der eingetragenen Gesellschaft Springer-Verlag GmbH, DE und ist ein Teil von Springer Nature. Die Anschrift der Gesellschaft ist: Heidelberger Platz 3, 14197 Berlin, Germany

Vorwort

Im Rahmen des Programms „Innovationen für die Produktion, Dienstleistung und Arbeit von morgen“ hat das Bundesministerium für Bildung und Forschung (BMBF) mehrere Projekte gefördert, um die Produktions- und Dienstleistungsprozesse effizient und umweltgerecht weiterzuentwickeln. Der Entwicklungstrend von der industriellen Wirtschaft hin zu einer Dienstleistungsökonomie ist heute bereits Realität. Dienstleistungen stellen auch weiterhin einen großen Wachstumsmarkt dar, in dem viele Innovationen möglich erscheinen. In Verbindung mit dem Zukunftsprojekt Industrie 4.0 und den heute verfügbaren (Internet-) Technologien ergeben sich viele neue Möglichkeiten, um Innovationen im Dienstleistungsbereich in neuen Geschäftsmodellen zu realisieren. Ein Zukunftsfeld im Bereich der neuen Geschäftsmodelle liegt darin, die Nachfrage nach garantierten Verfügbarkeiten für Investitionsgüter zu bedienen. Allerdings steckt für die Unternehmen in garantierten Zusagen einer Verfügbarkeit an die Kunden ein großes unternehmerisches Risiko. Häufig sind den Anbietern von Investitionsgütern die Einsatzbedingungen ihrer Produkte im Feld nicht so genau bekannt. Ausfälle können vorkommen oder die Vorhersagen zum Verschleiß sind nicht präzise genug. Die Zusage der Verfügbarkeit eines technischen Produktes muss bereits bei der Entwicklung des Produktes berücksichtigt werden und sie hat auch Auswirkungen auf die Gestaltung der Produktionsprozesse. Mit Beginn der Nutzungsphase des Produktes müssen die Services für den Kunden bereitstehen. In allen Phasen sind häufig mehrere Partner beteiligt, speziell der Service für ein Produkt ist häufig ausgelagert. Nur wenige Unternehmen können heutzutage von sich behaupten, dass sie alle erforderlichen Kompetenzen besitzen, die ein verfügbarkeitsorientiertes Geschäftsmodell erfordert. Damit verfügbarkeitsorientierte Geschäftsmodelle funktionieren, muss das gesamte Wertschöpfungsnetzwerk, bestehend aus Entwicklungs-, Produktions- und Servicenetzwerk der Partner reibungsfrei zusammenarbeiten. Somit sind in dem Wertschöpfungsnetzwerk neben den technischen Möglichkeiten der Kommunikation auch neue Fähigkeiten der Zusammenarbeit zwischen eigenständigen Unternehmen erforderlich. Die Kunden erwarten – selbstverständlich – weiterhin ein exzellentes Produkt und einen nahtlosen Service. Dabei ist es dem Kunden egal, welcher Partner aus dem Netzwerk für die Leistungserbringung verantwortlich ist. V

VI

Vorwort

In unserem Beitrag werden drei Aspekte beleuchtet. Im ersten Abschnitt beschreiben wir die Entwicklung von verfügbarkeitsorientierten Geschäftsmodellen. Ausgehend von unterschiedlichen Ausprägungen vom Serviceverständnis gibt es mehrere Möglichkeiten, Verfügbarkeiten anzubieten. Aus den unterschiedlichen Ansätzen haben wir die Gemeinsamkeiten extrahiert und eine generische Methodik zur Gestaltung von verfügbarkeitsorientierten Geschäftsmodellen beschrieben. Im zweiten Abschnitt geht es um die Ermittlung des aktuellen Betriebszustandes eines Investitionsgutes beim Kunden, die Erfassung und Verarbeitung der Felddaten und die Entwicklung von Vorhersagemodellen, um daraus Aussagen zum Erbringen von Serviceleistungen abzuleiten. Im dritten Abschnitt, dem umfangreichsten in diesem Buch, wird anhand von drei Demonstratoren aufgezeigt, wie sich produzierende Unternehmen den Herausforderungen einer Erweiterung ihres Leistungsangebotes gestellt haben. Das vorliegende Werk gibt ihnen einen schnellen und dennoch umfassenden Überblick über die Ergebnisse und Anwendungen des Verbundforschungsprojektes InnoServPro. Herzogenaurach, im Mai 2019 Kaiserslautern, im Mai 2019

Walter Koch Jan C. Aurich

Inhaltsverzeichnis

1 Innovative Serviceprodukte für individualisierte, verfügbarkeitsorientierte Geschäftsmodelle. . . . . . . . . . . . . . . . . . . . . . . . . . .   1 Patrick Kölsch und Jan C. Aurich 2 Grundlagen zu Produkt-Service Systemen. . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5 Patrick Kölsch, Jan C. Aurich und Christoph F. Herder 2.1 Definition eines Produkt-Service Systems����������������������������������������������������   5 2.1.1 System und soziotechnisches System ����������������������������������������������   6 2.1.2 Sachprodukt��������������������������������������������������������������������������������������   7 2.1.3 Serviceprodukt����������������������������������������������������������������������������������   7 2.1.4 Netzwerke von Akteuren������������������������������������������������������������������   8 2.1.5 Unterstützende Infrastruktur ������������������������������������������������������������   8 2.1.6 Datenbasierte Produkt-Service Systeme ������������������������������������������   9 2.2 Geschäftsmodelle für Produkt-Service Systeme������������������������������������������   9 2.3 Verfügbarkeit������������������������������������������������������������������������������������������������  12 Literatur������������������������������������������������������������������������������������������������������������������  14 3 Konzeption verfügbarkeitsorientierter Geschäftsmodelle . . . . . . . . . . . . . . . .  17 Patrick Kölsch, Jan C. Aurich, Christoph F. Herder und Viviane Zimmermann 3.1 Anforderungen an das Konzept zur Entwicklung von verfügbarkeitsorientierten Geschäftsmodellen ��������������������������������������������  18 3.2 Konzept zur Entwicklung von verfügbarkeitsorientierten Geschäftsmodellen��������������������������������������������������������������������������������������  19 Literatur������������������������������������������������������������������������������������������������������������������  30

VII

VIII

Inhaltsverzeichnis

4 Entwicklung intelligenter, kommunikationsfähiger Komponenten. . . . . . . . .  31 Paaranan Sivasothy, Dani Bechev, Horst Brehm, Georgis Bulun, Claudia Glenske, Julian Imwalle, Andrej Keksel, Ralf Mattukat, Bernd Sauer und Jörg Seewig 4.1 Identifikation servicerelevanter Komponenten ��������������������������������������������  32 4.2 Analyse der Ausfallmechanismen����������������������������������������������������������������  34 4.3 Entwicklung von Überwachungskonzepten��������������������������������������������������  35 4.4 Sensorentwicklung����������������������������������������������������������������������������������������  37 4.5 Physikalische Modellierung��������������������������������������������������������������������������  38 4.6 Signalverarbeitung und Datenvoranalyse�����������������������������������������������������  40 4.7 Schnittstellendefinition und Datenvermittlung in die Cloud������������������������  41 Literatur������������������������������������������������������������������������������������������������������������������  44 5 Intelligentes Informationsmanagement für verfügbarkeitsorientierte Geschäftsmodelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  45 Thomas Eickhoff, Hristo Apostolov, Christian Donges, Matthias Fischer, Jens C. Göbel, Michael Grethler, Julian Imwalle, Ralf Mattukat, Lan Liu, Kai Pankrath, Frank Zeihsel und Jörg Richter 5.1 Definition von Anforderungen an das Informationsmanagement ����������������  46 5.1.1 Kategorisierung der Teil-Anforderungen aus den Use-Cases����������  46 5.1.2 Aus Kategorien werden Anforderungen ������������������������������������������  47 5.2 Entwicklung einer Gesamtmodellierungssystematik für Produkt-Service Systeme ��������������������������������������������������������������������������������������������������������  49 5.2.1 PSS-Gesamtmodellierungssystematik����������������������������������������������  50 5.2.2 Beispielhafte Anwendung der PSS-­ Gesamtmodellierungssystematik ��������������������������������������������������  53 5.3 Konfiguration der Kommunikationsplattform����������������������������������������������  59 5.3.1 Umsetzung der Anforderungen ��������������������������������������������������������  59 5.3.2 Datenübermittlung����������������������������������������������������������������������������  60 5.3.3 Die Cloud-Server der IT-Infrastruktur����������������������������������������������  60 5.4 Entwicklung der Business Analytics������������������������������������������������������������  62 5.4.1 Datenverarbeitung ����������������������������������������������������������������������������  63 5.4.2 Business Analytics im Vorhaben������������������������������������������������������  66 5.4.3 Softwarewerkzeuge zur Analyse von Daten ������������������������������������  69 5.5 Entwicklung des Back-Ends und Front-Ends ����������������������������������������������  73 5.5.1 Entwicklung eines fachlichen Datenmodells������������������������������������  73 5.5.2 Implementierung des Back-Ends������������������������������������������������������  77 5.5.3 Entwicklung des Maschinen-Front-Ends������������������������������������������  82 5.5.4 Maschinenunabhängige Front-Ends�������������������������������������������������  87 5.5.5 Test und Verifikation der Front-Ends und des Back-Ends����������������  89

Inhaltsverzeichnis

IX

5.6 Integration der Subsysteme in und Verifikation der Kommunikationsplattform����������������������������������������������������������������������������  95 5.6.1 Integration der Business Analytics, Back-End, Front-End ��������������  95 5.6.2 Test und Verifikation der Kommunikationsplattform������������������������ 100 Literatur������������������������������������������������������������������������������������������������������������������ 107 6 Anwendungsfall GRIMME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Paaranan Sivasothy, Jan C. Aurich, Dani Bechev, Horst Brehm, Georgis Bulun, Claudia Glenske, Michael Grethler, Christoph F. Herder, Julian Imwalle, Andrej Keksel, Patrick Kölsch, Ralf Mattukat, Gerald Wessel, Bernd Sauer, Jörg Seewig, Frank Zeihsel und Viviane Zimmermann 6.1 Ausgangssituation bei der GRIMME Landmaschinenfabrik GmbH & Co. KG������������������������������������������������������������������������������������������������������ 111 6.2 Spezifische Konzeption eines verfügbarkeitsorientierten Geschäftsmodells bei der GRIMME Landmaschinenfabrik GmbH & Co. KG���������������������������� 112 6.3 Entwicklung intelligenter, kommunikationsfähiger Komponenten im Use-Case GRIMME�������������������������������������������������������������������������������������� 118 6.3.1 Identifikation servicerelevanter Komponenten �������������������������������� 119 6.3.2 Analyse der Ausfallmechanismen���������������������������������������������������� 119 6.3.3 Entwicklung von Überwachungskonzepten�������������������������������������� 120 6.3.4 Sensorentwicklung���������������������������������������������������������������������������� 124 6.3.5 Physikalische Modellbildung������������������������������������������������������������ 138 6.3.6 Signalverarbeitung und Datenvoranalyse ���������������������������������������� 149 6.3.7 Schnittstellendefinition und Datenvermittlung in die Cloud������������ 157 6.4 Ausgewählte Elemente des intelligenten Informationsmanagements���������� 159 6.4.1 Entwicklung der Business Analytics������������������������������������������������ 159 6.4.2 Entwicklung des Maschinen-Front-Ends bei GRIMME������������������ 162 Literatur������������������������������������������������������������������������������������������������������������������ 168 7 Anwendungsfall John Deere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Thomas Eickhoff, Hristo Apostolov, Jan C. Aurich, Christian Donges, Matthias Fischer, Jens C. Göbel, Christoph F. Herder, Patrick Kölsch, Claudia Schrank, Siegfried Trendler und Viviane Zimmermann 7.1 Einleitung������������������������������������������������������������������������������������������������������ 170 7.2 Spezifische Konzeption eines verfügbarkeitsorientierten Geschäftsmodells bei der John Deere GmbH & Co. KG������������������������������������������������������������ 174 7.3 Ausgewählte Elemente des intelligenten Informationsmanagements���������� 178 7.3.1 Entwicklung des Back-Ends ������������������������������������������������������������ 179 7.3.2 Entwicklung des Front-Ends������������������������������������������������������������ 182 Literatur������������������������������������������������������������������������������������������������������������������ 184

X

Inhaltsverzeichnis

8 Anwendungsfall BHN/Lenze/Schaeffler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Daniel Olivotti, Hristo Apostolov, Dani Bechev, Horst Brehm, Georgis Bulun, Christian Donges, Sonja Dreyer, Thomas Eickhoff, Matthias Fischer, Claudia Glenske, Jens C. Göbel, Simon Graf, Michael Grethler, Julian Imwalle, Andrej Keksel, Markus Kiele-Dunsche, Ralf Mattukat, Rolf Rettinger, Bernd Sauer, Jörg Seewig, Paaranan Sivasothy, Heiko Stichweh und Frank Zeihsel 8.1 Einleitung������������������������������������������������������������������������������������������������������ 186 8.2 Spezifische Konzeption eines verfügbarkeitsorientierten Geschäftsmodells�������� 188 8.3 Entwicklung intelligenter, kommunikationsfähiger Komponenten�������������� 192 8.3.1 Sensorausstattung der Demonstratormaschine �������������������������������� 192 8.3.2 Thermisches Modell������������������������������������������������������������������������� 197 8.3.3 Konzept zur Realisierung von Wartungsanzeigen anhand eines Beispiels�������������������������������������������������������������������������������������������� 199 8.4 Ausgewählte Elemente des Informationsmanagements�������������������������������� 201 8.4.1 Entwicklung der Business Analytics������������������������������������������������ 201 8.4.2 Entwicklung des Back-Ends ������������������������������������������������������������ 212 8.4.3 Entwicklung der Front-Ends ������������������������������������������������������������ 217 8.5 Realisierung des verfügbarkeitsorientierten Geschäftsmodells�������������������� 226 Literatur������������������������������������������������������������������������������������������������������������������ 230 9 Generische Ergebnisse der Geschäftsmodellentwicklung. . . . . . . . . . . . . . . . . 231 Viviane Zimmermann, Jan C. Aurich, Christoph F. Herder, Lars Holländer und Patrick Kölsch 9.1 Generisches verfügbarkeitsorientiertes Geschäftsmodell und -ausprägungen���������������������������������������������������������������������������������������������� 232 9.2 Generisches Wertschöpfungsnetzwerk für verfügbarkeitsorientierte Geschäftsmodelle������������������������������������������������������������������������������������������ 237 Literatur������������������������������������������������������������������������������������������������������������������ 239 10 Zusammenfassung und Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Patrick Kölsch und Jan C. Aurich Anhang. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Stichwortverzeichnis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Über die Herausgeber und die Autoren

Prof. Dr.-Ing. Jan C. Aurich  leitet den Lehrstuhl für Fertigungstechnik und Betriebsorganisation (FBK) an der TU Kaiserslautern. Seine Forschungsinteressen liegen in den Bereichen Fertigungstechnologie, Mikrobearbeitung, Cyber-physische Produktionssysteme, Life Cycle Engineering, Produkt-Service Systeme und nachhaltige Produktion. Professor Aurich ist Fellow der International Academy for Production Engineering (CIRP), Mitglied der Wissenschaftlichen Gesellschaft für Produktionstechnik (WGP) und Mitglied der Deutschen Akademie für Technikwissenschaften (acatech). Dr.-Ing. Christoph Herder  studierte Maschinenbau und war von April 2013 bis Januar 2019 wissenschaftlicher Mitarbeiter am Lehrstuhl für Fertigungstechnik und Betriebsorganisation (FBK) der TU Kaiserslautern. Seine Forschungsschwerpunkte lagen dabei im Bereich Technologiemanagement und Produkt-Service Systeme. Aktuell ist er Lean Manager bei der Karl Otto Braun GmbH & Co. KG. Dr.-Ing. Walter Koch  verantwortet seit Januar 2017 den Bereich Advanced R&D Engineering der Schaeffler AG in Herzogenaurach. Er ist prozessverantwortlich für den Geschäftsprozess Produktentstehung (PEP) der Schaeffler Gruppe. Darüber hinaus leitet er die Vorentwicklung für die Prozesse, Methoden und Tools der Funktion F&E. In dieser Funktion führte Dr.-Ing. Koch das Konsortium des BMBF-Verbundprojektes InnoServPro. Patrick Kölsch, M. Sc.  studierte Wirtschaftsingenieurwesen mit der Fachrichtung Maschinenbau und ist seit November 2015 wissenschaftlicher Mitarbeiter am Lehrstuhl für Fertigungstechnik und Betriebsorganisation (FBK) der TU Kaiserslautern. Seine Forschungsinteressen liegen im Bereich Produkt-Service Systeme und damit verbundenen Geschäftsmodellen sowie Agile Methoden, wie Design Thinking und Scrum.

XI

XII

Über die Herausgeber und die Autoren

Autorenseite Hristo  Apostolov  Lehrstuhl für Virtuelle Produktentwicklung, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland Jan  C.  Aurich  Lehrstuhl für Fertigungstechnik und Betriebsorganisation, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland Dani  Bechev  Lehrstuhl für Maschinenelemente und Getriebetechnik, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland Horst Brehm  Schaeffler AG, Herzogenaurach, Deutschland Georgis Bulun  Lehrstuhl für Messtechnik und Sensorik, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland Christian Donges  :em engineering methods AG, Darmstadt, Deutschland Sonja Dreyer  BHN Dienstleistungs GmbH & Co. KG, Aerzen, Deutschland Thomas  Eickhoff  Lehrstuhl für Virtuelle Produktentwicklung, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland Matthias Fischer  :em engineering methods AG, Darmstadt, Deutschland Claudia Glenske  Sensitec GmbH, Lahnau, Deutschland Jens C. Göbel  Lehrstuhl für Virtuelle Produktentwicklung, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland Simon Graf  Lehrstuhl für Maschinenelemente und Getriebetechnik, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland Michael Grethler  SolidLine AG, Karlsruhe, Deutschland Christoph  Herder  Lehrstuhl für Fertigungstechnik und Betriebsorganisation, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland Lars Holländer  Unity AG, Stuttgart, Deutschland Julian Imwalle  Anedo GmbH, Eydelstedt, Deutschland Andrej Keksel  Lehrstuhl für Messtechnik und Sensorik, Technische Universität Kaiserslautern, Kaiserslautern Markus Kiele-Dunsche  Lenze SE, Aerzen, Deutschland Walter Koch  Schaeffler AG, Herzogenaurach, Deutschland Patrick  Kölsch  Lehrstuhl für Fertigungstechnik und Betriebsorganisation, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland

Über die Herausgeber und die Autoren

XIII

Lan Liu  Schaeffler AG, Herzogenaurach, Deutschland Ralf Mattukat  Anedo GmbH, Eydelstedt, Deutschland Daniel Olivotti  BHN Dienstleistungs GmbH & Co. KG, Aerzen, Deutschland Kai Pankrath  XPLM GmbH, Viernheim, Deutschland Rolf Rettinger  BHN Dienstleistungs GmbH & Co. KG, Aerzen, Deutschland Jörg Richter  T-Systems International GmbH, Wolfsburg, Deutschland Bernd  Sauer  Lehrstuhl für Maschinenelemente und Getriebetechnik, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland Claudia Schrank  John Deere GmbH & Co. KG European Technology Innovation Center, Kaiserslautern, Deutschland Jörg Seewig  Lehrstuhl für Messtechnik und Sensorik, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland Paaranan  Sivasothy  Lehrstuhl für Messtechnik und Sensorik, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland Heiko Stichweh  Lenze SE, Aerzen, Deutschland Siegfried  Trendler  John Deere GmbH & Co. KG European Technology Innovation ­ enter, Kaiserslautern, Deutschland C Gerald  Wessel  GRIMME Landmaschinenfabrik GmbH & Co. KG, Damme, Deutschland Frank Zeihsel  enbiz GmbH, Kaiserslautern, Deutschland Viviane Zimmermann  Unity AG, Stuttgart, Deutschland

1

Innovative Serviceprodukte für individualisierte, verfügbarkeitsorientierte Geschäftsmodelle Patrick Kölsch und Jan C. Aurich

Zusammenfassung

In diesem Kapitel wird in die Thematik des Buches eingeleitet. Es wird die Wichtigkeit des Themas mit aktuellen Beispielen erläutert und den Lesern die Motivation des BMBF-Forschungsprojekts „Innovative Serviceprodukte für individualisierte, verfügbarkeitsorientierte Geschäftsmodelle für Investitionsgüter  – InnoServPro“ nähergebracht. Weiterhin findet sich im Kapitel eine Beschreibung der Teilziele des Projekts, die sich auch in der Kapitelstruktur des Buches widerspiegeln. Die Teilziele werden anhand zweier Use-Cases in der Landmaschinenbranche sowie eines Use-Cases in der Intralogistikbranche demonstriert. Die Projektergebnisse zeigen, dass verfügbarkeitsorientierte Geschäftsmodelle im Rahmen datenbasierter Produkt-Service Systeme gerade vor dem Hintergrund neuer Technologien und neuer Möglichkeiten durch Industrie 4.0 eine Chance für Unternehmen darstellen, sich von der Konkurrenz zu differenzieren und damit Wettbewerbsvorteile zu generieren.

Geschäftsmodelle wie „Power-by-the-Hour“ von Rolls Royce oder Carsharing sind aktuell populäre Beispiele einer wahren Welle an neuen Geschäftsmodellen. Jedoch stellt sich die Frage, warum gerade solche Geschäftsmodelle so populär sind, bei denen sich das eigentliche Produkt nicht oder nur teilweise im Besitz des Kunden befindet. In vielen Bereichen bevorzugen die Kunden mittlerweile nicht mehr nur das alleinige Produkt, sondern verlangen individuelle Lösungen zur Erfüllung ihrer Aufgaben. Aktuelle Trends und neue Technologien beschleunigen diese Transformation und ermöglichen den Anbietern P. Kölsch (*) · J. C. Aurich Lehrstuhl für Fertigungstechnik und Betriebsorganisation, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 J. C. Aurich et al. (Hrsg.), Entwicklung datenbasierter Produkt-Service Systeme, https://doi.org/10.1007/978-3-662-59643-2_1

1

2

P. Kölsch und J. C. Aurich

der Investitionsgüterindustrie, innovative Lösungen zu entwickeln. Zahlreiche Unternehmen bieten heute solche Systeme aus Produkten und Dienstleistungen an, die durch ein ganzes Netzwerk an Partnerunternehmen und unter Einsatz neuer Technologien entwickelt und realisiert werden. Die Gestaltung und Realisierung dieser sogenannten Produkt-Service Systeme (PSS) ist allerdings keine triviale Aufgabe, denn Kunden verlangen Flexibilität hinsichtlich Investitionen und Sicherheit hinsichtlich Maschinennutzung und Produktionsergebnissen. Das Entwickeln solcher PSS und das Anbieten im Rahmen verfügbarkeitsorientierter Geschäftsmodelle, bei denen der Kunde nur noch für die Einsatzfähigkeit des Produkts zahlt, ist eine durch viele Unsicherheiten geprägte Aufgabe. Eine der größten Hürden und wichtigstes Merkmal ist hierbei die Tatsache, dass die Initiierung fast aller Serviceprozesse in den Verantwortungsbereich des Anbieters übergeht, was insbesondere Prozesse wie Wartung und Instandhaltung betrifft. Um vor diesem Hintergrund eine Verfügbarkeit zu garantieren, muss der Anbieter die Zustände der im Sachprodukt verbauten Komponenten sowie die aktuelle Produktkonfiguration bei jedem Kunden genau kennen. Selbst wenn in manchen Fällen die erforderlichen Daten vorhanden sind, werden sie selten zielgerichtet verwertet. Aus diesem Grund kann eine Verfügbarkeit auf Basis von Daten kaum in ausreichendem Maße garantiert werden. Eine weitere Hürde ist die Gestaltung eines adäquaten Geschäftsmodells. Zwar existieren in der Literatur zahlreiche Ansätze zur Geschäftsmodellentwicklung, wie ein verfügbarkeitsorientiertes Geschäftsmodell im Rahmen eines datenbasierten PSS unter Einbezug zahlreicher Netzwerkpartner erarbeitet werden kann, wird bislang nur unzureichend adressiert. Ebenfalls wird der Verbindung zwischen Geschäftsmodellentwicklung und technischer Entwicklung wenig Beachtung geschenkt. Eine Unterscheidung zwischen technologie- und marktbasierter Induktion des Geschäftsmodellentwicklungsansatzes findet sich in der Literatur ebenfalls nur unzureichend. Hier bietet das Projekt „Innovative Serviceprodukte für individualisierte, verfügbarkeitsorientierte Geschäftsmodelle für Investitionsgüter  – InnoServPro“ Lösungsansätze an, wie solche datenbasierten PSS gestaltet werden können, um sie mithilfe eines verfügbarkeitsorientierten Geschäftsmodells Kunden in der Investitionsgüterbranche anbieten zu können. Eine so vielschichtige Aufgabe zu lösen, erfordert die Unterteilung in mehrere Teilziele. In InnoServPro ist das Gesamtziel die Entwicklung und Realisierung verfügbarkeitsorientierter Geschäftsmodelle. Dieses wurde in drei Teilziele unterteilt: Teilziel 1: Konzeption von individualisierten, verfügbarkeitsorientierten Geschäftsmodellen In diesem Teilziel wird ein Konzept entwickelt, welches es Unternehmen ermöglicht, verfügbarkeitsorientierte Geschäftsmodelle durchgängig von der Planung bis zur Realisierung zu entwickeln. Dabei werden mögliche Partner aus dem erweiterten Wertschöpfungsnetzwerk des PSS-Anbieters berücksichtigt und einbezogen. Ebenso wird das Konzept zur markt- und technologiegetriebenen Induktion gestaltet. Teilziel 2: Entwicklung und Integration intelligenter, kommunikationsfähiger Komponenten

1  Innovative Serviceprodukte für individualisierte, verfügbarkeitsorientierte …

3

Zur Garantie einer Verfügbarkeit müssen die Zustände relevanter Komponenten offengelegt und visualisiert werden. Im Zuge dessen werden die Komponenten einzelner Sachprodukte derart weiterentwickelt, dass bei der Nutzung des Sachprodukts Daten über dessen Zustand generiert und analysiert werden, um somit Handlungsempfehlungen für den PSS-Anbieter und dessen Kunden ableiten zu können. Dazu werden Überwachungskonzepte auf Basis experimenteller Untersuchungen entwickelt und realisiert. Teilziel 3: Gestaltung des Informationsmanagements für individualisierte, verfügbarkeitsorientierte Geschäftsmodelle Für die Übertragung der Felddaten muss eine Kommunikationsplattform entwickelt und Datenanalysemethoden zur Prognose von Ausfällen implementiert werden. Um eine hohe Verfügbarkeit garantieren zu können, müssen auch zufällig auftretende Fehler und ihre schnelle Instandsetzung betrachtet werden. Für solche Instandsetzungsmaßnahmen muss die Konfiguration des Sachprodukts bekannt sein, weshalb im Projekt ein digitaler Zwilling entwickelt wird. Die Gestaltung der Schnittstellen zwischen der Kommunikationsplattform sowie der Subsysteme (Back-End, Front-End, etc.) muss ebenfalls berücksichtigt werden. Die Teilziele wurden mithilfe dreier Anwendungsfälle (Use-Cases) validiert. Zwei der Use-Cases sind in der Landmaschinenbranche verankert und wurden mit der GRIMME Landmaschinenfabrik GmbH & Co. KG sowie mit der John Deere GmbH & Co. KG durchgeführt. Ein weiterer Use-Case zeigt die branchenübergreifende Übertragbarkeit und ist im Bereich der Intralogistik verankert. Dieser Use-Case wurde in Kooperation mit der BHN Dienstleistungs GmbH & Co KG., der Lenze SE sowie der Schaeffler AG durchgeführt. Die Projektergebnisse zeigen, dass verfügbarkeitsorientierte Geschäftsmodelle im Rahmen datenbasierter PSS gerade vor dem Hintergrund neuer Technologien und neuer Möglichkeiten durch Industrie 4.0 eine Chance für Unternehmen darstellen, sich von der Konkurrenz zu differenzieren. Für die Kunden der Investitionsgüterindustrie bedeutet dies gleichzeitig, dass durch die Akzeptanz solcher Geschäftsmodelle eine hohe Verfügbarkeit in Verbindung mit niedrigeren Investitionsausgaben resultiert. Für die Flexibilität und Produktionssicherheit müssen die Kunden eine strategische Partnerschaft mit dem PSS-­ Anbieter und den Partnern des erweiterten Wertschöpfungsnetzwerks aufbauen. Datensicherheit und Vertrauen zwischen den Vertragspartnern sind weitere wichtige Aspekte, die bei der Realisierung verfügbarkeitsorientierter Geschäftsmodelle beachtet werden müssen. Der Aufbau des Buches orientiert sich an den oben genannten Teilzielen. Im ersten Teil werden Grundlagen sowie die im Projekt entwickelte, generische Vorgehensweisen zur Entwicklung von vGM präsentiert. Im zweiten Teil werden diese Inhalte genutzt, um spezifische Lösungen anhand der drei Use-Cases zu erarbeiten und die technische Realisierung zu präsentieren. Im dritten Teil werden Use-Case-übergreifende Ergebnisse präsentiert, welche aus der Geschäftsmodellentwicklung der drei Use-Cases resultieren.

2

Grundlagen zu Produkt-Service Systemen Patrick Kölsch, Jan C. Aurich und Christoph F. Herder

Zusammenfassung

In diesem Kapitel werden die Grundlagen zu der Buchthematik gelegt. Dabei werden im ersten Teil des Kapitels Produkt-Service Systeme als Betrachtungsgegenstand genau analysiert und die Charakteristika der Systemelemente Sachprodukt, Serviceprodukt, Netzwerke von Akteuren und unterstützende Infrastruktur herausgestellt. Zudem werden datenbasierte Produkt-Service Systeme näher erläutert. Im zweiten Teil des Kapitels werden die verschiedenen Formen von Geschäftsmodellen unterschieden und die im Projekt genutzte Beschreibungssystematik für Geschäftsmodelle vorgestellt. Für die zu entwickelnden verfügbarkeitsorientierten Geschäftsmodelle wird der Terminus Verfügbarkeit unter technischen Gesichtspunkten definiert. Darunter fällt auch die Unterscheidung zwischen Fehlerarten, die bei der Verfügbarkeitsbetrachtung überwacht werden müssen. Eine erste Einordnung der Anwendungsfälle zu den beiden Teilen der Verfügbarkeit erfolgt am Ende des Kapitels.

2.1

Definition eines Produkt-Service Systems

In der Literatur existieren viele verschiedene Definitionen und Betrachtungsweisen eines Produkt-Service Systems. Diese unterscheiden sich im Wesentlichen hinsichtlich des integrierten Gestaltungsansatzes zur Planung und Entwicklung von PSS sowie in Bezug auf

P. Kölsch (*) · J. C. Aurich · C. F. Herder Lehrstuhl für Fertigungstechnik und Betriebsorganisation, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected]; [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 J. C. Aurich et al. (Hrsg.), Entwicklung datenbasierter Produkt-Service Systeme, https://doi.org/10.1007/978-3-662-59643-2_2

5

6

P. Kölsch et al.

Abb. 2.1  Produkt-Service System nach Mont [5]

die Systemsicht und die Definition der Systemelemente. Auch wenn bereits in den 40er-Jahren ähnliche Konzepte existierten, erlangten PSS erst in den späten 80er-Jahren an Relevanz. Eine der ersten Definitionen wurde von Goedkoop et al. im Jahr 1999 aufgestellt [1]. In der Literatur existieren zudem verschiedene weitestgehend synonym verwendbare Begriffe, wie beispielsweise hybride Leistungsbündel [2], hybride Produkte [3] oder Industrial Product-Service Systems [4]. Im Folgenden wird die Definition nach Mont genutzt [5]. Demnach ist ein PSS ein Netzwerk aus Sachprodukten, Serviceprodukten, Netzwerken von Akteuren und unterstützender Infrastruktur zur Erfüllung von Kundenwünschen, was in Abb. 2.1 visualisiert wird. Im Nachfolgenden werden die einzelnen Elemente des PSS genauer analysiert und der Systemgedanke näher erläutert.

2.1.1 System und soziotechnisches System Ein System wird nach Ropohl definiert als „[…] das Modell einer Ganzheit, die (a) Beziehungen zwischen Attributen (Inputs, Outputs, Zustände etc.) aufweist, die (b) aus miteinander verknüpften Teilen bzw. Subsystemen besteht, und die (c) von ihrer Umgebung bzw. von einem Supersystem abgegrenzt wird“ [6]. Diese Definition beinhaltet somit drei ­Betrachtungsweisen eines Systems. Zum einen die funktionale Betrachtungsweise, bei der das System an sich eine Blackbox darstellt. Es werden also die Inputs und Outputs näher betrachtet, die Struktur des Systems bleibt allerdings ungeklärt. Die Funktion des Systems zur Transformation von Inputs in Outputs durch Zustandsänderungen wird bei dieser Betrachtungsweise fokussiert. Die strukturale Betrachtungsweise repräsentiert die Auffassung, das System als eine Ganzheit der durch Relationen verknüpften Systemelemente zu betrachten. Es werden sowohl die Beschaffenheit der Systemelemente als auch die Beziehungsgeflechte untereinander näher betrachtet. Die hierarchische Betrachtungsweise stellt Über- und Unterordnungsbeziehungen zwischen existierenden Systemen und Systemelementen her. Bei übergeordneten Systemen wird dabei von Supersystemen bei untergeordneten Systemen von Subsystemen gesprochen. Die nachfolgende Abb. 2.2 zeigt die ganzheitliche Sicht aller drei Betrachtungsweisen auf ein System.

2  Grundlagen zu Produkt-Service Systemen

7

Abb. 2.2  Aufbau eines Systems nach Rophol [6]

Nach Laurischkat besteht ein sozio-technisches System aus einem oder mehreren technischen Systemen, besitzt definierte betriebliche Prozesse und berücksichtigt den Bediener des technischen Systems [7]. Ein PSS repräsentiert somit ein sozio-technisches System, wobei soziale und technische Teilsysteme stark vernetzt sind [8] und bei der Realisierung von PSS zum einen zwischenmenschliche Interaktionen als auch Interaktionen zwischen Menschen und technischen Systemen stattfinden [9].

2.1.2 Sachprodukt Sachprodukte bilden nach Ehrlenspiel und Meerkam eine Teilmenge technischer Systeme [10]. Der Sachproduktbegriff umfasst dabei alle gebrauchs- und verbrauchsfertigen Erzeugnisse, die als Ergebnisse industrieller Produktionsprozesse entstehen [11]. Im Folgenden entsprechen Sachprodukte Investitionsgütern. Als Investitionsgüter werden Güter bezeichnet, die ein Unternehmen beschafft, um weitere Erzeugnisse zu erstellen, die nicht an den Endkunden verkauft werden [13]. Dies entspricht einer Business-to-Business-­ Geschäftsbeziehung zwischen dem Produktanbieter und dem Kunden. Ein Sachprodukt ist somit ein investives Gebrauchsprodukt, dessen Charakteristika eine lange Lebensdauer und eine hohe technische Komplexität sind.

2.1.3 Serviceprodukt Serviceprodukte sind eine Teilmenge von Dienstleistungen. Für den Dienstleistungsbegriff existieren in der Literatur verschiedene Definitionsansätze. An dieser Stelle wird die Definition auf Basis konstitutiver Merkmale, also für eine Dienstleistung typische bzw. begriffsbildende Merkmale, herangezogen. Für eine Dienstleistung typische Merkmale sind beispielsweise die Immaterialität von In- und Output oder die Integration des externen

8

P. Kölsch et al.

Faktors (Kunde) in den Erbringungsprozess [12]. Dienstleistungen weisen zudem drei unterschiedliche Dimensionen auf, denen die konstitutiven Merkmale zugeordnet werden können [14]: • Potenzialdimension: Fähigkeit und Bereitschaft zur Erbringung der Dienstleistung • Prozessdimension: Initiierung und Begleitung der Dienstleistungserbringung • Ergebnisdimension: Dienstleistungsergebnis Eine Zuordnung der Merkmale zu den Dimensionen ergibt Immaterialität auf der Potenzial- und Ergebnisdimension sowie Simultanität von Produktion und Konsum auf Prozessdimension. Dabei müssen nicht alle Merkmale vorliegen, damit eine Dienstleistung als solche charakterisiert wird [9]. Als Serviceprodukte werden industrielle Dienstleistungen bezeichnet, deren Anbieter produzierende Unternehmen sind. Serviceprodukte sind eine Teilmenge investiver Dienstleistungen, deren Nachfrager andere Organisationen oder Unternehmen sind [15]. Aus dieser Definition resultiert eine ausschließliche Business-to-Business-Geschäftsbeziehung zwischen Anbieter und Nachfrager. Der Terminus Serviceprodukt resultiert aus der Ähnlichkeit zu Sachprodukten hinsichtlich Entwicklung, Produktion und Vertrieb [9].

2.1.4 Netzwerke von Akteuren Damit Unternehmen PSS anbieten können, müssen sie zwingend mit weiteren Unternehmen kooperieren [16]. Durch diese Kooperation können fehlende Kapazitäten und Ressourcen kompensiert werden [4]. Die kooperierenden Unternehmen bilden ein Netzwerk, welches von Aurich et al. als erweitertes Wertschöpfungsnetzwerk bezeichnet wird [17]. Dabei werden bei der Zusammenstellung des erweiterten Wertschöpfungsnetzwerks je nach Anwendungsfall Zulieferer, externe Servicedienstleister, Vertriebsniederlassungen, Entwicklungs- und Produktionsdienstleister berücksichtigt. Eine Integration mehrerer Unternehmenspartner ermöglicht also erst die Planung, Entwicklung und Realisierung von PSS [18].

2.1.5 Unterstützende Infrastruktur Nach Mont besteht zwischen den Sachprodukten eines PSS und der unterstützenden Infrastruktur eine gegenseitige Abhängigkeit. Die unterstützende Infrastruktur setzt sich zusammen aus gemeinschaftlichen Systemen, z. B. aus der Straße beim Autofahren, Unterstützungstechnologien und der räumlichen Gestaltung [5]. Nach Müller, Schulz und Stark ist die Infrastruktur eines PSS ein Teil des PSS-Kontexts. Dieser setzt sich aus der technischen Peripherie, wie Werkzeuge, Anlagen, Infrastruktur sowie Unterstützungs- und Ausführungssystemen zusammen [19]. Eine einheitliche Definition des Begriffs der unterstützen-

2  Grundlagen zu Produkt-Service Systemen

9

den Infrastruktur findet sich in der Literatur nicht. Im weiteren Verlauf werden unter dem Begriff Infrastruktur alle Systemelemente verstanden, die das Zusammenspiel zwischen den restlichen PSS-Elementen ermöglichen. Zur Anzeige eines Komponentenzustands einer Maschine an einem mobilen Endgerät müssen beispielsweise Sensoren, Steuerungsgeräte, Router, Cloudplattform, Auswertungssoftware und Schnittstellen zwischen den Systemelementen entwickelt und aufeinander abgestimmt werden. In diesem Fall wären diese Systemelemente die PSS-Infrastruktur.

2.1.6 Datenbasierte Produkt-Service Systeme Datenbasierte PSS (PSS 4.0 [20]) bestehen aus smarten Sach- und Serviceprodukten. Als smartes Produkt werden cyber-physische Systeme bezeichnet, die mit anderen Produkten z. B. über das Internet kommunizieren können [21]. Diese smarten Produkte sind mit Sensorik ausgestattet und werden über Software gesteuert. Durch die sensorische Ausstattung und die Kommunikationsfähigkeit werden große Mengen an Daten generiert. Werden die Daten spezifisch analysiert und interpretiert, ist es möglich, spezielle datenbasierte Serviceprodukte, sogenannte smarte Serviceprodukte für den Kunden anzubieten [22].

2.2

Geschäftsmodelle für Produkt-Service Systeme

Damit die Potenziale der Serviceprodukte beim Anbieten von PSS ausgeschöpft werden können, müssen passende Geschäftsmodelle entwickelt werden [23]. Eine einheitliche Definition eines Geschäftsmodells existiert nicht. Im weiteren Verlauf wird sich an der Definition von Osterwalder und Pigneur orientiert. Diese besagt, dass ein Geschäftsmodell das Grundprinzip widerspiegelt, nach dem eine Organisation Wert generiert, vermittelt und erfasst [24]. Es existieren drei unterschiedliche Formen von Geschäftsmodellen, die zum Angebot von PSS eingesetzt werden können [2]: • Funktionsorientierte Geschäftsmodelle : Bei funktionsorientierten Geschäftsmodellen werden die Sach- und Serviceprodukte integriert geplant und entwickelt. Der Kunde kann beim Kauf des Sachprodukts verschiedene Serviceprodukte in Eigenverantwortung beauftragen. Für die Initiierung der Serviceerbringung ist der Kunde verantwortlich. Dementsprechend trägt der Kunde auch die volle Verantwortung hinsichtlich seiner Produktion. • Verfügbarkeitsorientierte Geschäftsmodelle (vGM): Bei vGM wird dem Kunden die Einsatzfähigkeit des Sachprodukts garantiert. Dies bedeutet, dass der PSS-Anbieter einzelne Prozesse wie Wartung oder Instandhaltung in Eigenverantwortung initiieren muss. Durch diese Verfügbarkeitsgarantie trägt der PSS-Anbieter ein erhöhtes Risiko im Hinblick auf die Produktion des Kunden.

10

P. Kölsch et al.

• Ergebnisorientierte Geschäftsmodelle: Bei ergebnisorientierten Geschäftsmodellen geht die Verantwortung des PSS und damit für das Produktionsergebnis komplett auf den PSS-Anbieter über. Der Kunde zahlt nur noch für die zugesicherten Ergebnisse, z. B. fehlerfrei produzierte Teile. Eine Übersicht über die verschiedenen Geschäftsmodelle und ein Vergleich verschiedener Charakteristika findet sich in Abb. 2.3. Für die Entwicklung von Geschäftsmodellen bieten verschiedene Autoren unterschiedliche Methoden und Techniken. Zur Beschreibung von Geschäftsmodellen eignet sich beispielsweise der Business Model Canvas (BMC) von Osterwalder und Pigneur [24]. Dabei wird ein Geschäftsmodell anhand von neun Elementen beschrieben. Die Art und Anzahl der Elemente variieren in der Literatur je nach Autor und Beschreibungsrahmenwerk. Der BMC von Osterwalder und Pigneur beinhaltet die folgenden neun Elemente, die von Köster in vier Partialmodelle aufgeteilt wurden [25]: a. Angebotsmodell: Das Angebotsmodell setzt sich aus drei Elementen zusammen, den Kundensegmenten, dem Nutzenversprechen und der Marktleistung. Mit den Kundensegmenten werden jene Kunden beschrieben, die mit dem Geschäftsmodell adressiert werden [26]. Das Nutzenversprechen repräsentiert den Marktangebotsvorteil für den Kunden und die involvierten Partner des erweiterten Wertschöpfungsnetzwerks [27]. Die Marktleistung ist das dritte Element und beschreibt die Umwandlung der Geschäftsidee in marktfähige Produkte und Lösungen zur Erfüllung der Kundenwünsche. b. Kundenmodell: Das Kundenmodell besteht aus den Marketingkanälen, den Kundenbeziehungen und dem Erlöskonzept. Die Gestaltung der Marketingkanäle legt beispielsweise fest, wie die Kunden des festgelegten Kundensegments über die Marktleistung und das damit verbundene Nutzenversprechen informiert werden [28]. Die Gestaltung

Abb. 2.3  Vergleich verschiedener Geschäftsmodelle nach Meier und Uhlmann [2]

2  Grundlagen zu Produkt-Service Systemen

11

der Kundenbeziehungen legt die Art und Intensität fest, mit der der PSS-­Anbieter mit seinen Kunden interagieren möchte [24]. Das Erlöskonzept definiert die Art und Weise, wie der Anbieter das Nutzenversprechen in Erträge umwandelt [29]. c. Wertschöpfungsmodell: Das Wertschöpfungsmodell setzt sich aus vier Elementen zusammen. Dabei repräsentieren die Schlüsselaktivitäten jene Aktivitäten, die zur Realisierung des Nutzenversprechens durchgeführt werden müssen [30]. Zur Durchführung der Schlüsselaktivitäten sind einige Ressourcen unerlässlich und werden daher als Schlüsselressourcen zusammengefasst [31]. Einige wichtige Ressourcen sind beispielsweise nur bei externen Partnerunternehmen vorhanden, sodass zur Realisierung des Nutzenversprechens die wichtigsten Partner als Schlüsselpartner deklariert werden [32]. Wie diese Partner in der Wertschöpfungskette positioniert sind und wie deren Beziehung zueinander gestaltet ist, beschreibt das Element Organisationsform [33]. d. Finanzmodell: Das Finanzmodell setzt sich aus der Kostenstruktur zusammen, welche die wichtigsten Kostentreiber zur Realisierung des Geschäftsmodells aufschlüsselt [34]. Der weiterentwickelte BMC von Köster wurde von Echterhoff et al. um die Elemente Vorteile für Anwender, Anreize für Partner und Risiken erweitert [35]. Die Partner werden somit nicht nur in den Elementen Schlüsselpartner und Organisationsform adressiert, sondern deren Vorteile an einer Kooperation und Realisierung eines vGM hervorgehoben. Im Projekt wurde somit zur Dokumentation von Geschäftsmodellen der BMC nach Echterhoff et al. eingesetzt. Diese ist in der nachfolgenden Abb. 2.4 dargestellt.

Abb. 2.4  Erweiterte Business Model Canvas nach Echterhoff et al. [32]

12

P. Kölsch et al.

Im Projekt wurden nur vGM betrachtet, sodass im Folgenden auf die technische Verfügbarkeit eingegangen wird. Die vGM werden durch datenbasierte Produkt-Service ­Systeme realisiert. Im weiteren Verlauf wird stellvertretend für datenbasierte Produkt-Service Systeme lediglich der Begriff Produkt-Service Systeme verwendet.

2.3

Verfügbarkeit

Für die Entwicklung von vGM ist die Definition der Verfügbarkeit essenziell. In der Literatur existiert neben dem Begriff der Verfügbarkeit auch der Terminus Zuverlässigkeit, welcher bezogen auf den Betrachtungsgegenstand sehr ähnlich zur Verfügbarkeit ist. Aus diesem Grund muss die Verfügbarkeit zuerst von der Zuverlässigkeit abgegrenzt werden. Nach Eberlin und Hock wird Zuverlässigkeit als Fähigkeit eines Objektes definiert, unter gegebenen Bedingungen für eine bestimmte Zeit eine geforderte Funktion auszuüben [36]. Bei Zuverlässigkeitsuntersuchungen ist es wichtig, dass fehlerhafte Objekte nicht ausgetauscht werden. Falls fehlerhafte Komponenten ausgetauscht werden, wird die Verfügbarkeit betrachtet. Unter Verfügbarkeit wird im Allgemeinen die Wahrscheinlichkeit verstanden, in der sich ein System zu einem beliebigen Zeitpunkt in einem Zustand befindet, in dem es seine definierte Funktion erfüllen kann [36]. Das System ist also zu einem beliebigen Zeitpunkt in einem fehlerfreien Zustand. Die binäre Betrachtungsweise der Komponenten (fehlerfrei oder fehlerbehaftet) schließt allerdings eine Funktionseinschränkung einzelner Komponenten aus. Aus diesem Grund muss die Definition der Verfügbarkeit im Projekt derart angepasst werden, dass auch funktionseingeschränkte Bauteile zu einem bestimmten Anteil die definierte Funktion ausüben können und somit nur zu einem Teil fehlerbehaftet sind. Diese Mehrwertigkeit ist für die Berechnung der Verfügbarkeit und Umsetzung vGM essenziell. Die Verfügbarkeit berechnet sich durch den Quotienten aus prognostizierter Einsatzzeit und der Summe aus prognostizierter Einsatzzeit und mittlerer Ausfallzeit. Aus der Definition ergeben sich zwei Ansatzpunkte zur Beeinflussung der Verfügbarkeit – die Einsatzzeit und die Ausfallzeit. Ein Ziel des Projekts ist es, die Verfügbarkeit für den Kunden prognostizieren zu können. Aus diesem Grund wird die Einsatzzeit durch die entwickelte Lösung nicht über mehrere Szenarien gemittelt, sondern möglichst genau prognostiziert. ­Allerdings hängt die Ausfallzeit des Systems von mehreren Faktoren ab, die weder der Kunde noch der Servicetechniker beeinflussen kann. Beispiele hierfür sind die unterschiedlichen Zeiten zur Anreise des Servicetechnikers bzw. die Verkehrssituation. Somit muss die Ausfallzeit gemittelt werden, um auf eine aussagekräftige Kennzahl zu kommen. Ein fehlerbehafteter Zustand liegt dann vor, wenn eine oder mehrere Haupt- oder Nebenfunktionen, Baugruppen- oder Bauteilefunktionen nicht mehr erfüllt werden [36]. Um die Mehrwertigkeit auch bei der Definition eines Fehlers zu beachten, wird die Definition folgendermaßen angepasst: Ein fehlerbehafteter Zustand liegt vor, wenn eine oder mehrere Haupt- oder Nebenfunktionen, Baugruppen- oder Bauteilefunktionen nicht im

2  Grundlagen zu Produkt-Service Systemen

13

erforderlichen Maße erfüllt werden. Es liegt somit eine Leistungseinschränkung oder ein Totalausfall vor. Damit werden bei den betroffenen Bauteilen/Baugruppen Grenzwerte überschritten. Für deren Überschreitung und somit zur Prognose der verbleibenden Einsatzzeit müssen folglich Überwachungskonzepte entwickelt werden. Es werden dabei drei verschiedene Fehlerarten unterschieden [36]. Im Folgenden werden die Fehlerarten charakterisiert und in Abb. 2.5 anhand der Badewannenkurve visualisiert: 1. Frühe Fehler: Tritt ein Fehler dieser Art in einem frühen Stadium der Betriebsdauer auf, lässt sich die Ursache meist auf einen Fehler in der Planung, Konstruktion oder Produktion zurückführen. Auch durch eine fehlende Schulung der Maschinenbediener oder der fehlenden Kenntnis des Maschinenverhaltens/der Maschinenfunktionen kann ein Bedienfehler zum Verlust der Funktionsfähigkeit führen. 2. Zufällige Fehler: Tritt ein zufälliger Fehler auf, kann meist nicht auf die Ursache geschlossen werden. Zufällige Fehler treten unerwartet und unabhängig von Alter und Betriebsdauer auf. Bezogen auf die Lebensdauer der Komponente sind zufällig auftretende Fehler gleichverteilt. 3. Verschleiß-/Alterungsfehler: Zum Ende der Lebensdauer der Komponenten und somit im späteren Verlauf der Betriebsdauer treten verstärkt Verschleiß-/Alterungsfehler auf. Die Verfügbarkeit kann nur dann datenbasiert garantiert werden, wenn alle Fehlerarten überwacht bzw. registriert werden können. Aus diesem Grund müssen die Überwachungskonzepte zur Prognose der Einsatzzeit (erster Teil der Verfügbarkeitsbetrachtung) den Verschleißzustand der Komponenten und einen plötzlich auftretenden Totalausfall detektieren können. Der zweite Teil der Verfügbarkeitsbetrachtung stellt die mittlere Ausfallzeit in den Fokus. Die Erhöhung der Verfügbarkeit kann demnach durch die Reduzierung der Ausfallzeit erreicht werden. Maßnahmen hierfür sind beispielsweise eine schnellere Fehlerdiagnose, -behebung, schnellere Ersatzteillieferung, eine schnelle Bereitstellung von Kontaktinformationen an Werkstatt/Händler, Remote Support etc. Für einen Großteil dieser Maßnahmen ist die Bereitstellung von Produktinformationen (PLM-Daten, Lagedaten, Geome­ triedaten) wesentlich. Eine erweiterte Schritt-für-Schritt-Anleitung zur Unterstützung des

Abb. 2.5  Badewannenkurve nach Eberlin und Hock [33]

14

P. Kölsch et al.

Servicetechnikers kann sowohl bei der Fehlerdiagnose, Identifikation von notwendigen Ersatzteilen als auch bei der Instandsetzung und Fehlervermeidung bei Reparaturen ­unterstützen und so die Ausfallzeit reduzieren. In einzelnen und einfachen Schadensfällen wäre sogar eine durch Schritt-für-Schritt-Anleitungen unterstützte Selbstreparatur für den Maschinenbediener effizienter als die Anreise des Servicetechnikers. Tritt eine Störung oder ein Fehler bei einer Komponente auf, kann der Maschinenbediener diese in möglichst kurzer Zeit selbst beheben. Für eine solche Anleitung müssen geeignete Komponenten identifiziert werden, da nicht jede Komponente ohne fachliches Know-how repariert werden kann. Zudem muss die Anleitung zum Austausch einer Komponente den Fehler und die fehlerbehaftete Komponente möglichst genau identifizieren, wozu der Aufbau eines digitalen Zwillings der Maschinenkonfiguration unabdingbar ist.

Literatur 1. Goedkoop M, van Halen C, te Riele H, Rommens P (1999) Product service systems, ecological and economic basics. Pre-Consultants. The Netherlands 2. Meier H, Uhlmann E (2012) Hybride Leistungsbündel – ein neues Produktverständnis. In: Meier H, Uhlmann E (Hrsg) Integrierte Industrielle Sach- und Dienstleistungen – Vermarktung, Entwicklung und Erbringung hybrider Leistungsbündel. Springer, Berlin/Heidelberg, S 1–21 3. Spath D, Demuß L (2006) Entwicklung hybrider Produkte – Gestaltung materieller und immaterieller Leistungsbündel. In: Bullinger HJ, Scheer AW (Hrsg) Service Engineering – Entwicklung und Gestaltung innovativer Dienstleistungen. Springer, Berlin/Heidelberg, S 463–502 4. Meier H, Roy R, Seliger G (2010) Industrial Product-Service Systems  – IPS 2. CIRP Ann 59(2):607–627 5. Mont O (2004) Product-service systems – Panacea or myth? Dissertation, Lund University, Lund 6. Ropohl G (2009) Allgemeine Technologie – Eine Systemtheorie der Technik. Universitätsverlag Karlsruhe. Karlsruhe 7. Laurischkat K (2012) Product-Service Systems  – IT-gestützte Generierung und Modellierung von PSS-Dienstleistungsanteilen. Dissertation, Ruhr-Universität Bochum 8. Fuchs CH (2007) Life Cycle Management investiver Produkt-Service Systeme – Konzept zur lebenszyklusorientierten Gestaltung und Realisierung. Dissertation, Technische Universität Kaiserslautern 9. Waltemode S (2014) Qualitätsbewertung technischer Produkt-Service Systeme. Dissertation, Technische Universität Kaiserslautern 10. Ehrlenspiel K, Meerkamm H (2013) Integrierte Produktentwicklung. Carl Hanser, München/ Wien 11. Spur G, Krause FL (1997) Das virtuelle Produkt – Management der CAD-Technik. Carl Hanser, München 12. Kleinaltenkamp M (1998) Begriffsabgrenzung und Erscheinungsformen von Dienstleistungen. In: Bruhn M, Meffert M (Hrsg) Handbuch Dienstleistungsmanagement – Von der strategischen Konzeption zur praktischen Umsetzung. Gabler, Wiesbaden, S 29–52 13. Backhaus K (1992) Investitionsgüter-Marketing – Theorieloses Konzept mit Allgemeinheitsanspruch. Z Betriebswirtsch Forsch 44(9):771–791 14. Hilke W (1991) Grundprobleme und Entwicklungstendenzen des Dienstleistungs-Marketing. In: Hilke W (Hrsg) Dienstleistungs-Marketing – Banken und Versicherungen, freie Berufe, Handel und Transport, nicht-erwerbswirtschaftlich orientierte Organisationen. Gabler, Wiesbaden, S 5–44

2  Grundlagen zu Produkt-Service Systemen

15

15. Homburg C, Garbe B (1996) Industrielle Dienstleistungen – Bestandsaufnahme und Entwicklungsrichtungen. Z für Betriebswirt: ZfB 66(3):253–282 16. Mont O (2002) Clarifying the concept of product–service system. J Clean Prod 10(3):237–245 17. Aurich JC, Fuchs C, Wagenknecht C (2006) Life cycle oriented design of technical product-­ service systems. J Clean Prod 14(17):1480–1494 18. Mont O (2004) Reducing life-cycle environmental impacts through systems of joint use. Greener Manag Int 2004(45):63–77 19. Müller P, Schulz F, Stark R (2010) Guideline to elicit requirements on industrial product-service systems. Proceedings of the 2nd CIRP IPS2 conference 77, S 109–116 20. Aurich JC, Kölsch P, Herder CF, Mert G (2016) PSS 4.0  – Einflüssen von Industrie 4.0 auf Produkt-­Service Systeme. Z wirtschaftlichen Fabrikbetrieb 111(9):565–568 21. Abramovici, M, Gebus P, Savarino P, acatech (Hrsg) (2018) Engineering smarter Produkte und Services – Plattform Industrie 4.0 Studie. Acatech-Studie, München 22. Arbeitskreis Smart Service Welt/acatech (Hrsg) (2015) Smart Service Welt – Umsetzungsempfehlung für das Zukunftsprojekt Internetbasierte Dienste für die Wirtschaft. Abschlussbericht, Berlin 23. Aurich JC, Mannweiler C, Schweitzer E (2010) How to design and offer services successfully. CIRP J Manuf Sci Technol 2(3):136–143 24. Osterwalder A, Pigeneur Y (2010) Business model generation  – a handbook for visionaries, game changers, and challengers. Wiley, Hoboken/New Jersey 25. Köster, O (2014) Systematik zur Entwicklung von Geschäftsmodellen in der Produktentstehung. Dissertation, Universität Paderborn 26. Morris M, Schindehutte M, Allen J (2005) The entrepreneur’s business model – toward a unified perspective. J Bus Res 58(6):726–735 27. Stähler P (2002) Geschäftsmodelle in der digitalen Ökonomie – Merkmale, Strategien und Auswirkungen. Josef Eul, Köln 28. Bieger T, Reinhold S (2011) Das wertebasierte Geschäftsmodell – Ein aktualisierter Strukturierungsansatz. In: Bieger T, Knyphausen-Aufseß D, Krys C (Hrsg) Innovative Geschäftsmodelle – Konzeptionelle Grundlagen, Gestaltungsfelder und unternehmerische Praxis. Springer, Berlin, S 13–70 29. Bieger T, Rüegg-Stürm J, Rohr T (2002) Strukturen und Ansätze einer Gestaltung von Beziehungskonfigurationen – Das Konzept Geschäftsmodell. In: Bieger T, Bickhoff N, Knyphausen-­ Aufseß D, Caspers R, Reding K (Hrsg) Zukünftige Geschäftsmodelle – Konzept und Anwendung in der Netzökonomie. Springer, Berlin, S 35–61 30. Afuah A, Tucci C (2003) Internet business models and strategies – Text and cases. McGraw Hill/ Irwin, New York 31. Christensen C, Johnson M, Kagermann H (2009) Wie Sie Ihr Geschäftsmodell neu erfinden. Harv Bus Manag 4:37–49 32. Chesbrough H, Rosenbloom R (2002) The role of the business model in capturing value from innovation – evidence from Xerox corporation’s technology spin-off companies. Ind Corp Chang 11(6):529–555 33. Baier M, Gräfe G, Jekal M, John R, Vörckel T (2010) Geschäftsmodell für kommerzielles Grid-Providing. In: Hasselbring W (Hrsg) Betriebliche Informationssysteme – Grid-basierte Integration und Orchestrierung. Gito, Berlin, S 79–115 34. Ballon P (2007) Business model revisited – the configuration of control and value. Info, 9/5, S 6–19 35. Echterhoff B, Gausemeier J, Koldewey C, Mittag T, Schneider M, Heiko S (2016) Geschäftsmodelle für die Industrie 4.0. In: Jung HH, Kraft P (Hrsg) Digital vernetzt. Transformation der Wertschöpfung. Hanser, München, S 35–55 36. Eberlin S, Hock B (2014) Zuverlässigkeit und Verfügbarkeit technischer Systeme. Eine Einführung in die Praxis. Springer, Wiesbaden

3

Konzeption verfügbarkeitsorientierter Geschäftsmodelle Patrick Kölsch, Jan C. Aurich, Christoph F. Herder und Viviane Zimmermann

Zusammenfassung

In diesem Kapitel wird die Konzeption verfügbarkeitsorientierter Geschäftsmodelle dargestellt. Beginnend bei der Anforderungserhebung werden anschließend die Konzeptphasen zur Entwicklung verfügbarkeitsorientierter Geschäftsmodelle Schritt für Schritt aufgebaut und einfach handhabbare Werkzeuge beispielsweise aus dem Design Thinking für jede Phase hinterlegt. Die Werkzeuge und deren Anwendung werden dabei detailliert erläutert, wodurch ein unkomplizierter Einsatz in der Praxis ermöglicht wird. Das Konzept besteht insgesamt aus sieben Phasen und berücksichtigt sowohl eine technologiegetriebene als auch eine marktgetriebene Induktion. Weiterhin werden Anforderungen an die technische Realisierung des Geschäftsmodells erhoben, sodass die technische Entwicklung nahtlos an das Konzept anschließen kann. Das Konzept ermöglicht somit die Entwicklung verfügbarkeitsorientierter Geschäftsmodelle unter Berücksichtigung der notwendigen technischen Voraussetzungen und des Einbezugs eines Wertschöpfungsnetzwerks.

P. Kölsch (*) · J. C. Aurich · C. F. Herder Lehrstuhl für Fertigungstechnik und Betriebsorganisation, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected]; [email protected] V. Zimmermann Unity AG, Stuttgart, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 J. C. Aurich et al. (Hrsg.), Entwicklung datenbasierter Produkt-Service Systeme, https://doi.org/10.1007/978-3-662-59643-2_3

17

18

3.1

P. Kölsch et al.

 nforderungen an das Konzept zur Entwicklung von A verfügbarkeitsorientierten Geschäftsmodellen

Das Konzept zur Entwicklung von verfügbarkeitsorientierten Geschäftsmodellen (vGM) basiert auf unterschiedlichen Anforderungen. Die Anforderungen werden aus den Zielen abgeleitet, welche durch das Konzept zu erfüllen sind. Innerhalb dieses Kapitels werden zunächst diese Ziele und Aufgaben dargestellt, bevor im zweiten Teil die Anforderungen abgeleitet werden. Ziel des Konzepts ist es, dessen Nutzer nicht nur bei der Entwicklung verfügbarkeitsorientierter Geschäftsmodelle, sondern auch bei der Definition von technischen und organisatorischen Anforderungen an eine Realisierung zu unterstützen. Die Geschäftsmodellinnovation gilt als eigene Innovationsart, die sich mit den anderen existierenden Innovationsarten, der Leistungsinnovation, der Prozessinnovation, der Marktinnovation und der Sozialinnovation überschneidet [1]. Generell kann der Anstoß für eine Innovation zweck- oder mittelinduziert sein [2]. Sind Innovationen mittelinduziert, basieren sie auf neuen Technologien, für die passende Anwendungsmöglichkeiten definiert und realisiert werden (Technology-push). Zweckinduzierte Innovationen basieren auf Markt- und Kundenanforderungen. Diese gilt es durch geeignete Lösungen zu bedienen (Market-pull). Bereits 1992 erkannte Rothwell, dass eine ausgewogene Zweck-­Mittel-Beziehung für den Erfolg eines Unternehmens wichtig ist und somit Technologie- und Konsumentenorientierung zur Initiierung von Innovationsprozessen betrachtet werden müssen [3]. Daher müssen im Konzept beide Induktionsrichtungen berücksichtigt ­werden. Geschäftsmodelle beschreiben das Grundprinzip, nach dem eine Organisation Werte schafft, vermittelt und erfasst [4]. Demnach sind in der Entwicklung von neuen Geschäftsmodellen die Anforderungen des Kunden frühzeitig zu adressieren. Hierbei müssen die Werkzeuge und Prozesse eine Kundenintegration sowie Kundenorientierung ermöglichen. Geeignete Werkzeuge und Prozesse können sich hierbei an Design-Thinking-Ansätzen orientieren. Die Entwicklung eines Geschäftsmodells basiert auf initialen Ideen (zweckoder mittelinduziert), die im weiteren Konzeptverlauf kontinuierlich ausgearbeitet werden. Die Phasen des Konzeptes gliedern sich grob in eine Ideengenerierung, Ideenbewertung und -auswahl sowie der Ausarbeitung der ausgewählten Ideen zu einem detaillierten, individuellen Geschäftsmodell. Das Konzept schließt mit der Anforderungsdefinition an die technische und organisatorische Realisierung ab und verläuft somit vom Allgemeinen zum Spezifischen. Innerhalb des Konzeptes wird die Zielerreichung der einzelnen Phasen durch verschiedene Werkzeuge unterstützt. Verfügbarkeitsorientierte Geschäftsmodelle sind individuelle Lösungen, die unterschiedliche Kompetenzen und Wissen verlangen. Um eine solche integrierte Lösung anzubieten, müssen unterschiedliche Partner aus verschiedenen Disziplinen in einem erweiterten Wertschöpfungsnetzwerk zusammenarbeiten. Die Planung des erweiterten Wertschöpfungsnetzwerkes ist Teil der Geschäftsmodellentwicklung und im Konzept zu berücksichtigen. Aus den oben genannten Aspekten können zusammenfassend die folgenden Anforderungen an das Konzept definiert werden.

3  Konzeption verfügbarkeitsorientierter Geschäftsmodelle

19

Anforderung 1: Das Konzept soll den Anwender befähigen, individuelle, verfügbarkeitsorientierte Geschäftsmodelle zu entwickeln. Dabei soll das Konzept vom Allgemeinen (grundlegende Ideen und Überlegungen) zum Spezifischen (unternehmensspezifisch ausgearbeitete Geschäftsmodelle) verlaufen. Grundlegend können daraus folgende Grobphasen definiert werden: Ideengenerierung, Ideenbewertung und -auswahl, Ausarbeitung der Ideen zu einem detaillierten Geschäftsmodell. Anforderung 2: Die Entwicklung der Geschäftsmodelle soll sowohl zweck- als auch mittelinduziert erfolgen. Anforderung 3: Nach der Entwicklung der Geschäftsmodelle sollen Anforderungen an die technische sowie organisatorische Realisierung abgeleitet werden. Die Anforderungsgenerierung ist Teil des Konzeptes und stellt die Anforderungsliste für die Realisierungsphase dar. Anforderung 4: Bei der Entwicklung neuer Geschäftsmodelle ist eine kundenorientierte Vorgehensweise anzuwenden. Das Konzept soll den Nutzer in das Zentrum der Entwicklung stellen. Geeignete Vorgehensweisen (z. B. Ansätze des Design Thinkings) können als Orientierung dienen. Weiterhin können relevante Methoden (z.  B.  Customer Journey) im Konzept angewendet werden. Anforderung 5: Innerhalb der einzelnen Phasen des Konzeptes kommen Werkzeuge zum Einsatz, welche die Zielerreichung in den jeweiligen Phasen unterstützen. Hierbei sind erprobte und bewährte Methoden zu präferieren. Anforderung 6: Unterschiedliche Disziplinen und Unternehmen müssen zur Realisierung von Verfügbarkeitsgarantien unterschiedliche Kompetenzen und Wissen einbringen. Die Realisierung der garantierten Verfügbarkeiten erfolgt nur im Zusammenspiel innerhalb eines erweiterten Wertschöpfungsnetzwerks, bestehend aus Entwicklungs-, Produktions- und Servicenetzwerk. Die Planung dieses erweiterten Wertschöpfungsnetzwerkes ist Teil des Konzepts. Im Projektkontext wird an verschiedenen Stellen von Anforderungen gesprochen. Neben den hier genannten Anforderungen an das Konzept, fallen bei der Entwicklung der Geschäftsmodelle Anforderungen an, die im Text als High-Level-Anforderungen bezeichnet werden. In der technischen Realisie­rung werden aus diesen High-Level-­Anforderungen dann technische Anforderungen (auch „feingranulare Anforderungen“) abgeleitet, die im Laufe der Realisierung weiter verfeinert werden. Sollte nur von „Anforderungen“ gesprochen werden, sind stets die Anforderungen der im jeweiligen Textabschnitt betrachteten Abstraktionsebene gemeint. In Abb. 3.1 wird diese Abgrenzung bildlich dargestellt.

3.2

 onzept zur Entwicklung von verfügbarkeitsorientierten K Geschäftsmodellen

Ausgehend von den gestellten Anforderungen wurde das Konzept zur Entwicklung von vGM innerhalb des Projekts erarbeitet. Dabei wurden während der Projektlaufzeit diverse Workshops gemeinsam mit den Projektpartnern durchgeführt. Die Zusammenstellung der

20

P. Kölsch et al.

Abb. 3.1  Anforderungsausprägungen im Projektkontext

Workshop-Gruppen aus Unternehmen und Lehrstühlen der Universität gewährleistete eine interdisziplinäre Arbeitsweise. Aufgrund der Anforderung nach unterschiedlichen Induktionsrichtungen zur Geschäftsmodellentwicklung und -realisierung wurde das Konzept für Innovationen aus der Market-pull-Richtung und der Technology-push-Richtung gestaltet. Eine Initiierung durch Kundenanforderungen repräsentiert die Market-pull-Richtung. Für eine starke Kundenorientierung wurden Techniken aus dem Bereich des Design Thinkings eingesetzt. Design Thinking ist eine Methode aus dem Innovationsmanagement, die den Nutzer in das Zen­ trum der Entwicklung setzt [5]. Allerdings würde die alleinige Betrachtung des Kunden nur zu inkrementellen Innovationen führen. Die Initiierung auf Basis neuer Technologien ermöglicht auch disruptive Geschäftsmodellideen auf Basis radikaler Produkt- und Prozessinnovationen, die nicht vom Kunden, sondern innerhalb des Unternehmens entstehen. Dabei ist allerdings auch zu beachten, dass bei einer technologiegetriebenen Induktion zu Beginn potenzielle Markt-Applikationen noch weitgehend unbekannt sind und daraus eine höhere Marktunsicherheit resultiert [6]. Durch den Einbezug der unterschiedlichen Partner in die Workshops und die Entwicklung und Realisierung der Anwendungsfälle wurde der Open-Innovation-Gedanke realisiert [7]. Die Anwendungsunternehmen ließen das notwendige Branchenwissen in die Ausgestaltung der Workshops mit einfließen. Dadurch konnten die weiteren Projektpartner ihre vorhandenen Kompetenzen zur Realisierung des jeweiligen Anwendungsfalls ­einbringen. Bei der Gestaltung der unterschiedlichen Phasen wurde explizit darauf geachtet, die zur Realisierung der Ideen entstehenden Anforderungen als High-Level-Anforderungen zu dokumentieren und den Partnern der Teilziele 2 und 3 zur technischen Realisierung weiterzugeben.

3  Konzeption verfügbarkeitsorientierter Geschäftsmodelle

21

Abb. 3.2  Konzept zur Entwicklung verfügbarkeitsorientierter Geschäftsmodelle

Das Konzept wird in Abb. 3.2 dargestellt und besteht aus insgesamt sieben Phasen, die nachfolgend ausführlich beschrieben werden. Die eingesetzten Tools wurden dabei von den Projektpartnern ausgewählt, können allerdings bei Bedarf durch weitere Tools ergänzt bzw. ersetzt werden. Dabei werden die ersten beiden Phasen nur bei Anwendungsfällen durchlaufen, die aus der Market-pull-Richtung initiiert werden. Der Technologypush-­ Ansatz startet mit Phase 3. Anschließend werden beide Ansätze identisch weitergeführt. Phase 1 – Markt und Trends Die erste Konzeptphase wird ausgehend vom Kunden anhand von Anregungen oder neuen Anforderungen initiiert (Market-pull). Basierend auf dieser Initiierung der Geschäftsmodellentwicklung muss sich das Entwicklerteam mit den Gegebenheiten und dem Umfeld des Kunden auseinandersetzen. Dazu werden bestehende Trends in der Kundenbranche sowie den Branchen der am erweiterten Wertschöpfungsnetzwerk beteiligten ­Unternehmen analysiert sowie innerhalb eines Workshops präsentiert und diskutiert. Ziel ist dabei die Sensibilisierung der teilnehmenden Partner für die Fachgebiete und Trends der anderen Partner. Dadurch ist es den Partnern möglich, Verknüpfungen zu ihren eigenen Gebieten herzustellen. Zu Beginn werden die identifizierten Trends mittels eines

22

P. Kölsch et al.

Trendradars aufgenommen [8]. Ziel des Trendradars ist es, eine Entscheidungsgrundlage für die Berücksichtigung von Trends in den nachfolgenden Phasen der GM-Entwicklung zu bieten. Zuerst wird ein sogenannter Radarschirm aufgezeichnet. Der Mittelpunkt bildet das heutige Datum, der Rand des Radars ein spezifisch festgelegtes Datum. Identifizierte Trends für das angegebene Themengebiet werden in das Trendradar eingetragen. Die Größe des Trendsymbols repräsentiert die Wichtigkeit. Die Trends können weiterhin farblich markiert werden, um das Potenzial für das Unternehmen und die Netzwerkpartner zu visualisieren. Dabei kann das Radar in verschiedene themenspezifische Segmente eingeteilt werden und die jeweiligen Trends den Segmenten zugeordnet werden. Je weiter weg die Trends vom Mittelpunkt eingetragen werden, desto geringer ist die aktuelle Beeinflussung durch den Trend. Es können auch vorgegebene Trendradare eingesetzt werden und aus diesen relevanten Trends identifiziert werden (z. B. Hype-Cycle-Model nach Gartner). Die nachfolgende Abb. 3.3 veranschaulicht das Trendradar. Als Alternative zum Trendradar kann eine Art Suchfeldanalyse durchgeführt werden [9]. Diese Technik liefert in der ursprünglichen Form einen Überblick über beeinflussende Markt- und Technologietrends und wurde im Projekt angepasst eingesetzt. Zu Beginn dieser Technik werden Impulsvorträge von den teilnehmenden Partnern vorbereitet und präsentiert. In dieser etwas abgewandelten Form der Suchfeldanalyse werden aus den präsentierten Impulsvorträgen der Teilnehmer und einer daran anschließenden freien Diskussionsphase die Markt- und Technologietrends aus den Vorträgen auf Moderationskarten gesammelt. Aus dieser Sammlung der möglichen Trends werden themenspezifische Suchfelder gebildet und mit Überschriften benannt. Mit einer Punktbewertung werden die Suchfelder hinsichtlich der initiierenden Kundenanforderungen/-anregungen priorisiert und das am höchsten priorisierte Suchfeld für die Ideenfindungsphase des Geschäftsmodells ausgewählt. Auf Basis der relevanten Trends aus dem Trendradar oder der Suchfeldanalyse wird die zweite Phase Ideenfindung Geschäftsmodell initiiert.

Abb. 3.3  Trendradar nach Durst et al. [7]

3  Konzeption verfügbarkeitsorientierter Geschäftsmodelle

23

Phase 2 – Ideenfindung Geschäftsmodell In der zweiten Konzeptphase werden Geschäftsmodellideen auf Basis der identifizierten Trends generiert. Die Phase wird in drei Unterphasen aufgeteilt: Ideenfindung, Ideendokumentation und Ideenauswahl. Zur Ideenfindung werden Kreativitätstechniken wie Brainstorming und Brainwriting genutzt. Dabei stehen immer die identifizierten Trends aus der vorhergehenden Phase im Mittelpunkt. Nach einer 20 bis 40-minütigen Brainstorming-Sitzung werden die erfolgversprechendsten Ideen in der Unterphase Ideendokumentation in den erweiterten Business Model Canvas (BMC) nach Echterhoff et al. eingefügt (siehe Abb. 2.4) [10]. Innerhalb dieser Phase werden lediglich Geschäftsmodellideen betrachtet, was bedeutet, dass die Felder noch nicht vollständig sind und noch nicht detailliert ausgefüllt werden müssen. Zu Beginn wird ein leeres Template des erweiterten BMC benötigt. Hier werden die einzelnen Elemente schrittweise ausgefüllt. Kann ein Element zum gegebenen Zeitpunkt noch nicht ausgefüllt werden, wird zum nächsten Feld übergegangen. Dieser Schritt erfolgt immer gemeinsam mit den Workshop-Teilnehmern, wobei jedes Element sowie die Einträge kritisch hinterfragt werden. Somit sind mögliche Probleme frühzeitig zu identifizieren, nicht umsetzbare/gewünschte Ideen können selektiert werden und müssen nicht im BMC dokumentiert werden. Resultieren aus diesem Vorgehen mehrere Geschäftsmodellideen, müssen diese anhand ausgewählter Kriterien bewertet und ausgewählt werden, um den Aufwand in den darauffolgenden Phasen zu reduzieren. Für die Phase der Ideenauswahl wurde eine eigene Bewertungsmethode in Form einer Bewertungsmatrix entwickelt. Die Bewertungskriterien basieren auf den Kriterien des Bewertungskonzepts nach Köster (2014) und wurden im Projekt hinsichtlich PSS und Verfügbarkeitsorientierung angepasst und erweitert [11]. Die Bewertungsmatrix eignet sich zur Bewertung von Geschäftsmodellideen und bietet die Möglichkeit, mehrere Geschäftsmodellideen miteinander zu vergleichen. Die Bewertungsmatrix beinhaltet vorformulierte Bewertungsaussagen zu den Kriterien Strategiekonformität, Wettbewerbsfähigkeit und Verfügbarkeitsorientierung einer Geschäftsmodellidee. Das Entwicklungsteam muss die Geschäftsmodellideen und einzelne Elemente des dazugehörigen BMC bewerten. Nach der Bewertung können die Geschäftsmodellideen mit Hilfe eines Polaritätsprofils miteinander verglichen werden. Je nach verfügbaren Kapazitäten bei der GM-Entwicklung kann eine oder auch mehrere Geschäftsmodellideen im Konzept weiterverfolgt werden. Die ausgewählten GM-Ideen dienen als Grundlage für die Phase 3 Beschreibung des Anwendungsfalls. Die Bewertungsmatrix wird in der nachfolgenden Abb. 3.4 veranschaulicht. Die bisherigen Konzeptschritte wurden aufgrund von Kundenfeedback oder veränderten Kundenanforderungen initiiert. Um nicht nur inkrementelle, kundenzentrierte Innovationen hervorzubringen, sondern auch technologiegetriebene Innovationen zu ­berücksichtigen, wurde im Konzept beide Sichtweisen integriert betrachtet. Der Technology-push-Ansatz startet mit der Ausarbeitung einer Idee bzw. eines Anwendungsfalls für den Einsatz der neuen Technologie. Vorgelagerte Phasen wie beispielsweise eine technologieorientierte Suchfeldanalyse wurden im Konzept nicht miteinbezogen.

24

P. Kölsch et al.

Abb. 3.4  Bewertungsmatrix zur Bewertung von Geschäftsmodellideen

Die ersten beiden Phasen werden somit nur bei einer Market-pull-Innovation durchlaufen. Die darauffolgenden Phasen werden bei beiden Induktionsrichtungen analog durchgeführt. Phase 3 – Beschreibung des Anwendungsfalls Aus den Geschäftsmodellideen der Phase 2 werden in dieser Phase passende Anwendungsfälle (Use-Cases) generiert und beschrieben. Die Use-Cases werden gemeinsam erarbeitet und anhand eines Use-Case-spezifischen Templates textuell beschrieben. Die

3  Konzeption verfügbarkeitsorientierter Geschäftsmodelle

25

Kriterien des Templates können je nach Use-Case variieren. Zunächst wird der Use-Case anhand einer Kurzbeschreibung und mittels Abbildung hinsichtlich des Produkts, der Produktfunktion und des Ziels dokumentiert. Danach werden Inhalte definiert, die den Betrachtungsgegenstand unter anderem in Bezug auf seine Verfügbarkeit genauer beschreiben. Darunter fallen Kriterien wie relevante Komponenten, Lokalisierung am ­Produkt, Ausfallursache und -häufigkeit und betroffene Geschäftsprozesse. Für die ganzheitliche Beschreibung werden die Felder des BMC der Geschäftsmodellidee mit aufgenommen. Zudem werden technische, wirtschaftliche und rechtliche Rahmenbedingungen beschrieben. Als letzter Teil der Beschreibung wird eine prozessuale Betrachtung des Use-Cases angefertigt, bei dem dieser in einzelne Prozessschritte gegliedert wird und für jeden Prozessschritt Akteure und beteiligte Systeme identifiziert werden. Bei mehreren Use-Cases können die ausgefüllten Templates zu einem Gesamtdokument konsolidiert und eine gemeinsame Storyline entwickelt werden. Das im Projekt entwickelte Template findet sich im Anhang. Die Beschreibung des Use-Cases dient als inhaltliche Begrenzung für die nachfolgenden Konzeptschritte und erleichtert das Projektmanagement. Phase 4 – Bedürfnisanalyse und Lösungsideen Diese Konzeptphase zielt auf die direkte Einbindung des Kunden in die Entwicklung von vGM.  Dabei werden die Bedürfnisse des Kunden erfasst, analysiert und Lösungsideen entwickelt, welche die Kundenbedürfnisse befriedigen. Existieren unterschiedliche Kundengruppen oder große Unterschiede innerhalb einer Kundengruppe, können die Bedürfnisse in Form einer Persona generalisiert werden [5]. Die Persona repräsentiert eine fiktive Person mit Bedürfnissen und Charaktereigenschaften, die sich aus den unterschiedlichen Kunden bzw. Kundengruppen zusammensetzen [12]. Personas werden überwiegend im Entwicklungsprozess von Produkten und Services eingesetzt [13]. In dieser Phase werden die adressierten Kundengruppen in einer Persona zusammengefasst, um im Anschluss durch die Customer Journey die Bedürfnisse der Persona abzuleiten, Serviceideen gemeinsam mit Kunden und Partnern zu erarbeiten und erste Anforderungen an die Umsetzung zu generieren. Das Ziel einer Persona ist dementsprechend, ein generalisiertes und gleichzeitig detailliertes Abbild mit möglichst vielen Charakteristika einer Kundengruppe zu schaffen [5]. Die adressierten Kundengruppen aus den BMC der vorgehenden Phase können als Anhaltspunkt genutzt werden. Wurde noch keine Kundengruppe definiert, muss die Auswahl an dieser Stelle für die Geschäftsmodellidee erfolgen. Dem Entwickler wird somit der Bezug zu der Kundengruppe während der Entwicklung vereinfacht [14]. In Abb. 3.5 findet sich das im Projekt genutzte Template zur Erstellung der Persona. Im Anschluss an die Erstellung der Persona wird aus deren Sicht eine Customer Journey durchgeführt. Mit der Customer Journey ist es möglich, die Beziehung zwischen Kunden/Persona und PSS-Anbieter aufzuzeigen. Die Customer Journey beschreibt den „Weg“ des Kunden bei der Nutzung eines Produktes oder einer Dienstleistung und identifiziert Berührungspunkte und Interaktionsschritte des Kunden mit dem PSS-Anbieter [15]. Zu Beginn wird der Nutzungsprozess der Persona mit dem adressierten Produkt

26

P. Kölsch et al.

Abb. 3.5  Template zur Erstellung einer Persona

oder Service festgelegt. Der Prozess wird in einzelne sinnvolle Prozessschritte unterteilt. Im Anschluss wird jeder Prozessschritt dahingehend analysiert, dass in Zusammenarbeit mit dem Kunden spezifische Bedürfnisse erfasst werden. Anschließend werden Lösungsmöglichkeiten zur Bedürfnisbefriedigung für einen oder mehrere Prozessschritte mit den Partnern des erweiterten Wertschöpfungsnetzwerks erarbeitet. Auch hier kann die Technik Brainstorming/Brainwriting genutzt werden. Zudem können bereits gesammelte ­Geschäftsmodellideen aus den vorherigen Phasen in die Felder zur Bedürfnisbefriedigung eingetragen werden. Für die passenden Lösungsansätze können in einer weiteren Zeile erste Anforderungen zur technischen Entwicklung und Umsetzung der Lösung aufgenommen werden. Das Template zur Durchführung einer Customer Journey wird in Abb. 3.6 dargestellt. Bei der Verfolgung des Technology-push-Ansatzes dient diese Phase insbesondere zur Validierung der bereits erarbeiteten Ideen. Durch den fehlenden Kundenbezug in den ersten Phasen des Technology-push-Ansatzes müssen die erarbeiteten Ideen so früh wie möglich mit den Kundenbedürfnissen abgeglichen werden, um die Entwicklung eines PSS zu vermeiden, welches die Kundenbedürfnisse nicht oder nur unzureichend befriedigt. Sollten die erarbeiteten Ideen aus dem Market-Pull-Ansatz nicht mit den identifizierten Kundenbedürfnissen übereinstimmen, müssen die Geschäftsmodellideen in einem erneuten Durchlauf der Phasen zwei bis vier überarbeitet werden. Phase 5 – Detaillierung des Geschäftsmodells Nachdem die Customer Journey durchgeführt wurde und somit die Geschäftsmodellideen mit den Kundenbedürfnissen abgeglichen und validiert wurden, wird das adressierte Geschäftsmodell weiter ausgearbeitet. Dazu dient die bereits in dem BMC dokumentierte Geschäftsmodellidee aus Phase 2. Ziel dieser Phase ist ein komplett ausgefüllter BMC sowie ein gemeinsames Verständnis des Geschäftsmodells.

3  Konzeption verfügbarkeitsorientierter Geschäftsmodelle

27

Abb. 3.6  Template zur Durchführung einer Customer Journey

Phase 6 – Planung der Partner, Ressourcen und Interaktionen Nach der detaillierten Ausgestaltung des Geschäftsmodells wird in dieser Phase der Anwendungsfall bzw. das Geschäftsmodell visualisiert. Mit dieser Phase wird den Partnern der Ablauf des Anwendungsfalls, die beteiligten Schlüsselpartner, die Schlüsselaktivitäten und Schlüsselressourcen veranschaulicht. Ziel dieser Phase ist ein vollständig visualisiertes Wertschöpfungsnetzwerk des adressierten Use-Cases bzw. Geschäftsmodells [16]. Dies ermöglicht einen schnellen, umfassenden Überblick über die Gegebenheiten und vertieft das Verständnis der Zusammenhänge bei den Partnern. Zu Beginn werden die Partner und Schlüsselressourcen aus dem BMC auf Moderationskarten geschrieben und an einer Pinnwand verteilt. Danach wird das vGM gemeinsam prozessual beschrieben und die jeweiligen Information-, Geld- und Warenflüsse zwischen den Partnern und Schlüsselressourcen eingetragen. Zudem wird die Systemgrenze definiert, welche die Unternehmen, die Schlüsselpartner sowie die Schlüsselressourcen vom Kunden abgrenzt. Aus diesen Schritten entsteht eine übersichtliche Darstellung des Use-Cases mit allen Systemelementen des PSS. Die Notation zur Visualisierung des erweiterten Wertschöpfungsnetzwerks findet sich in Abb. 3.7. Anschließend beginnt die Phase Planung der Umsetzung. Phase 7 – Planung der Umsetzung Diese Phase dient der Planung der Umsetzung des entwickelten vGM. Ziel dieser Phase ist zum einen die Erarbeitung des detaillierten Ablaufs des Use-Cases in prozessualer

28

P. Kölsch et al.

Abb. 3.7  Notation zur Visualisierung des erweiterten Wertschöpfungsnetzwerks

Form (Prozessanalyse) und daraus abgeleiteten High-Level-Anforderungen für die technische Entwicklung. Zum anderen wird anhand der Technik „Masterplan of Action“ ein Umsetzungsplan ausgehend von der aktuellen Unternehmenssituation entwickelt, in dem notwendige Handlungsschritte innerhalb verschiedener Unternehmensbereiche definiert werden. Die Prozessanalyse zielt darauf ab, die notwendigen High-Level-Anforderungen an die technische Realisierung des Systems bzw. der Systemelemente abzuleiten. Als Grundlage der Prozessanalyse kann der bereits adressierte Prozess der Customer Journey verwendet werden. Dieser Prozess kann für die Analyse weiter detailliert werden. Für jeden Prozessschritt müssen die erforderlichen Schlüsselressourcen, Schlüsselpartner und ­Schlüsselaktivitäten (sog. Schlüsselelemente) betrachtet werden, die zur Erfüllung des Prozessschritts notwendig sind. Die Funktionen der Schlüsselelemente sind in jedem Prozessschritt zu beschreiben. Die hierbei beschriebenen Funktionen bilden die HighLevel-­Anforderungen. In einem nachgelagerten Schritt müssen die generierten High-Level-Anforderungen in technische Anforderungen übersetzt werden. Eine beispielhafte Prozessanalyse findet sich in Abb. 3.8. Anschließend an die Prozessanalyse wird unter Einsatz der Technik Masterplan of Action (MoA) die Einführung des vGM auf verschiedenen Unternehmensebenen geplant. Die Technik MoA dient dazu, ein ganzheitliches Bild bzw. einen Ordnungsrahmen für die Umsetzung des entwickelten Geschäftsmodells zu erarbeiten. Ziel ist die Identifikation der notwendigen Handlungsfelder, in denen Transformationsaktivitäten zur Realisierung des vGM durchgeführt werden müssen. Im ersten Schritt werden die zu betrachtenden Unternehmensbereiche bzw. Cluster definiert, welche von einer Transformation hin zum vGM bzw. zur Umsetzung eines solchen vGM relevant sind (z. B. Unternehmensstrategie, Prozesse, Kultur). Anschließend wird der Ziel-Zustand (auch: Soll-Zustand) je definiertem Unternehmensbereich erarbeitet. Dabei wird zuerst die Perspektive eines Unternehmens eingenommen, welches bereits ein vGM anbietet. Aus dieser Perspektive wird Schritt für Schritt in gemeinsamer Gruppenarbeit mit den PSS-Anbietern das Zielbild für den betrachteten Unternehmensbereich definiert. Im Anschluss an den Ziel-Zustand wird

3  Konzeption verfügbarkeitsorientierter Geschäftsmodelle

29

Abb. 3.8  Vorgehen zur Prozessanalyse

Abb. 3.9  Template des Masterplans of Action

der aktuelle Ist-Zustand je definiertem Unternehmensbereich erarbeitet. Nachdem der Ziel-Zustand definiert wurde, folgt also das Zurückversetzen in die derzeitige Ausgangssituation. Somit wird die Perspektive vom zukünftigen vGM zum derzeitigen, funktionsorientierten GM gewechselt. Ausgehend von diesem Perspektivenwechsel werden die Zustände in den jeweils definierten Unternehmensbereichen für den Ist-Zustand beschrieben. Nachdem ein Verständnis von Ziel- sowie Ist-Zustand erarbeitet wurde, werden im letzten Schritt die jeweiligen Handlungsfelder entwickelt, die es zu betrachten und in der ­anschließenden Umsetzung zu erarbeiten gilt. Als Ergebnis resultieren definierte Ist- und Ziel-Zustände und Maßnahmen für jedes identifizierte Handlungsfeld zur Transformation vom Ist- in den Ziel-Zustand. Ein beispielhafter MoA wird in Abb.  3.9 dargestellt. Es schließt sich die technische Umsetzung der vGM basierend auf den hier erarbeiteten Ergebnissen an.

30

P. Kölsch et al.

Literatur 1. Schallmo DRA (Hrsg) (2014) Theoretische Grundladen der Geschäftsmodell-Innovation – Definitionen, Ansätze, Beschreibungsraster und Leitfragen. In: Kompendium Geschäftsmodell-­ Innovation  – Grundlagen, aktuelle Ansätze und Fallbeispiele zur erfolgreichen Geschäftsmodell-Innovation. Springer Gabler, Wiesbaden, S 1–30 2. Benedix G (2003) Innovationsmanagement  – Konzept zur systemischen Gestaltung und Umsetzung. Dissertation, Technische Universität Kaiserslautern 3. Rothwell R (1992) Successful industrial innovation – critical factors for the 1990s. R&D Manag 22(3):221–240 4. Osterwalder A, Pigneur Y (2010) Business model generation – a handbook for visionaries, game changers, and challengers. Wiley, Canada 5. Liedtka J, Ogilvie T (2011) Designing for growth  – a design thinking tool kit for managers. Columbia University Press, New York 6. Herstatt C, Lettl C (2000) Management von technologie-getriebenen Entwicklungsprojekten. Working paper No. 5, Hamburg University of Technology, Hamburg 7. Chesbrough H (2006) Open Innovation – a new paradigm for understanding industrial innovation. In: Chesbrough H, Vanhaverbeke W, West J (Hrsg) Open innovation – researching a new paradigm. Oxford University Press, Oxford 8. Durst M, Stan S, Stößer L, Edelmann F (2010) Kollaboratives Trendmanagement. HMD Prax Wirtschaftsinformatik 47(3):78–86 9. Abele T (Hrsg) (2013) Einführung in die Suchfeldbestimmung und Ideenbewertung in der frühen Phase des Innovationsprozesses. In: Suchfeldbestimmung und Ideenbewertung. Springer Gabler, Wiesbaden, S 1–18 10. Echterhoff B, Gausemeier J, Koldewey C, Mittag T, Schneider M, Heiko S (2016) Geschäftsmodelle für die Industrie 4.0. In: Jung HH, Kraft P (Hrsg) Digital vernetzt. Transformation der Wertschöpfung. Hanser, München, S 35–55 11. Köster, O (2014) Systematik zur Entwicklung von Geschäftsmodellen in der Produktentstehung. Dissertation, Universität Paderborn 12. Aoyama M (2005) Persona-and-scenario based requirements engineering for software embedded in digital consumer products. In: Proceedings of the 13th IEEE international conference in requirements engineering, Paris S 85–94 13. Pruitt J, Grudin J (2003) Personas – practice and theory. In: Proceedings of the 2003 conference on designing for user experience, San Francisco S 1–15 14. West S, Di Nardo S (2016) Creating product-service system opportunities for small and medium size firms using service design tools. Procedia CIRP 47:96–101 15. Nenonen S, Rasila H, Junnonen JM, Kärnä S (2008) Customer Journey – a method to investigate user experience. In: Proceedings of the Euro FM conference, Manchester 54–63 16. Kölsch P, Herder CF, Zimmermann V, Aurich JC (2017) A novel concept for the development of availability-oriented business models. Procedia CIRP 64:340–344

4

Entwicklung intelligenter, kommunikationsfähiger Komponenten Paaranan Sivasothy, Dani Bechev, Horst Brehm, Georgis Bulun, Claudia Glenske, Julian Imwalle, Andrej Keksel, Ralf Mattukat, Bernd Sauer und Jörg Seewig

Zusammenfassung

In diesem Kapitel wird die systematische Vorgehensweise zur Entwicklung intelligenter, kommunikationsfähiger Komponenten, die zur Umsetzung von verfügbarkeitsorientierten Geschäftsmodellen notwendig sind, erklärt. Um einen anwendungsspezifischen Predictive-Maintenance-Ansatz, der die technische Grundlage für derartige Geschäftsmodelle bildet, umzusetzen, müssen zunächst die servicerelevanten bzw. ausfallkritischen Komponenten identifiziert werden. Hierzu werden verschiedenen Vorgehensweisen genannt. Anschließend ist der Ausfallmechanismus zu untersuchen, der

P. Sivasothy (*) · G. Bulun · A. Keksel · J. Seewig Lehrstuhl für Messtechnik und Sensorik, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected]; [email protected]; [email protected] D. Bechev · B. Sauer Lehrstuhl für Maschinenelemente und Getriebetechnik, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected] H. Brehm Schaeffler AG, Herzogenaurach, Deutschland E-Mail: [email protected] C. Glenske Sensitec GmbH, Lahnau, Deutschland E-Mail: [email protected] J. Imwalle · R. Mattukat Anedo GmbH, Eydelstedt, Deutschland E-Mail: [email protected]; [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 J. C. Aurich et al. (Hrsg.), Entwicklung datenbasierter Produkt-Service Systeme, https://doi.org/10.1007/978-3-662-59643-2_4

31

32

P. Sivasothy et al.

zum Versagen dieser Komponente führt. Auf Basis dieser Informationen kann ein ­geeignetes Predictive-Maintenance-Überwachungskonzept entwickelt werden. Es werden Verfahren vorgestellt, die sich für unterschiedliche Anwendungsfelder eignen. Die vorausschauende Wartung einer individuellen Maschine kann die Entwicklung neuer Sensoren erfordern. Um den gesamten Entwicklungsprozess bei der technischen Realisierung von verfügbarkeitsorientierten Geschäftsmodellen zu beschleunigen, ist der Aufbau eines virtuellen Prototyps empfehlenswert. Die allgemeine physikalische Modellierung wird erläutert. Weiterhin spielt die Kommunikation der Daten an eine zen­ trale Schnittstelle eine wesentliche Rolle. Der Datentransfer hat hohe Anforderung hinsichtlich der Robustheit und Effizienz zu erfüllen. Die entsprechende Vorgehensweise wird ebenfalls beschrieben.

4.1

Identifikation servicerelevanter Komponenten

In diesem Kapitel wird die mechanische Seite einer Maschine betrachtet. Die Elektronik, elektronische Komponenten, Software und Sensorik selbst werden vorerst nicht betrachtet. Alle Komponenten in einem komplexen System werden genutzt und sind daher verschleißgefährdet. Deswegen sind Ausfälle sowohl im mechanischen als auch im elektronischen sowie im Softwarebereich möglich. Die Methoden, die in dieser Arbeit aufgelistet sind, können analog an mechanischen, elektronischen Komponenten sowie an Softwareanwendungen angewendet werden. Eine Maschine erfüllt im Allgemeinen mehrere Funktionen und setzt sich aus mehreren Bauteilen und Baugruppen zusammen. An dieser Stelle können zwei Betrachtungsebenen unterschieden werden, einerseits die Funktionsstruktur der Maschine, andererseits die Produktstruktur. Die Transformation der Funktionsstruktur in eine Produktstruktur und die Produktarchitektur werden in Abb. 4.1 dargestellt. Die Funktionsstruktur beinhaltet alle Funktionen der Maschine, die in Haupt- und Nebenfunktionen aufgeteilt werden können. Die Produktstruktur beinhaltet alle Baugruppen,

Abb. 4.1  Produktarchitektur nach [1]

4  Entwicklung intelligenter, kommunikationsfähiger Komponenten

33

Unterbaugruppen und Bauteile der Maschine. Jedes Bauteil spielt eine bestimmte Rolle für jede Baugruppe und jede Unterbaugruppe erfüllt eine bestimmte Funktion für die Gesamtbaugruppe oder für die gesamte Maschine. Die Betrachtung der Funktionen erfolgt analog zu der Bauteilbetrachtung. Jede Unterfunktion hat eine bestimmte Wichtigkeit für die Nebenfunktionen, die Hauptfunktionen und die Gesamtfunktion. Es existieren eine oder mehrere Verknüpfungen zwischen den Bauteilen, Baugruppen und den Funktionen. Wenn ein Bauteil oder eine Baugruppe defekt ist, dann werden eine oder mehrere Funktionen nicht erfüllt. An dieser Stelle tritt folgende Herausforderung auf: Eine komplexe Maschine besteht aus sehr vielen Komponenten und erfüllt unterschiedliche Funktionen. Es wäre zu teuer und aufwendig alle Komponenten zu überwachen. Deshalb ist es notwendig, die Anzahl der zu überwachenden Bauteile und Baugruppen so gering wie möglich zu halten. Nur die wichtigsten, ausfallkritischen Bauteile und Baugruppen sollen überwacht werden und Informationen über ihren eigenen Zustand kommunizieren können. Wenn eine oder mehrere Funktionen nicht erfüllt werden, wird die technische Maschinenverfügbarkeit reduziert (verringert). Im Rahmen von InnoServPro wird die technische Verfügbarkeit in Abschn. 2.3 definiert. Die Maschinenverfügbarkeit wird durch Nichterfüllung einer oder mehrerer Funktionen reduziert. Werden eine oder mehrere Funktionen nicht erfüllt, kann auf einen oder mehrere Fehler im System der gesamten Maschine geschlossen werden. Nach Eberlin und Hock lassen sich drei Gruppen von Fehlern definieren (frühe Fehler, Fehler wegen Verschleiß und Abnutzung und zufällige Fehler), die in Abschn. 2.3 näher erläutert werden [2]. Im Kaufvertrag zwischen Anbieter und Kunde muss geregelt werden, welche Fehlerart oder Fehlerarten vom Maschinenhersteller überwacht werden. So kann auch festgelegt werden, bei welchen Komponentenausfällen der Anbieter für die Verfügbarkeit der Maschine garantiert. Die nachfolgende Methodik zur Analyse und Identifikation der servicerelevanten Komponenten kann bei allen drei Fehlerarten eingesetzt werden. Identifikation servicerelevanter Komponenten Die Analyse und Identifikation servicerelevanter Komponenten beschreibt den Prozess zur Bestimmung der ausfallkritischen Komponenten einer Maschine. Diese Komponenten sollen überwacht werden und in der Lage sein, ihren Verschleißzustand selbst zu detektieren und der Maschine weiterzugeben. Zur Analyse und Identifikation der servicerelevanten Komponenten in den Use-Case wurden mehrere Methoden analysiert. Das Ziel dabei ist, dem Industriegüterhersteller passende, allgemeingültige Methoden zur Auswahl, Analyse und Identifikation der servicerelevanten Bauteile und Baugruppen zur Verfügung zu stellen. Die zur Analyse verwendeten Methoden sind [3]: • FMEA • Fehlerbaumanalyse nach DIN 25424-1 und DIN 25424-2 • Ereignisablaufanalyse nach DIN 25419

34

• • • • •

P. Sivasothy et al.

PAAG/HAZOP Gefährdungsbaumanalyse Risikoeinschätzung nach DIN EN 62061 Risikoeinschätzung mittels Risikozahlen nach Reudenbach Risikoeinschätzung mittels der Methoden nach Kinney

Diese Methoden können direkt ohne Modifikationsbedarf für die Analyse und Identifikation der servicerelevanten Komponenten eingesetzt werden. Die Verfahren, die am häufigsten in der Industrie eingesetzt werden, sind die FMEA, die Fehlerbaumanalyse und die Ereignisablaufanalyse. Die Verfahren zur Risikoeinschätzung sind grundsätzlich für die Analyse und Auswahl der servicerelevanten Komponenten geeignet, müssen allerdings entsprechend modifiziert werden. Bei der Modifikation dieser Verfahren muss darauf geachtet werden, dass die Bauteil- und Baugruppenausfälle im Mittelpunkt stehen. Bei jedem Verfahren ist die vordefinierte Maschinenverfügbarkeit zu berücksichtigen. Die FMEA, Fehlerbaumanalyse und Ereignisablaufanalyse sind ausreichend, um servicerelevante Komponenten zu analysieren und zu identifizieren. Diese Verfahren wurden im Rahmen dieser Arbeit verwendet.

4.2

Analyse der Ausfallmechanismen

Nach der Identifikation der servicerelevanten Komponenten werden deren Ausfallmechanismen analysiert, um im nächsten Schritt eine Überwachungsstrategie zu entwickeln. Für die Analyse werden reale Schäden und Ausfälle der Komponenten untersucht. Dafür müssen Nichtübereinstimmungsberichte eingesetzt werden, um das Verständnis bzgl. auftretender Schadensbilder für die weitere Analyse aufzubauen. Anschließend muss die Ausfallursache identifiziert werden. Um das Verhalten und die Ausfallmechanismen der servicerelevanten Komponenten zu verstehen, sind Versuche und Untersuchungen notwendig. Dabei können durch Beobachtungen kritische Parameter und Einflussgrößen definiert werden. In Laborversuchen und Feldversuchen wird das Verhalten der Bauteile unter kritischen Bedingungen getestet. Durch Provokation von Fehlern und Ausfällen können die Ausfallmechanismen besser verstanden werden. Auf Basis der Ergebnisse können anschließend passende Überwachungsstrategien entwickelt werden. Die Analyse der Ausfallmechanismen kann somit in folgende Schritte unterteilt werden: . Analyse und Begutachtung von beschädigten Bauteilen und Komponenten 1 2. Identifikation der Ausfallursache 3. Durchführung von Versuchen zur Provokation von Ausfällen 4. Entwicklung von Verständnis über die Ausfallmechanismen 5. Definition von messbaren physikalischen Größen zur Überwachung

4  Entwicklung intelligenter, kommunikationsfähiger Komponenten

35

Auf Basis der definierten physikalischen Größen wird die Entwicklung von Überwachungskonzepten in Abschn. 4.3 initiiert.

4.3

Entwicklung von Überwachungskonzepten

Üblicherweise kauft ein produzierendes Unternehmen eine Maschine oder eine Anlage von seinem Produkt-Service System-(PSS-)Anbieter. Das Unternehmen zahlt in diesem Moment einen bestimmten Betrag für den zukünftigen Besitz des Investitionsgutes. Die Verantwortung für einen möglichst störungsfreien Betrieb liegt dann in erster Linie beim produzierenden Unternehmen selbst. Die grundlegende Idee hinter verfügbarkeitsorientierten Geschäftsmodellen ist das Übertragen dieser Verantwortung vom Kunden auf den PSS-Anbieter durch eine zusätzliche Dienstleistung [4, 5]. Da der PSS-Anbieter, der oft auch der Hersteller des Investitionsgutes ist, bereits eine historisch gewachsene ausgereifte Expertise bzgl. der technischen Pflege der Anlage hat, ist dieser als Garant für den störungsfreien Betrieb bestens geeignet. Die garantierte Verfügbarkeit, die der PSS-­ Anbieter dem produzierenden Unternehmen in Form der Zusatzleistung anbietet, reduziert wesentlich das Risiko eines Stillstandes und führt dadurch zu einer Gewinnsteigerung des Produzenten. Aus dieser Verantwortlichkeit resultieren mehrere neue Aufgaben für den PSS-­Anbieter. Jede einzelne Anlage, für die der Kunde die Zusatzleistung mit garantierten Verfügbarkeiten erworben hat, muss aus der Ferne überwacht werden. Die Daten aller Maschinen müssen dem PSS-Anbieter kommuniziert und dort zentralisiert werden. Eine zentrale Auswertung beurteilt die Daten und erkennt eine potenzielle Gefährdung so früh, dass eine vorausschauende Wartung (engl. Predictive Maintenance) möglich ist. Im Falle einer Gefährdung muss der Kunde bzgl. des potenziellen Stillstandes und der vorbeugenden Wartungsarbeiten informiert werden. Ein geschulter Mitarbeiter ist zu informieren, um den Kundenbesuch und die dazugehörigen Wartungsarbeiten durchzuführen. Der Grundstein für die erfolgreiche Bewältigung all dieser Aufgaben ist die zuverlässige Beurteilung der Verfügbarkeit einer Maschine. Dies setzt weitreichende Kenntnisse über die Verschleißmechanismen im Laufe des Lebenszyklus einer Maschine voraus [1]. Ein Überwachungskonzept, welches die Umsetzung verfügbarkeitsorientierter Geschäftsmodelle ermöglicht, hat die Beobachtung dieser Verschleißmechanismen im Fokus. Herkömmliche Überwachungskonzepte dienen vielmehr der Beobachtung des tatsächlichen Betriebes. In der Regel liegt ein gewünschter Soll-Betriebspunkt vor. Dieser Betriebspunkt kann durch mehrere physikalische Größen beschrieben werden wie zum Beispiel Spannung, Drehzahl, Druck, etc. Herkömmliche Überwachungskonzepte ermöglichen in den meisten Fällen die Beurteilung, wie präzise diese Werte eingehalten werden, sagen jedoch wenig bis nichts über den Verschleißzustand einzelner Komponenten oder der gesamten Maschine aus. Verfügbarkeitsorientierte Überwachungskonzepte müssen daher vollkommen neu konzipiert werden. Im ersten Schritt sind die ausfallkritischen oder servicerelevanten

36

P. Sivasothy et al.

­Komponenten zu identifizieren (vgl. Abb. 4.2). Da diese Komponenten bereits in der Vergangenheit vielerlei Störungen oder sogar Totalversagen verursacht haben, können diese in der Regel durch historische Daten aus Serviceberichten und Ersatzteilverkäufen ermittelt werden. Die Überwachung aller servicerelevanten Komponenten muss nicht zwingend zielführend sein. Beispielsweise kann, insbesondere bei Kleinteilen, der Aufwand für die Überwachung der Komponente unverhältnismäßig gegenüber dem Aufwand im Falle eines Ausfalls sein. Manche Komponenten weisen einen plötzlichen, impulsartigen Ausfall bei außergewöhnlichen Ereignissen auf. Da hier die Einflussmöglichkeiten stark eingeschränkt sind, ist der Mehrwert durch eine individuelle Überwachung kritisch zu beurteilen. Die Auswahl der wirtschaftlich effizientesten Komponente ist von essenzieller Bedeutung. Anschließend müssen die Verschleißmechanismen verstanden werden. Liegt dieses Know-how nicht unternehmensintern vor, so ist die Literatur heranzuziehen. Können auch

Abb. 4.2 Überwachungskonzepte

4  Entwicklung intelligenter, kommunikationsfähiger Komponenten

37

hier keine weitreichenden Informationen über die konkrete Maschine eingeholt werden, sind eigene Untersuchungen vorzunehmen. Experimentelle Tests mit unterschiedlicher Belastungsart und -dauer geben Aufschluss darüber, wie das Ermüdungsverhalten des Investitionsgutes im zeitvarianten Verhalten unterschiedlicher physikalischer Größen zu erkennen ist. Liegt nun das Wissen über die Verschleißmechanismen vor, ist eine geeignete physikalische Messgröße zu wählen. Dabei hat diese Größe zwei Kriterien zu erfüllen: a. Die Messgröße sollte über die Lebensdauer der Komponenten variieren. Wichtig ist dabei, dass das Verhalten charakteristisch für verschiedene Abschnitte der Lebensdauer ist bzw. sogenannte charakteristische Phasen existieren. Besonders gut geeignet sind physikalische Größen, die einen kontinuierlichen Verlauf über die Lebensdauer aufweisen. b. Die Messgröße sollte kostengünstig robust messbar sein. Ist dies der Fall, können im Folgenden handelsübliche Sensoren ausgewählt und eingesetzt werden. Sofern die direkte Messbarkeit der Größe nicht vorliegt, ist zu überlegen, inwiefern die physikalische Größe durch wesentlich einfacher zu messende Größen approximiert werden kann. Falls dies ebenso nicht möglich ist, sind eventuell neue Sensoren für den vorliegenden Anwendungsfall zu entwickeln. Im letzten Schritt ist eine geeignete Bewertung des Messgrößenverlaufs zu definieren. Dies kann in Form einer Kennlinienspezifikation stattfinden, welche die Messgröße einem bestimmten Bereich des Lebensdauerzyklus zuweist.

4.4

Sensorentwicklung

Die Umsetzung von verfügbarkeitsorientierten Überwachungskonzepten bringt die Verschiebung einer grundlegenden Zielstellung mit sich. Statt der Qualität des tatsächlichen Produktionsbetriebes, welche in herkömmlichen Überwachungskonzepten adressiert wird, steht die Beobachtung der Verfügbarkeit bzw. des Verschleißzustandes im Fokus. Dadurch gewinnen bisher eher unbeachtete physikalische Größen an Bedeutung. Beim Aufnahmeband eines Kartoffelvollernters steht beispielsweise weniger die Drehzahl des antreibenden Hydraulikmotors im Fokus, die den eigentlichen Maschinenbetrieb dominant bestimmt, sondern die Längung des Abstandes zwischen den kartoffeltransportierenden Metallstäben. Da die Messung einer Abstandsänderung zwischen Metallstäben wesentlich ungewöhnlicher ist als die Messung der Drehzahl einer Antriebswelle, kann die Entwicklung neuer Sensoren notwendig sein. Die Sensorentwicklung hat folgende vier Punkte primär zum Ziel: . Die Messgröße soll abgebildet werden. 1 2. Die Abbildung soll robust gegenüber Störeinflüssen sein.

38

P. Sivasothy et al.

3. Der Sensor soll kommunikationsfähig sein, um die zentrale Auswertung der Daten unterschiedlicher Maschinen zu ermöglichen. 4. Der Sensor soll intelligent sein, d. h. es soll eine anwendungsspezifische Vorverarbeitung und Auswertung der Daten innerhalb des Sensors stattfinden. Um diese Anforderungen zu erfüllen, erfordert die Sensorentwicklung das Durchlaufen der Schritte Konzeptionierung, Prototypenbau, Verifikation und Neu-Konzeptionierung in mehreren Schleifen. Der Prototypenbau kann dabei sowohl real als auch virtuell geschehen. Die Verifikation kann ebenfalls durch reale oder virtuelle Erprobung geschehen.

4.5

Physikalische Modellierung

Bei der Entwicklung eines neuen Produktes ist der Bau eines Prototyps unerlässlich. Aus einer Idee entsteht ein Konzept, welches die Zusammensetzung einzelner bekannter Elemente zu dem neuen Produkt vorsieht. Der Prototyp ermöglicht die Bewertung, ob die Einzelelemente im Gesamten so zusammenwirken wie gedacht. Jedoch bringt der Prototypenbau viele Nachteile mit sich. Da es sich dabei stets um eine Sonderanfertigung handelt, ist für den Bau ein enormes Maß an Wissen und Erfahrung erforderlich. Darüber hinaus fällt ein erheblicher finanzieller und personeller Aufwand an. Werden beim Prototyp Probleme oder Fehlerfälle ausfindig gemacht, so kann es vorkommen, dass die Ursachen hierfür aufgrund der physischen Einschränkungen und der hohen Systemkomplexität nur schwierig untersucht werden können. Auch sind die Szenarien, die getestet werden sollen, gegebenenfalls nur eingeschränkt realisierbar. In der heutigen Zeit übersteigt der Grad der softwaretechnischen Innovation oft den der mechanischen Innovation. Die Fortschritte, die hinsichtlich der Leistung von Grafikkarten in den letzten Jahren erreicht wurden, begründen u. a. die exzessiven Bemühungen, ungelöste, technische Problemstellungen mittels des Einsatzes von künstlicher Intelligenz zu bewältigen. Die Grundlage für jede künstliche Intelligenz ist die Existenz qualitativ und quantitativ hochwertiger Daten, um das abstrakte Wissen zu generieren, welches zur Problemlösung essenziell ist. Da eben solche Daten in vielen vielversprechenden ­Anwendungsfällen fehlen, ist die Entwicklung einer prototypischen künstlichen Intelligenz nicht möglich. Der herkömmliche Ansatz wäre somit das strukturierte Sammeln von industriellen Maschinendaten über einen langen Zeitraum. In vielen Fällen streckt sich dieser „lange Zeitraum“ über Jahre. Eine dynamische Alternative hierzu kann ein virtueller Prototyp sein (Abb.  4.3) [6]. Dabei werden die vor dem realen Prototypenbau definierten Spezifikationen und Kon­ struktionsdaten verwendet, um ein Simulationsmodell zu entwickeln, welches die wesentlichen mechanischen und elektrischen Vorgänge im System abbilden kann. Die Entwicklungszeit des virtuellen Prototyps ist in der Regel kürzer als die erforderliche Fertigungszeit des realen Prototyps. Die Materialkosten des virtuellen Prototyps beschränken sich auf den handelsüblichen Arbeitsrechner und die Lizenz einer geeigneten Software. Ein realer

4  Entwicklung intelligenter, kommunikationsfähiger Komponenten

39

Abb. 4.3  Virtueller Prototyp des Aufnahmebandes eines Kartoffelvollernters

Prototyp muss in der Regel von einem ganzen Team an Mitarbeitern betreut werden. Experimentelle Tests mit dem virtuellen Prototyp können von einer einzelnen Person durch einen alleinigen Mausklick durchgeführt werden. Parametervariationen, wie zum Beispiel die Änderung der Geometrie und Materialeigenschaften, können innerhalb eines virtuellen Prototyps unverzüglich realisiert werden. Ein anschließender Fertigungsprozess ist nicht erforderlich. Daher kann der virtuelle Prototyp gerade in der frühen Entwicklungsphase eines Produkts eine hilfreiche Stütze im Validierungsprozess sein. Im Zusammenhang mit der Nutzung von Methoden der künstlichen Intelligenz ist virtuelles Big Data ein interessanter Begriff. Da in vielen Situationen der Gewinn von realen Messdaten übermäßig kosten- und zeitintensiv ist, kann versucht werden, mit künstlichen oder virtuellen Großmengen an Daten die künstliche Intelligenz bis zu einem gewissen Grad zu trainieren. Der virtuelle Prototyp ist geeignet, um diese großen Datenmengen in kurzer Zeit zu generieren. Alle Komponenten haben einen idealen Arbeitspunkt. In der Realität kann dieser Bereich trotz genauer Untersuchung im Entwicklungsstadium selten exakt eingehalten werden. Die Überschreitungen korrelieren stark mit Maschinenausfällen. Die auf künstlicher Intelligenz basierende, vorausschauende Instandhaltung erfordert eine große Datenmenge, da der Ausfall selbst ein relativ seltenes Ereignis ist. Um ein Muster zwischen den Ausfällen und den Betriebsdaten zu erkennen, müssen diese Ausfälle mehrfach gemessen werden. Der große Vorteil des Simulationsmodells besteht darin, dass jeder beliebige Arbeitspunkt angefahren werden kann. Dazu können Simulationsszenarien definiert werden, die alle Betriebspunkte eines jeden Bauteils beinhalten. Basierend auf dieser Testmatrix können alle Szenarien sequenziell simuliert werden, wodurch nahezu alle Betriebspunkte für Big Data erzeugt werden können. Gegenüber dem notwendigen Aufwand bei experimentellen Tests spart die Simulation enorme Kosten und Zeit. Bei der Entwicklung des virtuellen Prototyps ist der zulässige Abstraktionsgrad zu definieren. Ein Simulationsmodell spiegelt das Original nie perfekt wider, so dass das Simulationsmodell stets als abstrahiertes Abbild zu sehen ist. Daher sind die im vorliegenden Anwendungsfall zu priorisierenden, physikalischen Eigenschaften des Systems zu spezifizieren. Viele komplexe Einflussfaktoren können für die qualitative Untersuchung vernachlässigt werden. Wichtig ist jedoch den kausalen Zusammenhang festzustellen, auf

40

P. Sivasothy et al.

dem das anwendungsspezifische Überwachungskonzept beruht. Alle physikalischen Komponenten, die eine essenzielle Rolle in dieser Wirkungskette einnehmen, müssen im Rahmen des virtuellen Prototyps modelliert werden, selbst wenn dessen Komplexität eine enorme Herausforderung bedeutet. Es stellt sich somit nicht die Frage ob sondern wie diese Komponenten modelliert werden können. Zunächst werden alle Komponenten einzeln modelliert und anschließend virtuell montiert. Hierzu kann zwischen drei Modellierungstechniken unterschieden werden, je nach Komponentenkomplexität und vorhandenem Wissen [7, 8]: • Blackbox • Greybox • Whitebox Ein Blackbox-Modell berücksichtigt keine Informationen über die inneren Beziehungen [8]. Das Modell ist eine triviale Zuordnung zwischen dem gemessenen Eingangssatz und dem Ausgangssatz. Daher wird es bevorzugt bei komplizierten Systemen eingesetzt, bei denen eventuell gar nicht bekannt ist, wie die inneren komplexen physikalischen Beziehungen modelliert werden könnten. Ein Whitebox-Modell rekonstruiert alle inneren physikalischen Beziehungen, die schließlich zum Ausgangssignal führen[8]. Diese Methode wird für einfache, gut untersuchte Systeme bevorzugt. Ein Greybox-Modell ist eine hy­ bride Technik, wobei komplexe physikalische Eigenschaften Blackbox-modelliert und simplere Eigenschaften Whitebox-modelliert werden.

4.6

Signalverarbeitung und Datenvoranalyse

Verfügbarkeitsorientierte Geschäftsmodelle bringen eine ausgeprägte Transparenz innerhalb des Datennetzwerks mit sich. Alle relevanten Informationen werden von jeder Maschine zu einer zentralen Auswertestelle transportiert. Nach der Auswertung wird ein Verfügbarkeitsfeedback an jede Maschine kommuniziert. Hierdurch entstehen hohe Anforderungen an die Dateninfrastruktur [9]. Um die Dateninfrastruktur dennoch möglichst effizient zu gestalten, ist eine Unterscheidung zwischen Daten und Informationen wichtig. Aus Daten lassen sich Informationen generieren, die wiederrum unmittelbar einen Mehrwert für den vorliegenden Anwendungsfall bedeuten. Die Dateninfrastruktur für verfügbarkeitsorientierte Geschäftsmodelle kann derart aufgebaut sein, dass die Rohdaten mit geringer Aussagekraft unberührt bis zur Cloud transportiert und erst dort zu Nutzdaten mit hoher Aussagekraft umgewandelt werden. Dabei kann die Infrastruktur durch den Transport von Rohdaten massiv belastet werden. Bei den daraus generierten Nutzdaten hingegen handelt es sich oft um eine wesentlich kleinere Datenmenge. Daher ist zu empfehlen, eine maschinennahe Vorverarbeitung ­vorzunehmen.

4  Entwicklung intelligenter, kommunikationsfähiger Komponenten

41

Die cloudbasierte zentrale Datenauswertung birgt gewisse Vorzüge für verfügbarkeitsorientierte Geschäftsmodelle. Durch das Zusammentragen der Daten, die unterschiedliche Maschinen und ihr störungsbehaftetes Betriebsverhalten beschreiben, ist es möglich, kausale Zusammenhänge zu detektieren. Nun kann auf dieser Basis abstraktes, allgemeingültiges Wissen generiert werden, welches sich auf alle Maschinen übertragen lässt. Die Qualität einer lokalen Auswertung auf der Maschine ist abhängig von der Zeit. Da mit der Zeit immer mehr Daten gesammelt werden können, steigt das Wissen über das Maschinenverhalten. Somit werden auch die Auswertealgorithmen mit der Zeit immer besser. Die Daten stammen dabei in der Regel von Prüfstandsversuchen, da die Daten der industriell eingesetzten Maschinen in der Regel nicht zentralisiert werden. Bei einer zentralen Auswertung werden die Daten aller Maschinen in der Cloud und nicht auf der Maschine ausgewertet. Die Datenbasis wird dabei nicht nur durch Prüfstandversuche angereichert, sondern von jeder Maschine, die im Betrieb ist. Die stetig steigende Datenmenge führt zu einer fortlaufenden Verbesserung der Maschinenqualität. Der Nachteil ist hierbei die Abhängigkeit von einer stabilen, schnellen Datenanbindung. Bricht die Verbindung zusammen oder fällt der externe Server aus, so fällt die lokale Maschinenfunktion ganz oder teilweise aus. Außerdem wird die Dateninfrastruktur stark belastet. Ein Kompromiss kann mit einer zweistufigen Auswertung gefunden werden. Auf Basis der aktuellen Daten wird eine Kennlinie erzeugt und auf der Maschine hinterlegt. Die Maschine wertet die Rohdaten lokal aus und gibt die Nutzdaten zurück an den Anwender. Darüber hinaus werden die Rohdaten an die Cloud kommuniziert. Der dort befindliche Auswertealgorithmus, der auf Methoden der künstlichen Intelligenz basiert, wird durch den Zuwachs an Daten verbessert. Das steigende Wissen wird in regelmäßigen Abständen oder eventbasiert an die Maschine kommuniziert. Dadurch werden sowohl alte als auch neuere Maschinen softwaretechnisch aktualisiert. Außerdem wird die Belastung der Dateninfrastruktur durch eine ständige Rückmeldung der Cloud wesentlich reduziert.

4.7

Schnittstellendefinition und Datenvermittlung in die Cloud

Die sensorseitige Schnittstelle an den IO-Modulen wird durch die verwendeten Sensoren bestimmt. Die angeschlossenen Sensoren erzeugen Sensordaten, die von den IO-Modulen erfasst und an das Steuergerät gesendet werden. In InnoServPro wurde folgender Aufbau verwendet: Das Steuergerät verarbeitet und sendet die Sensordaten über das Gateway in die Cloud (siehe Abb. 4.4). Für den Transport der verarbeiteten Sensordaten in die Cloud wird das Protokoll Message Queue Telemetry Transport (MQTT) verwendet. MQTT ist ein leichtgewichtiges, nachrichtenorientiertes Protokoll, das speziell für den Einsatz auf Geräten mit beschränkter Leistung und für die Verwendung bei unzuverlässigen Verbindungen mit kleiner Bandbreite oder hoher Latenz entwickelt wurde. Durch die „Organization for the Advancement of Structured Information Standards“ (OASIS) wird MQTT seit 2013 als Protokoll des Internets der Dinge standardisiert.

42

P. Sivasothy et al. EtherCAT

Ethernet

Mobilfunk

Sensor Cloud

Sensor Sensor

IO-Modul S30e Steuergerät M50

Gateway W30

Abb. 4.4  Schnittstellen vom Sensor bis zur Cloud

Das wesentliche Konzept des Protokolls ist die Verwendung des Publish/Subscribe-­ Musters als Message Exchange Pattern, wodurch eine Art von Beobachter-­Verhaltensmuster ermöglicht wird. Nachrichten werden vom Sender (Producer) nicht direkt zu einem Empfänger (Consumer) gesendet, sondern bei einem Broker veröffentlicht (Publish). Da nicht alle Empfänger an allen Nachrichten interessiert sind, können die Nachrichten für ein spezifisches Thema (Topic) veröffentlicht werden. Interessierte Clients (Consumer) haben die Möglichkeit, sich bei dem Broker für spezifische Topics zu registrieren (Subscribe), wodurch der Broker beim Eintreffen einer Nachricht zu diesem Topic den registrierten Clients diese Nachricht weiterleitet. Der Nachrichten-Sender und der Nachrichten-­ Empfänger werden entkoppelt. Aufgrund der verschiedenen Vorteile des MQTT-Protokolls, wird dies in InnoServPro für die Schnittstelle mit der Kommunikationsplattform verwendet. Berücksichtigt wurde hierbei neben technischen Überlegungen auch die oben beschriebene Standardisierung von MQTT. Zu den technischen Aspekten, welche zu der Entscheidungsfindung geführt haben, zählen die Berücksichtigung von Verbindungsabbrüchen und Bandbreitenbegrenzung im Entwurf von MQTT als auch die Erweiterbarkeit und Entkopplung von Teilkomponenten des Systems. Die Erweiterbarkeit ist durch das Publish-Subscribe-Muster und durch das Anlegen neuer Topics und Veröffentlichen (Publish) neuer Nachrichten gegeben, welche mittels Subscribe durch einen Konsumenten verarbeitet werden können. Für die Entwicklung eines verteilten Systems, welches die Anforderungen einer Vielzahl von Stakeholdern berücksichtigen muss, ist die Entkopplung der einzelnen Teilsysteme unabdingbar. Hierdurch können Stakeholder-spezifische Abstimmungen hinsichtlich der von den jeweiligen Stakeholdern genutzten Schnittstellenanteilen stattfinden. Durch den als Mediator fungierenden Broker wird eine Entkopplung der Empfänger von den Sendern der Nachrichten ermöglicht. Da ein Empfänger sich lediglich für die für ihn relevanten Nachrichten registriert, erhält er auch nur Nachrichten, die ihm bekannt sind und er interpretieren kann. Werden beim Broker andere bzw. neue Nachrichten veröffentlicht, muss der Empfänger nicht an diese angepasst werden, wenn er sie nicht verarbeiten will. Dadurch ist es möglich, das System zu erweitern, ohne bestehende Teilsysteme anpassen zu müssen [10]. Die Identifikation der MQTT-Nachrichten erfolgt über definierte Topics. In diesem Zusammenhang ist ein Topic definiert, als eindeutige Maschinennummer gefolgt von einem

4  Entwicklung intelligenter, kommunikationsfähiger Komponenten

43

Topic für das Gerät. Als Abschluss folgt ein Topic, das den Nachrichtentyp angibt. Es gibt folgende Nachrichtentypen mit jeweils eigenem Dateninhalt: • GPS: Informationen über die aktuelle Position der mobilen Arbeitsmaschine. • Verbindungstatus: Details über Verbindung. Dient als Alive-Signal für den Fall, dass keine Sensordaten und GPS-Daten aufgenommen werden. • Sensordaten: Messwerte der einzelnen Sensoren und Zeitstempel. Die Messwerte aller verwendeten Sensoren werden zusammengefasst und mit einem Zeitstempel versehen. Eine MQTT-Nachricht mit dem Topic Sensordaten besteht aus mehreren dieser Zusammenfassungen. Die Zusammenfassung vieler kleiner Pakete zu wenigen großen Paketen verringert den Datenoverhead, der zur Kommunikationsabsicherung notwendig ist. Dies steigert die Uploadeffizienz. Als Datenformat für alle MQTT-Nachrichtentypen kommt die JavaScript Object Notation (JSON) zum Einsatz. JSON ist ein schlankes menschenlesbares Datenformat, das auf Paaren von Namen und Werten basiert. Die JSON-Daten sind daher leicht zu erstellen und zu parsen. Es gibt mehrere Quality-of-Service-Level (QoS) in MQTT, mit denen der Empfang von Nachrichten am Broker quittiert werden kann. Diese Level sind folgende: • QoS-Level 0: Es findet keine Quittierung statt. Nachrichten werden vom MQTT-Client einfach versendet ohne Empfangsprüfung am Broker. • QoS-Level 1: Es wird durch Quittierung sichergestellt, dass eine MQTT-Nachricht mindestens einmal am Broker ankommt, nachdem sie vom MQTT-Client gesendet wurde. • QoS-Level 2: Es wird durch Quittierung sichergestellt, dass eine MQTT-Nachricht genau einmal am Broker ankommt, nachdem sie vom MQTT-Client gesendet wurde [10]. Im Forschungsvorhaben InnoServPro wird der QoS-Level 2 verwendet, welcher sicherstellt, dass eine Nachricht genau einmal am Broker empfangen wird. Dadurch wird ­verhindert, dass MQTT-Nachrichten verloren gehen oder doppelt ankommen. Die Datenbandbreite wird dadurch im Vergleich zu den QoS-Leveln 0 und 1 minimal reduziert. Da nicht gewährleistet werden kann, dass eine konstante Verbindung zur Kommunikationsplattform besteht, wird vorgesehen, dass die Daten im Fall einer fehlenden Verbindung auf der Maschine zwischengespeichert werden. Es wurde daher eine SD-Karte in den Microcontroller der Hardware-Plattform eingebaut, welche die Daten speichert, bis wieder eine Verbindung zur Verfügung steht. Softwaretechnisch wird die Zwischenspeicherung der Daten durch das Bridge-Pattern nahtlos in die Schnittstelle eingebunden (siehe Abb. 4.5).

44

P. Sivasothy et al.

Abb. 4.5  Einbindung des Zwischenspeichers in die Schnittstelle

Literatur 1. Feldhausen J, Grote K-H (2013) Pahl/Beitz Konstruktionslehre, Methoden und Anwendung erfolgreicher Produktentwicklung. Springer Vieweg, Berlin/Heidelberg 2. Eberlin S, Hock B (2014) Zuverlässigkeit und Verfügbarkeit technischer Systeme, Eine Einführung in die Praxis. Springer Vieweg, Wiesbaden 3. Mössner T (2012) Risikobeurteilung im Maschinenbau, Bundesanstalt für Arbeitsschutz und Arbeitsmedizin, Forschung Projekt F 2216. https://www.baua.de/DE/Angebote/Publikationen/ Berichte/F2216.pdf?__blob=publicationFile. Zugegriffen am 10.02.2019 4. Kölsch P, Herder CF, Zimmermann V, Aurich JC (2017) A novel concept for the development of availability-oriented business models. In: Procedia CIRP 64 – Proceedings of the 9th CIRP IPSS conference on circular perspectives on PSS, S  340–344. https://doi.org/10.1016/j.procir.2017.03.063 5. Mert G, Herder CF, Menck N, Aurich JC (2016) Innovative services for customized, availability-­ oriented business models for the capital goods industry. In: Proceedings of the 8th CIRP conference on industrial product-service systems, S  501–506. https://doi.org/10.1016/j.procir.2016.03.223 6. Choi SH, Chan AMM (2004) A virtual prototyping system for rapid product development. Comput Aided Des 36:401–412. https://doi.org/10.1016/S0010-4485(03)00110-6 7. Khan ME, Khan F (2012) Comparative study of white box, black box and grey box testing techniques. Int J Adv Comput Sci Appl 3(6):12–15 8. Worden K, Wong CX, Parlitz U et  al (2007) Identification of pre-sliding and sliding friction dynamics: grey box and black-box models. Mech Syst Signal Process 21:514–534. https://doi. org/10.1016/j.ymssp.2005.09.004 9. Göres T, Harms H (2007) Data management system for teleservice applications in mobile machinery. LANDTECHNIK 62(5):328–329 10. OASIS Message Queuing Telemetry Transport (2017). https://www.oasis-open.org/committees/ tc_home.php?wg_abbrev=mqtt. Zugegriffen am 05.02.2019

5

Intelligentes Informationsmanagement für verfügbarkeitsorientierte Geschäftsmodelle Thomas Eickhoff, Hristo Apostolov, Christian Donges, Matthias Fischer, Jens C. Göbel, Michael Grethler, Julian Imwalle, Ralf Mattukat, Lan Liu, Kai Pankrath, Frank Zeihsel und Jörg Richter

Zusammenfassung

Neben der Konzeption von verfügbarkeitsorientierten Geschäftsmodellen und der für die technische Umsetzung essenziellen Entwicklung von kommunikationsfähigen Komponenten bildet ein intelligentes Informationsmanagement die dritte Säule für das Anbieten von Verfügbarkeit. Im Rahmen des Forschungsprojektes wurde eine Cloud-­ basierte Gesamtlösung entwickelt, in der alle beteiligten Softwaresysteme daran arbeiten, dem richtigen Benutzer alle relevanten Informationen zur richtigen Zeit zur Verfügung zu stellen. Im vorliegenden Kapitel wird der Prozess zur Entwicklung einer solchen Plattform beschrieben, ausgehend von der Aufnahme von Anforderungen, die

T. Eickhoff (*) · H. Apostolov · J. C. Göbel Lehrstuhl für Virtuelle Produktentwicklung, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected]; [email protected] C. Donges · M. Fischer :em engineering methods AG, Darmstadt, Deutschland E-Mail: [email protected]; [email protected] J. Richter T-Systems International GmbH, Wolfsburg, Deutschland E-Mail: [email protected] M. Grethler SolidLine AG, Karlsruhe, Deutschland E-Mail: [email protected] J. Imwalle · R. Mattukat Anedo GmbH, Eydelstedt, Deutschland E-Mail: [email protected]; [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 J. C. Aurich et al. (Hrsg.), Entwicklung datenbasierter Produkt-Service Systeme, https://doi.org/10.1007/978-3-662-59643-2_5

45

46

T. Eickhoff et al.

sich in eine modellbasierte Beschreibungssystematik eingliedern und somit die Basis für die weiteren Prozessschritte liefern. Das durchgängige Systemmodell wird auch während der Konzeption und Implementierung der Cloudplattform sowie der beteiligten Systeme weiter gepflegt. Die eigentliche Implementierung wird anhand der konkreten Einzelsysteme beschrieben: So wurden im Projekt eine Business-Analytics-­ Plattform, ein Back-End sowie Front-Ends an der Maschine und anderen Endgeräten entwickelt. Am Schluss des Prozesses steht eine entsprechende Verifikation der Teilsysteme sowie der Gesamtplattform.

5.1

 efinition von Anforderungen an das D Informationsmanagement

In Abschn.  3.2 wurde das Werkzeug der Prozessanalyse zur ersten Anforderungserhebung näher erläutert. Die Anwendung dieses Werkzeugs innerhalb der drei Use-Cases (Abschn. 6.2, 7.2 und 8.2) brachte eine Anzahl von 152 Anforderungen an das Gesamtsystem hervor. Der Lesbarkeit halber und aufgrund der Buchstruktur wird bereits in diesem Kapitel mit diesen Anforderungen gearbeitet, um daraus Anforderungen an die Kommunikationsplattform ableiten zu können.

5.1.1 Kategorisierung der Teil-Anforderungen aus den Use-Cases Die 152 Anforderungen wurden kategorisiert durch die fünf Kategorienfamilien „Front-­ End“, „Back-End“, „Business-Analytics“, „Digital Twin“ und die Sicherstellung der Verfügbarkeit des Investitionsgutes durch die Kategorienfamilie „Diagnose“ (siehe Tab. 5.1). Diese fünfte und letzte Kategorienfamilie ist eine Querschnittsfunktionalität, die wiederum durch das Zusammenspiel von „Front-End“, „Back-End“ und „Business Analytics“, sowie der Daten im „Digital Twin“ realisiert wurde. Diese fünf Kategorienfamilien wiederum ließen sich in elf Kategorien unterteilen: Die Aufstellung der elf Kategorien erfolgte dabei nicht ad hoc, sondern im Zuge von vier Durchsichten der 152 Anforderungen, welche somit iterativ feiner kategorisiert wurden. L. Liu Schaeffler AG, Herzogenaurach, Deutschland E-Mail: [email protected] K. Pankrath XPLM GmbH, Viernheim, Deutschland E-Mail: [email protected] F. Zeihsel enbiz GmbH, Kaiserslautern, Deutschland E-Mail: [email protected]

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

47

Tab. 5.1  Kategorien und ihre Familien Kategorienfamilie Diagnose Digitaler Zwilling Back-End Front-End Business-Analytics

Kategorien Fehlererkennung Datenformat Datenhaltung Anzeige Business-Analytics

Fehlermeldung Dateninhalt Arbeitsabläufe Eingabe

Fehlervermeidung Fehlerbehebung

Dieses Vorgehen ist nicht frei von subjektiven Präferenzen des oder der Durchführenden, aber durch die mehrfachen Durchgänge in gewissen zeitlichen Abständen wird eine größtmögliche Objektivität erreicht. Realisiert wurde dieses Vorgehen in Form eines Excel-Arbeitsblattes mit einem Array B(z,s) mit elf Spalten für die Kategorien und 152 Zeilen für die Anforderungen, welches im Folgenden durch ein Visual Basic-Skript zur Auswertung erweitert wurde. Jede der 152 Teil-Anforderungen wurde durch eine binäre Kodierug „Kreuz“ oder „kein Kreuz“, bzw. B(z,s) = 1 oder B(z,s) = 0 in den s = 1 & … 11 Kategorienspalten für jede der z = 1 … 152 Anforderungszeilen dargestellt. Dabei konnte jede der 152 Anforderungen einer oder mehreren der elf Kategorien zugewiesen werden. Des Weiteren sollten die elf Kategorien möglichst disjunkt die Eigenschaften der Anforderungen der Use-Cases charakterisieren, d. h. die elf Kategorien sollten möglichst redundanzfrei die Eigenschaften der 152 Anforderungen beschreiben. Dieses wurde mit einer 11 × 11 Korrelationsmatrix nachgewiesen (siehe Tab. 5.2): Die obige symmetrische Matrix wurde mit Hilfe der 121-fachen Anwendung der Korrelationsfunktion von Excel auf die binären Kodierungen im o.  a. Skript erstellt. Der besseren Lesbarkeit halber, wurden nur die 55 verschiedenen Werte in der oberen Dreiecksmatrix dargestellt. Sie zeigt, dass mit Ausnahme des etwas häufigeren, gemeinsamen Auftretens der Kategorien Fehlererkennung und Fehlervermeidung, sowie Datenformat und Datenhaltung, alle anderen Kategorienpaarungen deutlich geringere Korrelationen aufweisen, d.  h. es existieren keine zwei Kategorien, die im Wesentlichen die gleiche Eigenschaft der Anforderungen beschreiben und deshalb durch eine einzelne neue Kategorie zusammengefasst werden könnten. Anders formuliert: die gefundenen elf Kategorien sind „verschieden genug“ und können nicht weiter zusammengefasst werden. Ob allerdings weitere Kategorien hilfreich sein könnten, kann mit dieser Methode nicht beantwortet werden.

5.1.2 Aus Kategorien werden Anforderungen Die elf Kategorien der 152 Anforderungen an das Gesamtsystem werden im nächsten Verfahrensschritt sowohl einzeln als auch in Kombination als Anforderungen an die ­Kommunikationsplattform interpretiert. Damit lägen maximal 152 verschiedene Anforderungen an die Kommunikationsplattform vor. Tatsächlich sind es jedoch erheblich weniger, wie eine genaue Clusterbetrachtung der ganzzahligen Kodierung der Kategorien der

Fehlerer-­ kennung Fehler-­meldung Fehler-­ vermeidung Fehler-­behebung Datenformat Dateninhalt Datenhaltung Arbeitsabläufe Anzeige Eingabe Business Analytics

1

0,21 1

0,07 0,07 0,10 1

1

Daten­ format 0,05

0,06 0,21

Fehler-­ Fehler­ Fehler-­ Fehler-­ erkennung meldung vermeidung behebung 1 0,49 0,00 0,10

Tab. 5.2 Korrelationsmatrix

0,17 0,12 1

0,07 0,17 0,20 0,40 0,12 1

0,17 0,03

Daten­ Daten­inhalt haltung 0,20 0,08

0,23 0,12 0,27 0,04 1

0,24 0,06

0,10 0,12 0,16 0,13 0,14 1

0,02 0,01

Arbeits­ abläufe Anzeige 0,24 0,06

0,04 0,07 0,15 0,10 0,09 0,11 1

0,11 0,20

Eingabe 0,13

0,12 0,07 0,47 0,07 0,11 0,03 0,12 1

0,06 0,18

Business Analytics 0,16

48 T. Eickhoff et al.

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

49

Anforderungen ergab. Diese ganzzahlige Kodierung ist die Umrechnung der binären Kodierung in eine natürliche Zahl als Summe der Zweierpotenzen über alle s = 1 … 11 Kategorienspalten in jeder der z = 1 … 152 Anforderungszeilen. 11



 z = 1…152 G ( z ) = ∑B ( z ,s ) 2 s −1 fur s =1



Damit liegen die Kategorisierungen der Anforderungen als natürliche Zahlen vor. Eine genaue Betrachtung dieser ganzzahligen Kodierung ergab 19 Cluster mit deutlichen Abständen zwischen diesen Häufungen. Die zu jeder Häufung gehörende Kategorienkombination wurde abschließend als funktionale Mehrfachanforderung an die Kommunikationsplattform ausformuliert. Zur Interpretation der elf einzelnen Kategorien: Die Anforderung jeder einzelnen Kategorie an die Kommunikationsplattform lautet, dass sie ausführbar sein muss. Zur Interpretation der 19 Mehrfachanforderungen: die Anforderung einer Kategorienkombination lautet, dass zwischen den ausführbaren einzelnen Kategorien der betrachteten Kombination die notwendigen Datenflüsse möglich sein müssen. Schlussendlich konnten aus den 152 feingranularen Anforderungen 30 Anforderungen an die Kommunikationsplattform als Gesamtsystem abgeleitet werden. Von diesen wurden 29 als erfüllt verifiziert und nur eine einzelne wurde als nicht erfüllt eingestuft, da die notwendigen externen Daten wie satellitengestützte Ermittlung der Bodenfeuchte bis Projektende nicht zur Verfügung standen.

5.2

 ntwicklung einer Gesamtmodellierungssystematik für E Produkt-Service Systeme

Engineering-Prozesse und -Methoden werden durch Interdisziplinarität, Digitalisierung und Virtualisierung grundlegend verändert. Neue intelligente, auf digitalen Modellen basierende Entwicklungsmethodiken für smarte Systeme sind daher nötig, um Prozesse, Methoden sowie IT-Werkzeuge aller Disziplinen inklusive Dienstleistungen in einen gemeinsamen Entwicklungsansatz zu überführen. Der Anstieg des originären Funktionsund damit auch Komplexitätsumfangs von Produkten bzw. Systemen wird sich weiter beschleunigen. Um diese Komplexität zu bewältigen, müssen einerseits die klassischen Entwicklungsmethoden auf den Prüfstand gestellt werden und an die neuen Anforderungen einer integrierten, cybertronischen Systementwicklung angepasst werden, andererseits muss zu jeder Zeit eine Rückverfolgbarkeit über alle Lebenszyklusphasen des Systems sichergestellt werden [1]. Dieses Unterkapitel befasst sich mit der Entwicklung smarter Produkt-Service Systeme (PSS) und stellt ein Rahmenwerk dar für die frühe Analyse und Spezifikation solcher Systeme mit Fokus auf die Dienstleistungen und IT-Infrastruktur. Die verfügbaren Methoden zur Entwicklung von PSS sind meistens Anpassungen konventioneller Entwicklungsmethodiken [2]. Die in den PSS enthaltenen Serviceprodukte

50

T. Eickhoff et al.

bzw. Dienstleistungen sind im Vergleich zu den physikalischen Produktteilen oftmals technisch unterdimensioniert und ineffizient gestaltet [3]. Um diese Problematik zu adressieren, wurde in den letzten Jahren viel Forschungsaufwand auf dem Gebiet erbracht [4–6]. Obwohl die Notwendigkeit eines methodisch und IT-gestützten Entwicklungsprozesses für PSS bereits erkannt worden ist [7], fehlt es immer noch an praktischen, modernen Ansätzen zur integrierten Entwicklung von PSS, die komplexe, cybertronische Produkte, Dienstleistungen und unterstützende IT-Infrastruktur in sich vereinen. Im Rahmen von InnoServPro wird u.  a. eine Gesamtmodellierungssystematik für Produkt-­Service Systeme entwickelt, die einen Rahmen vorgibt, anhand dessen das zu entwickelnde System mit Fokus auf Dienstleistungen und IT-Infrastruktur in der frühen Phase modellbasiert abgebildet werden kann. Dies dient der Systemanalyse und -spezifikation. Dadurch können alle im Entwicklungsprozess anfallenden Informationen und Entscheidungen formal an einer zentralen Stelle – dem Systemmodell – festgehalten werden. Es wird besonders viel Wert auf die Vollständigkeit und Eindeutigkeit der Informationen gelegt, über welche sich die Stakeholder im erweiterten Wertschöpfungsnetzwerk austauschen und auf Basis welcher Entscheidungen getroffen werden. Die Gesamtmodellierungssystematik gibt sowohl die Informationen vor, die im Entwicklungsprozess des PSS definiert werden sollen, als auch die Form, in welcher das erfolgen soll. Sie ist als Rahmenwerk zu verstehen und enthält keinen generischen Prozess mit Aufgaben, Verantwortlichkeiten, Meilensteinen, etc. für die Entwicklung von PSS. Die Gesamtbeschreibungssystematik setzt auf ein modellbasiertes, durch die Object Management Group (OMG) Systems Modeling Language (SysML) unterstütztes Vorgehen. Dadurch werden Systemanforderungen, -architektur, -verhalten und Schnittstellen zu externen Objekten sowie formale und komprimierte Tests in Systemmodellen festgehalten. Durch die verschiedenen Diagramme der Sprache können Stakeholder relevante Sichten auf Teile des Systems mit einem bestimmten Fokus (z. B. Struktur, Verhalten, Datenflüsse, etc.) erhalten oder das System in seiner Gesamtheit und den Realisierungskontext betrachten. Die formale Beschreibung des Systems ermöglicht eine rechnergestützte und in gewissem Maße automatisierte Systemanalyse, Verifizierung und frühe Validierung des Systemdesigns. Im Folgenden wird die Beschreibungssystematik im Detail erklärt und anschließend deren Anwendung anhand eines Beispiels aus dem Forschungsprojekt InnoServPro demonstriert.

5.2.1 PSS-Gesamtmodellierungssystematik Die PSS-Gesamtmodellierungssystematik baut auf drei wesentlichen Ansätzen für die Entwicklung von komplexen, cyberphysikalischen Produkten auf – dem mecPro2 Modellrahmenwerk [8], dem Systemkonkretisierungsmodell nach Pfenning [9] und dem Kaiserslauterer Systemkonkretisierungsmodell [10, 11]. Sie ist ein eigenständiger ­komplementärer Ansatz zur Entwicklung smarter PSS mit Fokus auf Dienstleistungen und produkt- bzw. dienstleistungsunterstützende Infrastruktur.

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

51

Die Spezifizierung des PSS gemäß der Modellierungssystematik findet auf vier verschiedenen Abstraktionsstufen statt, im Weiteren Ebenen genannt: 1) die PSS-Kontext-­ Ebene; 2) die funktionale Lösungsebene; 3) die logische Lösungsebene; und 4) die physikalische Lösungsebene (siehe Abb. 5.1). Diese vier Ebenen definieren den Lösungsraum der Systematik, in dem die kreative ingenieurtechnische Arbeit stattfindet. Dabei steigt der Konkretisierungsgrad des Systemdesigns von der PSS-Kontext-Ebene hin zu der physikalischen Lösungsebene. Parallel zu dem Lösungsraum erstrecken sich der Anforderungsund der Verifikations- bzw. Validierungsraum. Im Anforderungsraum werden die Anforderungen an das zu entwickelnde System definiert und strukturiert. Im Verifikations-/ Validierungsraum werden Testfälle definiert, welche der Systemdesignverifikation und der frühen Systemvalidierung dienen. Dazu gehört auch die Festlegung von frühen ausführbaren Verhaltensmodellen des Systems, durch welche In-the-Loop-Simulationen bereits existierender Systemkomponenten ermöglicht werden und dadurch die Entwicklung gewisser Anteile der PSS potentiell beschleunigt werden kann. Die Parallelität der Anforderungs- und Verifikations-/Validierungsräume zum Lösungsraum versinnbildlicht, dass Artefakte aus den beiden genannten Räumen sich auf Artefakte des Lösungsraums auf allen vier Abstraktionsebenen beziehen können. So kann zum Beispiel eine Anforderung gewisse Aspekte des PSS-Kontextes beschreiben oder aber auch konkrete logische oder sogar physikalische Lösungen vorschreiben. Auf der Kontextebene soll das System in seiner Gesamtheit – Produkte, Dienstleistungen und unterstützende Infrastruktur  – betrachtet werden. Das gleiche gilt bei den Anforderungs- und Verifikations-/Validierungsräumen. Auf den weiteren Ebenen des Lösungsraumes liegt der Fokus auf den Dienstleistungen, der Infrastruktur und den Zusammenhängen und Schnittstellen mit den physikalischen Produktanteilen des PSS. Die Entwicklung der smarten, cyberfähigen Produkte, die ein Bestandteil des PSS sind, wird

Abb. 5.1  Rahmen der PSS-Gesamtmodellierungssystematik

52

T. Eickhoff et al.

nicht durch die Gesamtmodellierungssystematik direkt unterstützt. Grund dafür ist unter anderem die Tatsache, dass diese ganz andere Entwicklungszeiten als das Gesamt-PSS haben können. Deren Entwicklung kann bereits erfolgt sein und parallel zu der des PSS laufen. Sollten die Produkte nach einem der verwendeten Ansätze [8–11] entwickelt werden oder entwickelt worden sein, so können dessen Modelle oder Teile davon nativ in die Einwicklung des PSS miteinbezogen werden. PSS-Kontext-Ebene Als erster Schritt in der Entwicklung des PSS werden die Business- bzw. Stakeholder-­ Anforderungen erhoben und im Systemmodell dokumentiert. Dieser Schritt ist dem Anforderungsraum zugeordnet. Basierend auf diesen Anforderungen wird auf der obersten Abstraktionsebene des Lösungsraumes das Ziel und somit die erzielte Basisfunktionalität des PSS aus Sicht des Kunden definiert. Die Modellierungssystematik befasst sich weiterhin nur mit der Entwicklung des Dienstleistungsteilsystems. Das Teilsystem wird in seinem Einsatzkontext analysiert, sodass die Systemgrenze definiert werden kann. Die Interaktionspartner und die externen Einflüsse auf das System werden identifiziert und somit auch die Schnittstellen zu externen Aktoren und zu der Umwelt definiert. Weiterhin wird auf dieser Abstraktionsebene sowohl die anvisierte Basisarchitektur des PSS als auch das Wertschöpfungsnetzwerk definiert, in dem das System umgesetzt werden soll. Funktionale Lösungsebene Auf der funktionalen Ebene werden aus den Business-Anforderungen zunächst konkrete Systemanforderungen abgeleitet und als Teil des Anforderungsraumes modelliert. Diese beziehen sich auf die funktionalen und nichtfunktionalen Aspekte des PSS, die umgesetzt werden müssen. Ausgehend davon und von der bereits auf der höheren Abstraktionsebene definierten Basisfunktionalität und dem Kontext des PSS wird die erste funktionale Untergliederung des Systems vorgenommen  – die Funktionen des PSS werden definiert und dem Sach- oder dem Dienstleistungsteilsystem zugeteilt. Dabei sollen Lösungsalternativen in Betracht gezogen werden. Die durch das Dienstleistungsteilsystem umzusetzenden Funktionen werden als Services definiert und als Teil der Basisarchitektur des PSS im Modell festgehalten. Im Verifikations-/Validierungsraum werden erste Validierungsszenarien überlegt und definiert, welche die Randbedingungen für die im weiteren Entwicklungsverlauf zu definierenden Testfälle vorgeben. An dieser Stelle ist die Funktionalität des PSS soweit spezifiziert, dass mit der nächsten Stufe, der Systemkonkretisierung, angefangen werden kann. Logische Lösungsebene Auf der logischen Lösungsebene findet eine weitgehende Detaillierung des Systems statt. Ziel dabei ist es, eine lösungsneutrale Systemarchitektur zu entwickeln und das Verhalten des Systems festzulegen. Zu diesem Zweck wird ausgehend von der Basisarchitektur des PSS die Architektur des Dienstleistungsteilsystems im Sinne von logischen, lösungsneu­ tralen Elementen definiert. Des Weiteren werden die Schnittstellen und die Objektflüsse zwischen den einzelnen Architekturelementen sowie zu externen Elementen festgelegt.

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

53

Das Wertschöpfungsnetzwerk wird um die Akteure ergänzt, die zur Abwicklung der Services benötigt werden. Die Funktionen des Dienstleistungsteilsystems werden in Aktivitäten untergegliedert. Diese werden den Elementen der logischen Architektur oder den Akteuren des Wertschöpfungsnetzwerkes zugeordnet, die für die Ausführung der Aktivitäten zuständig sind. Die logische Abfolge der Ausführung der Aktivitäten innerhalb eines Service wird festgelegt. Ebenso werden die zur Ausführung benötigten Eingangsobjekte sowie die aus den Aktivitäten resultierenden Ausgangsobjekte definiert. Ein wichtiges Ergebnis aus der Systemspezifikation auf dieser Ebene ist das fachliche Datenmodell (siehe Abschn. 5.5.1), auf dessen Basis das PSS-weite Informationsmanagement umgesetzt wird. (Physikalische) Lösungskonkrete Ebene Auf der lösungskonkreten Ebene werden basierend auf den Architektur- und Verhaltensmodellen der logischen Ebene Entscheidungen für konkrete physikalische oder softwaretechnische Lösungen, durch welche das System umgesetzt werden soll, getroffen und festgehalten. Der Entscheidungsprozess an sich wird durch die Modellierungssystematik nicht direkt unterstützt. Vielmehr wird durch sie eine klare, konsistente Beschreibung des umzusetzenden Systems in Form eines rechnerinterpretierbaren Modells erzielt, die als Ausgangspunkt für den Entscheidungsprozess dient. Sobald konkrete physikalische und softwaretechnische Lösungen identifiziert worden sind, kann eine weitere Detaillierung stattfinden. Aus dem abstrakten Modell der höheren Lösungsebenen werden eine oder mehrere Instanzen gebildet, die das System vollständig definieren. Dabei werden alle noch abstrakten Beschreibungen konkretisiert und wo nötig erweitert. So wird zum Beispiel die unterstützenden IT-Infrastruktur toolspezifisch definiert, es werden toolspezifische Datenmodelle gebildet und die Rollen der Akteure im Wertschöpfungsnetzwerk sowie die Ressourcen festgelegt, die von den Serviceprozessen benötigt werden. Das Ergebnis der Tätigkeiten auf dieser Ebene ist eine eindeutige Spezifikation des Systems, anhand welcher disziplinspezifische Entwicklungsarbeiten angestoßen werden können oder die Implementierungsarbeiten für das PSS anfangen können.

5.2.2 B  eispielhafte Anwendung der PSS-­ Gesamtmodellierungssystematik Um die bereits theoretisch beschriebene Modellierungssystematik greifbarer zu machen, wird im Folgenden die Anwendung der Gesamtmodellierungssystematik zur Gestaltung des PSS in einem der drei Use-Cases im Verbundforschungsprojekt InnoServPro demonstriert. Zu diesem Zweck wurde der Use-Case BHN/Lenze/Schaeffler herangezogen, beschrieben im Detail in Kap. 8. Szenario des Use-Cases Lenze ist ein produzierendes Unternehmen, das Hauptkomponenten wie Motoren, Getriebe, Umrichter und Controller für Automatisierungsanwendungen herstellt. Diese funktionskritischen Komponenten werden in Produktionsanlagen der Automobil-, Intralogistik- und

54

T. Eickhoff et al.

Verpackungsbranchen sowie in der Robotertechnik eingesetzt. Um ein verfügbarkeitsorientiertes Geschäftsmodell umsetzen zu können, muss Lenze eine erhöhte Verfügbarkeit seiner Komponenten gewährleisten. Dafür müssen intelligente Instandhaltungsstrategien wie Condition Monitoring und Predictive Maintenance für die eigenen Komponenten umgesetzt werden, aber auch das Zusammenspiel mit anderen Komponenten in der gesamten Produktionsanlage muss berücksichtigt werden. Dafür soll der Zustand der Komponenten durch Sensoren in Echtzeit erfasst werden und in eine zu entwickelnde virtuelle Repräsentation der Anlage (vgl. digitaler Zwilling, Abschn. 5.5.2.3) aufgenommen werden. In Kombination mit Lebensdauermodellen und Asset-­Informationen sollen intelligente Instandhaltungsstrategien umgesetzt werden, sodass im Falle von Wartungsarbeiten alle notwendigen Informationen an der Stelle unverzüglich verfügbar sind. Die durchführende Person soll vom System durch die Schritte der Instandsetzung oder Wartung navigiert werden und alle durchgeführten Arbeiten sollen digital erfasst werden. Die modellbasierte Beschreibung eines PSS bestehend aus einer Produktionsanlage, intelligenten Serviceprodukten bzw. Dienstleistungen für die Instandhaltung und IT-­ Infrastruktur samt Software, die diese Serviceprodukte unterstützt, gilt als Aufgabe dieser Fallstudie. Das gemäß der Gesamtmodellierungssystematik modellbasiert spezifizierte PSS wird im folgenden Beispiel anteilig vorgestellt. Beispielhafte Spezifikation eines Produkt-Service Systems gemäß der Gesamtmodellierungssystematik Die Analyse und Spezifizierung des umzusetzenden PSS beginnt auf der PSS-Kontext-­ Ebene mit der Aufnahme der Anforderungen der Stakeholder. Diese werden mit als Business-­Anforderungen typisierten SysML-Elementen modelliert. Nachdem die Business-Anforderungen in deren Gesamtheit aufgenommen worden sind, werden diese mit der Zielsetzung analysiert, Ähnlichkeiten in Bezug auf die geforderte Funktionalität oder Eigenschaft zu erkennen, sodass sie strukturiert oder zumindest gebündelt werden können. Die Strukturierung bzw. Bündelung erfolgt mittels rückverfolgbarer Beziehungen zwischen den einzelnen Modellelementen (siehe Abb. 5.2). Diese Beziehungen haben immer eine bestimmte semantische Bedeutung, wie zum Beispiel „enthalten“, „ableiten“ oder „verfeinern“. In den SysML-Diagrammen, die eine Sicht auf einen bestimmten Ausschnitt des Modells mit einem bestimmten Fokus verkörpern, kann die Strukturierung bzw. Bündelung auch grafisch dargestellt werden. Dies kann und soll die semantischen Beziehungen im Modell nicht ersetzen. Weiterhin werden aus den Business- bzw. High-­Level-­ Anforderungen funktionale und nichtfunktionale Systemanforderungen abgeleitet und zusammen mit den entsprechenden semantischen Verknüpfungen modelliert. Die Summe aller Systemanforderungen bildet eine Art modellbasiertes Pflichtenheft, während alle Business-Anforderungen als ein Lastenheft betrachtet werden können. Mit der Entwicklung der Systemanforderungen wird das Ziel des Systems präzisiert. Dieses wird im Modell als Hauptanwendungsfall des Systems definiert (siehe Abb. 5.3). Weiterhin wird das System in seinem Anwendungskontext analysiert, um eine Abgrenzung von seinem Umfeld zu erreichen und somit die Systemgrenze definieren zu können.

Abb. 5.2  Anforderungsdiagramm mit den in SysML modellierten Business-Anforderungen, zugehörigen Systemanforderungen und die daraus definierte Funktionalität „Fault Diagnosis“ (Ausschnitt)

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte … 55

56

T. Eickhoff et al.

Die externen Akteure, mit denen das PSS interagiert, und die relevanten Umwelteinflüsse werden bei der Analyse ebenfalls festgelegt. An dieser Stelle kann die erste funktionale Untergliederung des Systems vorgenommen werden, wobei der Übergang auf die nächste, funktionale Lösungsebene stattfindet. Ausgehend von dem festgelegten Ziel des Systems und den Systemanforderungen werden Produktfunktionen und Dienstleistungen definiert. Diese werden als typisierte SysML-Anwendungsfallelemente „ProduktFunktion“ oder „Service“, modelliert und semantisch mit dem Hauptanwendungsfall verknüpft (siehe Abb. 5.3). Die Dienstleistungsfunktionen werden im weiteren Entwicklungsprozess des PSS gestaltet und gemäß der PSS-Gesamtmodellierungssystematik spezifiziert, während die Produktfunktionen durch bereits existierende oder zu entwickelnde Produkte bereitgestellt werden. Basierend auf der ersten funktionalen Untergliederung des Systems und der Analyse seines Umfeldes kann die Basisarchitektur des PSS definiert werden. Diese enthält das Produkt- und Dienstleistungsteilsystem, die unterstützende IT-Infrastruktur und ein ­Abbild des Wertschöpfungsnetzwerks (siehe Abb. 5.4). Das Produktteilsystem wird dabei als Blackbox betrachtet, von der im Weiteren nur die Schnittstellen betrachtet werden. Das Dienstleistungsteilsystem enthält die bereits definierten Services, von welchen an dieser Stelle Aktivitäten abgeleitet werden, die als Grundlage der weiteren Detaillierung des

Abb. 5.3  Use-Case-Diagramm mit dem Ziel des PSS und die darin inkludierten Dienstleistungen

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

57

Abb. 5.4  Kontext des umzusetzenden PSS inklusive der Basisarchitektur

Systems dienen. Die grobe Zusammensetzung der IT-Infrastruktur wird im Sinne von logischen Bausteinen definiert. Die benötigten Partner des Wertschöpfungsnetzwerks werden festgelegt. Die Architekturbeschreibung erfolgt für Teile des Systems, wie in Abb. 5.5 dargestellt, unter anderem anhand von SysML-Blockelementen. Wie bereits erwähnt, werden dabei nur die Dienstleistungen durch SysML-Aktivitätselemente repräsentiert. Kompositionsbzw. Aggregationsbeziehungen werden genutzt, um die Zusammensetzung des Systems zu beschreiben. Der Zugriff von Dienstleistungen auf Elemente der IT-Infrastruktur wird durch „nutzen“-Verknüpfungen modelliert. Ferner findet die bereits erwähnte Detailierung der einzelnen Dienstleistungen statt. Dabei werden die einzelnen Schritte zur Umsetzung der Dienstleistung festgelegt und einem logischen Element der IT-Infrastruktur oder des Wertschöpfungsnetzwerks zugeteilt, das für deren Ausführung zuständig ist. Die Schritte werden als Aktivitäten modelliert und einer Swimlane zugeordnet, die mit dem für die Ausführung zuständigen Element verknüpft ist (siehe Abb. 5.5). Die Objektflüsse zwischen den einzelnen Schritten sowie diese, die von außerhalb der Dienstleistungsaktivität hineingehen oder nach außen herausgehen, werden festgelegt. Die logische Abfolge der Ausführung der Dienstleistungsaktivität kann, soweit durch die Objektflüsse nicht eindeutig definiert, durch einen Kontrollfluss vorgegeben werden.

Abb. 5.5  Aktivitätsspezifikation der Dienstleistung „Fault Localization“

58 T. Eickhoff et al.

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

59

Abb. 5.6  Interne Struktur der IT-Infrastruktur des PSS und Datenflüsse

Durch die Festlegung der Objektflüsse zwischen den einzelnen Schritten der Dienstleistung werden die Schnittstellen zwischen den Elementen der IT-Infrastruktur und des Wertschöpfungsnetzwerks indirekt definiert. Diese Schnittstellen werden im Weiteren explizit festgelegt und weiter spezifiziert, wie in Abb. 5.6 am Beispiel der internen Struktur der IT-Infrastruktur im Use-Case BHN/Lenze/Schaeffler dargestellt. Das gleiche gilt für die Informationsobjekte, die über die Schnittstellen ausgetauscht werden. Die konkreten Inhalte der Informationsobjekte werden im abstrakten fachlichen Datenmodell (vgl. Abschn. 5.5.1) des PSS definiert. Die somit generierte Spezifikation des PSS dient als Grundlage für alle weitergehenden disziplinspezifischen Entwicklungstätigkeiten sowie für die Umsetzung der Dienstleistungen und der IT-Infrastruktur.

5.3

Konfiguration der Kommunikationsplattform

5.3.1 Umsetzung der Anforderungen Ausgehend von der Anforderungsliste aus Abschn.  5.1 und den Anforderungen an das Konzept zur Entwicklung verfügbarkeitsorientierter Geschäftsmodelle in Abschn.  3.1 wurde die IT-Infrastruktur und die Kommunikationsplattform ausgewählt, erstellt und konfiguriert. Diese Bestandteile bildeten das Grundsystem, in welches das Back-End, das

60

T. Eickhoff et al.

Front-End und die Business Analytics implementiert wurden. Dies geschah in der Form eines Pilotsystems im Rahmen einer laborartigen Umgebung, welche alle wesentlichen Anteile der Systeme von Cloud-Servern enthielt. Vervollständigt wurde dieser Pilotaufbau durch die Anbindung der kommunikationsfähigen Komponenten zur Übermittlung von Messwerten über das Mobilfunknetz sowie die Anbindung der Projektpartner an die Cloud-Systeme. Ableitend aus den Anforderungen wurden zwei Anteile der Kommunikationsplattform erstellt: zum einen die Cloud-Server und zum anderen die Kommunikationstechnik bestehend aus den Mobilfunkanteilen zusammen mit einem geeigneten Kommunikationsprotokoll für die mobile Übermittlung von Daten aus dem Feld zu den Servern.

5.3.2 Datenübermittlung Für die Übermittlung von vorverarbeiteten und formatierten Messwerten der Sensoren am Investitionsgut fand die Machine-to-Machine-(M2M)-Infrastruktur der Telekom Verwendung. In einem ersten Schritt wurden SIM-Karten mit einem monatlichen Datenvolumen von jeweils 5 GB als Anfangsbefähigung beschafft, die im weiteren Verlauf des Projekts auf 30  GB pro Monat erweitert werden mussten. Diese Karten wurden mithilfe des M2M-Portals für den Feld-Einsatz konfiguriert, freigeschaltet und dem Projektpartner ANEDO als Verantwortlichem für die mobilen Devices am Investitionsgut zur Verfügung gestellt (siehe Abb. 5.7). Die Kommunikation zwischen Steuergerät mit SIM-Karte und den Servern erfolgt dabei mittels des MQTT-Protokolls, welches auch Unterbrechungen des Funkverkehrs im Feldeinsatz kompensiert und sicherstellt, dass keine Daten verloren gehen. Eine der ersten Aufgaben, die sich bei der Nutzbarmachung dieses Kommunikationsprotokolls stellten, war die Ermittlung einer geeigneten Größe der MQTT-Datenpakete. Zu diesem Zweck wurden unter Federführung von ANEDO eine Reihe von Tests durchgeführt. Dabei zeichnete sich eine Paketgröße von ca. 5000  Byte als sinnvoller Wert ab. In Abb.  5.8 wird ­tabellarisch der Zusammenhang zwischen Paketgröße, Paketsendefrequenz, Paketdurchsatz und effektiver Baudrate ersichtlich.

5.3.3 Die Cloud-Server der IT-Infrastruktur Zwei Server bzw. Server-Konfigurationen bildeten die beiden Säulen der IT-Infrastruktur. Um die Daten der Sensoren aufnehmen und für die weitere Verwendung vorhalten zu können, fand ein erprobter Server aus einem vorangegangenen Projekt der T-Systems Verwendung, der im weiteren Verlauf des Projektes den gestiegenen Datenanforderungen angepasst wurde. Die Hardware setzte sich aus einem Single-Core-Prozessor mit 4 GB

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

61

Abb. 5.7 M2M-Serviceportal

RAM und 100 GB Plattenplatz zusammen, der unter dem Betriebssystem CentOS 6.7 lief. Die eingehenden Messwerte wurden mithilfe einer NoSQL-Datenbank gesichert und für die Auswertung bzw. für die weitere Verwendung im digitalen Zwilling vorgehalten. Die zweite Säule der IT-Infrastruktur diente der Unterstützung der PLM-Anteile des digitalen Zwillings des jeweils betrachteten Investitionsgutes. Dazu fand das System Aras Innovator Verwendung. Aras Innovator wurde dazu auf einer Server-Konfiguration in der Open Telekom Cloud (OTC) implementiert und bildete durch seine Konfigurationsmöglichkeiten das Back-End des Projekts. Die OTC ist ein Produkt der Telekom, welches dem Anwender die Zusammenstellung unterschiedlichster IT-Ressourcen zur Deckung seines Datenverarbeitungsbedarfs ermöglicht. Realisiert wird dies mittels OpenStack, einer Software-­Suite zum Cloud-Computing und hardwareseitig durch große Rechenzentren der T-Systems, verteilt über ganz Deutschland, in denen virtualisierte Server die angeforderten Leistungen bereitstellen. Über eine Oberfläche spezifiziert der Anwender seine benötigten Komponenten. Für Aras Innovator wurde eine Konfiguration aus drei Elastic-­ Cloud-­Servern (ECS) gewählt: ein Server unter CentOS zur Überwachung, bestehend aus einer virtuellen CPU und 2  GB Speicher, ein Server unter Windows zum eigentlichen

62

T. Eickhoff et al.

Abb. 5.8 MQTT-Paketgrößen

Betrieb des Back-Ends mit zwei virtuellen CPUs und 8 GB Speicher und einem ECS als Reverse-Proxy-Server unter CentOS mit einer virtuellen CPU und 1 GB Speicher zwecks sicheren Zugangs zur Gesamtkonfiguration für den Anwender. Diesen drei ECS waren sechs Plattenkapazitäten mit zusammen ungefähr 1 TB zugeordnet. Eingebettet waren diese Ressourcen in die Virtual Private Cloud (VPC) „vpc-innoserv“ (siehe Abb. 5.9). Diese VPC ermöglichte den Datenverkehr zwischen den beteiligten ECS im Rahmen eines gemeinsamen Subnets, welches über einen Router für die Nutzer von außerhalb erreichbar ist. Dazu wurde ECS für den Reverse-Proxy-Dienst mit einer IP-Adresse versehen, die von extern adressierbar war.

5.4

Entwicklung der Business Analytics

Aufgabe der Business Analytics im Vorhaben ist die Auswertung sämtlicher servicerelevanter Informationen mittels Werkzeugen der Datenanalyse (Big Data/Data-Mining) und die Zurverfügungstellung relevanter Daten für das Back- und Front-End der jeweiligen Use-Cases. Die servicerelevanten Informationen umfassen dabei Felddaten (echtzeitnah im Investitionsgut erhoben), Servicedaten und Stammdaten. Ziel der Nutzung der erweiterten Datenbasis ist die flexible Initiierung von Service- und Engineering-Prozessen. Daneben sollen durch das neu verfügbare und verdichtete Wissen Informationen zur Prozessunterstützung und -optimierung aus der vorhandenen Datenbasis abgeleitet werden können.

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

63

Abb. 5.9 OTC-Architektur

5.4.1 Datenverarbeitung Der Ablauf für die Bearbeitung von Massendaten stellt sich wie in Abb. 5.10 dar. Er untergliedert sich in die Bereiche Datenerzeugung, Datenübermittlung, Echtzeitanalyse, Nachbearbeitung und Visualisierung und/oder Aktion. Datenerzeugung Es existieren nahezu unendlich viele Datenquellen. Philosophie von Data Analytics ist es, keine Vorauswahl für die Datenquellen zu treffen, sondern alle Daten zu verarbeiten, welche zugänglich sind. Eine Vorauswahl durch den Menschen erzeugt automatisch unerwünschte ergebnisrelevante Tendenzen. Daten können sowohl durch Sensoren (Sensoren aus Use-Case 1 und 3, Klimadaten, etc.) als auch durch bereits existierende Informationsund Wissensbestände erzeugt werden. Datenübermittlung Für die Übermittlung von Daten gibt es verschiedene Technologien. Alle haben das Ziel den Datenerzeuger mit dem Datensammler zu verbinden. Die Art der eingesetzten Technologie richtet sich nach der Verfügbarkeit der Netzwerkverbindung (LAN, WLAN, WIFI etc.) und nach Art und Menge der zu übermittelnden Daten. Die eingesetzte Datenstruktur richtet sich nach der Art der Daten, welche übermittelt werden. Die folgenden beiden Protokolle haben sich für die Kommunikation von Sensoren im Bereich IoT bewährt:

64

T. Eickhoff et al.

Datenerzeugung

Datenübermilung

(Echtzeit-)Analyse

Nachbearbeitung

Visualisierung/ Aktion

Abb. 5.10  Ablauf zur Verarbeitung von Massendaten

• MQTT (MQ Telemetry Transport oder Message Queue Telemetry Transport): Das von MQTT unterstützte Message Exchange Pattern ist das Publish/Subscribe Muster. Bei Publish/Subscribe kommuniziert der Sender einer Nachricht nicht direkt mit dem Empfänger sondern wendet sich an einen Broker der die Zustellung der Nachricht übernimmt. Der Broker entkoppelt den Sender oder Producer vom Empfänger, der Consumer genannt wird. Ein Producer kann eine Nachricht selbst dann senden, wenn kein Consumer online ist. Tatsächlich weiß der Producer nicht, ob es keinen, einen oder mehrere Consumer gibt, die sich für seine Nachrichten interessieren. Der Broker ist für Consumer und Producer gleichermaßen der Server. Consumer und Producer sind Clients, die sich mit dem Broker verbinden. Consumer sind oft nur an bestimmten Nachrichten interessiert, die ein Broker verteilt. Pro Thema kann ein Topic eingerichtet werden, an dem sich die Consumer anmelden (subscriben) können. Ein Topic Filter beschreibt für jede Subscription, an welchen Topics ein Consumer interessiert ist. Im Gegensatz zu Client/Server Protokollen wie HTTP arbeitet Publish/Subscribe ereignisorientiert. Ein Client muss nicht ständig beim Server anfragen, ob neue Daten vorliegen. Der Broker informiert die Consumer, wenn neue Daten zu einem Topic vorliegen. • OPC Unified Architecture (OPC UA): OPC UA ist eine service-orientierte Architektur (SOA) und ermöglicht einen standardisierten Datenaustausch von Maschinendaten, wie z. B. Gerätebeschreibungen, Messwerten, Parametern und Regelgrößen. OPC UA ersetzt dabei nicht die deterministische Kommunikation innerhalb von Maschinen, sondern ermöglicht eine einheitliche Kommunikation zwischen Anlagen, Maschinen und Komponenten unterschiedlicher Hersteller. OPC UA ist der Nachfolger der klassischen OPC-Variante und erweitert diese um standardisierte Transportprotokolle, wie z. B. Webservices, um Sicherheitsmechanismen und um die Fähigkeit, Informationen in einem Informationsmodell semantisch zu beschreiben. Die OPC Foundation ist ein Industriekonsortium und verwaltet die Standardisierung von OPC UA. Datenstromanalyse Die Datenstromanalyse bezieht sich ausschließlich auf Daten, welche sich in dem aktuellen Datenstrom befinden. Sie hat keinen Zugang zu historischen Daten. Das Regelwerk für die Datenstromanalyse wird durch die Nachbearbeitung erzeugt, durch die Datenstromanalyse verwendet, jedoch nicht in Echtzeit modifiziert oder angepasst. Während der Datenstromanalyse wird anhand des Regelwerkes der Datenstrom reduziert und nur bedingt an nachfolgende Prozesse weitergegeben. Nachfolgende Prozesse können das Auslösen eines Ereignisses sein, beispielsweise das Senden eines Alarmsignales oder auch die Weitergabe an eine Datenbank für komplexere Datenanalysen.

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

65

Zur Datenstromanalyse existieren Data Stream Management Systeme (DSMS). Ein Data Stream Management System ist ein Datenbanksystem zur Verwaltung von kontinuierlichen Datenströmen. Es ist vergleichbar mit einem Datenbankverwaltungssystem (DBMS), welches für Datenbanken eingesetzt wird. Im Gegensatz zu einem DBMS muss ein DSMS zusätzlich zu den Relationen mit Datenströmen umgehen und auf diesen kontinuierliche Anfragen ausführen können. Zur Formulierung von Anfragen können spezielle Anfragesprachen, wie beispielsweise die Continuous Query Language (CQL) eingesetzt werden. Zur Speicherung solcher Streams werden spezielle NoSQL Datenbanken, wie z. B. RethinkDB oder PipelineDB verwendet. Nachbearbeitung Der Datenstrom, welcher durch die Datenstromanalyse geliefert wird, wird in einer Datenbank gespeichert. Je nach Art und Volumen der Daten werden SQL-Datenbanken oder eine Form der NoSQL-Datenbank verwendet. NoSQL bezeichnet Datenbanken, die einen nicht-relationalen Ansatz verfolgen. Diese Datenspeicher benötigen keine festgelegten Tabellenschemata und versuchen Joins zu vermeiden. Es gibt verschiedene Arten von NoSQL-­Datenbanken: • • • • • • •

Dokumentenorientierte Datenbanken Graphdatenbanken Verteilte ACID-Datenbanken Key-Value-Datenbanken Multivalue-Datenbanken Objektdatenbanken Spaltenorientierte Datenbanken

Trotz mittlerweile verbesserter Journaling-Funktionen bergen NoSQL noch immer die Gefahr von Datenverlusten und eignen sich somit nicht für die Speicherung bereits aggregierter Daten. Die gewonnenen Daten werden mit Technologien wie Machine Learning und Data Mining analysiert. Machine Learning ist ein Oberbegriff für die „künstliche“ Generierung von Wissen aus Erfahrung: Ein künstliches System lernt aus Beispielen und kann diese nach Beendigung der Lernphase verallgemeinern. So kann das System auch unbekannte Daten beurteilen (Lerntransfer) oder aber am Lernen unbekannter Daten scheitern (Überanpassung). Machine Learning ist eng verwandt mit „Knowledge Discovery in Databases“ und „Data-Mining“, bei dem es jedoch vorwiegend um das Finden von neuen Mustern und Gesetzmäßigkeiten geht. Viele Algorithmen können für beide Zwecke verwendet werden. Außerdem können Methoden der „Knowledge Discovery in Databases“ genutzt werden, um Lerndaten für „maschinelles Lernen“ zu produzieren oder vorzuverarbeiten, und Algorithmen aus dem maschinellen Lernen finden beim Data-Mining Anwendung. Unter

66

T. Eickhoff et al.

Data-­Mining  versteht man die systematische Anwendung statistischer Methoden auf große Datenbestände mit dem Ziel, neue Querverbindungen und Trends zu erkennen. Knowledge Discovery in Databases (KDD) ergänzt Data-Mining um vorbereitende Untersuchungen und Transformationen der auszuwertenden Daten. Ziel des KDD ist die Gewinnung bislang unbekannter fachlicher Zusammenhänge aus vorhandenen Datenbeständen. In Abgrenzung zum Data-Mining umfasst KDD als Gesamtprozess auch die Vorbereitung der Daten sowie die Bewertung der Resultate. Die Ergebnisse von Machine Learning, Data Mining und KDD werden in SQL Datenbanken abgelegt und bilden die Grundlage für den Rules Generator zur Erzeugung der Rules Engine für die ­Datenstromanalyse. Visualisierung/Aktion Es existieren verschiedene Möglichkeiten zur Visualisierung von Daten. Datenvisualisierung ist ein allgemeiner Begriff für den Versuch, die Bedeutung von Daten zu verstehen, indem man diese grafisch darstellt. Muster, Trends und Korrelationen, die in textbasierten Daten unentdeckt bleiben, lassen sich mithilfe von Datenvisualisierung einfacher erkennen. Heutige Datenvisualisierungs-Tools gehen über Standard-Diagramme und Grafiken von Excel-Tabellen hinaus. Sie stellen Daten auf anspruchsvollere Weise in Infografiken, Skalen, geografischen Karten, Wortgrafiken, Heatmaps und detaillierten Balken-, Kreis- und Fieberkurven dar. Es gibt interaktive Funktionen, die es dem Anwender ermöglichen, Veränderungen an Abfragen und Analysen auf die zugrunde liegenden Daten anzupassen. Darüber hinaus können Indikatoren enthalten sein, die Benutzer benachrichtigen, wenn Daten aktualisiert worden sind oder vordefinierte Bedingungen auftreten. Für das Forschungsvorhaben hat sich aufgrund der gewählten Komponenten für Übertragung und Speicherung der relevanten Daten die Struktur ergeben, welche in der nachfolgenden Abb. 5.11 dargestellt ist.

5.4.2 Business Analytics im Vorhaben Im Rahmen der verfügbarkeitsorientierten Geschäftsmodelle kommt der Business Analytics eine entscheidende Rolle zu: kritische Prozessgrößen zu identifizieren, zu analysieren und zu überwachen. Dabei unterscheidet man in der Regel drei Modi: • Prescriptive Analytics • Predictive Analytics • Descriptive Analytics Eine gute Unterscheidung findet sich bei Seiter [12]. Danach adressiert die Descriptive Analytics Explorationsprobleme. Im Fokus stehen Problemstellungen, deren grundsätzliche Lösungsidee einen Bezug zur Identifikation unbekannter Muster aufweist. Beispiele für Muster sind Korrelationen, Cluster, Ausreißer

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

67

Abb. 5.11  Datenerfassung und -verarbeitung in den Use-Cases

und Trends. Weitere spezielle Muster sind Topics in Texten und Communities in sozialen Netzwerken. In Bezug auf die eigene Kundenbasis können solche Fragestellungen nach den Mustern sein: • Welche Charakteristika zeichnen unsere A-Kunden aus? • Können unsere Kunden in homogene Gruppen eingeteilt werden? • … In Bezug auf Produkte und Dienstleistungen lauten solche Fragen: • Werden manche Produkte und Dienstleistungen in der Regel gemeinsam verkauft? • Fallen bestimmte Maschinentypen häufig aus? • … Analysewerkzeuge, die hierbei zum Einsatz kommen, sind: • Einfache deskriptive Statistik • Clusteranalysen • Ausreißeranalyse u. v. m Predictive Analytics dagegen adressiert Prognoseprobleme. Im Fokus stehen nach Seiter Problemstellungen, deren grundsätzliche Lösungsidee einen Bezug zur Konstruktion von Modellen zur Prognose eines unbekannten Attributs aufweist [12].

68

T. Eickhoff et al.

Nach Seiter sind beispielhafte Fragestellungen hierzu: • Wann werden bestimmte Maschinen ausfallen? • Wie oft wird ein bestimmter Kunde im nächsten Jahr Leistungen aus einem Service-­ Vertrag abrufen? • Welcher Kunde wird einen bestimmten Customer-Life-Value überschreiten? • … Analysewerkzeuge, die hierbei zum Einsatz kommen, sind: • Klassifikation • Zeitreihenanalyse • Regression Prescriptive Analytics schließlich adressiert Optimierungsprobleme. Im Fokus stehen Fragestellungen, deren grundsätzliche Lösungsidee einen Bezug zur Konstruktion von Optimierungsmodellen aufweist. Beispielhafte Fragestellungen sind: • Wie sind die Bestände in einem Ersatzteillager zu verteilen, damit ein bestimmtes Service-­Level erreicht werden kann? • Welcher Produktpreis führt zum höchsten Gewinn bei einer bestimmten Mindestumsatzmenge? Alle drei Modi haben für verfügbarkeitsorientierte Geschäftsmodelle ihre Bedeutung. Zum einen ist es notwendig, die eigenen Daten zu verstehen und grundlegende Zusammenhänge sichtbar zu machen. Das gilt besonders dann, wenn sich Informationen in textbasierten Datenbanken z. B. des Services befinden, wie es beispielsweise im Use-Case BHN/Lenze/Schaeffler der Fall war (Kap. 8). Eine gewichtigere Rolle spielt allerdings Predictive Analytics. Durch das rechtzeitige Vorhersagen von Ausfällen bzw. das rechtzeitige Einplanen von Service- oder Instandhaltungsmaßnahmen lässt sich die Verfügbarkeit der Investitionsgüter erhöhen. Damit lässt sich die Rolle von Business Analytics im Rahmen des Vorhabens noch genauer definieren (siehe Abb. 5.12). Business Analytics verarbeitet die Daten der Investitionsgüter und wertet diese aus. Im Sinne einer Predictive Analytics sind dies Zusammenhänge zwischen z. B. Ausfällen und Fehlern und darauf wirkender Einflussgrößen. Daraus lassen sich über Data Mining und Machine Learning Modelle erstellen, die direkt am Investitionsgut zur Überwachung eingesetzt werden können, die Planung der vorausschauenden Instandhaltung verbessern können oder direkt Messwerte überwachen, die für die Verfügbarkeit des Investitionsguts kritisch sind. Zur Erstellung der Modelle sind Analysetools und Software notwendig, welche die Algorithmen des Machine Learnings implementieren. Diese werden im folgenden Abschnitt näher erläutert.

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

69

Abb. 5.12  Business Analytics am Beispiel des Use-Cases BHN/Lenze/Schaeffler (in Anlehnung an eoda [13])

5.4.3 Softwarewerkzeuge zur Analyse von Daten Im Bereich Big Data und Internet of Things (IoT) werden eine Vielzahl von Softwarewerkzeugen angeboten, die zur Analyse von Daten eingesetzt werden. Im Folgenden werden die aus Sicht des Vorhabens wesentlichen Softwarewerkzeuge vorgestellt. Open Source IoT: Kaa Kaa ist eine multifunktionale Middleware-Plattform für das IoT, die es ermöglicht, komplette End-to-End-IoT-Lösungen, angeschlossene Anwendungen und intelligente Produkte zu bauen. Die Kaa-Plattform bietet ein offenes Toolkit für die IoT-­Produktentwicklung. Für einen schnellen Start bietet Kaa eine Reihe von Out-of-the-Box Enterprise-Grade IoT-Funktionen, die leicht in Betrieb genommen werden können und Teile der Use-­Case-­ Anforderungen erfüllen. Kaa weist eine Reihe von architektonischen Besonderheiten auf. Zuerst ist Kaa hardware-­ agnostisch und damit kompatibel mit nahezu jeder Art von angeschlossenen Geräten, Sensoren und Gateways. Es bietet auch eine klare Struktur von IoT-Funktionen und Erweiterungen für verschiedene Arten von IoT-Anwendungen. So können fast als Plug-and-Play-Module mit minimalem zusätzlichen Code auf der Entwickler-Seite verwendet werden. Kaa ermöglicht die Datenverwaltung für angeschlossene Objekte und die Back-End-­ Infrastruktur durch die Bereitstellung der Server- und Endpunkt-SDK-Komponenten. Die SDKs (Software-Developer-Kit) werden in die angeschlossenen Geräte eingebettet und

70

T. Eickhoff et al.

realisieren den bidirektionalen Datenaustausch in Echtzeit mit dem Server. Kaa-SDKs können in sehr vielen Arten von angeschlossenen Geräten oder Mikrochips integriert werden. Der Kaa-Server bietet alle Back-End-Funktionen, die für den Betrieb von großen IoT-Lösungen benötigt werden. Er verwaltet jegliche Kommunikation mit verbundenen Objekten einschließlich Datenkonsistenz und -sicherheit, Geräte-Interoperabilität und fehlersichere Konnektivität. Der Kaa-Server verfügt über viele Schnittstellen für die Integration in Datenmanagement- und Analysesysteme sowie über Ihre produktspezifischen Services. Kaa beinhaltet keine Module zu Datenanalyse, Machine Learning, Data-Mining etc. Diese müssen durch weitere Softwarewerkzeuge bereitgestellt werden. Open Source Analysis: Apache Spark MLlib Apache Spark ist ein universelles Cluster-Computing-System. Es bietet APIs in Java, Scala, Python und R und eine optimierte Engine, die allgemeine Ausführungsgraphen unterstützt. Es unterstützt auch eine umfangreiche Reihe von übergeordneten Tools wie Spark SQL für SQL und strukturierte Datenverarbeitung, MLlib für maschinelles Lernen, GraphX für Grafik-Verarbeitung und Spark Streaming. MLlib ist die Spark Machine Learning (ML) Bibliothek. Sie bietet Werkzeuge wie: • ML-Algorithmen gemeinsame Lernalgorithmen wie Klassifikation, Regression, Clustering und kollaborative Filterung • Featurisierung: Merkmalsextraktion, Transformation, Dimensionsreduktion und Selektion • Pipelines: Werkzeuge zum Konstruieren, Auswerten und Optimieren von ML Pipelines • Persistenz: Speichern und Laden von Algorithmen, Modellen und Pipelines • Dienstprogramme: lineare Algebra, Statistik, Datenhandling, etc. Spark Streaming ist eine Erweiterung der Kern-Spark-API, die eine skalierbare, hochdurchsatz- und fehlertolerante Stream-Verarbeitung von Live-Datenströmen ermöglicht. Daten können aus vielen Quellen wie Kafka, Flume, Kinesis oder TCP Sockets aufgenommen und mit komplexen Algorithmen weiterverarbeitet werden. Schließlich können verarbeitete Daten in Dateisysteme, Datenbanken und Live-Dashboards verschoben werden. Microsoft Azure IoT Suite Microsoft Azure IoT Suite ist eine Lösung für allgemeine IoT-Szenarien für Unternehmen, z. B. Remoteüberwachung, vorausschauende Wartung und verbundene Factory. Die vorkonfigurierten Lösungen sind vollständige, funktionsfähige End-to-End-Lösungen, die Folgendes umfassen: • Simulierte Geräte, die den Einstieg erleichtern • Vorkonfigurierte Azure-Dienste, z. B. Azure IoT Hub, Azure Event Hubs, Azure Stream Analytics, Azure Machine Learning und Azure Storage • Lösungsspezifische Verwaltungskonsolen

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

71

Die vorkonfigurierten Lösungen enthalten bewährten, einsatzbereiten Code, den man anpassen und erweitern kann, um ihn in ein eigenes, spezifisches IoT-Szenario zu implementieren. Der Azure IoT Hub ermöglicht die sichere und zuverlässige bidirektionale Kommunikation zwischen der Cloud und den Geräten, die in der vorkonfigurierten Lösungsarchitektur verwendet werden. Der Azure IoT Hub implementiert das Muster für die dienstgestützte Kommunikation, um die Interaktionen zwischen Geräten und dem Back-End zu vermitteln. Das Ziel der dienstgestützten Kommunikation ist die Einrichtung von vertrauenswürdigen, bidirektionalen Kommunikationspfaden zwischen Steuersystemen, z.  B.  IoT Hub, und speziellen Geräten, die im nicht vertrauenswürdigen physischen Raum bereitgestellt werden. Der Azure IoT Hub bietet folgende Features: • Geräte können nur Verbindungen mit bekannten Peerdiensten wie IoT Hub herstellen bzw. Routen dafür einrichten. • Der Kommunikationspfad zwischen Gerät und Dienst oder Gerät und Gateway wird auf Anwendungsprotokollebene geschützt. • Die Autorisierung und Authentifizierung auf Systemebene basiert auf gerätebezogenen Identitäten. • Eignet sich für bidirektionale Kommunikation von Geräten, die aufgrund von Stromversorgungs- oder Verbindungsaspekten nur selten eine Verbindung herstellen. Der IoT Hub verfügt über spezielle Gerätewarteschlangen für die gesendeten Befehle. • Die Nutzlastdaten der Anwendung werden für die geschützte Übertragung über Gateways an einen bestimmten Dienst separat geschützt. Azure Stream Analytics ist ein vollständig verwaltetes Echtzeit-Ereignisverarbeitungsmodul zur Durchführung detaillierter Datenanalysen. Stream Analytics führt analytische Echtzeitberechnungen von Datenströmen von Geräten, Sensoren, Websites, Sozialen Medien, Anwendungen und Infrastruktursystemen durch. Im Azure-Portal können Stream-Analytics-Aufträge erstellt werden, indem die Eingabequellen von Streamingdaten, die Ausgabensenken für die Ergebnisse des Auftrags und eine Datentransformation in einer SQL-ähnlichen Sprache angegeben werden. Skalierung und Geschwindigkeit eines Auftrags im Azure-Portal können überwacht und angepasst werden. Azure Machine Learning ist ein Predictive-Analytics-Clouddienst, der die Erstellung und Bereitstellung von Vorhersagemodellen als Analyselösungen ermöglicht. Es existieren fertige Bibliotheken mit Algorithmen, die zum Erstellen einer Vorhersagelösung verwendet werden können. Beispiele und Lösungen bietet die Cortana Intelligence Gallery an. Azure Machine Learning bietet Tools, um Vorhersagemodelle als sofort nutzbare Webdienste bereitstellen zu können.

72

T. Eickhoff et al.

Amazon Web Services (AWS) IoT AWS IoT ist eine verwaltete Cloud-Plattform, mit der verbundene Geräte mit Cloud-­ Anwendungen und anderen Geräten zusammenarbeiten können. AWS IoT ist beliebig skalierbar. Mit AWS IoT können Anwendungen Geräte verfolgen und mit ihnen kommunizieren. AWS IoT ermöglicht es, AWS-Services, wie beispielsweise AWS Lambda, Amazon Kinesis, Amazon S3, Amazon Machine Learning, Amazon DynamoDB, Amazon CloudWatch, AWS CloudTrail und Amazon Elasticsearch Service mit nativer Kibana-­Integration zum Aufbau von IoT-Anwendungen einzusetzen, die Daten von den verbundenen Geräten sammeln, verarbeiten, analysieren und für weitere Aktionen berücksichtigen, ohne dass eine Infrastruktur verwaltet werden muss. Amazon Elasticsearch Service wird für Protokollanalysen, Volltextsuche, Anwendungsüberwachung und mehr verwendet. Amazon Elasticsearch Service ist ein vollständig verwalteter Dienst, der die APIs und Echtzeitfunktionen von Elasticsearch sowie die für Produktionsworkloads erforderliche Verfügbarkeit, Skalierbarkeit und Sicherheit bietet. Der Dienst bietet integrierte Integrationen in Kibana, Logstash und AWS-Dienste wie Amazon Kinesis Firehose, AWS Lambda und Amazon CloudWatch, um schnell umsetzbare Erkenntnisse aus Rohdaten erhalten zu können. Amazon Kinesis Firehose bietet die Möglichkeit, Streaming-Daten in AWS zu laden. Amazon Kinesis Firehose kann Streaming-Daten aufzeichnen, umwandeln und in Amazon Kinesis Analytics und Amazon Elasticsearch Service laden, sodass Analysen fast in Echtzeit möglich werden. Es handelt sich um einen vollständig verwalteten Service, der automatisch so skaliert wird, dass er mit dem Durchsatz Ihrer Daten übereinstimmt und keine weitere Verwaltung erfordert. Amazon Machine Learning ist ein Service, um die Technologie für maschinelles Lernen nutzen zu können. Amazon Machine Learning bietet Visualisierungstools und Assistenten, die durch den Aufbauprozess für ML-Modelle begleiten. Diese Modelle können bei Amazon Machine Learning mithilfe von APIs Prognosen für Anwendungen abrufen, ohne benutzerdefinierte Prognosecodes implementieren oder In­frastrukturen verwalten zu müssen. Amazon Machine Learning ist skalierbar und bietet hohen Durchsatz. Für die Nutzung von Amazon Machine Learning sind keine Vorab-Investitionen für Hardware oder Software erforderlich. Es existiert ein Pay-per-Use-Modell. Open-Source Statistikprogramm R R ist ein Open-Source Statistikprogramm, das sich in den letzten Jahren immer größerer Popularität erfreut. Dies liegt vor allem daran, dass die Statistiksoftware durch Pakete beliebig erweiterbar ist (zurzeit existieren ca. 2000 Erweiterungspakete). Neben einer eigenen Programmieroberfläche steht mit RStudio eine funktionell sehr umfangreiche Entwicklungsumgebung zur Verfügung, die sowohl als Client-Server-Verbindung als auch in lokaler Anwendung betrieben werden kann. Über die Pakete Shiny und Shiny-Dash­ board und den frei verfügbaren Shiny-Server lassen sich interaktive Webanwendungen

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

73

(z. B. interaktive Grafiken zur Datenvisualisierung) erzeugen und direkt im Web nutzen. R ist sehr gut integrierbar mit Datenbanken, Git, LaTeX sowie mit NoSQL-Datenbanken, wie z. B. MongoDB oder mit großen verteilten Systemen wie Hadoop. Weitere Vorteile von R sind die große Entwickler-Community, die leistungsfähige Skript-Sprache sowie die Verfügbarkeit für alle gängigen Systeme wie Windows, Mac und Linux. Ein Nachteil von R liegt in der Single-Thread-Ausführung von Aufgaben, was eine Analyse von Streaming-Daten erschwert. Allerdings sind hierzu Lösungen von Drittanbietern bereits in der Entwicklung und teilweise schon am Markt erhältlich.

5.5

Entwicklung des Back-Ends und Front-Ends

In diesem Kapitel werden zuerst die Entwicklung und Implementierung des Back-Ends erläutert. Anschließend wird das Vorgehen zur Visualisierung der Daten aus dem Back-­ End auf Maschinen-Front-Ends und auf maschinenunabhängigen Front-Ends beleuchtet.

5.5.1 Entwicklung eines fachlichen Datenmodells Vorgehensmodell zur Entwicklung eines fachlichen Datenmodells für InnoServPro Das Vorgehen zur Entwicklung des fachlichen Datenmodells lässt sich entsprechend der Ebenen der in Abschn. 5.2 vorgestellten Gesamtmodellierungssystematik gliedern, wobei der Anforderungsraum sowie die funktionale und logische Ebene im Fokus stehen (siehe Abb. 5.13). Beginnend im Anforderungsraum, wird mit der Ableitung feingranularer Anforderungen der Grundstein für die Entwicklung des fachlichen Datenmodells gelegt. Auf der funktionalen Ebene stellen diese Anforderungen den Input für die Definition benötigter Funktionen der Teilsysteme des Informationsmanagements dar und dienen der Ermittlung der notwendigen Datenflüsse zwischen den Teilsystem-Funktionen. Auf der logischen Ebene fließen die feingranularen Anforderungen direkt in die Entwicklung des fachlichen Datenmodells ein. Darüber hinaus werden auf dieser Ebene die Schnittstellen zwischen den zu entwickelnden Teilsystemen des Informationsmanagements aus den zuvor ermittelten, notwendigen Datenflüssen abgeleitet. Ergebnisse dieses Vorgehens sind ein teilsystemübergreifendes, fachliches Datenmodell sowie definierte Schnittstellen und Datenflüsse zwischen den am Informationsmanagement beteiligten Teilsystemen. Anforderungsentwicklung Bevor mit der Entwicklung des fachlichen Datenmodells begonnen werden kann, gilt es, die Anforderungen an das fachliche Datenmodell zu erfassen und zusammen mit den Use-Case-Stellern zu präzisieren. Den Input für die Anforderungsentwicklung stellen die Prozessmodellierungen der drei Use-Cases dar, die mit OMEGA modelliert wurden.

74

T. Eickhoff et al.

Abb. 5.13  Vorgehensmodell zur Entwicklung eines fachlichen Datenmodells für InnoServPro

Sie ­enthalten jeweils den Ablauf eines Use-Cases und die an den einzelnen Prozessschritten auftretenden High-Level Anforderungen. Diese High-Level Anforderungen werden extrahiert und mit einem Verweis auf das Quelldokument und den Use-Case sowie einer eindeutigen Bedarfsnummer gekennzeichnet. Für die Entwicklung des fachlichen Datenmodells ist es notwendig, die High-Level Anforderungen in sinnvoll voneinander abgegrenzte Fachanforderungen aufzubrechen. Jede abgegrenzte Anforderung wird mit der übergeordneten Bedarfsnummer gekennzeichnet und darüber hinaus mit einer eindeutigen Anforderungsnummer und einem Prüfkriterium versehen. Abschließend werden die feingranularen Anforderungen je Use-Case von den entsprechenden Vertretern einer Prüfung unterzogen und bei Bedarf überarbeitet. Die so abgestimmten, feingranularen Anforderungen dienen als Basis für die Definition benötigter Funktionen und die Entwicklung des fachlichen Datenmodells. Definition benötigter Funktionen Auf Basis der erstellten Anforderungssammlung, welche die zuvor entwickelten feingranularen Anforderungen einschließt, werden die zur Realisierung der Use-Cases benötigten Funktionen zusammen mit den für die Entwicklung der Teilsysteme verantwortlichen Projektpartnern definiert. Die zur Erfüllung der Use-Cases notwendigen Teilfunktionen werden identifiziert und gegen die entwickelten Anforderungen sowie mit Vertretern der Use-Case-Steller auf

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

75

Vollständigkeit geprüft. Die Teilfunktionen werden gemeinsam zu je einem der Teilsysteme „Back-End PDM“, „Front-End“, „Intelligente Komponenten und Sensoren“, „Plattform BigDataTool“ und „Plattform DataStorage“ zugeordnet. Die aus diesem Schritt entstandene Funktionsliste wird um Felder zur Bewertung der Relevanz einer jeden Teilfunktion für die drei Use-Cases sowie für die jeweiligen Demonstratoren erweitert. In einem gemeinsamen Review der Funktionsliste wird zusammen mit den für die Entwicklung der Teilsysteme verantwortlichen Projektpartnern und den Vertretern der Use-Case-Steller die Relevanz der einzelnen Funktionen festgehalten. Als Ergebnis liegt eine abgestimmte Funktionsliste vor. Definition notwendiger Datenflüsse Die abgestimmte Funktionsliste wird für die Definition der notwendigen Datenflüsse in eine m × m Matrix überführt, in der die gesammelten Teilfunktionen gegeneinander aufgetragen werden. In den entstehenden Schnittfeldern werden die zur Erfüllung einer jeden Teilfunktion notwendigen und von einer anderen Teilfunktion ausgehenden Datenflüsse verzeichnet. Für jedes Teilsystem wird hierfür eine diskrete Matrix erstellt, in der dem Teilsystem zugeordnete Teilfunktionen über die Gesamtheit der Teilfunktionen aufgetragen sind. Nach dem Pull-Prinzip verzeichnet jeder Teilsystemverantwortliche die für seine Funktionen notwendigen Input-Datenflüsse mit Beschreibung und erwartetem Format. Die von den Teilsystemverantwortlichen ausgefüllten, diskreten Funktionsmatrizen werden gesammelt und wieder in eine m × m Matrix zusammengeführt. In dieser Funktionsmatrix sind alle aus Sicht der Teilsystemverantwortlichen notwendigen Teilfunktionen und Datenflüsse zwischen diesen enthalten, die zur Erfüllung der drei Use-Cases benötigt werden. Zur Veranschaulichung und zur Use-Case-spezifischen Abstimmung mit den Use-­ Case-­Stellern, werden beim Erstellen der Datenflussmodelle mehrere verschiedene Datenflussmodelle aus der Funktionsmatrix ausgeleitet, darunter ein Datenflussmodell über die gesamte Funktionsmatrix, je ein Use-Case spezifisches Datenflussmodell sowie ein Datenflussmodell, das ausschließlich schnittstellenrelevante Datenflüsse umfasst. Diese Modelle unterscheiden sich im Umfang der enthaltenen Teilfunktionen und Datenflüsse, gemäß der verzeichneten Relevanz der einzelnen Teilfunktionen für den jeweiligen Use-­Case. In den Datenflussmodellen werden die Teilsysteme als übereinanderliegende Bahnen dargestellt, die ihnen zugeordneten Teilfunktionen als in den Bahnen liegende Knoten und die Datenflüsse zwischen diesen als gerichtete Kanten. Als Visualisierungswerkzeug kommt hierfür der yEd Graph Editor (www.yworks.com) zum Einsatz, da die als Excel vorliegenden Funktionsmatrizen teilautomatisiert importiert werden können. Das Review der Datenflussmodelle findet in Use-Case-spezifischen Workshops statt. Dabei werden die erzeugten Datenflussmodelle mit Vertretern der Use-Case-Steller sowie den Teilsystemverantwortlichen abgestimmt. Anmerkungen und sich aus den Diskussionen ergebende Änderungen fließen direkt in die jeweiligen Modelle ein und werden im

76

T. Eickhoff et al.

Nachgang in der Gesamtmatrix abgebildet. Als Ergebnis liegen die zwischen den Funktionen notwendigen Datenflüsse sowie die zwischen den Teilsystemen identifizierten Schnittstellen in abgestimmter Form vor. Definition benötigter Datenobjekte und Beziehungen Auf Basis der feingranularen Anforderungen werden in Form einer Anforderungs-­ Interpretation notwendige Datenobjekte und deren Beziehungen zu einander identifiziert. Der Schritt der Interpretation erfolgt für jede der zuvor entwickelten und abgestimmten Anforderungen. Dabei wird dem Datenmodell ein Datenobjekt oder eine Beziehung hinzugefügt, wenn diese Anforderung noch nicht im Datenmodell abgebildet ist. Alternativ werden bestehende Datenobjekte oder Beziehungen angepasst, vorausgesetzt, dass dessen Konformität zu den bisherigen Anforderungen bestehen bleibt. Als Tool für die Modellierung des fachlichen Datenmodells wird Cameo Systems Modeler verwendet (www.nomagic.com). Dieser steht den Entwicklungsbeteiligten zur Verfügung und ermöglicht unter Verwendung der SysML das Anlegen eines Metamodells, in welchem die bei der Modellierung des fachlichen Datenmodells zur Verfügung stehenden Elemente definiert werden können. Innerhalb des Metamodells wird vom SysML Stereotyp „Block“ der Stereotyp „Datenobjekt“ abgeleitet, von der Metaklasse „Property“ der Stereotyp „Attribut“ und von der Metaklasse „Association“ der Stereotyp „Beziehung“ mit den ihm zugewiesenen möglichen Ausprägungen „hat Input“, „hat Output“, „hat“ und „besteht aus“. Anschließend kann das fachliche Datenmodell aus den so definierten Grundelementen „Datenobjekt“, „Attribut“ und „Beziehung“ aufgebaut werden. Der erste Entwurf des fachlichen Datenmodells wird auf Basis der Anforderungen aus Use-Case 1 angefertigt. Nach einem Review mit den an der Entwicklung des fachlichen Datenmodells Beteiligten werden auch die Anforderungen der Use-Cases 2 und 3 in das fachliche Datenmodell integriert. Zur besseren Nachverfolgung werden die aus den Anforderungen abgeleiteten Datenobjekte, Beziehungen und Attribute in ihrer Spezifikation auf den jeweiligen Kurznamen der Anforderung referenziert. Das so entstehende, die Anforderungen aus allen drei Use-Cases abdeckende fachliche Datenmodell wird anschließend konsolidiert. Die Reviews mit den Use-Case-Stellern erfolgen in Use-Case-spezifischen Review-­ Workshops. Dort wird das fachliche Datenmodell den Use-Case-Stellern vorgestellt und gemeinsam validiert. Hierbei werden anhand konkreter Beispiele die im fachlichen Datenmodell definierten Datenobjekte und Beziehungen instanziiert und damit die Abbildungsmöglichkeiten nachgewiesen. An den Stellen, an denen das vorliegende Datenmodell noch nicht die geforderten Abbildungsmöglichkeiten bietet, werden Datenobjekte, Beziehungen und Attribute angepasst bzw. erweitert. Als Ergebnis liegt ein abgestimmtes, die Use-Cases übergreifendes, validiertes fachliches Datenmodell vor. Digitaler Zwilling Besonders hervorzuheben ist der im Forschungsprojekt behandelte „digitale Zwilling“ und dessen Ausprägung im fachlichen Datenmodell sowie die Verknüpfungen zum „digitalen

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

77

Master“. Den unterschiedlichen Use-Cases entsprechend wurden verschiedene Schwerpunktthemen betrachtet und in das gemeinsame fachliche Datenmodell integriert. Folgend wird eine überblicksartige Auswahl dieser Themen eingehender betrachtet. Kern des fachlichen Datenmodells bilden die Datenobjekte „Digital Master“ und „Digital Twin“ sowie die Verknüpfung dieser beiden Informationselemente. Sowohl der Digital Master als auch der Digital Twin lassen sich über Verknüpfungen zum Datenobjekt „Part BOM“ zu hierarchischen Produktstrukturen aufbauen. Um der Abbildung spezifischer Produktkonfigurationen unter besonderer Berücksichtigung verschiedener relativer Positionierungen von Bauteilen und Baugruppen Rechnung zu tragen, ist das Datenobjekt „Part BOM“ mit dem Datenobjekt „Relative Positionierung“ verknüpft, mit welchem Lage und Ausrichtung von Bauteilen und Baugruppen im Raum definiert werden. Dies ermöglicht den positionsgetreuen Zusammenbau von Produktgeometriemodellen für die Visualisierung, z. B. in für die Produktkonfiguration spezifischen Reparaturanleitungen. Die Verknüpfung der strukturbildenden Datenobjekte des digitalen Zwillings mit denen des digitalen Masters ist eine grundlegende Eigenheit, die man sich für die Verortung weiterer Informationselemente im Datenmodell zu Nutze macht. Die für alle digitalen Zwillinge relevanten Informationselemente, werden mit dem Digital Master verknüpft. Sie können über die bestehende Verbindung vom Digital Twin zum Digital Master von allen digitalen Zwillingen referenziert werden. Hierzu zählen produktbeschreibende Informationselemente, wie beispielsweise das Datenobjekt „Technische Dokumentation“ und das Datenobjekt „Repräsentation“, das 2- oder 3-dimensionale Repräsentationen einschließt. Die für spezifische digitale Zwillinge gültigen Informationselemente werden mit dem Datenobjekt Digital Twin verknüpft. Hierzu zählen beispielsweise das Datenobjekt „Digital Twin Item Status“, mit dem der Status von Produktkomponenten festgehalten werden kann, oder das Datenobjekt „Verfügbarkeitsvertrag“, welches das Hinterlegen individueller Verträge bezüglich der Verfügbarkeit von Investitionsgütern ermöglicht. Die Definition von allgemeingültigen Serviceprozessen in Kombination mit der individuellen Durchführung eines solchen und der Erhebung von bei der Abwicklung anfallenden Informationen stellt insofern einen Sonderfall dar, als dass sowohl die Verknüpfung zum Digital Master als auch zum Digital Twin gezogen werden muss. Um dies zu realisieren, ist das Datenobjekte „Service Prozess“ auf der einen Seite direkt mit dem Datenobjekt Digital Master verknüpft und auf der anderen Seite über das Datenobjekt „Durchgeführter Service“ mit dem Datenobjekt Digital Twin.

5.5.2 Implementierung des Back-Ends Das Back-End gliedert sich in die Gesamtarchitektur des Informationsmanagements ein. Die Gesamtarchitektur des Projektes ist in Abb. 5.14 dargestellt. Die an den intelligenten kommunikationsfähigen Komponenten gesammelten Informationen werden zunächst an

78

T. Eickhoff et al.

Abb. 5.14  Architektur des Informationsmanagements

den Data Storage übertragen, wo sie gespeichert und für die Business Analytics bereitgestellt werden. Die ausgewerteten Daten werden an das Back-End übertragen. Dort werden Produktdaten vorgehalten und mit den ausgewerteten Daten verknüpft. Darüber hinaus finden hier auch servicerelevante Prozesse statt. Schließlich stellt das Back-End auch alle nötigen Daten an das Front-End bereit. Das Back-End erweitert somit das klassische Product Lifecycle Management. Im Folgenden werden die nötigen Begriffe definiert, die Implementierung des Back-Ends im Allgemeinen beschrieben und Erfahrungen aus der spezifischen Implementierung im Projekt dokumentiert.

5.5.2.1 PLM im Projektkontext Der Begriff Product Lifecycle Management (PLM) bezeichnet laut [15] eine Erweiterung des Product Data Managements, also der Verwaltung von produktdefinierenden Daten und technischen/organisatorischen Geschäftsprozessen. PLM unterscheidet sich von PDM durch einen höheren Integrationsgrad über alle Phasen des Produktlebenszyklus und über die Prozesskette der Supply Chain, vom Anforderungsmanagement über die Entwicklung und Produktion bis hin zum Recycling. Dementsprechend umfasst ganzheitliches PLM auch Prozesse wie das Anforderungs-, Funktions- und Ersatzteil-, Servicesowie MRO-Management.

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

79

Die Product-Lifecycle-Management-Software Aras Innovator der nordamerikanischen Firma Aras Corp. wurde vom Konsortium des Projektes als die Lösung zur Implementierung des vorgesehenen Back-Ends ausgewählt [14]. Die Softwarelösung Aras Innovator soll nach einer umfangreichen Anpassung und Erweiterung Funktionalitäten zur Produktdatenspeicherung und -verwaltung, Reporting, sowie die Bereitstellung dieser Daten für andere Dienste gewährleisten. Neben dem Funktionsumfang von Aras Innovator, der viele der von der Aufgabe geforderten Punkte abdeckt, lag der Entscheidung vor allem die sehr gute Anpassbarkeit und Erweiterbarkeit der Software sowie ihre universale Verfügbarkeit über das Internet zugrunde. Out-of-the-box bietet Aras Innovator Funktionalitäten zur Verwaltung von Entwicklungsdaten, Projekt- bzw. Programm-Management, Qualitätsmanagement, technische Dokumentation und weitere Funktionen zur Unterstützung der Ingenieure von den ganz frühen Entwicklungsphasen bis hin zur Planung der Produktion.

5.5.2.2 Vorgehen Aus den Anforderungen an das Informationsmanagement lässt sich leicht die Notwendigkeit eines Back-End-Systems erkennen, welches statische Daten der einzelnen Produkt-­ Instanz zu den gemessenen Feld- und Sensordaten in Beziehung setzen kann. Darüber hinaus war es erklärtes Ziel des Projektes, auch die Brücke zu den allgemeinen Stammdaten des Produktes zu schlagen, um beispielsweise Rückkopplungen in die Produktentwicklung zu ermöglichen. Neben der reinen Verwaltung von Daten lassen sich aber auch andere Anforderungen erkennen: • Verschiedene Prozesse müssen dynamisch zur Laufzeit durchgeführt werden, wobei Zugriff auf die betroffenen Datenobjekte erforderlich ist. • Die unterschiedlichen Akteure in den Anwendungsszenarien benötigen unterschiedlich detaillierte Sichten auf die für ihre Arbeit relevanten Datenobjekte, was eine Benutzerund Rollenverwaltung erforderlich macht. • Über das Front-End müssen Datenobjekte angelegt und verändert werden können. Vergleichbare Funktionen finden sich in modernen PLM-Lösungen. Ein Ansatz zur Implementierung des Back-Ends liegt somit in der Erweiterung eines bestehenden PLM-Systems. Dieses sollte von Haus aus die folgenden Möglichkeiten bieten: • Verwaltung von Produkt-Daten wie hierarchischen Stücklisten, dazugehörigen Dokumenten. • Erweiterung des bestehenden Datenmodells um neue Datenobjekte, Eigenschaften und Beziehungen zwischen Objekten. • Möglichkeiten zum intelligenten Suchen und Filtern von Datensätzen, was die Definition von eigenen Suchmasken einschließt. • Verwaltung von Benutzern, Rechte- und Rollen-Management sowie Funktionen zum Zuweisen und Verfolgen von Arbeitsaufträgen auf Rollen- und Benutzer-Basis.

80

T. Eickhoff et al.

• Anpassbare Anzeigemasken für die Datenobjekte. • Ausführung von Prozessen, die z. B. als Programmcode auf dem Server hinterlegt werden können. Neu hinzu kommen unter anderem die folgenden Funktionen: Für das Begleiten jedes einzelnen Produktes beim Kunden, wird die Verwaltung von produktinstanzspezifischen Daten, d. h. von einem digitalen Zwilling jedes einzelnen an den Kunden ausgelieferten Produktes nötig. Dies schließt die Verwaltung und dynamische Generierung von Instanz-spezifischer Dokumentation (z. B. Serviceanleitungen) mit ein. Da das Back-End nicht alleine steht, sondern Teil der größeren IT-Infrastruktur ist (siehe Abschn. 5.3), müssen Schnittstellen zum Front-End sowie zu den anderen Systemen des Informationsmanagements definiert und implementiert werden. Die drei zuletzt genannten Funktionen werden in den folgenden Abschnitten genauer erläutert.

5.5.2.3 Der digitale Zwilling Der Begriff „digitaler Zwilling“ (auch digital twin, virtueller Zwilling, digitale Verwaltungsschale [16]) wird je nach Anwendungsfall unterschiedlich aufgefasst. Im Kontext von InnoServPro bezeichnet er das digitale Abbild einer konkreten Produktinstanz, welches zu jedem Zeitpunkt mit dem aktuellen Zustand des physikalischen Produktes konsistent ist. Der digitale Zwilling steht dem so genannten digitalen Master gegenüber, welcher die klassischen Produktdaten enthält. Der digitale Master kann in der PLM-Welt beispielsweise in Form einer Variantenstückliste vorliegen, die mehrere Konfigurationen des entsprechenden Produktes abdeckt („150 %-Modell“). Aus diesem muss für jeden digitalen Zwilling die jeweils zutreffende Konfiguration abgeleitet werden („100 %-Modell“). Wenn beispielsweise von einer Maschine fünf Exemplare gebaut werden, so entstehen auch zeitgleich fünf digitale Zwillinge, die alle auf denselben digitalen Master referenzieren. Im Kontext des Projektes stehen die zur Erhöhung der Verfügbarkeit nötigen Serviceprodukte im Vordergrund, daher wurde der digitale Zwilling während der Produktion als Forschungsgegenstand bewusst ausgeschlossen. Dort ist mit anderen Anforderungen und Rahmenbedingungen als den hier dargestellten zu rechnen. Trotzdem beginnt der digitale Zwilling in InnoServPro mit der Konfiguration des Produktes. Wie aus einer allgemeingültigen Variantenstückliste ein Abbild einer konkreten Konfiguration entsteht, ist in Abschn. 7.3.1 genauer beschrieben. Anschließend dient der digitale Zwilling als Aufhängungspunkt für Sensordaten, als Quelle für servicerelevante Informationen und zur Überwachung des Produktstatus. Die Sensordaten, die wie in Abschn. 4.6 und 4.7 beschrieben ausgewertet werden, liefern Informationen über den Status der überwachten Komponenten. Aus der im Datenmodell des digitalen Zwillings hinterlegten Statushierarchie kann aus den einzelnen Komponenten der Status des gesamten Produktes ermittelt werden (beispielsweise durch eine fehlerbaumartige Logik oder durch einfaches Durchreichen des kritischsten Status). Dies liefert in der Flottenübersicht Informationen darüber, welche Maschinen gerade einsatzbereit sind.

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

81

5.5.2.4 Instanz-spezifische Dokumentation Fällt eine Maschine aus, liegen im digitalen Zwilling alle Informationen darüber vor, welche Komponenten verbaut, welche Serviceprozesse möglich und welche Servicepartner zuständig sind. Dies ermöglicht dem Servicetechniker, im Voraus Serviceanleitungen bereitzustellen, die nur genau jene Informationen enthalten, welche für die betroffene Produkt-­ Instanz zutreffend sind. Auch hier sei auf Abschn. 7.3.1 verwiesen. Wichtig ist jedoch, dass diese Informationen direkten Einfluss auf die Verfügbarkeit des Produktes haben können: So kann der Servicetechniker einerseits direkt die relevanten Ersatzteile mitnehmen, andererseits wird er während der Durchführung von Servicearbeiten nicht durch irrelevante Dokumentation aller denkbaren Konfigurationen des Produktes abgelenkt. 5.5.2.5 Schnittstellen Die Schnittstelle zwischen Back-End und Business Analytics ist in Abschn. 5.6 genauer beschrieben. Die Anbindung an das Front-End wird in Abschn. 5.5.4 genauer thematisiert. Der hier beschriebene Funktionsumfang soll verdeutlichen, dass das Back-End als zentraler Knotenpunkt des Datenmanagements Informationen und Arbeitsabläufe in allen Bereichen des Projektes verwalten muss. Um die praktischen Aspekte des Aufbaus einer entsprechenden IT-Lösung greifbarer zu machen, wird im folgenden Abschnitt die konkrete Implementierung für die Demonstratoren des Projektes beschrieben. 5.5.2.6 Implementierung im Projekt Das Back-End in InnoServPro setzt auf das PLM-System Aras Innovator auf. Zur Umsetzung des in Abschn. 5.5.1 beschriebenen Datenmodells wurden zahlreiche neue Datentypen (im Aras-Jargon „ItemTypes“ genannt) angelegt oder bestehende Typen erweitert. Eine detaillierte Beschreibung des somit implementierten technischen Datenmodells ist in Abschn. 8.4.2.1 zu finden. Die Bestandteile des digitalen Masters stellen hier eine Erweiterung der klassischen Parts des PLM-Systems dar. Um konfigurierbare Produkte abzubilden, wurde auf das Aras Variants Package 5.7 zurückgegriffen, welches Funktionen zur Verwaltung von Variantenstücklisten bereitstellt. Durch Auswahl entsprechender Optionscodes kann diese auf die konkrete Konfiguration für den digitalen Zwilling reduziert werden. Variantenstücklisten und das Ausleiten des digitalen Zwillings sind in Abschn. 7.3.1 beschrieben. Lifecycle und Workflows Neben den genannten Erweiterungen des Datenmodells wurden für verschiedene Arbeitsabläufe benötigte Funktionen implementiert und im Back-End installiert. Hierfür bieten sich in Aras Innovator unterschiedliche Möglichkeiten. So lassen sich einfache Arbeitsabläufe, die im Kontext eines bestimmten Datenobjekts stattfinden, in den „Lifecycle“ des entsprechenden Objektes einbinden. Die Übergänge zwischen einzelnen Lifecycle-Phasen werden mit Workflows gesteuert. Zum Beispiel ist in Abb. 5.15 der Workflow zur Bearbeitung des Datenobjekts „Serviceauftrag“ abgebildet. Zunächst wird beim Anlegen eines Serviceauftrages automatisch eine E-Mail an den ausgewählten Servicepartner versendet. Im Anschluss daran wartet der

T. Eickhoff et al.

82

Start

Go

Go Email versenden

Auftrag durchfuehren

Auftrag abgeschlossen

End

Abb. 5.15  Workflow zur Durchführung eines Serviceprozesses

Serviceauftrag darauf, von einem Servicetechniker ausgewählt zu werden. Dieser hat anschließend die Möglichkeit, den Auftrag durchzuführen und im System als abgeschlossen zu markieren, womit er aus der Liste der aktiven Aufträge verschwindet und nur noch per Suche im Archiv gefunden werden kann. Neue Funktionalität mit Methoden Eine weitere Möglichkeit, neues Verhalten in Aras Innovator zu verankern, liegt in der Implementierung von Methoden. Diese in den Programmiersprachen C#, Visual Basic oder JavaScript geschriebenen Programmfragmente können anschließend mit verschiedenen Auslösern in Aras Innovator verknüpft werden. Konkrete Beispiele für Methoden sind in Abschn. 7.3.1 (Ausleiten des digitalen Zwillings) und Abschn. 8.4.2 (Aggregation des Komponentenstatus der digitalen Zwillinge) zu finden. Benutzerführung durch Clientseitige Methoden Die Weboberfläche von Aras Innovator erlaubt ebenfalls das Ausführen von JavaScript-­ Code auf dem Rechner des Benutzers. Dies eignet sich zum Beispiel für eine interaktive Benutzerführung in der Anzeige von Schritt-für-Schritt-Anleitungen für den Servicetechniker. Hier werden interaktiv die entsprechenden Serviceschritte vom Server nachgeladen und zur Anzeige im Front-End vorbereitet. Das Ergebnis ist in Abschn. 5.5.4.1 beschrieben.

5.5.2.7 Fazit Das Back-End liefert eine durchgängige Datenbasis für eine vollständige Vernetzung servicerelevanter Informationen zur Realisierung verfügbarkeitsorientierter Geschäftsmodelle in erweiterten Wertschöpfungsnetzwerken. Die Umsetzung des Back-Ends basiert auf den Ergebnissen der zuvor entwickelten Beschreibungssystematik und liefert die technische Umsetzung des fachlichen Datenmodells. Klassisches Product Lifecycle Management wird um eine Servicekomponente erweitert, um den Anforderungen der intelligenten Produkt-Service Systeme gerecht zu werden.

5.5.3 Entwicklung des Maschinen-Front-Ends Maschinen-Front-Ends (MFE) gestatten dem Bediener einer Maschine, mit der Maschinensteuerung zu interagieren. Der Anwender hat durch das MFE einen Überblick über den Zustand der Maschine, kann sie bedienen und Konfigurationen vornehmen. Ein Bedienterminal mit MFE wird bei Landmaschinen in der Regel in der Fahrerkabine angebracht. Servicetechniker an der Maschine können über das MFE für die Reparatur relevante Information erhalten.

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

83

Im Unterschied zum MFE ermöglicht das maschinenunabhängige Front-End die Fernverwaltung und Informationsbündelung unabhängig von der einzelnen Maschine, siehe Abschn. 5.5.4. Für ein MFE ist ein Rollenmodell implementiert. Über eine Benutzerverwaltung werden die Ansichten und Aktionen an der Maschine bestimmten Benutzergruppen zugänglich gemacht. Im Rahmen des Forschungsprojekts „InnoServPro“ werden herkömmliche und innovative Visualisierungskonzepte für ein MFE untersucht. Anforderungen • Alle Use-Cases benötigen verschiedene Rollen, in denen die unterschiedlichen Ansichten und Aktionsmöglichkeiten zusammengefasst werden. • Da die unterschiedlichen Rollen unterschiedliche Anzeigegeräte verwenden, unter anderem Bedienterminals, aber auch mobile Geräte wie Tablets, ist ein hardwareunabhängiges Front-End gefordert, das auf allen Geräten darstellbar ist. • Ein Schwerpunkt liegt in der Anzeige und Nutzung der servicerelevanten Daten für den Bediener der Maschine. Es wird daher eine Ansicht benötigt, die speziell auf die Maschine und den Bediener der Maschine zugeschnitten ist. Weiterhin wird eine Ansicht für Servicetechniker an der Maschine benötigt. Diese soll zusätzliche Informationen über die Maschine und weitere Aktionsmöglichkeiten bieten, z. B. das Anfordern einer Reparatur. • Zusätzlich soll es die Möglichkeit geben, eine Dienstleistung, z.  B. eine Reparatur, durch die Anzeige von Handlungsanweisungen wie Anleitungen zu unterstützen. Für die Visualisierung des MFE werden der in der Landwirtschaft weit verbreitete ISOBUS und in der Industrie die CODESYS WebVisu verwendet. Die Umsetzung des MFE auf ISOBUS wird als ISOBUS-Front-End (IFE) bezeichnet, die Umsetzung des MFE in der CODESYS WebVisu wird als Web-Front-End (WFE) bezeichnet. ISOBUS Mit dem ISOBUS (ISO 11783) ist es möglich, Anbaugeräte verschiedener Art und verschiedener Hersteller über dasselbe ISOBUS-Terminal zu steuern. Hierfür ist es erforderlich, ISOBUS-fähige Steuergeräte und Bedienterminals zu verwenden. Der ISOBUS wird mittlerweile von allen wichtigen Landmaschinenherstellern unterstützt, sowohl von Traktoren als auch von Anbaugeräten: Diese Norm (ISO 11783) verwendet Teile des aus dem Bereich „Truck & Bus“ bekannten CAN-Bus basierten SAE-J1939-Netzwerkprotokolls und baut auf die ehemalige DIN 9684 (LBS – Landwirtschaftliches-BUS-System) auf. Der internationale Hersteller-Verband AEF (Agricultural Industry Electronic Foundation) unterstützt die Einführung dieses Standards und sorgt mit entsprechenden Arbeitsgruppen für die kontinuierliche Weiterentwicklung und Zertifizierung der Kompatibilität zwischen Traktoren und Anbaugeräten.

84

T. Eickhoff et al.

Bei einem voll ausgebauten ISOBUS-System kommen eine Reihe von Applikationen auf den ISOBUS-Bedienterminals zum Einsatz, die alle wie eigenständige Teilnehmer im ISOBUS funktionieren, so zum Beispiel das Universal Terminal, der TaskController und das Auxiliary-Control. In Abb. 5.16 ist der Aufbau eines ISOBUS Systems zur Steuerung einer Maschine zu sehen. Das Bedienterminal stellt den ISOBUS Universal Terminal (UT) Server und ist als die Mensch-Maschine-Schnittstelle (HMI) des Gespanns das Anzeigeund Bediengerät. Das zentrale Steuergerät, Implement-ECU (Electronic Control Unit) genannt, ist auf der zu steuernden Maschine platziert. Sie übernimmt sowohl die Steuerung der Maschine als auch die der Maschinen-Visualisierung. Auf dem Steuergerät ist ein ISOBUS UT Client, der sich mit dem ISOBUS UT Server auf dem Bedienterminal verbindet. ISOBUS-Systeme lassen sich durch weitere Komponenten hot-plug-fähig einfach erweitern. Das Traktorsteuergerät Tractor-ECU ist in Gespannen auf dem Traktor oder dem Trägerfahrzeug das Gateway von dem internen Traktor-Steuerungssystem zum ISOBUS. Es stellt Informationen wie Fahrgeschwindigkeit, Zapfwellendrehzahl usw. auf dem ISOBUS in Form von Nachrichten zur Verfügung. Im Zusammenspiel mit GPS-Systemen gibt es Programme zur Betriebsdatenerfassung, dem sogenannten TaskController (TC). Mit dem SectionControl (SC) lassen sich einzelne Maschinensegmente geobasiert zu- und abschalten, damit mehrfach überfahrene Feldbereiche nur einmalig behandelt werden. CODESYS WebVisu CODESYS WebVisu ist eine auf HTML5 (Hypertext Markup Language) basierende Visualisierung. Sie wird zur Anzeige von CODESYS-Steuerungen im Web-Browser verwendet. Die Visualisierung ist damit hardwareunabhängig und mit der Hilfe des Internets überall erreichbar. In Abb. 5.17 ist ein WebVisu Beispiel zu sehen. Das Steuergerät stellt einen Server für die WebVisu über die Ethernet-Schnittstelle bereit. Die WebVisu kann über ein

ISOBUS UT Server

ISOBUS

ISOBUS UT Client

CAN

Steuergerät M50 IFE auf Bedienterminal T50i

Abb. 5.16  Visualisierung über den ISOBUS als Client-Server-Modell

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

mobilfunk

Internet

85

Mobilfunk Html5-fähiger Browser

WLAN Html5-fähiger Browser

Ethernet

MobilFunk Router Gateway W30

WFE auf Tablet

Remote WFE

Ethernet

CoDeSys WebVisu Server

Ethernet

Ethernet

Steuergerät M50

Html5-fähiger Browser

Switch

Stat ionäres WFE

Abb. 5.17  CODESYS WebVisu Topologie des Maschinen-Front-Ends (MFE)

Remote-­Gerät (z. B. Tablet, PC) oder lokales Gerät (z. B. PC) erreicht werden. Ein lokales Gerät ruft die WebVisu vom Steuergerät direkt auf, bei einem Remote-Gerät funktioniert es analog über das Internet. Auf dem Anzeigegeräte muss lediglich ein HTML5-fähiges Browserprogramm vorhanden sein. Die Steuerelemente umfassen Standardanzeigen wie Texte und Bilder, aber auch zusammengefasste Anzeigen wie Uhren, Balken, farbige LEDs und Datenverläufe. Weiterhin sind durch grafische Elemente wie Polygone, Kreise und Linien eigene Kompositionen möglich. Über ein Browser-Element können HTML-Seiten aus dem Internet in das WebVisu Front-End integriert werden. Zur Benutzereingabe sind Checkboxen, Buttons, Schalter und Schieberegler verfügbar. Die Eingabe von Text und Zahlen über Tastaturen und die Datumsauswahl über einen Kalender ist möglich. Die Kombination aus Anzeige und Eingabe bietet für den Bediener viele Möglichkeiten zur Darstellung der internen Zustände der Maschine, zur Navigation durch verschiedene Ansichten und zur Interaktion mit der Maschine in einer intuitiven Art und Weise. Die Übersichtlichkeit der Ansicht hängt vom Endgerät ab, mit der die WebVisu aufgerufen wird. Eine Ansicht, die viele oder große Elemente hat, ist auf einem großen Gerät wie einem Tablet einfacher zu bedienen als auf einem kleinen Gerät wie einem Smartphone. Wenn pro Ansicht wenige oder nur kleine Elemente vorhanden sind, müssen die relevanten Steuerelemente über viele Ansichten verteilt werden, worunter die intuitive Bedienbarkeit leidet. Kombination von ISOBUS-Front-End und Web-Front-End Der ISOBUS ist der Standard zur Visualisierung in der Landwirtschaft, daher sind Traktoren und Selbstfahrer mit einem ISOBUS-fähigen Bedienterminal ausgerüstet und der Fahrer ist dem Bedienkonzept des ISOBUS vertraut. Das IFE erfordert eine Kombination von

86

T. Eickhoff et al.

ISOBUS UT Server und ISOBUS UT Client. Daher sind die Anzeigegeräte auf Bedienterminals beschränkt, auf denen ein ISOBUS UT Server läuft. Die Verbindung zwischen ISOBUS UT Server und ISOBUS UT Client erfordert ein CAN Netzwerk und ist daher kabelgebunden. Das IFE ist somit an eine feste Position in der Kabine eines Traktors bzw. Selbstfahrers gebunden. Das WFE dagegen stellt an die möglichen Clients weniger Anforderungen und ist somit flexibler. Es kann auf einem mobilen Anzeigegerät wie einem Tablet angezeigt werden. Dies ist für die Reparatur von Vorteil, da eine Anleitung gesehen werden kann, während ein Servicetechniker an dem zu reparierenden Teil der Maschine steht. Die Kombination beider Front-Ends (IFE und WFE) ist auf landwirtschaftlichen Erntemaschinen sinnvoll, um sowohl eine Ansicht auf mobilen Geräten als auch eine Ansicht auf stationären Geräten wie Bedienterminals zur Verfügung zu stellen. In der Industrie gibt es keinen vergleichbaren Standard zum ISOBUS. Für die stationäre Visualisierung des WFE wird ebenfalls die CODESYS WebVisu auf einem stationären Bedienterminal verwendet, das mit Ethernet-Schnittstelle und einem HTML5-fähigen Browser ausgestattet ist. Zusätzlich ist in der CODESYS WebVisu eine Ankoppelung an das maschinenunabhängige Front-End möglich, siehe Abschn.  5.5.4. Durch ein Browser-Element wird der Inhalt einer Internetseite in der Ansicht des MFE angezeigt. Mithilfe dieses Elements ist eine eigene Interaktion mit dem Inhalt der angezeigten Internetseite möglich. Die Logik für Anzeige und Interaktion bleibt somit auf der Seite, an die geleitet wird. Dadurch können maschinenübergreifende Inhalte wie Reparaturhinweise zentral gespeichert werden und müssen nicht am MFE lokal gespeichert werden. Diese Anbindung ist bisher als Option getestet worden, allerdings noch nicht in die Front-Ends für die Demonstratoren eingebunden. Als Bedingung für die Anzeige auf einer Internetseite muss das „cross-origin framing“ auf der anzuzeigenden Seite erlaubt sein. Rollen und Ansichten Das MFE wird sowohl vom Bediener der Maschine als auch von den Servicetechnikern eingesetzt. Für den Bediener ist es wichtig, den Zustand jeder überwachten Komponente schnell und übersichtlich zu sehen, im Use-Case GRIMME z. B. den Verschleißzustand des Siebbandes der Maschine. Der Bediener sieht in seiner Anzeige den Verschleißzustand des Siebbandes in Form einer Ampel und dazu die Angabe des Verschleißes in Prozent. Jede überwachte Komponente der Maschine besitz eine eigene Ampel mit drei Zuständen: • Grün: Die Komponente hat einen geringen Verschleißzustand zwischen 0 und 33 % • Gelb: Die Komponente hat einen mittleren Verschleißzustand zwischen 34 und 66 % • Rot: Die Komponente hat einen hohen Verschleißzustand zwischen 67 und 100 % Falls eine Komponente einen hohen Verschleißgrad aufweist, kann der Bediener eine Bestellung für Ersatzteile auslösen. Der Servicetechniker vor Ort hat die Ansicht des Fahrers/

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

87

Bedieners und kann zusätzlich dazu relevante Sensordaten wie z.  B.  Spannung, Strom, Öltemperatur usw. als Datenverlauf sehen. Die physikalischen Werte sind jeweils abhängig von den Sensoren der überwachten Komponenten. Der Servicetechniker vor Ort hat in seiner Ansicht zusätzlich zugehörige Reparatur-Anleitungen zur Verfügung. Weiterhin kann der Servicetechniker weitere Services wie Reparaturen/Wartungen an der Maschine über das maschinenunabhängige Front-End beantragen. Zusammenfassung Die Front-Ends (IFE und WFE) zur hardwareunabhängigen Visualisierung und Nutzung servicerelevanter Informationen sind für die Use-Cases exemplarisch implementiert. Für die mobilen Arbeitsmaschinen ist die Visualisierung auf dem Bedienterminal über den standardisierten ISOBUS als IFE realisiert, für den Serviceeinsatz an der Maschine wird die CODESYS WebVisu für die Verwendung von mobilen Endgeräten als WFE eingesetzt. Für Maschinen in der Industrie-Automation sind beide Front-Ends als CODESYS WebVisu (WFE) implementiert. Die maschinenunabhängige Front-Ends eignen sich auch zum Remote-Adhoc-Zugriff über die Cloud auf die servicerelevanten Informationen der Maschinen.

5.5.4 Maschinenunabhängige Front-Ends Für viele Arbeitsabläufe in den Anwendungsszenarien des Projektes ist der Zugriff auf Daten in einem Kontext erforderlich, der nicht räumlich an eine einzelne Maschine gebunden ist. Beispielsweise wird sich ein Flottenmanager aus dem Use-Case 3 eher selten auf den Weg zu einem Kunden machen, um Daten über die im Einsatz befindlichen Maschinen über das MFE abzurufen. Für diese Szenarien ist es hilfreich, ein maschinenunabhängiges Front-End bereitzustellen.

5.5.4.1 Funktionsumfang des maschinenunabhängigen Front-Ends Im Kontext der Anwendungsszenarien des Projektes wurden unter anderem die folgenden Funktionen für das maschinenunabhängige Front-End identifiziert. Zugriff auf das erweiterte Wertschöpfungsnetzwerk (eWN) Der Zugriff auf das eWN umfasst vor allem Firmen und Personal. Es ist von zentraler Bedeutung, dem Benutzer in jedem Kontext die passenden Suchmasken zur Verfügung zu stellen, um beispielsweise Servicepartner oder Mitarbeiter für verschiedene Prozessabläufe zu finden. Diese Aufgaben sind bei der Verwendung eines PLM-basierten Back-Ends leicht umzusetzen. Zugriff auf PLM-Daten (digitaler Master) Auch hier kann auf die bestehende Funktionalität des PLM-Systems zurückgegriffen werden. Der Digitale Master wird für alle Aufgaben benötigt, die sich nicht auf die einzelne Maschine, sondern auf die klassischen Produktdaten, wie beispielsweise die Variantenstückliste, beziehen.

88

T. Eickhoff et al.

Übersicht über die Zustände von Maschinen und Maschinenkomponenten (digitale Zwillinge) Der Zugriff auf den digitalen Zwilling ist immer dann erforderlich, wenn Daten zu einer konkreten Produktinstanz benötigt werden. Hier müssen unterschiedliche Rollen berücksichtigt werden. Zur Verdeutlichung der Bandbreite der erforderlichen Ansichten sei hier als eine Option eine einfach zu bedienende Ansicht für den Servicetechniker vor Ort genannt (vergleichbar zum MFE, aber auch über mobile Devices erreichbar). Eine andere Option bildet die Flottenübersicht für den Maschineninstandhalter, der hier für alle aktuell verfügbaren digitalen Zwillinge die Statusmeldungen der intelligenten Komponenten bis zur Ausfallursache verfolgen kann. Zugriff auf Dienstleistungsinformationen (Service) Auch im Zusammenhang mit Servicearbeiten werden diverse aufgabenspezifische Oberflächen benötigt. Für die Unterstützung während der Servicearbeiten wird dem Servicetechniker eine interaktive Schritt-für-Schritt-Anleitung bereitgestellt, nach dem Abschluss der Servicearbeiten kann ein Servicebericht mit Anmerkungen erstellt werden. Die Berichte können dann am PC über mehrere digitale Zwillinge hinweg über entsprechende Filterkriterien gesucht werden. Auf die spezifischen Ausprägungen der genannten Funktionen in den einzelnen Use-Cases wird in Kap. 7 und 8 eingegangen. Dies schließt insbesondere die Verwaltung von konfigurationsabhängiger Geometrie im Use-Case John Deere (Abschn.  7.3.1) und die detaillierte Behandlung der Service-Anleitungen in Use-Case BHN/Lenze/Schaeffler (Abschn. 8.4.2.2) mit ein. Um einen unkomplizierten Zugang auf das Front-End von verschiedenen Endgeräten zu ermöglichen, ist der Einsatz einer Browser-basierten Lösung sinnvoll. Zumindest sollte darauf geachtet werden, dass jeder Rolle eine für ihr zu erwartendes Arbeitsumfeld passende Zugriffsmöglichkeit gewährt wird. Für den Servicetechniker unterwegs oder während Servicearbeiten könnte dies zum Beispiel ein Tablet sein (touchfreundliche Bedienung und einfache Benutzerführung sind wichtig!), während für den Manager am Schreibtisch eher mit einem PC zu rechnen ist (hier stehen eine hohe Informationsdichte und flexible Interaktionsmöglichkeiten im Vordergrund).

5.5.4.2 Implementierung im Projekt In der Implementierung im Projekt wurde das maschinenunabhängige Front-End größtenteils in Aras Innovator umgesetzt. Durch die Anpassung der Anzeige- und Bearbeitungsmasken der entsprechenden Datenelemente konnte bestehende Funktionalität genutzt und erweitert werden. Der Zugriff erfolgt dementsprechend über einen standardkonformen Internet-Browser. Dem Benutzer werden diverse Suchmasken als Einstiegspunkte für die Informationssuche bereitgestellt. Verschiedene Benutzergruppen sehen unterschiedliche Teilmengen der zur Verfügung stehenden Kategorien. Als Beispiel ist in Abb. 5.18 die Suche nach digitalen Zwillingen mit den Zuständen „Kritisch“ und „Ausgefallen“ aus Sicht eines

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

89

Abb. 5.18  Suche nach digitalen Zwillingen mit Status „Kritisch“

Administrator-­Benutzers abgebildet. Den Benutzern stehen die üblichen Funktionen zum Filtern oder Sortieren der Suchergebnisse zur Verfügung. Weitere Einstiegspunkte liefern der sogenannte „In-Basket“, in welchem neue Service-­ Aufträge von einem Servicetechniker angenommen werden können, sowie der frei vom Benutzer konfigurierbare „Desktop“. Für den Servicetechniker im Feld werden die von ihm angenommenen Serviceaufträge inklusive der zugehörigen Schritt-für-Schritt-Anleitungen in einer für mobile Geräte optimierten Ansicht angeboten, deren Komplexität weit geringer ist als die vollständige ­Oberfläche von Aras Innovator. Im Use-Case John Deere schließt dies auch die Darstellung der 3D-Geometrie von Bauteilen mit ein (siehe Abschn. 7.3.2).

5.5.5 Test und Verifikation der Front-Ends und des Back-Ends Entsprechend der in Abschn.  5.2.1 beschriebenen Modellierungssystematik stehen den Anforderungen an die technische Lösung Testfälle im Verifikationsraum gegenüber. Im Projektkontext wurden entsprechende Testfälle entwickelt, um das Back-End sowie die Front-Ends (maschinenunabhängig sowie Maschinen-Front-End) zu verifizieren. Die Testfälle ergeben sich hierbei indirekt aus den Anforderungen der drei Use-Cases. Während der Implementierung dienen die in einem Test-Managementsystem verwalteten Testfälle im Rahmen definierter Testszenarien als Basis für die fortlaufende Verifikation der Implementierung.

5.5.5.1 Vorgehensweise

Im Laufe des Projektes wurden die Arbeitspakete für die Verifikation des Front- und Back-­Ends zusammengelegt. Neben einer Zeitersparnis durch Nutzung von Synergiepotenzial ermöglicht ein derartiges Vorgehen das bessere Berücksichtigen von systemübergreifenden Szenarien. Aufgrund dieser Vorgehensweise gelten die in diesem Kapitel beschriebenen Ergebnisse gleichermaßen für die Verifikation beider Systeme.

90

T. Eickhoff et al.

Die Test-Cases bauen auf der abgestimmten Funktionsliste auf. Zusätzlich hilft Input der Use-Case-Steller bei der besseren Abbildung der angestrebten Szenarien. In den drei konkreten Use-Cases des Projektes lässt sich diesbezüglich eine gemeinsame Gesamtstruktur erkennen, die sich, auf den einzelnen Use-Case bezogen, vor allem in Ihrer Schwerpunktsetzung unterscheidet. Um auf derartige Überschneidungen zwischen geplanten Szenarien zu reagieren, kann ein gemeinsames „Maximalszenario“ definiert werden, aus dem sich die konkreten Szenarien nach dem Baukastenprinzip bedienen. Eine Beschreibung der Szenarien in Form eines Aktivitätsdiagramms bettet sich in das PSS-Gesamtsystemmodell ein und dient der Aufteilung und modellbasierten Verwaltung der Testfälle. Auch für die eigentliche Bearbeitung der Testfälle bietet sich eine maschinenfreundliche Repräsentation derselben an. Im Projektkontext kam zu diesem Zweck das Test-Management-System Testia Tarantula (http://www.tarantula.fi) zum Einsatz. Die einzelnen Phasen des beschriebenen Prozesses werden in den folgenden Abschnitten im Detail beleuchtet. Entwicklung des Maximalszenarios und der Testbausteine Um die Gemeinsamkeiten aller Use-Cases bestmöglich abbilden zu können, wird ein Maximalszenario definiert, welches aus „Testbausteinen“ besteht. Wie bei der Anforderungsentwicklung ist hierbei das Einbeziehen der Use-Case-Steller von zentraler Bedeutung, um ein gemeinsames Bild der gewünschten Szenarien sicherzustellen. Um eine für alle Partner gemeinsame Sprache zu erreichen, werden die Akteure in den konkreten Szenarien zu einer überschaubaren Menge an Rollen zusammengefasst. Die resultierenden Rollen der drei Use-Cases im Projekt sind in Abb.  5.19 abgebildet. Die Arbeitsabläufe werden auf eine ähnliche Weise abstrahiert. Die Teilschritte bilden die

Abb. 5.19  Rollen in den Use-Cases

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

91

Abb. 5.20 Testbausteine

Bausteine des Maximalszenarios (siehe Abb. 5.20). Die konkreten Einzelszenarien werden dann aus den jeweils relevanten Bausteinen zusammengesetzt. Exemplarisch soll folgendes Szenario aus UC 3 abgebildet werden:

Originale Szenariobeschreibung: „Störung kann nicht vom Maschinenbediener gelöst werden“ • Maschinenbediener: Störung tritt auf → Ampel springt auf rot –– Meldung mit Lösungsvorschlag an Bediener –– Nach Zeit oder durch neg. Bediener-Feedback, Meldung an Instandhaltung • Instandhalter verschafft sich Überblick –– … sieht Historie und Maschinenzustand –– … hat Remote Zugriff –– … bekommt Lösungsvorschlag vom System • → beauftragt passende Serviceaktivität • Service-Dienstleister erhält Service-Auftrag –– … mit Informationen zu Fehlerbehebung –– … dann Fehlerbehebung mit Dokumentation • Vorgang ist in Historie erfasst In Abb. 5.21 wird gezeigt, wie das Szenario mit den Bausteinen abgebildet werden kann. Einbettung in das Systemmodell Die Testbausteine werden (aus SysML-Sicht) als Aktivitäten in das PSS-Gesamtmodell übernommen. Um eine feingranulare Rückverfolgbarkeit sicherzustellen, kann ein

92

T. Eickhoff et al.

Abb. 5.21  Testbausteine für das Beispielszenario

Mapping zwischen den Testbausteinen und den betroffenen Systemfunktionen erstellt werden (siehe Abb. 5.22). Dies ermöglicht eine genaue Begründung, warum ein gegebener Testfall für die Funktion des Gesamtsystems relevant ist. Die einzelnen Testfälle dokumentieren, welche Schritte für die gegebenen Szenarien benötigt werden. Der zeitliche Zusammenhang der Testfälle kann im PSS-Gesamtmodell durch ein (SysML-) Aktivitätsdiagramm für das Gesamtszenario (beispielhaft in Abb. 5.23 abgebildet) und/oder einzelne Szenarien abgebildet werden. Eine Aufteilung desselben in Swimlanes für jeden betroffenen Akteur und jedes beteiligte Softwaresystem sorgt für bessere Übersichtlichkeit. Anlegen der Testfälle im Test-Management-System und Verifikation Mit den Ergebnissen der vorherigen Phase liegen neben den einzelnen Testbausteinen auch die zeitlichen Abläufe und Zusammenhänge im größeren Gesamtmodell auf einer feingranularen Ebene vor. Damit ist das Anlegen der Testfälle in einem Test-­Management-­ System eine rein mechanische Tätigkeit, die ggf. durch automatisierten Import in das System unterstützt werden kann. Die Begrifflichkeiten in den folgenden Abschnitten orientieren sich an dem im Projekt verwendeten System Testia Tarantula. Zu jedem Testfall wird ein entsprechendes Objekt angelegt, in dem die Funktion oder Aktivität in weitere Schritte unterteilt wird. Die Test-Cases werden anschließend in einem Gesamtszenario zusammengefasst, aus dem heraus für jeden Use-Case eine sogenannte Test-Execution extrahiert wird. Diese entsprechen den jeweils für relevant befundenen Testbausteinen. Das Test-Management-System unterstützt die Verifikation der Test-Cases durch Möglichkeiten wie das Zuordnen von Testfällen zu verantwortlichen Benutzern. Bei der Durchführung eines Testfalls wird der Benutzer interaktiv durch die einzeln definierten Schritte

93

Abb. 5.22  Mapping von Testbausteinen zur Funktionsliste

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

Abb. 5.23  Aktivitätsdiagramm für das Maximalszenario

94 T. Eickhoff et al.

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

95

geführt. Hierbei kann auch die für jeden Teilschritt benötigte Zeit gemessen werden. Nach erfolgreicher Durchführung eines Testszenarios kann dieses als abgeschlossen markiert werden. Das Test-Management-System kann mit diesen Informationen zu jedem Zeitpunkt Auskunft über den Anteil an erfolgreich verifizierten Testfällen liefern.

5.5.5.2 Fazit und Ausblick Die Verifikation der Projektergebnisse durch definierte Testfälle schließt den Kreis von der Implementierung zurück zu den Anforderungen. Durch Einbeziehung der Use-Case-­ Steller wird sichergestellt, dass die Testfälle für den späteren Einsatz der betroffenen Systeme repräsentativ sind. Durch ein gemeinsames Verständnis von Rollen und Testbausteinen können Gemeinsamkeiten zwischen den Use-Cases beleuchtet werden. Die Einbettung in das PSS-Gesamtmodell liefert ein hohes Maß an Nachverfolgbarkeit im Projektkontext.

5.6

I ntegration der Subsysteme in und Verifikation der Kommunikationsplattform

5.6.1 Integration der Business Analytics, Back-End, Front-End Das Kapitel beleuchtet die Hintergründe und Notwendigkeit einer Integration der beteiligten Komponenten Business Analytics, Front-End und Back-End. Es werden Leitfragen zur Bewertung der notwendigen Datenflüsse formuliert, die in der Folge zur Bewertung und schließlich zur Auswahl einer technischen Implementierung führen. Generelle Hinweise zur Arbeitsweise, der Komplexität der Aufgabe und ein konkretes Beispiel ergänzen den eher methodischen Teil des Kapitels. Im Anschluss wird auf die konkrete Implementierung im Forschungsprojekt eingegangen und die Gedanken zur Auswahl der Architektur dargestellt. Der Leser hat nach dem Lesen des Kapitels eine Vorstellung von den Fragestellungen und dem methodischen Ansatz zur Konzeption einer Datenintegration. Notwendigkeit der Integration Die konkrete Implementierung der verfügbarkeitsorientierten Geschäftsmodelle (vGM) erfordert eine Integration der technischen Komponenten. Die Aussagen zur Notwendigkeit einer Integration beziehen sich auf die im konkreten Projekt betrachteten Bestandteile Business Analytics, Back-End und Front-End, lassen sich aber auch auf weitere Komponenten ausdehnen, z. B. ERP- oder PLM-Systeme. Warum ist eine Integration notwendig? Jede der Komponenten implementiert Funktionen, die aufgrund der Gesamtsumme ihrer Anforderungen unterschiedliche technische Architekturen bedingen. Beispielsweise müssen in der Business Analytics große Datenmengen analysiert werden, während das Front-End Steuerungsfunktionen erfüllt und Informationen übersichtlich bereitstellt. Da­ raus folgt eine heterogene Systemlandschaft, in der aufgrund fehlender Standards eine flexible Datenintegration notwendig ist, sodass bei der konkreten Umsetzung von vGM dieses Thema berücksichtigt werden muss.

96

T. Eickhoff et al.

Die Ausführung der Geschäftsprozesse findet über Systemgrenzen hinweg statt und erfordert damit eine Orchestrierung der Teilprozesse. Diese kann durch generische, kommerziell verfügbare Software (Middleware), spezielle Lösungen oder einer Mischung von beidem implementiert werden. Die konkrete Auswahl einer oder mehrerer Lösungen muss anhand verschiedener Kriterien bewertet werden: • Was sind die am Geschäftsprozess beteiligten Komponenten? • Wie sieht die technische Infrastruktur aus, insbesondere unter Berücksichtigung des Investitionsgutes? • Welche Information (Inhalt und Umfang) muss zu welchem Zeitpunkt zwischen den Komponenten ausgetauscht werden? Schließlich dient die Integration der Informationsbereitstellung für beteiligte Stakeholder und schafft potenziell einen Mehrwert über die Implementierung der vGM hinaus, beispielsweise die Bereitstellung von Informationen aus der Business Analytics für die technische Optimierung im Rahmen der Produktentwicklung. Aspekte der Integration Die Planung einer Integration hinsichtlich Sammlung der Anforderungen und Software-­ Auswahl ist ein wichtiger Bestandteil der Gesamtlösung und kann systematisch erfolgen. Als Ausgangspunkt ist die Frage zu beantworten, welche Komponenten welche Informationen zu welchem Zeitpunkt austauschen müssen, um das vGM zu implementieren? Es bietet sich an, die Systemarchitektur zu Rate zu ziehen und die Datenflüsse grob zu visualisieren, wobei auch eine funktionelle Sicht eingenommen werden kann. Im Kern geht es um die übergeordnete Frage, welche Information wo benötigt wird, um das vGM abzubilden und zu steuern. Mit der gewonnenen Erkenntnis lassen sich im Folgenden diese Fragen beantworten, wobei immer der Bezug zum Gesamtkonzept des vGM gewahrt werden muss: • Welche Informationen sollen ausgetauscht werden und wozu dienen sie? Die Bandbreite geht dabei von einfachen Statusmeldungen zur Steuerung von Prozessen über den Austausch von Kennzahlen bis hin zum Austausch großer Datenmengen. Generell wird der Grundsatz der Datensparsamkeit empfohlen, d. h. die Konzentration auf die absolut notwendigen Informationen. • Zu welchen Zeitpunkten und wie häufig müssen die Informationen ausgetauscht und verteilt werden? Die Auslöser von Informationsflüssen können verschiedener Art sein: manuell durch Benutzer, automatisiert innerhalb von Prozessen oder zeitlich gesteuert. • Was ist die zeitliche Gültigkeit der Informationen und muss sie persistiert werden? Indirekt wirkt sich die Beantwortung auch auf die Zeitpunkte aus, zu denen Information aktualisiert werden muss. • Muss Information zwischen Komponenten ausgetauscht und damit potenziell repliziert werden oder reicht die Verknüpfung von Informationen über Systeme hinweg? Hier ist

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

97

kritisch zu hinterfragen, ob ein Informationsaustausch im Sinne der Datensparsamkeit in bestimmten Fällen überhaupt notwendig ist. • Welcher Logikanteil im Rahmen der zu implementierenden Prozesse liegt im Bereich der Datenintegration? Diese Frage ist im Zusammenhang mit der technischen Gesamtkonzeption zu beantworten. • Sind spezifische Standards zu berücksichtigen? Das kann sich auf den technischen Datenaustausch (Semantik und Technologie, z.  B.  OSLC, REST, ODATA), in der nächsten Stufe bezogen auf die Dateninhalte (z. B. ReqIF, STEP) oder weitergehende Standards beziehen. Generell lässt sich sagen, dass für die identifizierten Datenflüsse mit großer Wahrscheinlichkeit keine einheitliche technische Lösung zu finden sein wird, da die Unterschiedlichkeit der Anforderungen zu groß ist. Es sprechen auch wenige Gründe dagegen, für die jeweils speziellen Probleme entsprechende Lösungen aus der Vielzahl von Möglichkeiten auszuwählen. In jedem Fall sind die Erfordernisse aller beteiligten Stakeholder zu berücksichtigen. Allgemeine Hinweise Die Konzeption und Implementierung der vGM inklusive der Datenintegration ist kein streng linearer Prozess. Verschiedene Teilbereiche wechselwirken miteinander und ­erfordern eine enge Verzahnung innerhalb der Projektorganisation und einen ständigen Abgleich bis auf die Detailebene. Eine wichtige übergeordnete Aufgabe und Erkenntnis aus dem Forschungsprojekt ist, die Abhängigkeiten zwischen den Komponenten zu identifizieren und bis ins letzte Detail konsequent zu verfolgen, was sich an einem Beispiel aus der konkreten Implementierung belegen lässt. Beispiel

Beim Datenaustausch von Kennzahlen aus der Business Analytics in Richtung Back-­ End wurden zahlreiche technische Probleme gelöst, das Datenmodell festgelegt usw. In der im Projekt spät möglichen Datenanalyse aufgrund fehlender Rohdaten und der anschließenden Verarbeitung im Prozess stellt sich heraus, dass der Sensor in der Maschine Zahlenwerte liefert, allerdings keine physikalischen Einheiten. Diese ergeben sich faktisch aus der Bauweise und Datenübertragung eines Sensors, tauchen aber als Information im Prozess zunächst nicht auf. Ohne Einheit oder Bedeutung ist eine Kennzahl aber nutzlos, mindestens kann es zu Fehlern bei der Anwendung eines Regelwerks kommen (der NASA Mars Climate Orbiter, eine Investition von 125 Mio. Dollar, zerschellte auf dem Mars aufgrund einer Verwechslung des metrischen mit dem Amerikanischen Einheitensystem [17]). Es wurde festgelegt, dass die Einheit statisch festgelegt und in der Konfiguration der Integration bzw. dem dynamischen Datenmapping hinterlegt wird. Es zeigt sich, dass ein kleines Problem auf der Datenebene zu großen Schwierigkeiten im Gesamtprozess führen kann und demnach eine ständige Kontrolle und Abgleich notwendig sind.

98

T. Eickhoff et al.

Implementierung Im Forschungsprojekt wurden diese Integrationsanforderungen identifiziert und die technische Implementierung festgelegt. Es werden die beteiligten Komponenten, die Entscheidung zur technischen Integration und eine kurze Charakteristik dargestellt. • Business Analytics/Back-End –– Integration über XPLM Integrationsplattform (Middleware) –– Ereignisgesteuerter, automatisierter Datenaustausch von technischen Informationen und Prozesssteuerung im Back-End; Kernaufgabe ist die Übertragung von Kennzahlen (Analyseergebnissen). • Front-End/Back-End –– Integration über direkten Zugriff auf das Back-End –– Bereitstellung von Informationen und Angebot von Aktionen für den Benutzer im Front-End; Kernaufgabe ist die visuelle Darstellung von persistierten Informationen des Back-Ends und die Steuerung von Prozessen durch den Benutzer. • Front-End/Business Analytics –– Integration über direkten Zugriff auf die Business Analytics –– Anzeige erweiterter Informationen zum Zustand der Maschine im Front-End; keine direkte Nutzung innerhalb des vGM, sondern nützliche Zusatzinformation für den Benutzer. Die beiden letztgenannten Integrationen bestehen aus einem verhältnismäßig einfachen technischen Durchgriff und enthalten keine Prozesslogik (bezogen auf die Integration), sie werden daher nicht weiter besprochen. Die komplexere Integration zwischen Business Analytics und Back-End wird im Folgenden diskutiert. Integration Business Analytics Back-End Die Integration sorgt für den Transport von Daten aus der Business Analytics in Richtung Back-End und implementiert drei wesentliche Funktionen (siehe Abb. 5.24). Neben dem Zugriff auf Mess- und Analysedaten in der Business Analytics über eine SQL-Schnittstelle

Abb. 5.24  XPLM Integration Infrastruktursicht

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

99

und dem Zugriff auf das fachliche Datenmodell des Back-Ends über Nutzung einer bereits existierenden API erlaubt die Integration an sich die Konvertierung von Daten für die verwendeten Schnittstellen, die Erzeugung neuer Objekte im Back-End, sowie die Veränderung bestehender Objekte, z.  B. die Aktualisierung von Eigenschaften, über die Implementierung konfigurierbarer Datenaustauschprozesse. Die Daten werden für eine flexible Verarbeitung mit standardisierten Komponenten in der Integrationsplattform normiert. Der Dateninhalt wurde auf die Übertragung von für jeden Anwendungsfall unterschiedlichen Kenndaten beschränkt, welche steuernden Einfluss auf Bestandteile des vGM haben. Persistierte Roh-/Messdaten aus der Business Analytics werden nicht repliziert, da sie keinen Mehrwert im Back-End erzeugen und auf anderen Wegen zur Laufzeit abgefragt werden können. Generell wurden drei Ansätze zur zeitlichen bzw. logischen Steuerung des Datenaustauschs diskutiert und bewertet: • Push-Prinzip (die Business Analytics startet die Übertragung unmittelbar nach Änderungen von Dateninhalten): Dem Vorteil der hohen Datenaktualität im Back-End stehen die Nachteile der potenziell hohen Datendurchsätze und des möglichen Aufwands für die Implementierung entgegen. Da vGM in der Regel einen vorausschauenden Charakter haben, ist eine Datenversorgung des Back-Ends in „Echtzeit“ nicht notwendig. • Pull-Prinzip (das Back-End startet die Übertragung nach Notwendigkeit): Vorteilhaft ist die präzise Steuerung der Datenabfragen nach den prozessualen Erfordernissen, nachteilhaft ist der technisch etwas komplexere Weg. Aus fachlicher Sicht besteht keine Anforderung, die Datenaktualisierung aus dem Back-End zu steuern. • Synchronisations-Prinzip (die Integration steuert Häufigkeit und Inhalt der Datenaktualisierung): Die Implementierung innerhalb der Integration bietet eine fachliche Geschlossenheit der Lösung, da Konfiguration, Datenkonvertierung und Geschäftslogik in der gleichen Applikation implementiert werden. Die leichte Entkopplung von Business Analytics und Back-End kann aus fachlicher Sicht verschmerzt werden. Die Ansätze werden in der folgenden Abb. 5.25 in einer Übersicht dargestellt.

Abb. 5.25  XPLM Integration Push-Pull-Sync-Prinzip

100

T. Eickhoff et al.

In der Abwägung verschiedener Aspekte wurde die Lösungsarchitektur nach dem Synchronisations-­Prinzip gewählt, bei der die Integration die Aktualisierungshäufigkeit und die Inhalte steuert. Die Lösung schließt eine Ergänzung um oder komplette Umstellung auf eines der anderen Prinzipien nicht aus und kann bei Bedarf angepasst werden. Die Wahl eines flexiblen Ansatzes in der Implementierung erlaubt die schnelle Reaktion auf zukünftige Änderungen im vGM. Abkürzungen PLM Product Lifecycle Management ERP Enterprise Ressource Planning OSLC Open Services for Lifecycle Collaboration REST REpresentational State Transfer ODATA Open Data Protocol ReqIF Requirements Interchange Format STEP Standard for the Exchange of Product model data (ISO 10303) SQL Structured Query Language API Application programming interface

5.6.2 Test und Verifikation der Kommunikationsplattform In diesem Kapitel soll abschließend auf die Umsetzung der Anforderungen an die Kommunikationsplattform eingegangen werden. Von den folgenden 30 Anforderungen wurden im Verlauf des Projekts zwei nicht erfüllt, bzw. eine nicht erfüllt und eine als obsolet erkannt. Die Anforderungen und ihre Erfüllung bzw. Nichterfüllung wird nachfolgend beschrieben.

5.6.2.1 Einzelne funktionale Anforderungen zur Unterstützung des Back-Ends Anforderungsbezeichnung: REQ_KP_S_BE_1 Beschreibung: Die Kommunikationsplattform soll die Vorhaltung aller notwendigen Dateninhalte im Back-End für die Durchführung des Use-Cases des Investitionsgutes unterstützen. Insbesondere Dateninhalte wie Wettervorhersage, Bodeninformationen oder Ernteplanung. Also Daten, die nicht Teil des Digitalen Zwillings sind. Prüfkriterium: Vergleich der Daten an ihren Quellen mit den Daten im Back-End auf der Kommunikationsplattform Ergebnis: Anforderung wurde nicht erfüllt, da Satellitendaten über Bodenfeuchte nicht in der notwendigen Auflösung in der finalen Projektphase (Januar 2019) zur Verfügung standen. Anforderungsbezeichnung: REQ_KP_S_BE_2 Beschreibung: Die Kommunikationsplattform soll die Vorhaltung und Ausführung aller notwendigen Arbeitsabläufe im Back-End für die Durchführung des Use-Cases des Investitionsgutes unterstützen. Insbesondere Bedienungs- und Handlungsanweisungen bereitstellen, die nicht Teil einer Diagnoseaktivität, wie z. B. der Fehlerbehebung o. Ä., sind.

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

101

Prüfkriterium: Befolgen der vom Back-End bereitgestellten Arbeitsanweisungen durch einen unerfahrenen Nutzer des Investitionsgutes unter Kontrolle und Aufsicht eines erfahrenen Nutzers und Vergleich mit den Arbeitsanweisungen aus der ursprünglichen Quelle, wie z. B. Service-Manuals des Investitionsgutes. Ergebnis: Anforderung wurde erfüllt, durch Betrieb von Aras Innovator auf der OTC.

5.6.2.2 Einzelne funktionale Anforderungen zur Unterstützung des Front-Ends Anforderungsbezeichnung: REQ_KP_S_FE_1 Beschreibung: Die Kommunikationsplattform soll die Anzeige aller notwendigen Informationen im Front-End für die Durchführung des Use-Cases des Investitionsgutes unterstützen. Insbesondere Bedienungs- und Handlungsanweisungen bereitstellen, die nicht Teil einer Diagnoseaktivität, wie z. B. der Fehlerbehebung o. ä. sind. Prüfkriterium: Vergleichen der im Front-End angezeigten Informationen mit den ursprünglichen Quellen. Ergebnis: Anforderung wurde erfüllt, durch Anzeige der aufgezeichneten Messwerte auf dem Messwert-Server. Anforderungsbezeichnung: REQ_KP_S_FE_2 Beschreibung: Die Kommunikationsplattform soll die Eingabe aller notwendigen Informationen im Front-End für die Durchführung des Use-Cases des Investitionsgutes unterstützen. Insbesondere die Auswahl von Bedienungs- und Handlungsoptionen, inklusive der Diagnoseaktivitäten. Prüfkriterium: Vergleichen der erwarteten Aktionen im Use-Case mit den erfolgten Eingaben. Ergebnis: Anforderung wurde erfüllt, durch Nutzung des im Projekt angepassten Front-­ Ends der ausgewählten PLM-Lösung Aras Innovator auf der OTC. 5.6.2.3 Einzelne funktionale Anforderungen zur Unterstützung des Business-Analytics Anforderungsbezeichnung: REQ_KP_S_BA_1 Beschreibung: Die Kommunikationsplattform soll die Auswertung aller vorhandenen Daten und Informationen für die Durchführung des Use-Cases des Investitionsgutes unterstützen. Insbesondere die Auswertung von Sensordaten. Prüfkriterium: Die Methoden der Business Analytics können auf die benötigten Daten zugreifen und diese verarbeiten. Ergebnis: Anforderung wurde erfüllt, durch Zugriff auf die aufgezeichneten Messwerte auf dem Messwert-Server und anschließender Auswertung. 5.6.2.4 Einzelne funktionale Anforderungen zur Unterstützung des digitalen Zwillings Anforderungsbezeichnung: REQ_KP_S_DT_1 Beschreibung: Die Kommunikationsplattform soll die Vorhaltung aller notwendigen Dateninhalte des digitalen Zwillings für die Durchführung der Use-Cases unterstützen.

102

T. Eickhoff et al.

Prüfkriterium: Die PLM-Anteile des digitalen Zwillings auf der Kommunikationsplattform entsprechen den Daten in den originalen Herkunftssystemen. Die Messwert-Anteile des digitalen Zwillings auf der Kommunikationsplattform entsprechen den Werten direkt am Investitionsgut. Ergebnis: Der PLM-Anteil der Anforderung wurde erfüllt durch die Installation von Aras Innovator und der Datenmodelle auf der OTC. Der Messwert-Anteil der Anforderung wurde erfüllt durch den Upload der Messwerte per MQTT auf den Messwert-Server. Anforderungsbezeichnung: REQ_KP_S_DT_2 Beschreibung: Die Kommunikationsplattform soll alle notwendigen Datenformate des digitalen Zwillings, sowohl für die dynamischen, als auch für die statischen Daten, für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Die vereinbarten Datenformate für den digitalen Zwilling können lesend wie schreibend genutzt werden. Ergebnis: Der Anteil der Anforderung für die statischen Daten wurde erfüllt durch die Nutzung der PLM-Anteile in Aras Innovator und der Anteil der Anforderung für die dynamischen Daten wurde erfüllt durch die Speicherung der Messwerte in einer NoSQL-­ Datenbank auf den Messwert-Server.

5.6.2.5 Einzelne funktionale Anforderungen zur Unterstützung der Querschnittsfunktion Diagnose Anforderungsbezeichnung: REQ_KP_S_DIAG_1 Beschreibung: Die Kommunikationsplattform soll die Fehlererkennung als Teil der Querschnittsfunktionalität „Diagnose“ für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Am Investitionsgut geplant platzierte Fehler müssen reproduzierbar erkannt werden. Ergebnis: Die Anforderung wurde erfüllt durch reproduzierbare Sensorwertänderungen mit geplanter Fehlerstimulation am Messeaufbau im Use-Case 3. Anforderungsbezeichnung: REQ_KP_S_DIAG_2 Beschreibung: Die Kommunikationsplattform soll die Formulierung einer Fehlermeldung als Teil der Querschnittsfunktionalität „Diagnose“ für die Durchführung der Use-­ Cases unterstützen. Prüfkriterium: Am Investitionsgut geplant platzierte Fehler müssen (nach Erkennung) reproduzierbar beschrieben werden. Ergebnis: Die Anforderung wurde erfüllt durch reproduzierbare Meldungen mit geplanter Fehlerstimulation am Messeaufbau im Use-Case 3. Anforderungsbezeichnung: REQ_KP_S_DIAG_3 Beschreibung: Die Kommunikationsplattform soll die Formulierung der Fehlerbehebung als Teil der Querschnittsfunktionalität „Diagnose“ für die Durchführung der Use-­ Cases unterstützen. Prüfkriterium: Am Investitionsgut geplant platzierte Fehler müssen (nach Erkennung und Meldung) reproduzierbar behoben werden können. Ergebnis: Die Anforderung wurde erfüllt durch die Anzeige der in Aras Innovator hinterlegten Anleitungen nach geplanter Fehlerstimulation am Messeaufbau im Use-Case 3.

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

103

Anforderungsbezeichnung: REQ_KP_S_DIAG_4 Beschreibung: Die Kommunikationsplattform soll die Fehlervermeidung als Teil der Querschnittsfunktionalität „Diagnose“ für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Am Investitionsgut geplant applizierte Belastungen (die bei Fortsetzung zu Fehlern führen würden) müssen reproduzierbar gemeldet werden können. Ergebnis: Die Anforderung wurde erfüllt durch die Anzeige der in Aras Innovator hinterlegten Hinweise nach Applikation einer Belastung am Messeaufbau im Use-Case 3.

5.6.2.6 Funktionale Mehrfachanforderungen Anforderungsbezeichnung: REQ_KP_M_1 Beschreibung: Die Kommunikationsplattform soll die durchgängige Durchführung der Fehlererkennung, der Fehlermeldung und der Fehlerbehebung für die Durchführung der Use-Cases des Investitionsgutes unterstützen. Prüfkriterium: Am Investitionsgut geplant platzierte Fehler müssen erkannt, gemeldet und behoben werden können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_DIAG_1, REQ_KP_S_DIAG_2 und REQ_KP_S_DIAG_3. Anforderungsbezeichnung: REQ_KP_M_2 Beschreibung: Die Kommunikationsplattform soll die durchgängige Ausführung der Fehlervermeidung unter Verwendung der Dateninhalte des Digital Twins für die Durchführung der Use-Cases des Investitionsgutes unterstützen. Prüfkriterium: Am Investitionsgut applizierte Belastungen an Teilen, die im digitalen Zwilling abgebildet sind, müssen reproduzierbar als ausfallgefährdet erkannt und gemeldet werden können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_DT_1, REQ_KP_S_DT_2 und REQ_KP_S_DIAG_4. Anforderungsbezeichnung: REQ_KP_M_3 Beschreibung: Die Kommunikationsplattform soll die Durchführung der Datenhaltung im Back-End unter Verwendung der Datenformate des digitalen Zwillings für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Der digitale Zwilling muss modifiziert werden können. Ergebnis: Die Anforderung wurde erfüllt durch die Ableitungsmöglichkeit eines Twins aus dem Master in Aras Innovator auf dem OTC-Server und durch die Änderungsmöglichkeit der Datenstrukturen auf dem Messwert-Server. Anforderungsbezeichnung: REQ_KP_M_4 Beschreibung: Die Kommunikationsplattform soll die durchgängige Ausführung der Fehlerbehebung durch die Vorgabe von Arbeitsabläufen aus dem Back-End für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Am Investitionsgut platzierte Fehler müssen nach Erkennung und Meldung geführt behoben werden können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_DIAG_1, REQ_KP_S_DIAG_2, REQ_KP_S_DIAG_3, REQ_ KP_S_BE_2 und REQ_KP_S_FE_1.

104

T. Eickhoff et al.

Anforderungsbezeichnung: REQ_KP_M_5 Beschreibung: Die Kommunikationsplattform soll die durchgängige Vorhaltung und Bereitstellung von Arbeitsabläufen aus dem Back-End für die Durchführung der Use-­ Cases unterstützen. Prüfkriterium: Arbeitsabläufe müssen ins Back-End eingestellt und daraus bereitgestellt werden können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_FE_2 und REQ_KP_S_BE_2. Anforderungsbezeichnung: REQ_KP_M_6 Beschreibung: Die Kommunikationsplattform soll die durchgängige Nutzung der Anzeige des Front-Ends durch die Fehlererkennung, die Fehlermeldung, die Fehlerbehebung und die Fehlervermeidung für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Am Investitionsgut platzierte Fehler müssen mit den Anzeigefunktionalitäten des Front-Ends bearbeitet werden können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_DIAG_1, REQ_KP_S_DIAG_2, REQ_KP_S_DIAG_3, REQ_ KP_S_DIAG_4 und REQ_KP_S_FE_1. Anforderungsbezeichnung: REQ_KP_M_7 Beschreibung: Die Kommunikationsplattform soll die durchgängige Nutzung der Anzeige des Front-Ends für die Dateninhalte des digitalen Zwillings für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Dateninhalte des digitalen Zwillings müssen mit den Anzeigefunktionalitäten des Front-Ends genutzt werden können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_DT_1, REQ_KP_S_DT_2 und REQ_KP_S_FE_1. Anforderungsbezeichnung: REQ_KP_M_8 Beschreibung: Die Kommunikationsplattform soll die durchgängige Nutzung der Anzeige des Front-Ends für die Darstellung der Arbeitsabläufe für die Fehlererkennung, die Fehlermeldung, die Fehlerbehebung und die Fehlervermeidung für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Im Back-End vorgehaltene Arbeitsabläufe müssen mit den Anzeigefunktionalitäten des Front-Ends genutzt werden können und am Investitionsgut platzierte Fehler müssen nach Erkennung und Meldung behoben werden können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_DIAG_1, REQ_KP_S_DIAG_2, REQ_KP_S_DIAG_3, REQ_ KP_S_DIAG_4, REQ_KP_S_FE_1 und die in Aras Innovator hinterlegten Arbeitsabläufe. Anforderungsbezeichnung: REQ_KP_M_9 Beschreibung: Die Kommunikationsplattform soll die durchgängige Nutzung der Anzeige des Front-Ends für die Darstellung der Dateninhalte des digitalen Zwillings unter Nutzung der Arbeitsabläufe aus dem Back-End für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Im digitalen Zwilling vorhandene Informationen müssen mit den Anzeigefunktionalitäten des Front-Ends genutzt werden können.

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

105

Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_DT_1, REQ_KP_S_DT_2, REQ_KP_S_FE_1 und REQ_KP_S_ BE_2. Anforderungsbezeichnung: REQ_KP_M_10 Beschreibung: Die Kommunikationsplattform soll die durchgängige Nutzung der Eingabe des Front-Ends für die Modifizierung der Dateninhalte des digitalen Zwillings, der Fehlererkennung, der Fehlermeldung und der Fehlerbehebung für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Im digitalen Zwilling vorhandene Informationen müssen mit den Eingabefunktionalitäten des Front-Ends modifiziert werden können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_DT_1, REQ_KP_S_DT_2, REQ_KP_S_DIAG_1, REQ_KP_S_ DIAG_2, REQ_KP_S_DIAG_3 und REQ_KP_S_FE_2. Anforderungsbezeichnung: REQ_KP_M_11 Beschreibung: Die Kommunikationsplattform soll die durchgängige Nutzung der Eingabe des Front-Ends für die Auswahl von Handlungsalternativen aus den Arbeitsabläufen im Back-End für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Im Back-End vorhandene Arbeitsabläufe müssen mit den Eingabefunktionalitäten des Front-Ends ausgewählt werden können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_BE_2 und REQ_KP_S_FE_2. Anforderungsbezeichnung: REQ_KP_M_12 Beschreibung: Die Kommunikationsplattform soll die durchgängige Nutzung der Eingabe des Front-Ends für die Dokumentation von Handlungen im Back-End für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Im Back-End nicht vorhandene Arbeitsabläufe müssen mit den Eingabefunktionalitäten des Front-Ends eingegeben werden können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_BE_2, REQ_KP_S_FE_2 und REQ_KP_S_DT_1. Anforderungsbezeichnung: REQ_KP_M_13 Beschreibung: Die Kommunikationsplattform soll die durchgängige Nutzung der Eingabe und der Ausgabe des Front-Ends für die Arbeitsabläufe im Back-End für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Im Back-End vorhandene Arbeitsabläufe müssen mit den Anzeigefunktionalitäten des Front-Ends angezeigt und mit den Eingabefunktionalitäten des Front-Ends modifiziert werden können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_BE_2, REQ_KP_S_FE_1, REQ_KP_S_FE_2 und REQ_KP_S_DT_1. Anforderungsbezeichnung: REQ_KP_M_14 Beschreibung: Die Kommunikationsplattform soll die durchgängige Nutzung der Dateninhalte des digitalen Zwillings durch die Methoden der Business Analytics für die Durchführung der Use-Cases unterstützen.

106

T. Eickhoff et al.

Prüfkriterium: Programme der Business Analytics sollen auf die Werte im digitalen Zwilling zugreifen können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_DT_1 und REQ_KP_S_BA_1. Anforderungsbezeichnung: REQ_KP_M_15 Beschreibung: Die Kommunikationsplattform soll die durchgängige Nutzung der Dateninhalte des digitalen Zwillings und der Datenhaltung des Back-Ends durch die Methoden der Business Analytics für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Programme der Business Analytics sollen auf die Werte im digitalen Zwilling und auf Werte in der Datenhaltung des Back-Ends zugreifen können. Ergebnis: Die Anforderung wurde nicht erfüllt bzw. wurde obsolet, da der Master des digitalen Zwillings im Back-End repräsentiert ist und der Master für die Business Analytics nicht benötigt wurde. Anforderungsbezeichnung: REQ_KP_M_16 Beschreibung: Die Kommunikationsplattform soll die durchgängige Nutzung der Dateninhalte des digitalen Zwillings und der Arbeitsabläufe des Back-Ends durch die Methoden der Business Analytics für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Programme der Business Analytics sollen auf die Werte im digitalen Zwilling zugreifen und aus den Arbeitsabläufen des Back-Ends Handlungsalternativen vorschlagen können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_BE_2, REQ_KP_S_DT_1 und REQ_KP_S_BA_1. Anforderungsbezeichnung: REQ_KP_M_17 Beschreibung: Die Kommunikationsplattform soll die durchgängige Nutzung der Dateninhalte des digitalen Zwillings und der Anzeigefunktionen des Front-Ends durch die Methoden der Business Analytics zur Verwendung in der Fehlervermeidung und Fehlerbehebung für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Programme der Business Analytics sollen auf die Werte im digitalen Zwilling zugreifen und die Ergebnisse der Algorithmen darstellen können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_FE_1, REQ_KP_S_DT_1, REQ_KP_S_BA_1, REQ_KP_S_ DIAG_3 und REQ_KP_S_DIAG_4. Anforderungsbezeichnung: REQ_KP_M_18 Beschreibung: Die Kommunikationsplattform soll die durchgängige Nutzung der Dateninhalte des digitalen Zwillings, der Anzeigefunktionen des Front-Ends und der Arbeitsabläufe im Back-End durch die Methoden der Business Analytics zur Verwendung in der Fehlervermeidung für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Programme der Business Analytics sollen auf die Werte im digitalen Zwilling und die Arbeitsabläufe im Back-End zugreifen und die Ergebnisse der Algorithmen zwecks Fehlervermeidung darstellen können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_FE_1, REQ_KP_S_DT_1, REQ_KP_S_BE_2, REQ_KP_S_BA_1 und REQ_KP_S_DIAG_4.

5  Intelligentes Informationsmanagement für verfügbarkeitsorientierte …

107

Anforderungsbezeichnung: REQ_KP_M_19 Beschreibung: Die Kommunikationsplattform soll die durchgängige Nutzung der Dateninhalte des digitalen Zwillings, der Anzeige- und Eingabefunktionen des Front-Ends und der Arbeitsabläufe und Datenhaltung im Back-End durch die Methoden der Business Analytics für die Durchführung der Use-Cases unterstützen. Prüfkriterium: Programme der Business Analytics sollen auf die Werte im digitalen Zwilling und die Arbeitsabläufe und Datenhaltung im Back-End zugreifen und die Ergebnisse der Algorithmen darstellen können. Ergebnis: Die Anforderung wurde erfüllt durch die durchgängige Erfüllung der Anforderungen REQ_KP_S_FE_1, REQ_KP_S_FE_2, REQ_KP_S_DT_1, REQ_KP_S_BE_2 und REQ_KP_S_BA_1 sowie der Tatsache, dass die Business Analytics keine Erfüllung der Anforderung REQ_KP_S_BE_1 benötigte, sondern die Messwertanteile des digitalen Zwillings (=REQ_KP_S_DT_1).

Literatur 1. Eigner M (2016) Das Industrial Internet – Engineering Prozesse und IT-Lösungen. In: Sendler U (Hrsg) Industrie 4.0 grenzenlos. Springer, Berlin/Heidelberg, S 137–168 2. Baines TS, Lightfoot HW, Evans S, Neely A, Greenough R, Peppard J, … Wilson H (2007) State-of-the-art in product-service systems. Proc Inst Mech Eng B J Eng Manuf 221(10):1543– 1552. https://doi.org/10.1243/09544054JEM858 3. Pezzotta G, Pinto R, Pirola F, Ouertani M-Z (2014) Balancing product-service providers performance and customers value: the Service Engineering Methodology (SEEM). Procedia CIRP 16:50–55. https://doi.org/10.1016/j.procir.2014.01.008 4. Müller P (2014) Integrated engineering of products and services  – layer-based development methodology for product-service systems. Fraunhofer, Berlin 5. Thomas O, Nüttgens M (2009) Dienstleistungsmodellierung – Methoden, Werkzeuge und Branchenlösungen. Physica, Berlin/Heidelberg 6. Dangelmaier W, Hamoudia H (2002) Prozessmodellierung für die Planung der Dienstleistungserstellung im industriellen Bereich. In: Proceedings zur Tagung Modellierung betrieblicher Informationssysteme – MobIS 2002, S 7–28 7. Aurich JC, Fuchs C, Wagenknecht C (2006) Life cycle oriented design of technical product-­ service systems. J Clean Prod 14:1480–1494. https://doi.org/10.1016/j.jclepro.2006.01.019 8. Eigner M, Koch W, Muggeo C (2017) Modellbasierter Entwicklungsprozess cybertronischer Systeme – Der PLM-unterstützte Referenzentwicklungsprozess für Produkte und Produktionssysteme. Springer, Berlin/Heidelberg 9. Pfenning M (2017) Durchgängiges Engineering durch die Integration von PLM und MBSE. Dissertation, Technische Universität Kaiserslautern, Schriftenreihe VPE, Band 20 10. Eigner M, Dickopf T, Apostolov H (2018) Interdisziplinäre Konstruktionsmethoden und -prozesse zur Entwicklung cybertronischer Produkte  – Teil 1. In: Konstruktion, 11-12-2018, VDI Fachmedien, Dusseldorf 11. Eigner M, Dickopf T, Apostolov H (2019) Interdisziplinäre Konstruktionsmethoden und -prozesse zur Entwicklung cybertronischer Produkte  – Teil 2. In: Konstruktion, 01-02-2019, VDI Fachmedien, Dusseldorf 12. Seiter M (2017) Business Analytics  – Effektive Nutzung fortschrittlicher Algorithmen in der Unternehmenssteuerung. Vahlen, München

108

T. Eickhoff et al.

13. eoda (2018) Predictive Maintenance mit R  – Potenziale und Möglichkeiten der freien Statistiksprache R für neue Geschäftsmodelle im Industrie 4.0 Zeitalte., White paper. https://www. eoda.de/files/Use_Case_Seiten/Whitepaper/Predictive_Maintenance_mit_R.pdf. Zugegriffen am 03.02.2019 14. Aras Corporation (2016) Variants. https://github.com/ArasLabs/variants. Zugegriffen am 15.12.2018 15. Eigner M, Stelzer R (2009) Product lifecycle management. Springer, Heidelberg 16. Muggeo C, Pfenning M (2015) Die Rolle von MBSE und PLM im Industial Internet. In: Schulze S, Tschirmer C (Hrsg) Tag des Systems Engineering. Carl Hanser, München, S 279–287 17. Isbell D, Savage D (1999) National Aeronautics and Space Administration NASA. https://mars. jpl.nasa.gov/msp98/news/mco991110.html. Zugegriffen am 05.02.2019

6

Anwendungsfall GRIMME Paaranan Sivasothy, Jan C. Aurich, Dani Bechev, Horst Brehm, Georgis Bulun, Claudia Glenske, Michael Grethler, Christoph F. Herder, Julian Imwalle, Andrej Keksel, Patrick Kölsch, Ralf Mattukat, Gerald Wessel, Bernd Sauer, Jörg Seewig, Frank Zeihsel und Viviane Zimmermann

Zusammenfassung

Als Hersteller innovativer Kartoffel-, Rüben- und Gemüsetechnik ist die GRIMME Landmaschinenfabrik stets daran interessiert neue Geschäftsmodell und Technologien zu nutzen, um einen Vorteil gegenüber den Wettbewerbern zu haben. In dem folgenden Kapitel wird beschrieben, wie die Grundlagen für eben dies geschaffen werden. Neben der Entwicklung eines Geschäftskonzepts, dem die Verfügbarkeit einer komplexen Erntemaschine zu Grunde liegt, erfährt der Leser ebenfalls welche technischen

P. Sivasothy (*) · G. Bulun · A. Keksel · J. Seewig Lehrstuhl für Messtechnik und Sensorik, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected]; [email protected]; seewig@mv. uni-kl.de J. C. Aurich · C. F. Herder · P. Kölsch Lehrstuhl für Fertigungstechnik und Betriebsorganisation, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected]; [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 J. C. Aurich et al. (Hrsg.), Entwicklung datenbasierter Produkt-Service Systeme, https://doi.org/10.1007/978-3-662-59643-2_6

109

110

P. Sivasothy et al.

Voraussetzungen dafür nötig sind. Der konkrete Anwendungsfall dreht sich um eine Komponente eines Kartoffelvollernters, in diesem Fall das Aufnahmeband, welches die Kartoffeln aus der Erde in die Maschine fördert. Es soll der Ausfallzeitpunkt bestimmt werden, um im Vorfeld Maßnahmen zu ergreifen, welche die zugesicherte Verfügbarkeit des Bandes bzw. des Roders gewährleisten. Hierzu mussten die Fehlerursachen analysiert und neue Sensoren entwickelt werden, um diese zu messen. Für die Übertragung der gemessenen Daten in eine Cloud wurden Schnittstellen und Wege für die Datenvermittlung entwickelt. Darüber hinaus beschreibt das Kapitel die Signalverarbeitung der übermittelten Daten und wie mit Hilfe von Business Analytics der Ausfallzeitpunkt vorhergesagt werden kann. Die gewonnenen Informationen kann der Nutzer über die entsprechenden Front Ends einsehen, um die Verfügbarkeit der Maschine sicherzustellen.

D. Bechev · B. Sauer Lehrstuhl für Maschinenelemente und Getriebetechnik, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected] H. Brehm Schaeffler AG, Herzogenaurach, Deutschland E-Mail: [email protected] C. Glenske Sensitec GmbH, Lahnau, Deutschland E-Mail: [email protected] M. Grethler SolidLine AG, Karlsruhe, Deutschland E-Mail: [email protected] J. Imwalle · R. Mattukat Anedo GmbH, Eydelstedt, Deutschland E-Mail: [email protected]; [email protected] G. Wessel GRIMME Landmaschinenfabrik GmbH & Co. KG, Damme, Deutschland E-Mail: [email protected] F. Zeihsel enbiz GmbH, Kaiserslautern, Deutschland E-Mail: [email protected] V. Zimmermann Unity AG, Stuttgart, Deutschland E-Mail: [email protected]

6  Anwendungsfall GRIMME

6.1

111

 usgangssituation bei der GRIMME Landmaschinenfabrik A GmbH & Co. KG

Im Jahr 1861 wurde im niedersächsischen Damme ein Schmiedebetrieb gegründet, aus dem heute die GRIMME Landmaschinenfabrik (im Weiteren nur „GRIMME“) erwachsen ist. Das familiengeführte, mittelständische Unternehmen entwickelt sich stetig weiter vom Spezialisten in der Kartoffeltechnik für Feld und Halle zum weltweit agierenden Anbieter innovativer Kartoffel-, Zuckerrüben und Gemüsetechnik. Die Landmaschinenfabrik zählt zur GRIMME-Gruppe. Diese beschäftigt über 2400 Mitarbeiter weltweit, davon 1350 am Stammsitz in Damme und dem nahegelegenen Werk 2 in Rieste. Die weiteren Mitarbeiter sind bei den anderen zur Gruppe gehörenden Unternehmen beschäftigt. Dazu gehören beispielsweise der nordamerikanische Kartoffel- und Rübentechnikhersteller SPUDNIK, der dänische Gemüsetechnikhersteller ASA-LIFT, die herstellende GRIMME-­Niederlassung in China sowie in den wichtigsten Märkten weltweit verteilte Sales- und Servicestandorte. Mit über 150 Maschinentypen aus den Bereichen Kartoffel-, Rüben- und Gemüsetechnik bietet die GRIMME-Gruppe das mit Abstand breiteste und umfangreichste Produktprogramm in diesen Segmenten an. Die Maschinen werden in über 120 Ländern der Welt größtenteils über den Fachhandel vertrieben. Unterstützung erhalten die GRIMME-­Partner sowohl durch Werksbeauftragte des Vertriebs als auch im Aftersales durch 40 Servicetechniker sowie Produktmanagern Aftersales, welche bei Fragen rund um Service und Ersatzteilvertrieb beratend zur Seite stehen. Neben innovativen Maschinen verfügt GRIMME über ein umfangreiches Serviceportfolio. Dieses umfasst neben den klassischen Angeboten, wie einem umfangreichen Schulungsprogramm in der GRIMME Academy sowie auf dem Feld im Praxiseinsatz, einem 24/7-Telefonsupport, Nacherntechecks oder Ersteinsatzbetreuung auch digitale Services wie das Händlerportal GRIMME Connect, das Endkundenportal myGRIMME oder den GRIMME eigenen Webshop für GRIMME-Original-Teile. Bei der stetig wachsenden Globalisierung und dem somit größer werdenden Wettbewerbsdruck, ist ein erstklassiger auf den Kunden zugeschnittener Service für GRIMME unabdingbar. Die hochkomplexen Investitionsgüter aus dem Hause GRIMME arbeiten zumeist im harten Feldeinsatz auf teils steinigen, teils sandigen Böden. Steinige Böden können dabei zu unvorhergesehenen Ausfällen führen, sandige Böden fördern den Komponentenverschleiß. Erschwerend kommt hinzu, dass die Maschinen nur in einem begrenzten Zeitfenster von ca. drei Monaten zum Einsatz kommen. Die Schlussfolgerung für den Nutzer der Maschine ist, dass in dieser Zeit jeder Maschinenausfall Geld kostet und die Anforderungen an die Aftersales-Abteilung der Firma GRIMME und ihrer Partner entsprechend hoch sind. Durch das zuvor beschriebene Arbeitsumfeld ist ein gewisser Verschleiß unvermeidbar, der im schlimmsten Fall zum Stillstand der Maschine führt. In diesen Situationen gilt es für die Servicetechniker von GRIMME und/oder den Partnern, schnell Hilfe zu leisten und das Investitionsgut wieder in Stand zu setzen. Um die Stillstandzeiten möglichst gering zu halten, ist eine kontinuierliche Wartung von hoher Bedeutung. Im besten Fall lässt sich hierdurch ein Stillstand gänzlich vermeiden.

112

P. Sivasothy et al.

Zum Ausbau und Absicherung höchster technischer Verfügbarkeit der im Einsatz befindlichen Maschinen sollen verfügbarkeitsorientierte Geschäftsmodelle entwickelt werden. Um dies zu erreichen, müssen die Produkte aus dem Hause GRIMME Daten erfassen können und die Fähigkeit zur Kommunikation erhalten. Auf der Basis von Felddaten w ­ erden prädiktive Wartung und Instandhaltung zum optimalen Zeitpunkt angestoßen. Diese Abläufe sind das Ergebnis einer unternehmensindividuellen Integration existierender Prinzipien, Methoden und Werkzeuge der Dienstleistungsproduktion. Für GRIMME sind die Erkenntnisse über das Zusammenwirken der aus dem Feld erhobenen Daten und das Ableiten der notwendigen Maßnahmen von höchster Bedeutung. So lassen sich Ausfallkosten für die Kunden möglichst geringhalten und einen Wettbewerbsvorteil für GRIMME generieren.

6.2

 pezifische Konzeption eines verfügbarkeitsorientierten S Geschäftsmodells bei der GRIMME Landmaschinenfabrik GmbH & Co. KG

Zur Konzeption des verfügbarkeitsorientierten Geschäftsmodells (vGM) innerhalb des Anwendungsfalls GRIMME wurde das in Kap. 3 vorgestellte Konzept durchlaufen. Der Prozess zur Entwicklung eines vGM wurde aufgrund technologischer Neuerung seitens verschiedener Partner wie Sensorhersteller, Telekommunikationsunternehmen, etc. initiiert. Der Prozess wird also technologiegetrieben durchlaufen und die Phasen 1 und 2 entfallen. Die erzielten Ergebnisse werden nachfolgend dargestellt. Phase 3 – Beschreibung des Anwendungsfalls In dieser Phase wurde zuerst der Use-Case textuell in einem Template beschrieben. Der Aufbau des Templates wurde innerhalb eines Workshops mit den Projektpartnern erarbeitet. Das Template wird im Anhang dargestellt. Die Kurzfassung des Use-Cases ist folgende: Produkt: Aufnahmeband des Kartoffelvollernters Varitron 470 (siehe Abb. 6.1) Produktfunktion: Erntegut wird vom Aufnahmeband aufgenommen, vorgesiebt und zum nächsten Band transportiert. Use-Case: Sensoren überwachen kontinuierlich das Aufnahmeband und relevante Komponenten mit dem Ziel, einen möglichen Ausfall im Voraus zu erkennen. Genauso ist zu untersuchen, welche weiteren Daten für eine Bestimmung der Ausfallwahrscheinlichkeit benötigt werden (PLC-Daten, Maschinendaten, Daten aus Lebensdaueruntersuchungen, etc.). Aus den Daten sollen zudem spezifische Handlungsempfehlungen für den Nutzer abgleitet werden. Die gewonnen Daten werden auch dem eWN zur Verfügung gestellt, um Verbesserungen an deren Produkten vorzunehmen. Ziel: Ein anstehender Ausfall des Aufnahmebandes ist frühzeitig zu erkennen. Das Aufnahmeband soll dann entweder nachbestellt oder nachproduziert (je nach Lagerbestand) und der Serviceprozess zum Einbau des Bandes angestoßen werden. Mit dieser Use-Case-Beschreibung kann die nächste Phase zur Analyse bestehender Kundenanforderungen initiiert werden.

6  Anwendungsfall GRIMME

113

Abb. 6.1  Varitron 470 der GRIMME Landmaschinenfabrik GmbH & Co. KG

Phase 4 – Bedürfnisanalyse und Lösungsideen Auf Basis dieses Use-Cases wurden die verschiedenen Kundengruppe offengelegt, die bei GRIMME primär adressiert werden. GRIMME verkauft selbst nur wenig PSS direkt an Kunden, sondern verkauft Sachprodukte und Know-how an Premium-Servicepartner. Der Kunde steht somit mit dem Premium-Servicepartner in direktem Kontakt. Die unterschiedlichen Kundengruppen reichen von kleineren Landwirten über Großbetriebe und Lohnunternehmer bis hin zu Rodegemeinschaften. Als Persona wurde eine fiktive Person der Kundengruppe Großbetriebe/Lohnunternehmen ausgewählt. Im Unterschied zum kleinen Landwirt würde ein Großbetrieb/Lohnunternehmen früher in eine solche Lösung investieren. Zudem sind deren Erntemengen und Erntezeiträume größer, sodass eine technische Lösung eher realisiert werden kann. Auf Basis der gewählten Kundengruppe konnte eine Customer Journey durchgeführt werden. Ziel war dabei zu validieren, dass sich der aus technologischer Sicht resultierende Use-Case in den Bedürfnissen der Kunden (Großunternehmen) widerspiegelt. Zudem können bei der Durchführung auch weitere innovative PSS-Ideen resultieren. Zur Durchführung der Customer Journey wurde ein typischer Prozess der Kundengruppe „Ein Tag während der Ernte“ abgebildet. Der Prozess umfasst die Prozessschritte Vorbereitung, Fahren, Roden und Abbunkern sowie Maschine säubern und Maschinenhof. Für jeden Prozessschritt wurden die Bedürfnisse des Kunden aufgenommen. Realisiert wurde dies unter anderem in Zusammenarbeit mit der Vertriebsabteilung von GRIMME. Nachdem die Bedürfnisse aufgenommen wurden, wurden gemeinsam Serviceideen entwickelt, mit denen die Bedürfnisse befriedigt werden können. Für einzelne Ideen konnten erste Systemanforderungen identifiziert und aufgenommen werden. Die Customer Journey wird in Abb. 6.2 visualisiert. In den Bedürfnissen des Anwenders im Prozessschritt Roden findet sich eindeutig das Bedürfnis nach Kenntnis über Änderungen vom Betriebszustand der Maschine bzw. ausfallkritischer Komponenten, wie beispielsweise die Kartoffelförderbänder. Somit wurde dieser Use-Case weiterverfolgt und Phase 4 abgeschlossen. Phase 5 – Detaillierung des Geschäftsmodells Die Inhalte des Template zur Use-Case-Beschreibung beinhalten bereits erste Informationen zur Geschäftsmodellidee. Die Inhalte wurden in dieser Phase in den erweiterten BMC eingetragen und in mehreren Workshops mit den Projektpartnern hinsichtlich des adres-

114

P. Sivasothy et al.

Abb. 6.2  Customer Journey im Use-Case GRIMME

sierten Use-Cases erweitert. Es resultierte der in der nachfolgenden Abb. 6.3 dargestellte BMC und Phase 5 konnte abgeschlossen werden. Phase 6 – Planung der Partner, Ressourcen, Interaktionen In dieser Phase wurde das erweiterte Wertschöpfungsnetzwerk mit den Schlüsselpartnern und Schlüsselressourcen aus dem BMC in einem Workshop erstellt. Wie in Kap. 3 beschrieben, kann mit Hilfe der Aufzeichnung des Wertschöpfungsnetzwerks die Verbindung zwischen den verschiedenen Partnern und Ressourcen zur Realisierung des Use-­Cases in verständlicher Form visualisiert werden. Wichtige Partner und Ressourcen in diesem Use-Case sind: • • • • •

GRIMME und Premium-Servicepartner (als PSS-Anbieter) landwirtschaftlicher Großbetrieb (als Kunde) Komponentenhersteller/-zulieferer Cloud-Betreiber und Zulieferer für das Informationsmanagement Zulieferer für Datenanalysen

Zwischen den jeweiligen Partnern und Ressourcen wurden die verschiedenen Informations-, Geld- und Warenflüsse eingetragen. Das erweiterte Wertschöpfungsnetzwerk des Use-Cases wird in der nachfolgenden Abb. 6.4 dargestellt.

6  Anwendungsfall GRIMME

Abb. 6.3  Business Model Canvas im Use-Case GRIMME

115

116

P. Sivasothy et al.

Abb. 6.4  Erweitertes Wertschöpfungsnetzwerk im Use-Case GRIMME

Damit konnte Phase 6 abgeschlossen und die Ableitung von Systemanforderungen für die technische Entwicklung in der nächsten Phase initiiert werden. Phase 7 – Planung der Umsetzung Zur Planung der Umsetzung und Weitergabe der ersten technischen Anforderungen an die Entwicklung wurde eine Prozessanalyse durchgeführt. Dabei wurde der Prozess der Customer Journey aus Phase 4 genutzt und an den Use-Case-Ablauf angepasst. Die Vorgänge des Use-Cases setzten sich wie folgt zusammen. 1. Roden vorbereiten 2. Rodevorgang starten (Roden) 3. Kritischer Verschleißzustand erreicht 4. Maschine auf dem Feld vorreinigen 5. Ernteeinsatz abschließen

6  Anwendungsfall GRIMME

117

Für jeden Vorgang wurden Systemanforderungen erhoben, die umgesetzt werden müssen, um den Use-Case zu realisieren. Die Prozessanalyse für die Phase „Roden“ mit den definierten Anforderungen wird in Abb. 6.5 dargestellt. Anschließend an die Prozessanalyse wurde der Masterplan of Action entwickelt, um die Einführung des entwickelten vGM zu planen. Auf Basis der definierten Ist- und Soll-Situation auf unterschiedlichen Ebenen wurden Handlungsfelder identifiziert und dokumentiert. Handlungsfelder auf der Ebene Unternehmensstrategie sind beispielsweise: Entwicklung des Zukunftsbildes eines „Full-Service-Anbieters“ • Entwicklung des Geschäftsmodells und der Vermarktungsstrategie • Identifikation und Planung einer Pilotierung mit ausgewähltem Investitionsgut sowie in ausgewähltem Markt • Evaluierung des Geschäftsmodells und weitere Skalierung (Investitionsgüter, Baureihen, Märkte, etc.) Aufbau eines Wertschöpfungsnetzwerkes • Identifikation fehlender Kompetenzen und notwendiger Partner für ein vGM • Strategische Kooperationen bilden • Definition der Ablauforganisation im Wertschöpfungsnetzwerk Die weiteren Ebenen Prozesse, Kultur und Kompetenzen sowie deren jeweils identifizierten Handlungsfelder finden sich in der nachfolgenden Abb. 6.6.

Abb. 6.5  Prozessanalyse für die Phase „Roden“ im Use-Case GRIMME

118

P. Sivasothy et al.

Abb. 6.6  Masterplan of Action für den Use-Case GRIMME

Mit den Ergebnissen des Konzepts zur Entwicklung verfügbarkeitsorientierter Geschäftsmodelle konnte die technische Entwicklung der einzelnen Use-Case-Bestandteile initiiert werden. Der Verlauf der technischen Entwicklung wird in den nachfolgenden Kapiteln adressiert.

6.3

 ntwicklung intelligenter, kommunikationsfähiger E Komponenten im Use-Case GRIMME

In diesen Kapitel erfolgt die spezifische Entwicklung der notwendigen Komponenten zur Realisierung des in den Abschn. 6.1 und 6.2 dargestellten Use-Case GRIMME.

6  Anwendungsfall GRIMME

119

6.3.1 Identifikation servicerelevanter Komponenten In diesem Kapitel wird die Vorgehensweise zur Analyse der Ausfallmechanismen, wie in Abschn. 4.2 beschrieben, angewendet. Bei der Firma GRIMME wurden intern alle Maschinenausfälle der letzten Jahre anhand der Nichtübereinstimmungsberichte analysiert. Dabei hat sich das Aufnahmeband der Kartoffelvollerntemaschine Varitron 470 als fehleranfällig gezeigt und wurde daher für weitere Untersuchungen ausgewählt. Die Maschine und das Aufnahmeband wurden in Abschn. 6.2 präsentiert. Dieses Aufnahmeband dient der Aufnahme von Erde und des sich darin befindenden Ernteguts. Sechs parallel verlaufende Riemen lagern die Siebstäbe, durch die die Kartoffeln von der Erde getrennt werden. Das Aufnahmeband ist im Aufnahmekanal eingebaut und wird in Abb. 6.7 dargestellt. Diese Abbildung zeigt den genauen Aufbau des Bandes. Um ein Überwachungskonzept für das Aufnahmeband zu erstellen, ist die Kenntnis über Systemverhalten und die Ausfallmechanismen notwendig.

6.3.2 Analyse der Ausfallmechanismen Die Riemen werden durch Schlösser geschlossen. Sowohl die Stangen als auch die Schlösser sind aus ferromagnetischem Metall gefertigt. Um die Versagensmechanismen dieses Bauteils zu bestimmen, wurden Experimente in Prüfstandsversuchen durchgeführt. Die Hauptausfallmechanismen des Riemens sind Risse im Schlossbereich. Für die Experimente werden zehn Riemenstücke mit einer Länge von 250 mm inklusive des Schlosses getestet. Die Prüfungen werden an einer hydraulischen Pulsationszugmaschine durchgeführt. Der Prüfling wird in den Prüfstand gespannt und durch eine Kraft in eine Richtung geprüft. Im ersten Test unter 8,7 kN Belastung und 1 Million Dehnungsund Entlastungszyklen wurde die Dehnung des Riemens von 5 mm festgestellt. Allerdings waren keine Ausfälle und Risse in der Struktur des Riemens ersichtlich. Der Querschnitt

Abb. 6.7  Aufbau des Aufnahmebandes des Varitron 470

120

P. Sivasothy et al.

des Bandes wurde in zwei Teile geteilt. Anschließend wurde der Riemen unter höherer Belastung getestet, woraufhin Risse im Schlossbereich resultierten. Die Experimente wurden mit zwei Belastungszyklen durchgeführt. Der erste war mit kontinuierlicher sinusförmiger Belastung und der zweite mit nicht-kontinuierlicher sinusförmiger Belastung mit Haltezeit an der Stelle mit der höchsten Belastung. In diesem Zyklus spannt die hydraulische Pulsationsmaschine den Riemen bis zur maximalen Belastung des Experiments und hält die Kraft für zehn Sekunden. Es ließ sich feststellen, dass die Belastungsart ein unterschiedliches Verhalten der Dehnung verursacht. Bei einem sinusförmigen Lastzyklus ist die Dehnung langsamer im Vergleich zu einem nicht kontinuierlichen Lastzyklus mit einer Haltezeit von zehn Sekunden in dem Moment, in dem die höchste Kraft den Riemen belastet. In Abb. 6.8 sind die Ergebnisse von acht Experimenten dargestellt. Als Ergebnis gab es nach jedem Experiment Risse im Riemen. Die Ergebnisse zeigten, dass die Dehnung des Riemens mit der Belastung langsam zunimmt. Die Dehnung kann dementsprechend überwacht und vorhergesagt werden. Wie in Abb. 6.8 dargestellt, sind die einzigen Informationen, die durch die Voruntersuchungen über das betriebsrelevante Bauteil gewonnen wurden, der Dehnungsverlauf in Abhängigkeit von der Anzahl der gleichbleibenden Lastzyklen für einige wenige diskrete Laststufen. Da die Gesamtlast selten genau auf einer dieser Laststufen liegt, müssen diese Informationen verallgemeinert werden. Zuerst wird die maximale Anzahl der Lastzyklen für jede Last ermittelt. Wie in Abb. 6.8 a) zu sehen ist, zeigt die maximale Anzahl der Lastzyklen in Abhängigkeit vom Lastpegel ein exponentielles Verhalten. Experimentelle Tests haben gezeigt, dass jede höhere Kraft als 19,5 kN den Antriebsriemen sofort zerstört. Die gemessenen Dehnungsverläufe sind für jede Belastungsstufe unterschiedlich. Um das Dehnungsverhalten für jede Belastung zu modellieren, müssen diese ebenfalls verallgemeinert werden. Daher scheint die maximale Anzahl der Lastwechsel ein geeigneter Standardisierungsfaktor zu sein. Wie in Abb. 6.8 b) zu sehen ist, sind die standardisierten Dehnungsverläufe recht ähnlich und können daher durch ein Polynom achter Ordnung beschrieben werden.

6.3.3 Entwicklung von Überwachungskonzepten Verfügbarkeitsorientierte Geschäftsmodelle sehen im Kern eine Verschiebung der Verantwortlichkeit für den störungsfreien Betrieb vom Kunden zum Anbieter und dessen Partner vor. Die technische Herausforderung liegt dabei vor allem in der Maximierung der Maschinenverfügbarkeit. Hierzu stellt der Anbieter seinen Partnern möglichst alle Maschinendaten zur Verfügung. Bei diesen Daten handelt es sich um herkömmliche Betriebsdaten, welche die Beurteilung der realen Abweichung vom gewünschten Betriebspunkt zulassen sollen. Da im Rahmen von verfügbarkeitsorientierten Geschäftsmodellen vielmehr die Lebensdauer bzw. der Verschleißzustand der servicerelevanten Komponenten im Fokus stehen und

6  Anwendungsfall GRIMME

121

Abb. 6.8  a) Maximale Anzahl der Lastzyklen in Abhängigkeit vom Lastniveau, b) Bandlängung

weniger der eigentliche Betrieb, können derartige Verfügbarkeitsinformationen nicht mühelos aus den üblichen Betriebsdaten abgeleitet werden. Daher ist die Entwicklung und Umsetzung von verfügbarkeitsorientierten Überwachungskonzepten ein technischer Grundstein für die Realisierung von derartigen Geschäftsmodellen. Dabei ist das praxisnahe Verständnis für die Bedeutung der Verfügbarkeit von zentraler Wichtigkeit.

122

P. Sivasothy et al.

Im Folgenden soll ein verfügbarkeitsorientiertes Überwachungskonzept für den Use-­ Case GRIMME entwickelt werden. Im Fokus steht dabei die Aufnahmeeinheit des Kartoffelvollernters Varitron 470. Die landwirtschaftliche Aufgabe des Kartoffelvollernters ist die teilautomatisierte Kartoffelernte. Dabei werden die Kartoffeldämme gesiebt, die Kartoffeln aufgenommen und innerhalb des Roders gesäubert, sortiert und anschließend im Tank gelagert. Der Transport der Kartoffeln findet dabei auf einem metallenen Förderband statt. Das Band besteht aus einer Vielzahl von Metallstäben, die orthogonal zur Fahrtrichtung angebracht sind. An beiden Enden ist jeder Stab an einem Riemen befestigt. Dieser Riemen besteht aus einem mehrlagigen Verbundwerkstoff. Der Riemen wird durch einen Hydraulikmotor angetrieben und in Bewegung versetzt. Auf diese Weise fördern die Metallstäbe die Kartoffeln in das Innere der Maschine. Durch das rhythmische Rütteln der Stäbe werden die Kartoffeln von loser Erde befreit. Aus den historischen Aufzeichnungen bei GRIMME geht hervor, dass der die Aufnahmeeinheit antreibende Riemen die servicerelevante Komponente in dem vorliegenden komplexen mechanischen System ist. Es kommt häufig vor, dass der Riemen weit vor dem Ende seiner erwarteten Lebensdauer gewechselt wird. Der Grund hierfür sind die Folgen eines Komponentenversagens. Die rechtzeitige Ernte zum optimalen Zeitpunkt ist in der Landwirtschaft von essenzieller Bedeutung. Eine zu frühe oder zu späte Ernte beeinflusst die Qualität negativ. Auf Basis bewährter Messtechnik und seiner jahrzehntelangen Erfahrung versucht der landwirtschaftliche Großbetrieb, den optimalen Zeitpunkt für die Ernte zu wählen. Ist die Entscheidung einmal getroffen, so müssen die Erntearbeiten schnellstmöglich angegangen und abgeschlossen werden. Innerhalb dieser zwei bis drei Wochen sind Erntezeiten von 14 Stunden pro Tag keine Seltenheit, jede Arbeitsstunde ist damit von enormer Bedeutung. In der Praxis kommt es immer wieder zu einem Versagen des Antriebsriemens. Während der Ernte kann ein derartiges Versagen durch den Abriss des Riemens verheerende Folgen haben. Steht der mit Erde und Kartoffeln beladene Kartoffelvollernter inmitten des Ackerfeldes, meist ohne eine Mobilfunkverbindung und ohne eine geeignete Werkstatt in der Nähe, so bringt dies erhebliche zeitliche Verzögerungen bei der Ernte mit sich. Zunächst müssen Arbeitsmaterial und Ersatzteil zum defekten Roder transportiert werden. Qualifiziertes Personal muss dann das Maschineninnere von Erdmassen und defekten Maschinenteilen befreien. Anschließend sind die Wartungsarbeiten größtenteils manuell zu erledigen. Gerade unter dem Gesichtspunkt, dass ein plötzlicher Wetterumschwung das vorhandene Erntefenster reduzieren kann, erklärt diese Situation den saisonal wiederkehrenden Druck beim landwirtschaftlichen Großbetrieb. Wünschenswert ist also die frühzeitige Detektion des kritischen Zustandes, vor dem Riemenversagen. Wie zuvor beschrieben, ist hierfür die Identifikation einer physikalischen Größe erforderlich, die folgende beiden Bedingungen erfüllt: a. Die Messgröße sollte über die Lebensdauer der Komponenten variieren. Wichtig sind dabei, dass das Verhalten charakteristisch für verschiedene Abschnitte der Lebensdauer

6  Anwendungsfall GRIMME

123

ist bzw. sogenannte charakteristische Phasen existieren. Besonders gut geeignet sind physikalische Größen, die einen kontinuierlichen Verlauf über die Lebensdauer aufweisen. b. Die Messgröße sollte kostengünstig und robust messbar sein. Ist dies der Fall, so können im Folgenden handelsübliche Sensoren ausgewählt und eingesetzt werden. Sofern die direkte Messbarkeit der Größe nicht vorliegt, ist zu überlegen, inwiefern die physikalische Größe durch wesentlich einfacher messbare Größen approximiert werden kann. Falls dies ebenso nicht möglich ist, sind eventuell neue Sensoren für den vorliegenden Anwendungsfall zu entwickeln. Das Resultat der zuvor beschriebenen experimentellen Zugversuche ist die Erkenntnis, dass die Gesamtlänge des Antriebsriemens über die gesamte Lebensdauer stetig größer wird. Dabei weist der Riemen charakteristische Phasen auf. Insgesamt gibt es drei solcher Phasen [1]: 1. Die Einlaufphase: In der ersten Phase wächst die Länge des Riemens schnell. Die Längungsänderung weist jedoch einen degressiven Verlauf auf. Bei ca. 15 % der Lebensdauer mündet dieser Verlauf in einen linearen Bereich. 2. Die lineare Phase: Die Längungsänderung bleibt konstant. Gleiche, aufeinanderfolgende Belastungen auf den Riemen haben jeweils dieselbe zusätzliche Längung zur Folge. 3. Die Abrissphase: Die lineare Phase mündet in der Abrissphase. Die Längungsänderung pro zusätzlichen Lastzyklus steigt exponentiell an und endet im Komponentenversagen durch Abriss. Somit ist die Längungsänderung des Antriebsriemens eine geeignete physikalische Größe. Die Messung der Längungsänderung jedoch stellt messtechnisch eine Herausforderung dar. Hinzu kommt, dass Erfassung und Beobachtung von Verbundwerkstoffen aufgrund ihrer variantenreichen Zusammensetzung hochgradig schwierig sind. Der Riemen stützt in diskreten Abständen von 35 mm, 40 mm, 45 mm, 50 mm oder 55 mm die kartoffeltragenden Metallstäbe. Die messtechnische Erfassung oder Beobachtung von Metallkörpern und ihrer Bewegung ist eine vielfach gelöste Aufgabe. Da der Riemen also über die gesamte Länge mit äquidistant befestigten Metallstäben fest montiert ist, können diese als diskretisierende Stützpunkte des Riemens betrachtet werden. Das Auftragen aller Stabpositionen bildet also in Summe die Lage des gesamten Riemens ab. Anstelle der Gesamtlängung des Bandes kann also der Abstand zwischen den Metallstäben beobachtet und daraus eine Aussage über die Gesamtlänge getroffen werden. Dies führt in Kombination mit der experimentell ermittelten Zuordnung der Längung zur Lebensdauer zu einem geeigneten und kostengünstigen Überwachungskonzept für den antreibenden Riemen des Kartoffelvollernters Varitron 470 von GRIMME.

124

P. Sivasothy et al.

6.3.4 Sensorentwicklung Für die Überwachung des Bandausfalls wurden zwei Sensorkonzepte entwickelt, die im Nachfolgenden vorgestellt werden. Das erste berührungslose Sensorkonzept wurde auf Basis des AMR-Effekts von der Sensitec GmbH umgesetzt. Die Sensitec GmbH ist auf Sensoranwendungen mit magnetoresistiven Sensoren spezialisiert. Das zweite Sensorkonzept wurde von der Schaeffler AG entwickelt und wird im Anschluss an Sensorkonzept 1 erläutert.

6.3.4.1 Berührungsloses Sensorkonzept durch AMR-Sensor Der MR-Effekt Der Magnetoresistive Effekt, kurz MR-Effekt, ist seit ungefähr 150 Jahren bekannt. Die sensorische Nutzung konnte jedoch erst vor ca. 30 Jahren mit der Dünnschichttechnik vorangebracht werden. MR-Sensoren erobern seither ständig neue Applikationsfelder in der Magnetfeldmessung, als elektronischer Kompass, zur Weg- und Winkelmessung oder auch als Stromsensor. Der Begriff MR-Sensor ist ein Sammelbegriff für Sensoren, die auf verschiedenen physikalischen Prinzipien basieren. Alle MR-Prinzipien haben gemeinsam, dass sich der elektrische Widerstand in Abhängigkeit von einem Magnetfeld ändert. Durch entsprechende Anordnung der Strukturen können sehr unterschiedliche Sensoren realisiert werden, um beispielsweise einen Magnetfeldwinkel, eine Magnetfeldstärke oder auch einen Magnetfeldgradienten zu erfassen. Der Anisotrope MagnetoResistive Effekt (AMR) wurde 1857 von William Thomson entdeckt und tritt in ferromagnetischen Materialien auf. Deren spezifischer Widerstand ändert sich mit dem Winkel zwischen Magnetfeldrichtung im Material und der Stromrichtung im Material, siehe Abb. 6.9. Die Änderung des Widerstands beträgt wenige Prozent und ist schon bei schwachen Feldern nutzbar. 1975 wurde der Tunnel MagnetoResistive Effekt (TMR) von Michel Jullière entdeckt. Hier sind zwei ferromagnetische Schichten mit einem sehr dünnen Isolator (ca. 1 nm) getrennt und der Tunnelwiderstand durch diesen Isolator ändert sich in Abhängigkeit von dem

Abb. 6.9  Änderung des Widerstandes (R) in einer AMR-Schicht in einem Magnetfeld (H) als Funktion vom Winkel (α) zwischen Strom (I) und Magnetisierung (M)

6  Anwendungsfall GRIMME

125

Winkel der Magnetisierungen in den zwei Schichten. Bei diesem Effekt wurden schon Widerstandsänderungen von bis zu 1000 % erreicht, dies aber bei Temperaturen von 4,2 K. Bei Raumtemperatur wurden Widerstandsänderungen im Bereich von 40 % bis 200 % erzielt. Der Giant MagnetoResistive Effekt (GMR) wurde 1988 von Albert Fert und Peter Grünberg entdeckt. 2007 wurden sie dafür mit dem Nobelpreis für Physik ausgezeichnet. Hierbei sind zwei ferromagnetische Schichten durch einen dünnen nichtmagnetischen Leiter getrennt. Der Widerstand des Gesamtschichtpakets ändert sich in Abhängigkeit von dem Winkel der Magnetisierungen in den zwei ferromagnetischen Schichten. Die Widerstandsänderung kann bis zu 50 % betragen und ist nicht abhängig von der Stromrichtung. Von allen bekannten physikalischen Effekten, die mittels Magnetismus in einem Festkörper eine elektrische Eigenschaft ändern, muss die MR-Technologie besonders hervorgehoben werden. Der MR-Effekt ermöglicht die Erfassung von schwachen Magnetfeldern und liefert dabei ein Signal mit einem sehr guten Signal-Rausch-Verhältnis. Vorteile der MR-Technologie • Hohe Genauigkeit MR-Sensoren haben prinzipiell bedingt eine geringe Hysterese und eine hohe Linearität. • Hohe Auflösung MR-Sensoren bieten eine sehr hohe Auflösung. Dies ist wichtig bei Anwendungen, die eine hohe Qualität der Regelung verlangen, wie zum Beispiel Encoder für Direktantriebe. • Dynamik MR-Sensoren haben eine sehr hohe Bandbreite und können Magnetfelder mit Frequenzen bis in den Megahertz-Bereich erfassen. Dadurch können Anwendungen, die eine kurze Reaktionszeit verlangen, z. B. Hochgeschwindigkeitsspindeln oder Schalter, gut abgedeckt werden. • Hohe Zuverlässigkeit Das berührungslose Messprinzip und die Festkörpereigenschaften der MR-Sensoren machen sie eigensicher. Dies wird durch entsprechende Qualifikationstests nach industriellen und automobilen Standards untermauert. • Verschleißfreiheit Die Messung ist berührungslos und somit verschleißfrei. Dadurch wird eine lange Lebensdauer ohne mechanischen Verschleiß, wie zum Beispiel bei einem Potenziometer, ermöglicht. • Hohe Empfindlichkeit Die Sensitivität von MR-Sensoren ist bis zu 50-mal besser als bei den anderen bekannten magnetischen Festkörper-Effekten. MR-Sensoren werden bei Kompassanwendungen und für zerstörungsfreie Materialprüfung eingesetzt. Bei beiden Anwendungen liegen sehr schwache Magnetfelder vor. • Robustheit MR-Sensoren sind prinzipiell unempfindlich gegen sehr hohe oder niedrige Temperaturen, Öl, Verschmutzungen oder mechanische Belastungen durch Stöße oder Vibration.

126

P. Sivasothy et al.

Sie können auch in Strahlung oder im Vakuum eingesetzt werden. Beispiele sind MR-Sensoren auf dem Mars bei −120 °C oder in einem Ölbohrloch bei +200 °C. • Energie-Effizienz Für batteriebetriebene Anwendungen können Sensoren mit einem hohen Widerstand verwendet werden, somit ist eine sehr geringe Stromaufnahme gewährleistet. • Galvanische Trennung Das berührungslose Messprinzip von MR-Sensoren ist besonders gut geeignet für Anwendungen, die eine sichere elektrische Trennung verlangen. • Integrationsfähigkeit MR-Sensoren sind von Hause aus klein und durch ihre hohe Empfindlichkeit in der Lage, mechanisch bedingte Abstände und Toleranzen zur Maßverkörperung zu überbrücken. Dies macht sie besonders integrationsfähig für Konstruktionen, bei denen wenig Bauraum zur Verfügung steht, Toleranzen unvermeidbar sind und der Montageaufwand minimal sein muss. Bei Sensitec werden AMR- und GMR-Sensoren in Serie gefertigt. TMR-Sensoren gehen demnächst in Serie. Der im Projekt verwendete Sensor beruht auf dem AMR-Effekt. Magnetische Eigenschaften von Materialien Es existiert ein sehr einfaches Modell für Magnetismus innerhalb eines Materials. Im Material existieren viele kleine Dipole, auch Elementarmagnete genannt, die ohne eine äußere Einwirkung in allen Richtung gleichverteilt vorkommen, somit ist das Material nach außen auch nicht magnetisch. Durch ein äußeres Magnetfeld werden die Elementarmagnete beeinflusst. Je nach ihrer Reaktion werden die Materialien in fünf verschiedene magnetische Gruppen eingeteilt. • Ferromagnetismus In dieser Gruppe werden durch ein äußeres Magnetfeld alle Elementarmagnete in Richtung des Magnetfeldes ausgerichtet. Das Material selbst wirkt dann wie ein Magnet und bildet sein eigenes Magnetfeld aus. Für den Beobachter wird dann eine Überlagerung des angelegten Feldes und des vom Material erzeugten Feldes erkennbar. Je nach Material bleibt diese innere Ordnung auch nach Entfernen des äußeren Feldes erhalten. Diese Eigenschaft wird als die Remanenz eines Materials bezeichnet. Ist dieser Wert hoch, spricht man von einem hartmagnetischen Material oder auch einfach Magnet. Wenn der Wert klein ist, ist dies ein weichmagnetisches Material und kann beispielsweise als Schirmung gegen magnetische Felder eingesetzt werden. Eisen gehört zu den weichmagnetischen Materialien. • Antiferromagnetismus Im Gegensatz zum Ferromagnetismus richten sich hier die Elementarmagnete nicht gleich aus, sondern in entgegengesetzten Reihen. Von außen betrachtet ist das Material unmagnetisch.

6  Anwendungsfall GRIMME

127

• Ferrimagnetismus Hier sind die Elementarmagnete ausgerichtet wie beim Antiferromagnetismus, allerdings ist die eine Richtung schwächer ausgeprägt als die andere, somit ist das Material von außen betrachtet magnetisch nicht neutral. • Diamagnetismus Ein äußeres Magnetfeld erzeugt in solchen Materialien ein inneres Magnetfeld, das entgegengesetzt dem äußeren Magnetfeld gerichtet ist und dieses somit abschwächt. Dieser Effekt tritt in fast allen Materialien auf, wird aber meist von einem anderen Effekt überlagert. • Paramagnetismus Die Ausrichtung der Elementarmagnete folgt dem äußeren Magnetfeld und es kommt in Summe zu einer leichten Verstärkung des Feldes. Der Effekt ist in seiner Auswirkung deutlich geringer als der Ferromagnetismus. Nach Entfernen des äußeren Feldes wird durch thermische Fluktuation die innere Ordnung wieder komplett aufgelöst. Für die Auslegung von magnetischen Sensorsystemen ist gerade die erste Gruppe der ferromagnetischen Materialien wichtig. Der MR-Sensor selbst gehört ebenfalls in diese Gruppe. Alle Materialien dieser Gruppe sind Metalle, typischerweise auch als ferromagnetische Metalle bezeichnet. Diese behalten, nachdem sie einem Magnetfeld ausgesetzt waren, einen Teil der Magnetisierung, die sich im Inneren eingestellt hatte. In Abhängigkeit von dem eingespeicherten Feld spricht man von weichmagnetischen und hartmagnetischen Metallen. Eine klare Grenze in Prozent lässt sich hier nicht ziehen. Im mittleren Bereich entscheidet immer die geplante Anwendung mit ihren jeweiligen Randbedingungen, ob das Material geeignet ist. Im oberen und unteren Bereich lassen sich eindeutige Materialien gruppieren. Als hartmagnetisch oder auch Permanentmagnete werden die Materialien bezeichnet, die sich im oberen Bereich befinden. Im unteren Bereich befinden sich die weichmagnetischen Materialien. Diese werden zur Abschirmung, Führung und auch Verstärkung von magnetischen Feldern verwendet. Nachfolgend ist in Abb. 6.10 dargestellt, wie sich der Magnetfeldverlauf an einem Magneten durch einen runden Eisenstab verändert. Eisen gehört zu den ferromagnetischen Materialien mit einer sehr hohen Änderung des umgebenden Magnetfeldes. Es zeigt sich deutlich, dass die Feldlinien durch den Eisenstab stark verzerrt und in diesen hineingezogen werden. Das Verhalten der Feldlinien lässt sich auch mit Hilfe eines Widerstandes erklären. In Luft ist der magnetische Widerstand relativ hoch, im Eisen dagegen sehr klein. Somit ist für die Feldlinie ein längerer Weg, der dafür durch den Eisenstab geht, energetisch günstiger. Physikalisch ist diese Beschreibung nicht exakt richtig, veranschaulicht aber annähernd das Modell. Entwicklung Sensor Die in den vorangegangenen Kapiteln durchgeführten Beschreibungen der ausfallenden Komponente und des Ausfallmechanismus sind der Startpunkt für die Sensorentwicklung.

128

P. Sivasothy et al.

Abb. 6.10  Feldverlauf an einem Magneten, a) an Luft, b) mit Eisenstab davor

Die Stäbe und auch das Schloss des Aufnahmebandes im Kartoffelvollernter bestehen aus einem Stahl mit guten weichmagnetischen Eigenschaften. Dadurch ist die Grundlage gegeben, ein berührungsloses Messsystem auf Grundlage der MR-Sensorik zu entwickeln. Wie in Abb. 6.10 schon dargestellt, verzerrt ein Eisenstab einen homogenen Magnetfeldverlauf. Für die Entwicklung des Sensorsystems muss eine geeignete Kombination aus einem AMR-Sensor und einem Magneten gefunden werden. Der Magnet dient der Erzeugung des Magnetfeldes in dem Bereich, in dem die Messung erfolgen soll. Theoretisch kann ein solches Feld auch mit Hilfe einer Spule erzeugt werden. Diese benötigt aber zur Erzeugung der gleichen Feldstärke wie ein Magnet mehr Bauraum und dazu auch Strom, der im Bereich von einigen Ampere bis zu einigen hundert Ampere liegen kann. Der Magnet ist somit meist auf Grund von Bauraum und Energieverbrauch zu bevorzugen. Als Sensor kann hier ein AMR-Sensor mit einer Messbrücke zur Feldmessung verwendet werden. Die Kennlinie und somit der mögliche Messbereich des Sensors ist durch einen Magneten einstellbar. Dies hat auch den Vorteil, dass eine große magnetische Störung das System nicht verändern kann. Die Störung müsste so groß sein, dass der Magnet ummagnetisiert wird, was sehr unwahrscheinlich ist. Solche Felder entstehen zum Beispiel in einem MRT oder auch an Teilchenbeschleunigern. Somit wird sowohl für den AMR-Sensor als auch für die magnetische Anregung der Stäbe und des Schlosses am Band ein Magnet benötig. Ziel der Sensorentwicklung ist es, den Magneten so zu dimensionieren und den Sensor entsprechend zu platzieren, dass der Magnet beide Aufgaben parallel erfüllen kann. Die Umgebungsbedingungen im Aufnahmekanal sind schwer zu definieren, da eine direkte Beobachtung des Bandes während des Erntebetriebes aus Sicherheitsgründen nicht möglich ist. Im Projekt wurde bei einem Vollernter, der in einer Halle stand, die Bewegung des Aufnahmebandes unbelastet beobachtet. Hier wurde abgeschätzt, dass das Band um ±5  mm schwankt. Dies muss entsprechend für den zu erreichenden Arbeitsabstand des

6  Anwendungsfall GRIMME

129

Sensorsystems berücksichtigt werden. Zusätzlich sollten auch noch die Dicke des Gehäuses und der Luftabstand mit eingerechnet werden. Zusammenfassend ergab sich die Forderung, dass das Sensorsystem bis zu einem Abstand von 15 mm zwischen Magnet und Stab funktionieren soll. Aus vorherigen Projekten existierte schon ein Ansatz, wie Sensor und Magnet zueinander und zu den Stäben und der Bewegungsrichtung positioniert sein müssen. Im Vergleich sind die Dimensionen am Kartoffelvollernter deutlich größer. Bisher gab es einen Nennarbeitsabstand von 1–3 mm mit Toleranzen von ±0,1 mm bis ±1 mm. Um auf die geforderten großen Abstände und auch Toleranzen zu kommen wurde der Magnet mit 40 × 20 × 10 mm3 deutlich größer als bisher gewählt, der Magnetisierungsrichtung entlang der kurzen Achse. Als Material wurde Hartferrit genommen. Dies hat zwar von allen erhältlichen Magneten die geringste Remanenz, ist aber auch aus Kostengründen zu bevorzugen. Zusätzlich ist zu erwähnen, dass bei den hier notwendigen Ma­ gnetdimensionen die Handhabung anderer Materialien schwieriger ist (z. B. Verletzungsgefahr durch Quetschungen). Für die genaue Positionierung des Sensors auf dem Magneten wurde ein Labor-Aufbau erstellt. Hier ist auf einem Rad mit einem Durchmesser von 20 cm ein Stück Band mit Stäben und Schloss aufgebracht. An einer Halterung kann der Magnet eingespannt und im Arbeitsabstand von 0 mm bis 20 mm eingestellt werden. An diesem Aufbau wurden alle Versuchsmuster getestet, um sie untereinander vergleichen und die beste Konstellation Sensor zu Magnet bestimmen zu können. Das daraus resultierende Layout Magnet zu Sensor ist in Abb. 6.11 dargestellt. Dieser Aufbau hatte zwar im Vergleich bei kleinen Abständen nicht die höchste Signalamplitude geliefert, dafür waren die Signale bis zu einem Abstand von 17 mm gut messbar, während die anderen Konstellationen nicht die 15 mm erreicht hatten. Zusätzlich wird in der Skizze auch das Band mit den Stäben und ein Pfeil für die Bewegungsrichtung dargestellt. Das Größenverhältnis der einzelnen Bauteile zueinander ist beibehalten worden. Es wird hier ein Arbeitsabstand von 7,5 mm Magnet zu Band gezeigt.

Abb. 6.11  Aufbau Sensorchip und Magnet zueinander, sowie ein vereinfachter Querschnitt des Aufnahmebandes mit Bewegungsrichtung

130

P. Sivasothy et al.

Zur Konzeptbewertung wurde die Sensor-Magnet-Konfiguration nicht direkt in ein Gehäuse gebaut, um in der Maschine montiert zu werden, sondern wurde an dem Prüfstand der Technischen Universität Kaiserslautern (TUK) am Lehrstuhl für Maschinenelemente und Getriebetechnik (MEGT) verbaut. Für den Prüfstand wurde eine Verstärkerelektronik am Sensor angeschlossen. Bei den ersten Laborversuchen bei der Sensitec GmbH war dies noch nicht der Fall, um nur das Sensorsignal ohne sonstige Effekte bewerten zu können. Dies wurde durch eine Sensorversorgung über eine Batterie sowie ein kurzes Signalkabel direkt an eine hochauflösende Messkarte gewährleistet. Batterie und kurze Signalleitungen können bei dem Prüfstand eventuell noch realisiert werden, aber nicht mehr am Kartoffelvollernter. Somit wurde ab diesem Stadium für alle weiteren Messungen und Tests eine Verstärkerelektronik an den Sensor angeschlossen. Zusätzlich konnten an dem Prüfstand der TU Kaiserslautern Dauertests durchgeführt werden. Die gewonnenen Messwerte wurden zum Entwickeln des Algorithmus für den Bandverschleiß genutzt. Parallel zu den Tests wurde die Verstärkerelektronik für die Sensoranwendung angepasst. Bei der ersten Elektronikgeneration waren die Filter nicht explizit für die Anwendung im Kartoffelvollernter am Aufnahmeband ausgelegt, sondern für eine andere Prüfstandsanwendung im Automobilbereich mit ähnlichen Signalfrequenzen. Anschlüsse für einen Temperatursensor waren an der ersten Elektronik auch nicht vorhanden. Für die zweite Sensorgeneration wurde aus den Stababständen der verschiedenen Siebbänder und den möglichen Fahrgeschwindigkeiten des Kartoffelvollernters während der Ernte der abzudeckende Bereich der Signalfrequenz ermittelt. Die Abstände der Stäbe bei den Siebbändern liegen bei 28 mm, 35 mm, 40 mm, 45 mm, 50 mm und 55 mm. Die Fahrgeschwindigkeit liegt je nach Bodenbeschaffenheit zwischen 3 km/h und 8 km/h. Somit ergibt sich am Sensorausgang eine Signalfrequenz zwischen 15 Hz und 79 Hz. Entsprechend dieses Bereichs der Signalfrequenz wurden die Filter auf der Verstärkerelektronik angepasst. Ebenso sind Anschlüsse für einen Temperatursensor vorgesehen, der nahe am MR-Sensor mit im Gehäuse verbaut werden soll. Grundsätzlich stehen zwei Temperatursensoren zur Auswahl, ein PT100 und ein PT1000. Beim InnoServPro-Projektpartner ANEDO GmbH existiert eine Auswerteeinheit für einen PT100. Dabei muss keine Neuentwicklung, sondern lediglich eine Anpassung erfolgen. Somit legt man sich für den PT100 fest, gewählt wird der RTD Platin-­ Temperatursensor PT100 von Variohm EuroSensor. In der Verstärkerelektronik wird aus dem eigentlichen Sensorsignal, das zwischen −50 mV und +50 mV liegt, ein Signal erzeugt, das zwischen 0 V und 5 V liegt. 0 V am Ausgang des Sensorchips entsprechen dann 2,5 V am Ausgang der Verstärkerelektronik. Da die Verstärkerelektronik zwei Kanäle zur Verfügung hat, wurden auch zwei MR-­ Sensoren am Magneten verbaut. Beide Sensoren sitzen, wie in Abb. 6.11 gezeigt, auf dem Magneten, einer auf der Vorderseite, der andere auf der Rückseite. Neben einer höheren Stabilität des Systems und einer höheren Ausfallsicherheit durch Redundanz, wurde dies gewählt, um neben dem klassischen Ausfallmechanismus auch Gewaltschäden detektieren zu können.

6  Anwendungsfall GRIMME

131

Bei einem Gewaltschaden wird ein Stab verbogen und die Positionierung am Band ist dann ebenfalls verzogen. Da die zwei Sensoren einen Abstand von über 10 mm zueinander haben, würde eine solche Schräglage des Stabes sich in einem anderen Versatz der zwei Sensorsignale im Vergleich zu den anderen Stäben äußern. Ob diese theoretische Überlegung auch in der Praxis bestehen kann, müssen die Messungen und darauffolgenden Auswertungen zeigen. In den weiteren Beschreibungen wird von einem Sensorsystem gesprochen, dies ist dann die Kombination aus Magnet mit den zwei MR-Sensoren auf der Vorder- und Rückseite und der Verstärkerelektronik. Während des Projektes wurden zwei unterschiedliche Gehäuse für das Sensorsystem konstruiert. Das erste beruht auf einem Alugussgehäuse, das als Standardbauteil erhältlich ist. Bei diesem Gehäuse konnte nicht von einer langen Lebensdauer über mehrere Ernteperioden ausgegangen werden, es diente aber als erste schnelle Lösung für die Erntesaison in 2017. Das Gehäuse hatte in dem Bereich vor Magnet und Sensor eine Wandstärke von 0,5 mm ±0,1 mm. Dies ist nicht viel und wird voraussichtlich bei den rauen Umgebungsbedingungen schnell abgenutzt sein. In diesem Gehäuse war der Temperatursensor noch nicht integriert. An diesem Alugussgehäuse wurden die ersten Einbaupositionen rechts und links an der Außenwand des Aufnahmekanals getestet. Für den Einbau gab es keine Zeichnung, sondern es wurde direkt an der Maschine mit einem Mechaniker überlegt, wo der Sensor platziert werden kann. Die Halterung des Sensorsystems ist über Langlöcher flexibel gestaltet worden. Nach den ersten Wochen im Einsatz zeigte sich, dass die Sensorsysteme unterschiedlich zum Band montiert waren. Dies lag zum einen an der Signalamplitude, aber auch an dem mechanischen Verschleiß eines der beiden Sensorsysteme. Bei diesem war das Gehäuse vor dem Magneten nicht mehr vorhanden und die Signale lagen sehr hoch, bzw. sind auch teils in die Begrenzung des Verstärkers gelangt. Das andere Sensorsystem lieferte deutlich geringere Signale, teils auch zu gering, war aber mechanisch noch intakt. Es wurden daraufhin beide Sensorsysteme in ihrer Position korrigiert. Das eine mit größerem Abstand, das andere mit einem kleineren Abstand. Über einen Leerlauf in der Versuchshalle wurde überprüft, ob beide Sensorsysteme ungefähr die gleiche Signalam­ plitude liefern und somit beide den gleichen Abstand aufweisen. Für die zweite Gehäuse-Generation wurde ein Gehäuse aus dem Vollen gefräst. Die Halterung war im Gehäuse integriert und kein zusätzliches Bauteil. Die Wandstärke vor dem Magneten betrug bei diesem Gehäuse 2 mm. Der Temperatursensor war mit verbaut und wurde innerhalb des Gehäuses so nah wie möglich am Magneten positioniert. Vor Beginn der Erntesaison 2018 wurden die Sensorsysteme getauscht. Bei der Demontage der ersten Generation zeigt sich, dass bei beiden Gehäusen kein Aluminium mehr vor dem Magneten war, als Folge des starken Verschleißes. Da die MR-Sensoren aber relativ weit zurückgesetzt sind, wurden bis zum Ausbau von beiden Systemen Signale generiert. Die Montage der zweiten Generation sollte an der gleichen Position erfolgen wie für die erste Generation. Da das Lochraster der Langlöcher Generation 1 und Generation 2 nicht übereinstimmten musste pro Seite ein neues Befestigungsloch in die Außenwand

132

P. Sivasothy et al.

gebohrt werden. Auf Grundlage der Erfahrungen mit den ersten eingebauten Sensorsystemen wurde versucht, die Einbauposition der neuen Generation zu optimieren. Bei Stillstand des Bandes sollte ein Abstand von ~8 mm zwischen Gehäuse und Band vorliegen. An der rechten Außenwand (in Fahrtrichtung betrachtet) wurde gegenüber dem Sensorsystem eine Rolle befestigt, die eine gewisse Vorspannung auf das Band geben sollte bzw. auch den maximalen Abstand zwischen Band und Sensor fixierte. Die Rolle wurde nur auf der einen Seite eingebaut, um einen Vergleich zwischen den zwei Seiten ziehen zu können. Nach dem Einbau wurden wieder Leerlauftests gemacht, um die Signalhöhe auf beiden Seiten zu überprüfen und gleich einzustellen. Der Signalverlauf eines Sensors ist in Abb. 6.12 gezeigt. Die Messung ist nach der Montage beim letzten Leerlauftest aufgenommen worden. Zu sehen ist ein periodisches Signal, das um 2,5 V schwingt. Jeder Stab erzeugt eine Periode im Signalverlauf. Zählt man alle Maxima (Peak > 2,5 V), erhält man die Anzahl der Stäbe. Die Größenschwankung der Peaks wird durch die Vibration des Bandes, also die Änderung des Arbeitsabstandes Sensor zu Band (Stab) erzeugt. Bei 11,75 s und bei 14,45 s zeigt sich deutlich der charakteristische Signalverlauf des Schlosses. Dazwischen lassen sich die 87 Stäbe zählen. Inklusive des Schlosses und den zwei direkt benachbarten Stäben ergeben sich somit 90 Stäbe, was einem Band mit einer Stabteilung von 40 mm entspricht. Ein solches Band war während des Sensorumbaus und den Leerlauftests auf der Maschine montiert. Ausblick Auch wenn die ersten zwei Sensorgenerationen an der Maschine verbaut wurden und beide bis zur Demontage Sensorsignale geliefert haben, ist die Sensorentwicklung nicht abgeschlossen. Ein sehr großer Punkt, den es noch näher zu beleuchten gilt, ist die Einbausituation und der mechanische Verschleiß.

Abb. 6.12  Signalverlauf bei Leerlauf nach dem Umbau der Sensoren, die Maschine stand in einer Werkstatthalle

6  Anwendungsfall GRIMME

133

Um die Problematik der Einbausituation besser zu verstehen, wird im Folgenden der Antrieb des Aufnahmebandes nochmals beschrieben. Am obersten Punkt des Kanals ist eine Welle eingebaut, die mit einem Hydromotor angetrieben wird. Auf der Welle sind pro Aufnahmeband zwei Zahnräder montiert, die durch Eingriff zwischen die Stäbe das Aufnahmeband antreiben. Jede Teilung des Aufnahmebandes besitzt ihr eigenes Antriebszahnrad. Konstruktionsbedingt ist der Durchmesser der Zahnräder nicht identisch, sondern abhängig von der Bandteilung. Durch die verschiedenen Durchmesser ändert sich der Verlauf des Bandes in der Nähe des Antriebs. Deshalb muss eine Einbauposition gefunden werden, bei der sich – unabhängig vom eingebauten Aufnahmeband, mit dem dazugehörigen Antriebszahnrad – der Abstand zwischen Sensorsystem und Aufnahmeband nicht ändert. Auch die Abstandstoleranz von ±5 mm ist genauer zu betrachten. Zu prüfen ist, ob diese Toleranz nicht verringert werden kann, um entsprechend die Auswertung im Nachgang zu vereinfachen. Die Signalfrequenz, mit der die Sensorsignale aktuell abgetastet werden, beträgt 500 Hz. Für die meisten Kombinationen aus Stabraster und Fahrgeschwindigkeit ist diese Abtastfrequenz für eine sichere Auswertung des Sensorsignals zu gering. Eine Erhöhung der Abtastfrequenz ist möglich, wenn die Auswertung nicht in der Cloud, sondern sensornah erfolgen kann. Dazu sollte der Auswertealgorithmus auf einen Mikrocontroller oder einem vergleichbaren Bauteil implementiert werden. Die Verstärkerelektronik würde dann um die komplette Signalauswertung erweitert. Die Berechnung des Bandzustandes würde direkt im Sensorgehäuse erfolgen. Dadurch wäre eine Abfrage des Bandzustandes im Sekundentakt möglich. Bei der höchsten Fahrgeschwindigkeit werden für eine volle Bandumdrehung 1,6 s benötigt, bei der minimalen Fahrgeschwindigkeit 4,4 s für eine Bandumdrehung. Dies zeigt, dass hier auch eine Wertabfrage alle 10 s oder einmal pro Minute ausreichen würde. Voraussichtlich sind dann die anderen Maschinendaten, wie Hydromotor usw., die taktgebenden Komponenten.

6.3.4.2 Berührendes Sensorkonzept durch Zahnscheiben Wie in Abschn. 6.3.2 beschrieben längt sich das Band vor dem Reißen, besonders im Bereich des Bandschlosses. Um den Ausfall des Bandes vorherzusagen, bietet sich eine ständige Messung des Abstandes der Stäbe an, um daraus einen Trend zu errechnen. Ein Workshop wurde durchgeführt, bei dem unterschiedliche Ideen erzeugt und mitei­ nander verglichen wurden. Die am besten bewertete Lösung bestand aus zwei axial nebeneinander angeordneten Zahnscheiben, die mit dem Band mitlaufen, siehe Abb. 6.13. Dabei sind die beiden Zahnscheiben mit einer Feder so vorgespannt, dass sich die Zähne immer auseinanderspreizen und so immer an beiden Seiten der Aufnahmebandverzahnung anliegen. Je mehr sich die beiden Zahnscheiben gegeneinander verdrehen, desto mehr hat sich das Band gelängt. Die Herausforderung dabei war, die Information über den Verdrehwinkel zwischen beiden Zahnscheiben vom drehenden Teil auf das stehende System zu übertragen. Eine Funkübertragung an die Maschine wurde als zu aufwendig und in einem späteren Einsatz nicht umsetzbar eingestuft. Hauptgrund hierfür war die Energieversorgung auf dem drehenden Teil. Welche Lösung letztlich gewählt wurde, ist im Folgenden beschrieben.

134

P. Sivasothy et al.

Abb. 6.13  Sensorkonzept zur Überwachung des Bandes

Nach Vorstellung des beschriebenen Ansatzes beschlossen die am Use-Case Beteiligten, ihn (neben der MR-Sensorik) weiter zu verfolgen. Dabei stellte sich heraus, dass bei manchen Siebbändern ein Abtasten der Gummibandverzahnung nicht zielführend ist, da im Bereich des Bandschlosses die Verzahnung fehlt bzw. nicht eindeutig auf eine Längung des Bandes rückgeschlossen werden kann. Als Lösung wurde der Prototyp so weiterentwickelt, dass die Zahnscheiben direkt in die Stäbe eingreifen. Die Messung des Verdrehwinkels zwischen den beiden Scheiben übernimmt ein ortsfest montierter Sensor. Er misst Stegpaare an, deren beide Teile mit jeweils einer der Scheiben fest verbunden sind. Dazu ist die dem Sensor direkt benachbarte Scheibe mit mehreren äquidistanten, auf einem festen Radius in Umfangsrichtung verlaufenden axialen Erhöhungen versehen sowie mit radial unmittelbar anschließenden Langlöchern, durch die entsprechende Erhöhungen der anderen Scheibe ragen. Die Dimensionierung ist so gewählt, dass auch beim größten Stababstand (größten Verdrehwinkel) die beiden Teilstege überlappen und der Sensor ein ununterbrochenes Signal erzeugt, dessen zeitliche Dauer mit dem Winkel korreliert. Abb. 6.14 zeigt den ersten Prototypen, der mittels 3D-Druck hergestellt wurde. Anhand der unterschiedlichen Farben erkennt man, wo und wie die Erhöhungen und Langlöcher angeordnet sind. In Abb.  6.15 ist der Zusammenhang zwischen Stababstand und Bogenlänge (=Summenwinkel) dargestellt; zum Beispiel entsprechen 51,0  mm einem Summenwinkel des Stegpaars von 41,4 °. Als Sensor wurde ein schaltendes Hall-Element verwendet. Radiale Position und Messabstand sind so gewählt, dass über die gesamte Länge beider Teilstege eines Paars auf „High“

6  Anwendungsfall GRIMME

135

Abb. 6.14  Erster Prototyp aus dem 3D-Druck

Abb. 6.15  Zusammenhang zwischen Stababstand und Bogenlänge

geschaltet wird. Bei der Auswertung bildet der zeitliche Abstand zwischen den Stegpaaren den Maßstab, mit dessen Hilfe die „High“-Dauer auf den Winkel umgerechnet wird. Beim Betrieb in der Maschine muss die Sensoreinheit vor Erde und Steinen geschützt werden; dies erfolgt durch eine Abdeckung. Das zu messende Band ist nicht immer straff und kann im Betrieb flattern. Die Sensoreinheit kann somit nicht starr am Fahrzeug angebunden werden. Vielmehr wurde sie drehbar und mittels einer Feder vorgespannt am

136

P. Sivasothy et al.

Abb. 6.16  Sensoreinheit integriert ins Gehäuse

Abb. 6.17  Aufbau des Prüfstandes

Rahmen befestigt. Dadurch ist gewährleistet, dass die Zahnscheiben in ständigem Kontakt mit den Bandstäben stehen, siehe Abb. 6.16. Um die Funktion zu überprüfen und auch längere Tests zu ermöglichen, wurde ein Prüfstand entwickelt. Er besteht aus zwei angetriebenen, sich gemeinsam drehenden Scheiben, zwischen denen Bolzen angebracht sind. Diese haben unterschiedliche Abstände und sollen unterschiedliche Längungen des Aufnahmebandes simulieren. Die Sensoreinheit wird radial neben den Scheiben angeordnet und muss die unterschiedlichen Stababstände erkennen. Abb. 6.17 zeigt den Aufbau des Prüfstandes. Auf Abb. 6.18 sind die gemessenen Signale zu erkennen. Nach rechts ist die Zeitachse, nach oben der Schaltpegel des Sensors aufgetragen. Aus dem Abstand jeder zweiten Flanke, ausgelöst durch Erhöhungen auf derselben Zahnscheibe, kann die Drehzahl er-

6  Anwendungsfall GRIMME

137

Abb. 6.18 Sensorsignal

Abb. 6.19  Positionierung der Sensoreinheit an der realen Maschine

rechnet werden. Aus der Länge des hohen Signalpegels ergibt sich der Stababstand. Abb. 6.18 belegt, dass der Sensor auf dem Prüfstand gut verwendbare Daten liefert. Auch wurde ein 40 h Dauerlauf ohne Ausfall überstanden. Nach den positiven Prüfstandsläufen konnte der Einbau in die Maschine erfolgen. Die Sensoreinheit wurde in das Aufnahmeband in der Nähe einer Umlenkrolle ohne Verzahnung platziert (Abb. 6.19). Diese Anbringung ist praktisch alternativlos, weil auf der Oberseite

138

P. Sivasothy et al.

des Aufnahmebandes der Gutfluss eine Installation verhindert und ein Verbau von unten dazu geführt hätte, dass Erde in die Sensoreinheit eindringt. Da wie beschrieben das Band zwischen den Umlenkrollen flattert, sollte die Position der Sensoreinheit in der Nähe einer Umlenkrolle liegen, jedoch keiner mit Zwangsführung der Stäbe, da sonst die Längung des Bandes nicht erkannt werden kann. In der Maschine mit einem neuen Aufnahmeband und im Trockenlauf (ohne Erde) konnten sehr gute Messergebnisse erzielt werden. Bei einem gebrauchten Band, an dem die Stäbe verrostet waren und Erde anhaftete, waren die Messwerte jedoch nicht brauchbar. Die Zahnscheiben müssen auf den Stäben gleiten, um einzurasten und eine Verdrehung zu bewirken. Wie sich herausstellte, wurde dies durch den Rost und die Erde verhindert. Weiter hat sich gezeigt, dass durch die Positionierung zwischen dem hin- und rücklaufenden Band das Absieben der Erde behindert und somit eine Funktionseinschränkung des Aufnahmebandes hervorgerufen wurde. Die Problematik des Gleitens auf den Stäben könnte vermutlich durch eine Materialänderung an den Zahnscheiben (z. B. Teflon) und eine Optimierung der Kinematik behoben werden. Um den Siebprozess nicht zu beeinträchtigen, müsste dennoch eine alternative Position für die Sensoreinheit gefunden werden, z. B. integriert in die Antriebswelle am Ende des Bandes. Dies würde allerdings eine komplette Umkonstruktion der Sensoreinheit und des Einzuges der Maschine bedingen, was innerhalb des Forschungsprojektes weder zeitlich noch finanziell möglich war.

6.3.5 Physikalische Modellbildung Das folgende Kapitel befasst sich mit der Umsetzung der digitalen Nachbildung der Aufnahmeeinheit als Modell. Dafür wird die Einheit in funktionale Bereiche aufgeteilt, die separat umgesetzt und am Ende zusammengefügt werden. Diese Bereiche sind in Abb. 6.20 dargestellt. Zunächst wird der Hydraulikmotor samt Drehzahlsensor und Drucksensor mo-

Abb. 6.20  Struktur des Gesamtmodells der Aufnahmeeinheit

6  Anwendungsfall GRIMME

139

Abb. 6.21  Hydraulikmotor der Firma EATON

delliert. Danach folgen das Getriebe und der Magnetsensor. Anschließend wird der Drehzahlsensor am Aufnahmeband modelliert und zum Schluss folgt das Aufnahmeband. Das Aufnahmeband der Aufnahmeeinheit wird angetrieben von einem Hydraulikmotor der Firma EATON der 2000er Serie mit 130 cm3 Verdrängungsvolumen (siehe Abb. 6.21). Bei diesem erfolgt die Leistungsübertragung durch die Hydraulikflüssigkeit, die unter Druck stehend den im Motor befindlichen rotatorischen Antrieb in Bewegung versetzt. Das dabei erzeugte Drehmoment steht in direktem Zusammenhang mit dem Druck der Hydraulikflüssigkeit. Weiterhin passt sich die Geschwindigkeit des Aufnahmebands der Fahrgeschwindigkeit der Landmaschine an und kann bei Bedarf variiert werden. Der Hydraulikmotor wird mithilfe eines Gelenks modelliert, das einen rotatorischen Freiheitsgrad besitzt. Diesem Gelenk wird die Drehzahl entsprechend der Geschwindigkeit der Landmaschine vorgegeben. Um die Drehzahl zu ermitteln, wird die Geschwindigkeit der Landmaschine über den Radius der Antriebswalze mit Hilfe der Formel



nMotor = vLandmaschine ·

1 2 · π · rLandmaschine

in die Drehzahl umgerechnet. Diese Drehzahl wird mit dem typischen Wirkungsgrad von Hydraulikmotoren von 85 % gemäß [2] sowie mit weiteren Verlusten vom Getriebe verrechnet, damit diese kompensiert werden und die resultierende Bandgeschwindigkeit der der Landmaschine entspricht. Darüber hinaus wird an diesem Gelenk gemessen, welches Drehmoment bei der Rotationsbewegung anliegt. Da die Leistungsübertragung, wie beschrieben, über eine unter Druck stehende Hydraulikflüssigkeit erfolgt, kann mit Hilfe des

140

P. Sivasothy et al.

anliegenden Drehmoments und der Drehzahl dieser Druck bestimmt werden. Dafür ist das Motorkennfeld hilfreich. Dieses trägt bei einem bestimmten Volumenstrom und bei einem anliegenden Drehmoment den dazu gehörigen Druckunterschied auf. Um diesen Druckunterschied zu ermitteln, wird zunächst der Volumenstrom bestimmt. Dieser ist a­ bhängig vom Verdrängungsvolumen des Motors, der anliegenden Drehzahl und dem volumetrischen Wirkungsgrad des Motors. Der Volumenstrom wird mit der Formel aus [2]



qv =

Vg · nMotor · 60 1000 · η v



ermittelt. Mit dem am Gelenk anliegenden Drehmoment und dem berechneten Volumenstrom kann der Druckunterschied aus dem Motorkennfeld mit Hilfe von Interpolation bestimmt werden (siehe Abb. 6.22). Neben dem Hydraulikmotor sind zwei elektronische Druckmessumformer der Firma HYDAC Electronic verbaut. Diese dienen der Erfassung des Drucks im Vorlauf und des Drucks im Nachlauf. Diese Drucksensoren haben einen definierten Messbereich und wandeln den gemessenen Druck mit Hilfe der Sensorkennlinie in Abb. 6.23 in ein analoges Signal um. Dabei gilt folgende lineare Zuordnung:

[0;250] bar → [ 4;20] mA

Die Nachbildung der Signale erfolgt mit Hilfe des Druckunterschieds am Motor, der aus dem Motorkennfeld bestimmt wird. Aufgrund fehlender Messungen liegen jedoch keine konkreten Daten zum Druck im Nachlauf bereit. Gemäß der Aussage des Herstellers der Landmaschine entsteht ein Druck im Nachlauf von ca. 30 bar. Dieser Wert wurde durch Messungen ermittelt. Daraus wird der Druck im Vorlauf mit

pin = pout + ∆ pDruckunterschied

abgeleitet. Anschließend wird der ermittelte Druck über die Kennlinie in ein analoges Signal umgewandelt. Des Weiteren wird die Drehzahl des Hydraulikmotors mit einem Drehzahlsensor aufgenommen. Hierfür ist ein Impulsgeber im Gehäuse des Motors integriert. Das dazugehörige Impulsrad verfügt über 60 Zähne. Der Drehzahlsensor erzeugt ein frequenzmoduliertes Rechtecksignal (siehe Abb. 6.24). Dabei wird nach jedem Impuls die Periodendauer gemessen und durch



fi =

1 Ti

in eine Impulsfrequenz umgewandelt. Mit Hilfe dieser Impulsfrequenz wird nun über die Verrechnung der Zähnezahl durch



nMotor = f Motor =

1 Ti ⋅ 60

6  Anwendungsfall GRIMME

141 130cm3/r [8.0 in3/r] ¨Pressure Bar [PSI]

[.25] .95 [.5] 1.9 [1] 3.8 [2] 7.5 [4] 15 [6]

Flow LPM [GPM]

23 [8] 30 [10] 38 [12] 45 [14] 53 [16] 61 [18] 68 [20] 76 [22] 83 [24] 91 [25] 95

[250] 15

[500] [1000] [1500] [2000] [2500] [3000] [3500] [4000] [4500] 35 70 105 140 170 205 240 275 310

[170] 20 3 [190] 20 12 [230] 25 28 [230] 25 56 [220] 25 114 [220] 25 172 [200] 25 230 [180] 20 287 [160] 20 345 [150] 15 403 [130] 15 461 [110] 10 518 [90] 10 576 [60] 5 634 [40] 5 692 [20] 1.0 720

[410] 45 8 [510] 60 27 [510] 60 56 [500] 55 113 [490] 55 171 [480] 55 224 [470] 55 286 [460] 50 344 [440] 50 402 [420] 45 460 [400] 45 517 [380] 45 575 [350] 40 633 [325] 35 691 [310] 35 719

[870] 100 2 [1070] 120 23 [1080] 120 53 [1080] 120 111 [1080] 120 169 [1080] 120 222 [1070] 120 282 [1060] 120 338 [1030] 115 395 [1010] 115 452 [990] 110 509 [960] 110 568 [940] 105 624 [920] 105 682 [900] 100 712

[1580] 180 19 [1600] 180 47 [1620] 185 104 [1640] 185 161 [1650] 185 219 [1650] 185 276 [1640] 185 333 [1620] 185 391 [1600] 180 447 [1580] 180 504 [1550] 175 560 [1520] 170 619 [1490] 170 676 [1480] 165 705

[2050] 230 16 [2090] 235 42 [2150] 245 97 [2190] 245 153 [2220] 250 210 [2230] 250 269 [2230] 250 327 [2220] 250 385 [2200] 250 443 [2160] 245 500 [2130] 240 551 [2100] 235 604 [2070] 235 665 [2050] 230 692

[2520] 285 13 [2580] 290 39 [2660] 300 95 [2740] 310 149 [2780] 315 204 [2800] 315 261 [2800] 315 317 [3000] 340 373 [2780] 315 430 [2750] 310 484 [2710] 305 539 [2680] 305 597 [2650] 300 651 [2630] 295 679

[2920] 309 9 [2930] 330 36 [3100] 350 92 [3260] 370 146 [3310] 375 201 [3420] 385 255 [3350] 380 307 [3350] 380 360 [3330] 375 411 [3300] 375 471 [3280] 370 524 [3250] 365 579 [3220] 365 633 [3200] 360 682

[3310] 375 3 [3320] 375 28 [3540] 400 85 [3770] 425 132 [3840] 435 192 [3940] 445 243 [3910] 440 295 [3910] 440 348 [3890] 440 397 [3860] 435 456 [3840] 435 508 [3820] 430 560 [3780] 425 616 [3700] 420 656

[3640] [3990] 450 410 13 21 [3980] [4420] 450 500 77 70 [4280] [4800] 485 540 118 104 [4360] [4890] 550 495 175 184 [4450] [4970] 505 560 231 219 [4440] [4960] 560 500 272 284 [4440] 500 336 [4440] 500 384 [4410] 500 440

`

Torque [Ib-in] Nm Speed RPM

Abb. 6.22  Kennfeld des Hydraulikmotors der Firma EATON

auf die aktuelle Motorfrequenz geschlossen, die der Drehzahl entspricht. Die Nachbildung erfolgt durch ein erzeugtes Rechtecksignal. Das Verhältnis von High zu Low beträgt dabei 1:1. Die Frequenz ist abhängig von der aktuellen Drehzahl, die wiederum durch die Geschwindigkeit mit Hilfe der vorherigen Gleichung bestimmt wird.

P. Sivasothy et al.

142 .HQQOLQLH'UXFNVHQVRU+\GUDXOLNPRWRU





6LJQDOLQP$















   'UXFNXQWHUVFKLHGLQEDU



Abb. 6.23  Kennlinie des Druckmessumformers

Abb. 6.24  Schema des Rechtecksignals des Drehzahlsensors

Um das benötigte Drehmoment zu erreichen, ist hinter dem Hydraulikmotor ein Getriebe der Firma Rögelberg Getriebe verbaut. Dabei handelt es sich um ein Winkelgetriebe mit einer festen Übersetzung (siehe Abb. 6.25). Der Antrieb erfolgt durch den zuvor beschriebenen Hydraulikmotor. Die Kraft wird in das Getriebe eingespeist und über zwei Kegelräder mit einer festen Übersetzung an die nachfolgende Mechanik weitergegeben. Weiterhin hat ein solches Getriebe nach [3] einen Wirkungsgrad von ca. 96 %. Damit die Drehzahl am Band bei der Nachbildung korrekte Werte annimmt, werden der Wirkungsgrad des Motors, der Übersetzungsfaktor und der Wirkungsgrad des Getriebes mit

berücksichtigt.

nMotor · η Motor · ηGetriebe = nBand iGetriebe

6  Anwendungsfall GRIMME

143

Abb. 6.25  Getriebe der Firma Rögelberg Getriebe

Abb. 6.26  Messraster der Sensitec Sensoruntersuchung

In der Aufnahmeeinheit ist ein AMR-Sensor der Firma Sensitec verbaut. Dieser dient der berührungslosen Positionserfassung der Metallstäbe im Aufnahmeband und reagiert auf Veränderungen des Magnetfelds. Der Sensor wurde unter Laborbedingungen mit einer dafür eigens konzipierten Messeinrichtung am Lehrstuhl für Messtechnik und Sensorik (MTS) der Technischen Universität Kaiserslautern untersucht. Bei der Messung wurde für jede Position im Messraster gemäß Abb. 6.26 der dazugehörige Spannungswert des Sensors aufgenommen. Damit wurde ein charakteristisches Feld des Sensors ermittelt (siehe Abb. 6.27).

144

P. Sivasothy et al.

Abb. 6.27  Aufgenommenes charakteristisches Feld des Sensitec Sensors

Die simulative Umsetzung des Sensors wurde mithilfe einer Distanzmessung realisiert. Dabei wurde zunächst die Position des Sensors in der Ebene bestimmt. Von dieser Position aus wird die Distanz zu jedem nachgebildeten Metallstab des Aufnahmebands ermittelt.

∆ xn = xSensor − xn ,Stab



∆ yn = ySensor − yn ,Stab

Durch die Bedingung der kürzesten Distanz wird der Abstand zu dem Metallstab ausgegeben, der dem Sensor am nächsten ist. Daraufhin wird überprüft, ob der Metallstab im Detektionsbereich liegt. Ist dies der Fall, wird mithilfe von Interpolation der entsprechende Sensorwert aus dem hinterlegten charakteristischen Feld des Sensors ermittelt und ausgegeben. Mithilfe eines neu entwickelten Sensors der Firma Schaeffler, der in Abb. 6.28 dargestellt ist, wird die Drehzahl des Bandes überwacht und der Abstand zwischen den Stäben ermittelt, die mit dem Sensor im Eingriff stehen. Dieser Sensor besteht aus zwei Rädern mit jeweils sechs Zähnen am Umfang. Jedes Rad besitzt weitere sechs Nocken, die axial hervorstehen. Der Sensor wird mit einem Hall-Effekt-Drehzahlsensor kombiniert, der eine Magnetflussänderung misst und dadurch zur berührungslosen Erfassung der Drehzahl dient. Dieser ist auf die Flanken des Schaeffler-Sensors ausgerichtet und erzeugt ein Rechtecksignal. Das erzeugte Rechtecksignal ist sowohl frequenzmoduliert als auch pulsweitenmoduliert. Über die Drehzahl kann die Frequenzmodulation herausgerechnet werden, so dass die Informationen über den Stababstand lediglich pulsweitenmoduliert ist.

6  Anwendungsfall GRIMME

145

Abb. 6.28 Schaeffler-Sensor

Abb. 6.29  Bandstück des Aufnahmebands

Das Aufnahmeband der Aufnahmeeinheit besteht aus einem Gummiriemen, das von Metallstäben in äquidistantem Abstand von 45  mm durchsetzt ist. In Abb.  6.29 ist ein Bandstück dargestellt. Für die Nachbildung des Aufnahmebands werden die Metallstäbe durch Zylinder modelliert. Der Gummiriemen wird mithilfe des Kelvin-Voigt-Materialmodells nach [4] durch ein Feder-Dämpfer-System nachgebildet (siehe Abb. 6.30). Die Elastizität des Aufnahmebands wird mithilfe der Federsteifigkeit und der Dämpfung im Feder-Dämpfer-System angepasst. Hierfür wurden vom Hersteller Resultate aus einem statischen Zugversuch am Aufnahmeband zur Verfügung gestellt. Mithilfe dieser Daten wird die Federsteifigkeit bestimmt. Die Ermittlung der Dämpfungskonstante erfolgt mithilfe eines dynamischen Zugversuchs des Aufnahmebands. Dieser dynamische Zugversuch wurde am Lehrstuhl für Maschinenelemente und Getriebetechnik (MEGT) der Technischen Universität Kaiserslautern im Rahmen des Forschungsprojekts durchgeführt (siehe Abb. 6.31). Hierfür wurde ein Bandstück eingespannt und zyklisch mit einer definierten Kraft belastet. Da jedoch die maximale Kraft der Anlage das Bandstück nicht beschädigen konnte, wurde dieses in der Breite auf die Hälfte reduziert. Es wird angenommen, dass sich die Eigenschaften des Bands in Bezug auf die Breite linear verhalten. Die zyklische Beanspruchung erfolgte auf zwei Arten. Zum einen wurde das Bandstück mit einer Kraft belastet und entspannt, worauf eine Haltezeit von zehn Sekunden folgte bis der nächste Zyklus das Band belastet hat. Bei der zweiten Art der Beanspruchung entfällt diese Haltezeit, so dass das Bandstück belastet und entspannt wurde. Daraufhin folgte der nächste Belastungszyklus. Für die Nachbildung der Aufnahmeeinheit ist die Variante mit zehn Sekunden Haltezeit von Bedeutung, da diese Art am ehesten der Beanspruchung der

146 Abb. 6.30  Modellierung des Aufnahmebands

Abb. 6.31  Untersuchung am Bandstück

P. Sivasothy et al.

6  Anwendungsfall GRIMME

147

späteren Anwendung entspricht. Eine Übersicht der Untersuchung der Krafteinwirkung ist in Tab. 6.1 und in Tab. 6.2 gegeben. In Abb. 6.32 ist ein Versuch im Detail dargestellt. Dabei ist der von der Maschine zurückgelegte Weg beim Belasten über den Versuchszeitraum aufgetragen. Anlagenbedingt stellt sich zu Beginn ein initialer Weg ein, der im späteren Verlauf herausgerechnet wird. Die rote Messaufzeichnung beschreibt den bei Krafteinwirkung ausgedehnten Zustand des Bandstücks. Die grüne Messaufzeichnung stellt den Zustand des Bands ohne Belastung dar und entspricht somit dem plastischen Verformungsverlauf.

Tab. 6.1  Ergebnisse Untersuchung am Bandstück halber Breite bei Belastung mit 10 s Haltezeit Versuch 1 2 3 4 5

Kraft in kN 8,1 7,1 6,1 5,1 4,1

Dehnung in mm 14,3 10,5 11,3 9,23 7,37

Gesamtzyklenzahl 505 750 1515 3223 21.177

Periodendauer in s 11,5 11,38 11,2 11 11,18

Tab. 6.2  Ergebnisse Untersuchung am Bandstück halber Breite bei Belastung ohne Haltezeit Versuch 1 2 3 4

Kraft in kN 8,1 7,1 6,1 5,1

Dehnung in mm 9,92 6,70 4,95 6,56

Gesamtzyklenzahl 2791 6660 17.435 145.600

Periodendauer in s 1,38 1,24 1,36 1,3

Abb. 6.32  Auswertung der Belastung des Bandstücks mit definierter Kraft und 10s Haltezeit

148

P. Sivasothy et al.

Für die Dämpfungskonstante wird nun mit der vorhandenen Federsteifigkeit das untersuchte Bandstück in einem isolierten Minimalmodell nachgebildet. Dabei ist dieses Bandstück an einer Seite fest eingespannt, an der anderen Seite wird es mit einer Kraft belastet. Die Kraft wird entsprechend den Versuchen des MEGT angepasst. Die Federsteifigkeit wird auf den berechneten Wert gesetzt. Die Dämpfungskonstante wird initial auf einen Wert gesetzt und später variiert. Nachdem die Simulation gestartet wird, wird gemessen, welche Dehnung das Bandstück erfährt, wenn eine Kraft anliegt. Die Dehnung wird mit der Dehnung aus der Untersuchung abgeglichen. Dabei ist zu beachten, dass die Untersuchung für ein Bandstück halber Breite durchgeführt wurde, so dass die Angaben der Dehnung aus den Versuchen halbiert werden. Die Dämpfungskonstante wird solange eingepasst, bis die Dehnung der Simulation mit der Dehnung aus der Untersuchung übereinstimmt. Die Dämpfungskonstante hat bei einer Zugbelastung von 8,1 kN und einer Dehnung von 7,15 mm (da doppelte Breite) einen Wert von d = 2.625.617,9 N/(m/s). Dieser Wert hat sich jedoch in der Simulation als sehr nachteilig ergeben, da durch den hohen Dämpfungswert der elastische Effekt zu stark gedämpft und somit das Verhalten verfälscht wurde. Im Rahmen dieser Arbeit hat die Dämpfung mit dem Wert d = 228.314,6 N/(m/s) ein gutes elastisches Verhalten aufgezeigt. Die Plastizität des Aufnahmebands wird durch adaptive Längenänderung realisiert. Dafür wird im Feder-Dämpfer-System die Federlänge gemäß der plastischen Veränderung des Bandes verändert. In der Nachbildung wird für das Feder-Dämpfer-System, über das die Metallstäbe miteinander verbunden sind, folgende Formel gemäß [4] benutzt:

F = −k ( x − x0 ) − d · v

Die Kraft, die durch das Feder-Dämpfer-System zwischen zwei Metallstäben wirkt, wird bestimmt durch die Federsteifigkeit, der Distanz der beiden Metallstäbe, der Federlänge, der Dämpfung sowie der relativen Geschwindigkeit der Stäbe zueinander. Die Veränderung der Federlänge erfolgt mithilfe eines Belastungskennwerts. Dieser enthält Informationen darüber, wie sich das Band verhält, wenn eine bestimmte Belastung wirkt. Dafür werden die Untersuchungen des MEGT ausgewertet und hinterlegt. Zuerst wird mithilfe der Tab. 6.1 ermittelt, welchen Anteil eine Belastung am Gesamtversagen des Bands trägt. Zum Beispiel zeigt die Gesamtzyklenzahl des Versuchs Nr.  1 an, dass das untersuchte Bandstück nach 505 Belastungen mit einer Kraft von 8,1 kN versagt. Da in der Nachbildung von einem Band mit voller Breite ausgegangen und ein linearer Zusammenhang angenommen wird, wird die Zyklenzahl verdoppelt, diese über die Belastungen am Band aufgetragen und mit einer Kurve eingepasst. Das Resultat ist in Abb. 6.33 ersichtlich. Die Kurve wird über die Funktion

Zyklenmax ( F ) = a ⋅ ebF + c ⋅ e dF

eingepasst. Danach wird der prozentuale Anteil einer beliebigen Belastung F am gesamtversagenden Bandstück berechnet. Dabei gilt folgende Zuordnung: Die maximale Zyklenzahl

6  Anwendungsfall GRIMME

149

Abb. 6.33  Gesamtzyklenzahl voller Bandbreite mit eingepasster Funktion

einer Belastung F entspricht dem Gesamtversagen des Bands. Auf einen Beanspruchungszyklus heruntergerechnet ergibt sich ein prozentualer Anteil am Gesamtversagen. Dieser durch einen Beanspruchungszyklus entstandene prozentuale Anteil am Gesamtversagen kann durch V% =

1 N zyk ,max, F

bestimmt werden. Mit der eingepassten Funktion folgt daraus:



V% =

100 a · eb · F + c · e d · F

Mithilfe dieser Gleichung kann bestimmt werden, welchen Schaden eine beliebige Belastung F am Band verursacht hat. Daraufhin wird ermittelt, welche Auswirkung dieses Versagen auf die plastische Verformung des Bandstücks hat (Abb. 6.34).

6.3.6 Signalverarbeitung und Datenvoranalyse Um den Verschleißfortschritt und damit die Lebensdauer des Bandes abschätzen zu können, muss dessen Längung/Dehnung ermittelt werden. Diese kann bei konstanter

150

P. Sivasothy et al.

Abb. 6.34  Simulationsmodell des Aufnahmebandes

Bandgeschwindigkeit z. B. durch die Periodendauer eines Bandumlaufs berechnet werden. Eine Möglichkeit zur Ermittlung der Periodendauer ist z. B. die robuste Detektion des „Schlosses“ aus dem zeitlichen Signalverlauf. Durch die Zeitdifferenz zwischen der periodischen Detektion des Schlosses kann bei konstanter Bandgeschwindigkeit auf die Periodendauer T geschlossen werden. Weist ein Bandumlauf beim Prüfstandsversuch noch eine sehr eindeutige und periodisch auftretende charakteristische Signalform auf (hoher Peak bei Passieren des Schlosses, periodisch ähnliche Signalverläufe bei Passieren der Stäbe, siehe Abb.  6.35) so ergibt sich bei Feldtestmessungen ein wesentlich anderes Bild (siehe Abb. 6.36). Anhand des Signalverlaufs der Feldtestdaten lässt sich das Schloss kaum bis gar nicht mehr erkennen. Eine charakteristische Periode ist in diesem Signal nicht direkt ersichtlich. Um dennoch auf die Periodendauer eines Bandumlaufs (und damit auf die Bandlängung) schließen zu können, wird ein anderer Ansatz verfolgt. Das Signal wird zunächst mittels eines Tiefpass-Filters gefiltert. Hierzu wird an dieser Stelle ein Gauß-Filter der Grenzwellenlänge λc nach DIN EN ISO 16610-21 [5] verwendet. Das auf diese Weise gefilterte Signal kann als Welligkeitsprofil des Signals interpretiert werden (siehe Abb. 6.36). Dieses Welligkeitsprofil weist im Gegensatz zum Rohsignal eine gut sichtbare Periodizität auf. Die Periodendauer T wird nun ermittelt, indem die Autokorrelationsfunktion (AKF) eines gefilterten Signalabschnitts gebildet und analysiert wird (siehe Abb. 6.37). Die gut sichtbaren Peaks der AKF stehen für eine gute Überlagerung des Welligkeitsprofils mit sich selbst bei einer auf der horizontalen Achse ablesbaren Verschiebung. Daraus lässt sich die mittlere Periodendauer T und deren Standardabweichung σT ermitteln. Das zuvor grob beschriebene Verfahren zur Ermittlung der Periodendauer wird nun im Detail erläutert:

6  Anwendungsfall GRIMME

151

Abb. 6.35 Prüfstandsversuch

Abb. 6.36  Feldtestdaten und Welligkeitsprofil

Zunächst muss die Grenzwellenlänge des verwendeten Gauß-Filters geeignet gewählt werden. Diese sollte so groß sein, dass die durch Stäbe induzierte Periodendauer TS he­ rausgefiltert wird, der Welligkeitscharakter des Signals jedoch erhalten bleibt. Die Grenzwellenlänge (hier eigentlich Grenzperiodendauer) sollte demnach ein Vielfaches (Vielfach im Sinne von ca. Faktor 3 bis 6) der Periodendauer TS betragen. Mit Faktor K (ca. 3 bis 6), der Periodendauer eines Bandumlaufs T und der Anzahl der Stäbe z gilt der Richtwert

P. Sivasothy et al.

152

Abb. 6.37  Autokorrelationsfunktion (AKF) eines 30 s Intervalls des Welligkeitsprofils

λc = K ·



T . z

Die genaue Ermittlung der Periodendauer T ist Ziel des Verfahrens und muss für die Berechnung der Grenzwellenlänge entweder direkt geschätzt oder bei völliger Unkenntnis ein Schätzwert berechnet werden. Dieser lässt sich anhand von Bandlänge LB, Motordrehzahl nM, Getriebeübersetzung i und Radius der Abtriebswelle (Abstand Wellenzentrum zu Stabzentrum) rAW, S durch folgenden Zusammenhang berechnen: T≈

LB · i 2 · π · nM · rAW , S

Die Gewichtsfunktion (oder Impulsantwort) des Gauß-Filters nach [5] lautet: 



2

−π ·   ln ( 2 ) 1 α ·λ  g ( x) = · e  c  , mit α = α · λc π x



Die Filterung erfolgt durch „Faltung“ von Gewichtsfunktion und Signal [5]. Als Ergebnis erhält man das Welligkeitsprofil des Signals (siehe Abb. 6.37) Für ein diskretes Zeitsignal u(n) (n ist die diskrete Zählvariable und lässt sich durch t(n) = n · dt mit hier dt = 1 s in Sekunden umrechnen) lautet die Autokorrelationsfunk500 tion [6]



ϕuu (κ ) =

∞

∑ u [ n ] · u [ n + κ ].

k =−∞

∗

6  Anwendungsfall GRIMME

153

Der Ausdruck u∗[n] entspricht der komplex Konjugierten von u[n] und κ steht für die (Zeit-) Verschiebung der Signale zueinander und kann ebenfalls über Δt(κ) = κ · dt in Sekunden umgerechnet werden. Die AKF eines Δt = 30 s Zeitintervalls des Welligkeitsprofils (bei vorliegenden Feldtestdaten eignet sich ein Zeitfenster von Δt = 15 s bis Δt = 30 s besonders gut) ist in Abb. 6.37 dargestellt. Zuvor wurde das Signal vom Mittelwert befreit ( es gilt u [ n ] = 0 ), wodurch die charakteristische Form der AKF entsteht. Diese wird nun analysiert. In diesem Beispiel werden hierzu zunächst sämtliche Peaks detektiert und eine Gerade eingeführt, die als Grenzwert für die Identifikation eines Peaks als periodische Überlagerung des Signals dient (siehe Abb. 6.38). Die Abstände zwischen den herausstechenden Peaks werden analysiert und so auf die mittlere Periodendauer T geschlossen. In diesem Beispiel ergibt sich

T = T ± k · σ T = 2, 7365 s ± k · 0, 0028 s,

wobei T der Mittelwert und σT die Standardabweichung der ermittelten Periodendauer ist. Legt man das jeweils um die ermittelte Periodendauer T verschobene Welligkeitsprofil übereinander, so bestätigt sich die errechnete Periodendauer (siehe Abb. 6.39). Im vorherigen Abschnitt wurde die Periodendauer eines Bandumlaufs robust ermittelt. Diese Information wird ebenfalls für die Detektion des Schlosses genutzt. Das Signal, das durch Passieren des Schlosses im Feldtest entsteht, kann zum Zeitpunkt t = 302,8 s entnommen werden (siehe Abb. 6.40). Man erkennt, dass sich das Schloss-Signal von dem durch Stäbe induzierten Signal unterscheidet. Das Vorgehen zur Schlossdetektion beruht nun auf dem Ansatz, dass das Schloss-Signal andere Frequenzanteile aufweist als der Rest des Signals. Frequenzanteile der Stab-Signale (höhere Frequenzen) und Frequenzanteile der Welligkeit (niedrige Frequenzen) werden herausgefiltert. Übrig bleiben die Frequenzanteile, die für das Schloss-­ Signal charakteristisch sind. Das interessierende Frequenzintervall kann

Abb. 6.38  AKF mitsamt Peaks und Grenzgerade

154

P. Sivasothy et al.

Abb. 6.39  Überlagerung des Welligkeitsprofils um T

Abb. 6.40  Schloss im Signalverlauf

durch Kenntnis geometrischer Verhältnisse (Stabteilung, Maße des Schlosses) und zuvor ermittelter Periodendauer abgeschätzt werden. Abb. 6.41 stellt das Frequenzspektrum eines 30 s langen Signalausschnitts dar. Der herausstechende Peak in Abb. 6.41 bei ca. f = 31 Hz repräsentiert die Frequenzanteile des Stab-Signals. Mittels finite-impulse-response-(FIR-)Bandpass-Filter [7] hohen Grades (oder idealem Bandpassfilter durch Nullsetzen der Spektralwerte der herauszufilternden Frequenzanteile; hier FFT ideal genannt) werden in diesem Beispiel ­Frequenzanteile zwischen f = 12 Hz und f = 20 Hz beibehalten. Transformiert man dieses mittels Bandpass gefilterte Signal zurück in den Zeitbereich, so entsteht das in Abb. 6.42 schwarz dargestellte Signal. Im durch Filterung entstehenden Signalverlauf (Abb. 6.42) sind annähernd äquidistant herausstechende Peaks deutlich erkennbar. Abb. 6.43 stellt einen dieser Peaks

6  Anwendungsfall GRIMME

155

Abb. 6.41  Frequenzspektrum eines 30 s langen Signalausschnitts

Abb. 6.42  Gegenüberstellung Messung und mittels FIR-Filter gefiltertes Signal

im Detail dar. Es ist erkennbar, dass das FIR-gefilterte Signal große Amplituden (als Peaks erkennbar) bei Passieren des Schlosses aufweist. Mit Kenntnis der Periodendauer kann überprüft werden, ob die detektierten Peaks die Schlosspositionen wiedergeben oder es sich um „zufällig“ entstehende Peaks handelt. In Abb. 6.44 sind die als grobe Schlossposition detektierten Peaks gekennzeichnet. Die jeweiligen Peakabstände decken sich mit der zuvor ermittelten Periodendauer, was ein Kriterium für die Detektion als grobe Schlossposition ist. Bis zu diesem Punkt lässt sich das Schloss grob im Signalverlauf detektieren. Es liegt im Bereich um den Peak des mittels FIR-Filter gefilterten Signals. In einem weiteren Schritt wird die Position des Schlosses genauer detektiert. Betrachtet man den Bereich um die Peaks des FIR-gefilterten Signals, so kann man die charakteristische Form des Schloss-Signals erkennen. Dies wird in Abb.  6.45 und  6.46 deutlich. In diesen Abbildungen sind zusätzlich die Ableitungen des Sensorsignals abgebildet. Es wird deutlich, dass sich das Schloss an der Position befindet, an dem die Ableitung im betrachteten Fenster den geringsten Peak, bzw. das höchste Valley aufweist (je nach Aus-

156

Abb. 6.43  FIR-gefiltertes Signal

Abb. 6.44  Schlossfindung in Feldtestdaten

Abb. 6.45  Bereich um Schloss (rechtes Band)

P. Sivasothy et al.

6  Anwendungsfall GRIMME

157

Abb. 6.46  Bereich um Schloss (linkes Band)

richtung des Schlosses bei linkem und rechtem Band). Diese Information wird genutzt, um die genaue Position des Schlosses zu bestimmen. Wichtig ist, dass das Sensorsignal vor dem Ableiten geglättet wird (hier mittels Gauß-Filter nach [5]), da sonst zusätzliche Peaks durch Messrauschen in der Ableitung entstehen, die dann fälschlicherweise als Schlossposition detektiert werden können. Trotz Glättung des Signals kann es vorkommen, dass ein anderes als das tatsächliche Schloss-Signal als Schloss detektiert wird. Diese Position lässt sich durch Kenntnis der zuvor gewonnenen Periodendauer jedoch leicht ausschließen. Mittels dieses Verfahrens kann die Position des Schlosses in einem kleinen Zeitintervall mit konstanter Periodendauer sehr genau bestimmt werden. Nach Detektion des Schlosses ist es möglich, die für den Bandverschleiß kritischen Stäbe vor und hinter dem Schloss zu detektieren. Hierzu werden die Wendestellen der „fallenden“ Flanken des Signals als Stabposition detektiert (Abb. 6.47), wodurch anschließend ihre jeweiligen (zeitlichen) Abstände zueinander berechnet werden können.

6.3.7 Schnittstellendefinition und Datenvermittlung in die Cloud Im Use-Case „GRIMME“ soll die Verfügbarkeit eines Kartoffelvollernters durch die Zustandsüberwachung des als ausfallkritische Komponente identifizierten Aufnahmebands gesteigert werden. Die Aufnahmebänder werden bei ihrem Einsatz durch die Erde stark abgenutzt. Diese Abnutzung zeigt sich in einer Längung des Aufnahmebandes im Schlossbereich und kann ohne präventive Wartung zu einem Ausfall im Einsatz führen. Um bei einem kritischen Zustand des Aufnahmebandes rechtzeitig eine präventive Wartung durchführen zu können, soll der Zustand sensorisch überwacht und an GRIMME übermittelt werden. Daraus ergeben sich Anforderungen an die Sensorschnittstellen und an die Schnittstelle zur Kommunikationsplattform.

158

P. Sivasothy et al.

Abb. 6.47  Schlossposition und jeweils fünf detektierte Stäbe vor/hinter dem Schloss EtherCAT Strommessung DrehzahlSensor

ÖldruckSensor Frequenzmessung SchaefflerSensor

Frequenzmessung

IO-Modul S30e

EtherCAT

Spannungsmessung SensitecSensor

DrehzahlSensor

Strommessung ÖldruckSensor Frequenzmessung SchaefflerSensor

Frequenzmessung

IO-Modul S30e

Spannungsmessung SensitecSensor

Abb. 6.48 Schnittstellen der Sensor-Signalaufnahme bei der Aufnahmeband-Verschleiß-­ Überwachung

In Abb. 6.48 sind die im Use-Case „GRIMME“ eingesetzten Sensoren und ihre Anbindungen an die I/O-Module zu sehen. (vergleiche Abb. 4.4 aus Abschn. 4.7) Zur Zustandsüberwachung werden zwei verschiedene sensorische Ansätze (Sensorkonzept Sensitec und Sensorkonzept Schaeffler) für die Ermittlung der Bandlängung

6  Anwendungsfall GRIMME

159

verfolgt. Als weitere wichtige Messgröße wird die Belastung des Bandes durch die sensorische Erfassung des Drehmomentes über die Drehzahl und den Druck im hydraulischen Antrieb des Aufnahmebandes erfasst. Als unterstützende Messgrößen stehen die Fahrgeschwindigkeit und die Einstellparameter in der Steuerung zur Verfügung. Messen der Längung des Aufnahmebandes: • Schaeffler-Sensor (berührendes Sensorkonzept): –– Bandgeschwindigkeit (Frequenzmessung) –– Stababstand durch mechanische Abtastung der Stäbe (Frequenzmessung/Phasenverschiebung) • Sensitec-Sensor (berührungsloses Sensorkonzept): –– Magnetoresistives Analogsensorsignal der einzelnen Stäbe des Bandes (Spannungsmessung) Belastungsüberwachung: • Hydraulischer Druck im Bandantrieb (Strommessung) • Drehzahl des Bandantriebs (Frequenzmessung) Aus der Steuerung des Kartoffelvollernters: • die Fahrgeschwindigkeit • die Ist-Einstellungen des Kartoffelvollernters

6.4

 usgewählte Elemente des intelligenten A Informationsmanagements

In diesem Kapitel erfolgt die spezifische Entwicklung einzelner Elemente des intelligenten Informationsmanagements, die für die Realisierung des Use-Case GRIMME unabdingbar sind. Darunter fallen die Entwicklung der Business Analytics zur Datenauswertung sowie die Entwicklung des Maschinen-Front-Ends zur Datenvisualisierung auf dem Varitron 470.

6.4.1 Entwicklung der Business Analytics Im Use-Case GRIMME steht die Steigerung der Verfügbarkeit eines Kartoffelvollernters durch die sensorische Überwachung des Aufnahmebandes und weiterer relevanter Komponenten im Vordergrund. Es sollen ungeplante Maschinenstillstände durch ein defektes Aufnahmeband verhindert werden, indem dies frühzeitig erkannt bzw. der Ausfall prognostiziert wird. Aus der Erkennung sollen sowohl Maßnahmen zum weiteren, beispielsweise

160

P. Sivasothy et al.

leistungsgeminderten, Betrieb des Kartoffelvollernters als auch Serviceprozesse zur Produktion, Lieferung und Einbau des Bandes mit dem Ziel einer verkürzten Stillstandszeit angestoßen werden. Hieraus ergeben sich für die Business Analytics folgende Anforderungen: • Erkennung von Mustern hinsichtlich des Verschleißverhaltens des Aufnahmebandes • Prognose des Ausfalls des Aufnahmebandes aufgrund von Verschleiß • Meldung von bevorstehenden Ausfällen Als Grundlage wird das in Abschn. 5.4 beschriebene Modell zur Datenverarbeitung verwendet, mit dessen Hilfe Daten vom betrachteten Investitionsgut, in diesem Fall vom Kartoffelvollernter Varitron 470, in einzelnen Datenpaketen (Chunks) auf den Telekom-­Server übertragen werden und dort zur weiteren Bearbeitung durch die Business Analytics bereit stehen.

6.4.1.1 Datenauswertung von Varitron-Daten Zur Ermittlung des Zustands des Kartoffelvollernters und zur späteren Verarbeitung der Daten z. B. zur Mustererkennung, Clusteranalyse oder Ähnlichem, werden folgende Daten am Kartoffelvollernter aufgenommen und auf den Messwertserver übertragen: . Öldruck vor Hydraulikmotor 1 2. Öldruck nach Hydraulikmotor 3. Drehzahl Hydraulikmotor 4. Sensor-Signal (Sensitec) 5. Fahrgeschwindigkeit Kartoffelvollernter 6. Temperatur (ab Generation 2 Sensitec-Sensor) Diese Daten sind dadurch gekennzeichnet, dass sie automatisiert und hochfrequent von Sensoren erfasst und gespeichert werden. Aus den übertragenen Sensorsignalen lassen sich über Berechnungen folgende Werte ermitteln: • • • • • • • • • •

Druck vor dem Hydromotor Druck nach dem Hydromotor Drehzahl Antriebswelle Band Fahrgeschwindigkeit aus GPS-Signal Aufnahmeband-Abstand aus Sensitec-Signal Temperatur am Sensitec-Sensor (erst mit der 2. Sensorgeneration). Aktuelle Leistung des Motors Kumulierte Leistung Aktuelle Aufnahmebandgeschwindigkeit Verhältnis Aufnahmebandgeschwindigkeit zu Fahrgeschwindigkeit

6  Anwendungsfall GRIMME

161

Zur Auswertung der Daten wurde auf die Programmiersprache R zurückgegriffen. Eine Besonderheit ergab sich bei der Aufbereitung der Daten zur Berechnung des Aufnahmebandabstands. Wie im nächsten Abschnitt beschrieben wird, ist zur Auswertung eine Si­ gnaldauer von ca. 30 Sekunden notwendig. Durch das verwendete Übertragungsprotokoll (MQTT), das eine sichere, einmalige Übertragung gewährleistet, waren die übertragenen Datenpakete (Chunks) nicht mehr in der richtigen Reihenfolge, sodass zur Auswertung zunächst die Datenpakte geprüft und zusammenhängende, auswertbare Cluster erstellt werden. Die Auswertung dieser wichtigen Größe wird im nächsten Abschnitt dargestellt.

6.4.1.2 Auswertung der Bandlänge Die für die Verfügbarkeit wichtige Größe beim Varitron ist die Längung des Aufnahmebandes. Um die Verfügbarkeit zu gewährleisten wird mit Hilfe des Sensitec-Sensors ein Signal übertragen, das sowohl die einzelnen Stäbe als auch das Schloss des Aufnahmebandes erfassen soll. Für die Berechnung der Banddehnung ist ein Auswerteschema von Sensitec nach Abb. 6.49 vorgesehen. Zur Bestimmung der Bandlängung wird eine Messgröße definiert, die den Quotienten aus dem mittleren Stababstand der Stäbe vor und nach dem Schloss und der Schlosslänge darstellt. Dieser Quotient ist unabhängig von der Bandgeschwindigkeit und kann somit als Größe für die Veränderung des Bandes herangezogen werden. In der Praxis hat es sich jedoch als schwierig – und unter bestimmten Bedingungen auf dem Acker sogar als unmöglich – erwiesen, das Schloss und die einzelnen Stäbe davor und danach prozesssicher zu detektieren. Zur Auswertung wurde deshalb auf die Vorarbeiten von MTS im Rahmen dieses Vorhabens zurückgegriffen und folgendes Vorgehen für die

Abb. 6.49  Sensitec-Signal und Auswerteschema

162

P. Sivasothy et al.

Auswertung des Sensitec-Signals entwickelt. Der Workflow des entwickelten Algorithmus untergliedert sich in die folgenden Schritte: • Das reale Sensorsignal wird mittels einer Fensterfunktion (beispielsweise Von-HannFenster) in einem Zeitbereich von ca. 30 Sekunden für die weitere Datenanalyse gefiltert. • Durch eine Fast-Fourier-Transformation (FFT) des gefensterten Signals kann die Stabfrequenz f_Stab bestimmt werden. • Durch die Autokorrelationsfunktion (Auto Correlation Function - ACF ) des gefensterten Signals kann die Bandperiode T_Band (Schloss) bestimmt werden. Aus der berechneten Stabfrequenz f_Stab und Bandperiode T_Band (Schloss) kann, wie im Folgenden beschrieben, der Bandzustand bestimmt werden. Für ein Band, das aus n Stäben und einem Schloss besteht, gilt für die Längen:

LBand = LSchloss + n ∗ LStab

Bei konstanter Geschwindigkeit v, ist

L∗ = v ∗ T∗

und damit

TBand = TSchloss + n ∗ TStab LSchloss TSchloss TBand = = − n = TBand ∗ f Stab − n LStab TStab TStab

Damit lässt sich der gesuchte Quotient zur Beurteilung des Bandzustands aus dem Sensor-­ Signal ermitteln und kann für die Beurteilung des Bandzustands herangezogen werden. Die Auswertung der Daten erfolgte mithilfe der Programmiersprache R auf einem RStudio-Server, der den Vorteil bietet, dass mithilfe eines Cron-Jobs automatisiert die Daten vom Telekom-Server abgerufen, zwischengespeichert, ausgewertet und die Ergebnisse in die Datenbank zurückgeschrieben werden können. Diese Ergebnisse stehen dann anderen Anwendungen im Vorhaben zur Verfügung.

6.4.2 Entwicklung des Maschinen-Front-Ends bei GRIMME Im Use-Case GRIMME kommt ein hardwareunabhängiges Maschinen-Front-End (MFE) zum Einsatz, welches die relevanten Informationen über den Maschinenzustand und die

6  Anwendungsfall GRIMME

163

Services zur Verfügung stellt. Dem Fahrer der Maschine wird der Zustand des Aufnahmebandes als Ampel und als Verschleißanzeige angezeigt. Es ist weiterhin die Möglichkeit zum Austausch des Bandes aus einer Auswahl der verfügbaren Bänder gegeben. Darüber hinaus wird der Austausch des Bandes für einen Servicetechniker durch Wartungsinformationen an der Maschine unterstützt. Abb. 6.50 zeigt die Anbindung des ISOBUS-Front-Ends (IFE) über den ISOBUS und die Anbindung des Web-Front-Ends (WFE) über WLAN an das Steuerungssystem der Maschine. Das Steuergerät M50 stellt den WebVisu-Server. Die CODESYS WebVisu wurde in Abschn. 5.5.3 „Entwicklung des Maschinen-Front-Ends“ vorgestellt. Das Gateway W30 ist mit dem Steuergerät M50 über Ethernet verbunden und spannt ein WLAN-­ Netz auf, mit dem sich ein mobiles Gerät, wie ein Laptop oder ein Tablet, verbinden kann. Ist ein HTML5-fähiges Gerät ein Teil des Netzwerks, so kann dies auf den WebVisu-­ Server vom M50 zugreifen und die Visualisierung anzeigen. Die Absicherung des WLANs mit entsprechenden Schlüsseln beschränkt den Benutzerkreis auf autorisierte Personen. Die Hardwareunabhängigkeit des Front-Ends ist über das WebVisu-Konzept auf Basis von HTML5 realisiert, so kann jede beliebige Hardware (Laptop, Tablet, Smartphone, etc.) eingesetzt werden, die einen HTML5-fähigen Browser zur Verfügung stellt und sich mit dem WebVisu-Server des M50 verbindet. In der Fahrerkabine des Varitron 470 ist ein ISOBUS-fähiges Bedienterminal vorhanden, mit dem der Fahrer den Erntevorgang im Varitron steuert. Der ISOBUS-UT-Client des Steuergeräts M50 verbindet sich mit dem ISOBUS-UT-Sever auf dem Bedienterminal. Auch bei den ISOBUS-Bedienterminals ist eine entsprechende Hardwareunabhängigkeit realisiert, Geräte mit verschiedenen Displaygrößen und Ausstattungsmerkmalen verschiedener Hersteller lassen sich einfach mit dem M50 verbinden, das Maschinen-Front-End wird automatisch in das angeschlossene Bedienterminal geladen.

:/$1

(WKHUQHW

&R'H6\V :HE9LVX 6HUYHU ,62%8687 &OLHQW

+WPOIlKLJHU %URZVHU

*DWHZD\:

6WHXHUJHUlW0

&$1

:)(DXI7DEOHW

,62%8687 6HUYHU

,)(DXI%H GLH QWHUPLQDO 7L 



Abb. 6.50  Anbindung an das Maschinen-Front-End von im Use-Case GRIMME

164

P. Sivasothy et al.

Die Funktion des ISOBUS ist in Abschn.  5.5.3 „Entwicklung des Maschinen-­Front-­ Ends“ vorgestellt. Die folgenden Abbildungen zeigen eine repräsentative Auswahl von Bildern für das Maschinen-Front-End im Use-Case GRIMME. Auf der obersten Ebene des Front-Ends wird jeweils eine Übersicht der Maschine visualisiert, siehe Abb. 6.51. Diese ist für den Fahrer der Maschine gedacht. Es werden die Maschine, die Zustandsampel und verschiedene Buttons für Untermenüs abgebildet. Die Zustands-Ampel zeigt in den Farben Rot (Kritisch), Gelb (Achtung) und Grün (OK) den gesamten Zustand der Maschine an. Falls keine Lampe leuchtet, ist zurzeit keine Zustandsinformation verfügbar. In der Übersicht ist der Zustand der gesamten Maschine abgebildet, der sich aus den Zuständen einzelner Komponenten ableitet. Die Buttons dienen dazu, in die jeweilige Ansicht der überwachten Komponente und in verschiedene Untermenüs für den Servicetechniker zu wechseln. Die Untermenüs sind „Bandbestellung“ und „Wartungshinweise“. Die Abb. 6.52 zeigt die Ansicht einer einzelnen zu überwachenden Komponente an. Es werden zwei Siebbänder am Varitron 470 überwacht, die jeweils von den gleichen Sensoren überwacht werden. Jede Komponenten-Ansicht besitzt, wie die Maschinenübersicht, ein Bild der Komponente mit dazugehöriger Zustandsampel. Mit der Zustandsampel wird der Verschleißzustand der jeweiligen Komponente abgebildet, wobei eine grüne Ampel für einen niedrigeren Verschleiß steht, die gelbe Ampel für einen hohen Verschleiß und die rote Ampel für einen kurz bevorstehenden Ausfall. Es werden hier ausgewählte Messgrößen zusätzlich über automatisch aktualisierende Diagramme präsentiert. Anhand der Diagramme können Fehler oder ein untypisches Verhalten der Komponente erkannt werden.

Abb. 6.51  Use-Case GRIMME: Maschinenzustand

V

V

V

V

'UXFN6HQVRU5FNODXI>P$@

V

'UXFN6HQVRUYRUODXI>P$@

V

V

V

V

Abb. 6.52  Use-Case GRIMME: Band links

V

V

V

       











0RWRU=lKOHU>+]@

V

V

V =XVWDQG

YRUKHULJH

QlFKVWH

.RPSRQHQWH%DQGOLQNV .RPSRQHQWHQ]XVWDQG

6  Anwendungsfall GRIMME 165

166

P. Sivasothy et al.

Die Buttons „nächste“ und „vorherige“ werden dazu genutzt, um zwischen den Komponenten der Maschine zu navigieren. Zurück zum Startbildschirm gelangt man mit dem Button „Zustand“. Die angezeigten Datenverläufe stellen relevante Informationen über die ausgewählte Komponente aufgrund aktueller Sensordaten dar. Diese sind im Falle des Aufnahmebandes von GRIMME in dieser Abbildung die Taktfrequenz des Antriebsmotors, der Öldruck vor dem Antriebsmotor und der Öldruck hinter dem Antriebsmotor. Im Unter-Menü „Bandbestellung“ kann der Benutzer eine Bestellung für ein neues Aufnahmeband nach Bedarf auslösen, siehe Abb.  6.53. Am Varitron 470 werden zwei Siebbänder in Fahrtrichtung „links“ und „rechts“ eingesetzt. Pro Platz „links“ und „rechts“ ist der aktuell eingesetzte Typ zu sehen, im Beispiel „300.54321 Afnb 40 Tlg“. Der Typ des zu bestellenden Aufnahmebandes kann im Auswahlmenü gewählt und anschließend für die betreffende Seite bestellt werden. Es werden nur die Bandtypen im Auswahlfenster aufgelistet, die von der Maschine verwendet werden können. Es kann nur eine Bestellung pro Band verwaltet werden, daher wird der Bestellungsbutton bis zum Austausch des Bandes deaktiviert. Das Untermenü „Wartungshinweise“ zeigt dem Front-End-Betrachter eine Anleitung (siehe Abb. 6.54) und erläutert, wie die Aufnahmebandschlösser zu pflegen sind, um die Langlebigkeit und Betriebssicherheit zu gewährleisten. Die Wartung besteht aus mehreren Schritten, zwischen denen mit den Buttons „vorheriger Schritt“ und „nächster Schritt“ gewechselt wird. Der Button „Band ausgetauscht“ triggert die Übernahme des nächsten bestellten Bandes zum aktuellen Band.

%DQGEHVWHOOXQJ $XVZDKO $IQE7OJ

%DQGOLQNV $NWXHOOYHUZHQGHWHV%DQGOLQNV

$IQE7OJ

1lFKVWHQVHLQ]XEDXHQGHV%DQG

$IQE7OJ

%HVWHOOXQJ

%DQGUHFKWV $NWXHOOYHUZHQGHWHV%DQGUHFKWV

$IQE7OJ

1lFKVWHQVHLQ]XEDXHQGHV%DQG

$IQE7OJ

]XUFN

Abb. 6.53  Use-Case GRIMME: Bandbestellung

%HVWHOOXQJ





%DQGDXVJHWDXVFKW

]XUFN

Abb. 6.54  Use-Case GRIMME: Wartungshinweise

QlFKVWHU6FKULWW

YRUKHULJHU6FKULWW

6FKUDXEHQW\S0 $Q]XJVPRPHQW1P

±QDFKGHUHUVWHQ%HODVWXQJ ±QDFK%HWULHEVVWXQGHQ ±GDQDFKDOOH%HWULHEVVWXQGHQ

'LH6FKUDXEHQYHUELQGXQJHQ XQG9HUVFKOHL‰EXFKVHQ  GHU6LHEEDQGVFKO|V VHUEHGUIHQHLQHUEHVRQGHUHQ3IOHJHXPGLH%HWULHEVVLFKHUKHLWVRZLHGLH/DQJOHELJ NHLW]XHUKDOWHQ 'LH6FKUDXEHQYHUELQGXQJHQVLQGLQIROJHQGHQ$EVWlQGHQDXIIHVWHQ6LW]]XSUIHQ







:DUWXQJVKLQZHLVH

6  Anwendungsfall GRIMME 167

168

P. Sivasothy et al.

Literatur 1. Ströer F, Sivasothy P, Faißt KG et al (2017) Combined development and test of product-service systems in early product development stages for customized, availability-oriented business models in the capital goods industry. Procedia CIRP 72:714–719 2. Hatami H (2013) Hydraulische Formelsammlung. Rexroth Bosch Group. https://www.boschrexroth.com/business_units/bri/de/downloads/hyd_formelsammlung_de.pdf. Zugegriffen 24.04.2017 3. GIA (2001) Kegelradgetriebe. Gesellschaft für innovative Automationstechnik mbH. http://giambh.com/broschueren/Kegelradgetriebe.pdf. Zugegriffen am 22.10.2017 4. Wagner J (2013) Mechanische Systeme – Dynamik III. Institut für Statik und Dynamik der Luftund Raumfahrtkonstruktionen  – Universität Stuttgart. http://www.isd.uni-stuttgart.de/lehre/diplom/skript/Dyn_III_K8.pdf. Zugegriffen am 12.10.2017 5. DIN EN ISO 16610-21 (2013) Geometrische Produktspezifikation (GPS) – Filterung – Teil 21: Lineare Profilfilter: Gauß-Filter (ISO 16610-21:2011) 6. Dunn PF (2005) Measurement and data analysis for engineering and science. McGraw-Hill, New York 7. Meyer M (2014) Signalverarbeitung: Analoge und digitale Signale, Systeme und Filter, 7. Aufl. Springer Vieweg, Wiesbaden, verb

7

Anwendungsfall John Deere Thomas Eickhoff, Hristo Apostolov, Jan C. Aurich, Christian Donges, Matthias Fischer, Jens C. Göbel, Christoph F. Herder, Patrick Kölsch, Claudia Schrank, Siegfried Trendler und Viviane Zimmermann

Zusammenfassung

Nicht jeder Ausfall ist vorhersehbar oder vermeidbar. Für verfügbarkeitsorientierte Geschäftsmodelle ist eine schnelle und effiziente Instandsetzung ein wichtiger Erfolgsfaktor. Die Instandsetzung kann mithilfe interaktiver, visueller Handlungsanweisungen auf einem mobilen Endgerät Schritt für Schritt unterstützt und beschleunigt werden. Gleichzeitig können die einzelnen Schritte auf Richtigkeit geprüft und

T. Eickhoff (*) · H. Apostolov · J. C. Göbel Lehrstuhl für Virtuelle Produktentwicklung, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected]; [email protected] J. C. Aurich · C. F. Herder · P. Kölsch Lehrstuhl für Fertigungstechnik und Betriebsorganisation, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected]; [email protected] C. Donges · M. Fischer :em engineering methods AG, Darmstadt, Deutschland E-Mail: [email protected]; [email protected] C. Schrank John Deere GmbH & Co. KG European Technology Innovation Center, Kaiserslautern, Deutschland S. Trendler John Deere GmbH & Co. KG European Technology Innovation Cente, Kaiserslautern, Deutschland V. Zimmermann Unity AG, Stuttgart, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 J. C. Aurich et al. (Hrsg.), Entwicklung datenbasierter Produkt-Service Systeme, https://doi.org/10.1007/978-3-662-59643-2_7

169

170

T. Eickhoff et al.

dokumentiert werden. Wichtig ist, dass die Handlungsanweisungen im Kontext stehen und die ­richtigen Informationen in Bezug auf die konkrete Produktvariante und die durchzuführenden Reparaturen anzeigen. Dazu muss auf Daten aus dem Produktlebenszyklus zugegriffen werden und Bauteile müssen entsprechend dem räumlichen Kontext in ihrer Position und Ausrichtung visualisiert werden können. Das Kapitel beschreibt die Entwicklung des verfügbarkeitsorientierten Geschäftsmodells und dessen Realisierung durch eine interaktive, visualisierte Schritt-für-Schritt-Reparaturanleitung.

7.1

Einleitung

Auch in der landwirtschaftlichen Produktion halten die Ziele von Industrie 4.0 Einzug. Von Herstellern im Bereich Landtechnik werden in diesem Zuge Angebote für intelligente Produkte und Dienstleistungen vorangetrieben, die die Verfügbarkeit und Produktivität ihrer Maschinen und Geräte erhöhen und Prozesse optimieren. Die Landmaschinen werden in diesem Zug mehr und mehr zu vernetzen Werkzeugmaschinen. Derzeit angebotene Lösungskonzepte umfassen z. B. die Zustandsfernüberwachungen von Maschinen, datenbasiertes Benchmarking z.  B. bezüglich Produktivität und andere Key Performance Indicators und Systeme für das Flottenmanagement sowie die Prozessüberwachung [1]. Grundlegende Technologien dieser Entwicklungen sind höhere Rechenleistungen für die Steuerungssysteme, eine höhere Geschwindigkeit im Steuerungsablauf sowie eine zunehmende Vernetzung und Einbindung kommunikationsfähiger Komponenten [2]. Diese Entwicklungen verändern nicht nur die Abläufe in der landwirtschaftlichen Produktion, sondern bereiten auch den Weg für neue Geschäftsmodelle. Dazu gehören verfügbarkeitsorientierte Geschäftsmodelle, bei denen der Anbieter landtechnischer Geräte und Maschinen dem Kunden die Einsatzfähigkeit der Maschinen garantiert und dadurch ein besonderes Maß an Flexibilität schafft, um auf dynamische Entwicklungen am Markt und Veränderungen des Kundenbedarfs einzugehen. Bei verfügbarkeitsorientierten Geschäftsmodellen in der Landwirtschaft ist zu beachten, dass ungeplante Fehler, Ausfälle und Schäden nicht vollständig vermeidbar und vorhersehbar sind. Denn weiterhin gibt es viele Bauteile, die nicht durch Sensoren überwacht werden. Außerdem sind die Einsatz- und Umgebungsbedingungen sehr heterogen und nur einige relevante Parameter können erfasst werden [3]. Es ist also nicht möglich, mithilfe von Sensoren und Modellen in allen Fällen Fehler und Schäden an den Maschinen und Geräten zu prognostizieren. Daher sind besonders bei verfügbarkeitsorientierten Geschäftsmodellen auch Lösungen notwendig, die dann greifen, wenn es zu unvorhergesehen Ausfällen kommt. Das Ziel dieser Lösungen ist, die Verfügbarkeit schnell wiederherzustellen. Um dieses Ziel zu erreichen, ist ein schneller Serviceprozess entscheidend. Die Zeit, die vom Eintritt eines

7  Anwendungsfall John Deere

171

Fehlers/Schadens bis zur Wiederherstellung der Verfügbarkeit des Produktes vergeht, kann von verschiedenen Faktoren abhängen. Dazu gehören u. a.: • • • • • •

Zeit für die Diagnose Zeit für die Bereitstellung von Ersatzteilen und notwendigen Werkzeugen Zeit für das Einbeziehen qualifizierter Personen Zeit für Auseinanderbau/Demontage fehlerhafter Teile Zeit für die Montage/Einbau von Ersatzteilen Zeit für die Dokumentation

An dieser Stelle ordnet sich der Anwendungsfall der John Deere GmbH & Co. KG (im Weiteren nur „John Deere“) ein, denn dieser bezieht sich auf einen intelligenten Service mit interaktiven, visuellen Handlungsanweisungen. Die Vision ist, dass bei einem Fehler oder Schaden an den Landmaschinen der Mensch (z. B. Kunde, Servicetechniker) bei der Reparatur mit einem mobilen Endgerät (z.  B.  Smartphone, Tablet oder Augmented-­Reality-­ Brillen) je nach Bedarf unterstützt wird. Auf dem mobilen Endgerät wird, z. B. nach dem Abscannen der Seriennummer der Maschine, die aktuelle Produktkonfiguration aufgerufen und die Position der Teile entsprechend der Konfiguration der Maschine angezeigt. Das Gerät kann die reale Welt mit virtuellen Daten und Informationen ergänzen und so unterstützen. Die genauen Schritte für Fehlersuche, Demontage bzw. Montage werden gezeigt. Jeder Schritt wird auf Richtigkeit geprüft, dokumentiert und falls notwendig werden Fotos und Informationen im richtigen Kontext gespeichert und an anderer Stelle zur Verfügung gestellt. Der Nutzer des Systems hat die Möglichkeit, sich bei allen Schritten durch den gesamten Prozess führen zu lassen. Er kann aber auch an einer beliebigen Stelle einsteigen oder zwischen verschiedenen Endgeräten und Unterstützungsformen wechseln. Visuelle Handlungsanweisungen bis hin zu Augmented-Reality-Anweisungen, die genau zu der vorliegenden Produktkonfiguration passen und den Kunden oder Servicetechniker Schritt für Schritt zu Fehlerfindung und -behebung anleiten, können als intelligenter Service angeboten (z. B. Pay per Download, Pay per Use) werden und auch bei geplanten Stillständen (Predictive Maintenance) zum Einsatz kommen. Langfristig wird die Maschinenverfügbarkeit erhöht, indem Schadensinformationen oder Ausfallraten einer ­Komponente in einer bestimmten Konfiguration in Konstruktion und Produktion zurückgespielt, damit Fehler reduziert und kritische Situationen vermieden werden können. Im Rahmen des im Projekt entwickelten Demonstrators wird dargestellt, wie mit Hilfe unterschiedlicher Endgeräte, eines innovativen Front-Ends und von Technologien aus dem Bereich Augmented Reality die reale Welt mit virtuellen Geometrien überlagert und ein schneller Serviceprozess ermöglicht werden kann. Neben den Entwicklungen im Bereich Front-End, erfordert der Anwendungsfall eine datentechnische Integration über verschiedene Prozesse und Ebenen hinweg (siehe Abb. 7.1). Die Durchgängigkeit der Informationen umfasst dabei die horizontale Integration, die vertikale Integration sowie die digitale Durchgängigkeit des Engineerings [4]. Die horizontale

172

T. Eickhoff et al.

Abb. 7.1  Datentechnische Integration – Anwendungsfallrelevante John-Deere-Prozesse

Integration meint die Datendurchgängigkeit zu Partnern, Lieferanten und Kunden und bezieht sich auf den Informationsaustausch zwischen Unternehmen innerhalb eines Wertschöpfungsnetzwerkes [5]. Dagegen beschreibt die vertikale Integration den unmittelbaren Zugriff auf Feld- und Planungsinformationen innerhalb einer Organisation von der Produktentstehung über die Entwicklung und Fertigung bis hin zum fertigen Produkt. Demgegenüber befasst sich die digitale Durchgängigkeit des Engineerings ganz allgemein mit dem Lebenszyklus von Produkten und Produktionsmitteln [3]. Bei der datentechnischen Integration ist die hohe Variantenvielfalt zu beachten, die sich aus individuellen Kundenbedürfnissen ergibt. Die Vielfalt der Varianten zeigt sich z. B. in der Tagesproduktion von Traktoren des John Deere Werkes Mannheim. Dort werden bis zu 200 Traktoren an einem Tag gefertigt, wobei jeder dieser Traktoren ein Unikat darstellt und eine andere Spezifikation aufweist. Erreicht wird diese Vielfalt durch einen ­Modulbaukasten, indem für jede funktionsbedingende Baugruppe aus einer Menge an Varianten gewählt werden kann. Durch die Kombination der Variationsmöglichkeiten ergibt sich eine insgesamt sehr hohe Zahl an Varianten, die ein spezielles Variantenmanagement erforderlich machen (siehe Abb. 7.2). Die besondere Herausforderung der angestrebten Datendurchgängigkeit besteht nun darin, dass sich diese nicht nur auf textuelle und nummerische Daten wie z. B. Stückliste oder Arbeitsplan bezieht, sondern darüber hinaus Geometriedaten funktionaler Baugruppen in den Mittelpunkt der Betrachtung rückt (siehe Abb.  7.3). Die Verwendung von CAD-Daten als wesentliches Element in der Bereitstellung von visuellen Handlungsanweisungen bedeutet, dass jede Baugruppe in der CAD-Gesamtdarstellung jeder spezifischen Produktkonfiguration lagerichtig dargestellt werden muss. Ist dies nicht gegeben, so werden z. B. Leitungsverlegungen in der visuellen Handlungsanweisung nicht an der zu montierenden Stelle dargestellt. Daraus würde eine ineffiziente und zeitraubende Instandsetzung resultieren, da weitere Informationen beschafft werden müssen, um die genau Lage und Ausrichtung zu klären. Für eine gegebene funktionale Baugruppe ergeben sich nun bei gleichbleibender Stückliste produktkonfigurationsabhängig unterschiedliche CAD-Positionsdaten, was zu

7  Anwendungsfall John Deere

Abb. 7.2  Schematische Darstellung des Traktor-Modulbaukastens

Abb. 7.3  Geometriemodelle gleicher Baugruppen bei unterschiedlichen Varianten

173

174

T. Eickhoff et al.

einer zunehmenden Komplexität sowohl im Variantenmanagement als auch bei der ­Datendurchgängigkeit führt. Dabei ist die Aufgabenstellung von CAD-Variantenmanagement insbesondere auch im Hinblick auf die Integration heterogener Datenlandschaften wie SAP, Siemens PLM etc. herausfordernd. Die nachfolgenden Kapitel zur Entwicklung des Back-­Ends und Front-Ends gehen auf diesen Sachverhalt detailliert ein. Insbesondere innovative Technologien wie Augmented Reality werden von einer um die CAD-Per­ spektive erweiterten Datendurchgängigkeit profitieren können.

7.2

 pezifische Konzeption eines verfügbarkeitsorientierten S Geschäftsmodells bei der John Deere GmbH & Co. KG

Zur Konzeption des vGM innerhalb des Anwendungsfalls John Deere wurde das in Kap. 3 vorgestellte Konzept durchlaufen. Der Prozess zur Entwicklung eines vGM wurde aufgrund interner Ideenansätze zur Implementierung und Erweiterung eines Digitalen Zwillings initiiert. Der Prozess wird somit technologiegetrieben durchlaufen und die Phasen 1 und 2 entfallen. Die erzielten Ergebnisse werden nachfolgend dargestellt. Phase 3 – Beschreibung des Anwendungsfalls In dieser Phase wurde zuerst der Use-Case textuell in einem Template beschrieben, wobei unterschiedliche Komponenten betrachtet wurden. Das Template wurde gemeinsam in Workshops mit den Projektpartnern befüllt. Das Template wird im Anhang dargestellt. Die Kurzfassung des Use-Cases ist folgende: Komponente: 1) Traktorgetriebe, 2) Kotschützer am Traktor Use-Case: Im Falle eines technischen Ausfalls muss die Verfügbarkeit durch Instandsetzung schnellstmöglich wiederhergestellt werden. Die Anreise des Servicetechnikers kann sich durch unterschiedliche Ereignisse verzögern, sodass der Kunde sein Sachprodukt (landwirtschaftliche Maschine) in dieser Zeit nicht nutzen kann. Eine Schritt-für-­SchrittAnleitung, die den Kunden durch die Instandsetzung führt, wäre bei selbst behebbaren Fehlern eine alternative Möglichkeit der Instandsetzung. Jedoch existieren für eine Vielzahl an Komponenten mehrere Einbauvarianten (im Use-Case exemplarisch durch o.g. Komponenten dargestellt), die je nach Ausführung des Produkts angepasst werden müssen. Dem Kunden muss somit die richtige Einbauvariante zu seinem Produkt vorliegen, da ansonsten Fehlfunktionen oder Schäden auftreten können. Ein digitaler Zwilling, der die genaue Konfiguration der landwirtschaftlichen Maschine widerspiegelt und die Komponenten am Produkt genau räumlich zuordnet bzw. lokalisiert, ist daher unabdingbar. Eine konfigurationsspezifische Schritt-für-Schritt-Anleitung verhindert somit eine fehlerhafte Montage. Ziel: Beschleunigung des Instandsetzungsprozesses durch die Kombination eines digitalen Zwillings und interaktive Schritt-für-Schritt-Reparaturanleitungen auf einem mobilen Endgerät zur Erhöhung der Verfügbarkeit. Damit konnte die dritte Phase abgeschlossen und die nächste Phase „Bedürfnisanalyse und Lösungsideen“ initiiert werden.

7  Anwendungsfall John Deere

175

Phase 4 – Bedürfnisanalyse und Lösungsideen Auch John Deere hat ein zweistufiges Vertriebssystem und verkauft die Sachprodukte an einen John-Deere-Vertriebspartner. Dieser wiederrum bedient Kunden verschiedener Größe mit Sach- und Serviceprodukten. Für diesen Use-Case wurde die gleiche Kundengruppe gewählt und Mr. Miller als Persona erstellt. Der gewählte Kunde bzw. Kundengruppe arbeitet in einem Großbetrieb und nutzt dafür einen Traktor von John Deere. Für die Customer Journey wurde wieder der Prozess „Ein Tag während der Ernte“ aufgenommen. Durch die Ausrichtung des Use-Cases musste der Ausfall des Traktors zwingend mit in den Prozess aufgenommen werden. Der gewählte Prozess sowie die aufgenommenen Bedürfnisse, die identifizierten Serviceideen sowie die daraus abgeleiteten Systemanforderungen werden in der nachfolgenden Abb. 7.4 visualisiert. Auch hier wurden die Inhalte in einem Workshop gemeinsam mit den Partnern erarbeitet. Die abgeleiteten Bedürfnisse nach einem Schadenfall konnten mit in die Ausgestaltung des Use-Cases aufgenommen werden.

Abb. 7.4  Customer Journey im Use-Case John Deere

176

T. Eickhoff et al.

Nach der Analyse der Kundenbedürfnisse und der Bestätigung, dass der angestrebte Use-Case auch tatsächlich bestehende Kundenbedürfnisse befriedigt, konnte das ­Geschäftsmodell in der anschließenden Phase detailliert ausgearbeitet werden. Phase 5 – Detaillierung des Geschäftsmodells Auch in diesem Use-Case wurden erste Informationen aus der Use-Case-Beschreibung in den Business Model Canvas (BMC) übernommen. Die weiteren Elemente des BMC wurden in dieser Phase detailliert ausgefüllt. Der daraus resultierende BMC findet sich in der nachfolgenden Abb. 7.5. Nach der Ausarbeitung des Geschäftsmodells mussten die Beziehungen zwischen den Schlüsselelementen definiert werden. Dazu wurde die nächste Phase „Planung der Partner, Ressourcen und Interaktionen“ initiiert. Phase 6 – Planung der Partner, Ressourcen und Interaktionen In dieser Phase wurde das erweiterte Wertschöpfungsnetzwerk (eWN) mit den notwendigen Schlüsselpartnern und Schlüsselressourcen visualisiert. Die nachfolgende Abbildung Abb.  7.6 zeigt das resultierende eWN für den Use-Case John Deere. Dieses wurde gemeinsam mit den Partnern in einem Workshop erarbeitet. Die notwendigen Partner und Ressourcen zur Realisierung des Use-Cases sind: • John Deere und John Deere Vertriebspartner (als PSS-Anbieter) • Landwirtschaftlicher Großbetrieb (als Kunde) • Cloud-Betreiber und Zulieferer für das Informationsmanagement – im konkreten Fall Zulieferer für den Engineering Backbone und Digitalen Zwilling Zwischen den dargestellten Partnern und Ressourcen wurden die jeweiligen Informations-, Geld- und Warenflüsse eingetragen. Damit die ersten Systemanforderungen für die technische Entwicklung definiert werden können, wird die nächste Phase „Planung der Umsetzung“ initiiert. Phase 7 – Planung der Umsetzung Auch in diesem Use-Case wurde zur Planung der Umsetzung und zur Weitergabe der ersten technischen Anforderungen zuerst eine Prozessanalyse in einem Workshop durchgeführt. Die adressierten Prozessschritte betrachten den Zeitraum, nachdem eine Störung an der Maschine aufgetreten ist, und setzen sich wie folgt zusammen: • • • •

Schaden identifizieren und beheben Fehlerhaften Kotschützer demontieren Neuen Kotschützer montieren Testlauf

7  Anwendungsfall John Deere

Abb. 7.5  Business Model Canvas im Use-Case John Deere

177

178

T. Eickhoff et al.

Abb. 7.6  Erweitertes Wertschöpfungsnetzwerk im Use-Case John Deere

Für jeden Prozessschritt wurden Systemanforderungen erhoben, die umgesetzt werden müssen, um den Use-Case zu realisieren. Ein Masterplan of Action wurde aufgrund fehlender Ressourcen nicht durchgeführt. Die Prozessanalyse für die Phase „Schaden identifizieren und beheben“ mit den definierten Anforderungen wird in Abb. 7.7 dargestellt. Die Systemanforderungen müssen in einem nächsten Schritt in technische Anforderungen überführt werden. Die Ergebnisse bilden die Grundlage für die in den nächsten Kapiteln dargestellte technische Entwicklung.

7.3

 usgewählte Elemente des intelligenten A Informationsmanagements

An der Umsetzung des Informationsmanagements im Anwendungsfall John Deere lässt sich die Komplexität des Datenmanagements für variantenreiche Produkte gut erkennen. Jeder einzelne Traktor verfügt über eine individuelle Konfiguration. Im Rahmen von InnoServPro wurde untersucht, wie diese Komplexität beherrschbar gemacht werden kann, um durch gezielte Informationsbereitstellung Servicearbeiten zu beschleunigen.

7  Anwendungsfall John Deere

179

Abb. 7.7  Prozessanalyse für die Phase "Schaden identifizieren und beheben" im Use-Case John Deere

7.3.1 Entwicklung des Back-Ends Aus Sicht des Back-Ends gliedern sich die Daten zu einem variantenreichen Produkt in zwei Ebenen: Die allgemeine Beschreibung des Produktes mit allen seinen Ausprägungen liegt hierbei als Variantenstückliste bzw. „150 %-BOM“ im digitalen Master vor. Hieraus soll für jede Maschine ein individuelles Abbild (der digitale Zwilling, siehe Abschn. 5.5.2.3) erstellt werden, das nur die tatsächlich verbauten Bauteile in der passenden Konfiguration enthält. Für die Modelldaten soll auf den Master zurückreferenziert werden. Die Variantenstückliste Im Kontext des Product Lifecycle Managements dient üblicherweise die Konstruktionsstückliste (bzw. Engineering Bill of Materials) eines Produktes als zentraler Aufhängungspunkt für Daten über das Produkt. Diese Stückliste liegt als Baum vor, d. h. unter dem Wurzelknoten des Produktes liegen mehrere Teilkomponenten, die ihrerseits wieder aus Komponenten bestehen können, bis man schließlich Bauteile erreicht, die nicht weiter untergliedert werden. Soll nun ein Produkt mit mehreren möglichen Konfigurationen verwaltet werden, bestehen mehrere Möglichkeiten, diese in einer oder mehreren Stücklisten zu verwalten. Für eine detaillierte Betrachtung sei auf [6] verwiesen. Im Kontext des Projektes kommt eine Optionsstückliste zum Einsatz, welche ein Kompromiss aus der in der Quelle genannten regelbasierten Variantenstückliste und der Implementierung im Aras Variants Package darstellt [7].

180

T. Eickhoff et al.

Soll ein Bauteil nur in bestimmten Konfigurationen verbaut werden, so wird es in der Stückliste durch einen Optionsknoten ersetzt. Dieser beinhaltet Informationen darüber, welche Bauteile bei welcher vorliegenden Kombination von Optionscodes zu verbauen sind. Beim Konfigurieren des Produktes wird nun eine Menge von Optionscodes angegeben, welche die gewünschte Konfiguration eindeutig bestimmen.

Die Komplexität dieser beiden Ebenen ist für den Anwendungsfall John Deere von entscheidender Bedeutung. Dementsprechend folgt hier ein kurzer Abriss über die Datenelemente und -relationen der beiden Ebenen.

7.3.1.1 Der digitale Master Der digitale Master beinhaltet alle einem Produkt zugeordneten Baugruppen und Bauteile (inkl. möglicher Positionierungen), aus denen sich durch Konfiguration die unterschiedlichen Produktvarianten erstellen lassen. An entsprechenden Baugruppen- und Bauteilknoten können darüber hinaus technische Dokumentationen, Repräsentationen (bspw. zwei- und dreidimensionale Repräsentationen) sowie zugehörige Service- und Status-Strukturen angehängt werden. Daneben werden hier auch Verschleißmodelle und kritische Zustände zugeordnet. Eine weitere Besonderheit im Projekt liegt darin, dass die Positionierung einzelner Baugruppen bzw. Teile in der Beziehung zwischen übergeordneter und untergeordneter Komponente gespeichert wird. Um die Baum-Metapher aus der Beschreibung der Variantenstückliste aufzugreifen, könnte man auch sagen, die Informationen liegen auf der Kante zwischen zwei Knoten (siehe Abb. 7.8). Dies hat zur Folge, dass im Falle von Optionsknoten für unterschiedliche Konfigurationen die gleichen Bauteile in unterschiedlichen Positionierungen verbaut werden können. Dies ist z.  B. erforderlich, wenn ein Bauteil nach Möglichkeit an Position A verbaut werden soll, jedoch bei einigen Konfigurationen

Abb. 7.8  Ausleiten des digitalen Zwillings aus der Variantenstückliste

7  Anwendungsfall John Deere

181

auf die schwerer zugängliche Position B ausgewichen werden muss, da in diesen Konfigurationen andere Bauteile den Platz an Position A einnehmen. Da für die Master-Ebene der normale Aras-Itemtype „Part“ nur angepasst wurde, konnten die verschiedenen Varianten in der 150 %-BOM mit dem Aras-Variants-Package abgebildet werden. Dieses sieht vor, dass die Auswahlmöglichkeiten in der 150 %-BOM mit einer Kombination von Optionscodes (die mit den logischen Operatoren UND, ODER und NICHT verknüpft werden können) auf eine konkrete Konfiguration des Produktes abgebildet werden können. In der Standardkonfiguration von Aras Innovator ist allerdings an dieser Stelle Schluss, die Liste der Optionscodes ist das einzige, was zu einer so genannten „Order“ abgespeichert wird. Die sich hieraus ergebende Struktur des einzelnen Produktes wird nur zur Anzeige errechnet. Für die Zwecke von InnoServPro ist es aber nötig, die entstehende konkrete Stückliste als hierarchische Struktur im PLM-System abzuspeichern, um einen Aufhängungspunkt für die diversen servicerelevanten Informationen im Projektkontext zu haben. Diese Repräsentation bildet die zweite Ebene des Datenmodells, den digitalen Zwilling.

7.3.1.2 Der digitale Zwilling Der digitale Zwilling entsteht im Anschluss an das Konfigurieren eines Produktes, indem eine Methode ausgeführt wird, welche die sich aus den Optionscodes ergebende Struktur des digitalen Zwillings als Items des entsprechenden Typs in die Datenbank ausleitet (siehe Abb. 7.8). Hierbei werden, wie oben beschrieben, auch Aufhängungspunkte für die genannten Zusatzdaten sowie Informationen zur Positionierung der vorhandenen Bauteile abgespeichert. Die Methode wird (verpackt in eine Action) vom Benutzer nach Konfiguration einer Order per Rechtsklick auf dieselbe ausgelöst. Neben den reinen Strukturdaten enthält der digitale Zwilling auch diverse Datenobjekte zur Verwaltung von Serviceprozessen und deren Durchführung. Das Konzept zur Verwendung der Objekte, die im Vorfeld zu den Clustern „erweitertes Wertschöpfungsnetzwerk und Aufträge“ und „Technische Dokumentation“ zusammengefasst wurden, baut auf dem oben vorgestellten Konzept zum Digital Master und Digital Twin auf. Relevante Baugruppen und Bauteile des Digital Master werden dabei um wohldefinierte, mögliche ­Serviceprozesse erweitert. Im zentral dargestellten Verfügbarkeitsvertrag werden die für einen spezifischen Digital Twin angebotenen Serviceprozesse und der für die Durchführung verantwortliche Servicepartner referenziert. Mit Erstellung eines Serviceauftrags können der durchführende Servicepartner, der spezifische Digital Twin (auf Produkt-, Baugruppen- oder Komponentenebene), ein oder mehrere Serviceprozesse sowie Freigabe- und Durchführungsverantwortliche definiert werden. Darüber hinaus können ausgehend vom Serviceauftrag auch die tatsächlich durchgeführten Serviceprozesse in Form von Serviceprotokollen referenziert werden. Dort werden Startund Endzeit des durchgeführten Serviceprozesses festgehalten und ob die beauftragten Serviceprozesse hilfreich waren bzw. welche Serviceprozesse tatsächlich durchgeführt wurden.

182

T. Eickhoff et al.

Schließlich verfügt der digitale Zwilling, wie oben erwähnt, über Angaben zur relativen Positionierung. Angelegt werden ein oder mehrere „Relative Positionierung“-Items wie im fachlichen Datenmodell definiert an der hierarchischen Relation zwischen einer Baugruppe und dessen untergeordnetem Bauteil, also an der Part-BOM-Relationship im digitalen Master. Existieren im Digital Master mehrere „Relative Positionierung“-Items für ein Bauteil oder eine Baugruppe, so muss die korrekte relative Positionierung durch einen Variantencode bei der Erstellung einer Order definiert werden. Bei der Ableitung eines Digital Twins nach der zuvor beschriebenen Methode wird die betreffende relative Positionierung nicht kopiert, sondern lediglich von der Digital Twin-BOM aus referenziert. So lassen sich Digital Twins ableiten, deren identische Baugruppe „Aufhängung“ verschiedene relative Positionierungen referenzieren. In diesem Beispiel hat die Entscheidung für einen Reifentyp Auswirkung auf die referenzierte relative Positionierung des „Schutzes“.

7.3.1.3 Geometrie Neben der reinen Positionierung wird auch die dreidimensionale Geometrie der einzelnen Bauteile im PLM-System verwaltet. Hierbei wird auf die bestehende Funktionalität in Aras Innovator zurückgegriffen. Das Datenmodell erlaubt es dem Benutzer, einem Bauteil auf Master-Ebene eine oder mehrere CAD-Dateien zuzuweisen. Zusätzlich gibt es in Aras Innovator aufgrund der webbasierten Benutzeroberfläche die Unterscheidung in „Files“ und „Viewable Files“, d.  h. Dateien, die direkt im Browser angezeigt werden können. Dieses Konzept wurde aufgegriffen und so werden aus JT-Dateien generierte neutrale Darstellungen der 3D-Geometrie hinterlegt. Aus der Kombination dieser Dateien und den Positionierungsinformationen in der Stückliste auf Zwillingsebene kann zur Abfragezeit eine dreidimensionale Darstellung des tatsächlichen Verbauungszustandes errechnet werden, die an das Front-End weitergegeben wird.

7.3.2 Entwicklung des Front-Ends Der Begriff „Front-End“ ist im Anwendungsfall John Deere gleichbedeutend mit dem maschinenunabhängigen Front-End, da in diesem Anwendungsfall auf intelligente Komponenten an der Maschine verzichtet wird. Es steht hier ganz eindeutig die Unterstützung des Servicetechnikers im Vordergrund. Der Einstiegspunkt in die Oberfläche ist ein Servicefall. Der Servicetechniker erhält Informationen zum Verbauungszustand des betroffenen digitalen Zwillings, um sich auf die Arbeiten am physikalischen Gegenstück vorbereiten zu können. An der Maschine angekommen erhält der Servicetechniker Schritt-für-Schritt-­ Anleitungen, die ihn durch den Serviceprozess führen. Diese Anleitungen werden im Kontext des Anwendungsfalls BHN/Lenze/Schaeffler in Abschn. 8.4.2 detailliert vorgestellt.

7  Anwendungsfall John Deere

183

Abb. 7.9  Tablet-Version des maschinenunabhängigen Front-Ends

Abb. 7.9 zeigt links die Startseite mit der Aufgabenliste und rechts eine Schritt-für-Schritt-­ Anleitung in der Tablet-Ansicht. Im Gegensatz zum genannten Anwendungsfall verfügen die Anleitungen im Anwendungsfall John Deere jedoch über eine größere Bandbreite an Multimedia-Elementen. So können je nach Anwendungsfall Bilder, Videos und frei drehbare 3D-Modelle eingeblendet werden. Für die Darstellung dreidimensionaler Geometrie wurde von der Verwendung der Aras-Innovator-Bordmittel abgesehen, da sich aus der im vorherigen Kapitel beschriebenen Darstellung von konfigurationsabhängiger Geometrie ohnehin ein enormer Anpassungsaufwand ergeben hätte. Stattdessen kommt der JSON-Viewer des JNetCAD-­ Projektes zum Einsatz (siehe Abb. 7.10). Die aus JT-Dateien generierten JSON-Files werden abhängig von der Konfiguration gefiltert, die benötigten Komponenten werden an der richtigen Stelle platziert und das Ergebnis wird dem User als frei dreh- und zoombare Ansicht präsentiert.

184

T. Eickhoff et al.

Abb. 7.10  3D-Ansicht des Bauteils

Literatur 1. Deere J (2018) Pressemitteilung John Deere Neuheiten. https://www.deere.de/de_DE/our_company/news_and_media/press_releases/2015/corporate/weitere_jd_neuheiten.page. Zugegriffen 06.12.2018 2. Hoppe G (2014) High-Performance Automation verbindet IT und Produktion. In: Bauernhansl T, Hompel M, Vogel-Heuser B (Hrsg) Industrie 4.0 in Produktion, Automatisierung und Logistik. Springer, Wiesbaden, S 248–275 3. Vogel-Heuser B, Diedrich C, Broy M (2013) Anforderungen an CPS aus Sicht der Automatisierungstechnik. Automatisierungstechnik 61(10):669–676 4. Kagermann H, Wahlster W, Helbig J (2018) Umsetzungsempfehlungen für das Zukunftsprojekt Industrie 4.0: Abschlussbericht des Arbeitskreises Industrie 4.0. https://www.bmbf.de/files/Umsetzungsempfehlungen_Industrie4_0.pdf. Zugegriffen am 10.12.2018 5. Büttner K-H, Brück U (2014) Use Case Industrie 4.0-Fertigung im Siemens Elektronikwerk Amberg. In: Bauernhansl T, Hompel M, Vogel-Heuser B (Hrsg) Industrie 4.0 in Produktion, Automatisierung und Logistik. Springer, Wiesbaden, S 121–144 6. Zagel M (2006) Übergreifendes Konzept zur Strukturierung variantenreicher Produkte und Vorgehensweise zur iterativen Produktstruktur-Optimierung. Dissertation, Technische Universität Kaiserslautern 7. Aras Corporation (2016) Variants. https://github.com/ArasLabs/variants. Zugegriffen am 15.12.2018

8

Anwendungsfall BHN/Lenze/Schaeffler Daniel Olivotti, Hristo Apostolov, Dani Bechev, Horst Brehm, Georgis Bulun, Christian Donges, Sonja Dreyer, Thomas Eickhoff, Matthias Fischer, Claudia Glenske, Jens C. Göbel, Simon Graf, Michael Grethler, Julian Imwalle, Andrej Keksel, Markus Kiele-Dunsche, Ralf Mattukat, Rolf Rettinger, Bernd Sauer, Jörg Seewig, Paaranan Sivasothy, Heiko Stichweh und Frank Zeihsel

Zusammenfassung

Im industrielen Anwendungsfall BHN/Lenze/Schaeffler wird gezeigt, wie eine ganzheitliche Lösung von der Geschäftsidee bis zu konkreten technischen Umsetzungen entwickelt werden kann. Dabei wird das industrielle Wertschöpfungsnetzwerk zwischen Komponentenhersteller, Maschinenbauern, Systemintegratoren und Maschinenbetreiber betrachtet. Als technische Lösung kann ein durchgängiges Informationsmanagement gezeigt werden, welches Data-Analytics und intelligente Kommunikationsfähige Komponenten integriert. Die Komponenten sind dabei z. B. mit individualisierten Alterungsmodelle und Schritt-für-Schritt-Anleitungen verknüpft. Sensor- und Zustandsdaten aber auch Daten aus der Maschineninstandhaltung werden im Sinne von „BigData“ erfasst und stehen für Fehlerverfolgung und Data-Analytics zur Verfügung. D. Olivotti (*) · S. Dreyer · R. Rettinger BHN Dienstleistungs GmbH & Co. KG, Aerzen, Deutschland E-Mail: [email protected]; [email protected] H. Apostolov · T. Eickhoff · J. C. Göbel Lehrstuhl für Virtuelle Produktentwicklung, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected]; [email protected] D. Bechev · S. Graf · B. Sauer Lehrstuhl für Maschinenelemente und Getriebetechnik, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected]; [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 J. C. Aurich et al. (Hrsg.), Entwicklung datenbasierter Produkt-Service Systeme, https://doi.org/10.1007/978-3-662-59643-2_8

185

186

D. Olivotti et al.

8.1  Einleitung Gegenstand des gemeinsamen Use-Cases der Unternehmen BHN Dienstleistungs GmbH (nachfolgend BHN genannt), Lenze SE (nachfolgend Lenze genannt) und Schaeffler AG (nachfolgend Schaeffler genannt) war die Entwicklung von innovativen Serviceprodukten für die industrielle Antriebs- und Automatisierungstechnik. Ausgehend von sich rasant entwickelnden technischen Möglichkeiten im Rahmen der vierten industriellen Revolution und der damit einhergehenden Digitalisierung galt es, neue Architekturen im Bereich von Produktions- und Logistikprozessen zu erarbeiten, welche insbesondere durch die Nutzung von erweiterten Wertschöpfungsnetzwerken neue Geschäftsmodelle im Rahmen verfügbarkeitsorientierter Anwendungsszenarien ermöglichen. Besonderes Augenmerk wurde dabei auf die Ende-zu-Ende-Betrachtung der industriellen Wertschöpfungskette im Industriegüterbereich gelegt, um die neuen Technologien und Frameworks gezielt ­einzusetzen, die sich in deren Produktions- und/oder Logistikprozesse integrieren lassen, und Kunden diesbezüglich einen Mehrwert bieten zu können.

H. Brehm Schaeffler AG, Herzogenaurach, Deutschland E-Mail: [email protected] G. Bulun · A. Keksel · J. Seewig · P. Sivasothy Lehrstuhl für Messtechnik und Sensorik, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected]; [email protected]; sivasothy@mv. uni-kl.de C. Donges · M. Fischer :em engineering methods AG, Darmstadt, Deutschland E-Mail: [email protected]; [email protected] C. Glenske Sensitec GmbH, Lahnau, Deutschland E-Mail: [email protected] M. Grethler SolidLine AG, Karlsruhe, Deutschland E-Mail: [email protected] J. Imwalle · R. Mattukat Anedo GmbH, Eydelstedt, Deutschland E-Mail: [email protected]; [email protected] M. Kiele-Dunsche · H. Stichweh Lenze SE, Aerzen, Deutschland E-Mail: [email protected]; [email protected] F. Zeihsel enbiz GmbH, Kaiserslautern, Deutschland E-Mail: [email protected]

8  Anwendungsfall BHN/Lenze/Schaeffler

187

In diesem Zusammenhang wurden mittels Design-Thinking-Methoden und Customer-­ Journey-­Maps in Kundenworkshops „Personas“ entwickelt und der für den Kunden relevante Mehrwert im Bereich der Ende-zu-Ende-Prozessbetrachtung herausgearbeitet. Eines der wesentlichen Ergebnisse, welches jeweils herausgearbeitet wurde, war der Kundenwunsch nach Handlungsempfehlungen für auftretende Störungen entlang seiner Prozesskette, bezogen auf die herausgearbeiteten Personas. Dabei ist bezogen auf die Personas von unterschiedlichen Kenntnissen und Fähigkeiten auszugehen. Die erarbeiteten Ergebnisse wurden dann im Rahmen des Forschungsprojektes und des erweiterten Wertschöpfungsnetzwerkes aufgearbeitet und flossen so in den gemeinsamen Use-Case ein. Den an diesem Use-Case beteiligten Unternehmen war es wichtig, bereits in einem frühen Stadium die mit Kunden erarbeiteten Ergebnisse an einem Demonstrator zu spiegeln, welcher auf Messen präsentiert wurde. Das entsprechende Kundenfeedback konnte somit direkt wieder dem Forschungsprojekt zugeführt werden und hat früh zu einem PDCA-­Zyklus geführt und stetige technische Anpassungen und Verbesserungen für den Kunden ermöglicht. BHN/Lenze und Schaeffler verfolgten im Rahmen des Forschungsprojektes drei konkrete Arbeitsziele: 1. Entwicklung von intelligenten, kommunikationsfähigen Antriebs- und Automatisierungs-­ komponenten (im Besonderen für industrielle Investitionsgüter) als Basis zur Erfassung, Verdichtung und Kommunikation servicerelevanter Daten. 2. Gestaltung einer durchgängigen, vernetzten, digitalisierten und standardisierten Kommunikationsinfrastruktur, Datenablage sowie einer weiterentwickelten Business Analytics als Basis für neue Serviceprodukte und Geschäftsmodelle. 3. Übertragung der Serviceprodukte und Geschäftsmodelle für Investitionsgüter auf andere Branchen, z. B. im Umfeld der industriellen Produktion oder der Intralogistik. Diese Arbeitsziele wurden für jedes der beteiligten Unternehmen vollumfänglich erreicht und lassen sich am Demonstrator gut darstellen. Anhand des Anwendungsszenarios „Fördertechnik“ konnte sowohl die Vernetzung der einzelnen in der Maschine verbauten Komponenten als auch die Integration in die von dem Wertschöpfungsnetzwerk bereitgestellten Lösungen sehr gut dargestellt werden. So werden die gesammelten Daten in die Cloud transferiert, dort weiterverarbeitet, analysiert, interpretiert und als Basis für die in den Workshops und Customer Journeys erarbeiteten Fragestellungen neuen verfügbarkeitsorientierten Geschäftsmodellen zur Verfügung gestellt. Darüber hinaus wurden erste Schritte bzgl. einer testweisen Integration technischer Komponenten in Lenze Produkte realisiert, wie z. B. des Schaeffler VarioSense-Lagers mit Sensorik. Dies weist bereits auf zukünftige Möglichkeiten hin, z. B. Algorithmen unterschiedlicher Zulieferer einfach hinzubuchen zu können, um in einem erweiterten Wertschöpfungsnetzwerk Mehrwert für Kunden zu generieren und so zulieferübergreifende verfügbarkeitsorientierte Geschäftsmodelle zu ermöglichen.

188

D. Olivotti et al.

Abb. 8.1 BHN/Lenze/Schaeffler-Demonstrator

Unten abgebildet sehen Sie den BHN/Lenze/Schaeffler-Demonstrator (siehe Abb. 8.1), der Grundlage der hier erarbeiteten und dargestellten Ergebnisse war, welche auf den folgenden Seiten vorgestellt werden.

8.2  S  pezifische Konzeption eines verfügbarkeitsorientierten Geschäftsmodells In diesem Kapitel geht es darum, den Weg zu dem verfügbarkeitsorientierten Geschäftsmodell aufzuzeigen, das für den dritten Use-Case spezifiziert ist. Es wird beschrieben, wie Methoden zur Definition eines geeigneten Geschäftsmodells genutzt wurden. Dabei wird

8  Anwendungsfall BHN/Lenze/Schaeffler

189

insbesondere darauf eingegangen, wie die Customer Journey für den Use-Case ausgestaltet wurde. Außerdem wird verdeutlicht, wie mehrere Iterationsschleifen zum spezifischen Geschäftsmodell geführt haben. Beginnend mit einer Markt- und Trendrecherche wurde untersucht, welche Bedürfnisse potenzielle Kunden haben und welche Services sie sich wünschen. Dabei wurde sich nicht auf einen bestimmten Bereich beschränkt oder von einer gewissen Technologie ausgegangen. In Workshops wurden sieben aktuelle Fragestellungen identifiziert. Die erste Frage beschäftigt sich damit, welches individuelle Produkt an welcher Stelle verbaut ist. Gerade in großen Produktionsstätten ist unklar, welche Komponente (mit einer eindeutigen Serialnummer) sich an welcher Stelle befindet. Dies wird relevant, wenn beispielsweise Produkte ausgetauscht werden müssen, die in einem gewissen Zeitraum gefertigt wurden. Im Hinblick auf eine Fehleranalyse mit Sensordaten können Analyseergebnisse lokal wesentlich besser zugeordnet werden. Ein anderer Aspekt geht der Frage nach, wie Wissen am richtigen Ort und zur richtigen Zeit zur Verfügung gestellt werden kann. Je komplexer die Maschinen, Prozesse und Anwendungen in einem Unternehmen sind, desto wichtiger ist der Aspekt der Wissensnutzung. Eine strukturierte Datenbank, in der Wissen gespeichert und gezielt abgerufen werden kann, kann zu erheblichen Wettbewerbsvorteilen führen. Wissen umfasst dabei nicht nur die Analyseergebnisse aufgrund der Sensordaten, sondern auch das Wissen, das implizit bei den einzelnen Mitarbeitern vorhanden ist. Eine weitere Fragestellung bezieht sich auf die unmittelbare und zuverlässige Diagnose von Fehlerursachen. Technische Komponenten melden häufig Fehler, die keinen Rückschluss auf den eigentlichen Auslöser zulassen. Gerade in größeren Produktionsanlagen ist eine präzise Verortung des Fehlers wichtig, um lange Stillstandszeiten zu vermeiden und die Verfügbarkeit der Maschine hoch zu halten. Abgesehen von während des Betriebs entstehenden Störungen sollten auch Fehler vermieden werden, die auf einen fehlerhaften Einbau von Komponenten zurückzuführen sind. Aus diesem Grund geht ein weiterer Aspekt der Frage nach, wie Einbaufehler vermieden werden können. Im Zusammenhang mit den Analyseergebnissen und dem Wissen, das sowohl implizit als auch explizit vorhanden ist, stellt sich die Frage, wie man aus Erfahrung lernen kann. Dieser Punkt zielt darauf ab, in Unternehmen eine Systematik zu implementieren, die es ermöglicht, vergangene Erkenntnisse in der Zukunft zu nutzen. Ergebnisse und gewonnene Erkenntnisse sollten somit nicht nur für den aktuellen Moment als Entscheidungsunterstützung verwendet werden, sondern auch systematisch für die Zukunft herangezogen werden. Daraus ergibt sich ein weiterer Aspekt, der von potenziellen Kunden als interessantes Servicefeld genannt wird: die effiziente Wartungsplanung. Je mehr Analyseergebnisse vorliegen und über die Nutzung der einzelnen Komponenten ­bekannt ist, desto besser kann der Zustand einer Komponente oder einer gesamten Maschine bestimmt werden. Dies hat zur Folge, dass Wartungsaufwände minimiert werden können. Wartungen müssen dann nicht mehr nach einer festgelegten Zeit oder einer gewissen Anzahl an Betriebsstunden durchgeführt werden, sondern können individuell geplant werden. Zum einen werden dadurch Ausfallzeiten minimiert und zum anderen Kosten gesenkt. Im Zusammenhang damit steht die Frage, wie Wartungen bestmöglich geplant

190

D. Olivotti et al.

werden können. Sofern Wartungen von einer externen Firma durchgeführt werden, ist es sinnvoll, Wartungen zeitlich zu gruppieren, um Anfahrtszeiten und damit Kosten zu minimieren. Wie genau diese Gruppierung vorgenommen werden sollte und welche Parameter dabei zwingend Beachtung finden müssen, ist eine Fragestellung, die potenzielle Kunden interessiert. Insgesamt stellt sich somit die Frage für den Kunden, wie die Instandhaltung vereinfacht werden kann. Auf Basis dessen wurde eine Customer Journey durchgeführt, die im Folgenden ausgeführt wird. Der Fall, der in der Customer Journey betrachtet wird, beginnt damit, dass ein ungeplanter Stillstand einer Maschine auftritt. Anschließend wird der Fehler lokalisiert, bevor mit der Fehlerdiagnose begonnen werden kann. Lösungsoptionen werden ermittelt und der Lösungsvorschlag ausgewählt, dem als erstes gefolgt werden soll. Nach der Umsetzung des ersten Lösungsvorschlags wird validiert, ob der diagnostizierte Fehler behoben wurde. Ist dies nicht der Fall, wird ein weiterer Lösungsvorschlag umgesetzt. Nach einer Validierung, in der die erfolgreiche Fehlerbehebung festgestellt wurde, erfolgt die Wiederinbetriebnahme der Maschine. Den Abschluss bildet eine Fehler- und Ursachenanalyse, um diese Art von Störung in Zukunft frühzeitig erkennen zu können und somit einen ungeplanten Maschinenstillstand zu vermeiden. Es gibt innerhalb des betrachteten Beispiels mehrere Interessengruppen mit unterschiedlichen Bedürfnissen. Innerhalb der Customer Journey wird zwischen dem Bediener einer Maschine, dem Instandhalter und dem Manager unterschieden. Der Maschinenbediener ist in aller Regel derjenige, der Probleme an der Maschine als erstes bemerkt. Häufig ist er ebenfalls derjenige, der den Fehler in einem ersten Schritt zu beheben versucht. Der Manager interessiert sich im Wesentlichen für Schnelligkeit und Kosteneffizienz. Kennzahlen helfen ihm dabei, sich einen Überblick zu verschaffen. In dem Moment, in dem ein ungeplanter Stillstand auftritt, möchte der Maschinenbediener eine entsprechende Fehlermeldung angezeigt bekommen. Der Instandhalter möchte ebenfalls wissen, dass ein Stillstand vorliegt. Zudem interessiert ihn, wie kritisch dieser Zustand ist. Eine Priorisierung im Vergleich zu anderen aktuell vorliegenden Fehlern ist ebenfalls von Interesse. Der Manager verfolgt hingegen eine übergeordnete Sicht. Dazu zählen Kennzahlen, die Stillstände mehrerer Maschinen oder der gesamten Produktion zeigen. Eine einzelne Maschine kann dann damit verglichen werden, um Ausreißer in die positive sowie negative Richtung auszumachen und anschließend analysieren zu können. Zudem möchte der Manager die Möglichkeit haben, die Abarbeitung der unterschiedlichen Fehler zu beeinflussen und anzuordnen. Hilfreich für die unterschiedlichen Interessengruppen sind individuelle Visualisierungscockpits. Eine laufend aktualisierte Wissensdatenbank unterstützt bei einer zügigen Fehlerbehebung. Sowohl der Bediener als auch der Instandhalter interessieren sich für die Antwort auf die Frage, wo der Fehler lokalisiert ist. Hilfreich sind dabei insbesondere Sensorik und das Wissen, welche Komponenten an welcher Stelle verbaut sind. Dafür ist in aller Regel ein digitaler Zwilling notwendig. Dabei ist anzumerken, dass Standards genutzt werden sollten, damit digitale Zwillinge nicht nur intern genutzt und aktualisiert werden können, sondern auch von externen Unternehmen, wie beispielsweise Komponentenlieferanten. Ist der Fehler lokalisiert, wird festge-

8  Anwendungsfall BHN/Lenze/Schaeffler

191

stellt, ob der Bediener den Fehler möglicherweise selbst beheben kann. Dafür muss insbesondere ausgeschlossen werden, dass Gefahr droht. Ist dies der Fall, sollte der Instandhalter sofort hinzugezogen werden. Zudem ist der Instandhalter dafür zuständig, die für die Behebung notwendigen Ersatzteile zu beschaffen. Eine Fehlerfolgenabschätzung wird vom Manager vorgenommen, der dafür die notwendigen Informationen benötigt. Eine systematische Darstellung von Fehlerbildern hilft allen Interessengruppen. In Bezug auf die Lösungsoptionen ist für den Maschinenbediener relevant, was er zu tun hat und ob er zunächst selbst handeln darf. Der Instandhalter bevorzugt eine breitere Übersicht über ähnliche Fälle in der Vergangenheit, weitere Maßnahmen und die Historie der Maschine. Zudem ist eine Übersicht über die benötigten Ersatzteile und Werkzeuge notwendig, die für die unterschiedlichen Lösungsoptionen benötigt werden. In diesem Schritt kann ein Visualisierungscockpit dazu genutzt werden, Handlungsempfehlungen anzuzeigen. Je nach Interessengruppe ist die Anzeige unterschiedlich ausgestaltet. Während sich der Maschinenbediener dafür interessiert, welche Schritte im Einzelnen durchgeführt werden müssen, möchte der Instandhalter eine erweiterte Sicht, die auch eine Einsatzplanung umfasst. Der Maschinenbediener benötigt klare Handlungsempfehlungen ohne Auswahloptionen. Eine Schritt-für-Schritt-Anleitung stellt dabei eindeutig dar, wie die Fehlerbehebung erfolgt. Der Instandhalter sieht ebenfalls eine Anweisung, hat aber die Möglichkeit, Schritte zu überspringen oder andere Behebungswege zu nutzen. Dies wird entsprechend dokumentiert, um es für weitere Stillstände mit der identischen Ursache nachvollziehbar zu machen. Bei externen Firmen kann dies zudem für die Abrechnung genutzt werden. Für eine effiziente und zuverlässige Einsatzplanung müssen die Aspekte Ort, Zeit und Ressourcen berücksichtigt werden. Entsprechend müssen alle notwendigen Daten zur abgestimmten Einsatzplanung bereitgestellt werden. Dazu gehört unter anderem die Informationsbereitstellung über Ersatzteile, Lieferzeiten und notwendige Kompetenzen. Im Hinblick auf die Kosteneffizienz bevorzugt der Manager eine lokale Lösung, bei der keine externen Ressourcen benötigt werden. Zudem hat der Manager den Anspruch, dass die Umsetzung delegierbar und strukturiert erfolgt. Nachdem ein Lösungsvorschlag umgesetzt wurde, muss das Ergebnis validiert werden. Auch hier haben die Interessengruppen unterschiedliche Bedürfnisse. Der Maschinenbediener bevorzugt an dieser Stelle ebenfalls eine klare Anleitung, beispielsweise in Form einer Schritt-für-­ Schritt-Anleitung. Auch der Testprozess soll gestützt sein. Dabei sind klare Akzeptanzkriterien wichtig, anhand derer die Validierung erfolgen kann. Eine Funktion der Maschine, sodass sie ohne weitere Einstellung einen Testbetrieb durchläuft, ist außerdem vorteilhaft. Der Instandhalter bevorzugt dabei grundsätzlich die gleiche Visualisierung. Zusätzlich legt der Instandhalter jedoch auch Wert auf eine Nachweisdokumentation, die zeigt, dass die Maschine wieder betriebsbereit ist. Wie bereits in den vorherigen Schritten der Customer Journey verdeutlicht, bevorzugt der Maschinenbediener auch bei der Wiederinbetriebnahme der Maschine klare Anweisungen zum kontrollierten Anfahren. Der Instandhalter interessiert sich zusätzlich für eine zugehörige Nachweisdokumentation, die auch die Abnahme der Instandhaltung enthält. Der Abnahmeprozess muss dabei festgelegt sein. Für eine spätere Nachvollziehbarkeit muss dieser Prozess eingehalten werden.

192

D. Olivotti et al.

Die Customer Journey ist mit der kontrollierten Wiederinbetriebnahme noch nicht abgeschlossen. Im Nachgang erfolgt eine Fehler- und Ursachenanalyse, um Störungen gleicher Art in der Zukunft zu vermeiden. Das Interesse an dieser Nachbearbeitung ist bei dem Maschinenbediener dadurch begründet, dass er nicht ständig den gleichen Fehler beheben möchte und der Maschinenbetrieb möglichst wenig gestört wird. Dem Instandhalter ermöglicht die Analyse eine lückenlose Dokumentation, insbesondere im Hinblick auf Fehlerverlaufsprotokolle. Ein dadurch angestoßener kontinuierlicher Verbesserungsprozess trägt zu einer hohen Maschinenverfügbarkeit bei. Aus Managementsicht sind Monitoringaspekte interessant. Zudem ermöglicht eine breite und aktuelle Datenbasis weitere Analysen, die bis auf die Einzelfallebene herunterreichen. Dafür sind nicht nur interne Daten interessant, sondern auch Daten von Dritten, wie beispielsweise Lieferanten von Komponenten und Maschinenteilen. Auch Daten aus weiteren Systemen, wie aus dem ERP, tragen zu einer großen Datenbasis bei. Eine notwendige Voraussetzung sind dabei entsprechende Schnittstellen sowie eine Vernetzung. In Abb.  8.2 wird die Customer Journey zusammengefasst.

8.3  E  ntwicklung intelligenter, kommunikationsfähiger Komponenten Im Rahmen des Projektes InnoServPro werden drei Teilziele verfolgt. Ein Teilziel ist die Entwicklung intelligenter, kommunikationsfähiger Komponenten und wird in diesem Abschnitt näher erläutert. Diese intelligenten, kommunikationsfähigen Komponenten dienen dazu, benötigte Daten zu erfassen, zu verarbeiten und an die Informationsmanagement-­ Plattform weiterzugeben. Im Use-Case 3 wurde dazu eine technische Demonstrationsmaschine gebaut, die diese Komponenten beinhaltet. Neben der rein technischen Entwicklung von intelligenten, kommunikationsfähigen Komponenten wurde auch auf die Entwicklung mathematischer Modelle Wert gelegt, die wertvolle Informationen über die Komponenten liefern können. Zunächst werden im folgenden Kapitel der technische Demonstrator sowie die jeweilige Sensorausstattung beschrieben. Anschließend folgt die Beschreibung des entwickelten thermischen Modells als beispielhafte Beschreibung für die entwickelten Modelle.

8.3.1 Sensorausstattung der Demonstratormaschine Die Demonstrationsmaschine, die in diesem Projekt entwickelt wurde, stellt eine logistische Anwendung dar. Hierbei werden Güter über Förderbänder und Hubachsen verfahren (siehe Abb. 8.1). Um diese Förderanwendung zu realisieren, wurden Umrichter und Getriebemotoren der Firma Lenze verbaut. Ebenfalls wurde eine PLC-Steuerung von Lenze für die Gesamtanlagensteuerung verwendet. Einen Überblick über die technische Topologie ist in Abb. 8.3 zu sehen.

8  Anwendungsfall BHN/Lenze/Schaeffler

193

Abb. 8.2  Zusammengefasstes Ergebnisse der Customer Journey des Use-Case BHN/Lenze/Schäffler

Insgesamt sieben Getriebemotoren sind in der Demonstrationsmaschine verbaut. Diese werden unterschiedlich angesteuert, um eine Varianz in den verbauten Produkten zu realisieren und ein möglichst praxisorientiertes Anwendungsszenario darzustellen. Zwei ­Getriebemotoren sorgen für die Bewegung der beiden verbauten Hubachsen, diese werden über Umrichter der Lenze Baureihe 8400 über EtherCAT angesteuert. Auf diesen Hubachsen ist jeweils ein Förderband verbaut, welches über separate Getriebemotoren verfügt. Die Getriebemotoren für die beiden Bänder werden über zwei Umrichter der Baureihe i550 geregelt. Diese Umrichter sind an einer zentralen Platte montiert und entsprechen einer Schaltschrankanordnung in der Praxis. Zwischen den beiden Hubachsen sorgen drei übereinander angeordnete Förderbänder für ein Verfahren der Güter. Das obere Band wird

194

D. Olivotti et al.

Abb. 8.3  Topologie der Demonstratormaschine

ebenfalls über einen i550 geregelt. Das mittlere Band ist hingegen ein Smart Motor, der über ein NFC-fähiges Smartphone bedient werden kann. Dies ermöglicht den Einsatz des Motors in unterschiedlichen Anwendungen und eine schnelle Parametrierung mit einer intuitiven Smartphone-App. Der untere Getriebemotor in der Demonstratormaschine ist ein Getriebemotor mit aufgesetztem Umrichter mit der Bezeichnung 8400 motec. Der Vorteil dieser Konstruktion liegt darin, dass Getriebemotor und Umrichter direkt beieinander sind und eine aufwendige Verkabelung zum Schaltschrank entfällt. Dieser 8400 motec ist per CANopen angebunden. Zur Ansteuerung der Umrichter ist eine PLC des Typs p500 verbaut, diese enthält zugleich ein Touchdisplay zur Visualisierung und Steuerung der An-

8  Anwendungsfall BHN/Lenze/Schaeffler

195

lage für den Bediener. Über die Steuerung können Prozessgrößen der betroffenen Geräte ausgelesen werden. Beispielsweise sind diese Strom, Spannung, Drehmoment und Drehzahl, die alle 10 ms ausgelesen werden. Neben diesen hochfrequenten Daten können auch Informationen über Auslastung und Fehlerspeicher ausgelesen werden, diese Informationen werden nicht so hochauflösend benötigt. Obwohl keine separate Sensorausstattung verbaut wurde, liefern die eingebauten Sensoren und Komponenten in den Geräten wertvolle Informationen, die auf tatsächliche Belastung, Verschleiß und Fehler hinweisen. Ein möglicher Störungsfall, der zum Ausfall von Getriebemotoren führen kann, sind Lagerschäden. Um detaillierte Informationen über solch ein Lager zu bekommen, wurde in dem Getriebemotor, der die linke Hubachse antreibt, ein FAG Lager mit Schaeffler VarioSense-­ Modul als Sensor verbaut. Dieser Sensor liefert Informationen über Temperatur, Drehzahl und Verkippung des Lagers. Der Sensor ist über eine Auswertungsbox an ein Anedo m50 Gateway angeschlossen. Dieses Gateway dient als zentrale Stelle, um alle relevanten Daten der Anlage an das Back-End über das Internet zu versenden (Abb. 8.4). Eine der Herausforderungen entsteht dadurch, dass die Komponenten in unterschiedlichen Anlagen verbaut werden, wodurch sich die Einsatzbedingungen der Komponenten wesentlich unterscheiden können. Eine Vereinfachung der Instandhaltung kann durch die Datenaufbereitung und Kenngrößen-­Fusionierung mittels smarter, kommunikationsfähiger Komponenten bei drei wesentlichen Punkten unterstützt werden: • Fehlererkennung, • Fehlerursachendiagnose und • Fehlervermeidung.

Ethernet CODESYSNetzwerkvariablen

Ethernet

EtherCAT

RS485 Vario Sense

IO-Modul S30e Steuergerät M50

Abb. 8.4  Sensor-Anbindung an das Steuerungssystem des Demonstrators

196

D. Olivotti et al.

Durch die Analyse der Betriebsdaten ist es möglich, Fehlersituationen zu erkennen, welche sich aus der Abweichung zum normalen mechanischen Betrieb der Anlage ergeben. Durch eine erweiterte Fehlererkennung können Folgeschäden im Fehlerfall vermieden und die Instandhaltung schneller angestoßen werden. Hierzu werden Kenngrößen definiert, deren Veränderung auf eine Fehlersituation hindeutet. Ziel der Fehlerursachendiagnose ist es, einen Fehler auf die technische Fehlerursache zurückzuführen, z. B. den Ausfall einer Komponente. Durch die Diagnose der Ursache kann ein Fehler schneller behoben werden. Zur Fehlerursachendiagnose können aus den momentanen Maschinendaten, historischen Belastung- und Nutzungsdaten sowie Messdaten vor dem Auftreten eines Fehlers mögliche Fehlerursachen eingeschränkt werden. Die Speicherung dieser Daten kann bei zukünftigen Fehlerdiagnosen helfen. Dafür müssen die smarten, kommunikationsfähigen Komponenten Belastungs-, Nutzungs- und Messdaten erfassen und gegebenenfalls zu geeigneten Kenngrößen zusammenfassen. Die Fehlervermeidung soll vorwiegend über die Verwendung realer Nutzungs- und Belastungsdaten ermöglicht werden. Um diese Aufgaben zu ermöglichen, stehen den smarten, kommunikationsfähigen Komponenten durch die Antriebskomponenten folgende Informationen zur Verfügung: Umrichter: • • • • • • • • • • • • •

Ist-Geschwindigkeit Ist-Drehmoment Akt. Drehzahlfehler Motorstrom Ist-Spannung Netzeinschaltdauer Betriebsdauer CIA 402 Gerätestatus DC-Ist-Spannung Kühlkörpertemperatur Umrichterauslastung Motorauslastung Fehlercode

Motor: • Motortemperatur Die Sensorwerte der Antriebskomponenten werden nicht direkt vom Steuergerät M50 an den Sensoren abgelesen, sondern vom Steuergerät des Demonstrators erfasst. Zwischen dem Steuergerät der Lenze Maschine und dem Steuergerät M50 werden die Sensorwerte als CODESYS-Netzwerkvariablen ausgetauscht. Es wurde zusätzlich ein kommunikati-

8  Anwendungsfall BHN/Lenze/Schaeffler

197

onsfähiges „VarioSense-Lager“ von der Firma Schaeffler verbaut, das weitere Sensorwerte zur Verfügung stellt. Das Lager wird über eine RS485-Verbindung direkt am IO-­ Modul S30e angeschlossen. Folgende Werte liefert die kommunikationsfähige Lagerung: • Getriebe-Temperatur • Getriebe-Drehzahl • Getriebe-Radialbelastung

8.3.2 Thermisches Modell Die Temperatur innerhalb von Komponenten ist häufig ein guter Indikator, um Probleme zu erkennen, bevor eine Maschine ausfällt. Auf der anderen Seite ist die Temperatur eine Belastung, die eine Alterung von Komponenten zur Folge hat. Die Belastung kann dabei über die Laufzeit der Komponente aufgezeichnet werden und einem Restlebensdauermodel zur Verfügung stehen. Im folgenden Unterkapitel sind am Beispiel von Getrieben zwei Alterungsmodelle beschrieben, welche die innere Temperatur des Öls berücksichtigen. An dieser Stelle wird beschrieben, wie die innere Temperatur eines Getriebemotors aufgrund von vorhandenen Daten und Messgrößen abgeschätzt werden kann. Das Modell wurde nach erfolgreicher Validierung als Baustein für die Steuerung umgesetzt. Dieses Simulationsmodell wird dadurch charakterisiert, dass es schnell gerechnet werden kann und Parameter voraussetzt, die möglichst generisch aus bestehenden Daten und Informationen ermittelt werden können. Dadurch grenzt sich das Simulationsmodell von herkömmlichen Modellen ab, bei denen eine möglichst gute Abbildung der Realität im Vordergrund steht. Ein Grund dafür ist, dass Lösungen wie Getriebemotoren für den Maschinenbau sehr variantenreich sind. Zusätzlich hängen die thermischen Verhältnisse von der Befestigung des Getriebemotors an der Maschine ab. Für diese Variantenvielfalt dürfen keine Werte erforderlich sein, welche zum Beispiel erst über Messungen ermittelt werden müssen. Dafür sind hier die Genauigkeiten an das Ergebnis des Modells, hier die Temperatur, nicht sehr hoch. Das ist darin begründet, dass mit fachlich gut umgesetzten Modellen schon eine sehr viel bessere Aussage zur Alterung getroffen werden kann, als dies aufgrund von Maximalangaben der Fall ist, auch wenn ein Unsicherheitsfaktor für die Temperatur berücksichtigt wird. Aufgrund der Drehzahlvariabilität der abzubildenden Getriebe-Elektromotor-­Einheiten, und der unterschiedlichsten Kombinationen aus Getriebe und Elektromotor wäre die ­Messung von Referenzkurven, die das thermische Verhalten der konfigurierten Kombination beschreiben, mit unverhältnismäßig hohem Aufwand verbunden. Davon ausgehend wurde ein numerisches Modell entwickelt, welches mit nur wenigen Eingabeparametern eine Temperaturprognose der beiden relevanten Bauteile ermöglicht (Abb. 8.5). Basierend auf den zur Verfügung stehenden Daten und Anforderungen wurde als Simulationsmodell ein thermisches Netzwerk realisiert.

198

D. Olivotti et al.

Abb. 8.5  Schematische Darstellung des verwendeten thermischen Netzwerks

Infolge der gewünschten Einfachheit des Modells wird für den vorliegenden Anwendungsfall das thermische Netzwerk auf zwei Knoten reduziert, jeweils einen für das Getriebe sowie einen für den Elektromotor. In Abb. 8.5 wird der Aufbau des Netzwerks verdeutlicht und die berücksichtigten Leitwerte und Verlustleistungen visualisiert. So wird für den Knoten des Elektromotors sowohl die Wärmekapazität berechnet als auch die Leitwiderstände zum Getriebe (Kontaktfläche Elektromotor-Getriebe sowie der Kontakt über die Welle-Nabe-Verbindung) und zur Umgebung. Der Leitwiderstand des Maschinenfundamentes der Getriebe-Elektromotor-Kombination ist entsprechend der Vorgaben am Knoten des Getriebes berücksichtigt. Basierend auf dem in Abb. 8.5 dargestellten Netzwerk lässt sich das Differentialgleichungssystem der Anlage entwickeln. Dieses ist exemplarisch in der nachfolgenden Gleichung beschrieben.



C1 0 T1 L1U + L12 + L12 0 C2 T2

L2U

L12 P T1 = V1 + L2 F + L12 T2 PV 2

Das sich daraus ergebende System von Differenzialgleichungen 1. Ordnung wird im vorliegenden Fall mittels eines klassischen Runge-Kutta-Verfahrens gelöst. Zur besseren Übersichtlichkeit der benötigten Eingangswerte wurde eine Parameterliste erstellt, in der sämtliche zur Simulation der Temperaturverteilung notwendigen Größen (Wärmekapazitäten, Leitwerte und Verlustleistungen) aufgeführt sind. Über die darin gemachten Angaben und die Berechnung der jeweiligen Leitwiderstände

8  Anwendungsfall BHN/Lenze/Schaeffler

199

sowie die im Betriebspunkt abgenommene Leistung wird als Ergebnis der sich einstellende Temperaturverlauf für das Getriebe und den Elektromotor ausgegeben (Abb. 8.6). Diese im Betriebspunkt wirkenden simulierten Temperaturen werden dann mit der gemessenen Lagertemperatur abgeglichen. Somit ist es möglich, abweichende Temperaturen zu detektieren. Zur Steigerung der Genauigkeit des thermischen Modells ist es möglich, über vorangehende Referenzmessung das Netzwerk zu kalibrieren.

8.3.3 K  onzept zur Realisierung von Wartungsanzeigen anhand eines Beispiels Zur Vermeidung von Ausfällen werden Komponenten gewartet, welche einer Alterung oder einem Verschleiß unterliegen. Im Projekt wurden analog zur Ölwechselanzeige beim Auto zwei Wartungsanzeigen für Lenze-Getriebe umgesetzt. Dabei wurde bestehendes Wissen aus der Konstruktion in Modellen abgebildet, welche aufgrund der erfassten ­Belastungen Alterung und Verschleiß ableiten können. Die Gesamtlösung des Projektes beinhaltet, dass diese Modelle aufgrund der Daten über Ausfälle und der Belastungen der Komponenten immer weiter verbessert werden können.

Temperaturverlauf

160 140

Temperatur [ºC]

120 100 80 60 40 20

T E-Motor T Getriebe

0

0.5

1

1.5

2 Zeit [s]

2.5

3

3.5

4 × 105

Abb. 8.6  Simulierter Temperaturverlauf des thermischen Netzwerks für gegebene Elektromotor-­ Getriebe-­Kombination

200

D. Olivotti et al.

In der Regel werden die Komponenten einer Maschine, wie Getriebemotoren, so robust ausgelegt, dass sie die Maschinenlebensdauer möglichst ohne Wartung überleben. Dieser Ansatz sorgt dafür, dass die Wartung bedarfsorientiert erfolgt. Folgende Effekte wurden abgebildet: • Alterung des Getriebeöls – wie beim Auto ist abhängig von der Nutzung des Getriebes ein Ölwechsel sinnvoll. • Verschleiß des Wellendichtrings an der Abtriebsseite/Ausgangsseite des Getriebes  – der Wellendichtring wird abhängig von verschiedenen Belastungsgrößen irgendwann durchlässig. Diesen gilt es nicht zu früh und nicht zu spät auszutauschen. Im Folgenden wird die Umsetzung von Restlebendsdauermodellen zu diesen zwei Phänomenen beschrieben. Restlebensdauermodell Genau wie bei einem Auto benötigt das Getriebe eines industriellen elektrischen Getriebemotors Öl für die Schmierung der Lager und den Eingriff der Zahnflanken. Ein Tausch des Öles wird vom Hersteller abhängig von der Belastung nach einer definierten Betriebsdauer empfohlen. Für die Einflussgrößen Drehzahl, Drehmoment, Temperatur und die konstruktiven Eigenschaften wie Aufbau des Getriebes und Öl-Typ ist eine Empfehlung zum Ölwechsel aufgrund von Erfahrungen und Messungen in der Projektierungsanleitung beschrieben. Es ist bekannt, dass diese Empfehlung nur sehr ungenau getroffen werden kann, da wichtige Einflussgrößen wie z. B. die Verunreinigung der Umgebungsluft oder Reinigungen in Lebensmittelproduktionen nicht berücksichtigt werden. Außerdem werden die Antriebe in der Regel variabel betrieben, so dass Worst-Case-Annahmen getroffen werden müssen. Um hier eine Verbesserung zu erzielen, kann eine Alterung oder ein Verschleiß in Modellen durch Kenntnis der Belastungen wie Drehzahl, Drehmoment und Temperatur kontinuierlich gerechnet werden, indem eine Mikroalterung aufsummiert wird. So ist eine sofortige Nutzung des heute verfügbaren Wissens möglich und kann dann langfristig über Ansätze von Big Data weiter ausgebaut und optimiert werden. In diesem Projekt wurden ein Modell zur Alterung von Öl und eines zum Verschleiß des Wellendichtrings von Getrieben abgebildet. Die Einflussgrößen bei beiden Effekten sind ähnlich. Der Wellendichtring reagiert nicht auf das Drehmoment. Die Zusammenhänge zwischen Betriebspunkt und abgeschätzter Lebensdauer sind nicht linear und wurden approximiert. Abb. 8.7 zeigt beispielhaft ein Ergebnis eines solchen Modells, bei dem zu Vorführzwecken die theoretische Alterung so hoch skaliert wurde, dass schon nach ca. einer Minute eine Wartungsmeldung abgesetzt wurde. Im Normalbetrieb verändert sich der Wert nur sehr langsam, insbesondere in der InnoServPro-Beispielmaschine welche die Antriebsachsen nur sehr gering belasten.

8  Anwendungsfall BHN/Lenze/Schaeffler

201

Abb. 8.7  Präsentation Vorstellung Hannover-Messe 2017

8.4  Ausgewählte Elemente des Informationsmanagements In diesem Kapitel sind die Umsetzungen und Untersuchungen für den industriellen Use-­Case aus den Arbeitspaketen zur Business Analytics, zum Back-End und zum Front-End dargestellt.

8.4.1 Entwicklung der Business Analytics Im nachfolgenden Kapitel werden die einzelnen Inhalte der Entwicklung der Business Analytics für den Use-Case BHN/Lenze/Schaeffler detailliert erläutert. Darin inbegriffen sind Serviceberichtanalyse, Konzept zur Ausfallvorhersage sowie die Konzeption der Datenaufzeichnung für die Business Analytics.

8.4.1.1  Serviceberichtanalyse Lenze besitzt eine umfangreiche Datenbank, in der Informationen über Servicefälle der ausgelieferten Produkte der letzten Jahrzehnte enthalten sind. Diese Datenbasis dient als

202

D. Olivotti et al.

Grundlage für Analyse von Fehlerschwerpunkten, Problemlösungen und Erfahrungen bei der Instandsetzung ausgewählter Produkttypen. Im Rahmen des InnoServPro wurde eine Datenbasis bestehend aus ca. 435.000 Datensätzen für Elektronik-Produkte herangezogen. Neben strukturiert abgelegten Daten gibt es auch unstrukturierte Daten in Form von Freitextfeldern. In diesen Freitextfeldern tragen Servicemitarbeiter Informationen zur Ursache, Befundung und Maßnahmen ein. Die strukturierten Daten werden bereits laufend bei Lenze ausgewertet. Daher wurde in InnoServPro sich auf die Analyse des unstrukturierten Texts in den Freitextfeldern konzentriert. Daraus ergibt sich die Anforderung, in einer umfangreichen Menge von Texten Muster und Häufigkeiten zu erkennen und zu interpretieren. Für die Analyse dieser Daten wurden die Pakete in R wie „Quanteda“, „Caret“, „ggplot“ und „tm“ genutzt, die das Natural L ­ anguage Processing (NLP) und statistische Textauswertungen und Visualisierungen unterstützen. Da diese Daten sensible Geschäftsinformationen sind und der Geheimhaltung unterliegen, wird in diesem Bericht beispielhaft eine Auswerteroutine dargestellt, um im Begutachtungstext nach den Bereichen „Ursache“, „Befund“ und „Maßnahme“ zu unterscheiden und insbesondere die Daten nach dem Begriff „Ursache“ auszuwerten. Hierzu werden Wordbags der gefilterten Texte erstellt, über vordefinierte Stopword-Listen sowie manuell erstellte Stopword-Listen reduziert und im Anschluss die für Textauswertungen typischen Wordclouds erstellt, bei denen die Wortgröße mit der Häufigkeit des Auftretens korrelieren (Abb. 8.8).

Abb. 8.8  Auswerteroutine grafisch

8  Anwendungsfall BHN/Lenze/Schaeffler

203

Neben den Analysen der Servicetexte wurden weitere Analysen auf Basis der Servicedaten durchgeführt und mit Fachexperten aus verschiedenen Bereichen diskutiert: • Korrelation zwischen Bauteilausfällen und Leistungsstufen von Umrichtern • Korrelation zwischen Bauteilausfällen und Kundenbranchen für bestimmte Leistungsstufen von Umrichtern • Kombinierte Analyse zwischen Leistungsstufen, Kundenbranchen und Servicefällen • Test von Ansätzen des Machine Learnings für die Zuordnung von Texten und Begriffen zu Leistungsstufen Grundsätzlich ist die Datenbasis sehr umfangreich und strukturiert. Bei den erwähnten Freitextfeldern zeigt sich jedoch, dass diese für Auswertungen durch maschinelles Lernen schwer verwendbar sind. Dies ergab sich daraus, dass Symptom, Ursache und Maßnahme in einem Textfeld erfasst wurden. Um in der Vielzahl der Datensätze (> 50.000 unterscheidbare Fälle) Informationen zu extrahieren, war eine Vorbearbeitung der Textfelder notwendig, die mithilfe von Algorithmen die Felder in zuordenbare Einheiten unterteilt. Die bei der Auswertung der Servicedatenbank gewonnenen Erkenntnisse lassen sich allerdings gut für die Strukturierung einer neuen Servicedatenbank heranziehen. So könnte es z. B. von Vorteil sein, die Daten nicht mehr in einer tabellarisch gegliederten Struktur (wie in einer relationalen Datenbank) abzulegen, sondern in Dokumentenstruktur (wie beispielsweise in einer NoSQL-Datenbank). Hierbei ist es beispielsweise egal, wie viele Bauteile bei einer Service-Begutachtung als fehlerhaft begutachtet wurden, da diese einfach als erweiterbares Array im Servicefall gespeichert werden. Damit ergeben sich sowohl für die Eingabe durch den Servicetechniker als auch für die Darstellung der Daten und die Auswertungen weitere Möglichkeiten. Die folgende Abb.  8.9 zeigt beispielhaft eine NoSQL-­Datenbank, bei der für das Attribut „Fehlerhafte Bauteile“ unterschiedliche Anzahlen an Bauteilen je Fall hinterlegt sind.

8.4.1.2  Konzept zur Ausfallvorhersage anhand eines Beispiels Es gibt verschiedene Ursachen oder auch Mechanismen, welche zu Störungen führen. Als Ergebnis der Befragung eines großen Maschinenbetreibers aus der Automobilindustrie resultierte, dass Störungen, welche als Fehler eines Antriebs wahrgenommen werden, häufig nicht durch den Antrieb selbst verursacht wurden, sondern durch die Abhängigkeit von anderen Komponenten. Wie spontane, nicht vorhersehbare Störungen erkannt und klassifiziert werden können, wird an nachfolgendem Beispiel gezeigt. Anomalieerkennung beim Durchrutschen eines Übertragungsriemens:  Im Versuch wird das Förderband mit unterschiedlichen Massen belegt (siehe Abb. 8.10). Anschließend werden die unterschiedlichen Massen unabhängig voneinander zwischen den beiden Umlenkrollen verfahren und dabei die Sensordaten erfasst. Ein Ausschnitt aus den erfassten Daten ist in Abb. 8.11 dargestellt.

204

D. Olivotti et al.

Abb. 8.9  Beispiel für eine NoSQL-Datenbank (Anzahl der fehlerhaften Bauteile kann sich unterscheiden – siehe Pfeil)

Abb. 8.10  Versuchsanordnung und Ausgangssituation

Folgende Daten wurden als Messreihen zur Verfügung gestellt: • Trainingsdaten: störungsfreie Messreihen • Anonyme Daten: störungsbehaftete und störungsfreie Messreihen Zielfragestellung: „Ist es möglich, durch den verwendeten Algorithmus zwischen den störungsbehafteten und den störungsfreien Fällen in den anonymen Datensätzen zu unterscheiden?“

8  Anwendungsfall BHN/Lenze/Schaeffler

205

Abb. 8.11  Daten der Förderanlage

Da a priori keine Einteilung in „gut“ und „schlecht“ möglich ist, scheiden Algorithmen wie RandomForest, rpart oder ähnliche aus. Für die Auswertung der Daten wurden zwei Ansätze zur Modellbildung verfolgt: • Hauptkomponentenanalyse (PCA – Principal Component Analysis) • Autokorrelationsanalyse zur Erkennung von Abweichung von den „idealen“ Bedingungen für periodische Vorgänge Die Hauptkomponentenanalyse wird im Folgenden detailliert betrachtet. Machine Learning eignet sich insbesondere zur Anomalieerkennung sowie zur Extraktion höherwertiger Information (beispielsweise automatische Erkennung von Prozesszuständen). Die besondere Eigenschaft des Machine Learnings liegt im Gegensatz zu den modellbasierten Ansätzen wie im Use-Case GRIMME in ihrer selbstständigen Lernfähigkeit basierend auf einer bestimmten Menge von Daten. So können diese Verfahren basierend auf einem Trainingsdatensatz selbstständig bestimmte Aufgaben erlernen, ohne explizit dafür programmiert zu werden – es ist kein physikalisches Modell oder Expertenwissen erforderlich. Die Leistungsfähigkeit und die Möglichkeit der Erkennung von Anomalien des hier verfolgten Ansatzes hängen somit von der Struktur und Anordnung der einzelnen Algorithmen ab. Die Herausforderung bei der Entwicklung derartiger Algorithmen besteht nun darin, die Struktur zu finden, welche für die Erkennung von Anomalien an Förderanlagen die besten und zuverlässigsten Ergebnisse liefert.

206

D. Olivotti et al. Autoencoder Encoding

Rohdaten

Decoding

Vorverarbeitung - Entfernung Ausreißer - Erzeugung Features - Normalisierung - Whitening ...

Datenrekonstruktion

Rekonstruktion

Zustandsvektor Eingangsfeatures

Labels

Rekonstruierte Features

Anomalieerkennung - Detektion - Klassifikation - Vorhersage

Abb. 8.12  Darstellung eines generischen Ansatzes zur Erkennung von Anomalien mittels Autoencodern

Aus der langjährigen Erfahrung hat sich bei der Anomalieerkennung der in Abb. 8.12 dargestellte generische Ansatz mittels Autoencoder für verschiedenste Anwendungsszenarien bewährt. Dieser besteht aus den folgenden Modulen: • Vorverarbeitung: Aus dem Rohsignal werden Ausreißer entfernt, das Rohsignal wird normalisiert und de-korreliert, so dass die nachfolgenden Algorithmen möglichst aussagekräftige Informationen über die Förderbandanlage extrahieren können. • Autoencoder: Ein aussagekräftiger Zustandsvektor wird aus den Eingangsmerkmalen (Features) extrahiert, der es ermöglicht, basierend auf diesem Zustandsvektor die Eingangsmerkmale wieder möglichst genau zu rekonstruieren. Trainingsdaten werden genutzt, um dieses Modell möglichst gut an diese Daten anzupassen. • Datenrekonstruktion: Das Rohsignal wird basierend auf dem rekonstruierten Merkmalsvektor wieder rekonstruiert. Bei den Trainingsdaten sollte die Differenz zwischen Rohsignal und rekonstruiertem Signal minimal sein. • Anomalieerkennung: Die Rohdaten, der Zustandsvektor und das rekonstruierte Signal können nun genutzt werden, um Anomalien zu erkennen. Beispielsweise durch die einfache Differenz zwischen Rohsignal und rekonstruiertem Signal. Der wichtigste Bestandteil in dem hier verfolgten Ansatz ist der Autoencoder: je besser dieser sich an die Trainingsdaten anpassen und allgemeingültige Zustandsvektoren identifizieren kann, desto besser, robuster und prozesssicherer können Anomalien in der Förderbandanlage erkannt werden. Die folgenden Algorithmen können prinzipiell als Autoencoder verwendet werden: • Principal Component Analysis (PCA), Hauptkomponentenanalyse, ist ein Verfahren aus der multivariaten Statistik. Basierend auf einer mittels Trainingsdaten gelernten Linearkombination von Daten kann z. B. ein erwarteter Messwert und somit die Abweichung zum tatsächlichen Messwert berechnet werden.

8  Anwendungsfall BHN/Lenze/Schaeffler

207

• Künstliche Neuronale Netze (KNN) sind mathematische Beschreibungen, welche versuchen, die Struktur und Informationsarchitektur eines Nervensystems von Tieren oder Menschen näherungsweise abzubilden. Die besondere Eigenschaft der KNN ist ihre selbstständige Lernfähigkeit, d. h. basierend auf einem Trainingsdatensatz können sie bestimmte Aufgaben selbstständig erlernen, ohne explizit dafür programmiert zu ­werden. • Self-Organizing Maps (SOM) sind eine besondere Art von KNN für das unüberwachte Lernen von Merkmalen bezogen auf abgegrenzte Datengruppen. Die gelernten Merkmale können zur Überprüfung der Plausibilität der Mess- und Erfassungsdaten genutzt werden, d. h. der Erkennung von Auffälligkeiten. • Generative Topographic Mapping (GTM) kann als probabilistische Erweiterung von SOMs gesehen werden. Unsicherheiten in Mess- und Erfassungsdaten und dem gelernten Modell können systematisch berücksichtigt werden. Um in einem ersten Schritt den Aufwand gering zu halten und möglichst schnell Ergebnisse zu bekommen, wurden in den jeweiligen Modulen einfache Algorithmen ausgewählt, welche mit möglichst wenig Parameteroptimierung auskommen. Nach der Evaluierung der Ergebnisse können die Algorithmen entsprechend angepasst, weiter optimiert oder ausgetauscht werden. Die Vorgehensweise für die Analyse ist in Abb. 8.13 und die Anomalieindikatoren und deren automatisch bestimmten Schwellwerte für die Förderanlage in Abb. 8.14 dargestellt. In Abb. 8.15 bzw. Abb. 8.16 sind beispielhaft Ergebnisse dargestellt, bei denen eine bzw. keine Anomalie erkannt wurde. Mit den dicken, dunklen Linien ist der Motorstrom aller Trainingsdaten und in der dünnen, hellgrauen Linie der zu analysierende Signalverlauf dar-

Abb. 8.13  Erkennung von Anomalien mittels Autoencodern bei den Messdaten der Förderanlage

208

D. Olivotti et al.

Abb. 8.14  Anomalieindikatoren und deren Schwellwerte für die Förderanlage-Messdaten

gestellt. Es ist sehr deutlich zu sehen, dass der Anomalieindikator des Algorithmus die abnormalen Signalverläufe erkennt und bei normalen Signalverläufen nicht ausschlägt. In den Trainingsdaten ist der Fall eines Gewichts von 33 kg nicht vorhanden, allerdings in den Testdaten. Trotzdem schlägt der Anomalieindikator bei einem unbekannten Gewicht nicht aus, obwohl der Signalverlauf anders ist (siehe unterster Plot in Abb. 8.16). Dies spricht für die Interpolationsfähigkeit des hier entwickelten Algorithmus bezüglich des Gewichts.

8.4.1.3  Konzeption der Datenaufzeichnung für Business Analytics Die Datenaufzeichnung ist so konzipiert, dass eine stetige Verbesserung der Instandhaltung der Maschinen ermöglicht werden kann. Das betrifft die Erhöhung der Verfügbarkeit, aber auch die Verringerung der Kosten für Wartungen und Störungsbeseitigung. Für die Datenaufzeichnung bedeutet dies, dass jene Daten aufgezeichnet werden müssen, welche die Analyse derzeit noch unbekannter Störungen und Ausfallerscheinungen erlauben. Auf der einen Seite sollen die Daten bei der manuellen Ursachenanalyse unterstützen und auf der anderen Seite eine automatisierte Erkennung und Klassifizierung von Ursachen ermöglichen. Im Folgenden ist beschrieben, wie die Datenaufzeichnung konzipiert ist und wie diese Ansatzweise genutzt werden kann. Damit die Suche nach einer Ausfallursache durch einen Experten für die Maschine, unterstützt wird, wurden zu entsprechenden Komponenten in der Maschinenstruktur, welche auch Sensor- oder Zustandsdaten liefern, ein Dashboard definiert, auf dem die Signale sinnvoll dargestellt sind (siehe Abb. 8.17). Außerdem wurde beispielhaft eine Oberfläche realisiert, welche das Auftreten eines spezifischen Fehlers auflistet. Aus dieser Auflistung heraus kann man dann zu den Sensordaten der Komponente gelangen, welche diese Störung gemeldet hat. So kann ein Experte aufgrund der Daten sofort eine genauere Einschätzung der Situation geben. Die Information über die Störung wird auch an den digitalen Zwilling übergeben, welcher den Zustand

8  Anwendungsfall BHN/Lenze/Schaeffler

209

Motorstrom Filename: 2.mat



Timerange: 22512 – 24712 Gewicht: 22 kg

  

Filename: 9.mat



Timerange: 1577 – 3777 Gewicht: 72 kg

   Filename: 4.mat



Timerange: 9485 – 11685 Gewicht: 32 kg

   Filename: 6.mat



Timerange: 14230 – 16430 Gewicht: 62 kg

  







        WLPHVDPSOHV

Abb. 8.15  Beispiele von Datensamples bei denen eine Anomalie detektiert wurde. Hinweis: hier sind nur die Motorströme dargestellt, dunkle Linien: Trainingsdaten, hellgraue Linie: Datensample

der Maschine ändern kann, um z. B. den Instandhalter oder den Maschinenbediener zu informieren. Dieser kann dann aufgrund der dargestellten Sachlage entscheiden, welche Services nötig sind, um die Ursache nachhaltig und effizient zu beheben (siehe Abb. 8.18). Bis hier hin ist in dem Projekt eine demonstrierbare Lösung entstanden. Im Folgenden wird ein kleiner Ausblick gegeben. Wenn ein bestimmter Fehler häufiger auftritt, ist es möglich, die relevanten aufgezeichneten Sensordaten verbunden mit den im Serviceauftrag erfassten Einschätzungen eines Servicetechniker zu einem Fehlertyp an einen Analytics-Experten zu übergeben. Dieser kann nach Korrelationen des Fehlertyps mit anderen aufgezeichneten Daten suchen. Zu dieser Modellbildung können Algorithmen (z. B. Random Forrest, rpart für überwachtes oder Neuronale Netze für das nicht-überwachte Lernen) eingesetzt werden. Die so gefundenen Modelle können dann an der entsprechenden Stelle in der Maschinenstruktur die

210

D. Olivotti et al. Motorstrom Filename: 1.mat Timerange: 41427 – 43627 Gewicht: 11 kg

6 4 2 0

Filename: 5.mat Timerange: 46250 – 48450 Gewicht: 55 kg

6 4 2 0

Filename: 11.mat Timerange: 76339 – 78539 Gewicht: 72 kg

6 4 2 0 6

Hinweis:

In Trainingsdaten keine Samples mit 33 kg vorhanden.

4

Filename: 3.mat Timerange: 36717 – 38917 Gewicht: 33 kg

2 0

200

400

600

800 1000 1200 1400 1600 1800 2000

2200

time / samples

Abb. 8.16  Beispiele von Datensamples bei denen keine Anomalie detektiert wurde. Hinweis: hier sind nur die Motorströme dargestellt, dunkle Linien: Trainingsdaten, hellgraue Linie: Datensample

anfallenden Daten überwachen und bei Bedarf vor einem Ausfall der Maschine warnen. Die Instandhaltung kann auf dieser Basis präventiv tätig werden. So wird die Instandhaltung über die Zeit immer effizienter und damit kostengünstiger bei einer gleichzeitigen Erhöhung der Verfügbarkeit. Für einen Hersteller wie Lenze bedeutet dies, Daten nicht nur einer einzelnen Anlage (wie im Falle des Demonstrators für das Forschungsvorhaben) zu erfassen, sondern z. B. baugleiche Antriebe in einer Vielzahl von Anlagen datentechnisch zusammenzuführen, um aus verschiedenen, evtl. branchenbedingten Ausfällen ganzheitliche Konzepte zur Fehlerprävention oder präventiven Instandhaltung zu entwickeln. Darüber hinaus lassen sich durch die erfassten Daten und die aufgezeichneten Serviceberichte die oben genannten thermischen Modelle mit der Realität abgleichen und iterativ verbessern. Der Zusammenhang stellt sich dann wie in der folgenden Abb. 8.19 dar.

8  Anwendungsfall BHN/Lenze/Schaeffler

Abb. 8.17  Dashboard am Beispiel der Sensordaten vom Schaeffler-Sensor

Abb. 8.18  Dashboard mit Störungen an der Achse H1 und zugehörigen Sensordaten

211

212

D. Olivotti et al.

Abb. 8.19  Einbindung der Business Analytics im Rahmen der präventiven Instandhaltung und Verfügbarkeitserhöhung

Daten von den Anlagen werden systematisch erfasst und gespeichert. Business Analytics bereitet einerseits die Daten so auf, dass sie als visuelles Hilfsmittel für die Anlagenverantwortlichen genutzt werden können, andererseits werden die Daten über Machine-­ Learning-­Verfahren so analysiert, dass Modelle zu einer Eigenüberwachung der Anlagen eingesetzt werden können. Dazu fließen wiederum Daten aus der Durchführung von Service und Instandhaltung in die Datenbasis zurück. Daraus ergibt sich ein Wechselspiel, das zu einer steten Verbesserung beiträgt.

8.4.2 Entwicklung des Back-Ends Das Back-End des Anwendungsfalls BHN/Lenze/Schaeffler verbindet viele Aspekte der beiden vorangehenden Use-Cases. Die Beispielmaschine liefert Informationen über ihren Status, wodurch kritische Zustände frühzeitig erkannt werden können. Aber auch beim Auftreten eines Fehlers soll der Servicetechniker mit relevanten Informationen versorgt werden. Darüber hinaus stehen im vorliegenden Anwendungsfall die beteiligten Rollen mit ihren unterschiedlichen Sichten auf die Daten des BackEnds im Vordergrund. In den folgenden Abschnitten wird zunächst die Umsetzung des fachlichen Datenmodells aus Abschn. 5.5.1 beschrieben. Anschließend wird anhand der konfigurationsspezifischen Service-Dokumentation beschrieben, wie das resultierende System

8  Anwendungsfall BHN/Lenze/Schaeffler

213

I­nstandhaltungsprozesse unterstützen kann. Dies ist naturbedingt eng mit dem im folgenden Unterkapitel beschriebenen Front-End verzahnt. Beschreibungen der Rollen sowie der konkreten Benutzeroberflächen sind dort zu finden.

8.4.2.1  Umsetzung des technischen Datenmodells Für die prototypische Implementierung des Datenmodells in Aras Innovator wird in einem ersten Schritt eine Spezifikation erstellt, bevor aufbauend auf der Analyse toolspezifischer Eigenheiten die eigentliche Implementierung des Datenmodells vorgenommen wird. Ausleitung der Spezifikation Das in Abschn. 5.5.1 beschriebene fachliche Datenmodell in Form des im Cameo Systems Modeler definierten Block-Definition-Diagramms dient als Basis für die Ausleitung der Spezifikation. Die Spezifikation umfasst dabei im Wesentlichen alle definierten Datenobjekte und Relationen zwischen diesen. Um einen direkten Export aus dem fachlichen Datenmodell zu ermöglichen, werden die Tabellen „Datenobjekte Übersicht“ und „Relationen Übersicht“ erstellt. Abb.  8.20 zeigt einen Auszug aus der erstgenannten Tabelle, abgebildet sind die für das Forschungsprojekt InnoServPro zentralen Datenobjekte Digital Master, Digital Twin Item und Digital Twin Item Status.

Abb. 8.20  Auszug aus der Tabelle „Datenobjekte Übersicht“

214

D. Olivotti et al.

In der Tabelle „Datenobjekte Übersicht“ werden alle definierten Datenobjekte samt ihren Eigenschaften (Value Properties, kurz V) und den in Zusammenhang mit ihnen stehenden Objekten (Related Objects, kurz R) aufgelistet. In der Spalte Dokumentation finden sich die dem jeweiligen Datenobjekt zugrunde liegenden Anforderungen wieder. In der Tabelle „Relationen Übersicht“ werden alle definierten Relationen samt ihren Start- und Zielobjekten aufgelistet. Daneben wird jeweils die definierte Multiplizität aufgeführt. In der Spalte Dokumentation finden sich die der jeweiligen Relationen zugrundeliegenden Anforderungen wieder. Abb. 8.21 stellt einen exemplarischen Auszug dar, die Relationen sind zeilenweise von links nach rechts zu lesen: „0 bis n Datenobjekte vom Typ Hierarchie haben übergeordnet 1 bis n Datenobjekte vom Typ PSS Objekt“. Die in den exportierten Listen spezifizierten Datenobjekte und Relationen werden entsprechend ihrer Sinnzusammenhänge in acht Cluster unterteilt. Dies ermöglichte eine parallele Implementierung durch mehrere Projektbeteiligte. Bei der Implementierung gemachte Erfahrungen können so direkt in den weiteren Prozess der Implementierung einfließen und diesen gegebenenfalls beeinflussen. Bei der Implementierung des fachlichen Datenmodells anhand der ausgeleiteten Spezifikation müssen die Eigenheiten des Zielsystems Aras Innovator berücksichtigt werden. Der eigentlichen Implementierung geht daher eine kurze Analyse der vorgesehenen Datenmodellierung auf Typ-Ebene voraus. Aufgaben der Konfiguration und Administration in Aras Innovator können mit entsprechenden Berechtigungen zur Laufzeit ausgeführt werden und stellen keine Beeinträchtigung der Systemverfügbarkeit dar.

Abb. 8.21  Auszug aus der Tabelle „Relationen Übersicht“

8  Anwendungsfall BHN/Lenze/Schaeffler

215

Datenobjekte werden in Aras Innovator als Item Types angelegt, Attribute werden diesen als Properties hinzugefügt. Die zwischen den Datenobjekten definierten Relationen werden in Aras Innovator als Relationship Types angelegt. Für jeden Relationship Type wird automatisch ein Item Type mit identischer Benennung angelegt. Diesem können Attribute der Relation als Properties hinzugefügt werden. Entsprechend der Terminologie des in Aras Innovator verwendeten Datenmodells werden Item Types, welche durch einen Relationship Type verknüpft sind, in Source (Start) und Related (End) Item Type unterschieden. Für den letzteren lässt sich eine Multiplizität festsetzen. Darüber hinaus kann ein zu einem Relationship Type zugehöriger Item Type selbst wieder Source oder Related Item einer anderen Relation sein. Wird für einen Relationship Type kein Related Item angegeben, spricht man von einer Null-­Relation. Im fachlichen Datenmodell vorgesehene Vererbungen der Eigenschaften und Relationen von Eltern- zu Kindelementen lassen sich nicht eins zu eins im Zielsystem abbilden. Die in Aras Innovator gebotenen Möglichkeiten zur Umsetzung von Eltern-Kind-­ Beziehungen sind die optionale Strukturhierarchie eines Item Types und der Poly Item Type. In der Strukturhierarchie werden Kindelemente als Subklassen eines Item Types angelegt. Beim Anlegen einer Instanz eines mit Subklassen versehenen Item Types kann dann die Auswahl der gewünschten Subklasse erfolgen. Properties des Item Types können zwar spezifisch einer Subklasse zugeordnet werden, nicht jedoch die für den Item Type vorgesehenen Relationen zu und von anderen Item Types. Diese werden auf oberster Ebene definiert und bleiben für alle Subklassen bestehen. Die Bündelung mehrerer Datenobjekte in Form der Implementierung mehrerer Subklassen zu einem Item Type bietet sich also bei Datenobjekten an, die sich gemessen an ihren Relationen und Attributen sehr ähnlich sind. Mit dem Poly Item Type wird ein Sammler angelegt, unter welchem verschiedenste Item Types gruppiert werden können. Diese sind jeweils separate Item Types mit eigenen Attributen und Relationen. Sie werden dem Poly Item als Poly Source hinzugefügt. Beim Instanziieren eines Poly Items werden alle angelegten Poly Sources zur Auswahl des gewünschten Item Types angezeigt. Aras Innovator verfügt in der Standardkonfiguration bereits über ein umfangreiches Datenmodell, das die klassischen Funktionalitäten eines PDM-Tools abdeckt. Für manche Datenobjekte des fachlichen Datenmodells bietet es sich deshalb an, auf bereits vorhandene Item Types zurückzugreifen und diese gegebenenfalls anzupassen. Implementierung der Datenobjekte und Relationen Die Item Types wurden zeitlich parallel zur fortlaufenden Ausleitung der zugrunde liegenden Spezifikation implementiert. Für die Implementierung der Datenobjekte und Relationen des fachlichen Datenmodells einigt man sich auf folgende grundlegende Konventionen: Datenobjekte werden als Aras Item Type, Relationen als Aras Relationship Type angelegt. Solange keine anderen Gründe dagegensprechen (bspw. Zeichenanzahl), werden Item und Relationship Types wie im fachlichen Informationsmodell benannt, um die im fachlichen Datenmodell vorgesehenen Generalisierungen (Eltern-Kind-Beziehungen) zu realisieren.

216

D. Olivotti et al.

Für einige Datenobjekte des fachlichen Informationsmodells existieren in der Standardkonfiguration von Aras Innovator bereits Item Types, deren Eigenschaften sehr nah an die zu erfüllende Spezifikation heranreichen. Mit vergleichsweise geringem Aufwand können diese an die in InnoServPro formulierte Spezifikation angepasst werden. Mit Ausnahme der Datenobjekte „PSS-Objekt“ und „Statuskomponente“ werden alle übrigen im fachlichen Datenmodell definierten Datenobjekte im Zielsystem Aras Innovator implementiert. Die Datenobjekte „PSS-Objekt“ und „Statuskomponente“ sind im fachlichen Datenmodell als Elternelemente definiert. Gründe gegen ihre Implementierung sind die oben erwähnten, toolspezifischen Einschränkungen in der Vererbung von Attributen und Relationen von Eltern- zu Kindelementen, die signifikanten Unterschiede der Kindelemente (siehe PSS-Objekt) und dass über die Vererbung der Relationen hinaus kein weiterer Grund zur Generalisierung bestünde (siehe Statuskomponente). Man kommt stattdessen überein, die an den Elternelementen anknüpfenden oder von diesen ausgehenden Relationen direkt anknüpfend an bzw. ausgehend von den Kindelementen zu implementieren. Von einer eingangs favorisierten Implementierung der Datenobjekte „Digital Master“ und „Digital Twin Item“ als Subklassen in der Class Structure des Part Item Types wird im Verlauf des Projektes Abstand genommen. Diese Implementierung ginge mit großen Einschränkungen bezüglich der spezifisch für Twin und Master zu definierenden Relationen einher. Auch wäre die Entwicklung eines später aufsetzbaren Rechtekonzepts erschwert, welches die Berechtigungen für Anzeigen, Erstellen und Editieren der Digital Master und Digital Twin Items differenziert betrachten würde. Stattdessen wird separat zum Part Item Type (Digital Master) ein eigens für den Digital Twin vorgesehener Item Type angelegt. Am Digital Twin Item Type lassen sich getrennt vom Digital Master Item Type die erforderlichen Attribute und Relationen implementieren. Ein für den Digital Twin eigenes Icon erleichtert zudem die Unterscheidung von Digital Master und Digital Twin Items. Die Datenobjekte „Digital Master“, „Digital Twin Item“ und „Parameter“ werden als Item Types mit darunterliegender Class Structure implementiert. Die Class Structure des Part Item Types für den Digital Master umfasst die für den Part Item Type bereits existenten Subklassen Assembly, Component, Material, Software und Variant. Hinzu kommen die aus der Spezifikation des fachlichen Informationsmodells abgeleiteten Subklassen Engineering Gathering Number, Engineering Top Number, Produkt und Systemmodell. Die Class Structure für den Digital Twin Item Type sieht die dargestellten Subklassen Assembly, Component, Engineering Gathering Number, Engineering Top Number, Produkt und Systemmodell vor. Die für den Parameter Item Type angelegte Class Structure sieht die Unterteilung in die Subklassen Integer Parameter, Real Parameter und String Parameter vor. Die Datenobjekte „Firma“, „Repräsentation“ und „Technische Dokumentation“ werden als Poly Item implementiert. Dem Firma Item Type werden die Item Types Maschinenbauer, Maschinenbetreiber und Servicepartner als Poly Sources zugeordnet. Mit dem Repräsentation Item Type werden die Item Types Programmierung Parametrierung, Geographische Koordinaten, Zweidimensionale Darstellung und SysML Systemmodell ge-

8  Anwendungsfall BHN/Lenze/Schaeffler

217

sammelt. Dem Technische Dokumentation Item Type werden die Item Types Betriebsanleitung, Log File, Service Anleitung und Service Bericht zugeordnet. Durch die oben dargelegten Eigenheiten des Zielsystems ergeben sich formale Unterschiede zwischen dem fachlichen (in SysML modellierten) und technischen (ebenfalls im Modell dokumentierten sowie anschließend implementierten) Datenmodell. Durch sorgfältige Dokumentation bleibt trotzdem die Nachverfolgbarkeit erhalten. Nach dem Aufbau des Datenmodells folgt die Implementierung der vorgesehenen Prozesse. Die folgenden Abschnitte beschreiben Besonderheiten im Rahmen des Anwendungsfalls BHN/Lenze/Schaeffler.

8.4.2.2  K  onfigurationsspezifische Serviceanleitung und – Dokumentationen Das Produktportfolio der Firma Lenze ist sehr variantenreich und die einzelnen Produkte können mit unterschiedlichen Spezifikationen bestellt werden. Beispielsweise können Umrichter in verschiedenen Leistungsklassen bestellt werden und mit Zusatzmodulen und verschiedenen Feldbussystemen versehen sein. Um sowohl Endanwender als auch Techniker bestmöglich zu unterstützen, sollten relevante Serviceanleitungen und -Dokumentationen entsprechend des konfigurierten, individuellen Produktes vorhanden sein. Dazu wurde im Back-End an die jeweiligen Komponenten (Digital Twin) entsprechende Anleitungen hinzugefügt, die sich auf ein auskonfiguriertes Produkt beziehen. Eine Reduktion von Suchzeiten und die Vermeidung von Fehlern durch eine Informationsflut werden hierdurch unterstützt. Folgende Dokumentation wurde zugeordnet: • • • •

Anleitungen Datenblätter Wartungshinweise Softwarestände und Konfigurationen

Sobald der Maschinenbediener einen Fehler feststellt, kann er selbst oder ein Servicetechniker die entsprechende Anleitung im Back-End aufrufen. Diese ist so gestaltet, dass der Nutzer durch einen bebilderten Schritt-für-Schritt-Prozess geleitet wird. Innerhalb dieses Prozesses werden dem Nutzer basierend auf den Informationen der Sensoren und Input des Benutzers mögliche Behebungsoptionen vorgeschlagen. Hierbei wird wiederum Feedback von dem Nutzer angefordert, ob der jeweilige Schritt zur Behebung des Problems beigetragen hat und sukzessive weitere Schritte auf Basis der wahrscheinlichsten Fehlerbehebungsmöglichkeit vorgeschlagen.

8.4.3 Entwicklung der Front-Ends Zur Anzeige der aufgenommenen Sensordaten und Analyseergebnisse ist ein Front-End notwendig. Dies sollte nicht nur Use-Case-spezifisch, sondern auch rollenspezifisch sein. In diesem Kapitel wird deshalb vorgestellt, welche Möglichkeiten die Front-Ends des

218

D. Olivotti et al.

Abb. 8.22  Vorgehen bei der Definition der Front-Ends

Use-Case BHN/Lenze/Schaeffler bieten und wie sich diese für die einzelnen Rollen ­unterscheiden und angeboten werden. Dabei werden die wichtigsten Funktionalitäten erläutert und im Bezug zum Use-Case betrachtet. Bei der Definition des Front-Ends wurden die Ergebnisse aus dem entwickelten Geschäftsmodell berücksichtigt. An der folgenden Abb. 8.22 kann das prinzipielle Vorgehen dargestellt werden. Aufgrund des definierten Wertschöpfungsnetzwerkes können die wichtigsten beteiligten Rollen ermittelt werden. Aufgrund des Business Modell Canvas können wichtige Inhalte für die Darstellungen bewusst gemacht werden. Es werden zunächst die Rollen definiert und dann die prinzipiellen Anwendungsszenarien beschrieben. Bei der Festlegung einer Umsetzung sollte beachtet werden, dass zunächst ein beherrschbarer erster Umfang definiert wird, welcher dann sukzessive weiterentwickelt werden kann. Folgende Rollen und deren Aufgaben wurden bei der Definition des Front-Ends im Use-Case berücksichtigt: • Maschinenbediener des Maschinenbetreibers –– Überwachung der Datenaufzeichnung –– Störungsbeseitigung bei einfachen Störungen • Instandhalter des Verfügbarkeitsanbieters –– Ursachenanalyse von Störungen –– Organisation von Störungsbeseitigungen –– Organisation von Wartungen • Servicetechniker eines Dienstleisters –– Durchführung von Reparaturen und Wartungen

8  Anwendungsfall BHN/Lenze/Schaeffler

219

• Manager des Verfügbarkeitsanbieters –– Controlling der Kunden/Verfügbarkeitsverträge –– Analyse Optimierungspotenzial Anhand dieser Ergebnisse wurden folgende grundsätzlichen Anforderungen an das FrontEnd ersichtlich: • Es wird hauptsächlich der Zugriff auf die Daten im Back-End aus der Ferne benötigt. • Für den Maschinenbediener muss die Lösung auf bestehenden Anzeigegeräten inte­ griert werden können. • Der Maschinenbediener und Servicetechniker benötigen nur eine eingeschränkte Sicht auf das Back-End. • Für die Störungsanalyse ist eine Darstellung der nicht ausgewerteten Sensor- und Zustandsdaten sinnvoll. In den folgenden Unterkapiteln wird zunächst die beispielhafte Realisierung für die Aufgaben der verschiedenen Rollen vorgestellt. Anschließend wird die Realisierung eines Front-Ends für den Maschinenbediener aufgezeigt.

8.4.3.1  Entwicklung des maschinenunabhängigen Front-Ends Wie oben bereits dargestellt, ist für die in den Prozess involvierten Rollen ein Zugriff auf die Daten und Informationen aus der Ferne erforderlich. So kann z. B. der Instandhalter die erforderlichen Services an seinen in der Welt verteilten Maschinen planen und dabei die Daten und Erkenntnisse nutzen. Der Servicetechniker kann seine Arbeiten planen, bevor er den Maschinenbetreiber aufsucht. Wie in Abschn. 5.5.1 beschrieben wurde ein Modellierungswerkzeug für die Realisierung des Datenmodells eingesetzt. Da der Verfügbarkeitsanbieter die Mechanismen und das Wissen um die Verfügbarkeit der Maschinen ständig weiterentwickeln wird, wird dieser dieses Modellierungswerkzeug einsetzen, um flexibel alle Objekte anpassen und erweitern zu können. Im Projekt stellt sich dann die Frage, welche Oberfläche der Maschinenbediener oder ein Servicetechniker einsetzen kann. Da das Modellierungswerkzeug bereits alle Grundfunktionen wie einen rollenspezifischen Zugriff auf die Informationen in individuellen Ansichten unterstützt und multi-device-fähig ist, wurde auch für das Front-­ End Aras Innovator eingesetzt (siehe Abb. 8.23). Im Folgenden werden Beispiele der im Projekt erarbeiteten Front-Ends gezeigt. Ein möglicher Einstiegspunkt in das Front-End aus Sicht des Maschinen-Instandhalters ist der digitale Zwilling der Maschine. Hier sind alle relevanten Informationen zur einzelnen Maschine verfügbar. Anhand der (auf die servicerelevanten Komponenten reduzierten) Stückliste kann sich der Benutzer eine Übersicht über die Produktstruktur verschaffen. Wie in Abb. 8.23 dargestellt ist, wird für jede Komponente angezeigt, ob sie gerade einsatzbereit, in einem kritischen Zustand oder ausgefallen ist. So lässt sich ein Fehler am Produkt zu seiner Ursache zurückverfolgen. Im Fall von kritischen Zuständen können

220

D. Olivotti et al.

Abb. 8.23  Ansicht des digitalen Zwillings

Wartungsarbeiten vorgezogen werden, bei einem Ausfall kann ein entsprechender Instandsetzungsprozess beauftragt werden. Die beiden Prozesslisten sind in Abb. 8.24 abgebildet. Alle anderen Rollen haben die Möglichkeit, entsprechend ihrer Berechtigung Details zu diesen Serviceprozessen einzusehen. Nachdem ein Service beauftragt wurde, kann dieser nun im so genannten InBasket gesehen werden (siehe Abb. 8.25). Hier haben Servicetechniker die Möglichkeit, einen offenen Auftrag für sich zu beanspruchen („Claim Task“). Der Servicetechniker hat in den bereits beschriebenen Ansichten die Möglichkeit, sich über den anstehenden Prozess zu informieren. Nachdem alle bislang beschriebenen Schritte über das Standard-Webinterface von Aras Innovator ausgeführt werden können, kann der Servicetechniker für die Durchführung von Servicearbeiten zusätzlich auf ein für mobile Geräte optimiertes Front-End wechseln. Hier stehen ihm Schritt-für-Schritt-Anleitungen für alle von ihm beanspruchten Serviceprozesse zur Verfügung. In Abb. 8.26 ist exemplarisch ein Schritt aus der Anleitung zu einem Ölwechsel abgebildet. Diese Sicht steht für die entsprechenden Prozesse auch dem Maschinenbediener zur Verfügung.

8  Anwendungsfall BHN/Lenze/Schaeffler

221

Abb. 8.24  Wartungs- und Instandsetzungs-Prozesse

Abb. 8.25  Ausstehende Servicearbeiten im InBasket

Neben diesem webbasierten Front-End ist in diesem Use-Case auch ein Interface direkt an der Maschine implementiert, das im folgenden Abschnitt beschrieben wird.

8.4.3.2  Entwicklung des Maschinen-Front-Ends Im Use-Case BHN/Lenze/Schaeffler wird eine Maschine betrachtet, die eine Produktionsanlage mit Hubachsen und Förderbändern repräsentiert. Die Funktionseinheiten „Hubachse“ und „Bandförderer“ bestehen jeweils aus einem Umrichter und dem Antriebsmotor. Diese Komponenten werden durch verschiedene Produktionsprozesse verschieden stark ausgelastet und sind damit einem Verschleiß bis hin zum Ausfall ausgesetzt. Neben dem Verschleiß können an der Maschine Störungen auftreten, z. B. ein Klemmen des Förderbandes, durch welche Komponenten beeinträchtigt werden. Zur Erhöhung der ­Verfügbarkeit der Maschine werden diese Störungen erkannt und Hilfestellung zur schnellen Beseitigung in Form konkreter Reparaturhinweise gegeben. Für den Bediener der Maschine sind pro Funktionseinheit der Zustand und ausgewählte Sensorinformationen relevant. Für erkannte Fehler werden Reparaturhinweise angezeigt. In der Abb. 8.27 ist die Architektur im Use-Case BHN/Lenze/Schaeffler zu sehen. Analog zum WFE im Use-Case GRIMME stellt das Steuergerät M50 den CODESYS-­ WebVisu-­Server zur Verfügung. Das Gateway W30 ist mit dem Steuergerät M50 über Ethernet verbunden. Es stellt die Verbindung zum Internet bereit und spannt ein WLAN-­

222

D. Olivotti et al.

Abb. 8.26 Schritt-für-Schritt-­ Anleitung auf einem mobilen Endgerät

WLAN

Ethernet

Ethernet CoDeSys We bVisu Server

Html5-fähiger Browser

Steuergerät M50

Gate way W30

WFE auf Tablet

Abb. 8.27  Architektur im Use Case BHN/Lenze/Schaeffler

Netz auf. Ein mobiles Endgerät, wie z.  B. ein Laptop oder ein Tablet, kann mit einem HTML5-fähigen Browser dies auf den WebVisu-Server des M50 zugreifen und das Front-­ End visualisieren. Auf den folgenden Abbildungen ist das Maschinen-Front-End für den Use-Case BHN/ Lenze/Schaeffler mit entsprechenden Ansichten zu sehen. Auf der obersten Ebene des Front-Ends ist eine Übersicht der Maschine visualisiert, siehe Abb. 8.28. In der Übersicht ist die Produktionsstraße vom Use-Case BHN/Lenze/Schaeffler abgebildet mit einem Maschinenzustand, der durch eine Ampel repräsentiert ist. Der Zustand der gesamten Maschine leitet sich ab aus den einzelnen Zuständen der Komponenten und Funktionseinheiten.

8  Anwendungsfall BHN/Lenze/Schaeffler

223

Abb. 8.28  Visualisierung des Maschinenzustands

Die Buttons dienen dazu, in die jeweilige Ansicht der zu überwachenden Komponenten jeder Funktionseinheit und in verschiedene Untermenüs zu gelangen. Das Untermenü „aktuelle Fehler“ stellt zusätzliche Informationen über aktuell vorliegende Fehler bereit. Die Abb.  8.29,  8.30 und  8.31 zeigen jeweils die Ansicht der zu überwachenden Komponente an. Diese sind die Umrichter C1, C2, C4, C5, H1 und H2, die Getriebe C1, C2, C4, C5, H1 und H2 und das VarioSense-Lager, welches die zusätzlichen Informationen über ein Getriebe vorhält. Jede Komponenten-Ansicht besitzt wie die Maschinenübersicht ein Bild der Komponente mit dazugehöriger Zustandsampel. Mit der Zustandsampel wird der Verschleißzustand der jeweiligen Komponente abgebildet. Ausgewählte Messgrößen werden hier zusätzlich über automatisch aktualisierende Diagramme präsentiert. Beim Getriebe (Abb. 8.29) werden die Drehgeschwindigkeit, das Drehmoment und die Öltemperatur der letzten zehn Sekunden angezeigt. Beim Umrichter (Abb.  8.30) werden die aktive Betriebszeit und Kühlkörpertemperatur der letzten zehn Sekunden angezeigt. Anhand der Diagramme können Fehler oder ein untypisches Verhalten der Komponente erkannt werden. Die Buttons „nächste“ und „vorherige“ werden dazu genutzt, um zwischen den Komponenten der Maschine zu navigieren. Zurück zum Startbildschirm gelangt man mit dem Button „Zustand“. Bei dem Sensorsystem des Vario-Sense -Lagers, sieheAbb. 8.31, werden die Drehgeschwindigkeit und die gemessene Temperatur am Getriebe H1 angezeigt. Zusätzlich wird die Getriebe-Radialbelastung durch die beiden Werte „Versatz1“ und „Versatz2“ gezeigt. Aufgrund der Messwerte der Sensoren kann ein Rückschluss auf den Verschleißzustand des Getriebes dieser Hubachse gewonnen werden. Das Vario-Sense-Lager selbst hat keine

224

D. Olivotti et al. Komponente Getriebemotor C5

RotationSpeed [240000 / 2^15 rpm]

Komponentenzustand 4000 2000 0

nächste 9m

9m2s

9m4s

9m6s

9m8s

TorqueAct [1/2^15 NM]

vorherige Zustand

4000 2000 0

9m

9m2s

9m4s

9m6s

9m8s

9m4s

9m6s

9m8s

Oeltemperaturlst [°C]

30 20 9m

9m2s

Abb. 8.29  Maschinien-Front-End im Use-Case BHN/Lenze/Schaeffler: Getriebemotor C5

Abb. 8.30  Maschinen-Front-End im Use-Case BHN/Lenze & Schaeffler: Umrichter C1

Ampel, da es zusätzliche Sensorwerte zum Getriebe H1 liefert, welches bereits eine eigene Ansicht besitzt. Um die Verlässlichkeit der Sensorwerte des Vario-Sense-Lagers zu bewerten, werden zusätzlich die am Sensor angelegte Spannung „interne Spannung“ und die im Sensor gemessene Temperatur „interne Temperatur“ angezeigt. Das Vario-Sense-Modul im Lager wird mit ca. 12 V Spannung betrieben, die angezeigte Spannung wird diesen Wert widerspiegeln.

8  Anwendungsfall BHN/Lenze/Schaeffler

225

Schaeffler FAG VarioSense for Bearing 6206 Temperatur [°C]

26 24 22 20 18 16 14 12 10

Interne Temperatur [°C] 14

9m36s

9m38s

9m40s

9m42s

9m44s

Geschwindigkeit [U/min] 160 140 120 100 80 60 40 20 0

Interne Spannung [V] 11

9m36s

9m38s

9m40s

9m42s

Zustand

9m44s

Versatz [a.u.]

Versatz 1 [a.u.] 5400

5600

5200

5400 9m36s

9m38s

9m40s

9m42s

9m44s

9m36s

9m38s

9m40s

9m42s

9m44s

Abb. 8.31  Maschinen-Front-End im Use-Case BHN/Lenze/Schaeffler: Schaeffler FAG VarioSense for Bearing 6206

Ein weiteres Untermenü ist das Menü „Fehlerdetails“, das zusätzliche Details zu aufgetretenen Fehlern zeigt. Zu den Details gehören die Ursache, Auswirkung und die Behebung, sieheAbb. 8.32. Das Menü dient dem Maschinenbediener als Soforthilfemaßnahme, um mögliche Fehler schnell beheben zu können. Die Auswirkung beschreibt den Fehlerzustand, hier im Beispiel „Störung. Der Inverter wird sofort gesperrt. Der Motor wird momentenlos“. Zu diesem Fehler wird eine Ursache genannt und eine Möglichkeit zur Behebung, die vom Benutzer als „Ausgeführt“ markiert werden kann. Die in dieser Ansicht genannten Fehler samt Auswirkung und Behebung sind über das Maschinen-Front-End im Steuergerät gespeichert. Anbindung an das maschinenunabhängige Front-End Zusätzlich zu den Ansichten des Maschinen-Front-Ends ist eine Koppelung an das maschinenunabhängige Front-End möglich. Durch ein Browser-Element kann der Inhalt einer Internetseite in der Ansicht des Maschinen-Front-Ends angezeigt werden. Mit Hilfe dieses Elements ist eine eigene Interaktion mit dem Inhalt der angezeigten Internetseite möglich. Die Logik für Anzeige und Interaktion bleibt somit auf der Seite, an die geleitet wird. Dadurch können Maschinen übergreifende Inhalte wie Reparaturhinweise zentral verwaltet werden.

226

D. Olivotti et al. Fehlerdetails

Ursache

Geraeteauslastung (I*t) zu hoch.

Antriebsauslegung überprüfen.

Behebung

Auswirkung

Störung. Der Inverter wird sofort gesperrt. Der Motor wird momentenlos.

zurück

Ausgefuhrt

Abb. 8.32  Maschinen-Front-End im Use-Case BHN/Lenze/Schaeffler: Fehlerdetails

8.5  Realisierung des verfügbarkeitsorientierten Geschäftsmodells Das Kapitel zeigt auf, wie das verfügbarkeitsorientierte Geschäftsmodell für den dritten Use-Case aussieht. Dafür wird zum einen das Geschäftsmodell anhand des Business Modell Canvas erläutert, zum anderen wird das erarbeitete Wertschöpfungsnetzwerk beschrieben. Zur Veranschaulichung wird immer wieder der Demonstrator hinzugezogen. Die Grundidee des Geschäftsmodells liegt darin, dass der Bediener, der Instandhalter sowie der Manager in der Lage sein möchten, ihre Maschinen zu beherrschen und instand zu halten [1]. Gemäß dem Business Model Canvas wurden für die Entwicklung des Geschäftsmodells vier Dimensionen unterschieden. Die Dimensionen untergliedern den Business Model Canvas in das Angebotsmodell, das Kundenmodell, das Wertschöpfungsmodell und das Finanzmodell. Zudem enthält das Geschäftsmodell eine Übersicht über die Vorteile für den Anwender sowie Anreize für die Partner, die sich aus der Geschäftsmodellidee ergeben. Es werden außerdem mögliche Risiken betrachtet. Innerhalb des Angebotsmodells werden die Kundensegmente, das Nutzenversprechen sowie die Marktleistung betrachtet. Da das übergeordnete Ziel eine hohe Verfügbarkeit der Maschinen ist, ist der Maschinenbetreiber eine mögliche Kundengruppe. In diesem Fall handelt es sich um einen Direktvertrieb des Serviceanbieters. Häufig ist es jedoch so, dass ein Unternehmen keinen direkten Zugang zum Maschinenbetreiber hat. Dies ist beispielsweise dann der Fall, wenn ein Komponentenlieferant das Geschäftsmodell realisieren möchte. In diesem Fall kann der Service auch einem Maschinenbauer angeboten werden, der ihn wiederum dem Maschinenbetreiber anbietet. Dies hat den Vorteil für den Maschinenbetreiber, dass der Kunde sowohl das Produkt als auch den Service aus einer Hand erhält. Wie bereits angesprochen ist das Nutzenversprechen die Erhöhung der Verfügbarkeit der Maschine, dazu gehört eine effiziente Instandhaltungsplanung. Nicht nur unge-

8  Anwendungsfall BHN/Lenze/Schaeffler

227

plante Maschinenstillstände sollten vermieden werden, auch die geplanten Stillstände sollten minimiert werden. Mithilfe einer Instandhaltungsplanung auf Basis der aktuellen Maschinenzustände kann dieser Bereich optimiert werden. Weiterhin trägt eine schnelle und zielgerichtete Fehlerbehebung an der Maschine zu einer höheren Verfügbarkeit bei. Aus Sicht eines Managers bedeutet eine Erhöhung der Verfügbarkeit eine Erhöhung der Overall Equipment Effectiveness (OEE) des Maschinenparks. Abgeleitet aus dem Nutzenversprechen kann Predictive Maintenance als Marktleistung angeboten werden. Darin enthalten sind die Wartungsplanung sowie die Managementsicht für die Instandhaltung. Im Sinne einer schnellen Fehlerbehebung können Hilfestellungen für den Bediener angeboten werden. Auch ein cloudbasiertes Informationssystem trägt dazu bei, dass Fehler zeitnah lokalisiert und analysiert werden können. Ziel sollte dabei immer sein, einen kontinuierlichen Verbesserungsprozess zu verfolgen. Dies bedeutet insbesondere, dass Erkenntnisse und Zusammenhänge, die in der Vergangenheit festgestellt wurden, auch in der Zukunft genutzt werden. Denn nur so kann auf lange Sicht gewährleistet werden, dass die Verfügbarkeit hochgehalten wird. Das Kundenmodell setzt sich zusammen aus den Kundenkanälen, den Kundenbeziehungen sowie dem Erlöskonzept. In Bezug auf die Kundenkanäle ist die Strategie, die bereits vorhandenen Vertriebskanäle zu nutzen. Diese Entscheidung wurde vor allem deshalb getroffen, weil bereits bestehende Kunden angesprochen werden sollen. Der Zielpunkt des Vertriebskanals kann zum einen der Betreiber, zum anderen der Maschinenbauer sein. Die Kundenbeziehungen sollen dabei vor allem durch langfristige Partnerschaften gekennzeichnet sein. Eine vertrauensvolle Verbindung ist wichtig, vor allem im Hinblick auf den Austausch und die Nutzung sensibler Daten. In Bezug auf das Erlöskonzept ist ein zeitorientierter Preis angestrebt. Dies liegt daran, dass letztlich eine Verfügbarkeit angeboten wird. Wie hoch dieser Preis ist, wird individuell mit dem Kunden verhandelt. Dabei sollte sich an der aktuellen Maschinenausrüstung und der gewünschten Verfügbarkeit orientiert werden. Den Rahmen bildet ein Lizenzvertrag. Die Schlüsselaktivitäten, die Schlüsselressourcen, die Schlüsselpartner sowie die gewählte Organisationsform bilden das Wertschöpfungsmodell. Eine Schlüsselaktivität ist zunächst die Erstellung sowie die anschließende Pflege der digitalen Zwillinge der Maschinen. Diese bilden eine wichtige Basis, um Verfügbarkeitsgarantien anbieten zu können. Zudem muss eine Infrastruktur bereitgestellt werden, die Analysen in (nahezu) Echtzeit ermöglicht. Systematiken in Bezug auf Wartungsservices müssen entwickelt und fortlaufend verbessert werden. Gleiches gilt auch für die Analyse von Störungen sowie deren Behebungen. Bevor entsprechende Services angeboten werden können, muss ein Grundgerüst dafür vorhanden sein. Dieses Grundgerüst muss anschließend dynamisch weiterentwickelt und verbessert werden. Ähnliche Aktivitäten gelten auch für das Servicenetzwerk, das aufgebaut und gepflegt werden muss. Entsprechend ist als Schlüsselressource ein Servicenetzwerk notwendig. Soll das Geschäftsmodell weltweite Anwendung finden, muss ein engmaschiges Netz mit Servicepartnern vorhanden sein. Zudem ist umfangreiches Wissen über die Instandhaltung von Maschinen notwendig, um Maschinenausfälle möglichst gezielt und schnell beheben zu können. Außerdem ist ein cloudbasier-

228

D. Olivotti et al.

tes Informationssystem unerlässlich. Daten können dort gespeichert und analysiert werden, Wissen kann verwaltet werden und lässt sich mit neu gewonnenen Informationen verknüpfen. Sofern eine solche Plattform nicht selbst bereitgestellt wird, ist ein Plattformanbieter ein wichtiger Schlüsselpartner. Er agiert mit dem Maschinenbauer sowie dem Komponentenlieferanten in einem Netzwerk. Da das Geschäftsmodell eine Erweiterung des bestehenden Angebots von Produkten und Services ist, wird das Geschäftsmodell in die vorhandene Organisationsstruktur eingegliedert. Das Finanzmodell gliedert sich in die Bereiche Investitionsausgaben, Festkosten sowie variable Kosten. Die Investitionsausgaben für das Geschäftsmodell beziehen sich auf die Bereitstellungskosten für den ersten Marktauftritt. Die Höhe kann dabei abhängig von den bereits bestehenden Kundenbeziehungen stark variieren. Basis für die bereitgestellten Services bildet ein Verfügbarkeitsvertrag. Feste Kosten ergeben sich für die Infrastruktur, zudem müssen Instandhalter bezahlt und regelmäßige Wartungen durchgeführt werden. Variabel sind hingegen die Kosten, die durch Störungsbeseitigungen entstehen. Diese ­ändern sich je nach Häufigkeit und Ausmaß der Störungen. Zudem muss die geforderte Verfügbarkeit berücksichtigt werden. Für den Maschinenbauer hat das Geschäftsmodell den Vorteil, dass ein digitales Serviceangebot möglich wird, das er ohne Partner möglicherweise nicht realisieren könnte. Dazu zählt auch das Angebot eines Service-Komplettpakets über den gesamten Produktlebenszyklus. Interessant ist dies insbesondere für mittelständische Maschinenbauer ohne eigene Abteilung für Datenanalyse. Der Maschinenbediener hat zum einen durch die ­angebotenen Services eine vollumfängliche Wartungsplanung. Dazu kommt eine Visualisierung mit rollenbasierten Sichten, die den Mitarbeitern bei der Fehlerbehebung und -vermeidung unterstützt. Über die gelenkten und unterstützten Prozesse entsteht somit Wissen, das die Handlungsempfehlungen im Störungsfall kontinuierlich verbessert. Ein strukturiertes Wissensmanagement trägt außerdem dazu bei. Letztlich führen alle Vorteile dazu, dass die Verfügbarkeit über den kompletten Lebenszyklus erhöht wird. Auch für die Partner innerhalb des Geschäftsmodells ergeben sich Vorteile und Anreize. Der Plattformanbieter kann sein Spektrum erweitern und neue Geschäftsmodelle auf partnerschaftlicher Basis unterstützen und prägen. Auch die ganzheitliche Vernetzung ist für den Plattformanbieter vorteilhaft. Der Komponentenlieferant erhält durch das Geschäftsmodell möglicherweise erstmals die Möglichkeit, mit dem Endkunden in Kontakt zu treten. Zudem erhält der Komponentenhersteller Informationen zum Maschinenbetreiber, die er beispielsweise für Produktverbesserungen nutzen kann. Zu diesen Informationen zählen unter anderem die Anwendungen, für welche die Komponenten genutzt werden, sowie die aktuellen Bedürfnisse. Neben Produkten können dadurch auch umfangreiche Services angeboten werden, durch die neue Vertriebsmöglichkeiten entstehen. Zudem treten auch beim Komponentenlieferanten die Vorteile der besseren Vernetzung und der neuen Kontaktmöglichkeiten auf. Hinsichtlich der Risiken lässt sich sagen, dass das Risiko der Nichtrealisierbarkeit besteht. Da für eine zuverlässige und umfangreiche Analyse eine Vielzahl von Daten notwendig ist, muss auch auf externe Systeme und Unternehmen zurückgegriffen werden.

8  Anwendungsfall BHN/Lenze/Schaeffler

229

Dabei besteht die Möglichkeit, dass OEM und Betreiber kein Interesse an einer Zusammenarbeit mit weiteren Parteien haben. Wie bei den Kundensegmenten angesprochen, bildet der Maschinenbauer einen vielversprechenden Verkaufskanal. Dabei besteht jedoch das Risiko, dass der Maschinenbauer bereits einen ähnlichen Service anbietet und kein Interesse an der Zusammenarbeit mit einem Komponentenhersteller hat. Letztlich muss dabei jedoch geprüft werden, ob der Maschinenbauer dennoch einen Mehrwert durch die Daten des Komponentenherstellers hat. Abb. 8.33 fasst das Geschäftsmodell zusammen.

Abb. 8.33  Business Model Canvas des Use-Case BHN/Lenze/Schaeffler

230

D. Olivotti et al.

Literatur 1. Olivotti D, Dreyer S, Kölsch P, Herder CF, Breitner MH, Aurich JC (2018) Realizing availability-­ oriented business models in the capital goods industry. Procedia CIRP 73:297–303

9

Generische Ergebnisse der Geschäftsmodellentwicklung Viviane Zimmermann, Jan C. Aurich, Christoph F. Herder, Lars Holländer und Patrick Kölsch

Zusammenfassung

In diesem Kapitel werden die generischen Ergebnisse der Geschäftsmodellentwicklung präsentiert. Die Ergebnisse resultierten aus der Durchführung des Konzepts zur Entwicklung verfügbarkeitsorientierter Geschäftsmodelle aus Kap. 3 anhand der drei Use-Cases. Der generische verfügbarkeitsorientierte Business Model Canvas beinhaltet bereits jene Elemente, die zwingend beschrieben sein müssen, damit das zu entwickelnde Geschäftsmodell die Verfügbarkeit adressiert. Die Geschäftsmodellausprägungen zeigen, dass es nicht nur ein verfügbarkeitsorientiertes Geschäftsmodell gibt, sondern je nach Kundenwunsch verschiedene Umsetzungsmöglichkeiten realisierbar sind. Das generische verfügbarkeitsorientierte Wertschöpfungsnetzwerk beinhaltet bereits jene Partner, die vorhanden sein müssen, um ein verfügbarkeitsorientiertes Geschäftsmodell zu realisieren.

Die Entwicklung der verfügbarkeitsorientierten Geschäftsmodelle am Beispiel der drei Use-Case-Steller zeigt auf, dass alle Unternehmen den gleichen Aufgaben gegenüberstehen. Aufgaben wie das Erlöskonzept, die Sicherung der Kundenbindung oder die Auslagerung interner Aufgaben an externe Partner sind in allen Geschäftsmodellen nahezu ­gleichermaßen vorgekommen. Wenn sich die Aufgaben ähneln, liegt die Vermutung nahe, dass sich die Lösungsideen ähneln und sich Lösungsmuster ergeben [1]. V. Zimmermann (*) · L. Holländer Unity AG, Stuttgart, Deutschland E-Mail: [email protected]; [email protected] J. C. Aurich · C. F. Herder · P. Kölsch Lehrstuhl für Fertigungstechnik und Betriebsorganisation, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected]; [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 J. C. Aurich et al. (Hrsg.), Entwicklung datenbasierter Produkt-Service Systeme, https://doi.org/10.1007/978-3-662-59643-2_9

231

232

V. Zimmermann et al.

9.1  G  enerisches verfügbarkeitsorientiertes Geschäftsmodell und -ausprägungen Im Allgemeinen wurde der Business Model Canvas 2010 von Osterwalder und Pigneur [2] entwickelt und 2014 von Köster [3] sowie 2016 von Echterhoff erweitert [4]. Der Business Model Canvas wird beschrieben als „eine gemeinsame Sprache zur Beschreibung, Visualisierung, Bewertung und Veränderung von Geschäftsmodellen“ [2]. Um ein Geschäftsmodell mittels des Business Model Canvas zu entwickeln, müssen verschiedene Bausteine ausgearbeitet werden (siehe Kap. 2) [2]. Bereits 1962 präsentierte Rolls Royce sein Geschäftsmodell, indem es anstelle eines Festpreises für Turbinen einen vollständigen Turbinen- und Ersatzteilservice anbot. Das Erlöskonzept basierte dabei auf einem festen Preis für die Nutzung pro Flugstunde. Neben dem physischen Produkt enthielt das Geschäftsmodell auch einen wesentlichen Anteil an Serviceprodukten, die neben dem Austausch auch die Instandhaltung der Triebwerke beinhalteten [6]. Im Rahmen des Forschungsverbundprojektes InnoServPro sind weitere Geschäftsmodelle in anderen Industriezweigen entstanden: Beispielsweise strebt der Landmaschinenhersteller GRIMME mit seiner Lösung an, dass Kunden für die Verfügbarkeit und somit den Nutzen des Siebbandes bezahlen (siehe Abschn. 6.1). Installation, Betrieb und Instandhaltung werden dabei von GRIMME übernommen. Bei der Entwicklung von Use-Case-individuellen Geschäftsmodellen ist zu erkennen, dass sich die Herausforderungen und Aufgaben für die Unternehmen ähneln, die garantierte Verfügbarkeit am Markt anbieten wollen. Es ergeben sich drei wesentliche Erkenntnisse: 1. Das Angebot von Verfügbarkeit am Markt lässt sich generisch durch folgende Kriterien beschreiben Marktleistung: Ein Anbieter von Produkt-Service Systemen (PSS) verkauft die Verfügbarkeit eines Investitionsgutes. Vergütung: Vergütet wird je nach Vertragsabschluss die prozentuale Verfügbarkeit des Investitionsgutes. Verantwortung der Einsatzfähigkeit des Produkts: Die Verantwortung liegt bei verfügbarkeitsorientierten Geschäftsmodellen generell bei dem PSS-Anbieter. Verantwortung für das Ergebnis: Der Kunde ist verantwortlich, die angebotene Verfügbarkeit zur Ergebniserzielung zu nutzen und am Ende ein Ergebnis zu erzielen. Der PSS-Anbieter ist somit für das Angebot der Verfügbarkeit verantwortlich. 2. Das verfügbarkeitsorientierte Geschäftsmodell weist generische Bausteine auf, die branchenübergreifend für jedes Unternehmen gleichermaßen anwendbar sind Zuerst werden anwendungsfallspezifische Bausteine des Business Model Canvas identifiziert. Diese sind Kundensegmente, Kundenkanäle, Kundenbeziehungen, Organisationsform, Kostenstruktur, Erlöskonzept und Risiken. Diese Bausteine müssen für jedes Unternehmen und jeden Use-Case spezifisch ausgearbeitet werden. Gemeinsamkeiten können in den Bausteinen Nutzenversprechen und Marktleistung gefunden werden. Jedes verfügbar-

9  Generische Ergebnisse der Geschäftsmodellentwicklung

233

keitsorientierte Geschäftsmodell ist durch das Angebot der garantierten Verfügbarkeit charakterisiert, bei welchem der PSS-Anbieter die Verantwortung für die Verfügbarkeit eines Investitionsgutes übernimmt. Wie bereits in den vorherigen Kapiteln beschrieben, wird die Grundlage für verfügbarkeitsorientierte Geschäftsmodelle von intelligenten, kommunikationsfähigen Sensoren (und deren Signalverarbeitung), geeigneter Datenanalyse und einem durchgängigen Informationsmanagement gebildet. Diese Schlüsselaktivitäten und Schlüsselressourcen können im Wertschöpfungsmodell des Business Model Canvas gefunden werden. Falls die beschriebenen Kompetenzen innerhalb des Unternehmens nicht verfügbar sind, müssen Partnerschaften etabliert werden. Dies ist im Baustein Schlüsselpartner beschrieben. Da die Verantwortung für die Verfügbarkeit bei dem PSS-Anbieter liegt, muss dieser über die Möglichkeit und Kompetenz verfügen, Serviceprodukte auch tatsächlich erbringen zu können. Dies wird als weitere Schlüsselaktivität definiert. Diese Serviceprodukte müssen von den PSS-Anbietern entwickelt und erbracht werden [5]. Weiterhin müssen die Servicepartner der PSS-Anbieter geschult werden, um die notwendigen Serviceprodukte anzubieten, welche die Verfügbarkeit garantieren. Des Weiteren finden sich Gemeinsamkeiten in dem Baustein Vorteile für den Anwender. Zum einen reduziert sich der Aufwand des Kunden (z. B. in den Instandhaltungsabteilungen, da der PSS-Anbieter für die Verfügbarkeit verantwortlich ist), zum anderen wird die Verfügbarkeit des Investitionsgutes im Feld erhöht. Auch im Baustein Anreize für den Partner lässt sich eine Gemeinsamkeit identifizieren. Das Nutzenversprechen „garantierte Verfügbarkeit“ kann in aller Regel nicht nur durch einen alleinigen Partner erbracht werden, sondern nur durch das Zusammenspiel von unterschiedlichen Partnern und Kompetenzen innerhalb eines Wertschöpfungsnetzwerkes. Im Aufbau von langfristigen Partnerschaften liegt hier der Anreiz. Der allgemeine verfügbarkeitsorientierte Business Model Canvas, wie in Abb. 9.1 dargestellt, beschreibt die Gemeinsamkeiten, welche in den spezifischen Geschäftsmodellen der drei Use-Case-Steller identifiziert wurden. In einer unternehmensspezifischen Ausarbeitung von verfügbarkeitsorientierten Geschäftsmodellen können die beschriebenen Bausteine mit unternehmensspezifischen Erweiterungen vervollständigt werden. 3. Das Angebot von Verfügbarkeit am Markt ist kein alleinstehendes Geschäftsmodell Es zeigt sich in der Use-Case-spezifischen Entwicklung der Geschäftsmodelle, dass sich Herausforderungen und Aufgaben ähneln, denen die Unternehmen gegenüberstanden. Dies lässt den Schluss zu, dass die Verfügbarkeit als Markleistung generisch angeboten wird, die Ausprägung des unternehmensindividuellen Geschäftsmodells jedoch variieren kann. Damit ist die Annahme bestätigt, dass das Angebot von Verfügbarkeit am Markt kein einzelnes Geschäftsmodell ist, sondern mehr aus der Kombination einzelner Bestandteile des verfügbarkeitsorientierten Geschäftsmodells besteht. Mit dieser Erkenntnis konnten fünf eindeutige Geschäftsmodellausprägungen identifiziert werden, die sich nach Prozessstabilität und Serviceumfang bis auf den Full Availability Provider den drei Kategorien „Reactive Maintenance“, „Predictive Maintenance“ und „Prescriptive Maintenance“ zuordnen lassen (siehe Abb. 9.2).

234

V. Zimmermann et al.

Abb. 9.1  Verfügbarkeitsorientierter Business Model Canvas

Im Rahmen des Projektes InnoServPro lassen sich die Use-Case-Steller GRIMME, John Deere und BHN/Lenze/Schaeffler in drei der fünf Ausprägungen zuordnen. Geschäftsmodellausprägung 1: „Customer Integrator“ Bei dieser Geschäftsmodellausprägung wird der Kunde selbst in die Lage versetzt, die Verfügbarkeit innerhalb einer festgelegten akzeptierten Ausfallzeit wiederherzustellen. Der PSS-Anbieter bietet hierfür als Marktleistung den Verkauf von Know-how über die Maschine beispielsweise mittels gezielter Handlungsanweisungen an. Fällt das Investi-

9  Generische Ergebnisse der Geschäftsmodellentwicklung

235

Abb. 9.2  Verfügbarkeitsorientierte Geschäftsmodellausprägungen

tionsgut aus, bietet der PSS-Anbieter dem Kunden beispielsweise Instandsetzungsanleitungen, sodass dieser die Maschine schnellstmöglich reparieren und somit die Verfügbarkeit wiederherstellen kann. Ein beispielhaftes Geschäftsmodell hat im Rahmen des Projektes John Deere entwickelt. Dieses versetzt Kunden in die Lage, auftretende Schäden teilweise selbst beheben zu können. Der Endkunde erhält Reparatur- und Wartungsanweisungen auf ein mobiles Endgerät, z. B. ein Tablet oder eine AR-Datenbrille. Auf diese Weise kann der Endkunde oder Servicetechniker ein digitales Abbild der zu reparierenden Komponente einsehen und diese gemäß visualisierter Anleitung reparieren. Reicht dies nicht aus, bietet John Deere mit einem Support die Möglichkeit der erweiterten Kommunikation. Der Kunde oder der Servicetechniker, der eine komplizierte Reparatur oder Wartungsarbeit durchführt, kann zusätzlich mit einem Servicespezialisten bei John Deere Kontakt aufnehmen, der über die AR-Datenbrille mit dem Nutzer verbunden ist und in Echtzeit Handlungsempfehlungen zur Instandsetzung geben kann. Geschäftsmodellausprägung 2: „Remote Availability Provider“ Bei dieser Geschäftsmodellausprägung wird der Verkauf von garantierter Verfügbarkeit unter inkludierter (akzeptierter) Ausfallzeiten der Maschine verstanden. Der PSS-Anbieter bietet als Marktleistung die festgelegte Verfügbarkeit der Maschine an. Tritt ein Fehler an der Maschine auf, ist der PSS-Anbieter bzw. Instandhalter in der Lage, die Verfügbarkeit z. B. über den Remote-Zugriff wiederherzustellen oder einen entsprechenden Serviceprozess zu initiieren und zu koordinieren. GEA als einer der größten Systemanbieter für die nahrungsmittelverarbeitende Industrie gewährleistet seinen Endkunden von Produktionslinien einen ausfallsicheren Betrieb durch seine digitale Softwarelösung OptiPartner. Für jeden Endkunden werden kundenspezifische Lösungen erarbeitet, indem über die Ser-

236

V. Zimmermann et al.

viceleistung die Produktionslinien mithilfe von datengesteuerten und maschinellen Lerntechnologien überwacht werden. Dies führt zu Prozessoptimierung, zu Energieeinsparungen und schlussendlich zu erhöhter Prozessstabilität 24/7. Geschäftsmodellausprägung 3: „Predictive Availability Provider“ Bei dieser Geschäftsmodellausprägung wird u. a. der Verkauf der Garantie über die volle Funktionsfähigkeit und Verfügbarkeit einer Maschine verstanden. Der PSS-Anbieter bietet z. B. als Marktleistung die garantierte Verfügbarkeit der Maschine an. Dies beschreibt im Vergleich zur Geschäftsmodellausprägung 2 eine (noch) höhere garantierte Verfügbarkeit des Investitionsguts. Die einzige Ausnahme, bei der eine gewisse Stillstandzeit akzeptiert wird, ist ein nachweislich völlig unvorhersehbares Ereignis. Der PSS-Anbieter befindet sich in der Lage, einen notwendigen Wartungs-/Instandhaltungsprozess vorausschauend auf Basis von analysierten Maschinen- und Nutzungsdaten zu initiieren und mit Nutzungszeiten der Maschine abzustimmen, um somit nahezu die vollständige Verfügbarkeit zu garantieren. Geschäftsmodellmuster, wie Predictive Maintenance, sind dieser Geschäftsmodellausprägung zuzuordnen: Beispielsweise wurde im Rahmen des Projektes durch den Landmaschinenhersteller GRIMME ein Geschäftsmodell erarbeitet, das die zukünftige Garantie der Verfügbarkeit ermöglicht. Dabei wird der Zustand der Bauteile durch den Einsatz von Sensoren und einer intelligenten Prozesssteuerung kontinuierlich überwacht und ist somit in Echtzeit abrufbar. Geschäftsmodellausprägung 4: „Autonomous Availability Provider“ Ebenso wie bei dem Muster Predictive Maintenance wird bei dieser Geschäftsmodellausprägung die volle Funktionsfähigkeit und Verfügbarkeit einer Maschine seitens des PSS-Anbieters als Marktleistung angeboten und Stillstandzeiten sind nur bei nachweislich völlig unvorhersehbaren Ereignissen, z. B. Sturmschäden akzeptiert. Die Unterscheidung dieser beiden Ausprägungen orientiert sich an dem Gartner Reifegradmodell für Analytics, in dem zwischen Predictive und Prescriptive Maintenance unterschieden wird [7]. Prescriptive Maintenance beschreibt dabei die finale Phase der Business Analytics, welche in der Intelligenz des Produkt-Service Systems verankert ist. Hierbei setzt die Geschäftsmodellausprägung nicht nur auf die Vorhersage von zukünftigen Schadensereignissen, ­basierend auf Data Mining, maschinellem Lernen oder anderen statistischen Methoden. Vielmehr stützen sich die Geschäftsmodelle rund um den „Autonomous Availability Provider“ auf Handlungsempfehlungen, wie man ein unvorhergesehenes Ereignis verhindert oder auf ein zukünftiges Ereignis reagieren kann. Dies kann sich beispielsweise in der auf Nutzungszeiten abgestimmten Auslösung der notwendigen Wartungs- und Instandhaltungsprozesse äußern. Geschäftsmodellausprägung 5: Full Availability Provider Bei dieser Geschäftsmodellausprägung handelt es sich um die Weiterentwicklung des „Predictive Maintenance“ hin zu einem Angebot einer 100 %-igen Verfügbarkeit des In-

9  Generische Ergebnisse der Geschäftsmodellentwicklung

237

vestitionsguts am Markt. Dabei übernimmt der PSS-Anbieter die 100 %-Verantwortung für die Bereitstellung, die Inbetriebnahme und die Verfügbarkeit einer Maschine. Anbieter von z. B. Kaffeemaschinen, Geldautomaten oder Convenient-Food-Maschinen setzen dieses Geschäftsmodell bereits ein. Der entscheidende Unterschied dabei ist, dass solche Geschäftsmodelle für komplexe Investitionsgüter, wie Landmaschinen oder intralogistische Anlagen, bisher nur vereinzelt existieren. Zudem unterscheiden sich die Use-Cases dahingehend, dass die Verfügbarkeit der Sachprodukte in InnoServPro durch die Auswertung und Nutzung verschiedener Daten garantiert wird. Bei dieser Geschäftsmodellausprägung übernimmt der PSS-Anbieter die Bereitstellung, Inbetriebnahme und Sicherung der Laufleistung bis hin zu einer 100 %-igen Verfügbarkeit des Investitionsguts im Markt. Hierfür kombiniert der PSS-Anbieter Bausteine zur Instandsetzung (z. B. über digitale Vor-Ort-­ Verfügbarkeit von Reparaturanleitungen oder Remote Services) mit den Bausteinen der vorausschauenden Instandhaltung zu einem allumfassenden PSS. Ein beispielhaftes Geschäftsmodell ist im Rahmen des Projektes durch die Use-­Case-­ Steller BHN/Lenze/Schaeffler entwickelt worden. In diesem Zusammenhang wurde mittels intelligenter Komponenten und einem durchgängigen Informationsmanagement die Möglichkeit entwickelt, Maschinengrößen zu überwachen und dem Maschinenbediener per Remote oder AR-Technologien eine Schritt-für-Schritt-Anleitung für die Wartung und Instandhaltung anzubieten.

9.2  Generisches Wertschöpfungsnetzwerk für verfügbarkeitsorientierte Geschäftsmodelle Im vorherigen Kapitel wurde bereits gezeigt, dass verschiedene Schlüsselressourcen notwendig sind, um die garantierte Verfügbarkeit anzubieten. Geschäftsmodelle rund um Verfügbarkeit sind durch neu aufkommende Wettbewerber am Markt und der zunehmenden Digitalisierung nicht mehr für jedes Unternehmen alleine zu realisieren. Bei fehlenden Ressourcen innerhalb des Unternehmens sind deshalb Kooperationen und Partnerschaften ein maßgeblicher Erfolgsfaktor. Die Beziehungen der notwendigen Partner sind nicht mehr entlang der bekannten Wertschöpfungskette abzubilden. Wachsende Abhängigkeiten und gegenseitige Verflechtungen bedingen die Betrachtung des Ökosystems, in dem sich das Unternehmen befindet bzw. befinden sollte, um verfügbarkeitsorientierte Geschäftsmodelle und Services am Markt anbieten und realisieren zu können. Diese Beziehungen untereinander lassen sich in einem Wertschöpfungsnetzwerk darstellen. Partner und Ressourcen sind dabei in unterschiedlichen Beziehungen (Geld-, Informations- Leistungsflüsse) miteinander verbunden. Im Rahmen des Projektes bilden intelligente, kommunikationsfähige Komponenten eine Ausgangsbasis zur Realisierung von verfügbarkeitsorientierten Geschäftsmodellen. Die mit Sensoren ausgestatteten Komponenten werden dazu verwendet, Informationen über Betriebs- und Maschinendaten sowie Wissen und Kenntnisse über das Kundenverhalten zu sammeln und zu analysieren. Diese Daten werden dabei dem PSS-Anbieter zur

238

V. Zimmermann et al.

Verfügung gestellt. Ein Partner im Wertschöpfungsnetzwerk ist somit der Anbieter von intelligenten, kommunikationsfähigen Komponenten (inklusive Signalverarbeitung). Zur Auswertung der Sensordaten müssen geeignete Analysemethoden ausgewählt werden. Komplexe Maschinenzustände werden dabei nicht nur von einem Sensorwert beschrieben, sondern ergeben sich aus Mustern von verschiedenen Kennzahlen und Sensorwerten. Für diese Art von Analysen eignen sich Datenanalysemethoden. Einen zweiten Schlüsselpartner bilden demnach Big-Data-Analysten. Das Management aller servicerelevanten Informationen ist notwendig, um verfügbarkeitsorientierte Geschäftsmodelle zu realisieren. Das Informationsmanagement basiert im Projekt auf einer flexiblen, cloudbasierten Kommunikationsplattform, welche eine durchgängige Kooperation mit verschiedenen Partnern ermöglicht. Dort werden relevante Informationen gespeichert und ausgetauscht. Dafür werden eine Cloudplattform und ein Anbieter für Informationsmanagement benötigt. Während der Nutzungsphase übertragen die Investitionsgüter Daten des Maschinenzustands und des Kundenverhaltens zu der cloudbasierten Kommunikationsplattform. Dort werden die Daten gespeichert und analysiert. Finden sich spezifische Muster, wird die relevante Information z. B. über einen drohenden Ausfall oder weitere Probleme, die

Abb. 9.3  Generisches Wertschöpfungsnetzwerk für verfügbarkeitsorientierte Geschäftsmodelle

9  Generische Ergebnisse der Geschäftsmodellentwicklung

239

zu einem Ausfall der Maschine führen können, zu dem PSS-Anbieter sowie den Kunden, Servicepartnern und anderen relevanten Partnern in dem spezifischen Wertschöpfungsnetzwerk übertragen. Bei verfügbarkeitsorientierten Geschäftsmodellen sind die PSS-­ Anbieter für die Verfügbarkeit der Maschine verantwortlich. Mithilfe der Informationen und analysierten Daten können Services initiiert werden, um die Verfügbarkeit auf dem größtmöglichen Niveau zu halten. Das generische Wertschöpfungsnetzwerk ist in Abb. 9.3 dargestellt. Das entwickelte Wertschöpfungsnetzwerk basiert auf den anwendungsfallspezifischen Wertschöpfungsnetzwerken und repräsentiert die Gemeinsamkeiten. Unternehmensspezifische Elemente und Anpassungen können in einer spezifischen Ausarbeitung ergänzt ­werden.

Literatur 1. Gausemeier J, Dumitrescu R, Echterfeld J, Pfänder T, Steffen D, Thielemann F (Hrsg) (2018) Geschäftsplanng – Den unternehmerischen Erfolg vorausdenken. In: Innovationen für die Märkte von morgen. Strategische Planung von Produkten, Dienstleistungen und Geschäftsmodellen. Hanser, München, S 295–378 2. Osterwalder A, Pigeneur Y (2010) Business model generation – a handbook for visionaries, game changers, and challengers. Wiley, Hoboken/New Jersey 3. Köster O (2014) Systematik zur Entwicklung von Geschäftsmodellen in der Produktentstehung. Dissertation, Universität Paderborn 4. Echterhoff B, Gausemeier J, Koldewey C, Mittag T, Schneider M, Heiko S (2016) Geschäftsmodelle für die Industrie 4.0. In: Jung HH, Kraft P (Hrsg) Digital vernetzt. Transformation der Wertschöpfung. Hanser, München, S 35–55 5. Waltemode S (2014) Qualitätsbewertung technischer Produkt-Service Systeme. Dissertation, Technische Universität Kaiserslautern 6. Rolly Royce Company (2012) Rolls-Royce celebrates 50th anniversary of Power-by-the-Hour. Internetartikel. https://www.rolls-royce.com/media/press-releases-archive/yr-2012/121030-thehour.aspx. Zugegriffen am 24.02.2019 7. Eiduzzis D (2018) Auf der Suche nach dem Use Case. Predictive Analytics in der Praxis. Internetartikel. https://www.computerwoche.de/a/auf-der-suche-nach-dem-use-case,3544628. Zugegriffen am 20.03.2019

Zusammenfassung und Fazit

10

Patrick Kölsch und Jan C. Aurich

Zusammenfassung

Innerhalb dieses Kapitels werden die Ergebnisse vom ersten bis zum neunten Kapitel in Kurzform zusammengefasst und dabei die drei Use-Cases nochmals kurz vorgestellt. Das Kapitel endet mit einem Fazit.

Das Buch „Entwicklung datenbasierter Produkt-Service Systeme – Ein Ansatz zur Realisierung verfügbarkeitsorientierter Geschäftsmodelle“ bietet den Lesern unterschiedlicher Fachrichtungen Zugang zum Forschungsthema Geschäftsmodellentwicklung für Produkt-­ Service Systeme und deren technische Realisierung. Darin inbegriffen sind weitere aktuelle Forschungsthemen, die in den jeweiligen Kapiteln hervorgehoben werden. Das erste Kapitel (siehe Kap. 1) führt in die Thematik der Geschäftsmodellentwicklung für Produkt-Service Systeme ein. Die Kundenbedürfnisse in Bereichen wie z. B. der Automobilindustrie haben sich geändert. Der Kunde strebt oft nicht mehr den Erwerb des Produkts an, sondern bevorzugt lediglich dessen Nutzung und möchte auch nur für diese zahlen. Diese Änderung der Kundenanforderungen macht sich auch im Investitionsgüterbereich auf Business-to-Business-Ebene bemerkbar. Trotz vielfältiger Potenziale finden sich derartige Lösungen aufgrund zahlreicher Herausforderungen nur vereinzelt. Verfügbarkeitsorientierte Geschäftsmodelle stellen eine solche Lösung dar. Dabei zahlt der Kunde für eine vertraglich vereinbarte Verfügbarkeit einzelner Komponenten oder eines Produkts. Damit Investitionsgüterhersteller die Verfügbarkeit garantieren und dem K ­ unden diese Garantie P. Kölsch (*) · J. C. Aurich Lehrstuhl für Fertigungstechnik und Betriebsorganisation, Technische Universität Kaiserslautern, Kaiserslautern, Deutschland E-Mail: [email protected]; [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 J. C. Aurich et al. (Hrsg.), Entwicklung datenbasierter Produkt-Service Systeme, https://doi.org/10.1007/978-3-662-59643-2_10

241

242

P. Kölsch und J. C. Aurich

anbieten können, fehlen allerdings bislang geeignete Ansätze zur Entwicklung verfügbarkeitsorientierter Geschäftsmodelle. Zudem fehlen Nutzungsdaten der Maschinen, passende Algorithmen zur Datenanalyse sowie ein geeignetes Informationsmanagement. Das vom Bundesministerium für Bildung und Forschung geförderter Verbundforschungsprojekt „Innovative Serviceprodukte für individualisierte, verfügbarkeitsorientierte Geschäftsmodelle für Investitionsgüter“ adressiert die zuvor genannten Herausforderungen in drei Teilzielen. Die Ergebnisse werden anhand dreier Anwendungsfälle demonstriert, die in der Landmaschinenbranche und in der Intralogistik angesiedelt sind. Im zweiten Kapitel (siehe Kap. 2) werden die theoretischen Grundlagen hinsichtlich Produkt-Service Systeme gelegt. Dabei werden die einzelnen Elemente Sachprodukt, Serviceprodukt, Netzwerke von Akteuren und unterstützende Infrastruktur detailliert erklärt. Durch die fortschreitenden Entwicklungen im Bereich der Sensortechnologie, der Cloudtechnologie, der Datenanalysemethoden, etc., werden datenbasierte Produkt-Service Systeme ermöglicht. Dies bedeutet, dass smarte Produkte, die z. B. über das Internet mitei­ nander kommunizieren können, durch eine sensorische Ausstattung eine große Menge an Daten generieren. Mit der zielgerichteten Auswertung dieser Daten können datenbasierte Serviceprodukte, sogenannte smarte Serviceprodukte realisiert werden. Weiterhin werden in diesem Kapitel die Grundlagen hinsichtlich der Entwicklung von Geschäftsmodellen gelegt. Dabei wird zwischen den möglichen Formen von Geschäftsmodellen zum Anbieten von Produkt-Service Systemen unterschieden und mögliche Techniken zur Beschreibung von Geschäftsmodellen vorgestellt. Herausgestellt werden in diesem Kapitel die verfügbarkeitsorientierten Geschäftsmodelle durch eine ausführliche Definition der Verfügbarkeit, wie sie im Projekt InnoServPro verfolgt wurde. Dabei muss bei einer Verfügbarkeitsbetrachtung sowohl der Zeitraum berücksichtigt werden, bevor ein Ausfall eintritt, als auch jener, wenn durch einen zufälligen Fehler ein Ausfall bereits eingetreten ist und schnellstmöglich behoben werden muss. Das dritte Kapitel (siehe Kap. 3) widmet sich der Konzeption verfügbarkeitsorientierter Geschäftsmodelle. Auf Basis identifizierter Forschungslücken werden sechs Anforderungen an das neu zu entwickelnde Konzept gestellt. Das Konzept besteht aus insgesamt sieben Phasen: 1. Markt und Trends 2. Ideenfindung Geschäftsmodell 3. Beschreibung des Anwendungsfalls 4. Bedürfnisanalyse und Lösungsideen 5. Detaillierung des Geschäftsmodells 6. Planung der Partner, Ressourcen und Interaktionen 7. Planung der Umsetzung Das Konzept wurde innerhalb mehrerer Workshops mit den Projektpartnern in interdisziplinären Workshop-Gruppen erarbeitet. Die einzelnen Phasen wurden dabei mit ­Werkzeugen, u.  a. aus dem Design Thinking, hinterlegt. Dies gewährleistet eine starke

10  Zusammenfassung und Fazit

243

Kundenorientierung während der Entwicklung der Geschäftsmodelle. Das Konzept berücksichtigt sowohl eine technologiegetriebene als auch eine marktgetriebene Induktion der Geschäftsmodellentwicklung und ermöglicht es, in den frühen Phasen bereits Anforderungen für die technische Realisierung zu definieren. Das vierte Kapitel (siehe Kap. 4) beschäftigt sich mit der Entwicklung intelligenter, kommunikationsfähiger Komponenten, die als eine der Grundlage zur Realisierung der verfügbarkeitsorientierten Geschäftsmodellen dienen. Zu Beginn werden unterschiedliche Methoden zur Identifikation servicerelevanter Komponenten präsentiert. Eine Überwachung aller Komponenten und Systeme einer Maschine wäre bei Investitionsgütern, wie z. B. Landmaschinen, sehr kostenintensiv. Aus diesem Grund sind ausfallkritische Komponenten zu definieren und zu überwachen. Dazu müssen zuerst die Ausfallmechanismen der Komponenten untersucht und anschließend dazu passende Überwachungskonzepte entwickelt werden. Eine Möglichkeit dafür bietet die sensorische Überwachung die in diesem Kapitel erklärt wird. Die auf diesem Wege gesammelten Daten über den Zustand der Maschine bzw. der Komponente müssen zielgerichtet ausgewertet werden. Sind zu wenige Daten für eine solche Auswertung vorhanden, können Daten durch die physikalische Modellierung eines Prototyps virtuell erzeugt werden. Zudem werden in diesem Kapitel die Signalverarbeitung, die Datenvoranalyse, die Schnittstellendefinition und die Datenvermittlung in die Cloud inklusive des Nachrichtenprotokolls MQTT präsentiert. Im fünften Kapitel (siehe Kap.  5) werden die erarbeiteten Inhalte des intelligenten Informationsmanagements für verfügbarkeitsorientierte Geschäftsmodelle vorgestellt. Zu Beginn werden die Business-/High-Level-Anforderungen aus dem zweiten Kapitel in technische Anforderungen überführt. Für die weitere Entwicklung des Produkt-Service Systems wird eine modellbasierte Gesamtmodellierungssystematik entwickelt. Zum besseren Verständnis der Anwendung wird die Modellierung im Anschluss anhand eines Beispiels durchgeführt. Neben der Modellierung der Elemente eines Produkt-Service Systems wird in diesem Kapitel der Aufbau und die Konfiguration der Kommunikationsplattform charakterisiert, die als zentraler Bestandteil die Elemente Business Analytics, Back-End und Front-End miteinander verbindet. Zur Sicherstellung der Verfügbarkeit müssen die durch die Sensorkonzepte aufgenommenen servicerelevanten Daten ausgewertet werden. Die Daten umfassen dabei echtzeitnahe Felddaten aus der Nutzung des Investitionsguts, Servicedaten und Stammdaten. Zur Datenauswertung werden verschiedene Werkzeuge in diesem Kapitel näher beleuchtet. Die Daten werden der Business Analytics aus dem Back-End zur Verfügung gestellt und die ausgewerteten Daten wieder an das Back-End übertragen. Ein geeignetes Datenmodell ist dabei unerlässlich. Zudem wird in diesem Kapitel die Thematik des digitalen Zwillings genau beschrieben. Zur Anzeige der servicerelevanten Daten werden verschiedene Front-Ends entwickelt, welche zum einen als Teil der Maschine ortsfest sind, zum anderen auf verschiedenen Endgeräten zum Einsatz kommen. Die Integration der Systeme Business Analytics, Back-­End und Front-End in die Kommunikationsplattform sowie der gesamtheitliche Test und die Verifikation schließen das Kapitel.

244

P. Kölsch und J. C. Aurich

In den folgenden Kap. 6, 7 und 8 werden die entwickelten Konzepte und Systeme anhand dreier Use-Cases umgesetzt. Der Use-Case der GRIMME Landmaschinenfabrik GmbH & Co. KG betrachtet den Zeitraum der Verfügbarkeit bevor ein Komponentenausfall eintritt. Der Use-Case fokussiert die Garantie der Verfügbarkeit für das Siebband eines Kartoffelvollernters (Varitron 470). Dafür wird ein individualisiertes, verfügbarkeitsorientiertes Geschäftsmodell durch das in Kap.  3 entwickelte Konzept erarbeitet. Darauf aufbauend werden zwei unterschiedliche Sensorkonzepte zur Erfassung des Komponentenzustandes entwickelt und realisiert. Diese Konzepte basieren auf der Untersuchung der Ausfallmechanismen des Bandes. Die physikalische Modellierung des Siebbandes ermöglicht die frühzeitige Erstellung eines virtuellen Prototyps. Anschließend werden die Signalverarbeitung und Datenvoranalyse sowie die Schnittstellendefinition und Datenvermittlung in die Cloud näher betrachtet. Daraufhin werden ausgewählte Elemente des Informationsmanagements präsentiert, wobei anhand einer spezifischen Datenauswertung eine Beurteilung der Bandlänge durchgeführt und somit eine Verfügbarkeit garantiert werden kann. Zudem wird das entwickelte Maschinen-Front-End präsentiert, welches den Maschinenbediener über jedwede Zustandsänderung informiert und über welches er eine Bandbestellung tätigen kann. Der Use-Case der John Deere GmbH & Co. KG adressiert den Zeitraum der Verfügbarkeit in dem ein Ausfall bereits eingetreten ist und schnellstmöglich wieder behoben werden muss. Ebenso wie der Use-Case GRIMME wurde das Konzept gemäß des Technology-push-Ansatzes durchlaufen. Der Kunde bzw. der Servicetechniker wird im Reparaturprozess je nach Bedarf durch Schritt-für-Schritt-Anleitungen unterstützt. Dazu ist Kenntnis über die aktuelle Produktkonfiguration der Maschine unerlässlich. Um dies zu realisieren ist bei der datentechnischen Integration eine hohe Variantenvielfalt zu beachten. Je nach Kundenwunsch weisen die Investitionsgüter unterschiedliche Konfigurationen auf. Für die visuellen Handlungsanweisungen müssen CAD-Daten inklusive der korrekten Verortung von Komponenten am Produkt durch CAD-Positionsdaten zwingend miteinbezogen werden. Auch für diesen Use-Case wurde ein individualisiertes, verfügbarkeitsorientiertes Geschäftsmodell mit Hilfe des Konzepts aus Kap. 3 entwickelt. Anschließend wird die technische Realisierung anhand der Entwicklung des Back-Ends und der Visualisierung auf einem maschinenunabhängige Front-End präsentiert. Der Use-Case BHN/Lenze/Schaeffler wurde gemäß dem Market-pull-Ansatz durchlaufen. Somit startete die Entwicklung des individualisierten, verfügbarkeitsorientierten Geschäftsmodells mit einer Markt- und Trendrecherche. Zudem wurden Kundenworkshops durchgeführt und der Kundenmehrwert im gesamten Prozess herausgearbeitet. Der Use-­Case nimmt eine integrierte Betrachtung der beiden Teile der Verfügbarkeit vor. Dabei werden einzelne Komponenten sensorisch, unter anderem mit Hilfe von Modellen, überwacht. Zudem werden auch Schritt-für-Schritt-Anzeigen zur Fehlerbehebung implementiert. Zu Beginn wird wiederum ein individualisiertes, verfügbarkeitsorientiertes Geschäftsmodell gemäß Kap. 3 entwickelt. Dabei wurde das Konzept zur Entwicklung ver-

10  Zusammenfassung und Fazit

245

fügbarkeitsorientierter Geschäftsmodelle mit Hilfe des Market-pull-Ansatzes d­ urchlaufen. Anschließend wird die technische Realisierung des verfügbarkeitsorientierten Geschäftsmodells durch • sensorische und modellbasierte Überwachungskonzepte, • mehrere Business-Analytics-Konzepte, • die Umsetzung des technischen Datenmodells und der konfigurationsspezifischen Serviceanleitungen und -dokumentationen im Back-End sowie • die Entwicklung des Maschinen-Front-Ends und des maschinenunabhängigen Front-­ Ends anhand einer Maschine aus dem intralogistischen Bereich demonstriert. Durch die Entwicklung der individualisierten, verfügbarkeitsorientierten Geschäftsmodelle innerhalb der drei Use-Cases konnten Gemeinsamkeiten hinsichtlich einzelner Ergebnisse der eingesetzten Werkzeuge festgestellt werden. Diese werden im neunten Kapitel (siehe Kap. 9) präsentiert und anhand weiterer Beispiele analysiert. Zum einen wurden einzelne Felder des eingesetzten Business Model Canvas bei allen drei Use-Cases gleich beschrieben, sodass ein verfügbarkeitsorientierter Business Model Canvas resultierte. Dieser gibt an, auf welche Weise welche Felder auszufüllen sind, um ein verfügbarkeitsorientiertes Geschäftsmodell zu entwickeln. Wenn Unternehmen somit verfügbarkeits­ orientierte Geschäftsmodelle entwickeln möchten, können sie sich an den Feldern des Business Model Canvas orientieren. Zum anderen wurden fünf verschiedene Geschäftsmodellausprägungen identifiziert, welche die Verfügbarkeit auf verschiedene Arten adressieren. Je nach Serviceaufwand können unterschiedliche Wege zur Realisierung von Verfügbarkeitsgarantien eingeschlagen werden. Am Ende des Kapitels wird das generische Wertschöpfungsnetzwerk vorgestellt. Anhand der Use-Cases wurden Partner identifiziert, die zwingend im Netzwerk vorhanden sein müssen, um verfügbarkeitsorientierte Geschäftsmodelle zu realisieren. Ähnlich des verfügbarkeitsorientierten Business Model Canvas unterstützt das generische Wertschöpfungsnetzwerk Unternehmen bei der Entwicklung verfügbarkeitsorientierter Geschäftsmodelle und definiert notwendige Partner zur Realisierung. Die Inhalte dieses Buches zeigen, wie die in Kap.  1 genannten Herausforderungen überwunden werden können. Dabei sind Netzwerkpartner zur Realisierung dieser verfügbarkeitsorientierten Geschäftsmodelle und den damit verbundenen datenbasierten Produkt-­ Service Systemen unabdingbar. Die Realisierung der individualisierten Geschäftsmodelle anhand der drei Use-Cases lässt erkennen, dass nur durch regelmäßige Abstimmungen solche vielschichtigen Lösungen integriert entwickelt werden können. Gerade vor dem Hintergrund neuer Technologien und neuer Möglichkeiten der Datenauswertung bietet dieses Buch Ansätze, sich auf verschiedene Weise in der Investitionsgüterindustrie von anderen Unternehmen zu differenzieren. Die gezeigten Ergebnisse des BMBF-Verbundforschungsprojekts „Innovative Serviceprodukte für individualisierte,

246

P. Kölsch und J. C. Aurich

verfügbarkeitsorientierte Geschäftsmodelle für Investitionsgüter  – InnoServPro“ bieten vielfältige Möglichkeiten zur Weiterentwicklung in unterschiedlichen Themenbereichen. Zudem kann die Realisierung verfügbarkeitsorientierter Geschäftsmodelle als Grundlage zur Etablierung ergebnisorientierter Geschäftsmodelle innerhalb der Investitionsgüterindustrie gesehen werden.

Anhang

© Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 J. C. Aurich et al. (Hrsg.), Entwicklung datenbasierter Produkt-Service Systeme, https://doi.org/10.1007/978-3-662-59643-2

247

248

Anhang

Anhang

249

250

Anhang

Anhang

251

252

Anhang

Stichwortverzeichnis

A Abrissphase 123 Alterungsmodell 197 Anomalieerkennung 206 Anomalieindikator 207 Ausfallmechanismus 34, 119 Ausfallzeit 12 mittlere 13 Auswerteschema 161 Autokorrelationsfunktion 150, 162 B Back-End 77 Bandbestellung 167 Bandlängung 161 Bewertungsmatrix 23 Big Data 238 virtuelles 39 Business Analytics 62, 160 Business Model Canvas 10, 115, 232 C CODESYS WebVisu 84 Customer Journey 25, 113 D Data Stream Management Systeme 65 Datenaufzeichnung 208

Datendurchgängigkeit 172 Datenmodell fachliches 73, 214 Modellierung 76 Datenvisualisierung 66 Dehnungsverlauf 120 Descriptive Analytics 66 Design Thinking 20 Drehzahlsensor 140 Druckmessumformer 140 E Einlaufphase 123 F Fast-Fourier-Transformation 162 Feder-Dämpfer-System 145, 148 Dämpfungskonstante 145 Federsteifigkeit 145 Fehlerursachendiagnose 196 Fehlervermeidung 196 Finite-impulse-response-Filter 154 Frequenzspektrum 154 Front-End maschinenabhängiges 221 maschinenunabhängiges 87, 219 Use-Case BHN/Lenze/Schaeffler 217

© Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2019 J. C. Aurich et al. (Hrsg.), Entwicklung datenbasierter Produkt-Service Systeme, https://doi.org/10.1007/978-3-662-59643-2

253

254 G Gauß-Filter 150 Generative Topographic Mapping 207 Gesamtmodellierungssystematik Beispiel 53 Definition 50 Geschäftsmodell allgemeines 9 Entwicklung 18 verfügbarkeitsorientiertes 9, 233 Visualisierung 27 Geschäftsmodellausprägung Autonomous Availability Provider 236 Customer Integrator 234 Full Availability Provider 236 Predictive Availability Provider 236 Remote Availability Provider 235 Geschäftsmodellinnovation 18 Gewichtsfunktion 152 GRIMME Landmaschinenfabrik GmbH & Co. KG 111 H Hall-Element 134 I Informationsmanagement, intelligentes 159 Integration 95 Implementierung 98 Lösungsansätze 99 Notwendigkeit 95 Internet of Things 69 ISOBUS 83 IT-Infrastruktur 60 K Knowledge Discovery in Databases 66 Kommunikationsplattform Anforderungen 46 Bestandteile 59 Komponenten kommunikationsfähige 237 intelligente 192 servicerelevante 33 Künstliche Neuronale Netze (KNN) 207

Stichwortverzeichnis M Machine Learning 65, 205 Machine-to-Machine 60 Magnetfeldverlauf 127 Magnetoresistiven (MR-) Effekt anisotroper MagnetoResistiver Effekt (AMR) 124 Giant MagnetoResistiver Effekt (GMR) 125 Tunnel MagnetoResistiver Effekt (TMR) 124 Market-pull 18 Maschinen-Front-End 82, 162 Master, digitaler 80 Masterplan of Action 28, 117 Modellbildung, physikalische 138 Modell, thermisches 197 MQTT-Übertragungsprotokoll 60, 161 Definition 64 O OPC Unified Architecture 64 Overall Equipment Effectiveness 227 P Periodendauer 152 Persona 25, 113 Phase, lineare 123 Predictive Analytics 67 Prescriptive Analytics 68 Principal Component Analysis 206 Product Lifecycle Management 78 Produkt-Service-System datenbasiertes 9 Definition 6 Entwicklung 49 Prototyp, virtueller 38 Prozessanalyse 28, 116 Prüfstand 136 R Restlebensdauermodell 200 S Sachprodukt 7 Schnittstelle 157 Self-Organizing Maps 207 Sensor 41

Stichwortverzeichnis Sensorchip 129 Sensorkonzept berührendes 133 berührungsloses 124 Sensorsystem 131 Serviceprodukt 7 Serviceprozess 170 Simulationsmodell 150 Suchfeldanalyse 22 Systems Modeling Language (SysML) 50 System, sozio-technisches 7 T Technology-push 18 Temperatursensor 130 Test-Case 90 Trendradar 22 U Überwachungskonzept, verfügbarkeitsorientiertes 35 Use-Case 24

255 V Variantenstückliste 179 Varitron 470 112, 163 Aufnahmeband 119 Verdrehwinkel 133 Verfügbarkeit 12 Visualisierungscockpit 191 Von-Hann-Fenster 162 W Wartungshinweise 166 WebVisu 163 Welligkeitsprofil 150, 153 Wertschöpfungsnetzwerk 237 erweitertes 8, 114 Z Zahnscheiben 133 Zustand, fehlerbehafteter 12 Zustandsampel 164 Zwilling, digitaler 76, 181 Definition 80