Infrastructure Network Models: How Linear Algebra Reveals Interdependence, Resilience, and Risk

Last Updated July 2, 2026

Infrastructure network models explain how built, technical, ecological, and institutional systems depend on connected structure. Infrastructure is not only a collection of assets. It is a network of roads, pipes, power lines, substations, ports, hospitals, reservoirs, data centers, bridges, rail corridors, communication systems, supply chains, control systems, agencies, and communities linked through flows, dependencies, constraints, and vulnerabilities.

This article continues Part V of the Linear Algebra for Systems Modeling series by connecting infrastructure networks, graph representation, adjacency matrices, incidence matrices, flow constraints, node balance, interdependence, redundancy, bottlenecks, cascading failure, resilience, criticality, vulnerability, restoration, sparse computation, scenario analysis, and responsible governance.

The central modeling question is not only “What infrastructure assets exist?” It is “How are they connected, what depends on what, where can flow move, where can failure spread, and which representation choices shape what risks become visible?”

Infrastructure networks are often multilayer systems. Transportation supports emergency response. Power supports water treatment and communication. Communication supports grid control. Ports and rail support supply chains. Hospitals depend on energy, water, roads, staffing, information systems, and logistics. A disruption in one layer can propagate into another.

Linear algebra helps model this structure by turning infrastructure into matrices, vectors, operators, constraints, and workflows. Adjacency matrices encode asset-to-asset connections. Incidence matrices encode node-edge relationships. Flow vectors encode movement. Capacity vectors encode limits. Laplacians encode connectivity and diffusion. State vectors encode asset condition. Transition matrices encode degradation, recovery, or operational change. But every mathematical object depends on representation choices that require technical and institutional accountability.

Why Infrastructure Network Models Matter

Infrastructure network models matter because modern societies depend on connected systems that are difficult to understand asset by asset. A bridge matters because it connects routes. A substation matters because loads depend on it. A water-treatment facility matters because communities, hospitals, industry, and emergency services depend on its output. A port matters because global supply chains pass through it. A data center matters because services, agencies, logistics, and financial systems depend on digital continuity.

Network modeling helps reveal relationships that are not visible in asset inventories. It can identify critical nodes, overloaded edges, isolated communities, redundant routes, dependent layers, weak cuts, cascading-failure pathways, and restoration priorities.

Infrastructure network models support planning, maintenance, risk analysis, emergency response, public investment, and governance.

Back to top ↑

Infrastructure as Connected Systems

Infrastructure systems are connected physically, functionally, spatially, operationally, and institutionally. A road connects locations physically. A power line transfers electricity. A communications network supports control signals. A supply-chain link connects production and distribution. A regulatory agency, operator, or maintenance contractor may connect assets institutionally.

These connections matter because infrastructure performance depends on relationships. A system can have many assets and still fail if those assets are poorly connected, overloaded, isolated, or dependent on a fragile layer.

Infrastructure modeling should begin by defining which layer or layers are being represented.

Back to top ↑

Nodes, Edges, and Assets

In an infrastructure graph, nodes often represent assets, locations, service areas, junctions, facilities, control points, or institutional actors. Edges represent physical links, functional dependencies, flows, access relationships, service channels, or control signals.

The same asset can appear differently depending on the model. A hospital may be a demand node in an electric-grid model, a service node in a health-system model, and a critical destination in a transportation-access model.

Back to top ↑

Physical, Functional, and Institutional Links

Infrastructure networks contain different kinds of connections. Physical links connect assets directly. Functional links express dependence. Institutional links express governance, ownership, maintenance, funding, or operational responsibility.

These connection types should not be collapsed without care. Physical connectivity, functional dependence, and institutional responsibility answer different questions.

Back to top ↑

Single-Layer and Multilayer Networks

A single-layer infrastructure model represents one system at a time, such as a road network or water network. A multilayer model represents several systems and the dependencies among them.

Multilayer models are often necessary for resilience analysis because failures rarely respect system boundaries.

Back to top ↑

Adjacency, Incidence, and Flow Representation

Infrastructure network models often use several matrix representations. Adjacency matrices show asset-to-asset connections. Incidence matrices show node-edge structure. Flow vectors show movement. Capacity vectors show limits. State vectors show asset condition or service status.

