1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

How to manage serial numbers

Discussion in 'Embedded' started by pozzugno, Apr 10, 2014.

  1. pozzugno

    pozzugno Guest

    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?
     
    pozzugno, Apr 10, 2014
    #1
    1. Advertisements

  2. pozzugno

    Uwe Bonnes Guest

    What about buying One-Wire ID Chips or other parts with a unique ID?
     
    Uwe Bonnes, Apr 10, 2014
    #2
    1. Advertisements

  3. pozzugno

    Tim Wescott Guest

    I'll be he's got the board designed already.
     
    Tim Wescott, Apr 10, 2014
    #3
  4. pozzugno

    Tim Wescott Guest

    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, Apr 10, 2014
    #4
  5. pozzugno

    Paul Rubin Guest

    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.
     
    Paul Rubin, Apr 10, 2014
    #5
  6. 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, Apr 10, 2014
    #6
  7. pozzugno

    David Brown Guest

    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.
     
    David Brown, Apr 10, 2014
    #7
  8. pozzugno

    David Brown Guest

    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.
     
    David Brown, Apr 10, 2014
    #8
  9. pozzugno

    Paul Rubin Guest

    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.
     
    Paul Rubin, Apr 10, 2014
    #9

  10. 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.
     
    Robert Wessel, Apr 11, 2014
    #10
  11. pozzugno

    Paul Guest

    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 |
    <http://www.pcserviceselectronics.co.uk/> PC Services
    <http://www.pcserviceselectronics.co.uk/pi/> Raspberry Pi Add-ons
    <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
    <http://www.badweb.org.uk/> For those web sites you hate
     
    Paul, Apr 11, 2014
    #11
  12. http://www.rpmsys.com/avr_programmer.htm
     
    Boudewijn Dijkstra, Apr 11, 2014
    #12
  13. pozzugno

    antedeluvian Guest

    If you are using some form of Ethernet, how about a system using or base
    on the MAC address?
     
    antedeluvian, Apr 11, 2014
    #13
  14. 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
     
    Theo Markettos, Apr 11, 2014
    #14
  15. pozzugno

    Paul Rubin Guest

    If you generate perfectly random 32-bit numbers you should expect
    to see duplicates after around 64k, due to the birthday paradox.
     
    Paul Rubin, Apr 11, 2014
    #15
  16. pozzugno

    mac Guest

    If you are using some form of Ethernet, how about a system using or based

    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.
    -
    mac the naïf
     
    mac, Apr 11, 2014
    #16
  17. pozzugno

    pozz Guest

    Il 10/04/2014 17:38, Uwe Bonnes ha scritto:
    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.
     
    pozz, Apr 11, 2014
    #17
  18. pozzugno

    pozz Guest

    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!
     
    pozz, Apr 11, 2014
    #18
  19. pozzugno

    pozz Guest

    Il 10/04/2014 19:09, Paul Rubin ha scritto:
    The sequence could have gaps, but I don't think it's important.

    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.
     
    pozz, Apr 11, 2014
    #19
  20. 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
     
    George Neuner, Apr 11, 2014
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.