Modeling and Real-Time Simulation of Induction Motor Using RT-LAB

Received Mar 18, 2018 Revised Aug 12, 2018 Accepted Sep 8, 2018 This paper presents the modeling and real-time simulation of an induction motor. The RTLAB simulation software enables the parallel simulation of power drives and electric circuits on clusters of a PC running QNX or RTLinux operating systems at sample time below 10 μs. Using standard Simulink models including SimPowerSystems models, RT-LAB build computation and communication tasks are necessary to make parallel simulation of electrical systems. The code generated by the Real-Time Workshop of RTLAB is linked to the OP5600 digital real-time simulator. A case study example of real-time simulation of an induction motor system is presented.This paper discusses methods to overcome the challenges of realtime simulation of an induction motor system synchronizing with a real-time clock. Keyword:


INTRODUCTION
The induction motor is used in many industrial sectors as the main element of converting electrical energy into a mechanical drive because of its low cost, robustness, high degree of reliability and good powerto-weight ratio. Due to its feature sand high applicability in industrial fields, studies for higher efficiency have always been demanded.
As testing and validation of induction motor has become more and more important in the design and engineering process, the need for constant improvement of component modeling and for increasing the speed of prototyping the system has also become greater. Conventionally, validation of a induction motor was done by non-real-time simulation of the concept at early stage in the design, and by testing the system once the design is implemented. But this method has some major drawbacks:first, the leap in the design process, from off-line simulation to real prototype is so wide that it is prone to many troubles and problems related to the integration at once of different modules; second, the off-line, non-real-time, simulation may become tediously long for any moderately complex system, especially for motor drives with switching power electronics [1].
Real-time simulation of induction motor is a valuable tool for development and testing of control.Two situations can arise depending on the time required by the simulation platform to complete the computation of state outputs for each time-step ( Figure 1): 1) if the execution time, Te, for the simulation of the system is shorter or equal to the selected time-step, the simulation is considered to be real-time (Figure 1 (a)); and 2) if Te is greater than its time-step size for one or more time-steps, overruns occur and the simulation is considered as non-real-time or offline. In the latter case, either the time-step can be increased or the system model can be simplified to run it in Real-Time [2]- [5]. This paper presents the modeling and real-time simulation of an induction motor in a power system. Matlab/Simulink software is used to develop the induction motor model. The generated code of the Simulink model is linked to the OP5600 digital real-time simulator in order to simulate the induction motor.
The paper is divided into six sections, the hardware and software configuration of RT-LAB is presented in section 2, section 3 shows the mathematical model of the induction motor, a detailed modeling of an induction motor in RT-LAB is shown in secion 4. Section 5 illustrates the real time simulation results using RT-LAB, finally the conclusion is drawn in section 6.

RT-LAB CONFIGURATION
RT-LAB is an industrial-grade software package for engineers who use mathematical block diagrams for simulation, control and related applications. The software use popular programming tools such as MATLAB/Simulink and works with viewers such as Lab VIEW and programming languages including C++. RT-LAB allows the user to readily convert Simulink Models to real-time simulations, via Real-Time workshop (RTW) and run them over one or more PC processors [1], [4]- [6].

Hardware Configuration
RT-LAB software runs on a hardware configuration consisting of command station (host node), target nodes, the communication links (real-time and Ethernet), and the I/O boards [7].

The Command Station
The command station is a PC workstation that operates under Windows, and serves as the user interface. The command station allows users to: edit and modify models; see model data; run the original model under its simulation software (Simulink, SystemBuild, etc.); generate and separate code; and control the simulator's Go/Stop sequences [7].

Target nodes
The target nodes are real-time processing and communication computers that use commercial processors interconnected by an Ethernet adapter. The command node and target node are commercial PC's with different operating system. A PCI-626 I/O card (from Sensory Company Inc.) is used which satisfies all I/O requirements. Moreover, it is supported by RT-Linux real-time operating system. In this configuration the only communication link used is between the target and command station using Ethernet communication [7].

Software Configuration
For the above configuration of RT-Lab, the software in the command station (console) is Windows, and the simulation software is Matlab-Simulink to program the simulation and control tasks. The simulation program is coded into C code in the consol unit and transferred to the target node, which has linux operating system. The target unit compiles and executes the C code file in parallel with the simulation program in the console. The data is transferred on-line between the target and console throw communication Ethernet. In the consol station, the program is written in two main blocks (Consol-Master).
SM_: master subsystem. There is always one and only one master subsystem inside a model.it contains the computational elements of the model. SC_: console subsystem. The console subsystem is the subsystem operating on the command station that enables you to interact with the system .it contains all the simulink/systembuild blocks related to acquiring and viewing data (scope, manual switch, to workspace-type blocks, etc).the blocks you need, whether it is during or after the execution of the real-time model, must be included in the console subsystem.the console runs asynchronously from the other subsystems.note that there can only be one console per model [10]- [12].

