PLM - TUM

Transcription

PLM - TUM

PLM-Systeme in der industriellen Praxis
Seite 1 von 388
Vorlesung – PLM Systeme in der
industriellen Praxis
Prof. Josef Vilsmeier, Dipl.-Ing. (TU)
CASSIDIAN Air Systems
 Vilsmeier
Professor Josef Vilsmeier, Dipl.-Ing. (TU)
Geboren: 1951
Studium: Maschinenbau an der TU München
Berufliche Laufbahn:
 Seit 1978: EADS Militärflugzeuge
Einführung
Vorstellung des Dozenten
Seite 2 von 388
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





 Vilsmeier
Die Erstellung der Unterlagen für die Vorlesung
wurde unterstützt durch:
 PLM Team der EADS Military Air Systems
Einführung
Danksagung für Unterstützung
 SIS – Siemens Information Services
 ProSTEP GmbH
 Kollegen aus PLM Projekten anderer Firmen
Seite 3 von 388
 Vilsmeier
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




Einführung
Unterlagen für die Vorlesung
 Im Laufe des Semesters können geringfügige
Abweichungen zum Script vorkommen
Seite 4 von 388
 Vilsmeier




Grundlagen
PLM in der Flugzeugindustrie
Einführung von PLM
Methoden für die Einführung








Inhaltsverzeichnis
Inhalte der Vorlesung (1/2)
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
 Vilsmeier
Inhaltsverzeichnis
Inhalte der Vorlesung (2/2)







Seite 6 von 388
Visualisierung
Zeichnungsloser Prozess
PLMXML
Dokumenten Management
Diverses
Datenaustausch
Ausblick und Trends
 Vilsmeier
 Definitionen von
 PLM
 PLM
Grundlagen
Grundlagen




Seite 7 von 388
Komponenten des PLM Ansatzes
Struktur eines integrierten PLM Systems
Typen von PLM Systemen
Architektur von PLM Systemen
 Vilsmeier
 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
Grundlagen
Begriffsklärung
Bemerkung: Im Vorlesungsskript wird noch oft PLM verwendet,
obwohl in den meisten Fällen PLM gemeint ist.
Seite 8 von 388
 Vilsmeier
TIS
EDM
PLM
ZVS
PHM
EDB
CDP
CPC
TIM
CAD-DM
TDB
Grundlagen
PLM hat viele Ursprünge
CDP
VPLM
CPLM
(nach 2000)
PLM
Product Lifecycle Management
Seite 9 von 388
Quelle: Prof. Abramovici
 Vilsmeier
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
Produktlebenslauf – Unterscheidung zwischen technisch-orientierten u. kaufmännischen Prozessen
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
Seite 10 von 388
 Vilsmeier
Das Engineering hat sich in den letzen Jahren
dramatisch verändert
Grundlagen
Industrie-Produkte
Produktdaten
Zunahme der
• Funktionalität
• Teileanzahl / Produkt
• Produkttypen / Vielfalt
• Varianten / Produkttyp
• Elektronik und Softwareanteile
• produktbezogenen Dienstleistungen
• Produkt-Intelligenz (=> Smart Products)
Zunahme der
• Informationsmenge
• Heterogenität
• Dokumentation durch strengere
gesetzliche Vorgaben
• Produktdaten Zusammenhänge
• Produktstruktur-Komplexität
• Komplexitätsexplosion
• Unvorhersehbare
Veränderungen
Engineering Prozesse
• Höhere Komplexität
• Globale Verteilung
• Unternehmensübergreifend
• Durchgängige Rechnerunterstützung
• Beschleunigung
• Virtuelle Verifikation des Produktverhaltens
Operative IT-Systeme
Zunahme der
• unterschiedlicher Systemtypen
• Anzahl der Systemanbieter
• Systemkomplexität / Funktionskomplexität
• Anzahl der Systemschnittstellen
Seite 11 von 388
 Vilsmeier
Die enorme Zunahme der Engineering Komplexität
erfordert ein effizientes Management
Auftragsabwicklungsprozesse (kaufmännisch)
Engineering Prozesse (technisch orientiert)
Operative
Operative Daten
datenerzeugende
erzeugende
Engineering
Engineering
Anwendungen
Anwendungen
Grundlagen
Operative, Wertschöpfende Informationsprozesse
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).
Seite 12 von 388
 Vilsmeier
Product Lifecycle Management (PLM)
Integration des Datenu. Prozessmanagement
Basis PLM Methoden
Datenmanagement
Grundlagen
Komponenten des PLM - Ansatzes
PLM-Methoden u. –
Modelle werden durch
eine PLM-IT-Systemumgebung unterstützt
Prozessmanagement
Übergreifende PLM Methoden
Zentrale Verwaltung
von Benutzerrechten
Verfügbarkeit von integrierten PLM-Meta-Daten
u. -Prozessmodellen
Trennung zwischen
Metadaten und Nutzdaten bei digitalen
Dokumenten
Integrierte PLM Metamodelle
Zentrales PLM Datenarchiv
Zentrale Verwaltung
freigegebener digitaler
Dokumente in einem
Datenarchiv
Seite 13 von 388
 Vilsmeier
Struktur eines integrierten PLM Systems
Customising
Basis PLM - Funktionen
Datenmanagement
Grundlagen
PLM-Benutzungsoberfläche
PLMAnpassungsund
Administrationsfunktionen
PLM Schnittstellen
Prozessmanagement
• Datenmodellierung
• Datenverwaltung (Erzeugen,
• Prozessmodellierung
• Datensuche /Retrieval
• Versions-, Varianten-, SichtenManagement
• File-Management
• Datensicherung
• Prozesssteuerung
Ändern, Löschen, Filtern,
Sortieren, Kopieren)
• Prozesssimulation
• Prozessdokumentation
• Prozessvisualisierung
Übergreifende PLM-Funktionen
• Analytics & Reporting
• Engineering Collaboration Mgmt. • ………
• Autoren-Systeme
M-CAD
E-CAD
CAE
CASE
Office
• LDM-System
• SCM/CRM Systeme
• Projektmanagement Systeme
• CollaborationPortale
• Internet-Portale
Marktplätze
• TeileBibliotheken
Integrierte PLM Metamodelle
DBMS
File Management
System
Seite 14 von 388
PLM-Objekte
PLM-Prozesse
• Produktfunktion
• Mitarbeiter
• Produkt
• Anforderung
• Dokument • Projekt
• Produktions- • Techn. Produkt• Prozess
Dokumentation
Ressource
• Freigabeprozesse
• Änderungsprozesse
• Allgemeine Routineprozesse
Zentrales PLM-Datenarchiv
WFMS
Langzeit-Archivierungs-System
 Vilsmeier
Typen von PLM-Systemen
Grundlagen
PLM-Systemtypen
Merkmale
Beispiele
• SAP PLM
• ……….
ERP-nahe
PLM-Systeme
• 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
• ………
Engineering-nahe
PLM-Systeme
(Enterprise PLM)
• Unabhängigkeit von CAx- und ERP-Systemen
• Mittlere Datenintegration CAx- und
ERP-Systemen
• Hohe Leistungsfähigkeit bei übergreifenden
Engineering-Prozessen
• ………
• 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³
• ……….
Seite 15 von 388
 Vilsmeier
Grundsätzliche unternehmensspezifische
System-Architekturen
Unternehmensweites ERP-System
Unternehmensweites,
Integriertes PLM-/ERP-System
Unternehmensweites PLM-System
Grundlagen
ERP-PLM-System-Architektur
Integriertes
Autorensystem mit
lokalem
Datenmanagement
Lokales Datenmanagement
System (LDM1)
Autorensystem
1
Autorensystem x
PLM-Autoren-System-Architektur
Seite 16 von 388
 Vilsmeier
ERPSystemEbene
ERP 1
Übergreifende
PLM-SystemEbene
ERP 2
E-LDM
M-CAD
Mechanik-ProduktEngineering
E-CAD
E-CAD
CASE/Software
Konfiguration
Management-System
Integriertes M-CAD
LDM System
M-LDM
M-CAD
AnforderungsEngineering
Elektrik- u. Elektronik- Software
Entwicklung
Entwicklung
Mechatronik
Seite 17 von 388
ERP 3
Unternehmensweite PLM Plattform
AnforderungsManagement
System
Lokale
PLM-SystemEbene
AutorenSystemEbene
Grundlagen
Unternehemensspezifische 4-Ebenen-PLMArchitektur
CAE-LDM
OfficeLDM
CAE
Office
Berechnung/ Allgemeine
Simulation Dokumente
 Vilsmeier
Customer
PMO
Engineering
System Requirements Analysis
Production
ILS
System Acceptance
System Design
System Integration
Subsystem
Requirements
Analysis & Design
Grundlagen
Überblick Unternehmensprozesse
Subsystem
Integration
SWImplementation
HW
Implementation
Manufacturing
Equipment
Mechanical
Subassembly
Manufacturing
Integral Sub-Processes (constantly improving)
Product Lifecycle Management
Seite 18 von 388
 Vilsmeier
V-Modell – Verzahnung von „klassischen“
Disziplinen und HW- und SW-Entwicklung
System Acceptance
System Design
System Integration
Subsystem
Requirements
Analysis &
Design
Subsystem
Integration
Grundlagen
System Requirements
Analysis
SWImplementation
HW
Implementation
Manufacturing
Equipment
Seite 19 von 388
Mechanical
Subassembly
Manufacturing
 Vilsmeier
Historisches
 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
 Vilsmeier
Auslöser für die Einführung von PLM Systemen
 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
Seite 21 von 388
 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
 Vilsmeier
Signifikante Merkmale von PLM Projekten
Boeing
 PLM System: Teamcenter
 Anzahl der Benutzer: derzeit ca. 30000
 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:
Seite 22 von 388
 Derzeit noch keine echte CAD Integration
 Vilsmeier
Airbus




PLM System: PRIMES (Windchill)
CAD System CATIA V5 mit VPM als TDM gekoppelt
Anzahl der Benutzer: 10000
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:
Seite 23 von 388
 Noch begrenzte Funktionalität
 Sehr rigide Implementierung
 Vilsmeier
MTU Aero Engines
 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:
Seite 24 von 388
 Eine Benutzeroberfläche für Teamcenter Enterprise und Engineering
 Vilsmeier
EADS CASSIDIAN Air Systems
 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“
Datenaustausch produktiv
 Defizite:
Seite 25 von 388
 Keine direkte CAD Integration – STEP Schnittstellen VPM
 Fehlende Integration der frühen Entwicklungsphasen
 Vilsmeier
 PLM Systeme
Zusammenfassung
Seite 26 von 388
 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
 Vilsmeier
Strategien für die Einführung
 Think Big
Einführung von PLM
Grundsätze
 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
Seite 27 von 388
 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
 Vilsmeier
Treiber für die VerÄnderungsprozesse ...
Einführung von PLM
Treiber für eine PLM Einführung
Fundamental weitreichende
Anforderungen
Nicht umkehrbare
Globalisierung
Geänderte Geografische
Ausrichtungen
Sämtliche Prozesse in den
Unternehmen stehen auf
dem Prüfstand
Optimale IT-Strukturen
sind Voraussetzung für
Wettbewerbsstärke
Seite 28 von 388
Herausforderungen des Marktes:
„Time to Market“
„Customer satisfaction“
„Design to cost“
„World class quality“
Reaktionen der Unternehmen:
„Zeitwettbewerb“
„Kundenorientierung“
„Kostenwettbewerb“
„Qualitätswettbewerb“
Prozesswettbewerb
Reorganisation
Ablaufoptimierung
Nur mit optimaler IT-Infrastruktur möglich
 Vilsmeier
Einführung von PLM
Bottom up
 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
 Vilsmeier
Einführung von PLM
Top down
 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
 Vilsmeier
 Ohne überzeugte Leitungsmitglieder und
motivierte Mitarbeiter sind PLM Projekte schwer
umzusetzen, da
Einführung von PLM
Top down und bottom up
Seite 31 von 388
 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
 Vilsmeier
 Es gibt dafür wahrscheinlich so viele
Vorgehensweisen wie Projekte, einige
Möglichkeiten werden dargestellt:
Einführung von PLM
Start eines PLM Projektes (1/3)
Seite 32 von 388
 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)
 Vilsmeier
 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
Einführung von PLM
Analyse und Definition Projekt - Ziele, -Strategie, -Umfang
Klärung PLM Prozess-, Schnittstellen-, IntegrationsAnforderungen, 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
Seite 33 von 388




Formale Spezifikation der Anforderungen
Ausschreibung des Projekts
Benchmarking der PLM Systeme und Anbieter
Auswahl und Projektauftrag
 Vilsmeier
 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,
Seite 34 von 388
Was ist nun zu tun?
 Vilsmeier
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
Seite 35 von 388
 Ist die „out-of-the-box“ Funktionalität für das Startprojekt
überzeugend?
 Gibt es Schnittstellen für einzubindende Anwendungen?
 Vilsmeier
Vorbereitung des gesamten Unternehmens für das PLM Projekt
Review
u. KVP
Einführung von PLM
Das Richtige zuerst
Implementierung
Readiness
Awareness
Seite 36 von 388
KVP: Kontinuierlicher
Verbesserungsprozess
 Vilsmeier
Einführung von PLM
Kommunikation
PLM
Positionspapier
PLM Benutzer
Information
• Kontakt Information
• Erfolgsmeldungen
• Veröffentlichungen
• Ereignisse
• PLM Projekt Update
• PLM Neuigkeiten
Round Table
Benutzer
Seite 37 von 388
PLM Key Note
Präsentation
Top Management
Executive
Seminar
PLM
Seminar
PLM
Schulung
 Vilsmeier
Methoden für die Einführung - Chestra
Methodische Vorgehensweise – z.B. Chestra
Chestra –
Domänen
des Wandels
Hexagon des Wandels
Organisation
Standorte
Prozesse
Daten
 SBS
Seite 38 von 388
Applikationen
Technologie
 Vilsmeier
Chestra – Domänen des Wandels
 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
Seite 39 von 388
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.
 Vilsmeier
Chestra – Domänen des Wandels
 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
Seite 40 von 388
Die Domäne der Technologie behandelt die Hardware, die
Systemsoftware und die Kommunikationskomponenten, die zur
Unterstützung des Unternehmens genutzt werden.
 Vilsmeier
Methoden für die Einführung - Infrastruktur
Was sonst noch benötigt wird (1/2)





Seite 41 von 388
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 (?)
 Vilsmeier
Methoden für die Einführung - Team
Was sonst noch benötigt wird (2/2)
 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
 Vilsmeier
 Mental Change
Methoden für die Einführung
Eckpfeiler einer PLM Einführung
 Notwendigkeit für Mental Change
 Umsetzung des Mental Change
 Projekt Management und Controlling
 Methodisches Vorgehen für die Definition von
Seite 43 von 388
 Prozessmodell
 Datenmodell
 Integration von Anwendungen
 IT-Architektur
 Vilsmeier
Methoden für die Einführung – Mental Change
Notwendigkeit für 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
 Vilsmeier
Seite 45 von 388
Durchbruch
Fortschritt
Phasen in Mental Change Projekten
Ernüchterung
Angst
Begeisterung
Elan
Tal der Tränen
Rückschritt
Zeit
 Vilsmeier
Unterstützung des 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
Seite 46 von 388
Die Wirklichkeit ist meist anders, d.h. Management und
Mitarbeiter gehen auf Distanz.
 Vilsmeier
Methoden für die Einführung – Projektmanagement
Wichtigkeit des Projektmanagements
 Projektmanagement ist nicht der Kern der PLM
Einführung, aber eine wichtige Voraussetzung für eine
erfolgreiche Arbeit
 Aufgaben des Projektmanagements
Seite 47 von 388
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






 Vilsmeier
Methodisches Vorgehen sicherstellen
Vision und Strategie
P
R
O
G
R
A
M
M
M
G
M
T.
Seite 48 von 388
Architektur
Entwicklung
Integration
Einführung
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
Betrieb
 Vilsmeier
Projektorganisation
Seite 49 von 388
PLM Lenkungsausschuss
Auftraggeber (Leitung), Auftagnehmer,
Prozess Eigner
Projekt
Leitung
Projekt
Controlling
Projekt Leitung
Systemlieferant
Externe
Berater
Fachprojektleiter
Projekt
Projekt
TeilprojektLeitung
Leitung
leiter
 Vilsmeier
Dreiecke der Erwartungen/Zwänge
Kunde
Projektleiter
Management
Seite 50 von 388
Mitarbeiter
Lieferung
der Leistung
Auftrag
Zeit
Kosten
 Vilsmeier
Projektphasen
Seite 51 von 388
Planung u.
Start
Durchführung
Beendigung
 Vilsmeier
Projekt Durchführung
Kapitel
1.
2.
3.
4.
5.
6.
7.
8.
9.
Hintergrund
Ziele
Umfang
Liefereinheiten
Lösungsansatz
Risiken
Annahmen
Restriktionen
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
Seite 52 von 388
Projekt Management Plan
Projekt
Definition
Projekt
Plan
Prozeduren &
Werkzeuge
Weitere
unterstützende
Pläne
Unterkapitel
Hauptkapitel
1. Produkt/WBS
1.2.
2.
3.
3.4.
4.5.
5.6.
6.7.
7.
Produkt/WBS
Chart der AbhängigChart
keitender Abhängigkeiten
Terminplan
Terminplan
Projekt Organisaon
Projekt
Organisation
Mitarbeiter
Profile
Mitarbeiter
Profile
Budget
Budget
ZahlungsmeilenZahlungsmeilensteine
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
 Vilsmeier
