DE19950174A1 - Verfahren zum Konvertieren eines Datenmodells zur Beschreibung räumlicher Objekte - Google Patents

Abstract

Es wird ein Verfahren zum Konvertieren eines Datenmodells (16) zur Beschreibung räumlicher Objekte (18) von einem ersten System (12) in ein zweites System (40) angegeben, bei dem im ersten System (12) während der Erstellung des Datenmodells (16) die Befehlsfolge zur Erstellung eines Objektes (18) aufgezeichnet wird, bei dem anschließend die aufgezeichneten Befehle der Befehlsfolge (24, 26) des ersten Systems (12) nacheinander z. B. mit Hilfe einer Konvertierungstafel (28) in Befehle des zweiten Systems (40) konvertiert werden, um eine konvertierte Befehlsfolge (30, 32) zu erzeugen, die anschließend in das zweite System (40) eingelesen wird, um das Datenmodell (46) des Objektes (18) im zweiten System (40) zu erzeugen (Fig. 1).

Description

Die Erfindung betrifft ein Verfahren zum Konvertieren eines Da­ tenmodells zur Beschreibung räumlicher Objekte von einem ersten System in ein zweites System.

Die Erfindung betrifft ferner ein gekoppeltes System mit einem ersten System zur Erzeugung eines Datenmodells zur Beschreibung von räumlichen Objekten und mit einem zweiten System zur Erzeu­ gung eines Datenmodells zur Beschreibung von räumlichen Objek­ ten.

In jüngster Zeit hat die Nutzung von CAD-Systemen (Computer Ai­ ded Design), CAE-Systemen (Computer Aided Engineering), CIM- Systemen (Computer Integrated Manufacturing) und anderer sol­ cher Systeme, die teilweise auch als CXY-Tools bezeichnet wer­ den, erheblich zugenommen.

Bei sämtlichen solcher Systeme werden Datenmodelle zur Be­ schreibung räumlicher Objekte, z. B. von Konstruktionsteilen, erstellt, wobei teilweise noch Berechnungsprogramme verwendet werden, die die Materialeigenschaften und weitere Eigenschaften beschreiben oder das Datenmodell unmittelbar z. B. einer Maschi­ ne für Rapid Prototyping zur Verfügung stellen, oder die mit­ telbar zur Steuerung einer CNC-Maschine zur Herstellung des be­ treffenden Teils verwendet werden.

Ein zentrales Problem bei derartigen Systemen besteht darin, daß die Datenmodelle nur innerhalb einer einzigen Systemumge­ bung benutzt und weiterbearbeitet werden können.

Muß ein Modell eines räumlichen Objektes, das in einem ersten System erstellt wurde, auf ein zweites System konvertiert wer­ den, um z. B. ein von einem Zulieferer hergestelltes Einbauteil, das im CAD-System des Zulieferers mit einem Datenmodell be­ schrieben ist, in das CAD-System bzw. CIM-System eines Automo­ bilherstellers zu übernehmen, so stehen hierfür teilweise stan­ dardisierte Schnittstellen zur Verfügung. Mit derartigen Schnittstellen, die speziell zur Modellübergabe zwischen zwei bestimmten Systemen programmiert wurden, wird das Datenmodell als Ganzes, das das jeweilige Objekt vollständig beschreibt, umgesetzt. Dabei werden auch sämtliche Daten des Modells, die die zweidimensionale oder dreidimensionale Darstellung des Ob­ jektes betreffen, vollständig konvertiert.

Bei komplizierteren Objekten, die aus einer ganzen Folge von Basisobjekten erstellt und mit einer Vielzahl von Schritten be­ arbeitet wurden, entstehen selbst bei derartigen Spezial­ schnittstellen erhebliche Probleme, so daß eine vollständige Umsetzung des jeweiligen im ersten System erstellten Datenmo­ dells in ein entsprechendes Datenmodell in einem zweiten System nicht gewährleistet werden kann oder das Datenmodell im zweiten System trotz vorhandener Schnittstelle häufig vollkommen neu erstellt werden muß.