Node balance can be written using an incidence matrix:

The sign convention must be documented because it determines whether positive balance means net inflow, net outflow, supply, or demand.

Back to top ↑

Capacity, Demand, and Service

Infrastructure networks are meaningful because they provide service. A road network provides mobility. A water network provides water. A power grid provides electricity. A hospital system provides care. A communication network provides connectivity. Flow and capacity models help compare service demand against system capability.

Capacity values are rarely neutral. They may represent design capacity, observed capacity, regulatory capacity, emergency capacity, or degraded capacity under stress.

Back to top ↑

Interdependence and Cascading Failure

Infrastructure systems are interdependent. Failure in one network can reduce performance in another. Power outages can disrupt water pumps, communication systems, transit, hospitals, fuel distribution, and emergency operations. Transportation failures can disrupt supply chains and repair crews. Communication failures can impair control systems.

Cascading failure models require more than graph connectivity. They require rules for how damage, load, dependence, thresholds, and recovery interact.

Back to top ↑

Redundancy, Resilience, and Criticality

Redundancy means there are alternative paths, spare capacity, backup systems, or substitute services. Resilience means the system can absorb, adapt to, recover from, or transform under disruption. Criticality describes how important a component is to system performance.

Redundancy should be tested under realistic constraints. A backup route may exist in the graph but fail under capacity, access, ownership, weather, staffing, or operational constraints.

Back to top ↑

Centrality, Bottlenecks, and Vulnerability

Graph metrics can help identify structurally important infrastructure elements. Degree centrality, betweenness, closeness, eigenvector centrality, PageRank, flow centrality, and cut analysis can all reveal different kinds of importance.

Infrastructure vulnerability is not one metric. It depends on the hazard, service objective, time scale, population affected, and available response options.

Back to top ↑

Spatial, Temporal, and Operational Structure

Infrastructure networks are often embedded in space and time. Roads have locations. Power equipment has geographic exposure. Water systems depend on pressure zones. Communications networks depend on distance, line of sight, and routing. Emergency response depends on time of day, staffing, weather, traffic, and demand.

A purely topological network model may miss spatial exposure, temporal dynamics, operational constraints, and social consequences.

Back to top ↑

Scenario Analysis and Stress Testing

Infrastructure models should be tested under scenarios. A scenario may remove assets, reduce capacity, increase demand, change flow, delay restoration, alter interdependence, or impose a hazard footprint. Stress testing helps reveal fragility that average-condition models hide.

Scenario analysis should include both technical outputs and interpretive consequences: who loses access, where service shortfalls occur, and which recovery priorities are implied.

Back to top ↑

Restoration, Prioritization, and Recovery

After disruption, infrastructure modeling often shifts from prevention to restoration. Restoration modeling asks which assets should be repaired first, how limited crews and materials should be allocated, and how service recovery should be prioritized.

Restoration models are not neutral. Objectives and weights can prioritize throughput, economic activity, critical services, vulnerable communities, or speed. These priorities should be explicit.

Back to top ↑

Data Provenance and Model Governance

Infrastructure network models depend on data that may be incomplete, sensitive, outdated, proprietary, classified, or inconsistent across agencies. Asset inventories may omit informal connections, hidden dependencies, degraded conditions, emergency procedures, or social vulnerability.

Infrastructure modeling must balance technical precision, security, transparency, public accountability, and responsible use.

Back to top ↑

Infrastructure Network Modeling Workflow

A reproducible infrastructure network workflow should make each modeling layer explicit: asset definitions, edge definitions, graph boundary, network type, capacity units, demand assumptions, dependency rules, failure scenarios, recovery rules, data provenance, sensitivity tests, and interpretation warnings.

The workflow should preserve both mathematical outputs and modeling assumptions.

Back to top ↑

Mathematical Deepening

This section adds a more formal layer. Infrastructure network modeling connects graph theory, adjacency matrices, incidence matrices, capacity vectors, flow vectors, state vectors, Laplacians, interdependence matrices, scenario perturbations, optimization, sparse computation, uncertainty review, and governance.

Back to top ↑

Back to top ↑

Computation and Reproducible Workflows

