Smarte Produkte erfordern ein Umdenken bei ... · Ein gutes Beispiel hierfür ist das Automobil,...

Ein White Paper herausgegeben von: Siemens PLM Software

Smarte Produkte erfordern ein Umdenken bei Produktstrukturen und ProzessenDigitalisierung, Integration,

Interdisziplinarität und Föderation

AbstractDas Internet der Dinge und darauf basierende Forschungsinitiativen des BMBF (Industrie 4.0, Digitalisierung/internetbasierte Dienstleistungen) gehen in der Zukunft von vernetzten Produkten, Systemen und Dienstleistungen aus. Der wertmäßige Anteil an Elektronik und Software wird bei dieser Art von Produkten und eingebetteten Dienstleistungen kontinuierlich steigen. Kommunizieren Produkte miteinander, wird von Cyber-Physical Systems bzw. Cybertronischen Systemen gesprochen. Die Entwicklung dieser neuen Systeme wird mehrere Konsequenzen nach sich ziehen: interdisziplinäre und integrierte Produktentwicklung, ein Überdenken heutiger Konstruktionsmethoden, Prozesse, IT-Lösungen und Organisationsformen sowie die Forderung nach durchgängigen Prozessketten basierend auf digitalen Modellen in der Produktentwicklung, Produktionsplanung, Produktion und Service.

Autoren:

Prof. Dr. Martin Eigner, Lehrstuhl für Virtuelle Produktentwicklung, TU Kaiserslautern Urban August, Siemens Industry Software GmbH Matthias Schmich, Siemens Industry Software GmbH

siemens.com/plm

Inhalt

1. Abstract.................................................................................3 2. Ausgangssituation – Industrie 4.0 und Digitalisierung.........3 3. Produktstrukturen im Wandel der Zeit.................................6 4. Klassische hierarchische Stücklisten....................................8 4.1 Generische Produktstruktur....................................................8 4.2 Varianten-, Plattform und Modulstrategie...............................9 4.3 Verschiedene Stücklistensichten.............................................9 4.4 Instanziierung......................................................................10 5. Die Digitalisierung des Produkt- und Prozessmodells...........11 6. Wie ändern sich Produktstrukturen zukünftig?.....................12 6.1 Interdisziplinarität, Integration und Föderation.......................12 6.1.1 Software............................................................................13 6.1.2 Elektrotechnik/Elektronik....................................................13 6.1.3 Produktbezogene Dienstleistung.........................................13 6.2 Kollaboration........................................................................14 6.3 Product Line Engineering (PLE)..............................................14 6.4 Produktstrukturen in der frühen Phase des Produktlebenszyklus.............................................................15 6.5 Integration der späten Phase des Produktlebenszyklus............16 6.5.1 Closed Loop Manufacturing, Integrated Mechatronics Engineering..................................16 6.5.2 Zusammenspiel von SysLM, ERP und MES............................17 6.6 Service Lifecycle Management..............................................17 6.7 Visualisierung.......................................................................18 7. Zukünftige Prozess- und IT-Architektur.................................18 8. Zusammenfassung................................................................21 9. Literaturverzeichnis..............................................................22

2

White Paper | Smarte Produkte erfordern ein Umdenken bei Produktstrukturen und Prozessen

1. AbstractDas Internet der Dinge und darauf basierende Forschungs-initiativen des BMBF (Industrie 4.0, Digitalisierung/internet-basierte Dienstleistungen) gehen in der Zukunft von vernetzten Produkten, Systemen und Dienstleistungen aus. Der wertmäßige Anteil an Elektronik und Software wird bei dieser Art von Produkten und eingebetteten Dienstleistungen kontinuierlich steigen. Kommunizieren Produkte miteinander, wird von Cyber-Physical Systems bzw. Cybertronischen Systemen gesprochen. Die Entwick-lung dieser neuen Systeme wird mehrere Konsequenzen nach sich ziehen: interdisziplinäre und integrierte Produkt-entwicklung, ein Überdenken heutiger Konstruktions-methoden, Prozesse, IT-Lösungen und Organisationsfor-men sowie die Forderung nach durchgängigen Prozessketten basierend auf digitalen Modellen in der Produktentwicklung, Produktionsplanung, Produktion und Service. Weiterhin müssen Planungs- und Entwurfs-methoden aller Disziplinen – Mechanik, Elektronik und Software – auf den Prüfstand gestellt und ihre Tauglichkeit für ein neues Vorgehensmodell der Produkt- und Produk-tionsentwicklung überprüft werden, um diese in einen gemeinsamen, integrierten und interdisziplinären Methoden-, Prozess- und IT-Lösungsansatz zu überführen. Im Zentrum dieser Veränderungen in der Produkt- und Prozesswelt stehen die Produktstrukturen – sozusagen als Skelett eines durchgängigen digitalisierten Produktlebenszyklus (PLZ) –, die über den gesamten PLZ, über alle Disziplinen, über verteilte Standorte sowie über die gesamte Zulieferkette die Basis für ein digitales Produkt-, Produktions- und Prozessmodell darstellen. Die Digitalisierung bedeutet einen Transformationsprozess, der die klassischen Grenzen einer fragmentierten und konkurrierenden IT-Lösungswelt neu ordnet. Als durchgängiger Backbone wird eine Digital Enterprise Software Suite die Rolle der Daten- und Pro-zessintegration zwischen der Produkt- und Produktions-entwicklung, der Produktion/Fertigung und Montage sowie dem Service einnehmen.

2. Ausgangssituation – Industrie 4.0 und DigitalisierungDie letzten zehn Jahre sind durch einen stetigen Wandel der Wertschöpfungsanteile bei Industrie- und Konsumgü-tern gekennzeichnet. Software und Automatisierungstech-nik ersetzen zunehmend bisher mechanisch realisierte Funktionen in den heutigen Produkten. Nach einer aktuel-len Studie des VDMA sind zahlreiche Innovationen ohne verstärkten Einsatz von Technologien der Informations- und Automatisierungstechnik undenkbar. Rund ein Drittel der Herstellungskosten für ein Produkt entfällt heute auf IT und Automatisierungstechnik. Gegenüber der letzten Erhebung (2008) wuchs damit der Anteil von Software, IT-Hardware und Elektrotechnik um 11 Prozent. Nach Einschätzung der befragten Unternehmen werden IT- und Automatisierungstechnik vor allem in Bezug auf die Wettbewerbsfähigkeit weiter an Bedeutung gewinnen. Ein gutes Beispiel hierfür ist das Automobil, dessen Innova-tionen und Funktionserweiterungen mehr und mehr aus den Bereichen Elektronik und IT kommen. Kommunizieren Produkte miteinander, wird von Cyber-Physical Systems beziehungsweise Cybertronischen Systemen gesprochen.

Ein anderer Begriff ist das Internet der Dinge (Internet of Things, IoT). Darauf aufbauend werden häufig Dienstleis-tungen entwickelt (Internet of Services, IoS). Die gesamte horizontale und vertikale Integration der Wertschöpfungs-kette wird sich dadurch verändern. Wertschöpfungsketten zeichnen sich heute noch durch klar definierte Grenzen zwischen unternehmensinternen und externen Bereichen aus. In Zukunft aber erfordern kürzere Produktlebens-zyklen, kleinere Losgrößen und eine variantenreiche Produktion ein effizientes und schnelles Zusammenar-beiten aller Unternehmensbereiche und Zulieferketten. Dies gelingt nur durch eine durchgehende Digitalisierung der horizontalen und vertikalen Vernetzung. In der Folge werden sich neue Geschäftsfelder insbesondere in den Bereichen IT, Logistik und Produktion sowie im Service entwickeln [35].

Neben der weltweiten Vernetzung von Entwicklung, Produktion und Service wird vor allem der originäre Funk-tionsumfang und damit die Komplexität der entstehenden Produkte und Systeme rapide ansteigen. Mit dem Inter-netprotokoll IPv6 stehen künftig 430 Sextillionen Internet-adressen zur Verfügung (430 mit 36 Nullen). Bis zum Jahr 2020 werden rund 37 Milliarden „Dinge“ und Dienste mit dem Internet verbunden sein (Digitales Leben, Connecti-vity). Schon heute sind technische Produkte zunehmend multidisziplinäre Systeme, die im Zusammenspiel mehrerer Ingenieursdisziplinen entwickelt werden. Digitalisierung, Integration und Interdisziplinarität zwischen Mechanik, Elektrik/Elektronik, Software und Dienstleistung sowie die übergreifende Zusammenarbeit zwischen den einzelnen Phasen des Produktlebenszyklus (PLZ) werden zur Grund-lage moderner Produktentwicklungs-, Planungs- und Produktionsprozesse. Die zunehmende Integration von Informations- und Kommunikationstechnologien in die Produkte sowie die Verknüpfung mit Dienstleistungen bewirkt einen Paradigmenwechsel. Man spricht von Smart Engineering [2] und meint damit neue Methoden, Prozesse und IT-Toolketten für den Produktentstehungsprozess (PEP). Dasselbe gilt für den integrierten Produktionspla-nungs- und Produktionsprozess. Hier ist von Smarter Produktion und Digitaler Fabrik die Rede. Dies bezieht sich auf die Entwicklung, Produktion und Vermarktung innova-tiver, sowie ganzheitlich vernetzter Produkte, Produktions-systeme und Dienstleistungen, z. B. auf der Basis neuer internetbasierter Technologien [24]. Der PLZ unterliegt aber nicht nur durch Industrie 4.0 und der damit verbundenen Digitalisierung gravierenden Änderungen. Abbildung 1 stellt die Megatrends für den Wertschöpfungsprozess im Zusammenhang dar. Eine besondere Herausforderung liegt in der vielfachen Vernetzung und Abhängigkeit der einzelnen Trends untereinander. Diese Trends sinnvoll aufzunehmen, umzusetzen und die Gewährleistung der gesellschaftlichen Akzeptanz sind die Herausforderungen der nächsten Jahre.

1

Cybertronische Systeme sind mehrere mechatronische Systeme, Produkte und/oder Komponenten, die miteinander kommunizieren, z.B. beim autonomen Parken, das Fahrzeug, das Smartphone und das Parkhaus. 2

Im weiteren wird nur noch von Produkten gesprochen, da die Verfasser der Meinung sind, dass Produktionssysteme auch Produkte sind.

3

Industrie 4.0 wurde von der deutschen Industrie gestartet und wird von der Bundesregierung unterstützt. Der Begriff steht synonym für die vierte industrielle Revolution und ist über einen Zeithorizont von mehr als zehn Jahren angelegt.

Während der Schwerpunkt von Industrie 4.0 häufig in der Optimierung der Produktion gesehen wird, setzt diese Studie einen allgemeineren Ansatz – ähnlich dem Industrial Internet Consortium in den USA – voraus. Das bedeutet, dass (vgl. Abbildung 2)

• die gesamte horizontale Wertschöpfungskette im Unternehmen beeinflusst wird.

• die vertikale Integration zu den Produktionssystemen große Bedeutung erhält – Integration des digitalen Produktentstehungsprozess zum digitalen Produktionsprozess.

• die Engineering-Prozesse durchgängig unterstützt werden und die digitalen Produktmodelle (digitales Modell und digitaler Zwilling) in allen Unternehmensbereichen integriert genutzt werden.

Die Vernetzung und Integration zwischen Bereichen oder Abteilungen innerhalb eines Unternehmens aber auch zwischen verschiedenen Unternehmen ist ein zentrales Element von Industrie 4.0. Ziel der digitalen Vernetzung ist eine Verbesserung der Zusammenarbeit, Koordination und Transparenz über die Unternehmensbereiche hinweg sowie entlang der Liefer- und Wertschöpfungskette. Der Funk-tionsbereich Vernetzung und Integration (horizontale Integration) umfasst daher die bereichsübergreifende Zusammenarbeit innerhalb des Unternehmens und un-ternehmensübergreifende Zusammenarbeit in Wertschöp-fungsnetzwerken. Die vertikale Integration umfasst die Inte-gration verschiedener IT-Systeme auf den unterschiedlichen Hierarchieebenen innerhalb eines Unternehmens (beispiels-weise die Aktor- und Sensorebene, Steuerungsebene, Produktionsleitebene, Manufacturing and Execution-Ebene, Unternehmensplanungsebene).

Abbildung 1: Industrie 4.0 – Das digitale Unternehmen. Quelle: [34]

3

http://www.iiconsortium.org/

Abbildung 2: Industrie 4.0 – Ein deutsches Zukunftsprojekt mit einem Zeithorizont von 10 Jahren. Quelle: [35]

4


