I was wondering how people handle a firmware change in the
manufacturing process. One thing we are considering is issuing a
new part number for every firmware release. The number may be a "Rev
B" or some extension of a base part number, but it would be unique for
each firmware release. Then, when a unit is built, it must use a
certain "part number" that is really a firmware release, probably in
the form of some FLASH programming device, or at least a file that
contains the memory image for a micro-controller.
A problem comes into play if there are already manufactured units
ready to ship when a new firmware release is issued. I would think
the micro-controller, or EPROMs, or whatever form the firmware is
released in would have a sticker on it with maybe the part number? Or
should the sticker have the firmware revision number, or both?
We also thought of forgetting about the part number scheme and just
having some sort of list or database with the "correct" firmware
release listed. The advantage there would be special runs of an older
firmware release (something we have to do at times) could easily be
made without worrying about using a part number that was obsoleted by
a newer one.
I know the best way can cepend on the manufacturing/part number/ECO
system in use. But I am sure others have been down this road before
and may have some good suggestions. I am all ears and thankful for
those that may wish to reply.
Lou
Reply by ●April 7, 20052005-04-07
> I was wondering how people handle a firmware change in the
> manufacturing process. One thing we are considering is issuing a
> new part number for every firmware release. The number may be a "Rev
We consider a programmed microcontroller or EEPROM to be a subassembly
with its own bill of materials. When the firmware is revised, the part
number gets an incrementing suffix. The downside of this method is that
it's legal for the blank microcontroller to change, too. So it might
not be possible to upgrade from version xxxxx1 to xxxxx2 without
desoldering the part. This doesn't affect us much because we mostly use
OTP devices and even when they are flash devices, we don't allow
field-upgrades (it's RTB or no upgrade).
> released in would have a sticker on it with maybe the part number?
Or
> should the sticker have the firmware revision number, or both?
Our stickers have the internal part number only. Users and factory
workers don't normally care about the internal firmware rev#, they
simply need to be told "if the part number is xxxxxx2 or higher, it's
got ABC feature".
Masked parts are laser-marked with the internal part number.
Reply by Paul E. Bennett●April 7, 20052005-04-07
Mr. C wrote:
> I was wondering how people handle a firmware change in the
> manufacturing process. One thing we are considering is issuing a
> new part number for every firmware release. The number may be a "Rev
> B" or some extension of a base part number, but it would be unique for
> each firmware release. Then, when a unit is built, it must use a
> certain "part number" that is really a firmware release, probably in
> the form of some FLASH programming device, or at least a file that
> contains the memory image for a micro-controller.
>
> A problem comes into play if there are already manufactured units
> ready to ship when a new firmware release is issued. I would think
> the micro-controller, or EPROMs, or whatever form the firmware is
> released in would have a sticker on it with maybe the part number? Or
> should the sticker have the firmware revision number, or both?
>
> We also thought of forgetting about the part number scheme and just
> having some sort of list or database with the "correct" firmware
> release listed. The advantage there would be special runs of an older
> firmware release (something we have to do at times) could easily be
> made without worrying about using a part number that was obsoleted by
> a newer one.
>
> I know the best way can cepend on the manufacturing/part number/ECO
> system in use. But I am sure others have been down this road before
> and may have some good suggestions. I am all ears and thankful for
> those that may wish to reply.
>
> Lou
If you consider that the firmware is just another component, mentioned on
the bill of materials then you should not have much problem tracking what
is what.
I identify things by main functionality. If the base functions change then
that is a different part number (and a different model dash number for the
final product too). For upgrades that maintain the same base functionality
the part number is the same but the revision number changes. Each item that
has a part number has a proper drawing in the general assembly set that
details the part (and yes, if it is an EPROM, the part is drawn with one
view showing the labelling details).
Keeping track of the changes is basic configuration management.
--
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************
Reply by Lanarcam●April 8, 20052005-04-08
larwe@larwe.com wrote:
> > I was wondering how people handle a firmware change in the
> > manufacturing process. One thing we are considering is issuing a
> > new part number for every firmware release. The number may be a
"Rev
>
> We consider a programmed microcontroller or EEPROM to be a
subassembly
> with its own bill of materials. When the firmware is revised, the
part
> number gets an incrementing suffix. The downside of this method is
that
> it's legal for the blank microcontroller to change, too. So it might
> not be possible to upgrade from version xxxxx1 to xxxxx2 without
> desoldering the part. This doesn't affect us much because we mostly
use
> OTP devices and even when they are flash devices, we don't allow
> field-upgrades (it's RTB or no upgrade).
>
> > released in would have a sticker on it with maybe the part number?
> Or
> > should the sticker have the firmware revision number, or both?
>
> Our stickers have the internal part number only. Users and factory
> workers don't normally care about the internal firmware rev#, they
> simply need to be told "if the part number is xxxxxx2 or higher, it's
> got ABC feature".
>
> Masked parts are laser-marked with the internal part number.
This depends on what you call firmware.
We do the same as you do for parts that can be considered
hardware-like i.e. small MCUs that are replacements for hardware.
But for the main functionality we cannot change the revision number
on labels each time the customer requests a change.
We have a hierarchical database, the top item is the equipment, the
hardware and software are sub items each with their part/rev number.
A document is delivered to the customer and identifies all part/rev
numbers and reasons for change. The manufacturing process is
not affected by main software changes.
Signal Processing Engineer Seeking a DSP Engineer to tackle complex technical challenges. Requires expertise in DSP algorithms, EW, anti-jam, and datalink vulnerability. Qualifications: Bachelor's degree, Secret Clearance, and proficiency in waveform modulation, LPD waveforms, signal detection, MATLAB, algorithm development, RF, data links, and EW systems. The position is on-site in Huntsville, AL and can support candidates at 3+ or 10+ years of experience.