DE102014200384A1

DE102014200384A1 - Verfahren zum Herstellen von komplexen Produkten, insbesondere von Kraftfahrzeugen

Info

Publication number: DE102014200384A1
Application number: DE102014200384.9A
Authority: DE
Inventors: Martin Witzel
Original assignee: Volkswagen AG
Current assignee: Volkswagen AG
Priority date: 2013-06-03
Filing date: 2014-01-13
Publication date: 2014-12-04
Also published as: US10181006B2; US20160117438A1; WO2014195036A1; KR20160014011A; CN105190625B; KR101755146B1; CN105190625A; EP3005181A1

Abstract

Die Erfindung betrifft ein Verfahren zum Herstellen eines komplexen Produktes, insbesondere eines Kraftfahrzeugs, wobei ein Bauteil für das Produkt konstruiert wird. Es werden eine Datei mit einer dreidimensionalen Darstellung des Bauteils in einem ersten Datenformat für ein erstes Programm sowie eine Datei mit einer Metainformation der dreidimensionalen Darstellung des Bauteils in einem elektronisch durchsuchbaren Datenformat für ein zweites Programm erzeugt. Zudem wird die Datei mit der dreidimensionalen Darstellung des Bauteils in dem ersten Datenformat in die Datei im zweiten Datenformat eingebettet. Es ist ein drittes Programm zur Kommunikation zwischen dem ersten und dem zweiten Programm vorgesehen.

Description

Die Erfindung betrifft ein Verfahren zum Herstellen von komplexen Produkten, insbesondere von Kraftfahrzeugen. Dabei wird ein Bauteil des komplexen Produktes gemäß einer dreidimensionalen Darstellung des Bauteils gefertigt und das komplexe Produkt unter Verwendung des Bauteils hergestellt. Die Erfindung betrifft zudem ein Verfahren zum Betrieb eines Computers.
Die EP 1 008 112 B1 offenbart ein Verfahren zum Modellieren dreidimensionaler Objekte in einer interaktiven Rechnerumgebung, wobei eine zweidimensionale Darstellung einer dreidimensionalen Szene angezeigt wird, und wobei die zweidimensionale Darstellung eine Bildebene definiert. Es wird eine Zuordnung zwischen einem Satz von Steuerelementen eines modellierten dreidimensionalen Objekts und eines entsprechendes Satzes von zu der Szene gehörenden Positionen in der Abhängigkeit von einer Benutzereingabe gebildet, wobei die Positionen Soll-Positionen in der Szene für die Steuerelemente des modellierten dreidimensionalen Objektes darstellen. Zudem wird eine Orientierung einer Position des modellierten dreidimensionalen Objekts im dreidimensionalen Raum auf Grundlage dieser Zuordnung bestimmt, und es werden Elemente des modellierten dreidimensionalen Objektes mit der so bestimmten Orientierung und Position auf die Bildebene projiziert.
Die US 6 268 846 B1 offenbart ein computerimplementiertes Verfahren zum Generieren einer neuen Ansicht einer dreidimensionalen Szene durch Empfang dreier oder mehr Bilder, die drei oder mehr verschiedene Blickrichtungen auf eine Ebene darstellen. Die US 2006/0256136 A1 offenbart ein Verfahren zur Erzeugung eines zusammengesetzten Bildes von sowohl zweidimensionalen Bildschichten als auch von dreidimensionalen Bildschichten. Dabei sind die Bildschichten in Sequenzen angeordnet. Die US 7 453 459 B2 offenbart ein Verfahren zur Erzeugung dreidimensionaler Bilder. Dabei werden dreidimensionale Objekte zu einer Szene zusammengefügt.
Es ist Aufgabe der Erfindung, einen Fertigungsprozess eines komplexen Produktes, insbesondere einen Fertigungsprozess für Kraftfahrzeuge zu verbessern bzw. die Kosten eines solchen Fertigungsprozesses zu senken. Es ist weiterhin wünschenswert, einen Fertigungsprozess, insbesondere einen Fertigungsprozess für Kraftfahrzeuge zu schaffen, in dem der Anteil an Papierzeichnungen verringert wird bzw. der gänzlich ohne Papierzeichnung auskommt. Es ist zudem wünschenswert, eine papierlose Langzeitarchivierung von Zeichnungen eines Fertigungsprozesses, insbesondere eines Fertigungsprozesses für Kraftfahrzeuge zu ermöglichen bzw. zu schaffen.
Vorgenannte Aufgabe wird durch ein Verfahren zum Herstellen eines komplexen Produktes, insbesondere eines Kraftfahrzeuges mit folgenden Schritten gelöst:

– Konstruieren eines Bauteils für das Produkt,
– Speichern (bzw. Erzeugen einer Datei mit) einer dreidimensionalen Darstellung des Bauteils in einem ersten Datenformat für ein erstes Programm,
– Speichern (bzw. Erzeugen zumindest einer Datei mit) einer Metainformation der dreidimensionalen Darstellung des Bauteils in einem elektronisch durchsuchbaren zweiten Datenformat für ein zweites Programm,
– insbesondere Einbetten der Datei mit der dreidimensionalen Darstellung des Bauteils in dem ersten Datenformat in die Datei im zweiten Datenformat,
– Öffnen der Datei im zweiten Datenformat mittels des zweiten Programms zur Darstellung der Metainformation,
– (automatisches) Öffnen der Datei im ersten Datenformat mittels des ersten Programms zur dreidimensionalen Darstellung des Bauteils,
– (automatisches) Starten eines dritten Programms zum (insbesondere asynchronen und/oder bidirektionalen) Datenaustausch zwischen dem ersten Programm und dem zweiten Programm (zur Zuordnung der Metainformation zu (zumindest einer Position in) der dreidimensionalen Darstellung des Bauteils),
– Fertigen eines Bauteils gemäß der dreidimensionalen Darstellung des Bauteils,
– Herstellen des Kraftfahrzeuges unter Verwendung des Bauteils.

