ZTSafe: Safety-Certified Risk-Adaptive Scheduling for Zero-Trust Time-Sensitive Industrial Networks

Abstract

Zero-trust security continuously re-evaluates the trustworthiness of industrial devices and reacts by rerouting, isolating, or rescheduling traffic. In a time-sensitive network (TSN) that carries feedback control loops, however, every such reaction is itself a control-plane disturbance: a reroute that meets every deadline can still deliver stale measurements, and an optimizer that crashes mid-reconfiguration can leave the network in an undefined state. This paper presents ZTSafe, a scheduling architecture that treats physical safety—not attack blocking—as the object of guarantee. The guarantee has two distinct layers: compliance with the communication contract yields a deterministic invariance result conditional on the stated plant, disturbance, synchronization, and trusted-base assumptions, whereas the risk bound’s $1-\delta$ coverage is an empirical probabilistic calibration result. ZTSafe (i) synthesizes, offline and per control loop, a communication safety contract that bounds delay, age of information (AoI), consecutive losses, jitter, and path risk such that the physical state remains in its safe set under those assumptions; (ii) converts zero-trust evidence into conservative risk upper bounds and couples the admissible path-risk budget to the runtime safety margin of the plant; and (iii) places the scheduling optimizer outside the trusted computing base: an independent runtime shield checks every proposed schedule against the contracts, and on solver timeout, crash, or infeasibility the system atomically switches to a pre-checked fallback instead of executing an unverified approximate solution. Here, “verified” means independently checked by the shield, not machine-verified; a systematic shield defect or compromise of the remaining trusted computing base voids the deterministic claim. On a hardware TSN testbed with three physical control loops and fourteen attack and fault scenarios, ZTSafe reduces safe-set violations by 92.9% relative to the strongest baseline (12.8% to 0.9%; two-proportion $z=39.4$, $p<{10}^{-15}$) while sustaining 94.3% on-time completion of critical traffic, recovers within three control periods, and executes zero unverified configurations across 10,000 injected solver failures.

1. Introduction

A programmable logic controller (PLC) that holds a perfectly valid credential can still betray the process it controls: its hash-based message authentication code (HMAC) tags verify, yet it replays hour-old measurements [1] while flooding the control path with bursts. Authentication success is not behavioral safety. A zero-trust monitor [2,3] that observes this behavior will, correctly, lower the device’s trust score and trigger a network reaction—isolating the suspect flow, rerouting critical traffic around the suspect switch, and recomputing the gate control lists. But in a time-sensitive network (TSN) [4] that carries closed-loop control traffic, the reaction is itself a control risk: the new path may satisfy every frame deadline while delivering measurements whose age of information (AoI) [5] exceeds what the water-level, motor-speed, or heading controller can tolerate. Figure 1 traces this failure end to end: a compromised-but-credentialed PLC triggers a trust drop; the resulting reroute meets the 10 ms deadline on the alternate path; and the physical state nevertheless drifts out of its safe band, because the alternate path delivers data that is fresh enough for the network abstraction and too stale for the plant. Blocking the attack flow is not the same as guaranteeing physical safety.

Figure 1. A reputation-driven reroute that meets every deadline yet violates the age-of-information (AoI) bound, driving the physical state out of its safe set. (a) A compromised programmable logic controller (PLC) with valid credentials triggers a trust drop and a reroute; the new path satisfies the deadline but not the freshness the control loop needs, and the state leaves its safe band. (b) Two deadline-feasible paths with different control safety outcomes, and the propose–verify–commit–fallback pipeline ZTSafe builds around this observation: security-aware does not automatically mean control-safe.

1.1. Four Gaps

Existing work leaves four gaps between zero-trust networking and control safety.

Gap 1: Trust scores have no physical interface. Zero-trust systems produce reputation or risk scores, but no existing scheduler can answer the question a plant engineer would ask: what does a node risk bound of ${\overline{r}}_i=0.72$ mean for a water-level loop? Is the loop still safe if two of its frames traverse that node? Without a translation from risk to control-relevant guarantees, trust scores can only drive heuristics—block, allow, reroute—whose physical consequences are unexamined.

Gap 2: Meeting deadlines is not maintaining control safety. TSN scheduling research [6,7] compresses a control loop’s requirements into a period and a deadline. Yet control safety additionally depends on the age of the delivered data, the number of consecutive losses the loop rides through, delivery jitter, and the freshness of actuation commands. A schedule can be deadline-feasible and still starve a controller of a fresh state (Section 4.1 gives a concrete two-path counterexample).

Gap 3: The optimizer is implicitly trusted. Joint routing-and-scheduling formulations assume the solver returns a correct solution in time, every time. In an online zero-trust setting the solver is invoked continuously, under a real-time budget, on adversarially influenced inputs. What happens when it times out, crashes, returns an infeasible or partially applied candidate, for example at 2 a.m., mid-attack? Silent execution of an unverified approximate solution is the default in current designs, and it is indistinguishable from an attack on the scheduler itself.

Gap 4: There is no closed loop from zero-trust risk to safe degradation. Detection, scheduling, and fallback are studied separately. No existing system connects them so that any network decision induced by zero-trust evidence—including the decision to do nothing—comes with an end-to-end argument that the physical state stays within its safe set, or degrades along a pre-certified path when it cannot.

1.2. Core Idea: Propose, Verify, Commit

ZTSafe closes these gaps with a propose–verify–commit discipline (Section 5). Offline, each control loop’s tolerance to network degradation is compiled into a communication safety contract: bounds on delay, AoI, consecutive loss, jitter, and path risk under which, subject to Assumption 1, the physical state remains in its safe set, with explicit safety margins. Online, an optimizer—deliberately placed outside the trusted computing base—merely proposes schedules. An independent runtime safety shield [8] checks every proposal against the contracts and the current conservative risk bounds; only proposals that pass are atomically committed inside a protection window. If the optimizer times out, crashes, or produces an illegal candidate, the shield rejects it and the executor either retains the still-valid previous schedule or switches to a pre-verified fallback: a backup network plan, a degraded control mode, or a fail-safe action. Safety rests on the small verifier, not on the large optimizer [9,10]. This deterministic argument also assumes correct, uncompromised operation of the remaining trusted computing base.

Relative to security- and trust-aware TSN scheduling—instantiated in our evaluation by the security-aware TSN (SA-TSN) baseline (Section 6.3), which follows the published dependability- and security-aware co-synthesis of Reusch et al. [11] extended with dynamic trust—the delta is architectural, not incremental. The shield, the fallback library, and the atomic executor are modular and could in principle be retrofitted onto such a scheduler; the ablation variants “− safety shield” and “− fallback library” in the ablation study (Section 6.11) approximate such partial grafts and still incur 5.4% and 4.9% violations, respectively. The remaining gap requires what cannot be grafted: the contract interface ${\mathcal{C}}_k$ replaces the deadline-only task abstraction of that family, and the margin coupling of Equation (4) requires plant-margin feedback that its architecture does not carry. Exp3 (Section 6.6) quantifies the same boundary from the risk side: SA-TSN’s worst-hop aggregation transplanted into the full ZTSafe stack still incurs 3.9% violations versus 0.9% for the complete design.

1.3. Contributions

This paper makes four contributions.

• Control safety contracts from zero-trust risk. We define a per-loop contract ${\mathcal{C}}_k=({\overline{D}}_k,{\overline{A}}_k,{\overline{B}}_k,{\overline{J}}_k,{\overline{R}}_k,{\mathcal{S}}_k)$ and an offline synthesis procedure (Algorithm 1) that derives its bounds from closed-loop reachability under worst-case disturbances, with a three-way split into theoretical bounds, engineering-calibrated bounds, and explicit safety margins. A dynamic coupling makes the admissible path-risk budget ${\overline{R}}_k\left(t\right)$ shrink as the plant’s runtime safety margin $m_k\left(t\right)$ shrinks.
• A verified-execution architecture with an untrusted optimizer. ZTSafe’s trusted computing base contains only the evidence interface, the contract checker (runtime shield), the fallback library, and the atomic commit controller. The shield validates nine properties of every candidate schedule and outputs accept, reject, or fallback; the two-phase, precision time protocol (PTP)-aligned commit guarantees that the network always runs a complete old, complete new, or complete fallback configuration—never a mixture. Throughout, “verified” denotes acceptance by this independent runtime checker; machine-checked verification of the checker implementation is not claimed.
• Fail-safe guarantees. Under Assumption 1, including correct and uncompromised operation of the remaining trusted base, we prove that shield-accepted schedules keep every admitted critical loop inside its safe set (Theorem 1), that solver failure never causes an unverified configuration to execute (Theorem 2), and that recovery completes within provable per-path budget sums (17.0 ms on the normal path and 16.5 ms on the timeout path with our deployed stage budgets).
• Hardware evaluation against physical—not only network—metrics. On a testbed of eight TSN switches and three physical control loops (water level, motor speed, heading) under fourteen attack and fault scenarios, ZTSafe reduces safe-set violations from 12.8% (strongest baseline) to 0.9%, holds AoI at 0.87× its contract, recovers within three control periods, and executes zero unverified configurations across 10,000 injected solver failures, at an explicit and quantified cost of 1.8 percentage points of on-time completion.

Algorithm 1: Communication safety contract synthesis (offline, per loop k)

The remainder of the paper is organized as follows. Section 2 surveys related work; Section 3 defines the system, threat, and problem models; Section 4 synthesizes contracts; Section 5 presents the ZTSafe design together with its formal guarantees; Section 6 describes the implementation and evaluation; and Section 7 discusses limitations and concludes.

2. Background and Related Work

2.1. TSN and Joint Routing and Scheduling

IEEE 802.1AS provides sub-microsecond time synchronization [12], and 802.1Qbv enforces time-aware gates whose gate control lists (GCLs) give per-flow deterministic latency [4]. Computing GCLs is a joint routing-and-scheduling problem, tackled with SMT and ILP formulations [6,7] and, for dynamic environments, with runtime schedule reconfiguration [13]. Security analyses of TSN itself have begun to appear [14]. Across this line of work, the control application is abstracted as a period and a deadline: traditional TSN scheduling compresses control requirements into timing constraints that carry no dynamic security risk and no notion of physical state.

2.2. Zero-Trust and Trust-Aware Networking

Zero-trust architecture replaces perimeter trust with continuous verification and dynamic authorization [2,3,15], realized in networks as micro-segmentation, per-flow admission, and trust-aware SDN routing [16]. Trust management itself is attackable—on–off strategies let a compromised node rebuild its reputation between misbehaviors [17]—which motivates conservative, uncertainty-aware risk estimates rather than point scores. The field has moved quickly in the last three years: NIST’s practice guide SP 1800-35 distills reference deployments of zero-trust architectures [18], and Zanasi et al. demonstrate flexible zero-trust segmentation tailored to industrial IoT infrastructures [19]; none of these efforts, however, connects admission decisions to physical-process safety. Closest to ZTSafe, security- and dependability-aware TSN synthesis carries security constraints and overheads—authentication schedules, redundant disjoint routes—into joint routing and scheduling for control applications [11,20], demonstrating that security requirements can shape frame-level TSN decisions. Such schemes decide whether and how a low-trust flow enters the deterministic network; ZTSafe addresses what they leave open: guaranteeing that whatever the network decides, the physical process stays safe—and that the decision machinery itself is allowed to fail.

2.3. Networked Control Under Delay and Loss

