Year
2021
Problems solved
Data visualisation
Developing clear visual representations of system status, energy usage, and maintenance needs that enable quick decision-making.
Alert prioritisation
Designing notification systems that highlight critical issues without causing alert fatigue.
Mobile accessibility
Ensuring the system works effectively across devices for field technicians.
Workflow optimisation
Mapping and streamlining maintenance processes to reduce response times and simplify routine tasks.
Data collection and analysis
Reports on lighting usage, energy consumption, and environmental conditions to inform decision-making.
Scale and growth
Suitable for use in cities of different sizes: from towns to metropolitan areas.
Who we designed for
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.
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
Minimize 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.
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. Anchoring the information architecture to these future-proofs the data model.
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. So the model adds an operational layer on top of the standard: task, crew, etc. as entities. The two layers meet at the operator-to-technician seam. The standard-informed technical layer tells you a luminaire reports a comms failure and the operational layer guides the decison of how this becomes a unit of work.
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.
Solution highlights
Navigating lighting infrastructure
The system offers dual visualization of street lights – both as an organized 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 emphasize roads and landmarks, lighting management maps prioritize 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).
Profiles are created and managed independently, then assigned to specific areas or individual devices, ensuring they can be reused across multiple locations.
Metric visualisation
Reports
Personal takeaways
IoT ecosystem knowledge
Practical experience with sensors, connectivity options, power constraints, and data management in real-world Internet of Things applications.
Scalability challenges
Insights into designing solutions that can scale from small pilot projects to citywide implementations.
Long lifecycle considerations
Designing for products with 10+ year lifespans, including maintainability, durability, and future upgradability.