PLM – Quo Vadis?

Dirk Spindler, Schaeffler AG
Martin Eigner, Lehrstuhl VPE Kaiserslautern

Einleitung

Die Entwicklung innovativer mechatronischer und cybertronischer Systeme wird mehrere Konsequenzen nach sich ziehen: ein Überdenken heutiger Konstruktionsmethoden im Sinne interdisziplinärer und integrierter Produktentwicklung, Engineeringprozesse, IT-Lösungen und Organisationsformen. Zugrunde liegt die Forderung nach durchgängigen Prozessketten basierend auf digitalen Modellen in der Produktentwicklung, Produktionsplanung, Produktion und Service. Planungs- und Entwurfsmethoden aller Disziplinen – Mechanik, Elektronik und Software – müssen auf den Prüfstand gestellt und auf ihre Tauglichkeit für ein neues Vorgehensmodell der Produkt- und Serviceentwicklung überprüft werden, um diese in einen gemeinsamen, integrierten und interdisziplinären Methoden-, Prozess- und IT-Lösungsansatz zu überführen. Dieser Ansatz der digitalisierten Produktentwicklung wird Engineering 4.0 genannt [1,2]. Die Grundlagen bilden Methoden des „Systems Engineering“ (SE) [3] und des „Model Based Systems Engineering“ (MBSE) [4]. Im Zentrum dieser Veränderungen in der Produkt- und Prozesswelt stehen einerseits vollständig neue Anforderungen an Produkte [5,6,7] und dienstleistungsorientierte Geschäftsmodelle sowie andererseits neue IT-Technologien und Standards (Big Data, 3D-Druck, OSLC/ REST/RDF,…), die die Umsetzung dieser Anforderungen erst ermöglichen. Die Digitalisierung der Produkte und der Produktentwicklung bedeutet einen Transformationsprozess, der die klassischen Grenzen einer fragmentierten und konkurrierenden IT-Lösungswelt neu ordnet. Ein durchgängiger, leichtgewichtiger und föderierter Engineering-Backbone wird die Rolle der Daten- und Prozessintegration zwischen der Produkt- und Produktionsentwicklung, der Produktion/Fertigung und Montage sowie dem Service einnehmen.

Ist Stand und Zukunftschancen von PLM Implementierungen

Im Zentrum der aufgeführten Veränderungen in der Produkt- und Prozesswelt steht Product Lifecycle Management als Skelett eines durchgängigen digitalisierten Produktlebenszyklus (PLZ), das über alle Disziplinen, über verteilte Standorte sowie über die gesamte Zulieferkette die Basis für ein digitales Produkt-, Produktions- und Prozessmodell bildet. Als durchgängiges Rückgrat wird ein auf PLM basierender Engineering Backbone die Rolle der Daten- und Prozessintegration zwischen der Produkt- und Produktionsentwicklung, der Produktion/Fertigung und Montage sowie dem Service einnehmen. Die Komplexität heutiger PLM-Architekturen und Einführungsstrategien ist bereits sehr hoch und die zu erwartende weitere Zunahme durch cybertronische Produkt- und Produktionssysteme wird diesen Trend verstärken. Die Nachvollziehbarkeit und Rekonfigurierbarkeit nach ISO 9001 über den gesamten Produktlebenszyklus, über die Disziplinen und die Lieferkette muss jederzeit gewährleistet sein, um den Engineering Prozess zu beherrschen und zu dokumentieren. Im diametralen Gegensatz zu diesen visionären Zielen steht der aktuelle Einführungsstand in der Deutschen Industrie. Die Automobilindustrie ist sicher ein Vorreiter bei der Implementierung und hat viele Technologietrends mitgeprägt. Aber auch hier sind die bisher implementierten PLM Projekte weit entfernt von obiger Zielsetzung. Heutige PLM Implementierungen sind häufig auf Grund deutscher Übergründlichkeit total übercustomisiert (Bild1). Dies bedeutet eine hohe Anfangsinvestition, aber weitaus kostenintensiver ist das permanente Nachziehen der customisierten PLM Lösung bei Auslieferung einer neuen PLM Basisversion.

