HARDWARE-IN-THE-LOOP SIMULATION FOR ELECTRIC …revue.elth.pub.ro/upload/271189Art11_...

HARDWARE-IN-THE-LOOP SIMULATION FOR ELECTRIC POWERTRAINS

CĂTĂLIN VASILIU 1, NICOLAE VASILE 1

Key words: Real-time simulation, Hardware-in-the-loop (HIL), Electric vehicle, AMESim, LabVIEW.

HIL has been used extensively mainly in the aerospace industry and military applications due to the high cost needed for obtaining the required computing power. Recent advances in electronics and computer science have proven that a cost-effective solution for running complex systems simulation is available, so widening the field of applications for HIL testing. This paper presents the basic tools and principles used in the development of such a platform, which enable the study of electrical powertrains, especially those designed for road vehicles. A general-purpose test rig was developed, whose preliminary structure is briefly described.

1. REAL-TIME SYSTEMS AND HIL TESTING

Computer simulation of mathematical equations has a long history and a well-established place in the engineering design. After computing machines became powerful enough to be able to control real equipment, a new field of engineering emerged. At the beginning, processing units were based on analogue circuitry and ran faster than the systems being controlled. The command signal rates were limited in order to adapt them to the processes’ evolution rate. With the advent of digital computing systems, the controllers were commonly slower than the supervised plants. The notion of real-time emerged, referring to the computer’s generic reaction time relation with the process that it controls.

It is hard to define what a real-time system is, given the variety of computing platforms and applications that exist today. Two main characteristics are common to all real-time systems and could define them: a) are bounded to a process that evolves at its natural rate; b) respond to inputs in an absolutely determined manner. The core of every real-time system is a computing platform, which is composed of a hardware part and a software one. The software can be further split into two entities: the operating system and the user-defined programs. A real-time operating system is the brain that manages every aspect of the system. It is usually generic,

“Politehnica” University, Faculty of Electric Engineering of Bucharest Rev. Roum. Sci. Techn. – Électrotechn. et Énerg., 57, 2, p. 212–221, Bucarest, 2012

2 Hardware-in-the-loop simulation for electric powertrains 213

meaning that the same basic functionality can be ported to multiple platforms. Users can develop custom programs that implement specific functions using low level routines hardcoded into a kernel; the advantage is that the probability of malfunction is decreased dramatically, since the hard-tested kernel takes care of the resource management.

Common users for real-time systems are: satellites, military equipment, avionics, medical devices (non-invasive scanners), command and control for power plants (nuclear mostly), airbags and even mobile phones. Some of the used cases imply a strict no-error policy while others can tolerate occasional less-than-critical malfunctions. Based on the complexity and scale of the damage produced if the system fails, there are hard and soft real-time systems. However, this is not a proper classification since it lacks a measure for estimating the “softness” of a system. A soft real-time system is the one that runs as fast as the corresponding process, but either lacks a real-time operating system, or cannot guarantee the response time. For example, video decoding is said to be a real-time operation because it must present to the viewer a frame every 1/25th of a second, but if there is a problem and a few frames are skipped, then the error is not a critical one and the system’s functionality isn’t compromised. In case of a nuclear powerplant, even a generic error could generate a planetary disaster, so it is difficult to give a complete definition of a real-time system.

HIL started with ECU testing since it didn’t have moving parts or different subsystems, but later started to incorporate devices like shock absorbers, actuators, hydraulic systems, etc. This was the transition from model-in-the-loop or software-in-the-loop to system-wide testing and integration. This evolution shortened the development cycle with up to 75%. HIL systems can be regarded as hybrid or multi physics systems, because they involve components from different industries and integrate them into a fully functional mock-up of a real-life equipment.

2. SPECIFIC TOOLS USED IN THE DEVELOPMENT OF THE TEST BENCH

The goal of the design is to create a HIL system for testing electric powertrains of road vehicles. It should be able to test three main subsystems, but not all simultaneously: the electric motor, the controller for the car or the car model. The motor can be tested as it would be mounted on a full-scale vehicle model, and the car model would be driving a real load. This opens the way to a multitude of scenarios: tuning of the inverters, testing different geometries of the actual electric machine, car controller development, parameter tuning or model accuracy improvement. Although the same tests could be done on a real car, the time lost in getting the car ready, transporting systems in other locations or the

214 Cătălin Vasiliu, Nicolae Vasile 3

protection of confidential data, makes HIL testing a much more cost-effective alternative, and not only from an economical point of view. The HIL system includes a real-time operating system, data acquisition hardware, simulation software, actuators and, of course, the component being tested. The chosen software provides a multiphysics engineering platform that can handle almost any simulation task. In this work, AMESim from LMS International [1, 2], and LabVIEW [3] from National Instruments are used as basic software components.