Networked control theory characterizes stability under delay and packet loss [21,22,23], and set-invariance methods—robust positively invariant sets and control barrier functions—certify that a constrained state never leaves a safe region under bounded disturbance [24,25]. Event-triggered control reduces network load while preserving stability [26,27], and control-aware TSN scheduling optimizes control cost when synthesizing GCLs [28]. This literature treats network degradation as an exogenous disturbance; it does not model degradation that is deliberately and repeatedly triggered by a security policy—rerouting, isolation, admission changes—as ZTSafe must.

2.4. Age of Information in Industrial Control

AoI measures the freshness of the newest delivered sample rather than per-packet latency [5,29], and AoI-aware scheduling demonstrably outperforms delay-aware scheduling for control loops [30]. Low latency does not imply fresh data: a path can meet every deadline while delivering measurements buffered upstream—exactly the failure of Figure 1. ZTSafe therefore constrains not only delay but also AoI in every contract.

2.5. Runtime Assurance and Safety Shields

The Simplex architecture pioneered the pattern of an unverified high-performance controller guarded by a verified safety controller and a decision module [31,32], extended with real-time reachability [33] and shielding for learned policies [8]. In networking, consistent-update abstractions guarantee that a packet sees either the old or the new configuration, never a mixture [34]. Concretely, Reitblatt et al. formalize per-packet consistency and realize it by two-phase, versioned rule installation: new rules are pre-installed inactive, packets are stamped with a configuration version at ingress, and the switch applies exactly the rule set matching the stamp, so no packet ever traverses a mixture of old and new state. ZTSafe transplants this discipline from SDN rule tables to time-triggered GCLs, where the prepare/commit protocol of Section 5.7 plays the role of versioned installation and the PTP-aligned guard window provides the atomic activation instant for an entire control-loop iteration. Network scheduling, however, rarely treats the solver output as an untrusted proposal that must be independently verified before execution; ZTSafe imports the Simplex discipline into zero-trust TSN reconfiguration.

2.6. Comparison

Table 1 positions ZTSafe along six dimensions. No prior approach combines dynamic risk, TSN determinism, AoI/loss contracts, physical-safety guarantees, solver-failure fallback, and atomic switching; ZTSafe is designed to provide all six simultaneously, and Section 6 evaluates each dimension against the strongest representative of each row.

Table 1. Comparison with related approaches.

Approach	Dynamic Risk	TSN Det.	AoI/Loss Contract	Physical Safety	Fallback on Solver Failure	Atomic Switch
QoS-TSN scheduling [6,7]	No	Yes	Limited 1	No	No	Partial
Control-aware TSN [28]	No	Yes	Limited 1	Partial	No	Partial
Zero-trust SDN [16]	Yes	No	No	No	No	Partial
Security-aware TSN [11,20]	Yes	Yes	Limited	Indirect	Limited	Yes
ZTSafe (Proposed)	Yes	Yes	Yes	Yes	Yes	Yes

¹ “Limited”: the scheduler bounds per-frame delay (QoS-TSN) or optimizes an aggregate control cost (control-aware TSN), but neither enforces per-loop AoI, consecutive-loss, or jitter bounds as hard admission constraints, and neither carries certified safety margins. TSN: time-sensitive networking; SDN: software-defined networking; Det.: determinism; AoI: age of information; QoS: quality of service.

3. System Model, Threat Model, and Problem Definition

Table 2 collects the essential symbols the reader needs throughout; the complete notation, grouped into network, risk, and control symbols, is listed in Appendix A (Table A1) to keep the main text compact.

Table 2. Essential symbols (the complete notation is listed in Appendix A, Table A1).

Symbol	Meaning
${\mathcal{C}}_k=({\overline{D}}_k,{\overline{A}}_k,{\overline{B}}_k,{\overline{J}}_k,{\overline{R}}_k,{\mathcal{S}}_k)$	Per-loop communication safety contract: delay, AoI, burst-loss, jitter, and path-risk bounds; safe set
${\mathcal{E}}_k$	Safe envelope: the set of degradation-bound tuples certified by closed-loop reachability
${\overline{r}}_i^t$	Conservative (uncertainty- and staleness-inflated) risk upper bound of node i
$R\left(P\right)$, ${\overline{R}}_k\left(t\right)$	Aggregated path risk; margin-coupled dynamic risk budget
$m_k\left(t\right)$	Runtime safety margin of loop k: distance of the state to the safe-set boundary
${\mathrm{\Pi }}^t$; $T_d,T_r,T_v,T_c$	Active schedule; evidence, repair, verification, and commit stage budgets

3.1. Network and Task Model

The network is a graph $G=(V,E)$ of TSN switches and end stations connected by full-duplex links with known propagation and per-hop processing delays, time-synchronized by IEEE 802.1AS with synchronization error bounded by ${ϵ}_{\mathrm{sync}}$. Time is slotted; 802.1Qbv gates open and close per the GCL. A task (stream) $k=(s_k,d_k,T_k,L_k,{\mathcal{C}}_k)$ releases one frame of size $L_k$ every period $T_k$ from source $s_k$ to destination $d_k$. Critical tasks carry a contract ${\mathcal{C}}_k$; best-effort tasks do not. The scheduler assigns each admitted task one path ($z_{k,p}$) and a set of time slots on each traversed link ($y_{k,e,\tau }$).

3.2. Physical Loop Model and Contracts

Each critical task belongs to a control loop k whose sampled dynamics are

$$x_{k,t+1}=A_k{x}_{k,t}+B_k{u}_{k,t}+E_k{w}_{k,t},w_{k,t}\in {\mathcal{W}}_k,$$

(1)

with bounded disturbance set ${\mathcal{W}}_k$ and safe set ${\mathcal{S}}_k=\{x:h_{k,j}\left(x\right)\ge 0,j=1,\dots ,J_k\}$. The loop’s tolerance to network degradation is captured by the six-tuple contract

$${\mathcal{C}}_k=({\overline{D}}_k,{\overline{A}}_k,{\overline{B}}_k,{\overline{J}}_k,{\overline{R}}_k,{\mathcal{S}}_k):$$

(2)

maximum end-to-end delay ${\overline{D}}_k$, maximum age of information at use ${\overline{A}}_k$, maximum consecutive lost updates ${\overline{B}}_k$, maximum delivery jitter ${\overline{J}}_k$, maximum aggregated path risk ${\overline{R}}_k$, and the safe set itself. We emphasize what a contract is not: it is not a QoS class picked from network experience. Every bound is computed offline from the control model—by identification, reachability analysis, or closed-loop simulation—so that compliance with ${\mathcal{C}}_k$ implies an explicit physical-safety argument (Section 4).

3.3. Zero-Trust Evidence Interface

