Rail vehicle control system integration testing using digital hardware-in-the-loop simulation

352 IEEE TRANSACTIONS ON CONTROL SYSTEMS TECHNOLOGY, VOL. 7, NO. 3, MAY 1999

Rail Vehicle Control System Integration TestingUsing Digital Hardware-in-the-Loop Simulation

Peter Terwiesch,Member, IEEE,Thomas Keller, and Erich Scheiben,Member, IEEE

Abstract—Control systems for converter-controlled rail vehiclesare orders of magnitude more complex than controllers forprevious generations of vehicles. While the dynamic behavior ofprevious generations of vehicles was to a large extent determinedby its power components alone, an important part of the dynam-ics of modern vehicles is shaped by real-time software, distributedcomputing and intercontroller communication. To ensure properoperation of the vehicle on track, an integration test of the vehiclecontrol system is performed before initial roll-out. In order toachieve a maximum test depth and to minimize risk and cost,this test is achieved by connecting the original vehicle controlsystem to a real-time dynamic vehicle simulator in closed-loopoperation. The present paper describes concept, evaluation, andoperation of a digital hardware-in-the-loop simulator for testingcontrol-relevant parts of the vehicle. Particular emphasis is puton the hybrid nature of the underlying simulation problem andits inherent causality variations due to the combination of discreteswitching effects, e.g., in diodes and controlled converters, withcontinuous system parts, e.g., differential equations for currentsor mechanical system parts.

Index Terms—Digital control, hardware in the loop, hybridsystem, real-time systems, simulation, variable causality.

I. INTRODUCTION

A. Integration Tests Using Closed-Loop Real-Time Simulation

T RADITIONALLY, many technical systems are tested byputting them into their designated working environment

and seeing whether they perform according to expectation.Given the importance and complexity of modern digital controlsystems, including advanced control strategies implemented infar more than 100 000 lines of code per project and distributedover several controller boards with multiple processors eachand real-time bus communication between them, the traditionalad hocapproach is no longer adequate, and concern must begiven to system integration, testing, and verification.

This demand is driven by the following factors:

• risk (loss of human life or capital);• cost (test in target system can be prohibitively expensive);• availability (target system or designated working envi-

ronment are not available);• coverage (not all test states can be reached during regular

operation).

Manuscript received March 24, 1997. Recommended by Associate Editor,F. Svaricek.

P. Terwiesch is with the ABB Corporate Research, Information TechnologyDepartment, D-69115 Heidelberg, Germany.

T. Keller and E. Scheiben are with the ABB Daimler-Benz Transportation,Propulsion Systems, Department BAA, CH-8050 Zurich, Switzerland.

Publisher Item Identifier S 1063-6536(99)03276-5.

One of the most powerful, but also most demanding, testsfor dedicated real-time control systems (frequently also re-ferred to asembedded systems) is to connect the inputsand outputs of the control system under test to a real-timesimulation of the target process. As this implies that all controlloops are closed via the simulator, this method is often calledhardware-in-the-loopsimulation.

A particular merit of this approach is that it even permitsa gradual change-over from simulation to actual application,as it allows to start from a pure simulation and to graduallyintegrate real electrical and mechanical subsystems into theloop as they become available.

Depending on requirements and process dynamics, threeconceptual for control system testing exist:

• self-test/self-simulation mode designed as part of embed-ded system under test;

• use of another control system as a simulator;• dedicated real-time simulation system.

The advantage of the first approach is that it requires littleor no additional hardware and that it can be activated duringmaintenance stops without further external tools. However, abuilt-in self-test alone is hardly sufficient for finding com-munication bottle-necks or even design flaws, and its faultcoverage may often be insufficient. The second approach isrelatively popular in an industrial development environment,as it delivers the advantages of full-scale hardware-in-the-loop simulation at comparatively low cost. It saves on wiring,interfacing, and conversion, as controller and simulator aremade of identical hardware and are thus easily connected. Thisaspect is particularly important when several thousand signalsneed to be exchanged between control system and simulator,as is the case in power plant or chemical process control. Onelimitation of this approach is that it typically fails to work forextremely fast systems, such as systems with nonnegligibleelectrical dynamics, where the computing power sufficientfor running a controller may be an order of magnitude tooslow for executing a detailed process simulation. Anotherlimitation lies in the programming of this simulation, sinceelementary control function blocks are rather ill-suited for theimplementation of complex simulation systems.

For very demanding requirements only a dedicated real-timesimulation system can offer the required computing power. Fora long time, this has been the domain of analog and hybridsimulators, e.g., [2]. The third approach is more costly thanthe other two in terms of initial investment, as it requires aspecial hardware interface to the control system.

The present paper describes such a dedicated real-time

1063–6536/99$10.00 1999 IEEE

TERWIESCHet al.: RAIL VEHICLE CONTROL SYSTEM INTEGRATION 353

Fig. 1. Generic hardware-in-the-loop setup.

