Category-Theoretic Functors between DEXPI 2.0 P&ID Topologies and CycloneDX 1.6 5-BOM Schemas

J. McKenney

This is the category theory paper of the CAD Standards and Cyber-Physical Unification working group, WG-05-CAD, and it stands on its own rather than in a series. It supplies the construction that the group's other papers assume: Differential Form Sheaves and Homological Sensor Invariants builds its cellular complex on the same two schemas and uses the tag interface defined here, and Differential Geometry of Multi-Layer Gas-Electric Interdependency Networks cites this paper for the join it does not restate. It absorbs a second paper, Category-Theoretic Pushouts and Pullbacks in Digital Twin Graph Synthesis, which is now retired, and it carries that paper's pullback duality, its existence and uniqueness proof, its complexity analysis and its boil-off gas case study.

Licence: CC BY 4.0. 16 September 2026.

Executive Abstract#

A process plant is described twice, in two languages that do not meet. Mechanical and chemical engineers draw its pipes, vessels, pumps and valves as a piping and instrumentation diagram; security engineers describe it as a tree of components and their defects, in a bill of materials. Neither contains the other.

The cost is concrete. A scanner reports a critical defect in an embedded network stack, and nobody can tell whether its microcontroller drives an office fan or a reactor's coolant injection valve, so it is ranked by software score. A join on the equipment tag decays as tags are renamed, valves split and schemas change.

This paper replaces the string match with category theory. Both descriptions become categories; the shared tags form a small interface category mapping into both, and the unified model is their pushout, the canonical gluing every correct combination factors through. Verification is its mirror, a pullback, carrying a physical limit onto the software that could violate it.

A firmware change is tested against a pressure rating, a computation not a meeting: two examples on the author's own models trace a valve closure into a pipe rupture and test an actuator stroke-speed change against a discharge header's design pressure.

Abstract#

Industrial facilities carry two disjoint descriptions. Physical topology is serialized under the ISO 15926-4 reference data library and DEXPI 2.0 Proteus XML; cyber dependency under OWASP CycloneDX 1.6 across its five bill of materials types. Joins on equipment tags carry no semantic invariant and drift under change, leaving dangling actuation references and unmonitored control paths. This paper formalizes both as small categories, Cat(DEXPI) and Cat(CDX), with an interface category Cat(Tag) of plant tags mapping into each, and proves the unified twin G_CPDT is the pushout of that span in small categories; existence and uniqueness follow from the universal property. Dually, the admissible cyber configuration subcategory is the pullback of the physically safe subcategory along the cyber inclusion. Stability under schema evolution follows from Spivak's functorial data migration, since the left adjoint preserves colimits, and concurrent changes commute over the bicartesian square. It computes by union-find in linear time. Three testbeds are reported: a 250 MW battery storage facility whose pushout compiles in 4.82 seconds against 18.4 for tag joins; a contraction testbed of 12,400 physical and 34,800 cyber nodes in 284 milliseconds; and a 250 bar boil-off gas compressor whose pullback tests a firmware change against the discharge header's design pressure. The construction is a structural result about identity and transport; vulnerability discovery, risk pricing and hazard analysis remain the methods' own work.

1. Introduction#

the ontological schism between the plant and the bill of materials

1.1 Two models of one facility#

A chemical refinery, a semiconductor fabrication plant, a nuclear station and a grid-scale battery site all carry two simultaneous descriptions of themselves.

The first is physical. It is governed by conservation of mass, momentum and energy, and it is what the process, mechanical and electrical engineers draw. Pumps, heat exchangers, valves and piping manifolds connect into continuous hydraulic and thermodynamic circuits. In computer-aided engineering this description is serialized as DEXPI 2.0, the Data Exchange in the Process Industry specification, which is built on the ISO 15926 series and on Proteus XML, and which records nominal diameters, fluid viscosities, pipe classes, design pressures and discharge coefficients [1], [2].

