The Beauty of Relational Design in CATIA 3DEXPERIENCE
Join us on our 3rdsession of CATIA at 12:00 PM ET! Click here for more info!
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.
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.