Metainformation im Sinne der Erfindung ist insbesondere eine Zusatzinformation zu einer technischen Zeichnung (insbesondere jedoch nicht Maßangaben, Toleranzangaben, Angaben zur Oberflächenbeschaffenheit und/oder Übergangs- bzw. Krümmungsradien) bzw. kann eine solche Information umfassen. Eine Metainformation im Sinne der Erfindung kann eine textuelle und/oder eine grafische Information sein. Metainformationen im Sinne der Erfindung können Teilelisten, (Teil)stammdaten, Toleranzen, Teilekennzeichnungen, Referenzpunkte, Verbindungselemente, Änderungen und/oder Anmerkungen sein bzw. solche Informationen umfassen. Metainformation im Sinne der Erfindung kann die/eine Information über zu verwendende bzw. einzuhaltende Normen umfassen. Metainformation im Sinne der Erfindung kann den Informationsgehalt eines Änderungsfeldes in einer technischen Zeichnung umfassen. Metainformation im Sinne der Erfindung kann die Information innerhalb eines Schriftfeldes einer technischen Zeichnung umfassen. Metainformation im Sinne der Erfindung kann Farbrelevanz umfassen. Metainformation im Sinne der Erfindung kann einen Hyperlink, insbesondere einen Hyperlink auf eine andere Datei umfassen. Eine andere Datei in diesem Sinne ist insbesondere eine Datei in einem anderen als dem ersten Datenformat.
Eine dreidimensionale Darstellung eines Bauteils im Sinne der Erfindung umfasst insbesondere Maßangaben und/oder Toleranzangaben. Eine dreidimensionale Darstellung eines Bauteils im Sinne der Erfindung umfasst insbesondere Angaben zur Oberflächenbeschaffenheit und zu Übergangs- bzw. Krümmungsradien. Eine dreidimensionale Darstellung eines Bauteils im Sinne der Erfindung ist insbesondere mehrfarbig.
Ein drittes Programm im Sinne der Erfindung ist insbesondere als Hintergrundprozess implementiert.
In vorteilhafter Ausgestaltung der Erfindung erfolgt die dreidimensionale Darstellung des Bauteils in einem ersten Fenster, wobei die Darstellung der Metainformation in zumindest einem zweiten Fenster erfolgt.
Vorgenannte Aufgabe wird zudem durch ein Verfahren zum Betrieb eines Computers mit folgenden Schritten gelöst:

– Bereitstellen einer Datei mit einer dreidimensionalen Darstellung eines Bauteils (insbesondere für ein Kraftfahrzeug) in einem ersten Datenformat für ein erstes Programm sowie Bereitstellen zumindest einer Datei mit einer Metainformation zur dreidimensionalen Darstellung des Bauteils in einem elektronisch durchsuchbaren zweiten Datenformat für ein zweites Programm, wobei die Datei mit der dreidimensionalen Darstellung des Bauteils in dem ersten Datenformat in die Datei im zweiten Datenformat eingebettet ist,
– Öffnen der Datei im zweiten Datenformat mittels des zweiten Programms,
– (automatisches) Öffnen der Datei im ersten Datenformat mittels des ersten Programms zur dreidimensionalen Darstellung des Bauteils, insbesondere in einem ersten Fenster,
– (automatisches) Starten eines dritten Programms zum (insbesondere asynchronen und/oder bidirektionalen) Datenaustausch zwischen dem ersten Programm und dem zweiten Programm (zur Zuordnung der Metainformation zu (zumindest einer Position in) der dreidimensionalen Darstellung des Bauteils),
– Darstellung der Metainformation, insbesondere in einem zweiten Fenster.

