Relational Design is the capability, for several users working with CATIA 3DEXPERIENCE, to concurrently design complex parts, in context of configured products and taking into account relationship between these parts.

In the following short video, you can see how a design modification performed by an architect impact a set of mechanical parts (spars, ribs, etc...) inside the wing of an aircraft.

Let's now have a look at a little bit more complex aerospace scenario, described in this picture

One of the main concept needed to create all these data is the usage of skeleton parts.

The skeleton approach is a design methodology which has been adopted by many industries for designing their products.

The skeleton of a part or a product is a specific set of features (geometries and/or parameters) which represents its “functional” main characteristics. For instance the main axis, the main planes, the external shape or surfaces, etc...

The methodology consists then in creating in dedicated 3DParts or 3DShapes

• “functional specifications” (wireframe/surfaces geometries and/or parameters), which are the main specifications/characteristics of the product to be designed
• interfaces between parts of products allowing to put in position and to design all the 3DParts of the product
• other specifications (space reservation, etc…) and properties that can be used to design this Part or Product.

When designing a product, using this skeleton approach allows

• to distribute design specifications through the product structure, and then provide a clear way to create structured, easy to understand and reusable products.

• to create autonomous and self-sufficient products which can be opened and used alone, without needing opening too many unnecessary data.

• to ease the design of parts and products: user only see necessary information.

• to avoid creating unwanted links between parts and products which should not be linked together.

• to easily understand impacts of a modification and then

• either automatically update driven parts and products

• or easily control update propagation

Back to our scenario, as soon as the Aircraft Architect has defined a first version of his Aircraft Skeleton, the Wing Architect can create his own Wing Skeleton,

• first by importing needed published geometries and parameters coming from Aircraft Skeleton (and checking links using Impact Analysis)

• and then by creating his design and publishing geometries and parameter needed by the Mechanical Engineer to define his Mechanical Parts in position.

Using the same kind of approach, the Mechanical Engineer is then able to design all his Mechanical Parts in the wing, based on Wing Skeleton.

Now that all the products, parts and links have been defined, the beauty of Relational Design appears:

when the Wing Architect modifies his design, he can see which Mechanical Parts are impacted (and which ones are not),

and then the Mechanical Engineer can perform, on demand, the synchronization and update of his parts.

More to come on this amazing topic...