Um diese Vision umzusetzen, müssen Methoden, Prozesse und IT-Werkzeuge zur durchgängigen Digitalisierung des Produktlebenszyklus weiterentwickelt werden. Aufbauend auf der modellbasierten Entwicklung wird derzeit an Vorge-hen zur disziplinübergreifenden und integrierten Entwick-lung von cybertronischen Produkten und Systemen ge-forscht, welche sowohl Produkte als auch Produktions- und Servicesysteme beinhalten [3, 4, 6, 17]. Software und Elektronik werden in Zukunft eine Vielzahl von neuen Funktionen ermöglichen und die Funktionskomplexität der Produkte weiter erhöhen. Andererseits dürften sich die Entwicklungs- und Fertigungskomplexität durch eine Verschiebung der Varianz von Hardware zu Software teilweise reduzieren. Um die System- und Prozessqualität für produzierende Unternehmen zu verbessern, können beispielsweise serviceorientierte, skalierbare (Cloud-) Plattformkonzepte zur prädiktiven Qualitäts-datenanalyse dazu beitragen, intelligente, anwendungsspe-zifische Feedbackloops im Qualitätsmanagement etwa für Produkt- und Produktionsdaten zu schaffen. Aus einer zentralen Produktionssteuerung wird ein dezentraler, sich selbst organisierender Prozess [10,16]. Die Folge sind auto-nome, smarte Maschinen und kommunizierende Produkte sowie darauf aufbauende Dienstleistungen. Sie erlauben Full-Service-Konzepte (Abbildung 3), die allerdings heute in voller Breite nur unzureichend umgesetzt werden können, weil sie hohe Unsicherheit und ein hohes Risiko in sich bergen. Der Grund dafür: Es fehlt an Informationen und an einer transparenten Auswertung über das Gesamtsystem während des operativen Betriebes beim Betreiber oder Endkunden (z.B. Verschleiß von Bauteilen). Durch die Nutzung und den Aufbau von geschlossenen Regelkreisen mit intelligenter Auswertung von Felddaten, können diese Unsicherheiten beseitigt und das Ausfallrisiko des Systems besser abgeschätzt werden. Darüber hinaus entstehen neue Möglichkeiten für die Individualisierung von Serviceprodukten bei Investitionsgütern. Ebenso werden kunden- bzw. ma-schinenspezifische Full-Service Konzepte zur Absicherung höchster Verfügbarkeit, zur verbesserten Einsatzplanung, zur genaueren Ermittlung des Ersatzteilpotenzials sowie zum automatisierten Anstoß von Serviceprozessen möglich [17].

Entscheidend für die Ausgestaltung von Industrie 4.0 mit dem Internet der Dinge und Dienste sind Technologien mit Sensoren und Aktuatoren sowie eingebetteter Intelligenz. Nur so ist es für Produkte möglich, die Umgebung wahr-zunehmen und mit ihr zu interagieren. Auch drahtlose Kommunikation wie der Breitband-Mobilfunk oder RFID (Radio-Frequency Identification) sind von Bedeutung. Folglich wird die semantische Beschreibung von Diensten und Fähigkeiten wichtig, die eine intelligente Interaktion

von Produktkomponenten und Maschinen gewährleistet.

Mit „Smart Produce“ bzw. „Plug and Produce“ wird es mög-lich, dass Maschinen ihr Umfeld automatisch erkennen und sich mit anderen Maschinen vernetzen bzw. interagieren können. Dadurch entsteht ein Austausch von Informationen z.B. über Aufträge, Auslastung und optimale Fertigungspa-rameter. Als zentrales Element gilt es dabei, spezifische (auch cloudbasierte) Backbone-Konzepte aufzubauen, die die Informationskomplexität eines Produktsystems (Stich-wort: Big Data) über den gesamten Lebenszyklus hinweg auf administrativer Ebene beherrschbar machen. Abbildung 4 zeigt ein typisches Beispiel, wie sowohl Konsumgüter als auch Investitionsgüter – basierend auf einer aktiven Sensor-/Aktuator-Einbindung und einer intelligenten Datenaufbereitung (Business Analytics) – die Grundlage von serviceorientierten Geschäftsmodellen bilden.

Smarte Produkte und Systeme werden eine neue Ära von Produktinnovationen und veränderte Geschäftsmodelle mit hoher sozialgesellschaftlicher, ökonomischer und ökolo-gischer Bedeutung zur Folge haben. Sie basieren auf der zunehmenden Intelligenz moderner kommunikations-fähiger Komponenten, z.B. günstige, internetfähige Sen-soren bzw. Aktuatoren und erweiterter Konnektivität durch das Internet. Schlüsseltechnologien dieser Ebene sind die Sensor-/Aktuator-Technologie mit eingebetteter Intelligenz, intelligente Hardware, Kommunikationstechnologie und eingebettete Systeme. Darauf baut eine internetfähige System- und Serviceplattform auf, die neben der Daten-aggregation, der Datenfusion und der intelligenten Datenauswertung, zusätzlich eine optimierte Steuerung bzw. Regelung sowie eine grafische Visualisierung ermöglicht. Grundlage dieser Ebene bilden Softwaretechnologien (Business Analytics, Cloud Computing, Big Data, Security, Safety, kontextsensitive Systeme, etc.) und systemtheo-retische bzw. mathematische Modellierung, Analyse- und Simulationsverfahren. Die darüber liegende Ebene entwickelt neue dienstleistungsorientierte Geschäftsmodelle und Betriebsoptimierungen (Internet of Services) sowie die Vernetzung der beteiligten Partner und Komponenten/Systeme (Business Intelligence). Die genannten Ebenen bauen auf neuen, gemeinsamen und interdisziplinären Engineering Methoden, Prozessen und IT-Werkzeugen auf. Die Ebenen werden nach oben zunehmend anwendungsori-entiert und zielen mit ihren Services auf die jeweiligen Anwendungsfelder ab, z.B. Smart Products, Smart Farming, Smart Energy, Smart Factory und Smart Buildings.

Abbildung 3: Full-Service-Konzepte am Beispiel Smart Farming. Quelle: VPE

Abbildung 4: Grundsätzlicher Aufbau von serviceorientierten Geschäftsmodellen

5

Eine derart ganzheitlich vernetzte System- und Dienstleis-tungsentwicklung erfordert das Überdenken heutiger, im Engineering bekannter Entwicklungsmethoden, -prozesse und IT-Werkzeuge [11,12]. Entwurfs- und Planungsmethoden aller Disziplinen, also Mechanik- und Elektrokonstruktion und Elektronik-, Software- und Dienstleistungsentwicklung sowie die sich daran anschließende Prozessplanung für Fertigung und Montage müssen auf den Prüfstand gestellt werden. Ihre Tauglichkeit bezüglich der Digitalisierung muss überprüft werden, und letztlich muss dies alles in einen gemeinsamen integrierten und interdisziplinären Methoden- und Prozessansatz überführt werden. Diese Entwurfs- und Planungsmethoden müssen schließlich auf einer modernen IT-Infrastruktur abgebildet werden.

All diese Änderungen, stellen einen radikalen Umdenkungs-prozess dar, der mit dem Begriff Digitale Transformation bezeichnet wird. Diese Transformation ist für die künftige Wettbewerbsfähigkeit von Unternehmen unbedingte Voraussetzung [5, 6, 13, 14]. Die Einflüsse resultieren zum einem aus veränderten Marktbedingungen und Konsummustern und zum anderen aus neuen Anforderungen an smarte Produkte und Systeme [15]. Dies sind beispielsweise:

• Digitalisierung des Produkt- und Prozessmodells

• Modulare Produktentwicklung und modulare Produkte als Voraussetzung einer Wiederverwendung,

• Varianten und Derivate, die auf Querschnittsmodulen aufbauen

• Systemintegration mechatronischer und cybertronischer Anwendungen auf der Basis von Methoden des Systems Engineering

• Kundenspezifische Systemlösungen

• Steigende Bedeutung von Aftersales- und serviceorientierten Geschäftsmodellen

• Veränderung der Produkt-/Produktionsprozesse durch Innovation

• Agile und flexible IT-Lösungen die sich geänderten Geschäftsmodellen und -prozessen schnell anpassen

Das zentrale administrative Teilsystem eines über den Produktlebenszyklus durchgängigen digitalen Produkt- und Prozessmodells ist ein integriertes PLM (Product Lifecycle Management) System. Dieses System geht weit über den heutigen Leistungsumfang mit Schwerpunkt in der Entwick-lung und Konstruktion (die klassische CAD- und Konstruk-tionsstücklistenintegration) hinaus und ist Bestandteil der digitalen Enterprise Software Suite. Der erweiterte Funk-tionsbereich von PLM resultiert zum einen aus der zuneh-menden Interdisziplinarität, aber auch aus der vollständi-gen Abdeckung des gesamten Produktlebenszyklus sowie der Zulieferkette. Das zentrale „Nervensystem“ von PLM ist eine über den PLZ durchgängige, interdisziplinäre und integrierte digitale Produktstruktur.

3. Produktstrukturen im Wandel der ZeitDieses Kapitel beschreibt die methodischen Voraussetzungen zur Festlegung der Produktstrukturen, die heutige Abgren-zung zwischen den Funktionen von PLM und ERP (Enter-prise Resource Planning), sowie die Auswirkungen beim Einsatz einer digitalen Enterprise Software Suite. Grundsätz-lich werden bezüglich der Beschreibung der Produktstruktur bei ERP- und PLM-Lösungen heute immer noch dieselben Methoden seit Einführung der strukturierten Stücklistenform angewandt. Zum besseren Verständnis der Veränderungen in der Produktstruktur und der technischen Dokumentation über die letzten Jahrzehnte wird nachfolgend ein typisches Beispiel einer Baugruppenzeichnung aus den 70/80er Jahren vorgestellt (siehe Abbildung 5). Typisch für diese Phase ist, dass auf der Zeichnung alle technischen und organisatorisch relevanten Informationen enthalten waren. Daher auch die Aussage: „Die Zeichnung ist die Sprache des Ingenieurs“. Kennzeichen ist einerseits eine weitgehend flache Struktur der Einzelteile und Baugruppen. Die Zuord-nung der Teile zu Baugruppen und Erzeugnissen erfolgt visuell über die parallele Nummerierung in der Stücklisten-zeile und der grafischen Darstellung. Diese Methode hatte den Vorteil, dass die Zuordnung von Teilen weitgehend wertfrei von Interpretationen wie funktions- oder monta-georientiert war.

Waren in den 80er Jahren die Produktbeschreibungen noch auf Dokumente konzentriert, haben sich – auch auf Grund ver-stärkter CAD-Einführung in Mechanik und Elektronik sowie zur Unterstützung des Dispositionsprozesses für aufkommende ERP Systeme – stücklistenorientierte hierarchische Strukturen (BOM = Bill of Material) parallel zur geometrischen Beschreibung durchgesetzt. Dieses Vorgehen wurde insbesondere durch 3D CAD-Systeme unterstützt, die automatisch zur Positionierung der Einzelteile zu Baugruppen eine topologieorientierte Struk-tur erzeugten, welche die Zuordnung mittels grafischer Num-mern auf der Zeichnung ersetzte. In der Übergangszeit wurde trotzdem – auch wegen der guten Übersichtlichkeit vor allem bei zweidimensionalen Anwendungen – die Stückliste in die CAD-Zeichnung eingebettet und mit einer Nummernvergabe die Zuordnung auf der Zeichnung nachgebildet.

Abbildung 5: Beispiel einer Baugruppenzeichnung aus den 70/80er Jahren. Quelle: [30]

6


Hierarchische Strukturen bilden heute immer noch den Kern heutiger Produktstrukturen, müssen aber wegen der zunehmenden Bedeutung von Mechatronik und Cybertronik durch lineare und verzweigte (Software) und netzwerkar-tige Strukturierungsmethoden (MBSE/Elektrik/Elektronik) ergänzt werden (siehe Abbildung 6).

Während die Hardware (Mechanik und Elektrik/Elektronik) auf der Produktstrukturebene weiterhin über hierarchische Strukturen beschrieben wird, gibt es in der Softwareentwick-lung parallele Stränge (Trunks), Aufspaltungen (Branch) und Vereinigungen (Merge). Eine Konfiguration wird bei der Softwareentwicklung durch Verknüpfung der physischen Files, die durch Revision und Version gekennzeichnet sind, realisiert (Baseline). Die Elektronikentwicklung basiert zwar auf netzwerkartigen Strukturen auf CAD-Ebene, diese werden aber auf der PLM-Ebene ebenfalls heute als hierarchische Strukturen abgelegt. Auch in den Änderungszyklen unter-scheiden sich die Disziplinen. Die typische Änderungshäufig-keit zwischen Mechanik, Elektronik und Software verhält sich ungefähr im Verhältnis 1:10:100. Die Beschreibungen von Dienstleistungsmodellen und Prozessplänen in der Produk-tionsplanung haben ebenfalls eine netzwerkartige Struktur. Neben der Erweiterung der Strukturierungsmethoden ergibt sich eine weitere wesentliche Veränderung der Produktstruk-turen durch die Abdeckung des gesamten Produktlebenszyklus. Bei vielen industriellen PLM-Implementierungen wurde die Produktstruktur im Wesentlichen aus der Sicht der Entwick-lung und Konstruktion definiert und dann auf die Montage-sicht des ERP Systems transferiert. Nur wenige Firmen – häufig Einzel- und Kleinserienfertiger im Maschinen- und Anlagen-bau oder Großserienfertiger mit einer starken Dominanz der Montagelinie – haben eine gemeinsame montageorientierte Stücklistensicht etabliert.

