March 18, 2017
A street lighting management system for a country, city, region, street or individual lighting fixture. Management can be executed both in real time and according to schedule. Display of energy consumption and lighting output. Firmware development.
Street lighting is an indispensable part of urban infrastructure. Lighting should be efficient, provide safety for citizens and have a self-diagnosis system for when devices break down. Often it is necessary for some lighting units to operate in a special mode, lighting up important locations like pedestrian crossings and crossroads. Manual management of street lighting doesn't allow the goals of municipal administration to be achieved effectively.
Modern LED lights, microcontrollers with a Wi-Fi module and the Internet of Things allow us to solve the abovementioned tasks and provide a high level of automation, reduce the complexity of infrastructure installation and maintenance, and increase the accuracy of device management.
The street lighting management system we developed consists of the following components:
Each lamppost is equipped with a management block running on an ESP8266 microcontroller. Microcontrollers form a wireless mesh network which allows the appliances to interact with each other on the principle of a peer-to-peer network with no single access point. Each appliance connects to several others within the coverage area. Routing from one device to another is carried out using intermediary devices. If one of them breaks down, routing automatically adapts to the changed network topology. A mesh network can be used both in a local network and to provide Internet access through one or several gateways. In the street lighting management system a mesh network removes the necessity of stretching communication lines between lampposts. An energy counter management is developed based on the ESP8266 microcontroller; it measures the output and consumption of electrical energy and manages the contactor. Management blocks interact with the central server online.
Each block receives commands from the central server and at regular intervals sends out telemetry data: light fixture temperature, real time lamp current, counter power load etc. If there's a temporary loss of connection to the server the data is saved in the device's non-volatile memory and sent later when the connection is reestablished.
The central server gathers diagnostic and telemetry data from the management blocks and provides notifications to the management blocks about changes to device configuration. Device configuration includes lighting levels and the schedule for changes to lighting. The configuration is saved in the non-volatile memory of the device which allows for the schedule to be applied autonomously even during a temporary loss of connection with the central server.
Readings of energy consumption, output, current and other data are sent at regular intervals by the devices to the central server where they are processed and saved in Elasticsearch. Various reports are compiled on the basis of the collected readings.
Alongside the telemetry data, the devices periodically send information about their availability to the central server. As a result the system is able to identify problem blocks which haven't contacted the server for a long time.
By analysing the devices' functionality readings and the information about their availability, the central server generates a warning signal sent to those responsible for a given block, enabling a prompt reaction to emergency situations.
Lighting devices and energy counters are displayed in the form of a tree and are grouped by street, district, and city, which makes navigation easier when searching for a specific device.
The OpenStreetMap mapping service is used, with the devices displayed on the map. All devices are tied to geographical coordinates which allows their location to be displayed visually.
To make navigation easier several filters were created, sorting the devices by whether they are online or offline, whether there is any failure in the appliance's functionality, and by the lighting level.
Appliance management includes setting the lighting in real time as well as creating a schedule for changes to lighting levels. Thanks to the groupings available, one can manage the lighting of a whole street or even create a lighting schedule for an entire district or city.
In addition too from real-time management, an operator's responsibility includes the possibility of bulk loading information about locations and devices, and printing out location QR codes for wiremen.
The Elasticsearch makes it possible to create a flexible selection based on various criteria, as well as grouping and aggregating readings collected from the energy counters. This provides the possibility of both viewing energy consumption and lighting output readings in real time at various levels of detail and creating reports on previous periods with device filters in place.
The installation and replacement of malfunctioning devices is carried out by field engineers. They have a special role in the web interface adapted for mobile phones. The field engineer pins a device to a specific location during its installation. This is done by scanning the QR code of the device and the QR code of the location with the help of a mobile phone's inbuilt camera. Thus the appliance can by displayed on the map without having to insert a costly and energy hungry GPS module into every management block.
During the system design process the client chose Kaa as IoT-middleware. The solution looked reliable, had comprehensive documentation and open source code. In practice, however, the product turned out to be a bit crude, the documentation partly irrelevant and interaction via API rather complicated. The development team thankfully managed to find prompt support on a developers' forum after encountering these difficulties.
Using ASP.NET MVC technology and Ubuntu hosting on DigitalOcean turned out to be an interesting combination. At the time of development a cross-platform version with open source ASP.NET Core code was at the RC1 stage, which also added fuel to the fire. Nevertheless, a web application doesn't require a large number of different APIs, allowing the serious problems associated with the shortcomings of ASP.NET Core RC1 to be avoided.
Docker was used for system deployment automation which allows for various subsystems to be scaled independently in the long term.
2002–2024