Vorlesung PLM Systeme in der industriellen Praxis

Transkript

1 Vorlesung PLM Systeme in der industriellen Praxis Prof. Josef Vilsmeier, Dipl.-Ing. (TU) CASSIDIAN Air Systems Seite 1 von 388

2 Vorstellung des Dozenten Einführung Professor Josef Vilsmeier, Dipl.-Ing. (TU) Geboren: 1951 Studium: Maschinenbau an der TU München Berufliche Laufbahn: Seit 1978: EADS Militärflugzeuge Werkstoffe Schwerpunkt Faserverbundwerkstoffe Strukturtechnologie Projektleitung mehrer CEC Projekte Fachberater für IT-gestützte Geschäftsprozesse PLM Projektleitung: Erfolgreiche Zusammenarbeit mit TU München itm DPD (Digital Product Definition) Manager im Eurofighter Projekt für EADS Military Aircraft 2005 Projekt mit itm Abschaffung Zeichnung 2006 Ernennung zum Honorarprofessor der TU München Seite 2 von 388

3 Danksagung für Unterstützung Die Erstellung der Unterlagen für die Vorlesung wurde unterstützt durch: PLM Team der EADS Military Air Systems Einführung SIS Siemens Information Services ProSTEP GmbH Kollegen aus PLM Projekten anderer Firmen Seite 3 von 388

4 Unterlagen für die Vorlesung Einführung 12 Termine für Vorlesungen Script steht zur Verfügung Hauptmerkmal des Layouts ist gute Lesbarkeit Farblich aufwendige, aber schlecht druckbare Bilder und Grafiken werden, soweit möglich, vermieden Anregungen zu besseren und klareren Darstellung sind jederzeit willkommen Im Laufe des Semesters können geringfügige Abweichungen zum Script vorkommen Seite 4 von 388

5 Inhalte der Vorlesung (1/2) Inhaltsverzeichnis Grundlagen PLM in der Flugzeugindustrie Einführung von PLM Methoden für die Einführung Chestra Infrastruktur / Team Mental Change Projekt Management und Controlling Prozesse Daten Beispiele für Arbeitsmethoden mit dem PLM System IT Architektur Configuration und Change Management Produktstrukturen Digital Mock-Up Seite 5 von 388

6 Inhalte der Vorlesung (2/2) Inhaltsverzeichnis Visualisierung Zeichnungsloser Prozess PLMXML Dokumenten Management Diverses Datenaustausch Ausblick und Trends Seite 6 von 388

7 Grundlagen Grundlagen Definitionen von PLM PLM Komponenten des PLM Ansatzes Struktur eines integrierten PLM Systems Typen von PLM Systemen Architektur von PLM Systemen Seite 7 von 388

8 Begriffsklärung Grundlagen PLM Product Data Management das Management von Produkt Daten steht im Fokus der Implementierung PLM Product Lifecycle Management Unterschiedlichste Produkte aus vielen Industrien Der gesamte Lebenszyklus muss unterstützt werden, von der ersten Idee bis EoL (End of Life) Das Management beinhaltet nicht nur Daten sondern auch Prozesse, vor allem Engineering Prozesse Bemerkung: Im Vorlesungsskript wird noch oft PLM verwendet, obwohl in den meisten Fällen PLM gemeint ist. Seite 8 von 388

9 PLM hat viele Ursprünge TIS PLM ZVS Grundlagen EDM CAD-DM TIM TDB CDP PHM EDB VPLM CDP CPLM CPC (nach 2000) PLM Product Lifecycle Management Quelle: Prof. Abramovici Seite 9 von 388

10 Produktlebenslauf Unterscheidung zwischen technisch-orientierten u. kaufmännischen Prozessen Planung und Steuerung sämtlicher Auftragsabwicklungsprozesse von der Angebotserstellung über die Beschaffung, Herstellung bis zum Vertrieb, Distribution und Fakturierung eines Produktes. Überwiegend betriebswirtschaftliche Aufgaben Grundlagen Operative, wertschöpfende Informationsprozesse Auftragsabwicklungsprozesse (kaufmännisch) Engineering Prozesse (technisch orientiert) Zwischen beiden Informationsprozessen gibt es Wechselwirkungen und einen Informationsaustausch. Technisch-orientierte Planung, Definition, Konzeption, Dokumentation, Simulation von Industrieprodukten und produktbezogenen Prozessen im gesamten Produktlebenslauf. Überwiegend von Ingenieuren wahrgenommen Die Engineering-Prozesse sind die Quelle der Produkt-Innovationen Quelle: Prof. Abramovici Seite 10 von 388

11 Das Engineering hat sich in den letzen Jahren dramatisch verändert Industrie-Produkte Produktdaten Grundlagen Zunahme der Funktionalität Teileanzahl / Produkt Produkttypen / Vielfalt Varianten / Produkttyp Elektronik und Softwareanteile produktbezogenen Dienstleistungen Produkt-Intelligenz (=> Smart Products) Engineering Prozesse Komplexitätsexplosion Unvorhersehbare Veränderungen Zunahme der Informationsmenge Heterogenität Dokumentation durch strengere gesetzliche Vorgaben Produktdaten Zusammenhänge Produktstruktur-Komplexität Operative IT-Systeme Höhere Komplexität Globale Verteilung Unternehmensübergreifend Durchgängige Rechnerunterstützung Beschleunigung Virtuelle Verifikation des Produktverhaltens Zunahme der unterschiedlicher Systemtypen Anzahl der Systemanbieter Systemkomplexität / Funktionskomplexität Anzahl der Systemschnittstellen Quelle: Prof. Abramovici Seite 11 von 388

12 Die enorme Zunahme der Engineering Komplexität erfordert ein effizientes Management Operative, Wertschöpfende Informationsprozesse Auftragsabwicklungsprozesse (kaufmännisch) Operative Daten datenerzeugende erzeugende Engineering Anwendungen Engineering Prozesse (technisch orientiert) Grundlagen Produkt Lifecycle Management (PLM) ist ein integrierter Ansatz bestehend aus einem konsistenten Satz an Methoden Modellen IT-Werkzeugen zum Management produktbezogener Engineering Daten Engineering Prozesse und zur Integration von Engineering-Anwendungen entlang des gesamten Produktlebenszyklus innerhalb eines Industrieunternehmens oder in Industrieverbünden (bestehend aus Produzenten, Zulieferern, Partner und Kunden). Quelle: Prof. Abramovici Seite 12 von 388

13 Komponenten des PLM - Ansatzes Integration des Datenu. Prozessmanagement Product Lifecycle Management (PLM) Basis PLM Methoden PLM-Methoden u. Modelle werden durch eine PLM-IT-Systemumgebung unterstützt Datenmanagement Prozessmanagement Grundlagen Verfügbarkeit von integrierten PLM-Meta-Daten u. -Prozessmodellen Übergreifende PLM Methoden Zentrale Verwaltung von Benutzerrechten Trennung zwischen Metadaten und Nutzdaten bei digitalen Dokumenten Integrierte PLM Metamodelle Zentrales PLM Datenarchiv Zentrale Verwaltung freigegebener digitaler Dokumente in einem Datenarchiv Quelle: Prof. Abramovici Seite 13 von 388

14 Struktur eines integrierten PLM Systems PLM-Benutzungsoberfläche Customising Basis PLM - Funktionen PLM Schnittstellen Grundlagen PLM- Anpassungsund Administrationsfunktionen Datenmanagement Datenmodellierung Datenverwaltung (Erzeugen, Ändern, Löschen, Filtern, Sortieren, Kopieren) Datensuche /Retrieval Versions-, Varianten-, Sichten- Management File-Management Datensicherung Analytics & Reporting Übergreifende PLM-Funktionen Prozessmanagement Prozessmodellierung Prozesssimulation Prozesssteuerung Prozessdokumentation Prozessvisualisierung Engineering Collaboration Mgmt. Autoren-Systeme M-CAD E-CAD CAE CASE Office LDM-System SCM/CRM Systeme Projektmanagement Systeme Collaboration- Portale Internet-Portale Marktplätze Teile- Bibliotheken Integrierte PLM Metamodelle DBMS File Management System Produkt Dokument Prozess PLM-Objekte Mitarbeiter Projekt Produktions- Ressource Produktfunktion Anforderung Techn. Produkt- Dokumentation Zentrales PLM-Datenarchiv PLM-Prozesse Freigabeprozesse Änderungsprozesse Allgemeine Routineprozesse WFMS Langzeit-Archivierungs-System Seite 14 von 388 Quelle: Prof. Abramovici

15 Typen von PLM-Systemen PLM-Systemtypen Merkmale Beispiele Grundlagen ERP-nahe PLM-Systeme Engineering-nahe PLM-Systeme (Enterprise PLM) Abhängigkeit von einem ERP-System Tiefe Datenintegration mit ERP Daten Unternehmensübergreifende Integration des Änderungs- und Projektmanagements Unternehmensübergreifende Integration mit dem ERP-Dokumentenmanagement Keine sehr enge Integration mit CAx-Andwendungssystemen Unabhängigkeit von CAx- und ERP-Systemen Mittlere Datenintegration CAx- und ERP-Systemen Hohe Leistungsfähigkeit bei übergreifenden Engineering-Prozessen SAP PLM. Teamcenter Windchill CIM Database. Anwendungsnahe (lokale) PLM-Systeme (LDM Systeme) Abhängigkeit von einem oder wenigen CAx-Systemen Tiefe Datenintegration mit dem jeweiligen CAx-System Wenig übergreifende Funktionen für Engineering Prozesse PLM Link Enovia V5 Zuken E³. Quelle: Prof. Abramovici Seite 15 von 388

16 Grundsätzliche unternehmensspezifische System-Architekturen ERP-PLM-System-Architektur Unternehmensweites ERP-System Unternehmensweites PLM-System Unternehmensweites, Integriertes PLM-/ERP-System Grundlagen Integriertes Autorensystem mit lokalem Datenmanagement Lokales Datenmanagement System (LDM1) Autorensystem 1 PLM-Autoren-System-Architektur Autorensystem x Quelle: Prof. Abramovici Seite 16 von 388

17 Autoren- System- Ebene Anforderungs- Management System Lokale PLM-System- Ebene Integriertes M-CAD LDM System CASE/Software Konfiguration Management-System Übergreifende PLM-System- Ebene ERP- System- Ebene Unternehemensspezifische 4-Ebenen-PLM- Architektur ERP 1 ERP 2 ERP 3 Grundlagen Unternehmensweite PLM Plattform M-LDM E-LDM CAE-LDM Office- LDM M-CAD M-CAD E-CAD E-CAD CAE Office Anforderungs- Engineering Mechanik-Produkt- Engineering Elektrik- u. Elektronik- Entwicklung Software Entwicklung Berechnung/ Simulation Allgemeine Dokumente Mechatronik Quelle: Prof. Abramovici Seite 17 von 388

18 Überblick Unternehmensprozesse Customer PMO System Requirements Analysis Engineering System Acceptance Production ILS System Design System Integration Subsystem Requirements Analysis & Design Subsystem Integration Grundlagen SW- Implementation HW Implementation Manufacturing Equipment Mechanical Subassembly Manufacturing Integral Sub-Processes (constantly improving) Product Lifecycle Management Seite 18 von 388

19 V-Modell Verzahnung von klassischen Disziplinen und HW- und SW-Entwicklung System Requirements Analysis System Acceptance System Design System Integration Grundlagen Subsystem Requirements Analysis & Design Subsystem Integration SW- Implementation HW Implementation Manufacturing Equipment Mechanical Subassembly Manufacturing Seite 19 von 388

20 Historisches PLM in der Flugzeugindustrie In der Flugzeugindustrie wurden schon seit den 60iger Jahre IT- Systeme eingeführt (meist selbst entwickelt) um vor allem das Konfigurations- und Änderungs-Management zu unterstützen. Oft wurden Insellösungen für verschiedene Bereiche ohne jede Integration eingesetzt Fast alle Systeme waren zeichnungs- (dokumenten-) basiert Stücklistensysteme mit Matrixstückliste wurde oft verwendet Seite 20 von 388

21 Auslöser für die Einführung von PLM Systemen PLM in der Flugzeugindustrie In den 80ziger Jahren wurde in vielen Firmen daran gearbeitet eine Kopplung der einzelnen Systeme zu implementieren PLM Systeme wurden in verstärkten Umfang ab Mitte der 90ziger Jahre eingeführt Auslöser für PLM Systeme waren Einführung der 3D Geometrie Modellierung Die Pflege der Legacy Systeme wurde immer teurer Notwendigkeit der Integration auf digitaler Basis Rasante Fortschritte der Computer und Netzwerkstechnologie Immer härterer Wettbewerb in ziviler und militärischer Luftfahrt Seite 21 von 388

22 Signifikante Merkmale von PLM Projekten Boeing PLM in der Flugzeugindustrie PLM System: Teamcenter Anzahl der Benutzer: derzeit ca Hauptziele: Reduzierung Kosten Gesamtprozess durch radikales Business Process Re-engineering Reduzierung IT Systeme von 400 (Legacy, BoM, etc.) auf 4, darunter 1 PLM System Single Source für alle Produktionsinformationen Ergebnisse: Messgrößen: Produktkosten, Zeit, Defect Rate, Kundenzufriedenheit => deutliche Verbesserung Integration Entwicklung, Fertigung, Sales erreicht Defizite: Derzeit noch keine echte CAD Integration Seite 22 von 388

23 Signifikante Merkmale von PLM Projekten Airbus PLM in der Flugzeugindustrie PLM System: PRIMES (Windchill) CAD System CATIA V5 mit VPM als TDM gekoppelt Anzahl der Benutzer: Hauptziele: Ein gemeinsames PLM System für Airbus CAD Integration mit VPM (Virtual Product Manager) Digital Mock-Up Vielzahl von Tools Ergebnisse: Roll out begann mit A380 und A400M Defizite: Noch begrenzte Funktionalität Sehr rigide Implementierung Seite 23 von 388

24 Signifikante Merkmale von PLM Projekten MTU Aero Engines PLM in der Flugzeugindustrie PLM System: Teamcenter (Enterprise + Engineering) Anzahl der Benutzer: ca.7500, davon ca. 600 Lieferanten / Partner Hauptziele: Verbesserung der Wettbewerbsfähigkeit Reengineering der Entwicklunsprozesse mit Schwerpunkt Product Lifecycle Management in Entwicklung, Versuch und Fertigung Konsolidierung der Systemlandschaft für Produktdaten- und Konfigurationsmanagement Ablösung von 6 Legacy Systemen Ergebnisse: Einführung abgeschlossen Detail- und Entwurfsprozess in der Konstruktion, enge Integration mit CAD System NX Dokumenten und Konfiguration Management Digitaler Bauteilordner in der Fertigung 5 Legacy Systeme abgelöst Neue Errungenschaft: Eine Benutzeroberfläche für Teamcenter Enterprise und Engineering Seite 24 von 388

25 Signifikante Merkmale von PLM Projekten EADS CASSIDIAN Air Systems PLM in der Flugzeugindustrie PLM System: Teamcenter Anzahl der Benutzer: ca. 2000, ursprüngliches Ziel 1200 Hauptziele: Verbesserung der Wettbewerbsfähigkeit Ablösung von Legacy Systemen Single Source Data Base für Produktinformation Datenaustausch für Partner Firmen Ergebnisse: Einführung weitgehend abgeschlossen Produktstruktur(en) mit mächtiger Funktionalität Konfiguration Management inklusive As Built Dokumenten Management Datenaustausch produktiv Defizite: Keine direkte CAD Integration STEP Schnittstellen VPM Fehlende Integration der frühen Entwicklungsphasen Seite 25 von 388

26 Zusammenfassung PLM in der Flugzeugindustrie PLM Systeme Sind und werden von allen führenden Luftfahrtfirmen eingeführt Gelten als eine Schlüsseltechnologie für den Erhalt der Wettbewerbsfähigkeit Die Art der Nutzung von PLM Systemen ist sehr unterschiedlich Es ist schwierig die Potentiale der PLM Systeme wirklich zu nutzen, da die etablierten Verfahren nur schwer zu ändern sind Einigen Firmen ist es gelungen signifikante Verbesserungen zu erreichen PLM (PLM) wird die Firmen noch einige Jahre beschäftigen Seite 26 von 388

27 Strategien für die Einführung Grundsätze Einführung von PLM Think Big Notwendig um das Top Management zu gewinnen Nur so kann der optimale Nutzen erzielt werden Das ganze Unternehmen ist betroffen Start Small Schnelle Erfolge überzeugen Beginnen Sie mit einem einfachen Thema Scale Fast Gesamte Dauer einer PLM Einführung sollte nur 3 bis 4 Jahre Dauern (hängt natürlich vom Umfang der geplanten Funktionalität ab) Jede Verzögerung verringert den Nutzen Seite 27 von 388

28 Strategien für die Einführung Treiber für eine PLM Einführung Einführung von PLM Treiber für die Ver- Änderungsprozesse... Fundamental weitreichende Anforderungen Nicht umkehrbare Globalisierung Geänderte Geografische Ausrichtungen Sämtliche Prozesse in den Unternehmen stehen auf dem Prüfstand Herausforderungen des Marktes: Time to Market Customer satisfaction Design to cost World class quality Reaktionen der Unternehmen: Zeitwettbewerb Kundenorientierung Kostenwettbewerb Qualitätswettbewerb Optimale IT-Strukturen sind Voraussetzung für Wettbewerbsstärke Prozesswettbewerb Reorganisation Ablaufoptimierung Nur mit optimaler IT-Infrastruktur möglich Seite 28 von 388

29 Strategien für die Einführung Bottom up Einführung von PLM Der überwiegende Anteil der PLM Projekte beginnt bottom up, d.h. ein oder mehrere Mitarbeiter begeistern sich für die PLM Idee Jedoch: Jedoch 90% der Kollegen wollen und sehen keine Notwendigkeit für eine Veränderung 10 % sehen die Notwendigkeit für eine Veränderung ein 2-3% sind in der Lage die Veränderung zu gestalten Aus den 2 3% müssen Sie die potentiellen Key User und Meinungsbildner im Unternehmen herausfinden Dieser Personenkreis beginnt die PLM Idee im Unternehmen bekannt zu machen Seite 29 von 388

30 Strategien für die Einführung Top down Einführung von PLM Das Top Management ist meist skeptisch, da es von dieser Materie nichts verseht Unternehmensweite PLM Projekte sind sehr teuer, nicht nur wegen IT (Soft- und Hardware), sondern wegen der Neugestaltung der Prozesse Daher: Nur wenn mindestens ein Mitglied der Leitung bereit ist diese Neugestaltung durchzusetzen, sollten Sie ein PLM Projekt vorschlagen Der Nutzen ist jedoch schwer nachzuweisen und wird vom mittleren Management meist negiert Externe Berater können unterstützen, müssen jedoch einen soliden Erfahrungshintergrund haben Starten Sie kein PLM Projekt ohne ein vom Ziel der PLM Einführung überzeugtes Mitglied der Leitung Seite 30 von 388

31 Strategien für die Einführung Top down und bottom up Einführung von PLM Ohne überzeugte Leitungsmitglieder und motivierte Mitarbeiter sind PLM Projekte schwer umzusetzen, da Der offene oder versteckte Widerstand des mittleren Managements und vieler Mitarbeiter nicht unterschätzt werden darf - kann tödlich sein Ohne innovative und kreative Mitarbeiter das PLM Projekt wahrscheinlich nur die existierende Welt ohne großen Nutzen nachbildet Der finanzielle und personelle Aufwand nur über das Top Management genehmigt wird Nur das Top Management kann Querulanten zum Schweigen bringen Seite 31 von 388

32 Start eines PLM Projektes (1/3) Einführung von PLM Es gibt dafür wahrscheinlich so viele Vorgehensweisen wie Projekte, einige Möglichkeiten werden dargestellt: Aufbau eines Prototypen Auswahl der Story und des Umfangs des Prototypen Suche nach einem geeigneten PLM System und Anbieter Aufbau des Prototypen Demonstration des Prototypen im Unternehmens Möglichst breite Unterstützung erreichen PLM Projekt gemäß der signalisierten Unterstützung planen Über die Hierarchie eine Unterstützungslinie bis zur Leitung suchen Vorstellung des Projektes bei der Leitung => think big!!!! Und KIV (Kinder-, Idioten- und Vorstand sicher) Seite 32 von 388

33 Start eines PLM Projektes (2/3) Einführung von PLM System- und Lösungsanbieter verkauft die PLM-Idee an das Top Management Präsentation der PLM Idee beim Management Prozess - Workshop zur Identifizierung des Potentials von PLM beim Kunden Analyse und Definition Projekt - Ziele, -Strategie, -Umfang Klärung PLM Prozess-, Schnittstellen-, Integrations- Anforderungen, Definition Projektvorgehen, Anforderungen bezüglich Migration Erstellung eines Prototyps und Benchmarking Definieren eines SoW (Statement of Work) zum Projekt Projekt Start Eine Firma weis genau was sie benötigt Formale Spezifikation der Anforderungen Ausschreibung des Projekts Benchmarking der PLM Systeme und Anbieter Auswahl und Projektauftrag Seite 33 von 388

34 Start eines PLM Projektes (3/3) Die Initiierung eines PLM Projekts kann 1 bis 2 Jahre dauern, oft sogar länger Einführung von PLM Das PLM System ist ausgewählt, der Systemanbieter ist gefunden, die Leitung wurde überzeugt und das Budget genehmigt, Was ist nun zu tun? Seite 34 von 388

35 Strategie entwickeln Einführung von PLM Prozesse Auswahl der richtigen Prozesse für den Start Welche Prozesse sind leicht veränderbar? (Leidensdruck) Wo stellt sich der Nutzen schnell ein? Welche Prozesse sind darüber hinaus querschnittlich? Mitarbeiter Rechtzeitige und ausführliche Information der beteiligten Mitarbeiter Auswahl von Multiplikatoren und Meinungsbildnern für das eigentliche PLM Projekt Technologie Ist die out-of-the-box Funktionalität für das Startprojekt überzeugend? Gibt es Schnittstellen für einzubindende Anwendungen? Seite 35 von 388

36 Das Richtige zuerst Vorbereitung des gesamten Unternehmens für das PLM Projekt Einführung von PLM Readiness Implementierung Review u. KVP Seite 36 von 388 Awareness KVP: Kontinuierlicher Verbesserungsprozess

37 Kommunikation Einführung von PLM PLM Benutzer Information PLM Positionspapier PLM Key Note Präsentation Top Management Kontakt Information Erfolgsmeldungen Veröffentlichungen Ereignisse PLM Projekt Update PLM Neuigkeiten Round Table Benutzer Executive Seminar PLM Seminar PLM Schulung Seite 37 von 388

38 Methodische Vorgehensweise z.b. Chestra Methoden für die Einführung - Chestra Chestra Domänen des Wandels Hexagon des Wandels Prozesse Organisation Standorte Daten SBS Applikationen Technologie Seite 38 von 388

39 Chestra Domänen des Wandels Methoden für die Einführung - Chestra Geschäftsprozess Die Domäne der Geschäftsprozesse beschäftigt sich mit dem, was das Unternehmen tut, wie es dies tut, in welcher Abfolge es dies tut, welchen Regeln es folgt und welche Art von Ergebnissen erwartet werden. Bei Chestra treibt der Wandel bei den Geschäftsprozessen die Veränderungen in allen anderen Bereichen voran. Organisation Die Domäne der Organisation beschäftigt sich mit den Mitarbeitern des Unternehmens: ihrer Kultur, ihren Fähigkeiten, ihren Aufgaben bzw. Rollen, ihren Teamstrukturen und ihren Organisationseinheiten. Sie enthält außerdem die Unterstützungssysteme, die die Organisationsentwicklung ermöglichen. Standort In der Domäne des Standorts geht es um die Standorte, an denen das Unternehmen seine Geschäfte abwickelt, sowohl in bezug auf den Standorttyp als auch in Bezug auf die spezifischen physischen Einrichtungen des jeweiligen Standorts. Seite 39 von 388

40 Chestra Domänen des Wandels Methoden für die Einführung - Chestra Anwendung Die Domäne der Anwendungen behandelt den Leistungsumfang, die Struktur und die Anwenderschnittstelle der Software, die dem Benutzer zur Verfügung steht. Anwendungen können für das Unternehmensgeschäft spezifisch sein, beispielsweise eine Auftragserfassungsanwendung. Sie können aber auch allgemein sein, z.b. ein Textverarbeitungsprogramm, eine Tabellenkalkulation oder ein CAD System. Daten Die Domäne der Daten beschäftigt sich mit dem Inhalt, der Struktur, den Beziehungen und den Regeln in Zusammenhang mit den Informationen, die das Unternehmen ständig nutzt und verarbeitet. Technologie Die Domäne der Technologie behandelt die Hardware, die Systemsoftware und die Kommunikationskomponenten, die zur Unterstützung des Unternehmens genutzt werden. Seite 40 von 388

