Article Archive Contact Features List 10

Media Pack Subscribe Privacy Policy

Construction Computing Online Training Map Recruitment

News

Case Study

From CAD User Mechanical Magazine  Vol 15 No 06 - JUNE 2002

In the second of two articles on Interoperability Andy Chinn, Applications Manager at Transcendata Europe, looks at the types and causes of interoperability problems

It is possible to break down interoperability problems into five categories, all of which overlap and relate to each other in most instances.

Structural
Structural problems concern the form of the model and whether or not the entities are defined and linked together correctly. For example a model that should be a solid might only exist as a surface (or, worse still, wire frame) model in the target application. Problems can be caused by the use of a different class of modeller (wire frame, surface, solid or hybrid) or simply due to the export process from the source system not being fully understood.

Figure 1 is a simple example of a structural interoperability problem. The model starts life as a solid component in the source CAD system, but it is exported to the downstream FEA user without the solid definition and with all construction geometry in the file. Naturally, the CAD user just pressed the button to export, letting the system take care of matters!
The downstream FEA user has to decipher and extract a solid, or may just decide to recreate the component for analysis purposes from scratch - easy, perhaps, for this component, but would it be acceptable from the QA perspective of the customer? And it is totally impractical on a large component such as an engine block. 

ACCURACY
This is perhaps the cause of most interoperability and re-use problems and stems from the fact that different CAD systems either work in a range of fixed tolerances, or they provide a variable tolerance capability that allows the users to change how accurately they work. Some systems work in absolute tolerances such as 0.005mm or 0.01mm, others work to tolerances relative to the size of the model, say 10-4 times the model size, some work in different tolerances with respect to the units used, whilst others ignore the units altogether!

The net effect of this is that models can exist quite happily in a more tolerant modelling system but will simply disintegrate in a receiving system if the tolerances are too loose, and the entities are seen as disconnected and outside the required tolerance. There are also serious design intent issues, where a short edge or small face exists in one system, but is swallowed up by a larger tolerance in a downstream receiving system.

Realism
Typical realism issues relate to whether or not the model is realistic and can physically be manufactured. Such problems can often be attributed to features in a CAD model such as knife-edges, thin sliver faces, solids with internal voids, cracks in solids and pinched faces where material thickness approaches zero.

Causes can be user or system created and could be anything from a misplaced solid in a Boolean operation that will leave a thin lip or ridge, or the 'drilling' of a hole in the CAD model of an engine that extends too far and cuts a drill tip profile in a cylinder wall. CAD system failure can also cause realism problems. For example, the failure to perform a solid modelling operation correctly might leave a modelling artefact, such as a void within a solid.

System Limitations
The CAD systems and their underlying modelling kernels have different capabilities and levels of complexity that can be supported in terms of the tolerance requirements, mathematics and complexity of geometrical entities possible in the model.

A CAD system with an ability to produce highly accurate general 3D surfaces also has a tendency to produce very highly defined surfaces with thousands of points. Such surfaces can cause a considerable overhead in terms of model size and application times, and in some cases the definitions are too unwieldy to handle downstream.

It is also common to find overly complex geometry that can be simplified to basic primitive surfaces such as planes, cylinders, cones and spheres within the tolerances required in the receiving system. Figure 2 shows an example of a single surface which is overly defined and that can be represented by a much more basic definition within a required analysis tolerance.

As well as the level of complexity that is acceptable to a given system, there are also differences in terms of what a system classes as invalid geometry definitions. A good example is the generation of what are technically invalid three sided degenerate NURBS surfaces.

Some systems allow the creation of such entities, others will reject them, whereas some systems know that they are not permissible and in an effort to prevent them from being created, generate twisted four sided surfaces!
Other differences in the levels of complexity include the continuity of surfaces and edges and whether a particular CAD system sees them as discontinuous or not. A surface might be fine in one system but a perceived discontinuity in a downstream system may lead to a translation error or an application failure where the mesh generated on a discontinuous surface is unacceptable for analysis.

The differences between today's 'tolerant' modellers and other systems are also a source of problems. It is possible to create a valid model in a tolerant system that translates perfectly between all systems based upon that modelling kernel. However, as soon as that model is exported out of the common tolerant modelling environment serious underlying issues can be uncovered.

Translation and Automation
During any form of translation there is scope for data to be misinterpreted and badly translated. The standards for CAD data translation such as IGES and STEP are often implemented differently in all systems that have their own interpretations, ambiguous representations and sometimes plainly incorrect entities. Systems will also have varying levels of support for the range of entities in a given standard. All of this gives rise to potential problems in the translation process, especially when undertaken fully automatically.

An excellent analogy to draw here is that of language translation. Give any document to a set of three language translators and the result will most likely be three different documents. They all contain the same message and are more or less accurate, but none of them are exact representations of the original data.

Basically all systems are different in some respects and this means there is massive scope for introducing interoperability problems, which invariably appear in downstream applications.

The image in Figure 3 demonstrates a combination of realism, accuracy and system dependant interoperability problems. A simple CAD part is successfully translated between two systems in a seemingly perfect translation process with no warnings, errors or failures reported. The downstream FE analyst attempts to mesh the part but persistent meshing failures mean that considerable time is spent trying to solve the interoperability problems.

The cause of the problems in this example is a small thin face as shown, and the most likely source would be a misplaced solid during a Boolean joining operation, resulting in a small feature being created which is perfectly acceptable and within tolerance of the originating CAD system. The downstream user is faced with removing this edge by defeaturing the model, and although this may well be acceptable because of the relative sizes, there will be other instances where changes required bring into question design intent.

Each of the problems outlined above can be enough to scupper a data transfer process. As if that were not bad enough, however, the process itself is replete with things that can go wrong, even in an organisation that recognises data interoperability as an issue and has tried to do something about it. CU
www.transcendata.com

Case Study

Click here for a Print Friendly Version

©2006 Business and Technical Communications Ltd. All rights reserved.
No part of this site may be reproduced without written permission of the owners.
www.CADUser.com