This chapter outlines the project's evolution, beginning with the initial ideation phase for both the team and the product. After establishing the core concept, including its physical structure, smart systems, and packaging, the focus shifts to the prototyping stage. Here, we detail the key hardware and software adjustments made to the original design, concluding with an analysis of the test results and final performance.

The first Ideation of the team idea can be found on Figure 1

Here the team already had the idea of keeping the components on the bottom of the bottle, but a more square bottle was kept in mind with a handle that would be comfortable for the user's hand.

The second ideation of TRAQUA already has a more “classic” bottle shape 2.

For the third design, the team tried to come up with a concept that would either easy fold or just fit inside a backpack very easily. This was quite hard to accomplish, not because of the design but more in terms of the electronic components. It would be very hard to put them into the bottle if the bottle were shaped like in FIGURE 3.

Flyers

The team also had a few changes in their flyer before coming up with the definite solution. Below we will explore the different flyers the TRAQUA design team came up with.

The team's first flyer had no QR code; the text idea was already there, but the text just lies in boxes that feel out of place alongside the TRAQUA water bottle 4.

Immediately following the initial presentation, the group gathered to evaluate the proposed project tracks and reach a consensus. Our approach was rooted in an open brainstorming session where we weighed our individual strengths against the potential of each topic. It quickly became clear that the “Smartification of Objects” was the path that generated the most genuine enthusiasm among us.

More specifically, we decided to focus on a smart water bottle. This choice wasn't just based on personal interest; after conducting a preliminary market analysis, we identified a significant gap in the current landscape. We felt we could differentiate our product by consolidating multiple features and services into a single, cohesive solution. This sense of opportunity, combined with the fact that every team member felt comfortable and motivated by the technical challenges involved, made the smart bottle the definitive choice for our project.

Once we settled on the smartification of objects, specifically the smart water bottle, the team held its first dedicated brainstorming session. Because the potential features for a “smart” container are so vast, we needed a way to filter the noise and focus on what actually added value. We turned to Miro to map out these early thoughts, using the boards shown to organize our ideas into functional clusters. This collaborative space was essential not just for tracking our suggestions, but for refining a set of concepts that eventually became the foundation of our final proposal. Figure 5 …

Figures 6, 7 and 8 showcase the result of the initial brainstorming sessions conducted as part of the Design Thinking process.

The primary function of the smart bottle is to encourage consistent and healthy water consumption while, in the meantime, eliminating the hygiene concerns commonly associated with reusable water bottles. To achieve this, the bottle integrates five core features into a single device

First, a built-in UV-C sterilization module automatically disinfects the water and the interior surface of the bottle at regular intervals, removing the need for frequent manual cleaning and reducing bacterial buildup. Second, a temperature sensor continuously monitors the drink's temperature and makes this data available to the user in real time. Third, a hydration tracking system records water intake throughout the day and sends customizable reminders when the user falls behind their hydration goal.

All sensor data is transmitted via Bluetooth to a companion mobile application that serves as the central interface for the end user. The app displays all key aspects mentioned above. . This ensures that the user remains actively involved in managing their hydration while the bottle handles the more technical tasks autonomously.

The bottle will be prices at approximately 330 €. For mass production the team could look to reduce the production price up to 100 € per bottle. Meaning the end price of the bottle would be around 250 €.

Add and explain thoroughly the: (i) initial structural drafts;

Figure 9 …

