J. Inst. Eng. India Ser. B
DOI 10.1007/s40031-014-0128-6
REVIEW PAPER
Review of Real-Time Simulator and the Steps Involved
for Implementation of a Model from MATLAB/SIMULINK
to Real-Time
Suresh Mikkili • Anup Kumar Panda
Jayanthi Prattipati
•
Received: 10 December 2012 / Accepted: 21 May 2014
The Institution of Engineers (India) 2014
Abstract Nowadays the researchers want to develop their
model in real-time environment. Simulation tools have
been widely used for the design and improvement of
electrical systems since the mid twentieth century. The
evolution of simulation tools has progressed in step with
the evolution of computing technologies. In recent years,
computing technologies have improved dramatically in
performance and become widely available at a steadily
decreasing cost. Consequently, simulation tools have also
seen dramatic performance gains and steady cost decreases.
Researchers and engineers now have the access to affordable, high performance simulation tools that were previously too cost prohibitive, except for the largest
manufacturers. This work has introduced a specific class of
digital simulator known as a real-time simulator by
answering the questions ‘‘what is real-time simulation’’,
‘‘why is it needed’’ and ‘‘How it works’’. The latest trend in
real-time simulation consists of exporting simulation
models to FPGA. In this article, the Steps involved for
implementation of a model from MATLAB to REALTIME are provided in detail.
Keywords RT-LAB MATLAB HIL FPGA OP5142 Real-time implementation
S. Mikkili (&) J. Prattipati
Department of Electrical and Electronics Engineering, National
Institute of Technology Goa, Farmagudi, Ponda, Goa 403401,
India
e-mail: msuresh.ee@gmail.com; mikkili.suresh@nitgoa.ac.in
A. K. Panda
Department of Electrical Engineering, National Institute of
Technology Rourkela, Rourkela, Orissa 769008, India
Abbreviations
COTS
Commercial off-the -shelf
DSP
Digital Signal Processor
EMT
Electromagnetic Transients
FPGA
Field Programmable Gate Array
HIL
Hardware-in-the-Loop
RTW
Real Time Workshop
RT LAB
Real Time Laboratory
RTWT
Real Time Windows Target
SIL
Software –in –the Loop
TNA
Transient Network Analyser
PSS/E
Power system simulator for engineering
EMTP
Electro Magnetic Transients Program
PSCAD
Power Systems Computer Aided Design
MATLAB Matrix laboratory
Introduction
The term ‘‘real-time’’ is used by several industries to
describe time-critical technology [1]. However, the most
common usage of ‘‘real-time,’’ and the usage that applies to
Opal-RT, is in reference to embedded systems. Embedded
systems are electronic devices designed to interface with
the real world and provide control, interaction, and convenience of some form. In a real-time system, the
embedded device is given a predetermined amount of time,
such as, 1 ms, 5 ms or 20 ms to read input signals, such as
sensors, to perform all necessary calculations, such as
control algorithms, and to write all outputs, such as control
actuators, and control fuel flow.
RT-LAB [1–20], fully integrated with MATLAB/Simulink [2, 10, 14], is the open Real-Time Simulation
software environment that has revolutionized the way
Model-based Design is performed. RT-LAB’s flexibility
123
J. Inst. Eng. India Ser. B
and scalability allow it to be used in virtually any simulation or control system application, and to add computingpower to simulations, where and when it is needed. This
simulator was developed with the aim of meeting the
transient simulation needs of electromechanical drives and
electric systems while solving the limitations of traditional
real-time simulators [3]. It is based on a central principle:
the use of widely available, user-friendly, highly competitive commercial products (PC platform, Simulink TM). The
real-time simulator consists of two main tools: a real-time
distributed simulation package (RT-LAB) [1–16, 19–22]
for the execution of Simulink block diagrams on a PCcluster, and algorithmic toolboxes designed for the fixedtime-step simulation of stiff electric circuits and their
controllers. Real-time simulation and Hardware-in-theLoop (HIL) applications [5, 7, 13, 15, 20] are increasingly
recognized as essential tools for engineering design and
especially in power electronics and electrical systems.
This work presents the role and advantages of using
real-time simulation by answering three fundamental
questions, i.e. what is real-time simulation; why is it needed and how it works; The present work tried to investigate
the details of evolution of Real-Time Simulators, the
details of RT-Lab Simulator Architecture, the details of
How RT-LAB Works, the details of OP5142 configuration,
the steps involved for implementation of a model from
MATLAB to REAL-TIME and many allied areas.
Real-Time Simulation
(a)
Gaining time
•
•
•
(b)
Lowering cost
•
•
•
(c)
Allowing test engineers to gain time in the testing
process.
Find problems at an earlier stage in the design
process.
Proceeding to a device design while the actual
system is not physically available.
Reduces enormous cost on testing a new device
under real conditions.
The real-time system could test many possible
configurations without physical modification.
Reduction of total cost over the entire project and
system life cycle.
•
Automatic test script in order to run tests 24 hours
a day, 7 days a week.
Fixed-step solvers solve the model at regular time intervals
from the beginning to the end of the simulation [3]. The
size of the interval is known as the step size: Ts. Generally,
decreasing Ts increases the accuracy of the results while
increasing the time taken to simulate the system [5].
Definition: In a real-time system [6], it is defined that
the Time Step as a predetermined amount of time (ex: Ts =
10 ls, 1 ms, or 5 ms) as shown in Fig. 1. Inside this amount
of time, the processor has to read input signals, such as
sensors, to perform all necessary calculations, such as
control algorithms, and to write all outputs, such as control
actuators.
Over-runs: In a real-time system, when a predetermined time step is too short and could not have enough
time to perform inputs, model calculation and outputs,
there is an overrun which is shown in Fig. 2.
Evolution of Real-Time Simulators
Simulator technology has evolved from physical/analogue
simulators (HVDC simulators &TNAs) for EMT and protection & control studies, to hybrid TNA/Analogue/Digital
simulators capable of studying EMT behaviour, to fully
digital real-time simulators, as illustrated in Fig. 3.
Physical simulators served their purpose well. However,
they were very large, expensive and required highly skilled
technical teams to handle the tedious jobs of setting up
networks and maintaining extensive inventories of complex equipment. With the development of microprocessor
and floating-point DSP technologies, physical simulators
have been gradually replaced with fully digital real-time
simulators [1, 19, 21].
DSP-based real-time simulators were developed using
proprietary technology, and were used primarily for HIL
studies, were the first of the new breed of digital simulator
to become commercially available [5, 20]. However, the
limitations of using proprietary hardware were recognized
quickly, leading to the development of commercial supercomputer-based simulators, such as HYPERSIM [6] from
Increasing test functionalities
•
•
Fake and test all possible scenarios that could
happen in real life in a secure and simulated
environment.
High flexibility by being able to modify all
parameters and signals of the test system at a glance.
123
Fig. 1 Time step of real time systems
J. Inst. Eng. India Ser. B
Hydro-Quebec, which is no longer commercially available.
Attempts have been made by the researchers to develop
fully digital real-time simulators using low-cost standard
PC technology, in an effort to eliminate the high costs
associated with the use of high-end supercomputers. Such
development was very difficult due to the lack of fast, lowcost inter-computer communication links. However, the
advent of low-cost, readily available multi-core processors
(from INTEL and AMD) and related COTS [7] computer
components has directly addressed this issue, clearing the
way for the development of much lower cost and easily
scalable real-time simulators. In fact, today’s low-cost
computer boards equipped with eight processor cores
provide greater performance than 24-CPU supercomputers
that were available only 10 years ago. The availability of
this low-cost, high performance processor technology has
also reduced the need to cluster multiple PCs to conduct
complex parallel simulation, thereby reducing dependence
on sometimes-costly inter-computer communication
technology.
COTS-based high-end real-time simulators equipped
with multi-core processors have been used in aerospace,
robotics, automotive and power electronic system design
and testing for a number of years [6]. Recent advancements
in multi-core processor [13] technology means that such
simulators are now available for the simulation of EMT
Fig. 2 Over-runs of real time systems
expected in large-scale power grids, micro grids, wind
farms and power systems installed in all-electric ships and
aircraft. These simulators, operating under Windows, LINUX and standard real-time operating systems, have the
potential to be compatible with a large number of commercially available power system analysis software tools,
such as PSS/E, EMTP-RV and PSCAD, as well as multidomain software tools such as SIMULINK and DYMOLA
[23–25]. The integration of multi-domain simulation tools
with electrical simulators enables the analysis of interactions between electrical, power electronic, mechanical and
fluid dynamic systems.
The latest trend in real-time simulation consists of
exporting simulation models to FPGA [22]. This approach
has many advantages. First, computation time within each
time step is almost independent of system size because of
the parallel nature of FPGAs [8, 22]. Second, overruns
cannot occur once the model is running and timing constrains are met. Last but most importantly, the simulation
time-step can be very small, in the order of 250 nanoseconds. There are still limitations on model size since the
number of gates is limited in FPGAs. However, this technique holds promise.
Moore’s law describes a long-term trend in the history
of computing hardware. Since the invention of the integrated circuit was in the year 1958, the number of transistors that can be placed inexpensively on an integrated
circuit has increased exponentially, doubling approximately every two years. The trend was first observed by
Intel co-founder Gordon E. Moore in 1965 [17].
It has continued for almost half a century and in 2005
was not expected to stop for another decade at least. The
exponential growth of memory size and clock frequency in
computers has a great impact on everyday life. The growth
is empirically described by Moore’s law of miniaturization.
Physical limitations of this growth would have a serious
Fig. 3 Evolution of RT-LAB
Simulator
COTS
Simulation-OnChip
Digital COTS*
Simulators
Digital Custom
Simulators
Digital Supercomputer
Simulators
Hybrid (Analog/Digital)
Simulators
Analog
Simulators
* COTS: Commercial-Off-The-Shelf
1960
1970
1980
1990
2000
Year
123
J. Inst. Eng. India Ser. B
impact on technology and economy. A thermo dynamical
effect, the increasing thermal noise voltage (Johnson–Nyquist noise) on decreasing characteristic capacitances,
together with the constrain of using lower supply voltages
to keep power dissipation manageable on the contrary of
increasing clock frequency, has the potential to break
abruptly Moore’s law within 6–8 years, or earlier [18].The
Real-Time simulators are now fully digital. The processing
power evaluates with the Moore’s Law. Moore’s law for
CPU speed and transistors count is shown in Figs. 4 and 5.
RT-LAB Simulator Architecture
Block Diagram and Schematic Interface
The present real-time electric simulator is based on RT
LAB real-time, distributed simulation platform; it is
optimized to run Simulink in real-time, with efficient
fixed-step solvers, on PC Cluster [9]. Based on COTS nonproprietary PC components, RT LAB is a modular realtime simulation platform, for the automatic implementation of system-level, block diagram models, on standard
PC’s. It uses the popular MATLAB/Simulink as a frontend for editing and viewing graphic models in block-diagram format. The block diagram models become the
source from which code can be automatically generated,
manipulated and downloaded onto target processors
(Pentium and Pentium-compatible) for real-time or distributed simulation.
Fig. 4 Moore’s law for CPU
count
123
Inputs and Outputs (I/O)
A requirement for real-time HIL applications is interfacing
with real world hardware devices, controller or physical
plant alike. In the RT-LAB real-time simulator [10], I/O
interfaces are configured through custom blocks, supplied
as a Simulink toolbox. The engineer merely needs to drag
and drop the blocks to the graphic model and connect the
inputs and outputs to these blocks, without worrying about
low-level driver programming. RT-LAB manages the
automatic generation of I/O drivers and models code so to
direct the model’s data flow onto the physical I/O cards.
Simulator Configuration
In a typical configuration (Fig. 6), the RT-LAB simulator
consists of
•
•
•
One or more target PC’s (computation nodes); one of
the PCs (Master) manages the communication between
the hosts and the targets and the communication
between all other target PC’s. The targets use the
REDHAT real-time operating system.
One or more host PC’s allowing multiple users to access
the targets; one of the hosts has the full control of the
simulator, while other hosts, in read-only mode, can
receive and display signals from the real-time simulator.
I/O’s of various Types (analog in and out, digital in and
out, PWM in and out, timers, encoders, etc). I/O’s can
be managed by dedicated processors distributed [11]
over several nodes.
J. Inst. Eng. India Ser. B
Fig. 5 Moore’s law for
transistor count
The simulator uses the following communication links;
•
•
•
•
Ethernet connection (100 Mb/sec) between the hosts
and target PC’s.
Ethernet connection between target nodes allowing
parallel computation of models with low and medium
step size (in the millisecond range), or for free-running,
on real-time simulation.
Fast IEEE 1394 communication links (400 Mb/sec)
between target PC’s for parallel simulation of models
with small step sizes (down to 20 lsec) and tight
communication constraints (power systems, electric
drive control, etc.).
Fast shared-memory communication between processors on the same motherboard (dual, quad or 8
processors)
The Working Process of RT-LAB
RT-LAB allows the user to readily convert simulink
models, via Real-time workshop (RTW), and then to conduct Real-time simulation of those models executed on
multiple target computers equipped with multi-core PC
processors. This is used particularly for Hardware-in-loop
(HIL) and rapid control prototyping applications [12]. RTLAB transparently handles synchronization, user interaction, real world interfacing using I/O boards and data
exchanges for seamless distributed execution. Type of realtime systems configurations are given in Fig. 6.
Single Target Configuration
In this configuration (Fig. 7a, b), typically used for rapid
control prototyping, a single computer runs the plant simulation or control logic. One or more hosts may be connected to the target via an Ethernet link. The target uses
QNX or Linux as the RTO’S for fast simulation or for
applications where real-time performance is required [1, 3].
RT-LAB used Red-Hat ORT which is the standard Red Hat
distribution package with an optimized set of parameters to
reach real-time performance enabling to reach model time
step as low as 10 micros on multi-core processors.
Distributed Target Configuration
The distributed configuration (Fig. 8a, b) allows for complex models to be distributed over a cluster of multi-core
PCs [13] running in parallel. The target nodes in the cluster
communicate between each other with low latency protocols such as FireWire, Signal wire or Infinite Band, fast
enough to provide reliable communication for real-time
applications. The real-time cluster is linked to one or more
host stations through a TCP/IP network. Here again, the
cluster of PCs can be used for Real-Time applications
(using QNX or Red Hawk Linux), or fast simulation of
complex systems (using QNX, Red Hawk or Windows).
RT-LAB PC-cluster targets are designed for flexible and
reconfigurable mega-simulation. The user can build and
expand the PC-cluster as needed, then redeploy the PCs for
other applications when the simulation is done. RT-LAB
can accommodate up to 64 nodes running in parallel.
123
J. Inst. Eng. India Ser. B
Fig. 6 Type of real-time
systems configurations
Fig. 7 a. RT-LAB Simulator
with Single Target system.
b RT-LAB Simulator with
Single Target system and HIL
TCP/IP
Host Computer-Windows
Target Computer
Edition of Simulink model
I/O and real-time model execution
Model compilation with RT-LAB
QNX or Linux OS
User interface
FTP and Telnet communication
Possible with the Host
(a)
(b)
Simulator Solvers
The RT-LAB electrical simulator uses advanced fixed timestep solvers and computational techniques designed for the
strict constraints of real-time simulation of stiff systems.
They are implemented as a Simulink toolbox called ARTEMIS, which is used with the sim Power Systems (PSB). PSB is
a Simulink toolbox that enables the simulation of electric
circuits and drives within the Simulink environment [14].
While PSB supports a fixed-time-step solver based on the
123
Tustin method, PSB alone is not suitable for real-time simulation due to many serious limitations, including iterative
calculations to solve algebraic loops, dynamic computation
of circuit matrices, un-damped switching oscillations, and the
need for a very small step size which greatly slows down the
simulation. The ARTEMIS solver uses a high-order fixedtime-step integration algorithm that is not prone to numerical
oscillations, and advanced computational techniques necessary for the real-time simulation of power electronic systems
and drives such as:
J. Inst. Eng. India Ser. B
Fig. 8 a. RT-LAB Simulator
with distributed target system.
b. RT-LAB Simulator with
distributed target system and
HIL
•
•
•
•
•
Exploitation of system topology to reduce matrices size
and number by splitting the equations of separated
systems
Support for parallel processing suitable for distributed
simulation of large systems
Implementation of advanced techniques for constant
computation time
Strictly-non-iterative integration
Real-time compensation of switching events occurring
anywhere inside the time step, enabling the use of
realistic simulation step sizes while ensuring a good
precision of circuits with switches (GTO, IGBT etc).
Configuration parameters are given in Fig. 9.
RT-LAB Simulation Development Procedure
Electric and power electronic systems are created on the
host personal computer by interconnecting:
•
Electrical components from component model libraries
available in the Power System Block-set
•
•
•
Controller components and other components from
Simulink and its toolboxes that are supported by RealTime-Workshop
I/O blocks from the simulator I/O tool boxes. The easyto-use drag-and-drop Simulink interface issued at all
stages of the process.
These systems are then simulated and tuned off-line in
the MATLAB/Simulink environment [14]. ARTEMIS
fixed step solvers are used for the electric part and
Simulink native solvers for the controller and other
block-diagram parts. Finally, the model is automatically compiled and loaded to the PC-Cluster with RTLAB simulation interface.
PCI OP5142 Configuration
The OP5142 (Fig. 10) is one of the key building blocks in
the modular OP5000 I/O system from Opal- RT Technologies [1, 10]. It allows the incorporation of FPGA technologies in RT-LAB simulation clusters for distributed
123
J. Inst. Eng. India Ser. B
Fig. 9 Configuration
parameters
execution of HDL functions and high-speed, high-density
digital I/O in real-time models. Based on the highest density Xilinx Spartan-3 FPGAs, the OP5142 can be attached
to the backplane of an I/O module of either a Wanda 3U- or
Wanda 4U-based Opal-RT simulation system. It communicates with the target PC via a PCI-Express ultra-lowlatency real-time bus interface [15].
The OP5142 includes connectivity to up to four (4) 4U
digital and/or analog I/O conditioning modules. This
allows the incorporation of task-specific I/O hardware,
such as high-speed analog signal capture and generation.
Furthermore, FPGA developers can incorporate their own
functionality, using the System Generator for DSP toolbox
or their favourite HDL development tool, through the PCIe
interface without the need for connecting to the JTAG
interface. Configuration files can be uploaded and stored on
the built-in Flash memory for instant start up. The PCIExpress port on the OP5142 adapter board allows the user
to connect the distributed processors together and operate
at faster cycle times than ever before. This real-time link
takes advantage of the FPGA power to deliver up to 2.5
Gbits/s full-duplex transfer rates. Table 1. gives the
description of OP5142 layout.
Key Features
Reconfigurability
The OP5142 platform FPGA device can be configured
exactly as required by the user. Integration with Simulink,
the System Generator for DSP toolbox from Xilinx and
RT-XSG from Opal-RT Technologies allows the transfer
of Simulink sub models to the OP5142 [10] FPGA processor for distributed processing. In addition, standard and
123
Fig. 10 OP5142 Layout
user-developed functions can be stored on the on-board
Flash memory for instant start-up. The OP5142 board is
configurable on-the-fly using the PCIe bus interface and the
RT-Lab/Live lab design environments.
Performance
The OP5142 series products enable update rates of 100
MHz, providing the capability to perform time-stamped
capture and generation of digital events for high precision
switching of items such as PWM I/O signalling up to very
high frequencies, as I/O scheduling is performed directly
on the OP5142 board.
Channel Density
•
•
Up to 256 software-configurable Digital I/O lines for
event capture/generation, PWM I/O and user functions;
Up to 128 16-bit Analog I/O channels, simultaneous
sampling at 1 MS/s per channel for digital-to-analog
J. Inst. Eng. India Ser. B
Table 1 Description of components in OP5142 Layout (OPAL-RT)
Pin
Name
Description
1
S1
FPGA Engine manual reset
2
JTAG1
FPGA JTAG interface
3
JTAG2
CPLD JTAG interface
4
JUMP4
JTAG Architecture selection
5
JTAG3
PCIe Bridge JTAG interface
6
JTAG 4
SerDes JTAG interface
7
JP1
PCIe & Synchronization bus and Power supply
8
J1/J2/J3
Backplane data, ID and I2C interface
9
JUMP1
Identification EEPROM write protection
10
JUMP2
FPGA configuration mode selection
11
12
JUMP3
J4
Flash memory Write protection
Flash memory forced programmation voltage
conversion and
conversion.
400
5.
kS/s
for
6.
7.
• The synchronization pulse train to a RTSI
connector;
• Data communication packets to the PCI-express
bus;
• Power supply voltages.
analog-to-digital
FPGA Engine manual reset: This button is connected to the master reset signal of the OP5142 board.
Pressing this button forces the FPGA reconfiguration,
and then sends a reset signal to all OP5142
subsystems.
2. FPGA JTAG interface: This connector give access
to the OP5142 JTAG chain. It is used to configure the
flash memory with its default configuration file. The
JTAG connection enables the user to program
manually the reprogrammable components on the
board and to debug the design using the Chip scope,
through the System Generator for DSP ‘‘Chip scope’’
block. The use of this port is reserved for advanced
users. In general, this port should not be used after
the board is manufactured. Depending upon the
‘‘JUMP4’’ jumper presence, this interface may give
access to both the FPGA [19] and CPLD configuration, and only the FPGA one.
3. CPLD JTAG interface: If the ‘‘JUMP4’’ jumpers
are set to the independent mode, this connector gives
access to the CPLD JTAG configuration interface.
The JTAG connection enables the user to program
manually the reprogrammable components on the
board. The use of this port is reserved for advanced
users. In general, this port should not be used after
the board is manufactured. If the jumpers are set to
the shared mode, the CPLD and FPGA JTAG
configuration are dasy-chained, and the ‘‘JTAG1’’
connector must be used instead of this one.
4. JTAG architecture selection: This connector
enables the JTAG interface of the OP5142 CPLD
and FGPA to be daisy-chained. For independent
operation, place jumper between pins 6-8. For daisy
chain operation, place jumpers between pins 1-2, 3-4,
5-6 and 7-8, and use the FPGA JTAG connector only.
PCIe Bridge JTAG interface: This connector gives
access to the PLX PCI-express bridge JTAG interface. It is used during manufacturing to configure the
bridge with its default configuration, and should not
be used by the user.
SerDes JTAG interface: This connector gives
access to the Texas Instrument Serializer - Deserializer JTAG interface. It is used during manufacturing
to configure the chip with its default configuration,
and should not be used by the user.
PCIe & Synchronization bus and Power Supply:
This port implements all data and power transfers
that need to be done with the external world. It
carries to the external PCI-express adapter:
1.
Backplane Data, ID and I2C interface: These three
connectors are to be attached to the Wanda Backplane Adapter J1, J2 and J3 headers. They exchange
all I/O-related data to the I/O module, including
identification data, serial communication with I2C
devices and user I/O dataflow.
9. Identification EEPROM write protection: This
header enables the write protection of the EEPROM
located on the OP5142. This EEPROM contains the
board revision ID, and should always remain writeprotected.
10. FPGA Configuration Mode selection: This header
enables the developer to select the way the OP5142
FPGA should be configured. The two options are
(a) JTAG configuration, or (b) Slave parallel configuration (from the Flash memory). In normal use, the
FPGA should always be configured using the Slave
parallel feature. pin #1 has been kept on the left-hand
side of the header (i.e. the ‘‘J’’UMP side).
11. Flash Memory write protection: This header is used
to enable the developer to write some reserved sectors
of the configuration flash memory. These sectors
should never be used by the user.
12. Flash memory forced programmation voltage:
This header provides a 12V supply voltage to the
JUMP3 connector. JUMP3 is used to enable the
developer to write some reserved sectors of the
configuration flash memory. These sectors should
never be used by the user. Note that pin #1 is on the
left-hand side of the header (i.e. the ‘‘J’’4 side).
8.
123
J. Inst. Eng. India Ser. B
Technical Specifications
Steps Involved for Implementation of a Model From
MATLAB to REAL-TIME
Digital I/O
Number of channels
256 input/output configurable in 1- to 32-bit
groups Compatibility
Power-on state
3.3V
High impedance
FPGA
Device
Xilinx Spartan 3
I/O Package
fg676
Embedded RAM available
216 Kbytes
Clock
100 MHz
Platform options
XC3S5000
Logic slices
33,280
Equivalent logic cells
Available I/O lines
74,880
489
Bus
Dimensions (not including connectors)
PCI-express x1
Data transfer
2.5 Gbit/s
Analog Conversion Interface
Two types of analog conversion modules are available,
namely, the OP5340 (a bank of analog-to-digital converters) and the OP5330 (a bank of digital-to-analog converters). The analog conversion banks must be placed onto an
OP5220 passive carrier, thus providing an easy access to
the modules on the front panel of the Wanda box. OP5330
and OP5340 features are:
•
•
•
•
•
•
•
•
•
Up to 16 analog Input (OP5340) or Output (OP5330)
channels;
One 16-bit ADC (OP5340) or DAC (OP5330) per
channel;
Accuracy of ?/- 5mV;
Simultaneous sampling on all channels eliminates skew
errors inherent in multiplexed channels;
Up to 500 kS/s update rate for every channel. Total
throughput of up to 8 MS/s
Dynamic range of ± 16V;
Hardware configurable on-board signal conditioning
and anti aliasing filter;
On-board EEPROM memory for calibration
parameters;
Library of drag-and-drop Opal-RT RT-XSG blocks for
Simulink
123
The execution process allows user to run the Simulink
model with Opal-RT’s [1] software and hardware. It is
based on eight (8) main steps:
1.
2.
3.
4.
5.
6.
7.
8.
Open a model
Edit a model in MATLAB
Compilation
Assign nodes
Synchronization Mode
Loading
Execution / Pause
Reset
Open a Model
In the Main Control window, the Open Model button
allows user to open the model. Right-click button is used to
open a recently used model. Simulink, System Build &
EMTP models can be opened. When a model is open, its
path will appear in the top display. Opening of a Simulink
model using RT-LAB [10] is shown in Fig. 11.
Edit a Model
In the Main Control window, the Edit button allows user to
edit Simulink model [10] using MATLAB. Simulink model
consists of Master and Console subsystems which are
shown in Fig. 12.
Regroup into Subsystems
In a Simulink model that is to be used with RT-LAB, no
mathematical content can be found in the top-level of the
model. Therefore, subsystems are needed. The user must
add a prefix to all the top-level subsystems to allow RTLAB [1–16] to manage them. There are 3 types of subsystems. Each subsystem is computed on a different computation node in Opal-RT’s hardware. No Goto/From tags
are allowed between top-level subsystems to exchange
data. Only ‘‘wires’’. Regroup into sub-systems is given in
Fig. 13.
SM Master Subsystem
•
•
•
Prefix Identifier: SM_
Number of SM subsystems allowed in a model: 1
(always)
Content: All the computational elements of the model,
the mathematical operations, the I/O blocks, the signal
generators, etc.
J. Inst. Eng. India Ser. B
•
Note: This is the main subsystem and every model must
have one SM subsystem. SM Master Subsystem is
shown in Fig. 14.
SS Slave Subsystem
•
•
•
•
Prefix Identifier: SS_
Number of SS subsystems allowed in a model: Any
(From 0 to…)
Content: All the computational elements of the model,
the mathematical operations, the I/O blocks, the signal
generators, etc.
Note: This subsystem is needed only if the computational elements must be distributed across multiple
nodes. Remember that one subsystem = one computation node for the SM and SS.
Add the OpComm Block
RT-LAB uses OpComm blocks to enable and save communication setup information. This includes both communication between the console and the computation nodes
and communication between the multiple computation
nodes in a distributed simulation scenario. All subsystems
inputs must first go through an OpComm block before any
operations can be done on the signals they are associated
with. The OpComm block must be inserted after the subsystems creation and renaming. In general, only one OpComm block must be used even if there are multiple inputs
in one subsystem. Double-click on the block to select the
number of inputs required. OpComm block is shown in
Fig. 15. SC Console Subsystem is shown in Fig. 16.
Set the Real-Time Parameters
SC Console Subsystem
•
•
•
•
Prefix Identifier: SC_
Number of SC subsystems allowed in a model: 0 or 1
Content: All user interface blocks (scopes, displays,
switches, controls, etc)
Note: This is the only subsystem that will be available
to us during execution. It enables us to interact with the
system while it is running. The console runs asynchronously from the other subsystems. It is also the only
subsystem that is not linked to a computation node
(core). Therefore, there should be no signal generation
or important mathematical operations included in this
subsystem.
A real-time model can only run in Fixed-Step mode as real
time is fixed-step. The Fixed-Step size (fundamental sample time) must be chosen carefully regarding the needs of
the simulation, the dynamics of the model and must take in
account the software/hardware capability. A typical
mechanical application may run around 1ms while a typical
electrical system may run around 50ls.
In most cases, we want the console (SC) to run indefinitely. In order to do so, the simulation’s stop time must be
set to ‘‘inf’’. With this parameter set, the console will be
stopped only when us decides to reset his model. This
parameter does not apply to the simulation duration; only
to the console. To develop a model in RT-LAB, target
Fig. 11 Opening of a Simulink model using RT-LAB
123
J. Inst. Eng. India Ser. B
Fig. 12 Simulink model consists of Master and Console sub-systems
Synchronization Mode
There are 4 synchronization modes available in RT-LAB:
(a) Simulation
(b) Software Synchronized
(c) Hardware Synchronized
(d) Simulation with low priority
Fig. 13 Regroup into sub-systems
platform should be set in Red hat mode this is shown in
Fig. 17.
The synchronization mode can be set at any time before
loading a model. After the loading step, the simulation mode
list will be disabled and the model must be reset if a simulation mode change is required. Hardware Synchronization of
Simulink model using RT-LAB is shown in Fig. 20.
Simulation
Compilation
In the Main Control window, the Compile button allows us
to compile the Simulink model.
Right-click button is used to select only specific steps of
the compilation. If for any reason us wants to stop the compilation while it is launched, the Compile button is changed to
‘‘Abort’’ and is available to stop the process. Compilation of a
Simulink model using RT-LAB is shown in Fig. 18.
Official Description: Free-run, as-fast-as-possible simulation on target. In this mode, no synchronization is done.
Target nodes in a distributed simulation are synchronized
with the communication link. The data exchanged depends
on the model’s data flow.
Practically: The model is not synchronized. The model
starts a new computation step when the first one is completed (the model runs as fast as possible). It can be
compared to the offline simulation done in Simulink.
Assign Nodes
Software Synchronized
In the Main Control window, the Assign Nodes button
allows us to link the model’s subsystems to the targets. The
list of available nodes is on the right side. ‘‘Target Info’’
will provide us very useful information about the target
selected, which is shown in Fig. 19.
123
Official Description: The model runs in real-time. In this
mode, the model is synchronized on the internal RTOS
timer. Only one computation node is synchronized when
executing a distributed simulation. Other subsystems are
J. Inst. Eng. India Ser. B
Fig. 14 Edition of Master sub-system
synchronized with the communication link. The data
exchanged depends on the model’s data flow.
Practically: Synchronization is done by the OS using the
CPU clock as a reference can be used to test some models
that has no Opal-RT’s I/Os. Can run some PCI I/Os such as
CAN-AC2, RS-232, ARINC A429 and computation on the
OP5110.
Fig. 15 Opcomm block
Hardware Synchronized
Official Description: The model runs in real-time. In this
mode, the model is synchronized on an external hardware
timer.
A specific block must be inserted in the model to specify
and configure where the external clock is located. Only one
computation node is synchronized when executing a distributed simulation. Other subsystems are synchronized
with the communication link. The data exchanged depends
on the model’s data flow.
Practically: This mode is used when Opal-RT’s I/Os are
driven by the model and some signals must physically be
inputted/outputted to/from the simulator. The I/O board
clock is used to synchronize the simulation.
Simulation with Low Priority (Rare)
Fig. 16 Edition of Console sub-system
Official Description: This mode works with Win32 target
only. It is the same as simulation but the computation
subsystem runs in lower priority. It is useful when the
simulation runs on the command station; it will let the CPU
resource to other applications.
123
J. Inst. Eng. India Ser. B
Fig. 17 Selection of a Red hat mode for Simulink model using RT-LAB
Fig. 18 Compilation of Simulink model using RT-LAB
Practically: Rarely used. It can be used to run a simulation in the background while working with other applications on the same computer.
time subsystem (SM or SS). Loading Simulink model and
opening of console block using RT-LAB is shown in Fig. 21
and automatic generated console block during Compilation
of Simulink model using RT-LAB is shown in Fig. 22.
Load
In the Main Control window, the Load button allows us to
load the Simulink model on the target(s). This is the last step
before executing the model. The console will open and be
ready for execution. There is one log window for each real-
123
Execution
In the Main Control window, the Execute button allows us
to execute the Simulink model. During execution, we can
J. Inst. Eng. India Ser. B
Fig. 19 Assigning of nodes for Simulink model using RT-LAB
Fig. 20 Hardware Synchronization of Simulink model using RT-LAB
change the controls found in the console and witness
changes displayed in scopes, displays, etc. We can pause or
reset the model at any time. Execution of Simulink model
using RT-LAB is shown in Fig. 23.
window. This will stop the acquisition (software & hardware) and the console will close.
Reset
•
•
•
•
When we want to stop definitely our model from running,
we must use the reset button found in the Main Control
Application Field
Electrical (Power Electronics & Power Systems)
Aerospace & Defence
Automotive
Academic & Research
123
J. Inst. Eng. India Ser. B
Real-time Implementation of Shunt Active Filter Model
Real-time implementation of Shunt active filter [2, 10]
model is shown in Fig. 24. It consists of
(a) Host computer
(b) Target (Real-time Simulator) and
(c)
Oscilloscope
In host computer, Edition of Simulink model; Model
compilation with RT-LAB and user inter face is done. In
target system, I/O and model execution process is done and
results are displayed in CRO. In Fig. 24, CRO displays
four waveforms, first waveform is Load Current (or Source
Fig. 21 Loading Simulink model and opening console block using RT-LAB
Fig. 22 Automatic generated console block during Compilation of Simulink model using RT-LAB
123
J. Inst. Eng. India Ser. B
Fig. 23 Execution of Simulink model using RT-LAB
Fig. 24 Real-time implementation of Shunt active filter control
strategies using OPAL – RT
current before filtering); second waveform is Filter Current
(Compensation Current); third waveform is Source current
after filtering and finally fourth waveform is DC-Link
voltage.
Conclusion
Modern power systems continue to evolve requiring constant evaluation of new constraints. Major studies will
require the use of very fast, flexible and scalable real-time
simulators. This paper has introduced a specific class of
digital simulator known as a real-time simulator. By
answering the questions ‘‘what is real-time simulation’’,
‘‘why is it needed’’ and ‘‘How it works’’.
The latest trend in real-time simulation consists of
exporting simulation models to FPGA. This approach has
many advantages. First, computation time within each time
step is almost independent of system size because of the
parallel nature of FPGAs. Second, overruns cannot occur
once the model is running and timing constrains are met.
Last but most importantly, the simulation time-step can be
very small, in the order of 250 nanoseconds. There are still
limitations on model size since the number of gates is
limited in FPGAs. However, this technique holds promise.
Now a days every researcher want to develop his/her model
in real-time. The applications of RT-LAB are in Electrical
(Power Electronics & Power Systems), Aerospace &
Defence, Automotive, and Academic & Research. In this
article, the necessary steps involved for implementation of
a model from MATLAB to REAL-TIME are provided in
detail.
References
1. RT-LAB Professional [online], available: http://www.opal-rt.
com/product/rt-lab-professional
2. S. Mikkili, A.K. Panda, FLC based shunt active filter (p–q and
Id–Iq) control strategies for mitigation of harmonics with different fuzzy MFs using MATLAB and real-time digital simulator.
Int. J. Electr. Power Energy Syst. Elsevier 47, 313–336 (2013)
3. J. Bélanger, P. Venne, J.N. Paquin, The What, Where and Why of
Real-Time Simulation, pp. 37–49
4. S. Abourida, C. Dufour, J. Bélanger, V. Lapointe, Real-Time,
PC-Based Simulator of Electric Systems and Drives, International Conference on Power Systems Transients—IPST in New
Orleans, USA, 2003
123
J. Inst. Eng. India Ser. B
5. P. Kotsampopoulos, A. Kapetanaki, G. Messinis, V. Kleftakis, N.
Hatziargyriou, A PHIL facility for Microgrids. Int. J. Distrib.
Energy Resour. 9(1), 71–86 (2013)
6. V.Q. Do, J.-C. Soumagne, G. Sybille, G. Turmel, P. Giroux, G.
Cloutier, S. Poulin, Hypersim, an integrated real-time simulator
for power networks and control systems (ICDS’99, Vasteras,
1999), pp. 1–6
7. M. Papini, P. Baracos, Real-time simulation, control and HIL
with COTS computing clusters, AIAA Modeling and Simulation
Technologies Conference, Denver, CO, Aug, 2001
8. M. Matar, R. Iravani, FPGA implementation of the power electronic converter model for real-time simulation of electromagnetic transients. IEEE Trans. Power Deliv. 25(2), 852–860 (2010)
9. J.A. Hollman, J.R. Marti, Real time network simulation with PCcluster. IEEE Trans. Power Syst. 18(2), 563–569 (2008)
10. Suresh Mikkili, A.K. Panda, Types-1 and -2 fuzzy logic controllers-based shunt active filter Id–Iq control strategy with different fuzzy membership functions for power quality
improvement using RTDS hardware. IET Power Electron. 6(4),
818–833 (2013)
11. I. Etxeberria-Otadui, V. Manzo, S. Bacha, F. Baltes, Generalized
average modelling of FACTS for real time simulation in ARENE.
IEEE 28th Annual Conference of the Industrial Electronics
Society (IECON 02). 2, 864–869 (2002)
12. J. Bélanger, V. Lapointe, C. Dufour, and L. Schoen, eMEGAsim:
An Open High-Performance Distributed Real-Time Power Grid
Simulator. Architecture and specification, presented at the International Conference on Power Systems (ICPS’07), Bangalore,
India, Dec 12–14, 2007
13. C. Dufour, G. Dumur, J.-N. Paquin, J. Belanger, A multicore pcbased simulator for the hardware-in-the-loop testing of modern
train and ship traction systems, in the 13th Power Electronics and
Motion Control Conference (EPE-PEMC 2008), Poznan, Poland,
pp. 1475–1480, 1–3 Sept 2008
14. G. Sybille, H. Le-Huy, Digital simulation of power systems and
power electronics using the MATLAB/Simulink Power System
123
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
Block set, in IEEE Power Engineering Society Winter Meeting,
Singapore. 4, 2973–2981 (2000)
D. Auger, Programmable hardware systems using model-based
design, in 2008 IET and Electronics Weekly Conference on
Programmable Hardware Systems, London, 1–12 (2008)
J.-F. Cécile, L. Schoen, V. Lapointe, A. Abreu, and J. Bélanger.
www.opal-rt.com. [Online] http://www.opalrt.com/technicaldocument/distributed-real-time frame work dynamic management heterogeneous co-simulations, (2006)
E. Gordon Moore Lithography and the future of Moore’s law,
Proc. SPIE 2440, Optical/Laser Microlithography VIII, 2 (May
26, 1995); doi:10.1117/12.209244
L.B. Kish, End of Moore’s law: thermal (noise) death of integration in micro and nano electronics. Phys. Lett. A 305(3–4),
144–149 (2002)
L. Vanfretti, et al., SmarTS Lab A Laboratory for Developing
Applications for WAMPAC Systems. San Diego, USA: IEEE
Power and Energy Society, 2012 General Meeting, July 2012
P. Kotsampopoulos, N. Hatziargyriou, B. Bletterie, G. Lauss, T.
Strasser, Introduction of advanced testing procedures including
PHIL for DG providing ancillary services, 39th Annual Conference of the IEEE Industrial Electronics Society IECON 2013,
Vienna, Nov 2013
V. A. Papaspiliotopoulos, D. E. Karalexis, G. N. Korres,
Description, setting and secondary testing of a digital protective
relaying system, 12th International Conference on Developments
in Power System Protection (DPSP), Copenhagen, Apr 2014
M. Matar, R. Iravani, Massively parallel implementation of AC
machine models for FPGA-based real-time simulation of electromagnetic transients. IEEE Trans. Power Deliv. 26, 830–840
(2011)
http://emtp.com
https://hvdc.ca/pscad/
http://www.mathworks.in/products/matlab/