simulation system and its use for the integration testing ofthe line and the propulsion converter control system hardwareand software of an electrical locomotive. The inputs fromthe control system under test to the simulator are discretefiring pulses from Adtranz’ proprietary control system to thepower converters, and its outputs include measured currents,voltages, and drive speeds from the simulated vehicle tothe control system. The discrete and continuous dynamics ofthe main electric circuits and main mechanical modes of alocomotive are simulated in a real-time closed loop with ahybrid control system, resulting in a challenging hybrid controland simulation problem.

Fig. 1 shows the generic structure of such a system, includ-ing the possibility to connect pieces of actual process hardwareto the control system and the simulated process for those partsof the system where no proper models are available.

B. Controlled System: Electrical Locomotive

Today’s rail propulsion systems deliver a functionality interms of energy efficiency and power factor that was unheardof before the days of computer-controlled power converters(Section II-A). This revolutionary increase in functionality isaccompanied by an ever growing control system complexity(Section II-B).

1) Loco 2000: Despite differences in functionality betweendifferent classes of rail vehicles, we concentrate our processdescription of electrical rail vehicles on locomotives, as lo-comotive projects are one important class of applications forthe simulator described here and as locomotives typically haveoften more demanding control requirements and functionalitythen, e.g., trams or metros.

Within the class of electrical locomotives, we choose as anexample “Loco 2000,” the pride of Swiss Federal Railways.This class of vehicles employs three-phase propulsion andGTO gate turn-off thyristor) converters to reach maximumpower of 6100 kW and top speed of 230 km/h. Weighing in at81 tons, it is the first member of a family of locomotives onwhich several further European and overseas railway projectshave been based [8]. Together with the power transformer,the converters and their controllers are really the “gut” of the

Fig. 2. Loco 2000 electrical system.

locomotive. They have the task of converting the 16 2/3 Hzsingle-phase ac supply into a three-phase ac source of variableamplitude and frequency suitable for supplying the inductionmotor drives. The flow of energy conducted by the lineconverter does not equal that conducted by the propulsionconverter at every instant. The difference is either stored orsupplied by the dc link circuit, in banks of metallised papercapacitors.

Fig. 2 gives a schematic overview of the Loco 2000’selectrical system. Electrical energy is fed in from the catenarythrough the pantograph, and is then transformed and rectifiedto feed an intermediate-link capacitor. In Loco 2000 Re460,this capacitor is split in two symmetric halves, providing thevoltages 0.5 0.5 where is the dc link voltage.A computer-controlled GTO inverter bridge (propulsion con-verter) converts this dc energy to a three-phase AC system thatfeeds the driving motor. Note that this flow of energy can alsobe reversed for regenerative braking, which converts energy ofmotion back to electrical energy that is fed back into the line.

2) Control Structure: Fig. 3 summarizes the most impor-tant control functions of an electrical locomotive as relevant tothis paper. The main control signals are the GTO firing pulses,which determine whether the GTO thyristors are conducting ornot. These signals are generated by the line converter controllerand the motor inverter controller. For the line side, the controlsignals are generated by a pulse width modulator. By varyingthe widths of the different voltage impulses, the amplitude


Fig. 3. Major control functions in an electrical locomotive.

and phase-angle of the four-quadrant controller voltage can beadjusted to fit the needs of stability and energy. The motorcontroller produces GTO firing pulses to provide the motorswith a variable-frequency three-phase ac supply. To generatethe corresponding pattern of control impulses and for drivingthe motor under optimal conditions at all times the motorfrequency range is divided into three control ranges: indirectself control, direct self control, and full impulse method [18],[19]. Each control range has its own requirements with regardsto hardware-in-the-loop simulation and has therefore beenexamined individually.

II. HYBRID SIMULATION PROBLEM

A. Simulator Requirements

The goal of the proposed real-time simulator is to ensureproper operation of the control system on the actual vehi-cle. Tests are performed on the closed-loop system obtainedby connecting the actual locomotive control system to thesimulator. The basic structure of the hardware-in-the-loopsimulation is shown in Fig. 4. GTO firing pulses from thecontrol system are the most important inputs to the simulator,while electrical quantities (voltage, current) and mechanicalquantities (torque, speed) are the most important outputs.Within the simulator, mathematical models of converters,filters, drives, and mechanics are used to represent the electro-mechanical behavior of the vehicle. Obviously not only thedynamics of the vehicle itself, but also interaction with itsenvironment (wheel-rail contact and electrical network) needto be simulated. An example of a typical feature tested by thesimulator is the amplitude of the torque ripple produced by theinduction motors at different operating points. Another typicalmeasurement is the transient shape of motor and line currentswhen switching from acceleration to braking.

Fig. 4. Hardware-in-the-loop system structure.