• Verträge u. andere
Vereinbarungen
• Konfig. Mgmt. Plan
• Change Requests,
Problem Reports
• Leistungsvereinbarungen
• Leistungsbewertung
Management von Arbeitsergebnissen
Konfiguration
Mgmt.
Personal
Mgmt.
Problem
Mgmt.
Überwachung
& Verfolgung
Projekt
Ergebnisse
• Qualitätsplan
• Abnahme Protokolle
• Arbeitsblätter für
Risiko Aufnahme
und Bewertung
• Risiko Abminderungsplan
Seite 53 von 388
Qualität
Mgmt.
Risiko
Mgmt.
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
 Vilsmeier
Anwendungen
Prozesse
Kontrolle, Monitoring
Der Zielereichung
Für Gesamt- oder
Teilprojekte
Seite 54 von 388
OrganiDaten
sation
Soll
Ist
Technologie
Standorte
 Vilsmeier
Projekt Durchführung – Projekt-/Teilprojektphasen
Teilaktivität
Benennung
Inhalt
Phase 0
Gesamt-Setup
Planung des Gesamtprojekts, der Gesamt-ControllingMaß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
Grobspezifikation
(Konzept)
Übergreifende, konzeptionelle Darstellung der
künftigen Funktionalität in ihrer Relation zu
Prozessen, Informationsobjekten und anderen ITSystemen
Phase 2
Funktionale
Feinspezifikation
Detaillierte Beschreibung der geforderten
Funktionalität aus Sicht der Anwender/ Nutzer als
Referenz für die softwaretechnische Realisierung
Phase 3
Prototyping (gegebenenfalls parallel
zur Phase 2)
Beispielhafte Realisierung bestimmter,
vereinbarter Teile der Gesamtfunktionalität zur
Prüfung auf Plausibilität
Seite 55 von 388
 Vilsmeier
Projekt Durchführung – Projekt-/Teilprojektphasen
Teilaktivität
Benennung
Inhalt
Phase 4
DV-technische
Feinspezifikation
Detaillierte Beschreibung der Funktionalität aus DVtechnischer Sicht, insbesondere Darstellung der
Anforderungen an Hardware- und Betriebssystem.
Phase 5
Realisierung
Softwaretechnische
Funktionen.
Phase 6
Integration und
Test
Zusammenfügen aller Funktionen zum
Gesamtsystem, Test der Funktionalitäten .
Phase 7
Implementierung
und Migration
Bereitstellung des Gesamtsystems für den
Produktivbetrieb sowie der bereits vorhandenen AltInformationsobjekte.
Phase 8
GesamtAbnahme
Prüfung des Gesamtsystems auf vollständige
Erfüllung der beschriebenen Funktionalitäten.
Control
ling
Projektcontrolling
(querschnittlich)
Vergleich der Planungskennzahlen mit den realen
Kennzahlen mit entsprechender Reaktion.
Seite 56 von 388
Bereitstellung
der
einzelnen
 Vilsmeier
 Vorgehen in drei Stufen:
Methoden für die Einführung – Prozesse
Definition der Prozess Modelle
 Geschäftsprozesse und Überblick
 Arbeitsprozesse
 Elementare Business Prozesse
 Beispiele:
Seite 57 von 388
 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
 Vilsmeier
Geschäftsprozesse
Ausrichtung auf und nach Geschäftsprozessen fördert die
Rückbesinnung auf originäre Unternehmensziele.
M
Kunde
M
Teilprozess
M
Teilprozess
!
M
Teilprozess
Kunde
!
Geschäftsprozesse beginnen und enden bei Kunden
klarer Fokus
Geschäftsprozesse besitzen eine Meilensteinstruktur
Zwang
zu Ergebnissen
Seite 58 von 388
 Vilsmeier
Arbeitsprozesse (Aktivitäten)
Arbeitsprozesse bilden konkrete Tätigkeiten ab ...
In Geschäftsprozessen werden über die Meilensteine unterschiedlichste
Arbeitsprozesse aufgerufen. Diese beschreiben unter funktionalen Gesichtspunkten die konkreten Tätigkeiten im Unternehmen und produzieren die
Ergebnisse für die Teilprozesse.
„deliverables“
GeschäftsProzess
„Aufgabe“
Ergebnis
ArbeitsProzesse
(=Technische
UnterstützungsProzesse)
Arbeitslast
Seite 59 von 388
 Vilsmeier
Top down Vorgehen bei Prozessaufnahme
Seite 60 von 388
 Vilsmeier
Prozesslandkarte
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
Geschäftsprozeß Produktentwicklung
Version 4.5
- Seite 1 (Stand vom 28.09.98)
Vorentwurf
M1
M2
M0
PE-1
PE-2
PE-3
M3
M4
PE-4
Definitionsphase
M5
M6
PE-5
PE-6
PE-7
M7
Entwicklungs- und Fertig
M9
M 10
M 11
M8
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
Seite 61 von 388
 Vilsmeier
Stufenweise Prozess Detaillierung
Production
readyness
Start
Serie
S0
Serienbeauftragung
erwirken
SA-0
S3
Produktionsprogramm
planen
SA-1
S0
Start
Serienprozeß
Produktionsmittel planen
und
bereitstellen
Kontinuierliche Weiterentw. d. Std.Komponenten
Serienreifmachung
vornehmen
SA-3
Start
final
assembly
First flight
readyness
S5
S7
S9
Fertigung
des
single a/c
planen
SA-4
Kundenwünsche
für single a/c
integrieren
SA-2
Fertigungsplanung
abgeschlossen
SA-6
SA-5
S2
S4
Start Serienvorbereitung
Start
Produktion
Teile
fertigen
bzw. beschaffen
Montage
Komponenten
SA-7
SA-8
Montage
Serienflugzeug
Bodentests
SA-9
SA-10
Businessprozessebene
Flugtests
und
Abnahme
(Detaildarstellung mit
Teil-GP)
SA-11
S6
S8
S10
Start
Komponentenfertigung
Status
power-on
erreicht
Delivery
single a/c
Detaillierung auf
Aktivitätenebene
Standards für Spezifikationsphase bereitstellen
EL-3.1
(Teil-) Aktivitätenebene
Aktivität
Equipment-Einbauinformationen als
Vorgabe definieren
EL-3.4.5
EL-3.4.1
Aktivität
EL-3.4.6
Aktivität
EL-3.4.7
Hüllgeometrie des
Equipments
bereitstellen
Verfeinerung der Aktivitäten bis
auf Ebene des „elementaren BP“
(EBP)
EL-3.4.2
Geometrie der
Hauptkabelwege
festlegen
EL-3.4.3
Geometrie der
Haupttrennstellen
festlegen
Aktivität
EL-3.4.4
EL-3.4.5
Aktivität
Geometrie der VEEinheiten als Hüllgeometrie festlegen
EL-3.4.6
EL-3.4.5
Aktivität
Teilgeometrie zum
Digital-Mock-Up
zusammenstellen
EL-3.4.7
EL-3.4.6
Abstimmung
durchführen
Aktivität
EL-3.4.5
Quelle: debis Systemhaus, STA-Methodik
Seite 62 von 388
EL-3.4.7
Digital-Mock-Up auf Equipment-Ebene erstellen
EL-3.4
M7
 Vilsmeier
Geschäftsprozess Produktentwicklung
Beschreibt den gesamten Handlungsablauf auf Unternehmensebene zur
Entwicklung eines Flugzeugs bis zur Serienreife. Er wurde als Sollprozess
dargestellt, unabhängig von laufenden Vorhaben.
Entwicklungs- und
Fertigungsphase
Vorentwicklungsphase
Start
ProduktEntwicklung
M0
M2
Strategi- Technosche Ent- logiekonwicklungs- zepte
planung
entwikdurchf.
klen
PE-1
Auslegungsdefinition
abgeschlossen
M4
Produkt-Ideen
verfügbar
PE-2
Marktuntersuchung
durchführen
PE-3
Produktstudien
durchführen
PE-4
M6
Basiskonzept
entwikkeln
PE-5
Status
go ahead
erreicht
M8
Status ITP
erreicht
Feinkonzept
erstellen
PE-6
Entwicklungsangebot
erstellen
Produkt
spezifizieren
PE-7
PE-8
First flight
readyness
M10
M12
Beschaffung und Montage
TeilefertiProtogung Pro- typen
totypen
ProduktInformationen
erstellen
PE-9
Begin final
assembly
PE-10
PE-11
Bodentests
PE-12
Status
FOC
erreicht
M14
Leistungsnachweis
u. Refurbishing
Flugerprobung
PE-13
PE-14
M1
M3
M5
M7
M9
M11
M13
Start
TechnologieEntwicklung
Bedarfsermittlung
abgeschlossen
Configuration
Freeze
erreicht
Status ATO
erreicht
Status
first metal cut
erreicht
Status
power on
erreicht
Status a/c
certification
erreicht
Definitionsphase
Seite 63 von 388
 Vilsmeier
Geschäftsprozess Serienabwicklung
Beschreibt den Handlungsablauf für die Serienfertigung der Flugzeuge.
Production
readyness
S3
Start
Serie
S1
Serienbeauftragung
erwirken
SA-0
S0
Start
Serienprozeß
Produkttionsprogramm
planen
SA-1
Produktionsmittel planen
und
bereitstellen
SA-2
Serienreifmachung
vornehmen
SA-3
S2
Start Serienvorbereitung
Kontinuierliche Weiterentw. d. Std.Komponenten
SA-4
Kundenwünsche
für single a/c
integrieren
SA-5
Fertigungsplanung
abgeschlossen
S5
Fertigung
des
single a/c
planen
SA-6
S4
Start
Produktion
Teile
fertigen
bzw. beschaffen
SA-7
Start
final
assembly
S7
Montage
Komponenten
SA-8
S6
Start
Komponentenfertigung
First flight
readyness
S9
Montage
Serienflugzeug
SA-9
Bodentests
SA-10
S8
Status
power-on
erreicht
Flugtests
und
Abnahme
SA-11
S10
Delivery
single a/c
oder
Für jedes einzelne
Flugzeug
Seite 64 von 388
 Vilsmeier
Geschäftsprozess In-Service-Support
Beschreibt die (möglichen) Aktivitäten
im Umfeld ausgelieferter Serienflugzeuge.
Diese erstrecken sich parallel zueinander
über die gesamte life-cycle-Phase eines
Produkts.
Änderungswesen
PS-1
Ersatzteilwesen
PS-2
Produkterhaltung
PS-3
Dienstleistungen
B0
Logistic
Support Date
Seite 65 von 388
PS-4
B1
Verschrottung
 Vilsmeier
Vorgehensweise zur Prozessaufnahme
Standardvorgehensweise
Standardvorgehensweise
1 Prozessaufnahme
2 Darstellung der
Ist-Prozesse
4 Festlegen der
Soll-Prozesse
3 GP-Analyse
1 0 0
8 0
6 0
E r s t . L s t H f t
4 0
2 0
E r s t . P f t H f t
F r e i g . C
0
Iteratives für
Vorgehen
Vorgehen
Grobspec. V3
2 IterativesFestlegen der Soll-Prozesse
1 Prozessaufnahme
bzw.. - analyse
Ausnahmen zuerst ausschließen
Seite 66 von 388
 Vilsmeier
Elementare Geschäftsprozesse
Es wird nur ein zusammenhängender
Zeitraum betrachtet, d.h. zeitlich
auseinander liegende Aktivitäten
werden in mehreren EBP dargestellt
T0
automatische
und ...
Elementarer
Geschäftsprozess
Zu bearbeitende Objekte
bleiben konsistent, d.h. sie
lassen sich nicht sinnvoll
zerlegen
Seite 67 von 388
nur eine Aktivität
Elementarer
Elementarer
Geschäftsprozess
Geschäftsprozess
... manuelle
Tätigkeiten
Exakt eine Rolle zugeordnet
 Vilsmeier
Definition des Elementaren Business Prozess
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
 Vilsmeier
Definition des Elementaren Business Prozess
 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
Seite 69 von 388
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.
 Vilsmeier
Informationen zum EBP
 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 "NichtProzesskenner" verstehen, was bei der jeweiligen Aktivität zu tun ist.
 Rolle
Seite 70 von 388
Handelt es sich bei dem Prozessschritt um eine manuell durchgeführte
Aktivität, so muss (genau) eine Rolle zugeordnet werden.
 Vilsmeier
 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 MSWord, CATIA, LCABLE, PLM etc. dokumentiert werden.
 Standort
Jeder Prozessschritt muss (mindestens) einem Standort zugeordnet
werden.
 Datenvolumen und Transaktionsvolumen
Seite 71 von 388
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).
 Vilsmeier
 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
Ebene 1
E1
E1.1
Teilprozess
Ebene 2
E1.1.1
E1.1.2
E1.2
E1.2.1
E1.2.2
Seite 72 von 388
EBP
E1.1.1.1
E1.1.1.2
E1.1.1.3
E1.1.2.1
E1.1.2.2
E1.2.1.1
E1.2.1.2
E1.2.1.3
E1.2.2.1
 Vilsmeier
Beispiel der Darstellung von Arbeitsprozessen
(Aktivitäten)
M6
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
Spezifikationsinformation freigeben
EL-3.5
Spezifikationsinformation automatisiert
zusammenstellen
EL-3.6
Funktionale Spezifikation der Elektrik-Komponenten erstellen
EL-3
M7
Seite 73 von 388
 Vilsmeier
Beispiel für tabellarische Beschreibung von EBP
Prozess
Ref.-Nr.
Titel/ Erläuterung
EL-3.4.1.1 Equipment-Einbauinformationen als Vorgabe definieren
Input
Waffensystemspezifikati
on
Grundlage für die Untersuchungen am DMU, hier insbesondere Systemspezifikation
der Einbauuntersuchungen für die Equipments und die
Equipmentspezifikation
Verlegung der Kabelbündel, ist das Modell der Struktur, in das Equipment
die verschiedenen System eingebaut werden müssen.
EL-3.4.1.2 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)
EL-3.4.1.3 Hauptkabelwege festlegen
Hier erfolgt die Festlegung der Hauptkabelwege (Bündel).
Zusätzlich werden die erforderlichen Durchbrüche in
Zusammenarbeit mit Statik und Struktur festgelegt
EL-3.4.1.4 DMU-Anpassungen für Hautkabelwege durchführen
Seite 74 von 388
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.
Output
Einbauinformation (inboard profile)
DMU-Modell
(Waffensystem)
Einbauinformation (in- DMU-Modell
board profile)
(Equipment)
CAD-Modell (Equipment)
Wirksystem(e)
Rolle
MS-Office
Strukturentwicklu
HTML-Browser
ng
(WissensDB)
DMS
PDM
CATIA
DMU-Tool
DMS
Geräteeinbau
PDM
CATIA
DMU-Tool
Normteillibrary
(Geometrie)
Systemspezifikation
QAR
Circuit-Diagram
DMU-Modell
(Hauptkabelwege)
DMS
LCABLE
Kabelbündeleinba
u
DMU-Modell
(Hauptkabelwege)
DMU-Modell
(Waffensystem)
DMU-Modell
(Waffensystem)
PDM
CATIA
DMU-Tool
Strukturentwicklu
ng
 Vilsmeier
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
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
EL-1.4
Inhaltliche Standards für Konzeptphase erstellen
R
EL-1.5
Worksharing bezogen auf die Systeme des Waffensystems beschreiben
R
EL-2
Feinkonzept für Systeme erstellen
.
.
.
.
.
.
EL-2.1
Komponenten jedes Systems beschreiben
EL-2.2
Funktionale Anforderungen des Systems beschreiben
EL-3
Funktions-Spezifikation der Elektrik-Komponenten erstellen
.
.
.
C = Create (Erstellen)
C = Create (Erstellen)
R = Read (Lesen)
R = Read (Lesen)
= Update (Aktualisieren)
U = UpdateU(Aktualisieren)
D = Delete (Löschen)
D = Delete (Löschen)
Ref.Nr.
EL-3.1
Seite 75 von 388
Prozeß
Elektrischen Anteil der Systeme identifizieren
.
.
.
.
.
CU
R
.
.
CU
.
.
.
.
.
.
.
.
.
.
U
 Vilsmeier
