Model Continuity: From Offline Simulation to Real-Time Testing

Simulations help developers in many ways during the entire development process of a new power electronics application. The development process typically comprises the functional concept, the component selection, the mechanical design, the controller implementation and finally the test and verification under normal and faulty conditions.

Ideally, the development process refers to the familiar V-model (Fig. 1), where the design and implementation follow a top-down approach and the verification follows a bottom-up approach. At each level, the developed component is verified with appropriate test tools and procedures before being integrated into a larger system.

Figure 1: V-model for the development process of a power electronic system

For the verification it is important that the same specifications are used as for the design. Although the design and verification tools may use models with different levels of detail, it is important to ensure that the models produce comparable results. This article explains why a single model is not sufficient for all applications and how to ensure that multiple models deliver consistent results despite their different implementations and use cases.

Circuit concept

In the first phase of a new design, the feasibility of a particular power circuit and a proper control scheme can be assessed quickly with ideal circuit components and generic control blocks. During this conceptual phase, no manufacturer-specific information is needed to model the individual components of a power converter. Rather, power semiconductors such as MOSFETs and diodes are represented by simple on/off switches that correspond to their functional behavior. The parasitic properties of passive components like winding resistance and inductor saturation can be neglected unless they play a functional role for the circuit operation.

Likewise, the controls are represented by functional block diagrams or state machines, independent of their final implementation. These controls may later be realized as analog circuitry, digital logic, microcontroller code or hardware PWM generators.

Simulation software used in the conceptual phase must provide generic models for all types of electrical components encountered in power electronic applications. As power semiconductors are normally operated in switch mode they should be modeled as ideal switches to reduce the complexity of the simulation model. The user must be able to freely connect arbitrary components and to create his own customized components by means of subsystems.

During the conceptual phase, the system model can grow in complexity and size. In order to obtain fast transient simulations without significant integration errors, the use of a variable time-step solver is strongly recommended. A variable step solver automatically steers the time step in such a way that the maximum integration error is not exceeded and switching instants and other discontinuous events are hit exactly.

The simulation software PLECS has been designed from the beginning for the simulation of power electronic systems. One distinguishing feature is its capability to model power semiconductors as true ideal switches, which allows for fast and robust simulations of large circuits without the need to tune solver settings. 

Component selection

Based on the current and voltage requirement determined by the circuit design, suitable components with specific part numbers are selected and the mechanical layout is created. In this second phase, simulations help to predict the thermal losses and the resulting temperatures. In a continuous workflow, the thermal model presents itself a new layer placed over the electrical circuit. The thermal domain computes the losses generated by the electrical circuit and models the heat transfer. 

Switching and conduction losses can be simulated efficiently using a set of loss tables for each semiconductor. Tables for switching losses provide the dissipated energy depending on the blocking voltage, the on-state current and the junction temperature of the device. Tables for computing conduction losses show the voltage drop as a function of on-state current and device temperature. In each simulation step, the thermal losses are calculated and fed into a thermal equivalent network that comprises the semiconductor device, the heat sink and the external cooling arrangement. 

The advantage of using loss tables over simulating voltage and current transients during switching is that ideal switching and thus high simulation speed is maintained. The computation of the thermal domain just adds some extra effort to the electrical simulation based on ideal components.

Power semiconductor loss tables to be used with PLECS are readily available from a growing number of semiconductor manufacturers such as ABB, Infineon and Wolfspeed.

Mechanical design

The mechanical design, which is carried out in the next phase, includes the placement of the components, the electrical layout, the design of the cooling system and the integration into a housing. 

Because CAD programs and PCB layout software require many other parameters than the ones used for system simulations, the model tool chain is typically broken at this point. In the mechanical design, the developer must adhere to the parameters used in the system simulation or modify them accordingly in the original data set.

Using the spatial layout information from the mechanical design the developer can determine the influence of parasitic inductances and EMI effects in an electrical simulation. This is only possible if detailed semiconductor models are used that accurately reproduce the switching transients. Since these models are computationally very intensive, they can only be simulated over a few switching cycles and are therefore not suitable for system simulations.

Due to the enormous effort involved in using spatial information and obtaining detailed semiconductor models, as well as the limited gain of new insights, such low-level simulation is often omitted.

Controller implementation

In a power electronics application, the development of the controls often requires more effort than the design of the power stage, especially if a microcontroller is employed. The development of the controller should therefore begin immediately after the conceptual phase has been completed, before the actual power hardware is built.

In the classical approach, experienced software developers will implement the control code for a specific target MCU according to the specifications of the controls engineers. Implementing embedded control code, though, requires continuous testing. This can be simplified by compiling excerpts of the control code into a DLL destined for the host computer instead of the target MCU. Most system simulation software can include DLLs so that the control code can be verified against a model of the controlled system. In addition, PLECS offers the possibility of pasting C code directly into the editor of the C-Script block. This code is then automatically compiled and executed along with the model.

In order to ensure that the implemented control code and the functional block diagram of the conceptual phase produce the same results, a Configurable Subsystem can be used in PLECS, one implementation of which contains the block diagram and the other the code. Simulating multiple implementations of the same functionality and overlaying the results in a PLECS Scope is a crucial test for model continuity.

