Toolkit for urban data collection
Toolkit for decision makers and specialists to gain experience with data collection.
A smart city starts with high-quality data with a continous in-stream of more measurements which represent the current situation. This is the basis for every data analysis or machine learning model and needs to be built up first. For a city that is at this first stepping stone, it is not always easy to tell which data matters. To avoid a huge inital investment for the city's step into IoT, it would be great when a set of sensors together with an easy to use software would exist, so that desicion makers as well as specialists of the city administration can gather experience with data collection and its analysis before they decide about a bigger investment.
Aside of deployment in a testing phase, this toolkit could also be used for temporary use in a location, e.g. in advance of opening a construction site to gain some traffic data to estimate how many cars must be rerouted during the construction.
Most of the implementation can be done with a handful of open source projects, while for the sensors already existing solutions can be used. Those sensors are cheap and easily integrated into a system with a clean interface.
The project needs Python and web developers for creating the backend and user interface, microcontroller developers for the sensors and people that find use cases for such a toolkit, preferably directly with employees of the municipality.
We wanted to build a toolkit that enables to collect data in the real world in a device agnostic way.
For this we built on already existing open source solutions. We chose the test case of car traffic monitoring, around which we built our prototype. During the Lenzburg Hackathon we built a prototype with consisting of following modules: - Pub/Sub Broker - Data Management and Rule Engine - Database to save the data in a persistent way - Dashboard to visualize the data - IOT ToF sensor based on a development board
To keep the interface as open as possibile, we decided to use the MQTT Protocol as the basis to communicate between the different software modules and the IOT devices. We used Apache Mosquitto as our MQTT broker. Since there is already a containerized version of it in the Docker repository, we didn't have to invest any time to set it up and could directly launch it on a cloud service (AWS in our case). As a next step we needed a controller implement the data flow to different services that don't support MQTT, i.e. the SQL database or the dashboard. For this we used the open source software Node-RED. Node-RED offers a simple but nonetheless powerful graphical interface to implement a flow chart based rule set. Since Node-RED does not have a native SQL interface, we had to implement a plugin to enable this action. We containerized our modified Node-RED version and also lauched it on a cloud service. Afterwards we implemented our rule set which subscribed to the desired topics on the MQTT broker (the topics on which the IOT devices publish) and filled the received data in the right format into the database.
The SQL database setup was straightforward, since AWS offers databases as SaaS. We programmed a small Python script, which filled the database with dummy data so the team members working on the dash board were able to output something before the sensor implementation was finished to deliver the real data. The dashboard was implemented as a reactive web app, which was taking its data from the SQL database. Aside of a list with showed the most recent measurments of the sensors distributed in the city, it also showed the positions of the sensors on a map. Another figure was showing the development of an observed metric, in our case the number of cars passed per time unit.
As our sensor we used a development board from STM (part-nr.: B-L475E-IOT01A). We programmed it to observe whether something is passing in front of it and in the case that it detects a car, it shall publish a message on the given topic on the MQTT broker.
At the end we were able to build a functioning prototype from the hardware in the streets to the dashboard where the refurbished data is shown in a easily readable way.
The next step would be to find a town that would be interested to start measuring data to improve their decision processes and tune the product to their needs to develop a real product prototype. Ausblenden