AMESim is a simulation environment which, as many others, offers an advanced user interface for building representations of engineering systems. What sets it apart is that it is based on bond-graphs. Bond graphs are a manner to represent physical dynamical systems by modelling the energy transfer between components, based on the power conservation laws. Bond-graphs require that each component should have a real physical representation, and the greatest advantage is that by simply monitoring the power flow, enough information for validation is available. If other programs transmit information between blocks that has no intrinsic meaning, in AMESim every signal is has a physical unit and significance attached, so it is very hard to make mistakes.

The philosophy behind LabVIEW is that, by using standard blocks, one can built virtual instruments that resemble their actual counterpart, neglecting the build of all the subsystems that are common to specific categories. By integrating drivers and utilities for communicating with the hardware boards made by National Instruments, it offers a solid base for data acquisition and processing. With its real-time extension, LabVIEW can run complex HIL systems with minimal effort and hardware. It can import .dll files in a specific format, so that external models can be incorporated if necessary. The big advantage over other platforms is that it integrates everything needed in one package and doesn’t rely on third-party software. All other commercial real-time platforms use Matlab/Simulink to run in real-time, as dSPACE [5].

3. AMESIM SIMULATION ENVIRONMENT

AMESim has one more notable characteristic besides the one already described: it permits multi-domain engineering system simulation. A device can be modelled starting from the very basic structure up to whole systems of similar components (for example, the common-rail fuel injection system of a car). The graphical representations are ISO symbols or intuitive icons that facilitate the building of self-explanatory diagrams. There are many ways to analyse a system in order to get meaningful and accurate results. There is the possibility to run the system in order to get the equilibrium values for the state variables, use this values further for dynamic runs, hold the inputs constant and see if there are oscillations, change the time step or method, at any time during the simulation. There is also a


linear analysis mode which can pinpoint models that have an unusual behaviour. The energy-based solving method also can indicate where is the most CPU time consumed by counting the number of sub-model calls and calculating an activity index, which corresponds to the importance of a certain sub-model for the entire system. All these tools help to improve the solving of big systems in order to integrate them on the real-time platforms. When CPU time is an issue, every simplification counts and for the model of the car used this is very important, leading to better overall performance.

For creating real-time capable models, there are two restrictions that cannot be overlooked: the model must not contain implicit state variables; the model must be able to be integrated with a fixed-step solver, with a time step as close as possible to the one being used in the real-time system.

The solver built in AMESim uses a complex scheme of choosing the proper method to obtain the desired solution, making some systems run much faster than if using a fixed-step solver; however, variable-stepping isn’t implemented yet for real-time applications. There are intensive research programs that focus on faster integration designed for real-time platforms using variable-step solvers or other techniques as model-partitioning; it is possible that in the future versions of AMESim some of them to be applied.

From the car models that are offered as demos in AMESim, targeted at different aspects like handling, comfort, noise and vibration, thermal or fuel management, a suitable model was chosen, one that can be run with a fixed-step solver and that can offer an easy interpretation of the data. The offline version of the model, in which a speed reference generated from a static look-up table is generating a proportional command signal for an ideal torque source, is used as a starting point. The torque source is connected to a chassis model which serves as a general node to which all the other models are connected. Those models include aerodynamics, suspensions, brakes, tire and road models, reaching a total of over 50 state variables for the entire system. This model is adapted for HiL by replacing the controller and torque source with hardware components.

The big advantage of this example is that it can simulate the wind drag resistance and the road rolling resistance accurately and dynamically. These can be used as perturbations in the final system, making possible the identification of the desired parameters. Using the AMESim-LabVIEW interface, it is possible to run the AMESim model in LabVIEW, and then use the inputs and outputs on the virtual car to drive a virtual user interface and the real electric motors. In this setup, the AMESim model is solved using the fixed-step methods from LabVIEW and an intricate system of virtual instruments’ (VI’s) to step through the equations while maintaining stability altogether. From AMESim’s point of view, the procedure is simple enough to be done in a very short time.


4. NI’S PLATFORM FOR REAL-TIME SYSTEMS

Looking at the National Instruments Corporation’s platform, one can immediately notice the advantage of having a software and hardware solution that is flawlessly integrated. Following the trend from the 80’s, National Instruments developed standard blocks in software that are common between all types of measuring instruments and designed hardware that had the possibility to be configured for multiple types of applications, and by doing so they established the concept of Virtual Instrument. A virtual instrument is a computer-based program that behaves almost identical to a real one, but can be defined by the user as an interface and functionality. By making the software abstract enough, any hardware board can be connected to a defined set of algorithms that emulate a physical apparatus, thus making the system scalable. If more precision or more channels are needed, the hardware can be simply replaced, and by briefly modifying the software, one may have an upgraded instrument with the same functionality and aspect of a standard one, with a fraction of the cost.

