Hardware in the Loop Test for Motor Control Software
Motor Control Software Development Simplified
The miniHIL bridges the gap between model or software-in-the-loop testing and lab setup with real hardware when testing motor control software. It enables reliable testing of motor control software in interaction with driver software and microcontroller peripherals.
Regardless of the type of motor, the type of control selected, and the way in which motor control software is developed, it makes sense to integrate regular tests into the development process.
This is how a test normally works:
As a rule, development of the controller software begins before the associated hardware is available. During this first phase, only software or model-in-the-loop tests can be performed.
However, the integration of the motor control software with low-level drivers and the periphery of the controller cannot be tested or only insufficiently tested during pure software-in-the-loop tests. The integration is therefore often only tested when the real hardware is available.
Integration tests for motor control software are often complex because both the motor and the associated power electronics have to be set up. Depending on the area of application, additional hardware is required to obtain a realistic test setup. If fault cases are to be able to be reproduced in the test setup, the effort increases further.
Due to the effort and the associated costs, integration tests for motor control software are often used late in the development process. Often days or weeks pass before software changes can be tested on the test bench.
Testing Motor Control Software with miniHIL
How to run a test with miniHIL
One goal of the miniHIL is to test the integration of the controller and the function of the overall system without relying on the target hardware. In a test setup with the miniHIL, the software under test is executed on an evaluation board or a special adapter board. The controller that is also used in the final product works on this board. We call this board with the software under test Device under Test (DUT). The miniHIL environment offers the possibility to simulate the motor and, for sensor-based controls, the associated sensors in real time. The signals provided by the controller (usually PWMs) are measured at logic level, a simulation model is calculated, and the signals required by the controller are generated (analog and digital). All information exchange between the test environment and the DUT thus takes place via the hardware interfaces of the controller, which are also used in the final product.
To support the development and testing of motor control software, the miniHIL offers special features
- Simulation of the motor to be controlled and all associated sensors ⇒Integration of existing models (Matlab, Simulink, …) for which C code can be generated.
- Provision of the signals required by the controller at logic level.
- Simulation of the environment of the controller (residual bus simulation)
- Execution of integration tests directly at the developer workstation
- BLDC and DC motor control
- Universal motor control
- Sensorless motor control: Single Shunt / Dual Shunt
- Motor control with sensors: HALL / Angle sensors
How does the system behave in the event of a fault?
If a real engine is used for the test, it is only possible to test error cases with great effort. In the best case, reproducibility of the error is difficult. In the worst case, hardware must be deliberately manipulated or damaged to trigger a specific fault response.
By simulating the controlled system when using the MiniHIL and not having to use a real motor, many fault cases can be easily tested. In addition, the test case has access to the state of the complete simulation environment. With this knowledge, it is possible to check in real time whether fault detection and mitigation mechanisms in the DUT are working reliably. For example, a common question is whether an error is detected after a certain period of time and logged on a different communication bus.
Another advantage of simulation is that faults can be specifically triggered in different operating states of the controller. It is also possible to superimpose several error states.
Typical scenarios for fault injection are:
- Errors in the motor hardware: Overcurrent, load increase, load decrease, short circuits, failure of sensors, voltage drops, …
- Errors on a communication bus, failure of communication partners, …
Residual bus simulation
In addition to motor simulation, the miniHIL can also be used to simulate bus systems such as CAN, XCP, LIN, Uart, I2C. This makes it possible to test other functions of the ECU in parallel to the test of the motor control software.
Although many other functions in the ECUs do not directly affect the engine control system, it still makes sense to test the complete system in order to find errors at an early stage that only occur in the interaction of the components.
Motor types and controls
Commonly used motor and control types that can be tested with the miniHIL include:
- BLDC motors with field-oriented control.
- Dual Shunt
- Single Shunt
- BLDC motors with block commutated control
- Hall sensors
- Angle sensors
- Other DC motors with
- Hall sensors
- Angle sensors (e.g. for servo drives)
- Universal motors (Triac control) with
- Hall sensors
Test automation and traceability
The miniHIL tool chain provides all the features you need to run tests in a fully automated way (more…).
For example, it is easy to use the miniHIL together with your Continuous Integration solution. All changes to the software are thus tested directly in the overall system. Bugs can be found and fixed faster this way (more…).
If you need feature or requirements traceability, the miniHIL offers you several options:
- Our own traceability solution (HTML, XML reports).
- Integration with YAKINDU Traceability
- Ask us for integration with your traceability tool