Hardware-in-the-Loop Simulation of Rail Vehicles at Adtranz

Hardware-in-the-Loop Simulation of Rail Vehicles at Adtranz

Copyright ~ IFAC Mechatronic Systems, Darmstadt, Gennany, 2000 HARDWARE-IN-THE-LOOP SIMULATION OF RAIL-VEHICLES AT ADTRANZ Ericb Scbeiben, Tbomas Ke...

1MB Sizes 0 Downloads 33 Views

Copyright ~ IFAC Mechatronic Systems, Darmstadt, Gennany, 2000

HARDWARE-IN-THE-LOOP SIMULATION OF RAIL-VEHICLES AT ADTRANZ

Ericb Scbeiben, Tbomas Keller

Adtranz (DaimlerChrysler Rail Systems) Switzerland Dept. BLA, PO Box 8384, CH-8050 Zurich, Switzerland Phone: +411 3183916 Fax: +411 3183288 e-mail: [email protected]

Abstract: The present contribution gives a review of hardware-in-the-Ioop simulation of rail vehicles at Adtranz starting with a purely analog simulator and ending up with a purely digital simulator. The problems encountered and solved with analog and hybrid simulators are discussed and the simulator topology, the simulation model and simulation results of a completely digital real-time hardware-in-the-Ioop simulation of a converter vehicle are presented. Copyright @ 2000 IFAC Keywords: Analog hardware-in-the-loop simulation, digital hardware-in-the-loop simulation, control system testing, discrete events, hybrid system

MOTIVATION

are closed via the simulator, this method called hardware-in-the-loop simulation.

Traditionally, many technical systems are tested by putting them into their designated working environment and seeing whether they perform according to expectation. Given the importance and complexity of modern digital control systems, including advanced control strategies implemented in far more than 100'000 lines of code per project and distributed over several controller boards with multiple processors each and real-time bus communication between them, the traditional ad hoc approach is no longer adequate, and concern must be given to system integration, testing, and verification. This demand is driven by the factors: • •



often

A particular merit of this approach is that it even permits a gradually increasing integration of subsystems to a total system simulation and a gradual change-over from simulation to actual application, as it allows to start from a pure simulation and to gradually integrate real electrical and mechanical subsystems into the loop as they become available. The gradual integration of subsystems into an overall system simulation also has an impact on the engineering process. The interaction between the subsystem engineering processes concerning cross system compatibility comes up latest during type testing and earliest during concept development. The possibility for testing without hardware-in-the-Ioop simulations are limited and results are often based on many assumptions regarding environmental conditions that are hardly applicable in real life. With the introduction of all the possibilities of hardwarein-the-loop simulations compatibility tests can begin in an earlier stage of the engineering process. A key aspect is the independence on the production process. Long before a vehicle is available for type testing on the rail the dimensioning of the components and the control software functionality and parameterization can be tested. The benefits are found in two areas. One area comprises the economical advantages of shorter commissioning times on the vehicle that

risk (loss of human life or capital) cost (test in target system can be prohibitively

expensive) •

IS

availability (target system or designated working environment are not available) coverage (not all test states can be reached during regular operation)

One of the most powerful, but also most demanding, tests for dedicated real-time control systems (frequently also referred to as embedded systems) is to connect the inputs and outputs of the control system under test to a real-time simulation of the target process. As this implies that all control loops

787

integrators for a simulation. The primary bottleneck in our applications was the switching of the power electronic converters and the digital inputs.

DIGITAL SIMULATOR As described in the previous section, analog and hybrid simulators have been used for real-time hardware-in-the-Ioop simulations for more than ten years. However, a change to a digital simulator offers some major advantages. These are : • • • •

Fig. I. InterCity Tilting Train (lCN) for the Swiss Federal Railways (SBB). exceed by far the costs of hardware-in-the-Ioop simulation in the laboratory. The other area comprises the technical knowledge and know-how about the technical system, especially the interactions between disciplines. Hardware-in-the-Ioop testing is not limited by environmental or physical limitations. Dangerous operating points, emergency conditions and for instance high-speed tests can be done in the laboratory without any risk of human life. Furthermore these tests can be repeated and automised. All these benefits lead to shorter engineering times together with lower technical and financial risks. A typical example was the new intercity tilting train of the Swiss Federal Railways shown in fig . I, where the commissioning time could be reduced from weeks to days through the use of digital hardware-in-the-Ioop simulation.

Flexibility Modular hardware and software Modern programming language Lower hardware and maintenance costs

