Designing a test bench: mechanics, electronics and software

A test bench is not a mechanical machine to which you add sensors, then a program. It is a single system, in which every mechanical choice affects the wiring, and every wiring choice affects the software. Before describing the approach I follow to design a turnkey bench, a word on vocabulary and on the state of the art: test bench, test rig and metrology bench do not mean quite the same thing.

Test bench, test rig, metrology bench: what are we talking about?

The three terms are often used interchangeably. Standards nevertheless make it possible to tell them apart by what the bench must produce.

A test rig carries out tests in the sense of ISO/IEC 17000: determining one or more characteristics of an object according to a procedure. Endurance, ageing, fatigue, climatic or qualification tests: the product is subjected to loads, and its behaviour is observed.
A test bench checks that a product meets its requirements. The expected result is often a verdict, pass or fail, in development as well as at the end of a production line. In English, test bench also refers more broadly to any environment used to verify a design; in electronics and software, it can even be entirely virtual.
A metrology bench is about the measurement itself. It is a measuring system in the sense of the International Vocabulary of Metrology (VIM): a set of instruments assembled to provide measured values. It relies on three notions: calibration, measurement uncertainty and metrological traceability, that is, relating the result to a reference through a documented, unbroken chain of calibrations.

In practice, the boundary is blurred. A test rig needs well-controlled metrology for its results to mean anything, and a metrology bench is controlled like a test bench. The metrology benches for the ELT mirrors are a good example: measurement is the goal, but it relies on a complete control system. Laboratories that seek recognition for their tests and calibrations rely on ISO/IEC 17025.

The state of the art: what has changed

From instrument to system: the original bench was a workstation where a technician read values from an oscilloscope and a multimeter. Today, acquisition, control and recording are automated.
Modular platforms: off-the-shelf real-time controllers, chassis and acquisition modules replace electronics developed for a single bench. Examples are given below.
Simulation in the loop: with hardware-in-the-loop (HIL), part of the real system is replaced by a model running in real time. A controller can thus be tested before the machine it controls exists.
Software at the centre: test sequencers, real-time test environments, scripting languages for analysis, open communications (TCP/IP, gRPC) with the client's systems.
Data and traceability: each result must be traceable to the part tested, the bench configuration and the calibration status of its sensors.
The life cycle: a bench often outlives the product it was designed for. Modularity, configuration outside the code and documentation are what allow it to evolve.

Start from the need, not the solution

What the bench must prove: which quantity to measure, with what uncertainty, over what range. This is the question that sets everything else.
The context of use: in a laboratory or on a production line, by a test engineer or by an operator, a few tests a year or several a day. The same measurement need leads to two very different benches.
The site constraints: available space, power supplies, IT network, the client's safety rules.

This work is done with the client, often as early as the tender response. A misunderstood need costs far more to correct at acceptance than at the specification stage.

Split into three disciplines, take care of the interfaces

The bench is split into three subsystems: mechanics, electronics and software. Each has its own designer, but the difficulties almost always lie between the three:

Mechanics and electronics: sensor locations, cable routing, space for the electrical cabinet, earthing.
Electronics and software: channel list, signal types, acquisition rate, behaviour on a fault.
Software and mechanics: motion sequences, end stops, safety functions.

I freeze these interfaces early, in a document shared by the whole team: the channel list, in particular, is the common reference for the wiring technician and the developer.

Mechanics: hold the part, protect the operator

The frame must be stiff enough not to distort the measurement, and isolated from vibration when the measurement is sensitive to it.
The part mounting must be repeatable: a badly positioned part gives a wrong measurement, even with the best acquisition chain.
The operator must be able to load the part, reach the settings and carry out maintenance without dismantling the bench.
Safety is designed in from the start: guards, emergency stop and protective devices, rather than added at the end.

The 3D model, made for example in FreeCAD, is also used to check the footprint of the cabinet and the routing of the cables.

Electronics: from physical quantity to signal

