Case Study: Infrastructure Interdependence: How Linear Algebra Models Cascading Risk Across Systems

Last Updated July 6, 2026

Infrastructure Interdependence shows how linear algebra can model connected infrastructure systems whose risks do not stay inside one sector. Power, water, transportation, telecommunications, health services, fuel, logistics, finance, food systems, emergency response, and digital platforms depend on one another through physical, cyber, geographic, operational, economic, and institutional relationships.

This article continues Part X of the Linear Algebra for Systems Modeling series by applying network, matrix, and systems concepts to infrastructure interdependence: dependency matrices, multilayer networks, adjacency blocks, coupling matrices, flow constraints, service disruption, cascading failure, redundancy, vulnerability, robustness, sensitivity analysis, scenario stress testing, recovery priorities, evidence boundaries, uncertainty, governance, and responsible interpretation.

The central modeling question is not only “Which infrastructure assets are connected?” It is “How can disruptions move across systems, which dependencies matter most, and what can the model responsibly say before public decisions are made?”

Infrastructure systems rarely fail in isolation. A power disruption can affect water pumping, communications, hospitals, fuel distribution, traffic control, logistics, cooling, payment systems, and emergency response. A transportation disruption can slow repair crews, fuel delivery, medical access, supply chains, and food distribution. A communications disruption can weaken coordination across every other sector.

Linear algebra helps represent these relationships as matrices. A dependency matrix can encode how much one sector depends on another. A block adjacency matrix can represent multiple infrastructure layers. A coupling matrix can represent cross-sector effects. A state vector can record service levels. Matrix multiplication can propagate disruption or recovery across the system. But the model must be interpreted carefully because real infrastructure includes geography, time, behavior, redundancy, capacity, institutional coordination, uncertainty, and uneven consequences.

Why Infrastructure Interdependence Matters

Infrastructure interdependence matters because disruptions can travel across systems. A failure in one sector can become a service problem, safety problem, economic problem, governance problem, or public health problem elsewhere. The system’s risk is therefore not only the sum of individual asset risks. It is shaped by dependencies among assets, sectors, regions, institutions, and recovery capacities.

Linear algebra is useful because interdependence is relational. A dependency matrix can show which sectors rely on which other sectors. A state vector can show current service levels. A propagation matrix can show how disruption may spread. A recovery matrix can show which interventions improve downstream service.

Infrastructure interdependence modeling is most useful when it makes hidden dependencies visible. It is most dangerous when it turns uncertain dependencies into false certainty.

Back to top ↑

Case Study Framing

This case study uses a small synthetic infrastructure system with five sectors: power, water, communications, transportation, and health services. Each sector has a service level between zero and one. A dependency matrix records how much each sector relies on others. A disruption scenario reduces power service, and the model examines possible downstream effects.

The case asks:

• Which sectors are directly and indirectly affected by a power disruption?
• Which dependencies create the largest downstream service loss?
• How does interdependence change recovery priorities?
• Which outputs are robust under sensitivity checks?
• What must be documented before the model informs planning?

The synthetic case is deliberately small so the linear algebra remains visible. The modeling discipline scales to more complex infrastructure networks only when data, validation, and governance scale with it.

Back to top ↑

Infrastructure as a System of Systems

Infrastructure is a system of systems because each sector operates internally while also depending on other sectors. Water systems require power for pumping and treatment. Communications systems require power and physical access. Hospitals require power, water, communications, transportation, medical supplies, staffing, fuel, and digital systems. Transportation systems require fuel, power, communications, and maintenance logistics.

The modeling challenge is that each sector can be represented at different levels: assets, facilities, regions, operators, services, flows, customers, or functions. A sector-level matrix may clarify broad dependency patterns while hiding asset-level bottlenecks. An asset-level model may clarify local vulnerabilities while becoming data-intensive and difficult to validate.

The right level depends on the modeling purpose. Resilience planning, emergency response, infrastructure investment, equity review, and systems research each need different representations.

Back to top ↑

Dependency Matrices

A dependency matrix records how much one infrastructure layer depends on another. If \(D_{ij}\) measures how much sector \(i\) depends on sector \(j\), then rows can be read as dependency profiles and columns can be read as dependency burdens placed on a sector by others.

The meaning of each entry must be defined. A dependency weight may represent physical necessity, operational reliance, probability of disruption transfer, expected service loss, expert judgment, historical evidence, or scenario-based sensitivity. These meanings should not be mixed without documentation.