Computational workflows for infrastructure network models should document asset tables, connection tables, layer definitions, edge types, capacity units, service demand, dependency rules, node states, edge states, disruption scenarios, connectivity diagnostics, flow feasibility, criticality metrics, recovery assumptions, data provenance, security considerations, and interpretation warnings.

The companion repository treats infrastructure networks as auditable systems models. Python, R, Julia, SQL, Haskell, C, C++, Fortran, Rust, Go, notebooks, schemas, generated outputs, Canvas artifacts, advanced reports, and calculators each support a different layer of reproducible infrastructure analysis.

For this article, the computational examples focus on infrastructure asset registries, edge registries, layer summaries, dependency auditing, capacity/service diagnostics, simple failure scenarios, and governance records for infrastructure-network modeling choices.

Back to top ↑

Python Workflow: Infrastructure Network Audit

The Python workflow below builds a small multilayer infrastructure network, summarizes assets and dependencies, checks service-critical nodes, simulates a simple disruption, and writes auditable outputs.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import json


@dataclass(frozen=True)
class InfrastructureAsset:
    node: str
    layer: str
    service_role: str
    critical: bool
    baseline_capacity: float


@dataclass(frozen=True)
class InfrastructureEdge:
    source: str
    target: str
    edge_type: str
    capacity: float
    dependency_strength: float


@dataclass(frozen=True)
class InfrastructureNetworkAudit:
    network_name: str
    node_count: int
    edge_count: int
    layer_count: int
    critical_asset_count: int
    interdependency_edge_count: int
    total_baseline_capacity: float
    disrupted_asset: str
    remaining_capacity_after_disruption: float
    capacity_loss_fraction: float
    governance_warning: str


def build_assets() -> list[InfrastructureAsset]:
    return [
        InfrastructureAsset("power_substation", "energy", "electric service", True, 100.0),
        InfrastructureAsset("water_pump", "water", "water pressure", True, 60.0),
        InfrastructureAsset("hospital", "health", "critical care", True, 80.0),
        InfrastructureAsset("road_bridge", "transportation", "access corridor", True, 70.0),
        InfrastructureAsset("communications_hub", "communication", "control and coordination", True, 50.0),
        InfrastructureAsset("warehouse", "logistics", "supply distribution", False, 40.0),
    ]


def build_edges() -> list[InfrastructureEdge]:
    return [
        InfrastructureEdge("power_substation", "water_pump", "functional_dependency", 60.0, 0.95),
        InfrastructureEdge("power_substation", "hospital", "functional_dependency", 80.0, 0.90),
        InfrastructureEdge("communications_hub", "power_substation", "control_dependency", 40.0, 0.70),
        InfrastructureEdge("road_bridge", "hospital", "access_link", 70.0, 0.80),
        InfrastructureEdge("road_bridge", "warehouse", "logistics_link", 40.0, 0.75),
        InfrastructureEdge("warehouse", "hospital", "supply_link", 35.0, 0.65),
        InfrastructureEdge("communications_hub", "hospital", "coordination_link", 35.0, 0.60),
    ]


def impacted_capacity(disrupted_asset: str, assets: list[InfrastructureAsset], edges: list[InfrastructureEdge]) -> float:
    asset_capacity = {asset.node: asset.baseline_capacity for asset in assets}
    impacted = {disrupted_asset}

    for edge in edges:
        if edge.source == disrupted_asset and edge.dependency_strength >= 0.80:
            impacted.add(edge.target)

    return sum(asset_capacity[node] for node in impacted)


def build_audit() -> tuple[InfrastructureNetworkAudit, list[InfrastructureAsset], list[InfrastructureEdge]]:
    assets = build_assets()
    edges = build_edges()
    layers = sorted({asset.layer for asset in assets})
    disrupted_asset = "power_substation"

    baseline_capacity = sum(asset.baseline_capacity for asset in assets)
    lost_capacity = impacted_capacity(disrupted_asset, assets, edges)
    remaining_capacity = baseline_capacity - lost_capacity

    audit = InfrastructureNetworkAudit(
        network_name="synthetic_multilayer_infrastructure_network",
        node_count=len(assets),
        edge_count=len(edges),
        layer_count=len(layers),
        critical_asset_count=sum(1 for asset in assets if asset.critical),
        interdependency_edge_count=sum(1 for edge in edges if "dependency" in edge.edge_type),
        total_baseline_capacity=round(baseline_capacity, 12),
        disrupted_asset=disrupted_asset,
        remaining_capacity_after_disruption=round(remaining_capacity, 12),
        capacity_loss_fraction=round(lost_capacity / baseline_capacity, 12),
        governance_warning=(
            "Infrastructure network results depend on asset definitions, edge definitions, layer boundaries, "
            "capacity units, dependency rules, hazard scenarios, operating conditions, data provenance, "
            "security constraints, and social vulnerability interpretation."
        ),
    )

    return audit, assets, edges


