Beyond software: a different model for street-lighting operations

For years, the basic technology model for connected street lighting has been familiar.

An authority buys a CMS. It may also have a separate asset-management system. A maintenance contractor carries out field work. Other suppliers provide controllers, communications, energy services and integrations. The authority's own team sits in the middle and makes the whole thing work.

Each individual component may be perfectly reasonable. The problem is the amount of coordination that remains with the customer.

Someone still has to check the alarms, reconcile the asset data, monitor communications, prepare reports, investigate energy discrepancies, manage integrations and decide what needs attention.

Software has digitised much of street lighting without necessarily changing who does the work.

We think that is beginning to change.

From software product to operational platform

The first step is integration.

If lighting control and asset management sit in separate systems, every operational process starts with an information boundary. A lamp fault may originate in the CMS, be associated with an asset in the AMS, create work in another system and eventually appear in management reporting somewhere else.

Bringing more of that context into one operational environment makes automation much more useful.

Lumino combines central management and asset-management functions so that control information, assets, faults, energy information and operational workflows can be considered together.

That is important because an isolated alarm is simply data. An alarm understood in the context of the asset, its recent behaviour, maintenance history and expected performance can become a useful operational decision.

AI changes the service economics

This is where AI becomes more interesting than the current wave of product marketing might suggest.

For an authority, the benefit of AI is not that staff can type questions into a chat box.

The bigger opportunity is that routine operational work can increasingly be carried out automatically.

A system can identify exceptions rather than asking someone to inspect every device. It can interpret patterns across alarms and measurements. It can look for inventory inconsistencies. It can generate routine reports. It can prioritise what needs attention.

That changes the economics of providing an operational service.

Traditional managed services can be labour intensive because people reproduce many of the same processes customer by customer. If the underlying platform can automate a significant proportion of that work, a relatively small specialist team can potentially support much larger lighting estates effectively.

AI therefore becomes part of how the service is delivered, not simply another feature that the customer has to learn to use.

A spectrum rather than an outsourcing decision

We do not think authorities should have to choose between buying software and outsourcing the whole operation.

A better model is a spectrum.

Platform

The authority uses Lumino and operates the network itself. Valiciti provides the platform, support and updates.

Supported operations

The authority retains overall control but asks Valiciti to perform selected activities — for example network monitoring, asset-data management, reporting, settlement support or fault analysis.

Managed operations

Over time, Valiciti can take responsibility for a defined operational scope against agreed service levels and outcomes.

The boundary can move as the customer's needs change.

An authority may start with software because that is the immediate procurement need. Later, staff changes or budget pressure may make additional operational support attractive. Another authority may already know that it wants to reduce the amount of routine monitoring carried out internally.

The service should adapt to the authority rather than forcing the authority to adapt to the service.

Managed service should not mean greater lock-in

There is an obvious risk in this model.

If an authority hands more operational responsibility to a supplier, it could become more dependent on that supplier rather than less.

That is why openness matters.

Lumino is built to support controller-gateway integration using the publicly available TALQ protocol. This helps separate the management platform from individual controller manufacturers and gives customers more flexibility in future hardware procurement.

The principle needs to extend further than controllers. Customer data must remain accessible. Integrations should use practical open interfaces. Service processes need to be documented and measurable. A managed service should make the operation easier to change, not harder.

Shared knowledge creates another advantage

There is also an opportunity that conventional single-customer systems struggle to capture.

When an authority identifies an unusual controller behaviour, firmware problem or recurring hardware fault, that knowledge often remains inside the supplier relationship or the local team.

Another authority may then spend time discovering exactly the same issue.

Lumino Exchange is intended to allow useful operational knowledge to be shared across participating customers while keeping each authority's own data under its control.

That creates the possibility of a service that improves as more operational experience is accumulated.

A problem seen once can become knowledge. A problem seen repeatedly can become a pattern. A pattern can eventually become something the platform detects automatically.

The outcome matters more than the software

None of this means that every authority should outsource its street-lighting operation.

Good internal teams will continue to provide enormous value, particularly where they understand the local network and its history better than anyone else.

The opportunity is to stop using those people for work that a system or specialist service could perform more efficiently.

The technology should handle routine monitoring, reconciliation and reporting wherever possible. Experienced people should concentrate on exceptions, engineering decisions, policy and the things that genuinely require local knowledge.

That is a very different objective from simply selling another CMS.

The question is no longer only: “What software should we buy?”

Increasingly, it should also be: “What work do we actually want our own team to be doing?”

We think that question will shape the next generation of street-lighting services.