A dependency matrix should be treated as a documented representation of assumptions, evidence, and uncertainty, not as a neutral map of reality.

Back to top ↑

Multilayer Network Representation

Infrastructure interdependence can be represented as a multilayer network. Each layer contains nodes and edges for one infrastructure sector, while cross-layer edges represent dependencies between sectors.

In a larger model, blocks may represent power-power, water-water, communication-communication, power-water, transportation-health, fuel-transportation, or other cross-sector connections. This structure makes interdependence visible while preserving the identity of each layer.

Multilayer models are powerful because they keep sector identity and cross-sector coupling together. They are risky when the off-diagonal blocks contain uncertain or poorly defined dependencies.

Back to top ↑

Coupling Matrices and Cross-Sector Effects

A coupling matrix represents how a change in one sector may affect another. If \(\mathbf{x}\) is a vector of service disruptions, a coupling matrix \(C\) can approximate how disruptions propagate across sectors.

This is a strong simplification. Real coupling may be nonlinear, delayed, threshold-dependent, geographically constrained, capacity-limited, or mediated by emergency response. Still, a coupling matrix can be valuable for scenario exploration and sensitivity analysis.

Coupling matrices should be communicated as scenario tools unless validated against observed disruptions and operational data.

Back to top ↑

State Vectors and Service Levels

A state vector records service levels, disruption levels, demand levels, capacity levels, or recovery levels across sectors. In this case study, service levels range from zero to one, where one means fully available and zero means unavailable under the model definition.

Service-level vectors are useful for computation, but their meaning must be defined carefully. A value of 0.8 may mean eighty percent of customers served, eighty percent of capacity available, eighty percent of service quality, or a qualitative score converted to a number. These meanings are not interchangeable.

State vectors make complex infrastructure conditions computable. Responsible modeling keeps their definitions visible.

Back to top ↑

Cascading Disruption

Cascading disruption occurs when one failure produces downstream failures in connected systems. Linear algebra can approximate this through repeated propagation, matrix powers, or iterative state updates.

This approach can clarify possible paths of disruption. But it can also exaggerate or understate real cascades if coupling is nonlinear, time-varying, threshold-based, or mitigated by operator action.

Cascade analysis should be treated as structured scenario exploration unless supported by validated operational models.

Back to top ↑

Redundancy and Robustness

Redundancy means that a system has substitutes, backups, alternative paths, spare capacity, reserves, or operational workarounds. Robustness means that the system can absorb disruption without unacceptable service loss. Linear algebra can support redundancy analysis by comparing alternative paths, backup dependencies, spare capacity, and scenario outcomes.

Robustness is not only a property of the matrix. It depends on physical resources, time, people, institutions, maintenance, and governance.

Back to top ↑

Criticality and Prioritization

Infrastructure models often support prioritization: which assets to protect, repair, harden, inspect, or restore first. Linear algebra can help identify sectors or assets with high dependency burden, high downstream effect, low redundancy, high centrality, or large recovery leverage.

Prioritization is never purely technical. It involves ethical, legal, economic, equity, safety, and public-interest judgment. A model can inform priority, but it should not silently decide priority.

Responsible prioritization keeps mathematical rankings connected to explicit values, evidence, uncertainty, and accountability.

Back to top ↑

Geography, Time, and Capacity

Sector-level dependency matrices can hide three important infrastructure realities: geography, time, and capacity. A dependency may exist only in a particular location. A disruption may propagate after a delay. A service may operate normally until capacity is exceeded, then fail sharply.

Infrastructure interdependence models are strongest when they show what they include and what they leave out.

Back to top ↑

Uncertainty and Data Quality

Infrastructure dependency data can be incomplete, sensitive, proprietary, outdated, aggregated, confidential, or based on expert judgment. This makes uncertainty central to responsible interpretation.

Uncertainty should travel with the model output. A dependency score without uncertainty context can be misleading.

Back to top ↑

Equity and Distributional Risk

Infrastructure disruptions do not affect everyone equally. The same modeled service loss can have different consequences depending on neighborhood, income, disability, age, health status, mobility, language access, housing quality, digital access, and institutional support.

A sector-level interdependence model may show aggregate service disruption while hiding distributional harm. Responsible modeling should connect system-level metrics to people, places, and unequal exposure where the use case requires it.

Equity analysis is not an optional add-on when infrastructure models inform public decisions. It helps prevent technical averages from masking unequal consequences.

Back to top ↑

Mathematical Deepening