Außerdem gehen bei einer herkömmlichen Konvertierung immer die History bzw. die geometrischen Zwangsbedingungen verloren, was dazu führt, daß bei einer nachträglichen konstruktiven Änderung einzelner Objekte ein beträchtlicher Nachbearbeitungsaufwand entsteht. Dabei gehen also die Vorteile des parametrischen Volumenmodellierens durch die Datenkonvertierung verloren. Bei in der Entwicklung befindlichen Systemen zur Konvertierung der Zwangsbedingungen entsteht erheblicher Aufwand, so daß sich Probleme mit verschiedenen Softwareständen ergeben. Mit der schnellen Weiterentwicklung der CAD-Systeme kann die Entwick­ lung der Konvertierungsverfahren nicht mithalten, da letztere erst zeitlich versetzt erfolgen kann.

Die Aufgabe der Erfindung besteht demnach darin, ein Verfahren zum Konvertieren eines Datenmodells zur Beschreibung räumlicher Objekte von einem ersten System in ein zweites System zu schaf­ fen, mit dem eine Konvertierung des Datenmodells erleichtert wird und eine vollständige, weniger zeitraubende Konvertie­ rungsmöglichkeit zwischen unterschiedlichen Systemen geschaffen wird.

Ferner soll ein gekoppeltes System angegeben werden, das die Konvertierung eines in einem ersten System erstellten Datenmo­ dells zur Beschreibung eines räumlichen Objektes in ein ent­ sprechendes Datenmodell zur Beschreibung dieses Objektes in ei­ nem zweiten System ermöglicht.

Diese Aufgabe wird erfindungsgemäß durch ein Verfahren zum Kon­ vertieren eines Datenmodells zur Beschreibung räumlicher Objek­ te von einem ersten System in ein zweites System gelöst, bei dem im ersten System während der Erstellung des Datenmodells die Befehlsfolge zur Erstellung eines Objektes aufgezeichnet wird, bei dem anschließend die aufgezeichneten Befehle der Be­ fehlsfolge des ersten Systems nacheinander in Befehle des zwei­ ten Systems konvertiert werden, um eine konvertierte Befehls­ folge zu erzeugen, und bei dem anschließend die konvertierte Befehlsfolge in das zweite System eingelesen wird, um das Da­ tenmodell im zweiten System zu erzeugen.

Die Aufgabe der Erfindung wird so in überraschend einfacher Weise gelöst, da von der üblichen Konvertierung des vollständi­ gen Datenmodells abgesehen wird und statt dessen die einzelnen Schritte oder Befehle, die zur Erzeugung des räumlichen Objek­ tes notwendig sind, aufgezeichnet und für das zweite System um­ gesetzt werden.

Die aufgezeichnete Befehlsfolge, die nach ihrer Konvertierung im zweiten System lesbar ist, wird nun im zweiten System ver­ wendet, um das Datenmodell des Objektes neu aufzubauen. Dabei sind alle notwendigen Daten zur Erzeugung des Objektes in der konvertierten Befehlsfolge enthalten, so daß das Datenmodell vollständig mit sämtlichen Details im zweiten System erstellt werden kann.

Im Gegensatz zu einer manuellen Datenkonvertierung durch einen kompletten Neuaufbau des Modells, was aufgrund der oben be­ schriebenen Mängel bei Standardschnittstellen häufig notwendig ist, wird durch das erfindungsgemäße Verfahren erhebliche Bear­ beitungszeit eingespart. Erstens läuft das Verfahren nach dem Starten automatisch ohne Benutzerinteraktion ab und zweitens kann darauf verzichtet werden, das Modell während der Erstel­ lung grafisch darzustellen, was bei herkömmlicher Neuerstellung durch den Benutzer bislang immer notwendig war. Damit wird ein Großteil der zum Erstellen des Datenmodells benötigten Rechen­ leistung eingespart, so daß der Anwender auf dem System in der Zwischenzeit mehr Ressourcen für andere Aufgaben zur Verfügung hat. Es ist sogar möglich, daß während mit einem CAD-System ein Datenmodell erzeugt wird, ein solches Konvertierungsprogramm sozusagen online die Daten einem oder mehreren weiteren Syste­ men zur Verfügung stellt, so daß bei komplexen Projekten mehre­ re Personen gleichzeitig mit verschiedenen Systemen arbeiten können. Selbstverständlich kann dies gleichzeitig ebenso in die andere Richtung erfolgen.

