Produktionssysteme

Entwicklung modularer KBE-Applikationen

Dr.-Ing. Oliver Strohmeier Duisburg

Information und Wissen haben sich in unserer heutigen Gesellschaft zu entscheidenden Wirtschaftsfaktoren entwickelt und verlangen eine konsequente strategische Bewirtschaftung im Rahmen eines Wissensmanagements. Innerhalb der Produktentwicklung lässt sich in diesem Zusammenhang ein zunehmender Trend zu dem Knowledge-Based-Engineering (KBE) erkennen, um produkt- und prozessspezifisches Wissen in integrierter Weise zu erfassen und wiederzuverwenden [Str06].

Das Knowledge-Based-Engineering – oder zu Deutsch die wissensbasierte Konstruktion – beschäftigt sich mit der Einbindung von Expertenwissen in den computergestützten Konstruktionsprozess und kann als Weiterentwicklung der Feature-basierten Konstruktion verstanden werden. Die Entwicklung und spätere Pflege von KBE-Anwendungen stellt für viele Unternehmen ein sehr hohes Investitionsrisiko dar. Betroffen sind vor allem kleine und mittelständische Unternehmen.

Mit dem Ziel, KBE-Lösungen für Unternehmen attraktiver zu gestalten, entstand eine neue Methode zur Entwicklung wissensbasierter Ingenieursanwendungen. Mit Hilfe der neuen Methode können KBE-Systeme durch »bloßes« Kombinieren von vorhandenen oder zugekauften »Bausteinen« erstellt und damit die Entwicklungszeit und die Investitionskosten deutlich gesenkt werden. Jeder Baustein des Systems erfüllt eine klar definierte und abgegrenzte Teilaufgabe und leistet einen Beitrag zur Lösung der übergeordneten Gesamtaufgabe. Klar definierte Schnittstellen beschreiben die benötigten (IN) und bereitgestellten Informationen (OUT) eines jeden Moduls. Das notwendige Wissen bleibt dabei in Form von Regelwerken im Inneren der einzelnen Module verborgen (hidden) und kann mittels der Moduldefinition klar voneinander abgegrenzt werden (Bild 1).

Anzeige

Kommunikation zwischen einzelnen Wissensmodulen genügt jedoch nicht, die Komplexität anwendungsspezifischen Wissens gezielt abzubilden. Hierzu muss zusätzlich die Hierarchie von Wissen berücksichtigt werden. In dieser Hierarchie steht das wertvolle (unternehmens-) spezifische Wissen ganz oben. Dieses wird aus dem darunter liegenden so genannten generischen Wissen gebildet, das wiederum auf allgemeingültigen Wissensressourcen aufbaut (Bild 2).

Software-technisch genügt es, verschiedene Modultypen zu definieren und ein entsprechendes Umfeld für die Modulinteraktion zu schaffen. Module der obersten Hierarchiestufe dienen als direkte Schnittstelle zum Anwender (Client) oder zu übergeordneten Applikationsteilen Diese generieren letztlich die Gesamtlösung, sind jedoch dabei auf die Dienste untergeordneter Module angewiesen. Zur Abbildung des generischen Wissens wurden so genannte Intermediate-Module eingeführt, die sowohl Dienste bereitstellen als auch zur Lösung ihrer Aufgabe wiederum auf Dienste der Backend-Module zurückgreifen können, die als Server grundlegende Dienste beziehungsweise Lösungen bereitstellen (Bild 3).

Wissen und vor allem das technische Wissen zeichnet sich durch seine starke Problembezogenheit aus. Für ein bestimmtes Problem oder eine definierte Aufgabenstellung existiert eine minimale Menge an Wissen, die zur Lösung benötigt wird. Diese Wissensmenge ist in der Regel erst dann bekannt, wenn die Aufgabe vollständig gelöst ist. Das liegt unter anderem daran, dass während des Lösungsprozesses neues Wissen entsteht. Liegt dieses Wissen einmal vor, so können mit dessen Hilfe ähnliche oder verwandte Aufgabenstellungen bearbeitet werden. Wissen wird somit wiederverwendbar.

Die folgende beispielhafte Anwendung soll die neu entwickelte KBE-Methode und konkret das Ziel der Wiederverwendung eines einzelnen Wissensmoduls verdeutlichen. Sie bezieht sich auf Arbeitsergebnisse des AiF-Forschungsvorhabens zur »Integrierten Produktmodellierung von Sonderformen im Behälter- und Rohrleitungsbau« [AiF01] und deren anschließende Software-technische Umsetzung zu der durchgängigen Brachenlösung von Megatech Software GmbH »MegaCAD SF« (Bild 4) bis zur Marktreife [MC03]. Wesentliche Voraussetzung für eine Wiederverwendung ist die Definition des Funktionsumfangs und der entsprechenden Schnittstellen. Dabei ist es nicht notwendig, die gesamte Applikation zu betrachten beziehungsweise zu kennen. Ein lokales Umfeld, innerhalb dessen sich die umzusetzende Modulentwicklung einordnen lässt, ist ausreichend.

