FW16 Hardware-in-The-Loop (HIL)

Owned by Adel Chinoy
Last updated: Dec 16, 2024 by Aryan Kashem
3 min read

Purpose

A Hardware-in-the-loop is a system that enables regression testing to run directly on hardware. Think of it as a blend of unit testing (for us, unit tests using the unity framework) and system tests (our smoke tests).

HIL tests are different than the aforementioned as they allow us to continuously test our entire system on hardware, getting us as close to automating hardware and integration tests as possible. For example, if a PR is made to update BMS code, we might want to add HIL tests to ensure that our cell reading logic is still functional. If a new task were to be created, HIL tests would mitigate memory and timing problems as we would be able to catch many of them when running these tests.

DAQ Selection

A DAQ must be appropriately selected to have the correct number of digital and analog I/O channels, communication interfaces, and processing capabilities. Consider the following criteria:

  1. I/O Requirements: Ensure the DAQ has sufficient digital and analog I/O channels to simulate all our peripherals

  2. Communication Interfaces: Support for relevant protocols (e.g., CAN, SPI, I2C, UART)

  3. Sampling Rate: Adequate sampling rate, for our purposes this will likely not be an issue

  4. Resolution: Appropriate bit depth for analog-to-digital and digital-to-analog conversion (try to get as good as possible)

  5. Software Compatibility: Compatibility with chosen test framework and development environment. Ideally we can spin this up with an existing Python library

Test Framework

A test framework such as Pytest needs to be selected and integrated into our build system. Consider the following:

  1. Ease of use

  2. Industry usage

  3. Solid documentation

  4. Easy integration with CI/CD pipelines.

  5. Support for custom plugins or extensions to meet specific testing needs.

Hardware Interface

Design hardware interface circuitry between the DAQ and the controller board. Much of these considerations are related to the DAQ selected.

  1. Ensure proper voltage levels, current limits, and impedance matching.

  2. Implement electrical isolation where necessary to protect both the DAQ and the controller board.

  3. If required, implement multiplexing to maximize the use of available DAQ channels.

  4. Optional: Include capabilities for introducing faults to test system robustness. This might look like a high impedance path where we’re supposed to be reading into our ADC, a relay to disconnect a sensor or other trace, holding an I2C line high while the CB tries to initiate a transaction, etc.

Real-Time Simulation

Develop a real-time simulation environment to emulate the behavior of the physical system.

  1. Model Development: Create models of all our system boards. How should we respond to each protocol transaction, how do all peripherals respond, what might change over time (e.g. maybe we can do a long term test of our BMS by having our pack slowly discharge over time through a software mock of the pack)

  2. Real-time requirements: How do ensure our tests are responding quickly and reliably enough that our HIL doesn’t end up being the culprit in test failures.

Test Case Development

Establish a methodology for developing comprehensive test cases:

  1. Requirements Traceability: Ensure test cases cover all system requirements.

  2. Edge Cases: Develop tests for boundary conditions and error scenarios.

  3. Performance Testing: Include tests for system performance, timing, and resource utilization.

  4. Regression Testing: Maintain a suite of tests to catch regressions in system behavior.

  5. Parameterization: Design parameterized tests to cover a range of operating conditions.

Data Logging and Analysis

Implement robust data logging and analysis capabilities:

  1. Choose appropriate storage solutions for test results.

  2. Create a system that allows us to easily spot where our tests are failing

Integration with Development Workflow

Lastly, we’ll need to integrate the HIL into the existing CI. This could look like triggering a HIL run and then posting to our GitHub to see a little check similar to how our build success/failure looks right now.