Model-Based Design Simplifies Embedded Motor Control System Development

    Author: Dara O'Sullivan, Jens Sorensen, Aengus Murray, Analog Devices

 

    This article describes the details of a Model-Based Design (MBD) platform built around an ARM®-based embedded motor control processor. It then provides an example of an initially deployed basic permanent magnet synchronous motor (PMSM) control algorithm and describes a convenient functional extension to include multi-axis position control for an automation system.
 

    System and circuit modeling has long been an important aspect of motor control system design. With the MBD approach, electrical, mechanical, and system-level models are used to evaluate design concepts before building and testing physical hardware. MathWorks' latest simulation tools can model complete embedded control systems, including electrical circuits and mechanical systems. At the same time, embedded coding tools generate C language code from the control system model to deploy the control algorithm on the embedded control platform.
 

    These tools enable a model-based design process where one can design and fully test on a simulation platform before final hardware testing. The key to building a successful MBD platform is to separate the system model and the embedded software code. Once the MBD platform has been tested with known algorithms and systems, new algorithms can be developed and safely tested on the simulation platform at the system operating limits.

 

Complete design process
 

    MBD has been discussed for decades, but has only recently developed into a complete design process from model creation to full implementation. MBD is a mathematical and visual approach to solving problems associated with designing complex embedded control systems.
 

    Instead of using complex structures and large amounts of software code, designers can use MBD to define various models with advanced functional characteristics through continuous-time and discrete-time building blocks. These models, used together with simulation tools, can shorten the time for prototyping, software testing, and hardware-in-the-loop (HIL) simulation.
 

    Through simulation, we can immediately discover any specification discrepancies and model errors, rather than waiting until later in the design cycle. To optimize the overall code generation process, automatic code generation can be added to reduce any manual deployment steps and further help reduce the overall time to market. In summary, the MBD approach allows designers to start with more classical design solutions and expand directly from model creation to simulation, code generation, and HIL testing in a controlled manner, making incremental changes to the system behavior without redesigning the entire system.
 

    The experimental setup in this article is based on an AC-fed closed-loop motor control system, as shown in Figure 1. The system represents a fully functional PMSM mains input motor drive with power factor correction, full control, communication signal isolation, and optical encoder feedback. The core of the system is an ARM Cortex®-M4 mixed-signal control processor, namely ADI's ADSP-CM408. It is paired with tools from IAR and MathWorks to achieve a complete MBD platform deployment. 

   

 

AC Motor Drive System Modeling
 

    The target drive system is a PMSM with encoder position feedback connected to a three-phase AC power inverter with isolated phase current feedback. The drive control algorithm is deployed on a mixed-signal application-specific signal processor (ASSP) containing peripherals to capture the motor feedback signals and control the power inverter. 
 

    

    Figure 1. Drive system platform (a) AC-fed closed-loop motor control system block diagram (b) System prototype production

 

    There are three main components of the system that can be modeled: the power inverter and motor (plant), the control feedback circuit, and the digital controller. The plant model uses Simulink Simscape components to simulate the power inverter electrical circuit and motor electromechanical elements in the continuous-time domain. The feedback circuit model handles the gains and data types between the controller and the motor drive model.
 

    The C code created by the Simulink Embedded Coder tool accurately reflects the execution of the algorithm on the simulation platform and the embedded control processor. The successful implementation of Model-Based Design relies on accurate system and circuit models, as well as the proper separation of the system model and the embedded control software. Because the system contains a mixture of discrete and continuous time functions, the simulation solver uses a fixed-step discrete solver.
 

    The drive system hardware includes a power board, a control board, and a PMSM with encoder feedback (see Figure 1b). The power board contains the input rectifier, three-phase inverter module, current and voltage sensors, digital and analog signal isolation circuits, and encoder signal buffers. The control board contains the motor control ASSP (with an integrated 240 MHz ARM Cortex-M4F core) and dedicated motor control peripherals (including PWM timers, quadrature encoder counters, Sinc filters, and embedded analog-to-digital converters (ADCs)). The hardware includes motor current feedback options using isolated current sensors (with integrated embedded ADCs) or shunts (with integrated isolated ADC Σ-∆ converters), as well as embedded Sinc filters.
 

    Feedback signal acquisition and control algorithm execution are synchronized with the PWM switching frequency through the processor interrupt mechanism. Since the time constants of interest in the plant are much longer than the PWM switching period, the system simulation uses the same time step. Since full switching signal simulation cannot provide useful control information, the power inverter uses an average value model.
 

    The PMSM motor model is derived from the MathWorks SimPower Systems library and is supported by a configuration menu (even preset model parameters). Users can switch between custom motor or inverter models, depending on the requirements of the design development.
 

    The motor control (MC) algorithm model is a set of discrete time functions that are executed at each time step on the simulation and embedded platforms. Typically, the MC algorithm functions are contained in a single subsystem module to simplify the code generation process. The code generator creates C language code to implement the control algorithm and data structures for the algorithm input, output, and state variables. The algorithm itself is a common field-oriented control (FOC) with an outer speed loop and inner d-axis and q-axis current loops, as shown in Figure 2.
 

    The inverter interface and feedback path are divided into sensor signal conditioning and embedded interface blocks. The current sensor and signal conditioning models are simple gain elements because their bandwidth is beyond the range of interest for control feedback. The position sensor model is more complex because it provides a high-resolution incremental position signal and a low-resolution absolute position signal.
 

    Embedded signal interface models include type conversion functions because ADC, Sinc filter, counter, and timer peripherals have 16-bit or 32-bit fixed-point output data registers. The gain of each embedded interface is a function of the peripheral system clock rate, sampling rate, and interface peripheral register settings. Model parameters must match the embedded system configuration to ensure accurate simulation results.

 

Software Partitioning and Code Generation
 

    The motor drive system performs multiple functions and motor control algorithms. The embedded software is divided into multiple functional modules to achieve platform flexibility and facilitate development. The key code functions are system initialization, communication interface, application tasks, motor control interface, and motor control algorithm. Figure 3 shows the high-level driver flow chart and Figure 4 shows the code structure.
 

    The main program calls the initialization routine to configure the ASSP hardware and then puts the processor into a continuous wait loop. All other functions are called by the event-driven interrupt service routine (ISR). The ADC interrupt has the highest priority, and the ADC ISR calls the motor control function when a new sensor data sample is ready. The

    ADC sampling is synchronized with the PWM switching to provide execution timing for the control loop. The ADC ISR executes once every PWM cycle, but the motor control routine (PMSMctrl) is called only when the motor run flag is set. The motor current feedback path is selected before the code is built. 
 

    The PWM trigger interrupt is asynchronous; it is called only in response to a hardware fault and is the only function that delays a fault because the hardware PWM trigger function automatically shuts down the inverter PWM signals. The communication port ISR has a lower priority and processes user commands and sends data captured by the debug monitor function. The core timer ISR manages background application tasks such as motor start and stop sequences, debug monitor interface, and other housekeeping tasks. 

   

 

Figure 2. FOC algorithm

 

2 | Model-Based Design Simplifies Embedded Motor Control System Development

 

Figure 3. ISR description

 

Figure 4. Code separation
 

    The embedded code is organized by functionality rather than programming order. System initialization code sets up the processor clock, power, and core timers in a standard manner with little to no relevance to application functions. Communication and application task code is defined by user interface and system management requirements with little to no relevance to the motor control algorithm. 
 

    The motor control (MC) interface functions manage the signal data flow between the motor drive hardware and the control algorithm. This code is dedicated to controlling the drive circuitry and the motor control related peripherals that provide feedback signals to the control algorithm. The motor control algorithm is a platform-independent code generated by Simulink that contains data structures for feedback and output signals. All other drive code is hand-coded.

 

 

    To maximize the benefits of MBD, it is important to understand the modeling detail requirements of different parts of the motor control system and match the key physical system parameters with the corresponding model parameters as closely as possible. This includes separating the modeled system into different detailed parts. In general, it is sufficient to model the entire system in a PWM average value manner. For example, all signals are treated as average values ​​during the high-frequency PWM switching cycle, and no PWM ripple or switching components are included in the voltage or current signals. 
 

    The system model is divided into logical blocks as shown in Figure 5 (with the associated signal flows). Each block is further subdivided (as shown on the right side of the figure), and each sub-block is modeled using an appropriate approach as listed in Table 1. User command blocks are not listed in the table. User commands are communicated to the core algorithm through global parameter structures inside the C code; once they are defined as global tunable parameters in the Simulink algorithm, they are properly processed.

 

Figure 5. System model partitioning

    *The numbers in brackets correspond to the block diagram in Figure 5.
 

    By making the automatic code generation non-target specific, beyond basic settings (e.g., type size, byte order, etc.), code portability and ease of maintenance are maximized. MathWorks provides processor-specific code generation modules that directly address processor peripherals and drivers. While this capability is attractive in some cases, its drawback is that the code is not portable enough, and any changes to the device driver or peripheral configuration (e.g., a new processor variant) will require code changes. Therefore, in the design example described in this article, code generation is limited to the control algorithm, while the Simulink model contains all peripheral function models and is hand-coded in the application project. This approach is highlighted in Figure 6, where the code generated by the MathWorks controller model is connected to other code and library modules in the main application project.

 

Figure 6. Model code interface
 

    The Simulink model with the separated model blocks is shown in Figure 7. As shown in the figure, the code is generated from the motor control algorithm part of the model. The important settings for code generation can be selected in the Configure Code → Hardware Deployment window, where the overall device type can be selected, and in the Configure Parameters → Code Generation → Interface window, where the standard math library can be selected.
 

    Another factor that affects code efficiency is the C dialect used. Common dialects supported by most code generation tools and embedded workbenches are C89/C90 and C99. It is important that the same dialect is used in the tools. For example, if the embedded workbench is configured to build code according to C99, the automatic code generation tool must also build code according to the C99 standard. If this is not done, the code performance will be greatly reduced, and in the worst case, the code may behave unexpectedly.
 

    Another important factor is the fixed-point and floating-point type representation. Fixed-point is supported in both encoding dialects, so the choice of dialect in this case is not important as long as the same dialect is used in all tools. However, if floating-point types are used, the choice of C dialect becomes important.

C89/C90 do not distinguish between single and double precision floating point. This may be acceptable if the code is to be run on a processor that supports double precision, but for processors that only support single precision (such as the ARM Cortex-M4), the situation is very different. Remember to ensure that automatic code generation tools and embedded workbenches are set up to use the C99 "dialect".
 

    Simulink provides toolboxes such as Simscape and SimMechanics that can be used to easily model electromechanical systems when the physical parameters are known. Even if the physical parameters are not fully characterized, predefined component models (such as motors) can be loaded with roughly equivalent specifications to enable preliminary design of motor control algorithms. In terms of the algorithm itself, some blocks are useful, such as Park transform and sine-cosine CORDIC approximation blocks, which can simplify the development of motor control algorithms.
 

    The auto-code interface is defined by an initialization function call and one or more time-step function calls that must be called from within the main application code at the appropriate time step. In this example, there are two time-step functions—the main control algorithm, called at a 10 kHz PWM rate, and the speed measurement function, called at a 1 kHz rate. The auto-generated code module is integrated into the main project, as shown in Figure 8.

 

Figure 7. Modeling and code generation deployment

 

Figure 8. Code module organization and algorithm function calls
 

    As shown, the code is organized in a modular fashion, and the integration of application-specific functions, such as networking and protection, is very intuitive. High-priority tasks, such as motor control algorithms, are called from the ISR in Figure 3. Application-level tasks are called from the basic scheduler core as scheduled tasks. The MC interface routines are included in the motor control and measurement code modules, which contain all current feedback signal processing code. The ADI motor code includes a debug monitor function for system testing, which can capture application and control algorithm signal data while the motor is running. The data is transferred to the PC via a serial link for display and analysis.

 

System testing and debugging
 

    Once the key parameters in Table 1 have been determined by measurement, calculation, and data sheet review, the correct controller gains for the speed and current loops can be determined using the Simulink model. This can be accomplished using standard PID tuning techniques [2] or tuning tools such as the PID Tuner tool provided by MathWorks. This process is described in detail in Reference 3. 
 

    The current loop performance for modeled and experimental operation is shown in Figure 9 and Figure 10. The experimental data in this plot is sampled only every 5 ms, so there is some aliasing, but the overall trend is very clear.
 

    The performance of the model-based auto-generated code can be determined by examining the timing of the code execution during the PWM cycle. This can be done using I/O pins and an oscilloscope, or more simply using the ITM event feature in the IAR Embedded Workbench C-SPY debugger. The sequence of events during a PWM cycle is shown in the timeline in Figure 11.
 

    The PWM synchronization pulse occurs at the beginning of each new PWM cycle and is connected in hardware to the ADC timer to control the sampling of each ADC channel. In this case, the motor current is sampled immediately after the PWM synchronization pulse and directly accessed (DMA) to memory, and then the algorithm is executed and the PWM duty cycle update value is generated. As shown in Figure 11, the execution of the model-based auto-generated code consumes less than 10% of the PWM cycle, allowing for a large amount of other background task overhead. Previous concerns about the efficiency of auto-generated code no longer exist.

 

Figure 9. Comparison of model operation and empirical operation for (a) speed response and (b) q-axis current reference

 

Figure 10. Current loop performance—model and empirical results.

 

Figure 11. Code execution time limit
 

    In terms of code size, the relative size of the algorithm auto-code is shown in Table 2; it can be seen that the auto-generated code occupies only slightly more than 10 kb of memory, which is about 15% of the total size. The ADSP-CM408 has 384 kB of available SRAM, which can easily support this memory requirement, allowing the program to run from SRAM at the highest rate and providing more than enough margin for more complex algorithms and other monitoring or user interface functions. 


 

New application development

 

    The software discussed in this article assumes a system with two main components. The first is a model-based component that implements the control algorithm. Although the model is developed with the embedded target in mind, the code obtained from the automatic generation tool is generic in nature. The second is a handwritten software component that binds the generic algorithm code to the embedded target, handles scheduling, and allocates processor resources. This system separation has certain advantages in terms of model reuse and scalability.
 

    This article discussed control development for a single motor (single axis). Now, imagine that the driver specification calls for control of two motors (dual axis) through the same processor. This is undoubtedly a big change to the system, but the advantages of working with a generic model are also highlighted. The single-axis model that has been developed does not make any assumptions about the processor peripherals - it is a generic control algorithm for PM motors. Therefore, creating a model that can control a single/dual axis becomes a matter of creating a second instance of the single-axis model.
 

    Naturally, the handwritten code needs to be modified to support single/dual axes, but assuming the processor has the right set of peripherals and compute resources to control dual axes, the modification of the handwritten code is also straightforward. Whether controlling a single or dual axis, the main tasks of the handwritten code are to assign values ​​to the model's inputs, write the model's outputs to the processor peripherals, and schedule the model's execution time. Therefore, going from a single axis to a dual axis is just a matter of assigning/configuring the peripherals and scheduling the algorithm execution time for the added axis. The process is seamless and is made possible by the fact that the model is generic.
 

    If you are developing only a single control system, then there is limited benefit to using Model-Based Design. However, in most cases, product development means multiple product variants, and for these cases, reusing models is very attractive—not only because of the reduced development time, but also because of the increased quality that comes from using trusted models. Over time, algorithm developers will create a library of models; if deployed correctly, these models can be reused across different products. Because the models are generic, they can run on current and future processors.
 

    In addition to meeting potential requirements for product variants or controlling multiple axes, developers can sometimes offer different controller modes. A typical example is an application that offers torque control, speed control, and position control modes. A position control algorithm can be deployed on the basic building blocks of current and speed control algorithms.
 

    In most applications, the position control loop is implemented as an outer layer around the inner velocity and current loops. A basic position controller requires only a proportional gain term. An integral term is generally not required because any steady-state error in the position loop will result in a non-zero velocity reference. If the inner current and velocity loops are well tuned, these can be treated as ideal unity-gain blocks, and tuning the position loop becomes a straightforward task.
 

    In addition to the outer proportional control loop, it may be important to include a position reference so that the load follows a defined period and acceleration and deceleration rates. This is important to minimize mechanical stress in many systems. In this application example, a constant acceleration, constant velocity, and constant deceleration profile is applied to the position reference variation as shown in Figure 12; the figure shows the position reference, the curved position reference, and the corresponding ideal velocity profile. As to which actual velocity follows this curve depends on the dynamic response of the velocity controller.

 

Figure 12. Position reference curve
 

    All these functions - position loop gain, position profile, and auxiliary functions such as home positioning and end-stop detection are implemented as additional modules in the model-based part of the code. The only hand-written code changes required are the I/O configuration to support home position and end-stop signals.

 

in conclusion 
 

    Model-Based Design is a powerful tool that can accelerate embedded development for motor drive manufacturers. If set up and configured in a common way, it can significantly reduce the burden of handwritten code development and maintenance. It also speeds time to market because code development can be initially handled in the absence of hardware - as long as reasonably accurate models of key system components are available.
 

    These characteristics have been demonstrated in the case of a PMSM drive operating under FOC extended to multi-axis and position control. A method for partitioning the software modules and model-based components has been detailed to optimize the values ​​provided by the model-based solution. Experimental data also demonstrate the advantages of the model in terms of optimizing speed controller parameters, code generation compactness and efficiency.