StadtLärm - A Distributed Urban Noise Monitoring System
1 like302 views
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.
StadtLärm - A Distributed Urban Noise Monitoring System
- 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