This white paper presents EVO vHIL, a comprehensive, fully virtualized Hardware-in-the-Loop (vHIL) framework engineered for the co-development and validation of high-voltage electric vehicle (EV) control systems. The platform integrates a custom, pre-production C/RTOS Battery Management System (BMS) firmware, a production-intent Vehicle Control Unit (VCU) daemon executing on Android Automotive OS (AAOS), and a real-time communication bridge over a virtualized Controller Area Network (CAN).
In this revision, the architecture has been expanded in two significant dimensions. First, the BMS firmware now manages a dual-pack topology — a high-voltage traction pack and a physically independent low-voltage auxiliary pack — within the same RTOS environment, providing aerospace-grade redundancy for the vehicle's safety-critical 12V rail. Second, the VCU daemon has been extended with a native Linux user-space SPI driver enabling direct communication with a HomePlug Green PHY modem for DC Fast Charging (CCS Type 2) via ISO 15118 Powerline Communication (PLC).
Modern electric vehicles depend on tightly integrated, distributed software systems where failures carry direct safety implications. Historically, the development of Battery Management Systems (BMS), Vehicle Control Units (VCU), and DC Fast Charging controllers occurred in silos, with validation requiring expensive physical prototypes and dedicated Hardware-in-the-Loop (HIL) benches.
The EVO project addresses this bottleneck by engineering the embedded powertrain software and its validation infrastructure simultaneously. This approach moves validation to the earliest phases of the development lifecycle, enabling:
EVO vHIL is structured as a layered, loosely coupled architecture. Each layer operates in an isolated execution environment and communicates with adjacent layers through well-defined interfaces. This separation ensures that failures in any single layer — particularly the UI application layer — cannot compromise core powertrain safety logic.
The system is composed of six primary layers:
| Layer | Component | Technology |
|---|---|---|
| Embedded Powertrain | Pre-Production BMS Firmware (84S HV + 4S LV) | Custom C / RTOS |
| Simulation Environment | MCU Hardware Emulator | Renode |
| Communication Bridge | Middleware Protocol Translator | Python / Socket I/O |
| Control & Safety | VCU Safety Daemon | Native C++ / AAOS |
| CCS Charging Interface | Linux User-Space SPI Driver + PLC Modem | spidev / ISO 15118 |
| Application | Dashboard UI | VHAL / Android UI |
Unlike standard vHIL testbenches that rely on generic simulation scripts, the EVO architecture runs a custom-engineered, pre-production Battery Management System firmware written in C. Executed within an RTOS environment on a simulated 32-bit microcontroller (via Renode), the firmware is hardware-agnostic and completely unaware of its simulated execution context — ensuring that validation results are fully representative of production behavior.
The BMS firmware implements a formally structured power state machine governing all high-voltage contactor operations. Each state transition is conditional, safety-gated, and executed in a defined sequence to prevent destructive electrical events.
States: INIT → STANDBY → PRECHARGE → DRIVE (normal path) and STANDBY → CHARGE (charging path). Any fault transitions immediately to FAULT, which requires explicit clearance to reset.
The EVO architecture departs from conventional EV design by eliminating the DC-DC converter as the primary source of 12V auxiliary power. A physically independent 4S lithium pack powers the vehicle's low-voltage rail. The BMS manages both packs simultaneously within the same RTOS environment, treating LV state-of-health as a first-class safety signal.
Because the 4S pack is electrically independent from the traction system, a total failure of the 84S pack does not affect the 12V rail. The VCU continues to execute, the contactor coils remain powered, and the BMS retains full authority to sequence a controlled shutdown.
The BMS simulation and the Android OS execute in isolated network environments. A custom middleware bridge serves as a protocol translator and network orchestrator between the two domains, performing stream parsing, protocol encoding, and cross-boundary injection via socket interfaces.
This layer is the key enabler of deterministic fault injection — by intercepting the data stream before it reaches the VCU, testers can reliably reproduce edge cases that would be difficult or impossible to generate with physical hardware.
The core vehicle control logic is implemented as a native C++ daemon executing within the AAOS vendor partition. Telemetry is broadcast to the UI layer via UDP/UNIX sockets using a strict one-way publish model — a crash in the UI process cannot propagate upstream to affect the VCU safety loop.
Rather than routing PLC modem communication through the standard Android HAL, the EVO VCU daemon implements a direct Linux user-space SPI driver via the native kernel SPI device interface. This achieves the latency characteristics required to maintain the ISO 15118 TCP/IPv6 handshake — standard Android HAL abstraction introduces scheduling variability incompatible with the PLC protocol timing budget.
The VCU enforces three externally observable charging guarantees: no premature HV enable, continuous (not sampled) energy validation, and unilateral BMS authority to terminate any session at any time regardless of ISO 15118 negotiation state.
The VCU daemon implements a safety validation model inspired by ISO 26262 ASIL design principles. The model enforces a fail-safe posture by default: any violation of a safety invariant results in an immediate System Inhibit — isolation of the high-voltage contactor and cessation of drive or charge commands.
The three-stage safety check pipeline evaluates: (1) Network Watchdog timeout, (2) Integer-Math Plausibility Firewall, (3) Critical Node Fault presence. All three must pass for normal operation to be permitted.
The Integer-Math Plausibility Firewall uses strict integer mathematics throughout — floating-point operations have non-deterministic execution time on embedded targets. The tolerance floor is dynamic, adjusting at low states of charge to prevent false-positive fault trips.
Six fault scenarios have been validated:
| Scenario | Injection | Expected Response |
|---|---|---|
| Overvoltage Event | Corrupt HV cell voltage fields above threshold | System Inhibit — Contactor Drop |
| Sensor Variance Mismatch | Delta between cell sum and pack aggregate | Plausibility Fault — System Inhibit |
| Phantom Node (CAN Loss) | Drop all frames from critical participant | Watchdog Timeout — System Inhibit |
| LV Pack Under-Voltage | Drive 4S aux toward critical threshold | Graceful Isolation — Controlled Shutdown |
| Rogue Charger Overcurrent | Inject EVSE telemetry exceeding demand | Rogue Charger Fault — Relay Severed |
| Thermal Runaway | Escalate temperature sensors to critical | Thermal Fault — Highest Priority Inhibit |
The orchestration layer manages the deterministic boot sequence: Virtual Android OS → MCU Simulation → VCU Daemon → CAN+UDP Bridge → OS Boot Flag Poll → Environment Ready. The orchestrator polls the Android boot completion flag before establishing inter-layer tunnels, preventing race conditions and guaranteeing a known-good system state before any test scenario executes.
Initial integration testing successfully demonstrated: closed-loop communication stability with no packet loss under nominal conditions; powertrain/UI isolation verified (UI termination caused no disruption to VCU); plausibility firewall enforcement on corrupted frames; non-permanent-latching fault recovery; direct SPI hardware control at the required clock speed; and dual-pack LV resilience through simulated catastrophic HV failure.
The EVO architecture demonstrates that the concurrent development of full-stack embedded powertrain logic, Android OS integration, and high-speed peripheral drivers for DC Fast Charging is highly achievable using a virtualized pipeline — without bespoke hardware or proprietary simulation platforms.
By combining a dedicated 4S LV failsafe topology, a direct Linux user-space SPI driver for CCS communication, and production-intent RTOS firmware managing both traction and auxiliary packs, the platform reflects a flagship-tier EV architecture. The path from validated firmware to physical silicon — flashing the same BMS code onto a microcontroller and pairing it with a real PLC modem — is a direct next step that this architecture is explicitly designed to enable.
EVO vHIL represents a working implementation of the software-defined vehicle development future.