A crucial task is achieving a sufficiently short integration step size and a short dead time for the simulated system. A converter for instance has an estimated dead time of only 25llsec, and a real-time control system (as it is installed on Adtranz locomotives) for motor control has a cycle time under 50llsec. To avoid instability and a loss of accuracy, both times have to be carefully taken into account for the simulation. This leads to special integration methods being applied to handle the firing pulses of the converter. Affordable digital simulators with sufficient CPU calculation power to do real-time motor/converter simulations have become available only recently. Nowadays digital simulators are programmable with graphical programming tools, and the resulting models can be downloaded automatically. The German company dSpace offers an integrated development environment (dSpace, I 999a, b) based on Matlab/Simulink (MathWorks, 1999a, b). With its latest DEC-alpha processor board the calculation power is high enough to reach step times short enough for our demands.

IN THE BEGINNING

In the mid 1980's, after more than 15 years with AD4, a new generation of simulators were considered. The aim was to minimize the need of hardware know-how about the simulator itself, to simplify the programming and to improve the simulation documentation. The requirements were to simulate the whole locomotive drive system from powerstation to train mechanics. The digital simulator AD I 00 available at that time attained a benchmark simulation cycle time of about 300 Ils which was too slow to be used for the locomotive drive simulation.

The graphical programming language used is Matlab/Simulink (Math Works, 1999a). In addition to the dSpace being based on this tool , Adtranz already had in-house toolboxes for converter vehicles developed at ABB corporate research centers. A detailed description of the concept, evaluation and operation of the digital hardware-in-the-Ioop simulator appeared in (Terwiesch et. aI. , 1999).

As a consequence, the hybrid simulator SIMST AR was chosen for the task. A SIMST AR system consisted of a host digital computer, a digital arithmetic processor (DAP), data conversion processor (DCP) , and up to 6 parallel simulation processors (PSP) or patch panels. The particular SIMST AR system used at ABB Transportation was a stand alone version in that the DAP doubled as a host computer. One and a half fully expanded PSP' s (patch panels) were obtained providing up to 60

SIMULATION ENVIRONMENT

Simulator Hardware After bench marking different configurations, the final hardware architecture shown in fig. 3 was chosen. It

788

Alpha 2: 'asm12'

IM1

1M2

DSP: 'm~ster' .

.'

Line and Motor Controller Fig. 2. Separation of the model.

Separation of the Model

consists of 2 DEC-alpha processor boards and 6 TMS32OC40 digital signal processor boards (DSl003). Semiconductor firing pulses are read with 4 digital waveform capture boards (DS5oo 1) which save the binary input states together with a time stamp in an on-board buffer. Analog outputs are done with 4 high-speed digital to analog conversion boards (DS2102). Communication between processor boards are done with parallel links with a capacity of 20MB/sec between the DS 1003 boards. The Alphaboards are connected to a DS 1003 board via dual port memory and communicate via this channel. 110 boards are connected via a peripheral high speed bus with a capacity of 20MB/sec.

Due to the high demand for short simulation cycle times it was necessary to distribute the model on two alpha processors (Alpha 1 & 2) which act as the workhorses of the simulation, and on two C40 processors (DSPs) which act as communication managers (see fig. 3). In order to distribute the model on the two alpha processors, the propulsion system model is broken up at the dc link / motor converter interface as shown in fig. 2. The left side of fig. 2 (Alpha 1) is the line side submodel which comprises the catenary system, the main transformer, the four-quadrant converters and the dc-link. The right side of fig. 2 (Alpha 2) comprises the motor converters, the induction motors and the mechanical model of the train.

__

Not to dc-IIr*

r~ . ~ L ~ : (2&11, 16c:tww101s1

~ 1% 1, 1

·1 .

~boonI

DECAIphI

~TMS32OC4O U,*~boonI

1:

·

:

1:

[)SoO)1

:

dgbIf 110 (32 cIwneIsI

Ibc" .

.

~-TMS32OC4O

0=: ==--=

The simulation model is programmed using TheMath Works' Simulink modeling package (Math Works, 1999a). The code for the actual realtime simulation is compiled from modules partly implemented in Simulink code and partly in dedicated C code using MathWorks' Real-time Workshop (Math Works, 1999b), and dSpace's own software (dSpace, 1999a). An important advantage for the end-user of such a system (typically a traction engineer rather than a simulation specialist) is the simplicity and flexibility with which he can assemble pre-defined submodels to compose a model of his traction equipment.

r~ ' ~-(2&11, 16 c:twwIoIsl

~~

.... = ' 1 ·1 : '-'~ DS2102

:

1

-'-'lllSU)r

l

C&ZlO1

dgbIf a1IIIog caworter