Opcomm Communication Blocks
Once the model is grouped into console and computation subsystems, special blocks called opcomm blocks must be inserted into the subsystems.these are simple feed-through blocks that intercept all incoming signals before sending them to computation blocks within a given subsystem.opcomm blocks serve several purposes. When a simulation model runs in the RT-LAB environment,all connections between the main subsystems(SC_,SM_,or SS_)are replaced by hardware communication links .for communication between real-time target nodes(SM_ and SS_)RT-LAB uses adesignated real-time link.for communication between the console(SC_)and the real-time nodes(SM_ or SS_)RT-LAB uses TCP/IP.
Because of these communication links between nodes, the simulation may not run the same way in simulink or systemBuild as in RT-LAB. In RT-LAB, a computation subsystem waits for reception of all signals before it is able to start calculating.in Simulink and SystemBuild,on the other hand,computations performed on a signal start as soom as the signal is available,OpComm blocks emulate the behavior of the system as it is run in RT-LAB [10].

Recording Data with OpWriteFile
To obtain all data for any particular signal, use the OpWriteFile block data recorded with this block is stored on the target real-time node's hard drive.the data file is automatically transferred to the command station when the model is reset [10].

EXtreme High Performance (XHP) Mode
The XHP mode is a means for the real-time operating system to disable interrupts.this is done on a per-subsystem (thus per-CPU) basic.not allowing interrupts prevents process switching which removes latencies time for additional computation in the same time slice. The XHP mode is aimed at real-time applications of a given base sample time that cause overruns (overflow their allowed time-step for Int J Pow Elec & Dri Syst ISSN: 2088-8694  computation) while running in RT-LAB in the standard mode. In XHP mode, the model waits in an empty loop for its next scheduled step.the next model step is then computed.
In this mode, we use the CPU counter as our time reference.because this counter operates at the CPU's frequency, it offers a very high resolution, even for step-size in the microsecond range.because the counter resides on the CPU and reading its value is done within one CPU cycle, this operation introduces almost no latency [10].

INDUCTION MOTOR MODELING
The mathematical models of induction motor in the park frame are written as follows [13]- [19].
The stator and rotor fluxes are related to the current by: ϕ sd = L s . I sd + L m . I rd ϕ sq = L s . I sq + L m . I rq ϕ rd = L s . I rd + L m . I sd ϕ rq = L s . I rq + L m . I sq The stator and rotor angular velocities are linked by the following relation: The equations of mechanical and electromagnetic torques are: where: R s is stator resistance, R r is rotor resistance, L s and L r are respectively stator and rotor inductance L m the mutual inductance, ϕ sd and ϕ sq are the direct and quadrature stator flux, ϕ rd and ϕ rq are the direct and quadrature rotor flux, I sd and I sq are the direct and quadrature stator current, I rd and I rq are the direct and quadrature rotor current, P is the number of pair poles, W s and W r are the asynchronous and rotor angular frequency, T e and T m are the electromagnetique and mechanical torque, and F is the viscosity coefficient. To get a model state in terms of the rotor sizes ( I rd , I rq , ϕ rd , ϕ rq ),We express the stator sizes ( I sd , I sq , ϕ sd , ϕ sq ) in terms of rotor sizes [13].

MODELING INDUCTION MOTOR IN RT-LAB
In RT-LAB all top-level subsystems must be named with a prefix identifying their function .The prefixes are: SC_ for consol sybsystem and SM_ for master subsystem.
Depending on the type of data acquisition, we propose two RT-LAB models; in the first model the data transfer between the target node and the console machine is during the simulation task, however in the second one, the transfer will be done after the end of simulation performed.

Data Acquisition during Simulation
In this case RT-LAB enables signal acquisition from a real-time target during simulation using OpComm block for synchronization between target node and console. We use OpComm block in master and console subsystems; the consol sends the signal of Resistant Torque to the master subsystem and the latter sends signals of Isa,Isb,Isc,Ids,Iqs,Qrd,Qsd,Ce,Speed to the console subsystem.

Data Acquisition after the End of Simulation
In this case, we use OpWriteFile block for recording all data in the target node's hard disk, and when the simulation ends, the target node sends recorded data in matefile format to the console.  The OpComm block is not used in the console subsystem.

RESULTS AND ANALYSIS
All the simulations are carried out on an induction motor whose parameters are listed in the Table 1. We applied a resistant torque to the induction motor at time 2.0 s to 3.0 s. Figure 9 shows the speed response in real-time simulation in different times steps.Through the red curve we note that there is no data 1483 loss when we use 30 µs as time-step, The response is the same as in offline simulation.In the second case, when we use 20 µs as time-step it is shown clearly in the zoom graph that it started to loss data, However in the last case when we use 10 µs as time-step we observe that data was considerably lost and the signal of the speed has completely changed.

Figure 9. Speed respone of induction motor in different time-steps
We conclude that the acquisition data from the target node during simulation leads to the data loss if the time-step is small then 20 µs, because TCP/IP is relatively slow compared with most real-time systems like fireWire-type network. Figure 10 shows the speed response in second proposal where OpWriteFile block is used. In this case the target node does not send data to the console while the simulation is running. After simulation ends, the target node sends the recorded data in hard disque of target as mat file content all signal information to the console. We note from the curve that although very small time-step is used compared to the previous experiment, no data loss occurred just as in offline simulation. Later, a simulation attempt with time-step as 0,1 µs caused overruns and the simulator showed the following error message

CONCLUSION
In this paper we proposed two RT-LAB models for real-time simulation of the induction motor, in the first, model, data acquisition was during simulation, however in the second model, data acquisition was after the end of simulation, The simulation results show that in the first model we got data loss when we use small time-step because TCP/IP is relatively slow compared with real-time systems like fireWire-type network. However in the second model no data loss occured.