Abbildung 7 zeigt die typischen Ausprägungen von Produkt-strukturen während des gesamten Produktlebenszyklus. In der Automobil-, Aerospace- und Hightech-Industrie wird an Integrationsstrategien gearbeitet, die eine Verknüpfung der Anforderungsstruktur über Funktions-, Logik- und Verhaltens-strukturen mit der Konstruktionsstückliste ermöglichen sollen (Upstream Integration). Durch Lösungsansätze der digitalen Fabrik und Manufacturing Execution Systems (MES) kann die Integration auf die Bereiche der Produktions- und Fabrikpla-nung erweitert werden (Downstream Integration). Diese Potentiale werden insbesondere durch die zunehmend durch-gängige digitale Modellbildung, durch erprobte Integrations-standards und moderne IT-Werkzeuge erschlossen. Durch die Zunahme juristischer Forderungen nach Nachverfolgbarkeit im Schadensfalle (ISO9001, ISO 26262, EN50128, DO178B) oder Substance-/Material Compliance werden integrierte Modelle und darauf aufbauende Prozesse notwendig werden.

Die Darstellung zeigt die Vision einer über den PLZ durch-gängigen Produktstruktur. Kein Unternehmen hat heute eine derartige weitreichende Integration der Produktstruk-turen implementiert. In der industriellen Praxis liegt der erste Prozessbruch zwischen den isolierten Anforderungs-strukturen und den CAD-Strukturen sowie den Konstruk-tionsstücklisten (E-BOM). Eine Verbindung wäre möglich über funktionale und/oder logische Produktarchitekturen, eventuell bei Dominanz der Elektronik und Software ergänzt um Verhaltensstrukturen. Diese Verbindung wird aber erst im Stadium der industriellen Forschung vor allem in den Branchen Hightech, Aerospace und Automotive eingesetzt. Der zweite Bruch entsteht zwischen den Entwicklungs- und Fertigungs-/Montagestücklisten (M-/P-BOM). Obwohl es sich um sehr ähnliche Strukturen handelt, die auf weitge-hend gemeinsame Stammdaten zugreifen, liegt hierbei das Problem darin, dass die Strukturen voneinander abweichen und die Systemgrenze von PDM/PLM und ERP zwischen diesen beiden Produktstrukturen verläuft. Auch das wird sich mit der stärkeren Durchdringung der digitalen Modell-bildung in der Produktionsplanung und der Produktion (Digital Factory, MES) ändern. Aufgrund dienstleistungsori-entierter Geschäftsmodelle etabliert sich eine weitere Anwendung: Service Lifecycle Management (SLM). Diese fragmentierte IT-Landschaft führt zu getrennten Zyklen für die typischen Engineering Prozesse (Freigabe-, Änderungs- und Konfigurationsmanagement) und damit zu unbefriedi-genden Lösungen einer betrieblichen Integration.

Abbildung 5: Beispiel einer Baugruppenzeichnung aus den 70/80er Jahren. Quelle: [30]

Abbildung 6: Von der dokumenten- und stücklistenorientierten zur

modellbasierten digitalen Beschreibung nach [27]

Abbildung 7: Ausprägung von Produktstrukturen über den gesamten Produktlebenszyklus

7

4. Klassische hierarchische StücklistenAufgrund der heutigen Dominanz hierarchischer Produkt-strukturen erfolgt eine kurze Erläuterung der Grundver-fahren am Beispiel der klassischen hierarchischen Entwick-lungs- und Konstruktionsstückliste (Engineering BOM oder E-BOM). Sowohl bei PLM- als auch bei ERP-Lösungen spricht man bei Stücklistensystemen von einer Grunddatenverwal-tung. Grunddaten gliedern sich in:

• Stammdaten: Dies sind Daten, die selbständig, ohne Beziehung zu anderen Daten aussagefähig sind, z. B. Artikel (= Produkt, Baugruppe, Teil, Halbzeuge, Vorferti- gungsstufen) -Daten. Typische Stammdaten sind die Sachnummer, Revision/Version, Benennung, Status …)

• Strukturdaten: Dies sind Daten, die Beziehungen zwischen den Ausprägungen von Stammdaten herstellen, z. B. Stücklistenstrukturen

Informationstechnisch sind Stücklisten spezielle Darstel-lungsformen hierarchischer Strukturen (Top Down). Mit der Verwendungsliste (Bottom Up) zusammen ergeben sich komplexe netzwerkartige Produktzusammenhänge. Auf-grund mangelnder grafischer Darstellungswerkzeuge wurde die Produktstruktur in der Vergangenheit in Form von Listen gezeigt. Die Strukturstufen wurden durch Einrücken inner-halb der Liste gekennzeichnet. Die grafische Abbildung einer Produktstruktur setzt sich parallel mit dem Einsatz von grafischen Userinterfaces und dem Einsatz von Browsern durch und verdrängt die Listendarstellung. Der Gozinto-Graph (the part that goes into it) ist die Urform der gra-fischen Darstellung von Produktstrukturen (Abbildung 8).

Die Stückliste kann sich auf die mengenmäßige Zusam-mensetzung von Produkten beziehen (Mengenstückliste). Die Mengenstückliste ist eine unstrukturierte Darstellungs-form, die lediglich die Mengen untergeordneter Elemente auflistet. Dabei werden identische Elemente mit der An-gabe der konkreten Menge zusammengefasst. Die Stückliste kann aber auch den vollständigen Aufbau eines Erzeugnisses in einer Struktursicht wiedergeben (Strukturstückliste). Die Basisstückliste für IT-Anwendungen ist die zweistufige Baukastenstückliste. Sie enthält immer einen Knoten der Produktstruktur mit den Komponenten der hierarchisch niedrigeren Strukturebene. Aus diesem Grundkonstrukt lassen sich alle anderen Stücklistenformen redundanzfrei ableiten.

4.1 Generische Produktstruktur

Eine wichtige Vereinfachung gerade bei komplexen Stück-listen führt Schichtel durch eine Aufteilung der Produkt-struktur ein [31]:

• Produktgliederung (auch generische Produktstruktur genannt)

• physische Einzelteile und Zusammenbauten (konkrete (instanziierte) Stücklisten und Teilestämme mit Sachnummern)

Der Aufbau eines Produkts (P) wird zunächst in logische/generische Gruppen (G1-G6) gegliedert. Diese sogenannte Produktgliederung stellt das Skelett eines Produkts dar. Die tatsächlichen verbauten Einzelteile (E1-E6) oder Zusammen-bauten (Baugruppen) (Z1, Z2) werden unterhalb der Gruppen (logischen Knoten) hinzugefügt und erweitern die Produkt-gliederung zur Produktstruktur (Abbildung 9).

Diese Trennung stellt eine drastische Vereinfachung der Produktstrukturen dar. Sie wird bei quantitativer Komplexität (hohe Anzahl von Komponenten) zum Beispiel im Maschinen-, Anlagen- und Flugzeugbau sowie bei qualitativer Komple-xität (hohe Anzahl von Varianten) im Automobilbereich eingesetzt.

Abbildung 8: Gozinto Graph

Abbildung 9: Trennung der Produktstruktur in logische/generische und

physische Komponenten. Quelle: [31]

8


4.2 Varianten-, Plattform und Modulstrategie (Product Line Engineering)

Die Komplexität und Vielfalt moderner Produkte nimmt permanent zu. Nur wenn es gelingt, diesem Trend durch geeignete Produktentwicklungs- und Produktionsmethoden zu begegnen, können die Gesamtkosten unter Kontrolle gehalten werden. Geeignete Produktstrukturierung und -gestaltung sowie darauf aufbauende Fertigungs-, Montage und Beschaffungsprozesse sind die Voraussetzungen. Auf der Produktseite kann durch systematischen Aufbau einer variablen und modularen Produktstruktur anhand von Baureihen und Baukästen sowie Maßnahmen zur Kompo-nentenwiederverwendung ein wesentlicher Beitrag ge-leistet werden. Variantenbaukästen sind eine in der europäischen Industrie seit langen bekannte Arbeitstechnik. Ihre Bedeutung für die Kostenstruktur eines Unternehmens hat sich unter den genannten Randbedingungen noch verstärkt. Die Verwaltung dieser Varianten ist für die Dispo-sition, Fertigung/Montage und den Service von erheblicher Bedeutung, da die Anzahl möglicher Produktausprägungen sehr hoch sein kann. Abbildung 10 zeigt diverse Produkte, denen allen gemeinsam ist, dass sie in einer Vielzahl von Varianten und Derivaten angeboten werden.

Neben der Variantenbildung, die zu einer Vielzahl abgelei-teter Produktausprägungen führt, dient sowohl die Einfüh-rung von Plattformen als auch insbesondere die Definition von wiederverwendbaren Komponenten (Querbaukästen) zu einer Reduzierung der Komplexität bei gleichzeitiger vom Markt gewünschter Individualisierung bei (Abbildung 11). Diese Art der Systematisierung des Produktportfolios und der Produktprogramme wird auch als Product Line Engineering (PLE) bezeichnet.

Die Optimierung der Produktarchitektur ist von unterschiedli-chen, z.T. gegensätzlichen Zielen getrieben. Während beispielsweise aus Produktionssicht einfach montierbare Module gewünscht werden, steht aus Entwicklungssicht die funktionale Abgeschlossenheit im Vordergrund. Der Einkauf fordert dagegen kostengünstige Komplett-Module, aus Vertriebssicht ist maximale Varianz und Kombinierbarkeit gewünscht.

Eine tragfähige Produktarchitektur kann daher nur im Zusam-menspiel der verschiedenen Disziplinen entwickelt werden. Im Vorfeld oder parallel zur Produktentwicklung können modulare Produktstrukturen in Werkzeugen strukturiert aufgebaut werden (Abbildung 12).

4.3 Verschiedene Stücklistensichten

In den aufeinanderfolgenden Phasen des PLZ‘s wird die Produktstruktur aus verschiedenen Sichten und mit dem Ziel, verschiedene Informationen abzuleiten, interpretiert. Im täglichen Sprachgebrauch wird unterschieden zwischen Konstruktionsstücklisten und einer Vielzahl anderer Stücklisten, die im Folgenden unter dem Begriff Arbeitsstücklisten zusam-mengefasst werden. Dazu gehören z.B. die

• Fertigungsstücklisten

• Montagestücklisten

• Dispositionsstücklisten

• Terminstücklisten

• Kalkulationsstücklisten

• Lagerstücklisten

• Einkaufsstücklisten

• Servicestücklisten

Auf den Einsatz einer durchgängigen Produktstruktur bezogen, ist vor allem die Unterscheidung von Konstruktions- und Fertigungs-/Montagestücklisten interessant. In der Literatur werden folgende Unterschiede genannt:

• Auftragsabhängigkeit: Die Konstruktionsstückliste ist i. d. R. auftragsneutral, während die Fertigungsstückliste einen auftragsabhängigen Charakter besitzt [DIN 6789]. Bei Engi- neering to Order (EtO) und Assembly to Order (AtO) ist eine Trennung von auftragsneutral und auftragsabhängig teile- weise nicht mehr existent oder vermischt sich in der Produk- tion.

• Strukturunterschiede: Bei der Konstruktionsstückliste wird die Produktgliederung häufig aus funktionaler Sicht gesehen, z. B. mechanische, elektrische und pneumatische Komponenten, während die Fertigungsstückliste von den Fertigungs- und Montageoperationen abhängt.

• Informationsmenge: Die beiden Stücklistenarten werden durch die Menge der zu beschreibenden Daten bei gleicher Struktur und Identifikation der Produkte unterschieden.

Abbildung 10: Beispiel variantenreicher Produkte. Quelle: [32]

Abbildung 11: Plattform- und Modulstrategie nach [38]

Abbildung 9: Trennung der Produktstruktur in logische/generische und

physische Komponenten. Quelle: [31]

Abbildung 12: Optimierung der Produktstruktur mittels Metus (IDConsult) [39]

9

• Änderungszustand: Konstruktionsstücklisten entsprechen vor allem bei manueller Eingabe und Pflege i. d. R. nicht dem Änderungszustand der aktiven Fertigungsstückliste. Vermehrt setzt sich aber auch bei dieser Stücklistenform eine vereinfachte Art der Änderungszustandsverwaltung durch.

Auf das Produkt können je nach Produktlebenszyklusphase und Disziplin unterschiedliche Sichten definiert werden (vgl. Abbildung 13).

Die unterschiedlichen Sichten haben einen unterschiedlichen Bedarf hinsichtlich der Strukturierung des Produkts. In Folge dessen haben sich verschiedene verwendungsspezi-fische Stücklistenarten gebildet, die sich in Aufbau und Inhalt voneinander unterscheiden. Durch die Definition von Strukturierungselementen, die in Sicht A und in Sicht B jeweils unterschiedliche Einzelteile als Baugruppen zusam-menfassen, entstehen zwei abweichende Strukturen, die in diesem Falle auf gleiche Teile zugreifen aber verschiedene Strukturknoten generieren. IT-technisch werden E-BOM und M-BOM heute meist nicht als Sichten sondern in verschie-denen Strukturen abgebildet.

