Frequently Asked Question
Press "Ctrl + F" to find the keyword of your interest.
If you wish to have a direct link access to the video timestamps, please follow these instructions.
Found this video helpful? Why not take the whole HIL Specialist course? A Certificate is waiting for you for free at HIL Academy.
Would you or your organization benefit from having these videos narrated in your native language? Contact us and let us know if you wish to contribute.
TRANSCRIPT
Hello! In this video we will explain Model mapping,
which will be practically demonstrated with the model we have been using throughout basic workflow module.
Specifically, we will focus on different aspects of model compilation, which are necessary for
using your HIL device optimally. Besides a practical demonstration, we will also cover
the theoretical aspects of this topic necessary to apply this knowledge to more complex cases.
First of all, let s discuss the basic system architecture of the HIL system.
In order to have a simulation which runs in real time, we had to design our HIL
system so it can execute calculations fast. Because of this, specific parts of the model
simulation are predetermined to run on one of three separate units. These units exchange
data in real time among themselves. You can see these units on the right part of the slide.
Typhoon HIL simulators are based on a heterogeneous multi-processor
architecture. Every HIL device has these three elements Typhoon FPGA solver, System CPU,
and User CPU. If you want to understand the HIL architecture more comprehensively, take a look
at the System architecture basics documentation page, which is listed in the video description.
The Typhoon FPGA is a multi-core processor optimized for simulating
the electrical domain part of the model in real-time.
This means that every electrical circuit and all the components that comprise them such
as passive elements, converters, machines, and others, are simulated by this circuit solver.
In addition, there are two general purpose processors User CPU and System CPU.
Depending on the HIL device they can be single or multi-core processors. The System CPU is typically
used to either simulate low dynamics phenomena of certain electrical domain components or to handle
communication protocol stacks. A few examples of components that utilize System CPUs are Voltage
RMS, Single Phase Constant Power Load and Single Pole MP Circuit Breaker. In the vast majority
of cases, there is no need to change any of the default parameters of the System CPU.
In contrast, the User CPU is under direct user control. It executes sub-models composed
of signal processing components, such as Gain, αβ to DQ transformations, Sums, among others.
Now, let s see what this means for a real model.
For the model you currently see on the screen, the same separation applies.
The electrical part of the model is simulated by the FPGA circuit solver,
which in this case includes: the voltage source, the three-phase inverter, the contactor, and the
electrical machine. Control of the inverter, which is comprised of the sinusoidal sources,
the Constant source, and the αβ to abc component, are simulated on the User CPU.
The RMS current measurement in phase A is simulated on the System CPU.
Why should you know how the model is mapped on the HIL device? First you
need to know if your HIL device will meet the real-time requirements imposed by your model.
In practice, this means that your model needs to compile successfully for the selected HIL device.
For this to happen you need the basic knowledge of the system
architecture in order to efficiently troubleshoot compiler errors. Also,
managing your model s use of processing resources lets you utilize the hardware
resources economically so that you get the most out of your HIL device. Now that this is clear,
let s further explain the Typhoon FPGA solver architecture and constraints that it faces.
Typhoon s FPGA circuit solver simulates the electrical circuit with a predefined time step,
which can be set in Model settings, as shown in the 2.3.1 course sub-module. There are a
couple of constraints which are imposed by the fact that the simulation is run in real time.
The first one is that the simulation time step is discrete and fixed.
This simulation time step can t be dynamically adjusted and we can t
iterate our calculations in order to reach better simulation result.
The second one is that time for computation is strictly limited.
This means that all calculations must be finished before the next simulation step starts.
The system architecture is shown on this slide.
First, we will analyze the Standard Processing Core, sometimes referred to as SPC or simply
the core. This is a basic building block of the circuit solver, which is in charge of simulating
electrical circuits consisting of linear passive elements, converters, and contactors.
Let s check how many SPCs we have in our model and what they consist of.
In our model, we have only one SPC consisting of a resistor, a three-phase inverter, and a contactor.
We can see this by checking the Messages log when we compile the model to see the list of all SPCs.
You can currently see some elements corresponding to the SPC. This list is
useful when performing model partitioning, which will be covered in a later module.
Depending on the configuration of the device, we can have various amounts of SPCs in our model.
As we are currently compiling our model for a HIL 404 with configuration 1,
let s check how many SPCs we can fit.As you can see, for this configuration we have
a maximum of 3 SPCs. If we go to the Device table which can be found in Model settings,
we can check how many SPCs other configurations can support. As a reminder, the Device Table for
a given model can be found in the Model Settings dialog box in the Model menu in Schematic Editor.
You can see that if we want to have more SPCs, such as to simulate multiple converters,
we should switch to Configuration 2 since it supports 4 SPCs.
Configuration 3 offers a smaller amount of SPCs but has other benefits which may be useful for
simulations with electrical machines. In short, changing the device configuration
to provide more capacity can let you better use the FPGA solver resources.
Let s now talk about the SPC s internal resources.
On the left part of the slide, there is a visual overview of SPCs internal resources, while on the
right part we have the Device Configuration table for HIL404. Different colors indicate
relationship between device table parameter and specific SPC internal resources. Let s briefly
talk about Typhoon approach to converter modelling before taking a closer look at Converter solver.
The converters are modeled using ideal switches. Converters with more switches
increase the computational load on the solver. We assign each converter
a predefined weight to represent the magnitude of this computational load.
More complex converters have a weight of 3, such as the three-phase inverter in our model,
while simpler converters such as an IGBT Leg have a weight of only 1. We will take a deeper and
more comprehensive look at modeling converters in the HIL for Power Electronics submodule.
For each switch state permutation, our circuit model is considered to
be linear and time-invariant. We call these permutations the mode
of the circuit. For each mode of the circuit, we have designated a linear,
time-invariant model which is discretized and represented by a state space matrix.
Converter weight plays a significant role in the context of the Converter solver.
Since all switch permutations within the converter will trigger a circuit mode change,
we need a unit to determine what the next circuit mode will be. This unit is the Converter
solver. However, as the weight of the converter increases, so does the number of circuit modes,
which increases the load on the converter solver. Therefore, each configuration has a limit
on the overall weight of converters per SPC.Let s check out what this means for our model.
First let s enter into the Three Phase Inverter properties. In the description of the component,
you can see that its weight is 3. Now when we check the messages log,
we can see in the line Power Electronics Converter utilization that we reach the maximum
possible weight for this configuration.Now, let s move to the contactor solver.
Contactor states are determined by the contactor solver. They are also used for turning on and
off delays, zero current turn off, and generating feedback signals. Similarly,
to how we have a specific weight available per core, we also have specific number of contactors
available for each core. This information can be found in the device table as well.
Let s see what how many contactors we are able to put in our model.
As you can see, we have only one single-phase contactor in this model. If we take a look at
the messages log, we will notice that we are able to have up to six contactors in this SPC.
It is important to note that three phase contactors still count as one contactor,
since all three switches in the contactor work synchronously.
Now, let s move to the Non-ideal switch solver.Non-ideal contactors are modeled as small
inductances while they are conducting and small capacitances when they are open.
The biggest advantage of including these is that you can fit many more non-ideal
contactors than ideal contactors under certain configurations, but they should be used sparingly
because the way they are modelled puts an extra load on time slot utilization.
We currently don t have any non-ideal contactors in the model.
If we take a look at the Message log, we ll notice that for the current configuration we have no
available non-ideal switch utilization. Because of this, if we need to add non-ideal switches,
we will have to switch to another configuration.
Let s now discuss the time varying elements solver.
If we want to simulate time varying elements, such as variable inductors,
capacitors and resistors, which have an ability to change their values in real time,
we need to employ the time-varying elements solver.
As you can see in our model, we have no time variable elements in it.
In the messages log, you can notice that we can fit up to sixteen time-varying elements.
Now let s look at the rest of the SPC utilization parameters.
The total number of signal processing controlled sources is limited to 16 per core,
although we are not using any currently. Delayed controlled sources may appear as an
embedded part of some components, such as super capacitors. For this specific configuration we
can use up to 12 components that use delayed controlled sources.
We are now left with the two parameters of the SPC which describe their performance abilities:
matrix multiplier and matrix memory.
Matrix multiplier processing power defines the minimum simulation step for a given model.
The Matrix memory size defines the maximum size of the SPC, in terms of the number of passive
components and ideal switches. Increasing the number of passive components increases
the matrix size, and increasing the number of ideal switches results in additional matrices.
Now we can analyze how these two performance parameters apply for our model.
The memory requirements of our circuit is estimated during the compilation process.
Each core has a specific amount of memory allocated to it.
As you can see, our core only takes around a third of its designated memory.
Matrix memory utilization is in direct correlation with two parameters in Device configuration table
SPC matrix memory and SPC output memory size. If your core takes too much memory,
you should seek a configuration which provides relatively larger values of these parameters.
Aside from matrix memory, let s cover the matrix multiplier processing power.
The value of the matrix multiplier processing power parameter directly
reflects the SPC s ability to finish all calculations within one time step.
As you can see in the messages log, this model has a predefined simulation step of 1 microsecond.
After the matrices has been discretized with this time step, the timing constraint
analysis begin. In this part, the compiler analyzes if all SPCs and other functional
units could run on this time step, and time slot utilization is expressed in relative units.
As you can see in timing constraint analysis part of messages log, none of our functional
units exceed the maximum possible time slot of 100 percent. This means that timing
constraints are met, and that this model will run successfully both on a HIL 404 or on virtual HIL.
We have now analyzed all the resources that comprise a Standard Processing Core.
Let s now analyze other resources that comprise Typhoon FPGA solver.
The next functional unit within FPGA is the Signal generator. This unit is used
to simulate independent sources such as voltage sources, current sources, constant power loads,
and others. Since the Signal generator has a table based implementation, it supports
arbitrary waveforms. These waveforms could be harmonically rich waveforms, created inside
our SCADA or in our Waveform Generator tool.Let s see how is this implemented in our model.
We currently have only one voltage source. In the messages log, we can
see that we utilize only one signal generator out of a possible 12 for this configuration.
It is important to mention that this utilization counts every signal source,
regardless of if it is within a three-phase or single-phase component. For example, three-phase
voltage source will take 3 units within signal generator, even though it is a single component.
We should make distinction here between different types of sources.
We previously mentioned that Signal Processing sources utilization as a core resource these
sources have Signal Controlled prefix in their name and they utilize SPC resources. Basic signal
sources, such as voltage source or current source which have no special prefix are FPGA resources.
There are also two more types of sources voltage or current controlled which are
sources controlled by measurements in other components or externally controlled sources,
which are controlled from HIL analog inputs. These sources utilize only matrix memory.
Look-up tables are another type of FPGA resource. We use these to simulate
elements within an electrical circuit that have non-linear characteristics.
Some elements that have Look-up tables within them are Non-linear inductors, PV panels, and
batteries, among others. Every configuration has a specific number of Look-up tables it can support.
We don t utilize any element that contains a Look-up table in our model,
so in the messages log you can see that we use 0 out of the 8 possible for these elements.
The capacity for look-up tables is available for any combination of components that needs them.
For example, since we have a max of eight look-up tables, we could add three
batteries and five non-linear inductors.Now we ll discuss Machine solver. This FPGA
resource is a dedicated part of the processor which solves machine electro-magnetic state
space equations in the D-Q or alpha-beta domains and solves the mechanical equations.
In addition, the machine solver has built-in support for speed and position measurement devices
such as an incremental encoder and resolver.You can see that we currently use one machine
in our model the Induction machine with squirrel cage. Looking at our Machine solver utilization,
we see that the Machine solver resource is fully occupied.
The PWM Modulator is a FPGA resource which is used to generate PWM signals. When we
want to control our model with an internal control algorithm, as we have done in our model, then it
is very useful to utilize the PWM Modulator. PWM Modulators will be more comprehensively explained
in the Power electronics module. For now, we ll just discuss the resources they take up.
As you can see, we control this three-phase inverter by providing three modulation signals
to the PWM Modulators. As you can see, we use 3 PWM channels out of a possible 12.
This is because we have a Three-phase inverter, and each leg utilizes one of the PWM channels.
The last step of the compiling is the timing validation. Timing validation checks if the
FPGA solver can run a model with the required simulation step. If this part of the compilation
is finished successfully, then you can be sure that the timing validation passed.
This validation uses the device settings you defined for your model to define constraints,
and applies it to both the physical and virtual devices. This means that if you successfully
finish compiling the electrical part of the model and run it on virtual HIL in non-real-time,
the same model will run in real time on the selected HIL device. Therefore, you
can validate that your model will work on a real HIL device without having physical access to it.
This concludes the compilation of the Electrical part of the model.
If you want to learn more about FPGA solver, please take a look
at the FPGA solver basics documentation page listed in the video description.
The next part of the compile process is the compilation of the signal processing.
This means that the compiler will generate code for both the User and System CPU.
CPUs impose two boundaries on the signal processing
the maximum memory available and the maximum number of specific signal processing elements,
such as digital and analog probes, tunable elements, SCADA inputs and outputs, and others.
As we previously mentioned, we do have a component which runs on the System CPU in our model:
the RMS current meter in phase A. Inside the RMS meter there is one probe element, and as
you can see in the messages log, it is counted in the Probes utilization line. In the second part
of the compilation of signal processing we can see that the memory utilization is rather low.
Next, we can inspect the compilation for the User CPU.
This paragraph in the messages log shows how the CPU is utilized. We have two SCADA inputs, which
is reflected in the line IO variables utilization. Also, we have two probes, which is reflected
in the Probes utilization. One of the probes is streaming, which is reflected in the line
Streaming bandwidth, comparing the number of kilo Samples per second sent to the maximum capacity.
Lastly, the memory utilization of the compiled model code is shown.
This concludes the signal processing compilation and the whole compilation process in general.
This means that now we are ready to load compiled model to SCADA and to begin simulation.
Now you should have a detailed understanding of what is behind a successful model compilation. If
you are interested in signal processing modeling principles, please take a look at the Signal
processing modeling principles documentation page listed in the video description. In the
next video, we will take you through some of the typical issues that new users encounter during
the compilation process and how to solve them.
Thank you for your attention.