Bild 1: Beispiel einer „Übercustomisierung“

Typisch für Anwendungen in großen Unternehmen sind über 100 fragmentierte TDM/PDM und Autorensysteme sowie Excel und andere „hidden DB´s bzw. Shadow IT“, teils historisch gewachsen teils auf der Basis von M&A. Harmonisierungsversuche scheitern am Widerstand der Anwender und an der Unkenntnis des Managements über Details der Anwendungslösung. Ein voll integrierter Engineering Backbone als Basis der Engineeringprozesse war anfangs eventuell die Vision, die Realität zeigt einen Schwerpunkt in der Phase der Entwicklung und Konstruktion und der Verwaltung von M-CAD Daten. Anforderungen, Systemarchitekturen, Simulationen, Elektronik und insbesondere Software sind i.d.R. nicht in die Produkt- und Prozessstruktur integriert
Ansätze wie „bimodale IT“ (Gartner, 2016) oder „Digital PLM“ (Accenture, 2016) deuten in ähnlicher Weise wie SysLM [8,9] die Notwendigkeit einer Evolution. Überträgt man diese Ansätze auf PLM ergeben sich folgende Anforderungen:

• Von Dokument- zu Modell-basiert.
• Abbildung von hierarchischen- (herkömmlichen Stücklisten der Hardware) bis hin zu Netzwerk- (Systemarchitekturen) und linearen Strukturen (Software).
• Von monolithischen zu föderierten und leichtgewichtigen Systemen, die auf referenzierte bzw. verlinkte Daten aufbauen. Die dazu notwendigen IT-Technologien sind Repository-Technologien und die typischen WEB Standards REST, RDF, OSLC….
• Bereitstellung der PLM Lösung auf unterschiedlichen Cloud-Leveln (IaaS, PaaS und SaaS)
  Unterstützung der typischen Engineering Prozesse wie z.B. Engineering Change Management (ECM) und Configuration Management (CM) für Mechanik, Elektrik / Elektronik und Software sowie Ableitung von Digitalen Zwillingen bzw, Digital Twins für Einsätze im Prototypenbau, in Produktion und im operativen Betrieb ( Grundlage für Service-orientierte Geschäftsmodelle).
• Agile Einführung und betriebliche Anpassung durch überwiegend interaktive Konfiguration anstatt durch prozedurales Customizing.
• Automatischer Übernahme aller betrieblicher Anpassungen (Konfiguration und Customizing!) bei Upgrade des Basissystems.
• Neue flexible Geschäftsmodelle auf Basis von Subscriptions anstatt Lizenzen.

Die drei letzten Punkte führen zu einem signifikanten Rückgang der Total Cost of Ownership (TCO) bei der Beschaffung und Implementierung eines PLM/SysLM Systems. Bimodale Systeme bieten durch ihre Agilität und Flexibilität die optimalen Voraussetzungen für eine erfolgreiche Digitalisierung der Engineering Prozesse.

Die Digitalisierung, d. h. die vollständige Beschreibung eines Produktes in Form „digitaler Modelle“, und darauf aufbauende Engineering-Prozesse ( Freigabe, Änderung und Konfiguration) beginnen bereits in den ganz frühen konzeptionellen Phasen des PLZ (Bild 2).

 

Bild 2: Das Digitale Modell entlang des Produktlebenszyklus verteilt auf Autorensysteme, Team Data Management (TDM) und SysLM Backbone

