When developing an ECR/ECN process, the question of when to roll a rev vs. when to create a new part number must be answered.

In researching this question, I've come across multiple sources that state the principle of "interchangeability" as being the arbiter of this decision. If the change is such that old and new parts can be co-mingled in the same parts bin, then only a drawing revision is required. If they must be kept separated because there is a change in Fit, Form, or Function (the F3 rule) that affects the next assembly, then the old and new parts must be kept separate and a new part number is required.

This seems reasonable on the face of it. However, some things can change fairly often, such as firmware versions. Strictly applying the rule would imply that any firmware version change requires a new part number, but this seems that it can rapidly become excessive as bugfixes and minor features are rolled out.

To be clear, I'm not asking about the version of the firmware itself - that is easily handled. I'm referring to the PCBA into which the firmware is loaded. We order our PCBAs from our vendor with firmware already loaded onto it. For example, let's say that part number 12345 Rev A is the PCBA with firmware version 1.0. If we then move to FW version 1.1 (for example, let's say we add another set of translation strings to support a new language in our menu system), I would argue that the mixing the old boards with the new would cause confusion in the case that the old boards are sent to someone who needs the new language. So, the boards with FW v1.0 and FW v1.1 should not be mingled.

So, the F3 rule then dictates that we should create a new part number with the new FW version, designate a new bin location to stock the parts, etc. However, the rate at which seemingly minor changes in the FW (i.e. translations, bugfixes, etc) occur can lead to an explosion of part numbers, and consequently, warehouse bin locations, thus increasing cost.

Can anyone share an alternative for such a situation?

  • $\begingroup$ So the classic xxx.1, xxx.2, xxx.3 which most software updates come with won't work... $\endgroup$
    – Solar Mike
    Commented Aug 8, 2019 at 14:13
  • 1
    $\begingroup$ @SolarMike My question doesn't pertain to the firmware update itself, but rather to the next assembly. I've updated my question to make it more clear. Sorry about that. $\endgroup$
    – rothloup
    Commented Aug 8, 2019 at 14:39
  • $\begingroup$ Then don’t use the word « firmware » .... $\endgroup$
    – Solar Mike
    Commented Aug 8, 2019 at 14:52
  • $\begingroup$ The word "firmware" was part of the example, intended to help illustrate the question. It should be quite clear now. $\endgroup$
    – rothloup
    Commented Aug 9, 2019 at 16:18

1 Answer 1


If something is form-fit-function backward compatible with an earlier rev., then usually you can just bump the rev -- depending on your customer base.

Most places that make changes as rapidly as you imply make the firmware field updatable, and track the product as "Revision X hardware with revision Y firmware" -- in no small part for the reasons you detail. Even if you don't make the firmware field updatable, it's often wise to make it an easy update on final assembly, so that what you stock is the unprogrammed board, and loading firmware is done in some unit test step.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.