41 Was sonst noch benötigt wird (1/2) Methoden für die Einführung - Infrastruktur Räumlichkeiten für das Kernteam Räume und Infrastruktur für Workshops Entwicklungsumgebung Test- und Abnahmeumgebung Planung der Infrastruktur PLM Server PLM Clients PC Systeme Unix Systeme Netzwerke Work Group Server (?) Seite 41 von 388

42 Was sonst noch benötigt wird (2/2) Methoden für die Einführung - Team Externe Berater Ohne externe Berater wird zumindest der Start der PLM Projekts nicht gelingen Berater vom Lösungsanbieter Alles aus einer Hand, klare Aufgabenteilung Kennt meist das Geschäft des Kunden nur wenig Hat Stärken im PLM Know How Berater unabhängig vom Lösungsanbieter Spannungen sind vorprogrammiert, kann die Kreativität fördern oder zur Blockade führen Hat Stärken in anderen Domänen (z.b. Projektmanagement, Prozessveränderungen) Ausbildung und Know How der eigenen Mitarbeiter müssen sehr schnell aufgebaut werden Die Berater können bei der Neugestaltung der Prozesse meist nur bedingt helfen, da sie das Geschäft nicht verstehen Seite 42 von 388

43 Eckpfeiler einer PLM Einführung Methoden für die Einführung Mental Change Notwendigkeit für Mental Change Umsetzung des Mental Change Projekt Management und Controlling Methodisches Vorgehen für die Definition von Prozessmodell Datenmodell Integration von Anwendungen IT-Architektur Seite 43 von 388

44 Notwendigkeit für Mental Change Methoden für die Einführung Mental Change Was sind die Meßlatten für den Erfolg eines PLM Systems? Signifikante Fortschritte bezüglich: Zeit, z.b. Verkürzung der Entwicklungszeit (concurrent engineering) Sofortige Verfügbarkeit der Information für alle Beteiligten Kosten Papier-, Microfilmverteilung wird eingestellt Abschaltung von Altsystemen Qualität First time right Konsistente und richtige Information für das Unternehmen Was sind die Auswirkungen im Hinblick auf Mental Change, wie sind die Mitarbeiter dadurch betroffen? Zeit Die Mitarbeiter sollen noch unvollständige Informationen mit Kollegen teilen Fehler werden sofort offenkundig, Information muss geholt werden Kosten Arbeitplatz geht verloren, bzw. ändert sich radikal Know How Träger verlieren ihr Monopol Qualität Großer Anspruch an MA Teile des Mgmt. verlieren ihr Monopol für wichtige Informationen Die Umstellung erfolgt nicht langsam, sondern radikal!! Seite 44 von 388

45 Fortschritt Phasen in Mental Change Projekten Methoden für die Einführung Mental Change Begeisterung Elan Ernüchterung Angst Tal der Tränen Rückschritt Durchbruch Zeit Seite 45 von 388

46 Unterstützung des Mental Change Methoden für die Einführung Mental Change Vision und Ziele müssen klar dargestellt und kommuniziert werden Kommunikation, Kommunikation, Kommunikation auf allen Hierarchieebenen Management und Linie teilen das Risiko!!!! Arbeitsplätze sind sicher, d.h. Fortschritte generieren mehr Geschäft Management geht mit gutem Beispiel voran Alle Fortschritte werden kommuniziert Positive Beiträge werden gewürdigt Die Wirklichkeit ist meist anders, d.h. Management und Mitarbeiter gehen auf Distanz. Seite 46 von 388

47 Wichtigkeit des Projektmanagements Methoden für die Einführung Projektmanagement Projektmanagement ist nicht der Kern der PLM Einführung, aber eine wichtige Voraussetzung für eine erfolgreiche Arbeit Aufgaben des Projektmanagements Planung und Durchführung von Teilprojekten Sicherstellung des methodischen Vorgehens Controlling des Arbeitsfortschrittes Controlling des Budgets Management der internen Ressourcen Ausarbeitung von Verträgen und Beauftragung von Lieferanten und Sublieferanten (SLA = Service Level Agreement) Reporting an den PLM Lenkungsausschuss Planung und Durchführung der Kommunikationsmaßnahmen Seite 47 von 388

48 Methodisches Vorgehen sicherstellen Methoden für die Einführung Projektmanagement P R O G R A M M M G M T. Vision und Strategie Architektur Entwicklung Integration Einführung Betrieb E N T W I C K L U N G S K O R D I N A T I O N P R O J E K T M G M T Seite 48 von 388

49 Projektorganisation Methoden für die Einführung Projektmanagement Projekt Leitung Systemlieferant PLM Lenkungsausschuss Auftraggeber (Leitung), Auftagnehmer, Prozess Eigner Projekt Controlling Projekt Leitung Fachprojektleiter Externe Berater Teilprojekt- Projekt Leitung leiter Seite 49 von 388

50 Dreiecke der Erwartungen/Zwänge Methoden für die Einführung Projektmanagement Management Kunde Projektleiter Mitarbeiter Zeit Lieferung der Leistung Auftrag Kosten Seite 50 von 388

51 Projektphasen Methoden für die Einführung Projektmanagement Planung u. Start Durchführung Beendigung Seite 51 von 388

52 Projekt Durchführung Methoden für die Einführung Projektmanagement Kapitel 1. Hintergrund 2. Ziele 3. Umfang 4. Liefereinheiten 5. Lösungsansatz 6. Risiken 7. Annahmen 8. Restriktionen 9. Externe Abhängigkeiten 10. Kritische Erfolgsfakt. 11. Infrastruktur 12. Verantwortlichkeiten Untergeordnete Arbeitsmittel Projekt Mgmt. Tools Problem Lösungsprozedur Daten/Dokumenten Mgmt. Verfahren Weitere Projekt Methoden Projekt Management Plan Projekt Definition Projekt Plan Prozeduren & Werkzeuge Weitere unterstützende Pläne Unterkapitel Hauptkapitel 1. Produkt/WBS Produkt/WBS Chart der Abhängig- 2. Chart keiten der Abhängig- 3. keiten Terminplan Terminplan Projekt Organisaon Projekt Mitarbeiter Organisation Profile Mitarbeiter Budget Profile Budget Zahlungsmeilen- 7. Zahlungsmeilen- steine steine Untergeordnete Arbeitsergebnisse Plan zum Start v. Projekten Konfigurationsmgmt. Plan Unterauftragnehmer Mgmt. Abnahme Plan Kommunikationsmgmt. Plan Qualitätsplan Risiko Mgmt. Plan Schulungsplan Plan zur Meilenstein Überwachung u. Beurteilung Update Planung Seite 52 von 388

53 Projekt Durchführung Methoden für die Einführung Projektmanagement Verträge u. andere Vereinbarungen Konfig. Mgmt. Plan Change Requests, Problem Reports Leistungsvereinbarungen Leistungsbewertung Qualitätsplan Abnahme Protokolle Arbeitsblätter für Risiko Aufnahme und Bewertung Risiko Abminderungsplan Management von Arbeitsergebnissen Konfiguration Mgmt. Personal Mgmt. Qualität Mgmt. Risiko Mgmt. Problem Mgmt. Überwachung & Verfolgung Projekt Ergebnisse Projekt Mgmt. Ordner Problem Reports Problem Reports Log Planung der Aufgaben Zuordnung Projekt Kalender Projekt Status Bericht Projekt Performance Statistik Formale Abnahme Dokumente Kurzübersicht Abschluss Bericht Dokumente über Projekt Start Angebot und Vertrag Planung und Kontrolle Probleme Schriftverkehr und Notizen Material zur Zielfindung und Team Bildung Technische Infrastrukt. Administration Seite 53 von 388

54 Projekt Durchführung Methoden für die Einführung Projektmanagement Kontrolle, Monitoring Der Zielereichung Für Gesamt- oder Teilprojekte Soll Ist Organi- sation Anwendungen Technologie Prozesse Standorte Daten Seite 54 von 388

55 Projekt Durchführung Projekt-/Teilprojektphasen Methoden für die Einführung Projektmanagement Teil- aktivität Benennung Inhalt Phase 0 Gesamt-Setup Planung des Gesamtprojekts, der Gesamt-Controlling- Maßnahmen, der Ressourcen, die über das gesamte Projekt hinweg zur Verfügung zu stellen sind, der organisatorischen Maßnahmen im Umfeld des Projekts sowie der insgesamt bereitzustellenden finanziellen Mittel Phase 1 Phase 2 Phase 3 Grobspezifikation (Konzept) Funktionale Feinspezifikation Prototyping (gegebenenfalls parallel zur Phase 2) Übergreifende, konzeptionelle Darstellung der künftigen Funktionalität in ihrer Relation zu Prozessen, Informationsobjekten und anderen IT- Systemen Detaillierte Beschreibung der geforderten Funktionalität aus Sicht der Anwender/ Nutzer als Referenz für die softwaretechnische Realisierung Beispielhafte Realisierung bestimmter, vereinbarter Teile der Gesamtfunktionalität zur Prüfung auf Plausibilität Seite 55 von 388

56 Projekt Durchführung Projekt-/Teilprojektphasen Methoden für die Einführung Projektmanagement Teil- aktivität Phase 4 Benennung DV-technische Feinspezifikation Inhalt Detaillierte Beschreibung der Funktionalität aus DVtechnischer Sicht, insbesondere Darstellung der Anforderungen an Hardware- und Betriebssystem. Phase 5 Realisierung Softwaretechnische Bereitstellung der einzelnen Funktionen. Phase 6 Phase 7 Phase 8 Control ling Integration und Test Implementierung und Migration Gesamt- Abnahme Projektcontrolling (querschnittlich) Zusammenfügen aller Funktionen zum Gesamtsystem, Test der Funktionalitäten. Bereitstellung des Gesamtsystems für den Produktivbetrieb sowie der bereits vorhandenen Alt- Informationsobjekte. Prüfung des Gesamtsystems auf vollständige Erfüllung der beschriebenen Funktionalitäten. Vergleich der Planungskennzahlen mit den realen Kennzahlen mit entsprechender Reaktion. Seite 56 von 388

57 Definition der Prozess Modelle Methoden für die Einführung Prozesse Vorgehen in drei Stufen: Geschäftsprozesse und Überblick Arbeitsprozesse Elementare Business Prozesse Beispiele: Geschäftsprozesse: Entwicklung, Serienfertigung Arbeitsprozesse: Einzelteil konstruieren, Produktstruktur definieren, RMT Analyse durchführen Elementare Business Prozesse (EBP): 3D Modell erzeugen, 3D Modell freigeben, Fertigungsplan festlegen, Zuverlässigkeit ermitteln, Gewicht bestimmen Seite 57 von 388

58 Geschäftsprozesse Methoden für die Einführung Prozesse Ausrichtung auf und nach Geschäftsprozessen fördert die Rückbesinnung auf originäre Unternehmensziele. M Kunde M M M Teilprozess Teilprozess! Teilprozess Geschäftsprozesse beginnen und enden bei Kunden Geschäftsprozesse besitzen eine Meilensteinstruktur! klarer Fokus Zwang Kunde zu Ergebnissen Seite 58 von 388

59 Arbeitsprozesse (Aktivitäten) Methoden für die Einführung Prozesse Arbeitsprozesse bilden konkrete Tätigkeiten ab... In Geschäftsprozessen werden über die Meilensteine unterschiedlichste Arbeitsprozesse aufgerufen. Diese beschreiben unter funktionalen Gesichts- punkten die konkreten Tätigkeiten im Unternehmen und produzieren die Ergebnisse für die Teilprozesse. Aufgabe Ergebnis Arbeitslast deliverables Geschäfts- Prozess Arbeits- Prozesse (=Technische Unterstützungs- Prozesse) Seite 59 von 388

60 Top down Vorgehen bei Prozessaufnahme Methoden für die Einführung Prozesse Seite 60 von 388

