Year
2021
Problem
The big savings from smart lighting — energy and maintenance both — come partly from the hardware and partly from running the network well. The system's job is narrower: making "running it well" something an operator can actually do.
Two primary users hold different mental models, and most of the design work sits in the hand-off between them. The control-room operator works top-down — policy → zone → schedule → group → luminaire. The field technician works bottom-up — ticket → module → pole → proof of repair. A fault has to travel from one world to the other and back: detected, triaged, dispatched, fixed, verified, closed.
Around that seam sit the familiar control-room problems: surfacing status without drowning operators in alerts, visualising energy and usage data clearly enough to inform decisions, and keeping maintenance workflows short.
Who we designed for
Primary users
People who work with the system directly.
City planners and analysts
Optimise city lighting for energy efficiency, cost savings, and enhanced public safety.
Operations administrators
Ensure the lighting infrastructure is functional and well-maintained.
Maintenance technicians
Perform repairs.
Secondary users
People who set the goals of the system and/or depend on it in some ways.
Urban designers and architects
Integrate smart lighting with broader urban design projects.
Environmental analyst
Minimise environmental impact and promote sustainability.
Community members
Benefit from improved lighting for safety, convenience, and quality of life.
Policy makers and government officials
Develop and implement policies that leverage smart lighting for broader city benefits.
Constraints
Decade-long lifecycles
Lighting hardware stays in the ground for 10+ years. The design had to assume maintainability, durability and future upgradability rather than a typical software refresh cycle.
Towns to metropolitan areas
The same system had to hold up from a few hundred luminaires to citywide networks — without small deployments inheriting big-city complexity.
Field conditions
Technicians work outdoors, on mobile devices. Anything they need has to work in that context.
Approach
Modelling the domain
Before any screens, the work was to settle what the system is made of. The industry has a standards-backed vocabulary you can lift rather than invent: the TALQ Smart City Protocol models the world as Device → Function → Attribute/Event, addressed by Groups and driven by Services; D4i defines the luminaire, energy and diagnostics data each device reports; EN 13201 supplies the lighting-class taxonomy.
But a technical standard only takes you so far. TALQ describes devices and the data they report; it says nothing about whose job a fault becomes. The model therefore ended up in three layers — two grounded in the standards, one added on top.
Asset layer
Pole, bracket, luminaire, driver and controller — the physical things, each with a catalogue type carrying wattage, colour temperature, socket and warranty attributes.
Control layer
Groups, zones and segments as the targets of commands; schedules and dimming profiles as reusable programs assigned to them.
Runtime layer
Telemetry and faults — dimming failure, comms loss, voltage anomalies, the "day burner" lit in daylight.
Navigating lighting infrastructure
The system offers dual visualisation of street lights – both as an organised hierarchical list and on an interactive map. Each display method provides real-time status monitoring to accommodate different user needs.
Map style
Unlike regular maps that emphasise roads and landmarks, lighting management maps prioritise the lighting infrastructure itself as the primary visual element. The base map is simplified to remove details irrelevant to lighting management.
Energy profiles
Adaptive brightness schedules automatically adjust illumination levels based on time of day, season, local sunset/sunrise times, and amount of traffic. Custom dimming patterns can be set for different urban zones (residential, commercial, industrial, parks). Energy consumption parameters set the maximum and minimum power thresholds based on municipal policies. Profile can also represent a special event override for temporary lighting requirements (festivals, emergencies, construction).
Metric visualisation
Reports
Key decisions
Adopt, don't invent the language
The information architecture is anchored to TALQ, D4i and EN 13201 rather than a house ontology. A bespoke model might have fit the first release more snugly; the standards future-proof the data model and keep the door open to other vendors' hardware.
An operational layer on top of the standard
The standards stop at devices and data, so the model adds tasks and crews as first-class entities. The two layers meet at the operator-to-technician seam: the technical layer says a luminaire reports a comms failure, the operational layer decides how that becomes a unit of work.
Policy as reusable programs
Schedules and dimming profiles are created and managed independently, then assigned to zones, groups or individual devices — rather than configured per luminaire. Changing how a district lights at midnight is one edit, not a walk through every device.
Impact
A short, fixed-scope engagement doesn't leave room to validate a system like this in deployment, so the measure is what the design targets — the operator behaviours.
Alarm load
Keeping the steady-state alarm rate manageable by prioritising and grouping signals, and separating informational from action-required.
Fault to repair
A fault travels cleanly from detection to closure — triaged into a work order, dispatched, fixed, verified — with nothing rekeyed at the operator-to-technician hand-off.
Right light, not more light
Letting operators set and defend lighting to policy — level, place, time — rather than defaulting to maximum brightness on the assumption that brighter is safer.
Learnings
IoT ecosystem knowledge
Practical experience with sensors, connectivity options, power constraints, and data management in real-world Internet of Things applications.
Standards as design material
Industry standards turned out to be a source of information architecture, not just compliance — a vocabulary the users' tools and vendors already speak, free to adopt and cheaper to maintain than a custom ontology.