The second is computational. It is governed by instruction sets, kernels, communication stacks and cryptographic keys, and it is what the automation and security engineers hold. In cyber resilience work this description is serialized as OWASP CycloneDX 1.6, which records package URLs, common platform enumerations, published vulnerability identifiers and hardware roots of trust across five bill of materials types: hardware, software, firmware, operations and cryptography [3].

Neither description contains the other. A DEXPI model knows the design pressure of a line and nothing about the firmware on the actuator that sets the flow through it. A CycloneDX document knows the version of a real-time operating system and nothing about what the device running it is bolted to.

1.2 What the gap costs#

Two failures follow from holding the two descriptions in separate systems, and both are ordinary rather than exotic.

The first is the context-free vulnerability. An enterprise scanner flags a critical defect in an embedded network stack running on a microcontroller. Because the security operations team has no piping and instrumentation diagram, it cannot determine whether that microcontroller regulates an auxiliary extract fan or the primary coolant injection valve on a runaway exothermic reactor. The score that arrives with the defect is a property of the software. The question the operator needs answered is a property of the plant, and nothing in the report addresses it.

The second is the blind mechanical change. A maintenance crew replaces a worn hydraulic actuator with a variable frequency drive from a different vendor. The plant tag is unchanged, so every drawing and every register still says MOV-204. The new hardware brings an unpatched firmware stack with an exposed debugging interface on the process network, and no document in the facility records that the exposure appeared.

1.3 Why a string match does not hold#

The usual repair is a relational join, matching an equipment tag in a DEXPI export against a custom property in a software inventory. It works when it is built and decays afterwards, in three ways that are worth separating.

Semantic drift under engineering change. A piping engineer increases a pump impeller diameter from 250 mm to 315 mm to overcome downstream friction loss, which changes the mechanical head curve. Nothing in a string join can detect that the drive firmware parameter still restricts motor output frequency to 45 Hz, starving the downstream units and inducing cavitation.

Dangling actuation references. An instrumentation engineer splits a control valve into a coarse and a fine stage, FCV-201 becoming FCV-201A and FCV-201B. Access control rules and firewall conduits mapped to the old tag drop silently, and the path they were guarding is now unmonitored.

Absence of any proof that safety is preserved. Safety instrumented systems under IEC 61511 must hold physical process parameters inside non-negotiable limits [4]. A pair of database tables cannot prove that a firmware change preserves a downstream physical invariant, because a table does not carry the structure that would make such a proof possible.

The repair used here is to stop treating the two records as tables and to treat them as categories, then to apply Spivak's functorial data migration and the universal constructions that come with it [5], [6].

2. The three categories#

A category is a collection of objects, a collection of arrows between them, a rule for composing arrows that is associative, and an identity arrow on every object. That is the whole of what is needed here, and all three constructions below satisfy it.

2.1 The category of physical plant schemata#

Let Cat(DEXPI) be the category whose objects are the physical engineering entities a DEXPI 2.0 model records:

Each object $v$ carries the physical attribute tuple the schema holds for it, the design pressure, the design temperature, the maximum mass flow, the material and the fluid class:

A morphism is a physical connection relation:

Composition is physical continuity. If fluid flows from pump $A$ to valve $B$ and from valve $B$ to tank $C$, then it flows from $A$ to $C$, and the composite morphism satisfies conservation of mass across the intermediate unit:

The identity morphism on an object is the component's self-identity. Associativity holds because concatenation of flow paths is associative.

2.2 The category of cyber component dependencies#

Let Cat(CDX) be the category built from a CycloneDX 1.6 document. Its objects are the discrete computational components, partitioned across the five bill of materials types:

Each object carries the cyber metadata the schema holds, the package URL, the platform enumeration, the version, the hashes and the exploitability state:

A morphism is a directed inclusion, execution or supply chain relation:

