ŠKODA ELECTRIC is a leading world manufacturer of electric drive and traction motors for trolleybuses, tramways, locomotives, suburban train units for metro areas, and mine cars.
Testing the Electric Drive
An electric drive includes an electrical control unit (ECU) with its own software that has to be tested. Several methods are used when testing ECUs. One potential method of testing involves connecting the ECU directly to a controlled system to run single tests. This approach may lead to several problems. For example, if a controlled system is a motor with hundreds of kilowatts of power, it is necessary to have the appropriate power sources and space for placing test stands. All of these things are expensive and time-consuming to prepare. The aforementioned issues prompted us to implement a new approach to testing. The new approach involved replacing the controlled system with a model.
Description of the Controlled System
The electrical drive consists of a motor—in this case, an induction machine (IM), an inverter, and an ECU that controls the output voltage of the convertor via PWM. A simple diagram demonstrating how this functions is shown in Figure 1. Input signals to the ECU are phase currents from the IM and DC link voltage that signal the rotation speed sensor. All of these signals are used in the control software running in the ECU. The outputs of the ECU are signals for transistors in the inverter (PWM). The ECU is able to create logic I/O signals, and it communicates with other ECUs and PCs via a controller area network (CAN) and RS232.
Description of the Simulator Architecture
As mentioned, two versions of the simulator were created—one based on CompactRIO and one based on the NI PXI Express platform. The PXI Express simulator has additional functionality, but the main architecture (Figure 2) of both simulators is similar. The mathematical model of the controlled system runs on an FPGA. The FPGA implements input and output functionalities, providing a connection between the ECU and the simulator. The real-time target provides communication between a host PC and the simulator (settings models and constants). The communication is performed via network streams and shared variables.
A Simulator Based on PXI Express
Our goal was to test the ECU with the same version of software used on a locomotive without any conditional compilation for the testing. To meet this requirement, we needed to connect the ECU to the complete control system. This task increased the amount of demand put on the simulator. We had to create an interface between the ŠKODA Control System (ŠCS) and NI hardware. We used the interface to adjust signals because the ŠCS used special signals common in traction techniques such as currents, higher voltage of logical levels, and optical.
The PXI Express hardware was chosen for the complete simulation of the system involving all interfaces. The computing core was the same as the one used for the CompactRIO simulator—with the same software modules written using LabVIEW FPGA. Figure 3 shows an overall view of the PXI Express simulator. The computing heart of the system is the NI PXI-7854R R Series multifunction reconfigurable I/O (RIO) module. The chassis contains other modules, including CAN, fast digital I/O (DIO), power sources, and additional analog outputs. The power source module is used for setting appropriate logic level inputs for the ŠCS. The CAN module is used for communicating with the ŠCS. The analog output module and the fast DIO module are used for special test cases.
Simulator Based on CompactRIO
The simulator based on CompactRIO is a lighter version. It has the same computation model on the FPGA as the PXI Express version. The simulator is designed to be directly connected to the ECU (Figure 4), unlike the PXI Express version. It is an early prototype of a drive simulator made by ŠKODA. Model creation procedures were validated using this version and were transferred to the PXI Express platform for the next step. The advantages of this version include portability, small size, and the low cost of the required hardware.
Creating a Model Based on LabVIEW FPGA
This part was the biggest challenge of the whole project. The process of developing real-time models on an FPGA places higher demands on developers. On an FPGA platform, it is not possible to use simulation tools for creating a model. The inputs of a development process are differential equations that are processed by an appropriate numerical method of solving differential equations. The system of numerical equations is then transferred to the FPGA platform. It is important to remember that all operations are computed in fixed-point-arithmetic (FXP). It can be applied with advantage functions from a pallet of high-throughput math functions for computing operations.
The implementation of a numerical mathematical model in FXP arithmetic begins with the co-simulation of the simulated system. Co-simulation is used to verify the FXP model on the FPGA. As mentioned, the FPGA model computes in the FXP. Results of its computation are heavily dependent on a bit precision of partial operations. This is why it is so important to validate the results.
The LabVIEW Control Design and Simulation Module was used as a co-simulation tool. The co-simulation was performed in the following way: the FXP model and a Simulation Loop were called in one VI. A model of the same system on an FPGA was created in the Simulation Loop developed with the LabVIEW Control Design and Simulation Module. The option of calling an FPGA VI and Simulation Loops is really useful for developers. The deviations between the models are easy to view, and it is possible to make any necessary adjustments in the LabVIEW code. The VIs representing the FPGA model are called in the same VI with a Simulation Loop. This feature of LabVIEW helps developers because any numerical difference between the models is immediately visible, and it is possible to adjust the necessary parameters.
Model in an FPGA Versus a Model Using the LabVIEW Control Design and Simulation Module and a Real-Time Target
A significant advantage of the FPGA models is the possibility to achieve a short time-step of the simulation. A drawback of the short time-step is that it involves a more complicated process of model development.
The model created in the LabVIEW Control Design and Simulation Module and run on a real-time target has its advantages as well. It is difficult to achieve the same time-steps as on an FPGA, but the development process is significantly shortened. The model is created connecting mathematical blocks, and it is not necessary to write the numerical method manually. Another advantage is that all operations are processed in double format (64-bit floating-point).
Benefits of the Simulators on LabVIEW FPGA Platform
The connection between the LabVIEW Control Design and Simulation Module and the LabVIEW FPGA Module functions helped us create and validate an accurate model of the main drive of a locomotive. The simulators helped us evaluate new algorithms that control large drives and give our developers more time to test software. We are currently in the early stages, and we have plenty of ideas on how to further improve the simulator. The simulator project was first used in the single electric RegioPanther unit (Figure 5) by testing and validating control software.
ŠKODA ELECTRIC a.s.