Test and simulation software

Validative Software Studio

Name: Validative Software Studio
Brand: Validative Systems

Needsreadiness status for Validative Software Studio — from Gok

One application to build plant models, simulate electronic control units (ECUs), run manual and automated tests, and report the results.

Validation work is usually spread across separate tools: one to build the model, another to write the tests, another to run them, and a spreadsheet to record what happened. Software Studio holds the whole sequence in one application, so what is built in one step is ready for the next.

Teams can begin testing before hardware is available, repeat the same tests on every software change, and hand a manager a report rather than a summary written by hand.

Book a product demo Contact our engineering team

Starting fromNeedsstarting price and currency (EUR, INR or both) — from Gok

Software Studio main application window

Needsimage — Software Studio main application window — from Gok

Problems addressed

Three reasons validation runs late

The same three problems come up on almost every validation programme, and none of them is about engineering skill.

Testing by hand
Tests run by hand take time and are hard to repeat exactly. The same test can give a different result on a different day, and a defect slips through unnoticed.
Testing starts too late
When testing waits for hardware, faults are found near the end of the programme. A fault found on the vehicle costs far more to fix than the same fault found in simulation.
Results are scattered
Results end up in log files, spreadsheets and email. Nobody can answer "what was tested, and what passed?" without asking an engineer to go and look.

Model development and simulation

Start testing before the hardware exists

A plant model is a software copy of whatever the control unit is connected to — a motor, a battery, a valve, a vehicle. Software Studio is where that model is built.

With the model in place, the control unit software runs against it on an ordinary PC. No bench, no wiring, no waiting for a prototype. The same model is used again later, unchanged, when the test moves onto real hardware.

Plant models are built and edited in the application
Control unit software runs against the model on a PC
The same model is reused when testing moves to hardware

Model development view — building a plant model

Needsimage — Model development view — building a plant model — from Gok

Manual ECU testing

Work with the control unit by hand

Not every test is worth automating. During development an engineer often needs to send one signal, watch what comes back, and decide what to try next.

There is a manual mode for that work: send and receive signals, inspect the traffic on the bus, and run checks by hand while the unit is live.

Send and receive individual signals
Inspect bus traffic as it happens
Run checks by hand, without writing a script

Needsconfirmation that manual ECU testing is in the released version — from Gok

Manual test view — sending a signal and reading the response

Needsimage — Manual test view — sending a signal and reading the response — from Gok

Automated test execution

Write a test once, then run it on every change

Tests are written in Python and kept as ordinary files. They live in your version control system, next to the software they test, and they are reviewed the same way code is.

A suite runs unattended, in simulation or on hardware connected to the real ECU. The test itself does not change when the target changes.

Tests written in Python, stored as plain files
Suites run unattended, in simulation or on hardware
One test, either target — the test does not change

The hardware a suite can run on

An automated test suite running

Needsimage — An automated test suite running — from Gok

Test reporting and analysis

Show what was tested, and what passed

Every run produces a report: which tests ran, which passed, which failed, and the recorded signals around a failure. A manager can read it without an engineer in the room.

A coverage view answers the harder half of the question — which conditions the suite does not test yet. That is usually where the next defect is waiting.

A report for every run, per test and per failure
Recorded signals around the step that failed
A coverage view of the conditions not yet tested

Test report with the coverage view

Needsimage — Test report with the coverage view — from Gok

For engineers

How it fits your engineering environment

Software Studio runs alongside the benches and tools a team already has. Where a suitable bench does not exist yet, we design and build hardware-in-the-loop (HIL) systems and test rigs for the application.

Application

Platform: Windows desktop application
Installation: Runs on an engineer’s own PC

Tests

Test language: Python
Storage: Plain test files, kept in your version control system

Test targets

Simulation: Plant model and ECU software on the PC
Validative hardware: Electron eins desktop test unit
Third-party rigs: Adapters developed on request

Interfaces

Vehicle bus: CAN

Tell us what the bench is and what it has to drive, and we will say whether an adapter is straightforward.

Continuous integration

Running the suite on every code change

Planned

Continuous integration (CI) means a server builds the software and runs the tests by itself whenever a developer commits a change. Nobody has to remember to start the suite, and a regression is found the same day it is introduced.

Running Software Studio suites from a CI pipeline is planned. It is not available today, and the tests a team writes now will not have to be rewritten for it.

Assisted engineering

Help with the first draft

Planned

Some of the work around a test is repetitive rather than difficult: a first plant model for a component that behaves much like many others, or a first test script from a written specification.

We are developing assistance for exactly those first drafts, using AI. An engineer reviews, edits and accepts anything produced this way before it enters a project. The judgement stays with the test engineer, which is the only arrangement a validation team should accept.

Needsconfirmation of which assisted-engineering features are in the released version — from Gok

See it

Screenshots and demo video

Screens from the application, full size, and a short walkthrough of one complete test run.

Software Studio main application window
Needsimage — Software Studio main application window — from Gok
Model development view — building a plant model
Needsimage — Model development view — building a plant model — from Gok
Manual test view — sending a signal and reading the response
Needsimage — Manual test view — sending a signal and reading the response — from Gok
An automated test suite running
Needsimage — An automated test suite running — from Gok
Test report with the coverage view
Needsimage — Test report with the coverage view — from Gok

Product demo video

A two to three minute walkthrough: build the model, run the suite, read the report. It plays only when you start it.

Needsdemo video (2–3 minutes) — file or hosted link — from Gok

Prefer a live demonstration? Book one and bring your own test case.Book a product demo

Next step

See it run on your own test case.

Bring a function your team has to validate. We will show the model, the test and the report for it — online, or at our engineering lab in India.