4.4 Instanziierung

Werden in komplexen Systemen mehrere Komponenten des gleichen Typs verbaut, differenziert man die identischen Bauteile anhand von Instanzen. Die Instanziierung des digitalen Modells ist aus mehreren Gründen wesentlich. Bei komplexen Produkten und Systemen, zum Beispiel im Anlagen-, Schiff- und Flugzeugbau, müssen mehrfach verbaute Komponenten rückverfolgbar und einzeln identifi-zierbar sein. Die Komponenten eines speziellen Typs, z.B. Pumpe 4711 D (Sachnummer und Änderungsindex), werden in einem Schiff an mehreren Positionen eventuell auch mit verschiedenen anderen Parametern (z.B. Wartungsangaben und Lieferant) verbaut. Die verschiedenen Instanzen werden durch eine Seriennummer indiziert, die neben der Sachnummer und der Revision/Version die Instanz eindeu-tig identifiziert. Wichtige Bauteile unterliegen einer stück-mäßigen Verfolgung. Jedes Teil erhält deshalb neben einer Sachnummer eine Seriennummer, mit deren Hilfe eine lückenlose Dokumentation des einzelnen Teiles möglich wird. Die kontextspezifische Identifizierung aller Pumpen eines Schiffs geschieht durch Zuordnung der jeweiligen Instanzen (Sachnummer, Revision/Version, Seriennummer) zur Seriennummer des Schiffs (Abbildung 14).

Die Instanziierung durch Seriennummern ist in den meisten Fällen ausreichend, allerdings nur dann, wenn der Verbau-ungsort nicht von Interesse ist. Bei Großserienprodukten wird, wenn überhaupt, nur eine Seriennummer auf der obersten Ebene vergeben. In der Elektronik ist eine Instan-ziierung durch Positions-Indikatoren üblich, da die Position der jeweiligen Komponente für den Montageprozess rele-vant ist. So ist es sowohl in der Schema- und Layout-Zeich-nung als auch in der Stückliste üblich, eine identische Komponente durch Positionsindikatoren zusätzlich zu identifizieren (z. B. ein Kondensator mit derselben Kapazität hat eine Sachnummer, eine Revision/Version, eine Benen-nung und die Verbauungsorte C1, C2, C3,…). Durch Indus-trie 4.0 entstehen nun neue Anforderungen, vor allem aus der Definition serviceorientierter Geschäftsmodelle, die eine Instanziierung mit Kontextzusammenhang zum Ver-bauungsort und zum Produkt erfordern. Die von Sensoren gelieferten Werte können nur in diesem Kontextzusammen-hang interpretiert werden (Abbildung 15).

Abbildung 13: Verschiedene Sichten auf die Produktstruktur. Nach [33]

Abbildung 14: Zusammenhang zwischen Typ und Instanz sowie Differenzierung

durch Seriennummer


durch Positionsindikatoren

10


5. Die Digitalisierung des Produkt- und ProzessmodellsDie Entwicklung komplexer mechatronischer Produkte und Produktionssysteme umfasst bereits das Zusammenspiel der Disziplinen Mechanik, Elektronik und Software entlang des Produktlebenszyklus und über die Zulieferkette. Dies ist, auch ohne Industrie 4.0, in vielen Unternehmen heute noch ein ungelöstes Problem. 84 % der global agierenden Un-ternehmen verwenden ihre PLM-Lösung und damit die Produktstruktur nur für eine Disziplin und als System mit Archivcharakter. Das ist i. d. R. der Einsatz in der mecha-nischen Konstruktion [29]. 53 % sind der Ansicht, ihr PLM System unterstütze sie nicht bei der interdisziplinären Zusammenarbeit [29]. Mit Industrie 4.0 werden nun cyber-tronische Produkte und Systeme entwickelt, die neben der Problematik der Mechatronik eine weitere Komplexitätsstei-gerung durch Kommunikationsfähigkeit und den System-charakter mit Komponenten verschiedener Stakeholder mit sich bringt. Dadurch werden interne und externe Geschäfts-prozesse, aber auch ganze Geschäftsmodelle verändert. Diesen nicht ausschließlich technischen Transformations-prozess früh zu erkennen und umzusetzen ist die große Herausforderung für viele Unternehmen.

Die Digitalisierung, d. h. die vollständige Beschreibung eines Produktes in Form „digitaler Modelle“ und darauf aufbauende Engineering-Prozesse (Freigabe, Änderung und Konfiguration) beginnt bereits in den ganz frühen konzep-tionellen Phasen des PLZ (siehe Abbildung 16). Das in dieser Phase immer mehr eingesetzte Product Line Engineering (PLE) und Model-Based Systems Engineering (MBSE) sind multidisziplinäre Ingenieurparadigmen, die die Nutzung von Modellen anstelle von Dokumenten propagieren und damit die Analyse, Spezifikation, Entwicklung und Absicher-ung der zu entwickelten Produktsysteme unterstützen (vgl. Kapitel 6.3 und 6.4). Diese Durchgängigkeit entlang des Lebenszyklus eines Produktsystems und über einzelnen Disziplinen hinweg gestattet die Vernetzung aller Entwick-lungsergebnisse. Die konzeptionelle Produktbeschreibung, die im Wesentlichen aus Funktion, Logik und Verhalten besteht, kann auf diese Weise als Brücke zwischen Anforde-rungen und der detaillierten Konstruktion wirken. Des Weiteren muss der Bruch zwischen der Entwicklungs-, Produktions- und Servicewelt konzeptionell angegangen werden. Die bisherigen zwei Systemwelten, die durch PLM und ERP geprägt waren, müssen in einem integrierten digitalen Produkt- und Prozessmodell zusammengeführt werden. Prozesse wie Freigabe, Änderung und das Konfigu-rationsmanagement basieren dann auf einem einheitlichen und durchgängigen digitalen Produkt- und Produktionsmo-dell. Das ERP-System wird die Funktion eines Exekutionssys-tems übernehmen. Das führende System ist dann konse-quenterweise das PLM-System. Neben der PLM-ERP-Kopplung spielt MES zur realtime-Anbindung der Maschinen und Geräte und der Sicherstellung der Bauzustände eine entscheidende Rolle. Der Servicebereich wird ebenfalls durch den zentralen Produkt- und Prozessbackbone abgedeckt.

In der Diskussion solcher übergreifender PLM-Lösungen wird immer häufiger der Begriff System Lifecycle Manage-ment (SysLM) verwendet [14, 24]. Damit werden folgende Unterschiede gegenüber herkömmlichen PLM Implemen-tierungen ausgedrückt:

• SysLM beschreibt nicht nur Produkte sondern vollständige Systeme, die aus kommunizierenden Komponenten bestehen

• SysLM geht grundsätzlich von einem interdisziplinären Integrationsansatz aus

• SysLM steht für eine vollständige Integration des gesamten Produktlebenszyklus (vgl. Abbildung 16)

• SysLM unterstützt die Methoden des Model Based Sys- tems Engineering (MBSE) insbesondere durch einen systemischen interdisziplinären Entwurfsansatz in der frühen konzeptionellen PEP Phase (vgl. Kapitel 6.4)

Im Folgenden wird für diese umfassende Lösungsbe-schreibung der Begriff SysLM anstatt PLM verwendet.

Abbildung 16 zeigt auch deutlich, dass das vollständige digitale Modell auf mehrere Ebenen verteilt ist:

• Autorensystem Ebene (fachliche Ebene)

• Teamdaten Management (TDM) (lokale Administrations- ebene eng mit dem jeweiligen Autorensystem verbunden)

• System Lifecycle Management (SysLM) als Engineering/ Production/Process Backbone (globale Administrations- und Prozessebene)

Zwischen den Ebenen und den PLZ-Phasen liegen vielfältige Formen der Kommunikation vor. Bei der digitalen Modellie-rung werden zwei Begriffe unterschieden:

• das auftragsneutrale Digitale Modell bzw. der Digital Master

und

• der auftragsspezifische und vereinzelte Digitale Zwilling bzw. Digital Twin

Diesen Zusammenhang soll Abbildung 17 verdeutlichen. Dabei wird vereinfachend angenommen, dass die virtuellen und realen Instanzen nicht über einen Serviceprozess nachge-führt werden. Dieses Thema wird in Kapitel 6.6 (Service Lifecycle Engineering) nochmals an einem Beispiel mit nach-geführten Serviceprozess detailliert.


durch Seriennummer


durch Positionsindikatoren

Abbildung 16: Modellbasierter Entwicklungsansatz

11

Theoretisch ist das digitale Modell auftragsunabhängig und der digitale Zwilling ist das virtuelle Abbild des ausgeliefer-ten Produktes. In der Realität gibt es je nach Produktionsart viele Mischformen :

• MTS (Made to Stock) wird typisch bei Konsum- und Massengütern eingesetzt und bedeutet eine völlige Trennung der auftragsneutralen Entwicklung und prognoseabhängiger Produktion.

• CTO oder ATO (Configure oder Assembly to Order) Erst wenn individuelle Kundenwünsche in der Produktion eintreffen, wird die spezifische Variante fertiggestellt. CTO und ATO sind geeignet, wenn es basierend auf einem Baukasten- oder Variantenkonzept mehrere Alternativen eines Endprodukts gibt. In den Bereichen Entwicklung, Konstruktion, Beschaffung und Produktion wird über- wiegend auftragsneutral gearbeitet. In den Bereichen Endmontage und Distribution erfolgt die Fertigung kun- denspezifisch, also auftragsabhängig.

• ETO (Engineering to Order) wird direkt nach dem Eingang eines Kundenauftrags der Entwicklungs- und Konstruktionsprozess ausgelöst. Die Entwicklung ist teilweise auftragsneutral, teilweise auftragsabhängig. Die Bereiche Konstruktion, Beschaf- fung, Produktion, Endmontage und Distribution sind bei Engineering to Order in der Regel auftragsabhängig. Dieses Fertigungsprinzip eignet sich vor allem für kunden- individuelle Produkte. Der Standardisierungsgrad ist durch die individuelle Fertigung am geringsten.

Ein weiteres wesentliches Unterscheidungsmerkmal ist – wie bereits bei Abbildung 17 angedeutet – die Nachfüh-rung der realen und virtuellen Instanzen (Digitaler Zwill-ing). Es gibt Anwendungsbereiche, z.B. Aerospace, bei denen jede Veränderung durch einen Serviceprozess im digitalen Zwilling dokumentiert werden muss. Andere, vor allem sicherheitsrelevante oder serviceintensive Anwend-ungsbereiche diskutieren über die technische Machbarkeit und die Wirtschaftlichkeit eines permanenten Abgleichs des Digitalen Zwillings. Eine Übertragung des Begriffes Digi-tales Modell und Digitaler Zwilling auf andere Begriffe ist Abbildung 18 zu entnehmen.

6. Wie ändern sich Produktstrukturen zukünftig?

6.1 Interdisziplinarität, Integration und Föderation

Interdisziplinarität und Integration basiert darauf, das Engineering über den gesamten Produktlebenszyklus, von der frühen Phase der Anforderungsaufnahme, Produktent-wicklung, Produktionsplanung und Produktion, über den operativen Betrieb mit Service und Ersatzteilversorgung bis hin zum Recycling, über alle Disziplinen (Mechanik, Elektrik/Elektronik, Software und Dienstleistungen) und über Be-reichsgrenzen eines Unternehmens hinweg organisatorisch und systemtechnisch zu unterstützen (Abbildung 19).

Wesentlich für eine disziplinübergreifende Produktstruktur ist eine sinnvolle Integration der verschiedenen Autorensys-teme entlang des Produktlebenszyklus und der verschie-denen Disziplinen. Darunter fallen insbesondere die frühe konzeptionelle Phase des PEP (siehe Kapitel 6.4) sowie die CAD- und CAE-Anwendungen für die mechanische, elek-trische und elektronische Konstruktion sowie für die Soft-wareentwicklung (CASE). Dabei ist insbesondere die Ver-schiedenheit der Entwicklungsprozesse von Mechanik, Elektronik, Software und Dienstleistung zu beachten. Die mechanische Produktentwicklung basiert auf den in Kapitel 4 beschriebenen hierarchischen Stücklisten. Software- und Elektronikentwicklung, Produktionsplanung und Dienstleis-tungsbeschreibung unterscheiden sich in ihren Strukturierungs-methoden. Die Produktstruktur wird heute im Wesentlichen in der Phase Entwicklung/Konstruktion, Produktionsplanung und Produktion betrachtet. Der Trend geht eindeutig in die Richtung, die frühen konzeptionellen und die der Entwick-lung/Konstruktion nachfolgenden Bereiche des Produktle-benszyklus in SysLM-Lösungen zu integrieren. Dazu ge-hören die Bereiche Produktionsplanung, Produktion und Serviceunterstützung.

Abbildung 17: Zusammenhang Digitales Modell und Digitaler Zwilling [VPE] Abbildung 18: Zusammenhang Digitales Modell und Digitaler Zwilling [VPE]

Abbildung 19: Interdisziplinärer, integrierter und föderierter

Produktlebenszyklus. Quelle: [21]

