Sample Verification, Validation and Failure Analysis in Design-In

Engineering Context

Verification activity is distributed across a programme rather than concentrated at a single point. Design-in verification informs configuration selection, platform validation supports qualification approval, and failure analysis addresses conditions identified after deployment.

Treating these activities as a single test stage understates what each is intended to establish, and obscures which record applies when a configuration is later reviewed.

Sample Verification

Sample verification is performed before a configuration is approved. Initial samples are evaluated on the target board so that mechanical fit, initialisation behaviour and basic operating characteristics are established while the design can still be revised at limited cost.

For compact platforms, sample verification also confirms that the selected form factor is compatible with connector position, module envelope and enclosure clearance as laid out.

Platform Validation

Platform validation evaluates the selected configuration against the target system under the conditions defined for the programme. Compatibility, stability and, where applicable, performance characteristics are assessed as separate objectives rather than as a single pass or fail result.

Validation scope is defined according to platform configuration, operating conditions and project requirements. The scope applied to a compact fanless system is not necessarily the scope applied to an expandable rack platform.

Failure Analysis

Failure analysis is applied to returned units or field issues where root-cause investigation is required. It is a corrective activity and is not a stage that every programme passes through.

1. Reported condition is reproduced where technically feasible, under the configuration and conditions described in the report.
2. Analysis identifies whether the cause is located in the module, the platform or the operating conditions.
3. Findings are documented so that the reasoning, not only the conclusion, can be reviewed.
4. Corrective action is defined and its effect verified.

Applicable Limitations

Sample verification results apply to the sample configuration and the board revision on which they were obtained. Failure analysis findings apply to the reported condition and the configuration under which it was reproduced.

Design-In Review

Design-in review takes place before samples are built. It examines the board layout, the module envelope, connector position and the thermal conditions the module will operate in, so that mechanical and interface constraints are identified while the layout can still change.

For compact platforms this review often determines the form factor available for the rest of the programme, because a later change may require a board revision rather than a component substitution.

Verification Records

Each activity produces a record with a defined scope. Sample verification records the sample configuration and the board revision used. Platform validation records the configuration evaluated and the conditions applied. Failure analysis records the reported condition, the reproduction configuration and the corrective action.

Keeping the three records distinct avoids a common documentation problem, in which a sample result is later cited as evidence of platform qualification for a configuration it never covered.

When Activities Are Repeated

Sample verification is repeated when the target board or the module configuration changes. Platform validation is repeated when the configuration, firmware or operating conditions move outside the scope of the existing record. Failure analysis is initiated by a reported condition rather than by a schedule.

Defining Scope Before Testing

Scope is defined before each activity begins, because the value of the resulting record depends on it. A scope statement normally identifies the configuration under test, the conditions to be applied, the duration or sample size and the criteria by which the result will be judged.

Where scope is left implicit, two engineers may reach different conclusions from the same data, and the record becomes difficult to reuse later in the programme.

How the Activities Connect

Sample verification informs the configuration that platform validation evaluates. Platform validation produces the record that production material is subsequently controlled against. Failure analysis feeds back into both, either by identifying a configuration issue or by confirming that the reported condition originated outside the qualified configuration.

Treated together, the three activities form a loop rather than a sequence that ends at production approval.

Applying This to a New Programme

For a new platform, the sequence is normally: define the target configuration, evaluate samples on the target board, validate the configuration under the intended operating conditions, approve it for production and then hold it under configuration control. Failure analysis sits outside that sequence and is invoked when a field condition requires investigation.

Programmes that compress this sequence usually do so at the sample stage. The consequence is not that verification disappears but that it moves later, where a finding costs more to act on.

Engineering Summary

Each verification activity answers a different question and produces a different record. Configuration decisions should reference the record that corresponds to the question being asked, and the applicable scope should be defined before production configuration approval.

Related SIMORCHIP Resources