The Digital Product Passport: what you need to know about data carriers and product identifiers

In a previous blog post, we explained what the Digital Product Passport (DPP) is and how it works. In this second post, we take a closer look at one very important part of the DPP, how to gain access to it. 

Demystifying the DPP

The DPP is a potentially large collection of product related data including production processes, technical documents, return, maintenance and repair information, origin of components and recyclability etc. 

To access this data, an electronically accessible data carrier with a unique product identifier is used. This may sound a bit abstract, so let’s take a real-life example: the licence plate of a car. In this case, the product is the car, the data carrier is the licence plate itself and the unique identifier is the string of characters on the plate. Each licence plate is unique, and the licence plate number (the string of characters) enables access to detailed data associated with the vehicle. 

The difference with the DPP is that the licence plate is intended to be read visually (i.e. physically) rather than electronically. It is important to note that we have a product (the car), a data carrier (the plate) and a unique identifier(the number).

More about the data carrier

In this article, we’ve decided to focus on the data carrier, or in our example, the licence plate. Accessing the DPP of a product is more or less the same as accessing vehicle data using the unique identifier on the licence plate. However, there is a big difference with licence plates; only one authority is responsible for the unique identifier and for the underlying database(s).

For the DPP, this is much more complex with potentially multiple authorities managing the unique identifier and many databases and other repositories with product information. That’s definitely something for another blog, but for now, let’s focus on the data carrier.

The DPP regulations list some requirements for the data carrier:

• The data carrier shall be physically present on the product, its packaging or on documentation accompanying the product. The rule here is that the data carrier shall be physically connected to the product and only if that is not possible, it shall be on the packaging of the product and only if that is not possible, it shall be on the documentation that comes with the product. In practice, this means that the data carrier must be able to withstand typical use of the product while still enabling access to the DPP.
   
• Although exceptions are possible, in principle, DPP data should be accessible for at least 10 years after the product it relates to has been out on the market or put into service. In practice, this means that the data carrier must be capable of functioning within this period.
   
• The data carrier must provide easy access to the DPP. In practice, this rules out many identification technologies, which are not easily accessible to the many stakeholders targeted by the DPP. These stakeholders include manufacturers, distributors, consumers, maintenance and service facilities, sorters, recyclers, auditors to name but a few. All these may have different use cases in which they must access the DPP, but they must be able to easily access the relevant  data connected to a product.. For example, a consumer may never want to access DPP data in bulk, but a recycler or sorter will need it.
   
• The data carrier must be able to contain and communicate the unique identifier. As there is no single definition of the unique product identifier for the DPP, it’s impossible to say for a specific data carrier if this requirement can be met. On the other hand, the likely candidates for the data carrier are all capable of containing enough information for even the most complex identification scheme.

These are all mandatory requirements for the data carrier in the current DPP regulations. This means that the current regulations do not require for example additional information or functionality from the data carrier besides the ability to communicate the unique identifier. Even though it is not mandatory, for some products, it may make sense to add functionality to the data carrier; like for example, additional memory to store basic information allowing access to important information in cases where the DPP cannot readily be accessed (e.g. due to a lack of network access, inaccessible data etc), or for product authentication. 

QR codes & Barcodes VS RAIN & NFC tags

There are some obvious candidates for the data carrier which are widely discussed and also named in the draft EU regulations for the DPP: QR codes, barcodes and RFID. For RFID tags, the choice is between the NFC and RAIN tags. Let’s take a closer look at the candidates:

Accessible with smartphone simply means that the data carrier can be read using a smartphone. Preferably without a dedicated app. QR codes and NFC can be read with a smartphone, RAIN tags for the moment cannot, although the RAIN Alliance is working very hard to bring RAIN functionality to smartphones. Barcodes can be read with a smartphone to some extent, but they require specific apps.

Line-of-sight is required to be able to read QR and barcodes. In practice, this means that when using such codes, they must be visually accessible. It can be hidden, but it must be easy to uncover. RFID does not require line-of-sight and can be permanently hidden from view and from places where there is a lot of wear and tear. RFID is to some extent sensitive to the materials used, and care should be taken to ensure that the correct selection is made.

Longevity is more of an issue with QR and barcodes, as wear and tear can make these codes unreadable. As RFID tags can be placed inside  a product or in well protected areas and have a proven track record of functioning for very long time periods of time under extreme conditions, they score a plus in this category.

In terms of price, QR and barcodes are generally printed and for that reason they are a more cost-effective option. RFID tags require a chip and an antenna and are more expensive, although costs have come down dramatically.

For bulk reading (reading of many tags in a very short time) and read range, there is one technology that excels and that is RAIN as it is specifically designed for this. 

Protection against copying is not a mandatory requirement for the data carrier, but it is something to consider. Taking the licence plate of a car as an example again, the plate is easy to copy. There are however different mechanisms in place to enforce that a car has a correct plate. For some product categories, it makes a lot of sense to protect the licence plate itself from being copied and RFID offers ways to implement such functionality.

Conclusion

The difference really falls between two “line-of-sight” and two “non-line-of-sight” technologies. 

• Choosing between QR codes and barcodes is easy: people are used to dealing with QR codes and the technology is well standardised. They can be read with a smartphone using the camera, so in principle, no specific app is required. 
   
• The choice between NFC and RAIN also seems obvious as RAIN tags have the disadvantage that they cannot be read directly with a smartphone, while NFC tags can. As mentioned before, RAIN however has two big advantages: read range and bulk reading, both of which can be important for certain stakeholders. As mentioned above, the RAIN Alliance is working very hard to get the RAIN technology integrated into smartphones.
   
• The choice between using QR codes and RFID might seem an easy one, as QR codes can be implemented at very low cost. However, it is not all about price! . Longevity, the ability to identify without a line of sight and automated bulk reading, to name a few, must also be considered. The choice of data carrier technology to implement the DPP really depends on the application and lifecycle of the product. 

One other thing to consider is the combination of technologies to get the best of both worlds. Combining a QR code and a RAIN tag ticks all the boxes and provides a very powerful solution that can be used throughout the lifecycle of a product by any stakeholder.