What PIM users need to know about the Digital Product Pass (DPP)

Digital Product Passport (DPP) - what may initially seem like another bureaucratic challenge from the EU also offers opportunities. After all, transparency strengthens consumer trust and ensures sustainable customer relationships. But what exactly do the regulations require and how can companies implement these requirements efficiently?

There is already a wealth of information on this topic from service providers, associations, authorities and universities. I would like to place this information in the context of PIM.

What is the background?

The Digital Product Passport (DPP) is a measure within the Green Deal or Sustainable Products Regulation (ESPR). In short, the aim is to create a sustainable product life cycle ("circular economy"). In order to achieve this goal, the buyer should be fully informed about the product ("purchase decision") and so should the authorities ("compliance with laws"). Authorities naturally need different product information than the buyer.

What is the plan and the timetable?

From 2026 to 2030, all relevant product groups will gradually receive a DPP (with the exception of food, feed and medicinal products). This means that each product can be identified (QR code, chip) and the information can be viewed via the ID. In principle, this applies to all industrial manufacturers and retailers.

The DPP is basically a data record. I like to compare this with data records in BMEcat or similar formats. The data record must be available to buyers and authorities at the touch of a button. This requires direct access to database systems. Visualization for buyers can take place on web interfaces or apps, for example. For authorities or B2B customers, the data record can be made available via API interfaces.

What product information is contained in the DPP data record?

There will be a lot of content and it will be constantly expanding; I say there are no limits to the imagination here:

• Product identifiers (item number, EAN, description, etc.)
• Product descriptions
• Technical product data (dimensions, material/surface, electrical and mechanical properties, etc.)
• Logistical data (packaging, weight, customs tariff number, etc.)
• Product images (photos, drawings)
• Approvals, certificates
• Product relationships (spare parts, accessories, scope of delivery)
• Operating and assembly information
• Repair instructions
• Safety instructions
• Components of the product (e.g. relevant for disposal)
• Data for the determination of CO2 footprint and H2O footprint
• Illustration of the product information in the DPP data record

Now you can imagine the huge data quantities that this creates. After all, there are a large number of completely different products with different descriptions. On the other hand, the most diverse terms are also used for properties. For example, some refer to the diameter of a plastic pipe, others to the inner diameter or pipe diameter.

This means that the description and language should be standardized or classified for each product group. Fortunately, common classification systems such as ECLASS or ETIM have been in use for decades and can be used for this purpose.

Technical implementation of DPP

"Just another tool". The technical implementation requires the following components:

• A database system, more precisely a Product Information System (PIM). The data must be validated
• Integrated standard classifications (ECLASS, ETIM), as mentioned above
• Channel Output Management for output control of the DPP-relevant items (at least the items that have been or will be sold from 2026) and the required content and languages
• REST API ("Json") for the provision of data in an X format for direct and secure data access, as mentioned above

The format X is not yet known. Various players, let me put it this way, are "getting involved". I assume that the Asset Administration Shell (AAS) format will prevail, see https://industrialdigitaltwin.org.

In my view, this model has the following advantages, among others:

• Description using submodels is advanced, including Nameplate (product identification), Reliability (electrical components), Technical Data, Contact Information (contact details). See: https://industrialdigitaltwin.org/content-hub/teilmodelle
• Standard classification ECLASS is integrated in the "Submodel Technical Data"

Conclusion

No DPP without PIM. If you already have a PIM with ECLASS, REST API and output control, you can sit back and relax - at least as far as the technical part is concerned. REST API and output control are typically included in the PIM system as standard. If you do not yet have ECLASS, I recommend that you consider using it, ideally integrated into the PIM.

In terms of content, it is certainly necessary to add information. To do this, you need to list the content requirements for DPP data, compare them with the existing data in the PIM and check the delta, i.e. where the missing data needs to be maintained (e.g. in the ERP or in the PIM). This process cannot be started early enough, because experience has shown that it is the most time-consuming.