DEXPI 2.0 Extended Semantic Schema & CycloneDX 1.6 Hardware BOM Joint Graph Validation

J. McKenney

This paper belongs to the WG-05-CAD DEXPI and CycloneDX standards working group as a standalone treatment. It draws directly on two working-group siblings by the same author: the DEXPI 2.0 / CycloneDX 4-BOM standards introduction, and the Frontier AI Hardware Security and Platform Assurance Framework.

Licence: CC BY 4.0. 17 September 2026.

Executive Abstract#

Engineers who design physical plant, such as power stations, chemical refineries, and large data centres, describe how pipes, valves, and equipment connect and operate with one set of tools. Cybersecurity teams describe the software, firmware, and hardware inside that same plant with a completely different set. The two descriptions are kept apart, so no one can ask a single question that spans both, such as how much physical damage a specific software vulnerability could cause.

This paper joins the two into one combined model, so each can be checked against the other. It sets three rules a joined model must obey to be trusted: any safety-critical physical component must trace back to a verifiable hardware root of trust, and a simulated cyberattack cannot violate basic physical laws such as conservation of mass and energy.

On a model of a 250MW liquid-cooled data centre, the paper traces the full physical consequences of one known vulnerability in under a second, from the affected component out to the equipment it could endanger. A remote-code-execution flaw in the cooling valve controllers cut coolant to 64 GPU racks, and the model predicted GPU chips reaching their emergency shutdown temperature in 14.8 seconds.

Abstract#

Critical industrial infrastructure, from power generation and pharmaceutical plants to chemical refineries and hyperscale liquid-cooled computing facilities, is described by two disconnected ontologies. Physical and mechanical disciplines model facilities as continuous hydraulic, thermodynamic, and kinematic systems using CAD and P&ID standards, principally DEXPI 2.0 and ISO 15926-4. Cybersecurity and software disciplines model the same systems as discrete software, firmware, and hardware dependency graphs using Bills of Materials, standardized in OWASP CycloneDX 1.6+. Neither abstraction alone can compute the physical kinetic blast radius of a firmware vulnerability or the cyber attack surface introduced by a physical piping change. This treatise establishes the formal specification for the Unified Cyber-Physical Digital Twin Multigraph (G_CPDT), an attributed directed multigraph that binds continuous DEXPI P&ID topology to the discrete CycloneDX 1.6+ 5-BOM architecture (Hardware, Software, Operations, Cryptography, and Services BOMs). We define cross-domain binding morphisms, formulate three joint validation axioms (Grounded Actuation, Reachable Attestation, and Conservation Coherence), and implement a deterministic bidirectional graph traversal that computes physical thermal and hydraulic failure blast radii from silicon-level CVEs. On a 250MW liquid-cooled AI data centre model of 7,146 vertices and 14,890 edges, a CVSS 9.8 controller exploit resolved to full physical blast radius in 18.6 milliseconds.

1. The Architectural Divide Between CAD Topology and Cyber BOMs#

The design, operation, and security of modern high-hazard facilities are governed by two parallel, non-communicating engineering paradigms:

1. The Physical CAD / P&ID Domain: Mechanical, chemical, and process engineers represent plants as continuous differential-algebraic networks governed by physical conservation laws (mass, momentum, energy). Equipment specifications, nominal pipe bores, fluid viscosities, valve flow coefficients ($C_v$), and instrument tag names (e.g. FCV-101A, PMP-202B) are formalized using the Data Exchange in the Process Industry (DEXPI) specification, built upon ISO 15926-4. This domain models continuous physics but treats actuators, pumps, and sensors as passive electro-mechanical elements, oblivious to micro-controller firmware, operating system kernels, or network communication protocols.
2. The Cyber Bill of Materials Domain: Cybersecurity architects, compliance auditors, and software developers represent systems as discrete component dependency trees. Driven by statutory mandates such as the European Union Cyber Resilience Act (Regulation EU 2024/2847) and US Executive Order 14028, cybersecurity tools generate Bills of Materials (BOMs). OWASP CycloneDX 1.6+ has emerged as the premier cybersecurity-first standard, providing rich metadata spanning Software (SBOM), Hardware (HBOM), Operations (OBOM), Cryptography (CBOM), and Services (SaaSBOM). However, this domain treats components as flat inventory items, devoid of physical connectivity or thermodynamic context.

When these two domains operate in isolation, critical vulnerabilities fall into the structural seam:

• Blind Vulnerability Triage: A Security Operations Center (SOC) receives a critical Common Vulnerability Scoring System (CVSS 9.8) alert for an embedded Modbus RTU controller. Because the BOM lacks physical topological binding, security analysts cannot discern whether that controller governs a non-critical exterior louvre or the primary coolant injection valve of a nuclear reactor.
• Invisible Mechanical Expansion: A plant engineer replaces a worn mechanical control valve with an intelligent digital positioner featuring wireless HART and Bluetooth maintenance interfaces. Because CAD tools do not track digital attack surfaces, the physical upgrade inadvertently exposes the plant safety bus to unauthorized wireless exploitation without triggering a cybersecurity audit.

To close this structural gap, we define a mathematically unified graph representation and an automated validation engine that reconciles continuous mechanical engineering models with discrete cyber security bills of materials.

2. Mathematical Formulation of the Unified Graph ($\mathcal{G}_{\text{CPDT}}$)#

We formulate the Cyber-Physical Digital Twin as a unified attributed directed multigraph:

2.1 Vertex Partitioning#

The global vertex set $\mathcal{V}$ is partitioned into two disjoint, orthogonal subsets:

1. Physical Engineering Vertices ($\mathcal{V}_{\text{phys}}$): Derived from the DEXPI 2.0 XML tree: $$\mathcal{V}_{\text{phys}} = \mathcal{V}_{\text{equip}} \cup \mathcal{V}_{\text{pipe}} \cup \mathcal{V}_{\text{nozzle}} \cup \mathcal{V}_{\text{inst}}$$ where:
   • $\mathcal{V}_{\text{equip}}$: Major mechanical equipment (pumps, compressors, tanks, chillers, heat exchangers).
   • $\mathcal{V}_{\text{pipe}}$: Piping segments, headers, and branch lines carrying fluid or refrigerant.
   • $\mathcal{V}_{\text{nozzle}}$: Equipment connection points enforcing boundary flow continuity.
   • $\mathcal{V}_{\text{inst}}$: Instrumentation sensors (transmitters) and final control elements (actuators, positioners).
2. Cyber Component Vertices ($\mathcal{V}_{\text{cyber}}$): Derived from the CycloneDX 1.6+ 5-BOM model: $$\mathcal{V}_{\text{cyber}} = \mathcal{V}_{\text{hbom}} \cup \mathcal{V}_{\text{sbom}} \cup \mathcal{V}_{\text{obom}} \cup \mathcal{V}_{\text{cbom}} \cup \mathcal{V}_{\text{saas}}$$ where:
   • $\mathcal{V}_{\text{hbom}}$: Silicon hardware assets (Root of Trust, CPUs, Baseboard Management Controllers, PLC ASICs, physical network interfaces).
   • $\mathcal{V}_{\text{sbom}}$: Software assets (Real-Time Operating Systems, firmware binaries, control application logic, protocol libraries).
   • $\mathcal{V}_{\text{obom}}$: Operational configuration state (firewall rules, Modbus register maps, BACnet object configurations, systemd services).
   • $\mathcal{V}_{\text{cbom}}$: Cryptographic assets (certificates, private keys, symmetric ciphers, signature algorithms).
   • $\mathcal{V}_{\text{saas}}$: Service endpoints (cloud telemetry APIs, remote vendor diagnostic tunnels, historian replication links).

2.2 Edge Multigraph Partitioning#

The edge set $\mathcal{E}$ contains multiple directed and undirected relation types connecting intra-domain and inter-domain vertices:

• Fluid Edges ($\mathcal{E}_{\text{fluid}} \subset \mathcal{V}_{\text{phys}} \times \mathcal{V}_{\text{phys}}$): Directed hydraulic conduits representing fluid mass flow: $$e = (u, v) \in \mathcal{E}_{\text{fluid}} \implies \text{Flow}(u \to v) = \dot{m} > 0$$
• Electrical Power Edges ($\mathcal{E}_{\text{elec}} \subset \mathcal{V}_{\text{phys}} \times \mathcal{V}_{\text{phys}}$): Power delivery paths from switchgear to motor drives.
• Communication Edges ($\mathcal{E}_{\text{comm}} \subset \mathcal{V}_{\text{cyber}} \times \mathcal{V}_{\text{cyber}}$): Digital protocol conduits (Modbus TCP, BACnet/IP, PROFINET, OPC UA).
• Component Hierarchy Edges ($\mathcal{E}_{\text{hier}} \subset \mathcal{V}_{\text{cyber}} \times \mathcal{V}_{\text{cyber}}$): BOM dependency edges (dependsOn, contains, executesOn).
• Cross-Domain Binding Edges ($\mathcal{E}_{\text{bind}} \subset \mathcal{V}_{\text{cyber}} \times \mathcal{V}_{\text{phys}}$): The formal ontological bridge linking cyber control hardware to physical plant equipment.