The setup described in Fig. 4 imposes stringent real-timerequirements on the simulator, as the control system is run-ning with a cycle time of 40–60 s and as computation ofcurrents from firing pulses is extremely sensitive (1-s jitterin the processing may noticeably affect the outcome of thesimulation). This need for accurate processing of switchedcurrents and the fast control system sampling leads to arequired simulation frame time of about 30s, which issufficient for the evaluation of the electromechanical dynamicsprovided that switching events are receiving a faster specialtreatment. Here, frame time is the calculation time needed forone simulation step with the entire model. At the end of eachframe time the simulator communicates with the connectedcontrol system, meaning that the frame time is the granularityof real-time synchronization between simulator and connected


control system. Note that a conceptual alternative to the shortframe times needed here can be to synchronize control systemand simulator, using identical sampling instants. While thissomewhat relaxes the computation speed requirements, thisapproach appears viable only when a control system has beenexplicitly designed for such testing.

A further important requirement is that the programming ofthe simulation system should be user-friendly and configurablefor the end users, who are typically vehicle experts, butwithout in-depth real-time simulation knowledge. This needtranslates into the requirement of using a graphical block-oriented simulation language to configure and parameterizethe simulation model.

B. Simulator Platform

Several commercial vendors are addressing the real-timesimulation market with their hardware and software platformsolutions. One of them is dSPACE, a German company thatoffers a fast, modular real-time hardware, together with asoftware interface to Matlab/Simulink [17]. dSPACE systemsare widely used for rapid prototyping and hardware-in-the-loop simulation in many application areas, especially in theautomotive industry. Based on DEC Alpha processors andTMS320C40 signal processors they offer scaleable computingpower. The processors are connected by fast point-to-pointconnections, avoiding the bottleneck of a common bus. EveryC40 processor has its own peripheral bus for connectinginput–output (I/O) boards, allowing parallel I/O on differentprocessors. A number of very powerful I/O boards is available.

dSPACE offers a user-friendly development environmentbased on Simulink as a graphical modeling environment [15].Simulink is widely used for off-line simulations, resulting inthe existence of adequate company-internal model libraries andcommercial and university support toolboxes for our purposes.This is one of the reasons for using Simulink as a front-end,despite the drawbacks of Simulink and similar languages toimply fixed causality in its block diagrams and to properlysupport event handling.

Since causality variations and discrete events (e.g., firingpulses) in an otherwise continuous model (e.g., first-orderODE’s describing a motor) contribute an important part toour modeling problem and since we could not find suitableoff-the-shelf solutions for our problem, we had to give thisaspect further consideration and solve it for ourselves. Thefollowing sections describe our hybrid simulation problemin more detail, introduce a pragmatic solution to circumventthe above mentioned deficiencies of fixed-causality simulationlanguages, and show results obtained with the fully operatingsimulator.

C. Hybrid Simulation Problem: Discreteand Continuous Subsystem

The vehicle simulation model, as many others, consist of ananalog blockwith a number of first-order ordinary differentialequations (ODE’s) for the continuous-valued system statesand abinary blockwith combinatorial and sequential equationsfor the discrete-valued system states The two blocks are

Fig. 5. Hybrid model structure.

Fig. 6. External event.

coupled through switches (change of continuous input vari-ables or equation structure by digital signal) and comparators(binary result from comparison of continuous variable withthreshold) as shown in Fig. 5. While there is a wealth ofmethods available for simulation of either block [3]–[5], agreat challenge both in nonreal-time and real-time simulationis to properly account for the links between continuous anddiscrete simulation blocks.

This coupling between discrete and continuous subsystemsis one of the main reasons why digital real-time simulationis taking so long to replacehybrid simulation computers:hybrid computers contain comparators (analog to discrete) andswitches (discrete to analog) that implement this link verynaturally [1], [2]. In digital simulation, on the other hand,three types of problems resulting from the link of discrete tocontinuous blocks can be distinguished (with examples fromour system):

• external events (Fig. 6), e.g., firing pulses from the controlsystem to the converters;

• state (or internal) events (Fig. 7), e.g., idealized diodesthat conduct or block depending on voltage and currentconditions (blocks as long as neither voltage nor currentare positive)

• time events, e.g., waiting time conditions.

The latter two have in common that a continuous variablepasses a threshold, so that a comparator generates an event.This event will typically operate on a switch, so that it maysignificantly change the continuous system in its structure,causality, or parameters. In an electric circuit, containing ele-


Fig. 7. Internal event.

ments such as capacitors or inductances, the event structurallychanges the state equations, i.e., the differential equationsgoverning the dynamics of the system.

In real-time simulation, handling state and external eventsare the major problems, since the limited frame time, corre-sponding to a fixed external step size, normally does not permitadaptive step-sizing or iterations around the event. These twotypes of events thus call for a specific treatment depending onthe exact requirements. Time events, on the other hand, areusually known in advance and can be incorporated by usingadequate synchronization instants, so that they are normallynot the main problem of real-time simulation.

There are different ways to approach the handling of stateand external events in a digital hardware-in-the-loop simula-tion. External event problems can often be solved by one ofthe following approaches:

• small frame time;• interrupt-driven integration;

and state event problems by

• small frame times;• event time registration and correction.

