Connected Bus Monitor

Concept

One of the big challenges for the cities of the future is to decrease the number of vehicles in the city to reduce air pollution. One strategy to reduce the number of vehicles is to provide an efficient public transportation. To convince people to use public transportation instead of a personal vehicle, the public transportation service should be efficient in terms of reliability, deployment and comfort. In fact many people consider taking public transport a stressful experience. Many studies have shown that the surrounding environment has a big impact on our mood. In particular high levels of CO2 can leads to drowsiness, lethargy, fatigue, headaches and breathing problems.

Our device aims to monitor the bus indoor environment in terms of temperature, humidity and CO2 concentration in order to make the collected values available both to the users so they can consciously choose the means of transport as well as monitoring the state of the bus for maintenance purpouses.

Prototype Device

Our device is composed of three main components:

• B-L072Z-LRWAN1: It is a STM32 LoRaWAN discovery board and it is the main board of our device. It has a SX1276 transceiver that features the LoRa® long-range modem, providing ultra-long-range spread-spectrum communication and high interference immunity. Its role is to collect the data from the sensors, format them in a json string and send the message to the cloud using LoRa protocol.
• X-NUCLEO-IKS01A2: It is a motion MEMS and environmental sensor expansion board for the STM32 Nucleo. It is a very interesting expansion board since it contains all the most important sensors to monitor the environment. Furthermore it is equipped with Arduino UNO R3 connector layout so that we can plug it on top of the B-L072Z-LRWAN1 board. In our case we will use it to monitor the temperature and the humidity inside the bus.
• MH-Z19C: It is an infrared CO2 sensor using non-dispersive infrared (NDIR) principle to detect the existence of CO2 in the air, with good selectivity, non-oxygen dependent, and long life.

Overall Architecture

The overall architecture of the proposed system is shown in the figure above. It is a linear architecture that allows the data collected by the device, placed in a bus, to arrive to the user through TTN + AWS backend. In particular:

• Connected Bus: Is a bus equipped with our device. The device collects the data of humidity, temperature and CO2 concentration inside the bus and sends them to TTN through LoRa Protocol.
• The Things Network: Here is where our LoRaWAN application server is hosted. When the packets sent from the device arrive, the application server forwards them to AWS cloud services using a secured stack using MQTT protocol.
• Amazon Web Service: Here the data collected by the device are stored in a DynamoDB table and made public through REST API using API Gateway. We use AWS also to deploy the web dashboard of our system
• HTTPS Site: It is a website where the user can select a bus number to see the state of the bus cabin in terms of temperature, humidity and CO2 concentration. The site also shows the plots of the historical temperature, humidity and CO2 if the bus.

Cloud Architecture

In this section we will see more in detail how the cloud back-end, developed using Amazon Web Services, works and which are the main components.

• AWS IoT-Core: It acts as a MQTT broker receiving the data collected by the board on and forwarded by TTN. When receiving data with topic "lorawan/devID/uplink" it stores them to a dynamoDB table thanks to a custom lambda function.
• AWS DynamoDB: It is the database utility used to store the data collected by the sensors. All of the incoming data with topic "lorawan/devID/uplink" are stored in the DynamoDB table "cbmTable". The table "cbmTable" has 4 columns: timestamp, bus, data and sensorsData. The timestamp is the key of the entries while the column sensorsData contains the data collected by the sensors.

• AWS API Gateway: Is an AWS utility that allows us to create and deploy REST APIs to access data. Two resurces are made public: /bus and /bus/id. In both cases we can perform GET operation. GET/bus gives all the available buses in the database while GET/bus/id gives data specific to the bus with the given id.
• AWS Lambda Functions: AWS Lambda allows us to write some functions to manage the data in different ways. In this case we have two lambda functions: one receives the incoming data and stores them into the dynamoDB table while the other is called by the API Gateway and, based on the request, sends back the response to the frontend.
• AWS CodeCommit: It is an AWS service that allows the creation of a repository and keep it updated as it is a github repository. On that repository we put the static resources of our front-end that are accessed and deployed by AWS Amplify.
• AWS Amplify: Deploys our front-end websites keeping it up to date with regard to the static resources loaded and updated in the CodeCommit folder.

Front-End

The Front-End of the proposed system is a web page developed using Angular 2+ framework, hosted in a folder managed using AWS CodeCommit and deployed using AWS Amplify. At first the webpage shows all the available buses in the system.

When the user chooses a bus, all the information relative to that bus are shown as follows:

On the top right are the most recent data collected inside the bus while the three charts show the historical value of temperature, humidity and CO2 collected inside the bus.