Grundlage der Digitalisierung ist das Model-Based Systems Engineering (MBSE), ein multidisziplinäres Paradigma für eine neue interdisziplinäre und integrierte Konstruktionsmethodik. Es propagiert die Nutzung von Modellen anstelle von Dokumenten und somit wird die integrierte Analyse, Spezifikation, Entwicklung und Absicherung der zu entwickelten Produktsysteme unterstützt. Diese Durchgängigkeit entlang des Lebenszyklus eines Produktsystems und über einzelnen Disziplinen hinweg gestattet die Vernetzung aller Entwicklungsergebnisse. Die konzeptionelle Produktbeschreibung, die im Wesentlichen aus Funktion, Logik und Verhalten besteht, kann auf diese Weise als Brücke zwischen Anforderungen 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 Konfigurationsmanagement basieren dann auf einem einheitlichen und durchgängigen digitalen Produkt- und Produktionsmodell.
Zwischen den Ebenen und den PLZ Phasen liegen vielfältige Formen der Kommunikation vor. Bei der digitalen Modellierung werden zwei Begriffe unterschieden: das auftragsneutrale Digitale Modell (das sogenannte 150% Modell) und der daraus abgeleitete i.d.R. auftragsspezifische und instanziierte Digitale Zwilling.
Engineering Prozesse basieren 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 geeignete IT-Architektur in einen gemeinsamen Produkt- und Prozessbackbone eingebunden werden. Gekennzeichnet sind diese Konzepte durch vier IT- 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 (z.B. native Formate) und die direkt den Autorensystemen zugeordnet sind. TDM Systeme haben bereits ein mehr oder weniger intelligentes Versionsmanagement.
• Engineering Backbone, die zentrale Ebene des Produktlebenszyklus, die die interdisziplinären Produktstrukturen entlang des PLZ mit allen zugehörigen Dokumenten – in der Regel in neutralen Formaten – enthält. Darauf baut das Engineering-orientierte Freigabe-, Änderungs- und Konfigurationsmanagement auf.
• ERP Backbone, der bei einem global agierenden Unternehmen meist aus mehreren lokalen Instanzen und häufig verschieden angepassten PPS/ERP Systemen besteht. Auf dieser Ebene wird heute der logistische und produktionstechnische Teil des Änderungs- und Konfigurationsmanagements umgesetzt.

Bild 3 stellt diesen theoretischen Ansatz einer mehrstufigen IT-Architektur dar.

Bild 3: Abbildung des Digitalen Modells auf eine IT Architektur basierend auf dem VDA Vier-Ebenen Ansatz

Dabei wurde berücksichtigt, dass sich in den letzten Jahren verschiedene IT-Lösungskombination entwickelt haben. Die typischen CASE Tool Anbieter haben Ihre Lösungen um Requirements Management (RM) und SysML 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 Lebenszyklusphase eines Produkts.
Als eine erste Umsetzungsstufe bietet sich eine eher evolutionäre Lösung durch Auslagern der übergreifenden Prozesse (ECM und CM) in einen übergeordneten passiven Engineering Backbone an, Dies kann zum Beispiel auf der Basis eines modellbasierten Repository eines handelsüblichen PLM-Systems umgesetzt werden, wenn das Repository bereits Möglichkeiten beinhaltet auf externe Attribute und Objekte zu referenzieren und diese in den Backbone einzubinden. Das Repository enthält eine Verlinkung über WEB-Services aller theoretisch von einer Freigabe oder Änderung betroffenen Elemente (Configured Items) in den unteren Ebenen. Das bisherige Problem eines durchgängigen Engineering-Backbones – seine monolithische Struktur – wird in diesem Fall durch ein leichtgewichtiges föderiertes semantisches Netz gelöst. Hier ergeben sich durch intelligente Repository- und Web-Technologien neue Perspektiven. 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 betroffenen Elemente anzeigt (Affected Items), die dann in einen Folder des ECR eingetragen werden. Die Änderungsausführung (ECO) wird auf den unteren Ebenen umgesetzt. Optimal geeignet für die Anzeige sind Graphen-basierte Visualisierungslösungen. Am Lehrstuhl für Virtuelle Produktentwicklung (VPE) wurde auf der Basis der Repository Technologie des PLM Systems Aras ein Prototyp entwickelt [10], der von Aras industrialisiert wurde und zurzeit bei der Firma Schaeffler mit 20.000 Benutzern implementiert wird (Bild 4 und 5).

Bild 5: Grafische Darstellung der Affected Items aus den verschiedenen Anwendungen

