smart engineering - Industrie 4.0 aus einer Hand

FachbeiträgePLM versus PPS

Zukünftige Lösungen für ein durchgängiges Produkt- und Prozessmanagement
sep
sep
sep
sep
Fachbeiträge: PLM versus PPS
Statistiken der letzten Jahre belegen den permanenten Wandel des Produktentwicklungsprozesses (PEP). Die Einflüsse resultieren aus veränderten Marktbedingungen, aus neuen Anforderungen an das Produkt und aus Kundensicht. Der Anstieg der Produktkomplexität resultiert zum einen aus einer weitaus stärkeren „multi market“ – fähigen Produkt- und Variantenvielfalt und zum anderen aus der ständigen Zunahme elektronischer Komponenten und der zugehörigen „embedded software“ (Mechatronik). Der wertmäßige Anteil an Elektronik und Software ist in den letzten Jahren ständig gestiegen und liegt etwa im Fahrzeugbau bei circa 40 Prozent. Außerdem führt die zunehmende Globalisierung innerhalb der Wertschöpfungskette sowohl innerhalb der OEM´s als auch zwischen OEM´s und ihren Zulieferern zu komplexeren, vernetzten Arbeitsorganisationen und Prozessen. Die Anforderung bereichsübergreifender Kommunikation zwischen allen Beteiligten über verschiedene Kulturräume und Zeitzonen gewinnen immer mehr an Bedeutung.
Anzeige

Daraus leiten sich neue Handlungsbedarfe an Methoden und IT-Lösungen für den Produktentwicklungsprozess ab. Diese basieren darauf, die Engineering Tätigkeiten über den gesamten Produktlebenszyklus, das heißt von der frühen Phase der Anforderungsaufnahme bis hin zum Recycling, über alle Disziplinen wie Mechanik, Elektrik/Elektronik, Software und Dienstleistungen und über die Bereichsgrenzen eines Unternehmens hinaus, organisatorisch und systemtechnisch zu unterstützen, wie Bild 1 zeigt.

Dabei spielt die Definition und Verfolgung verschiedener Produktkonfigurationen entlang des Lebenszyklus eine wesentliche Rolle. Auf der IT-Ebene werden moderne Autoren-Systeme (MBSE – Model Based Systems Engineering), CAD-, CAM- und CAE-Systeme) sowie die entsprechenden Simulations- und Visualisierungstechniken eingesetzt. PLM-Lösungen (Product Lifecycle Management) bilden in der Regel dabei den funktionalen und administrativen Backbone für die Informationsmenge, die von der ersten Idee bis zur Konstruktionsstückliste anfällt. Die dann folgenden produktions- und logistikbezogenen Informationen werden in Produktionsplanungs- und -steuerungssystemen verwaltet.

Produktmodell und Prozessmodell

Um PLM zu verstehen, müssen zunächst die wesentlichen Kernkomponenten betrachtet werden. Dies sind: das Produktmodell und das darauf basierende Produktdaten Management und das Prozessmodell und das darauf basierende Prozess Management.
Produktmodelle haben die Zielsetzung, Produkte mit ihren für den gesamten Lebenszyklus relevanten Informationen abzubilden. Ein Produktmodell besteht aus den Komponenten Produktstammsatz, der auf der Attributebene unter anderem durch eine identifizierenden Nummer, eventuell einer Klassifikation, einen Änderungsstand (Revision oder Version) und einer Benennung gebildet wird, sowie einer Produktstruktur und den dazu gehörigen Dokumenten. Produktstrukturen werden in den verschiedenen Phasen des PEP´s differenziert aufgebaut. Die Produktstruktur ist das zentrale Instrument zur Unterstützung der Informationshandhabung und der Prozessgestaltung. Die in Bild 2 dargestellte Abbildung zeigt verschiedene Formen der Produktstruktur in den entsprechenden Phasen des Produktlebenszyklus. Diese „flache“ Struktur sieht in der Realität weitaus komplexer aus, denn sie vereinigt Funktionen und Komponenten aus verschiedenen Disziplinen und jede Komponente ist wiederum mit Fertigungs- und Montageressourcen und mit den entsprechenden Prozessen verknüpft. Im Rahmen eines vollständigen Konfigurationsmanagements müssen diese ganzen Verbindungen der technischen Objekte bei Änderungen verfolgt und dokumentiert werden.

