What we do

Automated validation as a service

We design test strategy, build the rigs, and run validation campaigns on our own Automation Testing System.

Hardware-in-the-Loop

Firmware tested against real hardware over serial or wireless interfaces, under real load.

Control-Loop Profiling

Step responses and profiling of control loops, power supplies, and motor-starting behaviour.

Environmental Testing

Ovens and freezers to characterize behaviour across the full temperature range.

Stress & Lifetime Testing

24/7 sequences and high power-cycling rates to find how a product behaves over its life.

Performance & Reliability

Worst-case CPU and memory usage, supply and control-loop stability, and failure-rate quantification.

CI/CD Integration

Test suites triggered from Jenkins, GitHub Actions, GitLab CI, Bitbucket Pipelines, or Azure DevOps.

Problems

Problems we work on

A fault appears in the field and never on the bench

Intermittent behaviour that needs hours or weeks of running to reproduce, across temperature and load. Manual testing cannot cover it and will not reproduce it consistently.

Testing is manual and cannot be repeated

Validation that depends on an engineer being present, with results recorded by hand and no traceability back to the firmware build that produced them.

There is no data when something fails

A failure observed but not captured, so the investigation starts from a description rather than a measurement.

Each release costs weeks of regression

Manual regression that grows with every feature until it becomes the schedule constraint.

You need evidence for a customer or a standard

Test records tied to specific builds and configurations, retained and reproducible.

Why us

Why choose us

Finds intermittent faults

Environmental and stress testing reproduces issues that only appear under specific conditions.

Repeatable and traceable

Test scripts live in version control, so every result ties back to a specific build and configuration.

Questions you haven’t asked yet

Raw data is retained, so historical runs can answer questions raised later.

Platform

How tests are written

Tests are defined in Python, live in source control alongside the firmware, and support scenario frameworks including behave. Definitions stay short and declarative: a full motor endurance sequence is a handful of lines.

				
					startStopSteps = [0, 2200, -2200, 2000, -2000, 1100, -1100, 300, -300, 0]

stepping_variables = [
    # Cycle through speed requests
    MatrixVariable('SR', steps=startStopSteps),
]

# On top of the default data captured continuously, also log
# embedded state variables and CPU usage
continuously_log_vars += ['=', 'c']

datastore = 'output/{timestamp}-motor_system_tests_5_5hrs_{unitDetails}.hdf5'
				
			

Results land in HDF5, one file per run. Raw data is retained rather than reduced to pass or fail, so historical runs can be re-analyzed against questions nobody thought to ask at the time.

FAQ

Common questions

Testing firmware against real hardware rather than a simulation, with the test system driving inputs, applying loads, and capturing the device’s behaviour. Our rigs use real motors, real dynos, and real thermal chambers rather than modelled equivalents.

Usually not. We add diagnostics to the firmware so the device reports its own internals over the existing comms link. Where external instruments are needed, the system controls them.

Yes. Tests trigger on a firmware release or on a schedule, and results come back attached to the build that produced them.

Rig setup depends on the interfaces involved, and we estimate it before starting. The campaign itself runs as long as the confidence you need requires: reproducing a rare intermittent fault can take weeks of continuous running.

It is retained. Reducing results to pass or fail throws away the ability to answer later questions, and trend analysis across historical runs has found issues nobody was looking for at the time.

Related services