Identifier for physical devices

[iomz]

To identify each physical devices (e.g., sensors, robots, etc...) in a "device profile" we need an identifier. Such devices usually don't have MAC or IPv6 address, so GIAI from GS1.

GIAI consists of the GS1 Application Identifier (8004), GS1 Company Prefix (7612345206 for our range), and Individual Asset Reference (something within 20 digits). We can use this 20-digit space to identifier individual assets.

[iomz]

For more details about GIAI, see the genspec: https://www.gs1.org/standards/barcodes-epcrfid-id-keys/gs1-general-specifications ...but I think you can ignore the definition as long as you have the numbers.

[jo-bru]

I was thinking about using a more dynamic profile identifier at the controller level instead of using the GIAI also for the profile/registration identifiers. In this case, the GIAI would only be needed on the gateway for identifying each asset/endpoint. For identification of the registered profiles on the MCU a smaller Profil_ID is used, which is dynamically allocated when the profile is registered. This would have the following advantages:

1. far less space is used on the MCU, since the Profil_ID can be much smaller than 30 digits.
2. we would not need a unique GIAI for each internal peripheral of the MCU (LED, buzzer, buttons, etc.)
3. if an asset has multiple sensors, each sensor can have its own profile
   What do you think about this? I can explain my idea in more detail on Wednesday.

[iomz]

To be honest, I also feel the GIAI is not suitable for identifying individual sensors, but for different reasons. The GS1 ecosystem treats an asset of an object of at least a size on which one of the GS1 data carriers (Barcode, DataMatrix or EPC Tag) can be attached, and not something in thumbnail sizes – it makes sense to use GIAI for the controllers, but not for sensors.

I'm not sure about "Profil_ID". If you mean a proprietary ID scheme then it may degenerate the interoperability and loses transparency in the context of explainability, but this also elicits the need for clarification – we need an identifier for both profiles and sensors.

To address other feature requirements in your proposal:

far less space is used on the MCU

This is not a dominant problem – even the 4k EEPROM can store far more 128-bit numbers than the number of PINs available for one MCU even with other required parameters. However, it becomes a prevalent problem when we need to include the lengthy ID in the line protocol to indicate which sensor data needs to be retrieved from the MCU to the Gateway.

we would not need a unique GIAI for each internal peripheral

We do need identification for each internal peripheral to provide the provenance of the data access – this is the primary initiative.

---

After the consideration above, I'd propose the following:

• Use UUID to identify individual sensors (Device ID) throughout the system, either with a namespace or a completely random generation. This will be the key value to associate the device with other metadata and is issued in the application layers.
• Use a proprietary Profile ID (1 byte) to identify a profile on the MCU. This ID is local to the MCU (Controller) and the Gateway, and the Gateway must generate and maintain the 1-to-1 mapping between the Profile ID and the Device ID at the time of registration – one profile represents one MCU-level data access for one device.
• Registration includes 1.) Profile ID, 2.) Device ID, 3.) Type of Profile (Passive, Active, Hybrid), 4.) Type of Device (Data access method/driver/library), and 5.) Supplementary Information for 4. These are stored as non-volatile data in the MCU and should be retrievable later if it's disconnected from the gateway once.
• After the registration process, the Gateway and the MCU communicate using the Profile ID and not the Device ID.

The use of UUID is open to discussion, but the 1-byte profile ID matches your idea. How about this?

[jo-bru]

Yes, that sounds great! I'm not sure if proto3 supports uint8 types, but for now, I'm using an uint32 type for the profile ID. But we can easily optimize this later.

[iomz]

Aha, true it doesn't. Perhaps length==1 of bytes, but nanopb explicitly excludes type uint8_t: https://github.com/nanopb/nanopb/issues/485

Go for uint32 for simplicity :-)

[jo-bru]

Maybe we could use the first bit of the 8-bit Profile ID to differentiate profiles registered on MCU1 and MCU2. I think this would simplify the profile handling of the different MCUs and saves a bit of space for the registration list as this is implemented as a static array (registered_profiles[])

[iomz]

Not now, the profile management will be done in the Gateway.