Numerous embedded electronic systems are installed on a railway train, and they are responsible for the operation of the different subsystems of the train. The development of these products involves a great number of challenges, such as market entry time, obsolescence period or cyber security. Engineers of Knorr-Bremse Budapest give us an insight into this field.
Contact
Knorr-Bremse Vasúti Jármű Rendszerek Hungária Kft.
Helsinki út 105.
Magyarország - Hungary
info@knorr-bremse.com
Embedded systems on railway trains
Embedded systems operate autonomously, yet they’re also engaged in intensive communication with the outside world and their environment. The same goes for the railway industry, where several embedded systems are operated on a train, such as the brake control units, the heating, ventilation and air conditioning subsystem, the door control units, and other elements responsible for the lighting, passenger information or even the traction. When developing embedded systems, one can encounter a large number of challenges, the most current of which are presented in this article through the example of brake control.
Take a brake with us
At Knorr-Bremse Budapest, every day we're working toward a safer and greener future. Take a "brake" with us. In a series of articles, we not only show how railway brake controllers and related features and systems work, but we also provide behind-the-scenes insights. Our engineers themselves tell us how development and testing takes place, how the various components are put together into a complete whole by the end of the process - things which ensure the passenger only feels that the vehicle is coming to a stop in the exact place and way in which it is supposed to.
Challenges
Brake control units perform safety critical functions, therefore partial or full outage or malfunctioning of such a system may in extreme cases lead to fatal consequences. To avoid that, each development phase – from system conception to full validation – happens according to strict processes, applying techniques and activities prescribed as compulsory by international norms and internal standards, moreover, requirements of internal instructions are in many cases more stringent than the applicable standards. This highly process oriented approach slows down market entry, presenting considerable challenges when it comes to meet delivery expectations of customers. However, some proven solutions exist to reduce development time, such as developing hardware and software in full parallel, or reusing more of the modules that are already finished.
Elements of the brake control, including electronics, are designed for decades of normal operation which requires company-level strategy to manage the obsolescence of hardware and software components. This is the so-called Obsolescence Management. Electronic components have a typical market availability of 15 years, meaning that, over its entire production lifetime, practically all elements of a control unit get replaced. For this reason, a key design objective is to simplify the process by designing architectures that ensure that such changes do not require software modifications. Beyond the hardware, obsolescence affects the supporting tool chain as well; it is enough to think of a compiler used in the 90s, where for maintenance purposes the operable software environment is required even today.
Another serious challenge is to reduce the cost of modification, be it planned or extraordinary. The total expenditure appearing over the entire supply chain is considerable. For example, in the event of a software failure, the program should be retested and qualified after the fix, and then released into production and, if necessary, updated for units already shipped. All this is an especially complicated process in the railway market with its many stakeholders, which is one of the reasons why strict operational processes cannot be slackened.
With the Ethernet-based networks gaining dominance, new opportunities and challenges emerged also in the field of brake control systems. Ensuring the proper cyber security level is a pivotal question for Knorr-Bremse too, while managing it and building it into the development process require completely new competences. As a result, various phases of the lifecycle are broadened with new elements such as risk analysis during the design phase, application of supplementary coding regulations during the implementation phase, penetration testing jointly with system testing, or continuous vulnerability monitoring carried out even after end of development.
All this require special caution, since not all the components of the control software are developed in-house, but they include an ever-growing portion of elements from third parties which are also subject to compliance guidelines. Moreover, the software made by third parties also have to be compliant with the applicable licence requirements, making in many cases a deeper involvement of product managers, project leaders and company lawyers necessary.
All this clearly shows that the development of embedded systems under the Knorr-Bremse umbrella offers many exciting challenges that demand continuous and swift alignment of the development departments to customer requirements and standard specifications, while maintaining the expected quality and return on investment.