Der Prototyp wird zurzeit am VPE weiterentwickelt. Auf der Basis von REST, RDF und der Aras Repository Technology sollen einerseits ein erweiterter Funktionsumfang und eine leichtere Überführung der jeweils customisierten Anwendungslösungen aus der Autoren- und TDM-Ebene in die Backbone-Ebene erzielt werden. Andererseits ist ein wesentliches Forschungsziel, auf der Basis der unternehmensspezifisch aus den Anwendungssystemen abgeleiteten RDF Semantik automatisch wiederum die REST Zugriffe auf die TDM Ebene zu generieren. Zwei Jahrzehnte nach seiner Einführung ist REST und RDF – eine der wichtigsten Technologien für Web-Anwendungen – für die Verlinkung von Engineering Artefakten entdeckt worden. Ihre Bedeutung wird weiter wachsen, zumal REST und RDF die Grundlage eines sich schnell entwickelnden Standards sind: OSLC (Open Service for Lifecycle Collaboration).

Bild 5: Zweiter Prototyp des VPE basierend auf dem ARAS Repository erweitert um REST/RDF

Für die Verwendung von RDF ergibt sich eine Reihe von Argumenten:

• Ein genereller Trend Unternehmensdatenmodelle in REST zu beschreiben,
• einfache Ableitung einer Graph-basierenden Visualisierung und
• RDF ist die semantische Voraussetzung für die Ableitung der REST-Zugriffe.

 

Umsetzung bei Schaeffler – 
Produktentstehung und Product Lifecycle-Management der Zukunft

Die zunehmende Komplexität von Produkten und Systemen und der Trend zu mechatronischen Systemen und Digitalisierung erfordern die Neudefinition einer PLM-Strategie. Dazu ist zunächst ein Zielbild notwendig, an dem sich das Vorgehen bei der Umsetzung orientiert.
In den letzten Jahrzehnten wurde PLM im Wesentlichen aus der Engineering-Disziplin betrieben. Der Nachweis einer Produktreife und damit die Nachverfolgung von Änderungsanforderungen und Produkt-Konfigurationen sowie deren Umsetzung im Rahmen eines dokumentbasierten Produktentstehungsprozesses erfolgten in sog. Product Data Management-Systemen, welche häufig ihren Ursprung in der Verwaltung von CAD-Daten hatten. Für die Verwendung in den nachgelagerten Produktions-und Logistiksystemen erfolgten teilweise manuelle Übertragungen in die entsprechenden Tools.
In der Zukunft werden Assistenzsysteme wie z.B. Konfiguratoren basierend auf Big-Data Technologien und Machine Learning Algorithmen zu zunehmender Automatisierung im Produktentstehungsprozess beitragen und damit sowohl die Effizienz als auch die Qualität in der Produktentstehung deutlich steigern. Die immer bessere Verfügbarkeit von Daten über den kompletten Lebenszyklus werden neue Produkte und Geschäftsmodelle ebenso ermöglichen wie eine effizientere Darstellung von Standardkomponenten. Das Zielbild für die Produktentstehung der Zukunft zeigt Bild 6.

Bild 6: Produktentstehung in der Zukunft

Bei der Weiterentwicklung des Produktentstehungsprozesses wird die dokumentenbasierte Reifegradsteuerung -insbesondere bei der Entwicklung mechatronischer oder cybertronischer Systeme- von einer modellbasierten langfristig abgelöst.
Dabei ist den unterschiedlichen Entwicklungsgeschwindigkeiten der Domänen Software, Elektronik und Mechanik Rechnung zu tragen, um eine sichere Rückverfolgbarkeit der dargestellten Lösung auf die Anforderungen zu ermöglichen. Hierbei ist auch die Einhaltung aller Anforderungen von Vorgaben wie ASPICE oder Funktionaler Sicherheit in der Automobilindustrie zu beachten.
Charakteristisch für die Entwicklung mechatronischer Systeme sind die unterschiedlichen Entwicklungsgeschwindigkeiten und damit Änderungszyklen von Software, Elektronik und Mechanik Dies erfordert eine eindeutige Zuordnung der jeweiligen Version zu einer Konfiguration des Gesamtsystems (Baseline), damit die Rückverfolgung einer Anforderung bis zur dargestellten Lösung disziplinübergreifend ermöglicht wird.

