Where is the "unique identity" stored?

[sounds]

CopperLan claims to be able to assign a unique identity to each of many identical devices, such that they can be reliably identified after unplugging and reconnecting. Where is this "unique identity" stored? Doe a CopperLan device need to speak some protocol for accepting and storing said ID so that it can be retrieved later?

For example, some USB Devices have a Serial Number, but others do not. Without a serial number, it can be challenging to reliably identify a specific physical unit from another identical unit.

[CopperPhil]

In fact it depends on the application type and capabilities. When an application is creating its CopperLan object structure (just single "device" or a "device tree" for more complex products), it can specify a duplicate number (identifying the instance of this application) like this:
- must be assigned by the network
- favourite number that can be changed by the network in case of ID conflict (two application having the same duplicate number)
- fixed number to be used (might result in an impossibility to get connected in case of conflict)

For computer software, best practice is to rely on the network. Imagine you're loading multiple instances of the same CopperLan application. You're certainly expecting to be able to restore connections between them, so they must get their previous duplicate number... but how to store a set of duplicate number and re-assign them to for each running instance? Possible of course but not so easy, so CopperLan do that for you thanks to its Virtual Network Manager running on the computer. It maintains a list of duplicate number assigned to each instance for a specific application type and restore them in the right order.

For hardware devices (USB or Ethernet) having a serial number/MAC address, it is a good practice to use (part of) it as a duplicate number indeed. In the other case, you can use a random number to assign a default duplicate if it does not exist yet, then store it in persistent memory in order to re-use the same number next time. If another device of the same type already uses this duplicate, a new duplicate will be re-assigned by the network, then the application is notified in order to store the new number. So for embedded systems, the duplicate number must be issued from static information (such as serial number) or from persistent memory. Then it is validated by the network and possibly changed to solve a conflict.

[sounds]

For hardware devices (USB or Ethernet) having a serial number/MAC address, it is a good practice to use (part of) it as a duplicate number indeed. In the other case, you can use a random number to assign a default duplicate if it does not exist yet, then store it in persistent memory in order to re-use the same number next time. If another device of the same type already uses this duplicate, a new duplicate will be re-assigned by the network, then the application is notified in order to store the new number. So for embedded systems, the duplicate number must be issued from static information (such as serial number) or from persistent memory. Then it is validated by the network and possibly changed to solve a conflict.

Where is this persistent memory? In the hardware device, or on some computer?

[CopperPhil]

For embedded system I mean in the hardware device... if you want to assign a unique ID to a hardware and if you want to be able to connect it anywhere on the network keeping the same ID (this should be the normal behaviour of CopperLan hardware), there is no other choice than saving the ID into the hardware itself... Usually it can be done in the MCU's flash memory or using a small EEPROM or something...