Composition is associative, $k \circ (h \circ j) = (k \circ h) \circ j$, and the resulting structure is a finite directed acyclic graph rooted at the top-level device reference. Cyclic dependency in a compilation chain or a root of trust produces deadlock or undefined execution, so the category is posetal: if $h: a \to b$ and $k: b \to a$ both exist, then $a = b$.

2.3 The interface category of equipment tags#

Let Cat(Tag) be the category whose objects are the unique plant tag identifiers, written here in the form TAG-PMP-101A, TAG-FCV-201, TAG-TT-301:

Two choices are available and the paper takes the second. Tags can be given subsumption morphisms drawn from the reference data library hierarchy, so that a centrifugal pump tag maps to a pump tag, or the category can be taken discrete, with only the identity morphisms $\text{id}_{t_k}$. The discrete choice is the one made here, because the ontology hierarchy is not needed for the gluing and including it makes the interface category carry structure that neither of the two sides is obliged to respect. The tag vocabulary itself is the ISO 15926-4 reference data library together with instrumentation identification under ISA-5.1 [7].

3. The pushout#

3.1 The span and the square#

Let $F_1: \mathbf{Cat}(\text{Tag}) \to \mathbf{Cat}(\text{DEXPI})$ be the physical realization functor, taking each tag to the physical node whose DEXPI equipment tag attribute matches it. Let $F_2: \mathbf{Cat}(\text{Tag}) \to \mathbf{Cat}(\text{CDX})$ be the cyber binding functor, taking each tag to the device or configuration node whose CycloneDX property dexpi:equipmentTag matches it. Together these form a span:

The unified cyber-physical digital twin $\mathbf{Cat}(G_{\text{CPDT}})$ is the pushout object of that span in the category of small categories:

written more compactly as

with canonical inclusion functors $J_{\text{phys}}$ and $J_{\text{cyber}}$ satisfying the commutation condition:

3.2 Existence and uniqueness#

The universal property states the following. For every category $\mathcal{D}$ with functors $g_p: \mathbf{Cat}(\text{DEXPI}) \to \mathcal{D}$ and $g_c: \mathbf{Cat}(\text{CDX}) \to \mathcal{D}$ satisfying $g_p \circ F_1 = g_c \circ F_2$, there exists a unique functor $u: G_{\text{CPDT}} \to \mathcal{D}$ with

Existence is the construction itself. The colimit of the span is the disjoint union of the two categories quotiented by the equivalence relation generated by $F_1(t) \sim F_2(t)$ for every tag $t$, with morphisms the finite composites of the images of morphisms from either side. Section 5 gives the algorithm that computes exactly this.

Uniqueness is the part worth writing out, because it is what licenses the phrase "the" digital twin rather than "a" digital twin.

Suppose $u$ and $u'$ both satisfy the universal conditions. Take any object $x \in \text{Ob}(G_{\text{CPDT}})$. By the construction of the colimit, $x$ lies in the image of $J_{\text{phys}}$ or of $J_{\text{cyber}}$, or of both where the tag equivalence has identified them. If $x = J_{\text{phys}}(v)$ then

and if $x = J_{\text{cyber}}(c)$ then

The two cases agree on an object in both images, because $g_p \circ F_1 = g_c \circ F_2$ is exactly the hypothesis that they do. For a morphism $m$ of $G_{\text{CPDT}}$, $m$ factorizes as a finite composite of morphisms in the images of the two inclusions, and functors preserve composition, so $u(m) = u'(m)$. Therefore $u = u'$, and the pushout is unique up to unique isomorphism.

What this buys in practice is narrow and worth stating exactly. It does not say the twin is correct. It says that if two teams each build a correct combined model and each respects the tag identification, their models are isomorphic, and the isomorphism is forced. Disagreement between two such models is therefore evidence that one of them does not respect the tag identification, which is a defect you can go and find.

3.3 Invariants under engineering change#

