|
Power
Quality
The resolution of power quality problems benefits from
capabilities that go beyond those available in most network solver environments.
Here we describe the specific capabilities of the VTB that support the solving
of power quality problems, and explain why these capabilities are useful.
Many power system solvers operate on a fixed time step. That
is problematic with respect to resolving the time of switching events. The VTB
allows variable time steps, which are chosen in a somewhat unique way. Rather
than basing the choice of time step on the system eigenvalues, instead any model
in the system can request either a) a time at which to end the next step, or b)
a rollback of time to the last (valid) time step if an event is triggered that
invalidates the current system output (failure to converge, threshold crossing,
etc). Both of these capabilities are critical in a simulator for systems that
incorporate power electronics in the power quality solution.
Virtually every solution to a power quality problem involves
power electronics and every solution to a power electronics problem involves a
control system (usually digital). Hence a simulation or virtual prototyping
environment for power quality solutions should allow seamless integration of the
control design. Most definitely, the support for control design must not be an
afterthought. The VTB supports control integration through a well-defined and
very-complete multistep process.
First, the hardware of the system model is completely defined
by using standard components from the VTB model library. The control inputs are
left open, awaiting definition of the control model. The control algorithm is
then derived using whatever tools the control engineer prefers. Usually the
control design is based on an approximate or perhaps a linearized model of the
system, yet the real system is much more complex and contains nonlinearities and
signficantly greater detail than would be used in the control design. With the
VTB, it is possible to automate the process of system identification without
resorting to extensive hand analysis or oversimplification of the system.
Rather, the items in the Matlab Control System Toolbox and the System
Identification Toolbox can be used to probe the system as it operates in order
to “measure” the transfer function or other important quantities. These data can
then be used to help formulate the control law.
The next important step is to confirm that the designed
control does indeed work when inserted into a high-fidelity model of the system.
To do that, the controller is assembled in block diagram form using Simulink.
For initial tests of the Simulink model of the controller, it is convenient to
insert the control model into the system as a cosimulation object. This allows
the control engineer to interactively refine the controller – the Simulink block
diagram and/or the control coefficients can be changed on-line and the effects
of those changes on the system dynamics can be directly and immediately observed
without ever stopping the simulation.
Once the controller algorithm is designed (plus or minus
tolerances on the control parameters), the controller can be compiled into an
executable object by using the Realtime Workshop of Matlab in conjunction with
VTB’s tool for creating models from compiled Matlab code. The user can specify
which parameters should be accessible to the user in the controller dialog box
(if any parameters are intended to be user adjustable). The compiled controller
model can now be shared with others who may be working on the system design and
they do not need to own Matlab/Simulink in order to test how the controller
works as modifications or additional detail are added to the system model. At
this point, the control design path bifurcates depending on whether or not the
designer intends to go directly to an embedded controller or first to a general
purpose controller before committing to an embedded controller for production
purposes.
If the step through a general purpose controller (such as
dSpace) is chosen then the Simulink model can be automatically compiled and
downloaded directly to the controller card. Before connecting to real hardware,
the particular software implementation of the controller can be tested against
the virtual prototype of the system as it runs in VTB. This we call processor in
the loop. Generally this test will NOT detect small timing errors because the
system model is stepped slowly, one step after each instruction is executed on
the digital control platform.
When the control and system engineers are satisfied that the
system has been thoroughly tested the next step can be taken – testing the
controller as it is connected to the actual hardware. This test will reveal
timing errors if there are any.
Finally, if the
power quality solution will be marketed as a commodity device, there is a need
to transfer the control algorithm to an inexpensive embedded processor. This
step is quite simple if a C-language compiler exists for the processor because
the same code that was tested on the general purpose controller (which was the
same as the code generated by Simulink) can be compiled for the embedded
controller. The embedded controller can again be tested against the VTB system
model (processor in the loop) before finally committing the design to
production.