With the introduction of the PXI-bus real-time controllers, a big step forward was made. Based on ×86 CPU (but not only), the controllers offer enough computing power for control applications in an industrial, rugged enclosure. They come equipped with two flavours of real-time OSes: ETS PharLap and WindRiver VxWorks [4]. Both are widespread and stable operating systems, which is a big advantage when designing critical real-time systems. VxWorks was, and is still used on spacecraft, industrial robots and many other high-end equipment. The user communicates with the real-time controller by means of LabVIEW, preventing tampering with the real-time system and providing easy access to development.

The mechanism by which an AMESim model gets to run in real time is the following:

– the model is analysed and perfected in AMESim; – the inputs and outputs that are needed are connected to a special block; – in LabVIEW, the .dll file created from the model is imported into a special

VI, which is basically an integrator; – the integrator and model are further included in a VI that manipulates the

data. Real-time operation is achieved by using timed loops with a single, unified

clock source, the OS taking care of the scheduling. The basic pattern of acquiring data – calculating control parameters – output command signals can be easily followed in LabVIEW.

In order to keep the real-time constraints, the VI (which is transformed in the end in an executable) that runs on the PXI is not allowed to have a user interface. That is to be designed and run on the host computer, communicating with the PXI through standard Ethernet bus. The PXI can be run headless if the deployed program allows that.


One of the goals of this work is to check if the controller can be prototyped and run on-site from a PXI system. LabVIEW offers many control engineering blocks besides raw access to measured data, the most important for this application being the PID controller and the Statechart Toolkit.

There are also third-party implementations of fuzzy or neural networks, but they are overly complicated and strictly entwined with the level of expertise of the author. The control scheme used for the car is simple enough to be implemented in a state chart: together with the real-time PID toolkit, control blocks can be assembled fast and further improved by running a suite of tests.

If the user desires, he can tackle the problem of designing the controller himself by using other tools as MathScriptRT, formula nodes, .dll files etc.

5. TEST BENCH STRUCTURE AND FUNCTIONAL DIAGRAM

To prove the capabilities of a HIL test bench, a scaled one has been designed, which can be upgraded to a full-scale one by changing the electric motors and drives. The size was chosen to be as small as possible because high-power machines are expensive and their power requirements are difficult to obtain in university laboratories. This doesn’t hinder the execution of the same experiments as for any other size. Because part of the models are defined in software, they can be adapted to any other application and, if there is a need to replace the electric motors, there should be only a change of parameters operated.

In Fig. 1 the simplified hardware structure of the testbench is being presented. Two brushless electrical motors are being driven by a Siemens converter, which is composed of a control unit and two inverters. Selected transducers transform electrical and mechanical variables into analogue signals that are fed into a PXI unit which runs the model and controller. The PXI unit is connected to an industrial computer that displays a graphical user interface.

In the vehicle dynamics offline model, the motor or engine are assimilated to a torque source. In order to scale the model, the measured torque is multiplied by a constant [5]. The maximum torque produced by a motor is generally related to its physical size rather than electrical parameters [6], so the chosen scaling rule is considered to be valid for the presented case. The angular velocity of a standard brushless motor, with a range extending up to 6 000 rpm, is suitable for a road vehicle, given a proper gearbox selection.

The final parameter that needs to be scaled is the motors’ inertia. Radial flux motors typically have low rotating inertias, so a cylindrical component, mounted along the main axle, helps increase the actual inertia of the system. It’s value has been chosen to be, togheter with the contributions from the two motors, the same as the combustion engine’s inertia divided by the car’s rotary inertia when running at maximum speed.


Fig. 1 – Test bench structure.

In order to simulate a powertrain, we need sources which have at their (real) output a controlled speed or torque. Electrical motors are the ideal candidate: they are easy to set up and have good dynamic characteristics for a given size. To simulate both the drive end and the load, two identical permanent magnet brushless motors were used. To minimize errors, a separate sensor for torque and speed was used. The inverters offer a good indication of those variables, but during transients the error can be too high to have a good feedback.

Fig. 2 – Control system’s layout.

There is a total of three controllers: one is running the PID, one that is running the simulation model, AME, (both in Fig. 2), and a separate one for the electrical variables data acquisition routines. This structure allows a faster operating speed and independent, easily- upgradeable, programs running on any of the three PXIs.


