Functional Safety and Integrity Allocation

Each safety function gets an integrity target set by the severity and frequency of the hazard it prevents; higher targets demand more redundancy, coverage, and proof.

Match rigor to hazard

Not every safety function needs the same rigor. Kronos allocates a safety integrity target to each function based on the hazard it addresses — how severe the consequence, how often the demand, and how much other protection exists. The target then drives concrete requirements: redundancy level, diagnostic coverage, proof-test interval, and independence from other layers.

def target_pfd(consequence, demand_rate_per_yr, other_layers_rrf):
    # required risk reduction = intolerable gap after existing layers
    tolerable = 1e-5                       # tolerable event freq / yr
    unmitigated = consequence * demand_rate_per_yr
    needed_rrf = unmitigated / (tolerable * other_layers_rrf)
    return 1.0 / needed_rrf                # PFD the function must meet

From target to design

Diagnostic coverage — the fraction of dangerous failures the system detects on its own — matters as much as redundancy. An undetected dangerous failure sits latent until a demand arrives; high coverage converts most of those into detected, safe-side failures that trip or alarm. This is why proof testing and diagnostic coverage is a first-class concern.

Allocation is revisited whenever the plant or the hazard picture changes, because integrity is a property of the whole risk chain, not a fixed label on a box. If a protection layer that other functions leaned on is removed or degraded, the functions behind it inherit a higher target automatically. Kronos keeps this dependency explicit so that a change in one layer surfaces every function whose integrity argument depended on it, rather than silently eroding margins elsewhere. The allocation therefore behaves as a living part of the safety case, traced from hazard through requirement to design, not a static label assigned once and forgotten.

Integrity allocation is not a paperwork exercise bolted on at the end; it is decided at design time and traces through to the failure response decision table and the redundancy chosen in voting and redundancy. Because these machines are pre-FOAK, the allocation is being validated in simulation and hardware-in-the-loop before first plasma.