Evaluation

Requirements

• Interpretation of the collected data based on particular thresholds.
• The data should not be older than 1 minute.
• Respect the LoRa DutyCycle constraint
• Guarantee security on the entire path.

Indoor Air Quality Indicators

To have a better understanding of the values collected by the sensors we fixed some thresholds for each of the three parameters: Temperature, Relative Humidity and CO2 concentration. Even if there aren't standard values used to define the ideal range for the three indicators, according to many studies the following values are the ones commonly used:

• Temperature: ideal range between 20 and 25 degree Celsius.
• Humidity: ideal range between 30 and 70 percent.
• CO2: ideal under 1100 ppm for indoor space.

We have collected CO2 concentration in three different bus and thanks to the range thresholds just defined we can interpret the data. In the following table there are some values of CO2 collected in three different buses.

Thanks to the thresholds we can assign labels to the collected data. For example we have assigned the following colors to the data in the table: red if CO2 concentration is too high, yellow if acceptable and green if ideal. Being able to assign labels or colors to the data can be helpful for the users to understand the data. In fact, even if a user does not know the meaning of a CO2 concentration of 1500ppm, they see a red indicator which means it is bad.

Sampling Frequency

The frequency with which our device can collect data and send them to the cloud is strictly related to the respect of the DutyCycle imposed by LoRa. In fact, the LoRa specifications in Italy impose to respect a DutyCycle of 1%. Respecting the DutyCycle of 1% means that if we need 0, 1 seconds to send our data to the cloud then we need to wait for 9, 9 seconds before to sending fresh data.

In our case the data of transmission of the data is the Time on Air (ToA) of the LoRaWAN packets containing our data. The ToA is strictly related to the Spreading Factor used to send the data.

Because the payload in our system is larger than 60 bytes, according to the table above, we can use SF7, SF8 or SF9. We tested all those SF and we have tested the network statistics.

The three spreading factors seems to guarantee to have data not older than 1 minute but in order to be certain, we need to consider the delay of our architecture.

Network Delay

In order to measure the delay on our network we need to consider the delay device/aws and the delay aws/frontend

The first one is the sum of the two delays device/TTN and TTN/AWS.

The delay device/TTN corresponds to the ToA of the LoRaWAN packets that we can retrieve by looking at the metadata of the packet received by TTN. In particular we have to look at the "consumed_airtime". As we have seen the longer ToA is 0.41 seconds using SF9.We can compute the delay TTN/AWS in the lambda function as the time when the data are received by the lambda function minus the time where the data arrives to the TTN network server. This last time is available in the packet metadata as "received_at". This delay varies greatly. In fact we have seen a max of around 2.9 seconds and a min of 1.1 seconds, with a mean value of 1.64 seconds.Now we can find the delay device/AWS as ToA + delay TTN/AWS that in the worst case, using SF9 and considering the max TTN/AWS delay, is 3.31 seconds.

The delay AWS/frontend clearly depends on the network speed. With a speed of about 85Mbps, we have a delay less than 1.3 seconds.

Finally, the worst overall delay, using SF9, is about 4.61 seconds and since using SF9 we can sample each 43 seconds. Considering that delay, we are able to respect the constraint of having data not older than 1 minute.

Security

To guarantee security over the entire network we need to be sure that security is guaranteed on the following paths:

• Device/TTN: In this path the data are exchanged through LoRaWAN that provides security in terms of integrity and confidentiality of the packets. In particular two keys are used: AppSKey to encrypt the payload and NwkSKey to compute the Message Integrity Code (MIC)
• TTN/AWS: The data are sent by TTN to AWS in a stack using MQTT protocol. MQTT does not provides strong security protocols, but AWS can make the aws-ttn stack secure. When AWS creates the stack it generates a key. That key is sent to the Global Join Server operated by TTI (The Things Industries) and then it is used to encrypt the data on the stack.
• AWS/Frontend: The front-end web page uses Htpps protocol so the security is guaranteed using TLS.

Future Plans

An interesting use for the CO2 concentration measured inside the bus could be to estimate the number of people inside the bus. We have seen that the CO2 concentration depends on the number of people on the bus. In order to have an accurate estimation of the number of people we also need to consider if the windows are open or not, if the air conditioning is on or off, and we also need to consider the volume of the bus cabin. One concept could be to try to develop an algorithm that consider all those factors and, given the CO2 concentration, can estimate the number of people in the bus.

Conclusion

For further information about the system you can visit the project github repository: https://github.com/FrancescoCrino/ConnectedBusMonitor