When developing digital control algorithms for power converters, engineers often need a structured workflow that bridges the gap between control design, simulation, and embedded implementation.
The following workflow outlines a typical progression used by engineers working with PLECS, from controller design in the continuous domain to hardware testing and beyond.
It also highlights common challenges and demonstrates how Software-in-the-Loop (SIL) functionality can maintain model fidelity throughout a project’s lifecycle.
Continuous-Domain Controller Design
The first step in the workflow is to design the controller in the continuous domain. Engineers typically validate the controller’s stability and performance using frequency analysis tools, such as Bode plots, available through the Small-Signal Analysis tools in PLECS. This allows for intuitive tuning and analysis of gain and phase margins before moving to digital implementation.
Discretization and Validation in PLECS
Once the continuous controller is verified, the next step is to discretize the controller using methods such as the bilinear (Tustin) transformation. The discretized controller can then be implemented in the PLECS discrete domain, allowing verification that its performance remains consistent with the continuous design and that sampling effects are acceptable.
Software-in-the-Loop (SIL) Workflows
SIL testing allows engineers to run controller code, whether automatically generated or handwritten, directly within PLECS. This enables early validation of embedded software behavior against the simulated plant model, helping to catch integration issues before hardware testing.
SIL via Code Generation
For workflows using automatic code generation, engineers can use PLECS Coder to generate C code for the controller subsystem and run it directly within the PLECS simulation. This allows the generated code to be validated against the original continuous-domain design before deployment on the microcontroller.
This SIL setup ensures that the generated code behaves as intended and that the model and firmware remain aligned as the project evolves, providing reliable closed-loop validation from initial design through hardware deployment.
SIL via C-Script
In projects where code generation isn’t used, the control algorithm is typically handwritten in C for the target microcontroller. Traditionally, engineers integrate this code directly into the hardware development process, iteratively refining the firmware to meet performance goals or evolving system requirements.
Over time, the simulation model can drift from the firmware and hardware development. It often needs to be updated and benchmarked against measurements before exploring new control strategies, which can be time-consuming and error-prone.
To streamline development, engineers can run the handwritten code directly within PLECS using a C-Script block. This allows the code to interact with the simulated plant before deployment on hardware.
This approach enables teams to:
- Keep the PLECS model tightly coupled to the project
- Maintain fidelity between simulation and firmware
- Validate control algorithms in a virtual closed-loop environment
- Accelerate iteration between modeling, firmware, and hardware testing
This method bridges the gap between manual firmware development and model-based design, reducing risk and speeding up the workflow.
Example Model
The attached zip file includes a simple buck converter model with an outer voltage loop and an inner current loop. It demonstrates the workflow described above for projects using SIL with manual firmware and contains four configurations:
-
Configurations 1 and 2 demonstrate the classic steps in digital controller design. Config 1 uses continuous-domain controllers, while Config 2 implements the discretized version using PLECS discrete blocks.
-
Configuration 3 validates the individual PI controllers for the voltage and current loops using a modular approach. This configuration maintains a schematic structure similar to the continuous and discrete implementations, verifying the handwritten PI controller matches the discrete implementation.
-
Configuration 4 finalizes the file structure for an MCU project. Here, the PI controller implementation is separated into its own source and header files and used by an overall
buck_controllermodule that contains the voltage and current loop ISR functions.
PLECS_BuckConverter_SIL_Example.zip (14.3 KB)