Daraus ergeben sich für eine PLM-Strategie im Wesentlichen vier Anforderungen:

1. Eine unternehmensweites, alle Funktionen integrierendes Konfigurations- und Änderungsmanagement muss eingeführt werden.
2. Die große Anzahl nicht vollständig integrierter Engineering-Tools führt zu Datenredundanz (Information muss in mehreren Tools manuell gepflegt werden) und damit zu deutlich erschwerter Rückverfolgbarkeit und Fehleranfälligkeit. Das kann z.B. für die Entwicklung über einen Engineering Backbone mit Schnittstellen zu den verschiedenen Tools und einem geeigneten User Interface gelöst werden.
3. Die Kommunikation der Disziplinen Vertrieb, Entwicklung, Produktion, Logistik, Service/Aftermarket muss über eine Architektur mit Backbones der jeweiligen Disziplin gesichert werden. Dazu wird ein unternehmensweites Datenmodell benötigt.
4. Die schnelle Integration bzw. Abkopplung von individuellen Tools (z.B. Simulationstools in der Entwicklung) muss ermöglicht werden, indem Schnittstellen zwischen den einzelnen Tools möglichst vermieden werden und die Kommunikation über den Backbone erfolgt. Diese Strategie erleichtert außerdem die Absicherung der Zukunftsfähigkeit von Customisierungen der Tools.

 

PLM-Strategie der Schaeffler AG

Im Folgenden wird eine Strategie zur Umsetzung der o.g. vier Anforderungen am Beispiel des Engineering Backbones (auch Engineering Cockpit) der Schaeffler AG beschrieben.

Ein kompletter Lebenszyklus eines Produktes beinhaltet neben dem Entwicklungsanteil auch die Anteile des Vertriebs (Produktmanagement) und der Produktion bis hin zum Auslauf der Serie bzw. dem Aftermarket. In der Vergangenheit haben sich die Aktivitäten im Wesentlichen auf die Produktentwicklung, repräsentiert durch das V-Modell konzentriert, heutige Anforderungen machen aber eine engere Kommunikation über den kompletten Zyklus hinweg notwendig (Bild 7).

Bild 7: das V-Modell als Teil des Produktlebenszyklus

In einer gesamtheitlichen PLM-Strategie wird diesem Aspekt durch eine Integration der Disziplinen Vertrieb, Engineering, Produktion, Lieferkette und Service/Aftermarket über eine gemeinsame Datenstruktur, dem sogenannten „Schaeffler Semantic Information Model“ Rechnung getragen. Dieses Modell ermöglicht den verschiedenen disziplin-spezifischen IT-Systemen einen Austausch wesentlicher Informationen ohne Eingriffe in proprietäre Datenmodelle der einzelnen Tools und damit eine bereichsübergreifende Geschäftsprozesssteuerung. Zum Einsatz für die Beschreibung der Datenmodelle kommen die zuvor erwähnten Formate wie RDF.
Zusätzlich erlaubt diese Strategie die Einbindung externer Datenquellen wie z.B. Messdaten aus den Sensoren smarter Produkte zur Weiterverarbeitung mit den internen Tools (z.B. zur Berechnung der verbleibenden Lebensdauer einer Komponente auf Basis bereits bei der Auslegung eingesetzter Modelle – digital twins).
Bild 8 zeigt eine schematische Darstellung der Architektur für ein Datenmodell im Unternehmen und die Verbindung der Backbones über diese Architektur.

Bild 8: schematische Darstellung eines Datenmodells für ein Unternehmen

Dabei sind auf der untersten Ebene die Domänenspezifischen Autoren- und TDM-Systeme in grau dargestellt, welche die produktbezogenen Daten in einem neutralen Format dem jeweiligen Cockpit (Backbone) zur Verfügung stellen. Die weitere Kommunikation erfolgt dann zwischen den verschiedenen Cockpits ohne direkten Zugriff auf die Expertentools. Schnittstellen müssen so jeweils nur zwischen Cockpit und TDM-System entwickelt werden. Damit wird größtmögliche Flexibilität im Einsatz einzelner Tools erreicht und die Abhängigkeit von Monolithen reduziert. Bild 9 verdeutlicht beispielhaft für die Produktentwicklung die beschriebene Architektur mit den Autoren- TDM-Systemen und dem als Integrations-Layer eingeführten Engineering-Cockpit und seinen wesentlichen Funktionen.

