Skip to content

Latest commit

 

History

History
132 lines (90 loc) · 8.15 KB

Design.md

File metadata and controls

132 lines (90 loc) · 8.15 KB

Design

This file is an updated version of this file

The proper functioning of the system depends on several complex technical aspects to be considered. In this section, we would like to address these issues in a real case scenario, describing the solutions and adaptations made to create the prototype.

Technical aspects

The first step before starting the development and deployment of the system is a deep analysis of the specific characteristic of the tunnel and the regulations to be complied with.
Considering that our project aims to automatically monitor and maintain the air quality and lighting conditions prioritizing energy efficiency, the main factors to be considered are:

  1. It is essential to have a regulamentation that defines the rules to be respected, to properly design the system for the specific needing. The air quality system must be based on a list of air pollutants to be monitored and their respective threshold values. Also, the minimum level of light to be guaranteed inside the tunnel must be clearly defined.
    To make consistent assumptions for the development of this project we referred to the current Ambient Air Quality and Clean Air for Europe Standards of 2008.
    It exposes a list of a set of air elements harmful to humans, accompanied by their respective threshold levels and permissible maximum exposure durations.
    The following list illustrates the components on the list generated by motor vehicles:

    Pollutant Formula Maximum concentration Maximum exposition time
    carbon dioxide CO2 1800 mg/m3 8 hour
    carbon monoxide CO 1000 mg/m3 15 minutes
    Nitrogen dioxide NO2 200 mg/m3 1 hour
    Sulphur dioxide SO2 350 mg/m3 1 hour
    Particulate matter PM10 50 mg/m3 24 hour

  2. Once the regulamentation is clarified, it is necessary to understand the characteristics of the specific tunnel in terms of dimensions, expected traffic, type of users, normal light conditions etc. This characteristic facilitates the comprehension of actuator specifications, determining the required quantity and strategic placements for optimal positioning.
    Considering the environmental conditions is also crucial to enable connectivity of the monitoring system to the internet.

Adapting the Prototype

We tried to design a prototype that reflects in a reasonable way a real case scenario, by making feasible estimations and assumptions in relation to the equipment at our disposal. The dimensions of the cardboard used to simulate the tunnel are 50cm x 40cm x 80cm, resulting in a total air volume of 0.18m³.

Sensors

Air quality

The air quality sensor used is MQ-135 GAS SENSOR, suitable for detecting CO and CO2.
This sensor vary the value of the R0 resistance depending on the concentrations of the various gases.
The standard sensitivity characteristics of the MQ-135 sensor to different gases are illustrated below:

Light
The light sensor used is BH1750FVI, a digital Ambient Light Sensor IC for I2C bus interface.

Actuators

Fan

We employed a simplistic method to estimate the fan airflow, considering that in the simulation scenario, this calculation serves as a rough approximation for guidance purposes, without requiring excessive complexity.
The fan speed is controlled through PWM modulation, using three different speed settings.
The formula results in:

Airflow = fan · area · fan_speed · efficiency_factor

Data value units of measure
fan_max_speed 44 m/s
fan_mid_speed 30 m/s
fan_low_speed 15 m/s
effinciency_factor 0.3
Airflow max speed Airflow mid speed Airflow low speed
0.033 m³/s 0.023 m³/s 0.011 m³/s

With an energy consumprion of

Airflow max speed Airflow mid speed Airflow low speed
100 mA 90mA 80mA

Based on this estimation, we can determine the time it takes for a fan to circulate an air volume equivalent to that of the cardboard:

Fan max speed Fan mid speed Fan low speed
6s 8s 17s

Light

By positioning the light source on top of the cardboard, it generates a cone of light on the bottom with a radius of 15cm. Consequently, we opted to utilize six light bulbs to adequately illuminate the entire length of the cardboard. During measurements taken at the centre of the cone, the recorded light intensity reached approximately 1600 units.

Managing the components

Based on the European standard mentioned earlier, the gases considered harmful to human health require a minimum exposure time of 15 minutes to pose a risk.
We define 4 threshold of gas concentration as follows:

  • No risk treshold: the gas concentrations are below the potentially harmful values for humans. Fan sistem is switched off.
  • Min risk treshold: the gas concentrations are slightly above the potentially harmful values for humans. Fan sistem is switched on at 1/3 of maximum speed.
  • Mid risk treshold: the gas concentrations are moderately above the potentially harmful values for humans. Fan sistem is switched on at 2/3 of maximum speed.
  • High risk treshold: the gas concentrations are moderately above the potentially harmful values for humans. Fan sistem is switched on at maximum speed.

The sampling period is based on the time needs for a fan to move a total volume of air equal to the volume of air of the tunnel.

Circuit Diagrams

We utilized two separate breadboards, one for the lightning system and one for the other components as one power supply was not generating enough current.
Additionally, it can be noticed that the DC motors are connected to a transistor rather than directly to the ESP32 PWM pin. This arrangement was necessary because the board alone can not generate enough current to power both motors. Using the transistor, the motors are supplied by the breadboard power supply, while the ESP32 exclusively controls their speed via PWM.

Sensors & Air Conditioning System Diagram

Lightning System Diagram

Network architecture

The network architecture diagram and a brief description are as follows:

Step 1:
ESP32 board sends data to Mosquitto MQTT broker, using the MQTT protocol. The connection is established over WiFi IPV4, with both devices connected to the same network.

Step 2:
The broker communicates with AWS IoT Core through a Python bridge always trough the MQTT protocol. The MQTT broker and bridge utilize the same topic (tunnel), while the bridge publishes the data to AWS IoT Core on the DATA topic.

Step 3:
Data is received on AWS IoT Core, designed as if it is an ESP32 board. This elements allows to define rules to determine what actions to perform with the received data. In this way, all the data received on that specific topic is inserted into a table in DynamoDB.

Step 4:
By utilizing a Lambda function (AWS Python function), data is retrieved from the DynamoDB. The authorization to access the database is managed by AWS IAM. The API Gateway enables the creation of a RESTful GET API connected to the Lambda function from the previous step, providing an endpoint that can be called from the web app.
Amplify is the AWS hosting service used for deployment.

Below is a sample figure of the web app accesible at this link