25 kW SiC DC Fast Charge Design Guide (Part 5): Control Algorithms, Modulation Schemes, and Feedback

The “power converter” is the core element of the model (our hardware representation), and the “controller” is the associated main algorithm block, the one we are developing and evaluating. Ultimately, by using the automation tools provided by the MATLAB simulation ecosystem, the algorithm block will be translated into the FPGAIP core itself.

By: Onsemi Karol Rendek, Stefan Kosterec

In Parts 1-4 of this series of articles[1-4], we shared and extensively introduced the development of 25 kW electric vehicle charging piles from a hardware perspective. Figure 1 represents the system discussed so far.

25 kW SiC DC Fast Charge Design Guide (Part 5): Control Algorithms, Modulation Schemes, and Feedback
Figure 1. High-level block diagram of a 25kW electric vehicle DC charging pile.

The fifth section will delve into charging pile design from another dimension, and we will discuss the control strategy and algorithm implementation of such systems, and provide practical insights.

Our intent is not to discuss control theory, but to provide first-hand details on the beneficial approach development teams have taken to control hardware and software development, helping to speed up the firmware development and verification process. This information applies to both the state machine on the ARM controller and the main control algorithm on the FPGA, which we’ll go into in detail later.

At the same time, the specific development process described here ensures that errors are minimized and detected early, even before prototyping hardware is provided or designed. In the following sections, we describe the steps and tools (MathWorks and Xilinx) to implement this approach, the state machine and algorithm block for power factor correction (PFC), and the main algorithm block for the DAB converter.

Control strategy development process

The overall architecture of the PFC control software is shown in Figure 2. At the heart of the design is Xilinx’s Zynq 7000 SoC, which contains an ARM core and an FPGA core. The Zynq 7000 is mounted on a Universal Controller Board (UCB), which also contains peripherals, ADCs, multiple memory boards, and the power tree required for the SoC and other components.[5]

First, the ARM core runs state machines (high-level routines in firmware) and other auxiliary tasks, including communication protocols, protection functions, and more. Second, the FPGA acts as the provider of the main control algorithm, running the control loop that drives the converter, processing power as needed, implementing AC-DC conversion, PFC, and boosting the voltage to the desired DC link level. Therefore, the “main algorithm” on an FPGA is a specific state of the state machine, which can be called a steady state. The DAB converter uses the same task distribution between the ARM core and the FPGA.


Figure 2. Overview of the 25 kW PFC converter control architecture. Schematic diagram of the assignment of tasks between the FPGA and ARM MCU of the XilinxZynq 7000 on UCB. The overview of the control architecture of the DAB converter is the same.

Using Model-Based Testing to Reveal Errors in Control Systems

Figure 3 illustrates the typical distribution of errors and detected errors across the entire project development chain. It can be seen that most bugs are introduced in the early specification and design stages; however, they are mostly not discovered until later in testing.


Figure 3. Introduced errors versus detected errors. (Source: Clive Maxfield and Kuhoo Goyal, EDA: The Beginning of Electronics.)

To address the phenomenon presented in Figure 3, we employ a development process that aims to detect most of these errors in the early stages of development. When implemented properly, this approach offers several advantages from a project resource and timeline perspective, including:

Minimize the risk of additional required hardware iterations.
Control system and converter performance can be largely optimized before the hardware is ready.
Accelerates the hardware evaluation phase and minimizes the necessary adjustments to the hardware. During the production of the prototype board, a lot of work has been performed.

To this end, onsemi firmware and control engineers take a model-based testing approach that leverages the MATLAB tools and ecosystem[6]. The successful implementation of this approach rests on four key pillars that developers need to address:

A representative model needs to ensure that the simulated system response closely matches the actual system response within a feasible simulation time. For PFC power supply simulation, a similar trade-off as described in Section III is made between model accuracy and simulation time.
Compile and verify our firmware C code (state machine) in our simulation process and simulation model. Therefore, verification occurs during the simulation phase, not the hardware evaluation phase.
FPGAIP cores can be automatically synthesized from validated models. This eliminates hand-coding errors and enables advanced optimizations to minimize FPGA core area while meeting timing constraints.

To accelerate the implementation of these features, we take full advantage of the following tools (shown in Table 1).