Funktionales Zusammenwirken der Equipments untereinander definieren
EL-3.3.1
Software-Funktionen zum System spezifizieren
EL-3.3.2
Mechanisches Zusammenwirken auf Equipment-Ebene spezifizieren
EL-3.3.3
Elektrisches Zusammenwirken der Equipments untereinander spezifizieren
Equipmententwickler
Elektrik-Konstrukteur
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Einkauf
.
DMU-Team
.
CAD-Modellierer
.
Bündelmonteur
Materialwirtschaft
EL-3.3
Kommissionierung
Equipment entwickeln
Kabelbündeleinbau
EL-3.2.3
Gerätekonstruktion
Zulieferer auswählen
Geräteeinbau
EL-3.2.2
Fertigungsplaner
Prozeß
Fertigung
Ref.Nr.
Betriebsmittelplaner u. Montageplaner
= Führt aus
X = XFührt
aus
Betriebsmittelkonstruktion und -fertigung
Zuordnung von EBP und Rollen
x
EL-3.3.3.1 Relevante Randbedingungen ermitteln
EL-3.3.3.2 Circuit-Diagram erstellen
EL-3.4
Vorläufiges Digital-Mock-Up erstellen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
EL-3.4.1
Vorläufiges Digital-Mock-Up vorbereiten
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
x
EL-3.4.1.2 Hüllgeometrie des Equipments bereitstellen
x
EL-3.4.1.3 Hauptkabelwege festlegen
EL-3.4.1.4 DMU-Anpassungen für Hautkabelwege durchführen
Seite 76 von 388
EL-3.4.1.5 Geometrie der VE-Einheiten als Hüllgeometrie festlegen
x
 Vilsmeier
x
Ref.Nr.
HTML-Browser
HOOK
FACT
EPOS
EIS
DMU-Tool
DMS
CORE
CATIA
CADAM
Verwendet
X X== Verwendet
ASAP
Zuordnung von EBP und Wirksystemen
Prozeß
EL-3.2.1.6 Umgebungsbedingungen spezifizieren
x
x
EL-3.2.1.7 RMT-Aspekte spezifizieren
x
x
EL-3.2.1.8 Sonstige Anforderungen spezifizieren
x
x
EL-3.2.2
Zulieferer auswählen
x
x
EL-3.2.3
Equipment entwickeln
EL-3.3
Funktionales Zusammenwirken der Equipments untereinander definieren
EL-3.3.1
Software-Funktionen zum System spezifizieren
EL-3.3.2
Mechanisches Zusammenwirken auf Equipment-Ebene spezifizieren
EL-3.3.3
Elektrisches Zusammenwirken der Equipments untereinander spezifizieren
x
.
.
.
x
.
.
x
x
.
.
.
.
x
.
.
x
x
x
.
.
.
.
EL-3.3.3.1 Relevante Randbedingungen ermitteln
.
x
.
.
.
.
.
x
.
x
EL-3.3.3.2 Circuit-Diagram erstellen
x
EL-3.4
Vorläufiges Digital-Mock-Up erstellen
.
.
.
.
.
.
.
.
.
.
.
EL-3.4.1
Vorläufiges Digital-Mock-Up vorbereiten
.
.
.
.
.
.
.
.
.
.
.
x
x
x
x
x
x
Seite 77 von EL-3.4.1.2
388
Hüllgeometrie des Equipments bereitstellen
x
x
x
 Vilsmeier
Seite 78 von 388
Augsburg
Manching
Bremen
Partnerstandorte
EL-4.1.4.1 Digital-Mock-Up für Bauanteil zusammenstellen
x
EL-4.1.4.2 DMU-Prüfungen durchführen
x
EL-4.1.4.3 Gemeinsame Abstimmung durchführen
x
EL-4.2
Konstruktionsfreigabe durchführen
x
EL-5
Elektrik-Komponenten fertigen
.
.
.
.
.
EL-5.1
Arbeitsvorbereitung durchführen
.
.
.
.
.
EL-5.1.1
Fertigungsplan erstellen
x
EL-5.1.2
Betriebsmittel erstellen
x
EL-5.1.3
Material bestellen
x
EL-5.2.4
Anschlußelemente in VE-Box montieren
x
EL-5.2.5
Leitungen in VE-Box verlegen
x
.
.
X = betroffener
Standort
Ref.Nr.
Ottobrunn
Zuordnung von EBP zu Standorten
Prozeß
EL-6.1.1.1 Montageplan erstellen
x
EL-6.1.1.2 Betriebs- und Prüfmittel erstellen
x
EL-6.1.1.3 Material beschaffen
x
EL-6.1.1.4 Testprogramme und Testproceduren (Stage A) erstellen
x
EL-6.1.2
Kabelbündel- und Gerätemontage vorbereiten
.
.
.
EL-6.1.2.1 Kennschilder anbringen
x
EL-6.1.2.2 Erforderlichen Geräteeinbau vor Kabelmontage durchführen
x
EL-6.1.2.3 Massetests durchführen
x
 Vilsmeier
Erfassung von Daten- und Transaktionsvolumina
zu EBP
Seite 79 von 388
Ref.Nr.
Prozess
Anzahl
Spitze
Grö
ße
Wachstum
Anmerkungen
EL4.2.1
Neuauftrag
5.00
/ Mo
4,00/
Wo
50
kB
20%/
Jahr
Spitze ist letzte
Woche im
Monat.
Änderungsauftrag
2.00
/ Mo
1.50/
Wo
75
kB
20%/
Jahr
Spitze ist letzte
Woche im
Monat.
Kreditgenehmigung
5.00
/ Mo
4.00/
Wo
120
kB
15%/
Jahr
Spitze ist letzte
Woche im
Monat.
Neuer Kunde
1.80
/ Mo
1.50/
Wo
30
kB
15%/
Jahr
Spitze ist erste
Woche im
Monat.
 Vilsmeier
Aufnahme von Anforderungen für mehrere EBP
Seite 80 von 388
Anf.-Nr.
Anforderungsbeschreibung
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
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
A02
A03
A04
betr.
Prozesse
EL-2.1
EL-2.2
EL-3.2.1
EL-3.3.3.2
EL-4.1.3.5
EL-3.2.3
EL-3.4.1.2
EL-4.1.2.2
 Vilsmeier
Frage nach SW Unterstützung für
Prozessmodellierung
 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
Seite 81 von 388
 Einheitliche Darstellung
 Hohe Integration möglich (Prozesse, Daten, Rollen, etc.)
 Ein Unternehmensmodell theoretisch möglich
 Vilsmeier
Prozessmodellierung bei EADS CASSIDIAN
 Keep it simple
Seite 82 von 388
 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
 Vilsmeier
Definition der Daten Modelle
Methoden für die Einführung – Daten
Ausgangssituation
Seite 83 von 388
Datenmodell
PLM System
Datenmodelle
Datenmodelle
Datenmodelle
Partnerfirmen
Partnerfirmen
Partnerfirmen
PLM
Enablers
Neues
Datenmodell?
Datenmodelle
Datenmodelle
Datenmodelle
„Altsysteme“
„Altsysteme“
„Altsysteme“
STEP Modelle
PLM Schema,
AP 214P
 Vilsmeier
Composed of
Giver
Auswahl von Beziehungen zwischen Daten
Releases
Work
Receiver
Enterprise
Releases
Built by
Calls out
Includes
Uses Product
Described by
Uses
Collection
Seite 84 von 388
Releases
Supplied by
Modeled
by
Model
Uses
Derived from
Includes
 Vilsmeier
 Datenmodell des PLM Systems
Randbedingungen
 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
Seite 85 von 388
 Sind meist nicht komplett dokumentiert
 Beschreiben Modelle, welche nicht mehr zum PLM
Ansatz passen (z.B. zeichnungsbasiert, Management
von Stücklisten)
 Vilsmeier
 STEP Datenmodelle
Randbedingungen
 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
Seite 86 von 388
 Ansatz zur Vereinheitlichung durch wichtige PLM
Anbieter
 Sollte auf alle Fälle begleitend betrachtet werden
 Vilsmeier
 Partnerfirmen
Randbedingungen
 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.
Seite 87 von 388
 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.
 Vilsmeier
Vorgehensweise zur Entwicklung des
Datenmodells
 Planung und Durchführung von Workshops –
z.B. Meta Plan Methode
 Vorbereitung:
Seite 88 von 388
 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.
 Vilsmeier
Vorgehensweise zur Entwicklung des
Datenmodells
 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?
Seite 89 von 388
 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
 Vilsmeier
Anforderungen an Moderatoren
 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
 Vilsmeier
Ziele für Datenmodell
 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
 Vilsmeier
Beispiel aus einem Work Shop
Seite 92 von 388
 Vilsmeier
Überblick konzeptionelles Datenmodell
Datenmodell
Version
C00
Committed
Dasa-M-Datenmodell
Version C-00 vom 3.3.98
Dokumenten-Management
initializes Requirement Item
Property Relation
Property
Relationship
Function Relation
Function
Relationship
Geometrie
DMU
Product Function
Ident-Nr
persistent
persistent
Properties
has properties
is represented by
persistent
is descibed by
item has function
Collected Document
Relationship
persistent
1+
1+
Document
Relationship
persistent
collected relation
View
Document Relation
Representation
is represented by
Mass Properties
Material Property
Item Properties
Value_Interpretation
Class
Label
Norm
persistent
persistent
1+
persistent
Item Relationship
item relation representation
Item Relation
{abstract}
persistent
1+
persistent
created by
created on
represents relation
Item relation description
1+
related_file
data/protocol
Assembly
Component
Relationship
User
Collected
Relationship
Quantity
Transformationmatrix
Ausbaureihenfolge
Einbaureihenfolge
MeasureUnit
User
Purpose
Physical
Realisation
Relation
general item
relationship
Functional
System
Relationship
Geometrical Relationship
Transformationmatrix
persistent
Described by
Document Item
persistent
persistent
Digital
Document
persistent
persistent
persistent
persistent
Archive
Document
Physical
Model
persistent
persistent
Format
is described by
Item Version
Relationship
RelationshipType
Instance
Relationship
ICY Approval
associated to
1+
Item Version
Item Version Relation
Type
TypeNumber
persistent
Instance Relation
has effectivity
persistent
1+
1+
1+
1+
Approval Relation
Item Version End
Item Rel
Approval
Relationship
1+
Approval
Product Class
Relationship
Item Version Approved {ordered}
approval_status
item_exchange
persistent
Item Approval
persistent
{ordered}
Date
approved on
is sub/superclass
created on
actual/target
1+
actual/target
is described by
created by
1+
date
time
actual/target
actual/target
Product Class
related_date
persistent
persistent
actual/target
sent/received
associated to
1+
has Version
General Classification
is described by
classified
1+
approved by
Type
1+
Type
Item
created by
1+
persistent
1+
{abstract}
Specific Classification
Person or Organization
{abstract}
Type
Type
created on
persistent
Type
sender/receiver
persistent
exchange_partner
classified
used in project
1+
is described by
1+
1+
exchange
persistent
Person
Organization
Security
NATO-Code
Work Order
persistent
Requirement
Item
Instance Item
Activity Item
Space
Envelope Item
persistent
ordered by
1+
1+
1+
persistent
End Item Relation
1+
Document
Item
Product Item
End Item
Functional
System Item
Function persistent
type
change_request_exchange
effects Config Item
1+
initialize
1+
Change Request Effectivity
persistent
persistent
transitory
Change Request
Version
changes
Type
{abstract}
{abstract}
1+
1+
1+
End Item
Relationship
1+
persistent
employed at
1+
persistent
persistent
persistent
Konfigurations-Management
persistent
created by
type
Standort
created on
has Approval
persistent
1+
1+
1+
1+
Change Request
End Item Rel
1+
Part Item/
Assembly Item
PartType
PartNumber
SiteCode
TitleEng
TitleGer
BoMrelevant
Software Item
persistent
End Item Collection
End Item Instance
Lot
Date
Block
Batch
Tail-Number-Range
Usage-Profile
Tail-Number
Request Version Relation
Request Version
Relationship
persistent
1+
persistent
persistent
has Change Request Version
Change Request
type
title
id
is valid
persistent
Change Request Relation
Elektrik/
Software &
Systeme
Effectivity
Relationship
persistent
Request Relationship
Effectivity
persistent
1+
1+
influenced by
used in project
Contract
Effectivity Approval
{abstract}
Effectivity Relation
1+
Relation Type
is valid
persistent
persistent
persistent
1+
Project
Planned Effectivity
Real Effectivity
in line
in service
method of
embodiment
Position
Serial-Number
Applicability
1+
id
1+
1+
affects
1+
Project Relation
persistent
persistent
persistent
Project Relationship
1+
persistent
persistent
used in project
Document Contract Relation
is described by
is described by
Änderungs-Management
Seite 93 von 388
 Vilsmeier
Office Integration
Create Document (z.B. Produkt-Spezifikation)
Wenn Sie die Berechtigung besitzen, in PLM Objekte anzulegen, können Sie dies über eine
dem Objekttyp entsprechende Create-Funktion.
Seite 94 von 388
Pflichtfenster ausfüllen
Es wird automatisch ein leeres
Office-Dokument angelegt.
 Vilsmeier
Attribute beim „create“ eines Office Dokuments
Seite 95 von 388
 Vilsmeier
Office Dokument (Data Item) ist mit dem
Dokument Business Item verknüpft
Die Office Anwendung verhält sich
wie gewohnt, das Data Item wird jedoch vom PLM System kontrolliert.
Seite 96 von 388
 Vilsmeier
Registrieren von Dokumenten in der Work
Location
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
 Vilsmeier
Maske für Metadaten (z.B. Excel Dokument in
Work Location)
Zu Metadaten/ Attribute zählt z.B. der Projektname, die Nummer eines Objekts,
Fertigungsort, Werkstoff
Seite 98 von 388
In dem Ergebnisbrowser sind in
der Regel nur
ausgewählte
Informationen
(Metadaten)
zusammengestellt
 Vilsmeier
Objekt zur Bearbeitung aus dem Vault holen
(Check Out)
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
 Vilsmeier
Objekt an den Vault übergeben (Check In)
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.
Seite 100 von 388
In der Dialogbox geben Sie den Namen
des Vaults an bzw. wählen diesen aus der
angebotenen Selektionsliste aus.
 Vilsmeier
Dokumente an Produktstrukturknoten verwalten
(Tree view)
Objekt-Relationen
können ausgeblendet werden
Mit Drag & Drop (oder per
expliziter Anweisung) kann ein
Objekt an einen Knoten der
Produktstruktur „angehangen“
werden.
Seite 101 von 388
 Vilsmeier
Cycle/ Workflow
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 PLMAdministrator durch; als Anwender können Sie dann den vordefinierten Life Cycle
benutzen.
Seite 102 von 388
 Vilsmeier
Integration von Anwendungen
Beispiel Office Anwendungen
 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
Seite 103 von 388




Suche über Querys oder Navigation in Strukturen
Elektronische Freigabe und Review
Konsistente Versionierung und Kontrolle
Verknüpfung mit Konfigurations- und Change Management
Methoden
 Vilsmeier
 Welche Rolle soll das PLM System im
Unternehmen spielen?
 Single source für alle engineering Daten? Wenn ja
IT - Architektur
Fragen vor IT Architektur Diskussion
Seite 104 von 388
 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?
 Vilsmeier
IT Architektur Gesamtunternehmen
Dasa-M IV-Strategie
(Schalenmodell der IV-Architektur)
Workflow-Systeme
Managementder
derInformationsInformationsManagement
flüsseüber
überWorkflow-Systeme
Workflow-Systeme
flüsse
Wirksysteme
Optimierungder
derArbeitseffizienz
Arbeitseffizienz
Optimierung
überWirksysteme
Wirksysteme
über
Datenverwaltungssysteme
Managementder
derDatenhaushalte
Datenhaushalte
Management
über
Datenverwaltungssysteme
über Datenverwaltungssysteme
IT-Infrastrukturen
Umfassendes
Wissiensmanagment
Kommunikationsplattform
Wissiensmanagment
IT-Support
Supportund
undUnterstützungsUnterstützungsSupport
leistungen
leistungen
Kommunikationsplattformen und Integration
Umfang, Architekturrahmen und Vorgaben
Umfang, Architekturrahmen und Vorgaben
IT - Architektur
Seite 16
Leistungsfähigeund
undzukunftszukunftsLeistungsfähige
sichere
IT-Infrastrukturen
sichere IT-Infrastrukturen
Für
Fürjedes
jedesAnwendungsfeld
Anwendungsfeldbei
beiDasa-M
Dasa-M
Seite 105 von 388
 Vilsmeier
Architektur mit geringer Integration
Engineering
Applications
IT - Architektur
A u t h o r i n g S y s t e m s (Originaldaten)
Data
Exchange
Seite 106 von 388
Design
Applications
Document
Applications
PLM Backbone System
Viewing
Systems
Down Stream
Systems
 Vilsmeier
Architektur mit hoher Integration
Secondary Data Base
Engineering
Applications
IT - Architektur
A u t h o r i n g S y s t e m s (Originaldaten)
Design
Applications
Local Team
Data Manager
Document
Applications
Data
Exchange
Advanced
Communication
Seite 107 von 388
PLM Backbone System
Viewing
Systems
Down Stream
Systems
 Vilsmeier
CATIA
CATIA E3D
3D
Session
IT - Architektur
PLM Architektur EADS DS MAS
3D
Viewer
DMU-
VPM NAV
Electric Information System
Product Structures
STEP
Seite 108 von 388
PLM
Change & Configuration Mgmt
Document Mgmt
2D-Archive
(TIFF)
ASAP
Office
Toolset
LCABLE
TeamCenter
System
Development
Toolset
Logistics
Toolset
 Vilsmeier