This section adds a more formal layer. Infrastructure interdependence modeling connects dependency matrices, block adjacency matrices, coupling matrices, state vectors, propagation models, sensitivity tests, recovery vectors, scenario ensembles, uncertainty records, and responsible interpretation.

Back to top ↑

Back to top ↑

Computation and Reproducible Workflows

Computational workflows for infrastructure interdependence should document sector definitions, dependency meanings, dependency weights, data provenance, uncertainty flags, state-vector definitions, disruption scenarios, cascade assumptions, recovery assumptions, sensitivity tests, validation evidence, equity review, governance status, and responsible-use warnings.

The companion repository treats infrastructure interdependence as an auditable modeling workflow. 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 dependency-matrix construction, scenario propagation, sensitivity review, and responsible interpretation.

For this article, the computational examples build a small sector dependency matrix, apply a power-disruption scenario, estimate one-step downstream service loss, compute dependency burden, and export a governance-ready audit report.

Back to top ↑

Python Workflow: Infrastructure Interdependence Audit

The Python workflow below creates a synthetic five-sector infrastructure dependency matrix, applies a disruption scenario, estimates downstream loss, identifies the highest dependency-burden sector, and exports a structured audit record.

from __future__ import annotations

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


@dataclass(frozen=True)
class InfrastructureInterdependenceAudit:
    workflow_name: str
    scenario_name: str
    sector_count: int
    initial_shock_sector: str
    initial_shock_magnitude: float
    highest_dependency_burden_sector: str
    highest_dependency_burden: float
    largest_downstream_loss_sector: str
    largest_downstream_loss: float
    total_estimated_downstream_loss: float
    sensitivity_warning: str
    interpretation_warning: str


SECTORS = ["power", "water", "communications", "transportation", "health"]

# D[i][j] = dependency of sector i on sector j.
# Rows depend on columns.
DEPENDENCY = [
    [0.00, 0.05, 0.10, 0.10, 0.00],  # power
    [0.70, 0.00, 0.10, 0.20, 0.00],  # water
    [0.60, 0.00, 0.00, 0.10, 0.00],  # communications
    [0.30, 0.00, 0.20, 0.00, 0.05],  # transportation
    [0.80, 0.50, 0.40, 0.30, 0.00],  # health
]


def matvec(matrix: list[list[float]], vector: list[float]) -> list[float]:
    return [sum(row[j] * vector[j] for j in range(len(vector))) for row in matrix]


def column_sums(matrix: list[list[float]]) -> list[float]:
    n = len(matrix)
    return [sum(matrix[i][j] for i in range(n)) for j in range(n)]


def build_audit() -> InfrastructureInterdependenceAudit:
    initial_disruption = [0.0 for _ in SECTORS]
    power_index = SECTORS.index("power")
    initial_disruption[power_index] = 0.40

    downstream_loss = matvec(DEPENDENCY, initial_disruption)
    burden = column_sums(DEPENDENCY)

    highest_burden_index = max(range(len(SECTORS)), key=lambda i: burden[i])
    largest_loss_index = max(range(len(SECTORS)), key=lambda i: downstream_loss[i])

    return InfrastructureInterdependenceAudit(
        workflow_name="infrastructure_interdependence_audit",
        scenario_name="synthetic_power_disruption_dependency_scenario",
        sector_count=len(SECTORS),
        initial_shock_sector="power",
        initial_shock_magnitude=0.40,
        highest_dependency_burden_sector=SECTORS[highest_burden_index],
        highest_dependency_burden=round(burden[highest_burden_index], 12),
        largest_downstream_loss_sector=SECTORS[largest_loss_index],
        largest_downstream_loss=round(downstream_loss[largest_loss_index], 12),
        total_estimated_downstream_loss=round(sum(downstream_loss), 12),
        sensitivity_warning=(
            "Dependency weights are scenario assumptions. Results should be compared across alternative "
            "weights, redundancy assumptions, time delays, and recovery capacities."
        ),
        interpretation_warning=(
            "This one-step linear cascade estimate supports exploratory planning only. It does not predict "
            "real failure behavior without geography, capacity, timing, backup systems, operational response, "
            "validation evidence, and equity review."
        ),
    )


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)
    (output_dir / "reports").mkdir(parents=True, exist_ok=True)

    audit = build_audit()
    row = asdict(audit)

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

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

    report = [
        "# Infrastructure Interdependence Audit",
        "",
        f"- Workflow: {audit.workflow_name}",
        f"- Scenario: {audit.scenario_name}",
        f"- Sector count: {audit.sector_count}",
        f"- Initial shock sector: {audit.initial_shock_sector}",
        f"- Initial shock magnitude: {audit.initial_shock_magnitude}",
        f"- Highest dependency-burden sector: {audit.highest_dependency_burden_sector}",
        f"- Highest dependency burden: {audit.highest_dependency_burden}",
        f"- Largest downstream-loss sector: {audit.largest_downstream_loss_sector}",
        f"- Largest downstream loss: {audit.largest_downstream_loss}",
        f"- Total estimated downstream loss: {audit.total_estimated_downstream_loss}",
        "",
        audit.sensitivity_warning,
        "",
        audit.interpretation_warning,
    ]

    (output_dir / "reports" / "infrastructure_interdependence_audit.md").write_text(
        "\\n".join(report) + "\\n",
        encoding="utf-8",
    )


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