In weiterhin vorteilhafter Ausgestaltung der Erfindung sind das erste und das zweite Fenster gleichzeitig geöffnet. In weiterhin vorteilhafter Ausgestaltung der Erfindung ist das erste Dateiformat .jt. In weiterhin vorteilhafter Ausgestaltung der Erfindung ist das zweite Dateiformat .pdf. Jt ist ein proprietäres Datenformat für 3D-Daten und wird als kompaktes, leicht anzuzeigendes und inhaltsreiches Datenformat angesehen, das auch Objekte- und Metadaten unterstützt. In weiterhin vorteilhafter Ausgestaltung der Erfindung umfasst das zweite Programm ein Plugin zur Kommunikation mit dem dritten Programm.
In weiterhin vorteilhafter Ausgestaltung der Erfindung ist das erste Programm und/oder das zweite Programm ein Viewer. Eine Viewer im Sinne der Erfindung ist insbesondere ein Programm, mittels dessen der Inhalt des mittels des Viewers dargestellten Informationsgehalts nicht veränderbar ist.
Es ist insbesondere vorgesehen, dass die Datei mit der dreidimensionalen Darstellung des Bauteils mittels des ersten Programms nicht veränderbar ist. Es ist insbesondere vorgesehen, dass die Metainformation mittels des zweiten Programms nicht veränderbar ist.
In weiterhin vorteilhafter Ausgestaltung der Erfindung umfasst die Datei mit der Metainformation zumindest einen Hyperlink.
In weiterhin vorteilhafter Ausgestaltung der Erfindung ist in die zweite Datei zusätzlich eine PDF-Datei, eine XML-Datei und/oder eine HTML-Datei eingebettet. In weiterhin vorteilhafter Ausgestaltung der Erfindung ist in die zweite Datei keine WORD-Datei eingebettet. In weiterhin vorteilhafter Ausgestaltung der Erfindung ist in die zweite Datei keine PowerPoint-Datei eingebettet. In weiterhin vorteilhafter Ausgestaltung der Erfindung ist in die zweite Datei keine Excel-Datei eingebettet.
Ein komplexes Produkt im Sinne der Erfindung ist insbesondere ein Produkt, dass aus einer Mehrzahl von einzelnen Bauteilen besteht. Kraftfahrzeug im Sinne der Erfindung ist insbesondere ein individuell im Straßenverkehr benutzbares Landfahrzeug. Kraftfahrzeuge im Sinne der Erfindung sind insbesondere nicht auf Landfahrzeuge mit Verbrennungsmotor beschränkt.
Weitere Vorteile und Einzelheiten ergeben sich aus der nachfolgenden Beschreibung von Ausführungsbeispielen. Dabei zeigen:
1 ein Ausführungsbeispiel eines Verfahrens zur Herstellung eines Kraftfahrzeugs,
2 ein Ausführungsbeispiel eines Systems zur Implementierung des Verfahrens gemäß 1,
3 ein Ausführungsbeispiel einer Verknüpfung der Informationen im Dokument mit einer 3D-Geometrie,
4 ein Ausführungsbeispiel einer JTBridge,
5 ein Ausführungsbeispiel einer Architektur und Kommunikationswege, Protokolle und Dateiablagen,
6 ein Ausführungsbeispiel eines Aufbaus eines 3D-Dokumentes (PDF/A-3a),
7 ein Ausführungsbeispiel einer JT-Referenz im Dokument,
8 ein Ausführungsbeispiel für Vertrauen von Dokumentenlinks in Adobe Acrobat/Adobe Reader,
9 ein Ausführungsbeispiel einer Organisation von PMI-Informationen,
10 ein Ausführungsbeispiel einer PMI-Struktur im JT-Model. für eine Baugruppe und
11 ein Ausführungsbeispiel einer Gesamt-Schnittstellenarchitektur.
1 zeigt ein Verfahren zur Herstellung eines Kraftfahrzeugs, wobei in einem Schritt 11 ein Bauteil für das Kraftfahrzeug konstruiert wird. Es folgt ein Schritt 12, in dem eine Datei mit einer dreidimensionalen Darstellung des Bauteils in einem ersten Datenformat für ein erstes Programm erzeugt wird. In einem folgenden Schritt 13 wird eine Datei mit einer Metainformation der dreidimensionalen Darstellung des Bauteils in einem elektronisch durchsuchbaren zweiten Datenformat für ein zweites Programm erzeugt. In diese Datei wird in einem Schritt 14 die Datei mit der dreidimensionalen Darstellung des Bauteils (im ersten Datenformat) eingebettet (bzw. angehängt).
Es folgt in einem Schritt 15 das Bereitstellen der Datei im zweiten Datenformat mit der eingebetteten Datei mit der dreidimensionalen Darstellung des Bauteils (im ersten Datenformat) und das Öffnen der Datei im zweiten Datenformat mittels eines zweiten Programms sowie in einem Schritt 16 das, insbesondere automatische, Öffnen der Datei im ersten Datenformat mittels des ersten Programms zur dreidimensionalen Darstellung des Bauteils. Zudem wird in einem Schritt 17 als Hintergrundprozess ein drittes Programm zum asynchronen und bidirektionalen Datenaustausch zwischen dem ersten Programm und dem zweiten Programm gestartet. Mittels des ersten Programms wird das Bauteil in einer dreidimensionalen Darstellung in einem ersten Fenster auf einem Bildschirm dargestellt. Mittels des zweiten Programms wird die Metainformation in einem oder mehreren weiteren Fenstern mittels des Displays dargestellt.
Anschließend wird das Bauteil in einem Schritt 18 gemäß der dreidimensionalen Darstellung des Bauteils gefertigt und das Kraftfahrzeug in einem Schritt 19 unter Verwendung dieses Bauteils hergestellt.
2 zeigt ein System zur Implementierung des Verfahrens gemäß 1. Dabei bezeichnet Bezugszeichen 20 eine Fertigungsstraße zum Fertigen eines Kraftfahrzeugs oder eines Teils eines Kraftfahrzeugs und Bezugszeichen 31 eine Entwicklungsumgebung zur Konstruktion und Entwicklung von Bauteilen für ein Kraftfahrzeug. In dieser Entwicklungsumgebung 31 wird die Datei im zweiten Datenformat mit der eingebetteten Datei im ersten Datenformat erzeugt und in einem Speichermedium 32 abgelegt und dadurch der Fertigungsumgebung 20 bzw. ihrer IT bereitgestellt. In der Fertigungsumgebung 20 ist ein Computer 25 mit dem ersten Programm 21, dem zweiten Programm 22 und dem dritten Programm 23 vorgesehen. Der Computer 25 steuert ein Display 27 zur Darstellung eines Fensters 28 zur dreidimensionalen Darstellung des Bauteils sowie ein Fenster 29 zur Darstellung der Metainformation an. Das Display 27 kann einen oder mehrere Monitore umfassen.
Im Folgenden wird das Verfahren gemäß 1 beispielhaft erläutert, wobei das erste Datenformat .jt und das zweite Datenformat .pdf ist. Dabei ist das erste Programm JP2Go oder VisMockup und das zweite Programm Adobe Reader oder Adobe Acrobat, Letztere jeweils ergänzt um ein Plugin. Das dritte Programm wird nachfolgend als JTBridge bezeichnet.
Die primäre Funktion der JTBridge ist es, eine bidirektionale Verknüpfung zwischen einem JT-Modell (dreidimensionale Darstellung des Bauteils im .jt-Format) und Metainformatiom, wie z. B. Stammdaten, in einer PDF/A-Datei herzustellen. Das JT-Modell ist in die PDF/A-Datei eingebettet und wird zusammen mit diesem nachfolgend als 3D-Dokument bezeichnet. Nach Abstimmung und technischen Randbedingungen sind die Daten beim Viewing in der dem jeweiligen Dateiformat zugeordneten Anwendung geöffnet. Damit können die formatspezifischen Funktionen der Viewer ausgenutzt werden. 3 zeigt eine solche Sitzung, in der das zu den Stammdaten gehörige 3D-Modell in einem parallelen 3D-Viewer geöffnet ist. Der Benutzer kann durch eine einfache Interaktion die zugeordneten 2D/3D-Informationen abrufen.
Das JT-Modell und die PDF-Datei sind in dem Viewer parallel geöffnet, die den Dateitypen über das Betriebssystem zugeordnet sind. Diese werden eigenständig und ohne Verbindung zueinander ausgeführt. In den Dateien ist aber das Wissen um die Verknüpfung der 2D-Daten und 3D-Informationen explizit hinterlegt oder inhärent vorhanden. Zwischen den Anwendungen wird – wie in 4 dargestellt – die JTBridge gelegt, der bekannt ist, wie die entsprechenden Informationen zu finden sind.
Es ist vorgesehen, dass keine expliziten Suchfunktionen in den Viewer über ihre Benutzeroberfläche, wie z. B. Menüs, Toolbars und Kontextmenüs integriert sind. Es ist vielmehr vorgesehen, die Verlinkung durch Links zu beschreiben, die alle nötigen Informationen in ihrer URI enthalten. Das dient dazu, den Aufruf des Links weitestgehend unabhängig zu machen von dem beinhaltenden Dokument bzw. des Viewers und somit HTML-, PDF- und Office-Formate gleichartig behandelt werden können.
Nachfolgend werden das Kontextdiagramm, das Datenmodell, das Funktionsmodell und das Schnittstellenkonzept der beispielhaften Implementierung des Verfahrens bzw. ein Teil des Verfahrens gemäß 1 beschrieben:
1. Kontextdiagramm
Das 3D-Dokument (Sammlung von Teildokumenten) ist genau 1-mal im PDF-Viewer geöffnet. In dem 3D-Dokument ist nach Vereinbarung genau ein JT-Modell enthalten, welches in einem JTViewer geöffnet sein kann, aber nicht muss. Diese beiden Komponenten werden über eine Kopplung miteinander in Beziehung gesetzt. Die Realisierung erfolgt über eine JT-PDF-Brücke, die außerhalb der beiden Standardkomponenten die Kommunikation übernimmt; und über verbindungslose, nicht blockierende Nachrichten Anweisungen an den jeweils anderen Viewer weitergibt. Die Brücke JTBridge ist als Hintergrundprozess implementiert, der bei Bearbeitung von 3D-Dokumenten zur Verfügung steht, und anschließend ohne Benutzerinteraktion wieder beendet wird. Die Brücke übernimmt die Kommunikation zwischen genau einer Instanz eines JT-Viewers, und n Adobe Reader/Acrobat-Fenstern, die jeweils mit einer PDF-Datei verbunden sind.
Der Zugriff auf das JT-Modell erfolgt aus der Brücke heraus über die VisAutomation(COM-)-Schnittstelle des JT2Go/VisMockup-Viewers, die zur Standardinstallation zählt. Der Zugriff auf das 3D-Dokument kann nur erfolgen, wenn im Adobe Reader ein Plugin integriert wird, das spezielle Suchmechanismen umsetzt und die Kommunikation nach außen behandelt. Vorgesehen ist Windows Inter Process Communication (IPC) in Form von DDE (Dynamic Data Exchange). Die ausgetauschten Daten sind öffentlicher Natur, es gibt keinen schätzenswerten Anteil darin. Daher muss die Kommunikation nicht verschlüsselt werden. Die Bestandteile in den Nachrichten sind jedoch UTF-8-codiert. Aufgrund des Zeichnungscharakters des 3D-Dokuments werden in den beiden Viewern (JT + PDF) nur nicht-modifizierende Operationen, wie zum Beispiel Navigation und Filterung, durchgeführt, obwohl auch interaktive 3D-Formulare denkbar sind.
In 5 sind die Kommunikationswege, Protokolle und Dateiablagen dargestellt. Das lokale Dateisystem wird derzeit genutzt, um die JT-Datei aus dem 3D-Dokument (Sammlung von PDF und genau 1 JT-Datei als Archiv) zu extrahieren. Hierbei wird nur der benutzerspezifische Cache des Adobe Acrobat genutzt (im Pfad des Benutzers). Sobald auf die AutoOpen-Funktion verzichtet wird, wird der Cache nicht benötigt.
2. Datenmodell
Nachfolgend werden das 3D-Dokument, der Aufbau und die Auflösung der Hyperlinks sowie die Verlinkung der Texte mit JT-Modell beschrieben:
2.1 3D-Dokument
Ein PDF wird zum 3D-Dokument (JT + PDF/A-3a), sobald ein JT-Modell in eine PDF-Datei in Form eines Attachments eingefügt wird (d. h. eingebettet wird in der Terminologie der Ansprüche). Das 3D-Dokument sowie seine Bestandteile müssen nach Zielsetzung des Projektes ohne Einschränkung langzeitarchivierungsfähig sein. Daher wird der PDF-Container als PDF/A-3 ausgeführt und leistet eine Bündelung von Teildokumenten zu einem einzigen LZA-Dokument, welches auch Nicht-PDF/A-Dateien einschließt. Ein PDF/A-1-Dokument vermeidet dynamische Inhalte, um eine zeitliche unbefristete und originalgetreue Wiedergabe der enthaltenen Informationen sicherzustellen. Damit können folgende Elemente der PDF-Technik nicht genutzt werden: PDF/A-3:

– aktive Inhalte
– Adobe Flash-Komponenten (Actionscript)
– Javascripting
– Video oder Sound
– XFA-Formulartechnik (statisch oder dynamisch)
– interaktive modifizierende Elemente (Buttons, Checkboxes, ...)
– Modifikation des Dokumenteninhaltes

Damit stellt sich das 3D-Dokument in seinem Aufbau grundsätzlich wie in 6 gezeigt dar. In dem 3D-Dokument sind verschiedenartige Anteile enthalten. Die reinen Text- und Tabelleninformationen werden abgebildet innerhalb der (Container-)PDF-Datei. Dazu zählen alle Stamm-Informationen, die keinen Geometriebezug zu einem Objekt innerhalb der JT-Datei besitzen. Davon unterscheiden sich die Textinformationen, die auf ein 3D-Objekt oder eine PMI bezogen sind. Diese bauen eine eindeutige Referenz auf einen Szenengraphknoten des JT-Modells auf. Dabei kann die Referenzierungslogik nicht in die PDF/A-Datei integriert werden, da nach PDF/A-Standard keine Skripte oder aktiven Inhalte erlaubt sind. Auch können dann keine Rückreferenzierungen aus dem 3D-Modell an die Textinformation durchgeführt werden, ohne auf die Besonderheiten an die jeweiligen Viewer-Implementierungen Rücksicht zu nehmen. In dem 3D-Dokument können auch Nicht-PDF/A 2D-Dateien, wie Excel-, PowerPoint-, Word- und HTML-Dateien enthalten sein, die ebenfalls 3D-Referenzen führen können. Eine (dort erlaubte) Implementierung via Skriptsprachen ist ebenfalls stark abhängig von der jeweiligen Originalapplikation und ist daher nicht vorgesehen. Stattdessen werden die zu verknüpfenden 2D/3D-Informationen mit Hyperlinks – wie in 7 dargestellt – eindeutig beschrieben. Das erlaubt eine universelle Verwendung innerhalb der PDF/A-3-Hauptdatei, den angehängten PDF-Dateien sowie den ebenfalls beigefügten Drittformaten wie HTML-, Word-, PowerPoint-, Excel-Dateien. Als Voraussetzung muss das JT-Modell referenzierbar sein. Dazu müssen die Scenengraph-Knoten eindeutig benannt oder durch ein Metadaten-Attribut eindeutig gekennzeichnet sein.
2.2 Aufbau und Auflösung der Hyperlinks
Ein Hyperlink innerhalb des 3D-Dokuments identifiziert ein 3D-Objekt, eine spezifische Ansicht, eine PMI oder eine Aktion, die am 3D-Modell durchgeführt werden soll. Da diese Verknüpfungsmethode durch kein Standard-URI-Schema abgebildet wird, wird ein eigenes URI-Schema definiert, das alle JT-Hyperlinks im 3D-Dokument festlegt: vwg-jtbridge. Um genügend Raum für die fachliche Beschreibung des Links zu geben, wird im schema-spezifischen Teil der URL ein projektrelevanter Anteil integriert. Diese Information steht anstelle des host-Anteils einer http(s)-URL. Die betrachteten Hostanwendungen (Internet Explorer, Firefox, Adobe Acrobat, ...) implementieren jeweils einen Vertrauensmechanismus zur Verfolgung von Links. Statt dem Protokoll systemweit zu vertrauen, wird dem host-Anteil vertraut (vgl. 8). Damit lautet die Basis-URL eines JT-Hyperlinks für beispielhafte Anwendungsräume:

