How to manage serial numbers

I don't know where to post this question, maybe here someone has faced the same problem in the past and could give me some good ideas.

I have to ship products with a different 32-bits serial number saved in a non-volatile memory (actually it's the internal EEPROM of AVR microcontrollers). Of course, I have to be sure to avoid two identical numbers in different devices.

I was thinking to a server-side application that is responsible to find and release a new serial number. The programming process started on a client PC should be:

  1. acquire a *new* (and never used) serial number from a server on the same LAN;
  2. generate the programming file for the memory (.bin, .hex, .eep, ...);
  3. program the memory;
  4. give positive/negative feedback to the server;
  5. in case of positive feedback the server should definitevely allocate the serial number saving it in a simple database with some useful info (date and time when the serial number was allocated, type of embedded device, ...)

I know I can write some code (scripts or other) for the server side and client side applications, but I was wondering if there's a ready solution to use for my needs.

The separation between server and client could be useful if the PC used for programming the device is far from the server (the database with serial numbers will be very important) and/or there are many PCs dedicated to programming.

For my skills, the server side application is more difficult.

Any ideas?

Reply to
pozzugno
Loading thread data ...

What about buying One-Wire ID Chips or other parts with a unique ID?

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de 

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt 
 Click to see the full signature
Reply to
Uwe Bonnes

I'll be he's got the board designed already.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

If you don't have the board designed yet, then go shopping for a microprocessor or a chip that comes serialized. If you do already have the board designed, double-check that your chip doesn't already do that (Some do. I don't pay attention to the AVR line these days, so I have no clue if you can reasonably expert yours to).

If you're ordering your microprocessors already programmed from the distributor, inquire about getting them with some specific location in memory already programmed. If they say "yes", I'd do a bit more vetting

-- I'd ask them for names of at least three satisfied customers and then I'd ask those places how they like the service.

If your board comes with a serial number, use that for the serial number in the chip.

Totally useless to you, but this could be a small cloud business -- make the server side application so that it works for any number of user accounts, then sell users unique serial numbers.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

This is traditionally a pain in the neck to get right. Do the serial numbers actually have to be serial (i.e. sequential rather than possibly having gaps)? Do they have to be 32 bits? How disastrous is it if two devices somehow end up with the same serial number? How long will the device be in production, how many are you going to make, will you manufacture them at multiple locations, etc.? You have to make sure every possible production facility stays in sync.

There are many examples of supposedly unique ID's like hardware MAC addresses or evey cryptographic keys ending up with duplicates, due to various sorts of process failures.

If your application can stand it, IMHO the simplest thing to do is assign a completely random 128 bit device ID to each device. You'd use one of the the cryptographic random number generators included in some OS's (/dev/urandom for linux, CryptGenRandom for windows). If your random ID's are B bits long and there are N devices, the probability that some two devices got the same ID is approx. N**2/2**B. So if there are a billion devices and 128 bit ID's, that's about 2**60/2**128 or

2**-68 or about 3e-21, if I got that right. That's low enough to be negligible. Now you don't have to worry about parallel manufacturing, maintaining or replicating counter state across production runs, etc. Life is good.

You can also do stuff like include a 32 bit timestamp and a manufacturing equipment ID, but don't rely completely on those since it's easy for clocks to be set wrong, and the manufacturing equipment ID to have a uniqueness failure.

Reply to
Paul Rubin

If this is all going into a central DB in any event what's wrong with using the built in serial type and going with whatever gets assigned, e.g. in PostgreSQL that would be:

create table serial_numbers ( id serial primary key, allocated timestamp not null -- Anything else to store... );

Create a new serial with an:

insert into serial_numbers (allocated) values (now());

and retrieve the value allocated with:

select currval('serial_numbers_id_seq');

Yes, that does work, at least in a transaction and on Postgres, in that you're guaranteed the number last allocated by that transaction even if other transactions allocate another serial in the interim. Refer to the manual for the exact syntax and semantics on other DBMSes.

--
Andrew Smallshaw 
andrews@sdf.lonestar.org
Reply to
Andrew Smallshaw

If you have boards with serial numbers already defined (such as on the microcontroller, or Dallas one-wire devices) then it is easy to get unique numbers. But if he wants a database with the numbers and date stamps, he needs to write client/server code to read out the numbers and store them in the database. It will not necessarily save much effort in the long run.

Reply to
David Brown

That was my first thought. If you think it is hard to generate a sequence of unique serial numbers, you really are in the wrong business.

It's another matter if it is vital to be sure there are no missing numbers - then you have to be sure that your test procedures (and usually board programming) happens before allocation of the serial number, so that failed boards don't leave gaps in your list. But that is not normally an issue, unless you don't want your customers to see embarrassingly long gaps!

One thing that /can/ make this a little more difficult is that you often want the serial number printed on the card, which can take coordination between a label printer and your PC software.

Reply to
David Brown

Depending on the requirements, it can be harder than it sounds. Client/server is one approach, but do you really want to have to stop your manufacturing line just because an internet connection went down? Even if the internet stays up, does its very presence mean you have to deal with a bunch of resulting potential security issues? Do you really want to sign up to keep administering that database across the entire production life of the product, that might be decades, just for the sake of keeping the serial numbers sequential? Etc. etc.

Reply to
Paul Rubin

Even with 32 bits, assuming the production rate is not too high, you can just make it a structured timestamp, say a 13 bit day number, 6 production line number and a 13 bit timestamp. So long as you're not going to be in production for more than 22 years, have more than 64 simultaneously active production lines, or have a production line produce more than one unit every 10.6 seconds, you're done. A longer serial number makes that more flexible.

Another approach is to assign blocks of serial numbers to production lines. Preferably at least several hours or days worth from a central source. That way you don't need a live connection to the central database.

Of course, that only produces unique IDs. As others have mentioned, we don't know all of the OPs requirements.

Reply to
Robert Wessel

Whats more useful is to have method barcode or embedded RFID for tracking batch runs (Yeild of batch, rev status, part date codes used etc).

But make this in some way totally local to production even to extent of rolls of preprinted barcodes, or similar. That can be later uploaded if needed as a batch process to some central database. Why does it matter that it is issued at what second of day. Pre allocate and document in batch is easier to maintain and administer

A tracking ID does not have to be the final serial number, which depending on product, market and some regulatory details means at end of production you may have to REPEAT that serial number to put label on case, label on packing box, paperwork, pallet list, shipping manifest certificate of conformity.......

How much you need a serial number or some form of tracking ID depends on your circumstances that only you know.

If in different countries what is wrong with plant number, or country or destination market or even year of manufacture being in the serial number as well.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk 
    PC Services 
 Click to see the full signature
Reply to
Paul

formatting link

--
(Remove the obvious prefix to reply privately.) 
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Reply to
Boudewijn Dijkstra

If you are using some form of Ethernet, how about a system using or based on the MAC address?

--------------------------------------- Posted through

formatting link

Reply to
antedeluvian

Simples:

unsigned int seed=0xDEADBEEF; /* your secret here */ srand(seed);

for (each request) printf("ID = %x\n", rand());

There will be no apparent ordering in the IDs. You may wish to pay close attention to your system's rand() implementation to check it's 32 bits long and has a 2^32 bit sequence length. To be safe you probably want to import a known-good 32 bit PRNG implementation.

Theo

Reply to
Theo Markettos

If you generate perfectly random 32-bit numbers you should expect to see duplicates after around 64k, due to the birthday paradox.

Reply to
Paul Rubin

This reminds me of a method once suggested for generating those addresses. Use the serial number from a dollar bill, and tape it into the cabinet. Of course, in those days, MAC interfaces were large and expensive, so $1 per SN wasn't unreasonable.

-
Reply to
mac

Unfortunately my board is already designed and is in production. Anyway they are a very low-cost products, so I prefer to use PC to generate unique serial numbers instead of adding cost to the board.

Reply to
pozz

Il 10/04/2014 17:48, Tim Wescott ha scritto:

Actually I'm using ATmega32A, ATmega168A and ATtiny4313. It seems they aren't serialized.

I already purchased microcontrollers... anyway I don't think the distributor/manufacturer would have offered this kind of service for me.

Yes, the product will have the serial number that is the same I need to generate with this system and save in the non volatile memory.

Good idea!

Reply to
pozz

The sequence could have gaps, but I don't think it's important.

Yes.

They are automatically recognized on a RS485 bus thanks to unique numbers. If two devices have the same serial number and they are on the same bus, the master will not be able to find them and work with them.

I don't know, I hope 20 years :-)

1000pcs/month or 10000pcs/month or ....

No, I don't think so.

I can use the same server on Internet that distribute unique numbers to multiple facilities.

I imagine.

Yes, this could be a good solution. The drawback is I will lost a central database filled with all the serial numbers and info about the device.

Reply to
pozz

Manufacturer assigned MAC addresses are *not* guaranteed to be unique ... they really only are a best effort.

Moreover, many (most?) chips allow the MAC address to be changed by software. Multiport NICs frequently ship with all the ports set identically and the software _must_ change them or network fabric will be driven crazy. Becomes interesting when you have many such NICs in the same network.

George

Reply to
George Neuner

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.