Configuration und Change Management
CMII - Configuration Management II
Seite 109 von 388
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.
 Vilsmeier
CMII - Definition
Seite 110 von 388
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
 Vilsmeier
CMII – Prozess (1/2)
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
 Vilsmeier
CMII – Prozess (2/2)
Der CMII-Prozess besteht aus den folgenden Teilprozessen:




Definitions- und Strukturierungsprozess
Anforderungs-Freigabeprozess
Anforderungs-Änderungsprozess
Erzeugnis-Änderungs- und Freigabeprozess
Links:
Institute of Configuration Management: www.icmhq.com/
Gesellschaft für Konfigurationsmanagement: www.gfkm.de
Seite 112 von 388
 Vilsmeier
Die Rolle von Configuration Management
innerhalb von PLM
Configuration
management
configuration, recording,
identification, controlling
Seite 113 von 388
Management of
data flow
workflow &
process
management
project
management
Management of data structure
Document - &
file management
parts information &
product structure
management
classification
 Vilsmeier
Configuration Management (CM)
Definition und Ziel
 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)
Seite 114 von 388
 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
 Vilsmeier
Configuration Management (CM)
Aktivitäten innerhalb des CM
Organisation und –planung des Konfigurationsmanagements (KMO)
Seite 115 von 388
Configuration
Configuration
Control/Change
Identification
Management
Configuration
Audit
Configuration
Management
Activities
Configuration
Status
Accounting
 Vilsmeier
Organisation und –planung des Configuration
Management (CMO)
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
 Vilsmeier
Configuration Management (CM) Aktivitäten
Begriffserklärungen (Teil 1)
 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)
Seite 117 von 388
 CI schließt folgenden Aufgaben ein: Produktstruktur und
Auswahl von Konfigurationseinheiten, Dokumentation der
Konfigurationseinheiten, Benummerung, Einrichten von
Bezugskonfigurationen.
 Vilsmeier
Configuration Management (CM) Aktivitäten
 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);
Seite 118 von 388
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
 Vilsmeier
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)
Seite 119 von 388
 Ä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
 Vilsmeier
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)
Seite 120 von 388
 Eine genaue Bezeichnung von Produktart und
Anspruchsklasse
 Prüfungsanweisungen und anzuwendende
Spezifikationen müssen enthalten sein
 Normen bezüglich des Qualitätssystems
 Vilsmeier
Anforderungen an Change Management
relevant_for_interface
Change_Request
(RFA)
affected_documents
affected_items
Manufacturing
interface
Technical
interface
concerned_organization
Seite 121 von 388
companion
Change_Request
(RFA)
derived change requests
EF Partner Company
 Vilsmeier
Change Management
Änderungslogik
Bisher: Stücklisten und Zeichnungen
Änderungsantrag
Änderungsantrag
Antrag
prüfen
Ablehnungsbegründung
Änderung
durchführen ?
nein
ja
Seite 122 von 388
Heute: nach PLM Einführung
Antrag
prüfen
Änderung
durchführen ?
Ablehnungsbegründung
nein
ja
Änderungsauftrag
Änderungsauftrag
Zeichnungen
Stücklisten
ändern
Änderungsdienst:
verteilen von geänderten
Zeichnungen + Stücklisten
Produktstruktur &
Information-Pack
ändern
Nach Freigabe sind
Änderungen in PLM
verfügbar
 Vilsmeier
Change Management
Der reale, alte Prozess zwischen Partnerfirmen
Seite 123 von 388
 Vilsmeier
Change Management - Eine Herausforderung
Overall change process
Inter-company change
procedure
company 1
company 2
company 3
Intra-company change management
Seite 124 von 388
 Vilsmeier
Links von Part/Assembly-Objects (Items) zu
Work Orders (Authorities)
Seite 125 von 388
PPof
Is Planned by
Work Order
RPof
Is Result by
Work Order
APof
Is Affected by
Work Order
 Vilsmeier
Links von Work Order (Authority) zu Positionen
Seite 126 von 388
has PP
Work Order has
Planned Position
has AP
Work Order has
Affected Position
Work Order has
Resulting Position
has RP
 Vilsmeier
Beispiel für eine Work Order (1)
Antragsgültigkeit
Seite 127 von 388
 Vilsmeier
Beispiel für eine Work Order (2)
Seite 128 von 388
 Vilsmeier
Gültigkeit
 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
 Vilsmeier
Gültigkeiten im Eurofighter Projekt
 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
 Vilsmeier
Bezeichnung von Gültigkeiten
(Effectivity Designations)
Seite 131 von 388
Kennung
Bedeutung
A
B
G
I
S
Österreich (Austria)
Grossbritannien (UK)
Deutschland
Italien
Spanien
P
T
S
IPA (Instrumented Production A/C)
Twin Seater
Single Seater
Beispiel: GT1-50 German Twin Seater, Flugzeug 1 bis 50
 Vilsmeier
Änderungsprozess Konstruktion
Kundenforderung durch
“Change Request/
Change Proposal”
Kunde
Strukturgültigkeit
(manuell vom
Konstrukteur)
Beschreibt
geforderten
Änderungsumfang
Antragsgültigkeit
CR/CP
Strukturgültigkeit
Konstruktion
Abgleich zwischen
Soll - Ist-Gültigkeit
Automatische Berechnung aufgrund der
festgelegten
Strukturgültigkeit
Abgleich
Bestätigung
Automatische
Berechnung
Änderungsgültigkeit
beschreibt tatsächliche
Änderungen zwischen
“davor” und “danach”
Seite 132 von 388
Revisionsgültigkeit
Ist-Zustand
Summe der Verwendungen
 Vilsmeier
Änderungsprozess Konstruktionsanlagen
Begriffserklärung (Teil 1)
 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.
Antragsgültigkeit:
- Änderung in PLM nicht möglich
- Keine Auswertung
Änderungsantrag
Anlage einer RFA/WO
und Übertrag nach PLM
Kunde
Change Request
Change Proposal
CR/CP Tool
Seite 133 von 388
CR
CP
RFA
Änderungen:
• Add items
• Remove items
• Effectivty Change
• Items revise
• QTY Change
PLM
 Vilsmeier
 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.
Work Order
beschreibt
Antragsgültigkeit
Betroffene Teile
Strukturgültigkeit
(manuell)
Seite 134 von 388
 Vilsmeier
 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.
Work Order
beschreibt
Antragsgültigkeit
Betroffene Teile
Strukturgültigkeit
(manuell)
Calculated Effectivity
Seite 135 von 388
 Vilsmeier
 Änderungsgültigkeit
Seite 136 von 388
 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
 Vilsmeier
Gültigkeiten für lagerfähige Baugruppen
Seite 137 von 388
Unterhalb einer lagerfähigen Baugruppe gibt
es keine Gültigkeitssplits
Die calculated (Revision)
Gültigkeit wird von den
übergeordneten Baugruppen vererbt
 Vilsmeier
Gültigkeiten für konfigurierbare Baugruppen
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
 Vilsmeier
Gültigkeitbereiche für CAD Modelle
Seite 139 von 388
 Vilsmeier
Ausschnitt Datenmodell Gültigkeiten
Seite 140 von 388
 Vilsmeier
Freigabe Authority
Daten Model (Teil 1)
signature
organization
STRING
STRING
is signature
for
is
based on
signed on
behalf of
type
name
was
designed on
date
INTEGER
INTEGER
INTEGER
authority
issue
STRING
STRING
STRING
STRING
REAL
decision code
STRING
day
month
year
based
on
item
issue
Seite 141 von 388
technical class
issue
contractual class
mass difference
is
approval of
decision
document
issue
item
issue 80x
title
approval
assignment
select
approved by
approval
of
approval
approval status
organization
STRING
 Vilsmeier
Freigabe Authority
Daten Model (Teil 2)
affects
partner
interface
STRING
has
design
responsible
interface
type
is for an
(INV) has issues
initiated
by
text
text type
design engineering
complete indicator
change type
change number
closed indicator
basic change indicator
STRING
STRING
STRING
BOOLEAN
STRING
kind of
remark
is for an
(INV) has issues
has a design
target
description
Seite 142 von 388
STRING
is
originated by
authority
STRING
STRING
STRING
site code
organization
authority
issue
approved by
approval status
organization
STRING
 Vilsmeier
Neues Konzept für Configuration und Change
Management für kleinere Projekte
 PIPE
Project for the
Improvement of EF
Processes & toolEnvironments for future programs
 FOCS – Function Oriented Configuration System
Seite 143 von 388
 Vilsmeier
Probleme der Eurofighter CCM Methodik
 Inflexibles Management der Gültigkeiten durch
hartkodierte Zuordnung der Gültigkeiten der Kunden
Seite 144 von 388
 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.
 Vilsmeier
Anforderungen an eine neue CCM Methodik
 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
 Vilsmeier
Implementierte Maßnahmen
 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
 Vilsmeier
Wesentliche Elemente des FOCS Konzepts
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
 Vilsmeier
FOCS Übersicht
WS0001
• Sichert Konsistenz von PACOs
• Erstellung von Baselines
• Unter RFA Kontrolle
Seite 148 von 388
• 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
Kunden
zuordnen
Product Allocation & Configuration Objects
Change
Authorities
Konfiguration
zuweisen
PLAN
Functional Product
Configurations
 Vilsmeier
FOCS Relationen
Function
Oriented
Configuration
Contains FPC
n:m
Has PACO
FPC
RE,Basic,1,A
Official = FALSE
Has Informal
Doc
Document
FPC
Has Release
Relevant Doc
Document
Has Release
Relevant Doc
Document
FPC
Seite 149 von 388
PACO
PACO-ID = PAC00000081
Rev = A
Block = 5B
MSN = 0003
EndItem ID Industry = GS0003
ToBeBuilt = FALSE
Type = End Item
Active = FALSE
Contains
PACO
n:1
Product-Plan
Level = H6
From = 1.1.
To = 30.7.
Has … Doc
Doc.
Has
Resulting
Items
RFA
2610001D1
Status = A
Has Informal
Doc
Document
Defines FPC
n:m
RFA
2610001D1
Status = 02
 Vilsmeier
FOCS – Configuration Items (CI) und Design
Solutions (DS)
PACO
PACO-ID = PAC00000081
Rev = A
Block = 5B
MSN = 0003
EndItem ID Industry = GS0003
ToBeBuilt = FALSE
Type = End Item
Active = FALSE
<TLFT>
Uses n : m
W532..1-800,A
CI
Uses
1
:
n
---
FPC
RE,Basic,1,A
W532..1-801,A
DS
FPC
W532..1-401,A
Part
Seite 150 von 388
FPC
Has Resulting Items
n:m
RFA
2610001D1
Status = 02
DC = Y
 Vilsmeier
 Produktstruktur – Was ist das?
Produktstrukturen
Einführung - Grundlegendes
Seite 151 von 388
 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
 Vilsmeier
 Ordungskriterien für Produktstrukturen
 View: Sicht auf ein Produkt abhängig vom Lebenszyklus - mögliche Strukturierung,
Produktstrukturen
Einführung – Sichten
Seite 152 von 388
 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
 Vilsmeier
Produktstrukturen
Einführung - Aspekte
Seite 153 von 388
 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
 Vilsmeier
Einführung - Klassifizierung
Produktstrukturen
 Elemente zur Gestaltung von Produktstrukturen
Seite 154 von 388
 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
 Vilsmeier
Produktstrukturen
Einführung - Relationen
Seite 155 von 388
 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
 Vilsmeier
Produktstrukturen
Schematische Darstellung des PS Aufbaus
Seite 156 von 388
 Vilsmeier
Item 1
Produktstrukturen
Grundelemente
Is release
relevant for
uses items
Relations
Seite 157 von 388
Attribute 1
Attribute 2
e.g.
name
Status
Doc 2
(Word)
Doc 1
(Word)
is used by
assembly
Item 2
is described by
describing
documents
Doc 2
(CAD)
 Vilsmeier
Produktstrukturen
Definition von Symbolen
Seite 158 von 388
 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
 Vilsmeier
Product Class
identifies Products like
Twin Seater, Single Seater
Produktstrukturen
Überblick
Seite 159 von 388
Effectivity
Aspect Level
„organises“ the
product according to the needs
of different
disciplines
Detail Level
Storable Items,
EPC designed,
EPC made,
or bought
 Vilsmeier
Functional Structure
System Definition Structure
Spec
Produktstrukturen
Von der funktionalen zur System Definition
Struktur
has sub functions
has sub system
Requirement
Requirement
Requirement
Requirement
Requirement
Main Hydraulic
System (291)
Requirement
Landing
Seite 160 von 388
is realised by
system
Requirement
Landing Gear
System (528)
 Vilsmeier
Von der system definition zur physical, as
designed Struktur
Product
Support
as designed
physical
System useage
has sub system
has usage
implements
Produktstrukturen
System definition
!
FCC
System
Engineering
Seite 161 von 388
uses part
FCC 1
SBC 1
FCC 2
SBC 2
Design
 Vilsmeier
as designed
physical (all A/C)
BT0001
as built
per A/C
uses part
Is part of A/C
Serial No.
Produktstrukturen
Von as designed zu as built
BT, GT
Is embodied in A/C
GT
BT
ASO1
GT
ASO3
ASO2
As planned
BT, GT
Seite 162 von 388
 Vilsmeier
Produktstruktur Elektrik
Electric System
FLIR Electric sub-system
Has effectivity list
Produktstrukturen
Is sub-system of
IT/ST
BT/GT
SDR
Effectivity List
Seite 163 von 388
EDR
Alenia
EDR
BAES
Circuit Diagramm
EDR
EADS C
EDR
EADS M
Wiring Diagramm
 Vilsmeier
functions
Technical
Publication
Spec
is realised by / is realisation of
system definition
has useage/ is useage of
Requirement
Produktstrukturen
Produktstrukturen im Zusammenhang
CAD
Model
system useage
implements / is implementation of
as designed
TP
DDP
Spec
is embodied / is emodiment of
as built
SBC
is delivered as / is maintained like
Visualiser
Seite 164 von 388
Serial No.
Actual A/C
configuration
as maintained
 Vilsmeier
Produktstrukturen
Produktstruktur
Views einer PS - schematisch
„As
designed“
„As
Planned“
„Delivered“
„As
„As
Built“
maintained“
Wartungsspezifischer
Aufbruch
W
Fertigungsspezifische Baugruppe
Seite 165 von 388
Waiver/Deviation
 Vilsmeier
Produktstrukturen
Definition Produktklasse
 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
 Vilsmeier
Change Management mit Gültigkeitssplitt in der
physikalischen Produktstruktur
Produktstrukturen
RFA 1: Change Eff. 1-50
RFA 2: Change Eff. 30-50
Str. Eff. 1-50
Str. Eff. 30-50
Str. Eff. 1-50
Str. Eff. 1-29
-401
-001
Seite 167 von 388
-403
-003
 Vilsmeier
Produktstrukturen
Product Classes Eurofighter
Seite 168 von 388
 Vilsmeier
Produktstrukturen
Physical as designed Twin Seater + PWI
Seite 169 von 388
 Vilsmeier
Produktstrukturen
General Arrangement (GA) Struktur TS
Seite 170 von 388
 Vilsmeier
Produktstrukturen
GA of Equipment
Seite 171 von 388
 Vilsmeier
Produktstrukturen
Beispiel konfigurierbare Baugruppe
Seite 172 von 388
 Vilsmeier
Produktstrukturen
Beispiel lagerfähige Baugruppe
Seite 173 von 388
 Vilsmeier
Produktstrukturen
Installation NLG mit IP Foldern und CAD Modellen
Seite 174 von 388
 Vilsmeier
Produktstrukturen
GA of Electric TS CF
Seite 175 von 388
 Vilsmeier
Produktstrukturen
LOOM GA mit Gültigkeitssplitt
Seite 176 von 388
 Vilsmeier
Produktstrukturen
Get Item Info – Einzelteil_1
Seite 177 von 388
 Vilsmeier
Produktstrukturen
Get Item Info – Einzelteil_2
Seite 178 von 388
 Vilsmeier
alternate
relationship
part number
is base of
title
security classification
part type
item
is alternate of
uses
is component of
has component
position
assembly relationship
with detail level
measure unit
remark
make from
relationship
Seite 179 von 388
item
issue
transformation
matrix
quantity
references finish material spec
authority
issue
authorized by
is assy of
REAL
STRING
STRING
measure unit
produced quality
issue
remarks
weight unit
calculated weight
safety classification
maturity stage
item
definition
produces
document
has production
site
organisation
defines
substitute of
base of
substitute
relationship
STRING
STRING
STRING
STRING
References protective treatment
is for an
(INV) has issues
Produktstrukturen
Partielles Datenmodell_1
References specification
STRING
STRING
STRING
REAL
STRING
STRING
document
is relevant for
STRING
REAL
item
view
view name
STRING
 Vilsmeier
within aspect level
STRING
remark
is component of
part number
item
80x
is for an
(INV) has issues
title
part type
STRING
STRING
STRING
STRING
references protective treatment
document
Produktstrukturen
Partielles Datenmodell_2
Authority
issue
authorized by
item
issue 80x
transformation
matrix
issue
remarks
is assy of
has component
position
with detail level
substitute
relationship
aspect to
detail level
Seite 180 von 388
base of
substitute of
has production
site
maturity stage
identifiable part
indicator
quantity
measure unit
remark
organisation
STRING
STRING
STRING
STRING
REAL
STRING
STRING
is component of
item
 Vilsmeier