def write_outputs(output_dir: Path) -> None:
    (output_dir / "tables").mkdir(parents=True, exist_ok=True)
    (output_dir / "json").mkdir(parents=True, exist_ok=True)

    audit, assets, edges = build_audit()
    audit_row = asdict(audit)

    with (output_dir / "tables" / "infrastructure_network_audit.csv").open(
        "w", newline="", encoding="utf-8"
    ) as handle:
        writer = csv.DictWriter(handle, fieldnames=list(audit_row.keys()))
        writer.writeheader()
        writer.writerow(audit_row)

    with (output_dir / "tables" / "infrastructure_assets.csv").open(
        "w", newline="", encoding="utf-8"
    ) as handle:
        writer = csv.DictWriter(handle, fieldnames=list(asdict(assets[0]).keys()))
        writer.writeheader()
        writer.writerows(asdict(asset) for asset in assets)

    with (output_dir / "tables" / "infrastructure_edges.csv").open(
        "w", newline="", encoding="utf-8"
    ) as handle:
        writer = csv.DictWriter(handle, fieldnames=list(asdict(edges[0]).keys()))
        writer.writeheader()
        writer.writerows(asdict(edge) for edge in edges)

    (output_dir / "json" / "infrastructure_network_audit.json").write_text(
        json.dumps(audit_row, indent=2, sort_keys=True),
        encoding="utf-8",
    )


if __name__ == "__main__":
    write_outputs(Path("outputs"))
    print("Infrastructure network audit complete.")

This workflow keeps asset definitions, dependency edges, capacity assumptions, disruption logic, and governance warnings together.

Back to top ↑

R Workflow: Infrastructure Diagnostics

R can support infrastructure-network diagnostics by preserving asset tables, edge tables, layer summaries, dependency counts, and disruption summaries.

assets <- data.frame(
  node = c("power_substation", "water_pump", "hospital", "road_bridge", "communications_hub", "warehouse"),
  layer = c("energy", "water", "health", "transportation", "communication", "logistics"),
  service_role = c("electric service", "water pressure", "critical care", "access corridor", "control and coordination", "supply distribution"),
  critical = c(TRUE, TRUE, TRUE, TRUE, TRUE, FALSE),
  baseline_capacity = c(100, 60, 80, 70, 50, 40)
)

edges <- data.frame(
  source = c("power_substation", "power_substation", "communications_hub", "road_bridge", "road_bridge", "warehouse", "communications_hub"),
  target = c("water_pump", "hospital", "power_substation", "hospital", "warehouse", "hospital", "hospital"),
  edge_type = c("functional_dependency", "functional_dependency", "control_dependency", "access_link", "logistics_link", "supply_link", "coordination_link"),
  capacity = c(60, 80, 40, 70, 40, 35, 35),
  dependency_strength = c(0.95, 0.90, 0.70, 0.80, 0.75, 0.65, 0.60)
)

disrupted_asset <- "power_substation"

direct_impacts <- edges$target[
  edges$source == disrupted_asset & edges$dependency_strength >= 0.80
]

impacted_nodes <- unique(c(disrupted_asset, direct_impacts))
baseline_capacity <- sum(assets$baseline_capacity)
lost_capacity <- sum(assets$baseline_capacity[assets$node %in% impacted_nodes])
remaining_capacity <- baseline_capacity - lost_capacity