The best approach to event problems is in all cases smallframe times. It is therefore always advisable to examinethe exact requirements of the system before implementingdifferent approaches, as they may lead to much bigger frametimes due to computational effort spent on iterations andcorrections. However, when the dynamics of the system arevery fast in comparison to the computational qualities, one ofthe other approaches must be used, see Section III-C.

D. Integration of Continuous Part

The choice of the right numerical integration method forthe continuous part may greatly contribute to the power ofa digital real-time simulator. This section summarizes someconsiderations for selecting appropriate algorithms, compare[9], [11].

Mathematically, the continuous part of the system that needsto be simulated in real-time is usually described by a set offirst-order ordinary differential equations

Here is the system state vector (containing elements suchas position, speed, voltage of a capacitor, current through aninductance etc.), represents external inputs (such as manualswitches, or signals coming from the control hardware), and

stands for time.In general, this type of system can be integrated using

several approaches, which are distinguished by the followingproperties [9].

• Explicit/implicit methods:Explicit methods only use pastvalues of (up to the present time ), whereas implicitmethods also use the new value , which they findby iteration. Implicit methods are particularly suitable forstiff systems, i.e., for systems in which very slow andvery fast dynamics need to be considered simultaneously.

• Single-step/multistep methods:Single-step methods onlyuse one past value for computing the new value,

Multistep methods use more than one past value,e.g., and . As single-step methods needsmaller frame times or more evaluations of the modelin the interval to achieve the same accuracyas multistep methods (as long as the state trajectoriescan be approximated by polynomials), they are alsocomputationally more expensive.

Note that real-time simulation does not permit to usepredictor/corrector methods beyond the current frame, since noknowledge of is available. As long as there are no abruptchanges in the state trajectories, multistep methods, suchas the Adams–Bashforth algorithm, offer better performanceand/or accuracy than single-step methods. However, as soonas switching needs to be accounted for, single-step methodssuch as the explicit Euler algorithm must be used, since anextrapolation of the past is no longer desirable and wouldlead to inaccurate results. Note, however, that these algorithmsrequire small step-sizes and have comparatively poor stabilityproperties [9]. Note that modern algorithms capable of eventdetection [23] are not suited for real-time simulation withoutmodifications (such as bounds on the number of iteration,which in turn would effect their accuracy) due to the needto synchronize with an external cycle time of 30s.

E. Switch Simulation Problem

As described above, events, also termed discrete modetransitions, due to idealised models of switches introduce twoproblems [12], [13].

• The causality of the continuous model part will changefor every mode-transition, e.g., if voltage was the inputand current was the output of a model before the event,voltage would be the output and current the input after it.

• State events have to be detected and continuous mode-equations rearranged and reinitialized for every mode-transition.

The problem of variable causality is illustrated by modelinga switch located between the transformer and the rectifier ofa locomotive. A switch model between the two blocks hasinputs and and outputs and (Fig. 8).

Now consider the change of causality depending on the stateof the switch. When the switch is closed, we have


(a)

(b)

Fig. 8. Causality change in switch model: (a) switch closed, (b) switch open.

and , as shown in Fig. 8 (upper). Model causality isdifferent when the switch isopened, since then and

Instead of is given and the voltage isundefined (Fig. 8, lower). However, is also an output ofthe transformer. In order to resolve this conflict properly, thetransformer equations have to be solved for instead of

Implicit simulation languages, such as ACSL [7] are ableto describe events, but are not directly suited for real-timesimulation. Explicit simulators such as Simulink do not supportsuch equations. One can obviously program all cases manually,but a system with switches would then have differentrepresentations, depending on the state of the switches [14],[6], [10].

Alternatively, we propose a pragmatic method to estimatethe undefined open switch voltage

III. SWITCH APPROXIMATION FOR

FIXED-CAUSALITY SIMULATION

Section IV discusses a pragmatic solution to the problem ofdigital real-time simulation of switched systems as described inSection III-E. Switching occurs both on the line side and themotor converter side of the vehicle and two issues, namelyvariable causality and accurate event processing need to bedealt with. Without a solution to the causality problem, thedecomposition of the system model to subsystem modelswould not be possible, resulting in a monolithic model thatis hard to engineer and difficult to distribute over multipleprocessors. The solution to the second problem, accurateprocessing of switching events, replaces the coarse intregrationof firing pulses with a time resolution limited to the samplingtime by a more accurate mechanism.

A. Open Switch Voltage Estimation

An open switch has to set the voltage in such a way thatthe current becomes zero. Our pragmatic approach is to usean estimator with an approximate model for determining(Fig. 9). The estimator is based on a first-order approximatemodel of the open circuit, e.g., an- -link for a transformer(Fig. 10). and represent the model of the transformer.Assuming that and are approximately known, the un-known voltage is estimated by applying a voltage

Fig. 9. Open switch with estimator.

Fig. 10. Open switch withR-L-Link.

and evaluating the resulting change in the currentNotethat an - -link is a reasonable choice in our case, as bothtypes of converter loads (transformer and induction motor) areinductive. For the values of and we choose the resistanceand leakage inductance of the corresponding coil, neglectingthe coupling of other coils. As shown later, modeling errorsresult in a leakage current.

