Design

When developing the architecture of the System, the key non-functional requirements were:

  • Ability to deploy the System on the customer’s servers;
  • Ability to deploy the System in the cloud;
  • Use of system software only with open source (Linux, PostgreSQL, etc.);
  • Support for minimal server hardware (1 processor, 512 MB RAM) for pilot projects or small installations;
  • Possibility of horizontal scaling due to the division of software into micro services;
  • Possibility of simultaneous operation of equipment from different manufacturers while maintaining the principle of a single dispatching window;
  • Multi-layer fault tolerance;
  • Security.

Depending on the size of the project, the type of equipment used in the SLCC / luminaries and the requirements for the level of availability, the architecture of the solution may differ. The figure below shows a typical minimal architecture, when all the components of the System are deployed on one virtual (or physical) server.

Typical solution scheme

Low layer mesh based radio network

Based on soft radio gateways

  1. SLCC without built-in radio gateway;
  2. Pole of street lighting on which the controlled luminaire is installed;
  3. A mounting for street lighting, on which an uncontrolled luminaire is installed;
  4. Mesh-net;

Based on radio gateways

  1. SLCC without built-in radio gateway;
  2. Pole of street lighting on which the controlled luminaire is installed;
  3. A mounting for street lighting, on which an uncontrolled luminaire is installed;
  4. Mesh-net;
  5. Radio gateway installed on one of the mountings.

A group of luminaries within one radio network, can be served by several radio gateways. One of the radio gateways is the main one, the others are backup. Regular rotation of the roles of radio gateways allows you to proportionally consume mobile traffic on all SIM cards.

Upper level

Solution Diagram of Technical Audit

The subsystem “Technical audit” provides collection of primary information about the state of street lighting facilities, as well as the characteristics of the installation sites.

AWS S3 or S3 Compatible Object Storage is only used for storing photos and videos.

System software

  • Operating system: Linux;
  • Database management system: PostgreSQL;
  • Cache: Redis;
  • SSL / TLS gateway: nginx with Letsencrypt support;
  • Docker

Development technologies

  • The Golang programming language;
  • TypeScript programming language and React library;
  • C programming language;
  • JavaScript programming language (for describing custom logic).

Supported Cloud Providers

  • AWS
  • Azure
  • Digital Ocean

Solution Diagram when Integrating 3rd Party Vendor

LMS and vendor’s middleware interact according to the black box principle. The specification of the application program interface (API) between systems remains unchanged.

Different 3rd party lighting control vendors support different types of middleware:

  • A middleware performs full encapsulation of the protocols between the LMS and the devices: electricity meter, cabinet sensors, radio gateways, etc. LMS gets high level API (JSON, Protobuf, MQTT, etc.)
  • A middleware provides tunneling of network interface and ensures delivery of network messages between LMS and managed device. Implementation of low-level protocols for interaction with an electricity meter or cabinet controller is responsibility implemented at the NG level.

Last modified March 17, 2022 : binding mountings to cabinet (f7c9037)