3. Cross-Domain Binding Morphisms & Property Mapping#

To bind the continuous mechanical model to the discrete cyber model, we formalize the Equipment-BOM Binding Morphism $\Phi_{\text{bind}}$.

3.1 Tag-to-Ref Reconciliation#

Every physical equipment item in a DEXPI 2.0 model possesses an alphanumeric equipment tag complying with ISA-5.1 or DIN 2481:

In CycloneDX 1.6+, every component possesses a globally unique bom-ref attribute within the document namespace. To establish deterministic binding without fragile manual cross-reference tables, we define an extended CycloneDX property namespace:

{
  "type": "hardware",
  "name": "Intelligent Valve Positioner",
  "bom-ref": "hw-actuator-fcv-101a",
  "properties": [
    {
      "name": "eigenia:physical:tag",
      "value": "FCV-101A"
    },
    {
      "name": "eigenia:physical:dexpi_id",
      "value": "DEXPI_XML_Equip_98214"
    },
    {
      "name": "eigenia:physical:iso15926_class",
      "value": "http://posccaesar.org/rdl/RDS323561"
    }
  ]
}

The binding mapping $\Phi_{\text{bind}}: \mathcal{V}_{\text{hbom}} \to \mathcal{V}_{\text{phys}}$ is defined by:

When this condition is satisfied, a directed binding edge $e_{\text{bind}} = (h, p) \in \mathcal{E}_{\text{bind}}$ is instantiated in $\mathcal{G}_{\text{CPDT}}$ with attribute control_authority = true.

4. Axiomatic Joint Graph Validation Framework#

A naive union of two graphs produces semantic inconsistencies. To guarantee that $\mathcal{G}_{\text{CPDT}}$ is physically realizable, computationally solvable, and legally defensible for safety certifications (IEC 61508 / IEC 62443), the joint graph must satisfy three axiomatic validation rules.

Axiom 1: The Grounded Actuation Axiom#

Every controllable final element in the physical domain (modulating control valves, variable frequency drives, motorized dampers, trip circuit breakers) must be bound to at least one physical hardware controller in the cyber domain. Uncontrolled physical actuation represents an unverified orphan risk:

If $\Phi_{\text{bind}}^{-1}(p) = \emptyset$, the validation engine raises a Severity 1 Orphan Actuator Defect: the mechanical drawing asserts digital modulation, but the bill of materials contains no record of the controlling embedded silicon.

Axiom 2: The Reachable Attestation Axiom#

Every cyber asset that asserts control authority over a safety-critical physical component must have a verifiable, cryptographically traceable path in $\mathcal{E}_{\text{comm}}$ and $\mathcal{E}_{\text{hier}}$ originating from an attested Root of Trust (RoT):

where $\mathcal{V}_{\text{RoT}} \subset \mathcal{V}_{\text{hbom}}$ represents silicon roots of trust (e.g. Caliptra, TPM 2.0, or secure enclave elements). Components lacking a verifiable chain of custody cannot be trusted for safety interlock functions.

Axiom 3: The Conservation Coherence Axiom#

When a cyber component $c \in \mathcal{V}_{\text{cyber}}$ undergoes a state change (e.g. firmware compromise leading to forced shutdown or uncommanded 100 percent valve opening), the induced physical parameter perturbation must propagate across $\mathcal{E}_{\text{fluid}}$ and $\mathcal{E}_{\text{elec}}$ without violating physical conservation laws:

Any simulated cyber attack scenario whose induced boundary conditions violate Kirchhoff's laws or continuity equations is mathematically rejected as an unphysical artifact.

5. The Full-Spectrum 5-BOM Architecture in Industrial Systems#

OWASP CycloneDX 1.6+ provides five distinct BOM classes. We map each class to its exact operational role within the unified physical plant architecture:

5.1 Hardware BOM (HBOM)#

The HBOM captures physical silicon, board-level microarchitectures, and field-replaceable units (FRUs).

• Attributes: Manufacturer, Part Number, Serial Number, Silicon Revision, Root of Trust Type (TPM, Caliptra, ATECC608), JTAG Debug Lock State, Physical Anti-Tamper Coating.
• Physical Mapping: Binds to DEXPI equipment tag and cabinet rack physical location coordinates $(x, y, z)$.

5.2 Software BOM (SBOM)#

The SBOM inventories executable machine code, firmware, operating systems, and application libraries.

• Attributes: Package URL (purl), Common Platform Enumeration (CPE), cryptographic hash (SHA-256), license identifier, functional safety certification rating (IEC 61508 SIL-2).
• Physical Mapping: Binds to HBOM via executesOn edges; inherits physical blast radius of the host controller.