Da eine automatische Aufzeichnung der Befehlsfolge bei der Er­ stellung eines Datenmodells bei praktisch jedem für den kommer­ ziellen Einsatz bestimmten CXY-Tool in Form eines Macrorecor­ ders und/oder in Form eines History-Trees ohnehin vorhanden ist, muß die vorhandene Software zur Modellerzeugung im ersten System oder im zweiten System selbst nicht angepaßt werden, sondern es muß nur für die Konvertierung der Befehle des ersten Systems in die entsprechenden Befehle des zweiten Systems Sorge getragen werden.

Wie bereits erwähnt, kann die Aufzeichnung der Befehlsfolge während der Erstellung des Datenmodells im ersten System etwa mittels eines Macrorecorders erfolgen, der ohnehin bei prak­ tisch allen Systemen vorhanden ist.

Selbstverständlich kann dies durch einen Hintergrundprozeß ge­ schehen, der als Client oder Serveranwendung über entsprechende Softwareschnittstellen objektorientierter Systeme kommuniziert.

Gemäß einer weiteren Ausführung der Erfindung erfolgt die Auf­ zeichnung der Befehlsfolge während der Erstellung des Datenmo­ dells im ersten System in einem History-Tree.

Bei einem History-Tree handelt es sich um eine sequentielle Aufzeichnung der Befehle zur Modellerzeugung, die zusätzlich graphisch dargestellt und mit den entsprechenden Daten hinter­ legt wird. Die Darstellung erfolgt in Form von miteinander ver­ bundenen Knoten (sogenannte "nodes" oder auch Identitäten).

Anhand eines derartigen History-Trees lassen sich die einzelnen objektbezogenen Eingaben zur Objekterzeugung in einfacher Weise nachvollziehen.

Der besondere Vorteil der Erfindung besteht darin, daß ledig­ lich die Befehle zur Erzeugung der Basisobjekte (z. B. Kreis, Ellipse, Rechteck bzw. entsprechende räumliche Strukturen) in die entsprechenden Befehle des zweiten Systems zur Erzeugung der Basisobjekte konvertiert werden müssen, d. h. also die Nodes oder Identitäten umgesetzt werden müssen. Dagegen wird auf eine Umsetzung der vererbten Objekte (d. h. der durch eine Folge von verschiedenen Nodes oder Identitäten erzeugten räumlichen Ob­ jekte) verzichtet.

Das zweite System führt bei Ausführung der Befehlsfolge automa­ tisch alle Vererbungsschritte bzw. sonstigen Berechnungen des Datenmodells (z. B. Schnittkanten usw.) durch, so daß das ent­ stehende Datenmodell alle Eigenschaften hat, als wäre es direkt im zweiten System erstellt worden. Es findet damit keine Nach­ ahmung von Eigenschaften des ersten Systems statt, sondern es werden die systemspezifischen Merkmale des zweiten Systems ge­ nutzt, wodurch erstens Speicherplatz gespart werden kann und zweitens eine Bearbeitung und Nutzung der Daten innerhalb des zweiten Systems erleichtert wird.

In vorteilhafter Weiterbildung der Erfindung wird die aufge­ zeichnete Befehlsfolge vor ihrer Konvertierung editiert, um Fehler, unnötige Wiederholungen, Befehle, die anschließend wie­ der gelöscht wurden, und dgl. zu beseitigen.

