1. Introduction
The potential for reducing the environmental impact of products is greatest in the field of engineering. It has been determined that approximately 80% of environmental impacts are determined during the development phase, while products and materials are responsible for around 45% of global emissions (BMUV, 2020; Reference Moriet, Blériot, Gueye, Jeffries, Banks and GravisMoriet et al., 2021). Concurrently, the absence of transparency and the paucity of data have been identified as significant impediments to the effective reduction of CO2 emissions (Reference Stenzel and WaichmanStenzel & Waichman, 2023). The implementation of climate targets, circular economy strategies, and compliance is rendered inefficient (Reference Olipp, Woschank and KopeinigOlipp et al., 2024).
The EU Green Deal, the Circular Economy Action Plan, and the Ecodesign for Sustainable Products Regulation (ESPR) are all focused on the strengthening of sustainability and the call for new innovative approaches (European Commission, 2023a, 2025; European Parliament, 2022). Considering this, the Digital Product Passport (DPP) is establishing itself as an EU-wide standard for all products. The introduction of the battery passport on 18 February 2027 will be the first mandatory implementation, laying the foundation for further product categories (European Commission, 2023b). It has been demonstrated that companies are cognizant of the advantages associated with the DPP. A survey revealed that 85% of respondents concurred that the DPP should be regarded as a beneficial instrument for engineering purposes. The primary benefit is the early availability and reliability of product data, which provides decision-relevant information for the relevant design, layout, and approval processes. The DPP facilitates the utilization of this data at the opportune stage in the product development process (Reference Trienens, Schreiner, Hovemann and DumitrescuTrienens, Schreiner, et al., 2025).
To capitalize on the possibilities presented by the DPP, it is essential to establish a coherent, systematic, and engineering-focused reference architecture. The objective of the present undertaking is threefold: firstly, to integrate the relevant data and the associated sources; secondly, to identify appropriate interfaces; and thirdly, to ensure interoperability. Moreover, the reference architecture furnishes an overview of the logical architecture, the requisite functions of a DPP and delineates the DPP’s potential for engineering. In the process of implementing a DPP, it is of particular importance for companies to seek external support. The present paper discusses an industry-independent DPP reference architecture that serves as the basis for the development and creation of a digital product passport.
2. State of research and related work
2.1. Digital Product Passport
The Digital Product Passport (DPP) is defined as a set of digital information uniquely assigned to a product that collects and provides reliable sustainability, material, and usage data throughout its entire life cycle. The objective is to enhance transparency, traceability, and circular value creation through interoperable data, unique identifiers, and standardised access (European Parliament, 2022; Reference Lopes and BarataLopes & Barata, 2024). Scientific reviews define digital product passports (DPPs) as “digital documents” that store and disclose life cycle-wide sustainability information, thereby providing operational support for circular economy strategies. In terms of regulation, the DPP is anchored in the EU through the Ecodesign for Sustainable Products Regulation (ESPR), which has been in force since 18 July 2024. This enables sector-specific implementing acts, including DPP obligations. Consequently, the DPP is gradually becoming a market access criterion for regulated product groups. The first mandatory DPP for industrial and vehicle batteries will become mandatory in 2027 (European Commission, 2025). Companies are confronted with the challenge of identifying the appropriate and pertinent data for their specific products, whilst concurrently implementing a technologically sound solution, for instance using digital twins. (Reference Trienens, Rasor, Kharatyan, Dumitrescu and AnackerTrienens et al., 2024) posit that this technology is conducive to the realisation of a DPP. Furthermore, the question of the extent to which a DPP can be used in upstream phases, such as product development, must be answered.
2.2. Reference architecture
A reference architecture (RA) is defined as domain-specific, reusable architecture that delineates the central building blocks and relationships of a class of similar systems with a view to enabling standardization, interoperability, and the efficient instantiation of concrete architectures. It should be distinguished from reference models, as far as it explicitly maps problem solutions to software elements. The structures have been designed to be applicable to all systems within the respective domain. The term “compliance” in this context refers to the presence of the fundamental structures of a reference architecture within a system, either in their entirety or in essential components. This encompasses, in particular, interfaces, layers, or components that are related to each other as described in the reference architecture. (Reference Galster and AvgeriouGalster & Avgeriou, 2011). In the context of the Digital Product Passport (DPP), a range of reference architectures is in place, with certain architectures proving complementary to one another. The EU project CIRPASS delineates a DPP system architecture with views on services, data flows, and governance as a blueprint for cross-sector implementations (Reference Archer, Olsson and JousseArcher et al., 2024). In the context of federated data exchange infrastructures supported by DPPs, the IDS RA Model (RAM 4.0) has been employed in a considerable number of projects. It delineates the roles, layers, and security mechanisms for trusted data spaces (Reference Heidel, Hoffmeister, Hankel and DöbrichHeidel et al., 2019). Concurrently, the Battery Pass Consortium is developing technical guidelines and system architecture as a reference for the EU Battery Pass (Reference D’Agostino, Böge, van Deventer, Fox, Gering and KnotheD’Agostino et al., 2023). Nevertheless, these approaches merely address a fraction of the comprehensive set of requirements that companies are obliged to consider establishing a holistic DPP. Moreover, the domain of product development remains unaddressed and unconsidered within the extant methodologies.
2.3. Engineering
Product development is a fundamental activity in both engineering and business, encompassing the trajectory from the conception of an initial idea to its market introduction. The transition from predominantly mechanical systems to intelligent, software-intensive systems necessitates collaboration across multiple disciplines. Established methodologies, including Pahl and Beitz’s design theory (Reference Pahl, Beitz, Feldhausen and GrothePahl et al., 2013)and the VDI 2206 guideline “Development Methodology for Mechatronic Systems”, are reaching their limits (VDI, 2021). To manage the growing complexity of development processes, there is an increasing necessity for interdisciplinary frameworks such as systems engineering (Reference Gausemeier, Dumitrescu, Echterfeld, Pfänder, Steffen and ThielemannGausemeier et al., 2019). The concept of sustainability assumes paramount importance in the realm of product development. It is incumbent upon firms to create products that are environmentally responsible, yet which remain competitive in economic terms and in functionality. This encompasses the utilization of recyclable materials, the implementation of energy-efficient manufacturing processes, and the adherence to global environmental standards and regulatory requirements (Reference Scholz, Pastoors, Becker, Hofmann and van DunScholz et al., 2018). Innovative approaches are required to facilitate product development and to provide relevant data of suitable quality throughout the life cycle, with a view to achieving the objectives of increasing product sustainability. In order to address this objective, it is necessary to elucidate the research question concerning the suitability of the DPP as a tool, the functionalities and data that are instrumental in this process, and the manner in which the DPP should be integrated into the IT infrastructure.
3. Research design
The method selected according to (Reference Galster and AvgeriouGalster & Avgeriou, 2011) will be used for the design and development of a DPP-RA. The approach delineates a systematic, empirically substantiated approach to developing RA as reusable, domain-specific architectural “templates” that promote interoperability, facilitate the instantiation of concrete architectures, and, in contrast to reference models (problem descriptions). The term “empirically based” signifies the presence of an empirical basis in real phenomena and principles, as well as subsequent empirical validation of applicability. This ensures that the RA can be reliably reused across different organisations. Figure 1 shows an overview of the six steps to be carried out.
Overview of the six steps to developing RA according to Reference Galster and AvgeriouGalster & Avgeriou (2011)
Figure 1 Long description
The table is structured into six columns, each representing a step in the development process of a reference architecture. The columns are labeled as follows: Determination of the RA type, Selection of the design strategy, Empirical data collection, Construction of the RA, Integration of variability, and Evaluation of the RA. Each column contains subcategories and methods used in that step. Row 1: Dimension 1: Context of use, Dimension 2: RA type. Row 2: Design strategy 1: Design from scratch, Design strategy 2: Design based on existing architectural artifacts. Row 3: People: Customers, users, researchers, Systems: Tech. documentation, source code, Publications: White papers, legal texts, papers. Row 4: Describing the RA: RA is described in the form of architectural views (e.g., functional, logical, and technical views). Row 5: Variability for instantiated RA: Note variability models and variability views. Row 6: Criterion 1: Correctness and usefulness, Criterion 2: Support for efficient adaptation and instantiation. The table also includes specific methods and criteria for each step, providing a comprehensive guide to the development process.
It is evident that the process is executed iteratively, traversing six distinct phases within a feedback loop. Firstly, in phase one, the type of RA is defined, as it controls both the information to be collected and the subsequent design. The classification combines the context of use (cross-platform, cross-industry, or cross-sector) with a characterization according to purpose, timing, and organizational reference (e.g., “classic” vs. “provisional,” ‘standardization’ vs. “facilitation,” for one or more organizations). In accordance with the DPP-RA, a cross-industry RA is delineated with the objective of ensuring that a wide range of industries can benefit from it. In phase two, the design strategy is selected. The RA is derived from existing architectural artefacts in a “practice-driven” manner (descriptive) or designed from scratch in a “research-driven” manner (prescriptive). The decision is linked to the chosen RA type. The DPP-RA is designed prescriptively, i.e., from scratch. Phase three is dedicated to the collection of empirical data: Firstly, suitable sources are identified, including people (i.e., stakeholders such as customers, users, researchers), systems (including documentation and source code), and publications/standards. Then, architecture-relevant information is systematically collected and qualitatively condensed using interviews, questionnaires, and document analyses. This includes stakeholders, their concerns, architecture-relevant requirements (including quality characteristics), and domain knowledge, if necessary, in a domain-specific modelling language. In the context of the DPP-RA, systematic literature research has been conducted regarding existing reference architectures and relevant processes, activities, and tasks. Concurrently, an expert interview study was conducted, in which further requirements for a DPP were defined. In phase four, the RA is constructed based on the evidence obtained in accordance with ISO/IEC 42010: The RA is documented via views and associated viewpoints (e.g., functional, logical, technical, or business, technical, and customer perspectives). Common building blocks are identified and anchored as core components, and specific parts are encapsulated for later adjustments. The quality objectives and key drivers are supported by established patterns and tactics from literature, rather than the creation of new, unproven solutions. Phase five instigates variability as a prerequisite for instantiations: Variation points can be annotated directly in models, described in separate variability models, or addressed via variability views. In each case, this must be consistent with the ISO/IEC 42010 views. This enables differences between application contexts to be configured in a targeted manner. In consideration of the evolving legal stipulations for a DPP, it is imperative to select a flexible framework and incorporate variability within the DPP reference architecture. In the final phase of the empirical investigation, the quality and usefulness of the RA are evaluated. This is achieved by assessing the correctness and usability of the RA, for example by mapping it to established architectures or reference implementations/prototypes. The efficiency of adaptation is also assessed, with the usefulness of annotations, variability models and views being taken into consideration. The focus of the two types of RAs is dependent on the design strategy employed; classical derived RAs tend to prioritize instantiation support, whereas novel, ground-up RAs necessitate additional validation efforts. These may include incremental approaches, reviews, and checklists, supplemented by domain-specific evaluation methods. The evaluation of the DPP-RA is conducted based on three use cases. The result is a blueprint that is demonstrably viable, and which can be refined iteratively. It is evident that the blueprint under discussion here satisfactorily addresses the interests of real stakeholders. Furthermore, it is based on proven concepts and yet remains variable and evaluable at the same time. The evaluation has not yet been completed. For this reason, further iterations of the DPP-RA may follow.
4. DPP reference architecture for engineering
4.1. Basic structure of the DPP reference architecture
The RA developed for the DPP provides a structured basis for systematically mapping the diverse requirements, functions, logical elements, and potential, thus creating a framework that supports companies in designing a DPP. The DPP RA is based on the industry 4.0 RA model RAMI 4.0 and adopts its fundamental logic of combining different dimensions and levels in a uniform architecture. Figure 2 presents a comprehensive overview of the architectural framework.
Overview of the developed DPP-RA
The RA is divided into five levels: the data level, the communication level, the architecture layer, the function level, and the potential level. These are supplemented by the life cycle axis, which maps the phases of the product life cycle, and the hierarchy axis, which allows for consideration of everything from materials, individual parts to the entire ecosystem. This configuration facilitates the acquisition of a comprehensive perspective on the DPP, encompassing technical, organizational, and regulatory imperatives.
The RA life cycle axis depicts the chronological sequence of phases that a product goes through from its creation to the end of its life. It consists of five phases: ideation, development, production, use phase, and end-of-life. The structure of the axis is based on the system life cycle described in ISO/IEC/IEEE 15288 The RA hierarchy axis delineates the various levels of consideration at which a DPP can be applied. The objective is to provide a comprehensive delineation of the scope of the DPP, whilst also mapping various levels of granularity. At the lowest level, materials or substances are named such as steel, aluminium or adhesives. On the second level, the part that represents the DPP for individual objects or a specific batch of an object is located. Examples of this phenomenon include components such as screws or a body part of a car. At a higher level of abstraction, the component is defined as an assembly consisting of multiple parts, such as a piston module or a sensor. The subsequent level of analysis is that of the subsystem, which is defined as a functional unit of an overarching system. An exemplification of this phenomenon can be observed in the composition of an engine. The system comprises the DPP of a complete product, such as a car, which integrates subsystems and components. The uppermost level of the axis is representative of the ecosystem. This is the network of DPPs across different value creation networks, platforms, and sectors. This level underscores the cross-system perspective and demonstrates that the DPP is not confined to a specific product but also assumes a pivotal role in networked structures and cross-sector contexts. The representation of the hierarchical axis demonstrates the flexibility of the DPP, which can be utilized at various levels of detail, ranging from material and individual components to complex ecosystems. This establishes the foundation for addressing both product-specific requirements and overarching sustainability objectives.
4.2. Data layer
The data layer of the DPP-RA provides a semantically and syntactically harmonized foundation for all DPP-related information throughout the entire product lifecycle and at all levels of consideration (part, component, subsystem, system, and ecosystem). At the core of the system is the creation of an industry-independent data model that enables the identification of products and variants (e.g. via serial numbers or identification links), the description of structures (BOM/BOP), and the recording of substance and material compositions (including restriction flags), process-related manufacturing and testing parameters, usage and maintenance events, status and sensor data, safety and compliance certificates, environmental and circularity metrics (including PCF/LCA indicators) and end-of-life information (e.g. disassembly, reuse and recycling paths). Information about hazardous materials or recycled materials is also important information at this level. The DPP-RA’s objective is to provide a structured description and identification of relevant DPP data. According to (Reference Trienens, Schreiner, Hovemann and DumitrescuTrienens et al., 2025), a total of 148 DPP-relevant data points were identified. The data points are divided into categories and structured along the product life cycle. Mapping to the hierarchy axis facilitates the identification of necessary data for a specific product. Concurrently, the DPP-RA furnishes a comprehensive perspective on diverse product categories. A clear and well-considered selection of information is crucial to comply with regulations and, beyond that, to enable further meaningful use cases such as potential remanufacturing processes or similar.
4.3. Communication layer
Based on the OSI layer model of (Reference Küveler and SchwochKüveler & Schwoch, 2003) OSI, the DPP-RA’s communication layer describes a regulatory framework consisting of seven layers which is shown in Figure 3 as an example. This defines where DPP data is generated, how it is addressed and transmitted securely, and the form in which it is made available to applications. At the bit transmission/physical layer (layer 1), data from the physical and digital worlds is integrated. This includes data from sensor technology and the IoT, as well as from IT systems such as ERP, PLM, and MES. Data integrity, correctness, and authenticity are ensured at the security/data link layer (layer 2). This includes mechanisms for data quality, hash/signature checks, and traceable provenance. The network layer (layer 3) enables the unique identification of parts, components, subsystems, and systems. It also facilitates the linking of individual products and batches within value chains via product-specific identifiers and ident links (e.g., UPID, IEC 61406 and GS1 Digital Link). The transport layer (layer 4) then ensures the trustworthy and interoperable transmission of a digital product passport (DPP) between stakeholders, for example via secure protocols, QR codes, or data room connectors. The session layer (layer 5) controls access and usage via authentication, authorization and role-based access control (RBAC), thereby establishing the foundation for data sovereignty and purpose limitation. The presentation layer (layer 6) standardizes formats and schemas for machine-readable interoperability. For this purpose, DPP-compliant data structures and standardized digital twins or submodels (e.g., AAS/.aasx, JSON schemas) are considered. The application layer (layer 7) provides visible interfaces (web UIs, apps and dashboards) through which users can query and verify DPP information (e.g., certificates and conformity) and integrate it into processes (e.g., PCF reporting and EoL evidence). This layering clearly separates responsibilities: data creation and quality assurance (layers 1 and 2); unique identifiability and secure transmission in networked supply chains (layers 3 and 4); controlled use (layer 5); and semantic harmonization and user-centered provision (layers 6 and 7). The communication layer thus supports the DPP’s requirements for interoperability, verifiability and scalability across organizations and industries.
Representation of an example the communication level of the DPP-RA
4.4. Architecture layer
The logical architecture of the DPP structures the technical capabilities, interfaces, and responsibilities without committing to specific technologies or deployments. It provides an overview of the DPP, offering insight into the logical elements of a DPP and the associated ecosystem. The necessity for different stakeholders, legislation and IT systems is contingent on the level of granularity of the specific products. As illustrated in Figure 4, the architecture level is presented.
Overview of the logical architecture of a DPP, including context representation
Figure 4 Long description
A diagram of the logical architecture of a Digital Product Passport (DPP) ecosystem, including context representation. The diagram is divided into several sections: Stakeholder, DPP-Ecosystem, IT-Systems, and Legal framework. The Stakeholder section lists internal stakeholders such as Development, Service, Logistic, Product Management, and IT, and external stakeholders such as Supplier, Customer, End-of-Life, Legislator, and Platforms. The DPP-Ecosystem section is divided into Frontend and Backend. The Frontend includes a User Interface with components like Search, Scan & Resolve, Dashboard, Domain Views, Change history, and Login. The Backend includes Role management, Access control, Role description, Repository, Compliance Engine, Engineering Connector, Data Monitoring, Event & Notification, and API-Gateway. The IT-Systems section lists various systems such as ALM/PLM, Authoring Tools, TDM, X-in-the-loop, ERP, MES, and IoT-Platform. The Legal framework section includes ESPR, Green Deal, Delegated Acts, and Governance/Policies. The diagram shows the interaction between these components and systems, highlighting the flow of information and the integration of the DPP with other systems and legal frameworks.
The DPP is embedded in a DPP ecosystem that encompasses internal and external stakeholders, legal frameworks, and existing IT systems. The internal stakeholders include development, service, logistics, product management and IT; the external roles include suppliers, customers, end-of-life partners (e.g., recyclers), legislators/auditors, and platform operators. The regulatory framework is set by the Ecodesign for Sustainable Product Regulation (ESPR), the Green Deal, and the resulting Delegated Acts, and is translated into operational rules via governance/policies. It is evident that the DPP is technically linked to existing IT systems. The following elements are to be considered: ALM/PLM (structure, variants), ERP (master data, orders), MES (manufacturing/quality), IoT platforms (usage/status data), TDM/X-in-the-loop, and authoring tools. This environment provides the source, sink, and verification context for DPP information throughout the entire product lifecycle.
The DPP is comprised of a front end and a back end, which interact via well-defined contracts. As a DPP system, it can manage several passports in parallel (“DPP n”). In the front end, a user interface layer bundles usage. The “Search” function facilitates the specific location of passes and artifacts. The “Scan & Resolve” function resolves identifiers/links (e.g., QR/GS1/DID) to the correct pass resources. The “Dashboard” function facilitates the definition of a specified perspective on the data and information of a DPP. The “Domain Views” function provides technical perspectives on various aspects, including identity/structure, material/substances, conformity/safety, sustainability/PCF, process/quality, use/service, and EoL. The following section will examine the extent to which these assumptions are accurate. These assumptions are based on the premise that login (authentication) and change history (versions/audit trail) provide cross-sectional control of access and verifiability. The backend implements the core capabilities as logically separate services. The management of roles, access control, and role description enforce identity, roles, rights, and purpose limitation. The repository is responsible for storing signed artefacts and indexes, including but not limited to parts list references, certificates, and PCF metrics. The compliance engine, on the other hand, plays a crucial role in checking rules and their validity, as well as providing verifiable statuses. The Engineering Connector serves to facilitate the integration of ALM/PLM, ERP, MES, IoT, and other sources, orchestrating the processes of ingestion and synchronisation. It also enables the monitoring of data quality, timeliness, and availability through data monitoring. It is evident from the extant literature that modifications are disseminated to authorised subscribers in an event-driven manner via the Event & Notification function. The API gateway functions as a regulated entry point for front-end calls and external integrations (e.g. rate limiting, logging, error handling).
4.5. Functional layer
The functional level of a DPP describes all the capabilities required to reliably generate, verify, provide, and use DPP information throughout the entire product lifecycle. It abstracts from specific technologies and bundles technical functions into clear, reusable services, ensuring interoperability, verifiability, and scalability across organizations. In relation to content, the level differentiates between MUST functions, which are deemed indispensable for ensuring compliant and interoperable operation, and CAN functions, which, while augmenting operational benefits, are not considered essential for fundamental compatibility. In addition to the engineering perspective, clustering is performed to create an overview that takes granularity (part, component, subsystem, system) into account.
Firstly, the MUST functions include the unique identification and resolution of product, variant, and batch identifiers so that each DPP can be reliably assigned to a specific object. Secondly, reliable data recording, versioning, and change management are necessary to ensure consistency, completeness, and traceability. Furthermore, it is imperative to ensure the security and availability of data. Thirdly, governance functions are required for authentication, authorization, purpose limitation, and logging to ensure data sovereignty and auditability. Fourthly, interoperability and transformation functions are required to make DPP data exchangeable across recognized standards, as well as event-based notifications that reliably distribute changes to authorized parties.
The CAN function has been demonstrated to expand this basis in a targeted manner. These include catalog and discovery services that facilitate the identification of the providers of the designated DPP artefacts, the conditions under which they are provided, and the monitoring of data quality and operating conditions for the purpose of continuous improvement. Analytics and reporting functions are also included, as well as PCF/LCA calculations with reproducible methodology, and assistance functions such as guided onboarding, self-service for suppliers, and notifications of impending rule violations. Within an engineering context, the provision of optional services for design-for-X, variant and change decisions, or the return of field and quality data, has been shown to significantly enhance the value of the DPP. However, these services can be interchangeable without compromising core interoperability. The functional level of the DPP is of paramount importance in ensuring that it not only serves as a data collection platform, but also functions as a reliable, verifiable, and expandable set of capabilities that meet regulatory requirements. This facilitates concrete decision-making and efficiency gains in engineering.
4.6. Potential layer
The potential layer illustrates the added value that the digital product passport generates in engineering based on specific use cases. It thus constitutes the interface between the technical competencies of the lower hierarchical levels (data, communication, architecture, functions) and the concrete, measurable results in development processes. In the potential layer, the use cases enabled by the DPP are formulated as value-oriented scenarios. The potential of the DPP is classified in accordance with the life cycle of a product and the levels of granularity (part, component, subsystem, system, ecosystem). Consequently, the DPP-RA can be utilized in an independent manner, unbound by the constraints inherent to the industry. The potential for process optimization through the utilization of digital product maintenance (DPP) encompasses several aspects. These include the simplification of compliance documentation, the automation of material and conformity checks in design, the traceability of data for product life cycle documentation (PCF/LCA documentation) in early development phases, and collaboration with suppliers. Furthermore, the DPP facilitates the digital submission of feedback data pertaining to usage and quality, thereby informing decisions pertaining to development and circularity-oriented Design for X (i.e., repairability, remanufacturing, disassembly, and recycling).
5. Discussion
The DPP-RA provides a foundation for companies to approach the creation of a DPP and utilize it in a targeted manner in the development process to support the development of sustainable products. The five levels, which have been clearly defined, support companies in creating a DPP and promote interoperability through the exchange of data across manufacturers and supply chains. The Digital Product Passport has been developed to be cross-industry and intended for use in a range of industries. The specific requirements for the DPP are based on the Ecodesign for Sustainable Products Regulation (ESPR) and the delegated acts to be adopted in the future. The future requirements are contingent on the product groups enumerated in Article 5 of the ESPR, which include iron and steel, aluminum, and textiles, amongst others. Consequently, it can be deduced that the requirements for the digital product passport are subject to continuous development. To reflect this dynamic framework, variability has been incorporated into the reference architecture. This phenomenon is evident in the individual levels: The data level is indicative of the prevailing status quo regarding information requirements, and it is subject to modification at any time in accordance with the emergence of new legal requirements. At the functional level, it is possible to integrate additional functional requirements resulting from future delegated acts. The present communication level is characterized by variability, as the DPP candidates provided for therein allow flexible adaptation to new technical standards or regulatory requirements. Consequently, variability is not realized in the form of explicit models or views, but rather through the fundamental design of the architecture. This enables continuous adaptation to new legal and technological conditions. To ensure a comprehensive and balanced consideration of the engineering focus, it is imperative to recognize the significance of the DPP. The utilization of use cases has been identified as a valuable method to illustrate the potential benefits of the DPP, thereby facilitating a nuanced and informed assessment of its applications. The domain views facilitate the targeted utilization of the DPP by the relevant stakeholders. This can be achieved, for instance, when making decisions regarding material selection or early determination of the carbon footprint based on reliable data. Additionally, the DPP-RA only addresses the integration of the engineering IT infrastructure at an abstract level. For a usable application in industry, it makes sense to involve specific software providers for engineering IT systems and DPP software.
Despite the advantages inherent in the DPP-RA, there are still gaps in its approach. The orientation of the layers has been demonstrated to increase complexity and integration effort. The consistent design of roles, guidelines, and DPP architecture is imperative. It is imperative to consider pertinent standards and tools (e.g., AAS, GS1) and to preserve interfaces with the DPP. Furthermore, companies are not offered any assistance with data harmonization or the optimization of data quality and availability, especially about cross-company aspects. Furthermore, the DPP does not consider scaling and costs. The absence of a universally applicable process model for the establishment and utilization of a DPP, particularly within the engineering sector, poses a substantial challenge for companies lacking clear legislative frameworks to initiate action in this domain. In addition to the EU Battery Regulation, which includes a DPP requirement for industrial and vehicle batteries, further legislation is currently being drafted but has not yet been adopted. The present paper demonstrates that RA provides a robust foundation for the preliminary identification of pertinent data. However, it is also possible that the data may be incomplete.
6. Conclusion and outlook
The Reference Architecture (RA) for the Digital Product Passport (DPP) organizes the DPP’s capabilities, data objects, interfaces, logical elements and responsibilities in such a way that it can be used in an interoperable manner in an industrial environment, particularly in engineering. It is divided into five layers: The data layer (harmonized lifecycle data, including identities/variants, bill of materials (BOM), materials/substances, processes/quality, usage, certificates, environmental information and end-of-life (EoL) information, as well as quality, provenance, versioning, access rules); the communication layer (OSI-analogous, covering source/backup, ident/link resolution, transport and access, as well as format/schema harmonization and presentation); the architecture layer (structuring the logical elements of a DPP and classifying them within a corporate context); the functional level (distinguishing between the mandatory and optional functionalities of a DPP); and the potential level, which describes engineering use cases such as compliance by design, automated material checks along the BOM, product carbon footprint (PCF) evidence, cross-supplier collaboration, feedback from operations/service and design for X, linking them to roles, required data and measurable effects. The DPP-RA provides a foundation on which companies can base the design, implementation and use of a DPP. To improve its use and enhance understanding among companies, a universal process model for creating and using a DPP must be defined. Additionally, the DPP-RA must undergo comprehensive validation to identify and address any shortcomings and demonstrate its added value for companies.
Open access
