This article introduces the fifth chapter in the TSMaster Building Vehicle Controllers from Scratch HIL Real-Time Simulation series, which continues with the implementation of real-time HIL for controllers.
I. HIL hardware in the loop
ABS algorithm simulation and vehicle model operation, their function is not simply to draw curves and collect operation data, but has a deeper purpose, which is to link with the external world, exposing the input and output data completely in the real world, to achieve the real purpose of HIL - hardware in the loop.
The process of interacting with the outside world can be very simple, just design a dbc file specifically for this purpose, load it into TSMaster, and map the contents of the system variables to the bus.
Here I have prepared a simple dbc file which contains four wheel speeds, and four wheel cylinder pressure signals. Let's drag it into tsmaster.
Turn on the RBS again and let the remaining bus emulation take over the sending of these signals.
Then we opened the hardware channel selector and selected the CAN channel as a bus tool of the same star - TC1005 as a demo. Channel 1 and channel 2 of TC1005 were connected to each other to ensure that the outgoing messages could be answered correctly.
We start the RBS, open the Trace window, and we can see that the signals we need are being sent on the bus at a predetermined frequency, but of course these signals are initially at 0 because they are not updated, and the next step isDo signal binding to pass the values in the system variables to these signals.
First stop the simulation and go back to our algorithm applet and add pre-send functions that take over the process of sending wheel speed and pressure messages. This means that whenever a message is about to be sent, the system calls these pre-send functions and we simply update the signals we need within these functions.
We try to assign values. Finally, we add the CAN signals to be observed in the graph window, including velocity and pressure signals, etc.
At this point, we have completed all the required pre-sending functions for the signals and it is time to start the entire simulation process, again in the same way, by connecting to the TSMaster application and clicking on the start button of the automation module. You can see that the vehicle is running.
As the program runs, we can observe the active wheel speed and pressure signals on the bus in real time, and these signals are finally interacting with the real world.
II. Implementation of HIL simulation of vehicle controller
With the previous foundation, we can say that at this point we have really stepped into the door of HIL real-time simulation. Using this set of processes, we can realize HIL simulation of various vehicle controllers with no change.
As a simple example, if we need to perform HIL simulation of the developed ibooster, which is a real ECU, we need to import all the dbc files of the network of the ibooster and simulate all the signals needed for it with our RBS.
And to emulate the signal, the easiest way is to select the ibooster node we need on the RBS emulation interface, right-click and automatically generate the HIL configuration with one click, this step will automatically activate the other nodes and messages that the ibooster depends on.
Next, come to the applet and construct the various bus signals needed for this node by using the pre-send function.
Next are some hardware signals, such as encounter pedal signals, which can be implemented through the cylinder automation interface or a custom API.
Also, if IO or on/off signals are encountered, they are implemented through our IO and relay board APIs.
If special sensor signals such as wheel speed are encountered, this is achieved through our wheel speed simulation board API.
If the control of the supply voltage is encountered, it can be achieved by using a programmable power supply with an API.
Finally, we can open the automation module and write a series of use cases to test our product in every possible way.
Of course, there is an important prerequisite behind all this, and that is that everything outside the software must be prepared, i.e. the ECU mechanical and hydraulic loads must be prepared in advance.
As long as the above are in place, then unattended fully automated parameter traversal and testing can be designed and eventually executed, and at the end of the test, the test report can be automatically generated with a single click using pre-configured information.
The final implementation content is too detailed and implemented in different ways. We have reason to believe that based on this whole set of simulation architecture of TSMaster, the partners can also use their own ingenuity to design various kinds of HIL real-time simulation systems.