The - -link in Fig. 10 is described by the followingdiscrete equation:

(1)

At time we know and , the new and theprevious current from the transformer, and , thevoltage over the switch from the previous time step. Withthese values the unknown source voltageduring the lasttime step can be estimated in the following way:

(2)At zero current this is the desired open switch voltage. But if

the switch is opened with nonzero current (which is physicallyimpossible but often happens in a simulation due to samplingeffects), a nonzero leakage current remains as a simulationerror. This simulation error can be forced to converge to zeroby adding a correcting term to the estimated source voltage

(3)

The leakage current, and thus the simulation error, will thendecrease with the time constant

(4)

We normalize the estimator gain with

(5)


the gain for The estimator gain is now describedthrough the relative factor

(6)

The following factors contribute to the leakage current.

• Time delay: The voltage estimation is delayed by one timestep.

• Switching off a nonzero current: Opening the switch witha nonzero current flowing results in voltage peaks, sincethe current through the inductivity cannot changediscontinuously. The current then fades away with a timeconstant given by the estimator parameters, as shownabove.

• Error in : A mismatch between the inductivity inthe estimator and the true inductivity in the circuit leadsto oscillations or even instability. The effect can be re-duced by allowing a larger time constant in the estimator(Section IV-B).

Fig. 9 illustrates that even for a nonzero leakage currentthe current on the other side of the open switch can be setto zero. In order to properly parameterize this estimator, twokinds of parameters must be chosen: internal model parametersand estimator gain.

The following discussion assumes an- -link as an internalmodel of the estimator, as described above. In our example,the choice of is not critical. It will be added to andcan normally be neglected, namely if On theother hand, the choice of is important. Assuming that thereal circuit is an - circuit according to Fig. 10 withinstead of , it can be shown that the estimator is only stable,if is in the range

(7)

When the inductivity of the open circuit is known exactly,the estimator can be tuned to make the leakage currentdisappear after one time step However,in many cases is not knowna priori, since it dependson the state of other switches. Then for simplicity anad hocdecision is taken for choosing Often the inductance of thebranch which is directly connected to the switch is used, e.g.,the leakage inductance of a transformer coil. The stabilityrange (7) can be extended at the lower end by choosing asmall value for , This makes the system more robustagainst changes in at the cost of a slower decreasingleakage current. As we see, the choice of is a tradeoffbetween stability and performance and must be examinedexperimentally. Reasonable values of lie in the range

Typical values in our transformer-rectifier example (Fig. 10)are H, e-6s. With

e- we can neglect in (5) and (6). Fordifferent choices of we have the following results (see

also Section V-B):

fast decreasing leakage current

