Part Numbering in the 3DEXPERIENCE Platform
In my time working with Engineering groups, I have seen a lot of different ways of numbering parts. One thing that’s always true is that this is a passionate topic. Engineers debate this topic constantly. Should we use serial numbers? Maybe smart part numbering techniques to better describe the components? The debate never ends. This is especially true when we talk about part numberings in the 3DEXPERIENCE Platform.
This topic itself is not super complex; generally, only a few schools of thought. But whenever the topic comes up, everyone has an opinion on what we should do. When opinions pit “old school” vs. “new school”, discussions get even more complex. We run across these contrasting options, typically mocking up examples of both for users to get a feeling for each. Whatever direction you choose, you need full buy-in from users to management.
Smart Part Numbering
I think that this sounds simpler than it is. I don’t know that I have ever found any product that is really 100% qualifiable with smart part numbers. Smart part numbers give you a way to name parts based on what they are. For example, I might name a file based on the dimensions and material. My 8 inch by 12 inch box made of pine becomes “8in x 12in – pine.sldasm”. Change the dimensions or material and the part number changes too.
Typically, this system is the existing method of part numbering. It’s generally liked by users that have been with the company for a long time since they can spout a base number from memory and understand the structure just by knowing the numbering system. New users often find the system daunting, unforgiving, and hard to navigate.
When implementing this part numbering system on the 3DEXPERIENCE Platform, we find that many attributes are redundant. They repeat the information that the file name is already tracking. The attribute still needs to be populated so that the system can search on the metadata of the CAD file. Therefore, smart part numbering not really required.
Serial numbers are the norm for most engineering systems. It offers a “number is just a number” mentality and gives users a disposable part number to use early on. For example, all of my SOLIDWORKS parts may use a 1000000 series number. The first part I create is 1000001, the second is 1000002, and so on.
With the 3DEXPERIENCE Platform, we capture data from attributes and database connections. We can use that data to search and filter, quickly finding parts in the system. This is by far my preference, and we have seen it result in a high success rate and widespread adoption. I believe that the success of this methodology is dependent on the implementation of the system. We need to properly map attributes for the CAD system. The Platform pulls the attributes in and assigns a predicate so that they can be indexed.
File Structure Creates Complexity
A file structure inside of a SOLIDWORKS file is not typical. It goes against some of the norms of other systems. The fact that configurations are all stored inside of a single part or assembly file complicates things. This creates a situation where there could be multiple parts (individual part numbers) in the same file. This is the main reason behind the CAD Family object type. The CAD Family serves as a holder for the file. Configurations are represented as individual physical product objects, each named by configuration name. The Platform connects those to the CAD family.
This layout creates some additional questions about part numbering in the 3DEXPERIENCE Platform. Traditionally, SOLIDWORKS users like to have their file name be the part number. Configurations mean the CAD Family object is no longer unique to just one part number. This create issues when the user wants to add configurations (part numbers) to a file or wants to revise a configuration that is part of his file. In the platform, the CAD Family and all the Physical Product objects need to be revised together. Some companies don’t feel this is an important factor. For others it leads to excessive or unrequired revisions to the structure when changes may only effect one configuration or part number.
One Part, One File
Duplicating the file or branching the revision (to be covered later) to create different versions of configurations makes me lean towards a “one part, one file” system. It allows for a more controlled change management processes that don’t negatively affect downstream processes. By no means am I saying configurations are unsupported or that there isn’t a reason to use them. Rather, it’s important to consider the purpose of the configuration. Does this constitute a new part or is it a different option? If you’re using “one part, one file”, I typically say that leaving the single configuration named to “Default” is normal.
When using multiple configurations, I generally rename the configuration to match the part number. This includes the default configuration. For example, a user will know they’re looking at one part if he or she sees an object named 123456(Default). If the object is named ABC(123456) they will know that the object is part number 123456 and it is part of CAD Family or file name “ABC”.
Throughout my time implementing 3DEXPERIENCE, we have created other options and systems to control this type of numbering and configuration. Mapped variables based off configuration or file name, the implementation of EIN (Enterprise Item Number), or custom back populated variables to represent a number, are all options. The bottom line comes back to the fact that part numbering is seldom cut and dry for any system. The configurability of the platform means that most companies will be better off enlisting help to guide them through the options during implementation. Eighty percent of companies will fall into a system or procedure that is the same or similar. Getting everyone on the same page is vital to the buy in and ultimate success of the implementation.