Table 1: Development and simulation tools used by ON semiconductor engineering teams to develop,
Firmware for simulating, deploying, and testing a 25 kW fast DC electric vehicle charger design.

One step at a time. How to develop simulation models?

Figure 4 depicts a simplified flowchart of the firmware development and execution process, divided into three main stages summarized in Table 2. In this article, only the simulation model development is discussed in depth, which is the most important phase.


Figure 4. 25 kW fast DC charging pile firmware development flow chart.

Table 2: Stages of the firmware development process.

The simulation model development phase includes the development of a simulation model (or simulation module) for validating the system control algorithm. The most important modules included in this project are:

• C code (state machine) that will run on the ARM core, imported via S-function block for simulation
• Converter control algorithm (control loop)
• Power converters for modeling hardware
• Hardware interface for modeling ADC circuits in hardware
• Device modules, AC devices for PFC and DC devices for DAB.

During this development phase, we use “light” models (representative models without improved details), which allow us to operate under various conditions (grid impedance, current command – depending on changes in output power levels – and others) ) to run multiple situations/scenarios to verify the controller’s response to many different scenarios. Therefore, switching models should be avoided at this stage, as these models are very detailed and take a lot of time to run – which we learned about in Power Supply Simulation in Part 3 of this article series.

We use an average switch equivalent model[7]As an alternative, the model allows building simulation blocks using FPGAIP cores. At the same time, we have preserved all the important/influential features of the hardware to ensure the integrity of the simulation, such as converter voltage drop effects, noise measurements, PWM transmission and analog-to-digital delays, etc.

Steps to Generate IP Using MATLAB

This chapter moves to the details section, which describes the key steps to implement a particular simulation model and how to take full advantage of the capabilities provided by the MATLAB environment. Figure 5 shows a simplified representation of a generic power conversion system with the elements presented in Table 1.


Figure 5. Simplified representation of a generic power conversion system (not specific to a 25 kW DC charger).

The “power converter” is the core element of the model (our hardware representation), and the “controller” is the associated main algorithm block, the one we are developing and evaluating. Ultimately, by using the automation tools provided by the MATLAB simulation ecosystem, the algorithm block will be translated into the FPGAIP core itself.

Our team used a series of six steps during the model development phase, through to final IP generation. An overview of these steps can be found in the simplified flowchart in Figure 6, which is briefly described below.

●- Step 1: We develop the model with double precision floating point, while the power converter uses the average model. As discussed in the previous section, at this stage the developed model plays an important role, being as light as possible to allow a reasonable simulation run time, yet accurate enough to reflect the actual behavior of the system.

●- Step 2: We use the automated tools provided by MATLAB to generate a fixed-point equivalent model of the system. The tool used for this task is MATLABFixedPointDesigner.

●- Step 3: After converting the double precision to fixed point precision, run a verification simulation to ensure that the fixed point conversion does not affect the working behavior of the system.

– Step 4: After verification, add the state machine to be run in the ARM core of the UCB controller. A tool that allows handwritten C code to be simulated in a Simulink model is the S-function. At this point, we should be able to test the controller for a variety of scenarios and conditions within a reasonable simulation run time. During this process, various important subtasks may occur. For example, verification of proportional-integral controller gains, evaluation of controller load step response, overcurrent response of state machines, and error handling.

●- Step 5: Before generating the FPGAIP core, we strongly recommend running some simulations for the selected situation/scenario, replacing the averaged model of the converter with the switching model. This process is time-consuming and should be repeated for very few simulation cases. However, it is important to ensure that the controller is immune to nonlinearities introduced by the switching behavior of the converter.

●- Step 6: Having sufficient confidence in the developed algorithm, we can now generate the FPGAIP core using automated tools. This process significantly reduces programming errors, enables area-optimized synthesizable RTL, and meets timing constraints.


Figure 6. Six-step flowchart for the simulation model development phase. For convenience of presentation, the “peripheral” module in FIG. 5 is omitted from this flowchart. Its location and connections to other modules are the same as in Figure 5.

PFC Control Strategy: State Machines and Control Loops

This chapter will introduce the control strategy of PFC in detail, including state machine and control algorithm (control loop). The state machine runs on the ARM core of the UCB, and the control algorithm runs in the “DC bus VOLTAGE_CONTROL” state of the state machine and is implemented on the FPGA chip.

