Bringing the past to the present

5 mins read

Interoperability has been a nightmare since the early days of CAD/CAM. But there are now robust solutions, says Dr Charles Clarke

Until fairly recently the CAD/CAM interoperability nightmare has been confined to the machine shop or the analyst's office. Data translation only reared its ugly head for designers when the incumbent CAD system was dumped in favour of a new one and legacy data became an issue. However, with the advent of globalisation, collaborative working and PLM (product lifecycle management), CAD interoperability is now very much a designer's and a business' challenge. "It is amazing the lengths that people go to to avoid having to convert or translate data," says Peter Thorne of industrial software analyst Cambashi, "because experience tells them it is the source of endless pain. But the good news seems to be that geometry translation technologies are gradually getting the upper hand on a problem that always seems to turn out to be so much more difficult than it at first appears – TrancenData's CADFix actually works!" According to John Meaney, sales director at TranscenData: "Our own research suggests that 20% of a typical NC programming job is spent preparing data for processing, a figure that rises to 70% for FEA [finite element analysis] or CFD [computational fluid dynamics] activities. This is crazy – highly qualified engineers being paid to answer complex questions, but spending two-thirds of their time second-guessing design intent and patching up messy CAD models." Over the years there has been a multitude of approaches to legacy data and interoperability. One of the first efforts was neutral file formats of which IGES was – and for some applications still is – a popular approach. Success with IGES depended on the compatibility of the translators in the native and target systems. If you were lucky it worked 95% of the time, but you could bet your job that it would fail when you were under pressure and you had no time to fix it. STEP is the modern neutral format for 3D data, but it has taken an age to come on stream and its effectiveness 'stand alone' is patchy at best. The popularity of Autodesk DXF has largely been due to the shortcomings of neutral formats. But all these solutions are just basic geometry translators – none of the model intelligence or attributes come through by these routes. These uncertainties prompted Dave Burdick, the celebrated CAD pundit, in the 1990s to suggest that the only 100% certain form of data translation was like-for-like. And if you want relatively 'stress free' interoperability this still holds today. Sadly, that usually means the exact same revision of the CAD software and the operating system and, in many cases, exactly equivalent hardware, especially in a Windows environment. An attempt to mimic like-for-like comes from the geometric kernel approach. Systems using the ACIS or Parasolid geometry kernels output SAT or XT files which can be read by other systems based on these kernels. The approach is better but still not 100%. As each developer develops in isolation, albeit using a common set of ground rules, there is still scope for interpretation, which can lead to incompatibilities. Can't even load? "We've got our own legacy problems in working with a long-time customer," says Ian Dampney, founder and managing director of Random Design. "We've just pulled out CAD data from 1992. It's obviously 2D data, and it's pretty much borderline whether we can use any of it or not. We have product in the market that goes back to the days of our first 2D CAD system in 1985. There is no way that this early 2D data could even be loaded on a modern machine let alone be of any use. "This data was never moved across to the system that replaced it, again 2D [HP MP-10]. As it turned out, that hasn't been a problem, but in truth, for safety's sake and to protect the client, we should have moved it across. However, at the time you're so busy dealing with the problems of the day, it doesn't occur to you that this old stuff could possibly be of use 20 years later. Also, we didn't have sufficient appreciation at the time for the longevity of the product we were creating." It's a common enough cry. Meanwhile, archiving for military purposes tends to focus on 2D drawings because the military are more concerned with the visual representation of parts and assemblies for identification purposes. Very little of that data is concerned with manufacturing, and you have to cascade down through the drawings to get to any manufacturing information. Which is bad news. "Also drawings that we've been given from a military archive have not been accurate," comments Dampney, "because there's nobody checking the accuracy of the manufacturing data. Plus they are 2D and they won't be accurate by definition. Things like aircrew visors – plenty of 2D drawings exist, but you would be very hard pressed to match a drawing to an existing physical product. The electronic razor blade is even worse than using a physical razor blade to modify a drawing because it leaves no telltale evidence that the dimensions have been tampered with." Best advice in dealing with the legacy data is to get it transferred to the new environment as fast as possible by the most direct route. "If you can't afford a full translation, as an absolute minimum it's essential to develop a process that will import all legacy data to the new system as effectively as possible," advises Dampney. "Only 6–10% of legacy data is ever reused, but you can bet your job that the data that you need will not be in the 6–10% you thought you would need!" In fact, because it's difficult to second guess what legacy data might be needed, and a full conversion is so expensive, an alternative strategy is to ignore the whole legacy problem. If somebody needed legacy data on a particular product, it could be recreated in the new system by reverse engineering the existing product. "In many ways this is a far better approach," agrees Dampney, "because using original CAD data often means you've lost track of 'on the hoof' alterations that were never documented anyway. Slight changes by the toolmaker, slight changes in the fit, all of which would never have made it back to the original model or drawing. I would suggest it's worth taking the risk of re-engineering, because it also gives you 'as manufactured' rather than 'as designed'." But this raises significant questions about the importance of maintaining design authority. "As a design consultancy we retain design authority and act as controller of the data for some specific products or components of products," explains Dampney. "Any changes should be via us and we control data issue levels. If we issue data for incorporation into an assembly we do not want anyone to change it." It's getting better Meanwhile, Theorem Solutions provides web-based translation facilities using CADVerter.com, a dedicated conversion portal. "Cadverter.com is the world's first comprehensive e-engineering data exchange bureau service," says Stuart Thurlby, managing director. "It is quick and easy to use, and helps hard-pressed design engineers free up valuable time to devote to the core aspects of their work." Then again, casting manufacturer QDF Components of Derby is using CADfix to help its engineers work more effectively with CAD data from a wide range of blue-chip clients. QDF is a ThyssenKrupp Automotive company whose customers include Ford, Perkins, MG Rover, Saab, Johann Hay, Aztec, Gil-Mar, Balfour Beatty and Volvo. Ian Warhurst, project engineer at QDF is very bullish about the benefits: "The average time from receiving a customer's CAD data to having a Pro/E solid model has reduced from eight hours down to half an hour. The average number of models which were previously impossible to repair has reduced from one per month to none." CADfix has also afforded greater benefits than Warhurst and his team expected: "We have been delighted to realise that – simply because of our capability to work efficiently with our customers' first choice file format – we are actually able to generate more business for the company." John Meaney sums the situation up nicely. "We are still a long way away from true engineering data interoperability, but the situation is improving all the time. The technology is becoming more sophisticated – and in some cases more tolerant – and better working practices and automation will help still further. It may be that the holy grail of universal interoperability is not such an impossible dream."