I started this series on what I’ve learned about migrating CAD data into Teamcenter a couple of weeks ago. The more I write, the more I find there is to write; as I pull on the thread of memory more and more details are pulled to the surface.
I was working on a different post in this series when I realized that what I had missed was a look at the big picture: what does you native data look like? What does your Teamcenter look like? What must you maintain when you migrate? These are the sorts of questions that will help you understand the complexity and level of effort you can expect from your CAD migration project.
I believe that working through the following questions will help you to shape an effective migration plan. If you can think of any others please share them in the comments below.
Native CAD Data
How Much Raw Data is There?
If you only have 1,000 native files then you might as well migrate everything except obvious junk like bobs_doghouse_plans.prt, and you’re probably fine using the standard import tools that come with NX. If you have 1,000,000 files, you might want to spend some time thinking about what you really need to have in Teamcenter and to what extent you can automate the migration process with custom tools.
How Clean
is your Raw Data?
In a previous post I discussed the types of problems you may see with native CAD data. Some of you have file systems that were essentially uncontrolled and now look like the aftermath of a party at Delta Tau Chi house. At the other end of the spectrum are those companies who have systems in place that kept your native file systems neat and tidy. I’ve seen both. Where you fall in that continuum will shape your migration strategy.
Teamcenter
How Complicated is your Teamcenter Data Model?
If all CAD data is stored under a single item of type, My_Item, you really can’t make any mistakes storing data as the wrong item type. If you have two types, My_Part and My_Drawing, it’s not impossible to make a mistake, but it’s probably pretty difficult to do and obvious when it happens. If you have My_Part, My_Drawing, My_Library_Part, My_Tooling_Part, My_Special_Part, My_Concept_Part, and My_Gal_Friday_Part, you’re probably going to have some problems — especially if you’re depending on users to manually select the correct item type. Sooner or later they’ll migrate a part file as a My_Part when it really should have been a My_Special_Part. And by the way, Siemens doesn’t support changing the item type of an existing item.
With a simple data model you can more easily leave assigning item type up to a user. With a complicated data model you’ll want to consider creating some automated tools to do it for them, perhaps by matching the file name against a regular expressions to see which numbering pattern the files uses, or by submitting the file name to some other system of record which can make the proper assignation.
How much Design History do you need?
Do you only need the latest revision? Latest released plus current working? All released revisions? Every revision ever created, released or not?
The obvious effect of migrating more revisions into Teamcenter is that you will spend more time moving bytes of data — in my experience the actual copying of the data from the native OS to Teamcenter’s volume servers is the most time consuming.
Less obvious is that you’ll probably end up migrating revisions out of order unless you’re very careful. If it bothers you to have your revisions ordered C-D-B-A, by date created, instead of A-B-C-D you’ll either want to spend time making sure that doesn’t happen or decide to clean it up after the parts migrate, perhaps by editing their date created attribute to match when they were created on the OS, not when they were migrated.
[box type=”note” style=”rounded” border=”full”]If you think it should be easy to migrate things in order, consider what happens when you migrate two assemblies that use different revisions of the same component. The first assembly migrated uses rev D and the second uses rev A. Presto, the component has had its revisions migrated out of order[/box]
Will you Keep the Precise Assembly Structure?
Some of us have configuration rules that say to always use the latest available revision of each part in an assembly. If that’s the case, then you can argue that only the latest revision needs to be migrated. This means less data to move, however it also means that assemblies may have to be updated to fix things like broken mating conditions or wave relationships.
Others have more complex effectivity rules that require them to maintain the exact structure, including revision, of their assemblies. This means more revisions need to be migrated. Even if you decide to only migrate the latest revision of certain top assemblies, different top assemblies may currently reference different revisions of the same component.
Performing the Migration
Centralized or Distributed Migration?
Will you have a dedicated team (or user) do all the migrations, or will you spread the work amongst the user community — giving each project team the task of migrating their own data, for example?
A centralized strategy has the advantage of economies of scale and being able to perform whole system analysis. For example, if you know that you are the only one doing migrations know precisely what’s been migrated and what has not, then you can make decisions easier than someone who may not be able to see all of the data nor be certain what someone else is doing at the same time.
The distributed approach has the advantage of spreading the workload around so no one user is dedicating a significant amount of time on migrations.
Personally, I prefer the centralized approach for complicated migrations involving messy native data and a complicated Teamcenter data model.
Vendor’s Tools or Custom?
NX has a GUI for importing data. Although it is somewhat cumbersome to use, any NX user can use it. I wouldn’t recommend it for doing any significant amount of data migration.
There are also command line tools for importing data. They are more useful for migrating large amounts of data, however they are a general tool and are not designed for your data. Of course, the advantage is that the utilities have already been developed and are supported by Siemens. However, if your migration is complicated enough you may prefer to invest in your own development effort so you have full control of the process.
Will you Fix Problem Data Before or after the CAD Migration (or ignore them)?
Unless you are very fortunate, you will have some data that will not migrate into Teamcenter correctly without some sort of intervention. That intervention could be a user fixing the data prior to migration, automated tools designed to detect and correct the problem during the migration itself, or having a process to automatically or manually correct the data after it is migrated into Teamcenter. Some of the issues I’ve seen are as follows:
Incorrect Item IDs
Typical example, the file should have been named 1234567_a.prt, but it was actually named project_x.1234567_a.prt, so the item created in Teamcenter is PROJECT_X.1234567/A.
I would at least consider fixing the data prior to migration (or design the migration to assign the correct item ID despite the incorrect file name), however, you have to be careful. What if there is both a project_x.1234567_a.prt and a 1234567_a.prt? Now it’s not so clear if you should renumber the prefixed file. For this reason I suggest waiting until the migrations are completed and then correcting what was actually migrated — perhaps only one of the two files will be migrated.
Multiple Items for same Part
One version is where each revision of a part has a different prefix: curly.1234567_a.prt, larry.1234567_b.prt, and moe.1234567_c.prt. The clean solution would be to eliminate the prefixes and migrate the files as three revisions of the same item, 1234567.
The messier version has multiple file at the same revision, 123456_a.prt and project_x.1234567_a.prt. Here you will have to do some additional digging to really understand what’s going on.
I think it’s worth trying to minimize this problem by cleaning the data prior to migration, but unrealistic to think you’ll completely defend against it unless you have very little data to migrate. You should plan on having duplicated items that you either decide to live with it or clean it up later.
Inter-part Relationships
If don’t preserve the precise assembly structures of parts you will migrate assemblies with different revisions of components than what they were saved with, which will mean that certain types of inter-part relationships will be out of date. If your data is NX, the following are some of the things that could need updating:
- Mating Conditions and Assembly Constraints
- Component positioning
- WAVE Data
- Promotions
- Inter-part expressions
- Drawing Graphics
If this applies to you, there really isn’t anything you can do prior to migration other than to manually update and refile the assemblies. You’re better off waiting until the migrations are complete and then updating the assemblies as the need to work with them arises.
Reordering Revisions
As I mentioned above, if you migrate multiple revisions of a single part you will have to either take care when migrating to migrate the revisions in order, or post-process the revisions when the migration is complete to modify their creation dates so that they are in the correct order.
Pingback: PLM Weekly News: September 22, 2011 - Zero Wait State()