V4 to V5 Conversion, Migration, Translation Process

You’ve probably heard our COE members use the phrase “V4 to V5” and “data upward compatibility”. What are they talking about?  But better yet, what do users of Dassault Systèmes’ software really need in regard to this issue of converting V4 to V5?

The problem arose when people started using CATIA Version 5 and realized that they could not simple read-in the CATIA Version 4 models and use them, without issues. The functional differences between V5 over V4 made the models somewhat incompatible. The initial and emotional reaction was one of foul play. After all, Dassault had always insured n to n+1 upward compatibility.

So along came conversion tools to convert CATIA V4 CAD models to V5. But this doesn’t seem to have quenched the thirst for the V4 to V5 issue?  Why not?  There are many reasons. The obvious one most often spoken about is because there is no button that will convert the V4 models to V5 models with 100% reliability and 100% of the data. Things are lost. Depending on the methods used to create the V4 models, there could be incompatibilities with converting it to a fully functioning V5 model. And so the chant continues, “Give us a conversion tool.”

But there is no conversion tool that will satisfy this chant. Why?  Because, what companies need is not merely conversion of V4 CAD models to V5 CAD models. Think deeper about the process and what is going on in the engineering department that causes the need for V4 to V5. The answer is that some design of new parts is going on. And the design of new parts on CATIA V5 requires the engineer to have available the adjacent parts and similar parts to aid in the design of new parts. And since those existing parts were originally created in V4, they need them converted. So why is CAD conversion software tool not the panacea to the issue?  Because on closer look at the V4 CAD models it is not merely a CAD model. It is a model of a collection of parts, part of a product, complete with product structure and bill of material attributes all of which are needed to define and understand the part definition. Both the CAD model and the BOM data needs to be taken into account when converting from version n to n+1.  So what companies need is a translation from legacy environment to future environment that includes both CAD models and BOM data to support new design work.

To fully understand the product part, an engineer needs not only the CAD model but also the assembly structure stored in BOM data or PDM (Product Data Manager) system, the global coordinate system location, the existence or not of left hand, opposite hand, and mirror image parts.  The new product, if it is to be accurate, needs to be designed in the full context of the adjacent parts, which requires knowledge of all the product definition data, both CAD definition and BOM data.

So V4 to V5 is not really the issue. The real issue is translation from a legacy environment to a future environment to support design of new parts on the future environment.  How does a company implement a new environment composed of CATIA V5 and ENOVIA LCA when all the previous parts have been defined in the legacy environment composed of CATIA V4 and some other BOM system or multiple BOM systems?  Additional confusion is created within industry about whether it is the best practice to implement a new V5 environment and migrate there or just work in a dual environment of V4 and V5 interoperability. Why confusion, because Dassault says, interoperability works and is a viable operational environment. They say that interoperability is part of the V4 to V5 migration path. But customer experience is showing dual environments don’t work, nor meet operational requirements, and create a nightmare for configuration control. So what is company to do?   The answer is, develop and implement a process to translate design data from the legacy environment to the future environment. And this includes both the CAD data and BOM data. And may or may not need to be a two-way process.

So what about this translation process?  What requirements are there?  Well one thing is for sure. If an engineer needs legacy data to support his/her new design, they will convert it themselves, trusting only their own conversion quality and consequentially a company could end up with multiple copies of converted data, all done by individual engineers to assist themselves in design of the new parts. This of course is a big waste of engineering time. The solution is to come to agreement with the engineers who need converted data on what quality and attributes they require in order to “trust” the converted data. If they can trust that converted data will meet their quality requirements they will use it in support of their new design.  And, this translation process needs to offer the engineers a simple way to make a request for a converted part; give them visibility of how the conversion is progressing; and eventually provide them the converted data in the target environment, which meets all their quality requirements.

So imagine now, you as an engineer, can send an email to someone to have legacy part number N4325-123 converted from whatever your legacy environment was to the future and target environment composed of CATIA V5 and ENOVIA LCA. And then have a website where you can see progress of the conversion. And finally receive an email stating the part and all its characteristics have been translated to V5/ENOVIA for use and it only took a day or two. Nice. For the engineer this would be like having a push button, on-demand solution to the V4 to V5 issue. But what really happened? Behind the scene is some analyst who receives the requests, queries all known BOM, PDM, CAD, Mylar systems for data associated with the request; reads it; checks it; and runs various conversion tools for the CAD model conversion; re-enters data into ENOVIA; uses tools to clean up and check the model and BOM data; and finally promotes the translated CAD model and BOM data to “released” engineering. In this case “released” means translated for use, but not to be sent to manufacturing for fabrication.  Now not only does the requesting engineer have access to this part, but the whole program of engineers does as well. The translated part is in the new V5/ENOVIA environment labeled with appropriate part number, meeting quality requirements and people can use it without risk.

This process is in work at one company I know and in 5 months, 10,000 detail parts were converted, (or translated is probably a better term), including over 100,000 BOM attributes, by a team of just a few people.

So the final answer to how can a company implement a new V5/ENOVIA environment is by offering their engineers and on-demand conversion process that is essentially a manual process, augmented by various software tools, some provided by Dassault, but many provided by the company’s own IT group, that results in translated data to the target environment and meeting the predefine quality criteria.

For assistance with setting up a V4 to V5 translation process contact:
Steve Lynn
Consultant: IBM Global Business Services
Phone: (20)686-9799 sglynn@us.ibm.com

The views expressed in this article are the personal views of Steve Lynn and do not necessarily represent the position of the IBM Corporation.