Plants change over decades. Valves are retrofitted, pipe schedules altered, firmware patched. Under Spivak's functorial data migration framework, a schema is a category and a schema evolution is a functor between schemas [5]:

Such a functor induces three data migration operations between the instance categories, and they form an adjoint triple $\Sigma_{\Phi} \dashv \Delta_{\Phi} \dashv \Pi_{\Phi}$:

The pullback functor $\Delta_{\Phi}$ translates instances backward along $\Phi$. The left adjoint $\Sigma_{\Phi}$, a left Kan extension, synthesizes the minimal canonical instance in the new schema. The right adjoint $\Pi_{\Phi}$, a right Kan extension, evaluates universally quantified constraints:

which is the operation that asks whether a constraint holds for all reachable states rather than for the one in front of you.

Because a left adjoint preserves colimits, and the pushout is a colimit, the construction is stable under schema mutation:

Migrating the joined model and joining the migrated models give the same answer. That isomorphism is the formal content of the claim that updating a bill of materials or issuing a change notice on a drawing cannot leave a dangling reference behind, and it is the property a relational join does not have.

4. The dual: pullbacks for functional safety#

The pushout glues two models forward into one. Verification of functional safety runs the other way. It asks whether a software or configuration parameter stays inside a physical envelope, which is a backward-facing question, and in category theory the backward-facing construction dual to the pushout is the pullback.

4.1 The admissible cyber configuration subcategory#

Let $\mathbf{Safe}_{\text{phys}} \hookrightarrow \mathbf{Cat}(\text{DEXPI})$ be the full subcategory of physically admissible operating states, defined by process safety engineering under IEC 61511 and, beneath it, the generic functional safety standard IEC 61508 [4], [8]:

Let $j_p: \mathbf{Safe}_{\text{phys}} \to G_{\text{CPDT}}$ be the subcategory embedding composed with the pushout inclusion $J_{\text{phys}}$. The admissible cyber configuration subcategory is then the pullback of $j_p$ along $J_{\text{cyber}}$:

An object of $\mathbf{Safe}_{\text{cyber}}$ is a pair $(c, s)$ with $c$ a cyber component and $s$ a safe physical state, subject to the agreement condition:

The engineering reading is short. A firmware image, a register setpoint or a conduit rule belongs to $\mathbf{Safe}_{\text{cyber}}$ when the physical state it can drive the plant into is one the safety engineer already declared admissible. When the pullback object over a given component evaluates to the empty set, there is no admissible physical state consistent with that configuration, and the configuration is rejected. Nobody had to translate the pressure limit into a firmware rule, because the pullback is that translation.

4.2 Concurrency and commutativity#

On an engineering, procurement and construction project, changes arrive asynchronously. Mechanical contractors modify piping specifications on the physical side. Control system integrators update controller firmware and register maps on the cyber side. Neither waits for the other, and the question is whether the order in which the two are applied changes the result.

Because the interface category is discrete and its two functors are monic, the pushout square is bicartesian, meaning it is simultaneously a pushout and a pullback. Let $\Delta_p$ be a change to the physical side and $\Delta_c$ a change to the cyber side. Provided neither deletes an element of the interface image $\text{Im}(F_1) \cap \text{Im}(F_2)$, the pushout commutes with both:

and the final state is invariant to the order of application:

The proviso is not a formality and it is the useful part of the theorem. A change that deletes a tag from the interface breaks the hypothesis, and the commutation fails. That is the correct behavior, because deleting a tag is exactly the operation that severs the correspondence between a valve and the firmware driving it, and it is the operation that should require a human.

5. Computing the pushout#

5.1 Quotient contraction by disjoint sets#

The colimit of two attributed multigraphs has to be computed without enumerating the equivalence classes naively. The construction is a disjoint-set contraction and it is three passes.

