Verifying a Novel Distributed Braking Algorithm for Heavy-Load Trains with Hardware-in-the-Loop Testing

When Electronically Controlled Pneumatic (ECP) railway braking was introduced several decades ago, it addressed several shortcomings of traditional air braking systems. Older brake systems, which relied on the propagation of air pressure through the train’s brake pipe, suffered from delays in brake activation, uneven braking forces, and significant longitudinal impulse that increased stress on couplers and extended stopping distances. ECP braking systems address these issues by using electronic signals to activate brakes simultaneously across all cars.

While the ability to activate brakes simultaneously across all cars via electronic signals marks a major advancement, ECP has its own set of shortcomings. It lacks adaptability, applying the same braking force regardless of carriage load and terrain. A strategy known as fencing control—which involves dividing a train into segments (or “fences”) and applying independent braking to each segment—can help but requires significant communication bandwidth to manage the increased number of independent signals sent to different train segments. Taken together, these challenges not only constrain speed and weight capacity, but also potentially compromise the reliability and safety of trains with heavy loads.

At the School of Information Science and Technology of Southwest Jiaotong University, we have developed a novel distributed cooperative braking control system that addresses many of the fundamental limitations of ECP systems. With this distributed design, each carriage is equipped with its own microcontroller, resolving bandwidth and communication problems and enabling adaptive braking forces to be calculated based on specific carriage characteristics and the current terrain. Because testing such a system on a real train weighing 80 tons or more would be both unsafe and prohibitively expensive, we used MATLAB^® and Simulink^® to verify the system’s control algorithm via both simulation and hardware-in-the-loop (HIL) testing (Figure 1). The ability to rapidly verify control implementation ideas and changes initially via desktop simulation and then via HIL tests made our entire design process significantly faster, more efficient, and more cost-effective than traditional approaches.

Modeling Train Dynamics and Running Desktop Simulations

Before running any closed-loop simulations with our control algorithm, we first needed a model of the train’s dynamics. For this part of the project, we initially used a third-party, computer-aided engineering (CAE) package for train dynamics modeling. Finding that this package was inconvenient for control algorithm development, hardware deployment, and HIL testing, we subsequently switched to MATLAB.

Working in MATLAB, we modeled train dynamics using a set of more than 200 ordinary differential equations (ODEs). Key parameters for these ODEs included train speed and the load of each carriage. To validate our MATLAB implementation, we compared its results against results produced by the CAE package.

Next, we created a system model in Simulink, using a MATLAB Function block to incorporate the MATLAB train dynamics model and control algorithm. We successfully deployed the control algorithm on the STM32 Nucleo control board via Simulink Coder™. Using this system model, we ran extensive simulations on the desktop, varying internal parameters, such as train speed and carriage load, as well as external conditions, such as track slope and curvature. We used MATLAB to visualize simulation results, including the acting traction and braking force generated by the control algorithm (Figure 2), as well as velocity during braking (Figure 3) and coupler force (Figure 4). The simulation results not only validated the algorithm’s functional logic but also informed refinements to the control design. In fact, the ability to generate ODE plots and other graphs in batches with MATLAB contributed to an 80% increase in our overall efficiency.

Verifying Real-Time Performance with HIL Testing

Once we were satisfied with the basic functionality of the control algorithm, as validated via desktop simulation, we were ready to begin real-time HIL testing. For this phase of the project, we used Simulink Desktop Real-Time™ to run the Simulink train model with the embedded MATLAB Function block on a laptop. We deployed the control model to a STMicroelectronics^® STM32 Nucleo board using the STMicroelectronics Nucleo Support Package. The laptop and STM32 board were linked via serial USB connection, and the board was directly connected to solenoid-actuated air intake and exhaust valves for the brake cylinder.

Running tests using this HIL setup, we monitored the change in brake cylinder air pressure during the braking process for a variety of scenarios and observed the actuation of intake and exhaust valves. Whereas our desktop simulations were primarily focused on the controller’s basic functionality and its braking force output, our HIL tests were focused on the controller’s real-time performance and its integration with real hardware, specifically setting the switch state of the solenoid-actuated valves. The ability to observe pressure changes and real-time valve actuation during simulated train operations provided valuable insights into how the controller would perform under real-world conditions.

Next Steps

The HIL testing platform we built with MATLAB, Simulink, and Simulink Desktop Real-Time has enabled us to prove that our distributed cooperative braking algorithm is functionally sound in a real-time operating environment. As we continue to refine and improve upon the algorithm, we are also planning improvements to the simulation and HIL environment. For example, we are exploring ways to extend the use of Simulink with Simscape™ to model the train motor and to eventually build a physical testbench to simulate train motion.