How to сhoose a street lighting management platform: An engineering perspective

Public lighting management system guide

Selecting a street lighting management platform — or street lighting CMS — is not about choosing a polished interface or comparing feature lists. It is an architectural decision that determines whether the system will operate reliably in a real urban environment for 10–15 years, integrate with other city services, and scale without full replacement.

Public street and area lighting accounts for up to 40% of electricity consumed by municipalities, and approximately 1–3% of total national electricity demand (The Climate Group / SEAD, Clean Energy Ministerial). A poorly chosen management platform does not just create operational inconvenience — it locks the city into a dead-end architecture that cannot adapt as infrastructure and efficiency requirements evolve.

The most common mistake in the selection process is treating the lighting platform as an isolated solution. In a modern city, it is always part of a broader digital ecosystem — alongside traffic management, video surveillance, SCADA systems, and energy infrastructure. A platform that cannot connect to this ecosystem loses most of its long-term value.

Key engineering takeaways:

This guide covers platform architecture, Open API requirements, must-have operational functions, asset lifecycle management, and a structured framework for evaluating any street lighting management platform or streetlight control software.

Start with architecture, not features — only a web-based platform is sustainable and scalable in a real Smart City environment.
Open API is not an optional feature — it is the baseline for integration with GIS, traffic management, video surveillance, and other city systems.
A street lighting CMS must cover six operational layers: real-time map/status, scheduling & dimming, energy reporting, OTA firmware updates, user roles & zones, and task management.
Asset inventory and lifecycle tracking are among the most underestimated requirements — a mature platform manages assets, not just lights.
Smart City does not mean one universal mega-platform — it means specialized domain systems connected through standardized interfaces.
The right platform allows a city to start simple and scale incrementally — without replacing hardware or rebuilding infrastructure.
Evaluate any platform through a structured KPI-based pilot — not a demo or a feature list

Street lighting platform architecture: Why it comes before features

Before discussing dimming profiles, reports, or dashboards, the first question to ask is: what architectural foundation is the system built on? Current options on the market include:

local desktop applications (Windows/Mac),
mobile applications,
web-based platforms (server + web interface),
hybrid solutions.

In real Smart City deployments, only web-based architecture proves sustainable and scalable over time. Why? Because a modern city is always a distributed system:

video surveillance runs on its own servers,
traffic management on its own,
SCADA and energy systems on their own,
street lighting on its own.

No single platform directly controls "the entire city."
The urban digital environment is built as a set of domain-specific systems that interact with each other. The connective layer between them is Open API.
If a public lighting management system is not built as a web platform with a fully documented API, it is architecturally constrained from the start and difficult to integrate into any broader ecosystem.

Open API integration: The compatibility baseline for Smart City Lighting

An Open API is the published interface through which a system communicates with the outside world. Through API integration, a street lighting platform can:

transmit data to the city's Smart City platform,
receive commands from external systems,
integrate with GIS, connect to task management systems,
feed analytics and BI tools,
interoperate with video surveillance and traffic management.

A critical distinction to understand:
Smart City ≠ one universal mega-platform.
Smart City = a set of specialized systems connected through APIs.

Attempting to select a single system that "does everything" is a strategic mistake. Such solutions tend to be overloaded, scale poorly, create strong vendor dependency, and complicate future modernization.

Street Lighting CMS: Core functional requirements

When evaluating a street lighting CMS, certain functions represent the current operational baseline — not advanced features, but table stakes.

Network map and real-time status

The platform must display:

all luminaires on a map,
their current status (operational / fault),
dimming level,
energy consumption (where metering is supported),
event history.

Without a real-time map and status layer, a platform cannot be considered operational.

Lighting Control

Required functions include:

on/off switching,
manual dimming,
schedule-based dimming,
annual and holiday lighting scenarios,
group control,
individual control of each luminaire — including the ability to address a single fixture within a network of thousands.

The system must scale from a single command to mass profile changes without losing control granularity.

Energy reporting and economics

Municipalities need to see not just consumption, but economics. The platform must allow operators

to set a cost per kWh,
generate consumption reports,
visualize dimming profiles,
display monthly and annual savings,
export all data.

Energy savings must be calculated and verifiable — not declared.

Remote Firmware Updates (OTA)

A modern platform must support

remote controller updates,
centralized firmware version management,
update status tracking across the network.

Without OTA update capability, operating large-scale networks becomes costly and operationally unmanageable.

Street lighting management software: Must-have requirements and evaluation checklist

Requirement	Why it matters	How to verify in pilot
Map & real-time status	Operational visibility across the network	Check live fault display on 100+ luminaires
Scheduling & dimming	Core energy savings mechanism	Run a week-long schedule change across groups
Energy reporting & cost calc	Measurable ROI for municipality	Export monthly report with kWh and cost data
OTA firmware updates	Reduces field maintenance cost at scale	Push firmware update to 10+ controllers remotely
User roles & zones	Distributed city operations require access control	Create 2 dispatchers with separate zone rights
Task management	Fault-to-resolution workflow	Trigger alarm → auto-create task → close with log
Asset inventory & lifecycle	Long-term asset management beyond light control	Add non-IoT asset, set service interval, check alert
Open API (bidirectional)	Integration with GIS, CMMS, Smart City platforms	Run one real API call: export or receive external command

