Multi-rate control

This note introduces the principles of implementing multi-rate control algorithms on imperix controllers. Multi-rate control is supported by the ACG SDK (for Simulink and PLECS environments) as well as the CPP SDK.

This note presents general principles, while environment-specific configuration instructions are provided separately for Simulink (PN145), PLECS (PN155), and C++ (PN149).

Context

The control of power electronics systems involves processes with physical phenomena operating across vastly different time scales. For instance, a grid-tied solar inverter control structure implies a fast inner-loop current control (typically 10–50 kHz), a slower DC-link voltage control (typically 100–1000 Hz), and a much slower MPPT algorithm (typically 1–10 Hz). Since controlling slow physical processes does not require high sampling or control execution rates, controller resources can be saved by adapting the sampling and execution rates to the underlying dynamics of each process.

For example, the diagram below illustrates the control structure of a grid-tied PV inverter (adapted from AN006 for illustration purposes). The different colors of the control blocks represent distinct execution rates, relying on Simulink’s discrete sample time visualization.

Multi-rate scheduling approaches

In a multirate control system, a rate defines the required execution frequency of a control algorithm, while a task defines the execution context in which one or more rates are scheduled. These rates must then be mapped to an appropriate task structure.

Two fundamental scheduling approaches can be used for this purpose: single-tasking and multitasking. The following sections describe their operating principles and compare their characteristics.

Imperix controllers support both execution modes. Dedicated configuration guidelines for single-tasking and multitasking on imperix controllers are provided separately for Simulink (PN145), PLECS (PN155), and C++ (PN149).

Single-tasking approach

In a single-tasking configuration, all execution rates are scheduled into a single monolithic control task. To derive secondary execution rates from the base rate, the generated source code uses software counters to trigger the execution of its corresponding slower rate routine.

The scheduling of the slower routines is handled automatically by Simulink or PLECS based on signal sample times. Alternatively, the scheduling can also be defined explicitly by the user using mechanisms such as triggered subsystems.

Because all subroutines run within a unique base-rate task, they execute sequentially. This sequential execution represents the primary limitation of single-tasking: the base-rate period must be long enough to accommodate the combined worst-case execution time of all overlapping subroutines (as illustrated in the figure below). Consequently, this constraint limits the maximum achievable base-rate frequency and prevents optimal utilization of the available computational resources.

Multitasking approach

In a multitasking configuration, although the control algorithm runs on a single CPU, the different execution rates are assigned to distinct, prioritized tasks. Higher-priority tasks can interrupt the execution of lower-priority tasks through a mechanism known as preemption.

Similar to the single-tasking approach, the base rate remains the fundamental timing reference for scheduling tasks. However, lower-priority tasks are no longer required to complete within a single base-rate period. If a slow task (lower priority) is still running when a high-priority base-rate interrupt occurs, the faster task preempts it. The slower task then resumes execution once the higher-priority task completes. This approach makes it possible to achieve a higher base-rate frequency or run more resource-intensive slow tasks without violating real-time execution constraints.

The figure below illustrates task preemption and shows how multitasking enables a higher base rate than single-tasking.

Data exchange and data dependency

In a multitasking environment, task execution is separated, but all tasks run on the same physical processor and share a single global memory space. Since tasks run at different execution rates, they can read and write shared data asynchronously. If data exchange is not handled properly and a higher-priority task preempts a lower-priority task mid-execution, it may read partially updated data or overwrite variables before the slower task finishes processing them.

To prevent data corruption, Simulink and PLECS provide a Rate Transition block to ensure time-consistent inter-task data transfers. More information about rate transition is given in Multi-rate control on Simulink (PN145) and Multi-rate control on PLECS (PN155). For C++ users, appropriate data-synchronization mechanisms, such as double buffering, should be considered.

Execution determinism

Due to preemption by higher-priority tasks, multitasking execution may introduce execution-time jitter on lower-priority tasks. In most power electronics applications, this is not an issue because the time-critical inner control loops execute at the highest priority and therefore experience deterministic timing. Lower-priority tasks, such as outer control loops, supervisory algorithms, or communication, generally tolerate the small timing variations introduced by preemption. Care should nevertheless be taken to avoid assigning time-critical algorithms to lower-priority tasks. If deterministic execution is required for all rates, single-tasking should be preferred.

Comparison of approaches

The table below summarizes the key architectural differences and trade-offs between the single-tasking and multitasking approaches.

Multitasking on imperix controllers

Task execution rules

As detailed in Operating principles of imperix controllers, and mentioned above, the control algorithm relies on an interrupt-based architecture. While a hardware interrupt schedules the main control task (base-rate task), subsequent tasks are triggered via software interrupts immediately following the main task’s completion. This operation follows the following concepts:

• Rate-monotonic preemption: Tasks use priority-based preemption. Higher priority is automatically assigned to tasks with higher frequency (see figure below).
• Overrun detection: An overrun occurs when a task fails to finish before its next scheduled execution time. Task overruns are strictly forbidden and will trigger a protection trip that disables all PWM outputs (core state: FAULT)
• Software interrupt limit: The architecture supports a maximum of 8 concurrent software interrupts.
• CPU load visibility: The CPU load metric displayed in Cockpit (Timings info tab) reflects the main control task only.

Control delay of sub-rate tasks

The evaluation of the control delay for loops running in the base-rate task is detailed in Discrete control delay identification. When control loops are implemented in slower tasks within a multitasking configuration, their control delay can increase and/or vary due to task preemption. Furthermore, to evaluate the control delay of these slower tasks, it is crucial to account for the fact that data exchange with the controller’s peripheral hardware (ADC, PWM, GPI, GPO, etc.) has to transit through the base-rate task.

The figure below illustrates the data paths through lower-priority tasks. The control delay for a given task is defined as the elapsed time between the sampling event (whose latest data is processed first by the base-rate task) and the moment the updated parameters (typically PWM duty cycles) are applied at the hardware modulator level. The resulting control delays for each task are also illustrated below.

Further readings

Environment-specific configuration instructions are provided separately for the following programming environments:

• Multi-rate control on Simulink (PN145)
• Multi-rate control on PLECS (PN155)
• Programming with CPP SDK (PN149)