but not robust (oscillations when error in

still fast no oscillations

robust until A

very slow no oscillations

robust until

This shows that selecting is not a critical designdecision.

By modeling a diode as an ideal switch, the same methodcan also be applied to diodes. We have modeled the diodes ofthe line converter in this way. With the proposed method thebehavior of the locomotive is simulated qualitatively correcteven with only the diodes working (switching pulses off).There is a small leakage current in the transformerwhich normally can be neglected, especially when the diodesare used only for charging the DC link capacitor at startup.

An alternative approach would be to zero the current inother parts of the model (e.g., transformer block) when theswitch is open. This decreases the leakage current by at leastan order of magnitude, but depends on changes in the modelblocks (e.g., transformer) and additional, artificial, connectionsbetween them. We have decided against this approach, sinceit would come at the cost of giving up the current modularity,since artificial control signals would be needed to transmit thestate of the switches to the blocks. Instead of setting the currentto zero it is also possible to design an internal event correctionmethod which calculates the exact time of the event and addsa correcting term in the next simulation step. This methodhas the same drawbacks concerning modularity as setting thecurrent to zero.

B. Time Stamping

While the frame time needed to process the electrical modelequations is in the order of 30s, switching delays andswitching jitter must be handled with a resolution of 1sor faster in order not to loose simulation fidelity. Since 1sframe time would be out of question for the given modelswith today’s real-time simulators, an alternative method forhandling the influence of switching events in the model isneeded for the particular application under investigation.

Our solution exploits that all converter firing pulses inthe vehicle model occur at the input of voltage integrators,where they switch between zero and a slow-changing voltagevalue. Consequently, this integration of firing pulses can beapproximated with high fidelity by approximating the idealcontinuous integrator with an accurate time-voltage productinstead of the usual coarse discrete-time integration. Since thevoltage is changing only slowly and can thus be consideredconstant over one frame time, it is sufficient to accuratelyregister the switching times (with 25-ns resolution in ourapplication) in order to produce a high-quality time-voltageproduct at the output of the integrator. This approximation isfirst-order accurate and neglects the cross-couplings betweendifferent integrators of the model. Simulation studies have


shown this time-stamping method to be far more precise thansampling of the switch state and every frame time, and theremaining real-time integration error compared to an accurateoff-line solution is definitely negligible in view of any modelquality that can be achieved for the type of system underinvestigation.

IV. RESULTS

A. Implementation

The real-time simulation is implemented according to themodularization shown in Fig. 4, including a model of the con-troller used in off-line simulations and sensitivity studies. Inon-line simulations the controller model is exchanged againstthe actual Adtranz controller hardware and software, and areal-time hardware-in-the-loop simulation is performed. Tak-ing special care of switching events as described in Section IVrequires some of the lower-level parts of the model to be codedin rather than Simulink. However, this part remains hiddenfrom the simulation end-user, who only gets to see the vehicletopology and parameters as a Simulink models.

As the locomotive consists of two almost symmetrical parts,only half of the locomotive (half the line converters andinverters, one intermediate circuit and one bogie) need to beconsidered and the coupling of the two bogies through rail andcarbody is neglected in the current version of the simulator.The model is entirely based on ordinary differential equationsas found in the literature, e.g., [21] for the electrical and [22]for the mechanical part of the vehicle. Practical tests haveshown that the approximation of the half-loco is sufficient inalmost all cases, with few exceptions such as the fine tuning ofadhesion controllers, where the leading axles are conditioningthe rail for the following ones.

Before actually building up the complete system, benchmarktests have been conducted together with dSPACE. The modelwas carefully partitioned over several processors to improvethe frame time, and the optimal configuration was determined.Such an optimum generally exists, since there is a naturalbound on the number of processors due to communicationneeds, which at some point increase the frame and reactiontime more than a further processor can reduce the computationtime. Not all parts of the model actually require a highsampling rate. The mechanical subsystem, for instance, hasvery slow dynamics in comparison to the rest of the model andcan therefore be sampled slower and connected by a zero-orderhold, thereby decreasing the computational load.

B. Hardware

Benchmarking different configurations, the final hardwarearchitecture has been chosen. Fig. 11 shows how the model ispartitioned in the final configuration. With two 300-Mhz, 64-bit, DEC alpha processors and six C40 digital signal processorsa frame time of less than 30s has been achieved.

The converter switching pulses are read in with a timestamping hardware with a resolution of 25 ns. The timestamp information is used in the simulation in order toincrease the accuracy and more than one pulse per integration

Fig. 11. Partitioning the model.

step can be handled. This prepares the simulator also forfuture applications with higher switching frequencies, such asthose possible with high-power IGBT (insulated gate bipolartransistor) converters.

A more detailed description of the underlying dSpace plat-form system and of their application to the problem describedhere from a platform point of view can be found in [20]. Allprocessors are mounted on PC/AT-compatible boards in twodifferent boxes. Each box is connected via ISA bus to the hostPC, a PentiumPro 200 with Windows NT, which is used as anengineering workstation and operator interface. The differentutilized dSpace component types are as follows.

• as designated working horses,evaluating the entire model. Clock frequency of 300-MHz 64-bit resolution. Communication through dual portmemory to a DS1003 board, practically no computationaloverhead.

• based on the Texas Instruments processorTMS320C40 with 50-MHz clock frequency and 32-bitresolution, mainly used for communication and not forthe evaluation of model equations. Also used to read theregistered trigger pulses from digital waveform captureboard (DS5001). Three types of communication channels:

a) Parallel 8-bit links: Six eight-bit parallel links perboard for interprocessor communication with 20-MB/s transmission rate. All DS1003 boards areinterconnected by these links.

b) 32-bit PHS-Bus: peripheral high-speed (PHS) busconnects peripheral boards to DS1003 boards with20 MB/s. Several peripheral boards can be connectedto the same bus.

c) Dual Port Memory: The dual port memory (DPM) isthe third possibility to connect a board to the DS1003board. It is used for the alpha processor board.

• : the simulator comprises four differ-ent types of peripheral for inputs and outputs.

a) Time-stamp Board. The DS5001 board is used toregister trigger pulses coming from the control elec-


tronics. It consists of 16 channels, each storing inone bit the state of the signal (high or low) and in31 bits the time of the transition with a resolutionof 25 ns.

b) Binary I/O. The DS4001 board consists of 32 binaryI/O configurable in groups of eight bits as inputs oroutputs. We use this board for slow binary signalssuch as control signals for circuit breakers and theirfeedback signals.

c) D/A-Converter Board. The DS2102 is a high reso-lution high speed digital to analog converter boardwith 16 bits resolution and a settling time of 2.5sfor six parallel channels.

d) Waveform generator board. The DS2301 con-sists of six parallel channels, each comprisinga TMS320C31 processor and a D/A-converter.Each processor is separately programmable in,which we use for the generation of incrementalspeed sensor signals. This calculation is performedasynchronously to the rest of the simulation with aresolution of 6 s.

The described digital real-time simulator replaces a previoushybrid simulator [2] of significantly higher cost, with morefrequent maintenance requirements, which filled a large air-conditioned computer room. The new simulator is considerablyless costly, requires less maintenance and requires only thespace of two desktop PC’s. Comparing the fidelity of bothsimulators against actual process measurements showed a veryhigh level of fidelity for both, with no clear accuracy advantagefor either of them.