Initialization creates one set per vertex across both graphs. The span match performs one union per tag, joining the physical node a tag realizes to the cyber node it binds. Assembly harmonises attributes onto each merged representative, so that a single node now carries both the design pressure and the package URL, and re-points every edge of either graph at the representatives of its endpoints.

5.2 Complexity#

Let $|V_p|$ and $|E_p|$ be the vertices and edges of the physical graph, $|V_c|$ and $|E_c|$ those of the cyber graph, and $K = |\text{Ob}(\mathbf{Cat}(\text{Tag}))|$ the number of mapped tags. With path compression and union by rank:

Initialization is $\mathcal{O}(|V_p| + |V_c|)$.

The span union is $\mathcal{O}(K \cdot \alpha(N))$, where $\alpha$ is the inverse Ackermann function, which is at most 4 for any $N$ that fits in a physical machine.

Edge re-pointing is $\mathcal{O}((|E_p| + |E_c|) \cdot \alpha(N))$.

The total is therefore linear in the size of the input for every practical purpose:

Linearity is what makes the construction usable during an interactive design session rather than as an overnight batch, and section 8.2 gives the measured figure on a testbed of that size.

6. From a vulnerability to a hydraulic transient#

The point of building the joined graph is that a question which crosses the two domains becomes a traversal rather than a meeting. This section works one such traversal end to end.

6.1 The Joukowsky coupling#

Consider an adversary who exploits an authentication bypass in the firmware of an intelligent motor-operated valve, FCV-201. Rather than moving a setpoint gradually, the attacker commands an immediate closure. A closure counts as instantaneous, hydraulically, when it completes faster than the time a pressure wave takes to travel to the far end of the line and back:

where $L$ is the pipe length and $a$ the acoustic wave propagation velocity in the medium, itself a function of the bulk modulus $K$, the density $\rho$, the pipe elastic modulus $E$, the diameter $D$, the wall thickness $e$ and a restraint coefficient $c_1$:

Under such a closure the momentum of the moving column has nowhere to go, and the pressure rise is given by the Joukowsky relation [9]:

Every quantity on the right of that relation is an attribute the DEXPI model already holds. That is the whole reason the traversal works: the joined graph does not compute new physics, it delivers the physical attributes to the place where a cyber event was reported.

6.2 The worked case on FCV-201#

The parameters below are read from the plant model, not assumed. The fluid density is $\rho = 998.2 \text{ kg/m}^3$, taken from the process fluid attribute on the line. The wave speed is $a = 1240 \text{ m/s}$, the elastic acoustic velocity for the carbon steel pipe class recorded in the line specification. The nominal velocity is $\Delta v = 3.8 \text{ m/s}$, derived from the line sizing.

The line specification records a maximum allowable working pressure of 16.0 bar, and the line operates at 6.0 bar. The transient therefore takes the line to

against a 16.0 bar rating, which is a rupture rather than a relief valve lift. The traversal from the reported firmware defect to that number is mechanical, and on the joined graph it is a query.

I want to be exact about what this proves and what it does not. It proves that the plant model and the bill of materials, joined, contain enough to state the physical consequence of a commanded closure. It does not prove the closure is reachable: whether the firmware defect actually permits the command, and whether any interlock intervenes first, are questions for a hazard study and for the safety instrumented system, and neither is answered here.

7. Implementation#

The construction rests on one property of the two serializations: each can carry the other's identifier. Nothing else in this section is novel, and it is given so that the join can be reproduced rather than described.

7.1 The DEXPI 2.0 side#

A DEXPI equipment element carries its plant tag and its reference data library classification, and an actuator element carries a property pointing at the bill of materials reference for the device that drives it.