12


Unter Föderation wird die organisatorische und technische Fähigkeit verstanden, Komponenten der Produktstruktur in verschiedenen internen und externen Organisationseinheiten und in verschiedenen IT-Lösungen zu verwalten und zu pflegen, dabei aber den Gesamtzusammenhang zu erhalten.

6.1.1 Software

Abbildung 20 zeigt ein Softwareprodukt aus unterschiedli-chen Komponenten (Item A, B, …), welche eigenständig revisioniert und versioniert sind. Durch die Auswahl von einzelnen Komponenten in spezifischen Versionen ergibt sich ein neuer Stand eines Softwareproduktes (Built). Generell wird Software innerhalb von Versionskontroll-Systemen entwickelt. Diese Systeme unterstützen unter-schiedliche Alternativen. Der „Trunk“ bezeichnet dabei den fortlaufenden Hauptstrang der Entwicklung. Hier werden sämtliche Änderungen erfasst und es besteht die Möglich-keit, an verschiedenen Entwicklungsständen Auskopplun-gen vorzunehmen, welche dann als separater Zweig – als „Branch“ – weitergeführt werden. Dies wird oftmals ge-nutzt, um kleine, aber permanente Änderungen abzu-bilden. Beispielhaft eine Software, die für ein anderes Land bestimmt ist. Ein solcher Zweig kann allerdings auch nur einen kurzfristigen Charakter haben, etwa um neue Elemente zu entwickeln, zu testen und anschließend erst in die Soft-ware zu implementieren. Zu diesem Zweck kann ein Zweig wieder mit dem Hauptentwicklungspfad verschmolzen werden. Diese Zusammenführung erfolgter Änderungen in beiden Versionen wird „Merge“ genannt.

6.1.2 Elektrotechnik/Elektronik

In der Elektrotechnik/Elektronik existieren verschiedene Anwendungsstufen (siehe Abbildung 21).

Auf der höchsten Betrachtungsebene der elektrischen Schaltung befindet sich das Motorsteuergerät und die damit verschalteten Sensoren und Aktuatoren sowie deren Energieversorgung. Das Steuergerät selbst ist in der Regel auf einer Leiterplatte realisiert. Leiterplatten sind eine Weiterentwicklung der freien elektrischen Schaltung. Sie werden durch eine kompakte und robuste, aber starre Befestigung einzelner (diskreter) elektrischer und elek-tronischer Bauteile charakterisiert. Wegen dieser spezifischen Ausprägung stellen Leiterplatten die zweite Betrachtungs-ebene zur Klassifikation von E-CAD-Werkzeugen dar. Man spricht auch von PCB (Printed Circuit Board) Design. Eine Ebene tiefer befinden sich die integrierten Schaltkreise (Chips). Ähnlich wie bei Leiterplatten, sind in integrierten Schaltkreisen Bauelemente (Transistoren, Kondensatoren, Widerstände) kompakt untereinander verbunden. Es handelt sich dennoch um eine viel größere Dichte (nur) digitaler Bauelemente, die mit ihren Verbindungen unter-einander direkt auf einem Substrat realisiert werden. Verbindungen nach außen sind über Pins realisiert, um Kontakt zur Leiterplatte und somit zu weiteren diskreten Bauelementen herzustellen. Diese drei Betrachtungsebenen stellen drei Möglichkeiten dar, Schaltkreise der Elektrotech-nik und Elektronik zu realisieren: durch die Elektrokonstruk-tion, den Leiterplattenentwurf und den Chipentwurf. Die Entwicklungs- und Produktionsprozesse auf diesen Ebenen sind unterschiedlich und werden von verschiedenen Klas-sen von Vorgehensmodellen, Methoden, Beschreibungsfor-malismen und IT-Werkzeugen zur E-/E-Entwicklung unter-stützt. Typisch ist zum Beispiel eine Instanziierung der E/E Stückliste, da die instanziierten Bauelemente jeweils mit Ihren Verbauungspositionen an den Bestückungsautomat gesandt werden. Beim Chipentwurf und beim Design einge-betteter Systeme stehen auch nicht wie bei der Elektrik und der diskreten Elektronik die grafische Eingabe von E-CAD Systemen im Vordergrund, sondern formale Hardware-beschreibungssprachen (HDL, Hardware Design Languages) wie SystemC, VHDL oder Verilog, mit denen Operationen von integrierten Schaltungen und ihr Design beschrieben sowie simulativ getestet werden können.

6.1.3 Produktbezogene Dienstleistung

Bei Industrie 4.0 bzw. Internet of Services typischen dienst-leistungsorientierten Geschäftsmodellen (vgl. Abbildung 3 und Abbildung 4) müssen die produktbezogenen Dienstleis-tungen und Serviceangebote bereits während der frühen Konzeptphase in die Produktentwicklung integriert werden. In der Regel basieren die Dienstleistungen auf der Kommu-nikationsfähigkeit der zu betrachtenden Komponenten. Dies ist unabhängig von der Art der Dienstleistung, z.B. der typische Fall der vorbeugenden Wartung (Predictive Main-tanance), Ersatzteilbevorratung oder – wie in Abbildung 22 dargestellt – die Optimierung der Müllentsorgung.

Abbildung 20: Konfiguration verschiedener Software-Elemente. Quelle: [36]

Abbildung 18: Zusammenhang Digitales Modell und Digitaler Zwilling [VPE]

Abbildung 19: Interdisziplinärer, integrierter und föderierter

Produktlebenszyklus. Quelle: [21]

Abbildung 21: Verschiedene Arten der Elektrik/Elektronik-Anwendungen

Abbildung 22: Produkt- und Service-Engineering im Bereich Müllversorgung [VPE]

13

Auch in diesem Fall werden die Dienste über Netzwerk-modellierende Sprachen beschrieben. Die Business Process Modeling Language (BPML) ist eine XML-basierte plattform-unabhängige Sprache zur Beschreibung von Geschäftspro-zessmodellen. Eine grafische Repräsentation der Prozesse ist mit der BPMN (Business Process Modelling Notation) - Sprache möglich. Eine weitere serviceorientierte Dienstleis-tung könnte die Generierung kundenspezifischer Dokumen-tationsunterlagen auf Basis des digitalen Zwillings – also der auftragsbezogene Konfiguration – sein.

Der Begriff der Föderation bedeutet die Abkehr von mono-lithischen Lösungen. Diese sind vor dem Hintergrund der quantitativ und qualitativ gestiegenen Produkt- und Pro-zesskomplexität nicht mehr adäquat. In Zukunft wird von föderierten semantischen Netzwerken ausgegangen, die das digitale Modell auf verschiedene Ebenen (Autorensys-tem, Teamdata Management und SysLM-Backbone) ver-teilen. Künftige SysLM-Architekturen müssen auf konsis-tenten, aber erweiterbaren Grunddaten basieren sowie autonome und an veränderte Prozesse und Organisations-strukturen flexibel anpassbare Funktionsbausteine bieten. Sie müssen dynamisch anpassbar sein, da die Datenmodelle regelmäßig verändert werden. Mit den Prozessen in der Organisation ändern sich auch die Stakeholder der einzel-nen Datenobjekte.

6.2 Kollaboration

Disziplinenübergreifende Produktentwicklung führt zwangs-läufig zu zunehmender Globalisierung im Bereich der Wertschöpfungskette, sowohl innerhalb der Produkther-steller als auch über die Zulieferkette. Daraus resultieren komplexe, vernetzte Arbeitsorganisationen und Prozesse (vgl. Abbildung 23). Das bedeutet, dass sich die Produkt- und Produktionsdaten sowie die typischen Engineering-Prozess über die gesamte Zulieferkette verteilen. Die Anfor-derung bereichsübergreifender Kommunikation und globaler Zusammenarbeit über verschiedene Kulturräume und Zeitzonen gewinnt immer mehr an Bedeutung. Außerdem muss die internetbasierende Einbindung von Kunden und Zulieferern in Form einer Engineering Collabo-ration Plattform Teil einer SysLM-Lösung sein. Auch Cloud Lösungen können diese Plattformen unterstützen.

Zugriffslogiken stellen sicher, dass die richtigen Mitarbeiter die Informationen zur richtigen Zeit, am richtigen Ort und in der ihnen zulässigen Untermenge sehen und eventuell auch bearbeiten können. Die Unterstützung der Kollabora-tion mit Joint Ventures, Entwicklungspartnern, Lieferanten

von Systemen, Software und Services usw. ist eine Kernan-forderung an zukünftige SysLM-Lösungen. Die Zusammen-arbeit muss viel enger gestaltet sein als heute, damit die Systeme der Partner als Gesamtsystem höchsten Ansprüchen genügen. Gleichzeitig muss der Schutz des geistigen Eigen-tums von OEM und Partnern sichergestellt sein. SysLM bietet zahlreiche Werkzeuge, mit denen Unternehmen intern und extern zusammenarbeiten können. Teilweise werden vereinfachte Kommunikationsmechanismen aus dem Be-reich Social Media angeboten.

6.3 Product Line Engineering (PLE)

System und Software Product Line Engineering, abgekürzt als Product Line Engineering (PLE), wird als das Engineering eines Portfolios von verschiedenen Programmen und darin variierenden Produkten definiert. Variation kann verschie-den interpretiert werden (vgl. Kap. 4):

• Ableitung von Varianten auf der Basis von Optionen, z.B. 1027 Varianten eines deutschen Mittelklassewagens auf der Basis eines Optionskataloges

• Aufbau von Plattformkonzepten, das bedeutet, dass auf Basis einer gemeinsamen Hardware oder Software Platt- form verschiedene Applikationen aufsetzen

• Modularität von Teilsystemen bzw. -komponenten, die in verschiedenen Applikationen wiederverwendet werden (Querbaukästen, Kommunalität). Zielsetzung ist eine hohe Wiederverwendung über Produkte, Programmen und Portfolios

Zielsetzung der Variabilität ist eine hohe Marktabdeckung (äußere Varianz) bei möglichst geringen betrieblichen Aufwendungen durch eine geringere innere Varianz zu erzielen. Hilfsmittel die innere Varianz niedrig zu halten sind zum Beispiel definierte Hardware und Software Schnittstellen oder generell die Verlagerung der Varianz in die Software. So ist es beispielsweise unter Fahrzeugher-stellern üblich dem Kunden eine 1,6, 1,8 und eine 2 Liter Variante eines Motors anzubieten. Innerbetrieblich basieren alle Varianten auf demselben 2 Liter Motor mit der iden-tischen Einspritzelektronik und demselben Applikationspro-gramm. Nur die Kalibrierungsdaten, die die Leistung des Motors definieren, werden verändert.

Der Begriff PLE kommt aus dem Softwareengineering, wird aber in letzter Zeit für das gesamte interdisziplinäre Produkt, Programm und Portfolio angewandt (ISO26550 Reference Model for System and Software Product Line Engineering). In der Hardwareentwicklung ist der Begriff noch relativ neu, aber die Varianten- und Baukastensyste-matiken sind bereits seit den 60er Jahren bekannte Me-thoden, die Produktentwicklung und die Produktion zu optimieren. Zielsetzung ist die Reduzierung der Entwick-lungskosten und der Markteinführungszeit bei gleichzeitiger Erhöhung der Produktivität, der Produktskalierbarkeit sowie der Qualität. Der radikale Umdenkungsprozess entsteht einerseits dadurch, dass PLE für ein gesamtes mecha-tronisches oder cybertronisches Produkt angewandt wird – also auf alle Disziplinen parallel – und zum anderen durch die Verbindung und Integration mit dem modellbasierten Entwicklungsansatz (MBSE vgl. Kapitel 6.4). Abbildung 24 zeigt diesen Zusammenhang.

Abbildung 23: Zukünftige Zusammenarbeit [40]

14


6.4 Produktstrukturen in der frühen Phase des Produktlebenszyklus (Upstream Prozess)

Industrie 4.0 Produkte, die zunehmende Digitalisierung sowie die dazugehörigen Engineering Prozesse verlangen eine stärkere Betonung der frühen Phasen des PEP. Zusam-men mit der notwendigen Interdisziplinarität ergibt sich durch Model Based Systems Engineering (MBSE) ein neuer Ansatz in der Produktentwicklung, der für die Entwicklung komplexer mechatronischer und cybertronischer Produkte optimale Voraussetzungen bietet. Daraus ergeben sich neue Modellelemente, die einerseits administriert werden und andererseits den Engineering Prozessen unterliegen. Dazu gehören z.B. Anforderungen, Funktionen, Verhalten, lo-gische Strukturen, Test- und Use-Cases sowie Stakeholder. Das Problem der Integration der verschiedenen Disziplinen während des frühen Entwicklungsprozesses kann durch die Verwendung solcher Modellierungssprachen möglichst früh in Angriff genommen werden, indem die Korrelationen zwischen den genannten Objektklassen definiert werden und eine interdisziplinäre Systemarchitektur beschrieben wird. Die durchgängige, modellbasierte Entwicklung ist in der virtuellen Produktentwicklung von zentraler Bedeutung und somit auch eine wesentliche Herausforderung an die Optimierung des PEP für mechatronische und insbesondere für cybertronische Produkte und Systeme. Die Methoden des Model Based Systems Engineering können dazu beitra-gen, ein multidisziplinäres Produkt in einer abstrakten Weise zu beschreiben. Die VDI 2206 definiert einen syste-matischen Ansatz für die Entwicklung mechatronischer Systeme. Der Fokus liegt hier auf dem linken Flügel des “V” und erweitert es mit den Werkzeugen des modellbasierten Systems Engineering. In dem vom BMBF geförderten For-schungsprojekt mecPro² wurden - unter Beteiligung von Siemens - die Ansätze der Software Plattform für Embedded Systems (SPES) mit den Konstruktionsmethoden der Mechanik (VDI2221) vereinigt (Abbildung 25). Daraus entstand ein erweitertes V-Modell [25] .

