This article presents a Digital Product Passport (DPP) technology for Open-Source Hardware (OSH) use cases. A DPP is a tool to provide physical products with a record of digital information about them, analogous to what might be imagined as a passport for Digital Twins. Such a passport may document non-observable attributes of products, such as their age, people involved in their creation, the licenses of designs used, locations they have travelled to and their current owner. In our tentative implementation and proposal for standard components, we focus on adopting a graph database of information, the REA (Resource-Event-Agent) accounting system and the Valueflows vocabulary to trace resources, events, and agents. Working in a federated environment where DPPs can be exported and authenticated even when they cross different contexts, we also examine how cryptography is used to ensure the integrity of DPPs by relying on authenticity rather than authorization.
8.1 Open Source Hardware
The open-source hardware (OSH) movement is a critical enabler of a more sustainable and decentralized economy. At its core, the OSH movement is about making hardware designs and specifications freely available to anyone who wants to use, modify, or distribute them (OSHA, n.d.-b).
Cooperation and knowledge sharing are among the OSH movement’s underpinning concepts, shared with the broader free and open-source software movement. By sharing hardware designs and specifications openly, OSH communities seek to leverage its members’ collective knowledge and expertise to create better, more efficient, and sustainable hardware products (OSHA, n.d.-a).
Anzeige
Local production is also essential among the OSH movement’s underpinning concepts. By openly sharing designs, specifications and manuals at different scales (city, regional, national or global), communities can produce their hardware locally, using local resources and skills. Local production of OSH designs has the potential to reduce transportation and logistics costs, lower the carbon footprint of production, and support the development of more sustainable local economies (Kostakis et al., 2015).
The OSH movement is also closely linked to the circular economy transformation in Europe and related to important initiatives such as the “Right to Repair” (Right to Repair, n.d.; Svensson et al., 2018; Hernandez et al., 2020). Such initiatives are shaping Europe’s future policies about the consumer market of hardware products. By enabling local production and the reuse of components and materials, OSH supports the development of more circular value chains, where waste is minimized, and products and materials are kept in use for as long as possible.
The backbone of the OSH movement is a growing ecosystem of maker spaces, fab labs and hackerspaces, as well a growing academic corpus that prompted the creation of a Journal of Open Hardware (Murillo & Wenzel, 2017). Such a vibrant and expanding movement has created a vast amount of projects available globally and build locally: they often share common components or are derivatives including modifications and combine diverse parts developed within the global OSH ecosystem. In order to account for authorship and liabilities as well as to trace the life-time and quality of both materials and machinery involved in their production, a very complex network of information is necessary. Our effort is to implement such an information system ad hoc on the needs of OSH and produce a “Digital Product Passport” format that can be printed along the products and linked to its “digital twin” in the global database of OSH creations.
The source of this article’s findings is the continued participatory research activity deeply ingrained into this ecosystem, for instance, in the context and success of the European REFLOW project (European Commission, 2022) or the more recent INTERFACER project (Interfacer, n.d.-a). These community-driven innovation spaces provide access to tools, resources, and expertise for hardware prototyping and production. This ecosystem is driving the democratization of hardware innovation, empowering individuals and communities to create their hardware solutions and participate in the circular economy transformation.
Anzeige
8.1.1 Digital Product Passport
The digital product passport (DPP) is a crucial enabler of the transition to a circular economy. Providing valuable information about a product’s design, material composition, and environmental impact supports the development of more sustainable business models and value chains while also reducing waste and increasing the efficiency of logistics and accounting functions when recycling materials and components.
A DPP as represented by a machine-readable data carrier (such as a QR code), contains a unique product identifier as well as linked data references not only to attributes such as its design and constituent materials but also process details spanning across the product’s life cycle – from manufacturing and usage to disposal and recycling (European Commission, 2022d).
The wide adoption of a DPP standard has the potential to facilitate fine-grained transitions to a circular economy, from the local to the global. A circular economy aims to keep materials in use for as long as possible, minimizing the entropy created by production processes: an externality known as waste and pollution. Products must be designed with their end-of-life in mind, and materials must be recovered, reused, or recycled to minimize the entropy of production processes.
DPPs can provide valuable information to enable this transition by facilitating the tracking of materials and products throughout their life cycle. Initiatives willing to produce open hardware can use this information to optimize recycling processes, reduce waste, and support the development of new business models and value chains.
For example, by providing information about the materials and components used in a product, a DPP can facilitate identifying and separating these materials for recycling. It can also provide information about the materials’ quality, lifetime, and condition, thereby enabling more effective recycling processes.
8.1.1.1 What a DPP Should Provide
At the heart of the European Commission’s European Green Deal strategy (European Commission, 2019), the Ecodesign for Sustainable Products Regulation (ESPR) (European Commission, 2022a) defines DPPs as the technical cornerstone for achieving its aims. DPPs are designed for all participants along a value chain, from designers, manufacturers, distributors and end users to repairers, re-manufacturers and recyclers, to cooperatively access information that is valuable in their work to improve environmental performance, prolong product lifetime, reduce energy use and waste disposal while boosting efficiency and increasing the use of secondary raw materials.
Over a product’s complete life cycle, from design and production to its usage, disuse, and recycling, a DPP is a means to:
increase a product’s sustainability by addressing consumers’ needs more effectively for longer, with less primary resources and energy required and less waste disposed of throughout the product’s life cycle,
achieve an increasingly circular economy by enabling the identification of opportunities to reuse, repurpose and recycle a product’s components and wastes, as well as minimizing energy consumption throughout its life cycle,
provide sufficient product locality information to assess manufacture, repair, and reuse transport and distribution energy use across the product life cycle, and
provide sufficient insights to producers to assess mass production models against less resource and waste-intensive business models (e.g., service-oriented sustainable models).
To achieve this, the ESPR and its Annexes outline required information parameters linked to a DPP data carrier as appropriate, a summary of which is listed in Table 8.1.
Table 8.1
Required information parameters for DPP data carrier (collated from ESPR Articles (European Commission, 2022b) and Annexes (European Commission, 2022c))
ESPR annex
ESPR article
Parameter
Expressed through (some may vary by product group)
III a
7(2)b(i)
Durability/reliability
Mean Time Between Failures (MTBF), expected lifetime, performance
7(2)b(ii)
Ease of repair/maintenance upgrade/reuse
Information for end users on modularity, availability and ID of parts; materials, tools and processes for (dis)assembly
7(2)b(iii)
Ease and quality of recycling
Information on disassembly, recycling, or disposal at end-of-life
4
Production of waste/energy and water consumption
Amount and type of waste produced/resources consumed
8(2)b,c
Types of data carrier used and presentation details
QR code, Bar code, RFID, etc. and location (on product, packaging, etc.)
8(2)d
DPP corresponds to model, batch, or item level
ISO 15459 identifiers
8(2)e,f,g
Differentiated access to information within DPP
DPP attribute-based access control of DPP information and typology of agents
8(2)h
Period for which the product passport shall remain available
DPP duration of availability
III b, c
Unique product identifiers
ISO 15459-6 identifiers
III d, e, j, k
Regulatory compliance data and import, distribution, safety identifiers
ISO 15459:2015 identifiers for agent roles and physically located facilities
10(g), 12(2)a
Data authentication, reliability and integrity shall be ensured
Strong cryptographic measures
10(h), 12
DPPs designed and operated with a high level of security and privacy
A central EU DPP registry is to be established
10(a)
ESPR DPP interoperability
All EU-regulated DPP types must be interoperable in technical, semantic and organizational aspects of end-to-end communication/data transfer
Article 12 of the ESPR also states that a European Registry of all ESPR DPPs is to be established by the European Commission where economic operators are obliged to upload required minimal DPP data.
The DPP definition explicitly states the intent to enable broader voluntary data sharing through decentralized networks of value chain participants, going beyond the products and requirements regulated under the ESPR.
8.1.1.2 What a DPP Should Not Provide
To further the ecodesign goals, the ESPR and its Annexes also outline information parameters that should not be linked to a DPP, outlined in Table 8.2.
Table 8.2
Parameters that should not be linked to a DPP
ESPR article or annex
Summary
5(5)e
No proprietary technology imposed on any agents
Annex I e
No technical solutions detrimental to re-use, upgrade, repair, maintenance, refurbishment, remanufacturing and recycling of products and components
10(h)
Privacy must be ensured with DPP linked data access adhering to GDPR and other privacy regulations
An ESPR-compatible DPP only guarantees sufficient details of a product life cycle to satisfy ecodesign principles as framed in the EU regulatory framework. Although the scope of the ESPR framework explicitly enables and promotes DPPs as an open data sharing environment, DPPs that are accepted within the EU DPP central registry are not guaranteed to contain consistent product information beyond this scope.
8.1.2 Graph Data and Resource-Event-Agent Accounting Method
In our research and development, we use a Resource-Event-Agent (REA; McCarthy, 1982) accounting model to create a product’s DPP. According to this model, a resource undergoes transforming events operated by agents. An example could be the following: a designer (agent) produces (event) a design (resource), and a manufacturer (agent) uses (event) the design (resource) to produce (event) a bike (resource).
The REA accounting model structure allows for graph data representation. We implement this structure utilizing a graph database and the Graph Query Language (GraphQL) to access it.
When looking at concrete implementations of a DPP, we introduce the following two concepts (Valueflows, n.d.-c):
To trace a resource: “follow the completed path backwards from its current point to where it began” – for example, tracing a bike from its current state through the production process back to the constituent components/materials.
To track a resource: “follow the emerging path forwards from your starting point to wherever the thing is”—for example, tracking a bike’s repairs and owner changes after being sold.
In our research and development, we focused primarily on tracing for the DPP because tracing contains each event that contributed to the manifestation of a resource, along with events of intermediate resources and their respective agents. For example, a bike’s trace starts with the bike and goes back along the assembly phase, listing the parts used. It proceeds following the trace of the parts bought by a workshop from different resellers, which in turn had bought batches from other manufacturers, and so on. Such a DPP allows for a tracing of a resource from its current manifestation back to its origins, up to and including all raw materials used.
In other words, tracing captures the provenance of the resource – the chain of relations between resources, events and agents and their properties that constitutes a given manifestation of the resource. An example of tracing back a resource is depicted in Fig. 8.1.
Fig. 8.1
Trace (fragment) of “fancy collaborative bike” (at the bottom). Squares represent events, circles resources, and triangles agents. The graph represents Processes (group of events) using diamond glyphs
×
As already mentioned, tracing represents a resource’s causal paths. In the resulting graph data structure, each connection between resources and events, or events and processes, has a direction. This is consistent with the causal order of the events.
Concerning tracking, we will briefly mention that it can be used to see what byproducts are generated during the process of a particular resource. In our example, possible questions that tracking can answer are:
What was also produced by the manufacturers that made the bike parts?
What was made with the same raw materials used to make the bike parts?
We consider these questions less relevant for our present open hardware DPP use case but may revise this assumption in future research.
8.1.3 Valueflows: A REA Implementation
8.1.3.1 Short Introduction to Valueflows
Valueflows, (n.d.-a) is a REA vocabulary to model economic resource creation, distribution, and exchange. Valueflows provide terms that can formally describe how a resource is created and elaborated. For example, Valueflows is able to model how all agents produce a final product using their resources through a series of events.
The vocabulary models into a flow the sequence of events performed on resources by agents. The Valueflows standard specifies events by a set of possible actions they perform (produce, consume, etc.) and the effect each action has on the resources (produce generates a new resource, consume deletes one, etc.). A Process can group more events to develop a complex transformation on one or more resources, involving more Agents, over a defined span of time (see Fig. 8.2).
Fig. 8.2
REA model relationship diagram
×
Valueflows has three levels: the level we just described models past events claimed to have occurred. There are two more levels: the second level models future plans (intents) and the other models present knowledge (including the know-how required to perform the events). While all levels are relevant, in this article we concentrate on past observed events, since this is directly relevant to DPPs in our experience so far.
8.1.3.2 Advantages of a Valueflows-Based DPP
To examine how appropriate Valueflows is to model relations relevant for a DPP, we look at the conditions described in the tables in Sect. 8.1.1.1.
According to 5(5)e, proprietary solutions are not allowed in a DPP, meaning that a DPP must document all information in an open, standard, inter-operable format and machine-readable, structured, and searchable format. Valueflows satisfies these requirements because it is formulated as a standard, and it specifies its data format in a machine-readable form (Valueflows, n.d.-c).
Moreover, Valueflows facilitates accounting for different levels of granularity, i.e., at the model level (e.g., electric bike model AAA), batch (e.g., electric bike model AAA, produced in factory XYZ), or item (e.g., electric bike model AAA, serial number 123456789) as required by 8(2)d.
Article 10(a) states the requirement for each DPP to be fully interoperable with other DPPs. This can also be satisfied by Valueflows because of its formal specification that allows mapping its concepts to different formally specified semantics. In other words, Valueflows can be integrated with other ontologies.
Further, we observe the following two requirements:
Access rights (8(2)e,f,g): the access to information included in the passport needs to be regulated
Product passport registry (Article 12): a registry managed by the EU Commission receives sufficient info to authenticate DPP information. All the attributes (including the more confidential information) remain with the economic operator.
These are not tasks that a vocabulary can satisfy, but such requirements on top of Valueflows could be implemented because its attributes can have links to external data (URIs – Uniform Resource Identifiers) as values, allowing the distribution and protection of information.
Finally, we will discuss more about the requirement for “data authentication, reliability and integrity” (10(g)) in the context of cryptographic signatures.
8.1.3.3 Requirements for Authentication in DPPs
In OSH development, multiple parties can be involved in producing a particular resource, a condition common to most supply chains. Parties should be able to work together with limited trust and visibility of each other’s actions. Each party then certifies and assumes liabilities for its part of the flow (corresponding to a sub-graph of the entire trace graph in our data representation), and each party can see and verify the other parties’ actions.
We use Fig. 8.1 as an example, where agent Designer1 creates a design (right part of the picture), releases it licensed as an OSH design; agent service_prov2 then uses (“cite” in Valueflows) this design and uses (i.e., “consumes”) two other resources (magic bike mirror and aluminum bike frame) to produce a bike (fancy collaborative bike). If we imagine a customer wanting to buy a bike designed by a local designer: the DPP can show this, but why would the customer trust it? A service provider may falsify a DPP, claiming they used an OSH design from a local designer.
A way to guarantee the authenticity of such claims is the use of cryptographic signatures. In this example, first, Designer1 generates (and thus signs) the design’s DPP (represented by the sub-graph on the right side of the picture). Once the bike is built from the design, service_prov2 generates (and thus signs) the manifested bike’s DPP (which includes citing the design of the local designer).
As shown in Fig. 8.1, the bike’s DPP contains the DPP for the bike’s design, as the design is embedded inside the bike’s trace graph. This configuration implies that when service_prov2 generates the bike’s DPP, the sub-graph describing the design is identical to the subgraph signed by Designer1; otherwise, Designer1’s design use cannot be verified.
A requirement for the DPP then becomes the following: any DPP generated at time t needs to include any DPP generated at an earlier time ti. In other words, each DPPt is a subgraph of DPPti if t ≤ ti.
We will focus on this requirement to discuss two possible limitations of a Valueflows-based DPP.
8.1.3.4 Implementation Limitations of Using Valueflows for a DPP
During a trace, we rewind time and retrieve all the events, resources, and agents relevant to the resource we are tracing. Therein, we expect to find previous states of resources and agents as we trace back in time.
Currently, Valueflows does not explicitly have the concept of a resource (or agent) at a particular time or before a specific event. Therefore, different “states” of the system are not explicitly modelled nor stored. Consequently, we cannot assume that the past state of a resource or an agent can be retrieved when tracing back: only the current state of a resource or agent is stored. The limitation to present state means that mutable attributes of a resource or agent that may be saved and exported in a trace may not be equal to what they were at each point in time referred to in the trace. A resource might have been moved in the meantime or consumed – it might therefore have a different quantity.
Past states of a resource or agent might be retrieved by looking at events which are conceptually immutable and therefore do not need a state. Examining events may be a viable solution, but care must be exercised since events may also be added to past processes, for instance, to correct mistakes in the model a-posteriori. This might be a problem, depending on where the correcting event is present in the trace, which is temporally (possibly much) later but logically next to the “corrected” event. Placing it next to the corrected event in the trace would invalidate the requirement we introduced before, i.e., traces (and therefore DPPs) at earlier stages must be a subset of traces at later stages.
8.1.3.5 Ways to Overcome Valueflows Limitations
There are several options for maintained consistency between DPPs generated at different times. One is to rely only on immutable data, for example, attributes that events cannot update. Attributes of a resource that can change in time should be excluded from the DPP and, if needed, derived from the applied changes (the events) starting from an initial, known situation. This solution assumes that event flows do not change, as discussed in the previous section.
A more comprehensive solution is to enforce immutability by technical means, adopting immutable storage as a backend for Valueflows, such that any change is recorded in ‘append-only’ mode. This way a DPP generated at later stages would always contain DPP generated at earlier stages in its revision history, making it possible to go back to a point in time and generate the same DPP.
8.1.4 DPP Verification Methods
Proper means to verify the authenticity of a DPP are essential because DPP-linked data references need to be exported into a data carrier (for instance, a RFID tag or QR code) and rely on a verification method to assess the data carrier’s integrity. The latter can hold only a limited amount of data constrained by the physical data carrier format, and so contains linked data references to provide further details for online verification.
An offline verification method can cryptographically verify the direct data and references contained inside the data carrier. An online verification method can verify both the data carrier content as well as all details of the referenced linked data available online. This link is necessary for an import of data into another federated system or a visualization of details for closer inspection.
In the case of Open-Source Hardware DPPs, it is crucial to have some information about agents involved in a product life cycle to further serve the implementation of economic models. In some situations, the agents should also produce valid signatures to attest liabilities and warranties related to an object’s production (such as service_prov2 in Fig. 8.1). Yet, strong privacy concerns arise then in terms of protection of personal details of people contributing work to a design, product, or service.
This configuration calls for the development of an advanced cryptographic model that can solve these requirements and which serves to authenticate data carrier linked data references to federated graph data storage. We have already created the cryptographic primitives for such a model in REFLOW crypto (Roio et al., 2021).
The building blocks are twofold: BLS signatures (Boneh et al., 2022) because of the possibility to aggregate them to pack multiple signatures into a single seal; this way, it can be exported at a reasonable size for non-interactive verification. Zero-Knowledge Proofs because they preserve agents’ privacy while proving they are known members of a production lab, which may give access to further details about the production process.
It is beyond the scope of this article to formally define a signature scheme. We experimented with this approach in-vitro and in-vivo with demonstrable benefits, especially when we tailored a signature to the specific needs of a single group of designers and manufacturers or a federated network of production labs.
8.2 Final Considerations
The Valueflows vocabulary as a Resource-Event-Agent accounting system is instrumental in the description of the complex graph of relationships behind the design and production of Open-Source Hardware. It can also go a long way in facilitating advanced authentication schemes that result in compact verifiable offline seals when properly adapted to a specific domain. It also eases the task of describing a production flow at scale when federation becomes necessary to account for multiple agents belonging to different organizations. The findings of research have been implemented into a software application called Zenflows (INTERFACER, n.d.-b), which can be adapted to more domains needing to handle data quality and complexity using REA accounting.
What we have learned so far is that it is necessary to implement Valueflows in a system that supports accounting for state changes in the time dimension and provides a history similar to that offered by revisioning systems, as for instance Git does for software.
It is also necessary to couple Valueflows with an additional ontology that goes further into detail to describe the properties and attributes of nodes in the graph. When modelling Open-Source Hardware production, the options for additional ontologies are neither scarce nor challenging to integrate; for instance, adopting a licensing classification like the one provided by the REUSE (n.d.) project is advisable.
As a future research outlook, we plan to harmonize these new modelling directions with existing initiatives such as the European Data Spaces (https://joinup.ec.europa.eu/collection/semic-support-centre/data-spaces), in order to be able to contribute to the “single market for data” as advocated for by the EU to ensure global competitiveness and data sovereignty” (European Commission, 2023). As a further ambitious application of ESPR ecodesign principles, the OSH DPP should be examined in the broader context of tracing electronic waste (Your Europe, 2023).
We are confident that the participatory approach of this research, grafted in the tradition of free and open-source software and knowledge commons, is the best methodology to co-develop the technical tools and the cultural and social background that enable regional initiatives to focus on information-intensive initiatives aimed at reusing designs and materials to boost local production. Our cooperation with the Fab City initiative is ideal to further pilot our concepts and continues well beyond this regionally focused beta release with a planned global deployment of our software as a FabCity Operating System to be launched during 2023.
Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 International Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.
Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.
