Custom test systems
Test rigs and hardware-in-the-loop (HIL) systems, built around your application
Bring us your application requirement — even if you don’t know the test architecture. We design and build the rig.
Most enquiries start with a part and a question, not with a specification: this is what we have to test, and we are not sure how it should be tested. Working out the test architecture is part of the job. It is not something you need to have finished before you talk to us.
We take the requirement, propose a test concept and a scope, and then design and build the complete system — mechanics, electronics, wiring, models and test software — and hand it over working.
One of our own test rigs, anonymised — no customer marks, logos or part numbers
Needsimage — One of our own test rigs, anonymised — no customer marks, logos or part numbers — from GokWhat we need to start
- The part or system to be tested
- What has to be tested about it
- A test standard, if one applies to you
- Your target timeline
Four short answers are enough for a first conversation. If you already have a test specification, send it and we will work to it.
Send your requirements and we will scope it.
Types of test systems
What we build
Five kinds of test system, each one scoped to a single application: your part, your interfaces, your test requirement. Nothing here is a catalogue product.
Every drawing on this page is a concept illustration — it explains how a system of that kind is arranged. It is not a photograph of a delivered rig, and it is labelled so you never have to guess which you are looking at.
ECU HIL systems
Hardware-in-the-loop systems, scoped per control unit
A hardware-in-the-loop system puts the real control unit on a bench and gives it a system to control. The vehicle, the machine or the actuator it expects is represented by a plant model running in software. The signals it reads and drives are provided by real input and output hardware, through wiring built for that unit.
To the control unit this looks like the real system, so its software can be tested against conditions that would otherwise need a prototype vehicle — including conditions nobody would create on a road.
Scope is set per control unit: which signals it needs, which bus messages it expects, which faults have to be provoked, and how much of the surrounding system the model has to represent. That is why these systems are quoted per project.
Not every requirement needs a rig. If a desktop test unit covers what you have to test, we will tell you that rather than quote a rig for it.
What the system is made of
EV & battery test systems
Battery management tested on simulation, then on the bench
An electric-vehicle (EV) battery test system lets a battery management system (BMS) be tested against conditions that are slow, expensive or unsafe to create with real cells. The cells and the pack are a model; the controller is real.
A scenario runs first in simulation, before any hardware is tied up. The same scenario then runs on the bench with the real controller in the loop, so the two results can be compared and a difference can be explained rather than argued about.
The kind of behaviour this puts under test
- How the controller reacts when a cell drifts away from the others
- How it behaves when a measurement goes out of range, or stops arriving
- What it does when a sensor line is opened or shorted during a test
- Whether it reports the fault it should, on the bus, every time
We publish this as a capability. Tell us the controller, the interfaces and the scenarios you have to cover, and we will propose a concept and a scope.
Steering & braking rigs
Steering and braking test rigs
We design and build test rigs for steering and braking actuators: real load and position mechanics, a vehicle dynamics model in software, and the actuator under test in the loop between them.
This is a capability statement, and we will keep it as one. We publish no delivered steering or braking rig and imply none. Tell us the actuator, the loads and what has to be measured, and we will propose a concept, a scope and a price for it.
Hardware & software integration
Mechanics, electronics, wiring and software — one delivery
A test rig is one system, so we deliver it as one. There is no integration gap left between suppliers, and no part of the rig where the answer is “that was somebody else”.
Rigs you already own
Tests do not have to be rewritten for each bench. We build rigs in-house, and we connect to a third-party rig through an adapter written for that rig, so one test suite can run on simulation, on a desk unit and on the bench.
Signal conditioning & fault injection
Getting the right signal in, and breaking it on purpose
A control unit expects each signal at a particular level and shape. A sensor on a bench rarely delivers exactly that, and a test usually wants to deliver something specific instead. Signal conditioning is the hardware in between: it changes the signal to the level the test needs, in both directions, so the unit under test sees what it would see in the real machine.
Fault injection is the ability to break a signal on purpose, under the control of the test. The rig can open a line, short it to ground or to the supply, or remove a bus connection — and then record what the unit under test does about it.
Why a rig does this at all
These are the faults that are unsafe, slow or impractical to create in a vehicle. On a bench they are safe, they are repeatable, and the same fault can be applied again on the next software release to prove the behaviour has not changed.
Faults a rig can apply
- Open circuit — the signal line is cut, and the unit sees a broken wire
- Short to ground — the line is pulled low while the unit is reading it
- Short to the supply — the line is pulled high the same way
- Bus disconnect — the unit loses the network it was talking to
- Supply interruption — power or ignition is removed mid-operation
How we design the fault side
Design & development workflow
How a rig gets built
Seven steps, and the first two are where most of the risk is removed. You see the proposed test architecture and the scope it is priced against before any hardware is ordered.
Requirements
What has to be tested, on which part, and what the result has to show.
Concept & quote
A proposed test architecture, a written scope, and the price for that scope.
Design
Mechanical, electrical and software design: interfaces, wiring, models, test sequences.
Build
Mechanics, electronics and harnesses built, assembled and checked.
Integrate
Hardware and software brought together, and every signal checked end to end.
Commission & validate
The rig is run against the agreed requirement, with your engineers present.
Handover & support
Documentation, training on your part, and support agreed as part of the scope.
What you receive
A rig your own team can run without us
A test system is only useful if your engineers can run it, extend it and maintain it after we have left. So the delivery is not only the hardware.
Needswhat support after handover includes — period, response and what is chargeable — from Gok
Example configurations
What a rig looks like, and what we will not show you
We show our own rigs, anonymised: no customer names, no logos, no part numbers, and nothing that identifies a programme. Where we have no photograph we can publish, you get a labelled concept drawing instead — never a stock photograph of somebody else’s bench.
Send your requirements
Tell us the part and what has to be tested.
You do not need a test specification, a rig concept or a drawing. The part, the test requirement and your timeline are enough for us to come back with a concept and a scope.
We reply within 1 business day.