Es können drei Ebenen der digitalen Modellierung identifi-ziert werden (Abbildung 26):

• Modellbildung und Spezifikation: Ein System wird durch qualitative Modelle beschrieben. Diese beinhalten Anforderungs-, Funktions-, Verhaltens- oder logische Systemstrukturen. Die Modelle sind beschrei- bend und können nicht simuliert werden. Als Autoren- werkzeuge dienen beispielsweise graphische Editoren für Beschreibungssprachen wie SysML, die auf einer Erwei- terung und Schnittmenge von UML basiert.

• Modellbildung und erste Simulation und Validierung: Auf dieser Ebene werden meist quantitative, simulierbare Modelle erstellt, etwa multiphysikalische Simulations- modelle, die mehrere Disziplinen mit einbeziehen. Als Autorenwerkzeuge dienen Simulationseditoren wie LMS Imagine.Lab Amesim, Matlab/Simulink oder in der Elek- tronik VHDL, Verilog oder SystemC.

• Disziplinspezifische Modellbildung und detaillierte Simu- lation und Validierung: Auf dieser Ebene werden zum Beispiel Geometrie- oder CAE-Modelle erstellt, die einen sehr disziplinspezifischen Charakter haben. Als Autorenwerkzeuge dienen CAD Systeme oder disziplinspezifische Berechnungs- und Simulationssoftware.

Basierend auf der Beschreibung des Systemmodells erfolgt eine Abbildung auf erste vereinfachte Simulationen, die bereits eine erste Validierung ermöglichen. Danach beginnt die disziplinspezifische Entwicklung, die die physischen Elemente des Systems wie Hardware-Teile oder Software-Code (gekennzeichnet mit P in Abbildung 26) adressiert.

Abbildung 24: Zusammenspiel von Product Line Engineering (PLE) mit

Systemmodellierung (MBSE)

Abbildung 25: Vereinigung von SPES mit VDI 2221 zu einem erweiterten V-Modell. Quelle: [25][26]

5mecPro² = modellbasierter Entwicklungsprozess cybertronischer Produkte und Produktionssysteme

Abbildung 26: Erweitertes V-Modell für Model Based Systems Engineering mit

einem SysLM-Backbone [24]

15

Hier setzen in der Regel die CAx-Prozesse in der virtuellen Produktentwicklung an. Ab dieser Ebene positionieren sich heutige SysLM-Lösungen. Die wesentlichen Erweiterungen der Produktstrukturen in dieser frühen Phase des PEP sind die neuen Informationselemente Anforderungen, Funktion, Verhalten und logische Systemelemente. Darauf sollten bereits vereinfachte Engineering-Prozesse (Freigabe-, Änderung- und Konfigurationsmanagement) zur Unterstüt-zung der „Traceability“ implementiert werden. Abbildung 27 zeigt einen konkreten Anwendungsfall auf der Systemarchi-tekturebene aus dem Anwendungsbereich Automotive.

Konkurrierend bzw. ergänzend zur heutigen SysLM-Philoso-phie haben einige Anbieter, die ursprünglich aus der CASE (Computer Aided Software Engineering) Anwendung ka-men, auch durch ihre leistungsfähigen Anforderungsman-agement-Systeme und zugekauften MBSE-Tools einen neuen Anwendungsbereich definiert: ALM = Application Lifecycle Management. Ähnlich der Einbindung von CAD zu PLM, wurden im Rahmen von mecPro² die Kommandos eines marktüblichen PLM-Systems in die Befehlsstruktur eines SysML-Autorensystems und vice versa integriert. Durch die Verknüpfung mit den im ursprünglichen PLM Leistungsumfang enthaltenen konstruktiven Stammdaten und Stücklisten wurde eine durchgehende Integration von Anforderungen, Funktionen, logischen Blöcken und der Entwicklungsstückliste (E-BOM) – und damit eine der wesentlichen Zielsetzungen von System Lifecycle Manage-ment – erreicht

6.5 Integration der späten Phase des Produktlebenszyklus (Downstream Prozess)

6.5.1 Closed Loop Manufacturing, Integrated Mechatronics Engineering

Eine der größten Herausforderungen stellen Medienbrüche eingesetzter Systeme und Prozesse zwischen Produktent-wicklung, Produktionsplanung sowie der eigentlichen Produktion dar. Ein Ansatz fordert, dass komplexe und smarte Produkte künftig annährend zum Preis einer Mas-senfertigung kundenindividuell entwickelt und gefertigt werden.

Mit CAx-Systemen werden Produktmodelle entwickelt, deren Daten eine Entwicklungs- bzw. Produktionsstückliste ergeben. Darauf aufbauend, können unter zur Hilfenahme von Digital Manufacturing Systemen Maschinen, Vorrich-tungen und Anlagen für die Fertigung entwickelt, sowie Simulationen der Produktion und des Materialflusses ange- stoßen werden. Das Ergebnis ist eine digitale Prozess-

beschreibung – eine Bill of Process (BOP). Mit SysLM kön-nen diese Daten miteinander verknüpft und ihre Beziehun-gen aktuell gehalten werden. Mit den Daten der Produkt-struktur und des betrieblichen Maschinen- und Anlagen-parks kann lediglich der prinzipielle Ablauf beschrieben werden. Eine Ansteuerung der Maschinen erfordert mehr.

Um dies zu ermöglichen, müssen zum einen die konkreten Anforderungen für einen einzelnen Auftrag der Auftrags-planung mit den technischen Daten verbunden werden. Zum anderen muss eine Ergänzung der Zulieferteile und um anlagenspezifische Daten einschließlich des Layouts der Anlage erfolgen. Dies ist die Aufgabe des Manufacturing Execution Systems (MES) und erforderte bislang erneute Eingaben und zusätzliche Bearbeitungsschritte.

Der Ansatz von Closed-Loop-Manufacturing basiert auf einem gemeinsamen Datenmodell und erlaubt somit einen bidirektionalen Datenfluss. Die verfügbaren Daten des SysLM-Systems können unmittelbar zur Ansteuerung der konkreten Produktionslinie genutzt werden, während gleichzeitig die Daten aus der Produktion dem Engineering zur Verfügung stehen.

Eine weitere Herausforderung, hervorgerufen durch die digitale Transformation der Industrie, hat ihre Ursache in einem anderen Medienbruch: Alle Fachdisziplinen, die für die Entwicklung und Fertigung smarter Anlagen benötigt werden, arbeiten heute oftmals mit unterschiedlichen Systemen und Datenmodellen. Das 3D-Modell der Mechanik ist i. d. R. nicht kompatibel mit dem Schaltplan der Elektrik. Das Verhaltensmodell der Softwareentwicklung kennt keine Engineering-Details von Mechanik und Elektrotechnik. Wenn ein Simulationsmodell existiert, dann sind seine Daten nicht ohne Zusatzbearbeitung für andere Modelle nutzbar. Mit Integrated Mechatronics Engineering können Daten und Prozesse integriert werden. Somit kann eine mechatronische Bibliothek von Bauteilen und Baugruppen entstehen, die beispielsweise Motoren, Antriebe, Ventile, Pumpen oder andere Teile enthält. Diese Bibliothek enthält schließlich, Detailinformationen aller beteiligten Disziplinen. Für die Entwicklung einer Maschine können diese Elemente als fertige Teile importiert werden, da die Daten zentral im SysLM-System verwaltet werden.

Obendrein ist die Automatisierungstechnik kompatibel zu dieser Sprache, wodurch die Engineering-Daten unmittelbar zur Generierung der SPS-Software und für die virtuelle Inbetriebnahme genutzt werden können. Dadurch werden Schnittstellen überflüssig. Zudem ändern sich die Prozesse und Abläufe im Unternehmen und mit den Zulieferern.

Abbildung 27: Systemarchitektur, funktionale Analyse und SystemmodelleAbbildung 28: Zusammenspiel von Softwareintegration und Fertigung

16


6.5.2 Zusammenspiel von SysLM, ERP und MES

System Lifecycle Management (SysLM), Manufacturing Execution Systeme (MES) und Enterprise Resource Planning (ERP) nehmen heutzutage oft ergänzende Rollen in einem Unternehmen ein. Dabei stellen Materialstammdaten, Stücklisten und Dokumente die Basis zur Umsetzung der unterschiedlichen Geschäftsprozesse genannter Systeme dar.

Heute sind viele ERP- und SysLM-Systeme in der Regel in einer Richtung integriert, d. h. das SysLM-System übergibt die Produktdaten an das ERP-System in Abhängigkeit der Produktreife. Ein MES-System wird über die Fertigungs-aufträge oder Abrufe vom ERP-System angestoßen.

Im Vergleich dazu gewährleistet ein SysLM-System die intelligente Vernetzung von allen technischen Produktinfor-mationen in der frühen Produktentwicklungsphase wesentlich besser als ein ERP-System. Die Prozessunterstüt-zung bei der funktionsübergreifenden Integration von Funktionsbereichen wie der Produktentwicklung und dem Produktions-Engineering gelingt wesentlich besser.

Künftig werden z.B. auch Simulationen in Verbindung mit Arbeits- und Montageplänen durchgeführt. Diese digitalen Informationen liegen im SysLM-System vor. Ein weiteres Argument für ein Umdenken der Arbeitsplan-Anlage in SysLM ist die häufige Umstrukturierung der Stückliste aus dem Engineering in eine Fertigungs- oder Montagestruktur. Wenn dies in einem System vorgenommen wird kann man mittels „Sichten“ Redundanzen vermeiden. Dies vereinfacht vor allem die Änderungsprozesse.

Das MES-System ist in die Geschäftsprozesse der Produk-tionsfeinplanung und -steuerung auf Basis von ERP-Aufträ-gen eingebunden. Produktdaten werden vom SysLM-Sys-tem beigesteuert.

Vor diesem Hintergrund wird klar, dass MES ein Bestandteil wesentlicher Unternehmensprozesse ist und in diese inte-griert werden muss. Zukünftig wird es eine Integration über die verschiedenen Funktionsebenen (SysLM, MES und ERP) mit den Bereichen Produktion, Instandhaltung, Qualität und Bestandsführung geben.

ERP-Anbieter sehen als Alternative zu einer dedizierten digitalen Enterprise Software Suite den monolithischen Ansatz, nur ein System einzusetzen. Dies entspricht in ihrem Kern dem CIM-Leitgedanken der 80er Jahre. Zu dem Zeitpunkt hat man versucht, sämtliche Daten und Prozesse in ein unternehmensweites Datenmodell zu integrieren. Die CIM-Bewegung ist damals gescheitert, nicht zuletzt auf-

grund der Komplexität und Inflexibilität eines solchen Ansatzes für unterschiedlichste Anforderungen aus ver-schiedensten Subsystemen. Eine digitale Enterprise Soft-ware Suite verfügt heute über eine moderne Softwarearchi-tektur, die dafür entwickelt wurde, Informationen zu vernetzen und dynamische Prozesse wie im Engineering zu unterstützen.

6.6 Service Lifecycle Engineering

Moderne Ansätze von internetbasierten Dienstleistungen, die auf kommunizierenden Produkten aufbauen, haben ihren Ursprung häufig in einer Massendatenauswertung während der Produktions- und Betriebsphase (vgl. Abbil-dung 4). Der Entwurf dieser Dienstleistungen, wurde in Kapitel 6.1.3. als vierte Disziplin neben Mechanik, Elektrik/Elektronik und Software eingeführt. Der Entwurf und die Ausführung dieser neuen dienstleistungsorientierten Ge-schäftsmodelle werden als Service Lifecycle Engineering (SLE) bezeichnet. Das bedeutet einerseits eine Erweiterung des digitalen Modells in den Servicebereich und somit auch eine Erweiterung der herkömmlichen SysLM-Lösungen.

Abbildung 30 zeigt am Beispiel eines mit internetfähigen Sensoren und Aktuatoren ausgestatteten Produktes aus der Landwirtschaft, welche Feedback-Loops relevant sind. Für die Optimierung des PEP ist es interessant, welche Kompo-nenten und Systeme zu qualitativen oder funktionalen Problemen führen. Durch direkte Anbindung an die tech-nischen Stammdaten im SysLM-System kann sich der Kon-strukteur jederzeit über die Fehlerhäufigkeit einer Kompo-nente informieren. In der Nutzungsphase kann einerseits der Wartungs- und Ersatzteilversorgungsprozess optimiert werden, um dem Kunden eine höhere Verfügbarkeit seines Produktes bzw. seines Systems zu garantieren (Predicted Maintenance). Andererseits bekommt der Kunde auf Grund der anfallenden Informationen und deren analytischer Auswertung Hilfestellungen für eine Optimierung seiner Prozesse. Beide Geschäftsmodelle basieren auf dem soge-nannten Condition Monitoring, d.h. der permanenten Überwachung des Betriebszustandes.

