Programmed device - labelling requirements?

[LeaUK]

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

 

[Greg Neff]

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

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.
[email protected]

 

[John Larkin]

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

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.

John

 

[LeaUK]

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

 

[John Larkin]

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!

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.

Obviously you both use labels too, but I really need
documentaional evidence - regulatory standards for labelling would be
the ideal.

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

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?

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

John

 

[Tim Shoppa]

Industry has previously always

placed labels on the final programmed part but I
need to understand why!

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

Tim.

 

[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

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:

http://assist.daps.dla.mil/quicksearch/

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:

http://ulstandardsinfonet.ul.com/scopes/0969.html


================================

Greg Neff
VP Engineering
*Microsym* Computers Inc.
[email protected]

 

[LeaUK]

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!

 

[James Morrison]

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!

Lea,

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.

Cheers.

 

[LeaUK]

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:

U1 UNPROG
U4 UNPROG
U7 UNPROG
U24 UNPROG
Axxxxxxxx

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