EADS Military Aircraft
Eurofighter
Produktstrukturen
Produktstruktur - Viele Projekte
Seite 181 von 388
MIG 29
Mako
Tornado
 Vilsmeier
Produktstrukturen
Namenskonventionen
 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
 Vilsmeier
Produktstrukturen
Detail Level_1
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:
Seite 183 von 388
 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
 Vilsmeier
 Teileklassen im Detail Level:
Produktstrukturen
Detail Level_2
Seite 184 von 388
 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)
 Vilsmeier
Detail Level_3 Spezialitäten
 Faserverbundbauteile
Produktstrukturen
 Spezielle Teileklassen im Detail Level:
Seite 185 von 388
 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)
 Vilsmeier
Produktstrukturen
Konfigurierbare Baugruppen
 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
 Vilsmeier
Produktstrukturen
Re-Identifizierung und Revisionierung
Bauteilklasse
Re-Identifizierung
Revisionierung
Konfigurierbare
Baugruppe
Nur bei massiven
Änderungen, entscheidet Konstrukteur
Wenn sich die
Zusammensetzung der
Baugruppe ändert
Lagerfähige
Baugruppe
Bei Änderung von
FF&F
Änderung, FF&F
nicht betroffen
„Zeichnungs-“
Einzelteil
Bei Änderung von
FF&F
Ä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
 Vilsmeier
Produktstrukturen
Faserverbundbauteil
Is Part/Rough Part for
Seite 188 von 388
 Vilsmeier
Produktstrukturen
Geschweißtes Teil
Seite 189 von 388
 Vilsmeier
Produktstrukturen
Schmiedeteil
Zeichnung Spant
fertig bearbeitet
Zeichnung Schmiedeteil
Seite 190 von 388
 Vilsmeier
Produktstrukturen
Item Instance
 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
 Vilsmeier
J12355555-401
Produktstrukturen
Use Cases Item Instance
Mehrfache Verwendung in Baugruppen
BoM QTY=1
J12312345-001_001
Position
J12398765-801
BoM QTY=1
J12312345-001_002
BoM QTY=1
J12312345-001_003
Position
Position
BoM QTY=0
Position entspricht
Transformationsmatrix
Seite 192 von 388
J12312345-001
SOL
 Vilsmeier
J12355555-801
Produktstrukturen
Verschiedene Gültigkeit - andere Position
BoM QTY=1
BoM QTY=1
J12312345-001_001
Structure Effectivity
SOL
J12312345-001_002
SOL
Position
Position
BoM QTY=0
Use Case auch für
flexible Bauteile
Seite 193 von 388
J12312345-001
 Vilsmeier
J12355555-401
Produktstrukturen
Verschiedene Elektrische Identifier
BoM QTY=1
BoM QTY=1
8ES003417-00 _001
8ES003417-00 _002
2LH
5LH
Position
Position
8ES003417-00
Seite 194 von 388
Electrical
Ident.
BoM QTY=0
SOL
 Vilsmeier
Austauschbarkeit verwendungsabhängig
BoM QTY=1
BoM QTY=1
Produktstrukturen
J12355555-401
8ES003417-00 _001
8ES003417-00 _002
2LH
5LH
Position
Position
BoM QTY=0
SOL
8ES003417-00
8ES004711-00
Substitute for this instance
SOL
8ES004712-00
SOL
alternative
Seite 195 von 388
 Vilsmeier
BT0001
Produktstrukturen
Serialnummern in einer as Built Struktur
Not embodied
J12355555-401
J12312345-001_001
Serial No. 123
embodied
J12312345-001_002
J12312345-001_003
Serial No. 456
J12312345-001
Seite 196 von 388
J12398765-801
Serial No. 789
SOL
 Vilsmeier
uses item instance
is item instance of
J12355555-401
J12398765-801
Position
Produktstrukturen
Mögliche Implementierung von Item Instance
Position
J12312345-001_002
J12312345-001_001
Uses
QTY=2
Position entspricht
Transformationsmatrix
Seite 197 von 388
Uses
QTY=1
J12312345-001
SOL
Position
SOL
J12312345-001_003
SOL
SOL
 Vilsmeier
-80x
Produktstrukturen
Management von STD Teilen, Equipments
-40x
-00x
ASM
SOL
-xxx
Die Geometrie aller Standard
Teile, Equipments wird in einem CATIA assembly Modell
(ASM) zusammengefasst
Von EPC definierte details, assys, Jxxxxx,
Standard parts, Equipments, CATIA dittos
SOL
Seite 198 von 388
ASM
CATIA Model, welches ein CATIA model file darstellt
 Vilsmeier
Produktstrukturen
Management von STD Teilen, Equipments in
sehr großer Anzahl
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 1:4
ASM 2:4
ASM 3:4
-80x
?
?
ASM 4:4
?
?
-40x
Seite 199 von 388
-00x
 Vilsmeier
-40x
-00x
ASM
SOL
Gültigkeitssteuerung
Collection Assembly Items
-80x
Produktstrukturen
Collection Assembly Items
-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
 Vilsmeier
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
Verwendung von CAI in System- und Zonen
Aspekt
System 1
System 2
Zone 1
Zone 2
-802
-801
-40x
ASM
Seite 201 von 388
-40x
-00x
ASM
SOL
-00x
SOL
-S01
ASM
-S02
ASM
-S01 ASM
-S02 ASM
 Vilsmeier
Taxying
Spec
Produktstrukturen
Beispiel für funktionalen Aufbruch
* Maximum time before take off
has sub functions
m.t.b.t.o.*
Take Off
Landing
ABS
Seite 202 von 388
Requirement
30 min, 50°C, 95% rel. L.F.
Requirement
400 m
Requirement
16 to
Requirement
350 km/h
Requirement
500 m ABS, 250 m Bremsfallschirm
Requirement
10 to
Requirement
260 km/h
Requirement
Bremsleistung 100 kW
 Vilsmeier
System Definition Structure
Spec
Produktstrukturen
Umsetzung von Funktionen in Systemen
Seite 203 von 388
has sub functions
Take Off
EJ 200Engine
System (71)
m.t.b.t.o.*
Fuel/Oil Cooling
System (287)
ABS
Main Hydraulic
System (291)
Landing
Landing Gear
System (528)
 Vilsmeier
Produktstrukturen
Beispiel Systemstruktur bottom up
Seite 204 von 388
 Vilsmeier
Produktstrukturen
Beispiel Systemstruktur top down
Seite 205 von 388
Single Seater und
Twin Seater in einer
Produkstruktur
 Vilsmeier
1.1. Spezifikation in
PLM anlegen
1.2.
System
anlegen
Has system usage
Is release relevant for
Produktstrukturen
Prozess für Systemstruktur
1.3. Spec zu
System zuordnen
(formale PartDoc
Rel)
Is subsystem of
1.5. LRUs zu
System zuordnen
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
 Vilsmeier
Elektrische Diagramme in der SD Struktur
Electric System
has useage
FLIR Electric sub-system
Has effectivity list
Produktstrukturen
Is sub-system of
IT/ST
BT/GT
SDR
Effectivity List
Seite 207 von 388
implements
EDR
Alenia
EDR
BAES
Circuit Diagramm
EDR
EADS C
EDR
EADS M
Wiring Diagramm
 Vilsmeier
Produktstrukturen
Ausschnitt System 91 Elektrik Diagramms
Seite 208 von 388
 Vilsmeier
DCN: Document change notice
ICR: Item Cange Record
DIA: LCABLE Diagramm
Produktstrukturen
Elektrik Subsystem FLIR Diagramme
Seite 209 von 388
 Vilsmeier
Produktstrukturen
Elektrik Diagramme und Gültigkeit
Seite 210 von 388
 Vilsmeier
Produktstrukturen
Auch diese Lösungen funktionieren (manchmal)
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.
Seite 211 von 388
Verlegung des Kabelbündels !
Durch die sehr transparente Kabelführung gewinnt man schnell einen
Eindruck über die Struktur des
Netzes.
 Vilsmeier
Verlegung des Kabelbündels !
So schaut es dann wirklich aus.
Produktstrukturen
Überblick Kabelbündel im Eurofighter
Seite 212 von 388
 Vilsmeier
PLM ist maßgeblich
für Konfiguration
(Gültigkeiten) und
Änderungskontrolle
Produktstrukturen
Übersicht Elektrikprozess
LCable (ECAD)
2D functional wiring diagram
PLM-EIS
Stammdatengenerierung / Verwaltung
PLM
Seite 213 von 388
 Vilsmeier
PS Elemente für Rumpfmittelteil (RM)
5 Länder
9 Versionen
(SS / TS)
Produktstrukturen
Elektrik Prozess
PLM - PLM-EIS - Rumpfmittelteil
z.Zt. gültige
Konfigurationen
Serie 1200
FTI
350
Systeme pro
RM
Serie 82
FTI 29
z.Zt. gültige
Kabelb.
Serie 470
FTI
560
Retro 95
erzeugte
Diagramme
Serie 450
FTI 210
Retro 55
Kabelbündel pro RM
Serie 130
Seite 214 von 388
erzeugte Kabelbündel
Serie >2000
FTI >2000
vorhandene
Gültigkeiten
Serie 4400
FTI 1200
 Vilsmeier
Produktstrukturen
SD und SU Fuel System (Ausschnitt)
Seite 215 von 388
 Vilsmeier
SBC: System
Breakdown Code
PLM interner
Eindeutiger
Schluessel, automatisch von Sysem
erzeugt
Produktstrukturen
Get item Info System Useage
Spezifikation und
Elektrischer Ident.
Zuordnung
von Zone(n)
Seite 216 von 388
Zuordnung zu
Klappe/Deckel
 Vilsmeier
Produktstrukturen
SU Relation zu as designed und Calc. Effectivity
Seite 217 von 388
 Vilsmeier
Produktstrukturen
SU Relation zu as designed und Calc. Effectivity
Seite 218 von 388
 Vilsmeier
as designed => as planned => as built
BT0001
as built
per A/C
uses part
Is part of A/C
Produktstrukturen
as designed
physical (all A/C)
BT, GT
Is embodied in A/C
GT
BT
ASO: Assembly
Stage Operation
ASO1
GT
ASO3
ASO2
As planned
BT, GT
Seite 219 von 388
 Vilsmeier
Produktstrukturen
Abwägung as designed <=> as planned
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
Seite 220 von 388
 Vorteil: Klare Strukturen für Konstruktion u. Fertigung
 Nachteil: Zwei Strukturen müssen konsistent gehalten
werden
 Vilsmeier
Änderungsauftrag:
1-401 re-identifizieren
2-001 re-identifizieren
Produktstrukturen
Problematik As designed <=> As planned
Ausgangszustand:
• Beide Strukturen sind freigegeben
• 3-801 ist bereits für GT1 gefertigt
• 4-801 ist im Zusammenbau für GT1
1-801 GT1+
5-801 GT1+
4-801 GT1+
3-801 GT1+
1-401
2-401
1-001
2-001
As Designed
Seite 221 von 388
1-401
1-001
2-401
2-001
As planned
 Vilsmeier
Produktstrukturen
Problematik As designed <=> As planned
As designed: Re-identifizierung durchgeführt
As Planned:
• 3-801 kann nicht re-identifiziert werden, da bereits gefertigt
• Gültigkeitssplitt in as planned
• Später muss für GT1 Teil 1-401 gegen
5-801 GT1+
1-403 ausgetauscht werden (Retrofit)
1-803 GT1+
3-801 GT1
1-403
2-401
4-801 GT1+
1-001
2-003
As Designed
Seite 222 von 388
3-803 GT2+
1-401 1-001
1-403 1-001
2-401 2-003
As planned
 Vilsmeier
Baseline Konzept als Basis für „As Built“
Produktstrukturen
workshare
Seite 223 von 388
A/C BAe
Final Assy
C/F
MAN
single
parts
single
parts
single
parts
embodiment
in -8xx
C/F
AUG
S/A
BAe
ToConfirm
(Structured Baseline)
embodiment
in -8xx
embodiment
in -8xx
single
parts
Section3
BRE
 Vilsmeier
Produktionskreislauf
SOLL
DBS
Design Build
Produktstrukturen
IST
Standard
Endprodukt
Produktstruktur
MCA
GT 0001
MAN
EinbauBrutto-/Nettobedarf
auftrag
W/D
Tt
t
Teile / Baugruppen
Seite 224 von 388
MCA
AUG
Bestellabruf
Manufacturing
Change
Authority
 Vilsmeier
Methode für Einbaubestätigung „As built“
„SBSE“ PS
to confirm
RFA
Jxxy-801
MAN
resulting
Jxyx-801
AUG
Jyyx-001
BAES
Seite 225 von 388
„as Built“ PS
SBSE1
SBSE1
GT1
GT1
A/C
MAN A/C
Jxxx-801
MAN
Produktstrukturen
„as designed“ PS
to confirm
Jxxy-801
AUG
Jxyy-001
AUG
Jxxx-801
MAN
as confirmed
SBSE1
GT1
F/F
SBSE1
GT1
R/F
as confirmed
SBSE1
GT1
MAN C/F
SBSE1
GT1
BAES
SBSE1
GT1
AUG
Jxxx-801
MAN
Jxxx-801
MAN
SBSE1
GT1
BRE
Jxxx-801
MAN
SBSE: Structured Baseline,
Single Effectivity
A/C: Aircraft complete
F/F: Front Fuselage
C/F: Center Fuselage
R/F: Rear Fuselage
 Vilsmeier
Produktstrukturen
Beispiel SBSE
SBSE: Structured Baseline Single Effectivity
Seite 226 von 388
 Vilsmeier
Produktstrukturen
As built
to confirm - as confirmed
Seite 227 von 388
 Vilsmeier
Produktstrukturen
Beispiel „As Built“ PS
Seite 228 von 388
End
Item
 Vilsmeier
Produktstrukturen
As Built PS: Relation „Is used by as built“
Seite 229 von 388
 Vilsmeier
Abfrage nach as
built informationen
true oder false
Produktstrukturen
As built
Beispiel für Serialnummer und Bauabweichung
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
 Vilsmeier
Prod. Structure Data-Exchange
W/D Data-Exchange
W/D
Separate Object/
Icon in PLM
Produktstrukturen
Übersicht Datenmodell Waiver/Deviation
CATIA
3-D Modell
CATIA Data-Exchange
Seite 231 von 388
WD Attachment
WD Attachment
WD Attachment
File Name 1
doc / txt
.....
File Name 2
jpg
.....
File Name 3
cgm
.....
pdf
tif
Preparation of the attachments outside PLM
 Vilsmeier
Produktstrukturen
Relationen zwischen verschiedenen
Produktstrukturen
Seite 232 von 388
 Vilsmeier
Produktstrukturen
Produkt Struktur Relationen – Auswahl von zwei
von vier Menüpunkten
Seite 233 von 388
 Vilsmeier
Produktstrukturen
System Useage für Fuel Gauging ....
Seite 234 von 388
 Vilsmeier
Produktstrukturen
Relationen zwischen SU und Physical Items
Seite 235 von 388
 Vilsmeier
Produktstrukturen
Management von Software Items und
dazugehöriger Hardware
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
 Vilsmeier
Produktstrukturen
Konfigurierbare Baugruppe für SW items
Seite 237 von 388
 Vilsmeier
Produktstrukturen
Software Items mit Hardware Items per „Runs on
Hardware“ verknüpft
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.
 Vilsmeier
Produktstrukturen
Baseline container für alle HW items mit resident
and non-resident SW
Seite 239 von 388
 Vilsmeier
Produktstrukturen
Hardware Items mit Software Items per „Has
downloadable software“ verknüpft
Seite 240 von 388
 Vilsmeier
Produktstrukturen
Nachweisführung mit „Has Release Relevant Doc“
zu Items Dokumenten
Seite 241 von 388
 Vilsmeier
Produktstrukturen
Dokumentenstruktur mit „Has Release Relevant
Doc“ zur Nachweisführung
Seite 242 von 388
 Vilsmeier
Produktstrukturen
Weapon System Qualifikationsdokument –
Declaration of Design and Performance
Gesamtdokument aus
Verschiedenen PDF
Files zusammengestellt.
Seite 243 von 388
 Vilsmeier
Retrofit: Umrüstung eines Luftfahrzeuges nach
Auslieferung an den Kunden (Upgrade)
 Kunde wünscht bessere Funktionalität (Upgrade)
 Spezifikation wurde nicht eingehalten, daher muss der
Hersteller „Nachbesserungen“ vornehmen.
Produktstrukturen
 Welche Gründe gibt es für Retrofit:
 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
Seite 244 von 388
 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
 Vilsmeier
Line Design
GT1+,BT1+
J5321xx-801,D
Line Design
Produktstrukturen
Retro für Inline: Ausgangs-Situation - Line-Design und
Retro-Installation
J5322xx-801,C
Gültigkeiten
01: GT 1-4
02: GT 5+
03: BT 1+
01
01,02
03
J532..2-401
J532..3-001
J532..4-001
01,02
Seite 245 von 388
J532..1-401
J532..5-001
Retro Installation
J0082xx-801,A
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
 Vilsmeier