audit_record <- data.frame(
  network_name = "synthetic_multilayer_infrastructure_network",
  node_count = nrow(assets),
  edge_count = nrow(edges),
  layer_count = length(unique(assets$layer)),
  critical_asset_count = sum(assets$critical),
  interdependency_edge_count = sum(grepl("dependency", edges$edge_type)),
  total_baseline_capacity = baseline_capacity,
  disrupted_asset = disrupted_asset,
  remaining_capacity_after_disruption = remaining_capacity,
  capacity_loss_fraction = lost_capacity / baseline_capacity,
  governance_warning = paste(
    "Infrastructure network results depend on asset definitions, edge definitions, layer boundaries,",
    "capacity units, dependency rules, hazard scenarios, operating conditions, data provenance,",
    "security constraints, and social vulnerability interpretation."
  )
)

layer_summary <- aggregate(
  baseline_capacity ~ layer,
  data = assets,
  FUN = sum
)

dir.create("outputs/tables", recursive = TRUE, showWarnings = FALSE)

write.csv(audit_record, "outputs/tables/r_infrastructure_network_audit.csv", row.names = FALSE)
write.csv(assets, "outputs/tables/r_infrastructure_assets.csv", row.names = FALSE)
write.csv(edges, "outputs/tables/r_infrastructure_edges.csv", row.names = FALSE)
write.csv(layer_summary, "outputs/tables/r_infrastructure_layer_summary.csv", row.names = FALSE)

print(audit_record)

This R workflow keeps infrastructure layers, capacity summaries, dependency edges, and scenario assumptions visible.

Back to top ↑

Haskell Workflow: Typed Infrastructure Records

Haskell can represent infrastructure-network audit output as typed records, keeping asset, dependency, disruption, and governance assumptions attached to the summary.

module Main where

data InfrastructureNetworkAudit = InfrastructureNetworkAudit
  { networkName :: String
  , nodeCount :: Int
  , edgeCount :: Int
  , layerCount :: Int
  , criticalAssetCount :: Int
  , interdependencyEdgeCount :: Int
  , totalBaselineCapacity :: Double
  , disruptedAsset :: String
  , remainingCapacityAfterDisruption :: Double
  , capacityLossFraction :: Double
  , governanceWarning :: String
  } deriving (Show)

buildAudit :: InfrastructureNetworkAudit
buildAudit =
  InfrastructureNetworkAudit
    "synthetic_multilayer_infrastructure_network"
    6
    7
    6
    5
    3
    400.0
    "power_substation"
    160.0
    0.60
    "Infrastructure network results depend on asset definitions, edge definitions, layer boundaries, capacity units, dependency rules, hazard scenarios, operating conditions, data provenance, security constraints, and social vulnerability interpretation."

main :: IO ()
main =
  print buildAudit

The typed record helps prevent infrastructure metrics from being separated from their representation and governance assumptions.

Back to top ↑

SQL Workflow: Infrastructure Modeling Registry

SQL can document infrastructure-network assumptions when models support resilience planning, emergency management, asset management, capital planning, risk analysis, or public dashboards.

CREATE TABLE infrastructure_modeling_registry (
    assumption_key TEXT PRIMARY KEY,
    assumption_name TEXT NOT NULL,
    mathematical_role TEXT NOT NULL,
    systems_modeling_role TEXT NOT NULL,
    review_warning TEXT NOT NULL
);

INSERT INTO infrastructure_modeling_registry VALUES
(
  'asset_definition',
  'Asset definition',
  'Defines the nodes of the infrastructure graph.',
  'Determines what physical, functional, spatial, or institutional entities are represented.',
  'Changing asset definitions changes connectivity, criticality, and vulnerability metrics.'
);

INSERT INTO infrastructure_modeling_registry VALUES
(
  'edge_definition',
  'Edge definition',
  'Defines the relationships among infrastructure nodes.',
  'Determines whether edges represent physical links, flows, dependencies, access, control, or governance.',
  'Different edge meanings should not be mixed without documentation.'
);

INSERT INTO infrastructure_modeling_registry VALUES
(
  'layer_boundary',
  'Layer boundary',
  'Defines infrastructure layers in a multilayer network.',
  'Determines whether transportation, energy, water, communication, logistics, health, and institutional layers are separated or combined.',
  'Cross-layer dependency can be hidden if layers are collapsed.'
);