How to evaluate a street lighting platform: A 30–60 day pilot framework

A proper evaluation cannot be done through a demo. A 30–60 day pilot on 100–500 luminaires should test:

Bulk schedule changes across multiple groups,
Alarm detection and task assignment workflow,
Data export: energy, events, inventory,
Role separation between dispatchers,
OTA update process end-to-end,
One real API integration scenario (GIS import or external command).

Document KPIs before starting: fault response time, energy baseline, export completeness. Test edge cases: connectivity loss, partial network failure, concurrent user access.
The evidence pack from a pilot — logs, exports, API responses — is the only reliable basis for a platform decision.

Advanced requirements: Asset management, Tasks, and API Integration

User management and responsibility zones

City operations are always distributed. The platform must support

user creation,
role-based access control,
group assignment,
defined responsibility zones.

For example:

dispatcher A is responsible for streets 1–2,
dispatcher B for streets 3–4,
fault notifications route to the specific responsible party.

Without access control and zone assignment, the system becomes unmanageable at scale.

Task management and maintenance workflow

A modern street lighting platform increasingly functions as an operational management system. It must support:

automatic task creation on fault detection,
manual task creation,
assignee management,
status tracking,
task closure,
full history storage.

This is effectively a CRM for urban infrastructure maintenance — particularly important in large networks where dispatchers and field crews interact continuously.

Asset inventory and lifecycle management

Inventory is one of the most underestimated functions in platform selection. Every asset has a service life:

luminaires,
controllers,
cabinets,
sensors,
even non-IoT assets such as benches, trees, and street furniture.

For example, if a bench coating has a 3-year paint lifespan, the system should store

the last service date,
trigger a maintenance notification at the appropriate interval,
log all work history.

This transforms the platform from a lighting control tool into a full asset management system.

Reporting and automated distribution

All data collected by the system must be

structured into reports,
exportable,
automatically distributed by email to responsible parties,
generated on a schedule.

Without this layer, data remains inside the interface and never becomes a management tool.

Bidirectional integration via Open API

The platform must be able to:

integrate into an external Smart City system,
integrate external services into itself,
support bidirectional data exchange,
maintain fully documented API endpoints.

Integration scenarios vary:

where a municipality already has a Smart City platform, lighting integrates as a module;
where no platform exists, the lighting system can become the integration core, connecting video surveillance, traffic management, and other city services.

Without a complete API, the platform becomes isolated and loses its long-term strategic value.

How to choose a street lighting management platform: Decision criteria

When selecting a street lighting management platform, evaluate:

Web-based architecture,
Presence of a documented Open API,
Real operational functions,
Scalability,
Asset inventory and lifecycle support,
Task management capability,
Integration potential within the city's existing digital ecosystem,
Total cost of ownership: licensing model, initial setup fees, and ongoing support costs — in many cases, configuration and onboarding charges significantly exceed the base connection cost and are not disclosed upfront.

The goal is not to find a universal super-platform. The right approach is to select a specialized system capable of fitting organically into the Smart City architecture through open interfaces — and with a pricing structure that remains transparent as the network scales.

DITRA Solutions: Two-tier approach to Street Lighting Control

DITRA Solutions supports two operational modes — depending on the scope of requirements and the city's level of digital maturity.

Direct line dispatching

This is the classic model built on a Windows application — the format most municipalities are already familiar with. In this mode, the dispatcher has access to:

connection to any equipment on the network,
full list of objects and lines,
real-time relay status display,
dimming state monitoring,
consumption data,
event and fault logs,
manual on/off and dimming control.

DITRA's implementation of this model — DITRA CMS — provides live graphical status updates of street lighting assets mapped via GPS, flexible dimming profile configuration, luminaire grouping, and zone assignment with adaptive control modes tailored to each project's requirements.

This is a baseline, proven dispatch room format — straightforward, reliable, and operationally familiar.

DITRA Synergy — Web Platform

For projects requiring extended functionality and integration, the Synergy platform adds:

a luminaire and asset map,
analytical reports and diagrams,
energy savings calculation,
task management and operational workflows,
user and responsibility group management,
asset inventory,
Open API for integration with other city systems.

Explore the DITRA Synergy platform here.

Architectural flexibility

These two modes are not isolated from each other. A city can start with classic line dispatching CMS and expand to the full Synergy web platform in minutes — without replacing any hardware or modifying the base infrastructure. This allows phased deployment and scaling precisely when it becomes necessary.

Choosing the right Street Lighting Platform: Final considerations

When selecting a street lighting management platform, there is no single universally correct architecture. Cities are at different stages of digital maturity. For some, classic line dispatching with real-time relay control, dimming, and consumption monitoring is sufficient. Others require a web platform with analytics, task management, reporting, and integration with other city services.

The key selection criterion is not the number of features, but the ability to:

start with a simple and operationally familiar model,
scale when necessary,
integrate through Open API,
expand the system without replacing infrastructure.

The right platform is one that allows a city to develop incrementally — from a familiar dispatch model to a full digital ecosystem — without hitting a technological dead end and without requiring a complete solution replacement.