Deliverable 5.5: Services Container and Procedures Description for Connections
Abstract
The deliverable 5.5 provides the Services Container and Procedures Description for Connections for the CircThread projects including as outcomes: an overview of the CircThread services management and feature requirements following the T5.1 architecture baseline, a summary of the deployment steps for a new service and require protocols for integration, a description of the frontend user interfaces for the services access including security aspects, and scenarios described of the deployment of the services container.
Full text
This project has received funding from the European Union’s H2020 Programme under Grant Agreement No. 958448 WP5 CIRCTHREAD ARCHITECTURE DEVELOPMENT AND IMPLEMENTATION Task 5.5 CircThread Services Container Deliverable 5.5 Services Container and Procedures Description for Connections Ref. Ares(2024)7453163 - 21/10/2024
2 DISCLAIMER The opinion stated in this report reflects the opinion of the authors and not the opinion of the European Commission. All intellectual property rights are owned by CIRCTHREAD consortium members and are protected by the applicable laws. Reproduction is not authorised without prior written agreement. The commercial use of any information contained in this document may require a license from the owner of that information. ACKNOWLEDGEMENT This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement Nº 958448.
3 Project Data Project Acronym CircThread Project Title Building the Digital Thread for Circular Economy Product, Resource & Service Management Grant Agreement number 958448 Call identifier H2020-LCCI-2020-EASME-twostage Topic identifier CE-SC5-31-2020 Develop, implement and assess a circular economy-oriented product information management system for complex products from cradle to cradle Funding Scheme IA - Innovation action Project duration 48 months (From 1 June 2021) Coordinator FUNDACION CARTIF Website https:// CircThread.eu Deliverable Document Sheet Deliverable No. 5.5 Deliverable title Services Container and Procedures Description for Connections Description Linked to T5.5 this deliverable provides the Services Container and Procedures Description for Connections for the CircThread projects including as outcomes: an overview of the CircThread services management and feature requirements following the T5.1 architecture baseline, a summary of the deployment steps for a new service and require protocols for integration, a description of the frontend user interfaces for the services access including security aspects, and scenarios described of the deployment of the services container. WP No. WP5 Related task T5.5 CircThread Services Container Lead Beneficiary EKOD Author(s) EKOD Contributor(s) SIM, SUP, INES, SAB Type Report Dissemination L. Public Language English – GB Due Date 30/09/2024 Submission Date 21/10/2024
4 Version Action Owner Date V.0.1 TOC, Written EKODENGE 02/8/2024 V.0.2 Initial Chapter Draft EKODENGE 15/8/2024 V.0.3 First draft of all chapter EKODENGE 25/8/2024 V.0.4 Internal review EKODENGE 30/8/2024 V.0.5 Advanced draft EKODENGE 15/9/2024 V.0.6 Updated draft EKODENGE 25/9/2024 V.0.7 Final draft EKODENGE 10/10/2024 V.0.8 Reviewed deliverable ECOWISE 14/10/2024 V.0.9 Final released version EKODENGE 17/10/2024 V.1.0 Submitted version with final checks CARTIF 18/10/2024
5 1 EXECUTIVE SUMMARY CircThread seeks to make appliances like boilers and washing machines sustainable. To achieve this, we want to swiftly increase appliance lifespan, repairability and reuse. And ensure that products are properly recycled when they are no longer repairable. We are working on this challenge with more than 30 organisations, thanks to grant funding from the European Union under the H2020 programme. To solve this challenge, we will put in the hands of all actors a software platform for sharing critical information about appliances. Information shared between product designers, manufacturers, retailers, citizens, repairers, and recyclers, among others. Radically improving our ability to make better lifespan improvement, reuse and recycling decisions. Helping you and others with circularity decision making at all stages of a product’s life cycle. The platform will become available in the cloud in 2025. Equipped with services for collaboration, trust and security. We are now testing it before launch in three pilots, in Slovenia, Spain and Italy. Together with manufacturers, repairers, retailers, collectors, recyclers and many others. A key part of the CircThread Platform is an area where circularity and sustainability services built on top of product information can be discovered, the so-called Services Container. This deliverable explains the technical description of the Services Container by addressing how external services are integrated and managed in the CircThread platform, include the design of the Services Container, its implementation, and the testing route for its improvement and secure functioning. The technical description includes simple user navigation examples as part of the implementation description. The main audience for this report is the CircThread consortium, for purposes of understanding the service in detail as part of the project piloting efforts in work package 7. The report also addresses an external audience, primarily for manufacturers and other lifecycle actors. Both in learning about the different services in container for outreach to the service providers and for understanding how they could integrate such services in their own workflow to improve their internal processes.
6 Table of Contents 1 EXECUTIVE SUMMARY ............................................................................................ 5 2 INTRODUCTION ........................................................................................................ 8 2.1 Overview ......................................................................................................................... 8 2.2 Project context and use of results ............................................................................. 8 2.3 Audience ......................................................................................................................... 9 2.4 Methodology .................................................................................................................. 9 2.5 Structure of the report ............................................................................................... 10 3 SYSTEM ARCHITECTURE ....................................................................................... 11 3.1 Microservice Architecture ......................................................................................... 11 3.2 Services Container Design Requirements .............................................................. 14 3.3 Services Container Communication Requirements .............................................. 16 4 SERVICES CONTAINER IMPLEMENTATION ..................................................... 19 4.1 Services Registration Process ................................................................................... 19 4.2 Viewing external services .......................................................................................... 25 4.3 Enabling external services ......................................................................................... 27 5 TESTING PROCESS TO PROVIDE USER FEEDBACK ...................................... 29 5.1 Local Tests .................................................................................................................... 29 5.2 Performance & User Tests ........................................................................................ 29 5.3 Security Tests ............................................................................................................... 29 6 CONCLUSIONS ......................................................................................................... 31 6.1 Results summary and conclusion ............................................................................. 31 6.2 Next steps ..................................................................................................................... 31 7 Annex 1 – Services Information ............................................................................. 32
7 List of Figures Figure 1. Methodology Framework ............................................................................................ 10 Figure 2. CircThread Ecosystem Architecture Overview (from D5.1). ............................... 12 Figure 3. Microservice Architecture Overview. ....................................................................... 13 Figure 4. Monolithic architecture vs Microservice Architecture. ......................................... 13 Figure 5. Services Container Integration Overview. ............................................................... 15 Figure 6. Communication integration Points for Services Container. ................................. 16 Figure 7. CircThread Platform Landing Page. ........................................................................... 19 Figure 8. Login page. ..................................................................................................................... 20 Figure 9. CircThread Platform admin view of registered services. ...................................... 21 Figure 10: External Service Registry Fields. ............................................................................. 22 Figure 11. Editing Existing Services that are already registered. ......................................... 23 Figure 12. Viewing details of an already registered service. ................................................. 24 Figure 13. Viewing Services Container for general users that are logged in. .................... 25 Figure 14. Viewing general information of external services. .............................................. 26 Figure 15. Button for enabling a service. .................................................................................. 27 Figure 16. User is taken to end-of-use recommendation web-based service. .................. 28 List of Tables Table 1. Data Sharing Connector - Basic Information. ........................................................... 32 Table 2. Legacy Product Data Identification - Basic Information. ....................................... 33 Table 3. Damaged Product Circularity Recommendation Service - Basic Information. .. 35 Table 4. Circular Sustainability Advisory Service - Basic Information. ................................ 36 Table 5. EoU Collection Recommendation Service - Basic Information. ............................ 37 Table 6. Circular Design Recommendation Service - Basic Information. ........................... 38
8 2 INTRODUCTION 2.1 Overview The CircThread project aims to develop and demonstrate the digital means to enable information exchanges across the life cycle of a product. It seeks to develop a Circular Digital Thread (CircThread), where product information is collected, updated and shared for individual products across the product life cycle. The possible information exchanges from such a digital setup are critical to improve decision making and enable services and associated business models to increase product recycling rates, increase product lifespan, and enhance product reuse. The project will to this end deliver a CircThread methodology and associated platform to facilitate information flow exchanges across the extended life cycle chain of products. The approach will be tested across 7 circular economy use cases for both newly manufactured and existing products along the products lifecycle across the three pilots in Spain, Slovenia, and Italy. Each use cases represents a different set of information needs for circular economy decision support to achieve a particular set of goal. With potential links and exchanges of information across the life cycle of a product between different organisations which do not typically exchange information. For example, the provisioning of wastes generated in the manufacturing phase from manufacturers, for purposes of improving circularity assessments for consumer purchasing to retailers and consumers. This deliverable, D5.5, provides the Services Container and Procedures Description for Connections for the CircThread project including as outcomes: an overview of the CircThread Services Container management and feature requirements following the T5.1 architecture baseline, a summary of the deployment steps for a new service and required protocols for integration, a description of the frontend user interfaces for the services access including access and security aspects, and scenarios described of the deployment of the services container. The Service Container is conceived for all of the users that are registered to the CircThread Platform. By utilising this service, users are provided with a user friendly and easy to use environment where all added-value services and services from WP6 can be found and acquired. For each service available at the container, it will be included a clear description of the service, how to install it and use it, and the main contact point of information. 2.2 Project context and use of results CircThread will be an information brokerage platform to enable sharing of product information across the product life cycle, including between the organisations that currently do not share information. WP5 aims to design and implement the Circular Digital Thread Architecture and its modules as a core part of the architecture. To this end, in WP5, the data structure is defined for all exchanges and storage of the information across the product life cycle. T5.5 in particular aims to set up a services container where the different services from CircThread will be located.
9 2.3 Audience The main audience for this report is the CircThread consortium, for purposes of understanding the service in detail as part of the project Piloting efforts in WP7. The secondary audience is the EU Research Executive Agency to evaluate the efforts carried out in delivering Task 5.5 as part of the CircThread project. The report also addressed an external audience, primarily for lifecycle actors, and product end-of-use actors since the services in the container mostly targets them. Both in learning about the service for outreach to the development company, Ekodenge, and for understanding how they could integrate such services in their own workflow. 2.4 Methodology The efforts in T5.5 were structured following four key software development stages (see also Figure 1 below) as follows: • Analysis o Understanding and documenting requirements, user needs and system constraints. Defining what the software should accomplish and how it should function within its environment. o Investigating the relationship between use cases and the services to be located in the Services Container. o Analysing the outputs of T5.1 to have harmonisation between the Central CircThread Platform and Services Container o Literature Review for Microservice Architecture Implementation o Prototype Developments • Design o Software architects and software designers translate analysis outputs into a blueprint for the software. o Defining of system architecture, data structures, algorithms, and user interface layouts. o Creation of a plan with sufficient detail to guide the implementation process. • Implementation o The implementation phase is partitioned into two sub-layers ▪ Backend development ▪ Frontend development o Implementation involves turning design specifications into working code. ▪ Developers write, test, and integrate software components according to the design plan. ▪ Attention to detail and adherence to coding standards are crucial to ensure the software behaves as intended. • Testing o The systematic process of evaluating software to uncover defects and ensure it meets requirements. To fix issues early in the development lifecycle so as to deliver a reliable product to end-users.
16 3.3 Services Container Communication Requirements In the CircThread Platform, the Services Container plays a crucial role in mediating communication between the platform and various external services to ensure secure and personalised access, the services container needs to interact closely with other core services within the CircThread Platform (see Figure 6). Figure 6. Communication integration Points for Services Container. The interaction with the CircThread Platform’s Identity Management service is essential to verify the identity of users and ensure that the services displayed to them are tailored to their specific roles and permissions. Every user that accesses the CircThread Platform will first be authenticated through the Identity Management service, which confirms their credentials and assigns them to a particular user group, such as administrators, manufacturers, recyclers, or other stakeholders involved in the circular economy. Based on this identification, the services container will need to filter and display only those services that the user is authorized to access, creating a personalized interface for each user type. Different visibility scenarios are envisioned depending on authorisations. If a user has the authorisation to view basic information about a particular external service but does not have permission to perform advanced operations, the services container will display only the basic details of that service.
17 For example, CircThread S13: End-of-use Collection Recommendation service is developed for collectors and PROs, and if the logged in user is repairer, he/she can only view the services descriptive information on services information card via GUI, without the permission to send a request to use the service. This ensures that users see only the services relevant to their role, enhancing both security and usability by preventing unnecessary access to services they do not need or are not authorised to use. The dynamic nature of this system is crucial for accommodating the diverse roles within the CircThread ecosystem, which includes different types of users interacting with multiple external services related to digital product passports, product data, life cycle assessments, repair, reuse and recycling related data, and other circularity services. The requirement goes beyond only displaying services. If a user is authorized to interact with an external data service, for example, to use a digital product passport service, the Services Container must enable a seamless connection between the CircThread Platform and the external service. This requires the Services Container to act as a directory service. When a user selects a service, the container needs to facilitate the transfer of an authentication token between the CircThread Platform and the external data service. This token transfer mechanism is crucial for maintaining secure communication and access control across different systems. The Services Container must also communicate with the CircThread platform’s Product Model Registry Service to ensure proper integration with services that require product model information. This interaction is essential because some external data services depend on the selection of a specific product model before they can be utilized. When a user, such as a manufacturer, attempts to access a service like a circular sustainability advisory tool, the services container must first determine whether the service requires a product model as input. To accomplish this, the services container interacts with the Product Model Registry Service to verify if a product model is necessary and whether the user has selected one. If the service is linked to productspecific operations, the services container ensures that the user selects the appropriate product model before proceeding. This capability is critical for maintaining the flow of data and ensuring that services are used in the proper context, enhancing the overall functionality and user experience within the platform. An authentication token is generated by the CircThread Platform’s Identity Management service once the user is authenticated. It contains vital information about the user's identity, role, and permissions, which the external data service will need to use to verify that the user is authorized to perform specific actions within its environment. This token is then transferred securely to the external service, allowing it to check the credentials and permissions of the user without the need for the user to log in again, ensuring a streamlined user experience. This process is critical for maintaining secure and controlled access across multiple services, as it prevents unauthorized users from gaining access to sensitive data or services. Once the external data service has verified the token and confirmed the user’s permissions, the Services Container will then redirect the user to the web service of the external service. At this stage, the user can interact with the service directly, whether it is for retrieving data, updating information, or utilizing specific functionalities provided by the external data app. This redirection is transparent to the user, who will experience it as a smooth transition from the CircThread Platform to the external service.
18 The use of token-based authentication ensures that the entire process remains secure, protecting the integrity of the system and the confidentiality of the data being exchanged. The requirements set for the structure of interaction between the services container, the CircThread Platform, and external data services ensure a high degree of security, flexibility, and user personalization. The reliance on token-based authentication provides a robust and scalable method for managing access control across multiple services and external services, while the integration with the Identity Management service ensures that users only see and interact with the services that are relevant to them. This design supports the overall goal of the CircThread Platform, which is to create a seamless and secure ecosystem for various stakeholders involved in circular economy activities, enabling them to access the services and data they need while ensuring that all interactions are properly authenticated and authorised Additionally, the approach allows for a high level of extensibility. As new external data services are added to the CircThread Platform, they can easily be integrated into the services container without requiring major changes to the CircThread Platform’s core architecture. The external services simply need to implement the token-based authentication mechanism, ensuring that the services container can authenticate users and securely transfer tokens. This makes the system highly adaptable, capable of growing and evolving as the CircThread ecosystem expands, bringing in new services and services to support the various needs of users across the circular economy.
19 4 SERVICES CONTAINER IMPLEMENTATION The chapter provides for an overview of the implementation status of the services registry, viewing module for external services, and enabling module for external services of the Services Container. 4.1 Services Registration Process The CircThread Platform admin enters the landing page of the CircThread Platform. The landing page has been delivered with a menu at the top right of the page which includes searching for product models, searching for services, a link to the CircThread website, and a login button. The CircThread Admin first logs in with their credentials (see Figure 7 and Figure 8). Figure 7. CircThread Platform Landing Page.
20 Figure 8. Login page. After the CircThread Platform administrator is logged in, they navigate to the services registration page. In this page, the admin user can view external services and register new external services (see Figure 9).
21 Figure 9. CircThread Platform admin view of registered services, fields are filled in with dummy data.
22 By clicking on ‘create a service’, CT admin can register a new external service (see Figure 10). Registering new external services requires entry of the service descriptive information and entry of the technical endpoint information. Figure 10: External Service Registry Fields.
23 The admin user can also edit external services that are already listed and views their details (see Figure 11 and 12). Figure 11. Editing Existing Services that are already registered.
24 Figure 12. Viewing details of an already registered service.
25 4.2 Viewing external services General users that are registered and logged in can view services that are registered to a CircThread Platform instance. This feature enables users to view general information associated with the external services as entered (see Figure 13 and 14). Figure 13. Viewing Services Container for general users that are logged in.
32 7 ANNEX 1 – SERVICES INFORMATION A. CircThread Data Sharing Connector Table 1. Data Sharing Connector - Basic Information. Information Description Service Name CircThread Data-Sharing Connector Brief Description The CircThread Data-Sharing Connector developed by INESCTEC was built to enable the sharing/consumption of data in a virtual data space. Detailed Description The CircThread Data-Sharing Connector is essential to share data on the CircThread dataspace. It automates the creation of data elements on the provider and consumer side, namely: - On the data provider side, it automates the creation of all the IDS information elements: catalogues, offered resources, representations, artefacts, rules and contracts. It does so by only requiring the Users, which can be external ICT systems, software developers or persons within the Participant domain, to 1) describe a data resource, the related data usage policy and contract, and 2) provide the data artefacts (i.e., files to be published in the data space). - On the consumer side, it automates the creation of the IDS elements (catalogues, requested resources, representations, rules and contracts), by providing the User with the means to query the Metadata Broker about existing data resource offers and to establish the link with the selected remote artefact (i.e., the artefact made available by the data provider). This Connector also enables easier integration with the IDS Metadata Broker and the participant information system (ParIS): - For the metadata broker, it facilitates the search for data resources and connectors by 1) providing a search function that can, optionally, add filters by using search terms, returning only the valuable and significant information about a set of registered data resources; and 2) allows to request all available information about a specific data offer to initiate a data resource contractualization and access. Furthermore, a specific query on the Metadata Broker returns a list of all the active connectors in the data space. - Regarding the ParIS, the DataSpace4EDI provides endpoints that return a list of all the registered connectors on the Identity Provider with all the descriptive information elements about the Participants in the business ecosystem Estimated TimeLine Prototype development started: June 2022 First release: February 2023 Second release: September 2023 (Added functionalities) Third release: February 2024 (Development of a User Interface) Forth release: March 2024 (Development of a shared mode connector) Stable Prototype: May 2024 Included Pilots Slovenian (washing machines) Italian (Dishwashers) Spanish (Smart Biomass Boilers) Potential User Groups Manufacturers, collectors, repairers and recyclers
33 Backend Web Service Connections to Other Systems or Modules (as a server) As a server, the CircThread Connector receives requests from another CircThread Connector running on the Middleware Web Service Connections to Other Systems or Modules (as a client) - The service/service connects to The IDS Identity Provider (Dataspace Security Component) for authentication and authorisation. - The service/service connects to a repository of IDS Connectors and resources (i.e., IDS Metadata Broker) to retrieve private information regarding products. - The service/service connects to a repository of IDS Participants (i.e., IDS Participant Information Service (ParIS)) to retrieve all participants (i.e., companies) registered on the CircThread Dataspace. - The service/service connects to a repository of IDS Contracts (i.e., IDS Clearing House) if an auditing mechanism is needed. Informational Materials Documentation The setup and usage model The service will work as software as a service and as a local setup. The IT companies for each pilot will implement the connector on their virtual machines and then make them available for each value chain company as software as a service. Other prerequisites for setup and usage environment One machine running Ubuntu Server (more advanced) or Desktop 20.04 with a public domain name (other versions may work but have not been thoroughly tested); Ports 8080 and 8090 should be exposed to the Internet; Java 17 must be installed; Docker and the Compose plugin must be installed on the machine This machine must have preferably a public host name or IP address. Other information and instructions The installation instructions are located on https://github.com/CircThreadH2020/dataspace B. Legacy Products Data Identification Service Table 2. Legacy Product Data Identification - Basic Information. Info Description Service Name T6.1 - S8 Legacy Products Data Identification service Brief Description The Legacy Products Data Identification service developed by SIMAVI is a valuable tool for collectors and recyclers. It enables the attachment of product information to legacy end-of-use products, excelling in cases where no data is available from the original manufacturer. The service allows progressive buildup of product information, starting from basic product details and extending to components and material compositions, including hazardous and rare materials. This comprehensive information is then used to generate a detailed Bill of Material for each product.
34 Detailed Description Legacy Products Data Identification service is designed to assess products such as washing machines, smart boilers and dishwashers. The service allows progressive build-up of product information in more steps: 1. General product information: The initial step involves capturing essential details such as serial number, manufacturer, product category, model, type and specific technical information like frequency, maximum centrifuge speed, and more. 2. Product components: Here, users can select product components and specify their details, including material composition. 3. Components hazardous substances and critical materials: In this step the user specifies each hazardous substance and critical material present in a component and provide more information about them. 4. Bill of Material generation: The information gathered in the previous steps is utilized to generate a comprehensive Bill of Material (BOM) for each product, in 3 formats: PDF, XML and CSV. Estimated TimeLine July 2022 - M14 Prototype development started July 2023 - M26 First online version was published November 2023 - M30 Start of pilot implementation March 2024 - M34 Stable Prototype Included Pilots Slovenian (Washing Machines) Italian (Dishwashers) Spanish (Smart Biomass Boilers) Included Use Cases Use case 1, Use case 4, Use case 6 Potential User Groups Recyclers and collectors Backend Web Service Connections to Other Systems or Modules (as a server) S1 Bill of Materials Quality Manager S7 NIRwave Detection advances Digital Product Passport -> Product Meta-Data Catalogue -> CircThread Platform -> CircThread Keycloak - authentication and authorization for backend -> CircThread Client Adaptors - used for securing the data communication - machine to machine -> Possible Gorenje data repository - via REST APIs Web Service Connections to Other Systems or Modules (as a client) - CircThread Keycloak - authentication and authorization for frontend The setup and usage model SIMAVI internal network for development Other prerequisites for setup and usage environment The S8 Service components run at the moment in SIMAVI Server machine for testing purpose. 8 core, 16GB RAM, 150 GB HDD, Ubuntu 20.04 The S8 Service components will run inside CircThread integration cloud platform
35 C. Damaged Product Circularity Recommendation Service Table 3. Damaged Product Circularity Recommendation Service - Basic Information. Info Description Service Name T6.3 - S9 Damaged product circularity recommendations service Brief Description Damaged Product Circularity Recommendations Service by SIMAVI is a tool for manufacturers and recyclers, designed to streamline the decision-making process. It enables rapid product damage evaluation and uses this data to provide a recommendation for any appropriate action concerning the product, as repair or resale. This information is then used to generate a recommendation report for each product, enhancing traceability. Detailed Description Damaged product circularity recommendations are designed to assess a wide range of products, including but not limited to: Washing Machines, Smart Boilers, Dishwashers and more. The service operates through a user interface: 1. Product Identification: Where the user inputs the identification method and fills in product information like model, type, serial number, product category, return type and other possibly relevant information. 2. Product Identification: Users will select specific damages applicable to the selected product category. For example: scratches, dents, missing or damaged components and other types of damages that will be tailored per pilot. 3. Evaluation: A business logic tailored for each pilot will generate recommendations based on the specified product damage from step Estimated TimeLine July 2022 - M14 Prototype development started July 2023 - M26 First online version was published November 2023 - M30 Start of pilot implementation March 2024 - M34 Stable Prototype Included Pilots Slovenian (Washing Machines) Spanish (Smart Biomass Boilers) Included Use Cases Use case 3 Potential User Groups Manufacturers and recyclers Backend Web Service Connections to Other Systems or Modules (as a server) - The service connects to a common repo backend (created and managed by SIMAVI) from where it draws product information like manufacturers, models and types. - T4.4 Digital Product Memory Service - CircThread platform - CircThread Keycloak - authentication and authorization for backend - CircThread Client Adaptors - used for securing the data communication - machine to machine Web Service Connections to Other Systems or Modules (as a client) CircThread Keycloak - authentication and authorization for frontend The setup and usage model SIMAVI internal network, where users need to register with a specific registration code in order to gain access to the service.
36 Other prerequisites for setup and usage environment The system server will run on SIMAVI integration machines - for testing purpose, during the project. 8 core, 16GB RAM, 150 GB HDD, Ubuntu 20.04 The Service would run inside pilot infrastructure for production environment D. Circular Sustainability Advisory Service Table 4. Circular Sustainability Advisory Service - Basic Information. Info Description Service Name Circular Sustainability Advisory Service - GRETA Brief Description GRETA is a web, microservices-based, service designed to assess the sustainability and circularity performances of products and processes in manufacturing contexts. It offers diagnostic and advisory functionalities, enabling users to optimize their manufacturing practices and make data-driven decisions. Detailed Description Greta includes LCA, LCC, SLCA, and CE assessments for different subjects like product, process, machine and production line. The service provides comparison between different alternatives of product and enabling users to explore the potential impacts of different manufacturing strategies. The system can be easily integrated with real production environments via remote services like IoTs, middleware, REST services. It consists of importing OpenLCA models, an BOM. Estimated TimeLine First release: July 2023 (LCA/LCC assessments) Second release: January 2024 (BOM, SLCA/CE assessments) Last release: March 2024 (Test and integration with CircThread platform) Included Pilots IT & ES Included Use Cases UC2 (ES+IT) & UC7 (IT+ES) Potential User Groups Manufacturer, end user (consumers), recycler, repairer, collector. Backend Web Service Connections to Other Systems or Modules (as a server) Manufacturing Supplier’s Intelligence Module (T6.6). Web Service Connections to Other Systems or Modules (as a client) DPP The setup and usage model Microservice based service hosted in SUPSI servers. Other prerequisites for setup and usage environment The service will run on premise.
37 E. End of Use Collection Recommendation Service Table 5. EoU Collection Recommendation Service - Basic Information. Info Description Service Name End of Collection Recommendations Service [Service 13] Brief Description Seamlessly merging individual product information with insightful survey, the service recommends the best decision for the recovery route of the product that reaches its end-of-use. Detailed Description The service asks product-related survey questions to its user using a QR code and combines individual product information with the answers given in a comprehensible way. It then expresses what the best next step for the product should be regarding sustainability and circularity. Estimated TimeLine Software development is divided into two modules, survey design module and survey service module. September 2023 and October 2023: Software Development Process is going to be continued. November 2023: First version of Survey Service Module December 2023: First version of Survey Design Module January 2024 and February 2024: Testing and functionalities improvement March 2024: Release of the final version Included Pilots Slovenian (Washing Machines) Italian (Dishwashers) Spanish (Smart Biomass Boilers) Included Use Cases UC1, UC4 Potential User Groups Consumer of the product, Recycler, Collector Backend Web Service Connections to Other Systems or Modules (as a server) DPP, CircThread Dashboard System Web Service Connections to Other Systems or Modules (as a client) DPP, Product Registry The setup and usage model The system will work as software as a service Other prerequisites for setup and usage environment The dockerised setup will be available for setting up in a cloud environment but the main goal is to just give access to the service users on the already running cloud based running service
38 F. Circular Design Recommendation Service Table 6. Circular Design Recommendation Service - Basic Information. Info Description Service Name Circular Design Recommendation Service [Service 14] Brief Description The service allows analysing product designs to understand their disassembly and circularity performance. Then, redesign suggestions are obtained by extending the methodology behind the VESPER Tool. Detailed Description This service provides circular product design decisions by considering disassembly effort which includes disassembly failure analysis and circularity indicators. Based on the existing background of the VESPER tool, the similarity analysis is performed, and recommendations are displayed for the target components. Estimated TimeLine September 2023: Software Development Analysis Phase October 2023: Function Diagrams November 2023: First version of Prototype December 2023: Software Development Implementation Phase will be started. September 2024: Release of the first version of the software service. Included Pilots Spanish (Smart Biomass Boilers) Included Use Cases UC5 Potential User Groups Manufacturer, Recycler Backend Web Service Connections to Other Systems or Modules (as a server) CircThread PlatformServices Container Web Service Connections to Other Systems or Modules (as a client) For internal information: Company Databases For external information: CircThread Platform - VESPER Tool The setup and usage model The system will work as software as a service Other prerequisites for setup and usage environment The dockerized setup will be available for setting up in a cloud environment but the main goal is to just be giving access to the service users on the already running cloud based running service