Programmed device - labelling requirements?

Hi all

I need some advice about requirements for labelling of programmed devices and wondered if someone can point me at documentation (FDA/ISO/IEC/BS) that identifies the exact labelling information required.

Some background:

I want to implement a PCB/programmed component labelling system across company that treats all programmable devices equally (EEPROMS, uC, PLDs, FPGs...etc) whether they are programmed on or off PCB.

I've read certain parts of the FDA 820 and BS EN 60601 (my company is medically based) but the only info defining labelling requirements I found was MIL-STD 130/129. This document appears to provide some light.

Our corporate systems allow full batch traceability but my argument for device labelling is simply based on gut feel that 'you can't beat a label'! Of course my presumption assumes that human readable info on programmed devices assists the field service personnel (and anyone else come to think of it) identify it's content but to assist me I need to point at a document saying "thou shall label all programmed devices with the following information:". This makes my life much easier in the convincing certain departments of this route.

Some questions:

What are the minimum identification markings for a device label - part number, firmware version, date of programming?

What happens to the device when a user upgrades the firmware - the label's firmware number is now invalid.

How does industry label devices too small to affix labels?

How does industry cope with batch programming and labelling at a latter date?

Does industry really need a label on programmed devices at all - what's the real purpose?

Thanks for any input chaps. Lea

Reply to
Loading thread data ...

We assign a software ID number and rev letter to each formal software release. A typical number might be 22376B. We stick a label on every programmed part, no matter how it's programmed.

We use mostly Xilinx FPGAs, which are ram based, so we don't label them. A typical product will have an eprom or a flash chip that contains uP code and one or more Xilinx config files, all rolled up into a single release.


Reply to
John Larkin

As a general rule, we solder programmable parts to the board unprogrammed, and program them using JTAG or a parallel interface. We avoid pre-programmed parts like the plague, but we still have some to deal with.

We don't label parts that are blank at board assembly. The file to program a part is maintained with the assembly build configuration. The file is not permitted to change once it's in build configuration. If a change in the file is required, then this is treated like a component change. In this case a new assembly part number is generated and a new complete build configuration documentation (and file) set is produced for the new assembly part number. Therefore, all we need to identify the file(s) in any given assembly is the part number of the assembly. We don't rev assemblies.

When a part has to be programmed ahead of time then we treat this as an assembly itself. We have a build configuration documentation and file set for the programmed PROM. This includes all programming and labeling instructions. All we really need on the label is our part number, but we will provide additional information on the label if there is room. Again, if a file change is required then this would force a new programmed PROM part number, and then this would in turn force a new PCB assembly part number for the PCB where it is used. This protocol ensures that the exact file can be traced from the top level assembly in all cases.

We allow some flexibility during initial prototype debug and verification. While there are only a few assemblies that are under our control we permit changes to the assembly (or PROM) without forcing the generation of new part numbers. Once the design is released to production it is then frozen, and no more changes are permitted.


Greg Neff VP Engineering

*Microsym* Computers Inc.
Reply to
Greg Neff

Hi John and Geoff

Thanks for your comments, most welcomed. We are medically driven and so have similar proceedure for batch traceability of parts as both you guys, but I'm specifically interested in arguments for and against placing labels on programmed parts. Industry has previously always placed labels on the final programmed part but I need to understand why! Obviously you both use labels too, but I really need documentaional evidence - regulatory standards for labelling would be the ideal.

There is much talk of labelling components in general in the MIL-STD-130 spec but I would hope for a harmonized (euro/US) spec.

Would be do me a favour and briefly review your company procedure manuals to see if the author has referenced any regulatory documents?

Would be MUCH appreciated.

Kind regards Lea

Reply to

So that, if a customer has a problem, he can look at a board and tell us the programming configuration, and we can see if he's up to date. We have, in theory, manufacturing and RMA (return/repair) records that could tarck his product by serial number, but checking the labels is quicker and a good crosscheck.

We avoid regulatory standards whenever possible. But we don't get audited, as a medical equipment supplier does.

The author was me, and no docs are referenced. Sorry.


Reply to
John Larkin

With UV-erasable EPROM's, an opaque label was more necessity and less luxury. Even if the label was blank :-)


Reply to
Tim Shoppa

I found some more MIL stuff. I checked the requirements for a UV EPLD in MIL-M-38510/507A. It says only this about marking:

"Marking shall be IAW MIL-M-38510. For programmed devices, the altered item part number shall be added to the marking by the programming activity"

Interestingly, there is no mention of covering the window after programming.

I also quickly looked at:

MIL-STD-1285 MIL-PRF-38535 MIL-STD-13281

From the MIL side it looks like labels on semiconductors may be a problem, because the altered item part marking is not permitted to obscure the factory part markings.

For those that are not aware, MIL standards can be downloaded for free from:

formatting link

The only reference I found to a regulatory standard is UL 969, but I'm not sure at all that this applies. Here is the scope:

formatting link


Greg Neff VP Engineering

*Microsym* Computers Inc.
Reply to
Greg Neff

Hi All

Apologies for the delay in responding but had to fly out of town on business so had to let the label issue rest until my return.

Now I'm back and of course I still need to resolve this issue across company and so have taken all your comments on board - they're the same as mine so it's good to know I'm thinking along the correct lines and I'm sure these can be argued as simply common sense!

However, I now need to consider programmed parts that cannot accept labels as I endeavour to make the label process common for parts programmed on and off board alongside parts that can accept a label or not.

Of course, I also need to consider parts, which can be upgraded via the user - now it gets a little more tricky!

Time for some further thinking!

Reply to


I used to work at a company that made medical equipment and used lots of programmable devices. You're right, it gets a lot trickier when you can do in-field upgrading. In that case, it is impossible to make sure that a physical label matches the actual revision of a part.

What my previous company did was have a suffix that was a combined revision of all the programmable devices. So each time one (or more) of the devices changed via an update that suffix was incremented. The combined rev was also stored in the flash so that you could read out the current revision. So the physical labels gave you the state it went out the door at and the electronic labels gave you the current versions of everything.

The downside of this is that it appeared in the ERP system and anytime one programmable device changed there were mountains of paperwork to change the combined revision suffix all the way up the BOM tree.

As devices became more dense, a requirement evolved to indicate that every programmable part had to be able to return its revision to the onboard processor. This made upgrading a lot easier since s/w could be written to only upgrade what was needed and began to make the combined revision a bit redundant. The system hadn't evolved to the point of getting rid of the combined revision and only using electronic labelling but that was the next logical (although widely contested) step.

One bit of advice: Don't let stuff out you know that you will need to rev in order to fix bugs. There's enough paperwork to do there's no sense volunteering.


Reply to
James Morrison

Hi James

Very wise words and I've interestingly come to similar conclusions after discussing the best way forward with various R&D and Manufacturing colleagues.

My plan is to mandate that prog. devices that are 'user' upgradeable (very common in consumer markets, but now also creeping in the Medical field too) the design includes electronic methods of version recovery for each device. Whether this is by visual (assuming some type of display) or simply by RS232 and a small debug connector (or similar) - field service engineers. can simply connect their laptops.

Of course another thing to consider is that real estate of programmable devices has previously been sufficient area to place labels, BUT often (FPGAs for example) the programmable code is stored within a configuration device and this is too small for a label and naturally has a very low pin count.

Now and in the future we'll have even more ICs that cannot accept labels, and in my opinion this percentage will grow significantly over the next few years so I have considered using a label area on the PCB assy. to represent all devices.

Here's my thoughts.

On the PCB we silk-screen multiple boxes (accounting for the number of prog. devices) and place text within, something similar to that shown below:


So as the operative programs the PCB (whether on board or off board) labels can be affixed over the top covering the 'UNPROG' silk screen. Maybe labels with the following info:

U1 V2.4 U4 V1.0 U7 (V1.1) U24 V2.3 A10001000 R2 - this label is ONLY affixed upon the completion of all programming and is the final top-level number indicating the PCB is now fully programmed and ready for despatch/restocking.

The R2 indicates top-level revision number. The brackets around the version number indicate 'user' upgradeable part' and this was the version at time of programming/shipping.

For us, this system has many advantages: flexibility allowing intermediate storage of the assy. at any stage (after reflow we can return the PCB to stock); it's programmed state will be known at any point of manufacture and flexibility in terms of programming sequence

- the operative can program 100 off U7 parts then return latter to program the U24 parts.

Only downside is real estate for size optimised PCBs with multiple prog. devices!

Thanks for all the comments. Lea

Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.