Today, let me share why I would model and simulate while designing a race car.

Bottom line: It can save you time, resources, and help you test your ideas that would be difficult to realize using hardware prototypes.

Modeling

Modeling is a way to create a virtual representation of a real-world system that includes software and hardware. If the software components of this model are driven by mathematical relationships, you can simulate this virtual representation under a wide range of conditions to see how it behaves.

Modeling and simulation are especially valuable for testing conditions that might be difficult to reproduce with hardware prototypes alone, especially in the early phase of the design process when hardware may not be available. Iterating between modeling and simulation can improve the quality of the system design early in the design process, thereby reducing the number of errors found at later stages.

Common representations for system models include block diagrams, schematics, and state charts. Using these representations, you can model, e.g. mechatronic systems, control software, signal processing algorithms and communications systems.

Simulation Software

Simulation software helps you predict the behavior of a system.  Engineers across automotive companies and student competitions use simulation software to:

• Evaluate new designs
• Diagnose problems with an existing design
• Test a system under conditions that are hard to reproduce, such as a system failure in a high velocity situation

To run a simulation, you need a model of your system. The model may be based purely on first principles, i.e. you know the underlying physics and are able to represent the system using equations. In contrast to that, you may not understand at all how the system behaves, i.e. it is a black box to you. Your actual examples will mostly be somewhere in-between.

Modeling types

The simulation software calculates the behavior of the model as conditions evolve over time or as events occur. Simulation software also includes visualization tools, to help monitor the simulation as it runs.

Find here two MATLAB Simulink Racing Lounge video links that focus on this topic plant modeling.

In summary, engineers and scientists generally use simulation because:

• Creating and simulating models is less expensive than building and testing hardware prototypes.
• Using simulation software allows them to test different designs before building one in hardware.
• Connecting simulation software with hardware allows for testing the integration of the full design.

Model-Based Design

A domain where student teams are heavily using simulation is for designing control systems, this approach is called Model-Based Design. Before diving into the core of Model-Based Design, let’s create the case for your race car development.

Let’s consider an electric powertrain. Hitting the accelerator pedal will send some signals to the motors and the car will start moving. You can imagine the controller as the object that converts the pedal position to the voltage applied to the motor(s). The plant is your car (model), which accelerates in reaction to spinning motors. This sounds pretty easy but let me ask you a few questions, and you will recognize the benefits of a structured development approach including modeling.

• How do you determine the optimal ratio between motor torque and the weight of your car?
• How do you make sure that the control algorithms you develop (perhaps in Simulink) behave the same way on the car’s engine control unit (ECU) as they did in your computer simulation?
• What is your strategy to minimize errors during each design step?
• How long does it take you during a test day to get your car back on track after adapting some controller settings?

Control system with feedback loop

Model-Based Design is a mathematical and visual approach for the development of complex control systems. It is the systematic use of models throughout the development process for design, analysis, simulation, automatic code generation, and verification. It is broadly used in motion control, industrial equipment, aerospace, and automotive applications.

Model-Based Design can be seen analogously to computer-aided design (CAD) , which allows mechanical designers to create virtual assemblies to understand whether product parts will work together before even being manufactured. Likewise, Model-Based Design lets embedded software developers create simulation models to understand whether algorithms will work before the embedded code is written. It also helps optimize overall system design.

Through virtual prototyping, system engineers can easily see whether the whole system (mechanical, electrical, hydraulic, and pneumatic, plus embedded software) will work as intended, even before the hardware is manufactured and available for testing. Embedded software developers can automatically generate embedded code from simulation models. This is similar, to how a CAD drawing is automatically translated to numeric control (NC) instructions for machining.

Development process V-diagram

One traditional way to show a system development process is the V-diagram. The process starts with the system requirements and specifications, in the upper left, then it moves down the left branch through the decomposition of the system into subsystems, which are designed first and then implemented at the bottom of the V.  Then moving up the right-hand side, there is a succession of integration and testing steps, first at the unit level, and finally in the car, called system-level testing.

In fact, many engineering organizations are moving integration-and-test activities from the right-hand side of the V to the left, doing more verification as part of the design process using models.

The V is a 2D view of a development process – the x-axis is time, while the y-axis is level of abstraction. As you move down the left-hand side of the V you add more and more details to the design with implementation at the vertex.  As you move up the right-hand side of the V, you consider higher and higher levels of integration and test with final working products at the end.

For the motor control problem, you start with a draft of your powertrain control concept (the requirements). This may happen even without using a computer, solely with pen and paper. Then, you may use a modeling tool, such as Simulink, for a first model of what you envisioned (the system and component design). At that level, everything is happening on your computer.

After making sure your model does the right thing, it is time to think about deploying, i.e. getting the algorithms running on your car. Commonly, ECUs are programmed using languages like C/C++ or HDL code. Software tools allow integration of your models with ECUs, either through a fully integrated approach or through generated code that you will can copy into an integrated development environment (IDE). Usually at the completion of this step you are only halfway through your development.

You may consider ‘climbing’ up the right-hand side branch of the V as bringing more and more of your algorithms to your car and synchronously testing them. At first, you will run the code on your ECU, your computer will act as car model (sub-system test). You will move gradually away from your computer and do hardware-in-the-loop testing (HIL), which means running your car model simulation on a powerful real-time machine. Finally, your controller running on the ECU will not communicate with your PC anymore, but it will actually make your car move. Note that the faster you are able to switch between the left- and right-hand branches of the V, the faster you can incorporate changes on the model to your car racing on track.

Watch our “Basics of Code Generation”-video, and read a user story from DUT (TU Delft racing team) for more information.

Conclusion

I’m interested in hearing your thoughts on this post. Is it applicable to you? Is there anything missing you would like to see? Any constructive feedback is welcome!