(16bit, 2.5tJa, 6c:twwIoIs1 6~(16bit, l.sv.sl 1Kh . . TMS32OC31

Fig. 3. Simulator topology.

789

between two channels, which is a crucial detail for certain types of speed sensor logic.

Numerical Stability

I

INITIALIZATION

I

Numerical stability is another critical simulation issue. Due to the strong real-time constraints a fixedstep Euler integration algorithm is used. This algorithm is numerically stable only in a circle of the left half plane of the complex plane. If the poles of the simulated system are stable, but outside the circle, the Euler integration is unstable. This can happen for weakly damped systems, e.g. the mechanical part of the drive of a rail vehicle. Fig. 5 shows the phase plane with the stability area for Euler and the poles of such a weakly damped system. One solution to avoid this numerical instability is to choose another integration algorithm for that part of the system, e.g. a 2nd order Runke-Kutta method. The stability area for that algorithm is larger, as shown in fig. 5.

Fig. 4. Simulink model. Most often the interprocessor communication is the bottle neck for fast simulations on distributed systems. Our division of the model of the propulsion system between the dc-link and the motor converters resulted in a minimal communication effort. The communication comprised only the dc-link voltage from the net-side to the motor side and the rectified motor current from the motor side to the net-side.

im

Fig. 4 illustrates how the Simulink model is distributed on the processors. This configuration (see also fig. 3) allowed us to achieve a simulation step size of only 40usec with a corresponding dead time that was no greater than 1.5 times the step size.

Simulation ofSpeed Sensors

The simulation of speed position sensors is a critical simulation issue. The mechanical sensors considered here put out a set of two rectangular pulses 90° apart. The simulation is required to have • •

• •

a pulse resolution down to a few J.1S in time. an accurate displacement angle (typically 90°) between the set of pulses to indicate the direction. run asynchronous to the rest of the simulation. an output signal that is different from TILlevels.

Fig. 5. Numerical stability.

Wheel-rail contact

These requirements required the use of a separate board called the Direct Digital Synthesis (DDS) board by dSpace. On this board 6 separate processors, each with a DIA converter, are available for C-prograrnrning. As cycle times below 5J.1S are attainable, this board met our requirements. Data is exchanged via dual port memory allowing the speed sensor simulation to run asynchronously to the rest of the simulation. The DIA-converter for each channel gives us the freedom to generate any signal behavior. The limitation is the voltage range of the DIA converter of ± lOV. The interrupt lines of each channel allows a very accurate displacement angle

In reality the adhesion process in the wheel-rail contact is a stochastic process with many influence parameters such as weather, temperature, wheel and rail surface, etc., see (Hase and Menth, 1996). A simplified model has been developed which is suitable for real-time simulation. The tractive force is modeled as a function of the wheel slip speed, i.e. the speed at which the wheel slips on th~ rail. ~ .typic~1 adhesion curve for dry and wet raIl condItIons IS shown in fig. 6. In order to model the stochastic effects, the shape of the adhesion curve can be changed randomly.

790

that had been reserved to analog or hybrid simulators in the past due to the extremely fast electrical process dynamics and the complexity of handling discrete switching events in otherwise continuous systems in real-time. The graphical programming of the entirely digital simulator greatly simplifies the control system integration test procedure.

Cl)

...uo

u..

Cl)

>

'zj

In the future hardware-in-the-loop simulations of rail vehicles will also be used for overall system investigations, such as stability of the vehicle in a supply network, or the influence of the adhesion process on the line current, or electromagnetic compatibility studies.

u

... I~

Wheel Slip Speed REFERENCES Fig. 6. Adhesion curves for dry and wet rail conditions.

dSpace (l999a). DSJO03 DSP Board RTf Reference. dSpace GmbH, Paderbom. dSpace (I 999b). Real-Time Interface (RTf and RTIMP) Implementation Guide. dSpace GmbH, Paderbom. Hase, P. and S. Menth (1996). Adhesion process of electric vehicles - mode ling and comparison with measured data. Elektrische Bahnen, vo!. 94, pp. 125-134 (in German). Math Works (I 999a). Using Simulink. The MathWorks Inc, Natick. MathWorks (I 999b). Real-Time Workshop. The MathWorks Inc, Natick. Terwiesch, P., T. Keller and E. Scheiben (1999). Rail vehicle control system integration testing using digital hardware-in-the-loop simulation. IEEE trans. control systems technology, vo!. 7, pp. 352362.

SIMULATION RESULTS The real-time simulator is also used for testing the adhesion controller of a rail vehicle. As an example the simulation results for a transition from dry to wet rails is shown. It can be seen in fig . 7, how the tractive force is reduced on wet rails. Wheel s~ (knVh)

i :~If--------+I--+-/--+ff±fH--=+! --'FI ~ --+--+-1

1~~ . 5--~~~0.-5--~1---1~.5--~----2.~5--~

MoI()("~(Nm( ~

i-< 2000~---+-.().5

0.5

1.5

2.5

1{s)

Fig. 7. Transition from dry to wet rails.

CONCLUSIONS AND PERSPECTIVE Selected results from a digital real-time simulation of traction vehicles have been presented. Particular emphasis was placed on the simulation of speed sensors, numerical stability, and simulation of the adhesion process. Overall, closed-loop real-time simulation of the vehicle using the actual control system considerably simplifies following vehicle tests on track and can be used to reconstruct and further investigate possible problems encountered during vehicle operation. The digital simulator described here has entered a domain

791