In my series of blog posts related to the (PLM) data model, I talked about Product, BOMs and Parts. This time I want to focus on the EBOM and (CAD) Documents relation. This topic became relevant with the introduction of 3D CAD.
Before companies were using 3D CAD systems, there was no discussion about EBOM or MBOM (to my knowledge). Engineering was producing drawings for manufacturing and not every company was using the mono-system (for each individual part a specifying drawing). Drawings were mainly made to assist production and making a drawing for an individual part was a waste of engineering time. Parametric drawings were used to specify similar parts. But now we are in the world of 3D!
With the introduction of 3D CAD systems for the mainstream in the nineties (SolidWorks, Solid Edge, Inventor) there came a need for PDM systems managing the individual files from a CAD assembly. The PDM system was necessary to manage all the file versions. Companies that were designing simple products sometimes remained working file-based, introducing the complexity of how to name a file and how to deal with revisions. Ten years ago I was investigating data management for the lower tiers of the automotive supply chain. At that time still 60 % of the suppliers were using CATIA were working file-based. Data management was considered as an extra complexity still file version control was a big pain.
This has changed for several reasons:
- More and more OEMs were pushing for more quality control of the design data (read PDM)
- Products became more modular, which means assemblies can be used as subassemblies in other products, pushing the need for where used control
- Products are becoming more complex and managing only mechanical CAD files is not enough anymore – Electronics & Software – mechatronics – became part of the product
Most PDM systems at that time (I worked with SmarTeam) were saving the 3D CAD structure as a quantity-based document structure, resembling a lot a structure called the EBOM.
This is one of the most common mistakes made in PLM implementations.
The CAD structure does not represent the EBOM !!!
Implementers started to build all kind of customizations to create automatically from the CAD structure a Part structure, the EBOM. Usually these customizations ended up as a mission impossible, in particular when customers started to ask for bidirectional synchronization. They expected that when a Part is removed in the EBOM, it would be deleted in the CAD assembly too.
And then there was the issue that companies believed the CAD Part ID should be equal to the Part ID. This might be possible for a particular type of design parts, but does not function anymore with flexible parts, such as a tube or a spring. When this Part is modeled in a different position, it created a different CAD Document, breaking the one-to-one relation.
Finally another common mistake that I have seen in many PDM implementations is the addition of glue, paint and other manufacturing type of parts to the CAD model, to be able to generate a BOM directly from the CAD.
From the data model perspective it is more important to understand that Parts and CAD documents are different type of objects. In particular if you want to build a PLM implementation where data is shared across all disciplines. For a PDM implementation I care less about the data model as the implementation is often not targeting enterprise continuity of data but only engineering needs.
A CAD Document (Assembly / Part / Drawing / …) behaves like a Document. It can be checked-in and checked out any time a change is made inside the file. A check-in operation would create a new version of the CAD Document (in case you want to trace the history of changes).
Meanwhile the Part specified by the CAD Document does not change in version when the CAD Document is changed. Parts usually do not have versions; they remain in the same revision as long as the specifying CAD Document matures.
Moving from PDM to PLM
For a PLM implementation it is important to think “Part-driven” which means from an initial EBOM, representing the engineering specification of the Product, maturing the EBOM with more and more design specification data. Design specification data can be mechanical assemblies and parts, but also electrical parts. The EBOM from a PCB might come from the Electrical Design Application as in the mechanical model you will not create every component in 3D.
And once the Electrical components are part of the EBOM, also the part definition of embedded software can be added to the BOM. For example if software is needed uploaded in flash memory chips. By adding electrical and software components to the EBOM, the company gets a full overview of the design maturity of ALL disciplines involved.
The diagram below shows how an EBOM and its related Documents could look like:
This data model contains a lot of details:
- As discussed in my previous post – for the outside world (the customer) there is a product defined without revision
- Related to the Product there is an EBOM (Part assembly) simplified as a housing (a mechanical assembly), a connector (a mechanical art) and a PCB (a mechanical representation). All these parts behave like Mechanical Parts; they have a revision and status.
- The PCB has a second representation based on an electrical schema, which has only (for simplification) two electrical parts, a resistor and a memory chip. As you can see these components are standard purchasable parts, they do not have a revision as they are not designed.
- The Electrical Part Flash Memory has a relation to a Software Part which is defined by Object Code (a zip-file?) which of course is specified by a software specification (not in the diagram). The software object code has a version, as most of the time software is version managed, as it does not follow the classical rules of mechanical design.
Again I reached my 1000 words, a sign to stop explaining this topic. For sure there are a lot of details to explain to this data model part too.
Most important:
- A CAD structure is not an EBOM (it can be used to generate a part of the EBOM)
- CAD documents and EBOM parts have a different behavior. CAD documents have versions, Parts do not have versions (most of the time
- The EBOM is the place where all disciplines synchronize their data, providing during the development phase a single view of the design status.
Let me know if this was to abstract and feel free to ask questions. Important for this series of blog post is to provide a methodology baseline for a real PLM data model.
I am looking forward to your questions or remarks to spark up the discussion.
5 comments
Comments feed for this article
July 22, 2015 at 5:28 pm
Mahire Abu Khaleel Alraiey
Good post that would lead to great result if it follows….
more points like New part number policy for FFF issues: The pulling teeth Saga—
PCB assembly Variants: Not in 3D world and will not be…..
Thanks for the feedback – for the moment I try to stay on the high-level of PLM data model practices, which are valid for most industries. Other topics like a part number policy can lead to various discussion. In a modern PLM system the part number does not have so much relevance. A Part is identified by its related specification and its usage in a BOM structure – if a new revision for the part exists for IT systems it does not matter if the first 5-10 characters are the same and only the last index changes or that a new complete random but unique number is generated.
We have to stop thinking more and more in a data-driven approach, but this will take time
Best regards, Jos
LikeLike
July 23, 2015 at 9:30 am
Erik van Nistelrooij
Great PLM reference material.
I’m looking forward to the next 1000 words.
Regards,
Erik
Thanks Erik, remember it is intended to be high-level. In your case I could be more specific as knowing your industry there are much more dedicated best practices, for example related to configurations and configuration management. Best regards Jos
LikeLike
July 25, 2015 at 11:38 pm
Denis Morais (@DenisMoraisX)
I am enjoying your latest posts.
I do have a question about comment:
“Parts usually do not have versions; they remain in the same revision as long as the specifying CAD Document matures.” mentioned in the PDM section.
I am curious what your thoughts of this from a PLM or Part-Driven strategy? I am assuming it is different but thought I would ask.
Denis I believe we are ultimately talking about the same and in my next post I will elaborate more on the content of the EBOM and the various parts in the EBOM.
I also believe it makes sense in most of the situations to start with a conceptual BOM in PLM which defines the ebom structure. Next for design parts a further detailed definition is required, mostly done in CAD. Whilst the EBOM Part still remains in the same status and revision, meanwhile the related CAD model might have versions in order to understand and communicate differences between various reviews. And the EBOM part might be specifying an assembly where the underlying subassemblies and parts will come from the CAD. I hope this is enough for the moment. I plan to have one more post as I mentioned before my holiday mid august. If you want to discuss before and with more detail feel free to drop me a mail. Best regards Jos
LikeLike
August 1, 2015 at 10:49 pm
Steve Calvert
Yes, don’t stop at 1000 words, we need this discussion.
I’m a Smarteam user and we try an make the EBOM match what’s going to be entered into our Oracle ERP system. Glue, paint, ETC are all just “Items” in our engineering world and we’ve solved the different configurations not needing another profile card because of their uniqueness.
We have a giant spreadsheet, not created here, that describes the differences in one of our products. It is too large to manage and the writers of that spreadsheet didn’t use our PDM system.
Please continue the discussion.
Thanks Steve for your feedback. Yes I am planning more posts. Next one upcoming is about EBOM characteristics. When you say you are passing the EBOM to Oracle ERP, I conclude you are not implementing SmarTeam as a PLM system but as a PDM system. See my post related to the MBOM. SmarTeam has PLM capabilities (Express methodology) however as I do not know your company and processes I am not sure if it can be the PLM system for the enterprise. Success and keep on reading – Jos
LikeLike
August 3, 2015 at 2:15 am
Steve Calvert
Correct, ST is our PDM system and we currently fill out a ‘profile card’ for each ST part and then turn around and re-enter that data into our ERP system. Lots of misuse of time but I guess we’re learning. Success Steve !
LikeLike