Every node i exposes an evidence vector $z_i^t=(a_i^t,b_i^t,f_i^t,u_i^t)$: authentication assurance $a_i^t$ (credential state, attestation results, per-frame MAC verification), behavioral anomaly $b_i^t$ (traffic and timing deviation, replay indicators such as stale sequence numbers [35]), fault indicators $f_i^t$ (loss, CRC errors, link flaps), and utilization $u_i^t$. Evidence is produced by an external zero-trust stack; in our deployment, credential state comes from a hardware-rooted credential service with revocation-consistent identity assurance, and the interface is deliberately provider-agnostic. From the evidence, ZTSafe maintains an instantaneous risk $\varphi \left(z_i^t\right)=g(1-a_i^t,b_i^t,f_i^t,u_i^t)$ with g monotone in each argument, and a conservative upper bound ${\overline{r}}_i^t$ (Section 5.2). Path risk is aggregated as $R\left(P\right)$; the candidate aggregators are the worst hop $R_{\max }\left(P\right)={\max }_{i\in P}{\overline{r}}_i^t$ (the worst-hop aggregation used by security-aware scheduling baselines [11,20], the cumulative form $R_{\mathrm{\Sigma }}\left(P\right)=1-{\prod }_{i\in P}(1-{\overline{r}}_i^t)$, and conditional value at risk (CVaR) at level 0.9 over the per-hop bounds [36]. We treat the aggregator as a comparable design choice, evaluated head-to-head in Section 6.6, not as the innovation itself.

3.4. Threat Model

We assume an adversary who can:

• Compromise end devices that hold valid credentials and produce correctly authenticated traffic;
• Replay stale measurements whose cryptographic tags verify [1];
• Inject burst traffic from compromised devices into the control path;
• Selectively delay frames traversing a compromised switch;
• Selectively drop frames, including consecutive drops targeted at one loop;
• Mount on–off attacks that alternate misbehavior and good conduct to game reputation [17];
• Suppress or locally forge the evidence emitted by nodes it controls;
• Time its actions to coincide with reconfiguration windows;
• Craft workloads that drive the online optimizer toward timeout or infeasibility;
• Combine any of the above across multiple nodes.

Out of scope are: (i) compromise of the trusted computing base itself (shield, contract library, commit controller, and the PTP grandmaster); (ii) physical destruction of plant equipment outside the network’s influence; (iii) cryptanalysis of the underlying primitives; and (iv) attacks on the time base beyond the bounded synchronization error ${ϵ}_{\mathrm{sync}}$, which we assume is enforced and monitored by complementary mechanisms.

These exclusions are assumptions to be enforced, not claims of invulnerability. The deployment hardens the TCB along four axes: (i) the shield, contract library, fallback store, and commit controller run on a dedicated host with measured boot and trusted platform module (TPM)-backed attestation, physically separated from the optimizer host; (ii) the contract and fallback stores are hash-chained and signature-verified on every load, so tampering is detected before use; (iii) the management plane is isolated on its own virtual LAN (VLAN) with 802.1Qci per-stream policing, and every shield verdict is signed and appended to a tamper-evident log; and (iv) time integrity relies on redundant grandmasters with cross-checked offsets and holdover oscillators, monitored against the ${ϵ}_{\mathrm{sync}}$ bound. Section 7 analyzes the residual risk when these defenses themselves fail—including the honest statement that a compromised shield voids the guarantees.

3.5. Design Goals

ZTSafe pursues nine goals. G1 (physical safety): Every admitted critical loop’s state remains in ${\mathcal{S}}_k$ under Assumption 1. G2 (verified execution): No configuration executes without passing independent verification by the runtime checker. G3 (atomicity): The network never runs a mixture of configurations. G4 (bounded recovery): Reaction to any trigger completes within a provable time bound. G5 (risk conservativeness): True risk exceeds its estimate with probability at most $\delta$ as an empirical calibration target, not a deterministic theorem. G6 (admission): Subject to G1–G5, admit as many critical tasks as possible. G7 (graceful degradation): When no compliant schedule exists, degrade along pre-certified fallbacks rather than improvising. G8 (freshness): Decisions use evidence and topology state of bounded staleness. G9 (performance): Admitted tasks meet their contracts with margin, not merely their deadlines.

4. Control Safety Contract Synthesis

4.1. Why Deadlines Are Not Enough: A Counterexample

Consider a control stream with a 10 ms deadline and a 15 ms AoI contract. Two candidate paths both satisfy the deadline: path A delivers in 6 ms, path B in 7 ms. Path B, however, traverses an ingress stage where a zero-trust isolation policy batches frames from downgraded sources, so the measurement inside a frame is up to 11 ms old before injection; the age at use reaches 18 ms—beyond the 15 ms contract—while every frame still arrives 3 ms before its deadline. A deadline-only scheduler considers paths A and B interchangeable; a controller fed by path B operates on state estimates whose error the safety analysis never licensed. Every contract dimension in ${\mathcal{C}}_k$ exists because a deadline cannot express it: freshness (${\overline{A}}_k$), gap tolerance (${\overline{B}}_k$), regularity (${\overline{J}}_k$), and exposure (${\overline{R}}_k$).

4.2. Offline Control Models

Contract synthesis needs a model of each loop, but not necessarily an analytic one. Any of the following suffices, in decreasing order of the strength of the resulting guarantee: (i) an LTI model (1) with polytopic disturbance bounds, enabling reachability analysis [37]; (ii) an identified model with validated error bounds, enabling robust invariance arguments [24]; or (iii) a high-fidelity simulator or digital twin, enabling exhaustive closed-loop simulation over the disturbance grid. All three produce the same artifact: a map from network-degradation parameters to a verdict on whether the closed loop stays in ${\mathcal{S}}_k$.

4.3. Safe Sets

Safe sets encode plant-level hazards as state constraints $h_{k,j}\left(x\right)\ge 0$. Our three testbed loops instantiate them concretely (Table 3): tank level within $[20,80]$ cm (overflow/dry-run protection), motor speed within $[2600,3000]$ rpm (mechanical limits), and heading error within 5° (collision corridor). The runtime safety margin of loop k is

$$m_k\left(t\right)=\underset{j}{\min }{h}_{k,j}\left(x_{k,t}\right),$$

(3)

the distance of the current state to the nearest safe-set boundary.

Table 3. Control communication contracts produced by Algorithm 1 for the three testbed loops. Each tuple is a single re-checked point on the frontier of its safe envelope (Proposition 1), not a combination of per-dimension maxima.

Loop	${\mathit{T}}_{\mathit{k}}$	${\overline{\mathit{D}}}_{\mathit{k}}$	${\overline{\mathit{A}}}_{\mathit{k}}$	${\overline{\mathit{B}}}_{\mathit{k}}$	${\overline{\mathit{J}}}_{\mathit{k}}$	${\mathit{R}}_{\mathit{k}}^{\mathbf{base}}$	Safe Set ${\mathcal{S}}_{\mathit{k}}$
Water level	20 ms	9 ms	28 ms	5	1.5 ms	0.30	level 20–80 cm
Motor speed	10 ms	2 ms	15 ms	2	0.5 ms	0.20	speed 2600–3000 rpm
Heading	20 ms	5 ms	40 ms	2	1.0 ms	0.25	heading error ≤ $5°$

4.4. Deriving the Bounds

For each loop we derive $({\overline{D}}_k,{\overline{A}}_k,{\overline{B}}_k,{\overline{J}}_k)$ in three layers (Figure 2 shows the pipeline end to end). First, theoretical bounds come from closed-loop reachability: the set of degradation tuples $(D,A,B,J)$ under which the reachable set stays inside ${\mathcal{S}}_k$ for all $w\in {\mathcal{W}}_k$—the maximal safe envelope ${\mathcal{E}}_k$ (Figure 3a). Second, engineering-calibrated bounds shrink the theoretical ones to the region validated by closed-loop simulation with the real controller code, quantization, and sensor noise. Third, an explicit safety margin $ϵ=({ϵ}_D,{ϵ}_A,{ϵ}_B,{ϵ}_J)$ absorbs clock synchronization error, execution overhead, and model mismatch: the contract is ${\overline{D}}_k=D_{\mathrm{safe}}^{\max }-{ϵ}_D$ and analogous for the other bounds, and the scheduler additionally targets $D_k^{\mathrm{sched}}\le {\overline{D}}_k-{ϵ}_D^{\prime }$ so that runtime operation sits strictly inside the certified region. The AoI bound ${\overline{A}}_k$ and the burst bound ${\overline{B}}_k$ deliberately capture different degradation modes—the staleness of what arrives, and the gaps when nothing arrives—and the synthesis explores their joint worst case rather than treating them independently.

Figure 2. Offline contract-synthesis pipeline (Algorithm 1): From control model and safety specifications, through parameter sweep and reachability-based safety evaluation, to the maximal safe envelope, single-frontier-point selection with margins, and the output contract; the lower strip shows the runtime margin-to-budget coupling of Equation (4). Large arrows between panels indicate the successive synthesis steps; in the lower strip, the green and purple arrows show how the measured safety margin drives the risk budget and, in turn, the scheduling constraint. In step 3, the dashed purple boundary is the closed-loop reachable set and the grey shading the unsafe region.

Figure 3. Safety envelope and contract example. (a) Two-dimensional cut of a safety envelope with the margin-shrunk contract box; (b) within-contract vs. contract-violated state trajectories; (c) the resulting water-level contract used on our testbed. In (a), the solid green boundary is the maximal safe envelope, the dashed green boundary the margin-shrunk contract envelope, the grey shading the unsafe region, and the blue dotted lines the selected contract bounds; in (b), green marks the within-contract (safe) trajectory and red the contract-violated one.

Proposition 1 (Downward closure of the safe envelope).

${\mathcal{E}}_k$ is downward-closed: if $c=(D,A,B,J)\in {\mathcal{E}}_k$ and $c^{\prime }\le c$ componentwise, then $c^{\prime }\in {\mathcal{E}}_k$.

Proof. 

Membership in ${\mathcal{E}}_k$ is evaluated on bounds: the reachable set computed in Algorithm 1 is taken over all degradation behaviors with delay ≤ $D$, age ≤ $A$, at most B consecutive losses, and jitter ≤ $J$. Every behavior admissible under $c^{\prime }$ is admissible under c, so the reachable set under $c^{\prime }$ is contained in the one under c, which lies in ${\mathcal{S}}_k$. □

Two consequences pin down the contract semantics precisely. First, a contract denotes the box $[0,{\overline{D}}_k]\times [0,{\overline{A}}_k]\times [0,{\overline{B}}_k]\times [0,{\overline{J}}_k]$: the synthesis selects a single certified point on the frontier of ${\mathcal{E}}_k$ (Algorithm 1, lines 5–7) and, because ${\mathcal{E}}_k$ is downward-closed, the entire box below that point lies inside ${\mathcal{E}}_k$. The guarantee never rests on combining per-dimension maxima drawn from different frontier points—a combination that would in general leave the safe region, since a loop can tolerate a high delay only while the age is small. Second, the margin shrink (line 8) moves the certified corner componentwise downward, so the shrunk box remains inside ${\mathcal{E}}_k$ by the same argument; line 7 additionally re-verifies the selected corner with a direct reachability call, as a defense against implementation faults in the frontier search itself.

The margins are measured, not tuned. We compose ${ϵ}_D=2{ϵ}_{\mathrm{sync}}+{ϵ}_{\mathrm{exec}}+{ϵ}_{\mathrm{model}}$: ${ϵ}_{\mathrm{sync}}$ is the P99.9 PTP offset taken from grandmaster statistics (<1 μs on our testbed, doubled to cover both endpoints); ${ϵ}_{\mathrm{exec}}$ is the P99.9 stack-traversal and gate-release overhead from worst-case execution time (WCET) profiling of the end stations; and ${ϵ}_{\mathrm{model}}$ propagates the plant-identification residual through the reachability analysis—the residual bound enters as an additional disturbance, and the resulting inward shift of the ${\mathcal{E}}_k$ boundary is charged to the margin. ${ϵ}_A$ adds one consumer phase to the same composition; ${ϵ}_J$ doubles the synchronization term; and ${ϵ}_B$ is zero because loss counts are integer. Section 6.9 reports the companion sensitivity sweep over the margin scale: halving all margins roughly doubles residual violations, while doubling them costs about 4.5 percentage points of task admission, bracketing the deployed operating point.

Offline contracts remain valid only while the plant stays inside its modeled envelope, so drift is a first-class concern. Bounded drift is absorbed by construction: ${ϵ}_{\mathrm{model}}$ is sized for a declared drift envelope $\parallel \Delta A_k\parallel \le {\gamma }_k$ (aging, environmental variation, calibration drift), and the reachability step certifies the contract for every model in that envelope. Three monitors guard it at runtime: (i) a recursive-identification residual exceeding ${\gamma }_k/2$ flags the loop for contract re-synthesis; (ii) a sustained mismatch between measured margin trajectories $m_k\left(t\right)$ and model predictions raises the same flag; and (iii) scheduled maintenance recalibration re-runs Algorithm 1 regardless. Re-synthesized contracts are versioned and swapped atomically exactly like schedules (Section 5.7), so a contract update can never yield a mixed configuration.

4.5. Coupling the Risk Budget to the Physical Margin

The fifth bound, ${\overline{R}}_k$, is where zero-trust evidence meets control safety, and it is deliberately dynamic. A loop operating mid-range can afford to route through moderately risky nodes; the same loop grazing its safe-set boundary cannot. ZTSafe scales the base risk budget by the normalized runtime margin:

$${\overline{R}}_k\left(t\right)=R_k^{\mathrm{base}}·\mathrm{clip}\left({\displaystyle \frac{m_k\left(t\right)}{m_k^{\mathrm{nom}}}},R_k^{\min },1\right),$$

(4)

where $m_k^{\mathrm{nom}}$ is the nominal margin and $R_k^{\min }$ floors the budget so that transient measurement spikes cannot zero it out. The coupling closes a loop that Gap 1 identified as missing: the physical state, through its margin, modulates how much network-level risk the scheduler may accept on that loop’s behalf—a risk bound of $0.72$ now has an operational meaning that depends, correctly, on how close the water level is to the rim.

The role of the risk budget in the safety argument deserves a precise statement, because it differs in kind from the four reachability-certified bounds.

Proposition 2 (Role of the path-risk bound).

Let loop k be scheduled on a path P with $R\left(P\right)\le {\overline{R}}_k\left(t\right)$, and let the calibrated coverage property of Equation (13) hold. Then the probability that adversarial behavior on P drives the realized degradation tuple of loop k outside the certified box of ${\mathcal{C}}_k$ within one decision epoch is at most ${\overline{R}}_k\left(t\right)+\delta$.

Proof. 

A safety violation requires an out-of-box excursion: while degradation remains inside the box, Theorem 1 keeps the state in ${\mathcal{S}}_k$. An out-of-box excursion within an epoch requires at least one element of P to deviate from its verified scheduled behavior. Whenever every true per-node risk is bounded by its estimate—which the coverage property guarantees except on a set of probability at most $\delta$—the aggregations of Section 3 bound the probability of such a deviation on P by $R\left(P\right)$. A union bound gives $R\left(P\right)+\delta \le {\overline{R}}_k\left(t\right)+\delta$. □

The division of labor is thus explicit. The box $({\overline{D}}_k,{\overline{A}}_k,{\overline{B}}_k,{\overline{J}}_k)$ carries the deterministic invariance certificate of Theorem 1; the risk budget is a calibrated stochastic envelope bounding how often an adversary can force the system outside the regime where that certificate applies; and the fallback machinery bounds what happens when it succeeds. ${\overline{R}}_k$ is neither a reachability variable nor an arbitrary policy: it converts calibrated detection quality into a bound on certificate-breaking frequency, and its isolated empirical contribution is quantified in Exp3 (Section 6.6).The base budgets in Table 3 are likewise derived, not chosen. With $\mu$ the fraction of nominal margin reserved for security-induced excursions (we use $\mu =1/3$), $\Delta m_k^{\max }$ the worst-case fraction of nominal margin consumed by a single excursion before fallback completes (measured in hardware-in-the-loop campaigns: 0.11, 0.17, and 0.13 for the water, motor, and heading loops), and $H=10$ decision epochs per recovery horizon,

$$R_k^{\mathrm{base}}={\displaystyle \frac{\mu }{\Delta m_k^{\max }H}},$$

(5)

which, rounded to the deployed 0.05 granularity, gives 0.30, 0.20, and 0.25 for the three loops: the loop that loses margin fastest per excursion receives the smallest budget. The values are physically grounded in that sustained attack pressure at the full budget consumes, in expectation, no more than the reserved third of the margin per recovery horizon.

4.6. Synthesis Algorithm

Algorithm 1 summarizes the six-step synthesis. Its output for our three testbed loops is Table 3; the water-level instance is visualized in Figure 3c. The envelope boundary in Figure 3a is the algorithm’s step-4 output: the contract is an offline-proven safe region, not an empirically tuned number.

5. ZTSafe Design and Formal Guarantees

5.1. Architecture Overview

Figure 4 shows the architecture; Figure 5 details the data flow through its five subsystems. The design decision that everything else follows from is this: the optimizer is not in the trusted computing base; the trusted base contains only the evidence verification interface, the contract checker, the fallback library, and the atomic commit controller. The optimizer may be arbitrarily sophisticated, arbitrarily buggy, or arbitrarily under attack—the safety argument never references its internals, only the shield’s checks on its outputs. Conditional safety is established by shield-accepted execution under Assumption 1, rather than by trusting the optimizer; the argument does, however, require the remaining trusted base to behave correctly and remain uncompromised.

Figure 4. ZTSafe architecture. Evidence flows into a conservative risk estimator inside the trusted computing base (TCB, shaded); the online optimizer proposes schedules from outside the TCB; the safety shield checks each proposal against the contract library; only a shield-accepted (“verified”) plan or pre-checked (“certified”) fallback reaches the atomic TSN executor. The physical process feeds its safety margin $m_k\left(t\right)$ back into the risk budget. The green check and orange cross mark the shield’s accept and reject outcomes; shield icons mark trusted checking components.

Figure 5. Detailed ZTSafe data flow: (A) Zero-trust evidence collection; (B) the untrusted optimizer with hierarchical objectives and incremental solving; (C) the trusted runtime checker (not a machine-verified implementation) and its decision outcomes; (D) two-phase atomic execution on the TSN data plane; and the pre-checked fallback library with its triggers. Arrow colors and styles follow the flow legend at the bottom of the figure. GCL: gate control list; CVaR: conditional value at risk.

5.2. Conservative Risk Estimation

Point estimates of risk are exactly what an on–off adversary manipulates. ZTSafe therefore schedules against an upper bound. The smoothed estimate follows the evidence,

$${\widehat{r}}_i^t=\alpha {\widehat{r}}_i^{t-1}+(1-\alpha )\varphi \left(z_i^t\right),$$

(6)

and the bound inflates it by uncertainty and staleness:

$${\overline{r}}_i^t=\min \left(1,{\widehat{r}}_i^t+\beta {\sigma }_i^t+\lambda F_i^t\right),$$

(7)

where ${\sigma }_i^t$ measures evidence dispersion and quantity, $F_i^t$ the age of the newest evidence, and $\beta ,\lambda$ are conservativeness weights. Three properties follow by construction: (i) missing evidence is not safety—if a node stops reporting, $F_i^t$ grows and its bound rises toward 1; (ii) older is riskier—the bound is monotonically non-decreasing in staleness; and (iii) uncertainty is penalized—two nodes with equal $\widehat{r}$ but different evidence quality receive different bounds. Section 6.9 sweeps $\beta$ and shows the resulting safety–admission trade-off; Section 5.9.3 reports how often the bound is violated in practice.

5.3. Risk-Constrained Joint Routing and Scheduling

The optimizer solves, over path variables $z_{k,p}$ and slot variables $y_{k,e,\tau }$, a lexicographic problem—safety feasibility ≻ critical admission ≻ performance:

• Safety feasibility (hard constraints). For every admitted critical task: end-to-end delay ≤ ${\overline{D}}_k-{ϵ}_D^{\prime }$; worst-case AoI ≤ ${\overline{A}}_k$; consecutive-loss exposure ≤ ${\overline{B}}_k$ under the current loss model; jitter ≤ ${\overline{J}}_k$; and aggregated path risk $R\left(P_k\right)\le {\overline{R}}_k\left(t\right)$ with the dynamic budget (4). These are never traded against the objectives below.
• Critical admission. Maximize ${\sum }_k{q}_k{a}_k$, where $a_k\in \{0,1\}$ admits task k and $q_k$ encodes criticality.
• Performance. Minimize ${\sum }_k\left(w_D{D}_k+w_A{A}_k\right)+w_R{\sum }_{k}R\left(P_k\right)+w_S{S}^{\mathrm{switch}}$, penalizing delay, age, residual risk, and the number of reconfigured flows $S^{\mathrm{switch}}$ (schedule churn is itself a disturbance).

The TSN constraints are standard—single path per task, slot conflict-freedom per link, gate feasibility, isolation between critical and best-effort queues [6]—and we do not innovate on them. The formulation is deliberately conventional; what is new is where its output goes: to a verifier, not to the network.

5.4. Incremental Online Solving

A word on why failure handling is structural rather than defensive over-engineering. Joint routing and gate scheduling of time-triggered flows is NP-hard—scheduling alone reduces from job-shop scheduling, and exact integer linear programming (ILP) formulations hit practical limits at a few tens of flows even offline [6,7]—so a hard real-time budget of 10 ms cannot come with a completeness promise. Four conditions reliably push the solver toward timeout or infeasibility on our testbed, and an adversary can induce three of them: (i) critical-flow density near link capacity, where the feasible region thins; (ii) risk pruning that cuts graph connectivity, forcing many flows to be rerouted simultaneously through a narrow residual graph; (iii) adversarial churn—evidence oscillation or task arrival patterns crafted to trigger repeated repairs, the scheduling analogue of algorithmic-complexity attacks [38], exercised as scenario S10; and (iv) topology events that invalidate many paths at once. Treating “no verified schedule in time” as a first-class, certified outcome is the design consequence.

Global re-solving on every evidence update is neither necessary nor, at scale, possible (Section 6.10). The solver runs three stages under a hard time budget $T_{\mathrm{timeout}}$: (i) risk pruning removes nodes and links whose bound ${\overline{r}}_i^t$ already exceeds every applicable budget, shrinking the search space before optimization begins; (ii) incremental repair starts from the previous verified schedule ${\mathrm{\Pi }}^{t-1}$ and re-solves only the tasks affected by the triggering event (a changed risk bound, a failed link), keeping all other assignments frozen; and (iii) bounded optimization improves the repaired schedule until the budget expires, at which point the best feasible candidate found so far is emitted. At every instant the executor holds at least one schedule that has already passed shield validation; the optimizer can only ever replace it with a better verified one. Solver failure is therefore never an emergency—it merely means the incumbent stays active (Section 5.6).

5.5. Independent Runtime Safety Shield

The shield is the heart of the TCB: a deterministic checker that verifies candidates and never optimizes. Figure 6 places it in the runtime pipeline with its per-stage time budgets. For every candidate $(\mathrm{\Pi },v,\mathrm{meta})$—schedule, risk version, metadata—the shield validates nine properties:

Figure 6. Runtime pipeline with per-stage budgets: evidence ($T_d$), incremental repair ($T_r$), shield validation ($T_v$, nine checks), and atomic commit ($T_c$); the fallback path is bounded by $T_v^F$ and the solver by $T_{\mathrm{timeout}}$. The composition of these budgets yields the normal-path and timeout-path recovery bounds of Section 5.9.2, Equations (11) and (12); the panel’s internal “Theorem 1/2” annotations refer to these two bounds. Only shield-accepted plans or pre-checked fallbacks can be committed.

• Every admitted task has a complete source-to-destination path;
• Every critical path satisfies its risk budget $R\left(P_k\right)\le {\overline{R}}_k\left(t\right)$;
• Delay and AoI bounds hold with the required margins;
• Burst-loss and jitter bounds hold;
• Slot assignments are conflict-free on every link;
• The risk version v is current (bounds have not moved since solving began);
• The topology version is current (no link state change since solving began);
• No safety-critical task has been silently dropped or downgraded relative to ${\mathrm{\Pi }}^{t-1}$;
• The change set is atomically committable within one protection window.

The verdict is accept (forward to the executor), reject (retain the incumbent), or fallback (the incumbent is also no longer valid—e.g., its path traverses a newly failed link—so a fallback entry must be activated).

Checks 3–4 are exact evaluations rather than heuristics, and their formal content strengthens reproducibility. For each admitted critical task k with path $P_k$ and slot offsets $\sigma$: the end-to-end delay $D_k\left(\mathrm{\Pi }\right)$ is summed directly from assigned slots and link latencies; the worst-case age at use under b consecutive losses is

$$A_k^{\left(b\right)}\left(\mathrm{\Pi }\right)=\left({\sigma }_k^{\mathrm{use}}-{\sigma }_k^{\mathrm{smp}}\right)+b{T}_k,$$

(8)

and check 3 requires the pair $\left(A_k^{\left(b\right)}\left(\mathrm{\Pi }\right),b\right)$ to lie inside the contract box for every $b\in \{0,\dots ,{\overline{B}}_k\}$—the joint age–loss worst case, not two independent scalars; the consecutive-loss exposure

$$B_k\left(\mathrm{\Pi }\right)=\underset{c\in \mathcal{Q}\left(P_k\right)}{\max }{\ell }_k\left(c\right),$$

(9)

where ${\ell }_k\left(c\right)$ is the longest run of consecutive releases of k whose only scheduled transmission opportunity traverses element c, is taken over the fault-equivalence classes $\mathcal{Q}\left(P_k\right)$ (links, switches) of the path and must not exceed ${\overline{B}}_k$; and the release-to-delivery jitter

$$J_k\left(\mathrm{\Pi }\right)=\underset{r}{\max }{d}_k^{\left(r\right)}-\underset{r}{\min }{d}_k^{\left(r\right)}\le {\overline{J}}_k$$

(10)

ranges over the per-release latencies $d_k^{\left(r\right)}$ of one hyperperiod. All three are computed from the candidate and the topology database alone, which is what makes the shield a deterministic checker.

Verification is linear in the schedule size: across every verification call of the failure-injection campaign it completes in 0.9 ms on average (P99 1.4 ms) at the 24-flow hardware scale—well inside its $T_v=3$ ms budget—and in 9.8 ms at the 1000-flow simulation scale (Section 6.10); its budget $T_v$ enters the recovery bound of Section 5.9.2.

5.6. Certified Fallback Library

When no contract-compliant schedule exists—or none can be found in time—ZTSafe does not improvise. A library of pre-verified fallback entries $F_j$ = (trigger, plan, mode, validity) is synthesized and shield-validated offline, in three escalating classes:

• F1—backup network plan: An alternative routing and GCL for the current task set, precomputed for the most probable failure patterns (single-link loss, single-switch isolation);
• F2—degraded control mode: The loop switches to a mode needing less of the network: halved sampling (e.g., motor loop from 10 to 20 ms with a locally retuned controller), local/embedded control, frozen setpoints, or suspension of maintenance-class traffic;
• F3—fail-safe action: Valves to safe position, speed ramp-down, hold last safe command, or controlled stop—the mode of last resort whose safety does not depend on the network at all.

Each entry records its validity conditions (topology version range, applicable fault set, contract hash) and is periodically re-certified against the current contract library. At runtime, fallback selection is a lookup—trigger matching plus validity check ($T_v^F\le 2.5$ ms)—never a synthesis.

The library does not attempt combinatorial completeness over failure patterns, and saying so precisely matters. Coverage is hierarchical: F1 entries are indexed by fault-equivalence class (per link, per switch), so their count grows linearly in network components rather than exponentially in failure combinations; F2 and F3 entries are per loop and network-independent, so they compose freely across loops—degrading loop k never invalidates the fallback of loop $k^{\prime }$, and a multi-loop response is assembled compositionally from per-loop entries. Selection is therefore total even though F1 coverage is partial: for any pattern outside the F1 index the selector composes per-loop F2 modes, and where even their validity conditions fail, the per-loop F3 action applies unconditionally, because its safety does not depend on network state at all. The guarantee is thus totality with graceful degradation—some certified response exists for every failure pattern—while optimality (remaining on F1 rather than escalating) is guaranteed only for indexed patterns. Exp4 (Section 6.7) shows empirically how rarely escalation beyond F1 occurs (F2 2.6% and F3 0.3% of failures).

5.7. Atomic Reconfiguration

Applying a new GCL switch-by-switch creates windows where old and new schedules coexist; frames then race gates that were computed for a different world—transient blackholes, AoI spikes, and loss bursts (quantified in Section 6.8). ZTSafe commits in two PTP-aligned phases: prepare loads the new configuration to every affected device in inactive state and collects acknowledgments and commit activates all devices at the same protection-window boundary, a guard band in which no critical frame is in flight. If any critical device fails to acknowledge preparation, three branches apply: (i) before the point of no return, the commit aborts and the incumbent remains active—staged configurations are inert by construction; (ii) if the window passes without full acknowledgment, the staged configuration is discarded and the optimizer may retry with the failed device excluded; and (iii) if a device fails during activation, the executor immediately commits the matching F1 fallback (or F3 if no fallback’s validity covers the failure), again atomically. No partial mixture is ever active (Section 5.9.1).

5.8. Event-Triggered Repair

Reconfiguration is triggered by events, not timers, and repairs only what the event touches. Seven conditions trigger the pipeline of Figure 7: (1) a risk bound crosses a budget on an active path; (2) a loop’s safety margin $m_k\left(t\right)$ falls below its coupling threshold, shrinking ${\overline{R}}_k\left(t\right)$; (3) evidence staleness $F_i^t$ exceeds its limit on a node carrying critical traffic; (4) a topology change (link or switch down/up); (5) arrival or departure of a critical task; (6) expiry of the periodic re-validation timer (a backstop, not the primary mechanism); and (7) a recovery opportunity—the system is on a fallback and a normal schedule has become feasible again. Triggers 1–3 are the zero-trust path: they originate in evidence, and their end-to-end latency to a committed safe response is the recovery bound of Section 5.9.2.

Figure 7. Runtime workflow across the five components. Top: normal flow—evidence update, incremental repair, shield validation, two-phase atomic commit. Bottom: solver-failure flow—timeout, crash, or illegal candidate leads to rejection and a pre-checked fallback commit; the physical state remains within ${\mathcal{S}}_k$ on both paths under Assumption 1 and correct trusted-base operation. Annotated stage times are typical L1 values; Section 6 reports the measured distributions. Arrow colors follow the in-figure flow legend (green: data and accept decisions; blue: proposals; red: failure or reject; black: execution); orange arrows mark fallback selection and commit.

5.9. Formal Guarantees

We now make precise what the design above guarantees and, just as importantly, under which assumptions. Throughout, “the shield accepts” means all nine checks of Section 5.5 pass. The theorem-level implications below are deterministic once their premises hold; the empirical coverage probability of Equation (13) is a separate risk-estimation claim.

Assumption 1. 

For each admitted critical loop k: the model (1) over-approximates the true dynamics with disturbance $w_{k,t}\in {\mathcal{W}}_k$; sensors and actuators are functional and their errors are absorbed in ${\mathcal{W}}_k$; the synchronization error is bounded by ${ϵ}_{\mathrm{sync}}\le \min ({ϵ}_D,{ϵ}_J)$; and the contract ${\mathcal{C}}_k$ was produced by Algorithm 1 under these conditions. The runtime shield, contract and fallback stores, atomic commit controller, and PTP grandmaster execute their specified logic and are not compromised.

Lemma 1 (Contract compliance).

If the shield accepts a candidate schedule $\mathrm{\Pi }$, then under $\mathrm{\Pi }$ every admitted critical task k satisfies all bounds of ${\mathcal{C}}_k$: delay $\le {\overline{D}}_k$, AoI $\le {\overline{A}}_k$, consecutive losses $\le {\overline{B}}_k$, jitter $\le {\overline{J}}_k$, and path risk $\le {\overline{R}}_k\left(t\right)$.

Proof. 

Each bound corresponds to one shield check (checks 2–4), evaluated on the complete paths guaranteed by check 1, against risk and topology state that checks 6–7 certify as current. The checks are direct constraint evaluations on $\mathrm{\Pi }$, not heuristics; acceptance therefore implies each inequality by construction. □

Theorem 1 (Communication-contract safety).

Under Assumption 1, if (i) Algorithm 1 certifies that ${\mathcal{S}}_k$ is robustly positively invariant for loop k whenever the network respects $({\overline{D}}_k,{\overline{A}}_k,{\overline{B}}_k,{\overline{J}}_k)$, and (ii) every configuration ever executed was accepted by the shield, then the state of every admitted critical loop satisfies $x_{k,t}\in {\mathcal{S}}_k$ for all t. This implication is deterministic once its premises hold; it does not turn the empirically calibrated probability that future risk remains within its bound into a theorem.

Proof. 

The argument comprises three steps. Step 1 (network): By Lemma 1, every executed configuration keeps loop k’s network variables within $({\overline{D}}_k,{\overline{A}}_k,{\overline{B}}_k,{\overline{J}}_k)$; by Theorem 3 (stated and proved independently in Section 5.9.1; the forward reference introduces no circularity) no unverified mixture is ever active between commits. Step 2 (contract): By construction of Algorithm 1, these bounds imply that the closed-loop reachable set from any $x\in {\mathcal{S}}_k$ remains in ${\mathcal{S}}_k$ under all $w\in {\mathcal{W}}_k$—robust positive invariance [24]. Step 3 (induction): The initial state lies in ${\mathcal{S}}_k$; invariance under every executed configuration extends this to all t. □

The guarantee is explicitly conditional: it depends on model accuracy, the disturbance bound, functioning sensors and actuators, and the synchronization bound of Assumption 1. We do not claim unconditional or perpetual safety; Section 6 probes precisely the residual cases where these assumptions fray (risk underestimation beyond the calibrated $\delta$, margin-edge trajectories), and Section 7 discusses them. Section 6.4 operationalizes the demarcation scenario by scenario: ten of the fourteen scenarios exercise the system strictly inside Assumption 1, and the measured violation count there is zero; the remaining four deliberately attack the calibration assumption itself, and every residual violation concentrates in them.

Theorem 2 (Fail-safe solver termination).

Under the trusted-base integrity premise of Assumption 1, if the solver times out, crashes, or emits a candidate failing any shield check, then the configuration that executes next is either (i) the incumbent verified schedule, if its validity conditions still hold, or (ii) a fallback entry $F_j$ whose trigger and validity conditions match, which was shield-certified offline. In no execution does an unverified configuration reach the network.

Proof. 

The executor’s interface admits only shield outputs (Figure 4); the shield emits accept only after all nine checks, and its other two verdicts name already-verified artifacts (the incumbent, a library entry). Solver failure modes map exhaustively onto verdicts: timeout and crash produce no candidate, hence triggering reject with incumbent retention or—if the trigger invalidated the incumbent—fallback; an illegal candidate fails a check, with the same two outcomes. Fallback entries are certified offline against the same checks and re-validated at selection time within $T_v^F$. The case split is exhaustive, so no path leads from a failed solve to an unverified execution. □

5.9.1. Atomicity

Theorem 3 (No mixed configurations).

Provided the synchronization and commit-controller premises of Assumption 1 hold, at every instant, the set of active device configurations equals exactly one of: the complete previous schedule, the complete new schedule, or the complete fallback plan.

The two-phase commit of Section 5.7 yields this directly: staged configurations are inert; activation happens only at a PTP-aligned window boundary after all critical acknowledgments; and each abort branch either discards the inert state or commits a complete fallback atomically. The consistency property mirrors per-packet consistency in software-defined networks [34], transplanted to time-triggered GCLs where the “packet” is a control-loop iteration.

5.9.2. Bounded Recovery

Let $T_d$, $T_r$, $T_v$, $T_c$ be the stage budgets of Figure 6. On the normal path,

$$T_{\mathrm{recovery}}\le T_d+T_r+T_v+T_c,$$

(11)

and on the timeout path, where repair is cut off at $T_{\mathrm{timeout}}$ and a fallback is verified in $T_v^F$,

$$T_{\mathrm{recovery}}^F\le T_d+T_{\mathrm{timeout}}+T_v^F+T_c.$$

(12)

With the deployed budgets ($T_d\le 2.0$, $T_r\le T_{\mathrm{timeout}}=10.0$, $T_v\le 3.0$, $T_v^F\le 2.5$, $T_c=2.0$ ms), the normal path is bounded by 17.0 ms and the timeout path by 16.5 ms. Section 6.7 confirms both bounds empirically—the maximum observed fallback completion is 15.9 ms across 10,000 injected failures (Section 6.7)—and Section 6.4 shows the loop-level consequence: recovery within three control periods at the 10 ms motor loop.

5.9.3. Risk Conservativeness

The risk bound (7) is calibrated so that

$$\mathrm{Pr}\left(r_i^t\le {\overline{r}}_i^t\right)\ge 1-\delta ,$$

(13)

where $r_i^t$ is the ground-truth risk revealed by post hoc labeling. Equation (13) must be read as an empirical calibration result, not a distribution-free guarantee: the estimator of Equations (6) and (7) is inspired by, but is not an instance of, conformal calibration [39], because successive observation windows are neither exchangeable nor independent, so no finite-sample coverage theorem applies. We therefore substantiate the target empirically and state the procedure exactly. Ground truth: A node–window pair is labeled compromised when the attack injector was active on that node during the window, or a fault was injected there; benign otherwise. $r_i^t$ is this indicator smoothed at the evidence cadence. Splits: The ${10}^5$ windows (100 ms each, ≈$2.8$ h of operation) are partitioned chronologically into 30% calibration (fitting the inflation weights $\beta ,\lambda$), 20% validation, and 50% test; no calibration window follows a test window, and all reported numbers are test-split values. Temporal correlation: Adjacent windows are correlated, so interval estimates use a moving-block bootstrap (block length 50 windows, ${10}^4$ resamples), giving a 95% interval of $[96.8\%,97.5\%]$ on coverage. Drift: The deployment recalibrates on a sliding window and monitors coverage online; if the running estimate over the last ${10}^4$ windows drops below $1-\delta$, the uncertainty weight $\beta$ is raised one step until recalibration restores the target (Section 6.9 prices that response in admission). We report calibration, coverage, and underestimation instead of claiming detector perfection: with $\delta =0.05$, measured coverage is 97.2%, the underestimation rate 2.8%, and the expected calibration error 0.041 over the ${10}^5$ windows (Section 6.6). Conservativeness is a property of the bound, not of the detector; the design goal is that scheduling decisions remain safe even when classification is imperfect, and the residual violations in Section 6.4 trace exactly to the $\delta$-tail.

6. Implementation and Evaluation

6.1. Testbed and Platform

Figure 8 shows the testbed; Table 4 lists its components. Eight TSN switches (1 GbE, 802.1Qbv/Qci/CB) form the mesh of Figure 8, synchronized by an IEEE 802.1AS grandmaster to sub-microsecond error. A centralized network configuration (CNC)-style orchestrator host runs the risk engine, the optimizer, the shield, and the fallback manager as separate processes; an attack/fault injector node applies the scenarios of Section 6.3 (delay, loss, replay, burst, topology changes) without touching the systems under test.

Figure 8. Testbed: Three physical control loops (water level, motor speed, heading) closed over an eight-switch TSN mesh with PTP synchronization; the control/security plane hosts the orchestrator, risk engine, optimizer, independent shield, and atomic executor; a dedicated node injects attacks and faults. Solid and dashed orange arrows mark the attack- and fault-injection paths from the injector node into the TSN switches; the remaining arrow colors follow the in-figure legend. PTP: precision time protocol; CNC: centralized network configuration; BLDC: brushless DC; IMU: inertial measurement unit; GbE: gigabit Ethernet.

Table 4. Testbed configuration.

Component	Configuration
TSN network	8 switches, 1 GbE, IEEE 802.1Qbv/Qci/CB; mesh topology (Figure 8)
Synchronization	IEEE 802.1AS PTP grandmaster; measured error < 1 μs
Streams	24 flows total, 8 critical control flows, frame sizes 128–256 B
Water-level loop	Tank, level sensor, pump; controller C1, period 20 ms
Motor-speed loop	BLDC motor [40], encoder, inverter; controller C2, period 10 ms
Heading loop	Mobile robot, IMU heading sensor, steering; controller C3, period 20 ms
Orchestrator host	6-core x86, 32 GB RAM, Ubuntu 22.04 (PREEMPT_RT); risk engine, optimizer, shield, fallback manager as separate processes
Solver	OR-Tools CP-SAT v9.8 [41] (C++ 17/Python 3.12), budget $T_{\mathrm{timeout}}=10$ ms
Shield	Independent Rust module, deterministic checks only
Risk parameters	$\alpha =0.9$, $\beta =1.0$, $\lambda =0.5$, $\delta =0.05$
Attack injector	Dedicated node; delay/loss/jitter/replay/burst/topology faults

Control loops. The three loops were chosen to stress different contract dimensions. The water-level loop (slow dynamics, tolerant of delay but sensitive to accumulated error) exercises AoI and cumulative-error behavior; its model follows the standard tank benchmark [42]. The motor-speed loop (fast, 10 ms period) is the jitter- and consecutive-loss-critical case; it is modeled with the classical phase-variable brushless DC (BLDC) formulation of Pillay and Krishnan [40], which remains the canonical reference for exactly the electrical dynamics our fixed-gain speed loop needs, while modern drive-control surveys [43] cover inverter and control advances that this loop does not exercise. The heading loop has the most legible safe-set boundary (5° corridor) and is the target for reconfiguration and degradation experiments.

6.2. Software Realization

Evidence inputs. The risk engine consumes: identity assurance and credential state (issued by a hardware-rooted credential service, including revocation events), per-frame HMAC verification results, sequence-number replay detection, traffic-volume and latency anomaly scores, node integrity status, evidence timestamps, and per-source uncertainty. HRCred is a replaceable interface, not a dependency: any zero-trust stack that emits $(a,b,f,u)$ tuples with timestamps plugs in unchanged.

Separation of optimizer and shield. The optimizer (Python orchestration around CP-SAT’s C++ core) and the shield (Rust) share no code, no libraries, and no address space. The motivation is common-mode failure: a bug in a shared constraint-evaluation routine would otherwise corrupt both the proposal and its verification. The shield re-derives every quantity it checks—path delay, worst-case AoI, slot occupancy—from the candidate and the raw topology/contract state, in deliberately simple loop-and-compare code amenable to review. Because Theorems 1–3 concentrate the guarantee on this one component, its assurance case is stated plainly rather than implied. The current implementation provides engineering assurance, not machine-checked formal verification. The shield is ≈$1.1$ kLOC of Rust with no unsafeblocks. Unit and property-based tests reach 96.4% line and 91.8% branch coverage. Differential testing replays ${10}^6$ randomized candidates, plus every candidate of the failure-injection campaign, against an independently written Python oracle, with zero verdict divergences; 72 h of coverage-guided fuzzing produced no panics, and any runtime panic is converted to reject—fail-closed, so a crashing shield denies rather than admits. Every change is reviewed by two developers who did not write it, with pedantic lints enforced in continuous integration. Terminology is used accordingly throughout: “certified” means checked against the contract by this independent verifier; “formally verified” is reserved for the machine-checked proof of the nine checks, which remains future work; and Section 7 discusses the residual implementation risk that testing cannot close—distinct from the model risk of Assumption 1.

Fallback storage and re-certification. Each fallback entry stores its topology version range, control mode parameters, applicable fault set, and a hash of the contract set it was certified against. A background task re-certifies entries whenever contracts or topology baselines change; entries whose validity lapses are marked unusable and regenerated offline. At steady state the library holds 3–5 F1 plans per critical loop, one F2 mode per loop, and one F3 action per loop.

6.3. Evaluation Methodology

Research questions. The evaluation answers seven questions. RQ1: Does ZTSafe keep the physical state in its safe set under attack, and at what cost? RQ2: Does deadline feasibility without contracts actually lead to physical violations? RQ3: How does the uncertainty-aware risk bound compare with alternative aggregations? RQ4: Do solver failures ever cause unverified configurations to execute? RQ5: Does atomic reconfiguration matter, or do transition transients not affect safety? RQ6: How should the conservativeness knobs be set, and what is the safety–performance trade-off? RQ7: Does the approach scale within its real-time budget?

Baselines. Nine baselines cover the design space. Four are end-to-end systems: B1 QoS-TSN, deadline-constrained joint routing and scheduling without risk or contracts [6]; B2 Control-aware TSN, scheduling with control-performance objectives but no security risk [28]; B3 Zero-trust SDN (software-defined networking), reputation-driven rerouting without TSN determinism [16]; and B4 Security-aware TSN (SA-TSN), a frame-level security- and trust-aware TSN scheduler with worst-hop risk aggregation, which we implement following the dependability- and security-aware co-synthesis of Reusch et al. [11] extended with dynamic trust scores [17]. Three replace ZTSafe’s risk bound in the otherwise unchanged system: B5 mean reputation, B6 cumulative path risk, and B7 CVaR at level 0.9 [36]. Two replace the atomic executor: B8 per-switch sequential update and B9 plain (non-guarded) batch update. All baselines run on the same testbed, traffic, and scenario schedule. In addition, a best-effort Ethernet control (B0)—the same topology with 802.1Qbv gating disabled and strict-priority queuing only—anchors the comparison below every TSN baseline and isolates the contribution of determinism itself (Exp1).

Attack and fault scenarios. Table A2 (Appendix B) lists the fourteen scenarios; each is run for 1000 episodes with randomized onset times, giving 14,000 episodes per method for the aggregate results. The table also maps every scenario to an external anchor—MITRE ATT&CK for industrial control systems (ICS) technique identifiers where applicable [44], published trust-management and TSN security literature, and the dependability taxonomy of Avižienis et al. [45]—making explicit which behaviors are externally grounded rather than designer-invented; Section 7.4 discusses the residual circularity risk.

Metrics. Five metric groups are reported. Physical safety: Safe-set violation rate (fraction of episodes with $x\notin {\mathcal{S}}_k$ at any time), maximum state excursion (normalized to the safe-set half-width), and integral absolute error (IAE, normalized to benign QoS-TSN). Control performance: Benign-operation IAE overhead. Network: On-time completion (OTC)—the fraction of released frames of admitted critical tasks delivered within their deadlines—and AoI P99 relative to contract. OTC is a frame-level service metric, distinct from the task-level admission rate (fraction of critical tasks admitted under contract constraints) reported in Exp6; the abstract’s headline 94.3% is OTC, and its numerical coincidence with the admission rate at the deployed $\beta$ is exactly that—a coincidence, not a definition. Security: Attack-flow admission and false-isolation rates. Runtime assurance: Count of unverified configurations executed and duration of mixed configurations—both of which must be exactly zero—plus recovery times against the bounds of Section 5.9.2. We measure the physical state directly from the plant sensors, not only network KPIs: a scheduler is judged by where the water level went, not by how many frames arrived on time.

6.4. Exp1: Physical Safety Under Attack (RQ1)

Setup. All six end-to-end methods (B0–B4 and ZTSafe), all fourteen scenarios, 1000 episodes each; attack onset uniform over $[10,50]$ s of each 60 s episode, three intensity tiers, seeds $1\dots 1000$ per scenario, all fixed and available on application (Data Availability Statement). Figure 9 and Table 5 report the primary results.

Figure 9. Physical safety under attack (Exp1, 14,000 episodes per method). (a) Safe-set violation rate; (b) maximum state excursion, normalized; (c) integral absolute error (IAE), normalized; (d) recovery time in control periods (QoS-TSN does not recover). ZTSafe violates in less than 1% of episodes across all fourteen scenarios.

Table 5. Primary safety results (Exp1; 14,000 episodes per method; recovery at P99 in control periods). Confidence intervals (CIs) are Wilson intervals on the episode-level violation proportion; per-scenario intervals are given in Appendix C. OTC: on-time completion; SA-TSN: security-aware TSN (baseline B4).

Method	Violation Rate	95% CI	Max Excursion	IAE	Recovery (P99)	OTC	AoI P99/Contract
Best-effort Ethernet	47.3%	[46.5, 48.1]	3.42	2.61	no recovery	71.8%	3.21×
QoS-TSN	34.2%	[33.4, 35.0]	2.86	1.94	no recovery	97.8%	1.64×
Control-aware TSN	18.6%	[18.0, 19.3]	1.92	1.41	9.2	96.4%	0.98×
Zero-trust SDN	22.4%	[21.7, 23.1]	2.13	1.67	7.5	91.2%	1.38×
SA-TSN	12.8%	[12.3, 13.4]	1.55	1.28	5.8	96.1%	1.21×
ZTSafe (full)	0.9%	[0.76, 1.07]	1.04	1.06	3.0	94.3%	0.87×

Findings. F1: ZTSafe reduces the safe-set violation rate by 92.9% relative to the strongest baseline (SA-TSN, 12.8% → 0.9%), and its maximum excursion of 1.04 means that even violating episodes barely cross the boundary, versus excursions of 1.55–2.86 for the baselines (Figure 9b). The mechanism matters: in scenarios S1, S3, and S8, where the attack flow is not immediately identified, the margin-coupled budget (4) tightens as the state drifts, forcing traffic off marginal paths and, where necessary, into F2 degraded modes—contract tightening and safe-mode switching prevent physical violation without requiring detection to win the race. F2: The cost is explicit and bounded—OTC drops from 96.1% (SA-TSN) to 94.3%, a 1.8-percentage-point OTC cost for conservatism, and benign-operation IAE rises only 3.1% over benign QoS-TSN. F3: Across all 14,000 episodes (10,000 adversarial, 4000 fault-injection), ZTSafe confined the physical state to its safe set in 99.1% of cases, and every residual violation traces to risk underestimation beyond the calibrated $\delta$ combined with margin-edge operation (Section 5.9.3), not to an executed unverified schedule. F4: The headline difference is statistically unambiguous: violation episodes number 126/14,000 for ZTSafe versus 1792/14,000 for SA-TSN; a two-proportion test gives $z=39.4$, $p<{10}^{-15}$ (Fisher’s exact test agrees), and the Wilson 95% intervals of Table 5 are pairwise disjoint; per-scenario intervals are tabulated in Appendix C (Table A3). Violations are insensitive to attack-onset tercile ($\pm 0.15$ pp) and monotone in intensity tier (0.4%, 0.9%, 1.4%), so the aggregate is not an artifact of the randomization policy. F5: The demarcation stated after Theorem 1 is visible in the data. The ten scenarios that operate inside Assumption 1 (S1–S2, S4–S6, S9–S13) produce zero violations in 10,000 episodes—wherever the assumptions held, the formal guarantee held—while all 126 violations concentrate in the four scenarios that attack the calibration assumption itself (S3: 41, S8: 38, S14: 35, S7: 12). Causally, 114 of 126 trace to risk underestimation beyond the calibrated $\delta$ under evidence-quality attacks (the estimator stayed wrong for longer than one repair epoch), and the remaining 12 (all S7) to multi-vector races in which degradation crossed the certified box within a single repair epoch, before any fallback could commit; none involved an unverified or mixed configuration, and the maximum excursion of 1.04 shows that even these episodes barely crossed the boundary. F6: The best-effort Ethernet control fails in 47.3% of episodes with AoI at 3.2× contract despite the lowest mean latency in benign conditions—determinism, not raw speed, is load-bearing for every guarantee above. RQ1 is answered affirmatively: near-total physical safety at a quantified, single-digit cost in on-time completion.

6.5. Exp2: Deadline-Only vs. Safety Contract (RQ2)

Setup. A constructed scenario in which a deadline-feasible schedule exists but violates the motor loop’s AoI and burst-loss contract: an S2 burst forces rerouting through a path that batches frames upstream. Figure 10 shows the time series; Table 6 the outcomes.

Figure 10. Deadline satisfaction is not control safety (Exp2). (a) AoI trajectories against the 15 ms motor contract; the deadline-met strip below is essentially all green for every method (green dots: all deadlines met in that interval; the single red dot marks the one interval in which SA-TSN misses a deadline, giving 99.2% on-time). (b) Motor speed: QoS-TSN and SA-TSN leave the safe band while meeting deadlines; ZTSafe rejects the deadline-feasible plan and triggers the F2 degraded mode (vertical dashed line), keeping the speed inside the band.

Table 6. Exp2 outcomes on the motor loop (AoI contract 15 ms, burst-loss contract 2).

Method	Reported Feasible?	Deadline Met	AoI P99	Max Consec. Losses	Physical Outcome
QoS-TSN	Yes	100%	24.6 ms	5	excursion to $+412$ rpm beyond limit; violations in 8.4% of episodes
SA-TSN	Yes	99.2%	21.3 ms	4	violations in 5.1% of episodes
ZTSafe	Rejects plan → F2 (sampling $10\to 20$ ms, local control)	100%	13.8 ms	1	0 violations

Findings. F1: The deadline-met strip in Figure 10a is all-green for QoS-TSN (100%) while its AoI crosses the 15 ms contract within four seconds and reaches 24.6 ms—deadline metrics are structurally blind to this failure. F2: The physical consequence is immediate (Figure 10b): QoS-TSN and SA-TSN drive the motor out of the 3000 rpm band while every frame is “on time”. F3: ZTSafe’s shield rejects the deadline-feasible candidate on check 3 (AoI) and the system degrades to F2—halved sampling with local control—holding AoI at 13.8 ms and losses at 1, with zero violations. RQ2: yes, deadline-only feasibility produces real physical violations, and the contract dimension that catches it here is AoI, not delay.

6.6. Exp3: Risk Aggregation Comparison (RQ3)

Setup. Four alternative risk models—B5 mean reputation, the worst-hop aggregation used by SA-TSN, B6 cumulative, and B7 CVaR—each transplanted into the otherwise unchanged ZTSafe stack, under identical scenarios; Table 7.

Table 7. Risk-model comparison (Exp3).

Risk Model	Attack Admission	False Isolation	Safety Violations	Schedule Feasibility
Mean reputation	14.2%	2.3%	6.8%	98.4%
Worst-hop (SA-TSN)	6.8%	3.1%	3.9%	96.7%
Cumulative risk	5.1%	4.8%	3.2%	94.9%
CVaR (level 0.9)	1.9%	5.6%	1.3%	92.8%
Uncertainty-aware bound (ZTSafe)	1.6%	3.9%	0.9%	94.3%

Findings. F1: Mean reputation is the weakest under on–off gaming (S3), admitting 14.2% of attack flows; worst-hop aggregation (SA-TSN’s choice) more than halves that but still leaks under multi-node campaigns (S7). F2: CVaR approaches ZTSafe’s safety but over-isolates (5.6% false isolation) and loses feasibility (92.8%); the uncertainty-aware bound dominates it on all four columns. F3: Calibration over ${10}^5$ evidence windows yields coverage $\mathrm{Pr}(r\le \overline{r})=97.2\%$ against the ≥95% target, an underestimation rate of 2.8%, and ECE 0.041—the bound is conservative in exactly the calibrated amount, per Equation (13). F4: The residual cost of conservatism is false isolation: 3.9% of legitimate flows are temporarily treated as risky, against 2.3% under mean reputation—the price of refusing to let an on–off adversary launder its score. The operational impact is bounded and measured: an isolated legitimate flow is rerouted rather than dropped (mean re-admission within 11 ms via the repair path of Section 5.9.2), and the aggregate cost is already contained in the 1.8 pp OTC gap of Table 5. The tuning knob is $\beta$: false isolation moves across 2.1%, 2.9%, 3.9%, and 6.3% at $\beta =0,0.5,1.0$ and $2.0$ while attack admission moves in the opposite direction (Exp6, Section 6.9); and since $\beta$ is per-loop, operators can run non-critical loops at $\beta =0.5$ and safety-critical loops at $\beta \ge 1$, reducing fleet-wide false isolation without touching the safety-critical operating point. RQ3: Uncertainty-aware upper bounds beat point aggregations; the win comes from pricing evidence quality, not from a better classifier.

6.7. Exp4: Solver Failure Injection (RQ4)

Setup. 10,000 solver failures injected across five types—timeouts at 5/10/20 ms budgets, process crashes, infeasible or illegal candidates, incomplete paths, and stale risk versions—under scenario S10 and mixed background attacks. Figure 11 and Table 8.

Figure 11. Solver-failure handling (Exp4, 10,000 injected failures). (a) Outcome proportions per failure type: the incumbent plan is retained or a pre-checked fallback (F1/F2/F3) commits; unverified executions: zero. (b) Every fallback completion time lies below the 16.5 ms bound of Equation (12).

Table 8. Solver-failure outcomes (Exp4). The shield rejected 100% of infeasible and illegal candidates; “unverified executed” is zero for every failure type.

Failure Type	Injected	Unverified Executed	Old Plan Retained	F1/F2/F3	Safety Violations
Timeout (5/10/20 ms)	4000	0	81.2%	16.4%/2.1%/0.3%	0
Solver crash	1500	0	76.8%	19.6%/3.2%/0.4%	0
Infeasible/illegal candidate	2000	0	79.4%	17.5%/2.8%/0.3%	0
Incomplete path	1500	0	74.1%	22.3%/3.3%/0.3%	0
Stale risk version	1000	0	68.9%	27.4%/3.4%/0.3%	0
Total	10,000	0	77.9%	19.1%/2.7%/0.3%	0

Findings. F1: No unverified configuration was ever executed across 10,000 injected solver failures—the empirical face of Theorem 2. F2: In 77.9% of failures the incumbent schedule simply remains active; fallbacks resolve the rest, overwhelmingly F1 (19.1%), with fail-safe F3 needed in only 0.3%. F3: Fallback completion takes 9.8 ms on average with a maximum of 15.9 ms, below the 16.5 ms bound of Equation (12) (Figure 11b); normal-path recovery (evidence to commit) completes in 10.9 ms on average (P99 15.4 ms) against the 17.0 ms bound of Equation (11), so even the 10 ms motor loop recovers within three control periods, consistent with Figure 9d. RQ4: Solver failure never becomes a safety event.

6.8. Exp5: Atomic vs. Non-Atomic Reconfiguration (RQ5)

Setup. B8 (per-switch sequential) and B9 (plain batch) against ZTSafe’s guarded two-phase commit, under S9-timed attacks and 500 reconfigurations each; Table 9.

Table 9. Reconfiguration transients (Exp5).

Update Strategy	Mixed-Config Duration	Transient Blackhole	AoI Spike (×Contract)	Loss Burst (Frames)	Safety Violations
Per-switch sequential	41.3 ms	3.8% of events	3.2×	6.1	12.4% of episodes
Plain batch	17.6 ms	1.2%	1.9×	3.4	4.1%
ZTSafe guard-window atomic	0 ms	0%	1.0×	0	0%

Findings. F1: Sequential updates leave old and new GCLs coexisting for 41.3 ms—four motor periods—during which AoI spikes to 3.2× contract and 12.4% of episodes violate safety; batching shrinks but does not eliminate the window. F2: The guarded atomic commit measures a mixed-configuration duration of exactly 0 ms across all events (Theorem 3 empirically), at the cost of one protection window ($T_c=2.0$ ms) of commit latency. F3: Attacks timed at reconfiguration windows (S9) gain nothing against the atomic executor, since staged state is inert until the aligned activation instant. RQ5: Transition transients are a real and attackable safety hazard, and atomicity removes it at millisecond cost.

6.9. Exp6: Safety–Performance Trade-Off (RQ6)

Setup. Sweep of the uncertainty weight $\beta$ (with margins, AoI caps, and budgets swept in companion runs); Figure 12a and Table 10.

Figure 12. (a) Safety–performance trade-off under the $\beta$ sweep (Exp6), with the recommended region shaded. (b) Scalability across L1/L2/L3 (Exp7): incremental repair stays near the 10 ms budget while full recomputation leaves it by an order of magnitude; shield verification remains far cheaper than solving at every scale. HIL: hardware-in-the-loop.

Table 10. Conservativeness sweep (Exp6).

$\mathit{\beta }$	Safety Violations	Admission Rate	IAE	Fallback Trigger Rate	False Isolation
0 (no uncertainty term)	4.2%	97.2%	1.18	2.1%	2.1%
0.5	1.8%	95.8%	1.09	3.4%	2.9%
1.0 (deployed)	0.9%	94.3%	1.06	4.6%	3.9%
2.0	0.4%	89.6%	1.05	8.9%	6.3%

Findings. F1: Removing the uncertainty term ($\beta =0$) quadruples violations to 4.2%—conservatism, not classification, carries the safety result. F2: Past $\beta \approx 1.5$ the admission cost accelerates (89.6% at $\beta =2$) for marginal safety gain; the violation curve flattens below 1%. F3: The recommended operating region is $\beta \in [1.0,1.5]$, where violations stay below 1% and admission above 92% (shaded band in Figure 12a); operators trade within it by loop criticality. F4: The companion sweeps of Table 11 answer two practical questions raised by the margin and calibration choices. Margins: Halving every $ϵ$ component roughly doubles residual violations (0.9% → 2.1%), while doubling them buys 0.6 pp of safety for 4.5 pp of admission—the deployed scale sits at the knee of the curve. Calibration level: Tightening $\delta$ from 0.05 to 0.001 cuts violations by two thirds at a 6.9 pp admission cost, with shield latency unchanged—$\delta$ enters only the inflation term of Equation (7), never the verification path, so conservativeness is priced purely in admission, not in reaction latency. RQ6: The trade-off is smooth, monotone, and tunable with a single interpretable knob.

Table 11. Companion sensitivity sweeps (Exp6): joint scaling of all margin components $ϵ$, and calibration level $\delta$.

Setting	Safety Violations	Admission	OTC	Shield Verify
margin $\times 0.5$	2.1%	95.9%	96.0%	0.9 ms
margin $\times 1.0$ (deployed)	0.9%	94.3%	94.3%	0.9 ms
margin $\times 1.5$	0.5%	92.6%	92.7%	0.9 ms
margin $\times 2.0$	0.3%	89.8%	89.9%	0.9 ms
$\delta =0.05$ (deployed)	0.9%	94.3%	94.3%	0.9 ms
$\delta =0.01$	0.5%	91.8%	91.9%	0.9 ms
$\delta =0.001$	0.3%	87.4%	87.5%	0.9 ms

6.10. Exp7: Scalability (RQ7)

Setup. Three levels, reported separately and not mixed: L1, the real hardware testbed (eight switches, 24 flows); L2, hardware-in-the-loop (HIL) with emulated switches (16 switches, 120 flows); L3, discrete-event simulation only (64 switches, 1000 flows)—L3 numbers are simulation extrapolations. Figure 12b and Table 12.

Table 12. Scalability across evaluation levels (Exp7; L3 is simulation extrapolation).

Level	Scale	Incremental Repair	Full Recompute	Shield Verify	CPU/Mem
L1 hardware	8 sw/24 flows	6.8 ms	84 ms	0.9 ms	18%/210 MB
L2 HIL	16 sw/120 flows	11.2 ms	412 ms	2.3 ms	34%/480 MB
L3 simulation	64 sw/1000 flows	38.6 ms	>budget (fallback path)	9.8 ms	71%/2.1 GB

Findings. F1: Incremental repair is the difference between feasible and infeasible online operation—full recomputation exceeds the 10 ms budget already at L1 (84 ms) and by 40× at L2. F2: Within the 10 ms budget the architecture sustains roughly 100 flows (interpolating between L1 and L2); at L3 scale even incremental repair overruns, and the system then lives on the fallback path by design—safe, but with degraded admission, which we report honestly rather than extrapolate away: sustained fallback-dominated operation at L3 admits 73.9% of critical tasks (versus 94.3% at L1) and suspends best-effort classes entirely, while every safety property is preserved (zero unverified executions, zero mixed configurations, all fallback commits within bound)—the scale ceiling degrades capacity, never safety. F3: Shield verification stays an order of magnitude cheaper than solving at every scale (0.9/2.3/9.8 ms), supporting the small-TCB architecture: the trusted component is the one that scales best. RQ7: Yes within the deployment envelope, with an explicit, measured ceiling.

6.11. Ablation Study

Setup. Each safety mechanism removed in isolation, full scenario suite; Table 13.

Table 13. Ablation study (14,000 episodes per variant).

Variant	Exposed Failure Mode	Violations	Key Symptom
Full ZTSafe	—	0.9%	—
− Safety contract	Deadline met, physics violated	15.7%	AoI P99 at 1.58× contract
− AoI constraint	Stale data arrives on time	8.3%	12.4% stale measurements
− Risk uncertainty	Optimism under thin evidence	3.8%	attack admission 6.2%
− Safety shield	Illegal candidates execute	5.4%	217 illegal configs per ${10}^4$
− Fallback library	Communication gap when unsolvable	4.9%	mean gap 86 ms
Non-atomic update	Mixed old/new GCLs	4.1%	17.6 ms mixed duration
Fixed risk threshold	Budget ignores physical margin	2.6%	near-boundary admission 4.8%

Findings. F1: The contract layer is the single largest contributor—removing it multiplies violations by 17. F2: Every component’s removal produces its own distinct symptom (stale data, admitted attacks, executed illegal configurations, communication gaps, mixed schedules), confirming that the mechanisms are complementary rather than redundant. F3: Even the subtlest coupling—the margin-dependent budget of Equation (4)—matters: freezing it triples violations by admitting risk precisely when the plant is least able to absorb it.

7. Discussion and Conclusions

7.1. Model Dependence

Theorem 1 is only as strong as Assumption 1, and we state this as a property of the approach rather than a footnote: contracts synthesized from a wrong model certify nothing. Three factors mitigate the exposure. The margins $ϵ$ in Algorithm 1 absorb bounded model mismatch by construction; the engineering-calibration layer validates bounds against the real controller code rather than the design model; and the runtime margin coupling (4) makes the system most conservative exactly when the state approaches the region where model error is most dangerous. The residual 0.9% of Exp1 lives where these mitigations thin out, and closing it requires either richer models or larger margins—a trade the operator makes explicitly, not one the system hides.

What actually happens when each assumption is violated deserves its own accounting. (i) Model error beyond the identified envelope voids the invariance certificate for the affected loop; violations then surface first at the safe-set boundary, which the margin monitor detects as anomalous margin consumption, triggering conservative degradation (F2) and contract re-synthesis (Section 4)—the failure mode is drift toward measured, flagged unsafety, not silent divergence. (ii) Disturbances beyond ${\mathcal{W}}_k$ behave identically, and the per-loop F3 actions remain valid because they are network-independent and only weakly model-dependent. (iii) Synchronization error beyond ${ϵ}_{\mathrm{sync}}$ first breaks guard-band premises: jitter checks and commit acknowledgments fail, the shield rejects candidates, and the executor freezes on the incumbent or falls back—degraded availability, not unsafety. (iv) Sensor or actuator failure lies outside the communication contract altogether; the per-loop F3 action (safe valve position, ramp-down, controlled stop) is the designed response. (v) TCB compromise is the one violation with no internal safety net—a compromised shield can accept anything; signed verdict logs make compromise detectable after the fact and the hardening of Section 3.4 raises its cost, but the guarantee chain honestly ends there (Section 7.2).

7.2. Residual Trusted-Base and Implementation Risk

Theorems 1–3 relocate trust rather than eliminate it: the guarantee is only as correct as the nine checks’ implementation, and this risk is distinct from the model risk above. Concretely, an accept-too-much shield fault can admit a contract-violating schedule; a corrupted contract or fallback store can substitute an unsafe bound or plan; a faulty commit controller can activate a mixed configuration; and a compromised grandmaster can invalidate the delay, jitter, and activation-time premises. Any of these events breaks a theorem premise and can cause physical unsafety. The assurance case of Section 6—96.4%/91.8% line/branch coverage, ${10}^6$-candidate differential testing against an independent oracle, fuzzing, fail-closed panics, and independent review—reduces but cannot close it; a systematic bug in one check could admit a contract-violating schedule while every experiment here passes. Accordingly, the current shield provides strong engineering evidence for its implementation, but not formal or machine-checked assurance. Three properties bound the blast radius. First, the checks are independent per dimension, so one faulty check compromises one contract dimension, not the argument wholesale. Second, the incumbent-re-verification path re-runs the same checks periodically, so a fault that rejects too much degrades availability visibly rather than safety silently; only the accept-too-much direction is dangerous. Third, verdict logs are signed and replayable: the differential oracle re-audits every production verdict offline, so an admitted-but-invalid schedule would be flagged within one audit cycle even if not before commit. Machine-checked verification of the checker core remains the stated future-work step, and until then “certified” means independently checked, not proven correct.

7.3. Imperfect Risk Estimation

ZTSafe does not assume its risk estimates are correct; it assumes they are calibrated. The framework’s value lies in making uncertainty an explicit scheduling input—Equation (7) prices evidence quality, staleness raises bounds, and Exp3 shows the resulting behavior under adversarial reputation gaming—and in ensuring that physical safety does not hinge on classification winning every race (Exp1, scenarios S1/S3/S8). Risk underestimation occurs in the measured 2.8% tail at the evidence-window level; the corresponding end-to-end residual is 0.9% of episodes, all after realized degradation left the contract-certified regime. The architecture bounds the blast radius but does not eliminate it.

7.4. External Validity of the Scenario Suite

The fourteen scenarios were designed by the same group that designed the defense, and we state the circularity risk plainly rather than leave it implicit. Two mitigations apply. First, the suite is externally anchored: Appendix B maps each adversarial scenario to MITRE ATT&CK for ICS techniques (spoofed reporting, denial of service, adversary-in-the-middle, blocked reporting) [44] or to attack classes documented independently of this project (on–off trust gaming [17], stealthy ICS manipulation [35], TSN-specific timing and reconfiguration abuse [14], algorithmic-complexity denial of service [38]), and the fault scenarios follow the standard dependability taxonomy [45]. Second, the scenario generator, seeds, and injector configurations are available to qualified researchers on application (see the Data Availability Statement), so external teams can replicate and extend the suite independently of us. What the mapping cannot remove is the risk of “teaching to the test” against an adaptive adversary who probes the deployed estimator’s blind spots specifically; the S3/S8/S14 results already show where that pressure lands (calibration, not verification), and independent red-teaming of exactly that surface is the follow-up we consider most valuable.

7.5. Availability Versus Safety

ZTSafe deliberately resolves the availability–safety tension toward safety: under extreme conditions it degrades sampling, falls back to local control, or executes a controlled stop rather than trading its hard boundaries for apparent availability. The 1.8-percentage-point OTC cost of Exp1 and the 4.6% fallback trigger rate of Exp6 are the measured price. For processes where availability itself is safety-critical (e.g., cooling), the contract synthesis accommodates this by encoding availability requirements into ${\mathcal{S}}_k$ and the F2/F3 mode designs—the framework does not force a stop where a stop is the hazard.

7.6. Interfaces to Identity and Analytics

ZTSafe consumes zero-trust evidence; it does not produce it. Credential state arrives through a hardware-rooted identity interface and behavioral scores through whatever analytics stack the operator runs; both are replaceable, and ZTSafe adds conservatism (7) on top of whatever quality they deliver. Richer upstream signals (attestation depth, learned anomaly scores) would tighten bounds and raise admission. The precise statement of what rests where: the deterministic layer of the guarantee—under Assumption 1, shield-accepted schedules keep degradation inside contract-certified boxes (Theorem 1)—does not depend on upstream evidence quality; the stochastic layer does, since risk underestimation beyond the calibrated $\delta$ is exactly what produces the residual 0.9% (Section 5.9.3 and Section 6.4). Better upstream evidence therefore shrinks the residual term, even though no upstream improvement is required for the invariance certificate itself.

7.7. Conclusions

This paper answered four questions. How does zero-trust evidence become a scheduling input? Through conservative risk upper bounds that price uncertainty and staleness, not through point scores. How does physical safety become a network requirement? Through per-loop communication contracts—delay, AoI, burst loss, jitter, and a margin-coupled risk budget—synthesized offline from control models with explicit margins. What guarantees that only safe schedules run? An independent runtime shield that checks every candidate against the contracts, backed by atomic commitment, so that exactly the shield-accepted configurations execute. What happens when the optimizer fails? Under the same model, synchronization, and trusted-base assumptions, the incumbent persists or a pre-checked fallback commits within a proven time bound—zero unverified executions across 10,000 injected failures on hardware. The assurance layers are distinct: Theorem 1 gives a deterministic conditional implication, whereas the measured 97.2% risk-bound coverage is an empirical probabilistic result rather than a formal guarantee. The safety gain carries a measurable service cost: OTC is 94.3% for ZTSafe versus 96.1% for SA-TSN, a difference of 1.8 percentage points. The residual 0.9% violation rate occurs only in the four scenarios that force realized degradation beyond the calibrated contract regime; none of those episodes executed an unverified or mixed configuration, so the residual does not contradict the deterministic implication inside its premises. The runtime shield currently has engineering assurance from memory-safe implementation, testing, fuzzing, differential checking, and review, but it is not formally verified; a systematic checker defect or compromise of any remaining TCB component voids the corresponding guarantee. Future work targets machine-checked contract synthesis and learned-but-calibrated risk estimators within the same verified-execution envelope.