In the following chapters, we will provide more details about the state machine and algorithm functions. Figure 7 provides an overview of the PFC state machine, with the “DC bus VOLTAGE_CONTROL” state highlighted in green, where the control loop and FPGA take over control and run the main algorithm function.


Figure 7. Overview of the PFC converter state machine.

When a 50 Hz three-phase voltage is supplied to the input connector of the charging pile, the output bus capacitor voltage will rise due to the nature of the PFC topology. A bridgeless PFC with MOSFETs guarantees a current path from input to output due to the presence of parasitic freewheeling diodes on each MOSFET.

When the MOSFETs are all off, the board is simplified to a three-phase diode bridge. The rectified input AC voltage will be set to a defined level based on the magnitude of the supply voltage and the forward voltage of the MOSFET body diode. However, it is desirable to provide at least a minimum AC voltage at the input. Therefore, the resistors on the two different lines act as inrush current limiters.

Once the bus voltage reaches 230 V, the main auxiliary power supply starts working. This power supply, along with a series of DC-DC regulators, generates the other voltage levels needed to power digital and analog circuits.For more details on PFC functionality, please refer to the ON Semiconductor AND9957/D Vehicle Charger PFC Converter Application Note[8]the implementation strategy is the same as this 25 kW DC charging pile project.

PFC state machine implementation on ARM core

As mentioned above, the state machine of the PFC runs on the ARM core of the UCB. The sequence starts with the IDLE module shown in Figure 7 and proceeds to offset voltage verification and input voltage monitoring and detection in the ADC channel. These are used to determine the frequency and phase angle of the three voltages. The phase angle will be used as the reference for the system to achieve power factor correction.

When the DC bus voltage reaches a flat steady state, the PFC controller sends a command to the relay, bypassing the surge resistor and allowing the output bus voltage to rise further. However, the voltage increment will be lower than the rectified input voltage amplitude √6∙VPHrms. The PFC controller will wait until the bus voltage is flat again in order to start controlling the bus voltage to the target value of 800 V. Instead of reaching the target value in one step, it follows a smooth ramp generator that ramps the bus voltage value up to a final 800 V according to a parameterized ramp.

The PFC implements only one hardware protection against overcurrent events using the DESAT function of the NCD57000DWR2G gate driver. However, DESAT hardware protection can be combined with software protection to generate a single-ended input to the NAND gate, providing a hardware stop for PWM generation.

The fault condition can only be reset by a reset command sent by the GUI or by a power down/power up sequence, which represent a hardware/software reset, respectively. For more details on the PFC function, see Reference 8, which describes the same implementation strategy as this 25 kW DC charging pile project.

PFC main algorithm and control loop on FPGA

Figure 8 illustrates the PFC control module as part of the complete simulation model. The PFC algorithm uses seven inputs and three outputs (see Table 3 for an overview). As part of this project, we will run and test different modulation strategies to evaluate which one yields better results in terms of efficiency and harmonic distortion. This control strategy is the same as that described in Reference 8.


Figure 8. High-level block diagram of the PFC control algorithm.

Table 3: Input and output parameters of the PFC control algorithm.

Figure 9, as a more in-depth study, shows in detail the modules and relationships that make up the PFC algorithm. VLINEVoltage is used to determine the actual position of the AC voltage phasor. Then, the current phase delay is adjusted to 0° using the angle θ, which is the main goal of PFC. The voltage positions are used to transform from a stationary ABC system reference to a rotating DQ coordinate system (for PFC, the D axis represents the magnitude of the phase voltage phasors) via Clark and Parker transformations.

Since the angle θ is known, all charges can be represented in the DQ system; this simplification ensures that a simple proportional-integral (PI) regulator can be used. The gain adjustment of the PI depends on the transfer function of the device to be adjusted. PI regulators can indeed effectively adjust the error to zero when a constant can be provided as a reference, but these regulators cannot adjust an AC reference.


Figure 9. Detailed block diagram of the PFC control algorithm.

In any case, the PI regulator needs some kind of calibration to ensure proper system stability. It is generally expected that the current loop (inner) has a faster response and the outer loop (voltage) has a slower response. It is worth noting at this point that the current control loop runs synchronously with the PWM. The synchronization procedure ensures that the ADC peripheral can be triggered at the exact time instance of the PWM carrier to ensure that switching ripple is naturally filtered out of the measured amount of current.

