Repair of speaker system
(B) Middle-of-life: repair (electronics case)
Repair outperforms replacement: a malfunctioning audio system restored with parts and instructions; and data sharing automates digital twin updates. A malfunctioning audio system doesn’t have to mean replacement. Here we highlight how repair can be supported by the Onto-DESIDE process. Guide 1 Value chain design, development & innovation helps decide when repair wins—clarifying incentives, roles, and the strategies that extend product life. Guide 2 Decentralised data & information sharing demonstrates how selective access to repair data, verifiable credentials, and standardised queries automate updates to digital twins and passports—so repair is faster, cheaper, and compliant. CEON and OCP refer to Onto-DESIDE’s Circular Economy Ontology Network and the Open Circularity Platform.
What: Repair of an audio system through access to reliable spare parts and instructions.
Why: Automating sustainable asset management through digital tools to enable easier data management, whilst protecting sensitive data.
A building owner identifies a malfunction in the installed audio system. Using a data exchange platform, they access repair instructions and discover that the original equipment manufacturer offers a repair service. The component is sent for repair, and the manufacturer replaces the faulty speaker with a newer model containing a higher amount of recycled content.
The repaired unit is reinstalled, and updated product data is published and added to the building’s digital twin, including material composition and sustainability attributes. Digital product passports record both original and repaired versions, tracking components and their environmental impact—including recycled content, origin, and certifications—automating the management of building information.
Step 1: Current undermining tensions and desired patterns using the Multi-Flow Method
Concentration vs. Distribution: Repair data, diagnostics, and spare-part info are locked behind OEM portals and contracts. Access to repair guides, compatibility, and pricing is controlled by OEMs, while building owners must scrape PDFs or call helpdesks, and updating a building’s digital twins is cumbersome. This erodes trust, invites errors, and tilts decisions toward replacement: unable to verify “fit-for-use,” and nudged by warranties and liability, owners replace rather than repair—driving premature end-of-life and extra cost.
Improvement opportunity for data flows: Apply governed, selective disclosure. That is: encode diagnostics and compliance as verifiable credentials; grant time-limited, purpose-bound access to repair data; and automatically sync updated composition and sustainability attributes to the digital twin or product passport after repair. This aligns incentives—owners get proof, OEMs keep control—ensuring access to reliable parts and streamlined data updates, letting repair outcompete replacement. Creating this capability develops into the focus of the next nine steps in the process.
Step 2 & 3—Requirements & Data Inventory
To enable sharing of repair options and instructions, OEMs and building-owner representatives make user stories—for example: “As a building owner, I want replacement-component options for a failed part, with costs and repair instructions, so I can decide between repair and full replacement.” The OEM’s data steward compiles a repair-asset inventory (manuals, speaker-module BOM, parts catalog, compatibility matrix, firmware notes, service logs), noting format, ownership and gaps. Certificates (safety, EMC, RoHS/REACH, recycled content) are registered, though few confirm post-repair performance. Sensitive fields—e.g., regulated-substance levels, raw diagnostics and pricing—are flagged for restricted, purpose-bound access.
Step 4–Enable Data Sharing
To share compliance data securely, the OEM chooses a decentralised setup using Solid pods on the Open Circularity Platform (OCP), which lets customers and suppliers retrieve data in a standardised way. The OEM can control access to each data element, ensuring only authorized actors view it. As a large company with many subsidiaries, the OEM hosts its own Solid server and offers this service to subsidiaries. They also maintain a registry of suppliers’ pods to enable federated queries.
Step 5a—Ontology Requirements & Inventory
The building owner must verify the repaired speaker’s compliance and recycled content. The OEM’s data steward frames competency questions (CQs)—e.g., “What are this device’s components?”, “How much recycled content does it contain?”, “Does it meet toxic-substance thresholds?”—and maps them to CEON. CEON covers general notions (Product, Product Component, Material Composition) but lacks electronics-specific and repair-history concepts. The steward records which CQs are supported and which require extensions.
Step 5b—Ontology Alignment
To cover smart electronics devices, the developer decides to reuse the SAREF ontologies (The Smart Applications REFerence Ontology) and additionally some compliance data that uses external certification vocabularies (ontologies). The developer creates mappings between CEON and these ontologies to ensure semantic interoperability. For example, saref:Device can be aligned with CEON’s Product concept, and hasMatter is aligned with equivalent relations in certification schemas. This allows data from different systems to be interpreted consistently, enabling secure and verifiable sharing of repair-related environmental data across actors without requiring changes to internal systems.
Step 6—Ensure Technical Interoperability
The OEM stores product data in a relational database, incl. component IDs, repair history, and certificates. To ensure technical interoperability, the OEM enables the representation of this data in RDF, a flexible graph-based data format that can easily be shared through the OCP. However, the original database stays as it is, and the data needed to respond to the needs of the other actors is only transformed to RDF on a per-need basis.
Step 7—Define Data Transformation
Using YARRRML mappings, the OEM maps database attributes (e.g., “component_id”, “certificate_reference”) to CEON properties (e.g., hasProductComponent, hasCertificate). The resulting RDF is published to the OEM’s Solid pod. Access control is applied to sensitive data entities, such as proprietary data, ensuring only authorized actors can view them. This setup supports secure, standardised sharing of product and repair data.
Step 8—Set Up Querying
SPARQL queries retrieve key information—for example, which speaker units were repaired, how much recycled material they contain, and whether certificates are valid. These run across the OCP’s decentralised Solid pods, including the OEM’s, enabling building owners and external repair partners to verify compliance and repair status.
Step 9–Develop Data Access Applications
A building owner can now use a repair portal to check the options for repair or replacement of the speaker unit. The app connects to the Solid pods of the OCP and runs SPARQL queries to display repair and replacement options, including details on recycled content, and compliance certificates. Sensitive data is restricted to authorized users. The interface allows verification of environmental compliance, supports informed decision-making, and ensures traceability of repaired components.
Step 10–Plan Maintenance and Evolution
If the OEM updates its repair process or introduces new materials into their spare parts, the ontology can be extended to reflect these changes. New data mappings are then created, and SPARQL queries are adjusted to include updated terms. Thus, such new data can then be displayed by apps built on top of the infrastructure, without substantial changes to their implementation. The system supports ongoing evolution, allowing new actors, data sources, and regulatory requirements to be integrated without disrupting existing workflows.
Want the detail from diagnosis to decision to data flow? The guides lay it out: see the “Tools & Training” section.
