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?
How to manage serial numbers
Started by ●April 10, 2014
Reply by ●April 10, 20142014-04-10
pozzugno@gmail.com wrote:> 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.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 --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Reply by ●April 10, 20142014-04-10
On Thu, 10 Apr 2014 15:38:47 +0000, Uwe Bonnes wrote:> pozzugno@gmail.com wrote: >> 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. > > What about buying One-Wire ID Chips or other parts with a unique ID?I'll be he's got the board designed already. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●April 10, 20142014-04-10
On Thu, 10 Apr 2014 08:29:20 -0700, pozzugno wrote:> 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?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 http://www.wescottdesign.com
Reply by ●April 10, 20142014-04-10
pozzugno@gmail.com writes:> I have to ship products with a different 32-bits serial number... > I was thinking to a server-side application that is responsible..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 by ●April 10, 20142014-04-10
On 2014-04-10, pozzugno@gmail.com <pozzugno@gmail.com> wrote:> > 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?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 by ●April 10, 20142014-04-10
On 10/04/14 17:48, Tim Wescott wrote:> On Thu, 10 Apr 2014 08:29:20 -0700, pozzugno wrote: > >> 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? > > 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. >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 by ●April 10, 20142014-04-10
On 10/04/14 19:42, Andrew Smallshaw wrote:> On 2014-04-10, pozzugno@gmail.com <pozzugno@gmail.com> wrote: >> >> 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? > > 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. >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 by ●April 10, 20142014-04-10
David Brown <david.brown@hesbynett.no> writes:> 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.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 by ●April 10, 20142014-04-10
On Thu, 10 Apr 2014 10:09:05 -0700, Paul Rubin <no.email@nospam.invalid> wrote:>pozzugno@gmail.com writes: >> I have to ship products with a different 32-bits serial number... >> I was thinking to a server-side application that is responsible.. > >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.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.
