FASTEST Smart Test Management orchestrates physical and virtual testing in complex lab environments.

A battery pack for an electric vehicle can take up to a year to clear its full aging and abuse test program on equipment that costs millions and sits idle whenever it isn’t wired to a unit under test. FEV.io built its Smart Testing Management Platform to change that arithmetic, and validated it at TRL 6 on one of the hardest testing problems in automotive: battery systems.

Testing is becoming the bottleneck

Ask a test-field manager where the schedule breaks, and it’s rarely the test itself. It’s everything around it.

Physical benches are scarce, capital-intensive assets. Chambers split into narrow capability classes, i.e., endurance, environmental, abuse, and a request that doesn’t match an available chamber simply waits. Abuse tests need dedicated bunkers and run one at a time for safety reasons, which caps throughput regardless of demand. Long-duration procedures, such as aging tests, can occupy a chamber for the better part of a year.

Meanwhile, data management is still largely local: spreadsheets, facility-specific tools, and manual report generation. That’s workable at small scale, but it doesn’t hold up against the direction regulation is moving. The EU Battery Passport Regulation, effective 2027, expects traceable, structured, near-real-time data, not a folder of exported spreadsheets.

Virtualization is the obvious lever: simulate what can be simulated, keep physical benches for what simulation can’t. But most organizations run virtual and physical testing as two separate worlds, coordinated by hand. That’s the actual bottleneck, not compute, not chamber count, but the manual handoffs between planning, models, execution and evidence.

The question every test field is asking

Automotive validation today spans physical benches, virtual models, software-in-the-loop, hardware-in-the-loop, and distributed teams working across all of them. So, the question is not “should we virtualize more tests”. Most organizations already know the answer is yes. The real question is:

Can every test, virtually or physically, run through one workflow, from request to evidence, without someone stitching the pieces together by hand?

Smart Test Management: one platform, from request to evidence

Smart Test Management is FEV.io’s answer: a cloud-based platform that manages physical test benches and digital twins in a single workspace, and automates the pipeline connecting them: test request → experiment design → model management and simulation build → scheduling → execution → results visualization and reporting.

It supports development from prototype through product-line deployment, and it’s offered the way engineering organizations actually consume platforms: Platform-as-a-Service on FEV’s Azure cloud, Software-as-a-Service on the customer’s own cloud, consultancy, or a white-box option for teams that want to extend the solution themselves.

Crucially, none of this is battery-specific by design. Battery testing is where FEV.io built and proved it first, but the architecture underneath is a general-purpose test-orchestration layer.

FASTEST Smart Test Management

That proof happened inside FASTEST (Fast-track hybrid testing platform for the development of battery systems), a project funded by the European Union (Grant No. 101103755) and UKRI (Grant No. 10078013). FASTEST set out to combine multi-scale, multi-physics virtual and physical testing to accelerate battery R&D, targeting Technology Readiness Level (TRL)-6 across three use cases, i.e., automotive, stationary, and off-road, and multiple cell chemistries.

FEV’s contribution was the operational hub of that platform: the Laboratory Inventory Management System (LIMS), together with smart test scheduling, orchestration, and hybrid-execution capabilities.

Inside the platform: LIMS as the orchestration hub

Smart scheduling and Design of Experiments

Every incoming request first passes through the Design of Experiments layer, which computes optimal test parameters using Fisher-Information-Matrix-based information assessment – and decides, based on the expected quality of the result, whether the test should run virtually or needs a physical bench.

If a physical bench is required, a scheduling algorithm takes over. It treats the test field as a set of parallel machines with precedence constraints and shared resources, and solves the assignment as a mixed-integer program – matching order requirements against test-bench capabilities, then optimizing the sequence against due dates, chamber occupancy and staffing constraints. It’s the same class of problem as production-line scheduling, applied to a battery test field for the first time.

FMI/FMU co-simulation: any model, any tool

The virtual test bench doesn’t force every partner onto one modeling tool. It relies on the Functional Mock-up Interface (FMI) standard: models built in MATLAB & Simulink, dSPACE, CarMaker, CarSim or Python are exported as Functional Mock-up Units (FMUs), self-contained packages of equations, parameters and, optionally, a solver, and combined automatically into an executable simulation on the co-simulation platform (dSPACE VEOS).

That one architectural choice removes most of the manual integration work that normally sits between “model is done” and “simulation runs”: no manual wiring between tools, fewer places for the process to break, and validated models that carry over from one project or team to the next instead of being rebuilt.

The hybrid pipeline, end to end

Put together, a test request moves through the same six stages whether it ends up virtual, physical, or hardware-in-the-loop:

1. LIMS: the user requests a test and specifies the unit under test, use case, standard and due date.
2. Digital Twin (developed by FASTEST partners led by INEGI): checks whether a suitable model and test procedure exist, and provides the FMU if virtualization is possible.
3. DoE (developed by FASTEST partners led by FHG): computes optimal parameters and decides virtual vs. physical, selecting a bench if physical execution is needed.
4. LIMS: schedules the request and routes it to the assigned resource.
5. Execution: the virtual test bench simulates it, or a physical/HiL bench runs it – including partner benches at Flanders Make, Flash Battery and Ikerlan.
6. Digital Twin Dashboard: visualizes the results on a dashboard, fed by near-real-time MQTT messages regardless of which path the test took.

This is what “concurrent virtual, physical and HiL testing” means in practice: the same intake and scheduling logic dispatches to whichever resource fits, instead of running three separate, disconnected operations.

Proof at pre-production level: TRL 6

FEV.io didn’t stop at architecture diagrams. The final validation exercised the full loop: the LIMS pipeline and virtual test bench were first verified internally with simulated DT and DoE components, then tested live in an integration workshop with concurrent virtual and physical requests, then extended to a project-developed FMU to confirm compatibility with real FASTEST battery models and finally connected to Ikerlan’s HiL bench and Flanders Make’s & Flash Battery’s physical bench.

The result: a platform validated to TRL 6 in an exemplary environment, orchestrating hybrid battery testing across multiple physical, virtual and HiL resources, exchanging structured requests and results, and publishing outcomes over MQTT in near real time. Virtualizing critical characterization experiments also targets acceleration on the order of 1,000× for the tests that qualify – the gap between “run once a year” and “run overnight.”

Built for more than batteries

Battery testing is the proof point, not the boundary. The same LIMS orchestration, scheduling optimization, and FMI/FMU-based hybrid execution apply to any domain where physical and virtual testing need to run side by side – Smart Test Management is explicitly built to extend to ADAS validation and to scale from a single prototype program to full product-line deployment.

That’s the point of proving it on batteries first: few test fields are more constrained – scarce chambers, long-duration procedures, strict safety rules for abuse testing, incoming data-traceability regulation. A platform that orchestrates that environment at TRL 6 has already cleared a higher bar than most testing operations will ever set for it.

What stays with your team

Smart Test Management schedules, orchestrates and virtualizes – it doesn’t decide what’s safe to skip. DoE proposes which tests can be virtualized and with what parameters; the platform executes and tracks the result. Whether a given test is sufficient – for a release gate, a safety case, or a regulatory submission – remains a call for the engineers and test authorities who own that decision. The platform’s job is to make sure that call is made with better information, faster, and with a traceable record behind it – not to make the call itself.

Let’s talk

Interested in what FASTEST Smart Test Management could do for your test field – battery, ADAS, or fleet? Reach out to Christopher Kugler, Lead Solution Manager for Software-Defined Systems (FEV.io), at solutions@fev.io.