It should be added that, due to the inherent ADC measurement delay, the PWM frequency is not completely independent of the control frequency, and this delay should be small enough to ensure timely execution of the PFC algorithm within the switching cycle. Since the latency of the FPGAPFC controller is very low, around 150 nanoseconds, the main limiting factor for the PWM frequency is the ADC sampling and conversion time. Once you have the number of ADCs, the control implementation is straightforward.

The main functions of PFC have been extensively tested using MATLAB, as described in the “Steps to Generate IP Using MATLAB” chapter. The main Simulink model used is shown in Figure 10 (the only missing part in this model is the S-function for testing the firmware state machine). The modules used are explained in the figure.

Note that the models at this level consist mainly of Simulink blocks, including the averaged model of the three-phase power converter. Grid and Interconnect Filter Utilization of PFC

Models in the SimscapeElectrical library, while DC loads and capacitors (DC devices) are modeled with the help of LaplaceSimulink modules. The model is light enough to support a reasonable simulation time using a conventional laptop, taking less than a minute to achieve a 0.1 second simulation.


Figure 10. Simulink model of the main PFC controller. The DC device modules (simple resistors and capacitors) are used as loads to test the functionality of the PFC algorithm and do not represent a model of an actual DAB converter.

DAB Converter Control Strategy and Flux Balance Technology

The implementation of the DAB converter control strategy follows a similar process to that of the PFC. In this chapter, we will discuss the control algorithm of the converter as well as the flux balancing technique. At the time of this writing, the Simulik model for the converter needs to be redesigned to be ready for the HDL encoder, and the average model for the DAB has not yet been finalized (we are still in step 6 of Figure 4).

Starting with the control algorithm, of the available control techniques, perhaps the best known technique is the fixed frequency phase shift technique. Figure 11 shows a classification of these techniques, of which single phase shift (SPS) is the simplest one. In fact, the simplicity of the controller is the main advantage of this technology, but at the cost of increased current circulation in the converter and the possibility of zero-voltage switching (ZVS) within a tighter operating range. These two drawbacks definitely affect the efficiency of the system.

Two SPS-based alternatives are Extended Phase Shift (EPS) and Dual Phase Shift (DPS) techniques, which enable more efficient use of the converter, reduce circulating current and extend the operating range of ZVS. But these improvements come at the cost of adding additional controls and complexity to the system.

Finally, Triple Phase Shift (TPS) technology is a unified version of SPS, EPS and DPS. From this point of view, SPS, EPS and DPS can all be derived from TPS and can be regarded as special cases or sub-cases of TPS. Figures 12-14 illustrate how SPS, EPS, and DPS work, respectively.


Figure 11. Classification of different phase shifting techniques. Triple Phase Shift (TPS) is a unified version of the other techniques, each of which can be considered a sub-case of TPS.


Figure 12. Single Phase Shift (SPS) technique. (Source: “Overview of Dual Active Bridge Isolated Bidirectional DC-DC Converters for High Frequency Link Power Conversion Systems”[9])


Figure 13. Dual Phase Shift (DPS) technique. (Source: “Overview of Dual Active Bridge Isolated Bidirectional DC-DC Converters for High Frequency Link Power Conversion Systems”[9])


Figure 14. Extended Phase Shift (EPS) technique. (Source: “Overview of Dual Active Bridge Isolated Bidirectional DC-DC Converters for High Frequency Link Power Conversion Systems”[9])

In the fourth part of this article series, we noticed that the power supply simulation of the DAB converter was performed using SPS. Later, we will test more advanced techniques on hardware prototypes and evaluate the advantages each technique will bring.

The most important possible improvement will be an increase in converter efficiency. In addition, it is possible to reduce the excitation peak current in the transformer (IM), which would allow the use of more compact transformers and inductors.

Control Algorithms and Flux Balance Model Modules

The control principle of DAB is shown in Figure 15. The goal of the controller is to generate the desired output voltage or current for the battery.


Figure 15. Block diagram of the DAB control algorithm. Transformer flux balancing algorithms are also included.

The basic concept is simple: both the measured output voltage (or current) and the target value are fed to the input PI controller. The output of the PI controller attempts to drive the PWM on the primary and secondary sides by generating the desired Δφ (that is, the angular phase difference between the primary and secondary AC voltages of the DAB), eliminating the error between them. The control loop is slow due to the output capacitance, but given the slow dynamic behavior of battery charging, this is not a problem.

