A Software-in-the-Loop Simulation of Vehicle Control Unit Algorithms for a Driverless Railway Vehicle

Abstract

The realization of the first prototype of a vehicle requires several tests of the algorithms implemented on the electronic control unit (ECU). This represents an important step for conventional vehicles, which becomes fundamental when dealing with unmanned vehicles. Since there is no human supervision, most critical tasks are handled by the control unit, which results in higher complexity for the control algorithms. In this work, a software-in-the-loop (SiL) test bench is used to validate the control algorithms of a vehicle control unit (VCU) for a driverless railway vehicle (DLRV). The VCU manages the control of the traction motors, pneumatic braking systems, and range extender, as well as control of the hybrid powertrain configuration to guarantee a high level of availability via the use of redundant systems. The SiL test bench has been developed in a Simulink real-time environment, where the vehicle model is simulated along with its fundamental subsystems. The model communicates with the VCU through a CAN bus protocol in the same way that it will operate with a real vehicle. The proposed method can be used to simulate many mission profiles for the DLRV, which may last several hours each. Moreover, this kind of test bench ensures a high time resolution, which allows one to find solutions for problems which occur with a time scale that is much smaller than the simulation time scale.

1. Introduction

“Safety and security are of primary concern for any transport system. Travelers expect transportation to be safe. One of the roles of the European Commission is to respond to these expectations by ensuring that there are satisfactory standards in the whole EU for safety and security in all modes of transport.” This has been reported by the European Commission for Mobility and Transport (https://ec.europa.eu/transport/themes/security_fr, accessed on 15 May 2021).

Railway transport systems are one of the key components of public transportation in Europe, and the construction of high-speed lines, connecting many countries in a few hours of travel, makes railways lines preferrable to other transportation modes [1,2]. Due to the wide use of high-speed railway transportation, its security is crucial for guaranteeing passenger safety. To surveil this infrastructure, a dedicated driverless vehicle is designed here to run along a line and detect possible security issues. This represents the first prototype of its kind ever made and, for this reason, many design aspects have been challenging during the development phase.

As known in conventional railway practice, electrical energy is transmitted to a train by an overhead contact line (OHL). For a single bogie, a smaller amount of power is required, so lower voltages can be used. The DLRV must be as light and compact as possible to reduce power consumption. To reduce the size and weight of all components (cables, power converters, etc.), the voltage range typically used for automotive applications (400–700 Vdc) represents a suitable solution. Furthermore, being independent from the OHL, this enables the possibility of operating overnight during maintenance, i.e., when the OHL is switched off. For these reasons, it was decided to realize the DLRV as a prototype hybrid railway vehicle.

To accomplish the mission task on a high-speed line, the vehicle is required to travel 200 km with a target speed up to 200 km/h. Given the main task of the vehicle, its typical mission can be divided into four subtasks:

-

Leaving the starting station;

-

travelling on the line at an almost constant speed;

-

approaching the final station;

-

connecting to recharge.

To test the vehicle control unit (VCU) and verify the software deployed on it, it is necessary to simulate the vehicle with all the functionalities that must be handled by the VCU.

To do this, the “software-in-the-loop” (SiL) approach is widely used in engineering since it allows faster, safer, and cheaper development processes. SiL models consist of splitting a system into physical and virtual parts which are simulated in a real-time computer. In the proposed application, the hardware part is constituted by the DLRV. To properly verify the control algorithms implemented in the VCU, this part of the system can be simulated by transforming the HiL model to a SiL model.

In [3], hardware-in-the-loop simulation is defined as “a real-time simulation where the simulation of a component is performed such that the input and output signals show the same time-dependent values as the real dynamically operating component.” In [4], Plummer showed an application in the automotive industry where a car was simulated to test the control unit of the car and its response to aerodynamic and tire forces. In [5], a general approach to HiL was presented while showing several application examples. In [6], a tool was developed in a MATLAB/Simulink environment that aids the design of HiL test benches. In [7], the application of model-in-the-loop, software-in-the-loop, and HiL analysis for race car design was shown. The work focused on the breakdown of models in terms of the functional and interface layers and ensuring a standard of communication between the layers. In [8], an application of HiL was presented to simulate pantograph–catenary interaction. In that paper, the real full-scale pantograph was coupled with a virtual simulated catenary.

Going into detail regarding the problems faced in this paper, in [9], the authors proposed a method for computing rail–wheel contact forces in real-time applications. In [10], the authors proposed a multibody model of a railway car composed of seven bodies with the contact force model reported in [11]. The work in [12] used a parallel computing technique to improve computational performance, which can be particularly useful when computing wheel–rail contact in cases where the numerical approaches for the calculation of creep forces are needed and look-up tables are not practical for use (e.g., in traction studies). The work in [13] presented the use of FPGAs (field-programmable gate arrays) to parallelize the calculation of creep forces based on the FASTSIM algorithm developed by Kalker. Further examples can be found in [14,15,16,17,18]. Many applications can also be found in the field of powertrain control algorithms for HEV. In [18], the authors used a HiL approach to verify their e-CVT control algorithm.

Summarizing the above, it is possible to see that the development of a real-time model is a complicated process, and all design aspects should be studied and the risks of applying any simplifications should be estimated at the development stage; however, one of the advantages of the proposed method is that many mission profiles of the DLRV can be simulated, which may last several hours each. Moreover, this kind of test bench ensures a high time resolution. In this way, it allows one to solve some problems which occur with a time scale much smaller than the simulation time scale, like those related to the contact forces between the vehicle and the rail.

The present paper presents a software-in-the-loop test bench for the testing of a VCU for an innovative railway vehicle. This vehicle does not feature similarities for a standard railway system as it is based on a single bogie operating at 200 km/h. A lumped body model is proposed which attempts to catch the longitudinal dynamics of the vehicle, including the pitch and load transfer effects. These effects are in fact important in this case, differently from conventional railway vehicles, due to the presence of a single bogie with a wheelbase of 2.5 m. Furthermore, the model reproduces the rail–wheel contact forces so that it is possible to test antiskid algorithms. The model is in fact used to simulate the vehicle longitudinal behavior while accounting for the most important powertrain components for the purpose of testing energy management strategies; however, these are not an objective of the present paper.

This paper presents a SiL test bench that is used to validate the control strategies implemented in the VCU of the hybrid railway vehicle. Section 2 presents the vehicle characteristics with the main data. Section 3 describes the VCU, its duty, and the control strategies implemented on it. Section 4 shows the scheme of the test bench, highlighting the connection between the devices. Section 5 reports the description of the vehicle model which simulates the vehicle longitudinal dynamics. Section 6 reports the powertrain energetic model which is coupled with the model in Section 5 to simulate the energetic behavior of the vehicle to test the VCU strategies. The two models have been implemented in a Simulink real-time environment and communicate with the VCU via a CAN bus as described in the Section 4. Finally, Section 7 reports the simulation results for the vehicle and the VCU behaviors in various typical scenarios.

2. Vehicle Description

The target of this vehicle project is to realize a vehicle that runs on a high-speed line to monitor the security of the track. This vehicle must be as small as possible and must carry the necessary instrumentation to surveil the line and to work in compliance with conventional high-level safety standard of a HSL. The design of the DLRV (Figure 1) is thus based on a single existing bogie that is designed for high-speed trains and is thus compliant with the standards and requirements for a high-speed railway line, on which a carbody unit is mounted to host all powertrain components, except for motors, and the instrumentation for surveillance. The carbody unit is suspended with a dedicated secondary suspension system to reduce the vibrations induced by the vehicle dynamics in order to improve sensors measurement and component durability.

The mass, dimensions, compactness, and power requirements of this vehicle are characteristics that make the final vehicle to be closer to a sport utility vehicle (SUV) than a train. For these reasons, it was chosen to adopt vehicular power electronic equipment and not equipment derived from railway applications. Furthermore, it is possible to use low-voltage components (<1000 Vdc), thus avoiding use of the OHL (25 kV, 50 Hz AC) as a power supply system.

In conclusion, a battery-based electrical vehicle has been designed with an on-board range extender. This allows the overall size of the vehicle to be very small if compared to trains, with a beneficial effect on the aerodynamic resistance, which is very important for the typical speeds that are reached when travelling along high-speed lines, where a typical mission has a maximum speed of 200 km/h. The choice of a battery pack at 700 V allows the adoption of automotive components. The bogie assembly consists of the frame, the wheelsets, the gearbox, and the pneumatic brakes. The original traction motors mounted on the bogie have been rewound to operate at the voltage of the battery pack. This operation allows space to be saved for the motor on the bogie, which is quite confined and features an uncommon shape factor. Furthermore, since the motor is a rail component, it is already in compliance with railway standards and has been adapted to high-speed duties. To satisfy the typical mission range and increase the availability of the powertrain with a high level of redundancy, the powertrain has been designed as a series hybrid powertrain with a range extender (RE), which is useful to extend the vehicle’s range (the required range is 400 km) and to boost power supply, thus reducing the overload operating point of the battery system. When talking about powertrain, we are referring to all the components that generate power and deliver it to the wheels of the vehicle. In a series hybrid powertrain, the battery pack, electric motor, inverter, and range extender are included.

3. Vehicle Control Unit Description

The vehicle control unit (VCU) used here was a commercial hardware controller provided by Bosch Rexroth, on which a proprietary software has been developed. The VCU has many physical I/O functionalities to receive feedback from systems and command different objects, while four independent CAN bus lines are used here to communicate with several components of the powertrain and remote mission planner. As shown in Figure 2, three of the CAN bus lines are used to communicate with the two traction motor drives, with the range extender motor drive and ICE, with the BMSs of the two battery packs, and with the mechanical pneumatic brakes control unit. Nevertheless, the VCU communicates via the fourth CAN bus line with the higher-level unit, in which the mission planner (MP) is implemented. In the following, the VCU strategies related to the management of motor torque, braking, and failure are described.

3.1. Motor Torque Management

In the starting phase, the motor torque must be controlled according to an adhesion condition to avoid wheel slipping. At the beginning, the VCU provides a driving torque to only the rear axle. As reported in Figure 3, when a driving torque T_d,ref is demanded by the speed control loop, it is split among the two traction motors according to k_d as reported in Equation (1):

$$\{\begin{array}{c}{T}_{d,F}=k_d{T}_{d,ref}\\ T_{d,R}=(1-k_d)T_{d,ref}\end{array}$$

(1)

In Equation (1), k_d is a function of the vehicle speed and direction of motion (forward or reverse) such that the driving axle, when starting from a still condition, is always in the back (with respect to direction of motion). This allows one to reduce the risk of wheel slipping as the backward axle is loaded by load transfer which, for the vehicle considered, cannot be neglected (this typically happens with trains). Furthermore, this choice allows the VCU to estimate the real vehicle velocity by considering the peripheral speed of the front axle to be equal to the vehicle speed, i.e., the longitudinal creepage value is negligible. In this way, by comparing the two rotational speeds, it is possible to detect when the adhesion condition is no longer fulfilled for the driving wheelset. When the torque on the rear axle reaches the maximum value, i.e., the maximum motor torque according to the motor speed, an increasing torque is applied also on the front axle (the two torques will be the same once the speed reaches a set threshold). If the friction coefficient change along the path, wheel slipping could easily occur. Then, the VCU algorithm has been implemented to efficiently avoid such a condition. The real speed of the vehicle is then estimated by using a GPS sensor fused with the wheelset speeds. When the estimated speed is significantly different from one wheelset speed, the traction cut-off of the VCU is triggered. This procedure sets the motor torque to zero, allowing the wheelset to recover from a slip. Then, the VCU provides the wheelset with a smaller torque, which is then increased if the adhesion condition is fulfilled. This works like a car’s emergency braking system [19]. This loop of the VCU algorithm is performed whenever a slip is detected.

3.2. Braking Management

The braking system consists of two different parts, namely the electrical and pneumatic parts. The VCU deals with the management of these two components. During a braking procedure, three different phases can be distinguished. In the first one, only electrical braking is involved, i.e., the two motors are used as generators to recharge the battery packs. In the second phase, when the speed is below a given threshold, the pneumatic braking system is also enabled and the pressure of the brakes increases according to a ramp function. When the minimum speed threshold is achieved (third phase), no more power is absorbed by the motors and only the pneumatic system is responsible for slowing the vehicle. In this way, a hefty burden is not placed on the pneumatic system and the braking power can be recovered by the motors to charge the batteries.

Nevertheless, the above-described situation represents the most general case. If some battery limits occur while braking (i.e., maximum SOC or power reduction required by the BMS), the electrical braking is proportionally reduced according to the feedback provided by the batteries. At the same time, the pneumatic system compensates for this lack of braking torque.

According to Figure 4a, the speed control loop requires a braking torque $T_{b,ref}$ which is split between electric and pneumatic brakes as follows:

$$\{\begin{array}{c}{T}_{b,e}=k_e{T}_{b,ref}\\ T_{p,e}=k_p{T}_{b,ref}\end{array}$$

(2)

where k_e and k_p are weighting coefficient that range from 0 to 1 and are function of the vehicle speed and battery SOC as reported in Figure 4b,c respectively. It must be pointed out that k_p and k_e are related as follows:

$$k_p=1-k_e$$

(3)

In this way, in steady-state conditions, i.e., neglecting the actuators dynamics, the provided braking torque, which is the sum of electric and pneumatic braking torque, is equal to the demanded braking torque.

3.3. Failure Management

The software on the VCU has hence been developed considering different control and failure modes. In particular, the VCU can receive a force reference from the high-level vehicle mission planner (MP), along with a speed reference or a position reference which is chosen by mission planner according to the mission task. The VCU software commands the vehicle powertrain components to track the references generated by MP considering the actual state of each subsystem and handling possible component failure, i.e., failure for the batteries, which are one of the most critical components in the case of failure [20]. A list of the possible failures that are managed by the VCU is schematically reported below:

• Batteries:

  -

  limitation of electric braking at a high SOC;

  -

  powertrain limitation at a low SOC;

  -

  powertrain limitation for too high overload conditions (an I2T model is used);

  -

  calculation of the range extender operating point;

• drive limitations:

  -

  powertrain limitation for high motor or drive temperature;

  -

  powertrain limitation for slippery conditions;

• management of the electric vs. mechanical braking operations;

• management of rear/front traction force distribution.

Lastly, the VCU is also responsible of onboard energy management. For this reason, the range extender is activated both in the case of low battery SOC and to reduce the overload level of the batteries. Different logic is considered for defining the generated power level. Algorithms that go beyond the thermostat or power follower controller are being analyzed at present. The main purpose of the system is to let the battery discharge properly while avoiding excessive fuel consumption. In conclusion, the RE can be used as a supplementary power supply due to the rather slow dynamic characteristics of the power demand request with respect to other applications, as in [21], in which a hybrid storage system has been considered.

4. SiL Test Bench Architecture

The vehicle is made up of several components, also in terms of control units. These control units have different tasks, but they work together to manage the interaction between all parts of the vehicle.

The test bench which is presented in this work has been developed to test the control algorithms implemented in the VCU. The test bench is schematically shown in Figure 5. The VCU (Bodas Rexroth) is physically connected to other devices, with which it communicates through a CAN bus network.

The behaviors of the vehicle powertrain components and the vehicle longitudinal dynamics are simulated into the “vehicle model” (Figure 5), which has been implemented in the Simulink real-time environment running on a commercial laptop. As better described in the following, this model accounts for the vehicle longitudinal dynamics, the hybrid powertrain, and the pneumatic braking system.

The command inputs are provided by the VCU, which is triggered by the driving control unit via the CAN network. Feedback to the VCU comes from the simulation model, where simulated CAN messages for components are generated with model outputs and sent back to VCU with a dedicated hardware CAN interface like Vector CanAnalyzer.

Some examples of the information that the MP is providing to the VCU include the operating condition of the vehicle, the moving direction, the reference speed, the maximum acceleration (traction and braking), the reference force (if the vehicle is controlled with a force loop), etc.

Once the VCU receives commands from the ATO, the control algorithms inside the VCU enable the components inside the model to run the vehicle. There are also some input parameters for the “vehicle model” that are not managed by the control units, like the track height profile and the friction coefficient, which depend on the position of the vehicle along the track. Details for these parts are given in the following paragraph.

5. Longitudinal Dynamics Vehicle Model

The vehicle model must consider the important effect related to powertrain control while at the same time being as simple as possible for real-time use. In particular, the model must reproduce the energy consumption of the vehicle, which is mainly controlled by the aerodynamics, rolling resistance, track grade, and forward acceleration. Furthermore, the model must reproduce the wheel slip condition since the VCU has to handle it. To reproduce such effects, a model for contact forces is necessary, for which a correct evaluation of normal forces is required. As such, the model must reproduce the load transfer when accelerating or braking or when climbing on a graded track. The adopted model is depicted in Figure 6. It is a planar model that reproduces the longitudinal dynamics of the vehicle. It has a total of 10 degrees of freedom (DOF) with 2 constrained degrees of freedom (CDOF). The system consists of four rigid bodies:

• 1 bogie with 3 DOF
• 1 carbody unit with 1 DOF
• 2 wheelsets with 3 DOF each

The carbody unit is constrained by a pin to rotate with respect to the bogie. The pitch motion of the carbody unit is balanced by secondary suspension springs and dampers. The bogie motion consists of longitudinal motion x, heave motion z, and pitch rotation θ. The bogie is connected to wheelsets by means of longitudinal and vertical springs and dampers, representing the bushing and the primary suspension elastic behavior, respectively. The wheelset can spin about its axis and contact forces are applied to reproduce the wheel–rail contact mechanism as better detailed in the following. Both the rolling resistance and aerodynamic forces are considered. Rail contact is modeled considering the contact point vertical displacement (considered as a CDOF) and rotation due to rail grade.

Table 1. Description of the degrees of freedom for the model.

Degree of Freedom	Symbol
Bogie horizontal motion	x
Bogie vertical motion	z
Bogie pitch motion	θ1
Carbody pitch motion	θ2
Front wheelset horizontal motion	xf
Front wheelset vertical motion	zf
Front wheelset rotation	θf
Rear wheelset horizontal motion	xr
Rear wheelset vertical motion	zr
Rear wheelset rotation	θr
Constrained degree of freedom
Front wheelset contact point	zcf
Rear wheelset contact point	zcf

presents the adopted DOF of the system and the nomenclature. The equation of motion for the system is written by adopting the minimal set approach, where the equations of motion are in the form of the following:

$$\left[M\right]\ddot{q}+\left[C\right]\dot{q}+\left[K\right]q=Q$$

(4)

where q is the vector containing the system DOF (see Table 1), $\left[M\right]$ is the mass matrix, $\left[C\right]$ is the damping matrix, $\left[K\right]$ is the stiffness matrix, and $Q$ is the vector of all the external forces applied to the system.

5.1. Mass Matrix

The mass matrix of the system is defined as follows:

$$\left[M\right]={\left[{\lambda }_m\right]}^T\left[m\right]\left[{\lambda }_m\right]$$

(5)

where [m] is the diagonal mass matrix, denoted as follows:

$$\left[m\right]=\mathrm{diag}\left[\begin{array}{c}{m}_1\\ m_1\\ J_1\\ m_2\\ m_2\\ J_2\\ m_w\\ m_w\\ J_w\\ m_w\\ m_w\\ J_w\end{array}\right]$$

(6)

where m₁ is the bogie mass, J₁ the bogie pitch inertia, m₂ is the carbody mass, J₂ is the carbody pitch inertia, m_w is the wheelset mass, and J_w is the wheelset rolling inertia, while [λ_m] is the Jacobian matrix of mass matrix.

$$\left[{\lambda }_m\right]=\left[\begin{array}{cccccccccc}1& 0& 0& 0& 0& 0& 0& 0& 0& 0\\ 0& 1& 0& 0& 0& 0& 0& 0& 0& 0\\ 0& 0& 1& 0& 0& 0& 0& 0& 0& 0\\ 1& 0& h_{GF}& h_{HG}& 0& 0& 0& 0& 0& 0\\ 0& 1& 0& 0& 0& 0& 0& 0& 0& 0\\ 0& 0& 0& 1& 0& 0& 0& 0& 0& 0\\ 0& 0& 0& 0& 1& 0& 0& 0& 0& 0\\ 0& 0& 0& 0& 0& 1& 0& 0& 0& 0\\ 0& 0& 0& 0& 0& 0& 1& 0& 0& 0\\ 0& 0& 0& 0& 0& 0& 0& 1& 0& 0\\ 0& 0& 0& 0& 0& 0& 0& 0& 1& 0\\ 0& 0& 0& 0& 0& 0& 0& 0& 0& 1\end{array}\right]$$

(7)

5.2. Stiffness Matrix

The stiffness matrix of the system is defined as follows:

$$\left[K\right]={\left[{\lambda }_k\right]}^T\left[k\right]\left[{\lambda }_k\right]$$

(8)

where [k] is the diagonal stiffness matrix and is given as follows:

$$\left[k\right]=\mathrm{diag}\left[\begin{array}{c}{k}_{1xF}\\ k_{1xR}\\ k_{1zF}\\ k_{1zR}\\ k_{2zF}\\ k_{2zR}\end{array}\right]$$

(9)

where k_1x is the primary suspension longitudinal stiffness due to the suspension bushings, k_1z is the primary suspension vertical stiffness due to suspension spring, and k_2z is the secondary suspension vertical stiffness due to suspension springs, while [λ_k] is the Jacobian matrix of stiffness matrix.

$$\left[{\lambda }_k\right]=\left[\begin{array}{cccccccccc}-1& 0& h_{FC}& 0& 1& 0& 0& 0& 0& 0\\ 1& 0& -h_{FC}& 0& -1& 0& 0& 0& 0& 0\\ 0& 1& -l_1& 0& 0& -1& 0& 0& 0& 0\\ 0& 1& l_1& 0& 0& 0& 0& -1& 0& 0\\ 0& 0& l_2& -l_2& 0& 0& 0& 0& 0& 0\\ 0& 0& -l_2& l_2& 0& 0& 0& 0& 0& 0\end{array}\right]$$

(10)

5.3. Damping Matrix

The matrix [C] has the same structure of the stiffness matrix since all the considered dampers are in parallel with the considered springs:

$$\left[C\right]={\left[{\lambda }_k\right]}^T\left[c\right]\left[{\lambda }_c\right]$$

(11)

where $\left[c\right]$ is the diagonal stiffness matrix as is denoted as follows:

$$\left[c\right]=\mathrm{diag}\left[\begin{array}{c}{c}_{1xF}\\ c_{1xR}\\ c_{1zF}\\ c_{1zR}\\ c_{2zF}\\ c_{2zR}\end{array}\right]$$

(12)

where c_1x is the primary suspension longitudinal stiffness due to suspension bushings, c_1z is the primary suspension vertical stiffness due to suspension spring, and c_2z is the secondary suspension vertical stiffness due to suspension springs, while [λ_k] is the Jacobian matrix of stiffness matrix. Since the dampers are in parallel with the springs, Jacobians are the same.

5.4. Track Height Profile

The rail grade must be considered as it is important to correctly reproduce the weight force component when climbing up an inclined path. As depicted in Figure 7, the track profile is defined using the following coordinates:

• x_T, the horizontal coordinate of the track profile;
• z_T, the vertical coordinate of the track profile;
• s_T, the travelled distance of the track profile, i.e., the curvilinear abscissa following the track.

The x_T coordinate is considered as the independent variable while z_T and s_T are x_T dependent as follows:

$$z_T=z_T\left(x_T\right)$$

(13)

$$s_T\left(x_T\right)={{\displaystyle \int }}_0^{x_T}\frac{dz}{dx}dx$$

(14)

These quantities were tabled and stored in a MATLAB workspace to be used in Simulink look-up tables. Figure 7 shows the relationship between cited quantities for the k-th element of the array of data. In fact, these relationships are important since they allow the evaluation of motion for a wheel–rail contact point. When considering the front wheelset, the contact point vertical displacement and velocity are defined as follows:

$$z_{cF}=z_T\left(x_F\right)$$

(15)

$${\dot{z}}_{cF}={\frac{\partial z_T}{\partial x_T}|}_{x_F}{\dot{x}}_F$$

(16)

The rail grade α is given as follows:

$${\alpha }_F\left(x_F\right)=\arctan {\left(\frac{\partial z_T}{\partial x_T}\right)|}_{x_F}$$

(17)

Considering the typical slopes of high-speed lines, which do not exceed a few percentage points, the arctangent can be approximated with its argument without introducing significant errors. The same procedure was adopted for the rear wheelset.

5.5. Wheel–Rail Contact Forces

A model for contact forces is necessary to evaluate the driving and braking performances of the vehicle. The simulation of driving and braking maneuvers allows testing of the anti-slip control strategy implemented in the VCU.

Normal contact forces were evaluated by means of elastic contact. The contact stiffness allows decoupling of the vertical motion of the wheel center from the rail vertical motion due to a change in the height profile. Bearing in mind the target of the simulator, rail unevenness was neglected, and contact was applied on the rolling table, which was thus perpendicular to the rail. The normal contact forces F_N are then given as follows:

$$F_{Ni}=k_c\left(z_{ci}-z_i\right)+c_c\left(\dot{z_{ci}}-\dot{z_i}\right) + F_{Ni0}$$

(18)

where i stands for front f and rear r, and k_c and c_c are the contact stiffness and damping coefficients, respectively. Furthermore, F_Ni0 is the static load due to the given weight distribution.

Once the normal load was computed, the Polach contact model was used to compute the longitudinal contact forces [21,22]. The longitudinal contact force $F_{Li}$ was thus given as follows:

$$F_{Li}=F_{Ni}\frac{2\mu }{\pi }\left(\frac{k_a{\epsilon }_i}{1+{\epsilon }_i^2{k}_a^2}+\arctan \left(k_s{\epsilon }_i\right)\right)$$

(19)

where k_a and k_s are constants and ε is computed as follows:

$${\epsilon }_i=\frac{G\pi ab{C}_{11}}{4F_{Ni}\mu }\left|{\xi }_{xi}\right|$$

(20)

G is the steel shear modulus, a and b the contact area half-lengths evaluated in a static load condition, and ξ_x is the longitudinal creepage, which is defined as follows:

$${\xi }_{xi}=\frac{{\dot{x}}_i-{\dot{\vartheta }}_{i}R}{\max \left(\left|{\dot{x}}_i\right|,0.1\right)}$$

(21)

where R is the rolling radius. The friction coefficient µ is computed as follows:

$$\mu ={\mu }_0\left(\left(1-A\right)e^{-w_{s}B}+A\right)$$

(22)

where µ₀ is the static friction coefficient, w_s is the absolute sliding speed, and A and B are coefficients for Stribeck friction effect.

5.6. Rolling and Weight Resistance

Rolling resistance was simulated by applying a torque to wheels opposite to the rolling velocity, which is denoted by Equation (23):

$$T_{roll,i}=-F_{N,i}R{f}_v\mathrm{sign}\left({\omega }_i\right)$$

(23)

where i stands for front or rear, f_v is the rolling resistance coefficient, and R is the nominal wheel rolling radius.

The vehicle can move both in forward and reverse directions. To smooth the sign function, a saturated function was used as reported in Figure 8. The parameter β was used to change the minimum value of the generic variable x to have a value of 1. The parameter β was tuned according to the variable of interest.

The weight effect was instead modeled through the contact forces that were applied to the wheel by considering them to be rotated according to the rail slope. The vertical and horizontal forces applied to the wheels may thus be given as follows:

$$F_{xwF}=F_{LF} - F_{NF}{\alpha }_F$$

(24)

$$F_{xwR}=F_{LR} - F_{NR}{\alpha }_R$$

(25)

$$F_{zwF}=F_{LF}{\alpha }_F + F_{NF}$$

(26)

$$F_{zwR}=F_{LR}{\alpha }_R + F_{NR}$$

(27)

where the sine and cosine function have been linearized while considering small slope angles.

5.7. Aerodynamic Forces

Aerodynamic resistance forces are of paramount importance when evaluating the power request of a vehicle travelling at 200 km/h. The drag coefficient has thus been computed by means of computational fluid dynamics (CFD) simulations and the resulting drag force was computed as follows:

$$F_d=\frac{1}{2}\rho C_{d}S{v}^2$$

(28)

where ρ is the air density, C_d is the drag coefficient, S is area of the frontal surface, and v the vehicle speed (no wind speed is considered). Due to the high speed of the vehicle, the lift force was considered in the form given as follows:

$$F_l=\frac{1}{2}\rho C_{l}S{v}^2$$

(29)

where, like drag, the lift coefficient has been computed with CFD.

5.8. Traction Motor Model

The bogie was equipped with two traction motors, one per each wheelset, that were connected to the wheelset by means of a fixed-ratio gear transmission. The mechanical behavior of the traction motors was reproduced by accounting for the torque–speed characteristic (shown in Figure 9) as inserted in Simulink as a 1D look-up table and accounting for a first-order time lag transfer function [3] which reproduces the motor drive and electric circuit transfer function expressed in Z domain with z the discrete domain coordinate:

$$T_m=\frac{\varsigma }{z+\left(1-\varsigma \right)}{T}_{req}$$

(30)

where T_m is the delivered motor torque, T_req is the demanded motor torque by the VCU via CAN bus, and $\varsigma$ is the filter constant, which is defined as follows:

$$\varsigma =\frac{\Delta t}{{\tau }_m}$$

(31)

where $\Delta t$ is the integration time step and ${\tau }_m$ is the motor time constant.

The above-mentioned motor model represents a good compromise in term of computational effort and the quality of the results obtained. It is important to remember that the model has to be solved real time and that, at this level, we have to simulate vehicle missions lasting hours.

5.9. Pneumatic Brakes Model

The axles have disk brakes mounted on the axle which are braked by pads pushed by pneumatic actuators. Each wheelset has a dedicated pneumatic circuit which is commanded by the pneumatic brakes control unit. The braking torque applied to the i-th wheelset is thus given as follows:

$$T_{bi}=-k_p{p}_i\mathrm{sign}\left({\dot{\vartheta }}_i\right)$$

(32)

where p is the air pressure in the pneumatic actuator cylinder as generated by brake control unit, k_p is a coefficient that accounts for the mean disk radius, pad–disk friction coefficient, actuator active surface, and leverage transmission ratio. The same torque in an opposite direction is applied to the bogie. To account for pneumatic circuit dynamics, a first-order time lag transfer function was adopted to describe the pressure dynamics in i-th braking cylinder:

$$p_i=\frac{{\varsigma }_p}{z+\left(1-{\varsigma }_p\right)}{p}_{req,i}$$

(33)

where p_req is the demanded pressure by the VCU via CAN bus for the i-th brake circuit and ${\varsigma }_{\mathrm{p}}$ is the filter constant, which is defined as follows:

$${\varsigma }_p=\frac{\Delta t}{{\tau }_p}$$

(34)

where $\Delta t$ is the integration time step and ${\tau }_p$ is the pneumatic circuit time constant.

5.10. External Forces

Once all the forces were computed, the vector Q was assembled as follows:

$$Q=\left[\begin{array}{c}-F_d\\ F_l\\ -T_{mF}-T_{mR}-T_{bF}-T_{bR}\\ -F_d{h}_{HG}\\ F_{xF}\\ F_{zF}\\ T_{mF}+T_{bF}-F_{LF}R+T_{rollF}\\ F_{xR}\\ F_{zR}\\ T_{mR}+T_{bR}-F_{LR}R+T_{rollR}\end{array}\right]$$

(35)

Finally, the equations of motion were solved in a Simulink real-time environment with a forward Euler first-order integration method with a time step where $\Delta t$ = 10⁻⁴ s. This time step was chosen by simulating the model with different timesteps. The adopted value was the largest possible that showed numerical stability and negligible differences between simulation results with respect to smaller values.

6. Powertrain Model

The powertrain layout is shown in Figure 10. It is composed of two battery packs used to feed the two traction drives. Furthermore, the ICE used to produce energy onboard is injected into the vehicle’s high voltage DC bus. To properly feed all the auxiliary systems, two DC/DC converters were also installed.

All the switches shown in Figure 10 were necessary to reconfigure the high voltage system in case of a fault in order to satisfy the main requirement of having a high level of redundancy.

To avoid excessive computational loads for the model, static models have been considered for all the powertrain components with the exception for the traction motor.

6.1. Batteries

Lithium battery technology for automotive applications has profusely been tested in the past few years, proving that it is mature for use in railway applications. Thus, it has been decided to use battery pack with lithium iron phosphate (LiFePO4) cells, which represents a good compromise in term of performance/safety. Each of the two battery packs were rated 742 V and 105 Ah each, with a maximum current of 200 A.

To evaluate the battery SOC, a simple Coulomb counter has been implemented as reported in [23].

The battery packs were modeled as inputs as per the demanded power and the initial SOC (state of charge) and as outputs as per the SOC.

Starting from the demanded power, considering an efficiency value of the battery pack of 95%, the current flowing through the battery was derived dividing by the battery voltage. This value changes as a function of SOC, as reported in [17]. The battery equivalent electrical model describes the SOC as function of time according to following equation

$$SOC\left(t\right)=SO{C}_{in}-{{\displaystyle \int }}_0^t\frac{i_{BATT}\left(t\right)}{C_n}dt$$

(36)

where SOC_in is the initial SOC of the battery pack, i_BATT(t) is the battery current as a function of time, and C_n is the nominal capacity of the battery.

6.2. Range Extender Model

The range extender was made up of two main components, namely, the ICE (internal combustion engine) and an electric motor used as a generator.

The behavior of the range extender was reproduced by considering the diesel torque map and intersecting it with constant power curves, as shown in Figure 11. In this way, it was possible to derive the main working points when inserted in Simulink as a 1D look-up table.

Finally, to consider the overall RE delay, due to the ICE and the drive, a first-order time lag transfer function was introduced as follows:

$$P_{RE}=\frac{\alpha }{z+\left(1-\alpha \right)}{P}_{REfilt}$$

(37)

where P_RE is the power derived from the 1D look-up table, P_REfilt is the power once properly delayed, and α is the filter constant, which is defined as follows:

$$\alpha =\frac{\Delta t}{{\tau }_{RE}}$$

(38)

where Δt is the integration time step and τ_RE is the range extender time constant.

7. Simulation Results

This section presents the results of the simulations obtained by feeding the system with the real profile of a track between Milano and Bologna. Different scenarios have been investigated to show how the system behaves in different operating conditions. A goal was also to test the adaptability of the VCU to some parameter changes (like the friction coefficient). In the following sections, different scenarios will be presented.

7.1. Normal Operation Scenario

In the first scenario (Figure 12), the simulation started by considering fully charged batteries (100% SOC). This mission was the simplest one and required the vehicle to run at a constant speed equal to 200 km/h for about 200 km. In Figure 12a, the reference and actual speeds of the vehicle are represented with a blue line and the battery SOC values are represented with a red one. Figure 12b shows the total power of the motor drives and the total power delivered by the batteries. These quantities represent the sum of the powers of the two motor drives and the two battery packs, respectively.

In Figure 12b, the difference between the power of the motor drives and the power of the batteries represents the additional power which is provided by the range extender (RE). In any time, in fact, the total power of the motor drives $P_{drives}$ is given by the following equation:

$$P_{drives}=P_{batteries}+P_{RE}$$

(39)

The on-board energy management control algorithm allowed the batteries to operate with an almost constant SOC rate, thus allowing the vehicle to reach the end of the mission without any restriction in the performance and without excessive usage of the range extender (and hence fuel).

7.2. Low Battery SOC Scenario

In the second scenario (Figure 13), the initial SOC of the batteries did not correspond to a fully charged state, where it has been set to 50% of the maximum value. Figure 13a,b report the same quantities described in the previous case. In the second case, while the SOC was decreasing, the minimum threshold was reached (after 21 min) and then some limitations in power output were triggered. Such limitations lead to lower power provided by the batteries, which tends to zero after some minutes (Figure 13b). At the same time, the range extender started generating the maximum available power (100 kW) and maintained this steady-state condition until the SOC values of the batteries reached acceptable values. By considering this configuration, the range extender powered the motor drives according to the traction limitations and the batteries in order to charge them. In such a condition, the system achieved a new equilibrium point in terms of power consumption, although the reference velocity was still 200 km/h. Considering Equation (39), $P_{batteries}$ is equal to zero and the equilibrium is represented by $P_{drives}=P_{RE}$.

7.3. Traction and Braking Management

The goal of the third simulation scenario was to show how the VCU manages both the acceleration and deceleration phases (Figure 14). In Figure 14a–c the reference and actual speeds are depicted in blue with dashed and continuous lines, respectively, while the internal force references generated by the speed controller are represented in red. In Figure 14b–d, the motor torques are depicted in blue (continuous and dashed lines for drive one and drive two, respectively) and the brake pressure is represented in red. Figure 14a,b show the front-to-rear distribution of the torques in the acceleration phase according to the strategy described in Section 3. Figure 14c,d report the results for a simulated braking maneuver which shows the VCU braking management strategy. The speed decreases with an opposite slope with respect to the acceleration phase and, looking at Figure 14d, the three braking phases described in Section 3 can be distinguished.

7.4. Traction Management in Wheel-Slip Condition

In the last scenario (Figure 15), the aim was to investigate the response of the system with some parameters changing during the simulation. In particular, the friction coefficient was sharply decreased to show how the VCU handles wheel slipping (as described in Section 3).

Figure 15a reports the reference speed of the vehicle (blue line), the actual speed (red line), and the measured speed (yellow line). The actual speed is the real one, which is represented by the time derivative of the position of the vehicle. The measured speed, instead, was obtained by considering the rotational speed of the wheelsets multiplied by the rolling radius.

Figure 15 shows the motor drives torques and the variation of the friction coefficient which is provided as an input to the system. The motor torques are depicted in blue (line and dashed line for drive one and drive two, respectively) and the friction coefficient is represented in red.

8. Conclusions

This paper has presented a SiL test bench that has been used to validate control algorithms developed for a driverless railway vehicle. Such a vehicle represents the first prototype of its kind, since there are no other similar vehicles developed for the high-speed railway monitoring purposes. For this reason, only a few papers have compared the concept of such a vehicle and the results presented in this paper.

To date, studies regarding control strategies related to hybrid electric vehicles have mainly focused on parallel hybrid configurations. Consequently, due to the features of the DLRV described in this work, it is necessary to study and develop new control strategies according to a series hybrid configuration. The redundancy of the powertrain components requires that the control algorithm is designed to deal with failure conditions for one or more elements. In this way, the system will be able to reconfigure itself so a new working condition can be found.

This paper has shown the vehicle model set-up with a description of both the dynamic equation derivation and the actuation system (i.e., motor, brakes, and batteries). An ad hoc vehicle model has been developed and used to simulate the longitudinal dynamics of the vehicle while accounting for the load transfer effect, which is not negligible for this vehicle. The Polach model was used for the contact forces, which allowed simulation and testing of the anti-slip control mechanism of the VCU.

The results shown here demonstrate that SiL test bench can be used for simulation in many scenarios. Such results provide an overview of the behavior of the vehicle in different situations, including normal and low SOC levels for the batteries, an acceleration phase, and a braking phase. In the acceleration and braking phases, management of both the traction torque and the braking torque has been shown, with a focus on the repartition of the braking torque into the electrodynamic and pneumatic components. Moreover, the control algorithms developed for the DLRV have been tested in conditions involving wheel slipping for both the traction and braking phases. In this way, the software developed for the VCU has been deeply debugged before being used and testing with a real prototype of the DLRV.