A city invests in one sensor network to support five services.
Water meters send readings. Streetlights report their status. Parking sensors show occupancy. Drainage sensors monitor water levels. Environmental sensors track local conditions.
The shared network reduces duplication and gives departments a common communications platform.
Then one gateway fails.
The network team sees one device offline.
The water team loses meter readings from part of the city. The drainage team loses visibility at several monitoring points. Parking data stops updating. Streetlight faults are no longer reported. Environmental observations arrive late.
The physical services may continue to operate. But the city has lost part of its ability to observe, manage and respond across several functions at once.
This is the overlooked risk of shared infrastructure: one failure can affect multiple services that appear independent on a dashboard.
The business case for sharing is real
Cities have good reasons to reuse digital infrastructure.
A communications network built for water metering may also be able to support other low-data applications. Shared gateways, connectivity, maintenance contracts and platform services can reduce the cost of deploying each new use case.
For a city operating under budget constraints, that matters.
But each additional service changes the consequences of failure. A gateway that originally supported monthly meter readings may later carry observations used to identify rising water in a drainage channel. The same communications outage can have very different consequences for those two decisions.
The question is no longer only:
Can this network connect more devices?
It becomes:
Can each service still meet its operational needs when a shared part of the network fails?
Five dashboards can hide one dependency
Consider an illustrative neighborhood where five departments use the same wireless network.
Each department has its own application. Each application reports that its sensors were working during the last check. Each team believes it has a functioning monitoring system.
Behind those dashboards, however, many of the sensors depend on Gateway G17.
If G17 loses power:
- Meter readings may be delayed until connectivity returns.
- Streetlight telemetry may become unavailable, even while lights continue to operate.
- Parking occupancy information may become stale.
- Drainage alerts from affected locations may stop arriving.
- Environmental monitoring may develop gaps in its time series.
Those are different outcomes. Some can tolerate a delay; others may need immediate attention. A city should avoid treating all lost observations as equally urgent.
It should also avoid assuming that an outage has stopped the underlying service. A communications failure may interrupt visibility without interrupting water supply or streetlight operation. That distinction matters when allocating response teams.
The operational challenge is to see the relationship between the failed component, the missing evidence and the decisions affected.
Redundancy is a relationship, not a device count
A city might respond by installing another gateway.
That could help but only if the second gateway provides a usable alternative when it is needed.
Two gateways may appear redundant while sharing the same power supply, backhaul connection, cabinet or flood-prone location. A disruption affecting that common dependency could take both offline.
Likewise, a sensor within range of more than one gateway does not automatically have dependable coverage. The city needs to verify that the alternative path can carry the required data under the relevant conditions.
A more useful resilience question is:
If this component or shared dependency fails, which services lose evidence, where, and for how long?
The answer requires more than a map of device locations. It requires an understanding of how assets, communications paths and city services depend on one another.
A digital twin should show the consequence of failure
A conventional asset view can show where sensors and gateways are installed and whether they are online.
A service-oriented digital twin can go further by connecting three views:
1. The asset view: What exists?
This includes sensors, gateways, power supplies, communications links, applications and the physical assets being monitored.
2. The dependency view: What relies on what?
Which sensors can reach which gateways? Which gateways share a power source or backhaul route? Which applications depend on those observations?
3. The service view: What function depends on the evidence?
Is a reading used for billing, preventive maintenance, flood monitoring, parking management or an environmental report? Who receives it, and how quickly does it need to be available?
Together, these views make it possible to explore the potential impact of a disruption before it happens.
A city could select Gateway G17 and ask:
- Which sensors and geographic areas may lose connectivity?
- Which services depend on those observations?
- Are alternative paths available and tested?
- Which critical decisions would be affected first?
- Who is responsible for responding?
The resulting assessment is only as reliable as the dependency information behind it. If network routes, ownership or failover arrangements are missing or outdated, the twin should show that uncertainty instead of presenting a confident answer.
The important test happens during disruption
A drainage sensor can be healthy on a clear day. Its gateway can be online. Its dashboard can show recent readings.
Now imagine that the gateway’s power supply is located in the same area that commonly floods.
When water rises, the sensor may continue working while the communications path fails. The city loses visibility during the very event the system was installed to monitor.
That suggests a useful addition to any monitoring service agreement: assess not only whether evidence is fresh during normal conditions, but whether it is likely to remain available under a defined disruption.
For critical locations, this could involve testing a scenario such as a local power outage, gateway failure or flood event. The assessment should identify expected evidence gaps, recovery arrangements and the teams responsible for acting.
There is no single resilience target that suits every service. A delayed parking update and a missing drainage alert have different consequences. Targets should follow the decision being supported.
Start with one shared dependency
A city does not need to model every asset before it begins. A practical pilot could focus on one network area and one critical service.
- Map the chain. Identify the sensors, gateways, power, backhaul, applications and operational teams involved.
- Identify shared dependencies. Find where several services rely on the same component, site or provider.
- Test a failure scenario. Simulate or safely test the loss of a gateway, power source or communications path.
- Assess the consequences. Separate delayed information, lost alerts and actual service interruption.
- Agree on a response. Define alternative evidence sources, escalation responsibilities and recovery priorities.
This exercise can reveal where investment matters most. The answer may be a second communications path, backup power, a revised maintenance arrangement, a field inspection procedure or a clearer agreement between departments.
The goal is to spend where it reduces a meaningful operational consequence.
From connected assets to dependable services
This issue extends beyond smart cities.
Two data centers may rely on the same fiber corridor. Two pumps may share an electrical panel. Two communications systems may run through the same duct. Assets that look separate in an inventory can still share a point of failure.
Infrastructure sharing creates efficiency. It can also concentrate risk.
The role of a digital twin is to make that trade-off visible, so that city leaders can decide where sharing is appropriate, where independence matters and what evidence must remain available during disruption.
A connected city should know more than how many devices are online. It should know which services remain observable and manageable when a shared dependency fails.
