Auto-generate tests.
Turn requirements into nominal, boundary, and recovery cases.
How Vinaka works · Industrial-controller example · Fault configuration exampleSkip walkthrough
compressor-controller.elfTest Speed trackingVirtual timeVirtual bench
Compiled firmware · modeled sensors, interfaces, and devices
Controller MCUCompiled firmware
RS-485 / Modbus RTUFirmware-facing interface
Motor driveSpeed feedback · register 40001
Part of a nine-component bench, including sensors, a load valve, and the modeled plant.
Controller MCU
- Firmware
- compressor-controller.elf
- Interfaces
- ADC · GPIO · UART
- Test suite
- Controller regression
Run the firmware
Workflow and evaluation detailsCode, evidence, and fit
Follow an industrial-controller example from a connected virtual bench through Python test conditions, a timed fault scenario, and execution evidence.
Vinaka is building one development loop for high-fidelity emulation, automatic test generation, fault injection, and failure tracing. Run firmware, explore failure conditions, and bring execution evidence into the next engineering decision.
This example connects a controller to sensors, a motor drive, and a modeled plant. A single bench brings the components and firmware-facing interfaces into the test.
The Python example requests 1,800 rpm and checks the healthy reply at 2.84 seconds against ±5%. This nominal-speed check precedes the fault activation at 3.00 seconds; the fault plan defines the subsequent diagnostic check.
def check_nominal_speed(bench):
console = bench.port("controller", "Console")
bench.wait_ms(400)
console.write_line("SET_RPM 1800")
bench.wait_ms(2400)
request = console.write_line("GET_SPEED 17")
reply = console.expect_line(
pattern=r"SPEED 17 [0-9]+",
after=request.submitted, within_ms=200,
)
rpm = int(reply.text.rsplit(" ", 1)[1])
assert 1710 <= rpm <= 1890The fault-plan example sets reported speed to 720 rpm in Modbus register 40001 from 3.00 to 5.00 seconds. The recovery requirement calls for a mismatch diagnostic within 500 ms of the first incorrect reply.
target: { component_id: motor-drive, endpoint: Modbus RTU }
filter: { register: 40001 }
operation:
primitive: set
params: { value: 720 }
activation: { at_ms: 3000 }
disable: { at_ms: 5000 }
validation:
diagnostic: SPEED_TRACKING_FAULT
within_ms: 500
anchor: first_mismatched_replyThe fault-plan example keeps the target, override, activation time, and recovery requirement together in one readable configuration.
The nominal-speed check passes at 2.84 seconds. Fault activation at 3.00 seconds is followed by the first mismatched reply at 3.04 seconds. That reply starts the 500 ms window for SPEED_TRACKING_FAULT. The missed deadline at 3.54 seconds establishes the diagnostic-check failure.
| Check | Expected | Observed | Virtual time |
|---|---|---|---|
| Nominal speed | 1,710–1,890 rpm | 1,800 rpm; nominal check passes | 2.84 s |
| Reported speed | 1,710–1,890 rpm | 720 rpm | 3.04 s |
| Mismatch diagnostic | SPEED_TRACKING_FAULT within 500 ms | Diagnostic absent at deadline; recovery gap identified | 3.54 s |
How fidelity is evaluated
Evaluate fidelity against the behavior your firmware depends on: interface responses, state transitions, and timing requirements.
Compare the emulated response with a configured response profile, then define the interface behavior and timing requirements that matter for your evaluation.
Evaluating Vinaka
Available for early-access evaluation.
- Who is Vinaka for?
- Firmware and validation teams across embedded products.
- What does it run?
- Compiled firmware against configured emulated hardware. The technical demo establishes the model and interface scope for your target.
- Which problems does it address?
- Expand test coverage, reproduce failure conditions, exercise recovery paths, and inspect firmware behavior in software.
- How is compatibility established?
- Build your evaluation around your target, firmware configuration, interfaces, and a test that matters to your team.
- What should I bring?
- Bring your target details, firmware format, relevant interfaces, and one test or failure to investigate. Use the technical demo to shape your first evaluation.
- What happens next?
- Book a technical demo to see the emulator, discuss your target, and scope an early-access evaluation.