This workflow keeps the dependency matrix, disruption scenario, sensitivity warning, and interpretation boundary together in one auditable artifact.

Back to top ↑

R Workflow: Dependency and Cascade Review

R can support the same case study by constructing a dependency matrix, applying an initial shock, computing downstream service loss, and exporting a responsible modeling audit.

sectors <- c("power", "water", "communications", "transportation", "health")

dependency <- matrix(
  c(
    0.00, 0.05, 0.10, 0.10, 0.00,
    0.70, 0.00, 0.10, 0.20, 0.00,
    0.60, 0.00, 0.00, 0.10, 0.00,
    0.30, 0.00, 0.20, 0.00, 0.05,
    0.80, 0.50, 0.40, 0.30, 0.00
  ),
  nrow = length(sectors),
  byrow = TRUE
)

rownames(dependency) <- sectors
colnames(dependency) <- sectors

initial_disruption <- rep(0, length(sectors))
names(initial_disruption) <- sectors
initial_disruption["power"] <- 0.40

downstream_loss <- dependency %*% initial_disruption
dependency_burden <- colSums(dependency)

audit_record <- data.frame(
  workflow_name = "infrastructure_interdependence_audit",
  scenario_name = "synthetic_power_disruption_dependency_scenario",
  sector_count = length(sectors),
  initial_shock_sector = "power",
  initial_shock_magnitude = 0.40,
  highest_dependency_burden_sector = names(which.max(dependency_burden)),
  highest_dependency_burden = max(dependency_burden),
  largest_downstream_loss_sector = rownames(downstream_loss)[which.max(downstream_loss)],
  largest_downstream_loss = max(downstream_loss),
  total_estimated_downstream_loss = sum(downstream_loss),
  sensitivity_warning = paste(
    "Dependency weights are scenario assumptions.",
    "Results should be compared across alternative weights, redundancy assumptions,",
    "time delays, and recovery capacities."
  ),
  interpretation_warning = paste(
    "This one-step linear cascade estimate supports exploratory planning only.",
    "It does not predict real failure behavior without geography, capacity, timing,",
    "backup systems, operational response, validation evidence, and equity review."
  )
)

dir.create("outputs/tables", recursive = TRUE, showWarnings = FALSE)
write.csv(
  audit_record,
  "outputs/tables/r_infrastructure_interdependence_audit.csv",
  row.names = FALSE
)

print(audit_record)

This R workflow emphasizes that dependency weights and cascade estimates should be exported with assumptions and warnings, not only numerical outputs.

Back to top ↑

Haskell Workflow: Typed Infrastructure Audit

Haskell can represent infrastructure interdependence review as a typed record, preserving scenario details, dependency-burden findings, downstream-loss estimates, and interpretation warnings.

module Main where

data InfrastructureInterdependenceAudit = InfrastructureInterdependenceAudit
  { workflowName :: String
  , scenarioName :: String
  , sectorCount :: Int
  , initialShockSector :: String
  , initialShockMagnitude :: Double
  , highestDependencyBurdenSector :: String
  , highestDependencyBurden :: Double
  , largestDownstreamLossSector :: String
  , largestDownstreamLoss :: Double
  , totalEstimatedDownstreamLoss :: Double
  , sensitivityWarning :: String
  , interpretationWarning :: String
  } deriving (Show)

buildAudit :: InfrastructureInterdependenceAudit
buildAudit =
  InfrastructureInterdependenceAudit
    "infrastructure_interdependence_audit"
    "synthetic_power_disruption_dependency_scenario"
    5
    "power"
    0.40
    "power"
    2.40
    "health"
    0.32
    0.96
    "Dependency weights are scenario assumptions and should be compared across alternative weights, redundancy assumptions, time delays, and recovery capacities."
    "This one-step linear cascade estimate supports exploratory planning only and does not predict real failure behavior without validation."

