--- title: "Electronics DPP Implementation Guide" description: "How to assemble an Electronics Digital Product Passport against the published openepcis-dpp-ready electronics vocabulary" canonical_url: "https://openepcis.io/docs/digital-product-passport/electronics/implementation-guide" last_updated: "2026-07-02T20:31:50.785Z" --- ## 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](/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](/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](/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: ```json { "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](/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](/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](/docs/digital-product-passport/multi-component-example) — for products that combine an electronic device with a separately-regulated battery