• jtbridge://3dzp 3D-Dokumente für zeichnungslose Prozesse

• jtbridge://fubit funktionale Bohrungsinformationen (Prototyp)

• jtbridge://{Projekt} allgemeine Darstellung
An die Basis-URL werden die Informationen zur Identifikation der JT-Objekte als Parameter angehängt. Für eine Referenz auf eine PMI sind erforderlich:

• Identifikation des JT-Modells jt = [Wert des JT-File Attribute am Root Scenegraph-Knoten]
• Identifikation einer oder mehrerer PMI, getrennt durch Semikolon id = [PMI Name1; [PMI Name2]; [PMI NameN]
• Identifikation der PMI-Ansicht mv = [PMI Modelview Name]

Nach der Beschreibung des 3D-Objektes wird noch die Aktion definiert, die bei Klicken auf den Link ausgeführt werden soll. Für das 3D-Dokument sind bisher zwei Arten von Aktionen definiert:

• Zoom auf die PMI-Modellansicht und Selektion der PMI act = GOTO_PMI_AND_MODELVIEW
• Anzeigen einer PMI-Modellansicht des JT-Modells act = GOTO_MODELVIEW

Die Parameter werden durch ein Ampersand „&” voneinander getrennt. Es ergibt sich für einen vollständigen JT-Link damit folgende Notation:
jtbridge://{PROJEKT}/jt={MODELL}&id={PMI}&mv={ANSICHT}&act={AKTION}
2.3 Verlinkung der Texte mit dem JT-Modell
Es werden jeweils beiden technischen Teilen (JT-Modell und PDF-Dokument) innerhalb des 3D-Dokumentes so viel Informationen mitgegeben, dass in dem jeweils anderen Viewer die zugeordnete Information eindeutig identifizierbar ist. Zunächst wird das JT-Modell innerhalb der JT-Viewer-Sitzung eindeutig gekennzeichnet sein. Eine Zuweisung über den Dateinamen reicht hier nicht aus, dieser ist im Lebenslauf der Datei zu flüchtig. Bei der Erstellung der JT-Datei jedoch wird innerhalb des Konvertierungsprozesses mit den Siemens-JT-Konvertern der JT-Scenegraph (SG) mit zahlreichen Metainformationen dekoriert, die auch eine eindeutige Identifizierung innerhalb einer JT-Viewer Sitzung zulassen. Am JT-Rootnode wird der Name der vom Konverter ursprünglich erzeugten JT-Datei als ein solches Metadatenattribut gesetzt. Zu der Abhängigkeit der Informationen bzgl. des Szenegraphen und Abbildung im JT-Modell sei auf die JT-Spezifikation verwiesen. Das verwendungsfähige Attribut am Rootnode des SG des JT-Modells lautet:
Name: Jt File Name:: Typ: UTF-8
Befällt ist das Attribut mit dem vollständigen Dateinamen einschließlich der Endung .jt.
Die Produkte der Siemens-JT-Viewer-Familie sind realisiert als MDI(Multiple Document Interface)-Applikationen. Damit kann parallel eine Vielzahl von JT-Modellen in einer einzelnen JT-Viewer-Sitzung geöffnet sein. Der Suchalgorithmus muss die geöffneten JT-Modelle in der Sitzung durchlaufen, und am jeweils Knoten des Szenengraphen nach der ursprünglichen Benennung der JT-Datei schauen, die dort als Metadaten-Element angefügt ist. In der Konsequenz heißt das aber auch, dass diese Information zusätzlich außerhalb des JT-Modells gehalten werden muss, sollen die Geometrie und PMI-Elemente in einem Dokument referenziert werden.

Auf Basis des Root-Knotens kann gezielt nach Informationen innerhalb des Modells gesucht werden. Dazu kann wiederum nach der Benennung des Knotens genutzt, oder aber die Identifikation in den Metadaten gesucht werden. Nach Vorgabe der 3DZP CAD FTA-Methodik werden Ankerpunkte zu den Geometrien über FTA-Annotationen gesetzt. Diese Annotationen werden in das JT-Modell als PMI-Notes übertragen, die n PMI-Modelviews zugeordnet sein können. Die Benennung der FTA-Annotationen und damit auch der PMI-Notes erfolgt aus den Anforderungen des jeweiligen fachlichen Bereichs. Zu den bisher bekannten und berücksichtigten Identifikatoren zählen:

CHA	[Index]	für Änderungseinträge am Modell
TXT	[Index]	Freitexte am Modell
PMK	[Index]	Teilekennzeichnung
RPS	[fachliche ID]	Referenzpunktsystem
LTA	[fachliche ID]	Lochtabellen
HAP, RB	[fachliche ID]	Hauptaufnahmepunkte
VEMText, VTA	[fachliche ID]	Verbindungstechnik, Schweißgruppen
[fachliche ID]_Label		Flächen- und Bohrungsinformationen

Die PMI-Informationen sollen weiterhin den fachlichen oder technischen Kontexten zuordenbar sein. Hinsichtlich der Datenstrukturen der PMI-Informationen existieren keine Unterschiede zwischen Bemaßungsannotationen, Freitexten oder auch Modellansichten (vgl. 9).
Ein Bauteil oder eine Baugruppe verfügt über eine Liste von gleichwertigen PMI-Elementen. Die Elemente erhalten ihre Typisierung ausschließlich durch ein internes Flag, zu den in 3DZP genutzten PMI-Informationen gehören:

• PMI_ÄTYPE_MODEL_VIEW
• PMI_TYPE_NOTE

Vorteilhaft ausgenutzt werden kann auch die Eigenschaft von PMI-Elementen, sich gegenseitig zu referenzieren. Darüber wird auch die Relation von PMI-Notes zu den PMI-Modelviews festgelegt. Eine Annotation kann beliebig vielen Ansichten zugeordnet sein. Daraus wird ersichtlich, dass bei einer zu implementierenden Suche nach PMI-Informationen eine Priorisierung oder Suche im Kontext in den Modelviews stattfinden muss. Zielsetzung ist daher, die genaue Information im Dokument zu hinterlegen. 10 zeigt das Verhältnis von PMI-Notes zur CAD-Produktstruktur im JT-Viewer.
Zusammengefasst sind also folgende Informationen relevant:

– Name der ursprünglichen JT-Datei als Metadaten im jeweiligen Szenengraphen-Knoten des konvertierten Bauteils und Baugruppe als Attribut JT File-Name
– Eindeutige Benennungsvorschrift für PMI-Notes
– Eindeutige Erfassung der Modelviews im Dokument
– Eindeutige Erfassung der PMI-Notes

3.3 Funktionsmodell
Im Folgenden werden die Funktionen des Systems vorgestellt. Hierzu gehören die durch den Nutzer hervorgerufenen Funktionen. In diesem Abschnitt werden beschrieben:

• Starten/Beenden des iReader-Plugins
• Öffnen des 3D-Dokumentes und Initialisierung des jtBridge-Prozesses
• Suche von PMI-Elementen im JT-Viewer
• Suche von Textstellen im PDF/A-3-Dokument
• AutoOpen des 3D-Anteiles
• Drucken der 3D-Anteile und der PDF-Teilinformationen
• Applikationseinstellungen

Dies sind die Funktionen, die von dem Benutzer als Aktivität des iReader-Plugins wahrgenommen werden. Andere funktionale Bestandteile und interne Mechanismen werden im Kapitel über den Modulaufbau dargestellt.
4 Schnittstellenkonzept und -architektur
Die Gesamtschnittstellenarchitektur der Implementierung ist in 11 dargestellt und nachfolgend näher beschrieben:
4.1 Application Protocol vwg-jtbridge
Das URI Schema vwg-jtbridge wird als Anwendungsprotokoll in der Windows Registry unter HKEY_CLASSES_ROOT (HKCR) registriert. Damit steht es systemweit zur Verfügung, und es kann nur mit Administratorrechten modifiziert werden. Dem Protokoll wird die Applikation JTBridge zugeordnet, die gestartet wird, sobald eine jtbridge URL in einer Anwendung aufgerufen wird. Die Weitergabe der URL an die JTBridge erfolgt durch die Windows Shell. Statt die URL aber als Kommandozeilen-Parameter zu übergeben, werden diese über eine DDE-Konversation an die JTBridge weitergereicht. DDE ist zur Datenübergabe geeignet, da die URL einen diskontinuierlichen Datenstrom darstellt und auf allen Windows-Systemen gleichermaßen verfügbar ist. Das Protokoll ist verhältnismäßig einfach, und es lassen sich über den inhärenten Topic-Subscription-Ansatz mehrere Applikationen gleichzeitig ansteuern. Die Übertragungsrate 1000/Sekunde ist ausreichend für alle geforderten Funktionen. Dabei ist es unerheblich, ob es sich um ein 32-bit oder 64-bit Windows handelt.
4.2 JTBridge
Die JTBridge wird bei Aufruf des Protokolls jtbridge gestartet. Sie hat die Aufgabe, Informationen zwischen den Viewern auszutauschen bzw. die gewünschten Viewing-Operationen ausführen. Sie implementiert als Einfangspunkt für Daten einen DDE-Server, der die Nachrichten der Windows Shell über den DDE-Anwendungsnamen DdeServiceBridge und den Topic 1337 entgegennimmt und verarbeitet. Wichtig ist vor allem, die Verarbeitung von fehlerhaft formulierten URLs zu verhindern, d. h. überlange URLs, die Schadcode beinhalten, zu ignorieren. Es ist Aufgabe der Bridge, die übergebenen URLs auf ihre korrekte Formulierung zu prüfen und auf die richtigen Funktionen zu mappen.
Die URL wird durch die JTBridge interpretiert, indem die Parameter (Projekt, Daten und Funktion) aus der URL extrahiert werden und an die 3D-viewerspezifischen Methoden der JTBridge weitergereicht werden. Unterstützt werden derzeit alle JT-Viewer, die auf den Siemens JT PLM Vis Components beruhen (JT2Go, VisBase, ... VisMockup). Falls weitere Formate bzw. Viewer berücksichtigt werden sollen, müssen die entsprechenden Connectoren verfasst werden.
Eine Verlinkung von 3D-Informationen in Richtung 2D kann ebenfalls über die Formulierung von Hyperlinks geschehen. Hier sind aber alle Informationen inhärent im Modell enthalten, und werden über eine Viewer-eigene Schnittstelle abgebildet. Über die VisAutomation(COM-)Schnittstelle registriert sich die JTBridge für applikationsspezifische Events, wie Öffnen und Schließen eines JT-Modells oder des Viewers, sowie für Events am Modell, die durch den Benutzer ausgelöst werden, wie zum Beispiel die Selektion einer PMI-Note.
Sobald eine Suchfunktion oder Operation auf dem geöffneten PDF-Anteil eines 3D-Dokumentes in einem Adobe Acrobat/Reader durchgeführt werden soll, wird das Ereignis an das 3DZP iReader-Plugin via DDE weitergeben. Dabei müssen so viele Informationen enthalten sein, dass eine eindeutige Identifikation der Textstelle (Link) im PDF möglich ist.
4.3 iReader Plugin für Adobe PDF-Viewer
Die Standardanwendungen zur Anzeige der 3D-Dokumente sind unter anderem Adobe Acrobat Standard sowie Adobe Reader. Um eigene Funktionen in diese Viewer zu integrieren, die über eine Schnittstelle von außen aufgerufen werden, kann vorteilhaft die DDE-Methode für eine Kopplung mit der JTBridge verwendet werden. Dazu ist ein Plugin ,iReader' vorgesehen. Es implementiert einen DDEServer mit Namen DdeServiceBridge und dem Topic 1337, über die DDE-Nachrichten aus der JTBridge empfangen werden. Die Nachricht hat dann eine analoge Syntax zur Link-Definition.
Wenn nach Auswahl einer PMI im JT-Modell durch die JTBridge eine Nachricht mit den folgenden Anteilen an das iReader-Plugin gesendet wird, dann identifiziert dieses unter allen geöffneten PDF Dateien das zugeordnete 3D Dokument und sucht darin nach dem Hyperlink mit den folgenden Eigenschaften:
Beispiel:

Jt = [Modellname].jt
id = [PMI Id]
mv = [Modelview]
act = GOTO_MODELVIEW

Die Zuordnung des 3D-Dokuments (PDF) zu einem geöffneten JT-Modell erfolgt implizit. Das richtige 3D-Dokument wird dadurch identifiziert, dass in allen geöffneten PDF-Dateien nach FileAnnotations gesucht wird, die eine JT-Datei referenzieren. Sofern ihr Name dem JT-Parameter aus der DDE-Nachricht entspricht, durchsucht das iReader-Plugin das betreffende PDF nach vwg-jtbridge-Hyperlinks, die als Parameter die id sowie den mv aus der DDE-Nachricht enthalten. Das Plugin bewegt dann die Ansicht zu der Textstelle, an der der Link auftritt.
Die Familie der Adobe-PDF-Viewer implementiert die Behandlung von Weblinks derart, dass diese bei Klick immer weitergegeben werden an den Standardbrowser des Systems, z. B. Internet Explorer, der dann zeitgleich geöffnet wird; und nicht der über das application protocol zugeordneten Anwendung (JTBridge). Obwohl die vwg-jtbridge URL dann korrekt an die JTBridge weitergereicht wird und die gewünschte 3D-Information im JT-Viewer sichtbar wird, ist dennoch immer das ,leere' Browserfenster zu sehen. Um dieses zu unterdrücken, kann ein eigener Weblink-Treiber für Adobe Acrobat und Adobe Reader vorgesehen werden, der die Links an die JTBridge direkt weitergibt, alle nicht vwg-jtbridge-Links aber weiterhin im Standard-Web-Browser öffnet.
Eine weitere Besonderheit bei den Adobe-Produkten ist der Geschützte Modus, in dem durch Sandboxing die Kommunikation aus dem PDF mit anderen Anwendungen eingeschränkt oder vollständig untersagt wird. Mittels eines eigenen Brokers wird die Adobe Sandbox unidirektional überbrückt. Es stehen dann alle definierten Funktionen der Lösung zur Verfügung, mit Ausnahme der Verlinkung aus dem JT Modell in die PDF Datei.
4.4 URL Moniker – Links im Internet Explorer und Firefox
Werden jtbridge-Links direkt aus dem Kontext des Microsoft Internet Explorers (IE) ab Version 8 verfolgt, dann werden Applikationsprotokolle anders behandelt. Das jtbridge-Protokoll wird über ein COM-Objekt (dII) behandelt, welches die URL zur weiteren Verarbeitung an die JTbridge weitergibt. Notwendig ist dieses Vorgehen nur für den IE. Bei Firefox wird die JTBridge direkt über das vwg-jtbridge-Protokoll aufgerufen und gesteuert..
4.5 Foxit PDF-Reader
Neben dem Adobe PDF-Viewer existieren auch andere PDF-Viewer, die industriellen Anforderungen gerecht werden. Die Verlinkung von 2D-Links zu 3D-Objekten kann mit der Standarddistribution des Foxit PDF-Readers geschehen.
4.6 Microsoft Office (Word, Excel, PowerPoint etc.)
Die jtbridge-Links in Office-Dokumenten können ohne Einschränkung genutzt werden. Die Auflösung erfolgt durch das Betriebssystem, das die Steuerungsinformationen an die JTBridge weiterleitet.
4.7 JT-Viewerarchitektur
Das im 3D-Dokument enthaltenen JT-Modell ist in einem Produkt der JT-Viewerfamilie geöffnet. Diese basiert auf der Komponententechnologie PLM Vis, mit Hilfe derer der Funktionsumfang der Viewer umgesetzt wird. Die Viewer werden immer mit der vollständigen Automation API ausgeliefert. Selbst bei dem kostenlosen JT2Go-Viewer ist diese vorhanden und kann zum Customizing via COM genutzt werden. Es ist dabei vorgesehen, die folgenden Viewerkonfigurationen zu berücksichtigen:

• JT2GO
• VisBase
• VisStandard
• VisProfessional
• VisMockup

Im Gegensatz zu der losen Kopplung zwischen Adobe Reader und Teamcenter Visualization Viewern (Tc.Vis.) muss zwischen Tc.Vis. und der JTBridge eine enge Bindung via COM realisiert werden. Dies ist die einzige Möglichkeit, mit einem JT-Viewer direktiv zu kommunizieren. Alle TC Vis-Viewer basieren auf einem einheitlichen Framework, Siemens PLMVis Components. Diese Architektur erlaubt das Ausliefern einer JT-Applikation mittels einzelner, ausgereifter Komponenten. Zu den von Siemens konfigurierten Applikationen gehören Siemens Teamcenter Base, Standard, Professional sowie VisMockup. Ebenso beruht der kostenlose Viewer JT2GO hierauf. Diese Applikationen erhalten somit auch die Fähigkeit, über COM bzw. ein (mit-)ausgeliefertes TypeLibrary (VisAutomation.tlb) Operationen auf dem JT-Viewer ausführen zu können.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

EP 1008112 B1 [0002]
US 6268846 B1 [0003]
US 2006/0256136 A1 [0003]
US 7453459 B2 [0003]

Claims

Verfahren zum Herstellen eines komplexen Produktes, insbesondere eines Kraftfahrzeuges mit folgenden Schritten: – Konstruieren eines Bauteils für das komplexe Produkt, – Erzeugen einer Datei mit einer dreidimensionalen Darstellung des Bauteils in einem ersten Datenformat für ein erstes Programm, – Erzeugen zumindest einer Datei mit einer Metainformation der dreidimensionalen Darstellung des Bauteils in einem elektronisch durchsuchbaren zweiten Datenformat für ein zweites Programm, – insbesondere Einbetten der Datei mit der dreidimensionalen Darstellung des Bauteils in dem ersten Datenformat in die Datei im zweiten Datenformat, – Öffnen der Datei im zweiten Datenformat mittels des zweiten Programms zur Darstellung der Metainformation, – Öffnen der Datei im ersten Datenformat mittels des ersten Programms zur dreidimensionalen Darstellung des Bauteils, – Starten eines dritten Programms zum Datenaustausch zwischen dem ersten Programm und dem zweiten Programm, – Fertigen eines Bauteils gemäß der dreidimensionalen Darstellung des Bauteils, und – Herstellen des Kraftfahrzeuges unter Verwendung des Bauteils.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die dreidimensionale Darstellung des Bauteils in einem ersten Fenster erfolgt, und dass die Darstellung der Metainformation in zumindest einem zweiten Fenster erfolgt.
Verfahren zum Betrieb eines Computers mit folgenden Schritten: – Bereitstellen einer Datei mit einer dreidimensionalen Darstellung eines Bauteils in einem ersten Datenformat für ein erstes Programm sowie Bereitstellen zumindest einer Datei mit einer Metainformation zur dreidimensionalen Darstellung des Bauteils in einem elektronisch durchsuchbaren zweiten Datenformat für ein zweites Programm, wobei die Datei mit der dreidimensionalen Darstellung des Bauteils in dem ersten Datenformat in die Datei im zweiten Datenformat eingebettet ist, – Öffnen der Datei im zweiten Datenformat mittels des zweiten Programms, – Öffnen der Datei im ersten Datenformat mittels des ersten Programms zur dreidimensionalen Darstellung des Bauteils, insbesondere in einem ersten Fenster, – Starten eines dritten Programms zum Datenaustausch zwischen dem ersten Programm und dem zweiten Programm, und – Darstellung der Metainformation, insbesondere in einem zweiten Fenster.
Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass das erste und das zweite Fenster gleichzeitig geöffnet sind.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das erste Dateiformat .jt ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das zweite Dateiformat .pdf ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das zweite Programm ein Plugin zur Kommunikation mit dem dritten Programm umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Datei mit der Metainformation zumindest einen Hyperlink umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das erste Programm und/oder das zweite Programm ein Viewer ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in die zweite Datei zusätzlich eine PDF-Datei, eine XML-Datei und/oder eine HTML-Datei eingebettet ist.