Revision standards

[mike miller]

I'm working on getting our rev standards nailed down, since it's been loosey-goosey up to this point. I'm specifically looking for suggestions/ideas for a standard that defines how far "up the tree" revisions should go. A natural-sounding idea is "whenever the BOM changes". That doesn't work in real life because that means every change will cascade upward to the top-level assembly. Which means every ECO that revises ANY part will trigger a new revision of the top-level assembly. My inclination is to go only one level up since it only affects the next stage in process in real life. Or sometimes it doesn't.

Where do you draw a line without being either arbitrary, sloppy, or ridiculously scrupulous?

@bnemec
@jcapriotti
@AlexLachance

[jcapriotti]

As you said, it depends on what the effect is to the assemblies above and is an engineer's call for us. Sometimes we make extremely small changes to a part, tweak a radius or increase a hole diameter for easier assembly. Or its drawing may have notes changed or cleanup done. These will bump the revision but not warrant any changes to assemblies in the part's "Where-used".

If the part changes affects the assembly, then we update the assembly. How many levels depends on the change. Changing a mounting hole to a slot would affect the next assembly up but likely not any higher. Changing a base fixed component might affect several levels.

[matt]

The definition I've always used has been "if it's not just a drop in replacement". So if there is some difference in function, the way its assembled, etc. So if the part only gets a new rev level, the assembly it's in doesn't need a rev. But if it is different enough to get a new part number, you'll have to rev the assembly it's in, but not the next assembly up. If the new part changes how the assembly works, then you have to rev up another assembly level.

I should be able to find some old rev scheme standards I've written somewhere...

[AlexLachance]

I'll reply to this a little later on when my brain is a little less scrambled, but we don't really have any standards we follow. We try to mark changes where they are made. If a hole size is done, the revision is on the part. If the holes are moved to reposition an assembly, part and assembly.

Basically, if it affects nesting and/or what is sent to production, we try and have revision. We also try to hide some revisions when there are too many(for example a part with over 10 revisions). If it's just adding,removing or replacing washers/nuts then generally there's not really a revision, unless the size of these changes.

[jcapriotti]

I'll reply to this a little later on when my brain is a little less scrambled, but we don't really have any standards we follow. We try to mark changes where they are made. If a hole size is done, the revision is on the part. If the holes are moved to reposition an assembly, part and assembly.

Basically, if it affects nesting and/or what is sent to production, we try and have revision. We also try to hide some revisions when there are too many(for example a part with over 10 revisions). If it's just adding,removing or replacing washers/nuts then generally there's not really a revision, unless the size of these changes.

You can never have too many revisions

I can think of one file that is on around Revision "GA", about 140 revisions.

[mike miller]

You can never have too many revisions

I can think of one file that is on around Revision "GA", about 140 revisions.

Does anyone here use split rev schemes? An example would be "1" for production releases and ".1" for dev versions. Then you could go from 1 to 1.1 to 1.2 to 1.3 until you found something that works. At that point it would become rev 2.

[jcapriotti]

Does anyone here use split rev schemes? An example would be "1" for production releases and ".1" for dev versions. Then you could go from 1 to 1.1 to 1.2 to 1.3 until you found something that works. At that point it would become rev 2.

We do.

Release
A, B, C, D, E, ..........

WIP
Revising A (A.01, A.02, A.03.....)
Revising B (B.01, B.02, B.03....)
etc.

[bnemec]

@mike miller Great topic. I'd like to provide a helpful answer but after trying a bit I realized I am unable to do that. We have a system to help determine how far up the tree to update when a component is revised. I try to summarize it, but there's just too many ifs and butts. Since Design Engineering is at the mercy of all the other departments, not to mention the customers, the flow chart would use up two marker boards, another wall, a ball of yarn, push tacks and two stacks of sticky notes to model. It's pretty much a random number generator.

- We have customers that do not allow revisions
- We have vendors that require revision on print if a note changes only by its LOCATION on the sheet.
- We like that the welders and assemblers notice if a component does not match how it looks in the weld/assembly level print they are using. So add a hole but don't update every mfg print then we teach them to ignore differences. Note, this is not the piece part print, that's updated obviously, talking about features that are noticeable in the weldment print.
- Sometimes its "How many need to update?" question, if it's a couple hundred where used in the next layer then maybe cannot see the benefit worth the cost.
- If the revision to the part is description, then the weldment print must be revised because we have the component descriptions in the parts list on the weldment print.
- on and on the list goes.

We've been more concerned with HOW to not revise the entire where used trees; now that we're in PDM and files are locked in Released state. Either we open it back up and let every Joe make no rev changes or the upper-level assemblies are using wrong version most of the time. Before PDM the first assembly that didn't get revised would be opened and updated to use the latest rev of the component and saved; no rev/doc control. VAR assumed every revision goes all the way up all of there where used trees. Yet when we asked where is the "Update all where used" tool in PDM there's no such thing...

[DanPihlaja]

...
- We have vendors that require revision on print if a note changes only by its LOCATION on the sheet.
...

Let me guess..... DOD or something similar?

[Brian-M]