B. Numerical Results for Switches

The simulation in Fig. 12 shows the development of thevoltage and the current during switching in an - -linkwith With the chosen value the leakagecurrent decreases with a time constant Notice thevoltage peaks at switching off due to forcing the current inthe inductance to zero. The detail plot in Fig. 13 shows thatthe estimation scheme is robust against a leakage inductancemismatch ( instead of ). It can be seen thatthe scheme produces perfect stationary accuracy and that thetransient estimation error converges back to zero with a timeconstant of about 0.3 ms, which is definitely acceptable forour purpose.

C. Numerical Results for Vehicle Simulation

Closed-loop simulation of the entire vehicle is demonstratedon the example of a comparison between field-weakeningdirect self control, which is used in the upper speed range,against indirect self control, which is used in the lower speedrange of the vehicle [18], [19].

For the line side the top row of Fig. 14 shows the primary-side current of the vehicle during a transition between drivingand regenerative braking. In order to make the time scalesequal, the later braking part of the indirect self control isomitted here. Especially for the field-weakening direct selfcontrol plot one can clearly see the 180phase change in the

Fig. 12. Switch inR-L-Link. Switching times: 0.015 off, 0.03 on, 0.045off. kcorr = 0:25:

Fig. 13. Effect of modeling error inL with kcorr = 0:25:

current, which is needed in order to feed back electrical energyinto the traction mains. The second row of Fig. 14 shows howthe intermediate link voltage is affected by the transition. Note,however, that a comparison of the control schemes based onthese voltages is not straightforward due to the different motorspeeds in both cases.

Regarding the motor side, Fig. 15 shows the spatial tra-jectory of the stator flux for one of the traction motors.The hexagonal flux figure of direct self control is easilydistinguished from the circular indirect self control flux figure.It can also be seen that 1.5 s after the braking command astationary trajectory has already been reached in the left case,whereas the flux amplitude is still growing in the right case.Fig. 16 shows a detail from this transition phase, namely theelectrical motor torque and a related stator phase current. Dueto the higher motor speed the sinus approximation of the phasecurrent in direct self control with field weakening needs to bemade with fewer switching actions (hence the hexagonal fluxfigure) compared to the lower stator frequency, where a muchbetter sine wave approximation is reached (hence the almostcircular flux figure).

V. CONCLUSIONS AND PERSPECTIVE

We have presented selected results from a digital real-timesimulation of traction vehicles. Particular emphasis was placedon the simulation of converter switching phenomena in the


Fig. 14. Primary current (top row) and intermediate link voltage (bottom row) during change from driving to braking operation with field-weakeningdirect self control (left column) and indirect self control (right column).

(a) (b)

Fig. 15. Spatial stator flux trajectories during change from driving to braking operation with (a) field-weakening direct self control and (b) indirect self control.

Fig. 16. Electrical motor torque (top row) and phaseR motor current (bottom row) during change from driving to braking operation with field-weakeningdirect self control (left column) and indirect self control (right column).


otherwise continuous system. Since this hybrid nature of theproblem does not permit an exact solution in real time, wehave presented an approximation method based on an esti-mator, which has satisfied our requirements. Distributing thelocomotive model over several processors yields a samplingtime of 30 s for the continuous part, while discrete switchingis resolved even more accurately.

Overall, closed-loop real-time simulation of the vehicle us-ing the actual control system considerably simplifies followingvehicle tests on track and can also be used to reconstructand further investigate possible problems encountered duringvehicle operation. The digital simulator described here hasentered a domain that had been reserved to analog or hybridsimulators in the past due to the extremely fast electricalprocess dynamics and the complexity of handling discretecausality changes in otherwise continuous systems in real time.The graphical programming of the entirely digital simulatorgreatly simplifies the control system integration test procedure.

Although a difficult task, we hope that simulation platformsuppliers will make hybrid real-time simulation even moreuser-friendly in future versions. One promising approach canbe to do the modeling on a higher level, without initially fixingthe causalities, as is supported by object-oriented modelingtools such as Dymola [16]. An intelligent translator can thenresolve the causalities analytically for a small number ofdiscrete combinations, or, knowing the network and possibleswitch combinations, resolve them approximately by findingan appropriate estimator as demonstrated in our example.

ACKNOWLEDGMENT

The authors would like to take the opportunity to thanka number of people who have given support throughout thiswork: R. Graf, P. Wenk, P. Kulli, B. Wixinger, and P. Hasefrom ABB Daimler-Benz Transportation, Switzerland Ltd; A.Petersen and S. Menth from ABB Corp. Research Ltd, and U.Kiffmeier from dSPACE, Germany.

REFERENCES

[1] H. Buhler, “A driving simulator for investigating the static and dynamiccharacteristics of speed regulating systems for traction vehicles,”Bull.Oerlikon, no. 364/365, pp. 15–22, 1965.

