Deliverable 6.5: Circular Design Recommendations Tool Overview and Technical Description

This project has received funding from the European Union’s H2020 Programme under Grant Agreement No. 958448 WP6 FLEXIBLE DECENTRALISED CIRCULARITY AND SUSTAINABILITY SERVICES Task 6.5 Circular Design Recommendations Service Deliverable 6.5 Circular Design Recommendations Tool Overview and Technical Description Ref. Ares(2024)7491550 - 22/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. 6.5 Deliverable title Circular Design Recommendations Tool Overview and Technical Description Description Linked to T6.5 this deliverable provides the circular design recommendations tool overview and technical description for the CircThread projects including as outcomes: a description of the service including its objectives, features, end users, benefits, and use scenarios in relation to the CircThread use cases, a technical description of the services at present and their TRL positioning and advancements during the project, a description of the software implementation of the services including user interface and backend data exchange and API endpoints for CircThread integration. WP No. WP6 Related task T6.5 Circular Design Recommendations Service Lead Beneficiary EKOD Author(s) EKOD Contributor(s) CAR, AU, GOR Type Report Dissemination L. Public Language English – GB Due Date 31/09/2024 Submission Date 22/10/2024 4 Version Action Owner Date V.0.1 TOC, Written EKODENGE 2/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 15/10/2024 V.0.8 Copy, edited & reviewed ECOWISE 21/10/2024 V.0.9 Updated deliverable EKODENGE 23/10/2024 V.1.0 Submitted version with final checks CARTIF 22/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. This deliverable explains the technical description and development of the Circular Design Recommendations Service. One of the services to be developed as part of the CircThread platform that seeks to capture data from the product life cycle, to feed it back to the product design phase to improve circularity. The deliverable describes the service structure and functions, backend, and frontend implementations. The technical description is linked with user scenarios, use examples and guided user interfaces. In addition, the deliverable elaborates on the integration of the service with the CircThread Platform and other external data apps. 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 product designers. Both in learning about the service for outreach to the development company, Ekodenge, and knowledge development by university Aarhus University, and for understanding how they could integrate such services in their own workflow to enhance reuse activities. 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 ............................................................................................... 11 3 PURPOSE, USER NEEDS, ALGORITHMS AND REQUIREMENTS ................. 12 3.1 Purpose ......................................................................................................................... 12 3.2 User Needs ................................................................................................................... 12 3.3 Circular Design Recommendations Data requirements and Algorithms.......... 13 3.3.1 PAC model creation ................................................................................................ 13 3.3.2 Disassembly Failure Analysis ................................................................................ 14 3.3.3 Circularity Information Selection ......................................................................... 15 3.3.4 Disassembly Operation Analysis .......................................................................... 15 3.4 Functional and Non-Functional Requirements ..................................................... 16 3.4.1 Functional Requirements ....................................................................................... 16 3.4.2 Non-Functional Requirements ............................................................................. 16 3.4.3 Wireframe Design ................................................................................................... 18 4 USER STORIES .......................................................................................................... 21 4.1 Use Cases ...................................................................................................................... 21 4.2 User Stories .................................................................................................................. 21 5 SOFTWARE IMPLEMENTATION .......................................................................... 23 6 SYSTEM ARCHITECTURE ....................................................................................... 30 6.1 Overview ....................................................................................................................... 30 6.1.1 Service Communication and Orchestration ....................................................... 31 6.1.2 Deployment and Scaling ........................................................................................ 31 6.1.3 Security and Compliance ....................................................................................... 31 6.2 Software Technologies ............................................................................................... 31 6.3 Integrations ................................................................................................................... 32 6.3.1 Integration with the CircThread Platform .......................................................... 32 6.3.2 BOM Information Retrieval ................................................................................... 33 6.3.3 Disassembly Failure Information Retrieval ........................................................ 33 6.3.4 Circularity Index Retrieval ..................................................................................... 33 7 TESTING PROCESS TO PROVIDE USER FEEDBACK ...................................... 35 7.1 Local Tests .................................................................................................................... 35 7.2 Performance & User Tests ........................................................................................ 35 7.3 Security Tests ............................................................................................................... 35 8 CONCLUSIONS ......................................................................................................... 37 8.1 Results summary and conclusion ............................................................................. 37 8.2 Next steps ..................................................................................................................... 38 7 List of Figures Figure 1: Legend for Analysis Document .................................................................................. 10 Figure 2: Product Model Selection and Bill of Material Information Upload .................... 18 Figure 3: Retrieving Disassembly Information and Disassembly Failures .......................... 19 Figure 4: Circularity Information Selection ............................................................................... 20 Figure 5: Product Model Selection ............................................................................................. 23 Figure 6: Bill of Material Upload ................................................................................................. 24 Figure 7: Bill of Material Viewing ............................................................................................... 24 Figure 8: Target Component Selection - 1 ................................................................................ 25 Figure 9: Target component selection – 2 ................................................................................ 25 Figure 10: Uploading Disassembly Information ....................................................................... 26 Figure 11: Viewing Disassembly Information and the PAC model for target component ........................................................................................................................................................... 26 Figure 12: Uploading Disassembly Failure Document ........................................................... 27 Figure 13: Disassembly Failures and DEI per action ............................................................... 27 Figure 15: Circularity Indicator Viewing .................................................................................... 28 Figure 16: Similarity Analysis for Critical Components .......................................................... 28 Figure 17: Viewing alternative parts .......................................................................................... 29 List of Tables Table 1. Data entry fields for manual input .............................................................................. 13 Table 2. Data entry fields for automatic data management ................................................. 13 Table 3. Disassembly Failure Analysis Sample Data ............................................................... 14 Table 4. Disassembly effort index sample data table ............................................................. 15 Table 5. Circularity Index sample data table ............................................................................. 15 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 individua 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, 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 D6.5 is the outcome of the software implementation of the framework for manufacturers to help with product circular design decisions as developed in T3.3: CircThread Product Circular Design Decisions Framework for Use Case 5: Lifespan Extension via repair circular design by considering the steps that are included in the “Software Development Breakdown Structure”. The service, Circular Design Recommendation Service, is intended for product design teams from manufacturers, focusing on disassembly improvements. The users can benefit from receiving insights for the disassembly operations for their products. By analysing the insights, users can detect the component/parts that cause inefficiencies on disassembly process by considering disassembly effort (time) and circularity indexes. 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. WP6 delivers Circular Economy software services to interface with the CircThread Platform, by integrating each of the services in the Platform’s Services Container, a directory for external services. All tasks in this work package identified the respective service use cases, the required data, and service delivered information linkages across the life cycle. As well as developed backend algorithms and the user interfaces. T6.5 in particular deals with the disassembly operations that can be included in repair, recycling or remanufacturing processes. The main objective is to detect problematic 9 parts/components by analysing the disassembly actions and potential disassembly failures. To this end, historical data for the potential disassembly failures are taken into account. In addition, by integration with the VESPER tool, which was developed by Aarhus University, the Circular Design Recommendations Service can deploy a similarity analysis, to replace problematic part/components with alternative ones. 2.3 Audience The main audience for this report are the CircThread consortium partners, 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 6.5 as part of the CircThread project. The report also addressed an external audience, primarily for manufacturer and designers that are included in product design phase. Both in learning about the service for outreach to the development company, Ekodenge, and knowledge development by university Aarhus University, and for understanding how they could integrate such services in their own workflow to enhance reuse activities. 2.4 Methodology The efforts in Task 6.5 were structured based on the main phases of Software Development, covering four key stages as follows: • Analysis o This phase involves understanding and documenting requirements, user needs, and system constraints. It sets the foundation for subsequent stages by defining what the software should accomplish and how it should function within its environment. o Use Case 5 – analysing the studies under T3.3 to understand the methodology and extract functional requirement. o D3.3: analyse the results to have holistic insight on design for circular disassembly methodology. o Prototype developments. • Design o In this stage, analysts translate analysis outputs into a blueprint for the software. This includes defining system architecture, data structures, algorithms, and user interface layouts. The goal is to create a comprehensive plan that guides the implementation process. o In addition, adopted sprint management strategy within EKODENGE was explained. • Implementation o Partitioned into two sub-layers. ▪ Backend ▪ Frontend 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. 16 3.4 Functional and Non-Functional Requirements To analyse the "Design for Circular Disassembly" (DfCD) methodology by Dr. Giovanni Formentini and Prof. Devarajan Ramanujan for software implementation, the methodology’s key principles and functionalities are partitioned into separate software aspects. The aim is to extract software requirements—both functional and nonfunctional—that align with the needs of the target users. 3.4.1 Functional Requirements • Design Evaluation: o The software offers a module where users (product designers) can upload product designs files such as CAD files, product structures, or simplified BOM file. o It evaluates key factors (potential disassembly failures affecting circularity indicators. o The tool provides a scoring mechanism or visual feedback on product design circularity performance. • Disassembly Process Visualisation: o The software allows users to visualise disassembly sequences by generating PAC (parent-action-child) model from uploaded document. • Recommendations for Design Improvements: o Recommendations are based on two improvement points, one of them is to decrease disassembly effort, and the other one is to have better score on circularity indicators. o Recommendations include alternative parts/components. To this end, there is a need to integration with VESPER Tool. In the first release of the tool, there is no integration but the logic of the VESPER tool for similarity analysis is utilised. • Integration of Component/Part Databases: o There is a need to get part/component information 3rd parties. 3.4.2 Non-Functional Requirements • Usability: o The software should have an intuitive user interface that is easy for product designers, recyclers, and repairers to navigate. o It should include comprehensive help documentation and tooltips explaining the different DfCD metrics and functionalities. • Performance: o The software must be able to process and simulate disassembly for complex product designs within reasonable time limits, ensuring smooth user experience. o The response time for generating reports, evaluating designs, and querying the database should be optimised for minimal delays. • Scalability: o The platform should support multiple users and large-scale projects, including complex product assemblies with numerous components. 17 o The system architecture must allow for future updates, such as integrating more advanced simulation algorithms or expanding material databases. • Data Security and Privacy: o The software must ensure that sensitive product design data is securely stored and accessed only by authorised users. o Encryption of all design files, reports, and user data is essential to prevent unauthorised access. • Interoperability o The software should be compatible with various design tools and file formats (e.g., CAD software), enabling smooth import and export of product designs. o It must integrate with external databases or third-party platforms that hold material information or circularity metrics, ensuring a cohesive user experience. • Maintainability and Extensibility: o The software should be built using modular architecture to facilitate easy updates and maintenance, allowing for the addition of new features as the DfCD methodology evolves. o The software should support continuous integration and continuous deployment (CI/CD) pipelines to ensure timely updates and bug fixes. 18 3.4.3 Wireframe Design A wireframe design was implemented by considering the studies above. In the wireframe design, the electrical kettle is used as an example product, following the works carried out in deliverable 3.3. The sample wireframe contents are shown below. Figure 2. Product Model Selection and Bill of Material Information Upload 19 Figure 3. Retrieving Disassembly Information and Disassembly Failures 20 Figure 4. Circularity Information Selection 21 4 USER STORIES 4.1 Use Cases The "Design for Circular Disassembly" (DfCD) methodology, developed by Dr. Giovanni Formentini and Prof. Devarajan Ramanujan, is a cutting-edge framework aimed at optimizing product designs for circularity. The methodology focuses on improving product disassembly, recyclability, and reusability while reducing waste. In today’s world, where sustainable product life cycles are essential, the DfCD methodology provides a structured approach for manufacturers and other stakeholders to make informed decisions that enhance product circularity. This use case centres around the software implementation of the DfCD methodology, designed to serve product designers (OEMs), recyclers, repairers, and refurbishers. The software offers these users tools to evaluate and modify product designs to facilitate easier disassembly, optimize material recovery, and extend product life cycles. By aligning design practices with end-of-life processes, the software will contribute to a circular economy by ensuring that products are designed for a future where they can be easily repaired, refurbished, and recycled. The implementation of the DfCD methodology through a digital platform encompasses several phases and activities that span the entire lifecycle of a product. The general use case description evaluates how users leverage the software to evaluate, modify, and enhance products for circularity. • Design Evaluation Phase: The primary phase involves product designers (OEMs) uploading product design files (such as CAD models or Bill of Materials) into the software to generate PAC model. • Disassembly Visualisation: Once the product design is evaluated, users can visualise the disassembly process by considering sequence, actions, parent component and child components. This visualisation breaks down each step of the product’s disassembly, identifying bottlenecks such as overly complex fasteners, or components that hinder circularity. • Recommendations for Improvement: After running similarity analysis, the software generates recommendations to replace problematic parts/components with the alternative ones. This iterative process allows designers to refine their designs to meet circular economy objectives. 4.2 User Stories The user stories are defined in a hierarchical manner. The structure is split into module, epic, feature and user story. Four main modules are designed to facilitate the implementation of the DfCD methodology in a software environment, addressing various user needs such as design evaluation, disassembly simulation, collaboration and reporting. 22 For each module detailed EPICs, features and user stories were developed. An example EPIC and Feature and User Story for each module are: • Module - 1: PAC model creation: o Epic 1: Uploading required product information. o Feature 1.1: Upload and manage product design files. ▪ User Story 1.1.1: As a product designer, I want to upload my product's BOM file into the platform so I can initiate the design evaluation process. • Module – 2: Gathering disassembly Information: o Epic 2: Uploading required disassembly operations information. ▪ Feature 2.1: Product designer uploads disassembly actions and disassembly failures document to the tool. • User Story 2.1.2: As a product designer, I want to simulate how my product can be disassembled to ensure ease of repair and material recovery by gathering required information from life cycle actors. • Module – 3: Identifying target component: o Epic 3: Selection of component that can have highest value to harvest. ▪ Feature 3.1: Enabling selection of target component. • User Story 3.1: As a product designer, I want to select target component to evaluate disassembly process to get it and then get insights for improvements. • Module – 4: Suggestions for design improvement: o Epic 4: Suggest design changes to improve product circularity. ▪ Feature 4.1: Generate design recommendations. • User Story 4.1.1: As a product designer, I want the software to suggest alternative component/parts (from internal databases) that are easier to disassemble in terms of effort or circularity performance. 23 5 SOFTWARE IMPLEMENTATION In this section, the software implementation based on user interfaces is shown as implemented in the Circular Design Recommendations service. The interfaces navigate across the data requirements and algorithm logic steps as described in section 3.3. In figure 5, the user can select the product model that is desired to have a design evaluation. Figure 5. Product Model Selection In figure 6 and figure 7, the user uploads a Bill of Material from a structured external document (csv) to provide and view the components/parts in table format. 24 Figure 6. Bill of Material Upload Figure 7. Bill of Material Viewing In figure 8 and figure 9, it is shown how the interfaces allow users to select a target component. 25 Figure 8. Target Component Selection - 1 Figure 9. Target component selection – 2 In figure 10 and figure 11, the interfaces are shown to get disassembly information (from external structured csv document) for a target component from the user. Then, the information is displayed within a table and PAC model as shown in figure 11. 32 Leveraging the asynchronous, event-driven nature of Node.js, the Circular Design Recommendation Service can efficiently handle concurrent requests and data processing tasks, ensuring optimal performance even under heavy workloads. For data storage and management, the Service utilizes MongoDB, a NoSQL database that provides flexibility and scalability for storing structured and unstructured data. MongoDB's document-oriented approach aligns well with the dynamic nature of survey data, allowing for easy storage and retrieval of survey responses and metadata. Additionally, MongoDB's support for distributed databases enables the Circular Design Recommendation Service to scale horizontally as the volume of data grows, ensuring continued performance and reliability. In summary, the Circular Design Recommendation Service leverages a modern software stack consisting of JavaScript, React.js, Node.js, and MongoDB to deliver a robust and scalable solution for facilitating end-of-use collection recommendations. By harnessing the power of these technologies, the End-of-Use Collection Recommendation Service empowers collectors to make informed decisions regarding end-of-use routes, ultimately contributing to sustainable resource management and environmental conservation. 6.3 Integrations Some of the services that are described above need to integrate with some external services and the CircThread Platform. In a microservice architecture, integrating external services is crucial for ensuring that a service can access and utilize specialised data from various sources. These integrations allow for seamless communication between internal services and third-party platforms, extending the tool’s functionality without compromising the modularity and independence of its microservices. Each integration will be handled via RESTful APIs or event-driven messaging systems, ensuring loose coupling between the tool and external services. Main integration points are: • Restful APIs. o Most external services will be integrated through standardised API interfaces, allowing for easy retrieval and submission of data. • Authentication & Security. o All external integrations will be secured using authentication protocols such as OAuth or API keys, ensuring authorised and secure access. • Data Transformation. o Each integration point may require data transformation to align with the internal data models used by the tool, ensuring compatibility. • Error Handling & Redundancy. o Built-in error handling will manage potential failures in external services, with fallbacks or redundancy measures implemented where applicable. Integration needs and details for each critical service are described below. 6.3.1 Integration with the CircThread Platform For registering and retrieving product models, the tool will integrate with the CircThread Platform Product Model Registry Service. This external service will provide access to standardised product model metadata, ensuring that users can retrieve and register products according to industry standards. 33 • Integration Mechanism: RESTful API provided by CircThread. • Key Data: Product name, model number, version, and related metadata. • Use Case: Designers will use this service to register products or query for existing product models when starting a circular design process. 6.3.2 BOM Information Retrieval For retrieving detailed Bills of Materials (BOM), the service could be integrated with the BOM Quality Manager Service implemented by SisTrade in T4.4, for quality assurance checks on the BOM. This integration would allow the system to verify that the BOMs used are of high-quality, ensuring accurate component details for disassembly and circularity analysis. The potential integration route for these services include: • Integration Mechanism: RESTful API or a direct service integration with SisTrade. • Key Data: Detailed component-level information, material composition, and part hierarchy. • Use Case: This will enable users to fetch complete and validated BOMs for accurate disassembly planning and component-level circularity analysis. 6.3.3 Disassembly Failure Information Retrieval To provide product designers and recyclers with insights into disassembly failures or damaged components, the service could be integrated with the Damaged Product Circularity Assessment Service which is developed in T6.3 BY SIMAVI. This external service offers assessments of damaged parts, rusted elements, and other product conditions that might affect disassembly. The potential integration route for these services include: • Integration Mechanism: RESTful API from the Damaged Product Circularity Assessment Service. • Fallback Integration: When integration with the Damaged Product Circularity Assessment Service is not available, the system will fall back to manufacturer or recycler internal databases, retrieving potential disassembly failure information stored locally. • Key Data: Damage reports, disassembly difficulties, part failure rates, rust conditions. • Use Case: Designers can access real-world disassembly challenges, making informed design modifications to improve product circularity. 6.3.4 Circularity Index Retrieval The GRETA Circularity Sustainability Advisory Service which is developed in T6.4 by SUPSI provides comprehensive circular economy indicators, which are essential for evaluating the environmental performance of products and components. The service could with GRETA to retrieve circularity index values that can inform the disassembly process and circularity decisions. 34 The potential integration route for these services include: • Integration Mechanism: RESTful API from GRETA. • Key Data: Circular economy indicators such as recyclability, reusability, resource efficiency, and overall circularity score. • Use Case: Users will leverage GRETA’s data to understand the sustainability impact of each disassembly decision and track the circularity of individual components and products. 35 7 TESTING PROCESS TO PROVIDE USER FEEDBACK 7.1 Local Tests Local tests are the processes of compiling the written codes, uploading them to the server and performing functional tests by software developers. Ekodenge uses GitLab as the code sharing infrastructure for the Circular Design Recommendation Service Developers carry out their individual tests to check functionality of the service, if the tests are carried out successfully, they merge requests and these are sent to the lead software developer. The review is conducted by the lead software developer. The review is carried out supported by a static code analysis tool called Sonar/Sonarlint. It is an automation software that keeps in its database errors that can be made while writing code known in the literature or some things about how it should be written. After the code is written, it is subjected to static code testing with this software. The tool detects potential problems and makes recommendations. It encourages better code. If everything is fine in the visual test, the merge is made and confirmed. If it is not approved, it is withdrawn, and changes are made and sent for approval again. After the review pipelines are prepared via Gitlab for deployment. When a commit is made in the pipelines, builds are automatically made and uploaded to the production servers. This is part of the CI/CD process, it can be done manually if desired. When this process is done manually, once the codes are compiled, the resulting files are copied to the servers with some file copying tools and made operational there. 7.2 Performance & User Tests The purpose of this type of testing is to test the installation and configuration of the system by focusing on the complete, end-to-end testing of the Circular Design Recommendation Service solution to meet user requirements. Performance & User Tests are implemented before each release. This type of tests is implemented by a someone who is not a technical person, with whom some user roles are shared to test the interfaces. The user test is applied for each module which is defined above: • Module – 1: PAC model creation. • Module – 2: Gathering disassembly Information. • Module – 3: Identifying target component. • Module – 4: Design improvement. 7.3 Security Tests Before the software is delivered to production, it is tested in a staging environment four security testing. Once the software is in production, a second round of security tests is conducted. The Ekodenge team uses the following procedure for security testing: ▪ Qualys SSL Check o An online tool to check whether the underlying SSL certificate and security structure are appropriate. 36 ▪ Nessus Vulnerability Scanner o Designed to systematically identify vulnerabilities, misconfigurations, and other security issues within a network infrastructure. o The tool employs a variety of techniques to assess the security posture of systems, including: o Remote scanning. o Local scanning. o Agent-based scanning. o Credential-based scanning. o Comprehensive Vulnerability Database. 37 8 CONCLUSIONS 8.1 Results summary and conclusion This deliverable D6.5 “Circular Design Recommendation Tool Overview and Technical Description” focused on the delivery of the software application by considering the steps that are outlined below: • Analysis (chapter 3) o Determine the user groups of the tool. o Extraction of user needs with series of meetings and demo presentation. o Determining the boundaries of the purpose of the service. o Preparation of system requirements. • Design (chapter 3, 4, 6) o Software Architecture Design. ▪ System Layers. ▪ Tech Stack. • Backend. • Frontend. o UI/UX Design. • Implementation and Testing (chapters 5 & 7) o Developed User Interfaces. o Test Procedures. In the report, an overview is given of the architectural principles, design considerations, and key decisions made for the development of the Circular Design Recommendation Service software system. Throughout the report, system requirements were analysed, major components were identified with their interactions, and the rationale behind the chosen architectural patterns and design approaches was outlined. The design process has been guided by an understanding of the user requirements, business objectives, and technological constraints. By following a systematic and iterative approach, a robust, scalable, and maintainable software system was created that meets the needs of its users and stakeholders. The architectural design of the system has been carefully crafted to ensure modularity, flexibility, and extensibility. Key system layers, components, and interfaces were presented, allowing for effective separation of concerns and ease of future enhancements. Additionally, the choice of architectural patterns, such as a backendfrontend structure, has facilitated the design of loosely coupled and highly cohesive modules. After the study for configuration of the architectural layers, the next step was to validate the service with rapid prototyping. At the beginning stages of the development, prototypes were prepared through some static environments like Figma and PowerBI. Then, by extracting the application backlog, the items were broken down into modules, epics, and features with a hierarchical manner, and implemented in a local prototype code environment. 38 8.2 Next steps Currently, the software was developed on the local environment. The next step is to move to the staging environment. As part of the next steps, it is planned that the functionalities and features of the service will be tested with activities like thinking aloud tests, demo presentations and proof of concept and validation studies, as part of the WP7 piloting efforts, so as to meet user needs with iterative approach. The approach will be usercentric, and the potential new features / functionalities will be implemented under new sprints as made in the pre-development progress. Then, the software will be taken to production environment. In addition, the service was not developed for specific products, but for the purpose of WP7 piloting efforts, so the specific needs for the products in Spanish pilot (batteries, smart boilers, PV glasses) will be investigated with the pilot partners and if there is a need, the service will be modified.