The Exception Matrix and Event Handling

An exception matrix maps detected off-normal conditions to defined responses, making fault handling explicit, reviewable, and testable.

Making fault logic explicit

When something goes wrong, the control system must respond correctly and predictably. An exception matrix (sometimes called an event table) captures this as an explicit mapping: each row is a detectable condition, each column an aspect of the response. It replaces scattered, implicit fault handling with one reviewable specification.

Structure

A typical matrix lists, for each condition, how it is detected, its severity, the response tier (continue, adapt, recover, terminate, mitigate), which subsystems act, and any prerequisites. Because it is tabular, engineers and physicists can review it together, spot gaps, and check that no condition falls through without a defined response.

Severity and precedence

When several conditions occur at once, the matrix defines precedence so the most severe response wins. A minor deviation that would prompt an adaptation is overridden by a concurrent condition demanding termination. Encoding precedence prevents conflicting responses from being issued together.

Testing

Because the matrix is explicit, each entry can be tested by injecting its condition in the flight simulator and confirming the specified response occurs. This turns fault handling from something hoped to work into something demonstrated to work, one row at a time, including the rare combinations that real operation seldom produces.

In the Kronos program

The Hyperion breeder's off-normal layer is organized around an exception matrix covering locked modes, vertical control loss, impurity influx, actuator failures, and diagnostic loss, each mapped to a response on the avoidance-first ladder. Every entry is exercised against injected faults in the flight simulator so the response is verified before hardware operation.