main :: IO ()
main =
  print buildAudit

The typed record keeps the scenario, computed result, and responsible-use warning attached to the same modeling artifact.

Back to top ↑

SQL Workflow: Infrastructure Governance Registry

SQL can document infrastructure interdependence assumptions when dependency models support repositories, dashboards, audits, planning workflows, or institutional decision systems.

CREATE TABLE infrastructure_interdependence_governance_registry (
    governance_key TEXT PRIMARY KEY,
    governance_name TEXT NOT NULL,
    modeling_role TEXT NOT NULL,
    review_requirement TEXT NOT NULL,
    responsible_use_warning TEXT NOT NULL
);

INSERT INTO infrastructure_interdependence_governance_registry VALUES
(
  'sector_definition',
  'Sector definition',
  'Defines the infrastructure layers represented by rows and columns.',
  'Document whether sectors represent services, assets, operators, regions, facilities, or institutional functions.',
  'Sector-level models can hide asset-level bottlenecks and uneven service impacts.'
);

INSERT INTO infrastructure_interdependence_governance_registry VALUES
(
  'dependency_semantics',
  'Dependency semantics',
  'Defines what cross-sector reliance means.',
  'State whether dependencies are physical, cyber, geographic, operational, economic, institutional, or mixed.',
  'Different dependency types should not be mixed without documentation.'
);

INSERT INTO infrastructure_interdependence_governance_registry VALUES
(
  'weight_evidence',
  'Weight evidence',
  'Defines how dependency weights were estimated.',
  'Record whether weights come from operational data, historical events, expert judgment, simulations, or scenario assumptions.',
  'Judgment-based weights require sensitivity testing and uncertainty flags.'
);

INSERT INTO infrastructure_interdependence_governance_registry VALUES
(
  'cascade_assumption',
  'Cascade assumption',
  'Defines how disruption is propagated across sectors.',
  'Document whether the model uses one-step, multi-step, linear, threshold, delayed, or nonlinear propagation.',
  'Linear cascade estimates should not be treated as predictions without validation.'
);

INSERT INTO infrastructure_interdependence_governance_registry VALUES
(
  'redundancy_review',
  'Redundancy review',
  'Records backups, alternative paths, spare capacity, reserves, and workarounds.',
  'Document backup duration, fuel, access, capacity, staffing, and geographic availability.',
  'Redundancy on paper may not be usable during regional disruptions.'
);

INSERT INTO infrastructure_interdependence_governance_registry VALUES
(
  'equity_review',
  'Equity review',
  'Connects service loss to people, places, and uneven vulnerability.',
  'Review whether aggregate sector losses hide concentrated impacts across communities.',
  'Average service loss can understate harm to vulnerable populations.'
);

INSERT INTO infrastructure_interdependence_governance_registry VALUES
(
  'validation_status',
  'Validation status',
  'Records whether modeled dependencies and cascades have evidence support.',
  'Compare results with historical disruptions, exercises, operational records, and domain expertise.',
  'Unvalidated cascade scenarios should be communicated as exploratory.'
);

INSERT INTO infrastructure_interdependence_governance_registry VALUES
(
  'decision_boundary',
  'Decision boundary',
  'Defines what the model can and cannot support.',
  'Attach interpretation limits, uncertainty notes, review status, and stop-use conditions to outputs.',
  'The model should inform public decisions, not replace accountable institutional judgment.'
);

SELECT
    governance_name,
    modeling_role,
    review_requirement,
    responsible_use_warning
FROM infrastructure_interdependence_governance_registry
ORDER BY governance_key;

This registry keeps sector definitions, dependency meanings, weight evidence, cascade assumptions, redundancy, equity, validation, and decision boundaries visible in the modeling workflow.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible infrastructure interdependence modeling workspace. It supports dependency matrix construction, sector-state vectors, disruption scenarios, one-step cascade estimates, dependency burden metrics, recovery leverage review, sensitivity warnings, governance tables, generated artifacts, advanced audit reports, and reusable calculator scripts.

Back to top ↑

Interpretive Limits and Responsible Use

Infrastructure interdependence modeling is powerful because it reveals dependencies that are often invisible in sector-by-sector planning. It can show how power, water, communications, transportation, health, logistics, fuel, and other systems support one another. It can help identify cascade pathways, recovery leverage, redundancy gaps, and fragile assumptions.