Nicht weiter zerlegte oder betrachtete Applikationsteile werden dabei als Black-Box behandelt. Diese Vorgehensweise ist durch die Modularisierung der Gesamtapplikation gerechtfertigt, die es ermöglicht, einzelne Applikationsteile getrennt voneinander zu entwickeln und zu testen (Bild 5).

Das Mantellinienverfahren stellt hier eine Einzellösung dar, mit der sich eine bestimmte Form von Geometrie erzeugen lässt. Aus zwei Anschlussquerschnitten in Form von Kanten oder Kurven wird unter Berücksichtigung vorgegebener Erzeugungsparameter eine abwickelbare Mantelfläche erzeugt. Dazu muss die eingehende Geometrie eventuell zunächst auf ihre Eignung geprüft und anschließend noch aufbereitet werden. Ebenso kann eine nachgeschaltete Geometriekontrolle, die die Qualität der erzeugten Flächen sicherstellt, sowie weitere Erzeugungsverfahren, wie das Verfahren der tangentialen Hilfskugel oder das Kugelabschnittverfahren, zu Elementen der Geometrieerzeugung gerechnet werden. Durch die Restrukturierung unter den Aspekten der Wiederverwendung wird die Isolierung des Mantellinienverfahrens aus seiner übergeordneten Struktur möglich. Hierbei spielen die entstehenden Schnittstellen im Informationsfluss eine entscheidende Rolle, die zu diesem Zeitpunkt der Entwicklung hinreichend bekannt sein sollten. Am Eingang des Mantellinienverfahrens – als isolierte Einzellösung – liegen die zu verbindenden Querschnitte in einer aufbereiteten geometrischen Beschreibungsform – konvexe stückweise planare Kurven – sowie die für das Verfahren spezifische Erzeugungsparameter an – zum Beispiel die Verfahrensvariante und die Genauigkeit.
Hier muss in jedem Fall sichergestellt werden, dass die eingehenden Daten von dem Verfahren verarbeitet werden können. Dazu gehören neben der Vollständigkeit auch die Konventionen über die jeweiligen Datenformate. Nach der Verarbeitung wird am Ausgang eine Mantelfläche in der gewünschten Beschreibungsform und Genauigkeit erwartet, beispielsweise Dreiecks-, Viereckssegmentierung oder NURBS-Flächen. Dabei muss gewährleistet sein, dass die erzeugte Mantelfläche von nachgeschalteten Funktionen weiterverarbeitbar ist. Hier gilt gleiches in Bezug auf Vollständigkeit und Formate (Bild 5). Zur Integration in Anwendungen werden die genauen Spezifikationen eingehender und ausgehender Daten über die zu definierende Schnittstelle sowie der Funktion des Moduls vorausgesetzt. Bei dem Mantellinienverfahren sind die allgemeinen geometrischen Beschreibungen der zu verbindenden Querschnitte die notwendigen Eingangsdaten. Hinzu kommen Parameter zur Steuerung der Genauigkeit und des gewünschten Verfahrens. Die allgemeine Flächenbeschreibungen der erzeugten Geometrie dienen als Ausgabedaten.

Die Implementierung der Funktion erfolgt durch die Abbildung der Eingangsdaten auf die Ausgangsdaten, innerhalb derer die entsprechende Geometrie erzeugt wird. Die Übertragung der Funktion auf ein entsprechendes Modul führt zur Definition einer Modulschnittstelle für übergebene und zurückgegebene Werte sowie zur Modulimplementierung, die die Funktionalitäten realisiert. Die Schnittstelle bildet die Verbindung des Moduls zu anderen Teilen einer Applikation und sollte im Sinne der Wiederverwendung möglichst allgemein gehalten werden. Für die übergebenen Parameter, wie Genauigkeit und Verfahren, stellt sich hier kein Problem ein, da diese Werte als Standardtypen, beispielsweise Integer (ganze Zahlen), definiert werden können. Anders verhält es sich mit dem Umgang mit geometrischen Datenstrukturen. Diese können in der Regel nur über ihre Objektreferenzen übergeben werden. Die Objekte selbst verbleiben dabei in dem geometrieverarbeitenden Systemteil, zum Beispiel im integrierten CAD-System. Funktionsaufrufe zur Erzeugung und Manipulation von Geometrie, etwa zur Erzeugung einer einzelnen Dreiecksfläche (Make_Face_3_Pts), benötigen eine jeweils spezifische Übersetzung in die Sprache des Geometriekerns, die mit Hilfe eines Wrapper-Moduls verwirklicht wird. Das Bild 6 zeigt die entsprechende Implementierung auf Basis des Geoemtriekernels ACIS (Programmiersprache: C++), der auch für MegaCAD verwendet wird. Ein solches Wrapper-Modul sollte dabei mindestens den zur Erfüllung der Aufgabe notwendigen Befehlssatz an geometrieerzeugenden und -verarbeitenden Funktionen enthalten. Dabei ist es wichtig, dass dieser Befehlssatz bezogen auf die Kommunikation mit der Applikation einen Standard darstellt, um eine Unabhängigkeit von Geometriekernel oder CAD-System einschließlich der Programmiersprache zu gewährleisten. Beispielsweise kann die gleiche Funktion zur adäquaten Erzeugung einer Dreiecksfläche aus drei Punkten über die API von Catia V5 (Sprache: Visual Basic) realisiert werden. Die so definierten standardisierten Funktionsaufrufe werden über eine Exportschnittstelle des Wrappers als Dienste zur Verfügung gestellt, so dass sie aus der gesamten Applikation heraus verwendet werden können. Durch diese Technik wird eine einfache Anpassung der Applikation an verschiedene CAD-Systeme beziehungsweise Geometriekernels erreicht.