A more modern approach to implementing controls on a MCU is to automatically generate target-specific C code from the functional block diagram. In addition to its offline implementation, each block must provide a method for outputting real-time capable C code. The block diagram typically contains generic signal processing blocks as well as target I/O blocks to configure the on-chip peripherals such as ADCs and PWM generators. Especially for beginners, auto-coding speeds up the development enormously, because peripheral configuration through program code is a daunting task that requires in-depth knowledge about the MCU or extensive study of the manual. With respect to model continuity, auto-coding has the advantage that the generated code always adheres to the block diagram definition. However, the responsibility for an efficient implementation of the controls is now shifted from the software developer to the controls engineer.

If the target MCU is not selected or the entire control board with the signal conditioning electronics is not yet available, the MCU can be temporarily replaced by a much more powerful real-time processing platform such as the PLECS RT Box. This approach is known as Rapid Control Prototyping (RCP) and helps to quickly get a working setup consisting of power stage and controller.

In PLECS, by switching from a particular MCU or the RT Box to a generic target, the generated code can be used instead of the original block diagram in the offline simulation. This feature allows for quick verification of the generated code by overlaying the simulation results. 

Controller testing

We have seen how handwritten or automatically generated code can be verified against the block diagram definition in an offline simulation by replacing the block diagram with the compiled code. This type of verification is called software-in-the loop (SIL) testing and allows for short turnaround times since no MCU needs to be flashed. However, the proper configuration of MCU peripherals cannot be verified with SIL, nor can timing issues, processor utilization or resource corruption be detected on the target MCU.

Testing not only the control code, but the entire control hardware, including the MCU peripherals, normally requires the real power stage to be connected to the controller. However, this is often impractical because the power stage and its protection may not be fully developed before final commissioning, and certain faulty operating conditions may even damage the power stage.

To test the control hardware independently of the power stage, the controller can be connected to a real-time simulator that mimics the behavior of the power stage. This approach is referred to as Hardware-in-the-Loop (HIL) simulation as the actual control hardware is part of a closed loop-simulation. Replacing the power stage with a real-time simulation has the advantage that the behavior of the controller can be extensively tested under a large number of normal and faulty conditions.

Controller HIL testing has become very popular, because the connection at signal level provides a clearly defined interface between the controller and the power stage, and only few modifications are needed to replace the power stage with a real-time simulator.

The challenge with HIL simulations of power electronics are the small time constants prevailing in electrical circuits. Only a short additional latency is acceptable, which is inevitably introduced by the real-time simulator. The computational latency between capturing the PWM signals and providing simulated sensor signals to the controller should be kept to a minimum, since the controller should still behave as if it were connected to the real power stage. This requires not only dedicated real-time hardware such as the PLECS RT Box, but also converter models optimized for fast and accurate execution in fixed time-step simulations.

Real-time simulations are always a race against the advancing time, since the computation of each time step must be completed within a discretization period. On a modern real-time platform, the minimum achievable time-step lies in the order of a few microseconds and may depend on the model size. Even with specialized converter models computed entirely on an FPGA, the time step can hardly be reduced below 0.5 μs. 

The switching frequencies of today’s power converters are mostly between 10 and 100 kHz. If the PWM signals were sampled only once per simulation step, the resolution of the captured duty cycle would be insufficient. In order to capture the duty cycle more accurately, the PWM signals are usually sampled at much smaller intervals of about 10 ns and averaged over one simulation step. The average value represents the relative on-time of the PWM signal during that step.

Averaged PWM signals can accurately represent the semiconductor gate signals only if they are applied to appropriate converter models. These models are based on controllable voltage and current sources instead of ideal on/off-switches (Fig. 2). Additional logic is employed to model discontinuous conduction mode and semiconductor blanking time. Since the simulation time step and thus the averaging interval is usually much smaller than one PWM switching cycle, in PLECS this modeling approach is referred to as sub-cycle averaging. Such converter models are also sometimes referred to as time-stamped bridges.

Figure 2: IGBT chopper model with two different implementations for offline and real-time simulation

While sub-cycle average models are recommended to for high-fidelity real-time applications, converter models based on ideal switches continue to be preferred in offline simulations. Because the sub-cycle averaging makes certain assumptions and simplifications, the simulation result might not always match exactly. Also, when using generated C code for fixed time-step simulations, the results can deviate slightly from the continuous-time model.

It is important that the same circuit model developed in the design phase is used when verifying the controller during HIL testing. However, a versatile offline model usually differs from a computationally efficient real-time implementation. To solve this dilemma, the power modules for various types of converter and inverter bridges in the PLECS library are all equipped with two implementations. One is based on ideal switches and the other uses sub-cycle averaging. The user can easily switch between them. To make sure that the two implementations behave the same even when discretized, the user should compare the results of the generated real-time code with the continuous model in an offline simulation as shown in Fig. 3---. This can already be done before uploading the code onto the RT Box.

Figure 3: Verification of real-time results through offline simulation

Conclusions

Using the same model for all simulations throughout the development process from design to verification is an ideal goal that is difficult to achieve in practice. Different aspects such as system or device behavior may require various simulation tools and models with very different levels of detail. Obtaining a single “digital twin” that resembles the entire system and using this twin as the single source of truth is therefore illusory.

Nevertheless, it is perfectly realistic to establish a development process in which all system parameters are stored in a central location and referenced by all models. This central location could be a comprehensive database or just a simple initialization script. Certain parameters will be used only by some models for simulating selected aspects. Using an integrated toolchain like PLECS helps to verify models for different purposes against each other and thus enables model continuity.