Hardware-in-the-Loop Testing for Embedded Protocol Stacks

Software-in-the-loop testing - executing embedded firmware on a host processor with simulated hardware - catches logic errors efficiently and integrates well into CI/CD pipelines. But SiL testing has a fundamental limitation: it cannot reproduce the timing behaviour, electrical characteristics, or hardware interactions of the real embedded system. A CAN protocol stack that handles messages correctly in SiL may exhibit timing violations when tested against a real CAN bus at 1 Mbps. A UDS implementation that responds correctly to simulated requests may fail when tested against an actual Vector VN1630A interface applying real ISO 15765-4 timing constraints. Hardware-in-the-loop testing bridges this gap by executing the actual firmware binary on the actual target hardware, in a controlled test environment that simulates the hardware's operating context.

HiL vs SiL: Complementary Testing Strategies

HiL vs SiL: Complementary Testing Strategies

A HiL test bench for embedded protocol stack validation consists of the ECU under test - the actual hardware with the firmware under test - connected through real physical interfaces to simulation and stimulus hardware. For CAN-based protocol stacks, a CAN interface adapter (Vector VN1630A, PEAK PCAN-USB, or Kvaser) connects the ECU's CAN bus to the test automation PC, allowing test scripts to inject CAN frames and capture ECU responses. For automotive Ethernet protocol stacks, an Ethernet switch connects the ECU's 100BASE-T1 port through an automotive PHY converter to the test PC's standard Ethernet port.

The test automation layer runs on the test PC, executing test scripts that send protocol stimuli and evaluate responses. Python with CANalyzer Python scripting, CAPL scripts in Vector CANoe, or custom test harnesses using SocketCAN and Python are common implementations. Test results are written to a database - typically a JUnit-compatible XML format for CI integration - allowing pass/fail status to be consumed by the CI pipeline alongside SiL test results.

Automated Test Scenarios for UDS and DoIP

Automated HiL test scenarios for UDS protocol stack validation should cover the complete ISO 14229 service matrix. Session transition tests verify that each session change request produces the correct positive response and that restricted services return NRC 0x7F in inappropriate sessions. Security access tests verify the complete seed-key challenge response sequence, test the delay timer behaviour after failed key attempts, and verify that secured services are inaccessible without prior security access. Flash programming tests execute the complete RequestDownload, TransferData, RequestTransferExit sequence with valid and invalid data, verifying correct completion and correct NRC responses to each error condition.

Timing tests are particularly important for HiL validation: P2 timeout tests verify the ECU responds within ISO 14229 limits, P2* tests verify correct NRC 0x78 handling, and TesterPresent timing tests verify that sessions time out correctly when TesterPresent messages are withheld.

Fault Injection and Robustness Testing

HiL testing enables fault injection scenarios that SiL testing cannot reproduce. CAN bus error injection - deliberately inducing bit errors, frame loss, and bus-off conditions - validates the CAN protocol stack's error recovery behaviour. Message truncation and malformed frame injection tests validate protocol stack input validation and rejection of non-conforming messages. Power cycling during active sessions tests session recovery behaviour. Network cable disconnection and reconnection tests TCP/IP stack reconnection handling for DoIP and SOME/IP stacks.

ISO 26262 Requirements for HiL Testing

ISO 26262 Part 6 requires software integration testing and software qualification testing using methods appropriate to the ASIL level. At ASIL B and above, hardware-software integration testing - which corresponds to HiL testing - is required to verify the interaction between software and hardware. HiL test cases must be systematically derived from software requirements, with traceability from requirements through test cases to test results documented as safety evidence. Automated HiL test execution with logged results and version-tracked test scripts provides the reproducible, traceable test evidence that ISO 26262 integration testing requires.

Validating RAPIDSEA Protocol Stacks with HiL

RAPIDSEA validates its UDS, DoIP, SOME/IP, CAN IVN, J1939, Modbus, and bootloader stacks against real hardware test benches using Vector CAN analysers (VN1610, VN1630A) and PEAK adapters - the same tools used in automotive OEM and Tier-1 supplier validation environments. This validation data is available to customers as evidence of pre-integration testing, reducing the HiL test scope required for customer-side validation. RAPIDSEA's MISRA-C compliant source code and modular architecture enable customer teams to add product-specific HiL tests on top of the protocol-level validation that RAPIDSEA's own test suite provides.

Conclusion

Hardware-in-the-loop testing provides the real-hardware timing validation and fault injection capability that SiL testing cannot deliver. For embedded protocol stack validation in automotive and industrial programmes, HiL testing is the bridge between host-based logic verification and the physical behaviour that actually matters in production. RAPIDSEA's pre-validated protocol stacks reduce the HiL test scope required at customer integration, while supporting the full range of HiL test scenarios that programme-specific validation plans require.

Ready to discuss protocol stack validation for your embedded programme?Contact our team to request an evaluation build or book a technical demo.