Fast Prototyping and Deployment

of Control Algorithms for Power

Conversion Applications

Bijesh Poyil and Martin Murnane

Analog Devices, Inc.

Abstract

Model driven development has been adopted by the industry as a solution for

fast prototyping and to reduce time to market. However, a signiﬁcant amount

of time and effort must typically be put in the ﬁnal implementation stage to

match the performance of the product to the performance of the model. The

full potential of model driven development is not realized in practice due to

this. In this article, we discuss how we can address this gap by following

some guidelines and techniques during model development. We also cover

how we can generate efﬁcient code from the models to reduce the time to

market of the product.

Introduction

The increasing depth of penetration of distributed energy resources such

as grid tied solar inverters has resulted in the power conversion community

to look for better, efﬁcient, and cost-effective solutions for these markets.

There are many algorithms and topologies in the literature to improve the

output quality and efﬁciency of the power conversion process. Silicon vendors

are coming up with new control processors with features and hardware

support to implement these algorithms efﬁciently. It is very expensive

to build the hardware prototype of a full inverter and to experiment with its

performance under various conditions. Moreover, any malfunctioning of the

algorithm during experimentation could damage the entire system. There are

also associated safety standards to be met for the products in these markets.

So the power conversion industry has always been slow in adopting these

innovations into the ﬁnal product.

Model driven development has been adopted as a solution to this problem. In

model driven development, a full model of the system is built and simulated

before a hardware prototype is generated. This verifies the algorithm

functionality and reduces the risk signiﬁcantly. Moreover, current modeling

tools support code generation directly from the model that simpliﬁes and

relaxes safety certiﬁcation criteria. However, the industry has not embraced

full model driven development mainly because 1

)

the performance of the end

product and the model varies signiﬁcantly, and 2

)

the generated code is not

very efficient for the target control processor and requires manual

modiﬁcation before taking it to the product.

In this article, we discuss techniques and approaches that can make the

model performance very close to the ﬁnal product performance to minimize

the risk of hardware changes and delays. We also discuss how the code

can be generated efﬁciently from these models to get the product faster

to market.

Model Development Guidelines

Model Driven Development

Consider a simplified diagram of a grid-tied residential solar inverter,

as shown in Figure 1. The solar radiation on the solar panel generates

dc proportional to the intensity of the radiation. The converter converts this

dc to ac, which can be used by home appliances and also can be fed to

the grid. Current and voltages from various points in the signal chain are

sensed by appropriate sensors and will be fed to the control processor in the

inverter. The algorithm running on the control processor analyzes these

signals and controls the power modules such that the generated current

and voltage are of required frequency, magnitude, and phase with the grid.

In this case, the solar panel acts as the power source, and the grid and the

home appliances act as the sink. In a different power conversion system,

the sources and sink would be different, but most of them will fall into the

structure shown in Figure 2.

The primary aim of a power conversion system/algorithm designer is to

arrive at the right components and algorithms for the block’s control

processor and converter hardware

(

shown in Figure 2

)

and meet the desired

performance for all source and load variations. So it is important to clearly

know the environment the system is going to operate in while designing the

system. For example, while designing a solar inverter for a system

(

shown

in Figure 1

)

, the designer should know the places the inverter is expected to

install, variations in intensity of solar radiations, the efﬁciencies of the

solar panel, grid conditions, etc. In a model driven development, the designer

ﬁrst creates the model of the converter, simulates the expected variation,

and veriﬁes that the model works as expected. Most often the modeling

tools will provide models and library blocks for modeling sources and sinks.

For example, Simscape Power Systems

™

from Mathworks has models for

grids, photovoltaic

(

)

panels, and various loads. These can be used to

simulate and verify various use cases of the system.

The system performance depends on all the components of the system. In

some cases, the designer has the freedom to start the design from scratch

and decide on all the components of the system to meet constraints on

source and load. In some other cases, part of the system may already be

ﬁxed due to reasons outside the control of the designers, and their degree of