Bild 9: Architektur der Engineering Tool-Landschaft mit dem Engineering Cockpit als Integrations-Layer

Im Folgenden konzentriert sich die Beschreibung auf das Engineering Cockpit mit der Aras-Technologie, andere lassen sich in ähnlicher Weise realisieren.

 

Umsetzung der PLM-Strategie im Engineering Cockpit

Bei der Entwicklung mechatronischer Systeme gilt es, die in Bild 10 dargestellten Aufgaben zu erfüllen und zu dokumentieren. Das Engineering Cockpit wird dabei als Plattform verstanden, die die Erledigung der anfallenden Aufgaben ermöglicht und dabei die Rückverfolgbarkeit aller Änderungen auf eine Anforderung sicherstellt. Alle für ein Entwicklungsprojekt relevanten Informationen stehen den berechtigen Personen im Engineering Cockpit zur Verfügung. Damit wird sowohl der Schulungs- als auch der Bedienungsaufwand für Mitarbeiter deutlich reduziert. So kann z.B. ein Mitarbeiter aus dem Einkauf über das Engineering Cockpit alle relevanten Informationen zur Einbindung von Lieferanten erhalten. Daraus ergeben sich die oben genannten 20.000 User für das Engineering Cockpit in seiner Endausbaustufe.

Bild 10: in der Produktentwicklung anfallende Aufgaben für die Entwicklungsteams

Bei der Umsetzung des Engineering Cockpits mit Hilfe der von Aras industrialisierten Technologie wurden folgende Prämissen als Ausgangspunkt definiert und werden im Rahmen eines über 3 Jahre geplanten Umsetzungsprojektes realisiert:

1. User:
   1. Jeder User sollte neben dem Engineering Cockpit max. 2 weitere Systeme nutzen (z.B. ein CAD- und das zugehörige TDM-System zur Datenverwaltung; für Schaeffler sind das PTC Creo und Windchill).
   2. Die User-Interfaces müssen konfigurierbar (rollenbasiert) und intuitiv aufgebaut sein, so dass die Produkt- oder Projektinformation auch ohne Expertenwissen in einzelnen Autorensystemen zur Verfügung steht.
2. IT:
   1. In den Autorensystemen oder dem TDM verfügbare Funktionen werden nicht im Engineering Cockpit dupliziert.
   2. Vermeidung von redundanter Datenablage, alle produktrelevanten Daten werden in den jeweiligen domänenspezifischen TDM-Systemen gehalten.
   3. Für die Disziplinen übergreifende Kommunikation des Engineering Cockpit werden notwendige Produkt- oder Projektinformationen in einem Neutralformat zur Verfügung gestellt und im Engineering Cockpit abgelegt. Damit können häufige Zugriffe auf die TDM-Systeme vermieden und die Infrastruktur entlastet werden.
   4. Die Definition einer Konfiguration (Baseline) erfolgt im Engineering Cockpit, eine mechatronische Stückliste wird beispielsweise im Engineering Cockpit erzeugt und verweist mittels Verlinkungen auf die jeweiligen Einzelkomponenten Mechanik, Software und Elektronik. Eine „physische Ablage“ der Informationen aus den Teildisziplinen in einem System erfolgt nicht.
   5. Weitere Autorensysteme müssen ohne Einfluss auf bereits vorhandene Tools integrierbar sein. Entsprechend müssen Systeme einfach zu- und abschaltbar sein. Dazu ist es erforderlich, Schnittstellen zwischen Autoren- oder TDM-Systemen „unterhalb“ des Engineering Cockpit weitgehend zu vermeiden.

 

Vorgehensweise bei der Umsetzung des Engineering Cockpit

