Provide here an overview of the contents (structure) of this chapter.
This chapter contains our project's evolution, in particular, you can find currently the concept, designs, smart system, structure and also the materials chosen for the Healing Cocoon.

The idea of ​​the Healing Cocoon came to us after reflection and several brainstorming sessions. First, we tried to recall events we had experienced and heard about in the fields of health and well-being. We quickly focused on the impact of the medical environment (hospitals or waiting rooms) and agreed to work on a solution to improve experiences in medical settings.

The concept of the Healing Cocoon is to transform clinical environments into calming and immersive spaces.

By combining light, sound and scent, it helps reduce stress and improve children well-being.

The features of our Healing Cocoon:

• Calming audio and scent stimulation
• Immersive 180° visual environment
• Accessibilty for children in wheelchairs

• Initial structural drafts and materials details – Figure 1 shows the rigid metal structure made of aluminium arches (this material was chosen because it is less expensive than brass and easy to work with.). In red, we drew the brass panels that will be attached to the metal structure (the exterior surface of the panels will be brushed to make the outside of the cocoon less metallic and more welcoming).

  

  Figure 2 shows the internal part and the materials: first, the acoustic panels are fixed using the aluminum structure. Then, the antimicrobial fabric is attached to these panels (using adhesive or the self-adhesive properties of the acoustic panels).

  

• Material selection – Figure 3 shows the different layers of our cocoon's structure. The air gap is due to the presence of the arched metallic structure in certain area of the cocoon, as shown in Figure 1. We have compiled a list of Portuguese suppliers who could meet our needs: (i) F.Marques da Silva S.A for the brass panels [1] and the aluminum structure [2]; and (ii) artnovion for the acoustic panels [3]. We are still thinking about the antimicrobial textil we want to use, but Monteiro Fabrics with its MEDIFLEX collection offers interesting possibilities [4]

• Detailed drawings – Figure 4 shows the evolution of the design of our idea. First of all, we decided that the cocoon will not be fully closed in order to avoid feelings of claustrophobia, but also so that parents could maintain contact with their child if needed. To allow for true sensory immersion, we wanted to incorporate a chair that could vary its positions (sitting, lying down) and rotate to face the visuals. We also wanted the inside of the cocoon to be accessible for children with reduced mobility, such as those in wheelchairs. We are now thinking about adding small wheels to the chair so it can be easily moved when a child in a wheelchair wants to get into the cocoon. These small wheels can be locked once the chair is inside the cocoon.

(iv) 3D model with load and stress analysis; (v) colour palette.

