Validation tests

Any product design starts with drafting specifications, where after having confirmed the feasibility, you can list all the expected requirements. It is up to you to segment your specifications in several parts, if your product integrates different sub-assemblies.

The steps that follow, “Preliminary Design” and “Detailed Design”, will take these requirements into account.

At the end of the detailed design phase, you will have to make prototypes of the product, the fruit of the design engineers’ initial conception.

Do you recognize it? We are in a V-model.

During the first phases, the design team will describe the tests needing to be performed to validate the design in a document, the Validation Test Procedure (VTP).

Coinciding with this document and design, and in order to design an industrial product at the source, the design will be submitted to the Test teams.

They then perform a “Design for Test” analysis and begin to imagine the test strategy that will be applied to the product during its manufacturing. This “DfT” analysis is formalized through a report of recommendations given to the designers so that they can take it into account in their study.

Now for the validation phase. Our objective: to carry out all the unit tests, integration tests and qualification tests. We must “validate” the prototypes by checking that they meet all the functional requirements initially defined.

The Validation phase is a complex one because a large number of tests must be performed to verify the functionality of the product as well as its behavior when pushed to its limits. It can also pose some problems of accessibility to the product because the signals to be stimulated or measured are not necessarily and even very rarely located on external connectors or easily available access points!

Another difficulty of this validation stage is validating the product in its environment. Will it integrate correctly into the system for which it was designed? Will it correctly control the elements it must manage? Will it receive and decode external data, such as sensors for example, in the way expected?

It is also a common occurrence that this validation phase require the programming of the product with adequate embedded test software specifically developed for this operation.

This operation is usually based on the VTP (Validation Test Procedure) and on a requirements traceability tool. The latter ensures that each requirement is validated by a test and that any changes to a requirement are monitored.

The milestone is validated when all the requirements have been demonstrated, either by calculation (e.g. measurement precision on acquisition chains), or by inspection (dimensions, etc.), or by compliance with datasheets (environment, etc.), or by testing. A Validation Test Report (VTR) is then written.

We are still in our V-cycle, more precisely on the ascent. At this stage, the testing means are not yet developed because the product can still evolve and we are not yet at the industrialization stage (NPI – New Product Introduction). To compensate for this, some designers use benches to access the signals to be guided or detected. This is where so-called “accessibility” benches called “minute benches” or “Check Labs” come in.

These can also be pre-equipped with the elements to be guided, for example motors, elements to be decoded or even programming probes, which are very useful for the simultaneous validation of hardware and software designs, whether it be the test software or the application.

Moreover, when developed in a responsible way, these benches can be recycled into the manufacturing process as accessibility tools for the diagnosis and repair of the same product.

In any case, this validation step remains a complex one and must be carried out with the utmost rigor. It will be decisive for the life of your product.

All the above steps are generally described in the development process so as to comply with the different certifications ISO9001, EN9100 (Aeronautics), ISO14385 (Medical) … and which are summarized by the same sentence: “Write what you do and do what you have written”.