Das Prozessmodell in dem hier vorliegenden Umfeld der Produktentstehung beschreibt die Abbildungen von technischen / organisatorischen Geschäftsprozessen. Man unterscheidet langfristig stabile Prozesse, zum Beispiel das Prüf-, Freigabe-, Änderungs- und Verteilwesen, die in der Regel im Qualitätshandbuch beschrieben werden. Diese Prozesse haben juristische Auswirkungen etwa auf die Produkthaftung, die elektronische Unterschrift und die Originalität des Dokuments. Prozesse werden meistens graphisch durch Zustands- (Status) und Übergangs- (Transitions) Diagramme dargestellt.

Konfigurationsmanagement

Kombiniert man das Produkt- und Prozessmodell so erhält man automatisch den Prozess des Konfigurationsmanagements (KM), das alle Informationen nach Inhalt, Status oder Revisionen organisiert. Durch Anwendung dieser Regeln, Beziehungen und Kontrollmechanismen werden die Einflüsse von Änderungen am zu verwaltenden Produkt automatisch verfolgt. Innerhalb des Modells ist somit beschrieben: Wo welches Teil verwendet wird, wer es entwickelt, hergestellt und geliefert hat und wer eine Änderung initiiert oder zu verantworten hat. Außerdem wann diese Änderung durchgeführt wurde, wann sie in die Produktion eingelaufen ist und warum diese Änderung durchgeführt wurde.

Die Identifizierung eines Bauzustandes erfolgt über die so genannte Effectivity. Diese stellt den Gültigkeitsbereich der zu konfigurierenden Produktkomponenten und Dokumente dar und bestimmt sich je nach Anwendungsfall aus dem Datum oder der Revision (vorwiegend Konsumgüter beziehungsweise Produkte in großen Stückzahlen) oder zusätzlich aus der Seriennummer, einer fortlaufenden Nummer für jedes hergestellte Erzeugnis, Baugruppe oder Einzelteil (vorwiegend für Investitionsgüter in Kleinserie im sicherheitsrelevanten Bereich, wie etwa in den Industrien Aerospace, Transportation, Defense).

Das Konfigurationsmanagements erlaubt jederzeit die Ableitung eines beliebigen Entwicklungs-, Fertigungs-, Auslieferungs- und Betriebszustandes. Es ist unverkennbar, dass das Konfigurationsmanagement sehr stark auf einem konsolidierten Aufbau der Strukturen des Produktes und des Produktionssystems aufbaut (BOM Centric Approach). Wesentliche Elemente und somit auch Anforderungen an eine Implementierung sind die Verbindung der Lebenszyklen über assoziative Produktstrukturen (Assoziativität) und die Ableitung von Sichten für verschiedene Anwendungen (View Konzept), siehe Bild 3.

Die verschiedenen Produktstrukturen liegen oft in isolierten Altsystemen, wie etwa in RM (Requirement Management), PDM (Produktdaten Management), MPM (Manufacturing Process Management), PPS und ASM (After Sales Management) vor. Oder sie werden wie die funktionale Struktur überhaupt nicht eingesetzt. Überwiegt im Produktspektrum der Bereich Software und Elektronik, so werden häufig Lösungen des Modellbasierten Systems Engineering (MBSE) für die beiden ersten Phasen Requirements und Concept eingesetzt. Moderne PLM Ansätze sind heute in der Lage, Produktstrukturen von den Anforderungen bis zu den Prozessen sowohl hierarchisch als auch durch netzwerkartige Ansätze des Systems Engineering in einer einheitlichen und gemeinsamen Datenbasis zu verwalten. Damit wären weitgehend assoziative Produktstrukturen in einer „erzeugenden“ (PLM / Design Chain) und in einer „ausführenden“ Systemwelt (PPS / Supply Chain) zu erzielen. Voraussetzung ist eine intelligente Kopplung zwischen PLM und PPS. In der Industrie gibt es genügend Beispiele der Verknüpfung der Produktdatenmodelle. Kritisch ist die Verknüpfung der typischen Engineering Prozesse Freigabe, Änderung uns Konfiguration.

Single Source of Truth

Auf der Basis der Vernetzung von Informationen durch assoziativen Produktstrukturen, beziehungsweise intelligent integrierte Altsysteme und durch geschickte Attributierung können sich die Anwender verschiedene Sichten generieren lassen. So könnte beispielsweise eine Abbildung von Anforderungen auf Funktionen, Zuordnungen von Entwicklungsstrukturen und zugehörigen Betriebsmitteln und Ersatzteile erfolgen.

