Updated: Jun 1
While working on another success story, I came across an essential technical term I’d like to introduce you to: restbus simulation. Hopefully, by the end of this blog post, you’ll see how it relates to the controller area network (CAN), and electronic control units (ECU). Why? Because these terms are essential in the automotive industry vocabulary. Restbus simulation is used to validate the functionality of an ECU by simulating parts of one or multiple in-vehicle buses. Vehicle-buses are specialized, in-vehicle communication networks, different interconnecting components inside the vehicle. To meet the unique requirements for vehicle control, such as having reliable message delivery, redundant routing, and other conditions typical to the automotive industry, appropriate communication protocols such as CAN or LIN (Local Interconnect Network) are implemented. Restbus simulation can then validate the functionality of the ECU. What this means is that the ECU needs to be able to make split-second decisions based on correct information it receives from vehicle bus nodes such as sensors, actuators, and other ECUs.
Different buses of your car in one picture: headlamps, turn signals, fog lamps etc.
Why Restbus Simulation?
This question is actually a little misleading, because the real question here should be: Why do engineers want to simulate vehicle buses? That’s because cars today have a great deal of ECUs interacting and interdepending on each other to operate as needed. Another challenge for developers is to take all the general conditions into account and to make the restbus simulation as realistic as possible. By performing restbus simulation, engineers can reduce testing time and costs because they can simulate real-world conditions from one or multiple vehicle buses to see how an ECU responds to it without having to build the entire vehicle network.
When performing restbus simulation, engineers apply different techniques such as switching between real and simulated ECUs (which normally is not a great technical challenge since most ECUs communicate on the same network), interacting with simulation models (check out this post for more on model-based design), scripting custom network communication (this is if engineers want parts of the system to perform a very specific task), logging data correctly, and making sure the communication of the entire system works (meaning correct transmission, triggering conditions and having the different networks report correctly to one another).
I hope you enjoyed this blog post! For more on ECUs, automotive communication protocols and automotive success stories I have covered in the past, check out the following blog posts and links: