Intelligentes Standardisieren, Teil 5

Auf der Grundlage der in den vergangenen Artikeln dargestellten Richtlinien und Prinzipien lassen sich sehr leistungsfähige, voll-parametrische und standardisierte Subsysteme als Intelligent Engineering Templates (IET) erstellen. Dazu sind zunächst die Standard-Funktionalitäten eines modernen CAD-Systems völlig ausreichend; Zusatzlizenzen, die viele Hersteller für KBE anbieten, sind erst einmal nicht erforderlich.

Das folgende Beispiel behandelt die Befestigung eines Hydraulikzylinders, hier zylinderseitig, wobei die Kolbenseite sich zwar maßlich, nicht aber prinzipiell unterscheidet. Es gibt in diesem Fall vier unterschiedliche Arten, den Hydraulikzylinder zu lagern:

mit einem einfachen Querbolzen,

mit einer Lagerbuchse (Bild 1),

mit einem Schwenklager (Bild 2, der Querbolzen selbst ist nicht Bestandteil des Lagers) oder

ohne Lagerung (Bild 3).

Dabei müssen einerseits einige Dimensionen des Lagers durch das eingesetzte Schmiedeteil des Hydraulikzylinders gesteuert werden. Andererseits müssen in diesem Schmiedeteil, je nach Lagerart, unterschiedliche Freimachungen vorgesehen werden. Bild 4 zeigt den Schnitt mit einer einfachen Lagerbuchse, Bild 5 mit Schwenklager; man erkennt die unterschiedlichen Ausdrehungen für das Lager selbst und für den Hinterschnitt des Sicherungsrings. Die zyklische Abhängigkeit, die sich hier vordergründig ergeben würde, kann, wie im Folgenden gezeigt wird, vermieden werden. All das soll automatisch sicher gestellt werden und darüber hinaus sollen Art und Größe der Lagerung durch einfaches Parametrieren beziehungsweise Austauschen der Lagerungs-Komponenten ohne weitere konstruktive Eingriffe geändert werden können. Das ist eine anspruchsvolle Aufgabe, die einer wohl durchdachten Struktur und – vor allem – einer sauber standardisierten Schnittstelle zwischen Hydraulikzylinder und Lager bedarf.

Zunächst müssen die Lager im Sinne der Komponenten-Denkweise als jeweils autonome, gekapselte Subsysteme definiert werden. Dabei ist besonderes Augenmerk auf den Einbauraum des Lagers zu richten, welcher im Lager selber und nicht im Einbauort definiert wird. Das Schwenklager muss im Schmiedeteil gehalten werden, und so kommt ein Sicherungsring hinzu, der natürlich ebenfalls einen Raumbedarf hat. Zusammen ergeben diese beiden Raumbedarfe den Gesamtbedarf für diese Lagerart so, wie er in Bild 6 dargestellt ist. Zu beachten ist, dass der Raumbedarf veröffentlicht (im Beispiel Catia V5) und so der ›Außenwelt‹ zugänglich gemacht wird.
Bild 7 zeigt schematisch die Struktur des Schwenklagers. (In den schematischen Darstellungen der Strukturen sind Baugruppenkomponenten dunkelblau und Teilekomponenten grün dargestellt. Mit ›CA‹ sind die Komponentenadapter im Sinne der Komponenten-Denkweise gekennzeichnet. Die dunkelroten Steuerungen sind im gezeigten Beispiel Teile; das kann aber in unterschiedlichen CAD-Systemen unterschiedlich gehandhabt werden. In Catia V5 beispielsweise ist das so erforderlich; Pro/Engineer kann hingegen Steuerungsgeometrie beziehungsweise -parameter in der Baugruppe selbst speichern und benötigt daher kein separates Teil dafür. Mit ›RB‹ ist der nach außen zur Verfügung gestellte Raumbedarf der Komponente gekennzeichnet.)