Auf diese Weise wird das Datenmodell zur Beschreibung des be­ treffenden räumlichen Objektes so weit wie möglich vereinfacht und die Konvertierung in das andere System möglichst einfach gestaltet.

In vorteilhafter Weiterbildung der Erfindung wird zur Konver­ tierung der aufgezeichneten Befehlsfolge in die konvertierte Befehlsfolge eine Konvertierungstabelle (oder Look-up-Tabelle) verwendet, die Konvertierungsanweisungen zur Konvertierung je­ des im ersten System zur Objekterzeugung möglichen Befehls in einen entsprechenden Befehl des zweiten Systems enthält.

In dieser Konvertierungstabelle oder Look-up-Tabelle wird jeder einzelne Befehl zur Objekterzeugung, der im ersten System ver­ fügbar ist, einem entsprechenden Befehl zur Objekterzeugung im zweiten System zugeordnet, wobei automatisch die Parameter ent­ sprechend der Möglichkeiten des zweiten Systems übergeben wer­ den (und umgekehrt, sofern eine Konvertierung aus dem zweiten System ins erste System erfolgt).

Wenn bspw. im ersten System die Erzeugung eines Quadrates mit der Kantenlänge a₁ möglich ist und das zweite System kein Qua­ drat, sondern nur ein Rechteck mit gleichlangen Seitenkanten kennt, so könnte die Umsetzungsanweisung vom ersten System in das zweite System lauten:
Quadrat, Kantenlänge (a₁) → Rechteck, Kantenlänge (a₁, a₁).

Entsprechende Konvertierungsanweisungen werden für sämtliche objektbezogenen Befehle erstellt.

Bei der Konvertierung einer aufgezeichneten Befehlsfolge zur Erstellung des Datenmodells im ersten System müssen dann ledig­ lich die einzelnen Befehle nacheinander aufgrund der Anweisun­ gen der Konvertierungstabelle automatisch in Befehle des zwei­ ten Systems umgesetzt werden.

Die so konvertierte Befehlsfolge kann dann in das zweite System eingelesen und zur automatischen Erzeugung des entsprechenden Datenmodells des Objektes im zweiten System genutzt werden.

Die Aufgabe der Erfindung wird ferner durch ein gekoppeltes Sy­ stem mit einem ersten System zur Erzeugung eines Datenmodells zur Beschreibung von räumlichen Objekten und mit einem zweiten System zur Erzeugung eines Datenmodells zur Beschreibung von räumlichen Objekten gelöst, mit Mitteln zur Aufzeichnung einer Befehlsfolge bei der Erstellung eines Datenmodells eines Objek­ tes im ersten System, mit Mitteln zur Konvertierung der aufge­ zeichneten Befehlsfolge in eine konvertierte Befehlsfolge, und mit Mitteln zum Einlesen der konvertierten Befehlsfolge in das zweite System zur Erzeugung eines Datenmodells des Objektes im zweiten System.

Die Aufzeichnung und Konvertierung des Datenmodells erfolgt in der vorstehend beschriebenen Weise, wobei wiederum bevorzugt ein Macrorecorder und/oder ein History-Tree verwendet werden kann und eine Editiermöglichkeit zur Optimierung der aufge­ zeichneten Befehlsfolge vorgesehen sein kann und die Konvertie­ rung etwa unter Verwendung einer Konvertierungstabelle erfolgen kann.

Es versteht sich, daß die vorstehend genannten und die nach­ stehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.

Weitere Merkmale und Vorteile der Erfindung ergeben sich aus der nachfolgenden Beschreibung bevorzugter Ausführungsbeispiele unter Bezugnahme auf die Zeichnung. Es zeigen:

Fig. 1 ein erfindungsgemäß gekoppeltes System mit einem er­ sten System für ein Datenmodell zur Beschreibung von räumlichen Objekten und einem entsprechenden zweiten System und mit einer Konvertierungsroutine und

