Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

02.06.1995

Schwerpunkt/Konstruktion und Fertigung

CAD-Objekte leiten das Ende monolithischer Systeme ein

Gestern erst als Highlight eines CAD/CAM-Systems gefeiert, gehoeren sie heute bereits zum Stand der Technik: Die "Feature-based Modeler", die einem Bauteil ausser der reinen Geometrie zusaetzliche technische Informationen zuweisen. Der Startschuss zur Integration saemtlicher Produktinformationen innerhalb einer Prozesskette ist damit gefallen. Doch wie ein kuenftiger Produktmodellierer auch aussehen mag, an der Objekttechnik wird er wohl nicht vorbeikommen.

Von Eberhard Rademeier*

CAD-Systeme der ersten Generation gingen von der reinen Geometrie aus - eine Zeichnung bestand aus geometrischen Elementen wie Linie, Kreis, Kreisbogen, im Idealfall zusaetzlich aus Kegelschnitten wie Ellipse, Hyperbel, Parabel oder bei 3D-Systemen aus deren dreidimensionalen Aequivalenten. Diese Geometrie wurde zusammen mit weiteren Elementen wie Bemassungen und Texten zu einer Zeichnung zusammengefasst. Im guenstigsten Fall enthielt eine Zeichnung so zusaetzliche Informationen, aus denen sich eine Stueckliste generieren liess: Anfang der 80er Jahre herrschte eine wahre BOM-Euphorie (Bill of material = Stueckliste). Softwarehersteller, die keinen BOM-Generator anbieten konnten, waren ploetzlich nicht mehr "on the leading edge".

Intelligente Systeme loesen "dumme Files" ab

Ansonsten stellten CAD-Zeichnungen eher dumme Files dar, die ausgeplottet wurden und deren Inhalt vom Bearbeiter wie eine normale Brettzeichnung interpretiert werden musste. Erst gegen Ende der 80er Jahre kamen Systeme auf den Markt (teilweise auch erst in die Diskussion), die deutlich mehr Informationen an eine Zeichnung heften konnten.

Vertreter dieser "intelligenteren" Systeme sind die sogenannten Feature-based Modeler. Features sind Gestalt- oder Formelemente, feature-based bedeutet: eine Ansammlung von Geometrieelementen "weiss" nicht nur um seine Zusammengehoerigkeit (das liesse sich ebenso durch einfaches Gruppieren erreichen), sondern um seine Funktion und seine Zusammenhaenge mit der umgebenden Geometrie. Ein haeufig benutztes, weil sehr einpraegsames Beispiel ist das Sackloch. Aus geometrischer (2D-)Sicht wird ein solches aus einem Rechteck und einem Dreieck zusammengesetzt, in einem 3D-System aus Zylinder und Kegel.

Geometrie- und Feature-based-Modeler

Aus konstruktiver und fertigungstechnischer Sicht ist ein Sackloch jedoch bedeutend mehr: Es besteht unter anderem aus einer Kernloch-bohrung, einer Senkung und einer Gewindebohrung, ausserdem hat es im vollen Material zu enden, ansonsten ist es eine Durchgangsbohrung.

Wird nun die Staerke der Platte, in die der Konstrukteur ein Sackloch bestimmter Laenge gesetzt hat, unter die Laenge des Sacklochs reduziert, so haengt ein Teil der Sacklochgeometrie in der Luft oder in einem anderen Bauteil. Ein konventioneller Geometrie-Modellierer bemerkt diese Verletzung nicht, ein Feature- based Modeler kann dagegen in diesem Fall eine Warnung ausgeben oder, falls entsprechende Informationen hinterlegt sind, automatisch die Laenge des Sacklochs an die neuen Gegebenheiten anpassen.

Soviel ein Feature-based Modeler aus konstruktiver Sicht auch leisten mag, unter dem Aspekt einer geschlossenen Prozesskette (Konstruktion, Arbeitsvorbereitung, Fertigung) bleiben noch immer Anforderungen offen. Das gilt insbesondere dann, wenn vom NC- Programmiersystem eine automatische Feature-Erkennung gefordert wird. Bei Sackloechern stellt sich dieses Problem weniger, da sowohl der Konstrukteur als auch der NC-Vorbereiter ein solches als Feature (Formelement) ansehen.

Anders ist es jedoch bei Features, die der eine als solche erkennt, der andere jedoch nicht. Wenn ein Konstrukteur einem Bauteil eine Rippe hinzufuegt, entstehen auf beiden Seiten Taschen.

Der Konstrukteur sieht das Element "Rippe", der Arbeitsvorbereiter jedoch die beiden Taschen, die der Konstrukteur seinerseits selten bewusst wahrnimmt. Vielfach entstehen Taschen auch erst im Zusammenbau. Das Problem liegt also in der Umwandlung eines konstruktions- in ein fertigungsorientiertes 3D-Modell.

