Developing PLC-Based Control and Management Systems for Electric and Diesel Multiple-Unit Railway Vehicles

Modern railway vehicles, carriages, and other rolling stock are equipped with sophisticated train control and management systems (TCMS). The TCMS is responsible for safety-critical tasks, such as emergency braking and emergency engine shutdown, as well as for passenger comfort systems, such as heating and ventilation.

Because of its safety-critical nature, TCMS software must meet stringent requirements. The software must be certified compliant with functional safety standards such as EN 50128, which covers software for railway control and protection systems. Thorough and continuous testing is key to a successful certification process. In traditional development processes, however, testing cannot begin until hardware is available, when software defects are extremely costly to fix and may even be missed.

At PESA, we use Model-Based Design to develop real-time TCMS software for locomotives, electric multiple units (EMUs), and diesel multiple units (DMUs)  (Figure 1).   Our engineers model low-level software requirements in Simulink^® and Stateflow^®, run simulations to verify their designs, and generate IEC 61131-3 Structured Text for deployment to a programmable logic controller (PLC). With this approach, we ensure that the implemented software matches requirements, identify defects earlier, shorten testing times, and provide better documentation to certification authorities to streamline the certification process.

Modeling and Simulating the TCMS Software

We begin by defining the initial system requirements in ALM software Polarion. These requirements include safety features, such as emergency braking, traction control, and diesel engine shutdown, and non-safety-critical features, such as control of lighting, heating, ventilation, and other passenger comfort systems.

We then model low-level software requirements in Simulink and Stateflow. State transition diagrams in Stateflow clearly show all the states in the system as well as conditions to be checked and actions to be performed (Figure 2). Whenever possible, we reuse components from our custom Simulink library, which includes a regulator that adjusts diesel engine speed based on the current power demand.

In addition to developing control models, we also develop plant models for hardware components of the train. We use these plant models to run closed-loop simulations in Simulink to verify the functionality of our control design before prototype hardware is available. Even when the hardware is available, we continue to use simulations to verify features that would be difficult or time-consuming to verify on the actual train (Figure 3). For example, it can take days to discharge a battery and hours to increase the temperature inside the passenger car to a specific set point. In Simulink, we can simulate drops in voltage or changes in temperature within minutes to quickly verify the functionality of electrical and passenger comfort systems under a variety of operating conditions.

Generating and Testing the Structured Text

After verifying the design via simulation, we generate Structured Text from our Simulink and Stateflow models using Simulink PLC Coder™. Because the generated code is never modified manually, we are 100% confident that it matches the requirements and design captured in the models. We then compile the Structured Text in our PLC integrated development environment (IDE), where we run limited tests before deploying to the actual PLC for real-time tests. In the past, these tests were our first opportunity to verify the design. With Model-Based Design, we run extensive simulations before reaching this point. As a result, we detect problems much earlier and have significantly fewer problems later in development. Our tests are now focused on those aspects of the design not readily verified through simulation, enabling us to reduce testing time by more than 30%.

The ability to generate Structured Text from our models not only eliminates defects introduced by hand-coding, but it also gives us the flexibility to target different PLC hardware. We currently use PLCs from three vendors. We can use the same Simulink models to generate Structured Text—or even C code—for implementation on any of the PLCs.

Our testing process is based on the EN 50128 standard. In this process, we create software components tests based on our software component design specification (SCDS). This document describes component data types, value ranges, and safety integrity levels as well as interactions between software components. Because the SCDS defines how input variables affect output states, test engineers can test each software component using a black-box model that includes a PLC functional block containing the Structured Text generated with Simulink PLC Coder (Figure 4).

Our test environment consists of a PLC controller that has the same processor and input/output modules as those used on the railway vehicle, simulating devices, and testing software. The testing software includes an array of simulated switches and LEDs as well as elements for specifying and displaying analog values, such as vehicle speed and coolant temperature (Figure 5). Test engineers use this software to set inputs according to established test scenarios for the component and then verify that the outputs displayed in the software match those defined in the scenarios.

Pursuing Certification EN 50128 and Next Steps

We are in the process of certifying our safety-relevant software as compliant with EN 50128 safety integrity level (SIL) 2 standards with TÜV SÜD. We expect our use of Model-Based Design in documenting, simulating, and verifying the software to expedite this process. If the certification authority reviewers want to compare two versions of our system, we can use the models and documentation to show that design changes were implemented exactly as we have described. In the past, reviewers had to rely on examining the source code.

As a next step, we are going to further streamline the certification process by linking our system requirements in Polarion to the model components that implement them in Simulink. We also plan to expand our use of Model-Based Design to the development of advanced driver assistance systems. For example, we are exploring the combination of image processing and machine learning techniques to process input from thermal cameras and other sensors for a collision-avoidance system that will detect obstructions on the tracks and automatically apply the brakes.