Fig. 2a-c verschiedene Stufen bei der Erzeugung eines History- Trees bei der Modellierung eines zweidimensionalen Objektes.

In Fig. 1 ist ein erfindungsgemäßes gekoppeltes System äußerst schematisch dargestellt und insgesamt mit der Ziffer 10 be­ zeichnet.

Das gekoppelte System 10 enthält ein erstes System 12 zur Modellierung eines räumlichen Objektes, wozu beispielhaft das durch eine gestrichelte Linie eingeschlossene Objekt 18 darge­ stellt ist.

Das erste System 12 enthält bspw. eine Workstation 14, in der ein Datenmodell 16 zur vollständigen räumlichen Beschreibung des Objektes 18 mit Hilfe einer Eingabetastatur 20 und z. B. ei­ ner Maus 22 oder einem anderen Eingabemedium erzeugt wird. Hierzu wird die vorhandene, objektbezogene Software des ersten Systems 12 benutzt.

Das erste System 12 weist ferner einen Macrorecorder 24 und ei­ ne Einrichtung 26 zur Erzeugung eines History-Trees auf. Wäh­ rend der Erstellung des Datenmodells 16 des Objektes 18 werden sämtliche Eingabeschritte mit dem Macrorecorder 24 aufgezeich­ net, was schematisch beispielhaft für einen ersten Eingabe­ schritt im Macrorecorder 24 dargestellt ist.

Darüber hinaus wird vorzugsweise zusätzlich die Erzeugung des Datenmodells 16 in Form des History-Trees 26 nachvollzogen, was eine besonders einfache und übersichtliche Aufzeichnung der Einzelschritte bei der Modellerzeugung zur Beschreibung des räumlichen Objektes 18 ermöglicht. Ferner läßt sich der Histo­ ry-Tree nach erstmaliger Erstellung des Datenmodells 16 in ein­ facher Weise editieren, um unnötige Schritte zu eliminieren, Fehler zu beheben und sonstige Vereinfachungen vorzunehmen, die zum selben Ergebnis führen.

Das erste System 12 enthält ferner eine Konvertierungstabelle oder Look-up-Tabelle 28, in der Konvertierungsanweisungen zur Konvertierung jedes einzelnen im ersten System 12 möglichen Be­ fehls in einen entsprechenden Befehl des zweiten Systems 40 ge­ speichert sind.

Unter Befehl wird in diesem Zusammenhang eine Anweisung zusam­ men mit den dazugehörigen Eingabewerten (Parametern) verstan­ den, z. B. müssen bei Erzeugung eines Rechtecks die Kantenlän­ gen, die Winkellage zu einem Koordinatensystem und die Position zu einem Koordinatensystem angegeben werden. Dies kann sowohl durch Eingabe von numerischen Werten, als auch durch die Fest­ legung von geometrischen Zwangsbedingungen (z. B. Parallelität einer Seite zu einer Koordinatenachse) erfolgen.

Steht nun bspw. im ersten System 12 der Befehl "Erzeuge Quadrat mit der Kantenlänge (a)" zur Verfügung und kennt das zweite Sy­ stem 40 kein Quadrat sondern nur das Basisobjekt "Rechteck", so ergäbe sich die Konvertierungsanweisung zur Konvertierung aus dem ersten System ins zweite System:
Quadrat (a) → Rechteck (a, a).

Entsprechende Konvertierungsanweisungen werden für sämtliche möglichen Befehle zur Objekterzeugung aufgenommen. Vielfach wird es sich dabei lediglich um die Abbildung eines Befehls in sich selbst handeln, sofern die betreffenden Befehle in beiden Systemen 12, 40 identisch sind.

Entsprechende Konvertierungsanweisungen werden zur Umsetzung von Befehlen aus dem zweiten System 40 in Befehle des ersten Systems 12 verwendet, sofern eine Konvertierung von Datenmodel­ len aus dem zweiten System 40 in Datenmodelle des ersten Sy­ stems 12 gewünscht ist.