Retro für Inline: Schritt 1 - Re-Identifizierung der
betroffenen Baugruppe
Line Design
GT1+,BT1+
Retro Installation
Is Base for
J0082xx-801,A
Retro Design
Line Design
J5322xx-801,C
Produktstrukturen
J5321xx-801,D
Gültigkeiten
01: GT 1-4
02: GT 5+
03: BT 1+
Seite 246 von 388
01
01,02
03
Is Re-Identified by
J532..1-401
J532..2-401
J532..3-001
J532..4-001
01,02
J532..5-001
Is Result of
J5322xx-851,A
Gültigkeiten
01: GT 1-4
02: GT 5+
03: BT 1+
01
J532..1-401
Neue StrukturRelationen:
• Is Base for – VerJ532..2-401 knüpfung zwischen
Ausgangszustand
und Reto Installation
03
J532..3-001
• Is Result of: Verknüpfung zwischen
J532..4-001 Zustand nach Durchführung der Retofitmaßnahme und
01,02
J532..5-001 Retro Installation
01,02
 Vilsmeier
Retro für Inline: Schritt 2 - Einschränken der
Strukturgültigkeiten der Retro-BG
Line Design
GT1+,BT1+
Retro Installation
Is Base for
J0082xx-801,A
Line Design
J5322xx-801,C
Produktstrukturen
J5321xx-801,D
Gültigkeiten
01: GT 1-4
02: GT 5+
03: BT 1+
Retro Design
Is Re-Identified by
Is Result of
J5322xx-851,A
Gültigkeiten
01: GT 1-4
01
J532..1-401
J532..2-401
03
01
01
J532..4-001
01
J532..5-001
Line Design: Gültigkeit meistens 1+
Seite 247 von 388
J532..2-401
J532..3-001
J532..4-001
01,02
J532..1-401
J532..5-001
Retro Design: Gültigkeit immer eingeschränkt
 Vilsmeier
Line Design
GT1+,BT1+
GT1-4
Retro Installation
J5321xx-801,D
Line Design
Produktstrukturen
Retro für Inline: Schritt 3 - Einhängen der Retro-BG in
die übergeordnete BG mit Retro-Gültigkeit
J5322xx-801,C
Gültigkeiten
01: GT 1-4
02: GT 5+
03: BT 1+
Retro Design
Is Re-Identified by
J0082xx-801,A
Is Result of
J5322xx-851,A
Gültigkeiten
01: GT 1-4
01
01,02
03
J532..1-401
J532..2-401
01
01
J532..1-401
J532..2-401
J532..3-001
J532..4-001
01,02
Seite 248 von 388
Is Base for
J532..5-001
J532..4-001
01
J532..5-001
 Vilsmeier
Retro für Inline: Schritt 5 - Bearbeiten der Retro-BG Darstellung des 100% Zustandes nach Änderung
J5321xx-801,D
Line Design
Produktstrukturen
Line Design
GT1+,BT1+
J5322xx-801,C
Gültigkeiten
01: GT 1-4
02: GT 5+
03: BT 1+
GT1-4
Is Base for
Retro Design
Is Re-Identified by
J0082xx-801,A
Is Result of
J5322xx-851,A
Gültigkeiten
01: GT 1-4
01
01
J532..1-401
J532..1-401
Position gelöscht
01,02
03
J532..2-401
J532..3-001
J008..8-001
Position hinzugefügt
J532..4-001
01,02
J532..4-001
01
J532..5-001
Is Reworked by
Seite 249 von 388
Retro Installation
J008..5-001
Position umgearbeitet
 Vilsmeier
Retro für Inline: Schritt 6 - Delta-Berechnung InlineBG zu Retro-BG
Line Design
GT1+,BT1+
Line Design
J5322xx-801,C
Produktstrukturen
J5321xx-801,D
Gültigkeiten
01: GT 1-4
02: GT 5+
03: BT 1+
GT1-4
Retro Design
Is Re-Identified by
J0082xx-801,A
Is Result of
J5322xx-851,A
Gültigkeiten
01: GT 1-4
01
01,02
03
02
J532..1-401
01
J532..1-401
J532..2-401
J532..3-001
J008..8-001
J532..4-001
J532..4-001
J532..5-001
01
Is Reworked by
Seite 250 von 388
Retro Installation
Is Base for
J008..5-001
Added J008..8-001
Added J008..5-001
Removed J532..2-401
Removed J532..5-401
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.
 Vilsmeier
Retro für Inline: Schritt 7 - Übertragen des
berechneten Deltas in die Retro Installation
Line Design
GT1+,BT1+
Line Design
J5322xx-801,C
Produktstrukturen
J5321xx-801,D
Gültigkeiten
01: GT 1-4
02: GT 5+
03: BT 1+
Retro Installation
GT1-4
Is Base for
Retro Design
Is Re-Identified by
J0082xx-801,A
Is Result of
J5322xx-851,A
Gültigkeiten
01: GT 1-4
01
01,02
03
01
J532..1-401
J532..1-401
Removes Part
J532..2-401
J532..3-001
J008..8-001
Adds Part
J532..4-001
J532..4-001
02
01
J532..5-001
Is Reworked by
J008..5-001
Reworks Part
Neue Relationen: adds, removes und reworks part
Seite 251 von 388
 Vilsmeier
Der Add/Remove Block wir automatisch aus
den hinterlegten Strukturinformation generiert,
ist nur richtig, wenn Produktstruktur korrekt.
Retro Installation
J0082xx-801,A
Produktstrukturen
Retro für Inline: Schritt 8 - Generieren des
Add/Remove-Blocks
Seite 252 von 388
 Vilsmeier
 Erste Retromaßnahme ist definiert, welche Möglichkeiten
gibt es für nachfolgende Retromaßnahmen?
Produktstrukturen
Retro nach Retro Prozess in PLM
 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
 Vilsmeier
Retro für Retro: Ausgangs-Situation - Erste RetroMaßnahme liegt bereits vor
GT1+,BT1+
J5321xx-801,D
Line Design
Is Result of
Retro Installation
Is Re-Identified by
J0084xx-801,A
Gültigkeiten
01: GT 1-4
01
01,02
03
01,02
Seite 254 von 388
J0082xx-801,A
J5322xx-851,A
J5322xx-801,D
Gültigkeiten
01: GT 1-4
02: GT 5-10
03: BT 1+
04: GT11+
Is Base for
GT1-4
Retro Design
J5322xx-801,C
Produktstrukturen
Retro Installation
J532..1-401
01
J532..1-401
J532..2-401
J532..3-001
J008..8-001
J532..4-001
J532..4-001
01
J532..5-001
J008..5-001
 Vilsmeier
Retro für Retro: Schritt 1 - Revisionieren der
betroffenen Baugruppe
GT1-4
J5321xx-801,D
GT1-4
Retro Installation
Is Base for
J0084xx-801,A
Line Design
J5322xx-801,C
Produktstrukturen
GT1+,BT1+
Retro Design
J5322xx-801,D
Retro on Retro Design
J5322xx-851,A
Gültigkeiten
01: GT 1-4
Gültigkeiten 01
J532..1-401
01: GT 1-4
02: GT 5-10
03: BT 1+
01,02
J532..2-401
04: GT11+
03
01,02
Seite 255 von 388
Revise
J5322xx-851,B
Is Result of
Gültigkeiten
01: GT 1-4
01
J532..1-401
01
J532..1-401
J532..3-001
J008..8-001
J008..8-001
J532..4-001
J532..4-001
J532..4-001
J532..5-001
01
J008..5-001
01
J008..5-001
 Vilsmeier
Retro für Retro: Schritt 2 - Erweitern der Struktur der
Retro-BG – Kopieren der PS mit Gültigkeit
Copy Effectivity Symbols
--- Select Area --ES
01
02
03
04
Produktstrukturen
Part Number Source J53220003-801
|
--- Edit Area ----------------------------------------------------------------------------------------------------|
new Effectivity Symbol 02
|
select ES ->
Effectivities
affected by current ES
VS
From To
Component
ES
<- copy ES
GT
0005 0010
J532xxx2-401
#01#02
|
J532xxx5-001
#02
|
copy ES with structure relations
--- View Area ----------------------------------------------------------------------------------------------------------------------------------------------Effectivity Symbols on Source Part
ES
copied? Effectivity Ranges
01
no
GT0001-GT0004
02
yes
GT0005-GT0010
03
no
BT0001-BT9999
04
no
GT0011-GT9999
Effectivity Symbols on Target Part
ES
01
02
OK
Seite 256 von 388
Part Number Target J53220003-851
new?
no
yes
Effectivity Ranges
GT0001-GT0004
GT0005-GT0010
Cancel
 Vilsmeier
Retro für Retro: Schritt 2 - Erweitern der Struktur der
Retro-BG
Retro Installation
GT1-10
J5321xx-801,D
GT1-4
J0084xx-801,A
Is Base for
Line Design
Retro Design
J5322xx-801,D
Gültigkeiten
01: GT 1-4
02: GT 5-10
03: BT 1+
04: GT11+
J5322xx-851,A
Revise
01
03
01,02
J532..1-401
01
J532..1-401
Is Result of
J5322xx-851,B
Gültigkeiten
01: GT 1-4
02: GT 5-10
Gültigkeiten
01: GT 1-4
01,02
Produktstrukturen
GT1+,BT1+
01
02
J532..2-401
J532..2-401
J532..3-001
J008..8-001
J008..8-001
J532..4-001
J532..4-001
J532..4-001
J532..5-001
01
J008..5-001
01
02
Seite 257 von 388
J532..1-401
J008..5-001
J532..5-001
 Vilsmeier
Retro für Retro: Schritt 4 - Bearbeiten der Retro-BG
GT1-10
J5321xx-801,D
Retro Installation
GT1-4
J0084xx-801,A
Is Base for
Line Design
Retro Design
J5322xx-801,D
Gültigkeiten
01: GT 1-4
02: GT 5-10
03: BT 1+
04: GT11+
Is Re-Identified by
J5322xx-851,A
Revise
01
03
01,02
J532..1-401
01
J5322xx-851,B
Gültigkeiten
01: GT 1-4
02: GT 5-10
Gültigkeiten
01: GT 1-4
01,02
Produktstrukturen
GT1+,BT1+
J532..1-401
02
J532..2-401
J532..3-001
J008..8-001
J532..4-001
Re-Identify
J532..4-001 Retro
Rework
J532..5-001
01
01
J008..5-001
01
Seite 258 von 388
J532..1-401
J532..2-401
J008..8-001
J008..4-001
Reworked
01
02
Removed
Is Result of
J008..5-001
J532..5-001
 Vilsmeier
Retro für Retro: Schritt 5 - Delta-Berechnung InlineBG/Retro-Vorgänger zu Retro-BG
J5321xx-801,D
Line Design
GT1-10
GT1-4
Retro Design
J5322xx-801,D
Is
Re-Identified
by
J5322xx-851,A
Gültigkeiten
Gültigkeiten
01: GT 1-4
01: GT 1-4
02: GT 5-10 01
01
J532..1-401
03: BT 1+
04: GT11+
01,02
Produktstrukturen
GT1+,BT1+
Revise
J5322xx-851,B
Gültigkeiten
01: GT 1-4
02: GT 5-10
J532..1-401
01
02
J532..2-401
03
ES 02: Line-Vorgänger:
Removed J532..4-001
Added J008..4-001
Removed J532..5-001
J532..3-001
J008..8-001
J532..4-001
J532..4-001
Re-Identify
Retro
Rework
01
J532..1-401
J532..2-401
J008..8-001
Removed
J008..4-001
Removed
01,02
Removed
Seite 259 von 388
J532..5-001
01
J008..5-001
01
Added
J008..5-001
ES 01 Retro-Vorgänger:
Removed J532..4-001
Added J008..4-001
 Vilsmeier
Retro für Retro: Schritt 6 - Erzeugung der Relationen
zwischen der Retro Installation und den betroffen
Teilen der PS
GT1-10
GT1-4
Retro Installation
J0084xx-801,A
GT1+,BT1+
Line Design
Gültigkeiten
01: GT 1-4
02: GT 5-10
03: BT 1+
04: GT11+
J5322xx-851,A
Gültigkeiten
01: GT 1-4
01
01,02
03
J532..1-401
01
J5322xx-851,B
Gültigkeiten
01: GT 1-4
02: GT 5-10
01
J532..1-401
02
J532..2-401
J532..3-001
J008..8-001
J532..4-001
J532..4-001
01
J532..1-401
J532..2-401
J008..8-001
01
J008..4-001
02
Rework
01
01,02
Seite 260 von 388
Retro Design
J5322xx-801,D
Produktstrukturen
J5321xx-801,D
J008..5-001
01
J008..5-001
02
J532..5-001
Remove
 Vilsmeier
Retro für Retro: Schritt 7 - Generieren des Add / Remove
Der Add/Remove Block wir automatisch aus
den hinterlegten Strukturinformation generiert,
ist nur richtig, wenn Produktstruktur korrekt.
Retro Installation
J0082xx-801,B
Produktstrukturen
Blocks
Seite 261 von 388
 Vilsmeier
Gegenüberstellung einer gefilterten
Produktstruktur, nur line und nur retro
Line
Retro
Produktstrukturen
Line and Retro
Seite 262 von 388
 Vilsmeier
Produktstrukturen
Retro Installation mit add, remove, rework
relationen
Seite 263 von 388
 Vilsmeier
Produktstrukturen
Retro Installation mit „is Base“ of und „is Result
of“ relationen
Seite 264 von 388
 Vilsmeier
Produktstrukturen
Retrofit – Nachrüstung von Kabelbündeln
Seite 265 von 388
 Vilsmeier
 Warum ist die Einführung dieser Items notwendig und
sinnvoll?
Produktstrukturen
Produktstruktur Items zur Ergänzung der reinen
Stücklistenstruktur
Seite 266 von 388
 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.
 Vilsmeier
Produktstrukturen
Index of Diagrams
Seite 267 von 388
 Vilsmeier
Produktstrukturen
Index of Looms
Seite 268 von 388
 Vilsmeier
Verknüpfung Index of Diagrams mit Index of
Looms
Produktstrukturen
Compatible
Seite 269 von 388
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.
 Vilsmeier
 Fertigungsrelevante Losgrößen
Produktstrukturen
Verschiedene Begriffe zum Thema „Los“
 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
Seite 270 von 388
 Beschreibt eine bestimmte Funktionalität, welche
erreicht und nachgewiesen werden muß.
 Eine Baseline kann einen oder mehrere Blocks
beinhalten.
 Eine Baseline kann Versionen haben.
 Vilsmeier
W/S Tranche
Batch
Block IPA 1/2/3
C+D
Baselines - In Line
TRANCHE 1
BATCH 1
BATCH 2
1
1B
1C
IPA 4/5
2
E
E2
E3
E3+
F
-
(3)
F2
5
(2)
I
FR
Baselines - Role Equipment
RE
RE
3
PT001
10
BT001
No. off A/C
Lead A/C
(1)
(1)
Baseline
C+D
E
E2
E3
F+E4
F
F2
BT
from to
BT
BT
1
5
Seite 271 von 388
2B
F2R
Baselines - Retrofit
Produktstrukturen
Beispiele für „Los“
BT
BT
12
13
RF
18 + 1
ST002
9
SS001
GT from to
4 GT
11 GT
12 GT
15 GT
IR
1
4
9
2
PS002
IT
3 IT
8 IT
IT
12 IT
34
ST004
from to
1
3
7
8
36
GS012
ST
34
BS026
from to
2 ST
6 ST
1
2
1
3
ST
4
5
7
8 ST
6
7
 Vilsmeier
Produktstrukturen
Get Item Info Index of Diagrams – Effectivity
Statement für Baseline
Seite 272 von 388
 Vilsmeier
Digital Mock-Up
Digital Mock-Up
Seite 273 von 388
 Vilsmeier
Digital Mock-Up
CAD Integration und Digital Mock-Up
Definition „Digitales Mockup“
 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:
Seite 274 von 388
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 3DModell abgeleitet
 Hoher Detaillierungsgrad




 Vilsmeier
Digital Mock-Up
Beispiel Bugfahrwerk
Seite 275 von 388
 Vilsmeier
Digital Mock-Up
Notwendigkeit
 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
 Vilsmeier
Digital Mock-Up
Anforderungen an DMU System
 Handhabung von ca. 10000 von EADS M modellierten
Bauteilen in der Sektionsentwicklung (z.B. Mittelrumpf)
 Handhabung von ca. 30000 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
Seite 277 von 388
 Gültigkeiten und Variantensteuerung
 Produktstrukturgesteuerte Navigation in allen
Prozessphasen notwendig
 Vilsmeier
Digital Mock-Up
3D Master und abgeleitete Zeichnung
Seite 278 von 388
Solid-E Master Modell
mit abgeleiteter
Zeichnung
 Vilsmeier
Avionik-Sektion
ohne Geräte
Digital Mock-Up
Beispiel
Seite 279 von 388
 Vilsmeier