freedom is limited to few components. In this article, we assume the main

aim of the designer is to choose and implement the right control algorithm

for an existing topology—but most of the guidelines explained can be applied

to a generic case as well.

Visit analog.com

Technical Article

Share on

Twitter LinkedIn Facebook Email

Fast Prototyping and Deployment of Control Algorithms for Power Conversion Applications

Figure 1. Solar inverter system.

Figure 2. Power conversion components.

Structuring the Model

It is important to structure the model in a modular way with the right interfaces.

A well-structured model helps to analyze and adapt the model quickly

to various use cases. Modeling tools typically provide various options to

group the components at appropriate levels of abstraction and for reuse. For

example, Simulink has provisions to create subsystems, library models, or

reference models. Consider the power conversion system shown in Figure 2.

A top-level view of a Simulink model is given as an example in Figure 3.

In this ﬁgure, the power converter and control processor are encapsulated

into a subsystem labeled as ADIInverter. Solar panel and grid models available

with Simscape Power Systems are used to model the source with provisions

to conﬁgure intensity and temperature. The ADIInverter subsystem in

the figure can be further partitioned hierarchically into control processor

and control algorithm blocks.

All blocks other than the control algorithm running on the control proces-

sor are hardware blocks. So the accuracy of simulation reﬂecting all the

constraints of these components is the most important criteria.

The interfaces of these blocks are analog signals and the most appropri-

ate choice for these are continuous models. The block control algorithm is

meant for running on a microcontroller and should only use discrete states

and ﬁxed steps. It would be good to keep that as a separate model with

different conﬁguration and solver settings and reference that model from the

top-level model. This will also be helpful in code generation and processor in

loop

(

PIL

)

testing of the algorithm, as explained later.

Solver Step Size and Data Types

The speed and accuracy of the simulation is mainly decided by the solver

type and step size. A small step size will give more accurate results but

will make the simulation run slower. We want to simulate the hardware

components with maximum accuracy. A continuous solver with a vari-

able step size should work in most cases. However, when the switching

frequencies are high, manual adjustments for the maximum step size may

be required. For example, PWM generation at a switching frequency

of 100 kHz

(

as shown in Figure 4a

)

may become distorted

(

as shown in

Figure 4b

)

if the step size is large. It is always a good idea to check the

output of the fast switching devices to conﬁrm that the step size is sufﬁcient.

Since the control algorithm runs on a microcontroller, it should be using a

discrete model with a ﬁxed step size. The step size used should be the

greatest common divisor

(

GCD

)

of the sampling period used in the system.

Most often the modeling software chooses this automatically.

The data types used also decide the accuracy of simulation. Simulation

with double precision arithmetic will always be more accurate than a

simulation with single precision arithmetic. For simulating the hardware

blocks, it is recommended to use the highest data type supported by

the modeling software. But for the control algorithm, we want to get the

performance of the algorithm the same as it runs on the control processor

and not more accurate. So we should be using the data type supported

by the control processor. For example, if the control processor is an

Analog Devices ADSP-CM41x processor, the appropriate data type is

single precision ﬂoating point, as it comes with a Cortex-M4 processor

with a ﬂoating-point unit

(

FPU

)

. If the control processor is a ﬁxed-point

processor, such as a Cortex

-M3, the algorithm should be designed and

implemented in ﬁxed-point data types. Modeling software may support

automatic conversion from a ﬂoating-point data type to a ﬁxed point that

will help to make the development faster.

Power Module

Control Processor

Solar Panel Grid

Load

Control Processor

Control

Algorithm

Gate

Drivers

Power

Modules

Peripherals

Sensors PV Panels

Loads

Grid

Converter Hardware Power Source and Sink

Irradiance

(W/m

)

Irradiance

Temp

Ramp-Up/Down

Temp

m_PV

Temperature

(°C)

Node 10

ADIInverter

mIr

–

Tr2

Utility Grid

Figure 3. Example Simulink model.