01 Plant model
Build the plant
AIDescribe the plant in plain words. Studio writes the first model.
Validative Studio
From plant model to CI.
One workflow.
Plant models, test cases, simulation, execution, signals and CI in one connected workflow.
Book a demo Windows
The experience
Everything the loop needs. In one window.
Six parts of the testing workflow, in one place. What is built in one is ready in the next.
How simulation worksCore workflow
02 Test cases
From specification to Python
AIA test specification goes in. Studio writes the Python.
TS-114Ramp the request to 8.0 V. The measured output must stay under 6.5 V.
from validative import ecu ecu.ramp("out_request", 0, 8.0)assert ecu.read("out_measured") <= 6.50
03 Simulation
Run without hardware
Real ECU software runs against the model, with no hardware in the loop.
Virtual ECUreal binary
Test cycleloaded
Clock12×
04 Test execution
Automatic or by hand
Start a suite and leave it, or step through it one case at a time.
output_limits12
fault_handling96 / 211
Observe and automate
05 Signals & I/O
Signals, traces and panels
Signals are visible as they happen, on a panel built for the function under test.
Output measured
6.42V
Load current
41.7A
06 CI pipeline
CI built in
Every action also has a command. The same engine runs in the pipeline.
# same engine, no window> validative run output_limits
Targets
Evidence
Scout · inside Studio
AI writes the first draft.
Validation knowledge makes it right.
Scout is the AI layer inside Studio, and the same intelligence does all of it: writing the first plant model, turning a specification into a script, and finding the conditions the suite never covered. What it knows is validation knowledge — ISTQB, ISO 26262, Automotive SPICE and years of ECU test engineering.
ISTQBTesting principles
ISO 26262Safety-oriented validation
Automotive SPICEProcess and engineering rules
Decades of test engineeringPatterns learned from real validation across multiple domains
And what only this team knows.
The team writes down its own validation experience — failure modes, conventions, the things a new engineer learns in week one. Scout uses it alongside the standards.
A written documentNothing is scraped or inferred.
Never sharedIt stays in that team’s Scout.
Never leaves the networkRuns on the customer’s own infrastructure.
The model is not the advantage. The validation knowledge behind it is.
AI is the mechanism. Validation knowledge is the intelligence.
What it finds
Every gap named.
Every draft reviewed.
Scout shows where the suite has holes and proposes a test for each one. Every finding names the rule behind it, so an engineer can check it and say no. Nothing Scout writes — a model, a script or a test — enters the project until someone does.
Boundary
Output limit at exactly 6.50 VTests exist at 6.48 and 6.55. The exact limit is never tested.
Negative
Output request while the supply is out of rangeNo test checks what happens when the input cannot be trusted.
Class
Supply between 9 and 11 VFourteen similar conditions. Only one of them is tested.
3 tests proposed · none added until reviewedRuns inside Studio, on every commit
Reporting
Coverage against requirements.
Requirements are imported in ReqIF. Every run reports which requirements have tests, how those tests ended, and which requirements have no test at all.
Test summary reportoutput_limitsIllustrativebuild 4127 · 03:12
48requirements imported
44covered by tests
4no test linked
5tests failed
requirementtitletestsoutcomestatus
The last row is the one validation teams look for.A requirement with no linked test never appears in a pass rate.
Per requirement
Linked tests, and how many passed, failed or were not run.
Per failure
The step that failed, with the signals recorded around it.
Per run
Build, target and time, so two runs can be compared.
Formats
HTML to read, PDF to circulate, JUnit XML for the pipeline.
On tool qualification. Classification under ISO 26262-8 is the tool user’s to make. We supply the input: intended use, restrictions, defect list.
On requirements tools. Import uses ReqIF, the open exchange format for requirement management tools. Results stay in Studio and are not written back to the source tool — the run exports as JUnit XML or PDF, and that is what gets attached against the requirement there.
Overhead
More of the day spent testing. Less spent preparing to test.
Our design target is to remove the repetitive work around validation: plant model setup, test preparation, execution setup, panel wiring and pipeline integration.
Thirty percent less validation overhead is the target we design against, not a measured result. Measured numbers will come from pilot teams, and we will publish them whatever they show.
Set up the plant modelagain
Prepare the test casesby hand
Set up the runscripts
Wire a panelone signal at a time
Integrate the pipelineafterwards
StudioTest Result
The proof
Twelve minutes.
One bug the suite could not have found.
00:00
Run starts. 211 cases queued.
Signals moving. Output following the request.
Boundary case reached. Request at exactly 6.50 V.
Unexpected response. The output does not clamp.
Test fails. The limit is exceeded.
Bug found, before any hardware existed.
The case that failed is the one Scout flagged as never tested.
Watch it run