Waffensystem
(alle Flugzeugvarianten)
Digital Mock-Up
PLM Anforderungen für Physical“ PS Handling
180000 Teile
720000 Elemente
1,5 Millionen links
Ein Flugzeug
(EF-TS Historie)
Durchschnittlich
4 Ausgaben
pro Teil
120000 Teile
200 Verbinder
(480000
Modelle)
150 Gbyte Daten
Product structure
handling
Seite 280 von 388
Database- and
Memory handling
Ein Zustand
eines Flugzeugs
(EF-TS letzte
Änderung)
30000 Teile
(120000 Modelle)
70000 Verbinder
Produkt-Struktur
Navigation
Maximum
Graphic handling
 Vilsmeier
Ein Zustand
eines ganzen
Flugzeuges
30000 Teile
Digital Mock-Up
Arbeitsmethodik und Werkzeuge
70000 Verbindungselemente
Ein Bauraum
eines Flugzeuges
Umgebung
einer Teilegruppe
Suche nach vordefinierten
Zonen
Montage- und
DemontageAnalysen
Suche nach
Individuell
definierten
Zonen
Kollisionsuntersuchungen
Produkt Struktur NachbarschaftsNavigation
suche
Ersatzgeometrie
Maximale
Anforderung
Ersatzgeometrie
Seite 281 von 388
Mess-Analysen
Umgebung
eines Teiles
CATIAKonstruktion
50 Teile
SOLID-E
100 Verbinder
ZugänglichkeitsAnalysen
Ersatzgeometrie
CATIA model
handling
 Vilsmeier
Digital Mock-Up
Zusammenspiel PS & geometrische Navigation
Seite 282 von 388
Navigation
mit
Hilfe der
Produktstruktur
Ersatzgeometrie
 Vilsmeier
Digital Mock-Up
Bauraumsuche
Bauraumsuche für
Hydraulikleitung
Seite 283 von 388
 Vilsmeier
Digital Mock-Up
Nachbarschaftssuche
Seite 284 von 388
Nachbarschaftssuche (Radius 20mm)
für Hydraulikleitung
 Vilsmeier
Digital Mock-Up
Montageanalyse
Seite 285 von 388
MontageAnalyse
 Vilsmeier
Digital Mock-Up
Demontage Analyse
Seite 286 von 388
DemontageAnalyse
 Vilsmeier
Digital Mock-Up
Kollisionsanalyse
Seite 287 von 388
KollisionsAnalyse
 Vilsmeier
Digital Mock-Up
Kollision zwischen Struktur & Elektrik
Seite 288 von 388
Frühzeitiges Erkennen
von Problemen
 Vilsmeier
Methodik – Absolute Positionierung
Y
0
Digital Mock-Up
Z
X
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
Seite 289 von 388
 Vilsmeier
Relative Positionierung:
Alle Bauteile werden relativ zum
Nullpunkt der nächsten Baugruppe
positioniert, mehrfache relative
Positionierung ist möglich
Z
Z
Digital Mock-Up
Methodik – Relative Positionierung
Z
Z
X
X
X
Y
Y
Y
X
Y
Vorteile:
• Baugruppen können insgesamt
verschoben werden, deutlich
reduzierter Aufwand
Seite 290 von 388
Nachteile:
• Komplizierter gegenüber absoluter Positionierung, mehrfache
Transformationen
 Vilsmeier
PLM und Team Data Manager
Teamcenter
=“Teilestamm”
Assy
Files
Files
Files
Assy
Z-Teil 1
Digital Mock-Up
Info Pack
Assy
Info
Pack
Z-Teil 2
Files
Files
Z-Teile
Files
Files
Info
Pack
Spec-Teile
SP1
Z-Teil 3
Info
Pack
Gültigkeiten
SP2
SP3
Files
Files
G Assy
G-Teil 1
G-Teil 2
CATIA
SOL
CATIA
DRW
CATIA
PRV
Seite 291 von 388
CATIA
SOL
CATIA
DRW
CATIA
PRV
Files
Files
Info
Pack
Check-out
Check-in
CATIA
DRW
Spec-Teil
“StüLi Normteile”
Trafo matrix
VPM
=“Geometriestamm”
G-Teil 3
CATIA
SOL
CATIA
DRW
CATIA
PRV
G-Teil SP
CATIA
ASM
CATIA
PRV
G-Spec.Teil
CATIA
SOL
CATIA
DRW
CATIA
PRV
 Vilsmeier
PLM und Team Data Manager
Assy
1:1 Beziehung
Files
Files
Files
Assy
Pfad Name als
Ref. In Metaphase
SP-ASSY
Digital Mock-Up
Metaphase
Info Pack
Assy
Z-Teil 1
Info
Pack
Files
Files
Info
Pack
ANC Assy
Z-Teil 3
Files
Files
Info
Pack
SP1
Files
Files
SP2
SP3
VPM
CATIA
DRW
G-Assy
G-Teil 1
G-Teil 2
CATIA
SOL
TIFF Dokument
CATIA CATIA
DRW SOL
CATIA
PRV
Seite 292 von 388
Z-Teil 2
G-Teil 3
CATIA CATIA
DRW SOL
CATIA
PRV
CATIA
DRW
CATIA
PRV
Auswertung der
CATIA Dittos und
Übertragung nach
Metaphase
G-Teil SP
CATIA
ASM
CATIA
PRV
 Vilsmeier
Digital Mock-Up
Digital Mock-Up - Strukturierung des Produkts
bezüglich Wiederverwendbarkeit der Geometrie
 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
Seite 293 von 388
 Aufbruch nach Systemen berücksichtigen
 Zonalen Aspect oder Zonenattribut einführen
 Vilsmeier
Digital Mock-Up
DMU Darstellungen für Eurofighter
Rumpfvorderteil und Flügel
Seite 294 von 388
 Vilsmeier
Digital Mock-Up
Nutzen
 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
 Vilsmeier
Visualisierung
3D-Visualisierung
Definition
Seite 296 von 388
3D-Visualisierung ist die Fähigkeit,
innerhalb des PLM Systems
3D Geometriedaten als sogenannte
Ersatzgeometrie zu visualisieren und zu
manipulieren
 Vilsmeier
 Unter Geometriedaten sind die 3D Konstruktionsdaten des
originären CAD-Tools zu verstehen.
Visualisierung
3D-Visualisierung
Geometrie - Geometriedaten
Seite 297 von 388
 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
 Vilsmeier
 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
3D-Visualisierung
Geometrie - Ersatzgeometrie
Seite 298 von 388
 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
 Vilsmeier
Visualisierung
3D-Visualisierung
Ersatzgeometrie Anwendungen
Wofür lässt sich
Ersatzgeometrie anwenden
... und wer kann sie nutzen
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
 Vilsmeier
Visualisierung
3D-Visualisierung
Aufruf des Viewers über das PLM
- Einstieg zur Visualisierung durch Aufruf
des PLM.
- Absetzen der Query
- Aufruf des 3D Viewers
Seite 300 von 388
 Vilsmeier
Visualisierung
3D-Visualisierung
3D Einzelteil-Visualisierung
Seite 301 von 388
- PC Oberfläche von
VisMockUp
- Darstellung der Produktstruktur (links)
- Darstellung der
tesselierten Ersatzgeometrie (rechts)
 Vilsmeier
Visualisierung
Zeichnung Blatt 1 des Assembly von Folie 8
Seite 302 von 388
 Vilsmeier
Visualisierung
Zeichnung Blatt 2 des Assembly von Folie 8
Seite 303 von 388
 Vilsmeier
Visualisierung
3D-Visualisierung
Volumen- und Bauraumsuche
- Bauraumsuche über
Volumen-Filter
nur über gesamte
Produktstruktur
möglich
Seite 304 von 388
 Vilsmeier
Visualisierung
3D-Visualisierung
Ergebnis von Volumensuche
- Ergebnis der Bauraumsuche mittels
Volumenfilter
Seite 305 von 388
 Vilsmeier
Visualisierung
Darstellung der Zonenstruktur und
Zonenmodelle
Seite 306 von 388
 Vilsmeier
Visualisierung
3D-Visualisierung
Suchvorgang über Volumen-Filter
- Die Bounding Box der
Zone wird zum suchen
mittels eines VolumenFilters aktiviert
Seite 307 von 388
 Vilsmeier
Visualisierung
3D-Visualisierung
Ergebnis der Bauraumsuche
Alle in der selektierten
Zone enthaltenen Teile
werden gegen die
gesamte Produktstruktur
gesucht und dargestellt
Seite 308 von 388
 Vilsmeier
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
Seite 309 von 388
 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
 Vilsmeier
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
Seite 310 von 388
 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
 Vilsmeier
3D Modellierung
Annotationen
Seite 311 von 388
 Vilsmeier
• Alle modernen CAD Systeme
ermöglichen 3D Modellierung.
3D Modellierung
Maße und Toleranzen
Seite 312 von 388
• 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.
 Vilsmeier
3D Modellierung
Maße und Toleranzen –Farbliche Zuordnung
Seite 313 von 388
 Vilsmeier
3D Modellierung
PMI – Product Manufacturing Information
• 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
Seite 314 von 388
 Vilsmeier
PLM XML
PLM XML Pipline – Datenintegration im
Unternehmen
Seite 315 von 388
 Vilsmeier
PLM XML
PLM XML „Datenstrom“
Seite 316 von 388
 Vilsmeier
PLM XML
PLM XML – Präsentation von Daten für
verschiedene Anwender
Seite 317 von 388
 Vilsmeier
PLM XML
PML XLM – Möglichkeiten der Datenintegration
im Unternehmen auf der Basis von PLM XML
Seite 318 von 388
 Vilsmeier
PLM XML
XML report writers and transformers in PLM
 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
 Vilsmeier
PLM XML
Wozu wird der XML report writer/transformer
benötigt bzw. eingesetzt?
 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
 Vilsmeier
PLM XML
Einführung: XML/XSL
 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
 Vilsmeier
Einführung: XML example
PLM XML
XML header with character set definition
<?xml version="1.0" encoding="ISO-8859-1"?>
<eadsrpt:ResultSet Title="All800s" Creator="be28615" Date="2005-03-18" Time="13:16"
xmlns:eadsrpt="http://www.m.eads.net/PLM/xmlrep"
xmlns:xrsup="http://www.m.eads.net/PLM/xmlrep-support">
<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">J00020000-801</eadsrpt:Field>
<eadsrpt:Field Name="s0Official">True</eadsrpt:Field>
<eadsrpt:Field Name="s1SiteCode">C0419 - 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="s1SiteCode">C0419 - 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="s1SiteCode">C0419 - EADS M</eadsrpt:Field>
</eadsrpt:Node>
</eadsrpt:Relation>
</eadsrpt:Node>
</eadsrpt:Relation>
</eadsrpt:Node>
</eadsrpt:ResultSet>
Attribute
Value
Element with preceding namespace
Seite 322 von 388
 Vilsmeier
PLM XML
Einführung: XML/XSL/XSLT
 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
 Vilsmeier
<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="1.1" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:eadsrpt="http://www.m.eads.net/PLM/xmlrep">
<xsl:output method="text" indent="no" encoding="ISO-8859-1"/>
<xsl:template match="eadsrpt:ResultSet">
<xsl:text>RFA-Type@RFA@Issue@Title@Mod@Mod Issue@Baseline@Part Nr.@Part Issue@System
Construct@Rev.Eff</xsl:text>
<xsl:text disable-output-escaping="yes">
</xsl:text>
<xsl:apply-templates/>
</xsl:template>
PLM XML
Einführung: XML/XSL/XSLT example
<xsl:template match="//eadsrpt:Node[@Class='s0WrkOdr']">
<xsl:variable name="RFANr" select="eadsrpt:Field[@Name='s0ChgReqNumber']"/>
<xsl:variable name="RFAType" select="eadsrpt:Field[@Name='s0ChgReqType']"/>
<xsl:variable name="RFATitle" select="eadsrpt:Field[@Name='s0ChgReqTitle']"/>
<xsl:variable name="RFAIssue" select="eadsrpt:Field[@Name='s0ChgReqRevision']"/>
<xsl:variable name="MODNr" select="eadsrpt:Field[@Name='s0PcmsCPNumber']"/>
<xsl:variable name="MODIssue" select="eadsrpt:Field[@Name='s0PcmsCPRevision']"/>
<xsl:variable name="Baseline" select="eadsrpt:Field[@Name='s0BaselineClass']"/>
<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
 Vilsmeier
 Ein XML report writer besteht aus den folgenden
Objekten
PLM XML
Wie wird ein XML report/transformer definiert
Seite 325 von 388
 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.
 Vilsmeier
Setting up an XML report/transformer
Enter report title
(will be written to XML file)
Can be narrowed to a
specific acces group
PLM XML
Enter report name
"Escape" attribute values that
would destroy well-formedness
What is escaping?
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
 Vilsmeier
PLM XML
Definition der Struktur für die Navigation
Creating the navigate structure
 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
Seite 327 von 388
 Item Navigation Templates
 Relationen Navigation Templates
 Vilsmeier
PLM XML
XML – Mögliche Berichte im PLM
 Der Report writer erzeugt nur ein XML file im
Verzeichnis des Anwenders
 Der Transformer führt eine server-based XSLTransformation der XML Datei aus und schreibt
als Ergebnis (XML, HTML, PDF, PS, ASCII) in das
Verzeichnis des Anwenders
Seite 328 von 388
 Vilsmeier
PLM XML
Vergleich HTML und XML Code
Der folgende HTML-Code

Hubert Hans Partl
 
Muthgasse 18
 
A-1190 Wien
 geb. 8. März 1949

bewirkt eine Darstellung wie
Hubert Hans Partl
Muthgasse 18
A-1190 Wien
geb. 8. März 1949
Seite 329 von 388
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
 Vilsmeier
Definition der Navigation Struktur
Item template
Relation template
PLM XML
Transformer object
Transformation description
(XSL-Sheet)
Seite 330 von 388
 Vilsmeier
PLM XML
Beispiel: Erzeugen eines RFA Reports
Seite 331 von 388
Drag & Drop
Name für PDF File
 Vilsmeier
PLM XML
PDF Repräsentation eines RFA Reports
Seite 332 von 388
 Vilsmeier
Vergangenheit
Jetzt
Dokumenten Management (DM)
Was ist neu? 1. Kommunikation
Strukturen,
Prozesse
Zeitversetzte Kommunikation
entlang d. Prozeßkette
über Dokumente;
komplexe &
redundante Kommunikation
Seite 333 von 388
Sukzessives Befüllen des
PLM Produktinformationsmodells; synchrone Zugriffsmöglichkeit, Concurrent
Engineering
 Vilsmeier
Jetzt
Vergangenheit
1.4.2000
10.00Uhr
1.4.2000
10.00Uhr
1.4.2000
10.00Uhr
1.5.2000
10.00Uhr
Dokumenten
Management
1.4.2000
10.00Uhr
1.6.2000
10.00Uhr
Dokumenten
Produktion
1.8.2000 10.00Uhr
Arbeitobjekt ist das
gesamte Dokument; daher sequentieller Ablauf
Seite 334 von 388
Layout,
Medien
Dokument
generieren
Was ist neu? 2. Strukturierte Dokumente
2.4.2000
10.00Uhr
Arbeitsobjekt ist das Dokumentelement; ermöglicht
parallelen Ablauf.
 Vilsmeier
Alter
Prozess
Was ist neu? 3. Informationsversorgung
1.4.2000
10.00Uhr
PLM
Prozess
2.4.2000
10.00Uhr
1.4.2000
10.00Uhr
1.4.2000
10.00Uhr
5.4.2000
10.00Uhr
4.4.2000
10.00Uhr
3.4.2000
10.00Uhr
Dokumentenversorgung als zentraler Service
Folge: Zeitverlust & Prozessunterbrechung
Seite 335 von 388
Elektronischer Online-Zugriff auf die Dokumente
Folge: unmittelbare Verfügbarkeit der
Informationen
 Vilsmeier
Komplexe Suche
Seite 336 von 388
 Vilsmeier
Work Flows für Dokumenten Management
Sign off, zur Freigabe
des Dokuments durch
die definierten
Verantwortlichen
Revise Überprüfung des Dokuments
Seite 337 von 388
 Vilsmeier
Anzeige Life Cycle Status
Seite 338 von 388
 Vilsmeier
 Pro Flexibilität
Diverses
Flexibilität oder striktes Prozessmanagement
 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
 Vilsmeier
 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.
Diverses
Datenqualität
 Feinde der Datenqualität
Seite 340 von 388
 Termindruck, Termindruck, Termindruck, !!!
 Qualität ist nicht Teil der Zielvorgabe
 Besser eine unvollständige Information als keine
 Vilsmeier
Kosten der Fehlerbehebung
Diverses
Zusammenhang von Fehlerbehebungskosten
und Entdeckung der Fehlers im Lebenszyklus
Vorentwicklung
Seite 341 von 388
Entwicklung
Produktion
In Service
 Vilsmeier
 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:
Diverses
Digitale Signatur – Elektronische Freigabe
 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:
Seite 342 von 388
 Papierdurchlauf mit hohem Personalaufwand entfällt.
 Einscannen u. Registrierung der Unterschriftsblätter entfällt
 Vilsmeier