5.3 Operations BOM (OBOM)#

The OBOM captures deployment configurations, operational limits, network routing tables, and access control boundaries.

• Attributes: Modbus register mapping, BACnet object identifiers, VLAN tagging (802.1Q), maximum allowable flow rate setpoint, high-pressure trip limit.
• Physical Mapping: Binds directly to DEXPI process limits; defines the authorized mathematical boundary of physical operation $[\Psi_{\text{min}}, \Psi_{\text{max}}]$.

5.4 Cryptography BOM (CBOM)#

The CBOM catalogs all cryptographic algorithms, key lengths, certificates, and protocol cipher suites.

• Attributes: Algorithm (AES-256-GCM, ML-DSA-65), Key Length, Certificate Expiration Timestamp, Post-Quantum Cryptography (PQC) Migration Status.
• Physical Mapping: Protects communication edges $\mathcal{E}_{\text{comm}}$ connecting safety instrumented systems.

5.5 Services BOM (SaaSBOM)#

The SaaSBOM captures external network dependencies, cloud telemetry endpoints, and remote diagnostic links.

• Attributes: Endpoint URI, Data Flow Directionality, Authentication Mechanism, Cloud Service Provider, SLA Requirements.
• Physical Mapping: Represents untrusted ingress conduits crossing the industrial demilitarized zone (IDMZ) into physical plant networks.

6. Deterministic Physical Blast Radius Traversal Algorithm#

A primary breakthrough of the unified $\mathcal{G}_{\text{CPDT}}$ schema is the ability to compute the Kinetic Blast Radius of an arbitrary cyber vulnerability in sub-second execution time.

6.1 Mathematical Formulation of Blast Radius#

Let $v_{\text{vuln}} \in \mathcal{V}_{\text{sbom}}$ be a software component exhibiting an exploitable vulnerability with Common Vulnerability Scoring System vector $\mathbf{v}_{\text{CVSS}}$ and active VEX status $\text{Status} = \texttt{affected}$.

1. Cyber Lateral Movement Reachability ($\mathcal{R}_{\text{cyber}}$): The set of cyber assets reachable from $v_{\text{vuln}}$ across communication and dependency edges without traversing an active, authenticated firewall barrier: $$\mathcal{R}_{\text{cyber}}(v_{\text{vuln}}) = \left\{ u \in \mathcal{V}_{\text{cyber}} \mid \exists \text{Path}_{\mathcal{E}_{\text{comm}} \cup \mathcal{E}_{\text{hier}}}(v_{\text{vuln}} \rightsquigarrow u) \right\}$$
2. Bound Physical Actuator Set ($\mathcal{P}_{\text{act}}$): The set of physical equipment items whose digital controllers are contained within the reachable cyber compromise set: $$\mathcal{P}_{\text{act}}(v_{\text{vuln}}) = \left\{ p \in \mathcal{V}_{\text{phys}} \mid \exists h \in \mathcal{R}_{\text{cyber}}(v_{\text{vuln}}) \cap \mathcal{V}_{\text{hbom}} \text{ with } (h, p) \in \mathcal{E}_{\text{bind}} \right\}$$
3. Physical Kinetic Blast Radius ($\mathcal{B}_{\text{phys}}$): The set of physical downstream equipment and fluid segments that experience pressure, temperature, or flow deviations exceeding their design limits when actuators in $\mathcal{P}_{\text{act}}$ are maliciously manipulated: $$\mathcal{B}_{\text{phys}}(v_{\text{vuln}}) = \left\{ q \in \mathcal{V}_{\text{phys}} \mid \exists p \in \mathcal{P}_{\text{act}}(v_{\text{vuln}}) \text{ with } \Delta \Psi_q(\Delta \mathbf{u}_p) > \Psi_{\text{tolerance}, q} \right\}$$ where $\Delta \Psi_q$ is evaluated by propagating hydraulic and thermal network equations through $\mathcal{E}_{\text{fluid}}$.

6.2 Blast Radius Traversal Implementation#

The traversal algorithm is implemented using an augmented bidirectional breadth-first search (BFS) that transitions across domain boundaries via $\mathcal{E}_{\text{bind}}$:

7. Empirical Validation & Industrial Test Case#

7.1 Testbed#

250MW Liquid-Cooled Hyperscale Computing Facility

We validated the joint graph validation engine on a comprehensive engineering model of a 250MW liquid-cooled AI data centre consisting of:

• DEXPI 2.0 Model: 48 primary chilled-water pumps, 192 modulating cooling distribution unit (CDU) valves, 384 rack heat exchangers, and 1,536 piping segments.
• CycloneDX 1.6+ Model: 192 microcontroller hardware units (STM32F407), 48 Siemens S7-1500 PLCs, FreeRTOS v10.4.3 firmware, and an OpenSSL 3.0.2 crypto stack.

================================================================================
UNIFIED CYBER-PHYSICAL GRAPH METRICS (G_CPDT)
================================================================================
Entity Category               | Count     | Source Schema
--------------------------------------------------------------------------------
Physical Equipment (V_equip)  | 624       | DEXPI 2.0 XML
Physical Piping (V_pipe)      | 1,536     | DEXPI 2.0 XML
Nozzles & Ports (V_nozzle)    | 2,112     | DEXPI 2.0 XML
Hardware Components (V_hbom)  | 240       | CycloneDX 1.6+ JSON (HBOM)
Software Components (V_sbom)  | 1,842     | CycloneDX 1.6+ JSON (SBOM)
Operational Rules (V_obom)    | 480       | CycloneDX 1.6+ JSON (OBOM)
Crypto Certificates (V_cbom)  | 312       | CycloneDX 1.6+ JSON (CBOM)
--------------------------------------------------------------------------------
Total Unified Vertices        | 7,146     | Unified Graph G_CPDT
Total Unified Edges           | 14,890    | Fluid, Comm, Hier, Binding
================================================================================

7.2 Experimental Results: CVE-2024-XXXX Micro-Controller Exploit#

A critical remote code execution vulnerability (CVSS 9.8) was injected into the embedded lightweight IP (lwIP) stack of the CDU valve controllers:

• Cyber Lateral Movement: The traversal identified 16 CDU controllers on Subnet VLAN-104 sharing unsegmented Modbus gateways (execution time: 4.2 milliseconds).
• Cross-Domain Binding: The 16 controllers mapped directly to valves FCV-401 through FCV-416 governing Server Hall Pod 4.
• Physical Kinetic Propagation: Simulating malicious valve closure ($\text{Position} \to 0\%$) triggered instantaneous hydraulic fluid starvation:
  • Coolant flow to 64 high-density GPU racks dropped from $122\text{ L/min}$ to $0\text{ L/min}$.
  • GPU junction temperature $T_j$ was predicted to reach the emergency hardware shutdown trip point ($94^\circ\text{C}$) in 14.8 seconds.
• Total Blast Radius Resolution Time: 18.6 milliseconds across 7,146 nodes and 14,890 edges on a standard commercial server.

8. Conclusion & Standardization Roadmap#

The joint validation of DEXPI 2.0 and CycloneDX 1.6+ resolves the historic fragmentation between physical process engineering and cybersecurity assurance:

1. A Single Computable Graph ($\mathcal{G}_{\text{CPDT}}$): We provided the formal mathematical specification joining continuous P&ID topology and discrete 5-BOM dependencies.
2. Three Axiomatic Validation Rules: Grounded Actuation, Reachable Attestation, and Conservation Coherence eliminate orphaned physical assets and unverified cyber controllers.
3. Sub-Second Blast Radius Traversal: Security teams can now evaluate the real physical kinetic impact of software vulnerabilities before threat actors exploit them.

Future standardization efforts in WG-05 will submit this unified schema to the DEXPI Working Group and OWASP CycloneDX Industry Working Group as the definitive open cyber-physical systems assurance standard.

9. References#

1. DEXPI e.V. (2025). DEXPI 2.0 Specification. Released 10 October 2025, gitlab.com/dexpi/Specification, CC BY 4.0.
2. OWASP Foundation. (2024). CycloneDX Specification Version 1.6: Full-Stack Bill of Materials Standard. OWASP.
3. European Commission. (2024). Regulation (EU) 2024/2847 of the European Parliament and of the Council on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act).
4. International Electrotechnical Commission. (2021). IEC 62443: Security for industrial automation and control systems. IEC.
5. International Electrotechnical Commission. (2016). IEC 61508: Functional safety of electrical/electronic/programmable electronic safety-related systems. IEC.
6. International Electrotechnical Commission. (2016). IEC 61511: Functional safety - Safety instrumented systems for the process industry sector. IEC.
7. McKenney, J. (2026). Eigenia Physics Models & DEXPI 2.0 / CycloneDX 4-BOM Standards. Eigenia Lab Sovereign Research Series, WG-05-CAD-DEXPI-Introduction.
8. McKenney, J. (2026). Frontier AI Hardware Security & Platform Assurance Framework. Eigenia Lab Sovereign Research Series, WG-05-CAD-Frontier-AI-Hardware-Security.