The drive used has the ability to recover the energy from the motors connected to it, a common DC bus which is controlled by a supervising unit. Similar architectures, but less flexible, were developed by different universities [7, 8] and companies like dSPACE [9, 10].

In order to test the control loop, a ramp signal has been generated for the speed reference, and the actual closed loop response, including motors and mathematical model, has been measured. From these preliminary tests it can be seen that the speed profile is being closely followed by the proposed control system (Fig. 3), as well as a good overall performance of the hybrid architecture. Since the ramp profile contains higher dynamics that those encountered in normal driving, it is expected that the performance of the control loop will increase when real-life speed profiles will be used. Numerical oscillations, visible in the constant speed regions have been observed, due to the small order of the integration method used (1st degree Euler) and the size of the timestep. Further optimisations will focus on reducing model complexity and improving the software architecture in order to obtain smaller timesteps and use more complex and accurate integration methods.

Fig. 3 – Experimental validation of the test bench.

This preliminary result leads to two notable conclusions: (a) the theoretical hybrid loop structure works as intended, and (b) the system should have no problem in reaching and maintaining the reference speed in any of the common test cycles (which is the basic measure of correct operation).

6. CONCLUSIONS

A HIL real-time system prototype was presented. The layout described represents a base common to many real-time applications, thus helping the reader


in understanding the key concepts of designing them. The capabilities of the platform encourage the development of a similar test bench for higher power electrical machines, with many possible industrial applications. By benchmarking the performance of the software, a proper scaling of future projects can be obtained. The research will continue with the design of test programs and the addition of necessary hardware as filters, amplifiers, relays etc. Also, extending and perfecting the virtual simulation models are other objectives.

Some special developments needed to match the hardware and software requirements are included in a Romanian Patent demand [11].

7. APPENDIX

Table 1

Nominal parameters of the motors

Parameter Value Unit Power 0.82 kW Torque 2.6 N m Speed 3000 rpm Max. Speed 6000 rpm Current 1.95 A Voltage 275 V Inertia 3.01*10-4 kg m2

Table 2

Transducer data

Type Prod. Code Characteristics

Torque HBM T20WN

5Nm nom., 10V analog output

Voltage LEM LV-20P

closed loop, 25kHz max, <0.2% linearity err.

Current LEM LTSR6-NP

closed loop, 100 kHz max, <0.1% linearity err.

Speed Siemens –

Abs. encoder EnDat 2048 pulses/rev

ACKNOWLEDGEMENTS

The work has been funded by the Sectorial Operational Programme Human Resources Development 2007-2013 of the Romanian Ministry of Labour, Family and Social Protection through the Financial Agreement POSDRU/6/1.5/S/19. The professional license of AMESim was granted by LMS Intl., Belgium, and the licence for LabVIEW RT was granted by National Instruments Corporation,U.S.A.

Received on 30 October 2010

REFERENCES

1. * * *, AMESim Reference Manual, Rev. 9, LMS International, November 2009. 2. M. Lebrun, R. Claude, How to create Good Models without Writing a Single Line of Code, 5th

Scandinavian International Conference on Fluid Power, Linköping, 1997. 3. * * *, LabVIEW User Manual, National Instruments Corporation, June 2009. 4. A.S. Tannenbaum, Modern Operating Systems, Prentice Hall, 2nd Ed., 2001.


5. M.D. Petersheim, S.N. Brennan, Scaling of Hybrid Electric Vehicle Powertrain Components for Hardware-In-The-Loop Simulation, 17th IEEE International Conference on Control Applications, Texas, USA, 2008.

6. D.C. Hanselman, Brushless Permanent Magnet Motor Design, Magna Physics, 2nd Ed., 2006. 7. D.C. Katsis, Development of a test bench for evaluation of electric vehicle drive performance,

Virginia Polytechnic Institute and State University, 1997. 8. K.K. Gunda, Adjustable Speed Drives Laboratory Based On dSpace Controller, MSc Thesis,

Louisiana State University, 2008. 9. * * *, EMH Solution – New integrated HIL simulation of electric motors, dSPACE Magazine, 3,

2009. 10. N. Holthaus, M. Plöger, T. Schulte, Electric Motors: Hardware-in-the- Loop Testing at Full

Power, Automobil-Elektronik, 2, 2010. 11. C. Vasiliu, Method and Devices for RTS of an Electric Car Transmission, Romanian Patent

Demand No. A2010/01079, 2010.

HARDWARE-IN-THE-LOOP SIMULATION FOR ELECTRIC …revue.elth.pub.ro/upload/271189Art11_...

Documents

Transcript of HARDWARE-IN-THE-LOOP SIMULATION FOR ELECTRIC …revue.elth.pub.ro/upload/271189Art11_...