Análisis de secuencias

6.4

System robustness analysis

The system robustness test is based on the practical situations, i.e. the vehicle load variation. Three cases are considered here.

•CASE 1: 10% decreases of vehicle body mass assuming half passengers occupied with 10% decreases in body roll inertia, and 10% decreases in body yaw inertia.

•CASE 2: 10% increases of vehicle body mass assuming vehicle over load with 10% increases in body roll inertia, and 10% increases in body yaw inertia.

•CASE 3: 17.5% increases of vehicle body mass assuming vehicle “crush load” with 17.5% increases in body roll inertia, and 17.5% increases in body yaw inertia.

Test results are illustrated in Figure 6.15 (Curving performance for the front vehicle body), Figure 6.16 (Curving performance for the rear vehicle body) and Figure 6.17 (on straight track). The results indicate that the overall system can accommodate the first two test cases both on straight and curved track. But in Test case 3, maximum value of suspension deflections in front and rear vehicle both exceed 60mm (as shown in Figure 6.16(b) and Figure 6.17(b)). The ride quality also degrades on straight track. The R.M.S. value of body centre lateral acceleration is 2.81%g, which provides an un- acceptable ride quality degradation (12%). The straight track ride quality degradation in the front and rear vehicle (Test case 3) are 6.09% and -13.69% respectively. The ride quality degradations for the center, front and rear vhicle in Test case 1 and Test case 2 are all within the required limit (7%), as shown in Figure 6.17.

6.4 System robustness analysis 0 200 400 600 800 1000 1200 −0.5 0 0.5 1 track (m)

Vehicle front body lateral acceleration (m/s

2)

Measured Front body lateral acceleration (58m/s) Normal case Test case 1 Test case 2 Test case 3

(a) Vehicle body lateral acceleration

0 200 400 600 800 1000 1200 −0.08 −0.06 −0.04 −0.02 0 0.02 0.04 0.06 track (m)

Lateral secondary suspension deflection (m)

Front lateral secondary suspension deflection (58m/s) Normal case Test case 1 Test case 2 Test case 3

(b) Lateral secondary suspension deflection

6.4 System robustness analysis 0 200 400 600 800 1000 1200 −0.5 0 0.5 1 track (m)

Vehicle front body lateral acceleration (m/s

2)

Measured rear body lateral acceleration (58m/s)

Normal case Test case 1 Test case 2 Test case 3

(a) Vehicle body lateral acceleration

0 200 400 600 800 1000 1200 −0.08 −0.06 −0.04 −0.02 0 0.02 0.04 0.06 0.08 track (m)

Lateral secondary suspension deflection (m)

Rear lateral secondary suspension deflection (58m/s) Normal case Test case 1 Test case 2 Test case 3

(b) Lateral secondary suspension deflection

6.5 Summary 3.12 3.36 2.47 3.14 2.74 2.28 3.12 2.73 2.15 3.21 2.81 2.45 3.31 2.9 2.61 0 0.5 1 1.5 2 2.5 3 3.5 4

Front vehicle Rear vehicle Centre

R .M .S .val u e ( % g )

Passive Normal Test Case1 Test Case2 Test Case3

Figure 6.17: Controller robustness test on straight track

6.5

Summary

In this chapter, the 9 DOF vehicle model is presented for further investigation of inte- grated tilt bolster and active lateral secondary suspension control. Symmetric tilting control and lateral actuator modal control are mainly addressed. The simulation re- sults show the efficiency of modal control on straight track ride quality improvement and the attenuation of the interaction between yaw and lateral dynamics. Electrome- chanical lateral actuator dynamics is discussed which slightly degrades the controller performance compared to the simulation with ideal lateral actuator. Furthermore, the overall system is well tested subject to the variation of the vehicle load.

Chapter 7

Investigation on HIL

implementation

As introduced in Chapter 1, the HIL design process consists of MIL (Model-In-the- Loop), SIL (Software-In-the-Loop) and HIL. Previous chapters mainly focus on the MIL design, the vehicle model and controllers are simulated in MATLAB/SIMULINK (a non-real time environment). In this chapter, a SIL system is configured to verify controllers before their hardware implementation. In the HIL design, xPC-Target pro- vides the real time environment for the railway vehicle model while control strategy is implemented into a FPGA-based controller. The result of 9 DOF railway vehicle control with the integrated active ARB and active lateral secondary suspension is il- lustrated via this HIL system, in which the combination of symetrical tilting control and lateral actuator modal control is adopted which is similar to the integrated tilting bolster and active lateral secondary suspension control.

7.1

SIL controller validation

SIL refers to the kind of testing done in a simulation environment to validate the behav- ior of the C code used in the controller, i.e. replacing the control algorithm in MATLAB code with C code and simulating it with the model in MATLAB/SIMULINK code. The C code mostly is generated from the code generation tools. In this section, the em-

7.1 SIL controller validation

bedded code autogeneration is introduced first followed by a SIL system configuration used in this research.

7.1.1 Embedded code auto-generation

A code generator (also automatic code generation tool or autocode tool) is essentially a compiler that translates a graphical modeling language into a high-level programming language such as from Simulink or Stateflow to C (in most cases) for the use in the embedded system. There are some commercial autocode generation tools:

• TargetLink from dSPACE (dSPACE GmbH (2010))

• Real-Time Workshop/Embedded Coder from The MathWorks (The MathWorks (2010)) • MapleSim from Maple (Maplesoft (2010))

• ASCET-SD (Advanced Simulation and Control Engineering Tool for Software Devel- opment) from ETAS (ASCET-SD (2010))

• SCADE drived by ESTEREL Technologies (ESTEREL (2010))

Most of them are used to genenrate the C code from a simulation model. These meth- ods are also called model-based auto code generators. In this study, differing from these model-based methods, the code autogeneration from Matlab m code to embedded C code is mainly addressed. Embedded MATLAB is investigated.

Embedded MATLAB is a subset of the MATLAB language, which supports MAT- LAB to C translation for implementing embedded algorithms and systems (MathWorks (2010b)). By using Embedded MATLAB, the C code can be automatically generated from MATLAB m code, which provides a direct path to embedded software implemen- tation from MATLAB. Note that the MATLAB m code should be written in a format for the Embedded MATLAB subset, but it is only slightly different compared with the normal MATLAB m code. An example of Embedded MATLAB m code for the Kalman filter is presented in Appendix G.

The standard procedures for generating C code from MATLAB m code via Embedded MATLAB are summarised below:

7.1 SIL controller validation

• Install prerequisite products (MATLAB and C Compiler) • Set up C compiler (use command ‘mex -setup’) in MATLAB

• Set up the file infrastructure based on compile search paths and naming conventions • Make the m code compliant with the Embedded MATLAB subset

• Specify properties of primary inputs by -eg/assert() • Choose the compiler target to be Embeddable C code

• Use MATLAB command: ‘emlc functionname -c -T RTW’, to generate the C code • Generate and interpret compilation reports.

Note that, the code can be generated in the fixed point data format via MATLAB fixed point toolbox functions, e.g. fi() to convert the floating point data to fixed point. But the floating point data is mainly considered here.

MODEL in SIMULINK

m function for

controller MATLAB subsetEmbedded c function for controller

VC++ 2005

C Dynamic Link Library (DLL)

C code for controller

in DLL S function in SIMULINK

Software-In-the-Loop

Model-In-the-Loop

Figure 7.1: Software-In-the-Loop process

7.1.2 SIL configuration

In this study, a SIL system combining MATLAB and C together (co-simulation) is presented. Figure 7.1 shows the overall SIL process. The controller in m function is