Mit Hilfe einer derartigen Konvertierungstabelle 28 wird die mit dem Macrorecorder 24 aufgezeichnete Befehlsfolge, die bei der Erstellung des Datenmodells 16 zur Beschreibung des Objek­ tes 18 aufgezeichnet wurde, in eine konvertierte Befehlsfolge 30 umgesetzt.

Alternativ oder zusätzlich kann der History-Tree 26 entweder vollständig in einen konvertierten History-Tree 32 umgesetzt werden, oder es werden lediglich die einzelnen Identitäten, die zur Erzeugung des History-Trees notwendig waren, konvertiert, wie mit der Ziffer 32 angedeutet.

Die konvertierte Befehlsfolge 30 wird nun in das zweite System 40 eingelesen, um so mit Hilfe der Workstation 44 ein entspre­ chendes Datenmodell 46 des Objektes 18 zu erzeugen, das dieses vollständig beschreibt und mit sämtlichen Einzelheiten korrekt abbildet, genauso, wie dies das Datenmodell 16 des ersten Sy­ stems 12 tut. Das Datenmodell 46 kann dann mittels der Tastatur 50, sowie einer Maus 52 oder einem anderen geeigneten Eingabe­ medium überarbeitet bzw. für einen anderen Zweck umgesetzt wer­ den, um z. B. eine CNC-gesteuerte Maschine zur Herstellung des modellierten räumlichen Objektes 18 zu steuern.

Soweit keine vollständige Konvertierung der mit dem Macrorecor­ der 24 aufgezeichneten Befehlsfolge in die konvertierte Be­ fehlsfolge 30 erfolgt, wird mit Hilfe der Konvertierungstabelle 28 eine Konvertierung der einzelnen Identitäten durchgeführt, wie dies mit der Ziffer 32 angedeutet ist. Die Folge der Iden­ titäten wird dann in das zweite System 40 eingelesen, um so das Datenmodell 46 zu erzeugen.

Während die vollständige Konvertierung der mit dem Macrorecor­ der 24 aufgezeichneten Befehlsfolge in die konvertierte Be­ fehlsfolge 30 in der Regel keine weitere Bearbeitung zur Ver­ einfachung bzw. Optimierung des Datenmodells 16 nach der Er­ stellung erlaubt, da dies in der Regel zu unübersichtlich wird, hat die Verwendung des History-Trees 26 in Verbindung mit der nachfolgenden Konvertierung der Identitäten gemäß Ziffer 32 den Vorteil, daß der History-Tree 26 vor der Konvertierung seiner einzelnen Identitäten editiert werden kann, um eine Optimierung des Datenmodells 16 (z. B. durch Entfernung von Redundanzen) zu ermöglichen.

Somit können beim Einlesen in das zweite System 40 die einzel­ nen Schritte der Modellerzeugung unmittelbar nachvollzogen wer­ den.

Die einzelnen Schritte zur Erzeugung des Datenmodells 16 für das einfache Objekt 18, das aus einem Quadrat, einem angrenzen­ den Rechteck und einem kreisförmigen Ausschnitt (cutout) be­ steht, sind im folgenden anhand von Fig. 2 verdeutlicht.

Dabei sind in der linken Hälfte die einzelnen Schritte a), b) und c) zur Erzeugung des Objektes in einem Koordinatensystem (x, y) dargestellt, während auf der rechten Seite der zugehöri­ ge History-Tree dargestellt ist.

Unter einem History-Tree versteht man eine sequentielle Auf­ zeichnung der Modellierereignisse, die zur Erzeugung eines Ob­ jektes verwendet werden.

