NOD-010 — Inject Node Faults

The DIDO-TE SHALL inject each fault specified for a Node by the governing Test Definition.

Node fault injection deliberately introduces a specified abnormal condition into a Node or a condition governing its operation. Fault injection supports controlled evaluation of fault detection, containment, tolerance, recovery, resilience, and failure behavior.

The governing Test Definition identifies the target Node, injected fault, injection point, initiating condition, timing, duration, intensity, scope, expected effects, prohibited effects, termination conditions, and recovery conditions. The governing Test Procedure specifies the actions used to prepare, authorize, inject, control, terminate, and recover from the fault.

An injected fault may affect Node state, processing, timing, inputs, outputs, Node Bindings, Dependencies, interfaces, services, communication, or resource use. Fault injection therefore requires controls that restrict the fault to the target and scope specified by the governing Test Definition.

Fault injection differs from the uncontrolled occurrence of a fault. The DIDO-TE introduces an injected fault deliberately, under identified authority and controlled test conditions. An unexpected fault or an effect outside the specified scope constitutes a Test Execution Exception.

The DIDO-TE preserves the distinction between the fault-injection action, the injected fault, the Node response, and the resulting Test Outcome. The presence of the injected fault does not, by itself, establish the success or failure of the Node.

Uncontrolled, incorrectly targeted, mistimed, excessive, ineffective, or unrecorded fault injection may invalidate Test Results, damage Test Resources, affect unrelated Nodes or Test Executions, or leave the Test Environment in an unknown condition.

NOD-010 is decomposed into the following leaf requirements:

Verification confirms that the child requirements collectively:

  1. Specify each fault, target Node, injection point, initiating condition, timing, duration, intensity, scope, expected effects, prohibited effects, termination conditions, and recovery conditions.
  2. Identify the Authorizing Authority for each fault injection.
  3. Prevent fault injection without the required authorization.
  4. Prepare the target Node, Test Environment, observation mechanisms, containment controls, Test Resources, and recovery mechanisms before injection.
  5. Verify the identity and state of the target Node before injecting the fault.
  6. Inject the specified fault at the injection point, time, intensity, duration, and scope established by the governing Test Definition.
  7. Prevent the injected fault from affecting a Node, resource, Test Environment, or Test Execution outside the specified scope.
  8. Observe the actual fault and its effects on the target Node.
  9. Detect a difference between the specified and actual fault.
  10. Detect an unexpected or prohibited effect of fault injection.
  11. Control, suspend, terminate, or contain the injected fault through the governing Test Procedure.
  12. Handle each Test Execution Exception arising from fault injection.
  13. Restore the target Node and affected Test Environment components to the states specified by the governing Test Definition.
  14. Verify the resulting Node, resource, Node Binding, and Test Environment states after recovery.
  15. Determine the effect of fault injection and recovery on affected Test Executions, Test Outcomes, Test Results, and Evidence.
  16. Record each fault-injection action, authorization, observation, exception, control action, termination, recovery action, and resulting condition identified for retention.
  17. Maintain Traceability among the governing Test Definition, governing Test Procedure, authorization, target Node, injected fault, observations, effects, exceptions, recovery, Test Outcomes, Test Results, and resulting Evidence.
  18. Identify nonconformance with a child requirement as nonconformance with NOD-010.

Assign the delivery phase.

Implementation status derives from the implementation status of the child requirements.

The proposed derived requirement and its decomposition require review and acceptance.


Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register.

Determine whether Fault, Fault Injection, and Injection Point require controlled Terms and Definitions entries before finalizing the child requirements.


The explicit child-requirement links remain on this page until all child pages have been created and finalized. The indexmenu then provides the maintained list of child pages.


© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

  • dido/03-dido-te/99-annexes/annex-c-requirements/03-functional-requirements/03-02-node-requirements/nod-010-inject-node-faults/start.txt
  • Last modified: 2026/08/17 14:20
  • by nick_dido