CAD data exchange – interoperability – or whatever it gets called next is not a straightforward process and this is an attempt to help people side-step common problems. It isn’t intended to be the definitive guide to data exchange. It is a list of hints and tips built up from practical experience.
When receiving data
1) Know what you expect to receive and check it when you get it
If you’re going to have to import or translate ‘foreign’ data it helps if you know what you are going to receive. It gives you the chance to plan and to ensure that when it does arrive you’ve got enough time, and the appropriate translation tools for the job.
Can you view it? Can you see if it is an assembly rather than a single part? Does it contain colours and other attribute data you might need? How large are the files? Have you worked with data from this person and this source before? Does it look like business as usual or is this something new?
In the automotive supply chain, data translation is a fact of life. With Class A surfaces, PMI data and feature trees adding to the complexity, it’s important to have a strategy for translation
2) Understand what you have received
Is it the right file type? Is it a compressed file? Is it a native CAD file or a STEP file? Don’t risk the embarrassment of calling a help desk to say that a translator doesn’t work when it is designed to translate a STEP file and maybe you have been feeding it a native CAD file.
Simple things can often get overlooked, for example make sure that you have checked the file extension and that zipped data has been unzipped! If you have a regular data exchange requirement it’s a good idea to define the process so that both the sender and recipient work in the same way every time data is exchanged.
If your interoperability work is such that you receive different files from different people it is still worth trying to put a definition on the process because it may save misunderstanding and so save time and effort.
3) Treat incoming data with care
Almost all data that is sent between companies for collaborative work contains intellectual property of one or both companies. Such data should be treated with care. Electronic files should be stored in secure areas and not left attached to a memo in an email in-box or in a directory on a public FTP site.
Ideally there should be a process that receives the data and before any validation, records what has arrived and puts the data in a secure place and tells the sender that it has been safely received. A similar process should be in place for data that is received on physical media such as tape or CD or disk. It should not be left in its envelope lying about on a desk it should be placed in a secure media store.
4) Only translate what you need
It is not unusual to receive much more data than is needed for the job. An extreme example might be a manufacturer of hinges receiving half a car body in order to ensure correct placement and fit of door hinges. (It’s true!) It’s not always as bad as that but it happens. The ideal situation would have been to have had sufficient dialogue with the sending organisation beforehand to agree exactly what data is needed and to send just that. However, sometimes that can’t happen.
One problem this can create is just how to handle very large files. Receiving a big CAD file that is not directly compatible with your own CAD system is not good. How big is big? CAD files of fifty or a hundred megabytes are not infrequently found and IGES or STEP files can sometimes be as big as three or four hundred megabytes! It’s a fact that the bigger the file the more likelihood there is of a translation failure – the machine you are doing the translation on may run out of memory. It is rare to need to work with that volume of data and if sending files that big can be avoided, it helps.
If you find yourself on the receiving end of such a file there are several things you can do. You could ask the sender to provide you with an assembly as a set of sub-assemblies but this might be commercially sensitive and pass negative signs to the sender and so may not be practical. The sender may simply not be able to disassemble the file or remove parts of the file to make things easier for you. Perhaps this is the last resort.
If you are very familiar with the translation tool you are using you may find that you can translate just the geometry that you need. It may be for example that a layering convention has been used and you can translate just the layers that you want or exclude the layers that you don’t want. It may be that the geometry that you want is surface geometry and your solution might be to translate just the surfaces. In short, knowing the capabilities of your translation tools can help you manage large files, save time and help get the job done.
Another alternative is to put an investigation and validation step in your process before attempting to translate. For example, using Theorem’s Data Exchange Navigator to view parts or assemblies before translation and using it to select just the parts or sub assemblies needed for your own job even from large complex assemblies will help you understand the data and break it up into more manageable files.
5) How do you know when you have succeeded?
In data exchange, if the translator only gives limited warnings and it produces a file we generally assume success. It can be dangerous to make this assumption. At this stage all that can be known for sure is that a file has been created and perhaps can be read into the target CAD system. It is not possible to say from what has happened so far that it has produced an equivalent CAD model to the original. There are different ways to validate files and they all have their strengths and weaknesses.
We might have a perfectly sound model but it may not be the same as the original. We could ask the sender for mass property details of the original and make some comparisons but even if they appear the same, the shape could be different. Sometimes visual inspection of the source model and just making a visual comparison with the destination model is sufficient to see a problem, however not seeing a difference does not mean that one doesn’t exist.
Validation is a difficult area. Fortunately we have now reached the stage where most translators work most of the time and one way or another we seem to be able to exchange data without having too many problems of this sort, especially where we are just exchanging a few files every now and then. The true size of this problem is not clear.
The necessity for validation varies depending on the intended use of the translated data. The question of accuracy and completeness of a translation becomes very important where complex shapes are used to create expensive tooling or when we have dozens of files most of which we will not check visually. It is even more of an issue in migration projects where tens of thousands of files may be translated and are required for future use, not simply for archive purposes.
Manual checking would be prohibitively expensive in time and money and so automated procedures need to be in place. Fortunately there are solutions and while this article is not a suitable place to describe them Theorem Solutions can provide technical and ‘user case’ detail for those who would like to enquire directly.
6) What to do when a translation fails
Unless the error message generated during the failure gives a definitive explanation of the problem you will probably have to try several things.
Perhaps the first thing to do is to put a test file through the translator. If a file known to be good goes through without failing this will indicate the problem as being in the source file. If on the other hand a file that is known to normally translate successfully fails then there are probably issues with the translator. Maybe a licensing issue or a permissions issue or perhaps some paths have changed. These kinds of problem are normally solved with a little time and effort.
If the test file goes through the translator with no problems the challenge is with the incoming file. Your first decision is whether you are going to try to resolve this yourself or if you are going to pass it back to the person who sent it, or even seek help from your translator supplier.
Assuming that you decide to resolve the issue yourself here’s where you might start.
If you have a tool which can display the source data use it to see if the source file looks wholesome. Gaps between surfaces or missing surfaces may be obvious and could be an indicator that you have a bad file.
Data translation in aerospace is often complicated by the complexity of the assembly, yet as you would expect, accuracy is everything
Check the file size and ask the person who sent it to confirm what it should be. The process of copying it in the first instance may have caused a problem.
If you understand the log files created by your translator, examining these will provide some clues. Seeing just what the translator was doing when it failed can sometimes point out a problem in the source file that could be avoided by selectively translating layers or entity types. In actual practice the people who can read and understand translator log files are a rare breed and you would be forgiven if you didn’t even want to peep into this realm.
Another option is to try to translate the file into a different format. If you have more than one translator you may find that a troublesome file will go into a different format without a problem. That only helps of course if you can then translate that file into your desired format and of course nobody knows what might have got lost in the course of more than one translation. However, sometimes it works.
Your translator company will normally have tools to investigate the source file and so should be able to tell you if that is the reason for the problem.
The option is to contact the support centre of your translator supplier. You have paid maintenance haven’t you? The only thing that should now prevent you from creating a file in the format you desire is that there is a fault in the source file and if that is the case you have little option other than to go back to the person who sent the file in the first place.
When sending data
7) Send only high quality data.
If you want your business partners to successfully import the files you send them make sure you send the best quality files that you can. Run them through whatever ‘checking’ routine there is in your design software. If there are errors – even if they don’t make any difference in your own CAD package, they might be showstoppers in translation.
For example if your CAD package creates solids even if there are gaps in the surfaces there is no guarantee that a translated part will be read into another package and represent the data as solid. If solids are important send solids – not surfaces with gaps. This kind of problem has given rise to some translators that will ‘fix’ problems like this but there are several potential issues with this approach. For example if the fix requires a change of shape, does it constitute a design change and if it does, should it be allowed to happen? The very best interoperability works with high quality source files and then the issue of design changes doesn’t arise.
8) Know what the data will be used for and send lightweight data if possible
There are many forms in which data can be exchanged including a native CAD model, IGES, STEP and much more common lately lightweight formats such as JT, 3DXML, ProductView, 3D PDF or XVL etc. In fact if you know that the end objective can be achieved by sending light-weight data then that is the best method to use. Creation of light-weight data is quick, results in small files and rarely fails to be read into the destination CAD system.
If you have the option of creating tessellated data it can be used for packaging, rapid prototyping including the use of stereo lithography and approximate clash detection. If that’s all that is wanted just send tessellated data. However lightweight formats should not be mistaken as being made up only of tessellated data. Some lightweight formats do not contain tessellated data. They can include accurate B-rep geometry and can therefore be used for almost anything that could have been achieved with the original CAD file.
Most importantly, interoperability via lightweight data format is one of the best ways of limiting the transfer of IP to the outside world. It could therefore be argued to be technically sufficient and commercially ideal.
9) If possible send only the data that the recipient needs
On a one to one data exchange it is possible to know precisely the data a recipient will need and to send just that – in whatever format is best. This is much more difficult where a project calls for project data to be sent for example to a number of suppliers, some of whom might be designing in context and others who may be making tools for body shapes and others creating robotic work cells.
In these cases the ideal solution is to send each supplier the data they need in the format they require but unless this process can be automated it can be costly in terms of time and effort. The sending of multi-purpose project data is one of the reasons that such large files are sometimes transmitted. However it is good practice where possible to send only what your supplier needs.
10) What about features and history?
The question of whether or not to send data with features and history is a difficult one and may well end up being a matter of company policy. There is no doubt that sending models with features and history is the most likely way of compromising company confidential information and IP. The trade off is that it should provide the recipient with a fully modifiable data set. In practice this isn’t so because so far Feature and History translation has not been fully effective and quite often requires significant operator interaction before the model is complete.
Some of the latest modelling techniques which enable direct editing of features may prove to be so effective in allowing modification of translated geometry that there is no value in attempting to translate History at all. Time will tell.
Conclusion
Most if not all of the suggestions written here are known to most if not all of the people who find that CAD data exchange is part of their work. The intention has not been to list mathematical or technical issues that influence CAD data exchange but rather to bring to mind again many of the known but perhaps forgotten things that can be done to improve interoperability. If you as a reader want to explore more deeply the technical aspects of this topic that will be covered in a future article.
www.theorem.co.uk
Top ten data translation takeaways
1 Set your expectation levels
Find out what format you will be sent data in. With plenty of forewarning you can prepare a strategy to convert the data or find the necessary resources/ services to make it happen.
2 Check what you get
Ensure you receive the right file type to translate, check the file extension. It might sound simple but the many technical support calls concern identification of file format problems.
3 Respect all Data
Intellectual Property is big business these days, sending files via email or FTP can duplicate and distribute confidential information far and wide. Streamline your process.
4 Translate only what you need
Find out what data is required and send only what is required. Do not send an assembly when only a part is required.
5 Validate your success
It may look the same but is it the same as the original file? Compare mass properties, visually inspect, use software compare tools.
6 Prepare yourself for failiure
There are a number of reasons for failure, copying errors, gaps in surfaces… If your translation tool has a log file the reason for failure may be indicated.
7 Send only high-quality data
The most common reason for failure is low quality data, gaps in solids require healing. Try and run your files through a model checking program.
8 Have an idea what the data will be used for
If one of the industry standard open file formats is good enough, why send the original data in a proprietary format? Tessellated data (triangulated surfaces) may be good enough, this will reduce the size of the file too.
9 Send only what’s needed
It may seem quicker to just dump out all the geometry from a project to send to collaboration partners. This can introduce a lot of extra and unnecessary work.
10 Consider Features and History
Sending Feature and History information to an outside company has its risks. Do you want your model to be fully editable? New modeling technologies may do this without 
Data translation – getting it right