INSERT INTO infrastructure_modeling_registry VALUES
(
  'capacity_semantics',
  'Capacity semantics',
  'Defines capacity values on nodes or edges.',
  'Determines whether capacity means design rating, observed throughput, emergency capacity, degraded capacity, or service capability.',
  'Capacity values require units, time scale, and provenance.'
);

INSERT INTO infrastructure_modeling_registry VALUES
(
  'dependency_rule',
  'Dependency rule',
  'Defines how failure or degradation propagates across links.',
  'Supports cascading-failure and interdependence analysis.',
  'Dependency strength and thresholds must be justified.'
);

INSERT INTO infrastructure_modeling_registry VALUES
(
  'scenario_design',
  'Scenario design',
  'Defines disruptions, hazards, demand shifts, and recovery assumptions.',
  'Supports stress testing and resilience analysis.',
  'Scenario choices determine what vulnerabilities become visible.'
);

INSERT INTO infrastructure_modeling_registry VALUES
(
  'recovery_priority',
  'Recovery priority',
  'Defines restoration objective and repair sequence logic.',
  'Determines how service recovery is valued over time.',
  'Recovery priorities can encode equity, economic, institutional, or political assumptions.'
);

INSERT INTO infrastructure_modeling_registry VALUES
(
  'governance_review',
  'Governance review',
  'Defines provenance, security, accountability, and interpretation controls.',
  'Connects infrastructure metrics to responsible decision use.',
  'Infrastructure outputs can affect public investment, access, safety, and accountability.'
);

SELECT
    assumption_name,
    mathematical_role,
    systems_modeling_role,
    review_warning
FROM infrastructure_modeling_registry
ORDER BY assumption_key;

This registry keeps infrastructure modeling tied to asset definitions, edge meanings, layer boundaries, capacity semantics, dependency rules, scenario design, recovery priorities, and governance.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible mathematical-modeling workspace. It supports infrastructure-network audits, asset registries, edge registries, layer summaries, capacity diagnostics, dependency checks, disruption scenarios, SQL governance tables, generated outputs, advanced mathematical audit reports, and reusable calculator scripts.

Back to top ↑

Interpretive Limits and Responsible Use

Infrastructure network models are powerful because they make connected assets, flows, dependencies, capacities, bottlenecks, and recovery pathways visible. They can support maintenance planning, emergency preparedness, capital investment, climate adaptation, logistics, service continuity, and public-sector decision-making. Their limits arise because infrastructure systems are not merely graphs. They are physical, operational, social, institutional, political, financial, ecological, and historical systems.

A high-centrality asset is not automatically the highest public priority. A minimum cut is not automatically the most urgent investment. A redundant path in a graph may not be usable under real operating constraints. A capacity value may reflect design assumptions rather than current condition. A disruption scenario may omit social vulnerability, workforce limits, supply shortages, cyber dependencies, jurisdictional conflicts, or community-level impacts.

Responsible use requires documenting asset definitions, edge definitions, network layers, capacity meanings, demand assumptions, dependency rules, scenario choices, recovery priorities, data provenance, security limits, uncertainty, and social consequences. Infrastructure network models should clarify dependence and vulnerability, not convert public systems into opaque technical scores divorced from accountability.

Back to top ↑

Related Articles

• What Is Linear Algebra for Systems Modeling?
• Network Adjacency Matrices
• Incidence Structure and Graph Representation
• Graph Theory Foundations for Systems Modeling
• PageRank and Network Influence Models
• Network Flow Modeling
• Flow, Connectivity, and System Vulnerability
• Control Systems Modeling
• Linear Dynamical Systems
• Matrix Differential Equations
• Stability Analysis with Eigenvalues
• Markov Chains and Transition Matrices
• Long-Run Behavior in State Transition Systems
• Linear Algebra for Systems Modeling
• Mathematical Modeling
• Systems Modeling
• Algorithms & Computational Reasoning
• Scientific Computing for Systems Modeling

Back to top ↑

Further Reading

