3. Test condition taxonomy for safety evidence

A safety requirement is only as trustworthy as the test conditions that exercise it. If a requirement states that "the motor controller shall limit phase current to 350 A under all operating conditions," the evidence supporting that claim must demonstrate not merely that the limit holds at 350 A, but that it holds at the boundary, inside each equivalence class of operating states, under injected sensor faults, and across the environmental envelope the vehicle will actually see. This chapter builds a taxonomy of test conditions and shows how each category maps back to specific safety requirements, so that traceability links carry semantic weight rather than being nominal references.

Why a Taxonomy, Not a Test List

An unstructured list of test cases is difficult to audit: reviewers cannot tell whether a requirement is covered thinly or thoroughly, and coverage metrics become counts of tests rather than measures of evidence strength. A taxonomy imposes structure on the condition space so that each requirement can be assessed against distinct, non-overlapping categories. The four categories used here — boundary values, equivalence classes, fault injection conditions, and environmental stressors — are chosen because they correspond to four different questions a safety engineer must answer:

• Boundary values: Does the requirement hold exactly at and just beyond its specified limits?
• Equivalence classes: Does the requirement hold for every representative behavior within a partition of the input or state space?
• Fault injection conditions: Does the safety mechanism detect, react to, and recover from credible faults as specified?
• Environmental stressors: Does the requirement remain satisfied across temperature, voltage, vibration, EMI, and similar stress dimensions?

Each category produces conditions with a different evidentiary character. Boundary tests are precise and cheap but narrow; equivalence-class tests generalize but depend on the validity of the partition; fault injection tests validate diagnostic coverage; environmental tests validate robustness margins. A requirement is well-evidenced only when the relevant categories are all represented.

Boundary Values: The Edges Where Requirements Break

For any requirement with a numeric threshold, the boundary set consists of the threshold itself, values immediately inside and outside it, and the transition region where the safety mechanism is expected to act. Consider a requirement: "When coolant temperature exceeds 105 °C, the inverter shall derate output power to 60 % within 500 ms." The boundary conditions include 104.9 °C (no derate expected), 105.0 °C (derate triggered), 105.1 °C (derate triggered), and the timing boundary at 500 ms. A test at 105.0 °C that observes derate at 480 ms passes; one that observes derate at 520 ms fails, even though the temperature condition was satisfied.

Boundary testing must also account for measurement uncertainty. If the temperature sensor has ±1.5 °C accuracy, a test at 105.0 °C cannot distinguish a controller that triggers at 104.0 °C from one that triggers at 106.0 °C. The test condition should therefore specify the sensor's calibrated uncertainty and, where the requirement's tolerance is tighter than the sensor accuracy, use a reference measurement channel rather than the production sensor. This is a common source of weak evidence: the test passes, but the pass is not attributable to the requirement being met.

Equivalence Classes: Partitioning the Behavior Space

Equivalence-class testing divides the input or operating-state space into partitions within which the system is expected to behave equivalently with respect to the requirement. For the derate requirement above, the coolant temperature axis partitions naturally into: below 90 °C (normal), 90–105 °C (warning region, no derate), above 105 °C (derate region), and sensor-fault region (open circuit, short to ground). Each partition needs at least one representative test, and the partition boundaries must be justified — typically by the control software's own threshold constants, which should be traceable to the requirement.

The partition must be derived from the requirement and the design, not from convenience. If the derate curve is nonlinear — for example, 100 % power at 100 °C, 80 % at 103 °C, 60 % at 105 °C — then a single test at 105 °C does not cover the 103 °C behavior, and the 90–105 °C partition is not actually an equivalence class. The correct partition follows the piecewise segments of the derate map. This is where traceability becomes substantive: each equivalence class should cite the design element (the derate lookup table, the threshold constant) that defines it, and each test should cite the class it represents.

Fault Injection Conditions: Proving the Safety Mechanism Works