Als bisher einziger Softwarehersteller bietet Control Data mit "Icem Part" eine solche Funktionalitaet. Dieses Paket loest das konstruktionsorientierte Solid-Modell in einzelne Gestaltelemente auf, die unter Beruecksichtigung der gemeinsamen Kanten geordnet werden.

Alle Daten in einer Datenbasis

Der Software unterlegt ist eine Wissensbasis, in der Informationen zu den verfuegbaren Bearbeitungsmaschinen mit den jeweils erreichbaren Toleranzen, eine Methoden-Feature-Zuordnung (welches Gestaltelement ist mit welcher Bearbeitungsmethode herzustellen?), verfuegbare Werkzeuge und Werkstoffdaten abgelegt sind. Damit ist eine weitgehend automatisierte und optimierte Erzeugung der NC- Bearbeitungsprogramme moeglich.

Einen Schritt weiter gehen Produktmodellierer, die seit einigen Jahren in der Entwicklung sind, deren vollstaendige Realisierung jedoch bisher aus mehreren Gruenden unterblieb. Produktmodellierer sollen - so jedenfalls die Idee - saemtliche Daten und Informationen enthalten, die noetig sind, um die Entstehung und die Eigenschaften eines Produkts vollstaendig zu beschreiben. Das beginnt bei der Definition und Beschreibung des Projektablaufs, in dessen Rahmen ein Produkt entsteht, und endet bei der Erzeugung der Fertigungsdaten. Dazwischen liegen alle Disziplinen, die an Entwicklung, Konstruktion, Design, Simulation, Dokumentation und Vertrieb des Produkts beteiligt sind.

Produktmodellierer gehen von der Idee aus, alle dafuer benoetigten Daten in einer einzigen Datenbasis zu halten. Jede Disziplin greift auf die fuer sie relevanten Daten zu, erzeugt neue oder modifiziert sie. Das Prinzip ist vergleichbar mit dem relationaler Datenbank-systeme. Auch hier liegt - mit der Verknuepfung mehrerer Datenbasen - eine Vielzahl von Informationen vor.

Mit der Definition sogenannter Views greift sich jeder Anwender lediglich die ihn interessierenden Daten heraus. Deren Visualisierung erfolgt in einer der jeweiligen Applikation (Projektplanung, Entwicklung, Konstruktion, Analyse, Dokumentation etc.) adaequaten Art.

Man braucht nicht viel Phantasie, um sich vorzustellen, welch immense Datenmengen auf diese Weise erzeugt werden - ein Grund, der die Realisierung solcher Modellierer bislang verhinderte. Eng verbunden mit der Entwicklung von Produktdatenmodellierern ist die Definition der Step-Schnittstelle (Standard for Exchange of Product Data).

Welche Daten sind wirklich notwendig?

Bei beiden sind die gleichen Probleme zu loesen, naemlich zu bestimmen, welche Daten notwendig und welche hinreichend sind, um ein Produkt zu beschreiben. Beide Entwicklungen stekken in dem Zwiespalt, einerseits ein moeglichst allgemeingueltiges Modell aufzubauen (es waere sinnlos, fuer jede moegliche Produktgruppe einen eigenen Produktmodellierer zu entwickeln, und widerspraeche auch dem Grundgedanken), andererseits aber die Datenmengen in handhabbaren Grenzen zu halten.

Ein weiteres Problem von Produktdatenmodellierern ist die Datenbasis selbst. Die heute verfuegbaren relationalen Datenbanksysteme sind voellig ungeeignet, um Geometriedaten (CAD- Zeichnungen) zu halten, sie koennen diese bestenfalls verwalten. Dazu werden objektorientierte Datenbanktechnologien benoetigt, die aber erst seit relativ kurzer Zeit verfuegbar sind und im Moment noch an mangelnder Performance kranken. So verwundert es kaum, dass Produktdatenmodellierer bislang nur in Teilbereichen als Forschungsprojekte realisiert wurden, allerdings mit wachsenden Erfolgen, was nicht zuletzt auch auf die staendig steigenden Hardwareleistungen zurueckzufuehren ist.

Neben zahlreichen universitaeren Projekten wurde unter anderem von SNI im Rahmen eines Forschungsprojekts exemplarisch die Machbarkeit eines Produktdatenmodells auf Basis der Step-Notation (soweit bereits normiert) gezeigt. Als Testobjekt wurde ein komplettes PC-Towergehaeuse entwickelt und objektorientiert beschrieben. Die zugrundeliegende Datenbank war allerdings noch nicht objektorientiert.

Bereits zum heutigen Zeitpunkt zeigen alle bisher realisierten Projekte eines sehr deutlich: Produktdatenmodellierer werden nicht nur auf objektorientierten Datenbanken aufsetzen, sondern nahezu zwangslaeufig selbst objektorientiert sein. Fuer den Anwender bedeutet dies letztlich eine wesentlich vereinfachte Bedienung seiner jeweiligen Applikation, sei es "Konstruktion" (CAD), "Analyse" (etwa FEM) oder "AV" (NC-Programmierung), da die Daten ihre Bearbeitungsmethoden kennen und dem Benutzer nur die momentan sinnvollen Funktionen angeboten werden.

