I want to paraphrasse this The OPAL RT system The OPAL RT system consists of two

Question

I want to paraphrasse this

The OPAL RT system

The OPAL RT system consists of two parts, the host computer and the real-time simulator. The host computer contains the software architecture in the form of RT-Lab. RT-Lab allows the user to import Simulink models, edit and then transform them to a real-time application via automatic code generation. The real-time simulator forms the hardware architecture of the system, which is responsible of the real-time execution of the Simulink model. Communication between the host and the real-time simulator happens via TCP/IP protocols. Each of the software and hardware architectures will be discussed further in the following subsections.

Hardware architecture: OP4510

OP4510 simulator, shown in Figure 1.5, was used in this project. The OP4510 simulator is equipped with the latest generation of Intel Xeon four-core processors and a powerful Xilinx Kintex 7 FPGA. Co-simulation between FPGA and CPU is also possible, thanks to a fast PCIexpress link exchanging data and signals between devices [10]. Simulation time-step of the FPGA can go to as low as 160ns making it possible to simulate high frequency converters accurately. OP4510 contains 16 Analog I/O channels and 32 Digital I/O.

Transforming a Simulink Model to a Real-Time Simulation

Once the Simulink model has been validated in offline, the next step is to import the model file into RT-Lab. Once imported, any further modifications to the model should only happen through RT-Lab. Alternatively, the user can build the entire model from scratch in RT-Lab environment.

1.3.3.1 Grouping the model

Simulink models in RT-Lab must be grouped into subsystems. Each subsystem is implemented at a certain target in the OPAL RT system. The three types of subsystems are: Console, Master and Slave. In any model, one console and one master subsystem should exist. Addition of a slave subsystem is optional. The console subsystem runs in the host computer, while the master and slave subsystems run in the real-time simulator in assigned computation nodes.

Console Subsystem: The console is the only subsystem that can be altered during the real-time simulation. Typically, it contains the parameters that the user wishes to change on the fly such as reference speed, input voltage, switching frequency etc. Time-varying signals cannot be placed in the console. Any outputs or readings, such as a voltage waveform or the RMS value of a current, that need to be observed during the simulation are also displayed in the console. Figure 1.8 shows a console subsystem with variable parameters. It contains parameters that the user can modify on the fly including modulation index, modulating frequency, carrier frequency in addition to a manual switch to control the delivery of the gating signals

Master Subsystem: The master subsystem contains the computational blocks of the model, mathematical operations, comparative elements, varying signals, I/O blocks etc. However, none of these elements can be adjusted while the simulation is running. Therefore, the user has to know which elements are to be varied on the fly and place them in the console. For example, if the user wishes to change the modulating frequency on the fly, then the frequency must be entered in the console and the modulating signal shall be generated manually in the master. If the signal generator block is used, then it will not be possible to adjust the frequency during the simulation. The master subsystem is executed on a CPU core in the real-time simulator

The eHS solver

OPAL RT developed a solver called eHS which allows the user to skip the programming step by using a block in their eFPGASIM Library. The user has only to build the circuit of the power converter in any circuit editor such as Simulink or PSIM and then introduce the eHS block to transfer the power converter onto the FPGA.

The eHS solver runs at the time-step of the FPGA, which varies depending on the size and complexity of the model being implemented on the FPGA. The circuit of the power converter is built in a different Simulink file. This file is never run, but is used as a reference to generate the equivalent converter on the FPGA.

Data exchange between the CPU and the FPGA happens at the time-step of the CPU as shown in Figure 1.11. This can be problematic if the gating signals are generated on the CPU for high frequency converters. The CPU time-step might not be short enough to accurately sample the gating signals. Therefore, in such cases, it is recommended to avoid using the conventional sine-triangle wave comparison blocks available from Simulink library. Instead, one might use blocks from RT-Events library as the RTE signals are of a higher time resolution which allows them to be sampled at eHS time-step.

Explanation / Answer

The OPAL-RT Hardware-in-loop simulation platform:

The OPAL-RT platform consists of a Host and Target platform. All the mathamaticial models are build in the Host system and upon verification and validation in offline mode they are ported on to the real time simulation platform for conducting the simulation and therby validating the performance of subsystems connected to the Target platform. Basically these type of platforms are used for conducting HARDWARE-IN-LOOP-SIMULATIONS.

The OPAL-RT is an effective platform for developing and testing of complex realtime embedded system.This system converts the mathamatical models developed (usually MATLAB/SIMULINK) into real time code by using a realtime software.

THE HOST : Normally the HOST PC is a high end workstation which consists of a several software packages used for modelling.For OPAL-RT system MATLAB/SIMULINK is the prefered one . Once the mathamatical model is ready it is validated in the offline mode . For porting onto the real time platform the model need to be configured in the MASTER-SLAVE-CONSOLE configuration. The main process of the algorithm / signals etc are contained in the master block and part of the algorithm /signals etc can be modeled as slave block , the slave block is not necessary . The console block consists of scopes and data viewers where the data or graphs can be viewed online.

Once the model is configured then next step is to porting on to the realtime simulation platform i...e the target PC

TARGET PLATFORM : The target platform consists of a processor with RTOS (real time operating sysyem) and interfaces such as 1553B,A/D and D/A ,CAN,GPIB ,RS-422/232/485 communication protocols. The offline model is converted into realtime by Realtime workshop.Then the model can be assigned processor nodes which are in the target platform for increasing the computational speed . Initially any subsystem can be modelled and later the real hardware can be connected through any of the communication protocols mentioned above to validate the system . one such example is the validation of a motor system. We can have multiple targets for accomodating communication interfaces but the target to target communication should be through IEEE 1394 protocol.

OP4510 simulator was used in this project. The OP4510 simulator is equipped with the latest generation of Intel Xeon four-core processors and a powerful Xilinx Kintex 7 FPGA. Co-simulation between FPGA and CPU is also possible, . Simulation time-step of the FPGA can go to as low as 160ns making it possible to simulate high frequency converters accurately. OP4510 contains 16 Analog I/O channels and 32 Digital I/O.

OPAL RT developed a solver called eHS which allows the user to skip the programming step by using a block in their eFPGASIM Library. The user has only to build the circuit of the power converter in any circuit editor such as Simulink or PSIM and then introduce the eHS block to transfer the power converter onto the FPGA.

The eHS solver runs at the time-step of the FPGA, which varies depending on the size and complexity of the model being implemented on the FPGA. The circuit of the power converter is built in a different Simulink file. This file is never run, but is used as a reference to generate the equivalent converter on the FPGA.

Data exchange between the CPU and the FPGA happens at the time-step of the CPU . This can be problematic if the gating signals are generated on the CPU for high frequency converters. The CPU time-step might not be short enough to accurately sample the gating signals. Therefore, in such cases, it is recommended to avoid using the conventional sine-triangle wave comparison blocks available from Simulink library. Instead, one might use blocks from RT-Events library as the RTE signals are of a higher time resolution which allows them to be sampled at eHS time-step.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.