Sowohl Assoziativität als auch die Sichtenbildung unterstützen das Konzept „Single Source of Truth“, das bei einem Produkt Lifecycle übergreifenden Änderungs- und Konfigurationsmanagement die absolute Voraussetzung ist. Eine Änderung einer produkt- oder produktionsrelevanten Information muss alle damit zusammenhängenden Informationen über den gesamten Lebenszyklus erkennen um Entscheidungen über abhängige Folgeänderungen zu unterstützen. Zum Beispiel hat die Änderung eines Spritzgussteils Auswirkungen auf die Änderungen an dem Werkzeug zur Folge, oder die Änderung einer Bedienerführung hat Auswirkungen auf die technische Dokumentation und das Benutzerhandbuch.

Der typische Ansatz stellt eine industrielle implementierte IT-Architektur mit der Zielsetzung eines integrierten Engineering Change Managements (ECM) und ein darauf aufbauendes Configuration Management (CM) dar. Gekennzeichnet ist dieses Konzept durch die vier Ebenen:

Autoren-Systeme (MBSE, MCAD, ECAD, CASE, CAP, CAM, Office) und Berechnungs- und Simulationssysteme

Team Data Management (TDM), eine Verwaltungsebene, die autorensystemnahe Informationen verwaltet

Engineering Backbone, die zentrale Ebene des PEP, die die mechatronische Produktstruktur mit allen zugehörigen Dokumenten – in der Regel in neutralen Formaten – enthält. Darauf baut das entwicklungstechnische Änderungs- und Konfigurationsmanagement auf.

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

Produkte und Prozesse in einer IT-Lösung!

Das Hauptproblem dieser Architektur liegt häufig in der Abstimmung von Informationen und Prozessen zwischen der durch PLM bestimmten Design Chain und der durch PPS bestimmten Supply Chain. Hinzu kommt, dass PPS-Systeme nicht die notwendig flexible Gestaltungsmöglichkeiten zur firmenspezifischen Adaption sowohl des Produkt- als auch des Prozessmodells besitzen und somit häufig eine gemeinsame Prozessgestaltung auf dem kleinsten gemeinsamen Nenner und nicht auf dem Optimum basiert. Häufig ist eine Revisionierung der Produktstammsätze in MRP-Systemen nur über die zugeordneten Dokumente möglich.

Gerade der letzte Punkt führte in einigen führenden Unternehmen zu einer Architekturdiskussion, die von einer gemeinsamen Produktstruktur, ECM- und CM-Backbone sowohl für die Design als auch für die Supply Chain ausgeht. Die verschieden instanziierten PPS-Systemen, werden zu reinen Exekutionssystemen, die ihre Informationen aus dem Backbone beziehen.

Die Rechtfertigung dieser Lösung liegt zum einen in der vollständigen Erfüllung der Vision der „Single Source of Truth“ durch eine gemeinsame Datenbasis und zum anderen durch die Leistungsfähigkeit und Flexibilität moderner IT-Basistechnologien (SOA, Web-Services et cetera), die die immer komplexer werdenden Produkte und Prozesse in einer IT-Lösung abbilden müssen. Das PLM-System wird auf einen schlanken Backbone reduziert, das alle Produkt- und Prozess-relevanten Informationen abbildet und den TDM- und PPS-Applikationen zur Verfügung stellt. Auf der Backbone-Ebene werden alle Dokumente in neutralen transparenten und archivierbaren Formaten verwaltet. Intelligente Engineering und Production Clients setzen darauf auf und stellen den Ingenieuren rollengerechte Informationen zur Verfügung. Bei einer Normung der Schnittstellen zum Backbone könnten ganz neue Geschäftsmodelle für Lösungsanbieter für Applikationen entstehen. Das ist natürlich ein Traum, aber ohne Träume keine Innovation!

Die aktuelle Systemlandschaft und die Interessen der Systemanbieter stehen dem diametral entgegen. Es wäre auch ein radikaler Sinneswandel, der gewaltige Anfangsinvestitionen in der Industrie nach sich ziehen würde, so dass man sich wohl mit Ersatzlösungen zufrieden geben müssen. Diese werden momentan unter dem Stichwort „Engineering Client“ im Automobil- und Flugzeugbau diskutiert. Bild 4 zeigt einen Ansatz der am Lehrstuhl VPE der TU Kaiserslautern entwickelt wurde.
Das Engineering Network (EN) ist ein multidisziplinäres Repository für Engineering Objekte (EO) und Prozesse (EP), das die Altsysteme über gemeinsame Metadatenmodelle logisch verknüpft. Dieser Ansatz ist in einfacherer Form unter Enterprise Application Integration (EAI) bekannt. Damit ist es möglich, dem Ingenieur beliebige rollen- und anforderungsspezifische Informationen zusammenzustellen, ohne dass dieser Rücksicht auf die Herkunft und Verteilung der Informationen nehmen muss. Natürlich wird die Bedienung des Engineering Clients sowohl neue Formen des Interaktionsdesigns als auch neue, insbesondere mobile Geräte berücksichtigen. Diese Lösung darf aber nicht darüber hinweg täuschen, dass sie nur eine, allerdings wesentliche Anforderung des Ingenieurs erfüllt: den Zugriff auf ein interdisziplinäres und föderiertes Produktmodell. Eine Integration der Prozesse über die Design und Supply Chain ist damit noch nicht automatisch gegeben. -sg-


