Module 10

Network Inventory, GIS & the Digital Twin

Everything you've learned so far — the glass, the splitters, the closures, the loss budget — exists as physical hardware in the ground. This module is about the software copy of that network: the system of record that knows what exists, where it is, and which strand connects to which, so the whole thing can be designed, built, queried, and repaired without a shovel.

The digital twin

A real fiber network is thousands of physical things scattered across a city — poles, closures, cabinets, splices, unbroken threads of glass. You can't hold that in your head or drive to a manhole for every question. So you build a software copy — a digital twin — that mirrors the real one closely enough to answer questions about it.

That copy lives in a network inventory system: the system of record for what exists and how it's connected. When the field crew's clipboard disagrees with the database, the inventory system is the version everyone trusts.

The inventory system isn't built once and frozen. It rides the whole life of a build — each phase produces something the next one needs:

Each phase hands the next a deliverable; the twin is the thread running through all four. BOM/BOQ = Bill of Materials / Bill of Quantities.

As-designed vs. as-built — and the gap

Two very different pictures of the same network sit inside the twin:

• As-designed (also as-planned) — the engineered layout before anyone digs: the intended cable routes, where each splitter and splice should go, the counts, and the bill of materials. This is the plan.
• As-built — the documented record of what was actually installed: the span that got rerouted around a tree, the handhole moved three meters, the extra splice nobody planned, the hardware that got substituted because the warehouse was out.

The difference between these two is the as-built gap — the accumulated drift from every field deviation. The plan said the cable runs down the east side of the street; the crew ran it down the west side. If the twin still shows the east side, every future decision built on it is quietly wrong.

Physical and logical inventory

The inventory itself has two layers stacked on top of each other:

The two layers meet at the physical port: it connects the physical cables while also anchoring the logical ports that logical connections attach to. A complete OSS (Operations Support System) inventory keeps both layers — physical and logical — in sync, so a change in one is reflected in the other.

Two maps of one network

This is the single most important idea in the whole module, so slow down here. The same network is stored two completely different ways, and both are necessary.

Why two? Because they answer different questions, and neither can answer the other's:

Spatial is the world of crews and length-based math; logical is the world of tracing, capacity assignment, and fault isolation. They can disagree in ways that matter:

• A cable can be physically intact but logically dark — the glass is fine and continuous, but no service is assigned to those strands, so they carry nothing.
• A strand can be logically continuous through a closure where two physically separate cables meet and are spliced together — one logical path, two physical cables.

See it for yourself. The widget shows one network both ways — flip the switch to redraw it as a geographic map or a clean connectivity graph, then trace a customer and watch the same path light up in both.

Points and lines (GIS)

The spatial map is stored in a GIS (Geographic Information System) — software that holds every asset as a geospatial feature with real coordinates. Despite all the fiber-hardware variety, a GIS needs only two shapes:

Storing assets this way unlocks spatial queries — questions only geometry can answer:

• Proximity — "What closures are within 100 m of this new address?"
• Length — "How many meters of cable on this route?" (drives both fiber cost and distance loss)
• Intersection — "Does this planned trench cross a gas main or a flood zone?"

None of these need to know which strand connects to which — they're pure geometry. For that question, you need the other map.

Tracing a path

A trace follows a single connection end to end through every passive and active element it touches — every splice, splitter, connector, and panel — to reconstruct the full path from the origin (the OLT, the Optical Line Terminal in the central office) all the way to the endpoint (the ONT, the Optical Network Terminal at the home). The passive plant in between — the fiber and splitters — is the ODN (Optical Distribution Network); OLT, ODN, and ONT are the three pieces of the access network you met in Module 2.

The natural way to think about a trace is as a graph traversal. The connectivity model is a graph:

• Nodes = ports and elements (an OLT port, a splitter input/output, a terminal port, an ONT).
• Edges = the splices and connections that join one port to the next.

Tracing is just walking that graph from a start node, hop by hop, until you reach the end — collecting everything you step through. With the full list in hand, a trace can do three useful things:

1. List every component — every participating fiber, splice, splitter, and connector on the path. "What does this circuit touch?"
2. Compute cumulative loss — the walk follows the logical graph hop by hop, but for each span it crosses it pulls that span's length from the spatial model and the joint losses from the logical elements. In other words the trace joins both maps: it sums the distance loss (length × dB/km, from the spatial lengths) plus each joint's loss (from the logical splices, connectors, and splitters). That's why you need both maps to compute the budget on demand.
3. Find where connectivity is missing — if the walk hits a port with nothing spliced to it, the trace stops there. That's your break, pre-located before anyone rolls a truck.

Feasibility and the money KPIs

The twin doesn't just describe the network — it's queried constantly to make money decisions. The first question is always: can we even serve this house?

Serviceability

Serviceability (or service feasibility) answers: can a given address be served, and how? The inventory and GIS check whether infrastructure already reaches the address — or can economically reach it. In practice that means asking the twin:

• Is there a drop terminal or closure nearby with spare capacity?
• Is there an available splitter port to assign this customer to?
• If not, what's the cost to extend a drop to the property?

Asked thousands of times a day, this check is usually automated and exposed as an API: a rep types an address and the twin answers "serviceable" or "not yet — here's the cost" in real time. The same checks pre-qualify leads, define the serviceable footprint, and budget where to build next.

The KPIs people constantly conflate

Once a network is built, a handful of KPIs (Key Performance Indicators) decide whether it was a good investment. They sound alike, people swap them carelessly, and the confusion has real consequences. Using the FTTH Council Europe definitions:

Now drive the relationships yourself — watch the denominators pull the rates apart: