Simulation essentials with Simulink

This note provides in-depth guidance for accurately and efficiently simulating an imperix controller and its corresponding plant model using the ACG SDK in Simulink. Because the underlying mechanisms are identical to those used in real-time operation, this content is also valuable for understanding the controller’s behavior during real-time execution.

Recommended articles related to the ACG workflow are shown below. A series of video tutorials is also available with similar content.

Offline simulation overview

As explained in PN134, offline simulation is an optional but highly valuable step in control software development, enabling validation of control algorithms before deployment. This process relies on simulation models of both the Controller and the Plant that faithfully reproduce real-world behavior using specialized blocks from the Control and Power libraries included in the ACG SDK.

Imperix supports using the same Simulink model for both simulation and code generation purposes:

• In offline simulation mode, both the Control and Plant subsystems are simulated.
• In code generation mode, only the Control subsystem is compiled, and the Plant subsystem is ignored.

Fundamental concepts

To model the behavior of the overall system, the following fundamental concepts are used:

• Plant modeling (continuous domain): Plant quantities are generally modeled with continuous signals (labeled Cont or FiM in the illustration below), as it is usually more efficient to simulate physical systems with wide-ranging dynamics. To support this, the model must be simulated using a variable-step solver.
• Control modeling (discrete domain): The control algorithms are modeled using discrete signals (labeled D1 in the illustration below), sampled at the CPU interrupt frequency and shifted by the sampling phase.
  • This requires an algorithm implemented in the discrete domain (in the \(z\) domain).
  • This is modeled accurately with the variable-step solver, since it is forced to take a major step at each interrupt execution.

While the imperix blocksets are designed to handle these concepts automatically, certain user-implemented code may require extra caution to remain coherent with the rest of the model. For this reason, it is crucial to develop a clear understanding of how these simulation models function "under the hood."

Control modeling

The controller is carefully modeled through each of its peripheral blocks. Together, these accurately describe and represent how the controller operates, enabling its behavior to be properly anticipated in simulation. A fundamental part of the corresponding modeling effort focuses on sampling and correctly representing the discrete execution of the control algorithms. Specifically, the following features are modeled:

• Sampling (CONFIG and ADC blocks): Both the frequency and exact sampling phase are accounted for in simulation. This notably permits the accurate modeling of synchronous sampling.
• Algorithm execution (CONFIG block): The delay introduced by the control algorithm is modeled to ensure the overall controller delay is accurately represented.
• PWM generation (PWM block): The frequency, phase, and shape of the PWM carriers are accurately modeled, along with the update instants of the duty-cycle and phase parameters. Optionally, dead time can also be simulated.

These three points directly follow from how imperix controllers physically operate, as detailed in PN261. More information about their firmware-level architecture is also given in PN253.

Plant modeling

To test the developed control logic in offline simulation, a plant model is required. This model can be built using any standard toolbox or by directly implementing the physical equations. To assist customers in deriving a model of their imperix power hardware, the Power library provides models for all imperix power products. The supported toolboxes for implementing these electrical circuits in the Simulink environment are:

• Simscape Specialized Power Systems (SPS, black blocks)*
• Simscape Electrical (blue blocks)
• PLECS Blockset for Simulink

Solver configuration

The variable-step solver can be configured to manage time-step calculations and simulation accuracy. These parameters are accessible via the Solver tab in the model's Configuration Parameters (Ctrl+E) or through the Simulation > Solver tab of the CONFIG block.

In most cases, the default values are sufficient. However, in some rare scenarios, manual adjustments may be necessary for the following reasons:

• Capturing fast transients: If rapid switching events are missed, lowering the Relative tolerance or the Max step size will force the solver to use higher precision and reduce the step size.
• Optimizing simulation speed: For long-duration simulations where high precision is less critical, increasing the Relative tolerance allows the solver to take larger steps, thereby reducing total simulation time. Obviously, this must be done carefully, as it may cause the solver to skip over critical high-frequency dynamics (e.g., PWM switching instants), resulting in significant inaccuracies in the simulated behavior.

Detailed information about variable-step solvers in Simulink can be found at https://www.mathworks.com/help/simulink/ug/variable-step-solvers-in-simulink-1.html

Working principles of the main peripheral blocks

The three fundamental library blocks are CONFIG, ADC, and PWM. Many applications can actually work with only those three, as in the standard configuration shown below:

CONFIG block

The CONFIG block configures the main global model parameters, such as:

• The model execution purpose (offline simulation or code generation).
• The frequency of the base clock \(F_{\text{CLK0}}\), which defines the sampling frequency and serves as the time basis for triggering the control interrupt. CLK0 can also serve as time base for PWM modulation.
• The sampling phase \(\phi_s\), which shifts the sampling instant within the CLK0 period.
• Optionally, the interrupt postscaler decimates interrupt execution by a factor \(k_{\text{post}}\).
• The cycle delay, which represents the computation time of the control algorithm. In most cases, the default value of 0.2 interrupt periods is sufficient. For higher simulation fidelity, the code should be executed on a controller and its execution time recorded in the Timings tab inside Cockpit.

These configuration parameters define the following timings, as further detailed in PN259:

• The sampling clock, with frequency \(F_{\text{SCLK}} = F_{\text{CLK0}}\) and sampling phase \(\phi_s\)
• The CPU interrupt, triggered at a frequency \(F_{\text{CPU}} = F_{\text{CLK0}}/k_{\text{post}}\) and a phase of \(\phi_s\)

To accurately model this in simulation, the CONFIG block contains a CLK block that generates a sawtooth signal at frequency \(F_{\text{CLK0}}\) with zero phase. This clock signal is then passed through a subsystem that generates the sampling clock with a relative phase shift \(\phi_s\)​, as illustrated below:

The CONFIG block also defines the value of a global variable named CTRLPERIOD. This variable can be used throughout the Simulink model as the sample time for any block (e.g. discrete transfer functions), ensuring its execution at the designated control rate. This provides an explicit alternative to using the inherited sample time (-1), which is particularly useful in complex models where Simulink’s automatic rate resolution differs from the user's intent (see the section about mastering the sample time). CTRLPERIOD is defined as a vector that incorporates both the interrupt (i.e. control) period and the sampling phase \(\phi_s\):

$${\small\texttt{CTRLPERIOD}} = \left[ k_{\text{post}}\cdot T_{\text{CLK0}}, \phi_s \cdot T_{\text{CLK0}}\right]$$

The interrupt execution period is therefore available with the variable \({\small\texttt{CTRLPERIOD(1)}}\).

ADC block

At the hardware level, each ADC block accesses a continuous variable representing a physical measurement, samples it at the desired sampling instant, and feeds it to the CPU for processing. The variable then becomes a discretely sampled value. More information about the corresponding process is given in PN261.

To accurately represent this behavior in simulation, the corresponding block takes the variable issued from the plant model ②, and samples it at the rising edges of the sampling clock ①. The resulting output signal ③ is then discretized with a rate and phase set to CTRLPERIOD, which automatically propagates to other blocks.

PWM block

Various types of pulse-width modulators are available at the hardware level. Among them, the carrier-based PWM modulator (CB-PWM) is the most widely used option.

In the simulation model, the clock signal ① serves as the frequency and phase reference for generating the carrier signal ②. In parallel, the duty-cycle value ③ is delayed by the algorithm execution time specified in the CONFIG block and sampled once or twice per switching period, depending on the update-rate parameter (see PN259 for more details). It is then compared to the carrier to produce the PWM signals ⑤. If Simulate dead time is checked in the mask parameter, a dead time is inserted between the complementary signals.

Mastering the sample times

Mastering the sample time (essentially the execution rate) of each block is key for an accurate and efficient simulation of discrete control algorithms in Simulink. Since Simulink uses this information to determine at which submultiple of the base rate certain tasks should be executed, this can also affect the real-time execution of the code. In any case, ensuring that the sample time aligns with the actual expectations is key to the relevance of the simulations conducted.

In particular, the execution rates must comply with the fundamental concepts listed above and be clearly identified by the Simulink engine, namely:

• The plant (i.e. physical) signals are represented as continuous signals.
• The control signals (i.e. those computed during the controller main interrupt) are represented as discrete signals with a sampling rate and phase corresponding to the configuration of the main interrupt. Their sample time is, therefore, the vector CTRLPERIOD.

All imperix blocksets are designed to comply with these concepts. Nonetheless, it is always recommended to monitor the sample times, as undesirable changes can easily occur in Simulink. Advice on how to verify and correct the sample times is given below.

Verifying the sample times

In Simulink, the sample time of each signal can be conveniently displayed by right-clicking a blank area of the model and choosing Sample Time Display > All. When this is correctly configured, the controller model should have the following colors in Simulation mode:

The color legend can be displayed by pressing Ctrl+J (see below).

The expected sample times are as follows:

• Continuous: Applied to the base clock signal and signals originating from the plant model.
• Fixed in Minor Step (FiM): An optimized version of "Continuous" applicable when a signal's value remains constant between the solver's major steps. This typically applies to switched signals (e.g., sampling clock and PWM), which do not vary between switching events.
• Variable 1, 2, 3: Assigned to specific clock signals internal to the CONFIG block.
• Discrete (D1): Used for all signals within the discrete control implementation (the algorithms executed by the CPU). D1 is technically a vector equal to CTRLPERIOD, which accounts for both the frequency and phase of the sampling.
• Multirate: Found in peripheral blocks, such as CB-PWM blocks and similar. Because these blocks bridge continuous plant signals and discrete control logic, they inherently incorporate multiple sample times.

To ensure the simulation implements a feasible configuration, the following conditions must be met:

1. The control implementation (all blocks between the ADC and PWM peripheral blocks) must consist exclusively of discrete signals because, in practice, control is discretized.
2. The red signals (D1) must have a sample time equal to CTRLPERIOD. This ensures that no part of the controller attempts to execute faster than the hardware interrupt, which is impossible. Other discrete signals may be present if they are integer multiples of the D1 period (hence, slower). In such cases, these signals necessarily appear in colors other than red. For more information on multi-rate control, please refer to PN145.

Correcting the sample times

If these conditions are not satisfied, the sample time of the problematic block(s) must be set to CTRLPERIOD. In many cases, an inherited sample time (-1) is also effective and resolves to CTRLPERIOD during model initialization.

The following example illustrates a problematic configuration in which the Sine Wave block defaults to continuous-time behavior. In this scenario, both conditions are unmet: the control path contains a continuous signal, and Simulink has resolved the fastest discrete sample time (red - D1) to something different than CTRLPERIOD.

To resolve this issue, the sample time of the Sine Wave block must be set to -1 or CTRLPERIOD. In practice, the CPU will update this value at its execution rate. It then makes sense that this is correctly modeled in simulation as well. Once the model is updated (Ctrl+D), the entire path resolves to a "red" discrete rate, equal to CTRLPERIOD.

In cases where the source of the rate conflict is difficult to identify or a block's sample time cannot be modified, a Signal Specification block set to CTRLPERIOD can be used. This helps Simulink resolve the sample times correctly throughout the signal path.

Further readings

The following related articles are recommended:

• PN138 is a guide to deploying code to imperix controllers.
• PN300 provides an overview of the tools available in Cockpit and explains how to use them.
• PN131 provides tips and tricks to speed up simulation with Simscape Electrical.