In diesem Beispiel ist ein kritischer oder sich häufender Schaden am Produkt (1b ) aufgetreten, der zur Weiterent-wicklung des Digitalen Modells mit dem Release-Stand R1a zum Release-Stand R2a führt. Die darauf weiterentwickelte Ersatzkomponente wird im Produkt eingebaut und führt beim Digitalen Zwilling und beim realen Produkt zu einem Release-Stand 1c. Je nach Einfluss des Schadens müssen die übrigen ausgelieferten Produkte dieser Baureihe mit der-selben Ausstattung entweder sofort oder beim nächsten Wartungsdienst umgerüstet werden.

Abbildung 29: Zusammenspiel der Systeme ERP, SysLM, MES

7Beim digitalen Produkt symbolisiert die 1 eine Seriennummer und der Buchstabe a eine Version

8Beim digitalen Modell bedeutet die Zahl 1 eine Revision und der Buchstabe a eine Version

Abbildung 30: Internetfähige Produkte können serviceorientierte

Informationen an Entwicklung und Service senden. [VPE]

17

Diese Art von Feedback-Loop setzt die in Kapitel 4.4 einge-führten Typ- und Instanz-Konzepte sowie die Entscheidung des Produzenten, die Instanzen in der virtuellen und realen Welt nachzuverfolgen sowie zu dokumentieren, voraus. Damit sind dann für jede beliebige Komponente service-orientierte Auswertungen möglich (Abbildung 31).

Mit diesem Datenblatt können alle über SysLM verknüpfte Informationen, z.B. 3D-Grafik, Stückliste und Wartungsplan angezeigt werden. Damit kann der Entwicklung und dem Service ein stets aktueller Überblick über die statischen und dynamischen Informationen zum Produkt und seine re-levanten Komponenten gegeben werden.

6.7 Visualisierung

Durch alle bisher aufgeführten Anforderungen an moderne Produktstrukturen, wie Interdisziplinarität, Integration, Instanziierung und Föderation über den gesamten Produkt-lebenszyklus erreicht das digitale Produktmodell einen Grad an Komplexität, der für die tägliche Bearbeitung durch Ingenieure kaum zu bewältigen ist. Akzeptanzproblema-tiken sind die konsequente Folge. Gerade die typischen Engineeringprozesse wie Freigabe-, Änderungs- und Kon-figurationsmanagement bedürfen einer hohen Transpa-renz, welche Objekte von einem solchen Prozess betroffen sind. Man spricht dann von:

• Configured Items (CI): Elemente der Produktstruktur und Ihren zugehörigen Dokumenten, die von einer Änderung grundsätzlich betroffen sein können. Eine typische Größenordnung liegt zwischen 50 und 200 CI´s.

• Affected Items (AI): Das sind dann die konkret von einer Änderung betroffenen und zu ändernden Elemente.

Graphen eignen sich sehr gut, diese komplexen Strukturen zu visualisieren (Abbildung 32). Das setzt natürlich voraus, dass über Links eine Zuordnung verschiedener Autoren- und Verwaltungssysteme (TDM, SysLM und ERP) realisiert ist (vgl. Abbildung 16). Die mit den Knoten verknüpften Dokumente müssen in dieser Visualisierungsschicht über die typischen „Light Weight“ Formate dargestellt werden (TIFF, PDF, JT, etc.)

7. Zukünftige Prozess- und IT-Architektur

Ein interdisziplinärer, integrierter und föderierter PEP, der die Entwicklung Industrie 4.0 geeigneter Produktstrukturen unterstützt, basiert auf einer Vielzahl von Autorensystemen über die verschiedenen Phasen des Produktlebenszyklus hinweg. Weiterhin muss dieser Prozess die verschiedenen Disziplinen, sowie die unterschiedlichen Standorte und Zulieferer miteinbeziehen. Diese müssen durch eine ge-eignete Architektur, welche über eine oder je nach Komplex-ität über zwei Hierarchiestufen verfügt, in einen gemeinsa-men Produkt- und Prozessbackbone eingebunden werden. Gekennzeichnet sind diese Konzepte durch die vier nachfol-genden Ebenen, die im Rahmen einer VDA-Arbeitsgruppe festgelegt wurden:

• Autoren Systeme (RM, SysML, MCAD, ECAD, CASE, CAP, CAM, Digital Factory, Office sowie Berechnungs- und Simulationssysteme)

• Team Data Management (TDM), eine Verwaltungsebene, die autorensystemnahe Informationen verwaltet und die direkt den Autorensystemen zugeordnet sind. Diese Ebene verwaltet in der Regel die nativen Formate der Autoren systeme. Sind die Autorensysteme einfach strukturiert, kann diese Ebene auch entfallen und man spricht von einer Direktkopplung. Der Trend geht heute in die Rich- tung, dass Autorensysteme bereits auf eigenen Datenban- ken aufbauen und damit die Ebenen zwischen Autorensys- tem und TDM verschmelzen.

• Engineering-Backbone, die zentrale Ebene des Produktle- benszyklus, die die interdisziplinäre Produktstruktur mit allen zugehörigen Dokumenten – in der Regel in neutralen Formaten – enthält. Darauf baut das engineeringorientierte Freigabe-, Änderungs- und Konfigurationsmanagement auf. Diese Ebene wird durch PLM- und SysLM-Systeme umgesetzt.

• ERP-Backbone, der bei einer globalen Verteilung meist aus mehreren lokalen Instanzen und häufig verschieden angepassten ERP-Systemen besteht. Auf dieser Ebene wird heute der logistische und produktionstechnische Teil des Änderungs- und Konfigurationsmanagements umgesetzt.

Abbildung 31: Beispiel eines serviceorientierten, permanent aktuell

gehaltenen Reports einer Komponente

Abbildung 32: Graphenbbasierende Lösung eines über den gesamten

Produktlebenszyklus verknüpften Produktmodells am Beispiel von „Affected

Items“ im Rahmen eines Änderungsantrags. Quelle: [37]

18


Abbildung 33 stellt diesen fragmentierten Ansatz einer heutigen IT-Architektur dar. Dabei wurde berücksichtigt, dass sich in den letzten Jahren eine IT-Lösungskombination ergeben hat. Die typischen CASE Tool Anbieter haben Ihre Lösungen um Requirements Management (RM) und MBSE Werkzeuge ergänzt und nennen das Application Lifecycle Management (ALM). ALM ist dann entweder auf der TDM-Ebene oder auf der Backbone-Ebene umgesetzt. Weitaus häufiger ist jedoch, dass diese drei Funktionen in den Unternehmen historisch nach der Methode „best in breed“ ausgewählt wurden. Identisch ist die Positionierung von Service Lifecycle Management (SLM) in der späten Lebens-zyklusphase eines Produkts.

Die TDM-Ebene dient dabei als Zwischenschicht für die Vielzahl zu integrierender Autorensysteme, die die Autoren-system-nahen Informationen verwaltet, z.B. die nativen RM, SysML, CAD- und CAE-Files. Nur die für die Engineering-Prozesse absolut notwendigen Produktdaten erreichen so den Engineering-Backbone. Die Visualisierung auf dieser Ebene arbeitet mit neutralen Formaten wie TIFF, JT und PDF (vgl. Abbildung 32). Die Enterprise Service Plattform ver-waltet die Feedback Daten vom operativen Betrieb und verwaltet oder referenziert die Konfigurationen der Digi-talen Zwillinge.

Das Hauptproblem dieser auf Backbone-Ebene fragmentierten Architektur (a in Abbildung 34), liegt in der Abstimmung von Informationen und Prozessen zwischen der durch ALM/SysLM bestimmten Design Chain und der durch ERP bestimmten Supply Chain. Hinzu kommt, dass ERP-Systeme nicht die erforderlichen flexiblen Gestaltungsmöglichkeiten zur firmenspezifischen Adaption sowohl des Produkt- als auch des Prozessmodells besitzen und somit eine gemeinsame Prozessgestaltung häufig auf dem kleinsten gemeinsamen Nenner anstatt auf dem Optimum basiert.

Abbildung 33: Architektur, ALM, SLM und PLM bilden gemeinsam mit ERP einen fragmentierten Backbone

19

Als eine Alternative bietet sich eine eher evolutionäre Lö-sung durch Auslagern der übergreifenden Prozesse in ein übergeordnetes System an, z.B. auf der Basis eines Unterneh-mensserver mit einem eingebetteten modellbasierten Repository (b in Abbildung 34 und Abbildung 35). Das Repository enthält eine Verlinkung aller theoretisch von einer Freigabe oder Änderung betroffenen Elemente (Con-figured Items). Im konkreten Änderungsfalle werden dem Anwender die möglichen betroffenen Elemente sukzessive angezeigt und interaktiv ausgewählt. Am Ende ergibt sich ein Szenario, dass nur noch die von dieser Änderung betrof-fenen Elemente anzeigt (Affected Items). Optimal geeignet für die Anzeige sind graphenbasierte Visualisierungslösun-gen (vgl. Abbildung 32) und Repository-Technologien die externe Objekte und Attribute erlauben.

Eine eher revolutionäre Lösung wäre, alle Anwendungsbe-reiche – ALM, die Produktionsplanung mit den Produktions- ressourcen und den Service – in den SysLM-Backbone zu integrieren. Das setzt eine leistungsfähige Einbindung von Digitalen Fabrik Systemen und MES voraus. ERP würde in diesem Szenario die Rolle eines ausführenden Systems übernehmen. Damit wäre eine Umsetzung aller Engineering Prozesse auf einer gemeinsamen Ebene möglich. Abbildung 36 zeigt einen für alle Anwendungsbereiche entlang des PLZ gemeinsamen SysLM-Backbone. Die Autorensysteme sind entweder direkt oder mit einer TDM-Lösung integriert. Es ist ein wesentliches Architekturprinzip, dass der Back-bone nur die wirklich relevanten Daten enthält. Die ALM und SLM Administrationsfunktionen sind im SysLM-Back-bone realisiert. Die Funktionen der Supply Chain werden durch ein leistungsfähiges MES-System in Verbindung mit der Digitalen Fabrik und dem ERP-System umgesetzt. Letzteres stellt in diesem Kontext ein reines Exekutions-System dar.

Das Problem eines durchgängigen Engineering-Backbones ist seine monolithische Struktur. Hier ergeben sich durch Web-Technologien neue Perspektiven. Mehr als ein Jahr-zehnt nach seiner Einführung ist Representational State Transfer (REST) eine der wichtigsten Technologien für Web-Anwendungen. Seine Bedeutung wird weiter wachsen, zumal REST die Grundlage eines sich schnell entwickelnden Standards ist: OSLC (Open Service for Lifecycle Collabora-tion). Fast jede Entwicklungssprache enthält heute Frame-works um RESTful Web-Services zu entwickeln. Entsprech-end kann die Backbone Lösung aus Abbildung 36 einen zukünftigen Kompromiss von persistenten Daten und über OSLC/REST verlinkten Daten im Backbone darstellen.

Abbildung 34: Grundsätzliche Alternativen der Integration von Design und

Supply Chain

Abbildung 35: Ausgelagertes Engineering-Cockpit zur Visualisierung und

Änderungsdurchführung (CMBC = Change Management Backbone and

Control). [37]

Abbildung 36: Durchgängige Backbone-Lösung für System Lifecycle Management

20


8. ZusammenfassungIntelligent vernetzte, kommunizierende Produktsysteme in ihrer vielfältigen Form stehen erst am Anfang unzähliger Innovationen. Treiber ist die Kombination der Möglichkeiten und fundamentalen Kräfte der Digitalisierung sowie der Kommunikationsfähigkeit von Komponenten und Systemen. Das Produktsystem steht künftig im Mittelpunkt, und damit auch das Wissen über den gesamten Lebenszyklus eines Produktsystems. Um dies ganzheitlich über den Lebenszyklus zu ‚managen‘, bedarf es zum einen der interdisziplinären Beschreibung anhand eines integrierten Systemmodells, beginnend in den frühen Lebenszyklusphasen, bis zum Recycling. Zum anderen braucht es eine Datenerfassung über alle Lebenszyklusphasen hinweg. Die Ausgestaltungen von Industrie 4.0 schaffen hierzu die notwendigen tech-nologischen Voraussetzungen. System Lifecycle Management (SysLM) gilt dabei als Schlüsselkonzept für einen Engineering- Backbone, der die interdisziplinäre, integrierte und föderierte Beschreibung und Verwaltung einer Produkt- und System-struktur als Teil des Digitalen Modells ermöglicht. Die Entwicklungen im diesem Bereich werden sowohl im wis-senschaftlichen als auch im praktischen Umfeld mit rasanter Geschwindigkeit weiter voran schreiten. Welche Entwick-lungstrends sich in Zukunft durchsetzen und auf breite Akzeptanz bei den Anwendern stoßen werden, wird sich in den nächsten Jahren herausstellen.

