A smart streetlight can lose its network connection while the light itself still has power. What happens next depends on the controller’s local settings: it might follow a stored schedule, use a configured fallback state, or require intervention. Remote commands and status updates are a separate question.
That is the distinction to settle before buying a connected lighting system. “Will the lights stay on?” is a reasonable question, but an acceptance test needs a more precise one: which failure are we testing, and what should each part of the system do?
First, identify what actually went down
A blank dashboard, an unreachable controller and a dark streetlight are three different observations. Start with the observation you can confirm.
Use the architecture to name the failed connection
Figure 1 in FHWA’s 2014 reduced-lighting guidance separates a management system, luminaire node controllers, individual luminaires and an ambient-condition sensor. Follow the failed connection on the diagram before assigning the incident to a contractor. A missing report at the management layer and a loss of electrical supply describe different restoration work.
Use the diagram to trace two paths separately: the path of a command to the controller, and the return path of a status report. If the management interface stops receiving updates, the next question is whether the controller still has power and an accepted local operating configuration. The diagram alone cannot answer that question.
This is a historical, generic architecture, not a diagram of LEOLink. The supplier’s current architecture, configuration and acceptance tests establish the supported protocols, local behavior and recovery sequence for the actual project.
| What failed? | What that tells you | Next check |
|---|---|---|
| Field communications | Commands or reports may not reach their destination; the luminaire may still have power. | Confirm actual light output and the controller’s documented offline behavior. |
| Central management service | The operator interface may be unavailable. | Check local operation separately and contact the service owner. |
| Electrical supply | The affected luminaire cannot produce light without an available power source. | Use the agency’s electrical fault and restoration procedure. |
| Luminaire, driver or controller | A local equipment fault can exist even when the network is healthy. | Inspect the affected asset through qualified maintenance personnel. |
Keep these categories in the incident record. Otherwise, a communications repair can be mistaken for a completed lighting repair.
What should happen locally?
Ask the supplier to describe the response for the actual controller, firmware and driver combination. Three details matter most:
- The trigger: does fallback start after a lost connection, a missed check-in, a platform outage or a restart?
- The light state: which output level or schedule should apply, and how is time maintained without normal connectivity?
- The recovery: when communications return, what happens to missed commands, settings and event records?
A supplier answer such as “the system is fail-safe” leaves those questions open. A useful answer names the behavior and points to the document and test that support it.
The public LEOLink system overview describes connected-lighting functions. For an offline requirement, request the corresponding controller documentation rather than inferring behavior from the platform’s normal features.
A practical acceptance exercise
Illustrative test scenario: a project requires selected lights to retain an approved local schedule during a defined communications interruption. This is a proposed test format, not a reported LEOTEK deployment or a claim about any controller.
- Record the test assets, hardware and firmware, local schedule, clock source and normal light state.
- Use a project-approved method to interrupt the relevant communications path while keeping the electrical condition known.
- Observe the lights in the field. Separately record the platform status, alarms and availability of remote commands.
- Restore the connection. Compare the returned settings, device time and event history with the baseline.
- Record each exception and its owner before accepting the result.
Agree on the observation period and pass/fail conditions before the exercise. A screenshot showing “online” after restoration is not enough to establish that the local schedule worked during the interruption.
Recovery needs an owner
When the connection returns, close two loops: confirm the field condition, then reconcile the records. Identify which assets remain unverified, whether commands need review and whether the incident history is complete. A system without event buffering may leave gaps; record them rather than treating an empty log as proof that nothing happened.
For the procurement review, keep the continuity requirement short: identify the failure condition, expected local response, verification method and recovery owner. NIST’s OT security guidance provides broader context for balancing security with physical-system reliability and operations.
Four states explain why an online light can still need attention
Separate electrical power, local control, communications and the management service. A fault in any one can produce a different observation at the operator's screen. A powered luminaire may continue an approved local schedule while the platform cannot contact it. An accessible dashboard may show old information because field communications have failed. A responsive controller may coexist with an electrical or optical fault elsewhere in the assembly.
This model changes incident triage. Begin with what is known, how recently it was observed and which part of the system produced the observation. A time-stamped last report is different from a current measurement. A stale record should not silently become the present lighting condition. This proposed diagnostic model is consistent with the system-boundary reasoning in NIST's OT security guide, but does not describe guaranteed behavior for a particular controller.
Offline operation has a time dimension
A controller's response immediately after losing communications may differ from its behavior after a restart or an extended interruption. Local schedules, clock handling and retained configuration are therefore relevant questions. Ask the supplier which information survives loss of communications, which survives loss of power, and what conditions require operator intervention. Do not assume that local scheduling establishes indefinite autonomous operation.
An illustrative acceptance scenario can include a normal schedule transition during a communications interruption, followed separately by a supported restart test under approved conditions. Record the field output, local time basis and available logs. Restore communications and compare the returned configuration with the accepted baseline. The observation period and expected results must come from the project's requirements and documented product capabilities.
The distinction between the two interruptions is important: a communications test and a power-recovery test answer different questions. Combining them without recording the sequence can make the result impossible to diagnose. A light that returns after power restoration does not prove that the expected schedule operated throughout a network outage.
Reconnection is a reconciliation problem
During an interruption, the city might change a schedule centrally while a field device continues its stored configuration. When the connection returns, which state should prevail? The project needs a documented rule for configuration version, effective time, missed commands and exceptions. The operator should not discover that rule by observing an unexpected district-wide change.
For an illustrative review, label the pre-outage configuration A and the newly approved configuration B. Identify the assets that received B, those still on A, and those whose state cannot be verified. Keep the unknown group explicit. A green online icon does not explain which configuration is running. The same discipline applies to event history: distinguish events buffered and uploaded after recovery from events that were never recorded.
Measure restoration instead of quoting one availability percentage
A monthly service-availability figure describes its stated boundary. It may not describe the availability of field communications, the duration of a particular outage, or the actual lighting state. An illustrative 99.9 percent figure over a 30-day month corresponds to about 43.2 minutes of unavailable time if all minutes share that denominator. It does not show whether those minutes occurred in one incident or many, or whether the streetlights stopped operating.
For operations, retain detection time, confirmed field condition, service restoration time, verified configuration and the time unresolved assets were closed. These timestamps help distinguish rapid reconnection from complete recovery. The practical lesson is that continuity and visibility of the system are separate objectives. Design the acceptance exercise to test both, then carry its records into the incident process. None of the illustrative arithmetic or states in this article establishes a LEOLink service-level commitment; those need the actual controller documentation and service agreement.
A stale dashboard can look more reassuring than a blank one
A displayed value needs a time meaning. Last received, last measured and last successfully commanded may describe three different events. During a communications outage, a dashboard can continue showing a previously reported on state even though it has no current confirmation. The interface should let an operator distinguish a recent observation from an old value retained for reference.
For a review exercise, compare the displayed state with its observation time and freshness indication. Disconnect the agreed communications path under controlled conditions, then check how the interface represents uncertainty. A clear unknown or stale state can be more useful than a green icon that silently preserves yesterday's information. This is a proposed acceptance question, not a claim about any particular LEOTEK platform's implementation.
The same distinction applies to historical energy and alarm records. If a device buffers data locally, ask which records it retains, for how long, and how missing periods are represented. If it does not, identify the resulting gap. A restored connection does not prove that every observation from the disconnected interval has been recovered. The city needs to know what is measured, what is missing and what is reconstructed.
Test the transition back to normal operation
A fleet may reconnect unevenly. Some devices recover quickly, others retry, and a small group may remain unreachable. In an illustrative recovery review, count the devices expected to return, those communicating again and those whose intended configuration has been confirmed. Those are different milestones. The last group should not be assumed identical to the first successful network connection count.
Ask how the system handles a backlog of messages or commands. A command that was appropriate before the outage may be inappropriate when delivered much later. The design should have a documented basis for deciding which instructions remain valid, how their age is determined and how the resulting state is reported. The actual behavior must come from the supported implementation and the city's agreed operating policy.
Testing recovery also exposes dependencies that a simple cable-disconnection demonstration can miss. A communications service can be available while another required service remains unavailable. Inventory the dependencies relevant to authentication, time and management, then agree which failures the acceptance exercise will cover. NIST's OT security guide provides the broader OT availability context; the proposed scenarios need to be tailored to the installed architecture.
Measure the unresolved tail of the incident
Suppose 980 of a hypothetical 1,000 devices resume communication promptly and 20 require follow-up. A 98-percent reconnection figure describes progress, but the remaining locations may still dominate the operational workload. Keep that exception list visible, with the last known state, responsible team and next action. Do not close the incident solely because the aggregate percentage looks satisfactory.
The most useful restoration report explains what was interrupted, what continued locally, what returned automatically and what required intervention. Record the time to confirm acceptable operation separately from the time the service provider declared its network restored. Those two clocks help the city identify whether the next improvement belongs in communications, local control, configuration reconciliation or maintenance response.
Questions customers ask
Do smart streetlights stay on when the network goes down?
They can, if power remains available and the installed controller supports the required local behavior. Confirm the exact schedule or fallback state and test it; connected lighting alone does not specify that response.
Can the dashboard tell us whether the street is dark?
An unreachable-device indication establishes a communications problem, not the light’s current output. Use the system’s documented diagnostics and field verification where the lighting condition matters.
What should we bring to a supplier review?
Bring the controller and luminaire models, firmware versions, required operating schedule and the failure scenario you want to test. That gives the discussion a defined outcome.
Continue with streetlight CMS architecture and alarm management, or send LEOTEK your continuity requirements.