Durch eine weitere Zerlegung der Aufgabe zur Erzeugung einer biegeumformgerechten Mantelfläche und eine anschließende Restrukturierung der lokalen Lösungsstruktur ist es alternativ möglich, für das Kernproblem der Aufgabe ein Modul abzugrenzen, das auf keine weiteren Dienste angewiesen und somit universell einsetzbar ist. Anstelle von Querschnitten dienen als Eingangsdaten die Punktefelder aus der Diskretisierung der Querschnitte. Die zurückgegebenen Mantellinien, die in Abhängigkeit von dem Verfahren die Mantelfläche repräsentieren, werden mittels ihrer Anfangs- und Endpunkte beschrieben und zu einer Struktur zusammengefasst. Diskretisierung und Flächenmodellierung müssen dann in Form eines Pre- und Postprocessing von anderen Applikationsteilen übernommen werden.

In der weiteren Entwicklung des Moduls wird die Lösung zur Erzeugung der Mantellinien, auf die hier nicht weiter eingegangen werden soll, formalisiert und Software-technisch implementiert. Die Schnittstellenbeschreibung erfolgt über die Spezifikation des angebotenen Dienstes mit Hilfe der sytemunabhängigen Interface-Definition-Language (IDL). Hieraus werden in Abhängigkeit von der Programmiersprache des jeweiligen Moduls (hier C++) die Server- und Client-seitigen Schnittstellen- objekte compiliert. -fr-


Literatur
[Str06] Strohmeier, O.: Integration von Wissensmodulen in den virtuellen Produktentwicklungsprozess. Dissertation. Shaker Verlag, Aachen 2006.

[MC03] Köhler, P.; Strohmeier, O.: Integration von konstruktiv/geometrischem Modellierungswissen des Behälter- und Rohrleitungsbaus in das System MegaCAD. Abschlussbericht. Duisburg 2003.

[AiF01] Köhler. P.; Strohmeier, O.: Aif-Vorhaben: 12217 N / 4: Integrierte Produktmodellierung von Sonderformen im Behälter- und Rohrleitungsbau. Abschlussbericht. Duisburg 2001.

Anzeige

Das könnte Sie auch interessieren

Anzeige

Big Data

Wissensmanagement im 21. Jahrhundert

Europa verschläft den Trend Big Data – die Industrie hinkt bei Big Data hinterher – fast täglich finden sich neue Meldungen zu dem Trend-Thema in den Medien. Doch wie können Unternehmen diese Thematik zu ihrem Vorteil nutzen?

mehr...

Software

Mehr Varianten in kürzerer Zeit

Um komplexe Satellitenentwürfe schneller bewerten zu können, setzt der Raumfahrtspezialist Astrium die Femap-Software von Siemens PLM Software ein. Simulationsmodelle lassen sich auf diese Weise schneller zusammenstellen und die Ergebnisse zügiger...

mehr...

Smart Industry

Wissen auf Knopfdruck

Oliver Brauer, MünchenUm Unternehmenswissen verfügbar und auffindbar zu machen, sind die logische Integration von Daten- und Dokumentbeständen sowie eine intelligente Suche notwendig. Für die Fraunhofer-Gesellschaft wurde durch Wissensmanagement...

mehr...

Datenanalyse

Automatisierter Rechnungseingang

Qurius (DMS und IT-Integration) und Ricoh (Hardware-Hersteller) haben eine gemeinsame Lösung für den Rechnungseingangsworkflow entwickelt, die den kompletten Dokumentenfluss bei den Beschaffungsvorgängen erheblich beschleunigen soll.

mehr...
Anzeige

MES

Die richtigen Daten in die Cloud

Das neue trendige „SaaS-Konzept“ (Software as a Service) ist ein kundenorientiertes Prinzip. Die Software liegt bei einem externen Dienstleister und der Kunde bezieht lediglich den Service der Dienstleistung, ohne sich um Hardware Gedanken machen zu...

mehr...