Wir müssen diese einmalige Chance nutzen, lassen Sie uns Um- und Querdenken, lassen Sie uns Barrieren einreißen und lassen Sie uns damit jetzt anfangen.

21

9. Literaturverzeichnis [1] Eigner, M.: Modellbasierte Virtuelle Produktentwicklung auf einer Plattform für System Lifecycle Management. In: Sendler, U. (Hrsg.): Industrie 4.0 - Beherrschung der industriellen Komplexität mit PLM, Springer Verlag, Berlin, Heidelberg 2013, S. 91-110.

[2] Anderl, R.; Eigner, M.; Sendler, U.; Stark, R. (Hrsg.): Smart Engineering – Interdisziplinäre Produktentste- hung, acatech DISKUSSION, 1. Aufl., Springer Vieweg Verlag, Berlin, Heidelberg, 2012.

[3] Annunziata, M.; Evans, P.: Industrie 4.0 – Pushing the Boundaries of Minds and Machines, GE General Electric, Fairfield, Connecticut, USA 2012.

[4] Annunziata, M.; Evans, P.: Industrie 4.0 – Eine europäische Perspektive: Neue Horizonte für Minds and Machines, GE General Electric, Fairfield, Connecticut, USA 2013.

[5] Eigner, M.: Industrie 4.0 - nur Produktionsautomatisierung oder doch mehr?, in: Konstruktion - Zeitschrift für Produktentwicklung und Ingenieur-Werkstoffe, Jhrg. 2015, HeftNr. 6, S. 3. - ISSN: 0720-5953.

[6] Eigner, M.; Roubanov, D.; Zafirov, R. (Hrsg.): Modell basierte Virtuelle Produktentwicklung, 1. Aufl., Springer Verlag, Berlin, Heidelberg 2014.

[7] Tschöpe, S.; Aronska, K.; Nyhuis, P.: Was ist eigentlich Industrie 4.0? – Eine quantitative Datenbankanalyse liefert einen Einblick, in: “ZWF Zeitschrift für wirtschaftlichen Fabrikbetrieb”, Jhrg. 110, HeftNr. 3, Carl Hanser Verlag, München 2015, S. 145-149. - ISSN: 0947-0085.

[8] Weyer, S.; Fischer, S.: Gemeinschaftsprojekt Industrie 4.0 – Fortschritt im Netzwerk, in: “ZWF Zeitschrift für wirtschaftlichen Fabrikbetrieb”, Jhrg. 110, HeftNr. 1-2, Carl Hanser Verlag, München 2015, S. 50-53. - ISSN: 0947-0085.

[9] Bauer, W.; Herkommer, O.; Schlund, S.: Die Digitalisierung der Wertschöpfung kommt in deutschen Unternehmen an – Industrie 4.0 wird unsere Arbeit verändern, in: “ZWF Zeitschrift für wirtschaftlichen Fabrikbetrieb”, Jhrg. 110, HeftNr. 1-2, Carl Hanser Verlag, München 2015, S. 68-73. - ISSN: 0947-0085.

[10] Eigner, M.; Apostolov, H.; Dickopf, T.; Schäfer, P.; Faißt, K.-G.: “System Lifecycle Management - am Beispiel einer nachhaltigen Produktentwicklung nach Methoden des Model-Based Systems Engineering “, in: “ZWF Zeitschrift für wirtschaftlichen Fabrikbetrieb”, Jhrg. 109, HeftNr. 11, Carl Hanser Verlag, München 2014, S. 853-860. - ISSN: 0947-0085.

[11] Ehrlernspiel, K; Meerkamm, H.; Integration versus Spezialisierung – Von der Notwendigkeit einer ganz- heitlichen Konstruktionsforschung und Lehre an Univer- sitäten und Hochschulen, in: Konstruktion – Zeitschrift für Produktentwicklung und Ingenieur-Werkstoffe, Jhrg. 2015, HeftNr. 9. - ISSN: 0720-5953.

[12] Eigner, M.; Schuh, G.; Baessler, E.; Stolz, M.; Steinhilper, R.; Janusz-Renault; G.; Hieber, M.: Management des Produktlebenslaufs. in: Bullinger, H.; Spath, D.; War- necke H.; Westkämper E.: Handbuch Unternehmensor- ganisation – Strategien, Planung, Umsetzung. 3. Auf- lage. Springer, Ber-lin/ Heidelberg 2009, S. 223-315. - ISBN 978-3-540-72136-9.

[13] Stark, R.; Kim, M.; Damerau, T.; Neumeyer, S.; Vorsatz, T.: Notwendige Voraussetzungen für die Realisierung von Industrie 4.0 – Ein Beitrag aus der Sicht der Indus- triellen Informationstechnik, in: “ZWF Zeitschrift für wirtschaftlichen Fabrikbetrieb”, Jhrg. 110, HeftNr. 3, Carl Hanser Verlag, München 2015, S. 134-141. - ISSN: 0947- 0085.

[14] Sendler, U. (Hrsg.): Industrie 4.0 - Beherrschung der industriellen Komplexität mit PLM. Springer Verlag, Berlin, Heidelberg 2013, S. 1-20.

[15] Porter, M; Heppelmann, J.: Wie smarte Produkte den Wettbewerb verändern, in: Harvard-Business-Manager – das Wissen der Besten. Jhrg. 36, HeftNr.. 12 (2014), S. 34-60. – ISSN: 0945-6570.

[16] Aurich, J.; Meissner, H.: Entwicklung cybertronischer Produktionssysteme – Vorgehen für einen integrierten Entwicklungsprozess cybertronischer Produkte und Produktionssysteme. ZWF 109 (2014) 1-2, S. 70-73.

[17] Aurich, J.; Gülsüm, M.: Produkt-Service-Systeme für Werkzeugmaschinenhersteller, in: “ZWF Zeitschrift für wirtschaftlichen Fabrikbetrieb”, Jhrg. 110, HeftNr. 4, Carl Hanser Verlag, München 2015, S. 177-181. - ISSN: 0947-0085.

[18] Fischer, J.: Licht ins Dunkle – PLM verstehen heißt Lebenszykluseffekte (er)kennen, in: “ZWF Zeitschrift für wirtschaftlichen Fabrikbetrieb”, Jhrg. 110, HeftNr. 1-2, Carl Hanser Verlag, München 2015, S. 36-39. - ISSN: 0947-0085.

[19] Terzi, S.; Bouras, A.; Dutta, D.; Garetti, M.; Kiritsis, D.: Product Lifecycle Management – from its History to its New Role. Int. J. PLM, 4 (2010) 4, pp. 360-389.

[20] Eigner, M.; von Hauff, M.; Schäfer, P.: Sustainable Product Lifecycle Management, in: Hesselbach J., Herrmann C. (Hrsg.): Glocalized Solutions for Sustain ability in Manufacturing, Springer, Berlin, Heidelberg 2011, S. 501-506.

[21] Eigner, M.; Stelzer; R.: Product Lifecycle Management – Ein Leitfaden für Product Development und Life Cycle Management. 2. Aufl., Springer Verlag, Berlin, Heidel- berg 2009.

[22] Eigner, M.; Geissen, M.: “System Lifecycle Management – am Beispiel einer nachhaltigen Produktentwicklung”, in: “Smart Engineering - ProSTEP iViP Symposium 2015”, Stuttgart, Deutschland, 05. - 06. Mai 2015, Kessler Druck, Böblingen, 2015, S. 48. - ISBN: 978-3-981-2226-5-4.

[23] Paredis, C.: Why Model-Based Systems Engineering? - Benefits and Payoffs. 4. PLM Future Tagung, Mannheim 2012.

22


[24] Eigner, M.; Faißt, K.-G.; Apostolov, H.; Schäfer, P.: “Kurzer Begriff und Nutzen des System Lifecycle Man- agement – im Kontext von Industrie 4.0 mit Industrie 4.0 und Internet der Dinge und Dienste”, in: “ZWF Zeitschrift für wirtschaftlichen Fabrikbetrieb”, Jhrg. 110, HeftNr. 7-8, Carl Hanser Verlag, München 2015, S. 475-478. - ISSN: 0947-0085. [25] mecPro² Projektunterlagen, www.mecpro.de

[26] Gilz, T.; Eigner, M.: Ansatz zur integrierten Verwen- dung von PLM Modellen in PLM zur Beschreibung der funktionalen Produktarchitektur. In (Maurer, M.; Schul ze, S.-O. Eds.): Tag des Systems Engineering. Carl Hanser Verlag GmbH & Co. KG, München, 2013; pp. 293–302.

[27] Pfenning, M.; Muggeo, C.: „Die Rolle von MBSE und PLM im Industrie 4.0“, in: Schulze, S.; Muggeo, C. (Hrsg.): Tag des Systems Engineering, Hanser Verlag, München 2015, S. 279-287. – ISBN: 978-3-446-44729-5

[28] Mauerer, J.: „Safety und Security: Sicherheit bei vernetzten Industrieanlagen“, Computer Woche, 1.10.2015

[29] Tenor, J.: IoT´s Impact on the Business of Engineering, Research Report, Perceptive Analysis 2016

[30] Europa Lehrmittel: Technisches Zeichnen, Technische Kommunikation, Grund- und Fachbildung Metall, 9. Auflage, 2006

[31] Schichtel, M.: „Produktdatenmodellierung in der Praxis“, Hanser Verlag, München, 2002.

[32] Zagel, M.: Übergreifendes Konzept zur Strukturierung variantenreicher Produkte und Vorgehensweise zur iterativen Produktstruktur-Optimierung, Promotion Lehrstuhl VPE, TU Kaiserslau-tern, 2006

[33] Schuh, G.: Produktkomplexität managen. Strategien ; ‘ Methoden ; Tools. Carl Hanser Fachbuch-Verlag, 2014

[34] Rüßmann, M.; Lorenz, M., Gerbert P. et al.: Industry 4.0: The Future of Productivity and Growth in Manufac- turing Industries. The Boston Consulting Group, 2015

[35] VDI Wissensforum : 2. VDI-Fachtagung „Industrie 4.0“. 28. und 29. Januar 2015 - Düsseldorf

[36] Crnkovic, I.; Asklund, U.; Dahlqvist, A. P.: Implementing and integrating product data manage ment and software configuration management. Boston: Artech House , 2003

[37] Ernst, J.: Phasen- und Systemübergreifendes Werkzeug zum Management technischer Änderungen, Promotion Lehrstuhl VPE, TU Kaiserslautern, 2016

[38] Innovation & Results – Plattform und Modulstrategie – 2011 - http://www.irman.de/glossar/modularitaet/

[39] ID Consult GmbH – Metus Software - https://id-consult. com/metus/metus-software

[40] Swisscom - http://ict.swisscom.ch/wp-content/uploads /2013/03/MCC.png

23

Über Siemens PLM Software

Siemens PLM Software, eine Business Unit der Siemens Digital Factory Division, ist ein führender, weltweit tätiger Anbieter von Software, Systemen und Dienstleistungen für das Product Lifecycle Management (PLM) und das Management von Produktionsvorgängen (MOM) mit über 15 Millionen lizenzierten Anwendern und mehr als 140.000 Kunden in aller Welt. Siemens PLM Software mit Hauptsitz in Plano, Texas, stellt in enger Zusammenarbeit mit seinen Kunden Industriesoft-ware-Lösungen bereit. Sie unterstützen Firmen weltweit dabei, ents-cheidende Innovationen in die Realität umzusetzen und so einen nachhaltigen Wettbewerbsvorteil zu erzielen. Weitere Informationen über die Produkte und Leistungen von Siemens PLM Software unter www.siemens.com/plm.

Siemens Industry Software GmbH Franz-Geuer-Str. 10 50823 Köln +49 221 20802-0

Österreich Siemens Industry Software GmbH Wolfgang-Pauli-Strasse 2 4020 Linz +43 732 377550

Schweiz Siemens Industry Software AG Freilagerstrasse 40 CH-8047 Zürich +41 44 755 72 720

© 2016 Siemens Product Lifecycle Management Software Inc., Siemens und das Siemens-Logo sind eingetragene Marken der Siemens AG. D-Cubed, Femap, Fibersim, Geolus, GO PLM, I-deas, JT, NX, Parasolid, Solid Edge, Synchrofit, Teamcenter und Tecnomatix sind Marken oder eingetragene Marken der Siemens Product Lifecycle Management Software Inc. oder ihrer Niederlassungen in den USA und in anderen Ländern. Alle anderen Logos, Marken, eingetragenen Marken oder Dienstleistungsmarken sind Eigentum der jeweiligen Inhaber.

60750-A16 12/16 DE

Smarte Produkte erfordern ein Umdenken bei ... · Ein gutes Beispiel hierfür ist das Automobil,...

Documents

Transcript of Smarte Produkte erfordern ein Umdenken bei ... · Ein gutes Beispiel hierfür ist das Automobil,...