Include and explain in detail the: (i) black box diagram; (ii) hardware component selection (use tables to compare the different options for each component; (iii) detailed schematics; (iv) power budget.

Black Box Diagram

This diagram represents a high-level overview of an interactive, multi-sensory system, likely designed for patient therapy, relaxation, or an immersive room experience.

Here is the breakdown of how the different parts interact:

Inputs

Cloud: This section handles remote data. It contains an App and Content that communicate with each other. The cloud sends data, media, or instructions down to the main control unit.

User/Patient: This represents the human interaction. The user has a Device to draw (tablet, mobile) that connects to a local App. Whatever the user inputs or draws is sent directly to the central control system.

Core Processing System

Controller: The central microcontroller processes all incoming commands and makes decisions.

Sensors: It continuously reads environmental data using various sensors (Light, Motion, Air, CO₂, Moisture). The controller and the sensors talk to each other to adjust the room's environment based on real-time conditions.

Outputs / Actuators Projector: Displays visual content (perhaps the drawings from the user's tablet or media from the cloud).

Scent sprayer: Releases aromas into the room (using your ultrasonic atomizer).

Speaker: Plays audio, music, or sound effects.

Power Supply

This block shows how electrical energy is distributed. It provides power directly to the central Controller, and it also has dedicated power lines going straight to the output devices (Projector, Scent sprayer, Speaker). This is a very important detail, as high-draw components like projectors and speakers need their own direct power lines rather than drawing current through the main controller.

Figure 5 presents the black box diagram.

Hardware component selection

Detailed Schematics

Detailed schematic diagram illustrating the precise electronic connections for the “Healing Cocoon” project. This diagram serves as the electrical blueprint, detailing how the central ESP32-WROOM-32 microcontroller is meticulously wired to interface with the various sensors (temperature, light, and air quality) and actuators (speaker and scent sprayer) essential for the system's function. By following these specific pin connections and component values, the physical interaction described in the system architecture can be realized.

Figure 6 presents the detailed schematics diagram.

Power Budget

Power consumption breakdown for the system's components. This table outlines the nominal and maximum values for current (intensity), voltage, and power, providing a clear overview of the electrical requirements and the total system load.

Describe in detail the: (i) use cases or user stories for the smart device and app; (ii) selection of development platforms and software components (use tables to compare the different options); (iii) component diagram.

Present and explain the: (i) initial packaging drafts; (ii) detailed drawings; (iii) 3D model with load and stress analysis, if applicable.

Refer main changes in relation to the designed solution.

Detail and explain any changes made in relation to the designed solution, including structural downscaling, different materials, parts, etc.

Detail and explain any change made in relation to the designed solution. In case there are changes regarding the hardware, present the detailed schematics of the prototype.

Detail and explain any changes made in relation to the designed solution, including different software components, tools, platforms, etc.

The code developed for the prototype (smart device and apps) is described here using code flowcharts.

For this project, a web-based prototype was developed to simulate how users interact with the Healing Cocoon system.

The main goal of this prototype is to show how the system would work in practice. The focus is mainly on the user experience and the overall flow, rather than on a fully developed technical solution.

It is important to note that this is a first demo version. The application can still be improved and expanded in future iterations.

The prototype was built using simple and accessible technologies:

• HTML for the structure
• CSS for the design and layout
• JavaScript for basic interactivity

No frameworks such as React were used. This decision was made to keep the system simple and easy to understand, especially for a first prototype.

The design follows a clean and modern style, inspired by medical and product interfaces, with a focus on clarity and ease of use.

The application is divided into two main user roles:

• Staff users (clinic or practice staff)
• Child users (end users of the cocoon)

The staff uses a dashboard to manage the system and set up sessions, while the child interacts with a much simpler interface designed to be intuitive and calming.

Figure 7 presents the login for our application.

The login page allows staff members to access the system using their practice credentials.

It includes fields for:

• Practice name
• Username or email
• Password

This ensures that only authorized users can manage the cocoon.

Figure 8 refers the dashboard interface 1.

Figure 9 refers the dashboard interface 2.

The dashboard gives a general overview of the system.

It shows:

• The current status of the cocoon
• The number of sessions for the day
• The most used environment
• Accessibility status

From this page, staff can quickly navigate to other parts of the application or start a new session.

Figure 10 presents the new session configuration 1.

Figure 11 presents the new session configuration 2.

This page is used to create a new session for a child.

The staff can:

• Enter the child’s name
• Select an environment (such as Ocean, Forest, or Space)
• Adjust sound and scent levels
• Set the duration of the session
• Enable accessibility options if needed

This is the main functionality of the system.

Figure 12 presents active session interface 1.

Figure 13 presents the new session configuration 2.

This page displays the currently active session.

It shows:

• The selected environment
• A countdown timer
• The chosen sound and scent levels

It also includes controls to:

• Pause the session
• End the session
• Activate an emergency stop

Figure 14 refers to child interaction interface 1.

Figure 15 presents the new session configuration 2.

The child view is designed to be simple and easy to use.

It focuses mainly on visual elements and avoids too much text. The child can choose a calming environment and start the session in a straightforward way.

Figure 16 presents the accesibility settings interface 1.

Figure 17 presents the accesibility settings interface 2.

This page allows staff to configure accessibility options.

For example:

• Wheelchair access
• Removable seat
• Low stimulation mode

This ensures that the system can be used by as many children as possible.

Figure 18 refers to settings interface 1.

Figure 19 refers to settings interface 2.

Figure 20 refers to settings interface 3.

The settings page is used to manage general system preferences.

It includes:

• Practice information
• Default session settings
• Notification options
• Basic data and privacy settings

The prototype uses a simple front-end logic.

First, the staff logs into the system. Then, a new session is created and the selected data is stored using LocalStorage. The active session page reads this data and displays it.

The child then interacts with the system through the child view.

This approach makes it possible to simulate a working system without using a backend.

This prototype is only a first version and can be further improved.

Possible future improvements include:

• Integration with real hardware (such as projectors and scent systems)
• Adding a backend with a database and authentication
• Real-time communication between components
• More advanced personalization for children

Perform the hardware tests specified in Tests. These results are usually presented in the form of tables with two columns: Functionality and Test Result (Pass/Fail).

Software tests comprise: (i) functional tests regarding the identified use cases / user stories; (ii) performance tests regarding exchanged data volume, load and runtime (these tests are usually repeated 10 times to determine the average and standard deviation results); (iii) usability tests according to the System Usability Scale.

Provide here the conclusions of this chapter and make the bridge to the next chapter.