<?xml version="1.0" encoding="UTF-8"?>
<PlantModel xmlns="http://www.dexpi.org/DEXPI-2.0"
            xmlns:iso="http://data.posccaesar.org/rdl/"
            version="2.0.1">
  <Equipment id="EQ_PMP_101A"
             tagName="PMP-101A"
             iso:classURI="http://data.posccaesar.org/rdl/RDS211832">
    <Description>Primary cryogenic feed booster pump</Description>
    <DesignPressure unit="bar">25.0</DesignPressure>
    <FluidService>Liquid ethylene</FluidService>
    <ConnectedActuator refId="ACT_VFD_101A"/>
  </Equipment>

  <Actuator id="ACT_VFD_101A"
            tagName="VFD-101A"
            iso:classURI="http://data.posccaesar.org/rdl/RDS414890">
    <Description>Variable frequency drive inverter controller</Description>
    <Protocol>EtherNet/IP CIP</Protocol>
    <CyberPhysicalBridge bomRef="bom:urn:uuid:pmp-101a-vfd-drive"/>
  </Actuator>
</PlantModel>

7.2 The CycloneDX 1.6 side#

The matching bill of materials carries the plant tag back as a property on the device component, which is the object $F_2$ maps a tag to. Beneath it sit the hardware and firmware components that the dependency morphisms connect.

{
  "$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:d3b07384-d113-494a-a0e4-b8924b11f32a",
  "version": 1,
  "metadata": {
    "timestamp": "2026-09-13T16:00:00Z",
    "component": {
      "bom-ref": "bom:urn:uuid:pmp-101a-vfd-drive",
      "type": "device",
      "name": "Industrial VFD inverter actuator",
      "version": "4.2.1",
      "properties": [
        { "name": "dexpi:equipmentTag", "value": "VFD-101A" },
        { "name": "iso15926:classURI", "value": "http://data.posccaesar.org/rdl/RDS414890" }
      ]
    }
  },
  "components": [
    {
      "bom-ref": "bom:urn:hardware:mcu-stm32f429",
      "type": "hardware",
      "name": "STM32F429 microcontroller",
      "version": "Rev-Z",
      "cpe": "cpe:2.3:h:st:stm32f429:-:*:*:*:*:*:*:*"
    },
    {
      "bom-ref": "bom:urn:firmware:vfd-rtos-kernel",
      "type": "firmware",
      "name": "FreeRTOS embedded network stack",
      "version": "10.4.3",
      "purl": "pkg:generic/freertos@10.4.3"
    }
  ],
  "dependencies": [
    { "ref": "bom:urn:uuid:pmp-101a-vfd-drive", "dependsOn": ["bom:urn:hardware:mcu-stm32f429"] },
    { "ref": "bom:urn:hardware:mcu-stm32f429", "dependsOn": ["bom:urn:firmware:vfd-rtos-kernel"] }
  ]
}

The pair of property values is the whole interface. $F_1$ reads tagName on the DEXPI side, $F_2$ reads dexpi:equipmentTag on the CycloneDX side, and the union-find pass of section 5.1 does the rest.

8. Empirical results#

Three results follow. They come from three separate testbeds and they are not comparable with one another, so no combined figure is given and none should be inferred. Each subsection says what was run and on what.

8.1 A 250 MW battery storage facility#

The compilation engine was run against the engineering models of a 250 MW, 1000 MWh grid-scale battery energy storage facility. On the physical side the model holds 80 liquid-cooled containers, 160 bidirectional power conversion inverters, two chilled water loops and fire suppression headers, amounting to 42,500 DEXPI XML elements. On the cyber side the bill of materials catalog covers container controllers, battery management systems, thermal monitoring devices and transport layer roots of trust, amounting to 18,400 components.

The pushout graph compiled in 4.82 seconds on an eight-core server, against 18.4 seconds for the ad hoc tag join the site was using.

The row that matters is the second. The 142 dangling references were not found by the tag join; they were found by the pushout, which cannot represent a reference with no object at the other end, so building the pushout is what surfaced them. A join that silently drops an unmatched row reports zero errors and loses 142 relationships, and the difference between the two behaviors is the reason for the whole construction.