Prof. Dr. Martin Eigner,

Lehrstuhl für Virtuelle Produktentwicklung (VPE), TU Kaiserslautern

Technische Universität Kaiserslautern, Kaiserslautern Tel. 0631/205-3871, http://www.mv.uni-kl.de

Diesen Artikel …
sep
sep
sep
sep
sep

Weitere Beiträge zum Thema

PLM: Branchenorientierte Produktstrukturen für PLM - Teil 2

PLMBranchenorientierte Produktstrukturen für PLM - Teil 2

Historisch gesehen waren PDM-Projekte in den 80er Jahren durch die Verwaltung von technischen Dokumenten in Verbindung mit CAD geprägt. In den 90er Jahren wurden die Dokumente mit den Stamm- und Strukturdaten verknüpft.

…mehr
PLM: Branchenorientierte Produktstrukturen für PLM - Teil 1

PLMBranchenorientierte Produktstrukturen für PLM - Teil 1

Historisch gesehen waren PDM-Projekte in den 80er Jahren durch die Verwaltung von technischen Dokumenten in Verbindung mit CAD geprägt. In den 90er Jahren wurden, die Dokumente mit den Stamm- und Strukturdaten verknüpft.

…mehr
PLM Future Tagung

FachtagungPLM Future Tagung in Kaiserslautern

„Industrial Internet - Umsetzungsstrategien, IT-Architekturen und Standardisierung“ lautet das Motto der 8. PLM Future Tagung, die vom 4. bis 5. Oktober 2016 in Kaiserslautern stattfindet.

…mehr
PLM Symposium

PLM SymposiumIndustrie 4.0 und IoT treffen PLM

Am 26. Juli 2016 findet das erste Münchner PLM Symposium im Zentrum von München in den Räumen der Hochschule München statt.

…mehr
PLM: Systemübergreifendes Änderungsmanagement zwischen PLM und ERP

PLMSystemübergreifendes Änderungsmanagement zwischen PLM und ERP

Ganzheitliches Änderungsmanagement zieht sich durch den kompletten Lebenszyklus eines Produktes. Um alle Informationen zu berücksichtigen, muss auf eine Vielzahl verschiedener Softwaresysteme zugegriffen werden.

…mehr
Anzeige
Anzeige

Anzeige - Highlight der Woche

COSCOM Digital-PROZESS Meetings

Einladung zu COSCOM Digital-PROZESS Meetings

Mehr Profit vor dem Span! COSCOM connected …

… Manufacturing: CNC-Prozesse optimieren!

… Tool-Management: Rüstprozesse beschleunigen!

… Prozess-Management: Durchgängige Daten bis an die Maschine!

Aktuelle Termine und Orte hier

Anzeige - Highlight der Woche

Aras Whitepaper: Internet of Things - Kontext statt Chaos


Hier stellt Ihnen das Unternehmen Aras das Highlight der Woche vor.

White Paper jetzt kostenlos herunterladen!

Mediadaten 2018

Anzeige

White Papers auf smart engineering


In unserer neuen White Paper Sektion finden Sie lösungsorientierte White Paper unserer Partner zu IT-Standards, Anwendungshinweisen, Leistungsübersichten uvm. Jetzt kostenfrei downloaden.

Künstliche Intelligenz: Forschungsroboter “Roboy“ und Martina Mara

Video- Künstliche Intelligenz: Forschungsroboter “Roboy“ und Martina Mara


Welche Wirkung hat der Anblick von Robotern auf Menschen? Mit dieser Frage befasst sich das Team um Professor Markus Appel vom Campus Landau in einem aktuellen Forschungsprojekt. Mit ihrer Studien wollen die Forscher herausfinden, inwieweit wir Menschen künstliche Intelligenz als helfende Hand im Alltag akzeptieren oder ablehnen.

smart engineering in Social Networks

smart engineering Newsletter

smart engineering Newsletter kostenfrei abonnieren

Unser Newsletter informiert Sie über die wichtigsten Neuigkeiten, Produktentwicklungen und Trends aus der Branche. Jetzt kostenlos registrieren.

SCOPE Newsticker