# IoT Based Smart City Bus Stops
## 3 Proposed System Hardware Architecture  
The objective of the proposed IoT-based bus stop was to capture the bus stop operational and surrounding environment parameters using a set of sensors that interfaced with a microcontroller. The microcontroller continuously reads and transmits the most recent sensor values to the remote database. In turn, a remote database pushes the most recent values to a mobile app available to the operators or maintenance personnel. Notifications are generated as soon as a utility abnormality or breakdown is detected at a bus stop.  
For example, a temperature of above 23 degrees Celsius with an occupancy \(>\) 0 is considered \"abnormal\". CO levels above 70 ppm and LPG levels above 1000 ppm are considered abnormal. Additionally, a light is considered as \"not working\" if it is dark while there are people at the bus stop, and so forth.  
In order to satisfy such requirements, the hardware architectural model chosen for the proposed IoT-based bus stop was a three-layered architecture as illustrated in Figure 1. The layers consist of the edge device layer, cloud layer, and the application layer.  
Figure 1: The hardware layers of the proposed system.  
The edge device layer consists of a set of sensors, single board microcomputer with WiFi access point, and a set of relays. The sensors are temperature, humidity, light, motion, and air pollution sensors. The sensors communicate with the controller using the inter-integrated circuit communication protocol (I2C).  
The relays are used to interface the lights, the air-conditioner, and non-smoking sign to the RPi output ports. Two different single-board edge device alternatives are compared in Table 1. The comparison is based on several criteria such as cost, wireless remote access, I/O pin availability, power consumption, built-in memory size, clock speed, weight, and size.  
In Table 1, the Cost factor was allocated as 15% as the implementation costs of large-scale systems of distributed smart bus stops must be kept to a minimum. The Memory factor, which refers to the static and dynamic RAMs of the microcontroller was allocated 7%. The Remote Access factor was allocated 15%. This factor refers to the Internet connection services that a microcontroller provides. The I/O Pin Availability factor was allocated 16% as the number of sensors and actuators that can be interfaced to the microcontroller board needs to be considered. A shortage of I/O pins at the microcontroller would restrict the application of the system. The Power Consumption factor was allocated 18% as the system aims to be environmentally friendly, and therefore, the power consumption must be kept to a minimum. The Clock Speed factor was allocated 10% as the microcontroller processing speed will affect the response time of the entire system. Finally, the Weight and Size factor was allocated 15% as portability needed to be considered.  
Based on the comparison, the RPi outperformed Arduino in many aspects including the built-in wireless access point, speed, I/Os, and memory size. Additionally, the RPi can be configured as a standalone server and therefore in conclusion, the RPi was selected as the physical layer computing platform in this work.  
The second layer is the cloud layer, which is used to store the collected bus stop status data. In this layer, the data are stored in JSON format in a Firebase real-time NoSQL database, which is cloud-hosted.  
The third and last layer is the application layer. In this layer, the mobile phones of the operators and users are used to access physical edge devices through the cloud layer.