Hello guys, welcome to our blog. In this article, I will discuss writing test cases for HiL Testing and the steps to follow. I will also share some real-time scenarios.

Ask questions if you have any electrical, electronics, or computer science doubts. You can also catch me on Instagram – CS Electrical & Electronics

Guide On Writing Testcases For HiL Testing

Hardware-in-the-Loop (HiL) testing is a crucial part of validating automotive control systems, particularly in embedded systems, where real-time interaction between software and hardware is tested. The goal is to ensure that the system behaves as expected in real-world scenarios, minimizing the risk of failure in the final product. Writing effective test cases for HiL testing is essential for validating the hardware and software interfaces, ensuring the system meets both functional and non-functional requirements.

This guide will walk you through five examples of HiL test case scenarios, explaining the necessary techniques and considerations involved in writing them. The techniques discussed will include system integration testing, boundary condition testing, failure testing, regression testing, and performance testing.

01. System Integration Testing

a. Test ID: HIL_SIT_01

b. Message:

Throttle Input Signal Integration

c. Conditions:

Normal throttle position from 0% to 100%

d. Input Data:

Throttle position: 0%, 25%, 50%, 75%, 100%

e. Test Description:

Simulate different throttle position inputs and check if the ECU correctly adjusts the engine speed as per the throttle position.

f. Expected Output:

Engine speed should correspond linearly with the throttle input (0% throttle = 0 RPM, 100% throttle = max RPM).
The output should be stable and smooth.

g. Pass/Fail Criteria:

Pass: The engine speed increases linearly with the throttle input.
Fail: The engine speed does not correlate with the throttle position.

02. Boundary Condition Testing

a. Test ID: HIL_BCT_01

b. Message:

Temperature Sensor Overload

c. Conditions:

Temperature exceeds sensor’s maximum rated limit (e.g., 120°C)

d. Input Data:

Temperature: 100°C, 120°C, 130°C

e. Test Description:

Simulate temperatures just below, at, and above the sensor’s rated limits. Verify that the system triggers an appropriate failure message or enters a safety mode.

f. Expected Output:

The ECU should enter an error state if the temperature exceeds the rated maximum (120°C).
An error message or fault code should be triggered.
ECU should protect the system by limiting power or entering a safe mode.

g. Pass/Fail Criteria:

Pass: ECU reacts to the temperature exceedance and enters a safe mode.
Fail: ECU does not handle the temperature exceedance appropriately, or the system crashes.

03. Failure Testing

a. Test ID: HIL_FT_01

b. Message:

CAN Bus Communication Failure

c. Conditions:

Disconnect the CAN bus between the ECU and the wheel speed sensor

d. Input Data:

CAN Bus communication is disrupted.

e. Test Description:

Simulate a failure in the CAN bus communication and verify if the ECU handles the failure according to predefined protocols (e.g., fallbacks, error messages, or entering “limp mode”).

f. Expected Output:

ECU should detect the loss of communication and set a fault flag.
The system should enter a safety or limp mode, reducing performance without causing hazards.
An error message or fault code should be triggered.

g. Pass/Fail Criteria:

Pass: ECU responds to the CAN bus failure with error detection and a safe state.
Fail: The ECU crashes or enters an unsafe state.

04. Regression Testing

a. Test ID: HIL_RT_01

b. Message:

Braking System Software Update Validation

c. Conditions:

Software update on braking system without hardware changes

d. Input Data:

Brake pedal input: 10%, 50%, 100%
Vehicle speed: 20 km/h, 60 km/h, 100 km/h

e. Test Description:

After an update to the braking system software, test the response of the system to various brake pedal inputs and vehicle speeds.

f. Expected Output:

Braking behavior should remain consistent with pre-update performance.
The braking distance should be consistent with the specifications after the update.

g. Pass/Fail Criteria:

Pass: The braking system continues to perform as expected without regressions.
Fail: Any deviation in braking performance compared to the previous version.

05. Performance Testing

a. Test ID: HIL_PT_01

b. Message:

High-Frequency Input Handling

c. Conditions:

Simulate rapid vehicle speed changes (e.g., 0 to 100 km/h in 2 seconds)

d. Input Data:

Vehicle speed: rapidly changing between 0 km/h to 100 km/h, 100 km/h to 200 km/h

e. Test Description:

Test how the system handles high-frequency inputs, ensuring that the ECU processes these changes without delays or performance degradation.

f. Expected Output:

The ECU should process and respond to rapid changes in vehicle speed within the specified time limits (e.g., response time < 10 ms).
There should be no delay in control actions (e.g., throttle or brake response).

g. Pass/Fail Criteria:

Pass: The ECU responds to high-frequency changes within the required time frame.
Fail: The ECU exhibits delayed or incorrect responses under high-frequency input conditions.

Test Case Structure:

For each HiL test case, the following structure should be used:

Field	Description
Test ID	Unique identifier for the test case
Message	Brief description of the test case
Conditions	Environmental or system conditions (e.g., normal, failure mode)
Input Data	The input signals or data to be simulated (e.g., sensor values)
Test Description	A detailed description of the steps for performing the test
Expected Output	The expected system behavior for the given input and conditions
Pass/Fail Criteria	Criteria to determine if the test passes or fails

✅ Final Thoughts: Wrapping Up HiL Test Case Best Practices

Writing effective and reliable test cases for Hardware-in-the-Loop (HiL) systems is not just about simulating inputs—it’s about ensuring safety, consistency, and system integrity under a wide variety of real-world conditions.

Here are a few closing tips to keep in mind:

01. Be Requirement-Oriented: Each test case should trace back to a specific system requirement or specification. This helps maintain traceability and compliance, especially for safety-critical automotive systems.

02. Structure is Key: A well-structured format (like Test ID, Message, Input, Conditions, Expected Output, Pass/Fail Criteria) ensures your test cases are understandable by the whole team, from developers to safety engineers.

03. Think Beyond Normal: Don’t just test for normal operating conditions—include boundary conditions, fault conditions, and performance edge cases.

04. Automate When Possible: Automating HiL tests (with tools like dSPACE, NI, or Vector CANoe) improves repeatability and reduces human error.

05. Iterate and Improve: Test cases evolve as the system evolves. Revisit them regularly during regression cycles and software updates.

By following a disciplined approach to writing test cases and considering real-world scenarios, your HiL testing process becomes more robust, reliable, and aligned with industry safety standards like ISO 26262.

This was about “Guide On Writing Testcases For HiL Testing“. Thank you for reading.

Also, read:

About The Author

Chetan Shidling

Automotive | Technical Blogger | Engineer | Content Creator

See author's posts

Share Now