61 Prozesslandkarte Methoden für die Einführung Prozesse Eine Prozesslandkarte zeigt den Zusammenhang zwischen Geschäftsprozessen und dem Aufruf von Arbeitsprozessen in Phase des Produktslebenszyklus Prozeßlandkarte (Geschäftsprozesse versus Arbeits- und Unterstützung Version 4.5 Vorentwurf Definitionsphase Entwicklungs- und Fertig - Seite 1 - M0 M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 (Stand vom ) PE-1 PE-2 PE-3 PE-4 PE-5 PE-6 PE-7 PE-8 PE-9 PE-10 PE-11 Strategie- und Technologie Einsatzanalyse Marketing (neue Produkte) Produktstudien und Vorentwurf Survivability (+) Mechanische Strukturen - Ausrüstungskonstruktion - Strukturkonstruktion - (Digital/real) Mock-Up (+) Strukturmechanik - Statik und Gewichte - Festigkeit - Analyse - Betreuung (+) Strukturdynamik - Belastungsmechanik - Analyse - Strukturversuch Aerodynamik Flugphysik (+) System/Software-Entwicklung - Systemtechnologie Studien - Systemkonzept Geschäftsprozeß Produktentwicklung Seite 61 von 388

62 Stufenweise Prozess Detaillierung Methoden für die Einführung Prozesse S0 Montage Komponenten Serienbeauftragung erwirken SA-0 Start Serie S0 Produktionsprogramm planen SA-1 Aktivität EL S2 Start Serienvorbereitung Aktivität EL Aktivität EL Produktionsmittel planen und bereitstellen SA-2 Serienreifmachung vornehmen SA-3 Aktivität EL Aktivität EL Production readyness S3 Kontinuierliche Weiterentw. d. Std.- Komponenten SA-4 Kundenwünsche für single a/c integrieren SA-5 Aktivität EL Aktivität EL S4 Fertigung des single a/c planen SA-6 Start Produktion Start Serienprozeß Fertigungsplanung abgeschlossen S5 Teile fertigen bzw. beschaffen SA-7 S6 SA-8 Start final assembly S7 SA-9 S8 SA-10 Status power-on erreicht First flight readyness S9 Montage Serienflugzeug Bodentests Flugtests und Abnahme SA-11 S10 Delivery single a/c (Teil-) Aktivitätenebene Verfeinerung der Aktivitäten bis auf Ebene des elementaren BP (EBP) Businessprozessebene (Detaildarstellung mit Teil-GP) EL-3.1 Hüllgeometrie des Equipments bereitstellen EL Digital-Mock-Up auf Equipment-Ebene erstellen EL-3.4 Detaillierung auf Aktivitätenebene Standards für Spezifikationsphase bereitstellen Start Komponentenfertigung Equipment-Einbauinformationen als Vorgabe definieren EL Geometrie der Hauptkabelwege festlegen EL Geometrie der Haupttrennstellen festlegen EL Geometrie der VE- Einheiten als Hüllgeometrie festlegen EL Teilgeometrie zum Digital-Mock-Up zusammenstellen EL EL Abstimmung durchführen Quelle: debis Systemhaus, STA-Methodik M7 Seite 62 von 388

63 Geschäftsprozess Produktentwicklung Methoden für die Einführung Prozesse Beschreibt den gesamten Handlungsablauf auf Unternehmensebene zur Entwicklung eines Flugzeugs bis zur Serienreife. Er wurde als Sollprozess dargestellt, unabhängig von laufenden Vorhaben. Vorentwicklungsphase Start Produkt- Entwicklung M0 Strategische Entwicklungsplanung durchf. PE-1 PE-2 M2 PE-3 PE-4 M4 PE-5 Technologiekonzepte entwikklen Marktuntersuchung durchführen Produktstudien durchführen Basiskonzept entwikkeln Feinkonzept erstellen PE-6 M6 PE-7 Produkt spezifizieren Entwicklungsangebot erstellen PE-8 Produkt- Informationen erstellen PE-9 Beschaffung und Teilefertigung Prototypen PE-10 M1 M3 M5 M7 M9 M11 M13 Start Technologie- Entwicklung Produkt-Ideen verfügbar Bedarfsermittlung abgeschlossen Auslegungsdefinition abgeschlossen Configuration Freeze erreicht Status ITP erreicht Status ATO erreicht Status go ahead erreicht M8 Entwicklungs- und Fertigungsphase Status first metal cut erreicht Begin final assembly M10 PE-11 PE-12 Status power on erreicht First flight readyness M12 PE-13 Montage Prototypen Bodentests Flugerprobung Leistungsnachweis u. Refurbishing PE-14 Status a/c certification erreicht Status FOC erreicht M14 Definitionsphase Seite 63 von 388

64 Geschäftsprozess Serienabwicklung Methoden für die Einführung Prozesse Beschreibt den Handlungsablauf für die Serienfertigung der Flugzeuge. Serienbeauftragung erwirken SA-0 S0 Start Serienprozeß Start Serie S1 Produkttionsprogramm planen SA-1 Produktionsmittel planen und bereitstellen SA-2 S2 Start Serienvorbereitung Serienreifmachung vornehmen SA-3 Production readyness S3 Kontinuierliche Weiterentw. d. Std.- Komponenten SA-4 Kundenwünsche für single a/c integrieren SA-5 oder Fertigung des single a/c planen SA-6 S4 Start Produktion Fertigungsplanung abgeschlossen S5 Teile fertigen bzw. beschaffen SA-7 Montage Komponenten SA-8 S6 Start Komponentenfertigung Start final assembly S7 Montage Serienflugzeug SA-9 Bodentests SA-10 S8 Status power-on erreicht Für jedes einzelne Flugzeug First flight readyness S9 Flugtests und Abnahme SA-11 S10 Delivery single a/c Seite 64 von 388

65 Geschäftsprozess In-Service-Support Methoden für die Einführung Prozesse Beschreibt die (möglichen) Aktivitäten im Umfeld ausgelieferter Serienflugzeuge. Diese erstrecken sich parallel zueinander über die gesamte life-cycle-phase eines Produkts. B0 Logistic Support Date PS-1 PS-2 PS-3 PS-4 B1 Änderungswesen Ersatzteilwesen Produkterhaltung Dienstleistungen Verschrottung Seite 65 von 388

66 Vorgehensweise zur Prozessaufnahme Methoden für die Einführung Prozesse Standardvorgehensweise 1 Prozessaufnahme 2 Darstellung der Ist-Prozesse Vorgehen Iteratives für Vorgehen Grobspec. V3 1 Prozessaufnahme bzw. - analyse GP-Analyse E r s t. L s t H f t E r s t. P F r e i g. C 2 Iteratives Festlegen der Soll-Prozesse f t H f t 4 Festlegen der Soll-Prozesse Ausnahmen zuerst ausschließen Seite 66 von 388

67 Elementare Geschäftsprozesse Methoden für die Einführung Prozesse Zu bearbeitende Objekte bleiben konsistent, d.h. sie lassen sich nicht sinnvoll zerlegen Es wird nur ein zusammenhängender Zeitraum betrachtet, d.h. zeitlich auseinander liegende Aktivitäten werden in mehreren EBP dargestellt Elementarer Geschäftsprozess Elementarer Geschäftsprozess nur eine Aktivität T 0 Elementarer Geschäftsprozess... manuelle Tätigkeiten Exakt eine Rolle zugeordnet automatische und... Seite 67 von 388

68 Definition des Elementaren Business Prozess Methoden für die Einführung Prozesse Die Definition des Elementaren Business Prozesses umfasst folgende Punkte: Aktivitätsarten In jedem Prozessschritt werden entweder manuelle oder automatische Aktivitäten dargestellt. Bei einer automatischen Aktivität übernimmt das Wirksystem bzw. die Anwendung (auch PLM) die Ausführung. In diesem Falle darf keine Rolle zugewiesen werden. Rollenzuordnung Ein elementarer Prozessschritt wird von einem Benutzer bzw. einer Rolle ausgeführt oder abgewickelt. Lässt sich eine Aktivität weiter in Segmente unterteilen, die von verschiedenen Rollen ausgeführt werden, so handelt es sich dabei noch nicht um eine elementare Tätigkeit, d.h. durch konsequentes Hinterfragen muss sichergestellt werden, dass dem Prozess maximal eine Rolle für die Ausführung zugeordnet ist. Konsistenz des konzeptionellen Datenmodells Das konzeptionelle Datenmodell ist vor und nach einem Prozessschritt konsistent. Ein Prozess sollte nicht so weit zerlegt werden, dass Inkonsistenzen im konzeptionellen Datenmodell die Folge sind. Beispiel: Wird eine Spezifikation innerhalb eines Reviews freigegeben, so ist der Input die Spezifikation und der Output die freigegebene Spezifikation. Eine Aufspaltung des Output in Spezifikation und "Freigabe-Flag" würde zu einer Inkonsistenz im konzeptionellen Datenmodell führen. Seite 68 von 388

69 Definition des Elementaren Business Prozess Methoden für die Einführung Prozesse Betrachtungszeitraum Die Benutzerbeteiligung wird auf einen zusammenhängenden Zeitraum beschränkt. Lässt sich eine Aktivität in Segmente unterteilen, die zu anderer Zeit ausgeführt werden, handelt es sich dabei nicht um eine elementare Aktivität. Eine Aktivität Wichtige Unterschiede zwischen Prozessschritten bleiben erhalten. Es kann vorkommen, dass ein Benutzer zwei unterschiedliche Tätigkeiten, die zwei unterschiedliche elementare Prozessschritte repräsentiert, in einem zusammenhängenden Zeitraum ausführt. Beispiel: So könnte z.b. ein CAD-Modell in einer frühen Entwicklungsphase vom verantwortlichen Konstrukteur erstellt und anschließend freigegeben werden. Die Erstellung und die Freigabe des CAD-Modells erfolgen dabei zwar zeitlich zusammenhängend, müssen aber als getrennte Prozessschritte erhalten bleiben. Diese Unterscheidung sollte schon bei einer rein tätigkeitsorientierten Prozessaufnahme dargestellt sein. Seite 69 von 388

70 Informationen zum EBP Methoden für die Einführung Prozesse Prozesstitel Die einzelnen Prozesstitel werden aus einem Substantiv, wenn erforderlich zusammen mit einem klassifizierenden Adjektiv, gefolgt von einem Verb gebildet. Beispiele sind "funktionale Anforderungen spezifizieren", "Normteile identifizieren", "Hüllgeometrie bereitstellen" oder Systemspezifikation erstellen". Innerhalb eines Prozessmodells darf ein Prozesstitel nur einmal verwendet werden. Prozessbeschreibung Die einzelnen Aktivitäten werden verbal in ein bis zwei Sätzen beschrieben. Die Beschreibung muss so erfolgen, dass "Nicht- Prozesskenner" verstehen, was bei der jeweiligen Aktivität zu tun ist. Rolle Handelt es sich bei dem Prozessschritt um eine manuell durchgeführte Aktivität, so muss (genau) eine Rolle zugeordnet werden. Seite 70 von 388

71 Informationen zum EBP Methoden für die Einführung Prozesse Objekt Bei dem/den zugeordneten Objekt(en) muss es sich um Objekte aus dem konzeptionellen Datenmodell handeln. Zusätzlich sollen die möglichen Aktivitäten wie Create, Update, Read und Delete dokumentiert werden. Ggf. kann eine genauere Aufnahme der Objekte sinnvoll sein. In diesem Fall können die realen Benennungen (Digital Dokument in Solid, Draw, ICR (Item Change Record), Test Sheet etc.) dokumentiert werden Wirksystem Zu jedem Prozessschritt müssen die jeweiligen Wirksysteme wie MS- Word, CATIA, LCABLE, PLM etc. dokumentiert werden. Standort Jeder Prozessschritt muss (mindestens) einem Standort zugeordnet werden. Datenvolumen und Transaktionsvolumen Zu jedem Prozessschritt sollten die jeweiligen Dateigrößen und die Häufigkeit des betrachteten Prozessschrittes dokumentiert werden Die beiden letztgenannten Punkte dienen der späteren Festlegung von Datenverteilung und Infrastruktur (Netz-, CPU- und Speicherkapazitäten). Seite 71 von 388

72 Informationen zum EBP Methoden für die Einführung Prozesse Prozessidentifikation Für eine eindeutige Identifizierung von Geschäftsprozessen und Teilprozessen sowie einer eindeutigen Zuordnung von untergeordneten zu übergeordneten Prozessen wird eine Prozess-Id (Identifikation) vergeben. GP-Nr. Teilprozess Teilprozess EBP Ebene 1 Ebene 2 E1 E1.1 E1.1.1 E E E E1.1.2 E E E1.2 E1.2.1 E E E E1.2.2 E Seite 72 von 388

73 Beispiel der Darstellung von Arbeitsprozessen (Aktivitäten) M6 Methoden für die Einführung Prozesse Standards für Spezifikationsphase bereitstellen EL-3.1 Funktionale Spezifikation der Equipments erstellen EL-3.2 Funktionales Zusammenwirken der Equipments untereinander definieren EL-3.3 Digital-Mock-Up auf Equipment- Ebene erstellen EL-3.4 Funktionale Spezifikation der Elektrik-Komponenten erstellen Spezifikationsinformation freigeben EL-3.5 Spezifikationsinformation automatisiert zusammenstellen EL-3.6 EL-3 M7 Seite 73 von 388

74 Beispiel für tabellarische Beschreibung von EBP Prozess Methoden für die Einführung Prozesse Ref.-Nr. Titel/ Erläuterung Input Output Wirksystem(e) Rolle EL Equipment-Einbauinformationen als Vorgabe definieren Waffensystemspezifikati Einbauinformation (inboard MS-Office Strukturentwicklu on profile) HTML-Browser ng Grundlage für die Untersuchungen am DMU, hier insbesondere Systemspezifikation DMU-Modell (WissensDB) der Einbauuntersuchungen für die Equipments und die Verlegung der Kabelbündel, ist das Modell der Struktur, in das die verschiedenen System eingebaut werden müssen. Equipmentspezifikation Equipment (Waffensystem) DMS PDM CATIA EL EL EL Hüllgeometrie des Equipments bereitstellen In dieser Teilaktivität werden die Hüllgeometrien der Equipments für den DMU bereitgestellt. Es ist in den entsprechenden Verträgen darauf zu achten, daß möglichst viele Geometrien schon zu diesem Zeitpunkt von Suppliern beigestellt werden und in Standardteil-Libraries abgelegt werden. Zur Zeit werden die Modelle noch auf Basis der gelieferten Herstellerzeichnungen bei der Dasa neu erstellt. (A03) Hauptkabelwege festlegen Hier erfolgt die Festlegung der Hauptkabelwege (Bündel). Zusätzlich werden die erforderlichen Durchbrüche in Zusammenarbeit mit Statik und Struktur festgelegt DMU-Anpassungen für Hautkabelwege durchführen Die Modellierung der festgelegten Durchbrüche etc. in der mechanischen Struktur erfolgt in diesem Prozeßschritt. Zur Konsintenzerhaltung zwischen den 3D-CAD-Modellen und der DMU-Modelle ist evtl. zusätzlich die Anpassung schon vorhandenener 3D-CAD-Modelle notwendig. Die Durchführung obliegt der Mechanikentwicklung. Einbauinformation (inboard profile) (Equipment) DMU-Modell Equipmentspezifikation CAD-Modell (Equipment) Systemspezifikation QAR Circuit-Diagram DMU-Modell (Hauptkabelwege) DMU-Modell (Waffensystem) DMU-Modell (Hauptkabelwege) DMU-Modell (Waffensystem) DMU-Tool DMS PDM CATIA DMU-Tool Normteillibrary (Geometrie) DMS LCABLE PDM CATIA DMU-Tool Geräteeinbau Kabelbündeleinba u Strukturentwicklu ng Seite 74 von 388

75 Equipmentspezifikation Equipmentspezifikation (Angebot) Equipmentstückliste Equipmentzeichnungen Erfahrung aus anderen Programmen Fertigungsplan Fertigungsstrukturkonzept Fertigungsunterlagen Freigabeschein DCN Funktionsstruktur Geräteeinbauzeichnung Geräteeinbauzeichnung (Gesamtflugzeug) CRUD Matrix für EBP und Infoobjekte Methoden für die Einführung Prozesse C = Create (Erstellen) C = Create (Erstellen) R = Read (Lesen) R = Read (Lesen) U = Update U (Aktualisieren) = Update D = Delete (Löschen) D = Delete (Löschen) Ref.Nr. Prozeß EL-0 Elektrik Soll-Prozeß EL-1 Grobkonzept für Systeme des Worksharing erstellen EL-1.1 Konzeptstandards definieren R EL-1.2 Gemeinsame IT-Systemumgebung festlegen R EL-1.3 Worksharing definieren R CU EL-1.4 Inhaltliche Standards für Konzeptphase erstellen R EL-1.5 Worksharing bezogen auf die Systeme des Waffensystems beschreiben R R EL-2 Feinkonzept für Systeme erstellen EL-2.1 Komponenten jedes Systems beschreiben CU EL-2.2 Funktionale Anforderungen des Systems beschreiben EL-3 Funktions-Spezifikation der Elektrik-Komponenten erstellen EL-3.1 Elektrischen Anteil der Systeme identifizieren U Seite 75 von 388

76 Betriebsmittelkonstruktion und -fertigung Betriebsmittelplaner u. Montageplaner Bündelmonteur CAD-Modellierer DMU-Team Einkauf Elektrik-Konstrukteur Equipmententwickler Fertigung Fertigungsplaner Geräteeinbau Gerätekonstruktion Kabelbündeleinbau Kommissionierung Materialwirtschaft Zuordnung von EBP und Rollen Methoden für die Einführung Prozesse X = aus X = Führt aus Ref.Nr. Prozeß EL Zulieferer auswählen EL Equipment entwickeln x EL-3.3 Funktionales Zusammenwirken der Equipments untereinander definieren EL Software-Funktionen zum System spezifizieren EL Mechanisches Zusammenwirken auf Equipment-Ebene spezifizieren EL Elektrisches Zusammenwirken der Equipments untereinander spezifizieren EL Relevante Randbedingungen ermitteln EL Circuit-Diagram erstellen EL-3.4 Vorläufiges Digital-Mock-Up erstellen EL Vorläufiges Digital-Mock-Up vorbereiten EL Equipment-Einbauinformationen als Vorgabe definieren x EL Hüllgeometrie des Equipments bereitstellen x EL Hauptkabelwege festlegen x EL DMU-Anpassungen für Hautkabelwege durchführen Seite 76 von 388 EL Geometrie der VE-Einheiten als Hüllgeometrie festlegen x

77 ASAP CADAM CATIA CORE DMS DMU-Tool EIS EPOS FACT HOOK HTML-Browser Zuordnung von EBP und Wirksystemen Methoden für die Einführung Prozesse X X = Verwendet Ref.Nr. Prozeß EL Umgebungsbedingungen spezifizieren x x EL RMT-Aspekte spezifizieren x x EL Sonstige Anforderungen spezifizieren x x EL Zulieferer auswählen x x EL Equipment entwickeln x x EL-3.3 Funktionales Zusammenwirken der Equipments untereinander definieren EL Software-Funktionen zum System spezifizieren x x x x x EL Mechanisches Zusammenwirken auf Equipment-Ebene spezifizieren x x EL Elektrisches Zusammenwirken der Equipments untereinander spezifizieren EL Relevante Randbedingungen ermitteln x x EL Circuit-Diagram erstellen x x x EL-3.4 Vorläufiges Digital-Mock-Up erstellen EL Vorläufiges Digital-Mock-Up vorbereiten EL Equipment-Einbauinformationen als Vorgabe definieren x x x x Seite 77 von EL Hüllgeometrie des Equipments bereitstellen x x x

78 Ottobrunn Augsburg Manching Bremen Partnerstandorte Zuordnung von EBP zu Standorten Methoden für die Einführung Prozesse X = betroffener Standort Ref.Nr. Prozeß EL Digital-Mock-Up für Bauanteil zusammenstellen x EL DMU-Prüfungen durchführen x EL Gemeinsame Abstimmung durchführen x EL-4.2 Konstruktionsfreigabe durchführen x EL-5 Elektrik-Komponenten fertigen..... EL-5.1 Arbeitsvorbereitung durchführen..... EL Fertigungsplan erstellen x EL Betriebsmittel erstellen x EL Material bestellen x EL Anschlußelemente in VE-Box montieren x EL Leitungen in VE-Box verlegen x EL Montageplan erstellen x EL Betriebs- und Prüfmittel erstellen x EL Material beschaffen x EL Testprogramme und Testproceduren (Stage A) erstellen x EL Kabelbündel- und Gerätemontage vorbereiten..... EL Kennschilder anbringen x EL Erforderlichen Geräteeinbau vor Kabelmontage durchführen x EL Massetests durchführen x Seite 78 von 388

79 Erfassung von Daten- und Transaktionsvolumina zu EBP Methoden für die Einführung Prozesse Ref.- Nr. Anmerkungen EL Prozess Neuauftrag Neuer Kunde 5.00 / Mo 2.00 / Mo 5.00 / Mo 1.80 / Mo Spitze 4,00/ Wo 1.50/ Wo 4.00/ Wo 1.50/ Wo Grö ße 50 kb 75 kb 120 kb 30 kb Änderungsauftrag Kreditgenehmigung Anzahl Wachstum 20%/ Jahr 20%/ Jahr 15%/ Jahr 15%/ Jahr Spitze ist letzte Woche im Monat. Spitze ist letzte Woche im Monat. Spitze ist letzte Woche im Monat. Spitze ist erste Woche im Monat. Seite 79 von 388

80 Aufnahme von Anforderungen für mehrere EBP Methoden für die Einführung Prozesse Anf.-Nr. Anforderungsbeschreibung betr. Prozesse A01 Modularisierung von Spezifikationen Um eine möglichst gute Weiterverwendung von Informationen in den Spezifikationen zu erreichen, sollen diese in modularisierter Form erstellt werden. Die Granularität der Module kann dabei bis auf einzelne Datenelemente heruntergehen. Betroffene Teilprojekte: Dokumentenmanagement und Systeme & Software EL-2.1 EL-2.2 EL A02 A03 A04 Funktionale Produktstruktur im PDM-System Bestimmte Bauunterlagen, vor allem ein Großteil der Diagramme, sind systemund nicht baugruppenbezogen. Um sie in der Produktstruktur entsprechend verankern zu können, wird ein funktionaler Aufbruch, die sogenannte Funktionsstruktur benötigt. Betroffene Teilprojekte: Systeme & Software und Produktstrukturmanagement Lieferung von Daten durch Supplier Zur Zeit werden noch sehr oft 3D-CAD-Modelle und andere Bauunterlagen bei der Dasa auf Basis der nicht ausreichenden gelieferten Unterlagen neu erstellt. In Zukunft sollen möglichst viele Geometrien und andere Produktinformationen schon von Suppliern beigestellt und in Standardteil-Libraries abgelegt werden. Automatische Erstellung von VE-Diagrammen Die elektrischen Funktionen und deren Realisierung durch Geräte (z.b. Relais, Schutzschalter etc.) sind auf den Wiring-Diagrammen bereits dezentral dokumentiert. Die elektrische Konstruktion beschränkt für die VE-Boxen sich daher hier auf die Erstellung von VE-spezifischen Diagrammen auf denen die dezentralen Informationen zusammengefahren werden. Da es sich hierbei nicht um einen wertschöpfenden Prozeß handelt, soll diese Tätigkeit möglichst weit automatisiert mit Hilfe des Wirksystems LCABLE geschehen EL EL EL EL EL Seite 80 von 388

81 Frage nach SW Unterstützung für Prozessmodellierung Methoden für die Einführung Prozesse Nachteile von Modellierungssoftware sie besitzen zu viel Funktionalität, die im praktischen Einsatz kaum Verwendung findet, sind also zu kompliziert zu nutzen sie müssen durch den Kauf von SW-Lizenzen zumeist teuer bezahlt werden sie wurden aus Sicht der Experten entwickelt und nicht aus Sicht der Fachleute, die die Kenntnis über die firmeninternen Prozesse mitbringen (Begriffsbildungen, mathematische Methodik und innere Komplexität entstammen der Theorie und nicht der Praxis) Direkte Nutzung in PLM Systemen ist meist nicht möglich Unternehmensmodelle werden unüberschaubar und sind nicht mehr zu pflegen Vorteile von Modellierungssoftware Einheitliche Darstellung Hohe Integration möglich (Prozesse, Daten, Rollen, etc.) Ein Unternehmensmodell theoretisch möglich Seite 81 von 388

82 Prozessmodellierung bei EADS CASSIDIAN Methoden für die Einführung Prozesse Keep it simple Hauptwerkzeuge: Grafische Prozessdarstellung Tabellenkalkulation Textverarbeitung Folienpräsentationen Schwerpunkt liegt eindeutig auf Arbeitsprozessen Konsistenz innerhalb von Teilprojekten wird sicher gestellt Grundlegende Methoden zwischen Teilprojekten festgeschrieben Unternehmensmodell wird nicht angestrebt (Aufwand und Nutzen sind nicht vertretbar) Mit Partnerfirmen wird Abstimmung für wichtige gemeinsame Prozessschritte angestrebt Seite 82 von 388

83 Definition der Daten Modelle Ausgangssituation Methoden für die Einführung Daten Datenmodelle Partnerfirmen PLM Enablers Datenmodell PLM System Neues Datenmodell? Datenmodelle Datenmodelle Altsysteme Altsysteme STEP Modelle PLM Schema, AP 214P Seite 83 von 388

84 Auswahl von Beziehungen zwischen Daten Giver Composed of Methoden für die Einführung Daten Enterprise Uses Supplied by Built by Calls out Receiver Includes Uses Product Described by Releases Work Modeled by Releases Model Derived from Releases Uses Collection Includes Seite 84 von 388

85 Randbedingungen Methoden für die Einführung Daten Datenmodell des PLM Systems Reich mit hinterlegtem Prozesswissen? Kern des PLM Modells sollte nicht geändert werden Soweit wie irgendwie möglich PLM Datenmodell verwenden Rudimentäres Datenmodell Datenmodell nur mit wenigen Objekten implementiert, jedoch sehr flexibel Hoher Aufwand für die Implementierung für komplexe Modelle Datenmodelle der Altsysteme Sind meist nicht komplett dokumentiert Beschreiben Modelle, welche nicht mehr zum PLM Ansatz passen (z.b. zeichnungsbasiert, Management von Stücklisten) Seite 85 von 388

86 Randbedingungen Methoden für die Einführung Daten STEP Datenmodelle Allgemeiner und sehr umfangreicher Ansatz für spezielle Industrien Nicht allgemein anwendbar Manchmal nicht mit den PLM internen Modellen vereinbar (Kernmodell unterschiedlich) Eignung mehr für Datenaustausch, jedoch nicht unbedingt für PLM Implementierung Analyse wertvoll zur Ausarbeitung des Datenmodells PLM enablers Ansatz zur Vereinheitlichung durch wichtige PLM Anbieter Sollte auf alle Fälle begleitend betrachtet werden Seite 86 von 388

87 Randbedingungen Methoden für die Einführung Daten Partnerfirmen Einheitliches Datenmodell wäre wünschenswert Konkurrenz verhindert Offenlegung der Datenmodelle Einigung ist im Rahmen der engen Terminvorgaben meist nicht möglich Einfluss neuer Methoden und Verfahren, z.b. 3D Konstruktion 3D Modell und nicht die Zeichnung ist der Master PLM Paradigma: One Part => One Model => One Drawing Die PLM Produktstruktur ist der Master für die BoM, nicht das BoM Dokument E-CAD Systeme definieren Modelle (Systeme), nicht mehr nur dumme Zeichnungen Strukturierte Dokumente: SGML, XML, HTML, etc. Seite 87 von 388

88 Vorgehensweise zur Entwicklung des Datenmodells Methoden für die Einführung Daten Planung und Durchführung von Workshops z.b. Meta Plan Methode Vorbereitung: Planung der verschiedenen Themenkreise Auswahl der Teilnehmer Vorbereitung der Moderatoren (externe Unterstützung) Planung der notwendigen Work Shops Tagesordnung Ziele definieren Unterlagen vorbereiten Moderatoren bereiten sich gemeinsam vor, d.h. die Rollen der Moderatoren werden definiert, z.b. wer leitet, wer dokumentiert, wer hinterfragt Die Rollen können getauscht werden, jedoch sollte jede Rolle immer besetzt sein. Seite 88 von 388

89 Vorgehensweise zur Entwicklung des Datenmodells Methoden für die Einführung Daten Auswahl der Methode der Darstellung, bekannte Modellierungsmethoden sind: UML (ist ein de facto Standard geworden, kann wesentlich mehr als das reine Datenmodell) EXPRESS und EXPRESS G (ist Standard für STEP basierten Datenaustausch) SysML Wird zunehmend eingesetzt, bedeutet jedoch einen erheblichen Aufwand??? Frage nach Werkzeugen? Es gibt viele Werkzeuge am Markt, jedoch gilt das gleiche wie bei der Prozessmodellierung, IT Unterstützung hilft bei der Konsistenzprüfung Wichtig ist: Grafische Darstellung des Datenmodells und ein detailliertes Data Dictionary, d.h. ein simples Grafik Programm und Textverarbeitung genügen meist, vor allem bei der Diskussion mit den Anwendern Seite 89 von 388

90 Anforderungen an Moderatoren Methoden für die Einführung Daten Fähigkeit zur Moderation Erfahrung in der Datenmodellierung Kenntnis wichtiger Standards bzw. Datenmodelle anderer PLM Projekte Abstraktion aus vielen ähnlichen Anforderungen die allgemein gültigen entwickeln Solange nachbohren, bis eine semantisch klare Beschreibung vorliegt Die Teilnehmer zu Beteiligten machen Möglichst breiten Konsens erreichen Seite 90 von 388

91 Ziele für Datenmodell Methoden für die Einführung Daten Mehr wie ein konzeptionelles Datenmodell für das gesamte PLM Projekt ist am Beginn nicht darstellbar Das konzeptionelle Datenmodell ist die Diskussionsbasis für das Unternehmen: Kann Basis für die Auswahl des PLM Systems sein Im PLM Projekt mit den Anwendern Zur Definition von PLM Teilprojekten Zwischen PLM Projekt mit anderen Projekten Beim Rückblick zur Kontrolle der Zielerreichung Die Umsetzung im PLM Projekt wird sich am internen Datenmodell des PLM Systems orientieren Seite 91 von 388

92 Beispiel aus einem Work Shop Methoden für die Einführung Daten Seite 92 von 388

93 Konfigurations-Management Überblick konzeptionelles Datenmodell Datenmodell Committed Version Dasa-M-Datenmodell C00 Version C-00 vom Dokumenten-Management Methoden für die Einführung Daten Property Relationship persistent Mass Properties Value_Interpretation persistent is descibed by Assembly Component Relationship Quantity Transformationmatrix Ausbaureihenfolge Einbaureihenfolge MeasureUnit persistent Property Relation Function Properties persistent Material Property Class Label Norm persistent User Collected Relationship User Purpose persistent Instance Relationship persistent is described by Document Item persistent Part Item/ Assembly Item PartType PartNumber SiteCode TitleEng TitleGer BoMrelevant Item Properties persistent Item relation description is described by is described by type Product Class persistent Physical Realisation Relation persistent General Classification persistent Specific Classification persistent Requirement Item persistent initializes Requirement Item is represented by is described by Product Item {abstract} transitory Product Class Relationship persistent Instance Item persistent Software Item persistent Function Relationship persistent has properties Instance Relation View persistent general item relationship persistent is sub/superclass associated to classified classified Functional System Item persistent Item Version Type TypeNumber persistent Item Function Relation item has function {abstract} persistent Space Envelope Item persistent End Item Collection Lot Date Block Batch Tail-Number-Range Usage-Profile persistent has Version Elektrik/ Software & Systeme Geometrical Relationship Transformationmatrix persistent End Item {abstract} persistent Planned Effectivity in line in service method of embodiment Position Product Function Ident-Nr persistent Item Relation associated to Item Version Relationship RelationshipType End Item Instance Tail-Number persistent Effectivity Relationship persistent Item Relationship {abstract} persistent Item Version Relation item_exchange Item Version End Item Rel Activity Item persistent has effectivity Item Approval created by created on End Item Relation Effectivity Relation Functional System Relationship persistent Real Effectivity Serial-Number persistent End Item Relationship Type Change Request End Item Rel persistent Effectivity {abstract} persistent Work Order persistent Change Request Effectivity is represented by Described by Document Item persistent Item Version Approved {ordered} ordered by Geometrie DMU ICY Approval {ordered} created on created by used in project is valid is valid Applicability persistent item relation representation Effectivity Approval Approval approval_status persistent related_file exchange Collected Document Relationship persistent collected relation represents relation data/protocol Digital Document Format Approval Relation Request Version Relationship persistent Request Relationship Relation Type persistent Approval Relationship approved on related_date approved by Project Relationship Representation Archive Document persistent actual/target actual/target actual/target sent/received Person Security Type Type Type persistent effects Config Item initialize Request Version Relation Change Request Relation Project Relation sender/receiver exchange_partner change_request_exchange changes Person or Organization {abstract} persistent Change Request Version type Standort persistent Change Request type title id persistent Project id Date date time persistent persistent Document Relationship persistent Document Relation created by created on Physical Model persistent employed at actual/target actual/target Type Type Organization NATO-Code persistent created by created on has Approval has Change Request Version used in project affects influenced by Contract persistent persistent persistent used in project Document Contract Relation is described by is described by Änderungs-Management Seite 93 von 388

94 Office Integration Create Document (z.b. Produkt-Spezifikation) Beispiele für Arbeitsmethoden mit dem PLM System Wenn Sie die Berechtigung besitzen, in PLM Objekte anzulegen, können Sie dies über eine dem Objekttyp entsprechende Create-Funktion. Es wird automatisch ein leeres Office-Dokument angelegt. Pflichtfenster ausfüllen Seite 94 von 388

95 Attribute beim create eines Office Dokuments Beispiele für Arbeitsmethoden mit dem PLM System Seite 95 von 388

96 Office Dokument (Data Item) ist mit dem Dokument Business Item verknüpft Beispiele für Arbeitsmethoden mit dem PLM System Die Office Anwendung verhält sich wie gewohnt, das Data Item wird jedoch vom PLM System kontrolliert. Seite 96 von 388

97 Registrieren von Dokumenten in der Work Location Beispiele für Arbeitsmethoden mit dem PLM System Die Übergabe von Files an PLM kann nur in einem persönlichen, für Sie definierten Directory (Work Location) erfolgen. Der Vorgang der Übergabe heißt Registrieren. Seite 97 von 388

98 Maske für Metadaten (z.b. Excel Dokument in Work Location) Beispiele für Arbeitsmethoden mit dem PLM System Zu Metadaten/ Attribute zählt z.b. der Projektname, die Nummer eines Objekts, Fertigungsort, Werkstoff In dem Ergebnisbrowser sind in der Regel nur ausgewählte Informationen (Metadaten) zusammengestellt Seite 98 von 388

99 Objekt zur Bearbeitung aus dem Vault holen (Check Out) Beispiele für Arbeitsmethoden mit dem PLM System Wenn Sie ein Objekt bearbeiten wollen, müssen Sie das Objekt zunächst aus dem Vault in Ihre Work Location holen = Check Out (nur über entsprechende Bearbeitungsrechte möglich) Seite 99 von 388

100 Objekt an den Vault übergeben (Check In) Beispiele für Arbeitsmethoden mit dem PLM System Wenn Sie mit der Bearbeitung eines Objekts fertig sind, übergeben Sie es an einen Vault = Check In. Damit stellen Sie das Object anderen PLM Anwendern zur Verfügung. In der Dialogbox geben Sie den Namen des Vaults an bzw. wählen diesen aus der angebotenen Selektionsliste aus. Seite 100 von 388

101 Dokumente an Produktstrukturknoten verwalten (Tree view) Beispiele für Arbeitsmethoden mit dem PLM System Mit Drag & Drop (oder per expliziter Anweisung) kann ein Objekt an einen Knoten der Produktstruktur angehangen werden. Objekt-Relationen können ausgeblendet werden Seite 101 von 388

102 Cycle/ Workflow Beispiele für Arbeitsmethoden mit dem PLM System Für die Prozessunterstützung im DMS werden u.a. Life Cycle bereitgestellt. Sie werden auch als Workflow bezeichnet. Ein Dokument, dass in einen Life Cycle steht, wird ausgewählten Personen (bzw. Personenkreisen) für die Durchführung definierter Aufgaben, zugestellt. Die Definition eines Life Cycles führt der PLM- Administrator durch; als Anwender können Sie dann den vordefinierten Life Cycle benutzen. Seite 102 von 388

103 Integration von Anwendungen Beispiel Office Anwendungen Beispiele für Arbeitsmethoden mit dem PLM System Alternativen zur Verwaltung von Dokumenten im PLM Direkte Verwaltung ohne Kopplung mit Strukturen Verwaltung an Knoten der Produktstruktur mit und ohne Gültigkeit, z.b. Spezifikationen, Test Procedures, Test Reports, Zulassungsdokumente Verwaltung über spezielle Knoten (z.b. Paper Work Items (PWI), PWI haben Eigenschaften wie ein Item, sie werden z.b. dann verwendet, wenn die Gültigkeit eines Dokuments unabhängig von der Gültigkeit des Items möglich sein muss) Verwaltung über Dokumentenstrukturen Vorteile der PLM Integration Suche über Querys oder Navigation in Strukturen Elektronische Freigabe und Review Konsistente Versionierung und Kontrolle Verknüpfung mit Konfigurations- und Change Management Methoden Seite 103 von 388

104 Fragen vor IT Architektur Diskussion IT - Architektur Welche Rolle soll das PLM System im Unternehmen spielen? Single source für alle engineering Daten? Wenn ja PLM ist das Unternehmens Back Bone für Produktinformation Möglichst tiefe Integration der Anwendungen Ablösung von Altsystemen Durchgängige Prozessunterstützung über alle Disziplinen Wenn nein PLM als Ablösung der Zeichnungsverwaltung? PLM nur als Laufbett für fertig erstellte Produktinformation? Aufrechterhaltung von Altsystemen und von vielen Schnittstellen? Seite 104 von 388

105 Wissiensmanagment Kommunikationsplattform Kommunikationsplattformen und Integration Umfassendes Wissiensmanagment IT Architektur Gesamtunternehmen Dasa-M IV-Strategie Umfang, Architekturrahmen und Vorgaben Umfang, Architekturrahmen und Vorgaben (Schalenmodell der IV-Architektur) Seite 16 IT-Support Support Support und und Unterstützungsleistungen Unterstützungsleistungen IT - Architektur Workflow-Systeme Wirksysteme Management Management der der Informationsflüsse Informationsflüsse über über Workflow-Systeme Workflow-Systeme Optimierung Optimierung der der Arbeitseffizienz Arbeitseffizienz über über Wirksysteme Wirksysteme Datenverwaltungssysteme IT-Infrastrukturen Management Management der der Datenhaushalte Datenhaushalte über über Datenverwaltungssysteme Datenverwaltungssysteme Leistungsfähige Leistungsfähige und und zukunftssichere zukunftssichere IT-Infrastrukturen IT-Infrastrukturen Für Für jedes Anwendungsfeld bei bei Dasa-M Seite 105 von 388

106 Architektur mit geringer Integration A u t h o r i n g S y s t e m s (Originaldaten) Engineering Applications Design Applications Document Applications IT - Architektur Data Exchange PLM Backbone System Viewing Systems Down Stream Systems Seite 106 von 388

107 Architektur mit hoher Integration A u t h o r i n g S y s t e m s (Originaldaten) Secondary Data Base Engineering Applications Design Applications Local Team Data Manager Document Applications IT - Architektur Data Exchange Advanced Communication PLM Backbone System Viewing Systems Down Stream Systems Seite 107 von 388

108 PLM Architektur EADS DS MAS CATIA CATIA E3D LCABLE 3D Session 3D Viewer VPM DMU- NAV Electric Information System IT - Architektur STEP Product Structures Change & Configuration Mgmt Document Mgmt PLM TeamCenter 2D-Archive (TIFF) ASAP Office Toolset System Development Toolset Logistics Toolset Seite 108 von 388

109 CMII - Configuration Management II Configuration und Change Management CMII (Configuration Management II) ist ein Modell für modernes Konfigurationsmanagement. Es beschreibt, wie ein Unternehmen seine Informationen und Abläufe organisieren muss, damit möglichst keine Korrekturmaßnahmen (z.b. Fehler, Nach- und Doppelarbeiten) entstehen. Das Modell hat zum Ziel, das Ausmaß an Fehlern, Rückrufaktionen, Garantiefällen, etc. auf ein Minimum zu reduzieren, damit keine Ressourcen dafür aufgewendet werden müssen und somit für Innovationen eingesetzt werden können. Das Modell beschreibt sehr genau, was ein Unternehmen tun muss, damit das o.g. Ziel erreicht wird. Es zeichnet sich durch einen sehr hohen Detaillierungsgrad aus, sogar die geeigneten Formulare werden genauestens beschrieben. Anderseits werden in diesem Modell die Formalismen auf ein Mindestmaß reduziert um die Routinetätigkeiten im täglichen Ablauf zu organisieren. Seite 109 von 388

110 CMII - Definition Configuration und Change Management Konfigurationsmanagement nach CMII wird vom Institute of Configuration Management (ICM) folgendermaßen definiert: KM ist der Prozess, der die Erzeugnisse, Einrichtungen und Prozesse einer Organisation in Form von Anforderungen (einschließlich der Änderungen an diesen) verwaltet und gewährleistet, dass die Ergebnisse immer konform mit den verwalteten Anforderungen sind. In dem Prozess werden alle Informationen (=Anforderungen) verwaltet, die einen Einfluss auf die Sicherheit, Qualität, Planung, Kosten, das Betriebs-ergebnis oder die Umwelt haben können. Standard: CMII-100B Seite 110 von 388

111 CMII Prozess (1/2) Configuration und Change Management CMII enthält bewährte Praktiken, mit denen Korrekturmaßnahmen eliminiert werden. Das Institute of Configuration Management verfolgt den Ansatz, dass zuerst Korrekturmaßnahmen eliminiert werden müssen und erst dann der kontinuierliche Verbesserungsprozess gestartet werden kann. Der CMII-Prozess erreicht dieses Ziel, indem nur auf der Basis von dokumentierten Anforderungen gearbeitet wird diese Anforderungen in zentralen Verwahrungsorten strukturiert abgelegt sind dafür gesorgt wird, dass diese Anforderungen stets gültig sind mit Hilfe von Dokumenten, Daten, Formularen und Aufzeichnungen (Records) nachvollziehbar und interpretationsfrei kommuniziert wird die Erfüllung von Anforderungen mit Hilfe von klar und umsetzbaren Akzeptanzkriterien nachgewiesen wird Änderungen so eingearbeitet werden, dass die gesamte Integrität stets gewährleistet ist und alle Anforderungen gültig bleiben. Seite 111 von 388

112 CMII Prozess (2/2) Configuration und Change Management Der CMII-Prozess besteht aus den folgenden Teilprozessen: Definitions- und Strukturierungsprozess Anforderungs-Freigabeprozess Anforderungs-Änderungsprozess Erzeugnis-Änderungs- und Freigabeprozess Links: Institute of Configuration Management: Gesellschaft für Konfigurationsmanagement: Seite 112 von 388

113 Die Rolle von Configuration Management innerhalb von PLM Configuration und Change Management Configuration management configuration, recording, identification, controlling Document - & file management parts information & product structure management Management of data flow workflow & process management Management of data structure project management classification Seite 113 von 388

114 Configuration Management (CM) Definition und Ziel Configuration und Change Management Definition (Auszug aus EN ISO 10007) CM wendet technische und verwaltungsmäßige Regeln auf den Produktlebenslauf (work flow) einer Konfigurationseinheit an CM ist auf Hardware, Software, Dienstleistungen und Zugehörige Dokumentation gleichermaßen anwendbar CM ist ein integraler Bestandteil des Life Cycle Managements Ziel von CM (Auszug aus EN ISO 10007) Das Hauptziel von CM ist die gegenwärtige Konfiguration eines Produkts sowie den Stand der Erfüllung seiner physikalischen und funktionellen Forderungen zu dokumentieren und volle Transparenz herzustellen Weiteres Ziel von CM ist, dass jeder am Projekt Mitwirkende zu jeder Zeit des Produktlebenslaufs die richtige Dokumentation verwendet Seite 114 von 388

115 Configuration Management (CM) Aktivitäten innerhalb des CM Configuration und Change Management Organisation und planung des Konfigurationsmanagements (KMO) Configuration Control/Change Management Configuration Audit Configuration Identification Configuration Status Accounting Configuration Management Activities Seite 115 von 388

116 Organisation und planung des Configuration Management (CMO) Configuration und Change Management Im Rahmen der CMO werden die organisatorischen und technischen Festlegungen zu Configuration/Change Management, Configuration Identification, Configuration Audit und Configuration Status Accounting getroffen. Dies kann sowohl projekt- als auch produktspezifisch erfolgen. Wesentliche Entscheidungen betreffen die Auswahl der einzusetzenden Werkzeuge, die Zuweisung von zu erfüllenden Aufgaben an Aufgabenträger sowie deren Informationsrechte und -pflichten und die Festlegung von Prozessdefinitionen. Zudem fällt die Auditierung des Gesamtsystems zur Überprüfung der Einhaltung und Wirksamkeit der getroffenen Entscheidungen der CMO zu. Seite 116 von 388

117 Configuration Management (CM) Aktivitäten Begriffserklärungen (Teil 1) Configuration und Change Management Change Management (Auszug aus EN ISO 10007) CM schließt folgenden Tätigkeiten ein, die im einzelnen in einem Änderungsverfahren dokumentiert werden sollen: die Änderung dokumentieren und begründen, die Änderungsauswirkungen beurteilen, die Änderungen genehmigen oder ablehnen, die Änderungen einführen und verifizieren, Sonderfreigaben vor und nach der Realisierung bearbeiten. Configuration Identification (Auszug aus EN ISO 10007) CI schließt folgenden Aufgaben ein: Produktstruktur und Auswahl von Konfigurationseinheiten, Dokumentation der Konfigurationseinheiten, Benummerung, Einrichten von Bezugskonfigurationen. Seite 117 von 388

118 Configuration Management (CM) Aktivitäten Begriffserklärungen (Teil 2) Configuration und Change Management Configuration Audit (Auszug aus EN ISO 10007) das Configuration Audit stellt sicher dass, das Produkt seinen vertraglich spezifizierten Forderungen entspricht in seinen Konfigurationsdokumenten richtig dargestellt ist Configuration Status Accounting (Auszug aus EN ISO 10007); CSA schließt folgende Aufgaben ein: Daten aller Konfigurationsidentifizierungen sowie alle Abweichungen von der spezifizierten Bezugskonfiguration verfügbar machen, Rückverfolgbarkeit von Änderungen auf die Bezugskonfiguration Seite 118 von 388

119 Change Management Begriffserklärungen (Teil 1) Configuration und Change Management Änderung (Auszug aus DIN 6789) Eine Änderung ist die vereinbarte Festlegung eines neuen anstelle des bisherigen Zustandes (funktionelle Verbesserung, Fertigungsrationalisierung, Marktbedürfnis, Behebung v. Fehlern, gesetzliche Bestimmungen) Der Lieferant/ Hersteller muss Abläufe zur Kennzeichnung, Dokumentation, angemessene Prüfung und Freigabe aller Änderungen und Modifikationen einführen und aufrechterhalten. Änderung von Dokumenten (Auszug aus DIN 6789) Änderungen von Dokumenten müssen durch dieselben Stellen/ Organisationen überprüft und genehmigt werden, welche die Überprüfung und Genehmigung der Erstausgabe ausgeführt haben. Die Art der Änderung muss im Dokument selbst oder in geeigneten Anlagen ausgewiesen werden. Eine Sammelliste der Änderungen muss eingeführt werden Seite 119 von 388

120 Change Management Begriffserklärungen (Teil 2) Configuration und Change Management Organisatorische Anforderungen an Änderung (Auszug aus DIN 6789) Der Änderungsindex muss zusammen mit der Sachnummer für jeden Gegenstand sowie für seine Dokumentation und alle zugehörigen Änderungszustände eine eindeutige Zuordnung über alle Produkt-Lebensphasen ermöglichen Anforderung an Spezifikationen (Auszug aus DIN 6789) Eine genaue Bezeichnung von Produktart und Anspruchsklasse Prüfungsanweisungen und anzuwendende Spezifikationen müssen enthalten sein Normen bezüglich des Qualitätssystems Seite 120 von 388

121 Anforderungen an Change Management Configuration und Change Management Manufacturing interface relevant_for_interface Technical interface concerned_organization Change_Request (RFA) affected_items derived change requests EF Partner Company affected_documents companion Change_Request (RFA) Seite 121 von 388

122 Change Management Änderungslogik Bisher: Stücklisten und Zeichnungen Heute: nach PLM Einführung Configuration und Change Management Änderungsantrag ja Antrag prüfen Änderung durchführen? Änderungsauftrag Zeichnungen Stücklisten ändern Ablehnungsbegründung nein Änderungsantrag ja Antrag prüfen Änderungsdienst: verteilen von geänderten Zeichnungen + Stücklisten Änderung durchführen? Änderungsauftrag Ablehnungsbegründung nein Produktstruktur & Information-Pack ändern Nach Freigabe sind Änderungen in PLM verfügbar Seite 122 von 388

123 Change Management Der reale, alte Prozess zwischen Partnerfirmen Configuration und Change Management Seite 123 von 388

124 Change Management - Eine Herausforderung Configuration und Change Management company 1 Overall change process Inter-company change procedure company 2 company 3 Intra-company change management Seite 124 von 388

125 Links von Part/Assembly-Objects (Items) zu Work Orders (Authorities) Configuration und Change Management PPof RPof APof Is Planned by Work Order Is Result by Work Order Is Affected by Work Order Seite 125 von 388

126 Links von Work Order (Authority) zu Positionen Configuration und Change Management has PP has AP has RP Work Order has Planned Position Work Order has Affected Position Work Order has Resulting Position Seite 126 von 388

127 Beispiel für eine Work Order (1) Configuration und Change Management Antragsgültigkeit Seite 127 von 388

128 Beispiel für eine Work Order (2) Configuration und Change Management Seite 128 von 388

129 Gültigkeit Configuration und Change Management Definition (Auszug aus EADS M) Die Gültigkeitsangabe identifiziert ein an den Kunden lieferbares Teilprodukt in der Produktstruktur (z.b. ein Flugzeug oder ein Bodengerät). Durch Gültigkeiten wird die Konfiguration im Soll- und Istbauzustand eindeutig für das Teilprodukt definiert. Arten von Gültigkeiten Allgemeine Gültigkeit (verwendungsunabhängig) Datumsgültigkeit ereignisgesteuerte Gültigkeit Losgültigkeit Verwendungsabhängige (Fertigungs-) Gültigkeit Losgültigkeit Serialgültigkeit Definition für Los Gültigkeit Die erlaubten Gültigkeiten werden durch eine untere Grenze (von-gültigkeit) und eine obere Grenze (Bis-Gültigkeit) definiert. Alle erlaubten Gültigkeiten und ihre Zuordnung für ein Teilprodukt müssen in einem Generallieferplan enthalten sein, welcher durch die Programmleitung (PMO) für alle am Produkt beteiligten Bereiche als verbindliche Grundlage freigegeben wird. Seite 129 von 388

130 Gültigkeiten im Eurofighter Projekt Configuration und Change Management Jede Gültigkeit wird eindeutig über einen 2-stelligen alphanumerischen Anwendungscode (Applicability Code) und eine 4-stellige numerische Seriennummer (Sequence Number) definiert. Jeder Anwendungscode identifiziert eindeutig eine Variante. Eine Variante bezeichnet z.b. das Flugzeug (Aircraft bzw. A/C), Role Items (R/I), AGE (Aircraft Ground Equipment) oder Test Items (T/I). Varianten stellen parallele Produktstrukturen dar und können Verweise untereinander besitzen. Die Variante für A/C setzt sich zusammen aus der Nationenkennung (Nation Identifier) und der Produktkennung (Product Identifier). Seite 130 von 388

131 Bezeichnung von Gültigkeiten (Effectivity Designations) Configuration und Change Management Kennung Bedeutung A Österreich (Austria) B Grossbritannien (UK) G Deutschland I Italien S Spanien P IPA (Instrumented Production A/C) T Twin Seater S Single Seater Beispiel: GT1-50 German Twin Seater, Flugzeug 1 bis 50 Seite 131 von 388

132 Änderungsprozess Konstruktion Configuration und Change Management Kunde Kundenforderung durch Change Request/ Change Proposal Bestätigung CR/CP Abgleich zwischen Soll - Ist-Gültigkeit Beschreibt geforderten Änderungsumfang Antragsgültigkeit Abgleich Änderungsgültigkeit Konstruktion Automatische Berechnung Strukturgültigkeit (manuell vom Konstrukteur) Strukturgültigkeit Revisionsgültigkeit Automatische Berechnung aufgrund der festgelegten Strukturgültigkeit Seite 132 von 388 beschreibt tatsächliche Änderungen zwischen davor und danach Ist-Zustand Summe der Verwendungen

133 Änderungsprozess Konstruktionsanlagen Begriffserklärung (Teil 1) Configuration und Change Management Antragsgültigkeit (RFA Effectivity) Die Antragsgültigkeit definiert eine verbindliche Vorgabe des Gültigkeitsbereichs, für den eine Änderung genehmigt ist. Sie wird vom Konstrukteur manuell am Änderungsantrag (RFA) definiert und einmalig bei der Anlage der entsprechenden Work Order nach PLM übertragen. Änderungsantrag Kunde Change Request Change Proposal CR/CP Tool Antragsgültigkeit: - Änderung in PLM nicht möglich - Keine Auswertung Anlage einer RFA/WO und Übertrag nach PLM CR CP RFA Änderungen: Add items Remove items Effectivty Change Items revise QTY Change PLM Seite 133 von 388

134 Änderungsprozess Konstruktionsanlagen Begriffserklärung (Teil 2) Configuration und Change Management Strukturgültigkeit Die Strukturgültigkeit ist als Eigenschaft der Verwendung (Verwendungsrelation) innerhalb des Aspect Level (AL) oder beim Übergang Product Class / AL bzw. AL / Detail Level definiert (vergleiche Product Struktur Vorlesung). Sie wird manuell aufgrund der Antragsgültigkeit der mit dem übergeordneten Bauteil verknüpften Work Order definiert. Eine maschinelle Überprüfung der definierten Strukturgültigkeiten zu einer übergeordneten Baugruppe wird nur insofern vorgenommen, als dass an einer Verwendung keine überschneidenden Gültigkeitsbereiche definiert werden dürfen. Betroffene Teile Work Order beschreibt Antragsgültigkeit Strukturgültigkeit (manuell) Seite 134 von 388

135 Änderungsprozess Konstruktionsanlagen Begriffserklärung (Teil 3) Configuration und Change Management Calculated (Revision) Effectivity Aus den manuell definierten Strukturgültigkeiten wird die auf Bauteil Issues bezogene Calculated Effectivity berechnet. Die Calculated Effectivity stellt eine Bauteilgültigkeit dar. Wird ein Bauteil Issue in mehreren anderen Bauteilen verwendet, so berechnet sich die Calculated Effectivity dieses Bauteils aus der Vereinigungsmenge aller Calculated Effectivites der übergeordneten Baugruppen, eingeschränkt über die an der Verwendung definierten Strukturgültigkeiten. Betroffene Teile Work Order beschreibt Antragsgültigkeit Strukturgültigkeit (manuell) Calculated Effectivity Seite 135 von 388

136 Änderungsprozess Konstruktionsanlagen Begriffserklärung (Teil 4) Configuration und Change Management Änderungsgültigkeit Sie spiegelt die durchgeführten Änderungen eines Teilprodukts wider und ermöglicht so den Abgleich mit der Antragsgültigkeit. Änderungsgültigkeit wird als Differenz zwischen der Revisionsgültigkeit des Produktvorgängers und der Revisionsgültigkeit des Produktnachfolgers definiert. Produktvorgänger und Produktnachfolger besitzen das gleiche Teilekennzeichen, der Produktvorgänger besitzt gegenüber dem Produktnachfolger einen um eine Einheit verringerten Issue. Mögliche Änderungen sind: Teile sind hinzugekommen Teile wurden entfernt Teile wurden revisioniert Teile haben sich in der Anzahl verändert Die Strukturgültigkeit von Teilen wurde geändert Seite 136 von 388

137 Gültigkeiten für lagerfähige Baugruppen Configuration und Change Management Unterhalb einer lagerfähigen Baugruppe gibt es keine Gültigkeitssplits Die calculated (Revision) Gültigkeit wird von den übergeordneten Baugruppen vererbt Seite 137 von 388

138 Gültigkeiten für konfigurierbare Baugruppen Configuration und Change Management Seite 138 von 388 Unterhalb einer konfigurierbaren Baugruppe kann es Gültigkeitssplits geben Die calculated (Revision) Gültigkeit der übergeordneten Baugruppe umfasst all Gültigkeitsbereiche

139 Gültigkeitbereiche für CAD Modelle Configuration und Change Management Seite 139 von 388

140 Ausschnitt Datenmodell Gültigkeiten Configuration und Change Management Seite 140 von 388

141 Freigabe Authority Daten Model (Teil 1) Configuration und Change Management organization STRING STRING INTEGER INTEGER INTEGER document issue item issue item issue 80x signed on behalf of type name day month year signature date approval assignment select is signature for is based on was designed on approval of authority issue decision based on approval is approval of title technical class issue contractual class mass difference decision code approved by approval status STRING STRING STRING STRING REAL STRING organization STRING Seite 141 von 388

142 Freigabe Authority Daten Model (Teil 2) Configuration und Change Management STRING STRING STRING STRING interface type text text type kind of remark interface is for an (INV) has issues description affects partner has design responsible has a design target organization initiated by authority authority issue is originated by design engineering complete indicator change type change number closed indicator basic change indicator is for an (INV) has issues site code approved by approval status STRING STRING STRING STRING BOOLEAN STRING organization STRING Seite 142 von 388

143 Neues Konzept für Configuration und Change Management für kleinere Projekte Configuration und Change Management PIPE Project for the Improvement of EF Processes & tool- Environments for future programs FOCS Function Oriented Configuration System Seite 143 von 388

144 Probleme der Eurofighter CCM Methodik Configuration und Change Management Inflexibles Management der Gültigkeiten durch hartkodierte Zuordnung der Gültigkeiten der Kunden Keine Einführung neuer Kunden ohne erhebliche Anpassungsprobleme möglich. (GS>AS, AS>GS, BS>CS, etc.) Einfacher Tausch von Hauptbaugruppen, sogar innerhalb desselben Blocks von Flugzeugen wird nicht unterstützt. (z.b. GS0027 Fin oder Canopy auf GS0026) Im Falle des Tausches von Hauptbaugruppen oder der Zuordnung von neuen Kunden müssen Bauabweichungen ungültig gemacht und neu geschrieben werden, was eine Verschwendung von Zeit ist und unnötigen Aufwand verursacht. Explizite Kunden Gültigkeiten auf Bauunterlagen könnten den Export schwieriger machen, vor allem dann wenn Export Kunden entsprechende Dokumentation (z.b. für die Endmontage) verlangen. Seite 144 von 388

145 Anforderungen an eine neue CCM Methodik Configuration und Change Management Flexibleres Gültigkeitsmanagement ohne Verlust der vollständigen Kontrolle der Konfiguration. Verbesserung der funktionalen Beschreibung aller Design Aspekte. Bessere Vergleichbarkeit verschiedener Produkte im Hinblick auf das Design und den Bauzustand Unterstützung der Austauschbarkeit von Komponenten mit gleicher funktioneller Konfiguration. Verbesserung der Transparenz der Produktstruktur der Konstruktion. Seite 145 von 388

146 Implementierte Maßnahmen Configuration und Change Management Entfernung der Kunden Gültigkeiten aus der Design Produktstruktur und Management unterschiedlicher Konfigurationen mit funktionalen Baselines. Einführung einer Ebene für Konfiguration. Zuweisung von Kundenaufträgen durch die Zuordnung von Flugzeug Tail Numbers zu funktionalen Konfigurationen; die Strukturgültigkeiten werden dann auf der Basis dieser Zuordnung berechnet und nicht auf der Strukturrelation von Hand eingegeben. Einführung eines teilebasierten DS (Design Standard) und DBS (Design Built Standard) Erprobte Konzepte und Funktionalität sollten erhalten bleiben nicht das ganze System vollständig umgebaut werden. Seite 146 von 388

147 Wesentliche Elemente des FOCS Konzepts Configuration und Change Management PLAN Konsistente Zuweisungen von Kunden Definition von Baselines Product Allocation & Configuration Objects Einfache Einführung/Neuzuweisung von Kunden ermöglichen OEM und Kundengültigkeiten getrennt erfassen bzw. ändern. Functional Product Configurations Kollektor für Design Solutions, Spezifikationen, etc. Baselines für Funktionen erstellen Design Solution Stellt einen Knoten in der Design Produkt Struktur dar wo die Gültigkeiten berechnet werden. Seite 147 von 388

148 Konfiguration zuweisen Kunden zuordnen FOCS Übersicht PLAN Product Allocation & Configuration Objects Configuration und Change Management Sichert Konsistenz von PACOs Erstellung von Baselines Unter RFA Kontrolle WS0001 Ermöglicht einfache Einführung / neue Zuordnung von Kunden Stellt die Konsistenz sicher Wird benutzt um Baselines zu definieren Kollektor für Design Solutions Design Produkt Struktur Change Authorities Functional Product Configurations Seite 148 von 388

149 FOCS Relationen Configuration und Change Management Document Function Oriented Configuration FPC RE,Basic,1,A Official = FALSE Has Informal Doc FPC Contains FPC n : m Has PACO Has Release Relevant Doc FPC PACO PACO-ID = PAC Rev = A Block = 5B MSN = 0003 EndItem ID Industry = GS0003 ToBeBuilt = FALSE Type = End Item Active = FALSE Document Has Release Relevant Doc Document Contains PACO n : 1 Has Informal Doc Document Defines FPC n : m Product-Plan Level = H6 From = 1.1. To = Has Doc Doc. RFA D1 Status = 02 RFA D1 Status = A Has Resulting Items Seite 149 von 388

150 FOCS Configuration Items (CI) und Design Solutions (DS) Configuration und Change Management Uses --- Uses n : m W ,A CI 1 : n W ,A DS <TLFT> FPC RE,Basic,1,A FPC FPC PACO PACO-ID = PAC Rev = A Block = 5B MSN = 0003 EndItem ID Industry = GS0003 ToBeBuilt = FALSE Type = End Item Active = FALSE W ,A Part Has Resulting Items n : m RFA D1 Status = 02 DC = Y Seite 150 von 388

151 Einführung - Grundlegendes Produktstrukturen Produktstruktur Was ist das? Methode zur Strukturierung des Produktes über den ganzen Lebenszyklus (Views) Fortschreibung der Änderungen des Aufbruch des Produktes (Zusammensetzung) und der produktbeschreibenden Daten Strukturierung des Produktes gemäß spezifischen Anforderungen von Disziplinen (Aspekte) Management von Versionen (Varianten) eines Produktes Master zur Berechnung der aktuellen Stücklisten für Produkte bzw. Teilprodukte Informationsdrehscheibe für die Visualisierung von Produktinformationen Seite 151 von 388

152 Einführung Sichten Produktstrukturen Ordungskriterien für Produktstrukturen View: Sicht auf ein Produkt abhängig vom Lebenszyklus - mögliche Strukturierung, As required/functional Was will der Kunde As specified Umsetzung der Anforderungen in Spezifikationen As engineered Umsetzung der Spezifikationen in Produktaufbruch und produktbeschreibende Daten durch den Entwicklungsbereich (Fertigbarkeit ist mit berücksichtigt) As designed / As planned Detaillierte Konstruktion und fertigungsspezifische Ergänzungen und Erweiterungen der Produktstruktur As built Dokumentation der tatsächlich gebauten Produkte As Maintained Fortschreibung der Änderungen des Produkts bis zur Entsorgung Seite 152 von 388

153 Einführung - Aspekte Produktstrukturen Aspekte Spezifische Strukturierung gemäß den Anforderungen einzelner Disziplinen Physical Strukturierung, wie die Einzelteile zu Baugruppen geordnet werden, welche sowohl den digitalen Zusammenbau (=> digital Mock-Up), als auch die Sicht der Fertigung ( logischer Zusammenbau ) integrieren System Strukturierung der Einzelteile gemäß dem Aufbruch in die Systeme eines Produktes (z.b. Elektrik, Klima, Hydraulik, Mechanik) Funktional Welche Funktionen beschreiben das Produkt (z.b. Rollen, Fliegen, Verteidigung, Angriff) die Funktionen können in der Regel durch das Zusammenwirken verschiedener Systeme realisiert werden Zonen Zuordnung von Teilen gemäß dem Aufbruch des Produktes in geometrisch vielgestaltige Bauelemente. Zonen sind unabhängig von Views Seite 153 von 388

154 Einführung - Klassifizierung Produktstrukturen Elemente zur Gestaltung von Produktstrukturen Klassifizierung des hierarchischen Aufbruchs Produkt Class Oberste Elemente der PS, z.b. Waffensystem Eurofighter, Flugzeuge Eurofighter (Twin-, Single Seat), C-Klasse, 3er Serie unabhängig von Aspekt Aspekt Mittlerer Teil der PS, welcher einerseits alle Einzelteile eines Produkts definiert, anderseits nach oben die Zuordnung zu einer Produktklasse sicherstellt Detail Level Teilesee, welcher alle Einzelteile (z. B. Konstruktionsteile, Normteile, Kaufteile (Spezifizierte Teile) als echte Einzelteile bzw. lagerfähige Baugruppen enthält Instance Level Explizite Darstellung aller Instanzen (Verwendungen) eines Einzelteil in einem bzw. mehreren Produkten Seite 154 von 388

155 Einführung - Relationen Produktstrukturen Relationen zwischen Produktstrukturknoten, z.b. Uses: Verknüpft Teile sowohl auf dem Detail Level als auch im Aspekt Physical Berechnungen der Stückliste Has System Verknüpft System und Subsysteme Is part of Zone Zuordnung zu Zonen Zwischen den Aspekten gibt es in der Regel keine Verknüpfungen, da die unterschiedlichen Ordnungskriterien meist keine Zuordnung erlauben (Ausnahme Funktion und Systeme) Relationen, welche die Historie beschreiben, wie: is predecessor of, is successor of Relationen welche beigefügte beschreibende Informationen Strukturieren z.b. is described by, attaches, has information pack Seite 155 von 388

156 Schematische Darstellung des PS Aufbaus Produktstrukturen Seite 156 von 388

157 Grundelemente Produktstrukturen Relations Item 1 is used by assembly Attribute 1 Attribute 2 e.g. name Status uses items Is release relevant for Doc 2 (Word) Doc 1 (Word) Item 2 is described by describing documents Doc 2 (CAD) Seite 157 von 388

158 Definition von Symbolen Produktstrukturen Weapon System Product Class - As designed/physical Product Class - Functional Product Class - System Funtional Item System Definition Item System Useage Item HW System Useage Item SW Detail EPC Designed Detail Bought Equipment Detail Standard Part Detail Standard Part Electric 800-Assembly 400- Assembly Waiver /Deviation As Built Item Seite 158 von 388

159 Überblick Product Class identifies Products like Twin Seater, Single Seater Produktstrukturen Effectivity Aspect Level organises the product according to the needs of different disciplines Seite 159 von 388 Detail Level Storable Items, EPC designed, EPC made, or bought

160 Von der funktionalen zur System Definition Struktur Functional Structure Spec System Definition Structure Produktstrukturen has sub functions is realised by system Requirement Requirement Requirement Requirement Requirement Requirement has sub system Main Hydraulic System (291) Landing Requirement Landing Gear System (528) Seite 160 von 388

161 Von der system definition zur physical, as designed Struktur System definition Product Support System useage as designed physical has sub system has usage implements uses part Produktstrukturen! FCC System Engineering FCC 1 SBC 1 FCC 2 SBC 2 Design Seite 161 von 388

162 Von as designed zu as built as designed physical (all A/C) as built per A/C BT0001 Produktstrukturen uses part BT, GT GT BT Serial No. Is embodied in A/C Is part of A/C GT ASO1 ASO3 ASO2 As planned BT, GT Seite 162 von 388

163 Produktstruktur Elektrik Is sub-system of Electric System FLIR Electric sub-system Has effectivity list Produktstrukturen IT/ST BT/GT SDR EDR Alenia EDR BAES EDR EADS C EDR EADS M Effectivity List Circuit Diagramm Wiring Diagramm Seite 163 von 388

164 Produktstrukturen im Zusammenhang functions Spec is realised by / is realisation of Technical Publication Produktstrukturen Requirement TP DDP SBC system definition Spec has useage/ is useage of system useage is embodied / is emodiment of implements / is implementation of as designed CAD Model Serial No. as built is delivered as / is maintained like Visualiser Actual A/C configuration as maintained Seite 164 von 388

165 Produktstruktur Views einer PS - schematisch Produktstrukturen As designed As Planned As Built Delivered As maintained Wartungsspezifischer Aufbruch W Fertigungsspezifische Baugruppe Waiver/Deviation Seite 165 von 388

166 Definition Produktklasse Produktstrukturen Eine Produktklasse hat einen festgelegten Wertevorrat für Gültigkeiten Ein Gültigkeitssplitt (Strukturgültigkeit) kann erstmals zwischen der Produktklasse und den nächstniedrigeren Produktstrukturknoten auftreten Für eine Produktklasse gibt es einen eindeutig abgegrenzten Aspect Level Es gibt keine Querverbindungen zwischen den PS-Knoten von Aspekten von Produktklassen mit Relationen an denen die Gültigkeit gepflegt wird Aspekte verschiedener Produktklassen können dieselben Teile des Detail Level anziehen Eine Strukturgültigkeit kann letztmals zwischen dem niedrigsten Knoten des Aspect Levels einer Produktklasse und dem obersten Knoten des Detail Levels gesetzt werden Seite 166 von 388

167 Change Management mit Gültigkeitssplitt in der physikalischen Produktstruktur RFA 1: Change Eff RFA 2: Change Eff Produktstrukturen Str. Eff Str. Eff Str. Eff Str. Eff Seite 167 von 388

168 Product Classes Eurofighter Produktstrukturen Seite 168 von 388

169 Physical as designed Twin Seater + PWI Produktstrukturen Seite 169 von 388

170 General Arrangement (GA) Struktur TS Produktstrukturen Seite 170 von 388

171 GA of Equipment Produktstrukturen Seite 171 von 388

172 Beispiel konfigurierbare Baugruppe Produktstrukturen Seite 172 von 388

173 Beispiel lagerfähige Baugruppe Produktstrukturen Seite 173 von 388

174 Installation NLG mit IP Foldern und CAD Modellen Produktstrukturen Seite 174 von 388

175 GA of Electric TS CF Produktstrukturen Seite 175 von 388

176 LOOM GA mit Gültigkeitssplitt Produktstrukturen Seite 176 von 388

177 Get Item Info Einzelteil_1 Produktstrukturen Seite 177 von 388

178 Get Item Info Einzelteil_2 Produktstrukturen Seite 178 von 388

179 base of substitute of defines Partielles Datenmodell_1 Produktstrukturen uses alternate relationship substitute relationship quantity measure unit remark make from relationship transformation matrix has component position assembly relationship with detail level REAL STRING STRING is base of is alternate of measure unit produced quality is component of is for an (INV) has issues authority issue authorized by is assy of item issue item definition produces STRING REAL item part number title security classification part type References protective treatment references finish material spec issue remarks weight unit calculated weight safety classification maturity stage References specification is relevant for item view STRING STRING STRING STRING document has production site organisation view name STRING STRING STRING REAL STRING STRING document STRING Seite 179 von 388

180 Partielles Datenmodell_2 Produktstrukturen assembly relationship within aspect level STRING substitute relationship aspect to detail level remark Authority issue base of substitute of is component of is for an (INV) has issues authorized by transformation matrix has component position item 80x item issue 80x is assy of assembly relationship with detail level item part number title security classification part type references protective treatment is component of has production site issue remarks maturity stage identifiable part indicator quantity measure unit remark STRING STRING STRING STRING document organisation STRING STRING STRING STRING REAL STRING STRING Seite 180 von 388

181 Produktstruktur - Viele Projekte EADS Military Aircraft Eurofighter Produktstrukturen Tornado MIG 29 Mako Seite 181 von 388

182 Namenskonventionen Produktstrukturen Traditionell wurden (werden) sprechende Namen vergeben, z.b. für Eurofighter Teilnummer JXXXYYYYY-801, -401, -001 J= Kennung für Eurofighter Programme XXX=Kennnummer für System, für alle Flugzeugtypen identisch (ATA Kapitel) YYYYY= Nummernbereich für jede Partnerfirma -801: konfigurierbare Baugruppe -401: lagerfähige Baugruppe -001: Einzelteil, von Partnerfirma konstruiert Empfehlung: Sprechende Nummern abschaffen Widerstand aller Voraussicht zu groß Attribute/Klassifizierung verwenden wo immer möglich, jede Funktionalität die auf Auswertung von Teilenummern aufsetzt, hat ihre Grenzen, die ein redesign des PLM Systems notwendig macht Seite 182 von 388

183 Detail Level_1 Produktstrukturen Detail Level Was ist das? Der Detail Level beinhaltet alle Items, welche benötigt werden um ein Produkt einer Produktklasse zusammenzubauen Teileklassen im Detail Level sind: Lagerfähige Baugruppen, d.h. fertig montierte Baugruppen, welche auf Lager gelegt werden können, werden in der Regel vom OEM definiert und gefertigt Equipments oder Spezifizierte Teile meist Zulieferteile - Einzelteile für den OEM, meist Baugruppen für die Zulieferfirma Einzelteile - Nicht weiter zerlegbare Teile, welche meist vom OEM definiert und produziert werden, können jedoch auch im Unterauftrag gefertigt werden Seite 183 von 388

184 Detail Level_2 Produktstrukturen Teileklassen im Detail Level: Normteile: Teile, welche in internationalen Normen (manchmal auch Firmennormen) definiert sind, werden in der Regel in großen Mengen verbaut, Beispiele: Schrauben und Muttern Verschlüsse Stecker Materialien (!?) - genormte Halbzeuge, welche die Ausgangsmaterialien für die Herstellung von Einzelteilen bzw. Baugruppen sind, Beispiele: Bleche, Stangen, Profile Kabel Faserverbund Prepregs Collection Assembly Items (Definierte Anzahl von verschiedenen Normteile zur Fertigung einer Baugruppe) Seite 184 von 388

185 Detail Level_3 Spezialitäten Produktstrukturen Spezielle Teileklassen im Detail Level: Faserverbundbauteile Baugruppen, wenn noch nicht ausgehärtet (verschiedene Faserverbundwerkstoffe (und Waben/Schäume) werden lagenweise gefügt Einzelteil nach Aushärtung (ein nicht mehr zerlegbares Bauteil) Schweißbauteile Mehrere Einzelteile mit eigener Fertigungsvorschrift Ein Bauteil nach Schweißen Flexible Bauteile (unverformter Zustand und verschiedene verformte Zustände nach Einbau, wie z.b. Schläuche, Masseverbindungen) Guss- und Schmiedeteile (zwei verschiedene Einzelteile, eins geht aus dem anderen hervor) Seite 185 von 388

186 Konfigurierbare Baugruppen Produktstrukturen Sind flüchtige Baugruppen, welche während des Zusammenbaus entstehen, d.h. sie sind im Endprodukt nicht mehr als Baugruppe sichtbar Sind wie eine Bauanweisung zur richtigen Auswahl der Teile des Detail Levels für die Fertigung eines Endprodukts zu verstehen Müssen über Change Management sorgfältig kontrolliert und freigegeben werden Sind die entscheidenden Produktstrukturknoten für die Konfigurationskontrolle Geometrie Modelle sollten nicht direkt an konfigurierbaren Baugruppen verwaltet werden Seite 186 von 388

187 Re-Identifizierung und Revisionierung Bauteilklasse Re-Identifizierung Revisionierung Produktstrukturen Konfigurierbare Baugruppe Lagerfähige Baugruppe Zeichnungs- Einzelteil Nur bei massiven Änderungen, entscheidet Konstrukteur Bei Änderung von FF&F Bei Änderung von FF&F Wenn sich die Zusammensetzung der Baugruppe ändert Änderung, FF&F nicht betroffen Änderung, FF&F nicht betroffen Spezifiziertes Teil Bei Änderung der Teils durch Lieferanten Nicht üblich Normteil Nicht üblich Nicht üblich FF&F Form, Fit und Funktion Seite 187 von 388

188 Faserverbundbauteil Produktstrukturen Is Part/Rough Part for Seite 188 von 388

189 Geschweißtes Teil Produktstrukturen Seite 189 von 388

190 Schmiedeteil Produktstrukturen Zeichnung Spant fertig bearbeitet Zeichnung Schmiedeteil Seite 190 von 388

191 Item Instance Produktstrukturen Alle Teile des Detail Level sind so definiert (3D Modelle, Zeichnungen, Spezifikationen, etc.) das jedes für sich allein gefertigt und auf Lager gelegt werden kann. Wird es durch eine Relation über eine oder mehrere Stufen mit einer Produktklasse verbunden, dann spricht man von einer Instance eines Items Weitere Instanzen können in anderen Produktklassen oder durch mehrfache Verwendung in einer oder verschiedenen Assemblies gebildet werden Es ist sinnvoll Instanzen für folgende Klassen im Detail Level zu bilden: lagerfähige Baugruppen, Einzelteile, Equipments, Collection Assembly Items, flexible Bauteile) Für Normteile muss dies geprüft werden (z.b. elektrische Stecker, Relais, etc.) Materialien und Halbzeuge benötigen keine Instanz Seite 191 von 388

192 Use Cases Item Instance Mehrfache Verwendung in Baugruppen J J Produktstrukturen BoM QTY=1 BoM QTY=1 BoM QTY=1 J _001 J _002 J _003 Position Position Position Position entspricht Transformationsmatrix BoM QTY=0 J SOL Seite 192 von 388

193 Use Cases Item Instance Verschiedene Gültigkeit - andere Position J Structure Effectivity Produktstrukturen BoM QTY=1 J _001 SOL BoM QTY=1 J _002 SOL Position Position BoM QTY=0 Use Case auch für flexible Bauteile J Seite 193 von 388

194 Use Cases Item Instance Verschiedene Elektrische Identifier J Produktstrukturen BoM QTY=1 8ES _001 8ES _002 2LH Position BoM QTY=0 BoM QTY=1 Position 5LH Electrical Ident. 8ES SOL Seite 194 von 388

195 Use Cases Item Instance Austauschbarkeit verwendungsabhängig J BoM QTY=1 BoM QTY=1 Produktstrukturen 8ES _001 8ES _002 2LH 5LH Position Position BoM QTY=0 Substitute for this instance SOL 8ES SOL 8ES alternative 8ES SOL Seite 195 von 388

196 Use Cases Item Instance Serialnummern in einer as Built Struktur BT0001 Produktstrukturen J Not embodied embodied J J _001 J _002 J _003 Serial No. 123 Serial No. 456 Serial No. 789 J SOL Seite 196 von 388

197 Mögliche Implementierung von Item Instance J uses item instance is item instance of Position J Produktstrukturen Uses QTY=2 Position J _002 J _001 Uses QTY=1 SOL Position SOL J _003 SOL Position entspricht Transformationsmatrix J SOL Seite 197 von 388

198 Management von STD Teilen, Equipments -80x ASM Die Geometrie aller Standard Teile, Equipments wird in einem CATIA assembly Modell (ASM) zusammengefasst Produktstrukturen -40x ASM -00x SOL -xxx Von EPC definierte details, assys, Jxxxxx, Standard parts, Equipments, CATIA dittos SOL CATIA Model, welches ein CATIA model file darstellt Seite 198 von 388

199 Management von STD Teilen, Equipments in sehr großer Anzahl Produktstrukturen -80x ASM 1:4 ASM 2:4 ASM 3:4 Falls eine sehr große Anzahl von Standard Teilen und Equipments in einer Baugruppe vorkommt, ist es sinnvoll diese auf mehrere ASM Modelle aufzuteilen, eine Zuordnung von Std. Teilen zu ASM Modell ist nicht mehr möglich.??? ASM 4:4? -40x -00x Seite 199 von 388

200 Collection Assembly Items -80x Collection Assembly Items Gültigkeitssteuerung Produktstrukturen -40x ASM -00x SOL -S01 ASM -S02 ASM -S03 ASM -S04 ASM Jedes Assembly modell muss mit einem collection assembly item (CAI) verknüpft sein. Gültigkeiten können dann nur über die Relation zwischen Teilen und nicht mehr an Modellen verwaltet werden. CAI sollten für jedes System erstellt werden, dann können auch Normteile und Equipmments Systemaspekten eindeutig zugeordnet werden. Seite 200 von 388

201 Verwendung von CAI in System- und Zonen Aspekt Items des System bzw. Zonen Aspekts werden nie konfigurierbare Items (-80x) des physical, as designed Aspekts aufrufen, deshalb ist es sinnvoll collection assembly items einzuführen, damit keine Geometrie and den 80x items verwaltet wird. Produktstrukturen -801 System 1 System 2 Zone 1 Zone x -00x -40x -00x ASM SOL -S01 ASM -S02 ASM -S01 ASM -S02 ASM ASM SOL Seite 201 von 388

202 Beispiel für funktionalen Aufbruch Taxying Spec Produktstrukturen has sub functions m.t.b.t.o.* Take Off Requirement Requirement Requirement Requirement * Maximum time before take off 30 min, 50 C, 95% rel. L.F. 400 m 16 to 350 km/h Landing Requirement 500 m ABS, 250 m Bremsfallschirm Requirement 10 to ABS Requirement Requirement 260 km/h Bremsleistung 100 kw Seite 202 von 388

203 Umsetzung von Funktionen in Systemen Functional Structure System Definition Structure Spec Produktstrukturen has sub functions Take Off m.t.b.t.o.* EJ 200Engine System (71) Fuel/Oil Cooling System (287) ABS Main Hydraulic System (291) Landing Landing Gear System (528) Seite 203 von 388

204 Beispiel Systemstruktur bottom up Produktstrukturen Seite 204 von 388

205 Beispiel Systemstruktur top down Produktstrukturen Single Seater und Twin Seater in einer Produkstruktur Seite 205 von 388

206 Prozess für Systemstruktur 1.1. Spezifikation in PLM anlegen Is release relevant for 1.2. System anlegen Has system usage Produktstrukturen 1.3. Spec zu System zuordnen (formale PartDoc Rel) 1.5. LRUs zu System zuordnen Is subsystem of 1.6. Zuordnung zu SBC festlegen Has system usage 1.4. LRUs in PLM anlegen gem. Spec LRU: Line replaceable Unit Seite 206 von 388

207 Elektrische Diagramme in der SD Struktur Is sub-system of has useage Electric System FLIR Electric sub-system Has effectivity list implements Produktstrukturen IT/ST BT/GT SDR EDR Alenia EDR BAES EDR EADS C EDR EADS M Effectivity List Circuit Diagramm Wiring Diagramm Seite 207 von 388

208 Ausschnitt System 91 Elektrik Diagramms Produktstrukturen Seite 208 von 388

209 Elektrik Subsystem FLIR Diagramme DCN: Document change notice ICR: Item Cange Record DIA: LCABLE Diagramm Produktstrukturen Seite 209 von 388

210 Elektrik Diagramme und Gültigkeit Produktstrukturen Seite 210 von 388

211 Auch diese Lösungen funktionieren (manchmal) Produktstrukturen Seite 211 von 388 Anschlusstechnik: Die präzise Dokumentation an jeder Leitung sichert den schnellen Zugriff auf jeden Anschluss. Die massive Bauweise des Gehäuses wehrt jegliche Manipulation an der sensiblen Technik ab. Verlegung des Kabelbündels! Durch die sehr transparente Kabelführung gewinnt man schnell einen Eindruck über die Struktur des Netzes.

212 Überblick Kabelbündel im Eurofighter Verlegung des Kabelbündels! So schaut es dann wirklich aus. Produktstrukturen Seite 212 von 388

213 Übersicht Elektrikprozess PLM ist maßgeblich für Konfiguration (Gültigkeiten) und Änderungskontrolle Produktstrukturen LCable (ECAD) 2D functional wiring diagram PLM-EIS Stammdatengenerierung / Verwaltung PLM Seite 213 von 388

214 PS Elemente für Rumpfmittelteil (RM) Elektrik Prozess PLM - PLM-EIS - Rumpfmittelteil Produktstrukturen 5 Länder 9 Versionen (SS / TS) Systeme pro RM Serie 82 FTI 29 erzeugte Diagramme Serie 450 FTI 210 Retro 55 Kabelbündel pro RM Serie 130 erzeugte Kabelbündel Serie >2000 FTI >2000 z.zt. gültige Konfigurationen Serie 1200 FTI 350 z.zt. gültige Kabelb. Serie 470 FTI 560 Retro 95 vorhandene Gültigkeiten Serie 4400 FTI 1200 Seite 214 von 388

215 SD und SU Fuel System (Ausschnitt) Produktstrukturen Seite 215 von 388

216 Get item Info System Useage SBC: System Breakdown Code Produktstrukturen PLM interner Eindeutiger Schluessel, automatisch von Sysem erzeugt Spezifikation und Elektrischer Ident. Zuordnung von Zone(n) Zuordnung zu Klappe/Deckel Seite 216 von 388

217 SU Relation zu as designed und Calc. Effectivity Produktstrukturen Seite 217 von 388

218 SU Relation zu as designed und Calc. Effectivity Produktstrukturen Seite 218 von 388

219 as designed => as planned => as built as designed physical (all A/C) as built per A/C BT0001 Produktstrukturen uses part BT, GT GT BT Is embodied in A/C Is part of A/C GT ASO1 ASO: Assembly Stage Operation BT, GT ASO3 ASO2 As planned Seite 219 von 388

220 Abwägung as designed <=> as planned Produktstrukturen Zwei gegensätzliche Ansätze zur Verwendung von PLM Systemen As designed ist ein Kompromiss, welcher die PS bereits nach fertigungstechnischen Gesichtspunkten strukturiert [as planned existiert nicht im PLM sondern nur in den MRP (Manufacturing Ressource Planning) Systemen] Vorteil: Leichter konsistent zu haltende PS Nachteil: Kompromiss für alle und niemanden - Anforderungen der Konstruktion und Fertigung gegensätzlich As designed dient ausschließlich den Anforderungen der Konstruktion, as planned ausschließlich der Fertigung, die as planned PS bildet den Fertigungsablauf nach Vorteil: Klare Strukturen für Konstruktion u. Fertigung Nachteil: Zwei Strukturen müssen konsistent gehalten werden Seite 220 von 388

221 Problematik As designed <=> As planned Änderungsauftrag: re-identifizieren re-identifizieren Ausgangszustand: Beide Strukturen sind freigegeben ist bereits für GT1 gefertigt ist im Zusammenbau für GT1 Produktstrukturen GT GT GT GT As Designed As planned Seite 221 von 388

222 Problematik As designed <=> As planned Produktstrukturen As designed: Re-identifizierung durchgeführt As Planned: kann nicht re-identifiziert werden, da bereits gefertigt Gültigkeitssplitt in as planned Später muss für GT1 Teil gegen GT ausgetauscht werden (Retrofit) GT GT GT GT As Designed As planned Seite 222 von 388

223 Baseline Konzept als Basis für As Built workshare A/C BAe Final Assy embodiment in -8xx ToConfirm (Structured Baseline) Produktstrukturen single parts single parts C/F AUG C/F MAN embodiment in -8xx embodiment in -8xx single parts S/A BAe single parts Section3 BRE Seite 223 von 388

224 Produktionskreislauf IST SOLL DBS Design Build Produktstrukturen Endprodukt Einbau- GT 0001 Standard MCA Produktstruktur MAN auftrag Brutto-/Nettobedarf Seite 224 von 388 W/D Teile / Baugruppen Tt t AUG Bestellabruf MCA Manufacturing Change Authority

225 Methode für Einbaubestätigung As built as designed PS SBSE PS as Built PS Produktstrukturen RFA Seite 225 von 388 resulting Jxyx-801 AUG Jyyx-001 BAES Jxxx-801 MAN Jxxy-801 MAN to confirm MAN to confirm Jxxy-801 AUG Jxyy-001 AUG SBSE1 GT1 F/F MAN SBSE1 GT1 BAES SBSE1 SBSE1 GT1 GT1 A/C A/C SBSE1 GT1 C/F SBSE1 GT1 AUG as confirmed SBSE1 GT1 R/F SBSE1 GT1 BRE Jxxx-801 MAN Jxxx-801 MAN Jxxx-801 MAN as confirmed Jxxx-801 MAN SBSE: Structured Baseline, Single Effectivity A/C: Aircraft complete F/F: Front Fuselage C/F: Center Fuselage R/F: Rear Fuselage

226 Beispiel SBSE Produktstrukturen SBSE: Structured Baseline Single Effectivity Seite 226 von 388

227 As built to confirm - as confirmed Produktstrukturen Seite 227 von 388

228 Beispiel As Built PS Produktstrukturen End Item Seite 228 von 388

229 As Built PS: Relation Is used by as built Produktstrukturen Seite 229 von 388

230 As built Beispiel für Serialnummer und Bauabweichung Abfrage nach as built informationen true oder false Produktstrukturen Seite 230 von 388 Zuordnung von Serial number Items zu as built Items kein Attribut wegen Item instance Zuordnung von W/D zu As designed (Genehmigung des W/D) und zu as Built items (Verbaung des W/D) in end item

231 Übersicht Datenmodell Waiver/Deviation Prod. Structure Data-Exchange W/D Data-Exchange W/D Separate Object/ Icon in PLM Produktstrukturen CATIA 3-D Modell WD Attachment File Name 1 doc / txt... WD Attachment File Name 2 jpg... WD Attachment File Name 3 cgm... CATIA Data-Exchange pdf Preparation of the attachments outside PLM tif Seite 231 von 388

232 Relationen zwischen verschiedenen Produktstrukturen Produktstrukturen Seite 232 von 388

233 Produkt Struktur Relationen Auswahl von zwei von vier Menüpunkten Produktstrukturen Seite 233 von 388

234 System Useage für Fuel Gauging... Produktstrukturen Seite 234 von 388

235 Relationen zwischen SU und Physical Items Produktstrukturen Seite 235 von 388

236 Management von Software Items und dazugehöriger Hardware Produktstrukturen Baseline Container für alle HW items mit resident and non-resident (downloadable) software Konfigurierbare Baugruppe für alle Software Items Teilenummer für CD auf der die Software ausgeliefert Wird, Zuordnung von Serialnummern PSC: Production System Configuration (SW und HW Seite 236 von 388

237 Konfigurierbare Baugruppe für SW items Produktstrukturen Seite 237 von 388

238 Software Items mit Hardware Items per Runs on Hardware verknüpft Produktstrukturen Seite 238 von 388 Hex Ident sind Attribute, mit denen sich die hardware und die software items beim Start (laden der Software) melden müssen, das Flugzeug kann nur dann gestartet werden, wenn alle Zuordnungen stimmen.

239 Baseline container für alle HW items mit resident and non-resident SW Produktstrukturen Seite 239 von 388

240 Hardware Items mit Software Items per Has downloadable software verknüpft Produktstrukturen Seite 240 von 388

241 Nachweisführung mit Has Release Relevant Doc zu Items Dokumenten Produktstrukturen Seite 241 von 388

242 Dokumentenstruktur mit Has Release Relevant Doc zur Nachweisführung Produktstrukturen Seite 242 von 388

243 Weapon System Qualifikationsdokument Declaration of Design and Performance Produktstrukturen Gesamtdokument aus Verschiedenen PDF Files zusammengestellt. Seite 243 von 388

244 Retrofit: Umrüstung eines Luftfahrzeuges nach Auslieferung an den Kunden (Upgrade) Produktstrukturen Welche Gründe gibt es für Retrofit: Kunde wünscht bessere Funktionalität (Upgrade) Spezifikation wurde nicht eingehalten, daher muss der Hersteller Nachbesserungen vornehmen. Traditionelles Vorgehen: Differenz -Zeichnungssatz, beschreibt die Retromaßnahme als Delta (add, remove, rework) Nachteil: Viele Baugruppen werden oft durch Retro beaufschlagt, der absolute Zustand ist wegen der ständigen Differenzdarstellung nur noch schwer nachzuvollziehen Retrofit und PLM PLM eignet sich besonders für 100% Darstellung Digital Mock-up benötigt 100% Produktstruktur Änderung der Arbeitsmethode ist daher eine fast Zwangsläufige Folge der PLM-Einführung Seite 244 von 388

245 Retro für Inline: Ausgangs-Situation - Line-Design und Retro-Installation Line Design GT1+,BT1+ J5321xx-801,D Retro Installation J0082xx-801,A Produktstrukturen Line Design Gültigkeiten 01: GT : GT 5+ 03: BT 1+ J5322xx-801,C 01 01, ,02 J J J J J Line Design: Sollvorgabe (100 %) für physikalische Produktstruktur zum Zeitpunkt der Fertigstellung eines Produkts Retro Design: Sollvorgabe (100%) für physikalische Produktstruktur durch Einarbeitung einer Änderung nach Auslieferung and den Kunden. Retro Installation: Beschreibung der Tätigkeiten, die notwendig sind um eine Retrofitmaßnahme durchzuführen. Die Retrofit Installation ist daher eine Differenzdarstellung Seite 245 von 388

246 Retro für Inline: Schritt 1 - Re-Identifizierung der betroffenen Baugruppe Line Design Line Design GT1+,BT1+ J5322xx-801,C J5321xx-801,D Is Re-Identified by Retro Design Is Base for J5322xx-851,A Is Result of Retro Installation J0082xx-801,A Produktstrukturen Gültigkeiten 01: GT : GT : BT 1+ J , ,02 J J J J Gültigkeiten 01: GT : GT : BT 1+ J , ,02 J J J J Neue Struktur- Relationen: Is Base for Verknüpfung zwischen Ausgangszustand und Reto Installation Is Result of: Verknüpfung zwischen Zustand nach Durchführung der Retofitmaßnahme und Retro Installation Seite 246 von 388

247 Retro für Inline: Schritt 2 - Einschränken der Strukturgültigkeiten der Retro-BG Line Design GT1+,BT1+ J5321xx-801,D Is Base for Retro Installation J0082xx-801,A Line Design J5322xx-801,C Retro Design Is Re-Identified by J5322xx-851,A Is Result of Produktstrukturen Gültigkeiten 01: GT : GT : BT 1+ J J J Gültigkeiten 01: GT J J J J ,02 J J Seite 247 von 388 Line Design: Gültigkeit meistens 1+ Retro Design: Gültigkeit immer eingeschränkt

248 Retro für Inline: Schritt 3 - Einhängen der Retro-BG in die übergeordnete BG mit Retro-Gültigkeit Line Design GT1+,BT1+ J5321xx-801,D GT1-4 Is Base for Retro Installation J0082xx-801,A Produktstrukturen Line Design Gültigkeiten 01: GT : GT 5+ J5322xx-801,C 01 03: BT 1+ J ,02 03 Retro Design Is Re-Identified by J J Gültigkeiten 01: GT 1-4 J5322xx-851,A J J Is Result of J J ,02 J J Seite 248 von 388

249 Retro für Inline: Schritt 5 - Bearbeiten der Retro-BG - Darstellung des 100% Zustandes nach Änderung Line Design GT1+,BT1+ J5321xx-801,D GT1-4 Is Base for Retro Installation J0082xx-801,A Produktstrukturen Line Design Gültigkeiten 01: GT : GT 5+ J5322xx-801,C 01 03: BT 1+ J ,02 03 Retro Design Is Re-Identified by J J Gültigkeiten 01: GT 1-4 J5322xx-851,A 01 J J Is Result of Position gelöscht J Position hinzugefügt J ,02 J Is Reworked by 01 J Position umgearbeitet Seite 249 von 388

250 Retro für Inline: Schritt 6 - Delta-Berechnung Inline- BG zu Retro-BG Line Design GT1+,BT1+ J5321xx-801,D GT1-4 Is Base for Retro Installation J0082xx-801,A Line Design J5322xx-801,C Retro Design Is Re-Identified by J5322xx-851,A Is Result of Produktstrukturen Gültigkeiten 01: GT : GT : BT 1+ J , J J J J Gültigkeiten 01: GT Is Reworked by 01 J J J J Added J Added J Removed J Removed J Die Delta Berechnung Wird durch das PLM System auf Grund der Relationen und unter Beachtung der Gültigkeiten und der Anzahl der Teile auf den Relationen durchgeführt. Erleichterung für den Konstrukteur und Qualitätsverbesserung. Seite 250 von 388

251 Retro für Inline: Schritt 7 - Übertragen des berechneten Deltas in die Retro Installation Line Design GT1+,BT1+ J5321xx-801,D GT1-4 Is Base for Retro Installation J0082xx-801,A Line Design J5322xx-801,C Retro Design Is Re-Identified by J5322xx-851,A Is Result of Produktstrukturen Gültigkeiten 01: GT : GT : BT 1+ J ,02 03 J J Gültigkeiten 01: GT 1-4 Removes Part 01 J J Adds Part J J J Is Reworked by 01 J Reworks Part Seite 251 von 388 Neue Relationen: adds, removes und reworks part

252 Retro für Inline: Schritt 8 - Generieren des Add/Remove-Blocks Der Add/Remove Block wir automatisch aus den hinterlegten Strukturinformation generiert, ist nur richtig, wenn Produktstruktur korrekt. Retro Installation J0082xx-801,A Produktstrukturen Seite 252 von 388

253 Retro nach Retro Prozess in PLM Produktstrukturen Erste Retromaßnahme ist definiert, welche Möglichkeiten gibt es für nachfolgende Retromaßnahmen? Neue Retro betrifft nur Line Design Baugruppe d.h. zusätzliche Flugzeuge werden nachgerüstet. Neue Retro betrifft nur Retro Design Baugruppe d.h. dieselben Flugzeuge erhalten eine zusätzliche Nachrüstung. Neu Retro betrifft Line Design und Retro Design Baugruppe d.h. einer neuer Nachrüstungsstandard für zusätzliche Flugzeuge und die bereits nachgerüsteten Flugzeuge wird definiert. Da durch eine Retro Installation viele Design Installations modifiziert werden können, gibt es natürlich auch Mischformen obiger Varianten. Alle Möglichkeiten müssen durch PLM optimal unterstützt werden. Seite 253 von 388

254 Retro für Retro: Ausgangs-Situation - Erste Retro- Maßnahme liegt bereits vor Produktstrukturen Line Design GT1+,BT1+ J5322xx-801,C Gültigkeiten 01: GT : GT : BT 1+ 04: GT11+ J5322xx-801,D 01 01,02 03 J5321xx-801,D Is Re-Identified by J J J Retro Design Gültigkeiten 01: GT 1-4 GT1-4 J5322xx-851,A 01 Is Base for Is Result of Retro Installation J J J0082xx-801,A Retro Installation J0084xx-801,A J J ,02 J J Seite 254 von 388

255 Retro für Retro: Schritt 1 - Revisionieren der betroffenen Baugruppe Produktstrukturen Line Design GT1+,BT1+ J5322xx-801,C J5322xx-801,D Gültigkeiten 01: GT : GT : BT 1+ 04: GT ,02 03 J5321xx-801,D J J J Retro Design Gültigkeiten 01: GT 1-4 J5322xx-851,A 01 GT1-4 J J GT1-4 Retro on Retro Design Revise Is Base for Gültigkeiten 01: GT 1-4 J5322xx-851,B 01 Retro Installation J0084xx-801,A Is Result of J J J J J ,02 J J J Seite 255 von 388

256 Retro für Retro: Schritt 2 - Erweitern der Struktur der Retro-BG Kopieren der PS mit Gültigkeit Copy Effectivity Symbols Part Number Source J Part Number Target J Produktstrukturen --- Select Area --- ES select ES -> <- copy ES VS GT 04 copy ES with structure relations --- Edit Area new Effectivity Symbol 02 Effectivities From To affected by current ES Component ES J532xxx2-401 #01#02 J532xxx5-001 # View Area Effectivity Symbols on Source Part ES copied? Effectivity Ranges 01 no GT0001-GT yes GT0005-GT no BT0001-BT no GT0011-GT9999 ES new? Effectivity Ranges 01 no GT0001-GT yes GT0005-GT0010 Effectivity Symbols on Target Part OK Cancel Seite 256 von 388

257 Retro für Retro: Schritt 2 - Erweitern der Struktur der Retro-BG Line Design Gültigkeiten 01: GT : GT : BT 1+ 04: GT11+ Produktstrukturen GT1+,BT1+ J5322xx-801,D 01 01, ,02 J5321xx-801,D J J J J J Retro Design Gültigkeiten 01: GT 1-4 J5322xx-851,A 01 GT1-4 Revise J J J J GT1-10 Is Base for Retro on Retro Design J5322xx-851,B Gültigkeiten 01: GT : GT Retro Installation J0084xx-801,A Is Result of J J J J J J Seite 257 von 388

258 Retro für Retro: Schritt 4 - Bearbeiten der Retro-BG Line Design GT1+,BT1+ J5322xx-801,D J5321xx-801,D Is Re-Identified by Retro Design GT1-4 J5322xx-851,A Retro on Retro Design Revise GT1-10 Retro Installation J0084xx-801,A Is Base for J5322xx-851,B Is Result of Gültigkeiten 01: GT : GT : BT 1+ 04: GT ,02 J J Gültigkeiten 01: GT J Gültigkeiten 01: GT : GT J J Produktstrukturen 03 01,02 J J J J J J Re-Identify Retro Rework J J Reworked J Removed 02 J Seite 258 von 388

259 Produktstrukturen Retro für Retro: Schritt 5 - Delta-Berechnung Inline- BG/Retro-Vorgänger zu Retro-BG Line Design GT1+,BT1+ J5322xx-801,D Gültigkeiten 01: GT : GT : BT 1+ 04: GT Removed Removed 01,02 01,02 J5321xx-801,D Is Re-Identified by J J J J J Retro Design J5322xx-851,A Gültigkeiten 01: GT 1-4 GT J J J J ES 01 Retro-Vorgänger: Removed J Added J GT1-10 Retro on Retro Design Revise J5322xx-851,B Gültigkeiten 01: GT : GT 5-10 Re-Identify Retro Rework Removed ES 02: Line-Vorgänger: Removed J Added J Removed J J J J J J Added Seite 259 von 388

260 Produktstrukturen Retro für Retro: Schritt 6 - Erzeugung der Relationen zwischen der Retro Installation und den betroffen Teilen der PS Line Design Gültigkeiten 01: GT : GT : BT 1+ 04: GT11+ J5321xx-801,D GT1+,BT1+ J5322xx-801,D 01 01, ,02 Retro Design J J J J J GT1-4 J5322xx-851,A Gültigkeiten 01: GT Retro on Retro Design GT1-10 J5322xx-851,B Gültigkeiten 01: GT : GT J J J J Retro Installation J J J J J J0084xx-801,A Rework 02 Remove Seite 260 von 388

261 Retro für Retro: Schritt 7 - Generieren des Add / Remove Blocks Der Add/Remove Block wir automatisch aus den hinterlegten Strukturinformation generiert, ist nur richtig, wenn Produktstruktur korrekt. Retro Installation J0082xx-801,B Produktstrukturen Seite 261 von 388

262 Gegenüberstellung einer gefilterten Produktstruktur, nur line und nur retro Line and Retro Line Retro Produktstrukturen Seite 262 von 388

263 Retro Installation mit add, remove, rework relationen Produktstrukturen Seite 263 von 388

264 Retro Installation mit is Base of und is Result of relationen Produktstrukturen Seite 264 von 388

265 Retrofit Nachrüstung von Kabelbündeln Produktstrukturen Seite 265 von 388

266 Produktstruktur Items zur Ergänzung der reinen Stücklistenstruktur Produktstrukturen Warum ist die Einführung dieser Items notwendig und sinnvoll? Die uses Produktstruktur definiert die Bauvorschrift, daher, kann jedes Teil nur entsprechend der Verbauung aufgerufen werden. Für Items, welche logisch zusammengehören, jedoch in unterschiedlichen Baugruppen bzw. unterschiedlichen Orten verbaut werden, sind Kollektoren sinnvoll; Beispiele dafür sind: Hardware Baseline Production System Configuration alle Software beaufschlagten Hardware Items, welche zu einer Konfiguration gehören. Index of Diagrams: Zusammenstellung von Wiring Diagrams und dazugehörigen Circuit Diagrams, welche eine Funktionalität beschreiben Index of Looms: Alle Kabelbündel, welche zu einer Funktionalität gehören und einem Index of Diagrams entsprechen. Seite 266 von 388

267 Index of Diagrams Produktstrukturen Seite 267 von 388

268 Index of Looms Produktstrukturen Seite 268 von 388

269 Verknüpfung Index of Diagrams mit Index of Looms Compatible Produktstrukturen Die Verknüpfung von Index of Diagrams und Index of Looms wird benutzt um Indexe mit äquivalenter Funktionalität zuzuordnen. Auf Grund der Zuordnung werden in der Elektrik Datenbank Prüfungen auf Konsistenz der Daten bei der Freigabe durchgeführt. Die Indexe sind auch die Basis für den Datenaustausch von AECMA Messages mit den Partnerfirmen. Seite 269 von 388

270 Verschiedene Begriffe zum Thema Los Produktstrukturen Fertigungsrelevante Losgrößen Tranche Vertragsrelevante Losgrößen, der Eurofighter Vertrag wird in 2 bis 3 Tranches gestaltet Batch: Eine Tranche ist in mehrere Batches aufgeteilt Block: Ein Block entspricht dem kleinsten Planungslos der Fertigung Baselines: Zulassungsrelevante Losgrößen Beschreibt eine bestimmte Funktionalität, welche erreicht und nachgewiesen werden muß. Eine Baseline kann einen oder mehrere Blocks beinhalten. Eine Baseline kann Versionen haben. Seite 270 von 388

271 Beispiele für Los W/S Tranche T R A N C H E 1 Batch B A T C H 1 B A T C H 2 Block IPA 1/2/3 1 1B 1C IPA 4/5 2 2B 5 Baselines - In Line C+D E E2 E3 E3+ F F2 (2) I - (3) F2R Baselines - Retrofit FR IR Produktstrukturen Baselines - Role Equipment RE RE RF No. off A/C (1) Lead A/C (1) PT001 BT001 ST002 SS001 PS002 ST004 GS012 BS026 Baseline BT from to GT from to IT from to ST from to C+D E BT 1 4 GT 1 3 IT 1 2 ST 1 1 E2 BT 5 11 GT 4 8 IT 3 6 ST 2 3 E3 F+E4 ST 4 5 F BT GT IT 7 7 F2 BT GT 9 12 IT 8 8 ST 6 7 Seite 271 von 388

272 Get Item Info Index of Diagrams Effectivity Statement für Baseline Produktstrukturen Seite 272 von 388

273 Digital Mock-Up Digital Mock-Up Seite 273 von 388

274 CAD Integration und Digital Mock-Up Definition Digitales Mockup Digital Mock-Up Ein Digitales Mockup ist eine vollständige, virtuelle Arbeitsumgebung für die gesamte Prozesskette der dreidimensionalen Entwicklung, Fertigung und Betreuung von komplexen Produkten mit integrierter Gültigkeits- und Variantensteuerung Notwendige Voraussetzungen dazu sind: Das Master im gesamten Prozess ist das 3D-Modell Absolute Einhaltung der pro Teil ein Modell - Regel Verwendung von Item Instance Festlegung und strikte Einhaltung von Modellierungsrichtlinien Die Zeichnung (wenn überhaupt notwendig) wird vom 3D- Modell abgeleitet Hoher Detaillierungsgrad Seite 274 von 388

275 CAD Integration und Digital Mock-Up Beispiel Bugfahrwerk Digital Mock-Up Seite 275 von 388

276 CAD Integration und Digital Mock-Up Notwendigkeit Digital Mock-Up Extrem komplexes Produkt mit hoher Komponentenzahl und hoher Packungsdichte Entwicklung von Einzelkomponenten sind nur in ihrem Umfeld möglich Entwicklung eines Militärflugzeugprototypen ist nur mit Hilfe von mehreren mechanischen Attrappen möglich Hoher Änderungsgrad beim Schritt vom Prototypen zum Serienprodukt Weiterentwicklungen (Upgrades) notwendig während der gesamten Lebenszeit Zunehmende Variantenvielfalt im Laufe der Nutzung => Mechanische Attrappen und deren Aufrechterhaltung sind extrem teuer Seite 276 von 388

277 CAD Integration und Digital Mock-Up Anforderungen an DMU System Digital Mock-Up Handhabung von ca von EADS M modellierten Bauteilen in der Sektionsentwicklung (z.b. Mittelrumpf) Handhabung von ca von Partnerfirmen modellierten Bauteilen in der Gesamtflugzeugentwicklung Bereitstellung aller notwendigen Analysen für die integrierte Entwicklung Verarbeitung einer hohen Variantenvielfalt während einer Produktlebenszeit von über 30 Jahren Einwandfreie integrative Verarbeitung von Ersatz- und Originalgeometrie mit Gültigkeiten und Variantensteuerung Produktstrukturgesteuerte Navigation in allen Prozessphasen notwendig Seite 277 von 388

278 CAD Integration und Digital Mock-Up 3D Master und abgeleitete Zeichnung Solid-E Master Modell mit abgeleiteter Zeichnung Digital Mock-Up Seite 278 von 388

279 CAD Integration und Digital Mock-Up Beispiel Avionik-Sektion ohne Geräte Digital Mock-Up Seite 279 von 388

280 CAD Integration und Digital Mock-Up PLM Anforderungen für Physical PS Handling Digital Mock-Up Waffensystem (alle Flugzeugvarianten) Teile Elemente 1,5 Millionen links Ein Flugzeug (EF-TS Historie) Durchschnittlich 4 Ausgaben pro Teil Teile 200 Verbinder ( Modelle) 150 Gbyte Daten Ein Zustand eines Flugzeugs (EF-TS letzte Änderung) Teile ( Modelle) Verbinder Produkt-Struktur Navigation Product structure handling Database- and Memory handling Maximum Graphic handling Seite 280 von 388

281 CAD Integration und Digital Mock-Up Arbeitsmethodik und Werkzeuge Ein Zustand eines ganzen Flugzeuges Ein Bauraum eines Flugzeuges Umgebung einer Teilegruppe Umgebung eines Teiles Digital Mock-Up Teile Verbindungselemente Produkt Struktur Navigation Suche nach vordefinierten Zonen Suche nach Individuell definierten Zonen Nachbarschaftssuche Montage- und Demontage- Analysen Kollisionsuntersuchungen Mess-Analysen Zugänglichkeits- Analysen CATIA- Konstruktion 50 Teile SOLID-E 100 Verbinder Ersatzgeometrie Maximale Anforderung Ersatzgeometrie Ersatzgeometrie CATIA model handling Seite 281 von 388

282 CAD Integration und Digital Mock-Up Zusammenspiel PS & geometrische Navigation Digital Mock-Up Navigation mit Hilfe der Produktstruktur Ersatzgeometrie Seite 282 von 388

283 CAD Integration und Digital Mock-Up Bauraumsuche Digital Mock-Up Bauraumsuche für Hydraulikleitung Seite 283 von 388

284 CAD Integration und Digital Mock-Up Nachbarschaftssuche Digital Mock-Up Nachbarschaftssuche (Radius 20mm) für Hydraulikleitung Seite 284 von 388

285 CAD Integration und Digital Mock-Up Montageanalyse Digital Mock-Up Montage- Analyse Seite 285 von 388

286 CAD Integration und Digital Mock-Up Demontage Analyse Digital Mock-Up Demontage- Analyse Seite 286 von 388

287 CAD Integration und Digital Mock-Up Kollisionsanalyse Digital Mock-Up Kollisions- Analyse Seite 287 von 388

288 CAD Integration und Digital Mock-Up Kollision zwischen Struktur & Elektrik Digital Mock-Up Frühzeitiges Erkennen von Problemen Seite 288 von 388

289 CAD Integration und Digital Mock-Up Methodik Absolute Positionierung Z Y 0 Digital Mock-Up Absolute Positionierung aller Teile zum Flugzeugnullpunkt Vorteile: Alle Teile sind eindeutig positioniert Nachteile: Teile mit Mehrfachverwendung sind im Nullpunkt Baugruppen können nicht gemeinsam verschoben werden, alle Teile einer Baugruppe müssen einzeln neu positioniert werden X Seite 289 von 388

290 CAD Integration und Digital Mock-Up Methodik Relative Positionierung Digital Mock-Up Relative Positionierung: Alle Bauteile werden relativ zum Nullpunkt der nächsten Baugruppe positioniert, mehrfache relative Positionierung ist möglich Z Z X X Y Z X Y Z X Y Y Vorteile: Baugruppen können insgesamt verschoben werden, deutlich reduzierter Aufwand Nachteile: Komplizierter gegenüber absoluter Positionierung, mehrfache Transformationen Seite 290 von 388

291 CAD Integration und Digital Mock-Up PLM und Team Data Manager Info Pack Assy Assy Teamcenter = Teilestamm Files Files Assy Digital Mock-Up Info Pack Z-Teil 1 CATIA DRW Files Info Pack Z-Teil 2 Files G Assy Info Pack Z-Teil 3 Files Z-Teile Spec-Teile Gültigkeiten Check-out SP1 SP2 Check-in SP3 Spec-Teil Info Pack StüLi Normteile Files Trafo matrix VPM = Geometriestamm G-Teil 1 G-Teil 2 G-Teil 3 G-Teil SP G-Spec.- Teil CATIA SOL CATIA DRW CATIA SOL CATIA DRW CATIA SOL CATIA DRW CATIA ASM CATIA SOL CATIA DRW CATIA PRV CATIA PRV CATIA PRV CATIA PRV CATIA PRV Seite 291 von 388

292 CAD Integration und Digital Mock-Up PLM und Team Data Manager Info Pack Assy Assy Metaphase 1:1 Beziehung Files Files Assy Pfad Name als Ref. In Metaphase Digital Mock-Up Z-Teil 1 Info Pack CATIA DRW G-Teil 1 Files Z-Teil 2 Info Pack Files G-Assy G-Teil 2 Z-Teil 3 Info Pack Files G-Teil 3 SP-ASSY SP1 SP2 SP3 VPM TIFF Dokument G-Teil SP ANC Assy Auswertung der CATIA Dittos und Übertragung nach Metaphase CATIA SOL CATIA DRW CATIA SOL CATIA DRW CATIA SOL CATIA DRW CATIA ASM CATIA PRV CATIA PRV CATIA PRV CATIA PRV Seite 292 von 388

293 Digital Mock-Up - Strukturierung des Produkts bezüglich Wiederverwendbarkeit der Geometrie Digital Mock-Up Create Once, use many times!!! Da aus den wiederverwendbaren Teilen des Detail Level das Produkt in seiner Gesamtheit konfiguriert wird, sollte 3D Geometrie nicht im Aspect Level verwaltet werden Nutzer aus Fertigung (z.b. Arbeitsvorbereitung, Endmontage) und Product Support einbinden Frage der Notwendigkeit von Geometrie und Systemen klären, wenn ja Aufbruch nach Systemen berücksichtigen Zonalen Aspect oder Zonenattribut einführen Seite 293 von 388

294 DMU Darstellungen für Eurofighter Rumpfvorderteil und Flügel Digital Mock-Up Seite 294 von 388

295 CAD Integration und Digital Mock-Up Nutzen Digital Mock-Up Einsparung von Iterationsschleifen durch exaktere Erstkonstruktion Erhöhung der Produktqualität u.a. durch Vermeidung von Reparaturen vor der Auslieferung Verbesserung des Produktes durch bessere Berücksichtigung von Montierbarkeit, Wartbarkeit und Reparierbarkeit Beschleunigung der Durchlaufzeit in der Entwicklungund Betreuungskonstruktion durch schnelle Suchmechanismen Vermeidung von Fehlern in der Entwicklungs- und Betreuungskonstruktion durch schnelle und sichere Suchmechanismen Vermeidung von mechanischen Attrappen Potential zum verteilten Entwickeln mit Partnern und Zulieferfirmen Create one, use many times bei guter Strukturierung Seite 295 von 388

296 3D-Visualisierung Definition Visualisierung 3D-Visualisierung ist die Fähigkeit, innerhalb des PLM Systems 3D Geometriedaten als sogenannte Ersatzgeometrie zu visualisieren und zu manipulieren Seite 296 von 388

297 3D-Visualisierung Geometrie - Geometriedaten Unter Geometriedaten sind die 3D Konstruktionsdaten des originären CAD-Tools zu verstehen. Visualisierung Vorteil: modernste Arbeitsweise, genaueste Daten, alle Anwender setzen auf den gleichen, aktuellsten Daten auf, 3D Darstellung und reales Produkt sind identisch und können direkt verglichen werden Nachteil: große Datenmengen, problematisch wenn große Bauteilmengen navigiert werden müssen, teuere Hard- /Software, spezielle Kenntnisse sind erforderlich Alternative: Ersatzgeometrie Seite 297 von 388

298 3D-Visualisierung Geometrie - Ersatzgeometrie Ersatzgeometrie ist ein 1:1 Duplikat des 3D Originalmodells, von welchem die Aussenhaut in dreieckige Elemente umgewandelt wurde (Tesselierung), jetzt auch schon exakte Geometrie Visualisierung ist je nach Auflösung bis zu einem 1/100 mm massgenau enthält etwa nur 15% der Datenmenge der Originalgeometrie es können davon unterschiedliche Ableitungen erzeugt werden (Vektorformat CGM, Pixelformate, Videosequenzen, Internetfähige Daten) es kann in großen Bauteilmengen navigiert werden es sind keine umfangreichen Engineering-Kenntnisse nötig Die Bedienung von Ersatzgeometrie-SW ist wesentlich einfacher als das originäre CAD System Ersatzgeometrie ist auf Standard -PCs lauffähig Seite 298 von 388

299 3D-Visualisierung Ersatzgeometrie Anwendungen Wofür lässt sich Ersatzgeometrie anwenden... und wer kann sie nutzen Visualisierung Viewing ( Einzelteile, DMU s) Kollisionsuntersuchungen QS Analysen Ein-/Ausbauanalysen Bauraumanalysen Arrangements und Ableitungen Animation alle PLM-User, LogAmtBw Konstruktion, Product Support RM&T Qualitätssicherung Montage, Ausrüstung Flugerprobung, Sonderausrüstung Product Support Training Intern / Extern Konflikt wegen Überschneidung mit CAD Funktionalität Seite 299 von 388

300 3D-Visualisierung Aufruf des Viewers über das PLM Visualisierung - Einstieg zur Visualisierung durch Aufruf des PLM. - Absetzen der Query - Aufruf des 3D Viewers Seite 300 von 388

301 3D-Visualisierung 3D Einzelteil-Visualisierung Visualisierung - PC Oberfläche von VisMockUp - Darstellung der Produktstruktur (links) - Darstellung der tesselierten Ersatzgeometrie (rechts) Seite 301 von 388

302 Zeichnung Blatt 1 des Assembly von Folie 8 Visualisierung Seite 302 von 388

303 Zeichnung Blatt 2 des Assembly von Folie 8 Visualisierung Seite 303 von 388

304 3D-Visualisierung Volumen- und Bauraumsuche Visualisierung - Bauraumsuche über Volumen-Filter nur über gesamte Produktstruktur möglich Seite 304 von 388

305 3D-Visualisierung Ergebnis von Volumensuche Visualisierung - Ergebnis der Bauraumsuche mittels Volumenfilter Seite 305 von 388

306 Darstellung der Zonenstruktur und Zonenmodelle Visualisierung Seite 306 von 388

307 3D-Visualisierung Suchvorgang über Volumen-Filter Visualisierung - Die Bounding Box der Zone wird zum suchen mittels eines Volumen- Filters aktiviert Seite 307 von 388

308 3D-Visualisierung Ergebnis der Bauraumsuche Visualisierung Alle in der selektierten Zone enthaltenen Teile werden gegen die gesamte Produktstruktur gesucht und dargestellt Seite 308 von 388

309 Visualisierung Visualisierung Die Migration des 2D (Zeichnungen, Stücklisten, etc.) Mikrofilm Archivs ist oft ein erfolgreicher Einstieg in eine PLM Implementierung 3D Visualisierung mit multi - CAD Fähigkeit ist eine Schlüsseltechnologie für die Zukunft Intern: Entwicklung, Fertigung, Produkt Support Entwicklungspartner und Zulieferer: Digital Mock-Up, Design Space, Concurrent Engineering Visualisierung ist ein entscheidender Schlüssel zum Erfolg einer PLM Einführung Seite 309 von 388

310 Visualisierung Visualisierung Die Migration des 2D (Zeichnungen, Stücklisten, etc.) Mikrofilm Archivs ist oft ein erfolgreicher Einstieg in eine PLM Implementierung 3D Visualisierung mit multi - CAD Fähigkeit ist eine Schlüsseltechnologie für die Zukunft Intern: Entwicklung, Fertigung, Produkt Support Entwicklungspartner und Zulieferer: Digital Mock-Up, Design Space, Concurrent Engineering Visualisierung ist ein entscheidender Schlüssel zum Erfolg einer PLM Einführung Seite 310 von 388

311 3D Modellierung Annotationen Zeichnungsloser Prozess Seite 311 von 388

312 3D Modellierung Maße und Toleranzen Alle modernen CAD Systeme ermöglichen 3D Modellierung. Zeichnungsloser Prozess Bemaßung und Toleranzen sind analog zu den bisher praktizierten 2D Verfahren möglich. Da jedoch viele Fertigungsmethoden direkt auf dem 3D Modell aufsetzen, ist eine vollständige Bemaßung im herkömmlichen Sinn nicht mehr notwendig. Der Vorteil besteht darin, dass keine 2D Ansichten und Schnitte mehr erstellt werden müssen. Seite 312 von 388

313 3D Modellierung Maße und Toleranzen Farbliche Zuordnung Zeichnungsloser Prozess Seite 313 von 388

314 3D Modellierung PMI Product Manufacturing Information Zeichnungsloser Prozess Seite 314 von 388 PMI muss alles im CAD Systems sein? Eigenschaften am Teil können als PLM Teileattribut am Teil verwaltet werden Verbauungseigenschaften an der Relation Eigenschaften an Geometrie Features im CAD Modell

315 PLM XML Pipline Datenintegration im Unternehmen PLM XML Seite 315 von 388

316 PLM XML Datenstrom PLM XML Seite 316 von 388

317 PLM XML Präsentation von Daten für verschiedene Anwender PLM XML Seite 317 von 388

318 PML XLM Möglichkeiten der Datenintegration im Unternehmen auf der Basis von PLM XML PLM XML Seite 318 von 388

319 XML report writers and transformers in PLM PLM XML Wozu werden XML report writer/transformer verwendet? Einführung in XML/XSL(T) Wie wird ein XML report/transformer definiert? Erstellung der Navigationsstruktur Definition eines XSL Files Erstellung eines Berichts Seite 319 von 388

320 Wozu wird der XML report writer/transformer benötigt bzw. eingesetzt? PLM XML Erstellung von benutzerdefinierten Berichten in verschiedenen Format wie Text, (X)HTML, PDF, Postscript. Der Benutzer hat die Möglichkeit, eigene, individuelle Berichte ohne direkten Datenbankzugriff zu erstellen (Wer welche Informationsobjekte sieht/erzeugt und wer welche Zugriffsrechte hat, davon ist der report writer nicht betroffen) Ad-hoc Berichte Speziell formatierte Berichte, welche sonst fast nicht machbar sind (Spezielle Layouts, etc.) Smarte Lösung für Berichte, welche in starkem Maße dynamische Relationen benutzen und/oder der Konfigurationskontext bzw. Zugangsberechtigungen eine Rolle spielen. Dort, wo es um kleine bis mittlere Datenvolumina geht. Seite 320 von 388

321 Einführung: XML/XSL PLM XML XML ("Extensible markup language") ist wie HTML eine tag-based, sogenannte meta-language, das bedeutet, dass die Grammatik vom Anwender selbst definiert und leicht erweitert werden kann. XML files sind strukturierte Dokumente. Sie werden durch eine baumartige Struktur repräsentiert, den sogenannten node tree. Es gibt einige grundlegende Regeln (XML header exists; all opened tags must be closed in the appropriate order, no reserved characters are used, etc.). Wenn eine XML Datei diesen Regeln entspricht, dann nennt man sie wellformed. XML files können gegen ein "DTD" (Document Type Description) geprüft werden. Das DTD definiert, welche Elemente und Attribute zulässig sind und welche ineinander geschachtelt werden können. Das DTD ermöglicht automatische Prüfung, nach erfolgreicher Prüfung wird das Dokument als "valid bezeichnet. Seite 321 von 388

322 Einführung: XML example PLM XML Seite 322 von 388 XML header with character set definition <?xml version="1.0" encoding="iso "?> <eadsrpt:resultset Title="All800s" Creator="be28615" Date=" " Time="13:16" xmlns:eadsrpt=" xmlns:xrsup=" <eadsrpt:node Class="s0Assbly" OBID="mfdbDDgDASA--ADMUSR--ZN6"> <eadsrpt:field Name="Nomenclature">GA OF W/S EF2000 (SPA)</eadsrpt:Field> <eadsrpt:field Name="Revision">A</eadsrpt:Field> <eadsrpt:field Name="s0PartNumber">J </eadsrpt:Field> <eadsrpt:field Name="s0Official">True</eadsrpt:Field> <eadsrpt:field Name="s1SiteCode">C EADS M OTN</eadsrpt:Field> <eadsrpt:relation Class="s2AsRvRv" OBID="mfdbDHcDASA--ADMUSR--ZN6oicmblhDASA-"> <eadsrpt:node Class="s0Assbly" OBID="oicmbldDASA--ADMUSR--cFZ"> <eadsrpt:field Name="Nomenclature">GA OF A/C SINGLE SEAT</eadsrpt:Field> <eadsrpt:field Name="Revision">C</eadsrpt:Field> <eadsrpt:field Name="s0PartNumber">J </eadsrpt:Field> <eadsrpt:field Name="s0Official">True</eadsrpt:Field> <eadsrpt:field Name="s1SiteCode">C EADS M OTN</eadsrpt:Field> <eadsrpt:node Class="s0Assbly" OBID="lbzfiRjDASA--ADMUSR--QHq"> <eadsrpt:field Name="Nomenclature">INSTL.LEVel.</eadsrpt:Field> <eadsrpt:field Name="Revision">A</eadsrpt:Field> <eadsrpt:field Name="s0PartNumber">J </eadsrpt:Field> <eadsrpt:field Name="s0Official">True</eadsrpt:Field> <eadsrpt:field Name="s1SiteCode">C EADS M</eadsrpt:Field> </eadsrpt:node> </eadsrpt:relation> </eadsrpt:node> </eadsrpt:relation> </eadsrpt:node> Attribute Value </eadsrpt:resultset> Element with preceding namespace

323 Einführung: XML/XSL/XSLT PLM XML XSL: extensible Stylesheet Language (Transformations) Ermöglicht die Umwandlung von einem (oder mehreren) XML file(s) in einen unterschiedlichen XML file (XSL) in ein formatiertes Dokument (XSLT) XSL transformations sind in XML geschriebenen Dateien, daher können die transformation instructions wie üblich geprüft werden. Ein spezieller "dialect, als xsl-fo (xsl formatting objects) bezeichnet, stellt Anweisungen bereit um ein Dokument als PDF oder Postscript zu erstellen. Seite 323 von 388

324 Einführung: XML/XSL/XSLT example <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet version="1.1" xmlns:xsl=" xmlns:eadsrpt=" <xsl:output method="text" indent="no" encoding="iso "/> <xsl:template match="eadsrpt:resultset"> <xsl:text disable-output-escaping="yes"> </xsl:text> <xsl:apply-templates/> </xsl:template> PLM XML <xsl:template <xsl:variable name="rfanr" <xsl:variable name="rfatype" <xsl:variable name="rfatitle" <xsl:variable name="rfaissue" <xsl:variable name="modnr" <xsl:variable name="modissue" <xsl:variable name="baseline" <xsl:apply-templates> <xsl:with-param name="rfanr" select ="$RFANr"/> <xsl:with-param name="rfaissue" select ="$RFAIssue"/> <xsl:with-param name="rfatype" select = "$RFAType"/> <xsl:with-param name="rfatitle" select = "$RFATitle"/> <xsl:with-param name="modnr" select ="$MODNr"/> <xsl:with-param name="modissue" select ="$MODIssue"/> <xsl:with-param name="baseline" select ="$Baseline"/> <xsl:sort select="."/> </xsl:apply-templates> </xsl:template> </xsl:stylesheet> Seite 324 von 388

325 Wie wird ein XML report/transformer definiert PLM XML Ein XML report writer besteht aus den folgenden Objekten XML report writer/transformer Object Struktur Navigation Definition (dies kann extrem komplex sein) Das höchste navigation template ist mit dem report writer/transformer Object verknüpft (optional) gespeicherte, mit dem report writer/transformer object verknüpfte Datenbankabfragen (transformer only) Registrierte XSL Dateien, welche die Transformationsregeln zur Verfügung stellen. Seite 325 von 388

326 Setting up an XML report/transformer PLM XML What is escaping? Enter report name Enter report title (will be written to XML file) Can be narrowed to a specific acces group "Escape" attribute values that would destroy well-formedness Some characters (like <,>,&,",') are forbidden in XML files since they have a special meaning. Having them in an XML file would cause a validating parser to generate an error since it would consider them as an XML token (document would not be well-formed). Those characters can still be used in XML files if they are written in a special way ("escaped"): (<, >; &, etc) Seite 326 von 388

327 Definition der Struktur für die Navigation Creating the navigate structure PLM XML Die Struktur für die Navigation ist der Kern für jeden Bericht. Die Navigation Struktur definiert wie der Bericht erstellt wird und wie das Ergebnis aussehen wird. Sie kontrolliert: Welche Objekte expandiert werden Welche Attribute in die XML Datei ausgeleitet werden. Welche Relationen expandiert werden. Navigation Strukturen bestehen aus Item Navigation Templates Relationen Navigation Templates Seite 327 von 388

328 XML Mögliche Berichte im PLM PLM XML Der Report writer erzeugt nur ein XML file im Verzeichnis des Anwenders Der Transformer führt eine server-based XSL- Transformation der XML Datei aus und schreibt als Ergebnis (XML, HTML, PDF, PS, ASCII) in das Verzeichnis des Anwenders Seite 328 von 388

329 Vergleich HTML und XML Code PLM XML Der folgende HTML-Code <p> Hubert Hans <b>partl</b> <br> Muthgasse 18 <br> A-1190 Wien <br> geb. 8. März 1949 </p> bewirkt eine Darstellung wie Hubert Hans Partl Muthgasse 18 A-1190 Wien geb. 8. März 1949 Der folgende XML-Code <person id="p4681" > <vorname>hubert</vorname> <vorname>hans</vorname> <zuname>partl</zuname> <titel>dr.</titel> <adresse>muthgasse 18</adresse> <plz>a-1190</plz> <ort>wien</ort> <geburtstag> <tag>8</tag> <monat>märz</monat> <jahr>1949</jahr> </geburtstag> </person> bewirkt eine Darstellung die vom Style Sheet abhängt Seite 329 von 388

330 Definition der Navigation Struktur Transformer object Item template Relation template PLM XML Transformation description (XSL-Sheet) Seite 330 von 388

331 Beispiel: Erzeugen eines RFA Reports PLM XML Drag & Drop Name für PDF File Seite 331 von 388

332 PDF Repräsentation eines RFA Reports PLM XML Seite 332 von 388

333 Dokumenten Management (DM) Was ist neu? 1. Kommunikation Vergangenheit Jetzt Dokumenten Management Strukturen, Prozesse Zeitversetzte Kommunikation entlang d. Prozeßkette über Dokumente; komplexe & redundante Kommunikation Sukzessives Befüllen des PLM Produktinformationsmodells; synchrone Zugriffsmöglichkeit, Concurrent Engineering Seite 333 von 388

334 Dokumenten Management (DM) Was ist neu? 2. Strukturierte Dokumente Vergangenheit Jetzt Dokumenten Management Uhr Uhr Uhr Uhr Arbeitobjekt ist das gesamte Dokument; daher sequentieller Ablauf Uhr Uhr Dokumenten Produktion Layout, Medien Arbeitsobjekt ist das Dokumentelement; ermöglicht parallelen Ablauf Uhr Dokumenten Management Dokument generieren Uhr Seite 334 von 388

335 Dokumenten Management (DM) Was ist neu? 3. Informationsversorgung Dokumenten Management Uhr Uhr Alter Prozess Uhr Uhr Uhr Uhr PLM Prozess Uhr Dokumentenversorgung als zentraler Service Folge: Zeitverlust & Prozessunterbrechung Elektronischer Online-Zugriff auf die Dokumente Folge: unmittelbare Verfügbarkeit der Informationen Seite 335 von 388

336 Komplexe Suche Dokumenten Management Seite 336 von 388

337 Work Flows für Dokumenten Management Dokumenten Management Revise Überprüfung des Dokuments Sign off, zur Freigabe des Dokuments durch die definierten Verantwortlichen Seite 337 von 388

338 Anzeige Life Cycle Status Dokumenten Management Seite 338 von 388

339 Flexibilität oder striktes Prozessmanagement Diverses Pro Flexibilität Der Anwender kann ein Dokument ins PLM einstellen, muss aber nicht. Wenig Pflichtattribute, viele kann Attribute. Keine Konsistenzprüfung bei der Freigabe von einzelnen Objekten bzw. funktionalen Einheiten Kontra Flexibilität Nur wenn etwas vom System erzwungen wird, dann wird ein Objekt auch angelegt und definiert. Möglichst viele Attribute aus vorbelegten Listen abrufen keine Schreibfehler, automatisch richtige Daten. IT-gestützte Prüfungen sind der Garant für gute Datenqualität Meine Meinung: Flexibilität ist Bull Shit Seite 339 von 388

340 Datenqualität Diverses PLM Systeme leben von der Datenqualität - was ist Datenqualität? Der Gesamtumfang der Daten ist komplett Alle Attribute sind vorhanden und inhaltlich richtig Die definierenden Dokumente sind vorhanden und inhaltlich richtig Voneinander abhängige Funktionsblöcke wie z.b. Baseline of Diagrams und Baseline of Looms sind in sich konsistent. Feinde der Datenqualität Termindruck, Termindruck, Termindruck,!!! Qualität ist nicht Teil der Zielvorgabe Besser eine unvollständige Information als keine Seite 340 von 388

341 Zusammenhang von Fehlerbehebungskosten und Entdeckung der Fehlers im Lebenszyklus Diverses Kosten der Fehlerbehebung Vorentwicklung Entwicklung Produktion In Service Seite 341 von 388

342 Digitale Signatur Elektronische Freigabe Diverses Hintergrund: Es gibt gesetzliche Regelungen wer welche Unterschriften leisten muss. Muss heute noch physikalisch unterschrieben werden? Nein: Digitale Signatur ist gesetzlich geregelt, erfordert jedoch noch hohen Aufwand bei der Umsetzung wenig benutzt Elektronische Freigabe durch einen geregelten Work Flow. Voraussetzungen dafür sind: Anwender müssen sich per Passwort am System anmelden. Definierter Work Flow für die Freigabe von Objekten. Aktionen müssen im System protokolliert und sicher gespeichert werden: Wer hat was, wann gemacht. Die Vermeidung von Unterschriften auf Papier bringt Vorteile: Papierdurchlauf mit hohem Personalaufwand entfällt. Einscannen u. Registrierung der Unterschriftsblätter entfällt Seite 342 von 388

343 EF Workshare und Organisation Datenaustausch EADS MAS EADS MAS Seite 343 von 388

344 Produkt Daten Technologie (PDT) Ziel: Bereitstellung der Technologie, um eine datenintegrierte Prozesskette zu ermöglichen! Elemente der PDT: Datenaustausch 1. Prozeßmodelle 2. Produktdatenmodelle Beschreibung der Prozessketten im Lebenszyklus des Produktes unter Anwendung entsprechender Methoden (z.b. ARIS EPK, SADT, UML,...). Alle Produktinformationen (z.b. Geometrie, Baugruppenstruktur,Versionen,...) werden zur Weiterverarbeitung mit Systemen in Produktdatenmodellen beschrieben (z.b. in EXPRESS, UML,..). Actuating variable Input Activity Auxiliary variable assembly_relation product product_version 3. Implementierungsmethoden/ Systeme Prozess- und Produktdatenmodelle werden in rechnergestützten Systemen implementiert. Die Systeme erzeugen und verändern Produktdaten entsprechend der Regeln der Geschäftsprozesse. QS NC M-CAD Seite 344 von 388 Folgerung: Eine rechnerintegrierte Prozesskette kann nur durch die gezielte Anwendung von Methoden, sowie den abgestimmten Einsatz von Systemen und Produktdatenmodellen realisiert werden.

345 Das Datenaustausch Problem BMW DC GM Ford VW Volvo Hersteller Datenaustausch Partner 1. Reihe 2. Reihe... Delphi Bosch Conti Siemens Hella FuBa ZF VDO a b c d e f g h i j k l m n Jede Beziehung benötigt Harmonisierung : der firmenübergreifenden Prozesse der Datenformate der Implementierungsmethoden Seite 345 von 388

346 Vorteil genormter Schnittstellen PLM A : Prozessor PLM A Datenaustausch ERP E CAD D CAD C PLM B ERP E CAD D genormte Schnittstelle CAD C PLM B Informationsaustausch ohne standardisierte Schnittstelle Prozessorenanzahl: n (n-1) = 20 Informationsaustausch mit genormter Schnittstelle Prozessorenanzahl: 2 n = 10 Seite 346 von 388

347 Daten Austausch/ Kommunikation Szenarien PLM Datenaustausch asynchroner Datenaustausch Technologie und Tools verfügbar Projekte produktiv Für die Partnerintegration Datenaustausch PLM Web Clients Viewing von Daten und Nutzung ausgewählter Funktionen via Netzwerk Technologie verfügbar Nur in Verbindung mit anderen Lösungen effizient für Zulieferer PLM Data Sharing Synchrone Datenkommunikation Technologie im Pilotstadium (i.e. PLM Enabler) Semantikprobleme nicht gelöst Gut für zukünftige Datenintegration besonders firmenintern Seite 347 von 388

348 Übersicht Application Protocols Datenaustausch Application Protocol Content 201 Explicit Draughting 202 Associative Draughting 203 Configuration Controlled 3D Designs of mechanical parts and assemblies 204 Mechnical Design using Boundry Representations 205 Mechnical Design using Surface Representations 207 Sheet Metal Die Planning and Design 208 Life Cycle Product Change Process 209 Composite & Metallic Analysis & Related Design 210 Electronic Assembly, Interconnect and Packaging Design 212 Electrotechnical Design and Installation 213 Numerical Control (NC) Process Plans for Machined Parts 214 Core Data for Automotive Mechanical Design Processes 215 Ship Arrangement 216 Ship Moulded Forms 217 Ship Piping 218 Ship Structures 220 PCA Process Planning 221 Functional Data and their Schematic Representation for Process Plant 222 Design to Manufacturing for Composite Structures 223 Exchange of Design and Manufacturing Product Information for Cast Parts 224 Mechanical Product Definition for Process Planning using Machining Features 225 Building Elements using Explicit Shape Representation 226 Ship Mechanical Systems 227 Plant Spatial Representation 231 Process Design and Process Soecification for Major Equipment 232 Technical Data Packaging Core Information and Exchange Seite 348 von 388

349 AP216:Ship moulded forms Flächen-, Drahtmodell und Offsetpunkt Repräsentationen Design, Produktion und Betrieb Datenaustausch Generelle Charakteristiken Hauptmaße Hüllgeometrie Wichtige Innenflächen Hydrostatik Stabilitätstabellen Seite 349 von 388

350 Begriffsdefinitionen Datenaustausch Seite 350 von 388

351 Units of functionality und Conformance Classes UoF = Unit of Functionality Sammlung von Entities die zusammengenommen eine bestimmte Art von Funktionalitäten repräsentieren. Datenaustausch CC = Conformance Class Sammlung von UoF mit dem Ziel den Implementierern einer beschränkte Menge von benötigten Entities zur Verfügung zu stellen z.b. in AP214 CC 1-2: Geometric (CAD) data exchange CC 3-5: Draughting data exchange CC 6-10: Product Structure and Configuration Management and EDM Data Seite 351 von 388

352 Spezifikationssprache EXPRESS 31 Spezifikationsmethoden Entwicklungsmethodik für Datenmodelle 32 Test- und Prüfmethoden SOAP - STEP ON A PAGE_1 STEP Anwendungsarchitektur Datenaustausch Anwendungsneutrale Bausteine zur Produktbeschreibung Beschreibungsmethode für Produktdaten (EXPRESS) Implementierungsmethoden für den Datenaustausch Anwendungsdatenmodelle (Application Protocols, APs) Prozeßketten in der Automobilindustrie (AP 214) Entwicklung elektrotechnischer Anlagen (AP 212) Technische Zeichnung 3D-Geometrie Produktkonfig. (AP 203) (AP 201)... anwendungsorientierte Kernmodelle (Application Resources) Zeichnung (101) Elektrik (103) Kinematik (105)... anwendungsorientierte Kernmodelle (Integrated Resources) Geometrie (42) Repräsentation (43) Produktstruktur (44) Darstellung (46) Grundlagen der Produktbeschreibung (41) Implementierungsmethoden Datei (21) SDAI (22)... Datenbank Seite 352 von 388

353 Spezifikationssprache EXPRESS 31 Spezifikationsmethoden Entwicklungsmethodik für Datenmodelle 32 Test- und Prüfmethoden SOAP - STEP ON A PAGE_2 STEP Anwendungsarchitektur Datenaustausch Anwendungsdatenmodelle (Application Protocols, APs) Prozeßketten in der Automobilindustrie (AP 214) Entwicklung elektrotechnischer Anlagen (AP 212) Technische Zeichnung 3D-Geometrie Produktkonfig. (AP 203) (AP 201)... anwendungsorientierte Kernmodelle (Application Resources) Zeichnung (101) Elektrik (103) Kinematik (105)... anwendungsorientierte Kernmodelle (Integrated Resources) Geometrie (42) Repräsentation (43) Produktstruktur (44) Darstellung (46)... Branchenspezifische Anwendungsdatenmodelle zur Produktbeschreibung (z.b. AP214, AP212, AP203, AP201) Test- und Prüfmethoden für Implementierungen Grundlagen der Produktbeschreibung (41) Implementierungsmethoden Datei (21) SDAI (22) Datenbank Als internationale Norm (IS) veröffentlicht Federführend durch ProSTEP bearbeitet Seite 353 von 388

354 Warum ist Produktstruktur und Konfigurationsmanagement im AP214 so wichtig? Datenaustausch Einfache Datenmodelle sind nicht anwendbar Unterschiedliche Firmen nutzen die verschiedenen STEP- Objekte auf unterschiedliche Art und Weise Entscheidend ist die Semantik der auszutauschenden Daten Zum Austausch von Product Coding / BoM Daten ist die Vereinbarung eines einheitlichen Referenzmodells erforderlich AP214 CC8 definiert die Strukturen komplexer Produkte Es gibt dafür keinen anderen Standard außer STEP Die Daten sind typischerweise systemübergreifend zu managen bzw. auszutauschen (PLM/TDM-CAD Integration für Digital Mock Up) Seite 354 von 388

355 Warum ist Produktstruktur und Konfigurationsmanagement im AP214 so wichtig? Datenaustausch Der STEP Standard ist Integrationsfaktor für heutige Systeme (z.b. PLM und nachfolgende ERP Systeme) Richtlinie für künftige (PLM) Systeme (Diskussion mit Anbietern auf neutraler Basis) In zunehmendem Maße erfolgt der Austausch ganzer Produktstrukturen (BoM) mit Hauptzulieferern bzw. Entwicklungspartnern mit dem Ziel der kompletten Dokumentation eines Produktes in digitaler Form Stand der Anwendung Austausch von Stücklisten zur Kommunikation von Änderungen und Gültigkeiten mit Entwicklungspartnern Voraussetzung für Dokumentation von Einzelfahrzeugen einschließlich der verbauten Teile und Einbaubedingungen ( Bauzustand ) Entwicklung von Standardsoftware für das Product Coding Seite 355 von 388

356 Das STEP PLM Schema Datenaustausch AP214 AP203 PLM Schema AP232 AP212 Common PLM data schema generated and maintained by PDES, ProSTEP and JSTEP Subset of PLM relevant STEP APs (AP203, 212, 214, 232) Fulfills nearly all requirements for PLM data exchange Main functionality for parts and documents: - identification - versioning - structures incl. transformations - approvals and authorization - project, work order, work request - effectivities - classification and properties Seite 356 von 388

357 Vorgehensweise Aufnahme User Requirements Datenaustausch Analyse der vorhandenen Spezifikationen Entwurf Express Datenmodell mit Ausdrücken der Benutzer Entities Attribute Relationen Erstellung eines Data Dictionary Iteration mit den Benutzern, bis Datenmodell und Data dictionary von allen Benutzern akzeptiert sind Mapping auf PLM Schema Seite 357 von 388

358 base of substitute of defines Partielles Express G Datenmodell Produktstruktur Datenaustausch uses alternate relationship substitute relationship quantity measure unit remark make from relationship transformation matrix has component position assembly relationship with detail level REAL STRING STRING is base of is alternate of measure unit produced quality is component of is for an (INV) has issues authority issue authorized by is assy of item issue item definition produces STRING REAL item part number title security classification part type references standard part spec references finish material spec issue remarks weight unit calculated weight safety classification maturity stage references protective treatment is relevant for item view STRING STRING STRING STRING document has production site organisation view name STRING STRING STRING REAL STRING STRING document STRING Seite 358 von 388

359 Elemente eines Data dictionarys Datenaustausch Name Beschreibung Quelle, Herkunft Klassifizierung Entität Attribut Relation - Verknüpft Name x mit Name y Format (nur bedingt notwendig) Beispiel Regeln Seite 359 von 388

360 Beispiel für item Datenaustausch Name: item Beschreibung: (1) MIL-STD-280. A non specific term used to denote any product, in-cluding systems, materials, parts, sub-assemblies,set, accessories, etc. (2) ISO AP214CD. Common information identifying one or more (versions) of physical parts, tools and systems including software some of which will be formal deliverables consistent through all process. (3) An item of the detail level is a storable item, which can be a 400 assembly or a detail part. An item can be a drawn part/assembly, a standard part/assembly or a specified purchased part/assembly Quelle, Herkunft: Klassifizierung: Entität Format (nur bedingt notwendig)/ Beispiel: Regeln: If an item is referenced by a relationship, only the partnumber (and for bought out parts the has_vendor information) is required to be stated within the product structure data exchange file. If the referenced items have not been exchanged before and are of the same authority, the complete information content about these items has to be stated additionally within the same product structure data exchange file. It is not valid to exchange a refernced item which has not been exchanged before and which is of a different authority. Seite 360 von 388

361 Beispiel des Attributs Teilenummer der Entität item Datenaustausch Name: Part number Beschreibung: unique identification of an item (e.g. part or assembly) according project rules. Reidentification of a item is required if changes to the information pack of the item are performed affecting fit, form or function of the item Quelle, Herkunft: EF Norm J Format (nur bedingt notwendig): An Beispiel:e.g 'J ', 'J ' Regeln: Seite 361 von 388

362 Aufgabe: Mapping Ansatz für Produktstruktur Product Class Eurofighter Weapon System Eurofighter Aircraft & TR 1000 l Tank AGE ASTA Twin Seater Single Seater Twin Seater Single Seater Datenaustausch Product Component Product Structure Class Structure System PHYSICAL ZONE Detail level Items / Instances Assembly Structure Aspects via separate product component structures (classified) Views (life cycle) via assignments to one or more different application context Seite 362 von 388

363 Schematischer Entwicklungsprozess im Kontext von RFA request Datenaustausch request for development work_request definition of development project project RFA initial development order work_order subdivide work into activities activity Seite 363 von 388

364 Unternehmen Variante Produktstrukturen in AP214 CC8 Produktklassen Konzeptionelle Produktkomponenten Varianten/ Lösungen Teilestruktur (BoM) Dokumente (z.b. CAD-Modelle) Type A Cyl. Head Type B... Datenaustausch Middle class car Standard Engine Interior... Camshaft Type C... Zugeordnete Informationen: Sports car... Convertible Chassis... Spezifikationen Konfigurationsregeln Änderungsdaten Effektivitäten Seite 364 von 388

365 Übersicht zu AP214 CC8 Datenobjekten Product Class Structure Product Class Product Classification Specification Component Structure Product Component Product Coding Datenaustausch Product Function Functional Structure Product Structure Product Instance Product Instance Item Instance Alternative Solution Alternative Solution Alternative Solution Configuration Classification Assembly Structure Bill of Materials Item / Item Version Effectivity Organizational Data Document / Model Structure Document / Geometric Model... Seite 365 von 388

366 AP 214 UoF S7 specification control Übersicht der ARM Objekte product structure S7 complex_ product_ relationship (ABS) complex_ product product_ structure_ relationship (ABS) product_ constituent Datenaustausch collection of products with same or similar characteristics S7 product_ class product characteristics and their dependencies S[1:?] functional design / requirements S7 product_ function product or component including all variants one variant (explicit rep.) alternative_ solution part or tool (implicit) S7 product_ identification manufacturable part or tool w/o variation (explicit) assembly_ component_ relationship product_ specification item item_ version physic. realized product or component (with serial #) specification_ expression specification specification_ category product_ component item_ instance design_disc_ item_definition physical_ instance S7 S7 S7 S3 S1... S7 configuration not covered by AP 203 relationship Seite 366 von 388 S7 control of part / variant usage (validity) partially covered by AP 203

367 Mapping approach für change Request relationships Change_Request versioned_action _request name= decomposition resolved_request directed_action action_ activity_ relationship relationship Datenaustausch action_ relationship action Manufacturing interface action_ relationship action Technical interface name= hierarchy applied_action_ assignment action_ relationship name= derivation directed_action action activity versioned_action _request Change_Request concerned_organization organization organization EF Partner Seite 367 von 388

368 Übersicht Daten Austausch Prozess SELECT EXPORT TRANSLATE PACK TRANSFER Datenaustausch Change Management Teamcenter or Selection Checkout trigger status Exchange Order P21 File Create Order Pre- Processor STEP File Package Monitoring Administration Message STEP File Data Package Data Exchange and Information Manager (chosen product DXM) status Exchange Order Create Order trigger on demand MP Interface P21 File Pre- Processor STEP File Package Message STEP File PLM Teamcenter Data Package Seite 368 von 388

369 Ziele des EF Datenaustausch Projektes Datenaustausch Jeder EPC hält die gesamten, gemeinsamen Produktdaten des gesamten Waffensystems. Weitestgehend automatisierte, maschinelle, kosten- und zeitoptimale Weiterverarbeitung von Partnerdaten. Produktdaten stehen in der EADS-MAS internen Semantik zur Verfügung. Die Partnerdaten stehen somit über die definierte Schnittstelle für die Entwicklung, Fertigung, das Qualitätsmanagement und den Product Support zur Verfügung. Ausgetauschte Produktdaten dürfen vom Empfänger nicht verändert werden. Seite 369 von 388

370 Erfahrungen aus der Erstellung der Datenaustausch Spezifikation Datenaustausch Benutzer können Anforderungen nur unvollkommen definieren, man muss sie buchstäblich herauspressen und kritisch hinterfragen. Definieren sie ein aussagekräftiges, präzises Datenmodell und Data Dictionary - Items, -Attribute, - Relationen Beschreiben sie die Trigger Points exakt. Definieren Sie die Arbeitsprozesse präzise, z.b. Revisionierung, Re-identifizierung, Gültigkeiten, Modellierungsrichtlinien Geometrie, etc. Regeln für Namenskonventionen und Datenpakete Definieren Sie Regeln für Error Handling rechtzeitig. Gemeinsame Infrastruktur - Netzwerk, Drop Server Seite 370 von 388

371 Standard Prozessor und EF spezifische Teileklassen Datenaustausch Id description versteht jeder Standard Prozessor Verstehen die EF Prozessoren product p_r_p_c rel p_r_p_c rel p_r_p_c part document assembly detail standard part general assembly EF HLID Item_80x Part_type Item STEP AP214 Assembly_ classification Assembly _type Seite 371 von 388

372 Überblick Funktionalität und Datenelemente EF HLID Funktionalität Anzahl der Datenelemente (Entitäten, Attribute, Relationen) Datenaustausch Produktstruktur 82 Change Management 109 Information Pack (Dokumente) 56 Design Standard, Design Built Standard 16 Seite 372 von 388

373 Datenaustausch IT Systeme bei EADS M Teamcenter Datenaustausch VPM CATIA (Fileserver) DXM (Dateiversand) PS-Export/Import (Teamcenter+CATIA) CM-Export/Import Teamcenter/VPM-Kopplung (Voraussetzung für PS-Export) Seite 373 von 388

374 Test Erfahrungen Datenaustausch Testumgebung sollte ca. 5% des Datenumfangs beinhalten. Erster Schritt: Austausch der Basisdaten für Test. Definition der Test Szenarios in ausreichender Tiefe. Der Empfänger allein akzeptiert die Daten. Der Test dauert viel länger als Sie planen, außer Sie haben extrem viel Ressourcen. Ein Test Team ist vorteilhaft. Der PS Test hat im EF Projekt über ein Jahr gedauert. Der Test ist die beste Gelegenheit das error handling zu erproben. Plane weitere Fehler bei Produktivsetzung ein. Seite 374 von 388

375 Lessons Learned Datenaustausch Zwingen Sie die Anwender gute Spezifikationen zu schreiben. Konzeptionelles Datenmodel Data Dicitionary Prozessmodell Es ist einfacher ein AP 214 Subset (z.b. CC6) als das PLM Schema zu verwenden. Eine direkte Abbildung der user requirements auf das PLM Schema ist faktisch unmöglich Die PLM Schema Useage Guides waren zu spät für das EF Projekt Ein AP ist eine Norm und keine Empfehlung wie das PLM-Schema. Die Industrie hat keine ausreichende STEP Kompetenz. Die Anwender entfernen sich oft von den vereinbarten Austausch Regeln und Prozessen. Vom Einfachen zum Komplexen (z.b. TIFF zu 3D mit TRAFO). Das Error Handling ist keinesfalls zu unterschätzen, da die Datenqualität im automatisiertem Betrieb extrem gut sein muss (besser 99% Fehlerfreiheit). Seite 375 von 388

376 PLM Entwicklungstrends (1/2) Ausblick und Trends Erweiterung heutige PLM-Methoden und Grundfunktionen Intelligentes Änderungsmanagement (Plausibilität, Inpact Analyse) Intelligente Klassifizierungs- und Suchmethoden Integrierter IPR Schutz von Engineering Daten Integration der digitalen Fabrik mit der Produktentwicklung Verbesserung der Funktion für Mechatronik- und Service PLM.. Neue, erweiterte Methoden / Funktionen Executive Information Management für Produktdaten Management technischer Produktdokumentation Integration des Wissensmanagement im Engineering Integration von Maintenance, Repair und Overhaul-(MRO)- Anwendungen Integration von Lifecycle Assessments von Ressourcen und Energiereffizienz.. Seite 376 von 388

377 PLM Entwicklungstrends (2/2) Ausblick und Trends Integration virtueller und realer Produktlebenszyklen Tracking und Tracing von Produkten Integration und Management von Kunden-Feedbackinformationen Dokumentation des realen Produktlebenslaufs Integration von eingebetteten Informationen im Produkt.. Neue PLM-Systemarchitekturen und Technologien Flexible SOA-Systemarchitekturen Adaptive Workflows Einsatz semantischer Technologien Einsatz von Cloud Computing.. Seite 377 von 388

378 Requirements Management Ausblick und Trends Wie sieht der Gesamtprozess im V-Modell aus? Welches Tool? Integriert in PLM? Configuration und Change Management Validation, Verification, Qualification, Certification Integration mit PLM? Seite 378 von 388

379 Interface Control Management (1/2) Ausblick und Trends Customer PMO Interface Control Management Configuration Management Engineering Production ILS PLM MRP ESS Product Model Repository Process Integration Configuration Management Data & Document Management Interface Management Integral Processes Seite 379 von 388

380 Interface Control Management (1/2) Ausblick und Trends Logische oder funktionelle Interfaces elektronisch elektrisch Man-Machine geometrisch hydraulisch. physikalisches Interface Gerät-Stecker-Pin-Signal-Pin-Stecker-Gerät PintoPin PintotoPin. Welche Strukturen werden sinnvoll aufgebaut? Wie werden Interfaces beschrieben/modelliert? Wie viel Configuration und Change Management ist nötig? Wie kann die Konsistenz zwischen logischen und physikalischen Interfaces sicher gestellt werden? Seite 380 von 388

381 Rollenbasierte Arbeitsplätze Ausblick und Trends Anwender sollen die Funktionalität zur Verfügung gestellt bekommen, welche sie primär für ihre tägliche Arbeit benötigen. Benutzerfreundliche Oberfläche (Windows bzw. WEB ähnlich) Eine Oberfläche mit Zugang zu mehreren Systemen (Datenbanken), z.b. PLM und MRP/ERP Problem: Wie viele verschiedene rollenbasierte Arbeitsplätze sind sinnvoll? Return on Investment! Seite 381 von 388

382 Funktionen von rollenbasierten Arbeitsplätzen Ausblick und Trends Seite 382 von 388