Nachdem in der Vergangenheit große PLM-Projekte häufig an ihrer Komplexität und der Dauer der Umsetzung gescheitert sind, wurde für die Umsetzung des Engineering Cockpit ein agiler Ansatz gewählt, bei dem in kurzen Zeitfenstern (Sprints) von jeweils drei Wochen sogenannte Userstories umgesetzt werden. In diesen werden die Anforderungen an ein System aus Sicht des Nutzers beschrieben und ein besonderer Fokus auf die Bedienbarkeit der Oberflächen gelegt. Das dient dazu, die Rückmeldeschleifen zwischen Nutzer und Entwickler erheblich zu verkürzen und außerdem eine schnellere Reaktion auf Änderungen der Randbedingungen z.B. in Produktstrategien oder neuen IT-Technologien zu erlauben. Die Konzentration auf Schnittstellen zwischen dem Engineering Cockpit und den verschiedenen Autorentools statt kompletter Integration zwischen den Tools erleichtert die Implementierung zusätzlich, auch wenn die Komplexität der Schnittstellen und die Schwierigkeiten bei der Definition des Datenmodells nicht unterschätzt werden darf.
Zusätzlich erfolgt die Entwicklung der Funktionalitäten des Engineering Cockpits in zwei Strängen vergleichbar der Vorentwicklung- bzw. Serienentwicklung in der klassischen Produktentwicklung. Während in einem Strang die Umsetzung der Lösung für den Anwender erfolgt (vgl. Serienentwicklung), werden neue Konzepte oder Lösungsvorschläge im sog. Solution Lab (vgl. Vorentwicklung) erarbeitet. Nur in diesem Ansatz erprobte Lösungen werden dann in die produktive Lösung übernommen. Dieser Strang eilt entsprechend der Serienumsetzung ca. 12 Monate voraus, und erlaubt eine störungsfreie Umsetzung der späteren Produktivlösung. Positiv ist dabei außerdem die frühe Möglichkeit zur Rückmeldung durch die späteren Anwender und daraus resultierend eine höhere Akzeptanz der Lösung.

 

Literatur

[1] BMWi: Smart Service Welt II – neue Anwendungsbereiche für digitale Dienste und Plattformen
[2] M. Künzel, J. Schulz, P. Gabriel: Engineering 4.0 – Grundzüge eines Zukunftsmodells, Begleitforschung AUTONOMIK für 
 Industrie 4.0 (Hrsg.), VDI / VDE Innovation + Technik GmbH, Berlin, 2016.
[3] Systems Engineering Booklet 2016
[4] ] Eigner, M.: Das Industrial Internet. In Sendler, U.: Industrie 4.0 grenzenlos. ISBN: 978-3-662-48277-3, Springer, 2016.
[5] R. Anderl, M. Eigner, M., U. Sendler, R. Stark „Smart Engineering“, acatech DISKUTIERT. Springer, Heidelberg, 2012.
[6] acatech (Hrsg.): Kompetenzen für Industrie 4.0. Qualifizierungsbedarfe und Lösungsansätze (acatech POSITION), ISSN 
 2192-6166/ISBN 978-3-8316-4502-2, Herbert Utz Verlag, München, 2016.
[7] C. Schröder: Herausforderungen von Industrie 4.0 für den Mittelstand, Herausgeber: Abteilung 
 Wirtschafts- und Sozialpolitik, Friedrich-Ebert-Stiftung, ISBN 978-3-95861-350-8, Bonn, 2016.
[8] U. Sendler: Ganzheitliche Strategie: Systems Lifecycle Management (SysLM). www.PLMportal.org,
 Positionen aus Wissenschaft und Forschung, Jahrgang 2012
[9] M. Eigner, H. Apostolov, T. Dickopf, P. Schäfer, K.-G. Faißt.: „System Lifecycle Management – am Beispiel einer nachhalti- 
 gen 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.
[10] E. Joscha: „Systemübergreifendes Änderungsmanagement – Graph-basierte Identifikation und Visualisierung betroffener 
 Konfigurationselemente aus PLM und ERP“, Dissertation, in: Eigner, Martin (Hrsg.): „TU Kaiserslautern, Schriftenreihe 
 VPE“, Band 17, Kaiserslautern 2016. – ISBN: 978-3-95974-036-4