Use Cases
vHaaS fits wherever embedded software teams need reliable, shared access to real hardware. These scenarios cover the most common ways teams use the platform — and the concrete value each one delivers.
Remote ECU development
Book an assembly, open a browser terminal, and you are connected to the hardware. The VM backing your session already has the relevant tool chain, debugger configuration, and network routes in place. Flash, debug, and iterate exactly as you would at a local bench — without needing to be near it.
Each booking gives you exclusive access for the session duration. When you finish, vHaaS resets the environment automatically so the next session starts from a known-good state.
- No hardware contention
- No lab access required
- Identical environment for every developer
Automated hardware testing in CI
A GitLab CI job that runs against real hardware with vHaaS follows the same pattern every time:
- The job calls the vHaaS CLI to reserve an assembly.
- Your test suite runs against the hardware — exclusively, with no parallel pipeline interference.
- Results are collected and the assembly is released.
The VM image is version-controlled, so results are reproducible across runs, branches, and team members without maintaining dedicated test machines or hand-crafted access scripts.
- Hardware-in-the-loop as a standard, repeatable CI step
- Reproducible results across runs and branches
- No dedicated test machines or custom access scripts
Shared HIL test bench
Registering your bench as a vHaaS assembly makes it visible and bookable to every member of your group. Reserve a time slot in advance, connect remotely, and the platform enforces exclusive access — no coordination overhead, no "is anyone using the bench?" messages.
Assembly health is monitored centrally. If something is wrong with the setup, vHaaS surfaces it before it interrupts your session.
- Full team visibility into availability
- No scheduling conflicts
- Defective setups flagged centrally, not discovered mid-session
Cross-company collaboration
A partner's engineers can belong to your organization and to their own at the same time. Add them to a group of their own and share only the assemblies that group needs — they book and use the hardware independently, through the same access controls as your own teams, with the hardware in a single auditable location.
The same model applies to other cross-boundary patterns: external consultants with time-limited access, two internal departments sharing a scarce hardware variant, or a subcontractor validating against your physical platform. Neither party needs to build or maintain remote access infrastructure.
- Hardware shared with partners without shipping or duplication
- Access scoped per group, revocable at any time
- No bespoke remote-access infrastructure required
Organization and visibility structure
ECU calibration and measurement
Book the assembly, open your calibration tool, and point it at the vHaaS virtual machine. The VM is pre-configured with the correct driver, network interface settings, and XCP channel to the target ECU — your CANape session connects the same way it would over a local bench network.
Your booking gives you exclusive access for the session duration. The hardware is stable and undisturbed throughout your measurement, regardless of where you are working from.
- Full XCP connectivity without physical lab access
- No hardware conflicts during your session
- Works for remote and distributed teams
Shared virtual machine environments
Not every workflow involves physical hardware. A vHaaS assembly can be a standalone VM — pre-configured with the right compiler version, tool chain, license settings, and network access, bookable like any other resource.
This is useful for:
- Standardised developer environments — new team members are productive immediately, not after days reproducing a local setup
- Configuration-sensitive tools — a CANoe or DaVinci Configurator setup where version consistency directly affects test comparability
- Tool chain updates — applied once, centrally, and available to everyone immediately
- No environment drift
- Faster onboarding
- Consistent baseline across the team