In model-based design (MBD) approach, model remains the primary artifact around which revolves the entire development process. Refining the model is a continuing quest for a developer till it’s ready to generate the desired code.

MBD holds a special place in the application software development ecosystem, automotive industry being one of them. Automotive applications such as motor control system and automotive lighting are quite complicated and require millions of lines of code. By creating models of the solution, the developers can simulate the entire system, test it, and automatically generate the code from the models.

Easier said than done, modelling and simulation require advanced tools with built-in mathematical blocks and libraries and, above all, the expertise to handle these tools.

In this blog, we will talk about two of these implementations that are most widely used by automotive engineers: Stateflow and Simulink**.**

While both are capable of modelling and simulating a control algorithm on their own, using each of them for certain tasks brings the best out of these tools. There are no hard and fast rules as to which tool to pick for a given scenario. Engineers take the pick based on their understanding of the system. However, there are certain considerations that might help them choose the best-suited tool to solve a particular problem statement.

**Stateflow: Logical flows simplified**

Stateflow is a modelling tool from Mathworks that’s built to model a reactive system where logic holds the key to action. Imagine a human machine interface (HMI) like an infotainment system wherein, if a user clicks a button, a particular screen must appear. It’s a dynamic setup that is constantly monitoring the system to capture a user action. Stateflow can be used to define how an algorithm would respond to events and input signals.

To better understand the role of Stateflow, we must first understand state machine.

State machine is a mathematical representation or abstraction that takes input and changes to a different state. Every possible state of a system, when grouped in a model, makes a state machine. An infotainment system can be seen as a state machine where different screens are the states that transition from one to another. The behavior of such as a system can be specified in the form of a graphical notation called statechart.

**Figure 1** Infotainment system is a state machine where different screens are the states that transition from one to another.

When it comes to modelling such stateful systems, Stateflow is the way to go. There are truth tables, state transition tables and flow charts to help the engineers model a system such as an infotainment system. Generally speaking, for systems that have switch cases and nested if-else statements, and are driven by logic, Stateflow is the way to go. Stateflow’s state charts are easy to read and maintain. Even Mathworks Automotive Advisory Board (MAAB) advises to use Stateflow when modelling stateful systems.

**Simulink: Mathematical formulae simplified**

For dynamic systems, where constant monitoring of various vehicle parameters is required to trigger a controller-based action, Simulink comes across as a natural fit. Closed loop control algorithm with proportional integral derivative (PID) tuning is a perfect example.

Let’s understand this with the example of field-oriented control (FOC) algorithm implementation for a motor control system. The FOC algorithm requires the current from the motor stator to be converted to flux and torque. This is done by implementing Clarke’s transform formula. Furthermore, the stationary reference frame needs to be converted to rotating frame which involves Park transform, another complicated formula. Simulink is designed in a way to implement such calculation-intensive algorithms. It has pre-built mathematical blocks that can be added to the model to make things simpler.

Another example is of the airbag system. The airbag module fires the airbags only when there is a sudden drop in acceleration, something that will be triggered only when the vehicle hits an obstacle. For successful opening of the airbags, the system constantly monitors the engine parameters using sensors. The data received from the sensors is used to calculate the deceleration. This calculation happens dynamically whenever the vehicle is in motion. When it comes to such applications where complex mathematical calculations are involved, Simulink is usually preferred. The same system can also be modelled using Stateflow, but there will be increased effort and the model would get complicated.

**Figure 2** The Simulink library comprises mathematical blocks like BLDC control and mathematical transforms.

The above diagram shows the Simulink library that comprises mathematical blocks such as mathematical transforms, PMSM control, BLDC control, and so on. Using these pre-built blocks from the library reduces the modelling effort to a large extent.

Similar to FOC algorithms and airbag systems, there are various vehicle systems where the engineers have to choose between Simulink and Stateflow. In several instances, both are used for their respective benefits. So, you would see a Simulink block executing some calculation inside a Stateflow model and vice versa.

**Which one to choose?**

Simulink and Stateflow are designed for different things, although they can be used interchangeably. However, if you use Simulink to create switching logic, you will get a cumbersome model that is difficult to read and even tougher to maintain. Similarly, if you attempt to create calculation blocks using statecharts, all you get is a complicated model. And this situation can be easily avoided by using Simulink.

*Manu Kumar, a senior software engineer at Embitel, focuses on model-based design paradigm.*

*Vaibhav Anand is a digital-marketing professional with a deep-rooted interest in everything automotive.*

**Related Content**