Safety requirements frequently specify reactions to faults: "Upon detection of a phase-current sensor offset exceeding 15 A, the controller shall transition to safe state within 100 ms." Evidence for such a requirement cannot come from nominal testing; it requires deliberate fault injection. The condition taxonomy for fault injection includes the fault type (stuck-at, offset, open circuit, short, bit-flip), the injection location (sensor, ADC input, software variable, communication bus), the injection timing (before startup, during operation, at a state transition), and the fault duration (transient vs. permanent).

A practical injection for the offset requirement might use a signal generator to superimpose a 20 A DC offset on the current-sensor output while the controller runs at 50 % load. The observable evidence is the time from offset application to the safe-state indication on the diagnostic interface, plus the recorded state-transition log. A pass requires the transition within 100 ms and confirmation that the safe state is actually safe (PWM disabled, contactor open). A common failure symptom is that the diagnostic flag sets but the actuator does not de-energize — the detection path works, the reaction path does not. That distinction must be captured in the evidence record, because it maps to two different sub-requirements.

Environmental Stressors: The Envelope Dimension

Environmental stressors are conditions that do not change the logical input but change the physical behavior of the system: ambient temperature, supply voltage, vibration, humidity, and electromagnetic disturbance. They are orthogonal to the other three categories and must be combined with them. A boundary test at 105 °C conducted at 25 °C ambient does not demonstrate the requirement at −40 °C ambient, where sensor offsets and timing margins differ.

The mapping to requirements should state which stressors are relevant and why. For the derate requirement, supply voltage (9–16 V) and ambient temperature (−40 to +85 °C) are relevant because they affect ADC reference accuracy and gate-driver timing. Vibration is relevant if the current sensor is mounted on a vibrating bracket. The evidence record should identify the stressor combination tested, the test facility or bench configuration, and the measured margin. Where full combinatorial coverage is infeasible, a documented rationale for the selected combinations — for example, corner combinations of voltage and temperature — is itself part of the evidence.

Mapping Conditions to Requirements: The Traceability Structure

The taxonomy becomes useful when each test condition is linked to a requirement through an explicit mapping record. A minimal mapping contains: requirement identifier, condition category, condition parameters with tolerances, expected observable, and the design element that defines the condition. The figure below shows how the four categories fan out from a single requirement and converge on evidence records.

The mapping record is what makes the taxonomy auditable. When a reviewer asks "how do we know SR-07 is met at cold start?", the traceability chain should lead from the requirement to the environmental-stressor condition (ambient −40 °C), to the specific test record, to the measured derate latency, and to the design element (the derate lookup table and its calibration constants) that the test exercised. If any link is missing, the evidence is incomplete regardless of how many tests were run.

Practical Construction of the Condition Set

Building the condition set for a requirement follows a repeatable sequence. First, extract the quantitative and qualitative claims from the requirement text: thresholds, timing, states, and fault reactions. Second, for each numeric threshold, define the boundary triple (inside, at, outside) with tolerances. Third, derive equivalence classes from the design's own piecewise definitions, not from arbitrary spacing. Fourth, for each fault-reaction clause, define injection type, location, timing, and duration. Fifth, identify the environmental stressors that affect the measurement chain or the actuator, and select corner combinations. Finally, record each condition with its expected observable and the design element that justifies it.

Two failure modes are worth calling out. The first is category collapse: treating a boundary test as if it covered an equivalence class, or treating a nominal test as if it covered a fault condition. The second is tolerance omission: recording a condition as "105 °C" without stating the measurement uncertainty, which makes the pass/fail judgment unreproducible. Both are detectable by reviewing the mapping records against the taxonomy — which is precisely the point of maintaining the taxonomy as a structured artifact rather than a prose description.

The taxonomy also supports prioritization. Boundary and fault-injection conditions typically carry the highest evidence value per test because they probe the requirement's actual limits and the safety mechanism's reaction path. Equivalence-class tests provide breadth, and environmental tests provide robustness margins. When schedule pressure forces trade-offs, the traceability record should show which categories are covered and which are deferred, so that the residual risk is visible rather than hidden in an aggregate test count.