It should be added that the importance of adaptive PI gain to compensate for the steep Vout/ΔΦ slope. A pure proportional controller (as opposed to PI) can be used as an alternative. However, the engineering team needs to do further research in this area.

An interesting part of the DAB control algorithm that deserves elaboration is the flux balance function. This technique, introduced in Part 4, compensates for any DC component in the converter transformer, preventing the accumulation of excitation current and core saturation.

Figure 16 shows the Simulink model used to implement the flux compensation concept in a 25 kW DAB transformer. The module has three inputs and one output. Primary and secondary transformer currents and synchronization (sync.) pulses are the inputs to this module. The output of this module is used to adjust the duty cycle of the PWM on the primary side of the transformer.


Figure 16. Magnetic flux compensation block diagram.

The flux balancing module is triggered by the secondary PWM sync pulse of the transformer (at the switching frequency of the converter), which means that the AC current fed into the module should require (at least) twice the switching frequency of the converter. Specifically, the sync pulses are those PWM pulses used to drive the high side switch of the first leg of the secondary side. Then, with the help of the sampled input current, the excitation peak-to-peak current of the DAB transformer is obtained by simple calculation.

The sample-and-hold (S&H) circuit is then triggered by the same sync pulse to calculate the switching average of the excitation current to be replicated. Finally, the estimated field average current is fed to a proportional (P) controller, which will generate a command to adjust the primary-side PWM duty cycle. Figure 17 shows the functionality of the flux balancing algorithm implemented in the simulation.


Figure 17. Simulated transformer magnetizing current (I) when DAB’s flux compensation algorithm is inactive (left) and active (right).M). When the flux balancing technique is not running, residual DC current accumulates during each switching cycle, eventually saturating the core.

A key factor in the effective implementation of flux balancing techniques is the required current acquisition bandwidth. As mentioned above, the switching frequency of the current to be measured and applied is 100 kHz, so the system should be able to measure at at least 200 kHz. So it is worth running a simulation to ensure that the selected current sensor does not introduce significant measurement errors that would break the flux compensation implementation.

The selected current sensor (LEM) has a specified bandwidth of 300 kHz. It must be taken into account that as the sampling frequency approaches 300 kHz, there will be gain reduction and, as with any acquisition system, there may be phase lag. So even though 300kHz seems to provide enough headroom at first glance, it is recommended to run the simulation. Sampling currents with/without limited LEM bandwidth are shown in Figures 18 and 19. (Note that in this example, we have not activated flux compensation, so the field current increase is very large.)

In Figure 19, it can be observed that there are very small, but almost negligible errors in magnitude and phase. The double sampling method included in the algorithm (two current measurements per switching cycle) will also help mitigate errors. In either case, we have seen in Figure 17 that the flux balance works fine.

The simulations shown below should be run before or concurrently with the results presented in Figure 17. Therefore, conventional LEM sensors with a bandwidth of about 300 kHz can be used. Figure 20 illustrates the estimated switch average current, the actual magnetizing current (IM) and sync pulses.


Figure 18. Primary and secondary current measurements with/without LEM current sensor effect. The flux balance algorithm does not work in this simulation.


Figure 19. Primary and secondary current measurements with/without LEM current sensor effect.


Figure 20. Estimated total excitation current (with LEM current sensor effect), estimated switch average (with LEM sensor effect), and sync pulse. The flux balance algorithm does not work in this simulation.

Summarize

As observed at the beginning of this discussion, here we take a different angle than the previous installments in this series, delving into the implementation of the control strategy and how it can be optimized and accelerated. This article describes a beneficial approach followed by the ON Semiconductor engineering team to help debug and identify bugs early in the simulation phase, prior to hardware production.

Additionally, this approach speeds up control development for hybrid controllers that combine ARM cores and FPGAs. Finally, it automatically generates FPGAIP from simulation models created in Simulink, facilitating the use of FPGAs by firmware engineers who are not experts in FPGA development. Needless to say, when the firmware can be deployed on the board and the actual complete system can be verified, the actual verification of the control algorithm can be done.

The Links:   QM100TX1-HB NL160120BC27-14