vPIL by efs.
Test speed beyond limit.
Test software and system under test belong apart.
We lift execution to an abstracted level.
vPIL is a build and execution environment for the software under test. Instead of running a physical PIL board per test PC, the target software runs virtualised in QEMU, on real hardware or under Windows and Linux. This makes the execution unit freely interchangeable. In a real project, test runtime dropped from eight days to under 30 minutes, a factor of 400. Available as standalone tooling or as a plugin for PikeTec TPT.
Release tests in minutes
instead of days.
PIL boards are expensive, error-prone and available only once per test PC. They block the CI/CD pipeline and make developer tests almost impossible. vPIL resolves this coupling. Tests run in parallel in the CI pool, on the build server or locally on the developer machine. With the same compiler and the same target as the series build. In productive use in OEM series projects, vPIL reaches release level 3, in one project even level 4.
Discover vPIL by efs in detail.
Compact, clear and to the point.
From virtualised execution to closed-loop simulation.
Virtualised PIL via QEMU
We replace the physical PIL board with emulation.
- Series maturity: Productive use in OEM series projects with release level 3 achieved, level 4 in one project.
- Emulated target hardware: The series software runs in QEMU instead of on a PIL board. No hardware bottleneck, no waiting for free test benches.
- Parallelisation in the CI pool: Nightly tests scale horizontally across all available build nodes.
- Supported targets: TriCore, STM32, ARM as well as x86 and x64 under Windows and Linux.
Plug-and-play connectors
We integrate existing test frameworks directly.
- Direct integration: TPT, Google Test, C# and OSLC with no adaptation effort.
- Investment protection: Existing test suites run on vPIL without needing to be rewritten.
- Plugin or standalone: Usable as standalone tooling or integrated into PikeTec TPT.
Zero-overhead integration of build artefacts
We execute what the series build produces.
- No rebuild: Compiled .o files are turned into an executable SUT without a new build.
- Automatic interface adaptation: Wrappers and serialisers for binary interfaces are generated, not written by hand.
- Series proximity: What gets tested is exactly the artefact that ships later.
Interchangeable execution targets
We switch the execution unit without changing the test.
- Seamless switching: Microcontroller, emulator or SIL, with no adaptation to tests or SUT.
- Identical results: Same test, different target, same outcome.
- Local and distributed execution: On the developer machine or remotely on the build server.
Timing and closed loop
We measure under real conditions.
- Timing measurement: Running SUTs with real data to assess timing behaviour.
- Closed-loop simulation: Embedding the SUT into your own simulation environments, with no hardware test bench.
- Developer tests with series setup: Compiler, target and toolchain as in the series build, right at your workplace.
Our approach:
Clarity in four steps.
01 Analysis (1 to 2 days): We review the toolchain, test frameworks and build environment. Where is the bottleneck and which targets are in use?
02 Integration: Connecting the existing test suites, setting up the execution environment and configuring the target platforms.
03 Verification: Counter-run against the previous PIL execution. We prove that results stay identical.
04 Rollout: Scaling in the CI/CD pipeline and enabling the team. Including documentation and handover.
Eight days of test runtime is not a technical necessity.
