From the earliest days of engineering, there has been a need to communicate information from the designer to the manufacturer.
Over time, the communication of design intent has become more formal. Descartes’ contribution was to give us Cartesian Geometry. Pencil and drawings have given way to the computer, graphics screens, plotters, and so on.
CAD (Computer Aided Design) is used routinely in most engineering disciplines, and the exchange of design information is an everyday part of the process. CAD data exchange has evolved over the past 20 years initially being focussed on drawings, and latterly incorporating model geometry and features.
In simple terms, features are named parts of CAD models. Typical features include Holes, Pockets, Fillets, and other identifiable parts of the model. An important aspect of features is that design intent can be encapsulated within them. Features are often associated with parameterisation, where dimensions are not simply measurements between distances, but can be used so that changing a dimension changes the shape of the part.
However, as CAD data translation appears to be becoming more and more complex, there is a body of opinion which says: ‘Who needs feature translation?’ and in fact, ‘Who needs CAD translation at all?’ It is being suggested that ‘interoperability’ will solve all these problems, and that CAD data translation will no longer need to take place.
Interoperability can be described as the ‘interactive communication of model changes between CAD systems’. This means that a designer working on an assembly can automatically see changes taking place on a component, as the component is modified.
However, interoperability, as we know it today, is dependant on CAD systems using the same kernel, so it is not possible to do this with systems that are widely different, such as CATIA and UG. By and large, interoperability between different CAD applications is a myth. Having said this, it is possible to achieve a level of interoperability between systems, which have the same kernel, such as Parasolid, or ACIS. Importantly, features are held at a level above the kernel, and interoperability between kernels excludes features.
Where it is claimed that features are included in interoperability between systems, translation is taking place to enable it. In addition, users will want interoperability between systems with different modelling kernels and for this to be achieved translation will have to take place. So, in fact, interoperability itself depends on successful CAD translation.
Shakespeare wrote: ‘A rose by any other name would smell as sweet’ and you could translate that into modern English as: ‘Interoperability smells like translation to me’.At Theorem we wanted to understand the CAD user’s thoughts on Feature translation, and we undertook a survey of over 10,000 users.
The users voted overwhelmingly for CAD translation to either incorporate Feature translation regardless, or incorporate Feature translation with the option of ‘turning it off’.
We can demonstrate the translation of features, we have some software in beta site testing, and we plan first product releases in the middle of this year. Beyond this there will be on-going development both in terms of function, and breadth.
Feature translation also raises new business challenges. It opens the door to inadvertently parting with more information than we wanted to. Feature translation raises the risk of giving away some of the information which is our added value.
This means good news for the large OEMs who have more than one ‘in-house’ system and good news for the Design Houses, again who might have more than one system and can now bridge design projects across more than one system. Is it good news for the SME in the supply chain? Does he really want to part with so much of his knowledge?