The document describes a distributed urban noise monitoring system called StadtLärm. It uses low-cost embedded systems with noise sensors distributed throughout a city to monitor noise levels. The sensors measure and detect noise scenes and events using machine learning. A central processing service stores and visualizes the data. MQTT is used as the communications protocol between the sensors, central service, and administration component due to its broker-based publish-subscribe capabilities and support for distributed systems. A field test of the system is planned for six months in a German city using 25 sensors.

1. © IMMS GmbH
StadtLärm ─ A Distributed Urban Noise Monitoring System
Dr.-Ing. Tino Hutschenreuther
System Design
IMMS GmbH
Cologne, Oct. 11, 2017

2. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
Outline
1.The StadtLärm Project
2.System Architecture
3.Communications Architecture
4.Summary & Outlook
2

3. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
The StadtLärm Project: Motivation
Noise in urban areas
ever-present, detrimental to quality of life of citizens
regular sources: traffic, crowds
temporary sources: sirens, construction sites, sports or musical events
→ subject to administrative regulations
Administrative application processes and complaints
validation of complaints against approvals
empirical monitoring
Noise measuring equipment
expensive & usually made for single-spot measurements
Why not utilize today‘s low-cost embedded systems to monitor noise
across larger areas of a city?
3

4. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
The StadtLärm Project: Mission
Noise monitoring system
near-real-time monitoring of noise via noise sensors at numerous locations
strategically distributed throughout a city
measure noise levels, detect scenes & events (through machine learning
techniques), and visualize these in 3D
facilitate administrative processes and assess noise levels and thus quality of
life in general
Regulations
Germany: TA Lärm → specifies details about how to perform various noise-
related measurements (considering impulsiveness, tonality, time of day, …)
Our task
specify the communications architecture
provide necessary infrastructure for the duration of the project
central administration component + noise sensors‘ firmware
4

5. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
Outline
1.The StadtLärm Project
2.System Architecture
3.Communications Architecture
4.Summary & Outlook
5

6. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
System Architecture
Components:
noise sensors preprocessing audio data (distributed embedded systems, mobile
communications)
central higher-level processing service and database of results
web application for visualization and management of noise-related public
administration processes
central administration component for the overall system (incl. field devices)
Further Requirements:
extensibility (additional sensors, data consumers, services)
Communications
logical m:n relations → implementation, setup, maintenance efforts if
physical
preference: physical 1:n communications based on a broker architecture
→ MQTT as a simple but sufficient broker-based message-passing protocol
6

7. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
System Architecture
7

8. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
System Architecture
MQTT advantages:
lower complexity, better accessibility (than, e.g., AMQP)
open source implementations of broker and client libraries readily available for
various platforms and programming languages
1:n communications → linear growth in physical connections with additional peers
authentication and authorization are handled centrally by the broker
so can be logging and diagnostics
unified protocol (still allowing for variable message contents per topic)
more complex interaction patterns can be realized using MQTT primitives
MQTT diasdvantages:
maximum message size: 256 MiB (not an issue; could use chunking)
high traffic on the central broker → if necessary, upgrade network links,
hardware, move to a cloud provider, bridge multiple brokers, broker-specific
scalability features
Selected broker: Mosquitto
8

9. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
System Architecture
Grafana dashboard monitoring the broker under simulated load (Grafana logo © Grafana Labs)
9

10. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
Outline
1.The StadtLärm Project
2.System Architecture
3.Communications Architecture
4.Summary & Outlook
10

11. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
Communications Architecture: Security
Security ensured by the broker
clients connect via TLS v1.2 with mutual certificate validation
private CA for the project, certificates distributed to partners
ACLs further regulate who may publish or subscribe to which topics
Privacy by design: sensors neither store nor publish raw data
data is (lossily) preprocessed through an auto-encoder
11

12. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
Communications Architecture: Topics Hierarchy
Topics hierarchy defined iteratively in discussions among all partners
Sub-trees:
admin
sub-topics for overviews of field devices, registration and configuration of field devices
provided by the central administration component (sladmin)
devices
sub-topics for state, preprocessed audio (fingerprints) and environmental sensor data
state information is retained and updated via “last will” messages if devices go offline
published by field device application (sldevice) wrapping the audio preprocessing
implementation developed at Fraunhofer IDMT, taking care of buffering and
configuration
proc
sub-topics for various processing results, both “live” and per request; also administrative
data stored in a database
provided by the processing and storage service (Fraunhofer IDMT)
no sub-tree for the visualization application as this does not publish anything of
its own
12

13. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
Communications Architecture: Request/Response
MQTT’s message-passing paradigm does not offer a request/response
mechanism out of the box
However, this can easily be implemented:
topics sub-structured after a certain convention
works transparently with any broker and client library
13

14. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
Communications Architecture: Granularity
Granularity of published data subject to frequent consideration
MQTT’s spirit: publish single scalar values on topics
home automation: temperature, or thermostat set-value ✓
but audio fingerprints?
intuition with complex composite data: publish complex data structures
extensibility: future clients may only be interested in portions of the
structures
also: broker-level ACLs are per-topic
Thus:
mostly composite data (data structures)
but split up wherever sensible (e.g., audio data = separate TA Lärm data and
audio fingerprints)
singular values only in some cases (e.g., sensor online state)
request/response topics are always composite (JSON)
14

15. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
Communications Architecture: Extensibility
Extensibility considered from the get-go:
additional parties/components (mostly consumers)
additional sensors (in the noise sensors, or even as separate sensors)
Open MQTT, broker-based architecture (1:n, ACLs, extensible topics hierarchy)
Scenarios:
Connecting an open data portal → backend implements an MQTT client, subscribing
to real-time topics or performing requests on the processing component
Mobile app (citizen science?) → for performance reasons, set up a separate broker
bridged to the system’s, possibly implement caching and rate limiting on request
topics
Incorporating external (Internet) data sources (e.g., a weather service) → will
publish on topics of its own, existing clients will need adapting to make use of the
additional data (new clients immediately benefit from it)
Sensor Hardware Platform extension (extensible HW platform) → similar, new
topics
15

16. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
Outline
1.The StadtLärm Project
2.System Architecture
3.Communications Architecture
4.Summary & Outlook
16

17. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
Summary & Outlook
As introduced
sensor system for distributed noise monitoring
open, extensible system and MQTT-based communications architecture
Status quo
platform stress-tested with simulated data
hardware and algorithms still under development
Field test
6 months starting in March 2018
25 sensors distributed in selected areas of Jena, Thuringia, Germany
operation in training mode (= up to 40 GiB of total data created per 24 hours)
Later, scene & event classification can be moved into the sensors
17

18. © IMMS GmbHStadtLärm ─ A Distributed Urban Noise Monitoring System
Summary & Outlook
This paper is a result of the “StadtLärm” project (2016─2018),
supported by the German Federal Ministry for Economic Affairs and
Energy (funding reference: ZF4085703LF6).
18

19. © IMMS GmbH
IMMS Institut für Mikroelektronik- und Mechatronik-Systeme gemeinnützige
GmbH
Ehrenbergstraße 27, 98693 Ilmenau
Tel.: +49 3677 – 8749 300, Fax.: +49 3677 – 8749 315
www.imms.de
StadtLärm ─ A Distributed Urban Noise Monitoring System
I‘ll gladly help if there are questions or issues.
Dr.-Ing. Tino Hutschenreuther
tino.hutschenreuther@imms.de
Tel.: 03677 – 8749 340
19