Wesentlich frueher als die Produktmodellierer wird eine andere Neuerung Einzug in die CAD-Welt halten: Man kann sie allgemein als objektorientierte Werkzeugkaesten bezeichnen. Fast zeitgleich stellten Anfang dieses Jahres die Softwareanbieter Computervision und Matra Datavision die Produkte "Pelorus Softstage" beziehungsweise "CAS.Cade/SF" vor.

Modularer Aufbau erleichtert Austausch

Beide verstehen sich als Entwicklungsplattformen sowohl fuer die herstellereigene Weiterentwicklung als auch fuer Applikationsprogrammierer. Mit diesen Toolboxen wird es kuenftig in weitaus groesserem Umfang als bisher moeglich sein, Anwendungssoftware auf spezielle Anforderungen des Endanwenders zuzuschneiden.

Diese Werkzeugkaesten stellen Tools wie Klassenbibliotheken zur Geometrieerzeugung oder zur Datenverwaltung bereit. Allen gemeinsam ist die weitgehende Modularisierung der unter diesen Plattformen geschriebenen Anwendungssoftware. Um diese Pakete auf andere Hardwareplattformen zu bringen, muss sie nicht mehr umgeschrieben und neu kompiliert werden. Es genuegt der Tausch des Hardware-abhaengigen Moduls.

Ebenso lassen sich neue Features hinzufuegen: Prinzipiell aehnlich den aus der Windows-Welt bekannten DLLs (Dynamic Link Libraries) wird ein entsprechendes Modul dazugeladen, und die neue Funktion steht zur Verfuegung. Sofern unter Windows und seinen Nachfolgern lauffaehig, kann die so erstellte Anwendungssoftware selbstverstaendlich auch die Windows-eigenen Datenaustausch- Mechanismen wie DDE und OLE nutzen. Damit ist eine enge Verzahnung von CAD-Funktionalitaet und Textverarbeitungs- oder Tabellenkalkulations-Funktionen moeglich.

Vorstufe zum Funktionsbaukasten

Beide Entwicklungen beruecksichtigen ausdruecklich das Step-Format. Da dessen Definition aber noch nicht abgeschlossen ist, muss man sich noch mit einer Datenstruktur begnuegen, die moeglichst eng an Step angelehnt ist.

Einen voellig anderen Weg beschreitet das Unternehmen Intergraph momentan mit seinen Neuentwicklungen beziehungsweise Entwicklungsankuendigungen. Dabei setzt man voll auf Windows und dessen Datenaustausch-Mechanismen. Die soeben vorgestellte Schnittstellen-Definition "OLE for Design and Modeling" ist als Vorstufe zu weiteren Entwicklungen, insbesondere OLE 3, zu betrachten.

OLE for Design and Modeling wird, wenn es in den entsprechenden Paketen implementiert ist, die direkte Einbindung von CAD- Zeichnungen oder -Modellen in andere Windows-Applikationen wie Textverarbeitung, Tabellenkalkulation und Grafikpakete erlauben, allerdings noch nicht deren Bearbeitung. Dabei ist es gleichgueltig, ob das Quellsystem mit einem zwei- oder dreidimensionalen Modell arbeitet und ob die Zielanwendung ein 2D- oder 3D-System ist. Als zusaetzliche Funktionalitaet gestattet es OLE for Design and Modeling, importierte Objekte transparent zu gestalten und auch mehrere Objekte gleichzeitig zu aktivieren.

Die naechste Stufe, "Jupiter Development Kit" genannt, wird - so ist es jedenfalls zur Zeit geplant - ein Entwicklungs-Tool mit einer gewissen CAD-Grundfunktionalitaet enthalten. Applikationsentwickler koennen dann in Visual Basic relativ einfach neue Funktionen schreiben und diese zu einem Gesamtpaket kombinieren. Fuehrt man diesen Gedanken konsequent weiter, dann koennten sich einige der Schnittstellen-Probleme, zu deren Loesung in der Vergangenheit eine Menge Entwicklungsaufwand betrieben wurde, in Luft aufloesen.

Die Entwicklungen von Computervision, Intergraph und Matra Datavision weisen auf alle Faelle in eine Richtung: Fuer das Gros der CAD-Anwendungen scheinen die Tage der monolithischen CAD- Systeme gezaehlt. Aus technologischer Sicht nicht mehr von der Hand zu weisen ist sogar die Vorstellung, dass sich CAD-Anbieter heutiger Couleur zu Herstellern von Funktionsbausteinen wandeln, bei denen der CAD-Anwender nur noch die fuer ihn passenden Module kauft.

* Eberhard Rademeier ist freier Fachjournalist in Heiligkreuzsteinach