Datenaustausch
EF Workshare und Organisation
EADS MAS
EADS MAS
Seite 343 von 388
 Vilsmeier
Produkt Daten Technologie (PDT)
Bereitstellung der Technologie, um eine datenintegrierte
Prozesskette zu ermöglichen!
Elemente der PDT:
1. Prozeßmodelle
Datenaustausch
Ziel:
Beschreibung der Prozessketten im Lebenszyklus
des Produktes unter Anwendung entsprechender
Methoden (z.B. ARIS EPK, SADT, UML, ...).
Actuating variable
Input
Activity
Auxiliary variable
2. Produktdatenmodelle
3. Implementierungsmethoden/
Systeme
Alle Produktinformationen (z.B. Geometrie,
Baugruppenstruktur,Versionen, ...) werden zur
Weiterverarbeitung mit Systemen in Produktdatenmodellen beschrieben (z.B. in EXPRESS, UML, ..).
Prozess- und Produktdatenmodelle werden in
rechnergestützten Systemen implementiert. Die
Systeme erzeugen und verändern Produktdaten
entsprechend der Regeln der Geschäftsprozesse.
assembly_relation
product
product_version
QS
NC
M-CAD
Folgerung:
Seite 344 von 388
Eine rechnerintegrierte Prozesskette kann nur durch die gezielte
Anwendung von Methoden, sowie den abgestimmten Einsatz von
Systemen und Produktdatenmodellen realisiert werden.
 Vilsmeier
Das Datenaustausch Problem
DC
GM
Ford
VW
…
Volvo
Hersteller
Datenaustausch
BMW
Delphi
Partner
1. Reihe
Bosch
Conti Siemens Hella
FuBa
ZF
…
VDO
2. Reihe
...
a
b
c
Jede Beziehung
benötigt
Harmonisierung :
Seite 345 von 388
d
e
f
g
h
i
j
k
l
m
n
 der firmenübergreifenden Prozesse
 der Datenformate
 der Implementierungsmethoden
 Vilsmeier
PLM
A
Datenaustausch
Vorteil genormter Schnittstellen
: Prozessor
ERP
E
PLM
B
CAD
D
CAD
C
Informationsaustausch
ohne standardisierte Schnittstelle
Prozessorenanzahl: n • (n-1) = 20
Seite 346 von 388
PLM
A
ERP
E
CAD
D
genormte
Schnittstelle
PLM
B
CAD
C
Informationsaustausch
mit genormter Schnittstelle
Prozessorenanzahl: 2 • n = 10
 Vilsmeier
Daten Austausch/ Kommunikation Szenarien
• asynchroner Datenaustausch
• Technologie und Tools verfügbar
• Projekte produktiv
• Für die Partnerintegration
Datenaustausch
PLM Datenaustausch
Seite 347 von 388
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
 Vilsmeier
Datenaustausch
Übersicht Application Protocols
Seite 348 von 388
Application
Protocol
201
202
203
204
205
207
208
209
210
212
213
214
215
216
217
218
220
221
222
223
224
225
226
227
231
232
Content
Explicit Draughting
Associative Draughting
Configuration Controlled 3D Designs of mechanical parts and assemblies
Mechnical Design using Boundry Representations
Mechnical Design using Surface Representations
Sheet Metal Die Planning and Design
Life Cycle Product Change Process
Composite & Metallic Analysis & Related Design
Electronic Assembly, Interconnect and Packaging Design
Electrotechnical Design and Installation
Numerical Control (NC) Process Plans for Machined Parts
Core Data for Automotive Mechanical Design Processes
Ship Arrangement
Ship Moulded Forms
Ship Piping
Ship Structures
PCA Process Planning
Functional Data and their Schematic Representation for Process Plant
Design to Manufacturing for Composite Structures
Exchange of Design and Manufacturing Product Information for Cast Parts
Mechanical Product Definition for Process Planning using Machining Features
Building Elements using Explicit Shape Representation
Ship Mechanical Systems
Plant Spatial Representation
Process Design and Process Soecification for Major Equipment
Technical Data Packaging Core Information and Exchange
 Vilsmeier
• Flächen-, Drahtmodell und Offsetpunkt
Repräsentationen
• Design, Produktion und Betrieb
• Generelle Charakteristiken
Datenaustausch
AP216:Ship moulded forms
• Hauptmaße
• Hüllgeometrie
• Wichtige Innenflächen
• Hydrostatik
• Stabilitätstabellen
Seite 349 von 388
 Vilsmeier
Datenaustausch
Begriffsdefinitionen
Seite 350 von 388
 Vilsmeier
UoF = Unit of Functionality
 Sammlung von Entities die zusammengenommen eine
bestimmte Art von Funktionalitäten repräsentieren.
Datenaustausch
Units of functionality und Conformance Classes
CC = Conformance Class
 Sammlung von UoF mit dem Ziel den Implementierern
Seite 351 von 388
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
 Vilsmeier
Seite 352 von 388
34
(Application Protocols, APs)
Technische
Zeichnung
(AP 201)
3D-Geometrie
Produktkonfig.
(AP 203)
...
anwendungsorientierte Kernmodelle
(Application Resources)
Zeichnung
(101)
Elektrik
(103)
Kinematik
(105)
...
(Integrated Resources)
Geo- Repräsen- Produktmetrie
tation
struktur
(42)
(43)
(44)
Darstellung
(46)
...
Grundlagen der Produktbeschreibung (41)
Implementierungsmethoden
Datei
(21)
SDAI
(22)
Datenbank
Test- und Prüfmethoden
Entwicklung elektrotechnischer Anlagen (AP 212)
33
Prozeßketten in der Automobilindustrie (AP 214)
32
Entwicklungsmethodik
für Datenmodelle
Anwendungsdatenmodelle
31
für den
Datenaustausch
Spezifikationsmethoden
Beschreibungsmethode
für Produktdaten
(EXPRESS)
Spezifikationssprache
EXPRESS
Anwendungsneutrale
Bausteine zur
Produktbeschreibung
Datenaustausch
SOAP - STEP ON A PAGE_1
STEP Anwendungsarchitektur
 Vilsmeier
Seite 353 von 388
34
Anwendungsdatenmodelle
(Application Protocols, APs)
3D-Geometrie
Produktkonfig.
(AP 203)
...
(Application Resources)
Zeichnung
(101)
Elektrik
(103)
Kinematik
(105)
...
(Integrated Resources)
Geo- Repräsen- Produktmetrie
tation
struktur
(42)
(43)
(44)
Darstellung
(46)
...
Grundlagen der Produktbeschreibung (41)
Datei
(21)
SDAI
(22)
Datenbank
Test- und Prüfmethoden
Technische
Zeichnung
(AP 201)
Branchenspezifische
Anwendungsdatenmodelle zur
Produktbeschreibung
(z.B. AP214, AP212,
AP203, AP201)
Test- und
Prüfmethoden für
Implementierungen
32
Entwicklung elektrotechnischer Anlagen (AP 212)
33
Prozeßketten in der Automobilindustrie (AP 214)
31
Entwicklungsmethodik
für Datenmodelle
Spezifikationsmethoden
Spezifikationssprache
EXPRESS
Datenaustausch
SOAP - STEP ON A PAGE_2
STEP Anwendungsarchitektur
Als internationale Norm (IS)
veröffentlicht
Federführend durch
ProSTEP bearbeitet
 Vilsmeier
Warum ist Produktstruktur und Konfigurationsmanagement im AP214 so wichtig?
 Unterschiedliche Firmen nutzen die verschiedenen STEPObjekte auf unterschiedliche Art und Weise
 Entscheidend ist die Semantik der auszutauschenden Daten
Datenaustausch
 Einfache Datenmodelle sind nicht anwendbar
 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
 Vilsmeier
Warum ist Produktstruktur und Konfigurationsmanagement im AP214 so wichtig?
 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)
Datenaustausch
 Der STEP Standard ist
 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
Seite 355 von 388
 Dokumentation von Einzelfahrzeugen einschließlich der
verbauten Teile und Einbaubedingungen („Bauzustand“)
 Entwicklung von Standardsoftware für das Product Coding
 Vilsmeier
Das STEP PLM Schema
AP214
Seite 356 von 388
AP212

Datenaustausch

PLM
Schema
AP203

AP232
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
 Vilsmeier
 Analyse der vorhandenen Spezifikationen
 Entwurf Express Datenmodell mit Ausdrücken
der Benutzer
Datenaustausch
Vorgehensweise Aufnahme User Requirements
 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
 Vilsmeier
alternate
relationship
part number
is base of
title
part type
item
is alternate of
uses
is component of
has component
position
with detail level
measure unit
remark
make from
relationship
Seite 358 von 388
item
issue
transformation
matrix
quantity
references finish material spec
authority
issue
authorized by
is assy of
REAL
STRING
STRING
measure unit
produced quality
issue
remarks
weight unit
calculated weight
safety classification
maturity stage
item
definition
produces
document
has production
site
organisation
defines
substitute of
base of
substitute
relationship
STRING
STRING
STRING
STRING
references standard part spec
is for an
(INV) has issues
Datenaustausch
Partielles Express G Datenmodell
Produktstruktur
references protective treatment
STRING
STRING
STRING
REAL
STRING
STRING
document
is relevant for
STRING
REAL
item
view
view name
STRING
 Vilsmeier
Datenaustausch
Elemente eines Data dictionarys




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
 Vilsmeier
 Name: item
 Beschreibung:
Datenaustausch
Beispiel für item
(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 10303 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




Seite 360 von 388
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.
 Vilsmeier
Datenaustausch
Beispiel des Attributs Teilenummer der Entität
item
 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 J13.740
 Format (nur bedingt notwendig): An
 Beispiel:e.g 'J123.12345-001', 'J123.12345-401'
 Regeln:
Seite 361 von 388
 Vilsmeier
Aufgabe: Mapping Ansatz für Produktstruktur
Eurofighter Weapon System
Eurofighter Aircraft & TR
Twin Seater
...
Product Component
Datenaustausch
Product Class
1000 l Tank
Single Seater
Twin Seater
AGE
ASTA
Single Seater
...
Class Structure
Product Structure
System
Detail
level
PHYSICAL
Items /
Instances
ZONE
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
 Vilsmeier
Schematischer Entwicklungsprozess im Kontext
von RFA
request
for
development
Datenaustausch
request
Seite 363 von 388
work_request
RFA
definition of
development
project
project
initial
development
order
work_order
subdivide work
into activities
activity
 Vilsmeier
Variante Produktstrukturen in AP214 CC8
Konzeptionelle
Produktkomponenten
Varianten/
Lösungen
Teilestruktur
(BoM)
Dokumente
(z.B. CAD-Modelle)
Type A
Cyl. Head
Type B
...
Type C
...
Engine
Unternehmen
Datenaustausch
Produktklassen
Seite 364 von 388
...
Camshaft
Standard
......
...
Middle class
car
Zugeordnete Informationen:
Interior
Chassis
Convertible
...
.....
...
Sports
car
...
......
...
...




Spezifikationen
Konfigurationsregeln
Änderungsdaten
Effektivitäten
 Vilsmeier
Übersicht zu AP214 CC8 Datenobjekten
Datenaustausch
Product Classification
Product Class Structure
Product Class
Component Structure
Product Component
Product Function
Product
Structure
AlternativeSolution
Solution
Alternative
Alternative
Solution
Specification
Product
Coding
Configuration
ProductInstance
Instance
Product
Item Instance
Classification
Assembly Structure
Effectivity
Bill of Materials
Organizational Data
Document / Model
Structure
Seite 365 von 388
Item /
Item Version
Document /
Geometric Model
...
 Vilsmeier
AP 214 UoF S7 „specification control‟
Übersicht der ARM Objekte
Datenaustausch
product structure
S7
complex_
product_
relationship
(ABS) complex_
product
collection of products
with same or similar
characteristics
product_
class
S7
product characteristics
and their dependencies
S[1:?]
specification_ specification specification_
category
expression
S7
product_
structure_
relationship
functional
design /
requirements
(ABS) product_
constituent
one variant
(explicit rep.)
part or tool (implicit)
product_
identification
physic. realized
product_
specification
S7
product_
function
S7
(with serial #)
manufacturable
alternative_
solution
part or tool
w/o variation
(explicit)
item
product or
component
including all
variants
assembly_
component_
relationship
item_
version
product_
component
item_
instance
design_disc_
item_definition
S7
product or
component
S7
S3
S1
...
physical_
instance
S7
not covered
by AP 203
configuration
S7 control of part / variant usage (validity)
Seite 366 von 388
relationship
partially covered
by AP 203
 Vilsmeier
Mapping approach für change Request
relationships
name=
“decomposition”
versioned_action
_request
resolved_request
activity_
action_
relationship
relationship
directed_action
Datenaustausch
Change_Request
action_
relationship
action_
relationship
action
action
Manufacturing
interface
Technical
interface
concerned_organization
Seite 367 von 388
activity
action
applied_action_
name=
assignment
“hierarchy”
action_
relationship
name=
“derivation”
organization
organization
directed_action
versioned_action
_request
Change_Request
EF Partner
 Vilsmeier
Übersicht Daten Austausch Prozess
Selection
Checkout
Datenaustausch
SELECT
Change
Management
Teamcenter
P21
File
TRANSLATE
PreProcessor
STEP
File
PACK
Package
TRANSFER
Message
STEP
File
trigger
Data Package
status
Exchange
Order
or
EXPORT
Monitoring
Administration
Create
Order
Data Exchange and Information Manager (chosen product DXM)
Exchange
Order
Create
Order
status
trigger
on demand
MP
Interface
PLM
Teamcenter
Seite 368 von 388
P21
File
PreProcessor
STEP
File
Package
Message
STEP
File
Data Package
 Vilsmeier
Datenaustausch
Ziele des EF Datenaustausch Projektes
 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
 Vilsmeier
Datenaustausch
Erfahrungen aus der Erstellung der
Datenaustausch Spezifikation
 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
 Vilsmeier
Standard Prozessor und EF spezifische
Teileklassen
description
product
p_r_p_c
‚part„
‚document„
rel
Datenaustausch
Id
versteht jeder
Standard Prozessor
‚„assembly„
p_r_p_c
‚standard part„
rel
Verstehen die
EF Prozessoren
‚general
assembly„
STEP AP214
EF HLID
Item_80x
Seite 371 von 388
p_r_p_c
Part_type
‚detail„
Item
Assembly
Assembly_ _type
classification
 Vilsmeier
Funktionalität
Anzahl der
Datenelemente (Entitäten,
Attribute, Relationen)
Datenaustausch
Überblick Funktionalität und Datenelemente
EF HLID
Seite 372 von 388
Produktstruktur
Change Management
82
109
Information Pack
(Dokumente)
56
Design Standard,
Design Built Standard
16
 Vilsmeier
Teamcenter
Datenaustausch
Datenaustausch – IT Systeme bei EADS M
Seite 373 von 388
DXM (Dateiversand)
VPM
CATIA (Fileserver)
PS-Export/Import (Teamcenter+CATIA)
CM-Export/Import
Teamcenter/VPM-Kopplung (Voraussetzung für PS-Export)
 Vilsmeier
Datenaustausch
Test Erfahrungen
 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
 Vilsmeier
 Zwingen Sie die Anwender gute Spezifikationen zu
schreiben.
 Konzeptionelles Datenmodel
 Data Dicitionary
 Prozessmodell
Datenaustausch
„Lessons Learned“
 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
 Vilsmeier
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
Seite 376 von 388
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
 …..




 Vilsmeier
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
Seite 377 von 388





Flexible SOA-Systemarchitekturen
Adaptive Workflows
Einsatz semantischer Technologien
Einsatz von Cloud Computing
…..
 Vilsmeier
Ausblick und Trends
Requirements Management






Seite 378 von 388
Wie sieht der Gesamtprozess im V-Modell aus?
Welches Tool?
Integriert in PLM?
Validation, Verification, Qualification, Certification
Integration mit PLM?
 Vilsmeier
Ausblick und Trends
Interface Control Management (1/2)
Interface Control
Management
Customer
PMO
Engineering
Production
ILS
Configuration Management
PLM
Process
Integration
Seite 379 von 388
MRP
Product Model Repository
Configuration
Management
Data & Document
Management
Interface
Management
ESS
Integral
Processes
 Vilsmeier
Interface Control Management (1/2)
Ausblick und Trends
 Logische oder funktionelle Interfaces






elektronisch
elektrisch
Man-Machine
geometrisch
hydraulisch
……….
 physikalisches Interface








Seite 380 von 388
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?
 Vilsmeier
Ausblick und Trends
Rollenbasierte Arbeitsplätze
 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
 Vilsmeier
Ausblick und Trends
Funktionen von rollenbasierten Arbeitsplätzen
Seite 382 von 388
 Vilsmeier
Eurofighter
Seite 383 von 388
 Vilsmeier

PLM - TUM

Transcription

Similar documents

ANSYS Parametric Design Language Das starke Herz

Masterkurs Kostenstellenrechnung mit SAP®

PDF der Sonderpublikation

Prospekt Process Manager_db.cdr

Rückblick auf die Business Solutions Konferenz 2014