---
title: "Electronics DPP Implementation Guide | OpenEPCIS Docs | OpenEPCIS - an open-core, GS1-compliant EPCIS implementation."
canonical_url: "https://openepcis.io/de/docs/digital-product-passport/electronics/implementation-guide"
last_updated: "2026-06-28T23:26:21.729Z"
meta:
  author: "benelog GmbH & Co. KG"
  description: "How to assemble an Electronics Digital Product Passport against the published openepcis-dpp-ready electronics vocabulary"
  keywords: "Electronics DPP implementation, repairability index, WEEE category, EPREL, software support"
  "og:description": "How to assemble an Electronics Digital Product Passport against the published openepcis-dpp-ready electronics vocabulary"
  "og:title": "Electronics DPP Implementation Guide"
  "twitter:description": "How to assemble an Electronics Digital Product Passport against the published openepcis-dpp-ready electronics vocabulary"
  "twitter:title": "Electronics DPP Implementation Guide"
---

</h2>Home

``

# **Electronics DPP Implementation Guide** How to assemble an Electronics Digital Product Passport against the published openepcis-dpp-ready electronics vocabulary [~~electronics~~](https://openepcis.io/de/tags/electronics)· [~~implementation~~](https://openepcis.io/de/tags/implementation)· [~~repairability~~](https://openepcis.io/de/tags/repairability)· [~~weee~~](https://openepcis.io/de/tags/weee)· [~~energy-label~~](https://openepcis.io/de/tags/energy-label)· 5 min read ## Overview This guide walks through assembling an electronics DPP that uses **only published vocabulary** — terms defined in the OpenEPCIS electronics ontology and the GS1 Web Vocabulary. It mirrors the canonical reference passports under [`**extensions/eu/electronics/examples/**`](https://github.com/openepcis/openepcis-dpp-ready/tree/main/extensions/eu/electronics/examples) in the dpp-ready repo. > **Conventions.** In JSON-LD documents the property names are **bare** — the JSON-LD context maps them to the right namespace. So you write `**"deviceCategory": "Smartphone"**`, not `**"electronics:deviceCategory"**`. Controlled values likewise come out unprefixed once `**@vocab**` is set. ## Prerequisites - A GS1 Company Prefix and assigned GTINs for the products you'll passport. - A resolver that can host the linkset for each Digital Link URL (see [Resolver Setup](https://openepcis.io/docs/digital-product-passport/resolver-setup)). - The electronics JSON-LD context: `**https://ref.openepcis.io/extensions/eu/electronics/electronics-context.jsonld**`. - For battery-containing devices (smartphones, laptops, e-scooters), also the battery context. The cleanest pattern for composite products is to expose the embedded battery as its own resolvable DPP (see [multi-component example](https://openepcis.io/docs/digital-product-passport/multi-component-example)). ## Step 1: Identify the device Every device gets a GS1 Digital Link URL — `**https://id.gs1.org/01/{GTIN}/21/{serial}**` for a serialised unit, or just `**/01/{GTIN}**` for SKU-level information. The same identifier becomes the `**id**` of the passport document and the `**epcList**` value in every EPCIS event. Dual-type the document: `**"type": ["Product", "Smartphone"]**` (or `**Laptop**`, `**Display**`, `**Server**`, …, drawn from `**electronics:DeviceCategory**`). ## Step 2: Repairability — French Index and EU Right-to-Repair grade The electronics vocabulary supports both repairability methods side by side: - The **French Repairability Index** is captured as an `**electronics:RepairabilityIndex**` block with one `**electronics:RepairCriterion**` per scored axis ( `**Documentation**`, `**Disassembly**`, …). The published vocabulary defines `**electronics:RepairCriterionType**`; the actual weighting per axis is set by French regulation per product family and is _not_ embedded in the passport. - The **EU Right-to-Repair grade** is captured as `**electronics:EURepairabilityClass**` with one of `**RepairClassA**`, `**RepairClassB**`, `**RepairClassC**`, `**RepairClassD**`, `**RepairClassE**`. For the calculation tables and per-family weights, refer to the [official French Repairability Index methodology](https://www.ecologie.gouv.fr/indice-reparabilite). For replaceability of individual parts use `**electronics:ReplacementDifficulty**` (`**UserReplaceable**`, `**ToolRequired**`, `**ProfessionalOnly**`, `**NotReplaceable**`). ## Step 3: Energy class and EPREL registration`**electronics:EnergyEfficiency**` carries the labelling data. The class itself goes in `**electronics:EnergyEfficiencyClass**` (`**EnergyClassA**` … `**EnergyClassG**`), and the EU Product Registry for Energy Labelling reference goes in `**electronics:eprelRegistrationNumber**`. `**electronics:annualEnergyConsumption**` captures the declared annual figure when the regulation requires it (washing machines, dishwashers, refrigerators, TVs). ## Step 4: WEEE registration (Annex III, six categories)`**electronics:WEEECategory**` is the controlled list from WEEE Directive 2012/19/EU Annex III — the six current categories: 1. `**WEEE1_TemperatureExchange**` — fridges, freezers, heat pumps 2. `**WEEE2_ScreensMonitors**` — TVs, monitors, displays > 100 cm² 3. `**WEEE3_Lamps**`4. `**WEEE4_LargeEquipment**` — any large appliance > 50 cm 5. `**WEEE5_SmallEquipment**` — small appliances ≤ 50 cm 6. `**WEEE6_SmallIT**` — small IT and telecom equipment ≤ 50 cm Producer registration goes in `**electronics:weeeRegistrationNumber**` with `**electronics:weeeRegistrationCountry**`. Take-back / collection program URLs are referenced from the core DPP block `**dpp:EndOfLifeProgram**`. ## Step 5: Spare-parts policy`**electronics:SparePartsAvailability**` captures the years a manufacturer commits to keeping spare parts available; `**electronics:SparePartsPricing**` captures the pricing policy. Each enumerated part type uses `**electronics:ComponentType**` (BatteryComponent, DisplayComponent, etc.) with `**electronics:componentPartNumber**`, and the difficulty of replacing it is tagged via `**electronics:ReplacementDifficulty**`. ## Step 6: Software support lifecycle`**electronics:SoftwareSupport**` declares the support commitment. Fields: - `**electronics:firmwareVersion**` / `**electronics:osVersion**` — current versions installed - `**electronics:previousVersion**` / `**electronics:newVersion**` — used when recording an update event - `**electronics:updateType**` — feature, security, bug fix - `**electronics:updateSource**` — provenance (OEM, OS vendor, …) When a software update happens, it is captured as an EPCIS event referencing these properties (see [reference EPCIS examples](https://github.com/openepcis/openepcis-dpp-ready/tree/main/extensions/eu/electronics/epcis), specifically `**software-update.jsonld**`). ## Step 7: Component BOM For laptops, servers and complex devices the component breakdown lives in `**electronics:ComponentBOM**`. Each entry is typed with `**electronics:ComponentType**` (BatteryComponent, CameraComponent, ConnectorComponent, CoolingSystemComponent, DisplayComponent, EnclosureComponent, KeyboardComponent, MemoryComponent, MicrophoneComponent, MotherboardComponent, PowerSupplyComponent, ProcessorComponent, SpeakerComponent, StorageComponent, TrackpadComponent) plus `**electronics:componentPartNumber**` and the replaceability info from Step 5. For products that combine an electronic device with a separately-regulated battery, prefer the multi-component pattern — the battery has its own GS1 Digital Link URL and its own passport. See [multi-component example](https://openepcis.io/docs/digital-product-passport/multi-component-example). ## Step 8: Publish the electronics linkset The electronics passport is served from an IETF `**application/linkset+json**` document (RFC 9264) — one object per `**anchor**` identifier, GS1 link relations as full-IRI keys. For a smartphone or laptop you typically want the consumer PIP, EPCIS history (commissioning, repairs, software updates), the repair/service information, the carbon-footprint / energy declaration, and the certification dossier:```
{
  "linkset": [
    {
      "anchor": "https://id.gs1.org/01/09521234000013/21/PHONE-2025-001",
      "itemDescription": "EcoOS smartphone",
      "https://ref.gs1.org/voc/defaultLink": [
        { "href": "https://dpp.example.com/electronics/09521234000013/PHONE-2025-001",
          "title": "Electronics passport" }
      ],
      "https://ref.gs1.org/voc/pip": [
        { "href": "https://dpp.example.com/electronics/09521234000013/PHONE-2025-001",
          "title": "Electronics passport (consumer view)",
          "type": "text/html",
          "context": ["ALL"], "public": true }
      ],
      "https://ref.gs1.org/voc/epcis": [
        { "href": "https://api.example.com/events?MATCH_anyEPC=https%3A%2F%2Fid.gs1.org%2F01%2F09521234000013%2F21%2FPHONE-2025-001",
          "title": "EPCIS event history (commissioning, repair, software updates)",
          "type": "application/ld+json",
          "context": ["ALL"], "public": true }
      ],
      "https://ref.gs1.org/voc/serviceInfo": [
        { "href": "https://dpp.example.com/service/09521234000013/PHONE-2025-001",
          "title": "Repair information and spare-parts catalogue",
          "type": "text/html",
          "context": ["ALL"], "public": true }
      ],
      "https://ref.gs1.org/voc/productSustainabilityInfo": [
        { "href": "https://dpp.example.com/sustainability/09521234000013/PHONE-2025-001",
          "title": "Carbon footprint and EPREL energy declaration",
          "type": "application/ld+json",
          "context": ["ALL"], "public": true }
      ],
      "https://ref.gs1.org/voc/certificationInfo": [
        { "href": "https://dpp.example.com/certs/09521234000013/PHONE-2025-001",
          "title": "CE declaration, WEEE registration, conformity reports",
          "type": "application/ld+json",
          "context": ["business", "authority"] }
      ]
    }
  ]
}
``` The `**?linkType=**` parameter on a resolver URL takes the bare relation name (`**pip**`, `**serviceInfo**`, `**productSustainabilityInfo**`, …). See [Resolver Setup](https://openepcis.io/docs/digital-product-passport/resolver-setup) for hosting options. ## Step 9: EPCIS events The dpp-ready repo ships reference EPCIS events for the electronics lifecycle: - `**commissioning.jsonld**` — device commissioned, baseline metadata captured - `**ownership-transfer.jsonld**` — sale or transfer to a new owner - `**software-update.jsonld**` — version transition recorded with previousVersion / newVersion - `**component-replacement.jsonld**` — repair event with the replaced ComponentType and the new partNumber - `**weee-disposal.jsonld**` — end-of-life recorded against the WEEE category All four follow the EPCIS 2.0 pattern: extension properties at event level (not inside `**masterDataAvailableFor**`), the `**GS1-Extensions**` header declaring the `**electronics=**` namespace. ## Validation A complete electronics DPP should pass three kinds of check: - **JSON-LD shape** — normalises against the electronics context (no unresolved terms, no `**@context**` collisions). - **SHACL** — instance data satisfies the electronics shapes published with the vocabulary. - **JSON Schema** — the payload validates against the electronics DPP schema. The repairability index check (criteria sum to total, total within 0–100) is enforced here. For EPREL registrations, cross-check the published number against the [EPREL Database](https://eprel.ec.europa.eu/) as part of the publishing workflow. ## Next steps - [Complete examples](https://openepcis.io/docs/digital-product-passport/electronics/complete-examples) — links to the canonical smartphone, laptop, display and server passports - [Electronics vocabulary browser](https://ref.openepcis.io/extensions/eu/electronics/) — full ontology - [Multi-component example](https://openepcis.io/docs/digital-product-passport/multi-component-example) — for products that combine an electronic device with a separately-regulated battery