Build MBD simulation model and state machine

1 The difference between model simulation and actual application

MBD (Model-Based Design) generates code through models, so it is necessary for us to understand the difference between model simulation and actual application.

The difference between simulation models and actual applications is essentially the difference between theory and practice, which can be said to be two completely different topics.

Here are three more articles related to motor control practice. They are motor control application notes written by NXP engineers and can be found on the NXP official website, or you can reply to the keyword "NXP application notes" in the dialog box to receive the corresponding resources.

The three application notes are:

• 3-Phase Sensorless PMSM Motor Control Kit with S32K144

• 3-Phase Sensorless BLDC Motor Control Kit with S32K144

• 3-phase Sensorless Single-Shunt Current-Sensing PMSM Motor Control Kit with MagniV MC9S12ZVM

*NXP Motor Control Application Notes* - From autoMBD

The first two articles focus on PMSM and BLDC respectively, introducing how to implement sensorless FOC control; the third article talks about the single resistor sensorless control solution, which also implements the FOC algorithm. There are some differences in software implementation, and it is also more complicated.

Tips: The third article is based on MagniV MC9S12ZVM, not S32K144. When referring to this article, the main thing to learn is the single-resistor motor control solution, which can also be fully ported to the S32K1xx series.

Sensorless control is more complicated than sensory control. A sensory control solution can be made by slightly modifying the sensorless solution, so these three application notes are very valuable for practical reference.

These three application notes all provide pure code development solutions, that is, they introduce how to implement motor control step by step from mathematical principles in engineering practice. The main contents include:

1. Mathematical Principles of Motor Control

2. Current, voltage sampling input and drive output

3. Usage of MCU module resources

4. Low-level driver configuration and initialization

5. Motor control software architecture (state machine, motor control library, MCAT, etc.)

The following block diagram can fully demonstrate the actual embodiment of points 1 to 4 in motor control: the system starts from external hardware (motor, inverter, pre-driver chip), goes through signal acquisition, then to the peripheral module of MCU (white square), then to the underlying driver (SDK Driver/orange square), and then enters the software algorithm part of FOC (green square), and the output of FOC is output to the pre-driver chip through the underlying driver and then to the peripheral module (FTM module), thereby realizing control. Point 5 is the state machine that schedules the above process, and point 5 will be explained in more detail later.

*NXP Motor Control Hardware and Software Block Diagram* - From NXP

From these five points we can lead to the question we want to discuss: What are the differences between model simulation and actual application?

Simply put, model simulation can only touch upon the first point mentioned above; if you have a deeper study on modeling, you can also simulate the second point. This part is actually related to hardware circuit design, so this point is rarely considered in model simulation; points 3, 4, and 5 are completely non-theoretical and have a strong connection with embedded systems, programming, and chips. They are real practical processes.

Therefore, points 2 to 5 are completely not included in Yuan Lei’s “Modern Permanent Magnet Synchronous Motor Control Principles and MATLAB Simulation”.

Taking the current sampling resistor as an example, in actual application scenarios, in order to measure the direction of the current signal, the sampling resistor is generally biased. Taking the DEVKIT driver board phase current sampling resistor developed by NXP as an example, its circuit design is shown in the figure below:

*DEVKIT driver board phase current sampling resistor* - From NXP

It can be seen that the bias voltage is half of the reference voltage, so the voltage finally input to the chip ADC is symmetrical around the bias voltage.

Depending on whether the current is greater than or less than the bias voltage, we can determine whether the current is in the positive or negative direction. Therefore, the bias voltage needs to be subtracted in signal processing.

Regarding current sampling, there are also different layout methods. Common sampling resistor layout methods are as follows:

• Three-resistance lower bridge arm sampling/phase current sampling

• Dual resistor lower arm sampling/phase current sampling

• Single resistor bus sampling

Tips: Common sampling resistor arrangements are listed here. In general applications, the lower bridge arm is sampled more frequently, and phase current sampling is mostly used in high-performance, high-efficiency motor control situations. Single-resistor bus sampling is the lowest cost, but the most complex sampling method.

Different arrangements will collect different currents, but the control algorithm requires all three-phase currents. Three sampling resistors can directly obtain three-phase current signals, and there are methods to obtain three-phase current data through one or two resistors.

The dual resistor is relatively simple. The third phase current can be directly solved according to the three-phase current sum is zero. The single resistor sampling scenario is much more complicated. For details, please refer to the third application note mentioned above.

All the above methods of current sampling are not considered in the model simulation. Only a signal line is connected to the controller. This is the huge difference between theoretical simulation and practice, as shown in the following figure (excerpted from Yuan Lei's "Modern Yong......Simulation"):

*Simulation Model Example* - From Yuan Lei

Tips: Because we are going to use the MBD development method, we will not go into detail about other differences here. We will provide tips where necessary in the future. Interested readers can refer to the above three NXP application notes.

When we understand the difference between all theory and practice, supplemented by the basics of embedded development and programming, a simple motor control project can be realized.

Even a product-level motor control software only supplements the functions required by other requirements such as communication, fault diagnosis, functional safety, etc. The complexity may be much higher, but the essential framework of development and design is like this.

2 MBD closes the gap between model simulation and actual application

To be more precise, the above discussion is only about the engineering practice of the motor control algorithm. A complete product application includes hardware design and software design. Hardware design can be handed over to hardware engineers, and we will focus on software design.

The motor control implementation solutions mentioned in the above three application notes are part of software design. In traditional development, the selected motor control solution needs to be converted into lines of code, which involves the conversion between mathematics (theory) and programming language (practice). The entry threshold is high and the efficiency is low.

Tips: Taking my own experience as an example, I went through the code implementation process of the above application notes. It took me three months to learn the basic modules and development methods of embedded systems and then to be able to write some basic embedded codes. It took me almost another month to implement a simple motor control embedded program. This is the development efficiency after I have a sufficient foundation in motor control theory.

But by using the MBD development method, we can greatly simplify this step. It is relatively easy for us to obtain the model, and using the model to directly generate code can effectively shorten the distance between theory and practice. For more MBD-related content, please refer to the previous issues of this public account, or reply to the keyword "MBD Introduction" in the dialog box.

*MBD development process* - From ST

If you read the above three application notes, you will find that many embedded software designs can be implemented through modeling. Here we simply divide software design into five categories, and its software and hardware levels are shown in the following figure (the software is the dotted box part):

*Example of motor hardware and software hierarchy* - From autoMBD

The following is an analysis of the five types of software for MBD modeling implementation:

• The underlying driver is strongly related to MCU and hardware circuits

The underlying driver is closely related to the chip and hardware circuit design. For example, if the hardware pins (pins, peripherals, ports, etc.) are used differently, the configuration of the underlying driver will also be different.

In principle, the underlying driver can be implemented through the MBD hardware support package provided by the chip manufacturer. However, from the perspective of flexibility and efficiency, it is currently recommended to configure the underlying driver through a dedicated underlying driver configuration tool, such as NXP's configuration tool Processor Expert for the S32K1 series.

• Digital signal processing, weak correlation with hardware circuits

Digital Signal Processing (DSP) is the process of converting physical quantities in the real world (analog quantities, such as current, voltage, etc.) into quantities required by the controller.

Taking current sampling as an example, based on the current sampling circuit given in the previous article, the voltage read by the ADC is actually a 12-bit integer, which needs to be subjected to operations such as offset elimination and physical quantity conversion, and filtering if necessary.