• Ahuja, R.K., Magnanti, T.L. and Orlin, J.B. (1993) Network Flows: Theory, Algorithms, and Applications. Upper Saddle River, NJ: Prentice Hall. Available at: https://mitmgmtfaculty.mit.edu/jorlin/network-flows/.
• Barabási, A.-L. (2016) Network Science. Cambridge: Cambridge University Press. Available at: https://networksciencebook.com/.
• Buldyrev, S.V., Parshani, R., Paul, G., Stanley, H.E. and Havlin, S. (2010) ‘Catastrophic cascade of failures in interdependent networks’, Nature, 464, pp. 1025–1028. Available at: https://doi.org/10.1038/nature08932.
• Johansson, J. and Hassel, H. (2010) ‘An approach for modelling interdependent infrastructures in the context of vulnerability analysis’, Reliability Engineering & System Safety, 95(12), pp. 1335–1344. Available at: https://doi.org/10.1016/j.ress.2010.06.010.
• Newman, M.E.J. (2018) Networks. 2nd edn. Oxford: Oxford University Press. Available at: https://global.oup.com/academic/product/networks-9780198805090.
• Ouyang, M. (2014) ‘Review on modeling and simulation of interdependent critical infrastructure systems’, Reliability Engineering & System Safety, 121, pp. 43–60. Available at: https://doi.org/10.1016/j.ress.2013.06.040.
• Rinaldi, S.M., Peerenboom, J.P. and Kelly, T.K. (2001) ‘Identifying, understanding, and analyzing critical infrastructure interdependencies’, IEEE Control Systems Magazine, 21(6), pp. 11–25. Available at: https://doi.org/10.1109/37.969131.
• U.S. Cybersecurity and Infrastructure Security Agency (n.d.) Critical Infrastructure Sectors. Available at: https://www.cisa.gov/topics/critical-infrastructure-security-and-resilience/critical-infrastructure-sectors.
• NetworkX Developers (n.d.) NetworkX Documentation. Available at: https://networkx.org/documentation/stable/.
• SciPy Developers (n.d.) Sparse Arrays: scipy.sparse. SciPy Documentation. Available at: https://docs.scipy.org/doc/scipy/reference/sparse.html.

Back to top ↑

References

• Ahuja, R.K., Magnanti, T.L. and Orlin, J.B. (1993) Network Flows: Theory, Algorithms, and Applications. Upper Saddle River, NJ: Prentice Hall. Available at: https://mitmgmtfaculty.mit.edu/jorlin/network-flows/.
• Barabási, A.-L. (2016) Network Science. Cambridge: Cambridge University Press. Available at: https://networksciencebook.com/.
• Buldyrev, S.V., Parshani, R., Paul, G., Stanley, H.E. and Havlin, S. (2010) ‘Catastrophic cascade of failures in interdependent networks’, Nature, 464, pp. 1025–1028. Available at: https://doi.org/10.1038/nature08932.
• Johansson, J. and Hassel, H. (2010) ‘An approach for modelling interdependent infrastructures in the context of vulnerability analysis’, Reliability Engineering & System Safety, 95(12), pp. 1335–1344. Available at: https://doi.org/10.1016/j.ress.2010.06.010.
• Newman, M.E.J. (2018) Networks. 2nd edn. Oxford: Oxford University Press. Available at: https://global.oup.com/academic/product/networks-9780198805090.
• NetworkX Developers (n.d.) NetworkX Documentation. Available at: https://networkx.org/documentation/stable/.
• Ouyang, M. (2014) ‘Review on modeling and simulation of interdependent critical infrastructure systems’, Reliability Engineering & System Safety, 121, pp. 43–60. Available at: https://doi.org/10.1016/j.ress.2013.06.040.
• Rinaldi, S.M., Peerenboom, J.P. and Kelly, T.K. (2001) ‘Identifying, understanding, and analyzing critical infrastructure interdependencies’, IEEE Control Systems Magazine, 21(6), pp. 11–25. Available at: https://doi.org/10.1109/37.969131.
• SciPy Developers (n.d.) Sparse Arrays: scipy.sparse. SciPy Documentation. Available at: https://docs.scipy.org/doc/scipy/reference/sparse.html.
• U.S. Cybersecurity and Infrastructure Security Agency (n.d.) Critical Infrastructure Sectors. Available at: https://www.cisa.gov/topics/critical-infrastructure-security-and-resilience/critical-infrastructure-sectors.

Back to top ↑