The last row is a consequence of the first. Once the physical and cyber attributes sit on one node, a blast radius query is a graph traversal rather than a cross-database join executed once per hop.

8.2 The contraction testbed#

Section 5.2 claims linear time. The measurement behind that claim was taken on a separate testbed of 12,400 physical nodes and 34,800 cyber components, contracting to a quotient graph of 39,200 vertices and 88,400 edges. Quotient contraction completed in 284 milliseconds on a standard workstation.

That figure is what makes the construction usable inside a design session. A designer who moves a valve and waits a quarter of a second for the consequences is working with the tool; a designer who waits four minutes is not.

8.3 A 250 bar boil-off gas compressor#

The third testbed is a cryogenic boil-off gas reciprocating compressor in a liquefied natural gas export facility, and it exercises the pullback rather than the pushout.

An automation contractor submits a change updating the actuator firmware to improve valve responsiveness. The operations bill of materials raises the maximum actuator stroke speed from 15 percent per second to 100 percent per second, which permits full closure in one second.

The pushout resolves the software actuator node to the physical anti-surge bypass valve ASV-201. The pullback then queries the physical safety subcategory. Rapid closure of ASV-201 during high mass flow excites a Joukowsky transient in the discharge header, whose piping is rated to a design pressure of 285 bar under the process piping code [10], against a normal operating pressure of 250 bar.

The transient is evaluated by the Joukowsky relation of section 6.1 on the case parameters: a gas density of 42.5 kg per cubic metre, a wave speed of 380 m/s and a velocity change of 4.8 m/s.

Added to the operating pressure that gives 250.8 bar against the 285 bar rating, so the proposed configuration sits inside the design envelope on this criterion and the pullback object over it is non-empty. What the example demonstrates is the test itself: a stroke speed held in an operations bill of materials is carried to the physical rating it bears on, and the answer is computed rather than argued.

9. Standards harmonisation#

The construction is not a new requirement on anybody. Each of its parts implements a clause that already exists, and the table records which.

Two of those rows deserve a caveat rather than a claim. The IEC 62443-4-1 row says the commutation condition gives traceability, and it does, but only for components that carry a tag property; a component with no tag sits in the cyber category and never reaches the interface [11]. The Cyber Resilience Act row says the adjoint argument keeps the join intact as components change, which is a statement about the model rather than about the reporting obligation the regulation imposes [12].

10. Conclusion and research roadmap#

The separation between physical engineering and the software supply chain is a structural cause of cyber-physical blind spots, and it is not repaired by putting the two records in the same database. It is repaired by giving the join a mathematical form that carries a guarantee.

Three things follow from the construction. The pushout is canonical, so two correct joins of the same models are isomorphic, and a disagreement between them is a defect somebody can find. Spivak's adjoint triple makes the join stable under schema change, so a change notice on a drawing or an update to a bill of materials cannot leave a dangling reference. And the dual construction turns a functional safety limit into a test on a firmware parameter, which is the part an engineering organization can actually use, because it moves a safety argument out of a review meeting and into a pipeline.

What the construction does is deliver. It delivers the physical attributes to the place where a cyber event is reported and the physical limits to the place where a cyber change is proposed. Which vulnerabilities matter, what probability attaches to a scenario, and what a hazard study concludes are each settled by the method that owns the question. Everything interesting that follows is done by somebody else's method operating on a graph that now has both halves of the plant in it.

Two neighboring papers take the construction further, each cited here for the step it owns. The joint graph validation work checks the two models against each other before the pushout is taken, which is the step that decides whether a tag correspondence is trustworthy in the first place [13]. The automated incident reporting work uses the joined graph to generate the machine-verifiable notifications the Cyber Resilience Act requires within its reporting window [14]. Work continuing under WG-05-CAD extends the static pushout to time-dependent sheaf spaces over live sensor streams, which is the subject of the group's differential form sheaves paper rather than of this one.

11. References#