In den Nodes oder Ereignissen sind die Eingaben zusammengefaßt, die zu dem in jedem Schritt erzeugten oder sonstwie manipulier­ ten Objekt führen. Unter einem Node bzw. einer Identität ist dabei eine Datenstruktur zu verstehen, die die einzelnen Model­ lierereignisse (objektbezogene Eingaben) repräsentiert. Nodes haben typischerweise ein Elternteil (parent) und zwei Kinder (children), ein linkes Kind (left child) und ein rechtes Kind (right child). Jeder Node hat entweder zwei Kinder oder keine Kinder. History-Trees werden normalerweise von unten nach oben gezeichnet, wobei die einzelnen Nodes in Folge durchnumeriert werden.

Gemäß Fig. 2 wird gemäß Schritt a) zunächst ein Quadrat 60 im Koordinatensystem (x, y) erzeugt, was durch den Node 70 im Hi­ story-Tree modelliert ist. Das linke Blatt (leaf) enthält die Angaben zur Festlegung des Koordinatensystems (x, y), während das rechte Blatt die Angaben zur Erzeugung des Quadrates 60 enthält. Dies soll bspw. mit der Kantenlänge a₁ am Ort (x₁, y₁) erzeugt werden und um einen Winkel von α = 0° gegenüber den Koordinatenachsen verdreht sein.

Im Schritt b) soll nunmehr an die rechte Seitenkante 62 des Quadrates 60 angrenzend ein Rechteck 64 angefügt werden, das die Seitenkanten a₂ und b₂ aufweist.

Das zum Node 72 gehörige Blatt auf der rechten Seite enthält die Anweisungen, daß das Rechteck zu plazieren ist, und zwar mit der Kantenlänge a₂, b₂, mit linker Seitenkante angrenzend an 62.

Im nachfolgenden Schritt c) wird nunmehr ein Ausschnitt 66 oder Cutout erzeugt. Gemäß dem rechten Blatt des Nodes 74 soll dies mit dem Radius r am Ort (x₂, y₂) erfolgen.

Während man dem räumlichen Objekt 18, das durch die Schritte a), b) und c) erzeugt wurde, nicht mehr ansehen kann, in wel­ cher Reihenfolge die einzelnen Teilobjekte zusammengefügt wur­ den und wann der Ausschnitt 66 erzeugt wurde, enthält der Hi­ story-Tree, der auf der rechten Hälfte von Fig. 2c) dargestellt ist, sämtliche notwendigen Angaben in übersichtlicher Form, die zur Erstellung des Objektes 18 verwendet werden.

Bei der Konvertierung des Datenmodells von einem System in ein anderes System müssen lediglich die zu den Nodes 70, 72, 74 ge­ hörigen Anweisungen umgesetzt werden. Dabei werden gleichzeitig die den Nodes hinterlegten Parameter bzw. geometrischen Zwangs­ bedingungen (Constraints) und numerischen Werte (z. B. Längen oder Winkel) umgesetzt.

Es versteht sich, daß die vorstehende Beschreibung der Erzeu­ gung des History-Trees gemäß Fig. 2 ausschließlich beispielhaf­ ter Natur ist und von System zu System anhand der möglichen Identitäten zur Objekterzeugung variieren kann.

Ferner dient die Beschreibung der Stellung des History-Trees gemäß Fig. 2 lediglich einer beispielhaften Darstellung, wozu ein besonders einfaches System zur zweidimensionalen Modellie­ rung gewählt wurde. Üblicherweise werden Objekte dreidimensio­ nal modelliert, wobei darüber hinaus noch weitere Angaben zu Werkstoffeigenschaften und dgl. verwendet werden können. Auch kann ein Berechnungsmodell angeschlossen sein, um bspw. die einzusetzenden Massen bei der Fertigung des betreffenden Teils berechnen zu können.

Claims (12)

1. Verfahren zum Konvertieren eines Datenmodells (16) zur Be­ schreibung räumlicher Objekte (18) von einem ersten System (12) in ein zweites System (40), bei dem im ersten System (12) während der Erstellung des Datenmodells (16) die Be­ fehlsfolge zur Erstellung eines Objektes (18) aufgezeich­ net wird (24, 26), bei dem anschließend die aufgezeichne­ ten Befehle der Befehlsfolge (24, 26) des ersten Systems (12) nacheinander in Befehle des zweiten Systems (40) kon­ vertiert werden, um eine konvertierte Befehlsfolge (30, 32) zu erzeugen, und bei dem anschließend die konvertierte Befehlsfolge (30, 32) in das zweite System (40) eingelesen wird, um das Datenmodell (46) des Objektes (18) im zweiten System (40) zu erzeugen.