Engineering Documentation Control Handbook, Frank Watts:
------------
Rule: The revision level of parts should not appear in support documents. Parts Catalogs, Maintenance Manuals, etc., should not refer to the revision level of the document depicting the item. [Don't have a BOM column for component revision level]

Reason: Items of the same part number must be interchangeable. Showing revision levels would (at least) confuse the issue.
------------
The question arises, when does the revision level change?

Rule: Every time a change is made to a released document, the revision level must be increased. These may be interchangeable changes to the part represented thereon or document only changes.

Reason: Changes made to documents are important. It is, therefore, necessary for everyone using that document to know that changes have occurred. If the part is affected, the production people or the supplier must be notified to implement the change.
------------

If you go with that, then you must revise the sub/assembly if a child part number changes (the BOM changes). But if the component was just revised (no form, fit, or function changes), you usually don't need to worry about the next level up. Benmec gave some examples of exceptions, but interchangeability is the key criteria in the generally accepted best practice.

What it means to be interchangeable varies with the product, and use of the item in question - and it often boils down to a judgement call (sometimes requires input from multiple departments). I like the example of part color - sometimes it's no problem to change it (bump the revision), and for other products it must be aesthetically consistent (new part number if you change color).

[dave.laban]

Sorry for digging this thread up but as it's related to "how far to propagate a revision change" this feels like a good place to ask.

Consider a basic assembly;

Top Level (Rev 2)
-----Sub-Assembly (Rev 0)
----------Part 1 (Rev 1)
----------Part 2 (Rev 1)

The sub-assembly is revised to swap out a part or something, so a common school of thought for revisioning would leave you with;

Top Level (Rev 2)
-----Sub-Assembly (Rev 1)
----------Part 1 (Rev 1)
----------Part 3 (Rev 0)

i.e. you've changed the revision of the sub-assembly that has had the component swap-out, but levels above stay where they are, leading to two slightly different configurations of product both bearing "Rev 2" on the outside.

If you are then presented with a failed top level device, whose only external marking is "Rev 2", how then do you determine it's exact build configuration in order to begin troubleshooting? If you have serial numbers on the top level device you can in theory find out when it was assembled, then cross reference those dates with the revision dates of sub-assemblies / component, but that is then a fairly sizeable paper trail to keep track of. Do any of you have any reliable methods for tracking that kind of information?

[bnemec]

Sorry for digging this thread up but as it's related to "how far to propagate a revision change" this feels like a good place to ask.

Consider a basic assembly;

Top Level (Rev 2)
-----Sub-Assembly (Rev 0)
----------Part 1 (Rev 1)
----------Part 2 (Rev 1)

The sub-assembly is revised to swap out a part or something, so a common school of thought for revisioning would leave you with;

Top Level (Rev 2)
-----Sub-Assembly (Rev 1)
----------Part 1 (Rev 1)
----------Part 3 (Rev 0)

i.e. you've changed the revision of the sub-assembly that has had the component swap-out, but levels above stay where they are, leading to two slightly different configurations of product both bearing "Rev 2" on the outside.

If you are then presented with a failed top level device, whose only external marking is "Rev 2", how then do you determine it's exact build configuration in order to begin troubleshooting? If you have serial numbers on the top level device you can in theory find out when it was assembled, then cross reference those dates with the revision dates of sub-assemblies / component, but that is then a fairly sizeable paper trail to keep track of. Do any of you have any reliable methods for tracking that kind of information?

All of the physical parts are all marked with part number and revision?

[dave.laban]

Yes, but for this scenario you have a customer who is only allowed to look at the outside of the unit (some fixes will be possible by them with a sealed unit, others would have to be return to base so stripping apart and getting part revs will be easier).

[bnemec]

Yes, but for this scenario you have a customer who is only allowed to look at the outside of the unit (some fixes will be possible by them with a sealed unit, others would have to be return to base so stripping apart and getting part revs will be easier).

Does the scenario MES/ERP system track revision implementation dates and or part change phase in/out dates?

Does every product that ships have a serial number tag with date of Mfg.?

[dave.laban]

PDM has revision dates. ERP doesn't track implementation or phase in/out dates. Further complicated by there maybe being 3-4 months between production runs (so there might be any number of revisions in the mean time) and everything is put together by a contract manufacturer rather than in-house.

This train of thought is prompted by our current PDM system has minor revision functionality, so in my example I'd currently minor-rev every level up the tree;

Top Level (Rev 2.01)
-----Sub-Assembly (Rev 1)
----------Part 1 (Rev 1)
----------Part 3 (Rev 0)

So a customer would have a Rev 2.01 in front of them and we could then immediately pick up what the product configuration would be.

We are weighing up moving to the same PDM system as another division of the company, however over there they don't use minor revisions; looking at the outside of the unit, they have no way of knowing what the internal config should be without correlating the serial number to an order from the contract manufacturer, find out the order date for that manufacturing batch then compare that to the PDM BOM at that date (which is non-trivial in that system) or hoping the contract manufacturer still has an accurate data pack.

We have various routes to success, however they want to do the one with the least $$$ spent which may mean our division adapting to no minor revs; just wondering how other people have conquered this.

(and yes, I'm painfully aware our data management leaves a lot to be desired).

[Brian-M]

That's an excellent question to bring up dave.laban - I don't really have an answer, it's something I've also wondered about, and of course the solution varies per company. This is one reason some companies bump revision levels on higher assemblies when - by the book - they don't need to.

I think the idea would be an ERP system that can take the serial number and tell you how that unit was built - which multi-level BOM. But I personally haven't seen that demonstrated by an ERP system in a good way. I'm sure it exists, but not all ERP are good at it.

So your idea to use minor rev seems like a practical work around. I suppose you also update the top level drawing, plus PDM and ERP revision levels? Can your ERP system then display a different BOM for 2.01 vs 2? Or do you rely on some other snapshot of the BOM?

That same system would probably work with major or minor revision increments. Minor tells you something, but it's not totally critical to that approach. In either case you are bumping the revision. Think about that if minor rev is a sticking point for your other division.

Another possible approach - keep a virtual file of the multi-level Bill Of Materials - dated according to date of manufacture (e.g. a series of PDFs labeled with item number and date for the top level BOM).
Or save those files (folder or filename or database) marked with serial number any time there is a transition in the multi-level BOM. Assemblies made in between dates or serial numbers can be assumed to be the same as the preceding, so you only need a new record on a change - it could be part of the ECO package.