The sensors are chosen for the target quantity, range and uncertainty, then each is given suitable signal conditioning.
Acquisition and control: fast acquisition for measurement, a PLC or real-time controller for control and safety functions. The choice depends on the required rate and level of safety.
The electrical cabinet is drawn with electrical design software, QElectroTech for example: the schematics, terminal blocks and cable markings form the reference documentation for both wiring and maintenance.
The safe state: every output is wired so that the absence of a command puts the bench in a safe state, even if communication is lost.

Software: control, measure, trace

Test sequencing: each test follows a defined sequence, with steps, pass criteria and responses to faults.
The operator interface shows what matters: the state of the bench, the current step and the alarms. Advanced settings are kept for the engineer.
Traceability: each result is recorded with the part tested, the bench configuration, the software version and the date.
Configuration outside the code: channels, thresholds and sequences are described in files, so that the bench can evolve without recompiling everything.

The language and tools follow those of the client and their maintenance team. Some examples below.

Examples: acquisition and control hardware

The same functions are found at the main suppliers. The choice depends on the rate, the bench environment and the tools already in place at the client's site.

National Instruments (NI): CompactDAQ (cDAQ) for PC-based measurement, CompactRIO (cRIO) for real-time control and FPGA, PXI for the most demanding test systems.
Dewesoft: data acquisition systems (SIRIUS, KRYPTON) run with the DewesoftX software, and IOLITE, which combines acquisition and real-time bench control, with analogue, digital and EtherCAT outputs.
WAGO: the modular 750/753 I/O system, connected to a fieldbus (EtherCAT, Modbus TCP…) through a coupler, or combined with a PFC controller programmed in CODESYS.
Gantner Instruments: I/O modules and Q.station controllers for distributed acquisition, configured and operated with the GI.bench software, and APIs for integration, including in Python.

Examples: programming the bench

LabVIEW: a graphical language built for data acquisition and control. A bench application is often organised into parallel loops that exchange messages: acquisition, control, user interface and logging. LabVIEW Real-Time and LabVIEW FPGA deploy the same language on a cRIO.
NI TestStand: a test executive. It runs steps that call code modules written in LabVIEW, C, .NET or Python, compares each measurement with its limits, runs tests sequentially or in parallel and generates the reports.
NI VeriStand: a real-time test environment, designed for hardware-in-the-loop. Channels, simulation models and alarms are configured in a system definition, without programming the real-time loop; scenarios are written as stimulus profiles or real-time sequences.
Python: widely used for data analysis and test automation. Suppliers provide their own libraries: nidaqmx for NI hardware, niveristand for writing VeriStand sequences in Python, as well as APIs from Dewesoft and Gantner.

A minimal Python example, which reads a voltage on the first channel of an NI cDAQ module:

import nidaqmx

with nidaqmx.Task() as task:
    task.ai_channels.add_ai_voltage_chan("cDAQ1Mod1/ai0")
    print(task.read())

On a bench, the same reading fits into a TestStand sequence or a test script, with its limits and its logging.

Integrate, validate, deliver

The acceptance tests are prepared from the specification stage: each requirement in the specification has a test that verifies it.
Integration is done in stages: each subsystem is tested on its own before the complete bench, so that a fault is found where it lies.
The documentation delivered includes the drawings, the schematics, the user manual and the acceptance reports.
Training the users is part of the delivery: a bench that nobody knows how to use is not finished.

An example: an aeronautical braking test system

At STYREL, we modernised the braking test system of an aeronautics client. Their goals: guarantee real-time performance, make data exchanges reliable and be able to develop their braking algorithms themselves.

A hybrid software architecture on a cRIO platform: LabVIEW for data management, embedded C for real-time processing. It combines performance, determinism and modularity.
A dedicated API provides reliable TCP/IP communication with the client's supervision system.
The results: real-time response under 1 ms, precision under 10 µs, and four times as many test scenarios.
An end-to-end project, from proof of concept to commissioning, through design, development and validation, using an Agile (Scrum) approach.

This example sums up the approach: start from the client's goals, choose the architecture accordingly, and leave them in control of what needs to evolve.

Key takeaways

A test bench is designed as a single system: problems come mainly from the interfaces between mechanics, electronics and software.
The client's context of use matters as much as the measurement itself.
Safety, traceability and acceptance are prepared from the start of the project, not at the end.