[2] H. P. Wenk, “SIMSTAR-Ein modernes simulationswerkzeug. ABBverkehrssysteme AG,”Roll-On, no. 3, 1992.

[3] G. A. Korn and J. V. Wait,Digital Continuous-System Simulation.Englewood Cliffs, NJ: Prentice-Hall, 1978.

[4] F. E. Cellier, Continuous System Modeling. New York: Springer-Verlag, 1991.

[5] A. Naim, Systems Modeling and Computer Simulation. New York:Marcel Dekker, 1988.

[6] O. Ruhle, “Echtzeitsimulation schneller transienter vorgange mit Hilfevon parallelrechnern,”VDI-Fortschrittsbericht, Reihe 20, no. 127, 1994.

[7] “Technical committee on continuous simulation languages, SimulationCouncils, Inc. (SCi): The SCi continuous system simulation language,”Simulation, no. 9, pp. 281–303, 1967.

[8] Locomotive 2000 product description, ABB Transportation Systems Ltd,Schweizer Eisenbahn-Revue 10/1991.

[9] G. H. Golub and J. M. Ortega,Scientific Computing and DifferentialEquations: An Introduction to Numerical Methods. New York: Aca-demic, 1992.

[10] O. Rathjen, Digitale Echtzeit-Simulation: Simulation einer Hoch-spannungs-Gleichstrom-Ubertragung, Vieweg, 1993.

[11] T. Hopkins and C. Phillips,Numerical Methods in Practice: Using theNAG Library. Reading, MA: Addison-Wesley, 1988.

[12] G. M. Asher and V. Eslamdoost, “A novel causality changing methodfor the bond graph modeling of variable topology switching circuits,”in Proc. IMACS Symp., 1991, pp. 371–376.

[13] J. E. Stromberg, J. Top, and U. Sodermann, “Variable causality in bondgraphs caused by discrete effects,” inProc. 1st Int. Conf. Bond GraphModeling (ICBGM ’93). San Diego, CA: SCS, 1993.

[14] W. Borutzky, J. F. Broenink, and K. C. Wijbrans, “Graphical descriptionof physical system models containing discontinuities,” inProc. ESM’93,Lyon, France, 1993, pp. 203–207.

[15] H. Hanselmann, “DSP in Control: The Total Development Environ-ment,” in Proc. Int. Conf. on Signal Processing Applications and Tech-nology, Boston, MA, 1995.

[16] H. Elmqvist, F. E. Cellier, and M. Otter, “Object-oriented modeling ofhybrid systems,” inProc. ESS’93, European Simulation Symp., Delft,The Netherlands, Oct. 25–28, 1993.

[17] Matlab and Simulink, The MathWorks, Inc., Natick, MA.[18] M. Depenbrock, “Direct self-control of inverter-fed induction ma-

chines,” inProc. IEEE PESC, Blacksburg, VA, 1987, pp. 632–641.[19] J. Steinke,Pulsbreitenmodulation eines Dreipunktwechselrichters f¨ur

Traktionsantriebe im Bereich niedriger Drehzahlen. etz Archiv, vol. 11,no. 1, 1989.

[20] R. Otterbach,Geschwindigkeitsrausch Trotz Simulierter Fahrt. Elek-tronik, no. 12, pp. 126–133, 1997.

[21] M. P. Kazmierkowski and H. Tunia,Automatic Control of Converter-FedDrives. New York: Elsevier, 1994.

[22] P. Terwiesch, S. Menth, and S. Schmidt, “Relation between mechanicaland electrical oscillations in rail vehicles,” inProc. 7th Int. Conf.Harmonics in Power Syst., Las Vegas, NV, Oct 16–18, 1997.

[23] J. Stoer and R. Bulirsch,Introduction to Numerical Analysis. NewYork: Springer-Verlag, 1980.

Peter Terwiesch (M’96) received the M.Sc. de-gree in electrical engineering/automatic control fromKarlsruhe Technical University, Germany, in 1991and the Ph.D. degree in the same area from ETH,Zurich, Switzerland, in 1994.

He is currently Manager of the information tech-nology and automation software department at ABBCorporate Research in Germany. This paper is aresult of his previous position at ABB CorporateResearch in Switzerland, where he was managingthe automatic control activities.

Dr. Terwiesch is a member of the IEEE Control Systems Society.

Thomas Keller received the M.Sc. degree in elec-trical engineering from ETH, Zurich, Switzerland,in 1992.

He is a Group Manager for propulsion systemsimulation and calculation within ABB Daimler-Benz Transportation, Switzerland.

Erich Scheiben (S’88–M’90) received the M.Sc.degree in electrical engineering/automatic controlfrom ETH, Zurich, Switzerland, in 1990.

He worked on the real-time simulation projectin ABB Corporate Research, Switzerland, untilhe moved to ABB Daimler-Benz Transportation,Switzerland, together with the project in January1997.

Documents

Rail vehicle control system integration testing using digital hardware-in-the-loop simulation