Hardware Element Evaluation: What Does the Evidence Prove?

A familiar component can become an unfamiliar safety problem when its job changes. The part number may be identical, while the required behaviour, fault response and operating conditions differ. The useful question is: what does the available evidence establish for this particular use?

Start with the application

When existing hardware takes on a safety-related role, its evaluation needs a clearly defined application. The useful boundary includes the element, its configuration, the allocated requirements and the conditions being assessed. Those details determine what the evidence needs to establish.

Consider a hypothetical analogue-to-digital converter (ADC). One design needs its measurements only after the supply has settled. Another also needs valid measurements during supply disturbances. Evidence collected for the first design cannot, by itself, establish suitability for the second. The changed requirement needs supporting evidence.

A document is useful when it supports a claim

A datasheet describes the supplier's specified behaviour and limits. Analysis, existing test results and operational experience can contribute to the evaluation argument. Their value depends on whether they cover the configuration and requirements under consideration. Assumptions and extrapolations need a rationale.

For the ADC example, a nominal accuracy result does not establish behaviour during a supply disturbance unless the evidence actually covers that condition. That gap does not prove the component is unsuitable; it identifies something the argument has yet to establish.

The effort also depends on how much of the relevant behaviour can be understood and verified. A simple interface can conceal complex internal behaviour. A familiar component name is therefore a starting point for investigation, rather than a conclusion about the evidence needed.

Keep evaluation connected to integration

Evaluating the element's specified behaviour and potential systematic faults is one part of the safety argument. The integrated design must also address random hardware faults and their effects. Information about failure modes and their distributions connects the element evaluation to that wider hardware safety analysis.

This makes the limits of an evaluation as useful as its conclusions. A result based on one configuration or operating range should reach the integration team with those conditions attached. The evaluation report states pass or fail against the assessed requirements, range and conditions; it does not approve every future use of the component.

Take one question into your next review

Which requirement in our application is supported by this evidence, and under what conditions? Answering that question makes a supplier document, a test report or a history of successful operation much easier to judge. Successful operation elsewhere can be useful evidence, provided its relevance to the new application is established.

The Hardware Element Evaluation concept lesson goes further with classification reasoning, interactive examples and the evaluation process. Use it to explore how the argument is built and where it can fail.