2. Verfahren nach Anspruch 1, bei die Aufzeichnung der Be­ fehlsfolge während der Erstellung des Datenmodells (16) im ersten System (12) mittels eines Macrorecorders (26) er­ folgt.

3. Verfahren nach Anspruch 1 oder 2, bei dem die Aufzeichnung der Befehlsfolge während der Erstellung des Datenmodells (16) im ersten System (12) in einem History-Tree (26) er­ folgt.

4. Verfahren nach Anspruch 2, bei dem die Macros der aufge­ zeichneten Befehlsfolge des ersten Systems (12) in eine konvertierte Befehlsfolge (30) mit Macros des zweiten Sy­ stems (40) umgesetzt werden.

5. Verfahren nach Anspruch 3 oder 4, bei dem die Identitäten (70, 72, 74) des History-Trees (26) des ersten Systems (12) in eine konvertierte Befehlsfolge (32) mit Identitä­ ten des zweiten Systems (40) konvertiert werden.

6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die aufgezeichnete Befehlsfolge (26) vor ihrer Konvertie­ rung editiert wird, um Fehler, Redundanzen und dgl. zu be­ seitigen.

7. Verfahren nach einem der vorhergehenden Ansprüche, bei dem zur Konvertierung der aufgezeichneten Befehlsfolge (24, 26) in die konvertierte Befehlsfolge eine Konvertierungs­ tabelle (28) verwendet wird, die Konvertierungsanweisungen zur Konvertierung jedes im ersten System (12) zur Objek­ terzeugung möglichen Befehls in einen entsprechenden Be­ fehl des zweiten Systems (40) enthält.

8. Gekoppeltes System (10) mit einem ersten System (12) zur Erzeugung eines Datenmodells (16) zur Beschreibung von räumlichen Objekten (18) und mit einem zweiten System (40) zur Erzeugung eines Datenmodells (46) zur Beschreibung von räumlichen Objekten (18), mit Mitteln (24, 26) zur Auf­ zeichnung einer Befehlsfolge bei der Erstellung eines Da­ tenmodells (16) eines Objektes (18) im ersten System (12), mit Mitteln (28) zur Konvertierung der aufgezeichneten Be­ fehlsfolge (24, 26) in eine konvertierte Befehlsfolge (30, 32) und mit Mitteln (34, 36) zum Einlesen der konvertier­ ten Befehlsfolge (30, 32) in das zweite System (40) zur Erzeugung eines Datenmodells (46) des Objektes (18) im zweiten System (40).

9. Gekoppeltes System nach Anspruch 8, bei dem die Mittel zur Aufzeichnung der Befehlsfolge im ersten System (12) als Macrorecorder (24) ausgebildet sind.

10. Gekoppeltes System nach Anspruch 9, bei dem Mittel zur Darstellung der aufgezeichneten Befehlsfolge in Form eines History-Trees (26) vorgesehen sind.

11. Gekoppeltes System nach Anspruch 9 oder 10, bei dem Mittel zum Editieren der aufgezeichneten Befehlsfolge (32) vorge­ sehen sind, um Fehler, unnötige Wiederholungen, Befehle, die anschließend wieder gelöscht wurden und dgl. zu besei­ tigen.

12. Gekoppeltes System nach einem der Ansprüche 8 bis 11, mit einer Konvertierungstabelle (28), die Konvertierungsanwei­ sungen zur Konvertierung jedes im ersten System (12) zur Objekterzeugung möglichen Befehls in einen entsprechenden Befehl des zweiten Systems (40) enthält.