(ii) material selection; (iii) detailed drawings; (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;

Figure 10 …

This is a system architecture/block diagram for a smart water bottle. At the core is an ESP32 DEVKIT V1 microcontroller that connects to several peripherals: an LED light, accelerometer (LIS3DHTR), TDS sensor (SEN0244), UV-C light, and a pressure sensor (FSR406) with a capacitor. Power is supplied by a battery through a charging circuit. The ESP32 communicates with a mobile application over BLE (encrypted + bonded) using notify/read/write operations. The legend color-codes the lines: red for energy, green for information, and blue for water-related connections.

Figure 11 …

(iv) power budget.

The following sub chapter will introduce and explain the reason why TRAQUA decided to program the application system the way it is, talk about its components and the tools used to do it.

Figure 12 …

In the above-seen use case, we can see an easy entry flow of how the application works. The application was made with one key concept in mind. Keep most of the “important” values one click away. With that mindset in mind. The application works in the following way. If the users log in for the first time, they enter their height and weight. This will help us determine how much water that person needs to intake per day. Then with 1 click that person can see the water purity and his or her total water intake. He can also start the cleaning process from the app by clicking on the navigation menu on the bottom of the app.

Figure 13 …

This is a Level 1 Data Flow Diagram (DFD) for a hydration tracking system. It shows an external entity (Water bottle) sending raw readings to a Sensors process (1.0), which passes data to a Process Data process (1.5). That process sends processed data to a Data store, which feeds into a Display on app process (2.0) that delivers hydration info to the User external entity. There's also a legend in the bottom-left defining the DFD notation (rectangles for external entities, circles for processes, open rectangles for data stores).

Software choices

The system consists of four main components. A mobile application, a web application a backend service and an embedded device based on ESP32

• Mobile Application

The application was developed using EXPO Go, a framework built on top of React Native. The choice was made due to its rapid development capacity, its cross-platform support (iOS and Android), its ease of testing without the requirement of complex native configuration, and the fewer risks of vulnerabilities that React has. Expo Go also enables efficient prototyping and provides access to device features such as Bluetooth, which is essential for communicating with the ESP32.

• Web application

Link to website: https://alvesbernardo.github.io/TRAQUA/

The shop of TRAQUA. This was done using SVELTE. SVELETE was chosen because of its lightweight nature, fast performance, and simple reactive model. Unlike traditional frameworks, Svelte compiles components at build time, resulting in highly optimized and efficient code

Figure 14 …

Figure 15 …

Figure 16 …

Figure 17 …

Figure 18 …

• Backend

The backend is planned to be developed using Python in combination with FASTAPI. Due to its simplicity, readability and extensive ecosystem. The backend is responsible for handling business logic, data storage, and communication between the web application and other system components.

• ESP32 The system uses an ESP32 microcontroller, which is well-suited for IoT applications due to its low cost, built-in Wi-Fi and Bluetooth capabilities, and sufficient processing power. The ESP32 is responsible for interacting with hardware components and executing real-time tasks while communicating with the mobile application.
• Communication Communication between the mobile application and the ESP32 is established using Bluetooth Low Energy (BLE). BLE was selected because it is energy-efficient, widely supported, and ideal for short-range communication between devices
• Security Considerations

Security is an important aspect of the system, particularly in Bluetooth communication. To ensure secure data exchange, several measures are implemented:

Secure pairing and bonding between devices Encryption of Bluetooth communication to prevent interception Authentication mechanisms to restrict unauthorized access Input validation across all components (mobile app, backend, and ESP32)

Additionally, secure development practices are followed in both the frontend and backend to minimize potential vulnerabilities.

Comparing Mobile framework

Web Framework

Backend Framework

Microcontroller

Below you can find a detailed use case explanation of how the user interacts with the system. Our user being the actor in this case. Figure 19 …

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

For the prototype, we use a rigid plastic bottle as the main structure. This material is easy to obtain, lightweight, and resistant, making it suitable for testing our concept. Inside the bottle, we add aluminum foil sheets. The aluminum acts as a reflective surface, allowing the UV-C light emitted by the LED to be reflected throughout the interior of the bottle. This improves the distribution of the light and increases the efficiency of the water disinfection process. We also include a plastic separator at the bottom of the bottle to protect the electronic components. This separator isolates the battery, sensors, and LED from direct contact with the water, ensuring safety and proper functioning during testing. This simple prototype allows us to validate the concept and test the performance of the UV-C cleaning system before developing the final product.

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.

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.