Etwas einfacher ist die Lage, wenn eine einfache Lagerbuchse verwendet werden soll. Auch diese hat einen Raumbedarf, der sich aber in einer einfachen Bohrung erschöpft und auch dieser wird unter demselben Namen (RB) wie der des Schwenklagers veröffentlicht (Bild 8).
Die Lagerung durch einen Querbolzen hat gar keine physische Komponente, sondern nur die Bohrung als Raumbedarf, die wiederum veröffentlicht wird (Bild 9).

Schließlich bleibt die Variante ganz ohne Lagerung, in der eigentlich gar kein Raumbedarf entsteht. Um aber eine einheitliche Schnittstelle für alle Lagerarten zu gewährleisten, wird auch hier ein Raumbedarf definiert und publiziert. Allerdings beschränkt sich dieser im vorliegenden Beispiel auf eine Bohrung, die deutlich kleiner ist, als das Querloch im Schmiedeteil, die also geometrisch keine Auswirkung hat.

Wichtig ist, dass alle vier Varianten dem übergeordneten Zusammenbau die identische Schnittstelle bieten. Deswegen werden sie so ausgeführt, dass jeweils ein Volumenkörper namens ›Raumbedarf‹ (RB) zur Verfügung gestellt wird. Das strukturell übergeordnete System nimmt dieses Volumen ›zur Kenntnis‹ und verarbeitet es weiter, etwa in Boole‘schen Operationen im Schmiedeteil. Einen Austausch des Lager-Subsystems ›bemerkt‹ das übergeordnete System überhaupt nicht, weil sowohl die Komponentenbezeichnung des Subsystems (Lagerung Subsys) als auch der bereitgestellte Raumbedarf (RB) sich dabei namentlich nicht verändern.

Umgekehrt steuert das übergeordnete System das Lager-Subsystem beispielsweise durch einschlägige Parameter. Diese Parameter muss das übergeordnete System nach wohldefinierten Standards bereitstellen, so dass das Subsystem diese zuverlässig abrufen kann. Hier ist es nicht mehr erforderlich, dass das Subsystem alle betreffenden Parameter abruft; nur diejenigen, welche es abrufen möchte, müssen verfügbar sein. Für das übergeordnete System bedeutet das, dass stets alle Parameter zur Verfügung gestellt werden müssen, auch die, die eventuell im Einzelfall nicht gebraucht werden.

So ergibt sich letztlich eine Schnittstelle zwischen dem übergeordneten System und dem Subsystem, die es erlaubt, beliebige Subsysteme einfach auszutauschen, ohne dass dabei im übergeordneten System oder im Subsystem irgendwelche weiteren Maßnahmen getroffen werden müssten. Bild 10 zeigt beispielsweise die Struktur der Befestigung mit Lagerbuchse, Bild 11 die mit Schwenklager; man erkennt, dass in beiden Fällen die Schnittstelle zum übergeordneten System identisch ist.

Die aus der objektorientierten Denkweise bekannten Prinzipien der Kapselung (›Privacy Principle‹ oder ›Geheimnisprinzip‹) und der standardisierten Schnittstellen (›Public Interface‹) sind allerdings strikt einzuhalten. Außerdem ist auf einen streng baumorientierten Informationsfluss im Gesamtsystem zu achten (Bild 12). Das Subsystem erhält die erforderlichen Informationen (Parameter, Geometrie) ausschließlich von ›seinem‹ unmittelbar übergeordneten System und es gibt Informationen ausschließlich an unmittelbar benachbarte Komponenten weiter. Weiter ›entfernte‹ Komponenten können nicht direkt mit dem Subsystem kommunizieren. Fazit: Durch standardisierte, wiederverwendbare und einfach austauschbare Konstruktionskomponenten können die Konstruktionssicherheit und die Produktivität signifikant erhöht werden. Ohne standardisierte Nomenklatur und Struktur, wie sie in den vorangegangenen Artikeln beschrieben wurden, ist das allerdings nicht umsetzbar. -co-

Smardcad Deutschland GmbH, Ulm, Tel. 0731/15902-0, www.smardcad.de