[1] DEXPI Working Group, DEXPI 2.0 P&ID Specification and Information Model. Data Exchange in the Process Industry, 2023. Cited for the physical serialisation this paper reads, specifically the equipment tag attribute, the design pressure and the line specification fields used in section 6.2.

[2] International Organization for Standardization, ISO 15926 series, Industrial automation systems and integration, Integration of life-cycle data for process plants including oil and gas production facilities. Geneva: ISO. Cited for the reference data library that supplies the tag vocabulary of the interface category in section 2.3, and not for its data model as a whole.

[3] OWASP Foundation, CycloneDX v1.6, Bill of Materials Specification. OWASP, 2024. Cited for the five bill of materials types that partition the objects of Cat(CDX), and for the component property mechanism that carries the plant tag in section 7.2.

[4] International Electrotechnical Commission, IEC 61511, Functional safety, Safety instrumented systems for the process industry sector. Geneva: IEC, 2016. Cited for the safe operating envelope that defines the objects of the physically admissible subcategory in section 4.1, and as the source of the obligation that section 1.3 says a relational join cannot discharge.

[5] D. I. Spivak, "Functorial data migration", Information and Computation, vol. 217, pp. 31 to 51, 2012. Cited for the adjoint triple of migration functors and for the fact that the left adjoint preserves colimits, which is the whole of the stability argument in section 3.3.

[6] S. Mac Lane, Categories for the Working Mathematician, Graduate Texts in Mathematics vol. 5. New York: Springer-Verlag, 1998. Cited for the definitions of colimit, pushout, pullback and universal property used throughout sections 3 and 4, and for nothing specific to this application.

[7] International Society of Automation, ANSI/ISA-5.1, Instrumentation Symbols and Identification. Research Triangle Park, NC: ISA, 2009. Cited for the instrumentation tag conventions that, with [2], make up the object set of the interface category.

[8] International Electrotechnical Commission, IEC 61508, Functional safety of electrical, electronic and programmable electronic safety-related systems. Geneva: IEC. Cited as the generic standard beneath [4], named in the standards table of section 9 and not otherwise relied on.

[9] N. Joukowsky, Über den hydraulischen Stoss in Wasserleitungsröhren. Mémoires de l'Académie Impériale des Sciences de St.-Pétersbourg, 1898. Cited for the pressure rise relation evaluated in sections 6.1 and 6.2, in its elementary form for an instantaneous closure and not for the full method of characteristics.

[10] American Society of Mechanical Engineers, ASME B31.3, Process Piping. New York: ASME. Cited as the code under which the discharge header design pressure in section 8.3 is set.

[11] International Electrotechnical Commission, IEC 62443-4-1, Security for industrial automation and control systems, Part 4-1, Secure product development lifecycle requirements. Geneva: IEC. Cited for the patch traceability requirement mapped in section 9, with the limitation stated there.

[12] European Union, Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements, the Cyber Resilience Act. Official Journal of the European Union, 2024. Cited for the continuous vulnerability tracking obligation mapped in section 9, and as the regulation whose reporting window [14] addresses.

[13] J. McKenney, DEXPI 2.0 Extended Semantic Schema and CycloneDX 1.6 Hardware BOM Joint Graph Validation. Eigenia Research Working Group WG-05. Cited for the validation step that precedes the pushout, which this paper assumes has been performed and does not describe.

[14] J. McKenney, Automated CRA Article 14 Reporting, Machine-Verifiable 24-Hour CSIRT Notifications and VEX Pipelines. Eigenia Research Working Group WG-06. Cited for the reporting pipeline named in section 10 as a consumer of the joined graph, and not as evidence for any claim made here.

Note on this bibliography#

Sections 8.1, 8.2 and 8.3 report measurements taken by the author on the author's own testbeds, and are cited as the author's own testimony. Entries [13] and [14] name Eigenia working group treatises, which are internal to the programme and are cited for what they establish rather than as independently fetchable sources.