Its limits are equally important. Dependency matrices simplify real assets, operations, institutions, geography, timing, behavior, capacity, and uncertainty. Linear propagation can miss thresholds, delays, operator adaptation, emergency response, and nonlinear escalation. Sector-level averages can hide concentrated harm. Rankings can appear more precise than the evidence supports.

Responsible infrastructure interdependence modeling requires documented sector definitions, dependency meanings, weight evidence, scenario assumptions, uncertainty flags, validation status, redundancy review, equity review, governance context, and interpretation boundaries. A useful model does not claim to predict everything. It clarifies where dependencies deserve attention, where assumptions are fragile, and where accountable human judgment remains necessary.

Back to top ↑

Related Articles

• Case Study: Network System Modeling
• Case Study: Economic Input-Output Analysis
• Network Adjacency Matrices
• Incidence Structure and Graph Representation
• Graph Theory Foundations for Systems Modeling
• Network Flow Modeling
• Infrastructure Network Models
• Flow, Connectivity, and System Vulnerability
• State Transition Models and System Dynamics
• Representation Choices and Model Assumptions
• Scaling, Normalization, and Comparative Structure
• When Linear Models Clarify and When They Distort
• Interpretation, Approximation, and Responsible Mathematical Modeling
• Systems Modeling
• Mathematical Modeling
• Scientific Computing for Systems Modeling

Back to top ↑

Further Reading

• Buldyrev, S.V. et al. (2010) ‘Catastrophic cascade of failures in interdependent networks’, Nature, 464, pp. 1025–1028. Available at: https://doi.org/10.1038/nature08932.
• Haimes, Y.Y. (2009) ‘On the definition of resilience in systems’, Risk Analysis, 29(4), pp. 498–501. Available at: https://doi.org/10.1111/j.1539-6924.2009.01216.x.
• 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.
• Little, R.G. (2002) ‘Controlling cascading failure: understanding the vulnerabilities of interconnected infrastructures’, Journal of Urban Technology, 9(1), pp. 109–123. Available at: https://doi.org/10.1080/106307302317379855.
• 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.
• National Academies of Sciences, Engineering, and Medicine (2012) Disaster Resilience: A National Imperative. Washington, DC: National Academies Press. Available at: https://doi.org/10.17226/13457.
• Newman, M.E.J. (2018) Networks. 2nd edn. Oxford: Oxford University Press. Available at: https://global.oup.com/academic/product/networks-9780198805090.
• Pescaroli, G. and Alexander, D. (2016) ‘Critical infrastructure, panarchies and the vulnerability paths of cascading disasters’, Natural Hazards, 82, pp. 175–192. Available at: https://doi.org/10.1007/s11069-016-2186-3.
• Vespignani, A. (2010) ‘Complex networks: the fragility of interdependency’, Nature, 464, pp. 984–985. Available at: https://doi.org/10.1038/464984a.

Back to top ↑

References

• Buldyrev, S.V. et al. (2010) ‘Catastrophic cascade of failures in interdependent networks’, Nature, 464, pp. 1025–1028. Available at: https://doi.org/10.1038/nature08932.
• Haimes, Y.Y. (2009) ‘On the definition of resilience in systems’, Risk Analysis, 29(4), pp. 498–501. Available at: https://doi.org/10.1111/j.1539-6924.2009.01216.x.
• 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.
• Little, R.G. (2002) ‘Controlling cascading failure: understanding the vulnerabilities of interconnected infrastructures’, Journal of Urban Technology, 9(1), pp. 109–123. Available at: https://doi.org/10.1080/106307302317379855.
• 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.
• National Academies of Sciences, Engineering, and Medicine (2012) Disaster Resilience: A National Imperative. Washington, DC: National Academies Press. Available at: https://doi.org/10.17226/13457.
• Newman, M.E.J. (2018) Networks. 2nd edn. Oxford: Oxford University Press. Available at: https://global.oup.com/academic/product/networks-9780198805090.
• Pescaroli, G. and Alexander, D. (2016) ‘Critical infrastructure, panarchies and the vulnerability paths of cascading disasters’, Natural Hazards, 82, pp. 175–192. Available at: https://doi.org/10.1007/s11069-016-2186-3.
• Vespignani, A. (2010) ‘Complex networks: the fragility of interdependency’, Nature, 464, pp. 984–985. Available at: https://doi.org/10.1038/464984a.

Back to top ↑